S2S ავთენტიფიკაცია

S2S ავთენტიფიკაცია ამტკიცებს, თუ რომელი სერვისი/worcload აკეთებს თხოვნას და აძლევს მას მინიმუმამდე საჭირო უფლებებს შეზღუდულ დროში. მომხმარებლის ნაკადებისგან განსხვავებით, აქ ადამიანი არ არის - შესაბამისად, რწმუნებათა სიგელები, კრიპტოგრაფიული მითითება workload/არხზე და მკაფიო დაკვირვება კრიტიკულია.

1) მიზნები და პრინციპები

Zero Trust სტანდარტულად: არ ენდოთ ქსელებს, მხოლოდ workload და კრიპტოგრაფიის სერტიფიკაციას.
მოკლემეტრაჟიანი კრედიტები: წუთი, და არა დღეები/თვეები.
კონტექსტთან დაკავშირება: tenant/region/licence/audience/scopes.
ცენტრალიზებული გაცემა, დეცენტრალიზებული შემოწმება: STS/IdP + ადგილობრივი გადამოწმება.
მინიმალური პრივილეგიები და აშკარა დელეგაცია: მხოლოდ საჭირო ნაკრები და აუდიტი.
როტაცია „ტკივილის გარეშე“: ორმაგი-კეი/ორმაგი წრე ფანჯარა და ავტომატიზაცია.

2) საფრთხის მოდელი (მინიმალური)

გამძლე საიდუმლოებების ქურდობა (API-keys, გრძელი-lived RT).
სერვისის შეცვლა VPC/კლასტერში.
ინტერრეგიონალური შეტევები გატეხილი სეგმენტით.
Replay/ტრაფიკის შემცვლელი მარიონეტული.
Supply-chain/კონტეინერის გამოსახულების შემცვლელი.
კონფიგურაციის შეცდომები (ფართო firewall/mesh წესები, საერთო JWKS ყველასთვის).

3) S2S ბაზის ნიმუშები

3. 1 mTLS (ურთიერთდახმარების სერთიფიკატები)

ვინ ხართ: ამტკიცებს არხს.
სერთიფიკატები მოკლე (საათნახევარი) შიდა PKI- დან; გამოშვებას/როტაციას მართავს mesh/sidecar ან SPIRE აგენტი.
ეს კარგია „მეზობლებისთვის“ ერთ სამგზავრო დომენში და ნიშნის შესაქმნელად.

3. 2 მომსახურება JWT (STS)

ვინ ხართ: ამტკიცებს შეტყობინებას.
მოკლე Access JWT (2-5 წთ) ერთად 'aud', 'scp', 'tenant', 'region'.
იგი ხელს აწერს KMS/HSM- ს, საზოგადოებრივ გასაღებებს JWKS- ს მეშვეობით 'kid' და როტაციით.
შემოწმება ადგილობრივად (IDP ქსელის ზარის გარეშე).

3. 3 SPIFFE/SPIRE (SVID)

worcloads- ის უნივერსალური თვითმყოფადობა: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
ავტომატური issuance/rotation X.509/JWT-SVID, ინტეგრაცია Istio/Linkerd- თან.

3. 4 OAuth 2. 1 Client Credentials / Token Exchange (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.
Gateway (PEP): ქსელის ტერმინი, რომელიც ხელმძღვანელობს mTLS/JWT, ამდიდრებს კონტექსტს, ითხოვს PDP- ს.
სერვისები (PEP): ხელახალი შემოწმება, PDP გადაწყვეტილებების ქეში.
SPIRE/mesh: ავტომობილების სერთიფიკატები და 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, 'kid' მიუთითებს აქტიურ კლავიშზე.
სურვილისამებრ არხის წინააღმდეგ: დროშა, hash cert, SVID.

6) გაცემის პოლიტიკა (STS) და გადამოწმება

• Subject აღებულია კლიენტის სერტიფიკატის/რეესტრიდან SVID.
• სიცოცხლის ხანგრძლივობა 2-5 წუთია, რეფრესი არ არის - ამის ნაცვლად, STS- ს კვლავ ითხოვთ.
• შეკრება/აუდიტორია აღებულია Policy Store- დან (GitOps) და არა კლიენტის მოთხოვნით.

