בהצפנת מנוחה

בהצפנת מנוחה

1) מדוע היא נחוצה ועל מה בדיוק אנו מגנים

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

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

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

2) מודל איום ושליטה על מטרות

• אובדן/גניבה של מדיה (דיסק, סרט, USB, התקן מפתח).
• גישה לא מורשית לגיבויים/תמונות/רישומים.
• ניצול לרעה של הרשאות ברמת הפלטפורמה/hypervisor/אחסון צומת.
• חציית דיירים עבור שגיאות תצורה.
• קבצים זמניים וזורקים שנופלים לתוך חפצים ותמונות.

1. סודיות של נתונים על המדיום.

2. בידוד קריפטוגרפי של דיירים/סביבות.

3. ניהול מפתחות (יצירה, אחסון, סיבוב, שלילה).

4. שמיעה (מי השתמש במפתח ומתי).

5. מזעור הסיכונים המבצעיים במקרה של תקריות.

3) יסודות הארכיטקטורה

אנחנו מצפינים הכל כברירת מחדל. Opt-out אסור ללא יוצאים מן הכלל ברמת הסיכון.
היררכיית מפתח (הצפנת מעטפה). Root/KEK = DESK (מפתחות הצפנת נתונים) = = אובייקטי מסד נתונים/קבצים/עמודים.
KMS/HSM כמקור אמון. הדור והאחסון של KEK ב-KMS/HSM, מבצעים שם עטיפת מפתחות/פעולות פריסה.
מפתחות לכל דייר. גרנולריות לבידוד ולדרישות סיבוב.
הפרדת חובות. הפלטפורמה פוקדת על בעלי מפתחות; הרשאות מינימום (PoLP).
זריזות מוצפנת. יכולת להגר בבטחה אלגוריתמים/אורכי מפתח.
סיבוב כתהליך, לא אירוע. מפתחות ונתונים חייבים לתמוך בהחלפת ”מתגלגל”.

4) אלגוריתמי הצפנה ומצבים

עבור אובייקטים/קבצים/רשומות: AES-256-GCM או AES-256-SIV (AEAD עם אימות).
עבור התקני בלוקים/כרכים: AES-XTS-256/512 (הגנה מפני תמורות בלוקים; לא AEAD - שימוש בפורמטים של קובץ עם MAC שבו שלמות חשובה).

• TDE, SQL Server TDE, MySQL/InnodB TDE.
• הצפנת שדה/קו (הצפנה דטרמיניסטית) - עבור יכולות חיפוש/joynes על שדות מוצפנים; חל בזהירות.
• דור מפתח ואחסון: KEK - ב- KMS/HSM; DEK - לזכר יישומים קצרי ימים, במהלך אחסון - עטוף בלבד.

5) היררכיית מפתח ו ־ KMS/HSM

1. מפתח שורש (סטטוטורי, ב ־ HSM/KMS). לא משאיר את המתחם HSM/KMS.

2. KEK (מפתח הצפנה). לפרויקט/סביבה/דייר. מנהל את אופן החיים של DEK.

3. DEK (מפתח הצפנת נתונים). לכל אובייקט/קובץ/טבלה/קטע. קצר ימים, מסתובב ללא הפסקה.

מנהגים: ‏

כל פעולות העטיפה/פריסה הן באמצעות KMS API עם ביקורת.
פוליטיקאים: מי יכול ”להשתמש” במפתח שיכול ”לשלוט” במפתח.
מפתח גיאו-הפצה: פין-אל-אזור + שליטה כפולה עבור בין-אזור.
מודל ”שתי בדיקות” (שני אופרטורים) אפשרי לפעולות בסיכון גבוה.
כדי לבודד רמה חזקה - טבעות מפתח נפרדות לדייר.

6) סיבוב, החזרה וציות

