S2S-authentication

S2S प्रमाणीकरण से साबित होता है कि कौन सी सेवा/वर्कफ़्लो अनुरोध करती है और इसे सीमित समय के लिए न्यूनतम आवश्यक अधिकार देती उपयोगकर्ता धाराओं के विपरीत, यहां कोई व्यक्ति नहीं है - इसलिए, क्रेडेंशियल्स का छोटा जीवनकाल, कसरत/चैनल के लिए क्रिप्टोग्राफिक बाइंडिंग और स्पष्ट अवलोकन महत्वपूर्ण हैं।

1) लक्ष्य और सिद्धांत

डिफ़ॉल्ट रूप से शून्य ट्रस्ट: नेटवर्क पर भरोसा न करें, केवल कसरत और क्रिप्टोग्राफी का प्रमाणन।

अल्पकालिक क्रेडिट: मिनट, दिन/महीने नहीं।

संदर्भ बाइंडिंग: किरायेदार/क्षेत्र/लाइसेंस/दर्शक/स्कोप।

केंद्रीकृत जारी, विकेंद्रीकृत सत्यापन: एसटीएस/आईडीपी + स्थानीय सत्यापन।

न्यूनतम विशेषाधिकार और स्पष्ट प्रतिनिधिमंडल: केवल आवश्यक स्कोप और ऑडिट।

"दर्द-मुक्त" रोटेशन: दोहरी-कुंजी/दोहरी-प्रमाणित खिड़कियां और स्वचालन।

2) धमकी मॉडल (न्यूनतम)

लंबे समय तक रहने वाले रहस्यों की चोरी (एपीआई-कुंजी, लंबे समय तक जीवित आरटी)।

वीपीसी/क्लस्टर के भीतर सेवा स्पूफिंग।

टूटे हुए विभाजन में अंतःक्षेत्रीय हमले।

रीप्ले/प्रॉक्सी ट्रैफिक प्रतिस्थापन।

आपूर्ति-श्रृंखला/कंटेनर छवि प्रतिस्थापन।

कॉन्फ़िगरेशन त्रुटियाँ (विस्तृत फ़ायरवॉल/मेष नियम, सभी के लिए सामान्य JWKS)।

3) बुनियादी पैटर्न S2S

3. 1 mTLS (आपसी प्रमाणपत्र)

आप कौन हैं: चैनल द्वारा साबित होता है।

आंतरिक पीकेआई से अल्पकालिक (घंटे-दिन) प्रमाणपत्र; रिलीज/रोटेशन को जाल/साइडकार या एसपीआईआरई एजेंट द्वारा प्रबंधित किया जाता है।

एक ही ट्रस्ट डोमेन में और बाध्यकारी टोकन के लिए "पड़ोसियों" के लिए अच्छा है।

3. 2 सेवा JWTs (STS)

आप कौन हैं: एक संदेश के साथ साबित होता है।

शॉर्ट एक्सेस JWT (2-5 मिनट) 'aud', 'scp', 'किरायेदार', 'क्षेत्र' के साथ।

KMS/HSM, सार्वजनिक कुंजी - JWKS के माध्यम से 'बच्चे' और रोटेशन पर हस्ताक्षर करता है।

स्थानीय रूप से जाँचें (कोई IdP संजाल कॉल नहीं)।

3. 3 SPIFFE/SPIRE (SVID)

कामगारों की सार्वभौमिक पहचान: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'।

स्वचालित जारी/रोटेशन X.509/JWT-SVID, इस्तियो/लिंकर्ड के साथ एकीकरण।

3. 4 OAuth 2। 1 क्लाइंट क्रेडेंशियल्स/टोकन एक्सचेंज (RFC 8693)

मशीन क्लाइंट एसटीएस से एक टोकन प्राप्त करते हैं; उपयोगकर्ता के लिए "ओर से" कार्रवाई - 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]─────────┴───────┴────────────┘

जारीकर्ता (एसटीएस/आईडीपी): लघु सेवा JWT/CVID जारी करता है, JWKS प्रकाशित करता है।

गेटवे (PEP): नेटवर्क टर्म, mTLS/JWT को मान्य करता है, संदर्भ को समृद्ध करता है, PDP का अनुरोध करता है।

सेवाएं (पीईपी) - गहराई में रक्षा, पीडीपी समाधान कैश।

SPIRE/mesh: mTLS के लिए ऑटो-सर्टिफिकेट और SVID।

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, 'बच्चा' सक्रिय कुंजी इंगित करता

