במילים פשוטות, העיקרון המרכזי של zero trust הוא "לעולם אל תסמוך, בצע אימות תמיד". זה מבטיח לאנשים הנכונים יש את רמת הגישה הנכונה, למשאבים הנכונים, בהקשר הנכון, וכי הגישה נבחנת ברציפות – כל זאת מבלי להוסיף חיכוך למשתמש. השינוי של Trust Zero לא מתרחש בן לילה, וכאשר ארגונים מיישמים ארכיטקטורות Zero Trust, זיהינו מספר שלבים של בשלות בתשתית.
שלב 0: זהות מקוטעת
ארגונים רבים מתחילים את תהליכי ה- Zero Trust שלהם במגוון יישומים מקומיים (on-premises) ואפליקציות ענן שאינם משולבים יחד או עם ספריות מקומיות כגון Active Directory. כתוצאה מכך, מחלקת ה IT נאלצת לנהל זהויות שונות על פני מספר מערכות כמו גם על שימוש ביישומים והשירותים הרבים ללא מודעות ל- IT. עבור המשתמש זה אומר גם סיסמאות רבות (וכנראה, לא בטוחות). ללא נראות וויכולת בקרה על הזהויות הללו , צוותי IT ואבטחה נותרים עם עם פערי אבטחה משמעותיים המאפשרים לתוקפים לנצל את הגישה למערכות בודדות.
שלב 1: (Unified Identity and Access Management (IAM
זהו הצעד הראשון לפתרון פערי האבטחה שנותרו פתוחים על ידי מערכת IAM רבות, ברחבי הענן. שלב זה קריטי לניהול גישה ואין להגביל אותו רק לגישה לשירות, כולל מימוש מלא של גורם אימות נוסף לאותו להזדהות הבסיסית של משתמש וסיסמה. בנוסף, איחוד מדיניות הגישה בין חלק מתשתיות ה- IT הוא המפתח לקידום IAM לאלפי ארגונים המשתמשים ב- Okta SSO כדי לאחד את זהות המשתמשים שלהם. לעתים קרובות Okta Universal Directory ו- Okta SSO משויכים יחד ובמקרים רבים לקוחות Okta בישראל ובעולם ויתרו על ה AD במערכות שלהם לטובת ה universal Directory של OKTA.
Okta Universal Directory הוא שירות ספריות מבוסס ענן שיכול לשמש מקור אמת אחד עבור ארגוני IT, והוא משמש כנקודת שילוב למספר AD's ושירותי ספרייה מקומיים אחרים. Okta SSO הופך את הניהול והאבטחה של הארגון המורחב לפשוט יותר עבור ה- IT ומבטל את הצורך בשימוש חוזר בסיסמאות . באמצעות Okta Advanced Server Access, מחלקת ה IT יכולה להרחיב את בקרת הגישה באופן דומה לשכבת השרתים באשר הם נמצאים בין אם בענן או בשרות ענני כדוגמת AWS , ולהביא את ניהול הגישה המאובטחת לרוחב המקורות המקומיים ושירותי הענן שהיא צריך לנהל.
שלב 2: גישה על פי הקשר
ברגע מחלקת ה- IT איחדה את IAM, השלב הבא באבטחת Zero Trust הוא ריבוד במדיניות הגישה המבוססת הקשר. משמעות הדבר היא איסוף מידע מעשיר על הקשר המשתמש (Context) (כלומר מי הם? האם הם בקבוצת משתמשים מסוכנת?), הקשר היישום (כלומר, לאיזו יישום המשתמש מנסה לגשת), הקשר של המכשיר, מיקום ורשת, והחלת גישה מדיניות המבוססת על מידע זה. לדוגמה, ניתן לקבוע מדיניות שתאפשר גישה חלקה למכשירים מנוהלים מהרשת הארגונית, אך מכשירים לא מנוהלים, הנכנסים מיקומים חדשים, ייתבקשו לבצע הזדהות חזקה באמצעות MFA . ארגונים יכולים גם להפעיל מספר גורמים בין קבוצות משתמשים כדי להגביר את האימות על סמך הבנה של ניסיונות האימות הללו. דוגמאות לכך יכולות לכלול משתמשים בסיכון נמוך ללא טלפונים חכמים המשתמשים בקודי סיסמה חד פעמיים (OTP) , או שhigh value targets כמו מנהלים ואנשי כספים יידרשו להשתמש בhard tokens באמצעות לחיצת יד קריפטוגרפית לאימות מאובטח לשירות. יתר על כן, אם משתמש עוזב או משנה תפקידים בארגון, הקצאה אוטומטית מבטיחה למשתמש גישה רק לכלים שהוא צריך כדי לבצע את עבודתו (או, במקרה של עזיבה, מבטלת באופן אוטומטי את כל הגישה, ומפחיתה את הסיכון של חשבונות יתומים או גישה סמויה לאחר עזיבה). לבסוף, יש להרחיב את בקרות הגישה העשירות הללו לכל הטכנולוגיות המשמשות את כוח האדם, כולל גישה מאובטחת לממשקי API שהם אבני הבניין של יישומים מודרניים אך יכולים לחשוף נתונים רגישים לאינטרנט.
ארגונים רבים כיום כבר משתמשים בתכונות ניהול תוך שימוש ב CONTEXT ו Risk based Authentication של Okta המגיעות עם Okta Adaptive MFA. על ידי עיבוד של מגוון תובנות הקשר לגבי משתמש, מכשיר, מיקום, רשת, היישום או הדפדפן שממנו ניגשים למשאב, מסגרת המדיניות של Okta יכולה להגיש מענה קונטקסטואלי. תגובה זו מבוססת על מרכיב הסיכון של הארגון(risk tolerance), הפועל כקו ההגנה הראשון בשמירה על ביטחון הארגון. לדוגמה, אם משתמש מנסה לאמת מהמחשב הנייד הרגיל שלהם ברשת הארגונית, הארגון יכול לקבוע מדיניות המחייבת רק את אותו המשתמש להזין סיסמה. אך אם המשתמש ינסה לאמת מהמחשב הנייד הארגוני במדינה זרה ברשת WiFi ציבורית, המדיניות עשויה לדרוש גם סיסמא וגם גורם שני. גישה מבוססת הקשר מסוג זה מועילה הן למשתמש והן למחלקת ה IT או האבטחה, כלומר בקשה לאימות מגורם שני רק במהלך ניסיונות אימות מסוכנים, לא בכל פעם.
שלב 3: כוח עבודה מסתגל
השלב האחרון ביישום Zero Trust מרחיב את התמקדות הארגונים באימות והרשאת גישה. משמעות הדבר היא שהאימות אינו מתרחש עוד רק בשער הקדמי, אלא באופן רציף לאורך כל חווית המשתמש באמצעות הערכה מסתגלת ומבוססת על סיכון, כדי לזהות איומים פוטנציאליים. תחילה זה נראה כמו הוספת מנוע אינטליגנטי ומבוסס על סיכון לתגובות ההקשריות שלב 2, מעבר למדיניות הנפרדת שנקבעה בשלב הקודם. כעת מחלקת ה- IT יכולה לקבוע סובלנות לסיכון ולאפשר ניקוד של הסיכון על סמך אותם אותות הקשר כדי לקבוע את הסיכון של אירוע אימות מסוים, וכן לבקש גורם אימות שני על סמך תובנה זו. האמון כבר לא מוחלט: אימות אדפטיבי זה מנוטר באופן רציף לזיהוי שינוי באחד מהאותות, מה שיוביל לבקשה מחודשת לאימות אם משהו בהקשר של אותו משתמש ישתנה. לבסוף, בעוד שהאבטחה מוגברת באמצעות בקרות גישה אינטליגנטיות אלו המבוססות על סיכונים, בסופו של דבר יש לפשט את החוויה עבור משתמש הקצה – מה שמאפשר גישה ללא חיכוך ובמקרים בהם מחלקת ה- IT קבעה מדיניות שתאפשר זאת, אימות ללא סיסמה.
Okta מאפשרת למנהלים להשתמש במדיניות כדי לשנות את חוויית האימות של משתמשי הקצה וכוללת הסרה לחלוטין של הסיסמה בתהליך האימות (Passwordless) . החלפת סיסמאות בגורם חלופי (כגון Okta Verify או YubiKey) כגורם העיקרי לאימות נותנת למנהלי IT אפשרויות בחירה. הם יכולים לקבוע מדיניות אימות מבוססת סיכון הדורשת אימות מוגבר על סמך סובלנות לסיכון סביב האותות המתקבלים. אם הביטחון גבוה בכך שהמשתמש הוא מי שהוא אומר שהוא, אותו משתמש מתבקש רק לאותו גורם ראשון, ללא שימוש בסיסמה.
למרות של- Okta יש גישה חזקה מבוססת מדיניות המשלבת נתוני איתות מבוססי הקשר, אנו ממשיכים לפתח את מנועי מודיעין המדיניות שלנו כדי שיהיו יותר התנהגותיים. רוב הארגונים כיום נמצאים בהתחלה של עקומת הבגרות של Zero Trust, אך מכיוון שהם ממשיכים לאמץ את הגישה של "לעולם אל תסמוך, בצע אימות תמיד", אל אבטחת הIT שלהם, Okta תמשיך לתמוך בתכונות נוספות המאפשרות ניהול גישה חזק ופשוט יותר.