סיבוב DEK: שקוף וקבוע (מתגלגל מחדש הצפנה ברמת האובייקט/דף).
סיבוב KEK: מחזורי (eg, כל 6-12 חודשים) + החזרה מיידית אם חשד להיפגע.
ביטול הגישה: באמצעות מדיניות KMS; חסימת פעולות פתיחה = ”קריפטו-הריסה מיידית” של נתונים.
יומני ביקורת: מי, מתי, עם איזה זכויות השתמש במפתחות; לאחסן בנפרד וגם להצפין.
תקנות וסטנדרטים: אנו מתמקדים בדרישות התעשייה (לדוגמה, GDPR/PCI מתיר/רגולטורים מקומיים), אנו משתמשים במודולים קריפטוגרפיים מוסמכים (לדוגמה, בהתאם לרמות ההסמכה).

7) תבניות לפי סוג האחסון

7. 1 כרכי בלוק/קובץ ו ־ VM/מכולות

הצפנת דיסק מלא (XTS) + ניהול מקשים באמצעות KMS (אתחול נפח במהלך ההרים).
הגנה על החלפה, מצבורי התרסקות, ספריות tmp, שכבות חפיפה של מכולה ,/תמונות AMI.
תמונות/תמונות - תמיד מוצפנות עם DEKs נפרדות.

7. 2 אחסון אובייקט

הצפנת מעטפה: DEK ייחודי לכל אובייקט; כותרות/מטא-נתונים - אין דליפות מח "ש.
גישה שליטה למפתח KMS על ידי דיירים וסביבות.
הצפנת צד-שרת (SSE עם KMS) או צד-לקוח (CSE) - בחר לפי מודל האמון.

7. 3 בסיסי נתונים

אפשר TDE היכן שזמין; לקשור את מפתחות בסיס הנתונים של KMS באמצעות תוסף/הרחבה.
עבור שדות רגישים במיוחד - הצפנת יישומים (AEAD) לפני הכניסה לבסיס הנתונים.
רישומי רישומים/רישומי העברות, יומני ארכיון, פתקים - להצפין בנפרד, מפתחות - בנפרד.

7. 4 יומנים/שבילים/מטריצות

תבנית רישום - ללא מידע רגיש כברירת מחדל (תברואה).
ארכיון יומן - מפתחות נפרדים ואחסון TTL קצר.
גישה לרישומי קריאה - באמצעות שירות פרוקסי עם A&A וביקורת.

7. 5 גיבויים ומדיה לא מקוונת

תמיד להצפין על הלקוח לפני כתיבה לקלטת/ענן.
מפתחות אחסון בנפרד (out-of-band), נאמנות עם שליטה נפרדת.
למקרי חירום, פיצול הסוד (לדוגמה, m-of-n) כדי להחזיר את הגישה הראשית.

8) רב ־ דייר

מפתח לדייר: KEK-per-Detant + DEK-per-datagaset.
בידוד מדיניות: KMS name selections, IAM Descriptions, IDP Diversity.
הסרה לבקשת הלקוח: ”למחוק” - לסגת KEK של הדייר ולהרוס DEK.
דיווח לקוח: חפצי ציות, יומני גישה מפתח, אישור סיבוב.

9) ביצועים ותפעול

האצות חומרה (AES-NI/x86, ARMv8 הרחבות קריפטו).
פרופיל נתיב חם: להצפין בגבולות I/O, להימנע הצפנה כפולה שלא לצורך.
בריכות הפעלה של KMS, מטמון עטוף DEKs בזיכרון (עם TTL והגנה על זבל).
SLO/metrics: latency undrep, פרופורציה של אובייקטים ”מוצפנים מחדש”, שגיאות KMS, מהירות הצפנה גיבוי.

10) רישומי התייחסות

