תורת הגנת הסייבר בענן – הקדמה

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

ישנם הבדלים רבים בין יישום שירותי הענן השונים של Microsoft עם שירותי הענן הספציפיים של Azure ושל Office 365 לבין שירותי הענן של וונדורים אחרים כדוגמת שירותי הענן של AWS ושל Google. במידה מסוימת ישנה מדיניות ודרישות התואמת לכלל הוונדורים אשר מספקים שירותי ענן.

המאמר הנוכחי מתמקד באופן כללי באבטחת מידע בענן מול שירות Office 365 תוך כדי שילוב של יכולות אבטחה מבוססות Microsoft.

מדיניות אבטחת מידע בענן

כאשר עולים לענן של Microsoft בין אם זה לשירות מסוים של Office 365 כגון Exchange Online או לכל שירות אחר, האינטגרציה הראשונית היא אינטגרציה של תשתית Active Directory מקומי מול תשתית זהויות של Azure AD או מול תשתית זהויות אחרת.

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

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

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

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

דרישות אבטחה מידע בענן

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

אלה הם הדרישות הבסיסיות לחיבור מול שירות Office 365.

תקשורת

הרובד הראשון הנדרש בענן הוא תקשורת בין הסביבה המקומית לבין סביבת הענן,ולכן נדרש חיבור פרטי, כדוגמת Azure Express Route המספק חיבור פרטי בלבד בין הסביבה המקומית של הארגון לבין סביבת Azure במטרה לאפשר חיבור פרטי לא על קווי האינטרנט הרגילים (Public Connection).

בתרחיש של Azure Express Route האינטגרציה והחיבור בין התשתית המקומית לבין תשתית הענן נעשית בצורה מאובטחת ומספקת רובד ברמת Layer 2 או Layer 3 (תלוי הגדרה).

הקשחות

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

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

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

יישום הקשחות נעשה לפי שני מודלים:

  • הקשחת Office 365 – במידה ושירות Office 365 מוגדר מבצעים הקשחת רכיבים וכלים שאינם נמצאים בשימוש או צריכה של המשתמשים לפי קטגוריות של דלף מידע, גישה למידע, הרשאות וכן הלאה. הקשחות אלה נעשות לפי המלצות של Office 365 Security Risk Assessment.
  • הקשחת Azure – שירות Azure פעיל ולכן מומלץ לבצע הקשחה ראשונית לפי ניהול חשבונות משתמשים ואופן חלוקת Subscriptions, כאשר כל חשבון מקבל את ההרשאה הנדרשת לטובת יצירת Subscriptions ייעודי. בשלב שני מיושם מבצעים הקשחה לפי זהויות (על סמך ניהול זהויות) , הקשחת רכיבי תקשורת ורכיבים ברמת IaaS, ניהול המלצות לפי Azure Security Center (ישנו Secure Score ייעודי בנוסף אשר יכול לסייע).

ניהול זהויות

השלב הראשון בניהול זהויות הוא ליצורתצורה היברידית של זהויות בין תשתית Active Directory מקומי לבין תשתית זהויות בענן, למשל תצורה של Azure AD Hybrid המאפשרת בשלב זה לחבר תשתית Active Directory מקומית מול תשתית Azure AD לפי הדגשים הבאים:

  • ביצוע הכנות לתשתית היברידית אשר כוללות הגדרת Azure AD, הגדרת אובייקטים ייעודיים, הגדרה והקשחת אובייקטים ספציפיים (Service Account) לביצוע סנכרון יומיומי, ניטור אובייקטים ספציפיים, סנכרון אובייקטים לפי ערכים מסוימים, סנכרון אובייקטים ספציפיים וכן האלה.
  • הגדרת תשתית Azure AD Hybrid – הגדרת תשתית Azure AD Hybrid מול תשתית Active Directory מקומית על סמך הכנות, וכן ביצוע הכנות לביצוע הזדהות חזקה שכולל בין היתר הגנה מפני מתקפות שונות, כגון Password Spray וכן הגדרת Multi Factor Authentication.
  • יישום הגנה מתקדמת בין תשתית Active Directory מקומית מול Azure AD מול זהויות במטרה לתייג סיכונים וביצוע פעולות מנע מול כל סיכון נדרש. סיכונים אלה יכולים להיות בין היתר על בסיס התנהגות חשודה, מיקומים בסיכון, גישה למידע.
  • הגנה נוספת של שילוב תשתית Azure AD Identity Protection לבין תשתית הגנה של Active Directory מקומית (AD Protect) במטרה לתת מענה המבוסס על Kill Chain ותרחישי התקפה נפוצים.
  • חסימת גישה לפי שירות ע"י פוליסי מבוסס תנאים במטרה לתת למשתמשי קצה גישה למשאבים נדרשים בלבד.

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

