S2S-authentication

אימות S2S מוכיח איזה שירות/עבודה הופך את הבקשה ומעניק לה את הזכויות המינימליות הדרושות לזמן מוגבל. בניגוד לזרמי משתמש, אין כאן אדם - לכן, אורך החיים הקצר של תעודות, קשירה קריפטוגרפית לאימון/ערוץ ויכולת תצפית ברורה הם קריטיים.

1) מטרות ועקרונות

אפס אמון כברירת מחדל: לא לסמוך על הרשת, רק הסמכה של האימון והצפנה.
נקודות זכות קצרות חיים: דקות, לא ימים/חודשים.
קשירת הקשר: דייר/אזור/רישיון/קהל/סקופים.
הוצאה מרכזית, אימות מבוזר: STS/IDP + אימות מקומי.
זכויות מינימליות ומשלחת מפורשת: רק סקופים הכרחיים וביקורות.
סיבוב ”ללא כאב”: חלונות כפול מפתח/כפול סלט ואוטומציה.

2) מודל איום (מינימום)

גניבה של סודות ארוכי ימים (מפתחות אפי, RT ארוך חיים).
זיוף שירות בתוך אשכול VPC/.
התקפות בין-אזוריות במקטע שבור.
תחליף תנועה חוזר/פרוקסי.
החלפת תמונת שרשרת אספקה/מכולה.
שגיאות הגדרות (כללי חומת אש/רשת רחבה, JWKS נפוץ לכולם).

3) דפוסים בסיסיים S2S

3. 1 MTLS (תעודות משותפות)

מי אתה: מוכיח על ידי הערוץ.
תעודות קצרות ימים (שעה-יום) מ-PKI פנימי; שחרור/סיבוב מנוהל על ידי רשת/צד או סוכן SPIRE.
טוב ל ”שכנים” באותו תחום אמון ולאסימונים מחייבים.

3. 2 שירות JWTs (STS)

מי אתה: מוכיח עם הודעה.
גישה קצרה JWT (2-5 דקות) עם "audd'," scp "," דייר "," אזור ".
סימנים KMS/HSM, מפתחות ציבוריים - באמצעות JWKS עם 'ילד' וסבב.
בדוק באופן מקומי (ללא שיחת רשת IDP).

3. 3 SPIFE/SPIRE (SVID)

זהות אוניברסלית של עובדים: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
X.509/JWT-SVID הוצאה אוטומטית/סיבוב, אינטגרציה עם איסטיו/לינקרד.

3. 4 אוט '2. 1 אישור לקוח/החלפת טוקן (RFC 8693)

לקוחות מכונה לקבל אסימון מ STS; עבור פעולות ”מטעם” - OBO (החלפת סמלים).

שילוב: mTLS עבור הערוץ, JWT עבור ההודעה, SPIFFE עבור זהויות יציבות.

4) ארכיטקטורת התייחסות

[KMS/HSM]       [Policy Store / PDP]

[STS/IdP (issuer)] ── JWKS ──[Gateway/PEP] ─────[Services/PEP]
│
SVID/JWT │         │    │      │
(SPIRE/Istio)│      mTLS/DPoP  │    mTLS/DPoP
│         │    │      │
[Workload/Sidecar]─────────┴───────┴────────────┘

Issuer (STS/IDP): משחרר שירות קצר JWT/CVID, מפרסם את JWKS.
שער (PEP): מונח רשת, תוקף mTLS/JWT, מעשיר את ההקשר, מבקש PDP.
שירותים (PEP) - הגנה לעומק, מטמון פתרונות PDP.
תעודות אוטומטיות ו-SVID ל-mTLS.

5) פורמט שירות JWT (דוגמה)

json
{
"iss": "https://sts. core",
"sub": "svc. catalog, "//service identity
"aud": ["svc. search"] ,//target service/domain
"exp": 1730390100, "iat": 1730389800,
"tenant": "brand_eu",
"region": "EE",
"scp": ["catalog:read:public","catalog:read:tenant"],
"mtls": { "bound": true, "spiffe": "spiffe://core/ns/prod/sa/catalog" }
}

ES256/EdDSA חתום, ”ילד” מציין מפתח פעיל.
כבילה אופציונלית לערוץ: דגל, חשיש סרט, SVID.

6) מדיניות הוצאה לפועל (STS) ואימות