1. შეამოწმეთ mTLS (სურვილისამებრ) და ჯაჭვის შესაბამისობა.

2. JWT ხელმოწერის შემოწმება JWKS- ზე ('kid').

3. შეამოწმეთ 'exp/nbf/iss/aud', tenant/region/licence.

4. გაამდიდრეთ კონტექსტი და იკითხეთ PDP (RBAC/ABAC/ReBAC).

5. PDP (TTL 30-120 გ) გადაწყვეტილების მიღება, მოვლენების ინვალიდობა.

7) მულტფილმები და რეგიონები (trust domains)

გაზიარეთ trust-domain's: 'spiffe ://eu. core`, `spiffe://latam. core`.
ცალკეული JWKS/PKI რეგიონებში; მეჟრეგიონი - მხოლოდ სანდო კარიბჭეების საშუალებით.
ჩართეთ 'tenant/region/licence' სტიგმებში და შეამოწმეთ რესურსის შესაბამისობა.
ლოგიკური/აუდიტი სეგმენტირებულია ტენანტებსა და რეგიონებში.

8) Mesh/sidecar და mesh რეჟიმში

Istio/Linkerd: mTLS „ყუთიდან“, პოლიცია-განვითარება L4/L7 დონეზე, ინტეგრაცია SPIRE- სთან.
მესის გარეშე: კლიენტის ბიბლიოთეკა + მუტალური TLS პროგრამაში; უფრო რთულია როტაციის კონტროლი - ავტომატიზაცია აგენტის საშუალებით.

9) გასაღებები, JWKS და როტაცია

პირადი გასაღებები მხოლოდ KMS/HSM- ში; ხელმოწერა - დისტანციური ზარი/მოწყობილობა.
Rotation ყოველ N დღეში; ორმაგი კეი: ძველი + ახალი მიიღება, issuer ხელს აწერს ახალს ქეშების დათბობის შემდეგ.
მონიტორინგი: „kid“ - ის მოხმარების წილი, მომხმარებლების „დაკიდება“ ძველი გზით.

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-bound)

mTLS-bound tokens: JWT- ში დაამატეთ hash კლიენტის სერტიფიკატი; მიმღების შემოწმება.
DPoP: HTTP კლიენტებისთვის mTLS- ის გარეშე - ხელი მოაწერეთ თითოეულ თხოვნას DpoP გასაღებით, განათავსეთ thumpprint DPoP AT- ში.

11) შეცდომები და დაბრუნების პოლიტიკა

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

პასუხი შეიცავს მანქანათმშენებლობის 'error _ code' და 'as _ of' (გასაღების/პოლიტიკის ვერსია).

12) დაკვირვება და აუდიტი

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• „kid“ - ის მოხმარება, mTLS-bound მოთხოვნის წილი.

• `subject`, `aud`, `tenant`, `region`, `scp`, `kid`, `sid/svid`, `decision`, `policy_version`, `trace_id`.

• ნიშნების გაცემა, გასაღებების როტაცია, პოლიტიკოსის ცვლილებები, უარყოფილი მოთხოვნები.

13) პროდუქტიულობა

JWT გადამოწმება ადგილობრივად, JWKS ქეშირაიტი (TTL 30-60 ს) ფონის განახლებით.
X.509 ჯაჭვები - pinining CA და OCSP/CRL ქეში.
გამოიტანეთ ძვირადღირებული კრედიტი I/O gateway/sidecar.
გამოიყენეთ prefetch ნიშნები/სერთიფიკატები (გასვლამდე 10-20 საათით ადრე).

14) ტესტირება

Contract/interop: სხვადასხვა YP/ბიბლიოთეკები, clock skew ± 300.
Negative: ვადაგადაცილებული/ყალბი ნიშანი, არასწორი 'aud', არასწორი რეგიონი/ტენანტი, გატეხილი cert-chain.
ქაოსი: მოულოდნელი „kid“ როტაცია, JWKS- ის მიუწვდომლობა, მასობრივი ექსპორტი, mTLS- ის დაშლა.
Load: STS გაცემის პიკი, verify gateway.
E2E: mTLS-only, JWT-only, კომბინირებული რეჟიმი, ტოკენის ბირჟა (OBO).

