مدیریت کلید و چرخش

کلید ها «ریشه های اعتماد» پلت فرم هستند. یک سیستم مدیریت کلید قابل اعتماد (KMS/HSM + processes + telemetry) رمزنگاری را از یک ادغام یک بار به یک عملیات روزمره تبدیل می کند: کلید ها به طور مرتب به روز می شوند، استفاده از آنها شفاف است، سازش ها محلی می شوند و مشتریان بدون تغییر خرابی یک تغییر کلیدی را تجربه می کنند.

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

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

2) طبقه بندی کلیدی

Root CA/Master Key: استفاده بسیار نادر، که در HSM نگهداری می شود، برای انتشار کلید های متوسط یا بسته بندی های کلید داده استفاده می شود.
عامل: امضای JWT/رویداد، TLS، امضای webhook، رمزگذاری پیکربندی/PII.
جلسه/زمان: DPoP، mTLS-binding، ECDH-output برای کانال/گفتگو.
ادغام: کلید های شریک (عمومی) و اسرار HMAC.
کلید های داده (DEK): استفاده از رمزگذاری پاکت تحت KEK، به صراحت ذخیره نمی شود.

3) سیاست شناسایی و استفاده کلیدی

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

قوانین: «یک هدف - یک کلید» (حداقل اشتراک گذاری)، زمینه های صریح برنامه و زمان بندی.

4) چرخه عمر کلید (KMS/HSM)

1. تولید: در HSM/KMS، با سیاست صادرات = رد شد.
2. انتشار: برای عدم تقارن - JWKS/گواهی با «بچه».
3. استفاده: عملیات از راه دور (علامت/رمزگشایی) با IAM کنترل شده.
4. چرخش: کلید «next» را اجرا کنید و پذیرش دوگانه را فعال کنید.
5. بازنشسته: ترجمه قدیمی به «بازنشسته»، سپس «لغو».
6. نابود کردن: نابود کردن مواد (با پروتکل پاکسازی) پس از اختلاف پنجره.

5) چرخش: استراتژی

برنامه ریزی شده: تقویم (به عنوان مثال، هر 1-3 ماه برای امضای JWT، 6-12 ماه برای TLS-serts).
نورد: به تدریج تغییر مصرف کنندگان (JWKS در حال حاضر شامل یک کلید جدید ؛ امیتر شروع به ثبت نام جدید پس از گرم کردن مخازن).
اجباری (امنیت): چرخش فوری پس از سازش ؛ پنجره پذیرش دوگانه کوتاه، انقضای تهاجمی مصنوعات.
Stagged در هر منطقه/مستاجر: به طوری که به «کف زدن» تمام جهان در همان زمان.

قانون طلایی: ابتدا انتشار، سپس امضا جدید است، و تنها پس از انقضا - فراخوانی یکی از قدیمی.

6) پنجره کلید دوگانه

ما JWKS را با «بچه» قدیمی و جدید منتشر می کنیم.
کارشناسان هر دو را میپذیرند.
امیتر در N دقیقه/ساعت شروع به امضای جدید می کند.
ما نظارت بر سهم چک در قدیمی/جدید «بچه».
پس از رسیدن به سهم هدف، retyrim قدیمی است.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) سیاست های امضا و اعتبار سنجی

الگوریتم های پیش فرض: ES256/EdDSA امضا ؛ RSA-PSS در صورت لزوم

ممنوعیت الگوریتم های «هیچ »/ضعیف ؛ لیست سفید در سمت تأیید.
انحراف ساعت: ما اجازه می دهد ± 300 C، انحراف ورود به سیستم.
پین کردن کلید (خدمات داخلی) و کش کوتاه TTL JWKS (30-60 ثانیه).

8) رمزگذاری پاکت و KDF

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

KEK (کلید رمزگذاری کلید) در KMS/HSM ذخیره می شود، به طور منظم چرخانده می شود.
DEK در هر شی/دسته ایجاد می شود ؛ هنگام چرخش KEK، ما دوباره بسته بندی (به سرعت، بدون رمزگذاری مجدد داده ها) انجام می دهیم.
برای جریان - ECDH + HKDF به خروجی کوتاه مدت کلید کانال.

9) منطقه ای و چند مستاجر

کلیدها و JWKS منطقه بندی می شوند: «eu-core»، «latam-core» مجموعه های مختلفی از کلیدها هستند.
جداسازی IAM/حسابرسی توسط مستاجر/منطقه ؛ کلیدها بین اقامتگاهها «جریان» ندارند.
'kid' code with trust domain prefix: 'eu-core-es256-2025-10'.

10) اسرار ادغام (HMAC، کلید API)

در فروشگاه Secret Store تحت حمایت KMS ذخیره کنید، از طریق اسرار مشتری کوتاه مدت (سیاست چرخش ≤ 90 روز) صادر کنید.
پشتیبانی از دو راز فعال (دو راز) در طول چرخش.