מעקב וניטור המידע

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

היכולת של Cloud App Security מאפשר אינטגרציה של ניהול הזהויות מתוך Azure AD ושילוב מול רכיבים הקיימים בשירות Azure, בנוסף לכך ניתן להעביר לוגים מתוך Cloud App Security אל SIEM ארגוני במטרה לעקוב מתוך SOC קיים.

ארכיקטורה אבטחת מידע

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

בקרות הגנה

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

  • הגדרת פוטנציאל הנזק – ביצוע מיפוי של מהו מידע חשוב ורגיש לפי פוטנציאל הנזק שעלול היגרם לפי נמוך, בינוני, גבוה וקריטי.
  • הגנה על סמך פוטנציאל הנזק – הגנה על נכס ומידע תבוצע בהתאם לרמת הקריטיות שלו לתפקוד הארגון ולפי מיפוי של פוטנציאל הנזק.
  • הגנה פרואקטיבית – הגדרת בקרות הגנה עבור שלבי המניעה, הזיהוי והתגובה והחזרה לשגרה לפי תהליכים ונהלים (framework).
  • הגנה רב מימדית – ביצוע הגנה על המידע בענן לפי תהליך המשלב שלושה נקודות עיקריות: משתמשים ,טכנולוגיה ותהליכים.
  • ניתוח איומים – בביצוע הביקורת חשוב לנתח את תסריטי האיום הרלוונטיים לסביבת העבודה בענן ולבחון באופן שוטף את יעילותן של הבקרות.
  • מדיניות ובקרות –במסגרת הביקורת יש לוודא כיצד נבחרת מערכת בענן, על פי אילו מדדים, מי רשאי לאשר, וכיצד.
  • משפחת בקרות – אחריות דירקטוריון והנהלה – ניהול סיכונים והערכת סיכונים – בקרה, ביקורת ותאימות
  • תפקידים ואחריות – במסגרת הביקורת חשוב לוודא כי הוגדרה האחריות לניהול סיכוני הענן, כחלק מביקורת פנימית יש לבחון מעורבות ואחריות של ההנהלה בתהליכים.
  • הגדרת דרישות למערכת – במסגרת הביקורת יש לוודא כי בעת פיתוח ו/או רכישה של מערכת הוגדרו דרישות אבטחת המידע הרלוונטיות, לרבות התייחסות לנושאים כגון שמירה על פרטיות המשתמשים, שמירה על חיסיון הנתונים, שמירה על שלמות המידע, שמירה על אמינות המידע, שמירה על זמינות המערכת, שמירה על שלמות תהליכים עסקיים, ממשקים עם מערכות חיצוניות, ועוד.
  • יישום המערכת – כחלק מתהליכי העבודה יש להקפיד על כתיבת קוד בהתאם לכללי פיתוח מאובטח. כמו כן, יש לבצע סקר קוד (Code Review) על מנת לוודא את יישום דרישות אבטחת המידע. ניתן לעשות זאת תוך שימוש בכלים אוטומטיים כגון Static Code Analyzer.
  • בדיקות – יש לדאוג כי פיתוח ויישום בדיקות יכללו את כל היבטי אבטחת המידע. במסגרת ביצוע הביקורת ניתן לערוך בדיקות המתייחסות לבקרה אחר שלמות ביצוע הבדיקות תוך שימוש ברשימות תיוג מובנות וכו'.
  • בחינות חדירות – הואיל וכל מערכות הענן חשופות לרשת, לפני יישום מערכת חדשה חשוב לקיים מבדקי חדירות (Penetration Test).
  • הקשחת סביבת המערכת – מלבד האפליקציה עצמה, כל מערכת מידע כוללת רכיבי תוכנה וחומרה נוספים כגון מערכות הפעלה, בסיסי נתונים וכדומה. יש לוודא כי כל רכיבי המערכת מוקשחים בצורה מיטבית.
  • תחזוקה של המערכת – לאחר שהמערכת פועלת בסביבת הייצור יש לדאוג לבצע עדכוני אבטחת מידע שוטפים לתשתית המערכת (Security Patches).
  • ניהול נכסים ותצורה – חשוב לעקוב אחר הנכסים הנוכחיים ולבדוק כיצד הם מוגנים.
  • אבטחה ותשתיות פיזיות – יש לוודא כי המיקום הפיזי אינו באזור בסיכון גבוה וכי קיימות בקרות פיזיות מספקות, כגון גדרות, מצלמות, חיישני תנועה, בקרת אש, אספקת חשמל, דלק, מיזוג וכדומה, וכן יכולת גיבוי.
  • ניהול משתמשים והרשאות – יש להקפיד על ניהול הרשאות הגישה של העובדים למערכות ולנתונים בכל הרמות – התשתית, מערכות ההפעלה, ציוד התקשורת והאפליקציות. ניתן לבחון במסגרת הביקורת את מדיניות ההרשאות ויישומה, תדירות עדכון הסיסמאות ואת הבקרה השוטפת הקיימת אחר פעולות חריגות במערכות.
  • טיפול ותחזוקה בציוד – בעת ביצוע הביקורת ניתן לבחון האם וכיצד מבוצעת התחזוקה השוטפת של הציוד והאם היא עומדת בהנחיות היצרנים.
  • המשכיות עסקית – קיום תכנית לטיפול באירועי חירום, לרבות תיעוד מסודר ותרגול.
  • ניהול אירועים – ניהול האירועים בענן יכלול את כל האלמנטים של ניהול אירועים בסביבות האחרות, לרבות הגדרת הסיכונים ותרחישי הסיכון, הגדרת תגובות לתסריטים ידועים, זיהוי וניתוח של האירועים, ניתוח האירועים, החלת האירוע, סיום האירוע, הפקת לקחים.