• הנבדק נלקח מרשימת תעודות הלקוח/לקוח של SVID.
• תוחלת חיים 2-5 דקות, רענן אף אחד - לבקש STS שוב במקום.
• סקופים/קהל נלקחים מחנות הפוליסות (GitOps), ולא מבקשת לקוחות.

1. בדוק אם ־ TLS (אופציונלי) ותוקף שרשרת.

2. בדוק חתימת JWT על ידי JWKS (על ידי ”ילד”).

3. בדוק 'exp/nbf/iss/aude', דייר/אזור/רישיון.

4. להעשיר את ההקשר ולשאול PDP (RBAC/ABAC/ReBAC).

5. פתרון PDP מטמון (TTL 30-120 S), נכות באירוע.

7) רב-דיירים ואזורים (תחומי אמון)

אמונים נפרדים 's:' spife ://euro. Core ',' spiffe ://latam. ליבה ".
הפרד JWKS/PKI לפי אזור; ביניים - רק דרך שערים אמינים.
כלול ”דייר/אזור/רישיון” בבולים ובדוק ציות משאבים.
רישומי קטע/ביקורת על ידי דיירים ואזורים.

8) רשת/סירה ומצב ללא רשת

Istio/Linkerd: MTLS מתוך הקופסה, מדיניות-אכיפה ברמה L4/L7, אינטגרציה עם SPIRE.
ללא רשת: ספריית לקוחות + TLS הדדית ביישום; קשה יותר לנהל סיבוב - אוטומט באמצעות סוכן.

9) מפתחות, JWKS וסבב

מפתחות פרטיים רק ב ־ KMS/HSM; חתימה - על ידי שיחה/סט מרוחק.
סיבוב כל יום N; מפתח כפול: ישנים + חדשים מתקבלים, מסירים סימנים חדשים לאחר חימום מטמונים.
ניטור: נתח של צריכה על ידי ”ילד”, תלה לקוחות על המפתח הישן.

yaml issuer:
jwks:
alg: ES256 rotation_days: 30 publish_cache_ttl: 60s sts:
access_ttl: 5m audience_policies:
- subject: "svc. catalog"
allow: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
tenancy:
claims: ["tenant","region","licence"]
jwks_per_region: true

10) קשירת קישור (DPoP/mTLS-bounding)

אסימונים של MTLS: הוסף חשיש תעודת הלקוח JWT; תבדוק בקבלת הפנים.
DPoP: ללקוחות HTTP ללא mTLS - לחתום על כל בקשה עם מקש DPoP, למקם טביעת אצבע DPoP ב-AT.

11) שגיאות ומדיניות החזרה

• '401 INVALID_TOKEN'/'EXPIRED_TOKEN'/'AUD_MISMATCH'.
• '401 MTLS_REQUIRED'/'MTLS_CERT_INVALID'.
• '403 INSUFFICIENT_SCOPE'/'POLICY_DENY'.
• 429 RATE_LIMITED'.

התגובה מכילה ”שגיאה _ קוד” של המכונה ו ”as _ of” (גרסת מפתח/מדיניות).

12) יכולת תצפית וביקורת

• 's2 _ auth _ p95 _ ms',' לאמת _ jwt _ p95 _ ms', 'jwks _ skew _ ms',
• 'invalid _ token _ rate', 'aud _ insmatch _ rate', 'לא מספיק _ scope _ rate',
• צריכת על ידי ”ילד”, הפרופורציה של בקשות כבולות mtls.

• 'substlect',' aud', 'דייר', 'אזור', 'scp', 'ילד', 'sid/svid',' החלטה ',' מדיניות _ גרסה ',' trace _ id'.

• תמצית טוקן, סיבוב מפתח, שינויי מדיניות, בקשות נדחו.

13) ביצועים

אימות JWT - באופן מקומי, מטמון JWKS (TTL 30-60 S) עם עדכון רקע.
שרשראות X.509 - מצמיד CA ומטמון OCSP/CRL.
תביא את האימות היקר אל השער/סירה.
השתמש באסימונים/תעודות (10-20 שניות לפני התפוגה).

14) בדיקה