15) Playbooks (runbooks)

1. ხელმოწერის გასაღების კომპრომისი

დაუყოვნებლივი revoke 'kid', ახალი, შემცირებული TTL ნიშნების გამოშვება, აუდიტი, „ჩამოკიდებული“ მომხმარებლების ძებნა, ძველი 'kid' იძულებითი დენა.

2. მასობრივი 'INVALID _ TOKEN'

შეამოწმეთ JWKS ქეში, საათის რასსინქრონი, ტოქსინების წარმოშობა (TTL ძალიან მოკლე), დროებით გააფართოვეთ skew დაშვება და გაათბეთ JWKS.

3. mTLS წარუმატებლობები

CA ჯაჭვის შემოწმება, SVID თარიღები, მასპინძელი დრო; განვითარებადი ხელახლა გამოცემა SPIRE/Istio- ს საშუალებით, ჩართეთ fallback მარშრუტები მხოლოდ რეგიონში.

4. ზრდა 'AUD _ MISMATCH'

დრიფტის პოლიტიკოსი: შეადარეთ STS პოლიტიკა რეალურ გამოწვევებთან, დროებით დაამატეთ საჭირო 'aud', დაგეგმეთ ზარის არქიტექტურის კორექტირება.

5. STS მიუწვდომელი/შენელებულია

გაზარდეთ TTL უკვე გაცემული ნიშნები (grace), ჩართეთ prefetch/refresh ადრე, scale-out STS.

16) ტიპიური შეცდომები

გრძელი API გასაღებები/საიდუმლოებები env/კოდში.
საერთო JWKS/PKI „ყველა რეგიონისთვის და ყველა დროისთვის“.
binding (mTLS/DPOP) ნაკლებობა მარტივია.
ფართო 'aud =' და „Admin“ scopes ნაგულისხმევი.
როტაცია ორმაგი კეის პერიოდის გარეშე - მასობრივი 401.
ტოქსინების შემოწმება მხოლოდ gateway- ზე (არ არის დამცავი დეპრესიაში).
„მუნჯი“ უარი (არა 'error _ code' და 'reason') ძნელია გუნდების გაშვება და მომზადება.

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-bound tokens.
• SPIFFE/SPIRE ან ექვივალენტი მანქანის გაცემის/სერთიფიკატების ბრუნვისთვის.
• STS პოლიტიკოსებთან audience/scope; გაცემა მხოლოდ სანდო იდენტურობით.
• trust-domains და JWKS დაყოფა რეგიონებში; შემოწმებულია tenant/region/licence ბრენდები.
• PDP/PEP ინტეგრირებულია, გადაწყვეტილებების ქეში + შეზღუდული შესაძლებლობის მქონე მოვლენებზე.
• Dual-key ფანჯრები, 'kid' მოხმარების მონიტორინგი, ალერტები invalid/aud mismatch.
• სრული logs/S2S აუდიტი, შედის შესრულების/შეცდომების მეტრიკა.
• Playbooks საკვანძო კომპრომისზე, STS ვარდნა, mTLS გაუმართაობა.
• დასრულდა კონტრაქტის/ნეგატიური/ქაოსის/ლოადის/E2E ტესტების ერთობლიობა.

დასკვნა

S2S ავთენტიფიკაცია არის ნდობის არხის (mTLS) ერთობლიობა, ნდობის შეტყობინება (მოკლე JWT) და workload (SPIFFE) სტაბილური იდენტურობა, რომელსაც მართავს ცენტრალიზებული STS და ადგილობრივად დამოწმებულია. დაამატეთ trust დომენების გამიჯვნა, მკაცრი audience/scopes, ავტომატური როტაცია და დაკვირვება - და მიიღეთ წრე, რომელიც საიმედოა, ახსნა და მასშტაბური პლატფორმასთან და მის გეოგრაფიასთან ერთად.