GH GambleHub

ניהול מפתחות וסבב

מפתחות הם ”שורשי אמון” של הפלטפורמה. מערכת ניהול מפתחות אמינה (KMS/HSM + processions + telemetry) הופכת את הקריפטוגרפיה מאינטגרציה חד פעמית לפעולה יומיומית: המפתחות מתעדכנים באופן קבוע, השימוש בהם שקוף, הפשרות מקומיות, והלקוחות חווים שינוי מפתח ללא השבתה.

1) מטרות ועקרונות

זריזות קריפטו: היכולת לשנות את אורך האלגוריתם/מפתח ללא נדידה גדולה.
חשיפה לפחות: מפתחות פרטיים אינם משאירים KMS/HSM; פעולות חתימה/פענוח נמחקו.
חפצים קצרי חיים, מפתחות טוקנס/סשן חיים דקות-שעות, לא שבועות.
חלונות כפול-מפתח/כפול-Cert: סיבובי אל-כשל.
בידוד דייר אזורי: מפתחות מחולקים על ידי אזור ודייר.
יכולת שמיעה מלאה: רישום עסקאות בלתי ניתנות לשינוי, אימות HSM, בקרת גישה.

2) סיווג מפתח

Root CA/Master Key: שימוש נדיר ביותר, הנשמר ב-HSM, המשמש לשחרור מפתחות ביניים או עטיפות מפתח נתונים.
הפעלה: JWT/חתימת אירוע, TLS, חתימת webhook, הגדרת הצפנה/PII.
Session/time: DPoP, mTLS-binding, ECDH-pult עבור ערוץ/דיאלוג.
אינטגרציה: מפתחות שותף (ציבוריים) וסודות 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 חודשים עבור serts TLS).
מתגלגל: בהדרגה עובר הצרכן (JWKS כבר מכיל מפתח חדש; הפולט מתחיל לחתום חדש לאחר חימום המטמונים).
אילוץ (ביטחון): סיבוב מיידי על פשרה; חלון קבלה כפול קצר, תפוגה אגרסיבית של חפצים.
מטלטל לכל אזור/דייר: כדי לא ”למחוא כפיים” את כל העולם באותו הזמן.

כלל הזהב: ראשית הפרסום, לאחר מכן החתימה חדשה, ורק לאחר התפוגה - החזרת הישן.

6) חלון מפתח כפול

אנחנו מפרסמים את JWKS עם ”הילד” הישן והחדש.
מאשרים מקבלים את שניהם.
פולט בעוד N דקות/שעות מתחיל לחתום חדש.
אנחנו עוקבים אחר נתח הצ 'קים של הילד הישן והחדש.
עם הגעה לחלק המטרה, הרטירים ישנים.

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 שבו נדרש.
איסור על אלגוריתמים חלשים; הלבנה בצד האימות.
שעון סקיו: אנו מאפשרים pen300 c, סטיות יומן.
Pinning (שירותים פנימיים) ומטמון TTL JWKS (30-60 S) קצר.

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/ביקורת על ידי דייר/אזור; מפתחות לא ”זורמים” בין בתי מגורים.
קוד עם קידומת תחום אמון: ”eu-cort-es256-2025-10”.

10) סודות אינטגרציה (HMAC, מפתחות API)

חנות ב-KMS המגובה ב-Secret Store, גיליון באמצעות סודות לקוח קצרי-ימים (מדיניות רוטציה ל-90 יום).
תמיכה בשני סודות פעילים (כפול סודי) במהלך סיבוב.
עבור חוברות אינטרנט - חותמת זמן + חתימת גוף HMAC; חלון זמן צמוד 5 דקות.

11) בקרת גישה ותהליכים

מטריצת IAM: מי יכול ”ליצור”, ”לסמן”, ”לפענח”, ”לסובב”, ”להרוס” (תפקידים מינימליים).
עקרון 4-עין: פעולות רגישות דורשות שני אישורים.
שינוי חלונות: חלונות כדי לאפשר מפתח חדש ולבחון אזורי קנרית.
ריצות: תבניות הליך לסיבוב מתוכנן ואילוץ.

