הגנה על סיסמאות חלשות Azure AD Password Protection

סיסמאות הן עדיין גורם מהותי בזהויות, ולמרות שישנם פתרונות מוכרים או מתקדמים, כמו, אימות מבוסס MFA ושיטות זיהוי נוספות כמו SMS-Based, או Passwordless וכמובן פתרונות המבוססים על זיהוי פנים, חומרה ייעודית וכן הלאה.

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

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

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

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

ספקי זהויות כמו Azure AD, OKTA ודומיהם משפרות או מנסות לשפר בכל רגע נתון את חווית המשתמש, כמו זאת של Password Less. הכוונה היא חיובית, אך עדיין ארגונים רבים אינם בשלים ליישום פתרון הגנה ללא סיסמאות, ולמרות שהפתרון של Password Less הוא מצוין ומתקדם, אך עדיין מקדים מעט את זמנו.

פלטפורמת הזהויות של Azure AD מתעדכנת בקצב מהיר ודינמי ויכולות חדשות מתווספות לשירות מידי שבוע, ואחת האפשרויות לא החדשות דווקא היא הגנה על סיסמאות חלשות באמצעות מנגנון Password Protection.

המטרה שלנו היא לאכוף פוליסי סיסמאות חזקות וכאלה שאינן ניתנות לעקיפה ע"י מנגנון Password Protection שמטרתו למנוע בחירת סיסמאות לפי פרמטרים מוגדרים או סיסמאות ידועות מראש.

הגנה על סיסמאות חלשות מבוססת Azure AD Password Protection מביאה איתה בשורות חדשות וישנות, הבשורה החדשה היא שאפשר להתנהל מול הבעיה של מניעת סיסמאות חלשות בסביבת ענן, בסביבה מקומית ובסביבה היברידית, והבשורה הישנה היא שהמנגנון מבוסס על Password Filter DLL שהוא מצוין ונועד בדיוק למטרה הזאת.

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

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

לצד בעיות מיסקונפיגורצה או בעיות ביישום ישנו גורם נוסף שמעונין בסיסמאות והם התוקפים למינהם, אלה שמבצעים תקיפות מזדמנות או תקיפות מוכוונות מראש, והתיקפות שחזרו לאחרונה הם אותן תקיפות מוכרות של Password Spray או Brute-force. לא חדש אבל חזר במסגרת מחודשת ומוכוון מול הענן.

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

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

הפלטפרומה של Azure AD בנויה מסט של מרכיבים שונים החל מיכולות iDP רגילות המתבססות על Azure AD, דרך הגנה על זהויות עם Identity Protection ועד Azure AD PIM. כמובן, שהיכולות של Azure AD Protection הם חלק מאותה פלטפורמה.

טיפ: קשה לעצור סיסמאות כגון Password spray ולעיתים קשה עוד יותר לעצור את התוקף, ולכן השילוב של Password Protection יחד עם Identity Protection מקטין ומונע בעשרות אחוזים תקיפות מהסוג הזה. 

מנגנון Password Protection

כאשר עובדים עם AAPP ישנם שתי תצורות: Cloud & Hybrid.
בתצורת ענן היישום הינו פשוט יותר ומצריך הגדרות רק ברמת Azure AD עצמו, בתצורה היברידית ישנו מנגנון שמצריך התקנה מול שרת DC ושרת נוסף בדומיין (אפשר להתקין את הרכיבים על אותו שרת DC)

במקרים רבים כולנו עובדים עם תשתית Active Directory מקומי ולכן בתרחיש כזה ישנו מנגנון שמורכב מתשתית ורכיבים שונים עם שלושה רכיבים עיקריים:

Azure AD Password Protection Proxy

שירות Proxy אשר רץ על שרתים החברים בדומיין החל מגרסת Windows Server 2012 ומעלה, ותפקידו להעביר בקשות מתוך Active Directory מקומי אל שירות Azure AD ולאחר מכן להחזיר את התושובת של אותה בקשה חזרת מתוך שירות Azure AD אל שרתי Domain Controllers מקומיים.

Azure AD Password Protection DC Agent

