בשנים האחרונות בנק הפועלים החל בתהליך של הקמת סביבה מאובטחת בענן הציבורי ומיגרציה של מערכות מהרשת הארגונית לענן הציבורי. מדובר באתגר משמעותי וגדול בתחום אבטחת המידע, בעיקר בארגון כמו בנק. חלק מהנושאים והתובנות שלמדנו מהתהליך מובאים במאמר זה.
נתחיל במושג "ענן". מושג זה עלול להטעות. הוא מקנה תחושה של אזור בטוח ומוגן, שניתן לסמוך עליו בלי כל מאמץ. ניתן לטעות בקלות ולחשוב שהמידע שאגור בו הוא באחריות גורם אחר, אך אחת האמרות המפורסמות באבטחת מידע, שהופיעה כשטכנולוגיית הענן פרצה לחיינו, היא ש"אין דבר כזה ענן, אלא מחשבים של מישהו אחר".
האמירה הזו מזכירה לנו שבענן יש לנו אחריות אפילו גדולה יותר להגן על המידע ועל המערכות שלנו. השליטה שלנו בענן קטנה יותר לעומת הרשת הארגונית, ולכן תפקידנו לדאוג שהמידע העובר לענן יהיה מוגן, לפחות כמו ברשת הארגונית ואף יותר. באופן הזה, המשימה הופכת הרבה יותר מורכבת.
הבעיה היא תפיסתית
ארגונים רבים - גדולים ובינוניים - הגיעו למסקנה שלא ניתן להשיג ברשת הארגונית את אותן יכולות שהענן מספק. גם ארגונים שעד לא מזמן נטו לדחות את ההחלטה לעבור לענן (ארגונים רפואיים, ביטחוניים ופיננסיים) הבינו שאין מנוס מהמעבר. יש לכך מספר סיבות:
* העבודה בענן מאפשרת הקמה של מערכות בצורה מהירה וגמישה יותר מאשר ברשת ארגונית.
* בענן אפשר להקים מערכות עם כוח מחשוב גדול, בהן ניתן להקטין ולהגדיל את כוח המחשוב לפי הצורך.
* ההקמה עצמה יכולה להתבצע באמצעות שורות קוד, בשילוב תהליכי CI/CD.
* את הקוד הקיים ניתן ליישם במספר סביבות שונות ולייצר תאימות בין הסביבות השונות.
* העבודה בענן מאפשרת יכולת ביזור רחבה, שמתפרסת על כל העולם.
* ברוב חדרי השרתים המסורתיים, נמצאים שרתים עם ניצולת נמוכה, שגורמים לבזבוז משאבים.
אז מדוע האתגר כל כך גדול?
ייתכן שהבעיה היא תפיסתית. כשארגונים עברו מחדר שרתים אחד למשנהו, הם העבירו את השרתים כפי שהם. היו מספר התאמות של כתובות והגדרות רשת, אבל העקרונות נשארו ללא שינוי. המעבר לענן הוא סיפור אחר. כדי לעבור לענן נדרש להבין מהו הענן שאליו עוברים, מה החלקים המרכיבים אותו ואיך חיים במרחב החדש הזה.
המלכודת הכי נפוצה במעבר לענן היא Lift And Shift. כלומר, כמו שהעברנו מחדר שרתים אחד לשני, נעביר לענן, ללא שינוי מהותי. בגישה זו המעבר קל. ניתן להקים רשת פרטית, לבצע תהליך מיגרציה לשרתים בענן ובכך הארגון יכול להכריז שהוא "עבר לענן". בגישה הזו טמונות מספר בעיות:
* מפספסים את היתרונות של עבודה בענן, כי הארגון נשאר עם שרתים שכוח העיבוד שלהם לא מנוצל בצורה אופטימלית.
* הענן מציע שירותים ללא שרתים המאפשרים ארכיטקטורה בצורת Event Driven Architecture המאפשרת עבודה אפקטיבית ויעילה.
* התשלום על שרתים בענן הוא יקר.
התאמה של העקרונות ודרכי היישום
הדרך הרצויה היא לעבור באופן מותאם לשירותים שהענן מספק (שירותי קוד, שירותי תשתית מנוהלים וכדומה).
גם באבטחת מידע יש נטייה לבצע מעבר בצורה של Lift And Shift (כלומר, לראות את הענן כמו הרשת הארגונית). גם פה הגישה יכולה להיות בעייתית, כי הענן הוא לא הרשת הארגונית שרגילים אליה, והעקרונות שהיינו רגילים ליישם בה לא תמיד מתאימים.
הענן מספק כלים שונים להגנה, אך לעיתים הם אינם מקבילים למה שקיים ברשת הארגונית. גם פה נדרשת התאמה של העקרונות ודרכי היישום, תוך שימוש ביכולות הענן בתחום אבטחת מידע, כדי לספק הגנה טובה לא פחות מהרשת הארגונית.
ספקיות הענן מתארות בפירוט את הדרכים ליישם ארכיטקטורה נכונה ומאובטחת (לדוגמה, ב-AWS יש את ה-Well-Architected Framework). נדון כאן במספר עקרונות להגנה הרלוונטיים גם למערכות ענן אחרות:
מנגנון זהויות חזק
מנגנון ההזדהות לענן הינו אחד המקומות הרגישים והחשובים. קל מאוד לטעות ולייצר דרכי הזדהות שיגרמו ל-Shadow IT, או שידלפו לעולם. מכאן הדרך לאירוע אבטחת מידע קצרה. אם מסתכלים על היסטוריית אירועי אבטחת מידע בענן, רואים שאזור זה הוא פגיע במיוחד. מימוש לא נכון באזור זה גרם ללא מעט אירועים, ולכן, יש לייצר מנגנון הזדהות חזק.
הנה מספר דוגמאות להתנהלות נכונה:
* ברוב המקרים ההמלצה היא לעבוד עם ה—IDP הארגוני, ולממש SSO אל מול הענן, ללא שימוש במשתמשים מקומיים.
* עבודה עם זהויות זמניות ככל שניתן עם מינימום הרשאות.
* ניטור המשתמשים החזקים, ניטור משתמשים ללא שימוש או עם הרשאות ללא שימוש.
כשמקימים חשבון ב-AWS נוצר משתמש ROOT חזק מאוד, שיכול לעשות כל פעולה בחשבון. אם יש לארגון עשרות או מאות חשבונות, נוצר אתגר ניהולי לא קטן. לכן, מומלץ להשתמש במשתמש מסוג זה באופן מצומצם ועל-פי צורך, להגדיר MFA למשתמש ה-ROOT, ולא לייצר חיבור באמצעות CLI למשתמש הזה. חשוב מאוד לנטר את פעולות המשתמש ואת הפעולות שלו.
הגנה בשכבות (Defense In Depth)
עקרון אבטחת מידע זה חל גם על הרשת הארגונית וגם על הענן. בעוד שברשת הארגונית ישנה גם ההגנה הפיזית, בענן ישנן מספר שכבות שניתן ליישם בהן את העקרון של ההגנה בשכבות. למשל, הגנה על ה-Perimeter, מערכות הפעלה, אפליקציות, מערכת ההזדהות והנתונים עצמם. עיקרון זה חשוב בענן, כי קיים סיכון גדול של Misconfiguration, ולכן לא מומלץ להסתמך על בקרה אחת בלבד.
ניטור והתראות
ניטור של פעולות ושינויים מהווה מרכיב חשוב בהגנה על הענן, מכיוון שכמות הפעולות והשינויים בו היא גדולה ומשפיעה על הסביבה בצורה משמעותית. הענן נותן כלים ליישם ניטור במגוון דרכים, ומאפשר חיבור למוצרי ניטור בתוך הארגון או בענן אחר, לצורך ניתוח והגדרת התראות.
אוטומציה
אחד היתרונות הגדולים בענן הוא שניתן ליישם את כל הרכיבים וההגדרות באמצעות קוד (IaC). המשמעות היא שכמו בפיתוח תוכנה, ניתן לסרוק את הקוד כבר בסביבת ה-IDE של המפתח/DevOps ולזהות Misconfiguration. יתרון נוסף הינו יישום הקוד באמצעות PIPLINE, שכולל סריקות ואישורים של גורמים נוספים עד ליישום בסביבות השונות. צורת עבודה זו מיישמת את העקרון של Shift Left ומאפשרת לחסוך זמן רב ומשאבים בהמשך הדרך.
הגנה על המידע
הגנה על המידע בתנועה או במנוחה כוללת את קטלוג המידע לפי רגישותו, כך שיאפשר הגנה מותאמת. הבקרות יכולות לכלול הצפנת מידע, ניהול המפתחות, ניהול ההרשאות באמצעות שמירה על עקרון "הצורך לדעת", הרחקת האנשים מהמידע הייצורי ככל שניתן ושימוש בתהליכי אוטומציה.
Incident Response
מכיוון שהסביבה בענן שונה מהסביבה ברשת הארגונית, יש חשיבות גדולה בתכנון מפורט לגבי זיהוי אירועי אבטחת מידע ותגובה. הענן מספק שירותים שונים לצורך זיהוי של אירוע ויכולת תגובה בעת הצורך. מדובר בתוכנית רחבה הכוללת השתתפות של נושאי תפקיד שונים בארגון ומגוון רחב של פעולות בכל אחד משלבי התוכנית. כדי לדעת אם התוכנית אפקטיבית, נדרש ליישם תרגול אחת לפרק זמן כדי ללמוד וליישם שיפור מתמיד.
המעבר לענן והעבודה בו דומה לעבודה של תזמורת. אם הכלים לא מסונכרנים יש רעש גדול וההתקדמות קשה. השותפים לתהליך הם גורמים שונים בארגון שצריכים לדעת לעבוד ביחד, להעשיר אחד את השני ולעבוד עבור מטרה משותפת. זהו הבסיס להצלחת התהליך כולו.
הכותב הוא ארכיטקט אבטחת מידע בחטיבת הטכנולוגיה והמחשוב בבנק הפועלים
לאתר >>> הטכנולוגית, בנק הפועלים
בשיתוף בנק הפועלים
