הגנה על זהויות עם Azure AD Password Protection

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

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

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

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

הערה: חלק חשוב בהגנה על סיסמאות של משתמשי קצה עם Azure AD הוא הגנה מפני מתקפות כגון: Password Spray, Brute Force ודומיהם והפתרון של Azure AD Password Protect מבצע זאת בצורה דיי טובה אך מאד חשוב להקשיח את השרתים שמעורבים ביישום בכדי לא לחשוף את המנגנון לפריצה ע”י האקרים ברמת שרתי Domain Controllers.

איך עובד המנגנון

כאשר עובדים עם 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) ובכל קריאה כזאת מתרחשים שני דברים:
מתבצעת בקשה ראשונה של ולידציה של הסיסמה החדשה
ביצוע ולידציה ורישום השינוי במערכת

image

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

How Azure AD password protection components work together

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

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

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

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

image

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/

מודעות פרסומת


:קטגוריותAzure AD, Security

תגים: , ,

תגובה אחת

טרקבאקים

  1. azure-ad-password-protection-2 – הבלוג של אלי שלמה

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

מתחבר ל-%s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d בלוגרים אהבו את זה: