הצפנת נתונים במנוחה (encryption at rest): היכן נשברת ההגנה
הצפנת נתונים במנוחה נחשבת בדרך כלל לבעיה פתורה: הדיסק של מכונה וירטואלית מוצפן, כלומר אי אפשר לקרוא דבר מהמדיה. עם זאת, הגנת הנתונים על המדיה נשברת בפריפריה — במקומות שבהם נוצרים עותקים: סנאפשוטים, ייצוא, מטמון, יומנים. דווקא המקומות האלה אחראים לרוב התקריות, ולא הכרך הראשי.
הערוץ הנפוץ ביותר — סנאפשוטים וגיבויים לא מוצפנים. סנאפשוט של כרך יורש את ההצפנה של ההורה, אבל dump של מסד נתונים או העתקת ספרייה לאחסון אובייקטים יוצאת בטקסט גלוי: ההצפנה מוגדרת ברמת הדיסק, אך לא ברמת הייצוא. דליפת גיבויים מביאה לכך שמהארכיון מוצאים את כל מסד הנתונים בשלמותו — כולל הסכמה והקשרים.
השכבה השנייה — מטמון האפליקציות וארכיוני יומנים. הפעלות (sessions) וייצוא זמני נכתבים לדיסק המקומי של הצומת, והיומנים מכילים טוקנים ונתונים אישיים בטקסט גלוי. פורמלית אלה לא «נתונים», למעשה — גישה מוכנה לשירות.
סיכון נפרד — גישה מבפנים: אם המפתח נמצא לצד הנתונים, באותו פרויקט או על אותו צומת, ההצפנה מצילה מהוצאת מדיה, אך לא מחשבון משתמש שנפרץ. מפתחות מוציאים לאחסון נפרד עם הפרדת הרשאות ויומן פניות — לדוגמה, HashiCorp Vault — וההצפנה נבנית בשני רבדים: כרך בלוקים ושירות ניהול מפתחות.
מדיניות הצפנה אם כן עונה על שלוש שאלות: מה מוצפן כברירת מחדל, היכן נמצאים המפתחות ומי מבצע להם רוטציה. בהמשך נפרט כיצד זה נסגר.
מה משתנה לאחר ההטמעה: סוגי סיכונים וזמן תגובה
האפקט הראשון — נעלם סוג התקלות «מדיה מחוץ להיקף». דיסק מחדר שרתים, כונן שהוצא משימוש, צילום דיסק שהוסר או עותק ארכיוני ללא מפתח נקראים כקבוצת בלוקים אקראית: הצפנת כרכים פועלת ברמת ההתקן ואינה תלויה בקפדנות האפליקציה. חלק הנתונים מחוץ להגנה מצטמצם לא חלקית, אלא לאפס — תחת ההגנה נכנסים גם גיבויים וגם כרכים זמניים.
האפקט השני — הפרדת גישה למפתחות. המפתח חי בנפרד מהנתונים, ב-HashiCorp Vault או בשירות ניהול מפתחות מנוהל, ומונפק לתפקיד מסוים עבור פעולה מסוימת לזמן מוגבל. זה מנתק את הקישור «גישה לדיסק = גישה לתוכן»: מנהל האחסון רואה מטא-נתונים, אך אינו יכול לפענח את הכרך. רוטציה מתוכננת אינה דורשת הצפנה מחדש של כל המערך — משתנה רק מפתח-העטיפה.
השלישי — ביקורת הגישה לנתונים הופכת לניתנת לבדיקה. כל הנפקת מפתח מותירה רשומה: מי, מתי, לאיזה משאב ועל איזה בסיס קיבל גישה. חקירת תקרית מתבצעת לפי היומן, ולא לפי תשאול צוותים והשוואת יומני אפליקציות.
מכאן — חיסכון בזמן תגובה. תרחיש «המדיה נעלמה» פירושו היה בעבר ימי חקירה: ספירת עותקים, הערכת נפח, הודעות. כעת הוא מצטמצם לשעות: לתעד את העובדה, לבטל את המפתח, להנפיק חדש.
הדליפה נסגרת על ידי ביטול גישה, ולא על ידי דריסה של כל העותקים — זה מקצר גם את חלון הסיכון וגם את היקף העבודה הידנית בעת תקרית.
השוואת גישות: הצפנה בדיסק, באחסון ועבור סודות
גישות ל-encryption at rest אינן מחליפות זו את זו: הן סוגרות סוגי סיכון שונים, והבחירה תלויה במי שאנו סומכים עליו עם המפתח ומה אנו מגנים — מדיה, אובייקט בודד או סוד.
הצפנה מלאה של דיסק וכרכים מגנה מפני הוצאת מדיה ודליפת סנאפשוט, אך חסרת אונים מול תהליך שכבר קיבל גישה לכרך מחובר. הצפנת אחסון אובייקטים פועלת ברמת אובייקטים וגרסאות בודדים ואינה דורשת בנייה מחדש של מכונות.
סודות מוציאים למתחם נפרד: מנהל סודות מחלק גישה לפי תפקידים, ושירות ניהול מפתחות מנהל רוטציה ויומן פניות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הצפנה מלאה של דיסק, כרכים וסנאפשוטים | מכונות וירטואליות, מסדי נתונים על כרכים מקומיים, גיבויים | המפתח נדרש בעת האתחול; בתוך מערכת פועלת הנתונים נקראים בגלוי |
| הצפנת אחסון אובייקטים | קבצים, ייצוא, ארכיונים, אובייקטים עם גרסאות | סוגר רק את האובייקט; הרשאות גישה ומחזור חיים מוגדרים בנפרד |
| מתחם נפרד לסודות ומפתחות | סיסמאות, טוקנים, מפתחות חתימה, גישות למסדי נתונים | נדרשת משמעת: סודות לא צריכים להיכנס למשתני סביבה ומאגרי קוד |
| סכמה היברידית | מספר סוגי נתונים ודרישות לביקורת גישה | מורכבת יותר לתחזוקה: יהיה צורך לתאר היכן נמצא איזה מפתח ומי הבעלים שלו |
בפועל משלבים סכמות: כרך וסנאפשוטים מוצפנים ברמה התחתונה, אובייקטים — באחסון, והגישות לכל השאר נמצאות במתחם נפרד עם רוטציה וביקורת.
שלבי הטמעה: מספירת נתונים ועד מסירה
הצפנה במנוחה נשברת לא בזמן ההגדרה, אלא בזמן התפעול: מפתח שנשכח בעת הוצאת צומת מכלל שימוש, או גיבוי שאיש לא ניסה לפענח, מאפסים את כל העבודה. לכן ההטמעה מתבצעת כשרשרת, שבה כל שלב נשען על הקודם ונבדק לפני המעבר הלאה.
- ספירת נתונים. אוספים רשימה של כרכים, מסדי נתונים, אחסוני אובייקטים, עותקים וייצוא — כולל אלה שנמצאים על מכונות של מהנדסים. בלי הרשימה הזו כל סכמה מכסה רק חצי מהמתחם.
- סיווג נתונים. מסמנים מערכים לפי רגישות: היכן נדרש כרך מלא, היכן מספיקה הצפנת אובייקטים, והיכן נתונים לא אמורים להישמר כלל. הסיווג קובע גם את שיטת ההגנה וגם את מצב הגישה.
- סכמת מפתחות. בונים היררכיה: מפתח שורש באחסון סודות, מפתחות הצפנת נתונים — בנפרד למתחם ולשירות, עם הרשאות נפרדות. רוטציה של מפתחות מתוכננת מראש, יחד עם לוח זמנים וסדר הוצאה מכלל שימוש.
- הגדרת הצפנה. מפעילים LUKS על כרכי בלוקים, הצפנה בצד השרת באחסון אובייקטים, הצפנה ב-DBMS ובגיבויים. בודקים שהמפתחות לא דולפים לתמונות, קבצי קונפיגורציה ויומנים.
- בדיקת שחזור. מפענחים עותק בסביבת בדיקה נקייה בדיוק לפי ההוראות, ולא לפי הזיכרון של המהנדס. אם השחזור אינו משוחזר בפעם הראשונה לפי המסמך — הנוהל לא מוכן.
- ביקורת ונוהל גישה. מפעילים תיעוד יומן של פעולות עם מפתחות, בודקים למי יש זכות לפענוח, ומצמצמים את המעגל למי שבאמת נדרש.
- מסירה והדרכה. מעבירים את הסכמה, הוראות רוטציה ושחזור, ועוברים עליהן עם משמרת התורנות של הלקוח.
תוצאת העבודה — לא דוח, אלא היכולת של הצוות שלכם לבצע רוטציה ולהעלות נתונים מעותק בלעדינו.
חפצי מסירה: קונפיגורציות, סכמות מפתחות, נהלים
העבודה מסתיימת לא בהצפנה מופעלת, אלא בסט של חפצים שלפיהם הצוות שלכם יוכל לתפעל ולבקר את ההגנה בלי התמיכה שלנו. אנחנו מוסרים קונפיגורציות עובדות, ולא תזכיר «איך להגדיר» — אפשר ליישם אותן שוב ולהשוות למצב הנוכחי של התשתית.
- קונפיגורציות עובדות — פרופילי LUKS לדיסקים ומחיצות, פרמטרים של הצפנה בצד השרת ל-buckets ולמסדי נתונים, חיבור לאחסון מפתחות.
- סכמת היררכיית מפתחות — מפתח שורש, מפתחות הצפנת נתונים ומפתחות עטיפה: מה מגן על מה, היכן נמצא, כיצד מתבצעת רוטציה בכל רמה.
- מדיניות גישה לנתונים — לאילו תפקידים ולחשבונות שירות מותר לפענח, באילו תנאים, כיצד מנוהל יומן הפניות למפתחות.
- סדר רוטציה וביטול — לוח זמנים לרוטציה מתוכננת, קריטריונים לרוטציה לא מתוכננת (דליפה, עזיבת עובד), התנהגות השירותים כאשר המפתח מבוטל.
- הוראות שחזור — שלבים: גישה לאחסון המפתחות, טעינת הכרך, עלייה מגיבוי, בדיקת שלמות; תרחיש נפרד לאובדן אחסון אחד.
- מטריצת אחריות — מי הבעלים של המפתחות, מי מנפיק גישה, מי מאשר רוטציה, ולמי מתבצעת הסלמה בעת תקרית.
- תיעוד הצפנה — מפת נתונים עם רשימת מתחמים סגורים, נימוק לסכמה הנבחרת וגבולות כנים: מה ההצפנה אינה מכסה.
המסמכים נמצאים לצד הקונפיגורציות באותו מאגר: כאשר התשתית משתנה, הוראה מיושנת שוברת את הבדיקה בשלב הבנייה, ולא צפה ברגע התקרית.
מקרה בוחן: מעבר להצפנה בלי לעצור את השירות
לקוח — שירות עם אחסון מבוזר: עשרות כרכים, שחלקם נוצרו ידנית ונשארו לא מוצפנים, כי הנוהל לא הספיק לקצב גדילת התשתית. אי אפשר היה לעצור את הפלטפורמה לצורך הצפנה מחדש — העומס הוא מסביב לשעון, וחלון התחזוקה לא הספיק אפילו לאתחול מחדש של צמתים. נפרט מה הראה הביקורת ומה השתנה לאחר מכן.
מה נמצא לפני ההתחלה
הספירה נתנה תמונה לא נעימה: 34% מהכרכים לא היו מוגנים בהצפנה, והרישום התנהל בטבלה שסטתה מהמציאות בשמונה מכונות. רוטציה של מפתחות כללה 14 פעולות ידניות ונמשכה ימים, ובדיקת גיבויים — כתשע שעות באופן מדגמי, בלי שחזור מאומת.
נקודת הכשל התבררה כנמצאת במקטע אחד: שם ניתן היה להצפין מחדש כרכים רק עם עצירה, ולכן דחו אותם, ודווקא הם הצטברו הכי הרבה זמן.
מה שינו
העברנו בשכבות: תחילה רפליקות קרות, אחר כך צמתים פעילים — ההצפנה מחדש התבצעה ברקע עם תעבורה חיה, בלי ניתוק חיבורים. המפתחות הועברו ל-Vault ונקשרו למדיניות גישה, הרוטציה הפכה לנוהל אחד עם בדיקה אוטומטית, וכל עותק החל להיות משוחזר בסביבת בדיקה נפרדת.
סיכום לפי מדדים: שיעור הכרכים שאינם מכוסים — 34% → 0, רוטציה של מפתחות — 14 צעדים ידניים → הפעלה אחת, בדיקת גיבויים — תשע שעות מדגמית → ארבעים דקות לכל העותקים. זמן השבתה במהלך המיגרציה — אפס, כשלים בהצפנה מחדש — אפס.
במה שונה הצפנה בדיסק מהצפנה באחסון?
ההבדל נקבע לא לפי האלגוריתם, אלא לפי המקום שבו הטקסט המוצפן הופך לטקסט גלוי. הצפנה בדיסק פועלת ברמת התקן בלוקים: הכרך מפוענח על ידי הליבה לאחר הזנת המפתח, ומכאן כל הקלט/פלט עובר בגלוי.
נקודת הפענוח נמצאת בתוך אותה מכונה, ולכן גבול האמון עובר דרך ההיפרוויזור והמארח: root, dump זיכרון חירום או דיבאגר מחובר רואים את הנתונים בדיוק כמו האפליקציה עצמה.
הצפנה באחסון מפענחת את האובייקט בצד השירות — בגבול הרשת או בתוכו. הספק מקבל את המפתח, ואם הסכמה אינה צד-לקוח, הוא רואה את הטקסט הגלוי יחד עם המטא-נתונים: שמות אובייקטים, גדלים, זמן גישה.
לעומת זאת, ניהול המפתחות מתרכז — מדיניות גישה, רוטציה, ביטול, יומן פניות למפתח ומפתחות נפרדים ל-bucket או prefix.
מה נשאר לא סגור: במקרה הראשון — צילום זיכרון, תהליך חי, כרך מחובר; במקרה השני — שירות האחסון עצמו, המנהלים שלו וכל מי שקיבל זכות לפענוח. אף אחת מהגישות אינה מגנה מפני מי שכבר יש לו גישה לייצוג המפוענח.
לכן משלבים אותן. הצפנה בדיסק סוגרת את המדיה הפיזית ודיסקים שהוצאו, הצפנה באחסון נותנת גרנולריות ומפתחות מנוהלים, וסודות ברמת האפליקציה מעבירים את גבול האמון ללקוח — המפתח נשאר רק אצלו.
ניהול מפתחות הופך למתחם נפרד: היכן נמצא מפתח השורש, מי יכול לבצע לו רוטציה, מה יקרה בעת ביטול ומי באותו רגע מאבד גישה לנתונים.
שאלות שמהנדסים שואלים לפני ההתחלה
לפני תחילת הצפנה במנוחה מהנדסים שואלים בערך את אותו סט שאלות — על מהירות, מפתחות ותאימות למערכות שכבר פועלות. להלן תשובות קצרות בלי ניסוחים מתחמקים; פרטים לתשתית מסוימת נפרט בשלב התכנון.
עד כמה ההצפנה תאט פעולות?
במעבדים עם האצה חומרתית, תקורת ההצפנה של בלוקים נשארת בטווח של כמה אחוזים בתפוקה וכמעט לא נראית בזמן התגובה של האפליקציות. עבור אחסון אובייקטים, הצפנה בצד השירות אינה צורכת משאבי אפליקציה כלל.
לפני ההטמעה אנו מבצעים מדידות על פרופיל העומס של הלקוח: פעולות קריאה, כתיבה וכתיבה מחדש — ומראים את ההבדל לפני ואחרי.
מה יקרה אם יאבד מפתח?
הנתונים יהפכו לבלתי קריאים — זו מתמטיקה, לא שאלה של תמיכה. לכן מפתח האב נשמר באחסון מאובטח עם ניהול גרסאות והפרדת סמכויות: להנפקה נדרש יותר ממנהל אחד. עותק מהימן של המפתח נמצא בנפרד מהנתונים המוצפנים, והרוטציה מתבצעת לפי הנוהל, ולא «כשנזכר».
אפשר להפעיל הצפנה על מערכת פעילה?
כן, בשלבים: תחילה מצפינים כרכים חדשים וכתיבות חדשות, אחר כך בכתיבה מחדש ברקע מכסים נתונים קיימים עם נקודות חידוש. אפשר לעצור ולהמשיך את התהליך — הפסקה של הצפנה מחדש אינה הורסת בלוקים שכבר עובדו. נסיגה בשלב ביניים מתוכננת.
מה עם גישה לעותקים ישנים וכמה זמן לשמור אותם?
גיבויים נשארים מוצפנים במפתחות שהיו בתוקף בעת יצירתם, ולכן היסטוריית גרסאות המפתחות נשמרת לא פחות מהעותקים עצמם. אם מפתח של גיבוי ישן יימחק לפני תום תקופת השמירה של העותק, שחזור ממנו יהפוך לבלתי אפשרי. תקופות השמירה של עותקים ומפתחות מסונכרנות אצלנו במדיניות אחת.
נדון במשימה: מה יידרש מכם בהתחלה
כדי שההערכה תהיה עניינית ותוכנית הטמעת ההצפנה תישען על עובדות ולא על הנחות, בהתחלה מספיק לפרט את הנתונים הראשוניים. אין צורך במפרט מוכן — יש צורך בחתך של התשתית והמגבלות שבתוכן נצטרך לפעול.
- הרכב המערכות ומקומות האחסון: דיסקים של מכונות וירטואליות, כרכי שרתים, מסדי נתונים, אחסון אובייקטים, גיבויים;
- מה מצפינים: רק נתונים חדשים או שנדרשת מיגרציה של כרכים וארכיונים קיימים;
- דרישות להגנה: מדיניות פנימית, תקנים ענפיים, ציפיות ביקורת, האם נדרשת הפרדה של מפתחות ממנהלי התשתית;
- היכן נשמרים המפתחות: שירות ניהול מפתחות נפרד, מודול חומרתי או אחסון סודות, ולמי ניתנה גישה;
- האחראים על המפתחות: בעלים, סדר אישור רוטציה, נוהל להוצאת מפתח מכלל שימוש;
- חלונות ביצוע עבודות: הפסקות מותרות, דרישות לרציפות, מוכנות לתרגל מעבר בסביבת בדיקה או רפליקה;
- סביבה וגישות: אתר משלכם או ענן, אורקסטרטור, סיגמנטציה של רשת, אילו הרשאות יינתנו לנו.
מהסט הזה נבנית מפת עבודות: היכן ההצפנה מופעלת בלי השבתה, היכן נדרש מעבר נתונים, והיכן מספיק להחליף סכמה בכרכים חדשים. תארו את המשימה — נחזור עם הערכה, תוכנית הטמעה ורשימת סיכונים לכל מקטע.