איך אפשר למנוע זליגת מידע?

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

אחד מההיבטים החשובים באבטחת המחשבים והרשתות הוא השמירה על המידע הרגיש לא נגיש לצדדים שלישיים לא מורשים. במסמך הזה נפרט מהן הסכנות לזליגת מידע ונדון בשיטות מומלצות בתחום לאבטחת מידע. נסביר איך להשתמש בכלים ובפיצ'רים של Google Cloud כדי למזער את הסיכונים, לזהות זליגת מידע ולטפל באירועי זליגה. נשתדל לתאר ככל שאפשר את איומי האבטחה ואת הגישות להגנה בהקשר שאינו תלוי בענן. הסביבה הרגולטורית ההולכת ומתפתחת, ובמיוחד התקנה הכללית להגנה על מידע (GDPR) באירופה – שהפכה לחובה ב-2018, מדגישה בדרכים חדשות את הצורך להשתמש במנגנונים למניעה של זליגת מידע.

ההגדרה של זליגת מידע

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

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

איך מתמודדים עם זליגת מידע בענן?

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

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

במודל האבטחה של הענן הציבורי משתמשים בגישה כזו כדי לתת מענה גם ללקוחות שהכי מודעים לאבטחה. ב-Google Cloud אנחנו משתמשים בעיקרון של מכונות וירטואליות (VM) מוגנות כדי לאמת את התקינות של המכונות הווירטואליות של Compute Engine, ולתת לכם שקט נפשי בידיעה שתוכנות זדוניות ברמת ה-boot או הליבה לא מסכנות את המכונות שלכם. התקינות של המכונות הווירטואליות המוגנות מאומתת באמצעות הפעלה מאובטחת, אתחול מדוד מבוסס-vTPM וניטור של התקינות.

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

הספקים גם מגדירים צווארי בקבוק מפורשים, כמו יעד מבוצר (bastion host), לתקשורת עם Fleet של מכונות וירטואליות, שרתי proxy של רשתות, שרתי תעבורת נתונים יוצאת (egress) ברשתות ורשתות בין פרויקטים. אמצעי האבטחה האלה יכולים לצמצם את הסיכונים של זליגת מידע, אבל לא למנוע אותה לחלוטין.

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

קטגוריות של אירועי זליגת מידע

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

תקשורת יוצאת

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

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

מניעה וצמצום הפגיעה

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

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

  • לעקוב אחרי נפח הנתונים שהמשתמשים מעבירים ואחרי תדירות ההעברה באימייל ובכלים אחרים להעברת הודעות שקיימים בארגון. אם המשתמש הממוצע שולח 5 מגה-בייט של נתונים בממוצע ליום, השליחה של 500 מגה-בייט צריכה להפעיל התראה.
  • לשמור יומן עם תיעוד של הכתובות שמשמשות לשליחת אימיילים, המכשירים שמהם האימיילים נשלחים והכתובות של הנמענים. הפרטים האלה יעזרו לכם לזהות את המקור וההיקף של אירועי זליגת המידע. ברשימת משימות האבטחה לאדמינים מוסבר איך בודקים סיכוני אבטחה בחשבונות אימייל בגרסה העסקית של Gmail.
  • לסרוק אימיילים שנשלחים ממערכות עם גישה למידע רגיש, כדי לוודא שהם לא מכילים תוכן לא מורשה. אפשר לפשט את תהליך הסריקה על ידי תיוג תוכן רגיש באמצעות סמנים כמו מילות מפתח או מחרוזות גיבוב (hash).
  • למנוע את היכולת לשלוח הודעות בערוצים לא מאובטחים, כמו שימוש ב-http במקום ב-https, ולוודא שצוות אבטחת המידע מקבל התראות בכל ניסיון כזה.

הורדה למכשירים לא מאובטחים

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

מניעה וצמצום הפגיעה

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

תוכלו להשתמש בחלק מהשיטות וכללי המדיניות הבאים:

  • לאסור הורדה של מידע רגיש מאוד. בהתאם לאופן שבו משתמשים במידע שלכם ומעבדים אותו בענן, יכול להיות שהמשתמשים בכלל לא יצטרכו להוריד את המידע לחומרה מקומית. אם אפשר, כדאי לשמור את כל המידע בענן ולבצע את כל פעולות המחשוב בענן. אם טכנית ניתן להוריד מידע, כדאי להשתמש במדיניות שאוסרת על הורדות, לסווג ולתייג את המידע הרגיש ולשמור יומני גישה למידע שמתקבל ונשלח באמצעות אינטראקציות מאובטחות וקריאות ל-API. במסמך בנושא יומני ביקורת תוכלו לקרוא מידע נוסף.
  • להשתמש במתווך מבוסס-ענן לאבטחת גישה (CASB) כדי לפקח על החיבורים בין לקוחות מורשים לשירותי הענן בהתאם למדיניות האבטחה של הארגון.
  • להגן על הקבצים באמצעות כלים לניהול זכויות דיגיטלי (DRM). באמצעות הכלים האלה תוכלו להוסיף לכל קובץ שכבת הצפנה ואבטחה המבוססת על הרשאות.
  • להשתמש בסימני מים דינמיים בלקוחות המורשים כדי לתעד את המשתמש שאחראי לצילומי המסך או לתמונות של צגי המחשבים עם המידע הרגיש.

העלאה לשירותים חיצוניים

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

מניעה וצמצום הפגיעה

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

כדי למנוע זאת מומלץ להפעיל את אמצעי האבטחה הבאים:

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

התנהגות לא מאובטחת בענן

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

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

מניעה וצמצום הפגיעה

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

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

  • להגדיר טבלאות IP במכונות הווירטואליות, שאוסרות על חיבורים יוצאים לכתובות לא מוכרות. כך תוכלו להפחית את הסיכון שגורם יעביר מידע רגיש אל מחוץ לרשת.
  • לא למסור כתובות IP ציבוריות של מכונות וירטואליות, ולהשתמש בשירות של תרגום כתובות רשת (NAT) כדי לעבד חיבורים נכנסים ויוצאים. למידע נוסף, תוכלו לקרוא את המדריך להגדרת שער NAT ל-Compute Engine.
  • להשתמש ביעד מבוצר (bastion host) בענן כדי לתווך את החיבורים למארחים אחרים ולפקח עליהם.
  • להשבית תוכנות לניהול מרחוק, כמו סוכנים של Remote Desktop Protocol (‏RDP) או Windows Remote Management (‏WinRM), במכונות שבהן לא צריך אותן.
  • להפעיל מכונות וירטואליות (VM) ברשתות משנה באמצעות גישה פרטית ל-Google, כדי להגיע לשירותים ולממשקי ה-API של Google באמצעות כתובות IP פנימיות במקום כתובות IP חיצוניות.
  • להשתמש באפשרות של שיתוף רשתות בין פרויקטים (XPN) כדי לשתף את הרשתות הווירטואליות של Google Cloud בין הפרויקטים בארגון שלכם ב-Cloud.
  • להגביל אנשים שיש להם צורך קריטי והכרחי לגשת למכונות הווירטואליות, לגישת SSH ישירה. ל-Google Compute Engine יש כלים נרחבים לניהול מפתחות SSH שתוכלו להיעזר בהם לבקרת הגישה למכונות הווירטואליות.

בשירותי אחסון בענן כמו Cloud Storage או Cloud Bigtable, תוכלו להשתמש בשיטות הבאות כדי להפחית את הסכנה לזליגת מידע:

  • להשתמש בממשק של ניהול הזהויות והרשאות הגישה (IAM) כדי לתת למשתמשים ולאפליקציות את הרשאות הגישה המצומצמות ביותר למידע, בהתאם לצרכים שלהם. כדאי גם לאחסן מידע עם מידה שונה של רגישות ודרישות גישה בקונטיינרים שונים, כדי לתת הרשאות פרטניות ככל האפשר.
  • לעקוב אחרי קצב קריאת הנתונים ממשאבי האחסון שלכם ולהגביל אותו. תוכלו להשתמש בסוכני מעקב כדי שצוות האבטחה יקבל התראות בכל ניסיון להעביר יותר נתונים מהצפוי במקרי שימוש רגילים.
  • לתת הרשאות זמניות למידע רגיש מאוד, וגם לבדוק ולבטל את ההרשאות האלה לעתים קרובות. לדוגמה, תוכלו להשתמש במכסות ל-App Engine.
  • לבקש מצוות אנושי לבדוק באופן סדיר את האנשים שיש להם גישה לקונטיינרים שמכילים מידע רגיש מאוד.
  • לנהל ביומן רישום מקיף של כל הגישה לשירותי האחסון. במצב אידיאלי, כדאי להפריד בין האנשים שיש להם גישה לשירותי האחסון לבין האנשים שיש להם גישה ליומנים. כך תוכלו להפחית את הסיכון שגורם זדוני ישנה את היומנים. כדאי להשתמש בכלים של יומן הגישה ל-Cloud Storage כדי לכתוב את נתוני היומן בקטגוריית אחסון נפרדת.

