S2S-authentication

احراز هویت S2S ثابت می کند که کدام سرویس/گردش کار درخواست را انجام می دهد و حداقل حقوق لازم را برای مدت زمان محدود می دهد. بر خلاف جریان کاربر، هیچ شخصی در اینجا وجود ندارد - بنابراین، طول عمر کوتاه اعتبار، اتصال رمزنگاری به تمرین/کانال و مشاهده پذیری واضح بسیار مهم است.

1) اهداف و اصول

Zero Trust به طور پیش فرض: به شبکه اعتماد نکنید، فقط گواهینامه تمرین و رمزنگاری را تأیید کنید.
اعتبار کوتاه مدت: دقیقه، نه روز/ماه.
زمینه اتصال: مستاجر/منطقه/مجوز/مخاطب/حوزه.
صدور متمرکز، تأیید غیر متمرکز: STS/IdP + تأیید محلی.
امتیازات حداقل و نمایندگی صریح: فقط حوزه ها و ممیزی های لازم.
چرخش «بدون درد»: پنجره های دو کلید/دوگانه cert و اتوماسیون.

2) مدل تهدید (حداقل)

سرقت اسرار طولانی مدت (API-keys، RT طولانی مدت).
جعل سرویس در VPC/خوشه.
حملات بین منطقه ای در تقسیم بندی شکسته.
جایگزینی ترافیک پخش/پروکسی.
جایگزینی تصویر زنجیره تامین/ظرف.
خطاهای پیکربندی (قوانین فایروال/مش گسترده، JWKS مشترک برای همه).

3) الگوهای اساسی S2S

3. 1 mTLS (گواهینامه های متقابل)

شما کی هستید: اثبات شده توسط کانال.
گواهینامه های کوتاه مدت (ساعت در روز) از PKI داخلی ؛ انتشار/چرخش توسط عامل مش/جانبی یا SPIRE مدیریت می شود.
خوب برای «همسایگان» در همان دامنه اعتماد و برای نشانه های اتصال.

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 چرخش، ادغام با Istio/Linkerd.

3. 4 OAuth 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 کش.
SPIRE/مش: گواهینامه های خودکار و 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، «بچه» نشان دهنده کلید فعال است.
اتصال اختیاری به کانال: پرچم، هش cert، SVID.

6) سیاست های صدور (STS) و تایید

• موضوع از SVID/گواهی مشتری/ثبت نام مشتری گرفته شده است.
• طول عمر 2-5 دقیقه، تازه کردن هیچ - درخواست STS دوباره به جای.
• محدوده/مخاطبان از فروشگاه سیاست (GitOps) گرفته شده است، نه از درخواست مشتری.

1. mTLS (اختیاری) و اعتبار زنجیره ای را بررسی کنید.

2. امضای JWT توسط JWKS (توسط «بچه») را بررسی کنید.

3. «exp/nbf/iss/aud»، مستاجر/منطقه/مجوز را بررسی کنید.

4. متن را غنی کنید و از PDP (RBAC/ABAC/ReBAC) بپرسید.

5. راه حل کش PDP (TTL 30-120 s)، ناتوانی رویداد.

7) چند مستاجر و مناطق (دامنه اعتماد)

اعتماد دامنه های جداگانه: 'spiffe ://eu. هسته '،' spiffe ://latam. هسته ای است.
جدا کردن JWKS/PKI بر اساس منطقه ؛ interregion - فقط از طریق دروازه های مورد اعتماد.
شامل «مستاجر/منطقه/مجوز» در تمبر و بررسی برای انطباق منابع.
بخش سیاهههای مربوط/ممیزی توسط مستاجران و مناطق.

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 محدود)

mTLS-bound tokens: اضافه کردن هش گواهی مشتری به 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'

پاسخ شامل ماشین قابل خواندن «خطا _ کد» و «به عنوان _ از» (کلید/نسخه سیاست).

12) قابلیت مشاهده و حسابرسی

• 's2s _ auth _ p95 _ ms'، 'verify _ jwt _ p95 _ ms'، 'jwks _ skew _ ms'،
• 'invalid _ token _ rate', 'aud _ mismatch _ rate', 'ناکافی _ scope _ rate',
• مصرف توسط «بچه»، نسبت درخواست های متصل به mTLS.

• «subject»، «aud»، «مستاجر»، «منطقه»، «scp»، «بچه»، «sid/svid»، «تصمیم»، «policy _ version»، «trace _ id».

