הגנה על סיסמאות חלשות 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

איך מגדירים? במאמר התקנה והגדרת Azure AD Password Protection

מידע נוסף בקישור הבא azure-ad-password-protection-and-smart-lockout-are