הצפנת גיבויים: היכן ההגנה על הנתונים נשברת
הצפנת גיבויים אינה נשברת בשלב בחירת האלגוריתם — בכך מתמודד כיום כל כלי. היא נשברת בתפעול: העותק נשלח לאחסון אובייקטים כשהוא גלוי, המפתח מונח באותו דלי שבו נמצאים הנתונים, ולגישה למאגר זכאים כל מי שאי־פעם נזקק לשחזור. דליפה דרך גיבוי מתרחשת כמעט תמיד כך — לא על ידי פריצת הצופן, אלא על ידי עקיפתו.
הפרצה הנפוצה ביותר — תמונות מצב לא מוצפנות. הכרך הראשי מוצפן, אך תמונת מצב של הדיסק או דאמפ של מסד הנתונים נשלחים לאחסון "כפי שהם", מפני שתמונת המצב נוצרת על ידי ההיפרוויזור ולא על ידי היישום.
המקרה הטיפוסי השני — הצפנה רק בעת ההעברה: הערוץ מוגן, אך בדלי העותק מונח כטקסט גלוי, וההגנה על גיבויים מסתיימת בגבול הרשת.
אחסון מפתחות — השגיאה השלישית והיקרה ביותר. מפתח הרשום בקונפיג לצד העותקים או באותו מאגר מבטל את ההצפנה כולה: מי שהשיג גישה לאחסון משיג גם את הנתונים.
בנפרד פוגע בקרה חלשה על הגישה — חשבונות משותפים, הרשאות קריאה על כל המאגר, היעדר הפרדת תפקידים בין מי שכותב עותקים למי שמשחזר אותם.
מפרקים כיצד זה נסגר: היכן למקם את ההצפנה בשרשרת, כיצד להפריד בין מפתחות לנתונים וכיצד לבנות גישה שבה עותק שנגנב נותר אוסף חסר תועלת של בתים.
מה נותן הצפנת עותקים באחסון ובהעברה
הצפנת גיבויים מכסה שני סוגי סיכונים שונים: יירוט העותק ברגע ההעברה בין אתרים וקריאת נתונים מהמדיה כשהיא כבר נמצאת באחסון. זוהי לא הגדרה אחת, אלא צירוף — הצפנה בהעברה מגנה על הערוץ, הצפנה באחסון מגנה על הארטיפקט עצמו, ושתיהן פועלות באופן בלתי תלוי. אם עותק דלף מסרט או מאחסון אובייקטים, ללא מפתח הוא נשאר רצף בייטים בלתי קריא.
ההשפעה המעשית מדידה. שיעור העותקים המוגנים מגיע ל-100% — כל גיבוי מוצפן לפני הכתיבה, ולא "מתישהו אחר כך". סיווג הסיכונים יורד: תקרית של גניבת מדיה או גישה לאחסון מפסיקה להיות דליפת נתונים והופכת למשימת רוטציה של מפתחות.
זמן השחזור לא גדל — הפענוח מתבצע בצד המקבל ומוסיף לתהליך השחזור שניות, ולא שעות, אם המפתחות זמינים למשמרת התורנית.
הנקודה המרכזית היא ניהול מפתחות, ולא האלגוריתם עצמו. המפתחות נשמרים בנפרד מהעותקים, הרוטציה מוגדרת לפי לוח זמנים, והגישה אליהם מוגבלת לפי תפקיד. אחרת ההצפנה הופכת לקישוט: העותק מוצפן, והמפתח מונח לידו באותו אחסון. אנו מפרידים בין המעגלים הללו, כדי שפשרה באחסון לא תעניק גישה לנתונים.
בנפרד אנו בודקים את השחזור. עותק מוצפן שאי אפשר לפרוס הוא לא הגנה, אלא גיבוי אבוד. לכן בתקנון נכלל שחזור בדיקה מארטיפקט מוצפן: מאשרים שהמפתח זמין, ששרשרת הפענוח עוברת, ושהנתונים מוחזרים בזמן. כך ההצפנה לא מפריעה לשחזור הנתונים, אלא משולבת בו.
גישות להצפנה: השוואת מצבים וכלים
הבחירה בגישה קובעת לא רק את חוזק ההגנה, אלא גם היכן נמצאים המפתחות, מי יכול לקרוא את הנתונים ומה יקרה בעת כשל. להלן שלוש תכניות עבודה, שביניהן באמת בוחרים בעת בניית גיבוי.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| הצפנה בצד הלקוח | הנתונים יוצאים מחוץ לפרימטר, אין אמון באחסון, דרישות הרגולטור לשליטה במפתחות | המפתחות והרוטציה שלהם — בצד שלכם; עם אובדן מפתח לא ניתן לשחזר את הגיבוי; דה-דופליקציה ודחיסה בצד האחסון כמעט אינן פועלות |
| הצפנה בצד האחסון | הנתונים נשארים בקונטור מהימן, חשובים הפשטות ומהירות ההטמעה | לספק האחסון יש גישה טכנית למפתחות; ההגנה פועלת רק מפני גניבת מדיה ודליפה פיזית |
| תכנית היברידית | נדרש פשרה: נתונים רגישים — תחת מפתח משלכם, השאר — בצד האחסון | מורכבת יותר בתחזוקה: שני קונטורים של מפתחות, מדיניות רוטציה וביקורת נפרדות |
הצפנה בצד הלקוח מעניקה שליטה מקסימלית: הנתונים מוצפנים לפני השליחה, האחסון רואה רק זרם בלתי קריא. המחיר — אתם אחראים באופן מלא על מחזור החיים של המפתחות: יצירה, רוטציה, גיבויים של המפתחות עצמם והפרדת גישה אליהם.
הצפנה בצד האחסון מסירה את העומס הזה, אך גבול האמון עובר בתוך התשתית של הספק. התכנית ההיברידית מכסה את שני התרחישים: נתונים קריטיים עוברים תחת מפתח עצמאי, השאר — בניהול האחסון. את הבחירה בגישה מקבעים בשלב התכנון — ממנה תלויים גם תכנית הרוטציה וגם הליך השחזור.
כיצד אנו מיישמים הצפנת גיבויים: שלבי העבודה
יישום הצפנת גיבויים מתחיל בביקורת תשתית: אנו אוספים רשימה של מערכות מקור, בוחנים היכן נוצרים כעת עותקים, כיצד הם מועברים והיכן הם מאוחסנים. בשלב זה חשוב להבין אילו נתונים כפופים לדרישות הגנה ואילו ניתן להשאיר במתאר הנוכחי.
בנפרד אנו מתעדים נקודות שבהן מפתחות והרשאות גישה כבר נמצאים בשימוש — כדי לא ליצור מתאר שני לניהול סודות.
לאחר מכן אנו מתכננים את הסכימה: בוחרים מה מוצפן בצד המקור, מה — בהעברה, ומה — בצד האחסון. מגדירים את מודל ניהול המפתחות ואת סדר הרוטציה. לאחר התכנון עוברים להגדרה ולבדיקה — דווקא כאן עולים לרוב צווארי הבקבוק שאינם נראים על הנייר.
- ביקורת תשתית: מיפוי מלאי של מקורות, אחסון וערוצי העברת עותקים.
- תכנון הסכימה: בחירת רמות הצפנה (מקור, ערוץ, אחסון) ומודל ניהול מפתחות.
- הגדרת הצפנה: הפעלת הצפנה בסוכנים ובאחסון, הגדרת ערוצי העברה מאובטחים.
- ארגון אחסון המפתחות: הוצאת מפתחות לאחסון מאובטח נפרד, הגדרת הרשאות גישה ורוטציה.
- בדיקת שחזור: פריסה לניסיון מתוך עותק מוצפן על מתקן מבודד.
- נהלים ותיעוד: תיעוד נהלי רוטציה של מפתחות, שחזור ופעולות במקרה של פגיעה.
- מסירה: הדרכת צוות הלקוח, מסירת הרשאות והוראות, ליווי המחזור הראשון.
השלב המרכזי — בדיקת השחזור. לעותק מוצפן שאי אפשר לפרוס ממנו אין ערך, ולכן אנו תמיד מריצים מחזור שחזור מלא לפני המסירה. אם בשלב זה משהו אינו מסתדר — אנו חוזרים להגדרה, ולא מעבירים את הבעיה לתפעול.
מה הלקוח מקבל לידיו: תצורות ותקנות
אנחנו מוסרים לא "שרת מוגדר", אלא ערכה ניתנת לשחזור: לפיה הצוות שלכם יוכל להקים הצפנה מאפס, לבצע בדיקה או שחזור בלעדינו. כל ארטיפקט מנוהל בגרסאות במאגר — שינויים עוברים סקירה, כמו קוד רגיל.
- תצורות הצפנה: פרמטרים של צפנים ומצבים, רוטציית מפתחות, תבניות לאחסון ולערוצי העברה — עם הסבר מדוע נבחר דווקא מצב זה.
- תרשימי זרימת נתונים: היכן הנתונים מוצפנים, היכן מפוענחים, היכן מאוחסנים המפתחות ומי ניגש אליהם — בעמוד אחד נראות כל נקודות האמון.
- מדיניות גישה: תפקידים, למי אילו מפתחות וגיבויים נגישים, הפרדת הרשאות להצפנה ולפענוח, תיעוד יומן של גישות.
- תיעוד: הוראות לרוטציית מפתחות, הוספת צומת חדש לתרשים, אבחון תקלות אופייניות — מיועד למהנדס תורן, ולא למחבר ההגדרה.
- תקנות שחזור: סדר פעולות שלב אחר שלב בעת אובדן מפתח, נזק לגיבוי או rollback — עם ציון מי מקבל את ההחלטה ומה נבדק לפני ההפעלה.
- רשימת תיוג לקבלה: מערך בדיקות המאשרות שההצפנה פועלת באחסון ובהעברה, והשחזור עובר בסביבת בדיקה.
בנפרד אנחנו מתעדים מטריצת אחריות: מה אנחנו מתחזקים, מה נשאר בצד שלכם. זה מסיר את הסיכון המרכזי — מצב שבו בעת תקלה אף אחד לא יודע אצל מי המפתחות ומי מפעיל את השחזור.
מקרה בוחן: כיצד הצפנת גיבויים צמצמה סיכוני דליפה
פנה אלינו לקוח לאחר שגיבויים של אחד ממסדי הנתונים שלו נמצאו באחסון רשת משותף בגלוי — לגישה אליו הייתה הרשאה למחצית מהקבלנים. הגיבויים ישבו בארכיונים ללא הצפנה, המפתחות לא הוחלפו, ואת יומן הגישה איש לא קרא.
הבדיקה הראתה: לא ניתן לשחזר את שרשרת "מי ומתי ייצא את הדאמפ", והדאמפ עצמו היה קריא בכל עורך טקסט.
מה עשינו
חילקנו את ההגנה לשני מעגלים. בהעברה, הגיבויים עוברים רק בערוץ מאובטח עם אימות תעודת המקבל — החלפת צומת או יירוט תעבורה אינם מאפשרים עוד גישה לתוכן. באחסון הפעלנו הצפנה בצד הלקוח: המפתח אינו יוצא מהמודול המאובטח, והאחסון רואה רק בלוק מוצפן. הפרדנו את המפתחות לפי תפקידים והפעלנו החלפה אוטומטית עם תיעוד של כל פעולה.
בנפרד סגרנו את השחזור: פענוח אפשרי רק עם אישור מפורש ורישום בביקורת. זה מסיר את הסיכון העיקרי — כאשר הגיבוי מוגן, אך לא ניתן לשחזר ממנו, כי המפתח אבד או פג תוקפו.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| גיבויים בגלוי | כולם | 0 |
| תדירות החלפת מפתחות | לא בוצעה | לפי תקנון, אוטומטית |
| זמן שחזור | שעות של עבודה ידנית | דקות לפי תרחיש מתורגל |
| יומן גישה קריא | לא היה קיים | ביקורת מלאה לכל פעולה |
חודש לאחר ההטמעה, בדיקת הגישה לאחסון הפסיקה להיות סיכון: גם בעת פגיעה בחשבון של קבלן, הנתונים נותרים בלתי קריאים. גישה זו תואמת את דרישות OWASP להגנת נתונים באחסון ובהעברה — אנו נשענים על מקור זה כעל עוגן בתחום.
אם הגיבויים שלכם נמצאים באחסון משותף ואיש אינו יודע בוודאות למי יש גישה אליהם — תארו את המשימה, ונחזור עם הערכה ותוכנית.
במה שונה הצפנה בעת העברה מהצפנה בעת אחסון?
הצפנה בעת העברה מגנה על נתונים ברגע המעבר בין צמתים: לקוח ואחסון, שתי רפליקות של המאגר, שירות ונמען חיצוני. הערוץ מוצפן למשך הסשן — בדרך כלל TLS עם אימות תעודה בשני הצדדים, כדי למנוע החלפת צומת. האיום כאן קונקרטי: יירוט תעבורה ברשת, האזנה לסגמנט פנימי, החלפת נקודת היעד. ברגע שהנתונים נכתבו לדיסק, הגנת הערוץ מפסיקה לפעול — הקובץ נשאר קריא למי שקיבל גישה למדיה.
הצפנה בעת אחסון עובדת עם הארטיפקט עצמו: גיבוי מוצפן לפני הכתיבה ונשאר מוצפן כל הזמן שהוא נמצא באחסון או בקלטת. המפתח נשמר בנפרד מהנתונים — אחרת המשמעות אובדת. כאן נסגר סוג אחר של איומים: דליפת צילום דיסק, גניבת מדיה מהארכיון, גישה לדלי עם גיבויים, הרשאות שגויות אצל קבלן. אפילו בדליפה מלאה של קבצים ללא מפתח אי אפשר לשחזר את התוכן.
ההבדל עקרוני: העברה מגנה מיירוט בדרך, אחסון — מגישה לנתונים שכבר נמצאים. אלו לא חלופות, אלא שתי שכבות של סכימה אחת, ויש להגדיר אותן יחד. העברה ללא הצפנת אחסון משאירה עותקים פתוחים בדיסק; אחסון ללא הגנת ערוץ נותן חלון שבו הנתונים עוברים ברשת בצורה פתוחה.
בפועל הסכימה נראית כך: הערוץ מוקם על תעודות מאומתות, והארכיון עצמו מוצפן במפתח המוצא לאחסון סודות נפרד. המפתחות מסובבים לפי לוח זמנים, הגישה אליהם מופרדת לפי תפקידים, והליך השחזור מתורגל מראש — אחרת בעת תקרית יתברר שהמפתח אבד יחד עם הגישה. בנפרד אנו בודקים שגם עותקי ביניים וגם snapshots מוצפנים, ולא רק הארכיון הסופי.
ספקות טכניים נפוצים בבחירת ספק
הצפנת גיבויים כמעט תמיד מעוררת את אותם ספקות טכניים: האם היא תשבור תהליכים קיימים, האם השחזור ייתקל בצוואר בקבוק של ביצועים, מי וכיצד ינהל את המפתחות. להלן — ניתוח של כל אחד מהם בלי מילים כלליות.
האם ההצפנה תואמת לתשתית הנוכחית שלנו ולפורמטים של הגיבויים?
כן, אם מצפינים ברמת האחסון או בערוץ התעבורה, ולא כותבים מחדש את הדאמפים עצמם. הצפנה «על הדרך» אינה משנה את פורמט הגיבוי — מסד הנתונים, אחסון הקבצים או תמונת הדיסק נשארים בצורתם הרגילה, והמפתח מוחל על הקונטיינר או על ערוץ ההעברה.
לכן משימות שכבר הוגדרו, לוחות זמנים ובדיקות שלמות ממשיכים לעבוד בלי שינויים. אנו בודקים בנפרד את התאימות לכלים הנוכחיים שלכם לגיבוי לפני תחילת העבודה.
האם ההצפנה תאט את יצירת הגיבויים והשחזור?
העומס העיקרי נופל על המעבד והרשת, ולא על הדיסקים, ולכן בשרתים מודרניים תוספת זמן ההרכבה נמדדת בדרך כלל באחוזים בודדים. מה שקריטי יותר הוא השחזור: אם המפתח נשמר בנפרד ואינו זמין באופן מיידי, הזמן עד להשבת הנתונים גדל לא בגלל ההצפנה, אלא בגלל הליך הגישה למפתח. אנו מתכננים את הסכמה כך שנתיב השחזור יישאר קצר וצפוי.
מי וכיצד ינהל את המפתחות, ומה יקרה במקרה של אובדנם?
המפתחות נשמרים באחסון מאובטח נפרד, ולא לצד הגיבויים — אחרת משמעות ההצפנה אובדת. הגישה ניתנת לפי תפקידים: מהנדס תפעול רואה את הגיבויים אך לא את המפתחות, והשחזור דורש אישור נפרד.
אנו מגדירים בהכרח גיבוי של המפתחות עצמם והליך סבב החלפתם, מכיוון שאובדן מפתח משמעו אובדן כל העותקים המוצפנים. סיכון זה אנו סוגרים בשלב התכנון, ולא לאחר תקלה.
תארו את סכמת הגיבוי הנוכחית שלכם — נחזור עם הערכה ותוכנית כיצד לשלב הצפנה בלי לעצור תהליכים.
נדון במשימה שלכם להגנה על גיבויים
הצפנת גיבויים היא משימה שבה מחיר הטעות מתגלה לא ברגע ההגדרה, אלא בשעת השחזור: מפתח שגוי, גישה שאבדה או פורמט ארכיון לא תואם הופכים את הגיבויים לאוסף חסר תועלת של בתים.
לכן אנחנו מתחילים לא מבחירת כלי, אלא מניתוח התשתית שלכם: מה ולאן מגובה, למי יש גישה, מהן הדרישות לגבי תקופות שמירה ושחזור.
כדי שההערכה והתוכנית יהיו מציאותיות, אנחנו צריכים להבין את המצב הנוכחי. תארו את המשימה — מקורות הנתונים, יעדי האחסון, אופן הפעולה של המערכות, המגבלות על חלונות הגיבוי. זה מספיק כדי לחזור עם הצעה קונקרטית לארכיטקטורת הגנת הגיבויים.
מה תקבלו בסופו של דבר:
- תרשים הצפנה: היכן בדיוק מיושמת ההגנה — בצד המקור, בזמן ההעברה או באחסון.
- מדיניות ניהול מפתחות: היכן הם נשמרים, למי יש גישה, כיצד מתבצעת רוטציה ומה קורה בעת חשיפה.
- קונפיגורציות עבור הסטאק שלכם — הצפנה בזמן העברה ובזמן אחסון, עם בדיקה בשחזור ניסיוני.
- נהל שחזור: סדר פעולות שלב אחר שלב עם פענוח ובדיקת שלמות הנתונים.
- תיעוד עבור הצוות: הנחיות לעבודה עם מפתחות, הסלמת אירועים ובדיקות מתוכננות.
- תוכנית יישום עם שלבים, תחומי אחריות וקריטריוני מוכנות בכל שלב.
אנחנו לא מוכרים פתרון מוכן — אנחנו מנתחים את המצב שלכם ומציעים את מה שיכסה את הסיכונים בלי מורכבות מיותרת. נדון במשימה: ספרו כיצד מאורגן כעת הגיבוי ומה מעורר דאגה. נחזור עם הערכת לוחות זמנים, תוכנית עבודה והבנה אילו צעדים יידרשו מצדכם.