चैनल के लिए वैकल्पिक बाइंडिंग: फ्लैग, हैश सर्टिफिकेट, एसवीआईडी।

6) जारी करने की नीतियां (एसटीएस) और सत्यापन

• विषय SVID/क्लाइंट प्रमाणपत्र/क्लाइंट रजिस्टर से लिया जाता है।
• लाइफस्पैन 2-5 मिनट, कोई भी ताज़ा न करें - इसके बजाय फिर से एसटीएस के लिए पूछें।
• स्कोप/दर्शकों को पॉलिसी स्टोर (GitOps) से लिया जाता है, ग्राहक के अनुरोध से नहीं।

1. एमटीएलएस (वैकल्पिक) और श्रृंखला वैधता की जाँच करें।

2. JWKS ('बच्चा' द्वारा) द्वारा JWT हस्ताक्षर की जाँच करें।

3. 'exp/nbf/is/aud', किरायेदार/क्षेत्र/लाइसेंस की जाँच करें।

4. संदर्भ को समृद्ध करें और पीडीपी (RBAC/ABAC/ReBAC) से पूछें।

5. कैश पीडीपी समाधान (टीटीएल 30-120 एस), घटना विकलांगता।

7) बहु-किरायेदार और क्षेत्र (ट्रस्ट डोमेन)

ट्रस्ट-डोमेन 's: ' spiffe ://eu. कोर ',' spiffe ://latam। कोर '।

क्षेत्र द्वारा अलग JWKS/PKI; परस्पर - केवल विश्वसनीय प्रवेश द्वार के माध्यम से।

टिकटों में 'किरायेदार/क्षेत्र/लाइसेंस' शामिल करें और संसाधन अनुपालन की जांच करें।

किरायेदारों और क्षेत्रों द्वारा खंड लॉग/ऑडिट।

8) मेश/साइडकार और नो-मेश मोड

Istio/Linkerd: mTLS बॉक्स से बाहर, L4/L7 स्तर पर नीति-प्रवर्तन, SPIRE के साथ एकीकरण।

जाल के बिना: आवेदन में क्लाइंट लाइब्रेरी + आपसी टीएलएस; रोटेशन का प्रबंधन करना अधिक कठिन है - एजेंट के माध्यम से स्वचालित

9) कुंजी, JWKS और रोटेशन

केवल केएमएस/एचएसएम में निजी कुंजी; हस्ताक्षर - रिमोट कॉल/सेट द्वारा।

हर एन दिन घूर्णन; दोहरी कुंजी: पुराने + नए स्वीकार किए जाते हैं, कैश वार्मिंग के बाद जारीकर्ता नए संकेत देते हैं।

निगरानी: 'बच्चे' द्वारा खपत का हिस्सा, पुरानी कुंजी पर ग्राहकों को लटका दिया।

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) लिंक बाइंडिंग (डीपीओपी/एमटीएलएस-बाउंड)

mTLS-बाउंड टोकन: JWT में क्लाइंट सर्टिफिकेट हैश जोड़ें; रिसेप्शन पर जाँच करें।

DPoP: बिना mTLS के HTTP क्लाइंट के लिए - DPoP कुंजी के साथ प्रत्येक अनुरोध पर हस्ताक्षर करें, AT में DPoP थंबप्रिंट रखें।

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) अवलोकन और लेखा परीक्षा

• 's2s _ auth _ p95 _ ms', 'सत्यापित _ jwt _ p95 _ ms', 'jwks _ skew _ ms',
• 'invalid _ token _ rate', 'aud _ mismatch _ rate', 'अपर्याप्त _ scope _ rate',
• 'बच्चे' द्वारा खपत, एमटीएलएस-बाउंड अनुरोधों का अनुपात।

• 'subject', 'aud', 'किरायेदार', 'क्षेत्र', 'scp', 'बच्चा', 'sid/svid', 'निर्णय', 'नीति _ संस्करण', 'trace _ id'।

• टोकन जारी करना, कुंजी रोटेशन, नीति परिवर्तन, अनुरोधों को अस्वीकार कर दिया।

13) प्रदर्शन

JWT सत्यापन - स्थानीय रूप से, पृष्ठभूमि अद्यतन के साथ कैश JWKS (TTL 30-60 s)।

X.509 चेन - सीए पिनिंग और OCSP/CRL कैश।

गेटवे/साइडकार में महंगा सत्यापन I/O लाएँ।

प्रीफेच टोकन/प्रमाणपत्र का उपयोग करें (समाप्ति से पहले 10-20 सेकंड)।

14) परीक्षण

