מפו סמכויות ולא רק שמות משתמשים
התחילו בנתונים הפעילים, מנגנון הגיבוי, יעד האחסון, חשבון החיוב וערוצי השחזור. רשמו גם מי מנהל את הדואר שאליו נשלח איפוס סיסמה. שני חשבונות עם אותו נתיב שחזור עלולים להישאר תלויים באותה נקודת כשל.
הפרידו בין אדם, חשבון שירות ומנהל בעל סמכות גבוהה. סיסמה אחרת לאותה הרשאת-על אינה בהכרח הפרדה מספקת. גם תהליך אוטומטי שעובד בשם עובד שעזב דורש בירור לפני שינוי; ביטולו ללא מיפוי יכול לעצור גיבויים חדשים.
בנו מטריצת הרשאות לכל פעולה
הטבלה מציעה שאלות לבחינה במוצר שלכם. אין להניח שכל ספק מאפשר את אותה חלוקת תפקידים. אם אין תפקיד מצומצם מתאים, תעדו את המגבלה ואת הבקרה המשלימה במקום להצהיר שהושגה הפרדה מלאה.
| תפקיד | יכולת נחוצה לבדיקה | יכולת שיש לברר בנפרד |
|---|---|---|
| תהליך גיבוי | כתיבת העותק הנדרש | מחיקת היסטוריה ושינוי שמירה |
| מבצע שחזור | קריאת העותק המאושר ליעד מתאים | שינוי כל החשבונות וההרשאות |
| מנהל מדיניות | אישור תצורת שמירה | עקיפה או ביטול נעילה |
| בעל העסק | שליטה בבעלות ובתהליך חירום | גישה שוטפת לסודות של כל מערכת |
חזקו את דרך הניהול ואת השחזור החלופי
הגנו על חשבונות ניהול באמצעי אימות נתמכים, בדקו הרשאות מזעריות והגדירו מי רשאי לאשר שינוי רגיש. מסלול גישה חלופי צריך להיות מוגן ומתועד בלי לפרסם קודים או מפתחות במסמך העבודה. אם האחראי אינו זמין, העסק צריך לדעת למי לפנות ואיזה אישור נדרש.
כספת, דואר וספק זהות הם תלויות בפני עצמם. אל תאחסנו את פרטי השחזור היחידים בתוך אותה מערכת שזמינותה נבדקת. אין משמעות להפרדה שמונעת גם מהגורם המורשה להתאושש בשעת תקלה.
בדקו מחיקה והגנות על נתוני ניסיון בלבד
קראו את התפקידים והמדיניות, ובמידת האפשר צרו ניסוי עם אובייקט מלאכותי וחשבון מוגבל. בדקו כתיבה נדרשת ומניעת פעולה שאינה מורשית, בלי לנסות למחוק היסטוריית גיבוי אמיתית. הגדרה במסך אינה מספיקה אם איש לא בחן איזו מדיניות חלה על הנתון בפועל.
יש מוצרים שמוסיפים אישור או אימות לפעולות קריטיות. לדוגמה, Microsoft מתעדת הגנות מסוימות לגיבויים היברידיים ב-Azure עם תחולה מפורשת למוצרים ולגרסאות. זו דוגמה לתלות ביישום; אין להעתיק את היכולת לכל גיבוי בענן או להניח שהיא הופעלה בחשבון שלכם.
דוגמה: חשבון האחסון מנהל גם את העותקים
זו המחשה ולא מקרה לקוח. באתר נשמרים גיבויים אצל ספק האחסון, ואותו חשבון יכול למחוק את האתר ואת ההיסטוריה. האחראי ממפה את היכולת, בודק יעד נוסף ובעלות, ומוודא שאפשר לקרוא עותק משם באמצעות מסלול מורשה גם כשהאחסון הראשי אינו זמין.
הפתרון נבחר לאחר בדיקת כיסוי ועלויות, לא רק על ידי שינוי שם התיקייה. אם עדיין יש מנהל שיכול למחוק את שתי הסביבות, מתעדים זאת. הגנה מפני שינוי, שמירת גרסאות והפרדת זהויות יכולות להשלים זו את זו, אבל אף תווית אינה הוכחה לעותק נקי ומלא.
השאירו רישום שינוי ובדיקת תפקוד
לאחר שינוי הרשאות בדקו שגיבוי חדש עדיין נוצר, שניתן לקרוא עותק מאושר ושמסלול השחזור לא נפגע. לפני החלפת מפתח או הסרת ספק, זהו את כל התהליכים המשתמשים בו. בצעו שינוי בהיקף מתואם ואל תשתפו סודות בהודעת הפנייה.
רשומת המסירה צריכה לציין חשבונות ותפקידים, הרשאות לפני ואחרי, תוצאת בדיקה ומגבלות שנותרו. קבעו בחינה בעת עזיבת עובד, החלפת ספק, שינוי זהות או חיבור יעד נוסף. אם יש חשד לחשבון שנפרץ, צריך לתאם תגובה לאירוע ולא להסתפק בביקורת הרשאות מחזורית.