• صدور توکن، چرخش کلید، تغییرات سیاست، درخواستهای رد شده.

13) عملکرد

تأیید JWT - به صورت محلی، حافظه پنهان JWKS (TTL 30-60 s) با به روز رسانی پس زمینه.
زنجیره های X.509 - CA پینینگ و OCSP/CRL کش.
I/O گرانقیمت را به gateway/sidecar بیاورید.
از توکن ها/گواهی های پیش فرض (10-20 ثانیه قبل از انقضا) استفاده کنید.

14) تست

قرارداد/interop: NP/کتابخانه های مختلف، ساعت ± 300 ثانیه تغییر می کند.
منفی: علامت منقضی شده/جعلی، نادرست 'AUD'، منطقه اشتباه/مستاجر، شکسته CERT زنجیره ای.
هرج و مرج: چرخش ناگهانی 'بچه'، در دسترس نبودن JWKS، انقضا جمعی، mTLS شکستگی.
بار: مسئله اوج در STS، تأیید سنبله در دروازه.
E2E: فقط mTLS، فقط JWT، حالت ترکیبی، تبادل توکن (OBO).

15) کتاب های بازی (کتاب های اجرا)

1. سازش کلید امضا

لغو فوری «بچه»، انتشار جدید، کوتاه نشانه TTL، ممیزی، جستجو برای «آویزان» مشتریان، مجبور انکار برای قدیمی «بچه».

2. توکنهای «نامعتبر» انبوه

بررسی کش JWKS، ناهماهنگی ساعت، ریشه نشانه (TTL بیش از حد کوتاه)، به طور موقت گسترش تحمل انحراف، گرم کردن JWKS.

3. mTLS-امتناع

بررسی زنجیره CA، تاریخ SVID، زمان میزبان ؛ اورژانس مجدد از طریق SPIRE/Istio، مسیرهای جایگزین را فقط در منطقه فعال کنید.

4. 'AUD _ رشد نامتناسب

رانش سیاست مخاطبان: مقایسه STS-سیاست با تماس های واقعی، به طور موقت اضافه کردن مورد نظر 'aud'، برنامه تماس تنظیمات معماری.

5. STS در دسترس نیست/آهسته

افزایش TTL از نشانه در حال حاضر صادر (فضل), فعال prefetch/تازه کردن-زودتر, مقیاس کردن STS.

16) خطاهای معمول

کلید API طولانی مدت/اسرار در ENV/کد.
عمومی JWKS/PKI «برای همه مناطق و برای همه زمان ها».
عدم اتصال (mTLS/DPoP) → توکن آسان است.
دامنه Broad 'aud =' و «admin» به طور پیش فرض.
چرخش بدون دوره کلید دوگانه → جرم 401.
چک کردن نشانه ها فقط در دروازه (بدون دفاع در عمق).
شکست «گنگ» (بدون «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.
• SPIFFE/SPIRE یا معادل آن برای صدور خودکار/چرخش گواهینامه.
• STS با سیاست های مخاطبان/دامنه ؛ صدور فقط با هویت قابل اعتماد.
• جدایی اعتماد دامنه و JWKS توسط منطقه ؛ مستاجر/منطقه/مجوز تمبر بررسی می شود.
• PDP/PEP یکپارچه، حافظه پنهان راه حل + ناتوانی توسط رویداد.
• پنجره های دو کلید، نظارت بر مصرف «بچه»، هشدار به عدم تطابق نامعتبر/aud.
• گزارش های کامل/ S2S حسابرسی، معیارهای عملکرد/خطا فعال شده است.
• playbooks سازش کلیدی، قطره STS، شکست mTLS.
• مجموعه آزمون contract/negative/chaos/load/E2E گذشت.

نتیجه گیری

احراز هویت S2S ترکیبی از اعتماد کانال (mTLS)، اعتماد پیام (JWT کوتاه) و هویت کارگر مداوم (SPIFFE) است که توسط یک STS متمرکز مدیریت می شود و به صورت محلی تأیید می شود. جداسازی دامنه اعتماد، مخاطبان/حوزه های دقیق، چرخش خودکار و قابلیت مشاهده را اضافه کنید - و شما یک طرح کلی دارید که قابل اعتماد، قابل توضیح و مقیاس پذیر همراه با پلت فرم و جغرافیای آن است.