अनुबंध/इंटरऑप: विभिन्न एनपी/पुस्तकालय, घड़ी तिरछा। 300 एस।

नकारात्मक: समाप्त/नकली टोकन, गलत 'aud', गलत क्षेत्र/किरायेदार, टूटी हुई सर्टिफिकेट-श्रृंखला।

अराजकता: अचानक रोटेशन 'बच्चा', JWKS की अनुपलब्धता, समाप्ति एन मस्से, mTLS टूटना।

लोड: एसटीएस पर पीक इश्यू, गेटवे पर स्पाइक सत्यापित करें।

E2E: एमटीएलएस-ओनली, जेडब्ल्यूटी-ओनली, संयुक्त मोड, टोकन एक्सचेंज (ओबीओ)।

15) प्लेबुक (रनबुक)

1. हस्ताक्षर कुंजी समझौता

तत्काल 'बच्चा', नए, छोटे टीटीएल टोकन की रिलीज, ऑडिट, "त्रिशंकु" ग्राहकों की खोज, पुराने 'बच्चे' के लिए इनकार करने के लिए मजबूर किया।

2. मास 'INVALID _ TOKENS'

JWKS कैश, घड़ी मिसलिग्नमेंट, टोकन ओरिजिन (TTL बहुत छोटा) की जाँच करें, अस्थायी रूप से तिरछा सहिष्णुता का विस्तार करें, JWKS को गर्म करें।

3. mTLS-इनकार

सीए श्रृंखला, एसवीआईडी तिथियों, मेजबान समय की जाँच करें; SPIRE/Istio के माध्यम से आपातकालीन-पुनर्जागरण, केवल क्षेत्र के भीतर फॉलबैक मार्गों को सक्षम करता है।

4. 'AUD _ MISMATCH' growth

दर्शक नीति बहाव: वास्तविक कॉल के साथ एसटीएस-नीति की तुलना करें, अस्थायी रूप से वांछित 'aud', शेड्यूल कॉल आर्किटेक्चर समायोजन जोड़ें।

5. एसटीएस अनुपलब्ध/धीमा

पहले से जारी टोकन (अनुग्रह) का टीटीएल बढ़ाएँ, प्रीफेच/रिफ्रेश-पूर्व, स्केल-आउट एसटीएस सक्षम करें।

16) विशिष्ट त्रुटियाँ

एनवी/कोड में लंबे समय तक जीवित एपीआई कुंजी/रहस्य।

जनरल JWKS/PKI "सभी क्षेत्रों के लिए और सभी समय के लिए"।

बाध्यकारी (mTLS/DPoP) की कमी - टोकन को दूर करना आसान है।

ब्रॉड '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 min), स्थानीय सत्यापन, JWKS कैश।
• mTLS (या DPoP) सक्षम; प्राथमिकता - एमटीएलएस-बाउंड टोकन।
• SPIFFE/SPIRE या ऑटो-जारी करने/प्रमाणपत्र के रोटेशन के बराबर।
• दर्शकों/गुंजाइश नीतियों के साथ एसटीएस; केवल विश्वसनीय पहचान द्वारा जारी करना।
• क्षेत्र द्वारा ट्रस्ट-डोमेन और जेडब्ल्यूकेएस का पृथक्करण; किरायेदार/क्षेत्र/लाइसेंस टिकटों की जांच की जाती है।
• पीडीपी/पीईपी एकीकृत, घटना द्वारा समाधान कैश + विकलांगता।
• दोहरी कुंजी खिड़कियां, खपत 'बच्चा' की निगरानी, अमान्य/aud बेमेल करने के लिए अलर्ट।
• पूर्ण लॉग/ऑडिट S2S, निष्पादन/त्रुटि मेट्रिक सक्षम।
• प्रमुख समझौता प्लेबुक, एसटीएस ड्रॉप, एमटीएलएस विफलता।
• contract/negative/chaos/load/E2E परीक्षण सूट पास हुआ।

निष्कर्ष

S2S प्रमाणीकरण चैनल-ट्रस्ट (mTLS), संदेश-विश्वास (लघु JWT), और लगातार कार्यकर्ता पहचान (SPIFFE) का एक संयोजन है, जो एक केंद्रीकृत एसटीएस द्वारा प्रबंधित और स्रमाणित है। ट्रस्ट डोमेन पृथक्करण, कठोर दर्शक/स्कोप, स्वचालित रोटेशन और अवलोकन जोड़ें - और आपके पास एक रूपरेखा है जो मंच और इसके भूगोल के साथ विश्वसनीय, व्याख्यात्मक और स्केलेबल है।