איך מיישמים Zero Trust
סוכר ומלח נראים אותו הדבר אז איך אפשר להבדיל בינהם? כך גם הגישה במודל Zero Trust, והאם אפשר לדעת ולבטוח במי שמתחבר לארגון וצורך מידע?
במאמרים האחרונים של Zero Trust התמקדתי במודלים, ארכיטקטורה, איפיון ועקרונות של Zero Trust ועל רבדיו השונים. קישור לכלל המאמרים בנושא:
מודל ואסטרטגית Zero Trust בסביבת Microsoft
המאמר הנוכחי יתמקד בדגשים, טיפים ואיך לבצע וליישם Zero Trust.
יישום Zero Trust
יישום Zero Trust נחלק למספר שלבים התלויים אחד בשני, ולמרות שכל שלב הוא רובד אבטחה בפני עצמו המטרה של Zero Trust היא לשלב בינהם בכדי לקבל אחידות, קורלציה בין המידע השונה של כל שלב ורובד אבטחה וכן האפשרות להגיב במקרה של בעיות אבטחה.
השלבים ביישום Zero Trust בסביבת Microsoft נחלקים לשלבים הבאים:
מיפוי שטח ההגנה הוא השלב הראשון בו אנו צריכים לדעת מהו המידע ומהם הנכסים החשובים בארגון ומהם האפליקציות שאיתם אני עובד, ולכן מומלץ לדרג את המידע לפי רגישות המידע, חשיבות וסיכון במקרה והמידע דולף.
בניית ארכיטקטורה מגיעה לאחר שיש לנו הבנה על הנכסים החשובים בארגון, ובשלב זה אנו בונים את שכבת ההגנה והרובדים הנדרשים בכדי להגן על המידע.
בשלב השלישי של ניהול זהויות וגישה אנו מתחילים לבנות מערך זהויות מבוסס Azure AD, החל מבנית תצורת Azure AD Hybrid לזהויות בלבד (עדיין לא מכונות) ולאחר מכן ממשיכים עם יישום כלי הגנה לזהויות, כמו, אכיפת MFA, יצירת תנאים (Conditional Access), מידול הרשאות ואוטוריזציה לחשבונות רגישים.
לאחר יישום זהויות אנו ממשיכים לשלב הרביעי של הנגשת אפליקציות שם אנו מאפשרים לזהויות השונות לגשת לאפליקציות לפי מודל הרשאות וגישה, לפי רמת חשיבות המידע והאפליקציה.
לשלב החמישי של ניהול Devices אנו מגיעים לאחר שיש לנו שכבת הגנה על זהויות ואפליקציות, ומכאן אפשר להרחיב את הסגמנטציה לפי סוגי המכונות, לפי אימות המכונה ובהתאם לכך ניתן להפעיל פוליסי.
בשלב שלאחר מכן אנו סופסוף יכולים ליישם Information Protection, ובשלב הזה אנו מתחילים להגן על המידע באמצעות תיוג, הצפנה ומעקב אחר כל קובץ או פריט דואר ולאן המידע שלנו מטייל בעולם.
בשלב האחרון אנו מחברים את כל שכבות ההגנה למערכת SIEM כדוגמת Azure Sentinel בכדי לקבל את כל המידע של שכבות ההגנה יחדיו ובהתאם לכך לבצע תחקור ותגובה.
טיפים לשלבי היישום
- מיפוי שטח ההגנה הוא אחד השלבים החשובים אך יכול להשנות גם לאחר בנית הארכיטקטורה.
- ניהול מכונות נחלק לשניים: ניהול תחנות קצה וניהול מכשירים חכמים אין לשלב בין השניים באותה משימה בגלל השינויים הרבים שיש בניהם.
- מומלץ שבחירת פתרון Zero Trust תהיה עם טכנולוגיות שיודעות לדבר אחד עם השניה.
- ניתן לשנות את סדר השלבים במקרים מסוימים בו צריכים לבצע Information Protection לפני הגנה על מכשירים, אך בשום אופן לא מומלץ לדלג על שלב הזהויות.
איך מיישמים
נדלג על השלבים של מיפוי המידע והשלב של בנית ארכיקטורה, ונעבור ישירות ליישום השכבות המעניינות של זהויות, ניהול והקשחת מכונות והגנה על המידע.
ניהול זהויות וגישה
בתצורה היברידית הזהויות הם חלק חשוב מאוד במודל Zero Trust, ולכן הוא השלב הראשון שאנו מיישמים, ולפי השלבים הבאים: (שלבים בסיסיים וראשונים)
חיבור תצורה היברידית Aazure AD Hybrid כולל בין היתר הגדרת AAD Connect, סנכרון אובייקטים וכן הלאה צריך להיעשות לפי מספר דגשים ולא התקנת NNF:
- סנכרון אובייקטים ספציפיים ללא משתמשים לא פעילים או Services וכן הלאה
- בחירת מודל Password Hash Sync שהינו מודל מאובטח יותר לסנכרון אובייקטים
- הגדרת Azure AD Provisioning לפרסום אותה זהות מול מערכות צד שלישי
- הגדרת Azure AD Connect Health
לאחר שסיימנו עם כל אותן הגדרות בסיסיות של Azure AD Connect עם היכולות הנוספות של Provisioning ושל Connect Health אנו יכולים להמשיך ליישום Seamless SSO.
הגדרת Seamless SSO של הסביבה המקומית מול Azure AD מאפשרת למשתמש לעבוד בצורה שקופה ללא צורך בהתעסקות עם סיסמאות ומקביל אינו שומר את הסיסמה המקומית באותה תחנה.
במצב כזה הזדהות המשתמש והבקשות שנעשות על גבי TGT נשלחות באמצעות Token אל הענן ולכן הלוגין הוא ללא סיסמאות.
לצד הגדרת Seamless SSO צריך להגדיר במקביל תמיכה של OAuth לשירותי הענן של Exchange Online, SharePoint Online וכן הלאה.
לאחר שיש לנו תשתית זהויות היברידית של Azure AD אנו ממשיכים להגדרת Azure MFA ובשלב זה אנו דורשים מכל המשתמשים לעבוד עם מזהה נוסף ובגלל שמדובר בשלב ראשון אנו מגדירים אימות מבוסס MFA מתוך הרשת החיצונית בלבד
בכדי להגדיר Azure MFA רק מתוך הרשת החיצונית של הארגון אנו צריכים לבצע את הדגשים הבאים בהגדרות:
- הגדרת Trusted IP's (או Named Location) – הגדרת כתובות ורשתות NAT של הארגון בלבד במטרה להחריג אותם מבקשות MFA
- הגדרת Verification Method – הגדרת אופי המזהים של המשתמש, למשל, אפליקציה או שיחת טלפון (לא מומלץ להגדיר SMS)
- הגדרת Authentication Method – ניתן להוסיף אפשרויות אוטנטיקציה כדוגמת Password Less בכדי להגביר את יכולות האבטחה
- הגדרת חוק ספציפי (בשלב ראשון) של Azure AD Conditional Access – הגדרת תנאי שאוכף הזדהות MFA לכל המשתמשים אשר נמצאים מחוץ לרשת הארגונית ומחוץ לטווחי הכתובות שהוגדרו (Trusted Location)
מומלץ להשתמש ביכולות של Identity Protection ולבצע מעקב ואכיפת פוליסי נוסף למשתמשים בעלי סיכון, למשל, דרישה לרישום מחדש של MFA למשתמש עם סיכון.
טיפ: מומלץ מאוד לאפשר רישום MFA אך ורק מתוך כתובות הארגון באמצעות Azure AD Conditional Access בכדי למנוע בעיות של רישום משתמשים אמיתיים עם MFA זדוני
מידול הרשאות ודלגצית משתמשים מומלצת בשלב זה רק באמצעות האפשרויות של Roles and administrators הקיימות בתוך Azure AD, ועדיין לא להחיל פוליסי באמצעות Azure AD PIM.
לאחר שסיימנו עם הגדרות MFA, קצת דלגציה לחשבונות בעלי הרשאות (אדמינים) אנו נמשיך להגדרת תנאים Azure AD Conditional Access, שם אנו דואגים להכין את הקרקע לטובת הגנה והנגשת אפליקציות, הנגשה למידע רלוונטי ולהקשחת מכונות.
טיפ: בשלב ראשון מומלץ להחיל פוליסי להנגשת מידע רלוונטי ולאפליקציות בלבד.
הגנה על אפליקציות
בתצורה היברידית ומעבר לשירותי הענן אנו עובדים המון עם אפליקציות, כמו, Office 365, Salesforce, Concur ורבים אחרים. במצב כזה כל גישה לאפליקציה צריכה להיעשות לפי פוליסי ותנאים וכן על סמך מיפוי המידע ומסמך איפיון.
הגנה על אפליצקיות היא למעשה הגנה על המידע שעלול ברוב המקרים לכלול מידע רגיש או מידע שאינו יכול לדלוף החוצה בגלל סיבות שונות, ולכן אנו נדרשים להגן על האפליקציות על סמף הזהויות שהגוגדרו, על סמך ניהול הגישה ועל סמך תנאים וחוקים.
למה כל כך חשוב להגן על אפליקציות? בגלל אופי התקנים והפרוטוקולים בענן המאפשרים למשתמשים חבר כל דבר ולכן אנו עלולים למצוא את עצמנו במצב הבא עם אפליקציות:
- אימות של אפליקציה בענן נעשה על סמך המשתמש
- אפליקציות עלולות להחיל גישה למידע רגיש בענן
- ישנן אפליקציות Fake שמטרתן היא לגנוב זהויות או להשיג גישה למידע
הדגשים בהגנה על אפליקציות הם:
- הגדרת תנאים מבוססים Azure AD Conditional Access
- כל גישה לאפליקציה דורש אימות MFA מחוץ לרשת הארגונית
- אפליקציות עם מידע חשוב מוגדרות עם אימות MFA כפול
- חסימת הגדרת אפליקציות ע"י המשתמש
- הגדרת טופס בקשה להוספת אפליקציות (תהליך אוטומטי המצריך אישור אדמין)
- ניטור אפליקציות באמצעות Microsoft Cloud App Security
- לסרוק שינויים בהרשאות אפליקציות על בסיס שבועי
- הגדרת Session Control לחסימת הורדת תוכן, הגבלת טוקן והגדרת Persistent
טיפ: ניתן להשתמש ביכולות של Azure AD Identity Governance בכדי לאפשר גישה לפי תנאים מתקדמים יותרעם גישה מותנית מראש, סגמנטציה של הגישה, אישור ידני של הגישה ועוד
לסיכום, כל אותן הגדרות, דגשים וטיפים שהוזכרו במאמר הם רק החלק הראשוני בהגדרת Zero Trust, אך בהחלט מספיקות להקמה ראשונית של תצורה היברידית ויישום Zero Trust לטובת הגדרה נכונה של אובייקטים והנגשת הענן מתוך הסביבה המקומית, ניהול זהויות בענן והגנה על אפליקציות ענן.
במאמר הבא נמשיך להגדרת Zero Trust עם Intune (או MEM החדש), אכיפת Information Protection ומלא טיפים נוספים.