חוזה/אינטרופ: NP/ספריות שונות, שעון רזה net300 s.
שלילי: פג תוקף/אסימון מזויף, לא נכון, אזור/דייר שגוי, שרשרת סרוט שבורה.
כאוס: סיבוב פתאומי 'ילד', חוסר זמינות של JWKS, תפוגה בהמוניהם, שבירת MTLS.
גיליון שיא ב-STS, לאמת ספייק בשער.
E2E: mtls-only, JWT-בלבד, מצב משולב, Token Exchange (OBO).

15) ספרי משחק (ספרי הפעלה)

1. פשרת מפתח חתימה

ביטול מיידי 'ילד', שחרור אסימונים חדשים, TTL מקוצר, ביקורת, חיפוש לקוחות ”תלוי”, הכחיש מאולץ ”ילד ישן”.

2. MASS 'INVALID _ TOKEN&pos

בדוק את מטמון JWKS, יישור שגוי של השעון, מקור סמלי (TTL קצר מדי), הרחיב זמנית את הסובלנות של skew, חימם את JWKS.

3. סירוב MTLS

בדוק שרשרת CA, תאריכי SVID, זמן מארח; דחוף-מחדש באמצעות SPIRE/Istio, לאפשר נתיבי חזרה רק בתוך האזור.

4. 'AUDD _ MISMATCH' growth

מדיניות הקהל: השוו בין מדיניות STS-Policy לבין שיחות בפועל, הוסיפו באופן זמני את ה-Aud הרצוי, קבעו שינויים בארכיטקטורה.

5. STS לא זמין/איטי

הגדל את ה ־ TTL של אסימונים שכבר הונפקו (בחסד), אפשר prefetch/רענון-מוקדם יותר, STS-אאוט בקנה מידה.

16) שגיאות אופייניות

מפתחות אפי-איי-איי/סודות ארוכי חיים בקוד אינוו.
גנרל JWKS/PKI ”לכל האזורים ולכל הזמנים”.
חוסר קשירה (mTLS/DPoP) = קל לקחת את האסימון.
Broad 'aud' ו ”מנהל” סקופים כברירת מחדל.
סיבוב ללא מחזור דו-מפתח = מסה 401.
בדיקת אסימונים רק על שער (אין הגנה בעומק).
כשל ”מטומטם” (ללא ”שגיאה _ קוד” ו ”סיבה”) - קשה להדיח ולאמן צוותים.

17) תבניות הגדרות מיני

yaml auth:
require_mtls: true jwks:
url: https://sts. core/.well-known/jwks. json cache_ttl: 60s claims:
required: ["iss","sub","aud","exp","tenant","region"]
tenant_in_header: "x-tenant"
pdp:
endpoint: "opa:8181/v1/data/policy/allow"
decision_cache_ttl: 60s

yaml subjects:
- id: "svc. catalog"
spiffe: "spiffe://core/ns/prod/sa/catalog"
audiences: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
ttl: "5m"

18) רשימת בדיקות לפני המכירה

[ ] שירות קצר JWT (5 דקות), אימות מקומי, מטמון JWKS.

[ ] MTLS (או DPoP) מופעל; עדיפות - אסימונים קשורים mTLS.

[ ] SPIFFE/SPIRE או מקביל להנפקה אוטומטית/סיבוב של תעודות.

[ ] STS עם מדיניות קהל/היקף; הוצאה על ידי זהות מהימנה בלבד.

[ הפרדת אמונים ] JWKS; בדקו בולי דייר/אזור/רישיון.

[ ] PDP/PEP משולב, מטמון תמיסה + נכות באירוע.

[ ] חלונות עם מפתח זוגי, ניטור צריכת 'ילד', התראות לאי התאמה תקפה/אוד.

[ ] רישומים/ביקורת מלאה S2S, מטרי ביצועים/שגיאות מופעלים.

[ ] פשרות מפתח, נפילת STS, כשל mTLS.

[ ] contract/negative/chaos/load/E2E הסוויטה עברה.

סיכום

אימות S2S הוא שילוב של ערוץ-אמון (MTLS), מסר-אמון (קצר JWT) וזהות עובדת עקשנית (SPIFFE), המנוהל על ידי STS מרוכז ומאומת באופן מקומי. הוספת הפרדת דומיין אמון, קהל/סקופים קפדניים, סיבוב אוטומטי ויכולת תצפית - ויש לך מתווה אמין, בר הסברה ומסקרן יחד עם הפלטפורמה והגיאוגרפיה שלה.