Preventing Account Manipulation

המלצות:

1. תכנון מבנה ה-Domain - טרם סנכרון ה-AD הלוקאלי שלכם לענן, דאגו לכך שההיררכיה ב-Domain שלכם אכן מותאמת לסנכרון.
2. הפרד ומשול - הפרידו בין זהויות חזקות לבין זהויות משתמשים רגילות בסנכרון מלא/חלקי לענן. יצרו קבוצה נפרדת למשתמשים החזקים.
3. סנכרון וניהול הזהויות - בחרו את ה-Organizational Units הרלוונטיים ביותר לסנכרון לענן וזכרו – לא כל הזהויות נדרשות לסנכרון ל-Azure AD.
4. יכולות הגנה - הוסיפו יכולות הגנה על זהויות הארגון בענן, נטרו ובקרו את פעולותיהם השונות ע"י כלי ניטור ותגובה מתקדמים.

מידע כללי והרחבות:

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

אחת הדרכים הנפוצות של תוקפים לניצול שירותים בסביבה הלוקאלית ובעזרתה גם להגיע לניצול בשירותי ה-Azure AD ושירותים נוספים בענן הינה Account Manipulation.

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

בזמן שתוקף השיג את פרטי המשתמש, הוא ממשיך להפעיל מניפולציות ובפועל מבצע שדרוג בהרשאות עד להשגת רמת הרשאה גבוהה (Privilege escalation), שתאפשר לו להגיע לנכסים חיונים ברשת הלוקאלית (לא פחות מהמשאבים המצויים בענן). שליטה על משתמש חזק תוביל לשרתי ה-Domain Controllers הלוקאליים ובזמן הסנכרון יקבל גישה ישירה לשירותי ה-Azure AD או שרתי Domain Controllers הענניים.

לצורך צמצום ואף לעיתים מניעה של גניבת זהויות ברשת הארגונית קיימים כלי הגנה ויכולות רבות כדוגמת מימוש אימות דו/רב שלבי – MFA/2FA, מימוש Single Sign-on (SSO) בענן, שימוש ביכולות ניטור ומניעה ועוד.

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

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

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

1. תכנון מבנה הDomain - טרם סנכרון ה-AD הלוקאלי שלכם לענן, דאגו לכך שההיררכיה ב-Domain שלכם אכן מוכנה לסנכרון. וודאו שקיימת חלוקה של משאבים וזהויות עפ"י הצורך הארגוני. וודאו בנוסף כי זהויות אשר לא בשימוש בענן, לא יסונכרנו אליו כלל!
2. הפרד ומשול - הפרידו בין זהויות חזקות לבין זהויות משתמשים רגילות בסנכרון מלא/חלקי לענן. פעולה זאת תסייע לכם להכיל בסופו של דבר מנגנון ניהול של הרשאות משתמשים למשאבים בענן.
3. סנכרון וניהול הזהויות - בחרו את ה-Organizational Units הרלוונטיים ביותר לסנכרון לענן וזכרו – לא כל הזהויות נדרשות לסנכרון ל-Azure AD. הימנעו מסנכרון של זהויות שלא נדרשות להיות בענן. צמצמו למינימום את היישויות.
4. יכולות הגנה - הוסיפו יכולות הגנה על זהויות הארגון בענן, נטרו ובקרו את פעולותיהם השונות ע"י כלי ניטור ותגובה מתקדמים.

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

שימו לב וממשו את תהליך המיגרציה והבקרה למתבצע בין הסביבות השונות בצורה הטובה ביותר!