S2S аутентификациясы

S2S-аутентификация сұрау салуды қандай сервис/ворклоад жасайтынын дәлелдейді және оған шектеулі уақытқа ең аз қажетті құқықтарды береді. Пайдаланушы ағындарынан айырмашылығы, мұнда адам жоқ - сондықтан есептік деректердің қысқа өмір сүру мерзімі, ворклоад/арнаға криптографиялық байланысу және айқын байқау өте қиын.

1) Мақсаттар мен қағидаттар

Zero Trust әдепкі: желіге сенбеу, тек workload және криптографияны аттестаттау.
Қысқа өміршеңдік: күндер/айлар емес, минуттар.
tenant/region/licence/audience/scopes.
Орталықтандырылған беру, орталықтандырылмаған тексеру: STS/IdP + жергілікті верификация.
Ең аз артықшылықтар және айқын табыстау: тек қажетті сатып алулар мен аудит.
Ауыртпалықсыз ротация: dual-key/dual-cert терезелер және автоматтандыру.

2) Қатерлер моделі (минимум)

Ұзақ мерзімді құпияларды ұрлау (API-keys, long-lived RT).
VPC/кластер ішіндегі сервисті ауыстыру.
Сегменттеу бұзылған кездегі өңіраралық шабуылдар.
Проксидегі трафикті replay/ауыстыру.
Supply-chain/контейнер бейнесін ауыстыру.
Конфигурация қателері (кең firewall/mesh ережелері, барлығына ортақ JWKS).

3) Базалық паттерндер S2S

3. 1 mTLS (өзара сертификаттар)

Сіз кімсіз: арнамен дәлелдейді.
Ішкі PKI-дан қысқа мерзімдік (сағат-тәулік) сертификаттар; шығаруды/ротацияны mesh/sidecar немесе SPIRE-агент басқарады.
Бір trust-домендегі «көршілер» үшін және binding токендері үшін жақсы.

3. 2 Сервистік JWT (STS)

Сіз кімсіз: хабармен дәлелдейді.
Қысқа Access JWT (2-5 мин) с 'aud', 'scp', 'tenant', 'region'.
KMS/HSM, жария кілттерге қол қояды - JWKS арқылы 'kid' және ротациямен.
Жергілікті түрде тексеру (IdP желілік шақыруынсыз).

3. 3 SPIFFE/SPIRE (SVID)

Ворклоадтардың әмбебап сәйкестігі: '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 (token exchange).

Біріктіреміз: 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 сұратады.
Services (PEP): қайта тексеру (defense in depth), 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 қол қойды, 'kid' белсенді кілтті көрсетеді.
Арнаға қосымша binding: жалауша, hash cert, SVID.

6) Беру саясаты (STS) және верификация

• Subject SVID/клиент сертификатынан/клиент тіркелімінен алынады.
• Өмір сүру мерзімі 2-5 минут, refresh жоқ - оның орнына қайтадан STS сұраңыз.
• Сатып алулар/аудиториялар клиенттің сұрауынан емес, Policy Store-дан (GitOps) алынады.

1. mTLS (қосымша) және шынжырдың дұрыстығын тексеру.

2. JWKS бойынша JWT қолтаңбасын тексеру ('kid' бойынша).

3. 'exp/nbf/iss/aud', tenant/region/licence.

4. Контекстті байытыңыз және PDP (RBAC/ABAC/ReBAC) сұраңыз.

5. PDP (TTL 30-120 c) шешімін кэштеу, оқиғалар бойынша мүгедектік.

7) Мульти-тенант және өңірлер (trust domains)

trust-domain ':' spiffe ://eu. core`, `spiffe://latam. core`.
Өңірлер бойынша бөлек JWKS/PKI; өңіраралық - тек сенімді шлюздер арқылы.
'tenant/region/licence' таңбаларына қосыңыз және ресурсқа сәйкестігін тексеріңіз.
Логи/аудитті тенанттар мен өңірлер бойынша саралаңыз.

8) Mesh/sidecar және mesh режимі жоқ