12) יכולת תצפית וביקורת

מדדים:
  • 'sign _ p95 _ ms',' לפענח _ p95 _ ms', 'jwks _ skew _ ms',
  • צריכה על ידי ”ילד”, ”old _ kid _ usage _ ratio”,
  • 'invalid _ חתימה _ rate', 'פענוח _ כישלון _ rate'.
יומנים/ביקורת:
  • כל פעולת חתימה/פענוח היא ”מי/מה/מתי/איפה/ילד/מטרה”.
  • היסטוריה של סטטוס מפתח ובקשות סיבוב/שלילה.
  • אימות HSM, רישומי גישה לחומרי מפתח.

13) ספרי משחק (תקריות)

1. פשרת מפתח חתימה

ביטול מיידי של ה ”ילד הזקן” (או תרגום ל ”פורש” עם חלון מינימלי), פרסום של JWKS חדש, אסימוני TTL מקוצרים, נכות Logout/RT, תקשורת לבעלי אינטגרציה, ביקורת רטרו.

2. מסה 'INVALID _ חתימה' לאחר סיבוב

בדוק מטמון סקיו JWKS/שעון, להחזיר דו-קבלה, להאריך חלון, לחלק ללקוחות.

3. עלייה בKMS/HSM Latency

אסור לאפשר את מטמון החתימה המקומי; במקום - אצווה/תור ב פולט, אוטוסקלינג פרוקסי HSM, עדיפות של זרמים קריטיים.

4. כישלון של אזור אחד

הפעל הליכי בידוד אזוריים; לא ”למשוך” מפתחות מאזורים אחרים; פונקציות משפלות הקשורות לחתימות באזור שנפל.

14) בדיקה

חוזה: תקינות JWKS, תקן ”ילד ”/alg/שימוש, תאימות לקוח.
שלילי: חתימה מזויפת, ”ילד” מיושן, אלג שגוי, שעון רזה.
תוהו ובוהו: סיבוב מיידי, אי-זמינות של KMS, סחף זמן.
עומס: חתימות שיא (JWT/webhooks), פענוח שיא (PII/payouts).
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 וסמנים בחפצים

רסיס הכותרת של JWT:
json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }
JWKS (חלק ציבורי):
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.
מדריך ”סודות” ב ”אינב” במקום ”סיקרט סטור”.

18) רשימת בדיקות לפני המכירה

[ ] כל המפתחות הפרטיים ב ־ KMS/HSM; מטריצת IAM ועקרון 4 העין מכוונים.
[ מדיניות האלגוריתם ], אורכי מפתח, ותקופות חיים מאושרים.
[ ] איפשר תהליך דו-מפתח עם ניטור שיתוף 'ילד'.
[ ] JWKS יוצא לאור עם TTL קצר והתחממות מטמון; לקוחות מקבלים מפתח 2.
[ הצפנת מעטפת ]: KEK מסתובב, DEK מחדש לעטוף ללא הפסקה.
[ ] בידוד אזורי ומערכות מפתח נפרדות על ידי דיירים.
[ ] פשרה/גלגול/סיבוב כוח חוברות משחק; ריצות אימונים.
[ ] Metrics ('old _ kid _ usage _ ratio', 'inflid _ signate _ rate') והתראות הופעלו.
[ ] contract/negative/chaos/load/E2E הסוויטה עברה.
[ תיעוד ] לאינטגרציות: כיצד להתמודד עם שינוי ה ”קיד”, אשר חלונות וקודי שגיאה.

סיכום

ניהול מפתח הוא משמעת מבצעית: KMS/HSM כמקור לאמת, סיבוב רגיל ומאובטח עם בידוד כפול, אזורי ודייר, הצפנת מעטפות ויכולת תצפית. על ידי ציות לחוקים אלה, אתה מקבל קריפטו המתווה את המאזניים, עמיד בפני תקריות וקל להסביר למבקר - ומפתחים ואינטגרטורים חווים כל שינוי ללא כאב.

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

בלחיצה על הכפתור אתם מסכימים לעיבוד הנתונים שלכם.