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

בדרך כלל, חוסר תשומת הלב להגנה על נתונים מלווה בהנחה שגיבוי הנתונים ינוהל על ידי מחלקת ה-IT. זה בדרך כלל נכון ככל שזה מגיע. אבל לפעמים זה לא מגיע מספיק רחוק. 

בדרך כלל במקרים אלה, ה-IT יספק את רמת ההגנה הסטנדרטית שלו, שברוב המקרים פירושו גיבוי הנתונים באמצעות גיבוי מסורתי אחת ל-24 שעות. 

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

בדרך כלל, חוסר תשומת הלב להגנה על נתונים מלווה בהנחה שגיבוי הנתונים ינוהל על ידי מחלקת ה-IT. זה בדרך כלל נכון ככל שזה מגיע. אבל לפעמים זה לא מגיע מספיק רחוק. 

בדרך כלל במקרים אלה, ה-IT יספק את רמת ההגנה הסטנדרטית שלו, שברוב המקרים פירושו גיבוי הנתונים באמצעות גיבוי מסורתי אחת ל-24 שעות. 

זה בסדר אם תדירות הגיבוי הזו מתאימה. אבל מה קורה אם אובדן נתונים של 24 שעות עבורה ייצור בעיה רצינית עבור החברה? 

בדרך כלל מתעלמים משני עניינים חיוניים במצבים כמו זה שתואר לעיל: קביעת רמת ההגנה המתאימה לנתונים המשויכים והבטחה שרמת ההגנה הזו מיושמת.

פגיעויות שעלולות להיות יקרות

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

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

דמיינו את ההשפעה על בנק שאיבד לצמיתות נתונים של שמונה שעות על ההפקדות, המשיכות וההעברות של לקוחותיו. 

כעת, דמיינו אובדן מקביל של מידע בארגון שלכם.

ברור שזהו תרחיש שעדיף להימנע ממנו, והדרך להימנע ממנו היא לזהות ולסגור פערים בתוכנית הגנת הנתונים של הארגון שלך.

בניית מדיניות הגנת מידע

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

מדיניות כזו צריכה להכיל את הדברים הבאים:

דרישה שלכל סביבת ייצור תהיה גיבוי מינימלי יומי. זהו המינימום המוגדר כברירת מחדל; ייתכן שיהיה צורך לגבות בסביבות מסוימות בתדירות גבוהה יותר כפי שמוסבר להלן. 

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

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

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

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

תהליך המפרט כיצד יטופלו חריגים. חריג פירושו מצב שבו לא ניתן מיידית להגן על הנתונים או הסביבה בתדירות גבוהה כפי שה-RPO דורש. הסיבות הרגילות לכך שיש צורך בחריגות הן עלות או חוסר יכולת טכנית. יש לעקוב ולציין חריגים כאלה, כאשר ההנהלה הבכירה חותמת על מתן החריג. תהליך החריגה עשוי להגדיר תוכנית לסגירת הפער וביטול הצורך בחריג בתוך מסגרת זמן כמו שישה חודשים. ייתכן שהגישה תצטרך להיות מדורגת, בהתאם לאופי הפער. גם מחלקת ה-IT וגם המחלקה העסקית שבבעלותה הנתונים צריכים להיות מעורבים בתהליך החריגות של אפליקציה נתונה. 

הגן על הארגון שלך על ידי הגנה על נתונים

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

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