רכיב אשר רץ על שרתי Domain Controllers מבצע מספר פעולות, והראשונה בהן היא לקבל בקשות ואלידציה של סיסמאות ע”י שימוש בקובץ filter.dll, לאחר מכן מעבד את הבקשה מול הפוליסי (password policy) ובסיום מחזיר תשובה של הצלחה או כשלון ובהתאם לכך מתריע על על בעית סיסמאות או מגן על זהות המשתמש.
אחת לשעה מתבצע סנכרון בין Proxy לבין DC Agent במטרה לעדכן לגבי הפוליסי של הסיסמאות באמצעות RPC over TCP ולאחר מכן אותו שרת DC מבצע סנכרון ליתר שרתי DC באותו דומיין על גבי תיקיית Sysvol

DC Agent Password Filter

הרכיב שאחראי על שליחת תקינות הסיסמאות ותפקידו לבצע ולידציה של מדיניות הסיסמאות ולאחר מכן לסנכרן את הסיסמאות אל DC agent, מאחורי הקלעים DC Agent Password Filter מבצע רישום ועובד מול Password Filter DLL אשר מבצע רישום באותם שרתי DC’s. כאשר מתבצע שינוי של סיסמה הרכיב LSA מבצע בקשה מול DC Agent (שעובד מול Password Filter) ובכל קריאה כזאת מתרחשים שני דברים:
מתבצעת בקשה ראשונה של ולידציה של הסיסמה החדשה
ביצוע ולידציה ורישום השינוי במערכת

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

יכולות נוספות

banned password – פיצ’ר מגניב לגמרי שמונע ממשתמשי קצה להשתמש במילים מסוימות כטשר בוחרים סיסמאות שונות ובעת החלפת הסיסמה, הגדרת custom banned מאפשר פוליסי שכולל בין היתר:
הגדרה עד 1000 מילים
הרשימה חייבית להיות עם אותיות case-insensitive
אפשרויות שימוש בסימונים נפוצים כגון @ וכן הלאה

בהתאם להמלצות NIST כך גם מול Azure AD ישנו המלצות לגבי מדיניות ופוליסי סיסמאות שמאפשר למנוע מצבים של הגדרת סיסמאות באופן המוכר אות ראשונה גדולה, ספרה ואות או סימן מסוים וכן בחירה על בסיס תחביב מסוים.

Smart Lockout – רכיב שמטרתו למנוע גילוי של הסיסמה במצבים שונים ולתת למשתמש להמשיך לעבוד עם אותה סיסמה “כאילו כלום לא מתרחש ברקע” וזאת ע”י פלטפורמת Cloud Intelligence שמאפשרת לזהות מיהו התוקף ומיהו המשתמש האמיתי על סמך Machine Learning וכתוצאה מכך אותו האקר נחסם מלבצע פעולות שונות מול זהות המשתמש.

Real World

אופן העבודה של AAPP בתצורה היברידית המנגנון עצמו חשוף למתקפות ידועות אשר קיימות מול Active Directory ולכן מומלץ בין היתר לבצע ולשלב את ההמלצות הנוספות:

הקשחה על שרתים בשרתים שבהם מותקנים הרכיבים
ניטור של פעילות AAPP בשרתים שבהם מותקנים הרכיבים (ישנם Event ייעודים)
לוודא מדיניות AAPP עם מדיניות סיסמאות ארגונית

בנוסף מומלץ

לשלב את היכולות החדשות של AAPP מול מנגנון MFA
להחיל את היכולות של AAPP מול יכולות Conditional Access
לאפשר למשתמשים לעבוד עם יכולות Reset Password

האם זה יותר מידי כאשר משלבים את היכולות הנ”ל עם AAPP? ממש לא וכל אותם יכולות נמצאות כחלק מהגנה באמצעות Azure AD על זהויות.

דרישות ורישוי

שרתי בגרסת Windows Server 2012 ומעלה (לטובת Proxy + DC Agent)
הרשאות Global Admin בשירות Azure AD
הרשאות Domain Admin מול Active Directory מקומי
בתצורה של Active Directory מחייב רישוי Azure AD Premium
בתצורה של banned password מצריך Azure AD Premium

במאמר הבא – דגשים בהתקנה והגדרה ואיך מוודאים שלא חושפים את המנגנון החדש להתקפות Active Directory השונות.

מידע נוסף https://cloudblogs.microsoft.com/enterprisemobility/2018/06/19/azure-ad-password-protection-and-smart-lockout-are-now-in-public-preview/

1 Response

  1. 25/06/2018

    […] הראשון התמקד באפשרויות השונות של הגנה על זהויות עם Azure AD Password Protection ומהם ההמלצות והיכולות ביישום בתצורת ענן ותצורה […]

מה דעתך?

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