Zero Trust תרחישים, טיפים והמלצות

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

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

במספר מאמרים ממוקדים של Zero Trust הרחבתי על מודל, עקרונות, איפיון ואיך ליישם:

למרות הפשטות ביישום והקלות בממשקי Azure AD Conditional Access וכן הממשקים הנלווים אליו כגון: Endpoint Manager, Azure Apps, MTP ואחרים, עדיין איפיון Zero Trust אינו איפיון פשוט כי אנו צריכים להתאים תרחיש מאובטח למציאות קיימת שבה ישנם אפליקציות או פרוטוקולים ישנים – בקיצור ישנם פערים במציאות.

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

מכיוון שאין יותר DMZ ואין יותר הסתמכות ברמת Network, אנו מסתמכים על טכנולוגיות אחרות כמו זאת שמגיעה מתוך Azure AD Conditional Access ומתבססת על תנאים מגוונים כדוגמת:

זהויות היא שכבת אבטחה מכריעה בשירותי הענן וחלק מהותי במודל Zero Trust

אפליציות היא שכבה נוספת וחשובה מאוד, וככל שהאפליקציות הן אפליקציות Native, כך נוכל ליישם תנאים מבוססים Access + App Protection

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

כתובות אמינות (Trusted Locations) היא שכבה נוספת שמאפשרת לקיים תנאים שונים מול השכבות האחרות שמוזכרות מעלה

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

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

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

הגדרת זאת מבוצעת ע"י הגדרות Sign-in frequency וע"י הגדרת Persistent browser session

תרחישי Zero Trust

התרחישים מבוססים על תשתית Azure AD Conditional Access המספקת מספר אפשרויות של יישום, החל מיישום מבוסס טכנולוגיות Microsoft או יישום מבוסס על גבי טכנולוגיות צד שלישי (חלק מתוך אקוסיסטם רחב), אך את כולן מאפיין דבר אחד: שילוב של טכנולוגיות המאפשרות בקרה ומניעה של גישה לא מורשית.

טיפ: התקני קצה אמינים (Trusted device) יכולים להיות Intune-compliant או Azure AD Compliant, יכולים להיות על גבי מערכות Windows 10, מערכות הפעלה צד שלישי (עם פתרון נוסף) או מכשירים חכמים בגרסאות מסוימות

תרחיש Native Apps + גישה מבוססת התקני קצה

תרחיש ראשון ומחמיר הוא תרחיש שמבוסס על הדגשים הבאים:

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

בתרחיש כזה שבו מסתמכים על אפליקציות Native או ליתר דיור Modern Apps, משלבים יחד איתם התקני קצה מאומתים הרשומים במערכות במצב Compliance וכן דורשים שחיבור מתוך רשת חיצונית יבוצע ע"י MFA, בתרחיש כזה אנו מצמצים את שטח התקיפה באופן משמעותי.

מה זה אומר מבחינת Conditional Access? הגדרה לפי התנאים הבאים:

  • הגדרת רשתות אמינות ברמת Named Location
  • הגדרת זהויות עם דרישת לביצוע MFA מול כל רשת שאינה Named Location
  • הגדרת התקני קצה עם ההגדרות הבאות

במערכות Windows 10 / macOS

Modern Authentication clients & browsers: Require trusted device
Legacy Authentication clients & Exchange ActiveSync: Block access

במערכות iOS

Modern Authentication clients & browsers: Require compliant device   Apple DEP + Intune enrollment
Legacy Authentication clients & Exchange ActiveSync: Block access

במערכות Android

Modern Authentication clients & browsers: require compliant device Android Enterprise Corporate-Owned / Business-Only + Intune enrollment
Legacy Authentication clients & Exchange ActiveSync: Block access

בכדי להיות בשליטה מלאה על כלל התקני הקצה שמתחברים לארגון עלינו לוודא שמערכות Windows 10 וכן מערכות iOS / Android מוגדרים עם Company Portal מלא.

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

טיפ: במידה ומפעילים Azure AD Conditional Access מומלץ לעבוד עם משתמש שתפקידו להיות Break Glass Account  למטרות חירום

דיאגרמה של Conditional Access יחד עם רכיבים רבים כמו Azure ATP + Endpoint Manager + Microsoft Cloud App Security ונוספים המבצעים אינטגרציה יחדיו במטרה לבצע הגנה מפני מתקפות כופר.

תרחיש קל שמתבסס על הדגשים הבאים:

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

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

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

מה זה אומר מבחינת Conditional Access? הגדרה לפי התנאים הבאים:

  • הגדרת רשתות אמינות ברמת Named Location
  • הגדרת זהויות עם דרישת לביצוע MFA מול כל רשת שאינה Named Location
  • הגדרת התקני קצה עם ההגדרות הבאות

מערכות Windows 10 / macOS

Browsers: Require MFA on unknown devices
Legacy Authentication clients & Exchange ActiveSync: Block access

מערכות iOS

All clients: require approved applications (protected by Intune App Protection)
Legacy Authentication clients & Exchange ActiveSync: Block access

מערכות Android

All clients: require approved applications (protected by Intune App Protection)
Legacy Authentication clients & Exchange ActiveSync: Block access

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

המלצות נוספות

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

  • צמצום גישה חיצונית לפרוטוקולים ישנים
  • מעבר לאפליקציות מודרניות והסרת Legacy Authentication
  • לוודא שישנו כיסוי רחב על כלל התקני הקצה בארגון אשר מתחברים בין אם מדובר על תחנות קצה או מכשירים חכמים
  • תנאים מבוססים רשתות (לא רשתות Named Location) הם בחלקת Best Effort
  • יש להפריד פוליסי מול משתמשים רגילים לבין פוליסי מול חשבונות בעלי הרשאות
  • מומלץ לעבוד עם Azure AD PIM לטובת חשבונות רגישים וגישה מול נכסים רגישים
  • מקרים של החרגות מומלץ לבצע בקרה וניטור על אותם תנאים
  • מומלץ מאוד לשלב יכולות נראות של Microsoft Cloud App Security בכדי לנהל הגנות מבוססות Session ברמה מתקדמת
  • במקרים מסוימים ולא חריגים ניתן לבצע מיקרו סגמנטציה ברמת רשתות – בפועל תקורת ניהול גבוהה
  • זהויות הם הבסיס להצלחה ולאימוץ מודל Zero Trust
  • אקוסיסטם במודל Zero Trust הוא דרישה קריטית ולכן וודאו שהפתרון כולל טכנולוגיות שיודעות לדבר אחד עם השניה ולבצע פעולות בצורה Native שאינם דורשים הגדרות ותחזוקה אינסופית של הגדרות בין הפתרונות
  • אוטומציה יכולה להיעשות במקרים מסוימים, כדוגמת החרגה של תחנה עקב אירוע סייבר (דורש אינטגרציה עם פתרון EDR)
  • מומלץ לבצע בקרות שבועיות על תצורה קיימת ולשפר אותה בכל עת, וזאת בגלל יכולות חדשות שמתווספות לענן בכל עת
  • מומלץ לחבר אפליקציות מול Azure Enterprise App במטרה לאפשר גישה מבוססת תנאים (כולל SSO במצבים מסוימים)

טיפ: בענן אין דבר כזה DMZ אך עם מודל Zero Trust ניתן לבנות מערך הגנה מבוסס תנאים שונים ואלי לדמות סוג של perimeter

 

מה דעתך?

This site uses Akismet to reduce spam. Learn how your comment data is processed.