שלב 0 - רשימת נתונים. קטלוג כל המאגרים ושבילי הדליפה (tmp, ducps, export, analytics dylets).
שלב 1 - עיצוב היררכי מרכזי. אנו קובעים את רמות KEK/DEK, גרנולריות, אזורים, תפקידים.
שלב 2 - בחר מצבים/ספריות. אלגוריתמים מאושרים, ספריות מוצפנות, מדיניות גירסה.
שלב 3 - אינטגרציה עם KMS/HSM. דור/עטיפה/ביקורת, מדיניות IAM, גיאו-פינג.
שלב 4 - הצפנה לכל כתיבה. אפשר כברירת מחדל, נדידת נתונים קיימים דרך הצפנת הרקע.
שלב 5 - סיבוב ותרחישי חירום. תקנות, בדיקות ”פשרת מפתח”, ”KMS אינו זמין”.
שלב 6 - ניטור וביקורת. לוחות מחוונים, התראות, דוחות ציות קבועים.
שלב 7 - אימונים ו "קידוד מאובטח. "מדריכים למהנדסים, איסור על הצגת סודות ביומנים/פסולת.

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

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

12) טעויות תכופות וכיצד להימנע מהן

הצפנה כפולה ללא משמעות. תוספת איחור ומורכבות. החזיקי שכבה שנותנת את הגרנולריות והבידוד הרצויים.
אחסן מפתחות ליד נתונים. מפתחות תמיד נפרדים, תחת מודל גישה שונה.
חפצים נשכחים. קבצים זמניים לא מוצפנים, יצוא CSV, מצבורי תמיכה. אפשר ניטור ב CI/CD ומניעת אובדן נתונים.
חוסר סיבוב. הפוך את הסיבוב לחלק מהצינור/קרון, לא הליך ידני.
יומנים עם נתונים רגישים. הזן חוזה לפורמט רישום וחיטוי אוטומטי.

13) מתכונים קטנים (פסאודו-קוד)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) רשימות בדיקה

[ הצפנת ברירת המחדל ] מופעלת על כל סוגי האחסון.

[ ] היררכיית המפתח מתוארת ומיושמת; תפקידים ומדיניות IAM מוגדרים.

[ ] KMS/HSM משולב, פעולות מפתח ביקורת מופעלת.

[ ] סיבוב DEK/KEK הוא אוטומטי; תרחישי פשרה הסתדרו.

[ ] גיבויים, תמונות, רישומים וזריקות - מוצפנים; מפתחות מאוחסנים בנפרד.

[ ] התראות מוגדרות לשגיאות KMS, סטיות תג AEAD, פרופורציה של חפצים לא מוצפנים.

[ ] KMS לא זמינים ומבחני שלילת מפתח עברו.

[ דו "ח חודשי ] על ניצול מפתח וניסיונות גישה.

[ ] תוכנית קריפטו-זריזות וחלון לנדידת אלגוריתם ללא כאבים.

[ ] צוות אדום תקופתי לחלץ נתונים ממדיה גולמית.

15) Q&A (FAQ)

Q: האם הצפנת דיסק מלא מספקת?
א. עבור סיכונים פיזיים - כן, אבל עבור בידוד דיירים וסבב גמיש כדאי מעטפה עם DIK-on-object/set.

קיו: מה לעשות כאשר ק "ק בסכנה?
א. החזר מיד את KEK ל ־ KMS, שחזור מחדש, ערוך מחדש את כל ה ־ DEKS, בדוק רישומים והפעל RCA.

ש: איך אנחנו מצפינים את השדות שאנחנו מחפשים?
א. השתמש בתכניות דטרמיניסטיות או ב ־ FPEs רק בהערכת סיכונים קפדנית (דפוס לקות). עדיף לעצב שאילתות כך ששדות רגישים לא ידרשו תצוגה פתוחה.

קיו: האם אני צריך פקודה נפרדת בשביל המפתחות?
A: אופרטור ההצפנה/KMS מומלץ כתפקיד עם זכויות ונהלים נפרדים.

• ”ניהול מפתח וסבב”
• ”אימות S2S”
• ‏ ”לחתום ולאמת בקשות” ‏
• ”חבר OAuth2/OpenID בקרנל”
• ‏ ”ערובות למשלוחים” ‏