דרכי גישה למידע

  • גישה מבוססת על סמך ניהול זהויות – ניהול שירותי הענן ייעשה ע"י סגרגרציה של חשבונות בעלי הרשאות לפי מנגנון Azure PIM ועל סמך מסמך RACI וכל חשבון העל הרשאות יחויב במאפיינים הבאים:
    • הרשאה לפי תפקיד וגישה למקורות מידע מוגדרים מראש
    • אימות מבוסס תנאים לפי פוליסי שכולל Azure MFA, Conditional Access
    • במקרים של חשבונות רגישים במיוחד ניתן לשלב אימות MFA מבוסס חומרה
  • גישה למשאבים בענן לפי הרשאות – גישה של משתמשי קצה תבוצע על הדגשים הבאים:
    • גישה למשאבים נדרשים על גבי תשתית Azure Express Route
    • משתמשים שאינם מסונכרנים אינם יכולו לגשת למשאבי ענן
    • גישה למשאבים לפי הרשאות משתמש, לדוגמא חיבור RDP לפי כתובות או Windows Hello
    • ניהול הקצאת משאבים (ליצירה וצריכה של משאבים) לפי הרשאות משתמש
  • גישה לפי מיקום – גישה של משתמשים תעשה לפי מיקום וע"פ העקרונות הבאים:
    • הגדרת מיקומים פיסיים של עפ"י Trusted location
    • הגדרת גישה המבוססת על סמך מיקום בלבד
    • התניית גישה ליישומים שונים ולפי קבוצות נדרשות לפי מיקום

לסיכום

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

מה דעתך?

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