הילוך טורנט

הצפנה והגנת API: TLS, HSTS, PFS, סבב סודי

1) תמונת איום ומטרות

APIs תחת מתקפת MITM, יירוט תנועה, התקפות הורדה, זיוף סמלי, דליפות מפתח, ושימוש לרעה של סודות ארוכי ימים. מטרות הגנה:

סודיות ויושרה (TLS 1. 3 + צפנים חזקים).
הגנה מפני הורדת דירוג/חשפנות (HSTS, גרסאות/צפנים אסורות).
מזעור נזקי פשרה (PFS, TTL קצר, סיבוב מהיר).
אימות לקוח/שירות אמין (mTLS/tokens) ויכולת איתור.

2) TLS כבסיס (שרת ושירות)

גרסאות וצפנים:

ברירת המחדל היא TLS 1. 3; אפשר TLS 1. 2 עבור תאימות בלבד. בטל 1. 1/1. 0.

הצפנת עדיפות TLS 1. 3:

'TLS _ AES _ 128 _ GCM _ SHA256', 'TLS _ AES _ 256 _ GCM _ SH384', 'TLS _ CHACHA20 _ POLY1305 _ SH256'.
עבור TLS 1. 2: רק ECDHE עם AES-GCM/ChaCha20 וחתימת ECDSA/RSA (למשל. 'ECDHE-ECDSA-AES128-GCM-SHA256'.

מפתחות ותעודות:

מפתחות שרת: ECDSA P-256/P-384 (מהיר וקצר יותר) או RSA 2048 +/3072.
מפתחות לקוח עבור mTLS: ECDSA P-256; או תשלום HSM/KMS.
אפשר הידוק OCSP, רצוי עם הדגל Must-Stiple, ו-ALPN (HTTP/2/3).

PFS (סודיות קדמית מושלמת):

מסופק על ידי החלפות ארעיות (ECDHE) - גם אם מקש השרת דלף, לא ניתן לפענח הפעלות קודמות.
כפה הסכם מפתח סטטי של DH/RSA.

תוספות מודרניות:

ECH (לקוח מוצפן שלום), אם נתמך על ידי החזית/CDN, מסתיר את ה ־ SNI.
HTTP/2/3 רק עם צפנים חזקים; איסור על HTTP לא מוגן, להפנות ל-HTTPS.

3) חשפנות HSTS נגד TLS

אפשר אבטחת תחבורה קפדנית של HTTP בתחום השורשים ותת-הדומים:


נוקשה-תחבורה-אבטחה: מקסימום גיל = 63072000;  SubDomains; טעינה מוקדמת

שים את התחום ברשימת העומס מראש של ה-HSTS.

שים לב לתקינות לפני ההוצאה לאור (rollback הוא קשה).

4) אימות הדדי: mTLS ו/או אסימונים

MTLS בין microservices/internal APIs: bi-directional advices, automatic rotation דרך service mesh (Istio/Linkerd) או PKI קנייני.

לקוחות API (שילוב מובייל/שותף): אסימונים (OAuth2/OIDC, JWT), mTLS אופציונלי לסיכון גבוה.

עבור חזיתות ציבוריות: TLS + אסימונים OAuth2/OIDC קצרי ימים עם התקן/DPoP מחייב.

5) תעודה וניהול אופן חיים

אוטומציה של ACME (לדוגמה, בואו להצפין/ארגון CA) עם עדכון אוטומטי 30 יום לפני התפוגה.

חיים קצרים של תעודות (90 ימים) + ניטור של מועדים, התראות וחבילות פריסה כנרית.

PKI מרוכז: root/intermediate CA, CRL/OCSP, ביקורת משחררת ומבטלת.

דוגמה של nginx (מקטע):

nginx ssl_protocols TLSv1. 3 TLSv1. 2;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers על;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_stapling על; ssl_stapling_verify על;
add_header מקסימום-Transport-Security "= 63072000;  SubDomains; pretload" תמיד;

6) סיבוב סודי: עקרונות ודפוסים

מטרות סיבוב: להגביל את ”רדיוס הפיצוץ” של דליפות, להפחית את זמן השימוש לרעה ולהבטיח שחרור חלק.

כללים בסיסיים:

שמירת סודות רק במנהל הסודי (KMS/Vault/Cloud SM). אין סודות בגיט/תמונות.
TTL קצר וסבב אוטומטי: מפתחות חתימה, סיסמאות בסיס נתונים, מפתחות API מספקים.
חלון מפתח כפול: המפתחות הישנים והחדשים פעילים בו זמנית לתקופת הגלגול.
Versioning + kid (עבור JWT/JWKS), חלון גרייס לאסימונים ישנים.

מה לסובב באופן קבוע:

מפתחות JWT (חתימה/הצפנה), סודות HMAC של חוברות אינטרנט וקולקציות, חשבונות Passords/Database, מטמונים (רדיס), אסימונים CI/CD, סודות ספקים (KYC/AML, תשלומים, SMS/דואר אלקטרוני), מפתחות אוטומציה.

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

7) JWT/JWKS: תפקיד בטוח בכיסוי

Publish JWKS endpoint עם מפתח עדכני ועתידי (”ילד” נדרש).

הליך סיבוב:

1. צרו מפתח חדש כפול הוסף אותו למפתח JWKS כמפתח ”שני”.

2. עדכון חתימות # הנפקת אסימונים חדשים עם מפתח חדש.

3. חכו ל TTL של אסימונים ישנים * הסר את המפתח הישן מ-JWKS.

התקנת אסימוני TTL קצרים (לדוגמה, 5-15 דקות) + רענון זרמים עם אימות נוסף.

8) ניהול סודי בפועל

הצפנת מעטפת KMS +: מפתח מאסטר ב ־ HSM/KMS, המידע מוצפן ב ־ ”עטוף” DEK.

Vault/Cloud Secret Manager: קרדיטים דינמיים לבסיס הנתונים (הוצאת רשומות עם TTL), סיבוב מחזורי.

קוברנטס: סודות חיצוניים/סודות חנות CSI; הצפנת etcd; RBAC; איסור על כריתת סודות.

גישת תפקידים: IAM/ABAC, עקרון הרשאות מינימום, גבולות חומרה (HSM, TPM).

ביקורת מלאה: מי, מה, מתי, למה לקרוא/לשנות.

9) הגנת תחבורה בתוך המתחם

אין לסמוך על ”הרשת הפנימית”: בכל מקום TLS/mTLS (אפס אמון).

תעודות אוטומטיות שירות, הפעלה מחדש וסבב, יכולת תצפית (mTLS כברירת מחדל).

מזעור סיום TLS: או קצה + מוצפן מזרח-מערב בלבד, או הצפנה מקצה לקצה.

10) API על מדיניות ביטחון TLS

קצב הגבלת הגנת DOS, אימות חתימות webhook (HMAC עם סיבוב סודי).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options

MTLS עבור נקודות קצה קריטיות (תשלומים, לוח ניהול), IP Low-List על ידי שותפים.

הגנה חוזרת: חותמת זמן + nunce בבקשות חתומות, חלונות לא יותר מ-5 דקות.

11) מעקב ובדיקות

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

סורקים (CI/CD): בודקים צפנים נתמכים, תעודות, HSTS, OCSP.

תרגילי כאוס/ד "ר: פקיעת תעודה, הורדת מנהל סודי, חתימה על פשרת מפתח - תוכניות תגובה לבדוק.

12) נהלי תגובה

פשרת מפתח: שלילת תעודה מיידית/הסרת מפתח מ-JWKS, היפוך לגיבוי, התחדשות אסימון מאולצת.

תפוגה ללא חידוש: הידרדרות זמנית (תנועה פנימית בלבד), החזרה אוטומטית של התעודות.

דו "ח תקרית: ציר זמן, נושאים מושפעים, חלקים טכניים, אמצעים מתקנים.

13) בדיקת בדיקה מהירה (דפוס מוכן)

[ ] TLS 1 בלבד. 3 (+ 1. 2 עבור לגאסי), רשימה קפדנית של צפנים.

[ ] HSTS ”טעון מראש”, הידוק OCSP, ALPN.

[ ] ECDHE עבור PFS; ECDSA P-256/384 או RSA 3072.

[ ] mTLS בתוך האשכול/בין שירותים קריטיים.

[ ] ילד JWKS +, אסימוני TTL קצרים, תכנית רוטציה.

[ ] סודות - רק בקמ "מ/כספת, סיבוב אוטומטי של מסדי נתונים/ספקים.

[ ] חידוש אוטומטי של תעודות (ACME), התראות תוך 30 יום.

[ ] בדיקת CI/CD של כותרות אבטחה וצפנים פגיעים.

[ ] תיעד ריצות "ו: סיבוב, חזרה, תקריות.

המשך תקציר

הגנה אמינה של API היא שילוב של TLS 1. 3 + HSTS + PFS כמפתח מינימלי ובוגר ותהליכי ניהול סודיים. הוספת mTLS בין שירותים, שחרור אוטומטי/סיבוב באמצעות KMS/Vault/mesh, שמירת TTLs קצרים וחלונות כפולים בעת החלפת מפתחות - ותמזער את הסיכונים של יירוט, הורדת דירוג ושימוש לרעה של סודות דלופים מבלי לשבור את הזמינות והמהירות של המוצר.