אכיפת הציות למדיניות האבטחה

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

בזכות ההיררכיה של 'ארגון > תיקיה > פרויקט > שירות של Google Cloud > משאב', אפשר להגדיר את מדיניות האבטחה בכל אחת מהרמות כך שהיא תחול על כל הרמות שמתחתיה בהיררכיה. מדיניות האבטחה נבחנת מלמעלה למטה בהיררכיית המשאבים, וברגע שמתקבל "אישור", ניתנת גישה למשאב.

אכיפת הציות

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

זיהוי וצנזור של מידע רגיש

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

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

מניעה וצמצום הפגיעה

באמצעות הפיצ'ר 'מניעת אובדן נתונים' (DLP) של Google Cloud תוכלו להבין ולנהל מידע רגיש. בעזרתו תוכלו לסווג במהירות ובכל קנה מידה, וגם לצנזר אם צריך, כל מידע רגיש כמו מספרי כרטיסי אשראי, שמות, מספרי תעודות זהות, מספרי דרכונים, מספרי רישיונות נהיגה מקומיים ובינלאומיים ומספרי טלפון. תוכלו להשתמש ב-Cloud DLP לטקסט, לנתונים מובְנים ולתמונות – כל מה שצריך לעשות הוא להעביר את המידע ל-Cloud DLP או לציין איפה מאוחסן המידע במכונות של Cloud Storage, ‏Big Query ו-Datastore. תוכלו להיעזר בתוצרים של Cloud DLP כדי לעקוב אוטומטית אחרי ההגדרות של IAM, מיקום המידע וכללי מדיניות אחרים וגם לעדכן אותם אוטומטית. באמצעות Cloud DLP תוכלו לצנזר או לבצע התממה לחלקים מסוימים במידע, כדי להפחית את מידת הרגישות או להגביל את איסוף המידע כחלק ממדיניות של הרשאות מינימליות או של הגבלת הגישה רק למי שבאמת זקוק לה. תוכלו להשתמש בשיטות של התממת מידע, הצפנה תוך שמירה על הפורמט, שימוש באסימונים ובחלוקה לקטגוריות בנתונים מובְנים או בטקסטים חופשיים.

התנהגות זדונית של אדמינים

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

מניעה וצמצום הפגיעה

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

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

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

פיטורי עובדים

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

מניעה וצמצום הפגיעה

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

סיכום

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

  • מידור המידע, כדי למזער את "היקף הפגיעה" של זליגת המידע
  • יצירת יתירות ומערכת אישורים לתהליכי העבודה של האדמינים, כדי להגדיל את לקיחת האחריותיות
  • להשתמש בהרשאות פרטניות ולתת גישה למידע הרגיש רק למי שבאמת זקוקים לה מתוקף תפקידם
  • להשתמש במערכות של רישום ביומן כדי לשפר את היכולת לראות למי הייתה גישה ואת תנועת המידע בארגון
  • להגביל את תעבורת הנתונים הנכנסת (ingress) והיוצאת (egress) במכונות של הארגון ולפקח עליה באמצעות כללים ברשת, הממשק של ניהול הזהויות והרשאות הגישה (IAM) ויעדים מבוצרים (bastion hosts)
  • להגדיר ערכי בסיס לתעבורת נתונים רגילה, כמו כמויות נתונים שמקבלים אליהם גישה או מעבירים אותם, ומיקומים גיאוגרפיים של גישה, כדי שיהיה אפשר להשוות אליהם התנהגויות חריגות

השלבים הבאים