Istio/Linkerd: mTLS «қораптан», L4/L7 деңгейінде policy-enforcement, SPIRE-мен интеграция.
mesh жоқ: кітапхана-клиент + қолданбада mutual TLS; ротацияны басқару қиынырақ - агент арқылы автоматтандырыңыз.

9) Кілттер, JWKS және ротация

Жеке кілттер тек KMS/HSM; қолы - қашықтағы шақырумен/аппаратпен.
Әрбір N күнде Rotation; dual-key: ескі + жаңа қабылданады, 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: mTLS жоқ HTTP-клиенттер үшін - әрбір DPoP сұрауына DP-кілтімен қол қою, AT-ға thumbprint DPoP орналастыру.

11) Қателер және қайтару саясаты

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

Жауабында machine-readable '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 тізбектері - CA пиннингі және OCSP/CRL кэші.
gateway/sidecar бағдарламасына қымбат I/O валидациясын шығарыңыз.
Prefetch токендерін/сертификаттарын қолданыңыз (10-20 секунд бұрын).

14) Тестілеу

Contract/interop: әртүрлі ЯП/кітапханалар, clock skew ± 300 с.
Negative: мерзімі өткен/жалған токен, дұрыс емес 'aud', басқа өңір/тенант, сынған cert-chain.
Chaos: кенеттен 'kid' ротациясы, JWKS қол жетімсіздігі, жаппай экспирация, mTLS үзілісі.
Load: STS-те беру шыңы, gateway-де verify жүгірісі.
E2E: mTLS-only, JWT-only, аралас режим, Token Exchange (OBO).

15) Плейбуктар (runbooks)

1. Қолтаңба кілті

Дереу revoke 'kid', жаңа, қысқартылған TTL белгілерін шығару, аудит, «ілініп қалған» клиенттерді іздеу, ескі 'kid' үшін мәжбүрлі deny.

2. Жаппай 'INVALID _ TOKEN'

JWKS кэшін, сағаттардың рассинхронын, токендердің бастауын (TTL тым қысқа) тексеру, уақытша skew рұқсатын кеңейту, JWKS-ті жылыту.

3. mTLS істен шығуы

CA тізбегін, SVID мерзімін, хост уақытын тексеру; emergency-SPIRE/Istio арқылы қайта шығару, fallback-маршруттарды тек өңір ішінде қосу.

4. 'AUD _ MISMATCH' өсуі

Дрейф саясаты audience: STS-policy-ді нақты шақырулармен салыстыру, уақытша 'aud' қосу, шақырулар архитектурасын түзетуді жоспарлау.

5. STS қол жетімді емес/баяу

Берілген (grace) токендердің TTL үлкейту, prefetch/refresh-ертерек, scale-out STS қосу.

16) Типтік қателер

env/кодтағы ұзақ өмір сүретін API кілттері/құпиялары.
Жалпы JWKS/PKI «барлық өңірлерге және барлық уақытқа».
Жоқ binding (mTLS/DPoP) → токенді оңай алып кетеді.
Әдепкі кең 'aud =' және "әкімшілік 'scopes.
Dual-key кезеңінсіз ротация → жаппай 401.
Тек gateway бағдарламасында тексеру (defense in depth жоқ).
«Мылқау» бас тарту (жоқ '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.
• Толық логи/аудит S2S, өнімділік/қателер өлшемдері қосылған.
• Кілттің жамандығына арналған плейбуктер, STS құлауы, mTLS істен шығуы.
• contract/negative/chaos/load/E2E тестілеу өтті.

Қорытынды

S2S-аутентификация - бұл орталықтандырылған STS басқаратын және жергілікті түрде тексерілетін сенім арнасының (mTLS), сенім хабарының (қысқа JWT) және ворклоадтың тұрақты сәйкестігінің (SPIFFE) комбинациясы. trust-домендерді бөлу, қатаң audience/scopes, автоматты ротация және бақылау қосыңыз - және платформамен және оның географиясымен бірге сенімді, түсінікті және масштабталған контурды алыңыз.