עקרונות ביישום Zero Trust
סדרת מאמרים בנושא Zero Trust, והמאמר הנוכחי מתמקד בעקרונות של יישום Zero Trust באופן כללי אך מתייחס להמון טכנולוגיות של Microsoft 365 Security וכן Azure Security.
למאמרים הקודמים:
מודל, איפיון, ארכיטקטורה וגישה של Zero Trust – מאיפה להתחיל? ישנם סברות שונות בגישה ליישום מודל Zero Trust, אך בגלל שלרוב מדובר בתשתית היברידית ואולי גם כזאת של יותר מספק ענן אחד, אז משך זמן היישום מתקצר באופן משמעותי, כולל מצבים שבהם ישנו שילוב של יישום מול משתמשי קצה, למשל MFA.
עקרונות ביישום Zero Trust
ישנם מספר עקרונות ליישום Zero Trust בסביבת Microsoft 365 כולל Azure וסביבה מקומית, והעקרונות חכיולים להתבצע באופן מדורג החל מהסביבות שבהן מיישמים, דרך השטח שעליו אנו מגינים וכן הלאה.
העקרונות של יישום Zero Trust נחלקות לעשרה שלבים אך מתבססות על המאפיינים הבאים של זהויות, התקנים, נתונים ואפליקציות. לצד כל המאפיינים האלה חשוב לשמור על שטח ההגנה ולוודא שהוא מצומצם ככל האפשר.
ארכיטקטורה – לפני הכל ארכיטקטורה, ורגע לפני שמתחילים ללחוץ על כפתורים חשוב לדעת מהי האריכטקטורה הנדרשת של Zero Trust , כלומר מהו שטח ההגנה? מהם התנאים הנדרשים? מי צריך לגשת למידע? וכן הלאה.
כל מידע ונתון שאליו מנגישים מידע חייב להיות חלק מתוך הארכיטקטורה, ולכן הפוקוס צריך להיות בתנאי הנגשה על סמך זהות המשתמש כולל הרשת ממנה הוא מגיע וכן התקן הקצה שממנו מתחברים.
בתצורת עבודה של סביבת מרובת עננים יחד עם סביבה מקומית אנו לא יכולים להסתמך על רשתות ולכן הארכיטקטורה תסתמך קודם כל על זהויות ורק לאחר מכן על התקני קצה ורק אז על רשתות.
במידה והארכיטקטורה איננה כוללת את שטח ההגנה (מידע, נתונים ונכסים רגישים) אנו עלולים למצוא את עצמנו מספספים את הנקודה הכי חשוב של Zero Trust והיא הגנה על הארגון ושמים את שטח ההגנה בסיכון גבוה.
זהות חזקה – מכיוון שתצורת Zero Trust מתסמכת על זהויות אנו צריכים לוודא שהזהות היא הדבר החזק ביותר וסביבה אנו יוצרים את התנאים הנדרשים.
בכדי ליצור זהות חזקה אנו צריכים לוודא שיש ברשותנו תנאים גרנולריים המאפשרים יצירת בסיס חזק לביצוע אוטנטיקציה ואוטוריזציה מול כלל המשאבים. תנאים אלה מלווים את זהות המשתמש בכל הסייקל עד לגישה וצריכה של מידע ונתונים.
התנאים הנדרשים צריכים לכלול בין היתר:
- יצירת תבנית זהויות לסוגי משתמשים
- יצירת Roles לכל תבנית של זהויות המשתמשים
- יצירת קבוצות ייעודיות לכל אפליקציה או גישה למידע
- יצירת תנאים המבוססים על אופן הגישה, חסימת יכולות וכן הלאה
- תמיכה בכל סוגי האימות החזקים: MFA, שילוב חומרה וכמובן Passwordless
- צמצום הרשאות מול שטח ההגנה הנדרש
- יישום תקנים ופרוטוקולים כמו OIDC
- בקרה ונראות של כל תזוזה ברשת
טיפ: תשתית של Directory למשתמשי הארגון חייבת להיות נפרדת מכל Directory אחר של ספקים, אורחים וכן הלאה. במצב של Directories נפרדים ישנן פחות טעויות אנוש כולל בעיות מיסקונפיגורציה.
טיפ: זהות אדמין חייבת להיות שונה מאשר זהות משתמש רגיל וכן שונה מאשר זהות אדמין של Active Directory מקומי. מסרבל במעט את אופן העבודה אך מונע בעיות רבות.
זיהוי מכל מקום ובכל צורה – במודל Zero Trust הזיהוי צריך להיעשות מכל מקום, בכל צורה, לכל גישה ולכל מערכת.
אימות מבוסס MFA הוא אחד המאפיינים החשובים של Zero Trust ואינו צריך להאפיל אל חווית המשתמש ואף יכול לשפר אותה בגלל צורות הזדהות שונות, למשל, אפשרויות מבוססות Token או אפשרויות מבוססות Password Less.
אימות מבוססת MFA יכול להיעשות לפי רגישות הגישה למידע ולכן במצבים מסוימים ניתן לדרוש MFA בצורה משולבת: אחת בכניסה לכלל האפליקציות והשניה בכניסה לאפליקציה רגישה או בכניסה למידע רגיש.
התקן FIDO2 הוא אחד הגורמים שיכולים לסייע באכיפת מדיניות מתקדמת בגלל אפשרויות שונות כדוגמת Password Less היכולות לייתר את הסיסמה בכל המכשירים ולאפשר אימות מאובטח יותר.
התקני קצה מאומתים – התקני הקצה יכולים להיות תחנות קצה של Windows או Linux וכמובן מכשירים חכמים (טאבלטים, ניידים וכן הלאה). אנו צריכים לוודא שהתחנות מאומתות ואמינות.
התקני קצה חייבים להיות מאומתים ותקינים מבחינת אבטחה, ולכן כל בדיקה נעשית ע"י מדיניות ופוליסי המציבה תנאי לכל מחשב שמעונין להתחבר לארגון עם תנאים ודרירות.
ההסתמכות על התקן קצה מאובטח נעשית לפי מספר מאפיינים של סוג מערכת הפעלה, חומרה ואפשרויות אבטחה שונות:
- זהויות נשמרות בהתקן קצה ולכן מנגנון כמו TPM או לחלופין Credential Guard יאפשר להקשיח תחנה בצורה בטוחה יותר.
- מידע ונתונים עלולים להישמר בהתקן קצה ולכן מניעת זליגת מידע (למשל Information Protection) מורידה את הסיכון של חיבור תחנות קצה.
- רוב הגישה נעשית מתוך מכשירים חכמים שהם מאובטחים פחות ולכן מכשירים חכמים מקבלים פוליסי אחר מבוסס MAM ומחמיר יותר, למשל, מניעת הורדה של תוכן למכשיר.
כאשר מאפשרים גישה להתקן קצה שאינו מנוהל או אינו מזוהה בדרך כלשהיא אנו מעלים את הסיכון לבעיות אבטחה שונות, כגון, זליגת מידע, חיבור מתחנה נגועה וכן הלאה.
בנוסף לכך חשוב לשמור על התקני קצה בריאים, והתקן קצה נגוע עלול להכיל שחקן זדוני שממתין לרגע הנכון בכדי לבצע פעולה הרסנית, הרגע הנכון יכול להיות בעת גישה למידע רגיש בארגון.
ישנם דרכים שונות לבדוק האם תחנה נגועה ובמידת הצורך לאכוף פוליסי מול תחנה נגועה שלא תתחבר אל הארגון.
אפליקציות ושירותי ענן – אפליקציות ושירותי ענן חייבים להיות אמינים במאת האחוזים, מוגדרים לפי מדיניות ונמצאים במעקב רציף.
כיום ישנם אפליקציות רבות שאיתם ניתן לבצע לוגין באמצעות שם המשתמש והסיסמה הארגונים, וגם במצב כזה כאשר נעשה לוגין ע"י המשתמש בצורה מאובטחת, עדיין ישנה אפשרות שמדובר באפליקציה נגועה אשר דורשת הרשאות גבוהות, וכתוצאה מכך האפליקציה מקבלת הרשאות למשאבים רגישים.
לצד זה ישנן אפליקציות ישנות המצריכות אימות באמצעות פרוטוקולים ישנים (POP,SMTP), אפליקציות כאלה אינן עובדות עם Modern Authentication ולכן עלולות לחשוף פרטים של שם משתמש וסיסמה.
מכיוון שאפליקציות הם לא דבר שנמצא בשליטתנו המלאה, וישנם מצבים בהם שאם נרצה להחליף את אופן האוטנטיקציה של אפליקציה מסוימת נידרש לבצע שינוי מהותי באפליקציה וכזה שיגרום לעלות קיצונית.
נראות, מעקב וניטור – אולי אחד העקרונות הכי חשובים של Zero Trust הוא נראות, מעקב וניטור אחר כל גורם שעובר דרך מנגנון Zero Trust בין אם הוא הצליח או נכשל ובין אם הוא משתמש רגיל או חשבון בעל הרשאות.
כאשר נמצאים במצב של תצורה מולטי היברידית ובנוסף מאמצים את מודל Zero Trust אנו מותחים את הרשת הארגונית בצורה רחבה, וכזאת שאינה שמאתגרת את המעקב אחר כל פעולה אשר מתרחשת בסביבה שלנו.
במצבים כאלה פתרונות CASB נותנים את המענה הנדרש ויכולים לעקוב אחר כל גורם בין אם בסביבת ענן (Multi-Cloud) או בסביבה מקומית, ככל שמערכת CASB מחוברת ליותר מערכות כך נוכל להגיע למצב טוב יותר של נראות.
יישום CASB הוא אחד העקרונות שצריך ליישם רגע לפני שמאפשרים יישום תצורה היברידית כי אנו רוצים לקבל נראות ולנטר כל מידע אשר קשור לסביבה שלנו.
פוליסי מבוסס סיגנלים – הכח של Zero Trust מבוסס על אינטגרציה ואקו-סיסטם, וזאת בגלל שסיגנל הוא חלק חשוב ביצירת מדיניות וחייב להיות חלק אינטגרלי בין המערכות, ולצד זה מספק לנו מידע בזמן אמת לגבי השירות או האפליקציה שמחוברת לענן.
ברגע שיש לנו סיגנלים רבים אנו יכולים לתחם את צורת העבודה של המשתמש ולהנגיש את המידע בצורה בטוחה יותר ועם פוליסי מותאם על גבי אותו סיגנל.
למשל, משתמש שמתחבר עם זהות מתוך תחנת קצה לאפליקלציה מסוימת, במצב כזה אנו בונים את הגישה (הפוליסי, התנאים והחוקים של Zero Trust) על גבי מספר סיגנלים: זהות, תחנת קצה, מצב תחנת קצה, מיקום, גישה נדרשת למידע, הרשאות גישה למידע וכן הלאה.
לא לבטוח ברשתות – במודל Zero Trust אנו לא בוטחים ברשתות ואנו מסתמכים עליהם פחות, וזאת בגלל שכל מה שעובר בין הזהות לבין הגישה למידע חייב להיות מבוסס על גבי מאפיינים אחרים קודם לכן.
יותר קל להשיג רשת של משתמש ספציפי מאשר זהות משתמש עצמה, למשל, התחברות מתוך רשת ביתית או רשת WiFi כשלהיא, במצב כזה משתמש לא יודע האם הוא גולש על גבי חיבור תקין או חיבור זדוני ומשם ניתן להסניף תעבורה ולבצע פעולות MITM.
סיבה נוספת לביצוע סגמנטציה על גבי משתמש היא בגלל שכל משתמש הוא "DMZ" בפני עצמו ולכן אין לנו אפשרות להתסמך על גישה מרשתות שאינן מוכרות, ולכן המיקרו-סגמנטציה נעשית על גבי זהות המשתמש.
בחירת שירות Zero Trust – עוד דגש חשוב מאוד הוא בחירת הפתרון וכן בחירת הטכנולוגיות שאיתם נבצע יישום Zero Trust, בחירת הפתרון משפיעה על כל התהליך של Zero Trust, מתחילתו עם איפיון וארכיטקטורה ועד יישום ברמת הבורג.
מכיוון שתהליך Zero trust מתחיל משלושה מאפיינים ראשונים: זהויות, שמירה על המידע ואכיפת מדיניות מול התקני קצה. אנו צריכים לוודא שהספק שבחרנו יודע לעבוד עם טכנולוגיות נוספות, כגון: נראות וביצוע פעולות מנע (CASB), הגנה והצפנה של המידע (AIP), הגנה על תחנות קצה (XDR) וכן הלאה.
ביישום מודל Zero Trust אין לנו אפשרות לעבוד במצב של איים בודדים כי האינטגרציה בין כלל הטכנולוגיות היא משמעותית מאוד, ולכן ככל שתהיה לנו סינרגיה בין הטכנולוגיות כך נוכל לבצע אכיפה של המדיניות עם תנאים ופוליסי.
לדוגמה, כאשר מיישמים מודל Zero Trust ומשלבים את Azure Sentinel לטובת Cloud Native SIEM אנו מאפשרים נראות, מעקב וניטור על כל סיגנל שהינו חלק מתוך Microsoft וגם מערכות שהם חלק מתוך האקוסיסטם של Microsoft.
האקוסיסטם של Microsoft נקרא Microsoft Intelligent Security Association ובקצרה MISA, אשר מכיל מעל 100 וונדורים של אבטחת מידע עם סיגנלים שונים בתחומים אבטחה שונים.
במצב כזה כאשר ישנם אינספור סיגנלים הקורלציה של המידע היא מדויקת יותר ומורידה False Positive מול אירועי אבטחה, ולכן במצב כזה ניתן לבצע תחקור וניתוח אירוע עם Azure Sentinel בצורה מדויקת, פשוטה ועם הרבה מאוד מידע.
מתוך האתר של Azure Sentinel: A Tip of the Microsoft Security Iceberg
גישה ביישום Zero Trust
וכאן מגיעה השאלה הגדולה והיא, איך מיישימים Zero Trust? לצד העקרונות של Zero Trust חשוב להדגיש כי היישום של Zero Trust נחלק לשניים: סביבה חיצונית וסביבה פנימית. מה הסיבה לחלוקה הנ"ל?
הסביבה החיצונית מהווה סיכון רב יותר מאשר הסביבה הפנימית שאולה אנו כבר מנטרים ומכילים מספר שכבות של אבטחה, ובנוסף לכך פשוט יותר לאכוף מדיניות על גישה חיצונית כי לרוב (לפחות בשלב ראשון) מדובר על גישה מול אפליקציות מודרניות.
יישום מתוך סביבה חיצונית – יישום Zero Trust מול הענן ומול הסביבה המקומית מתוך רשתות חיצוניות וכל מקום שאינו הרשת המאומתת והקיימת של הארגון, במצב כזה אנו מבצעים הגנה על כל נכס ארגוני בענן או בסביבה המקומית לכל גישה חיצונית.
יישום לסביבה פנימית – יישום Zero Trust מול הענן ומתוך הרשת הפנימית או אתרים שונים של הארגון. יישום מתוך רשת פנימית של הארגון כבר מחילה הגנות שונות ולכן בסדר העדיפויות כדאי להתחיל עם יישום סביבה חיצונית.
ביישום Zero Trust לסביבה פנימית תמיד עולה השאלה למה צריך בכלל להחיל תנאים וחוקים מול סביבה שאני מגן עליה? ישנן המון סיבות אך השניים החשובות, הם: מניעת גישה לא מורשית לנכסים בענן למורשים בלבד, והסיבה נוספת, היא למנוע מצב של תנועה רוחבית של שחקן שאינו מורשה.
מאמרים נוספים בנושא Zero Trust בקישור Zero Trust Archives – אלי שלמה