برای وب سایت ها - برچسب زمان + امضای بدن HMAC ؛ بازه زمانی ≤ 5 دقیقه

11) کنترل دسترسی و فرآیندها

ماتریس IAM: چه کسی می تواند «تولید»، «علامت»، «رمزگشایی»، «چرخش»، «نابود کردن» (حداقل نقش).
4-اصل چشم: عملیات حساس نیاز به دو تایید.
پنجره ها را تغییر دهید: پنجره هایی برای فعال کردن یک کلید جدید و تست مناطق قناری.
Runbooks: قالب های روش برای چرخش برنامه ریزی شده و اجباری.

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

• 'sign _ p95 _ ms', 'decrypt _ p95 _ ms', 'jwks _ skew _ ms',
• مصرف توسط 'بچه'، 'old _ kid _ usage _ ratio'،
• 'invalid _ signature _ rate', 'decrypt _ failure _ rate'.

• هر عملیات امضا/رمزگشایی «چه کسی/چه زمانی/کجا/کودک/هدف» است.
• تاریخچۀ وضعیت کلید و درخواستهای چرخش/ابطال.
• مدارک تحصیلی HSM، مواد کلیدی دسترسی سیاهههای مربوط.

13) کتاب های بازی (حوادث)

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

لغو فوری «بچه» قدیمی (یا ترجمه به «بازنشستگی» با یک پنجره حداقل)، انتشار یک JWKS جدید، نشانه های TTL کوتاه، ناتوانی نیروی خروجی/RT، ارتباطات به صاحبان ادغام، حسابرسی یکپارچهسازی با سیستمعامل.

2. Mass 'INVALID _ SIGNATURE' after rotation بعد از چرخش

بررسی JWKS/ساعت کش انحراف، بازگشت دوگانه قبول، گسترش پنجره، توزیع به مشتریان.

3. افزایش در تأخیر KMS/HSM

فعالسازی نهانگاه امضای محلی مجاز نیست ؛ به جای - دسته/صف در امیتر، خودکار HSM پروکسی، اولویت بندی جریان بحرانی.

4. شکست یک منطقه

فعال کردن روش های جداسازی منطقه ای ؛ کلید ها را از مناطق دیگر «بکشید» ؛ کاهش توابع گره خورده به امضا در یک منطقه کاهش یافته است.

14) تست

قرارداد: صحت JWKS، صحیح «بچه »/alg/use، سازگاری مشتری.
منفی: امضای جعلی، منسوخ «بچه»، ALG نادرست، انحراف ساعت.
هرج و مرج: چرخش فوری، عدم دسترسی KMS، رانش زمان.
بار: حداکثر امضا (JWT/webhooks)، رمزگشایی اوج (PII/پرداخت).
E2E: پنجره دو کلید: انتشار - تأیید - انتقال ترافیک - رد یکی از قدیمی.

15) مثال پیکربندی (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) نمونه ای از JWKS و نشانگر در مصنوعات

json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }

json
{ "keys":[
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-10","x":"...","y":"..."},
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-07","x":"...","y":"..."}
]}

17) ضد الگوهای

کلید های طولانی مدت «برای سال ها» و مشترک برای همه مناطق.
چرخش «در یک لحظه» بدون پذیرش دوگانه.
صادرات کلیدهای خصوصی از KMS/HSM «برای سرعت».
وظایف مخلوط کردن: JWT را امضا کنید و داده ها را با یک کلید رمزگذاری کنید.
عدم وجود HSM سیاهههای مربوط/صلاحیت و محدودیت IAM.
هیچ مکانیزم بسته بندی مجدد برای DEK در چرخش KEK وجود ندارد.
دستی «اسرار» در ENV به جای فروشگاه راز.

18) چک لیست پیش فروش

• تمام کلید های خصوصی در KMS/HSM ؛ ماتریس IAM و اصل 4 چشم تنظیم شده است.
• سیاست های الگوریتم، طول کلید و طول عمر تایید شده است.
• فرآیند دو کلید را با نظارت بر اشتراک گذاری «بچه» فعال کنید.
• JWKS با TTL کوتاه و گرم شدن کش منتشر شده است ؛ مشتریان ≥2 کلیدی را می پذیرند.
• رمزگذاری پاکت: KEK چرخش، DEK دوباره بسته بندی بدون خرابی.
• جداسازی منطقه ای و مجموعه های کلیدی جداگانه توسط مستاجران.
• سازش/نورد/چرخش نیروی playbooks ؛ آموزش اجرا می شود.
• معیارها ('old _ kid _ usage _ ratio'، 'invalid _ signature _ rate') و هشدارها فعال می شوند.
• مجموعه آزمون contract/negative/chaos/load/E2E گذشت.
• مستندات برای ادغام: نحوه رسیدگی به تغییر «kid»، کدام پنجره ها و کدهای خطا.

نتیجه گیری

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