אפוקליפסת Basic Authentication בשירות Exchange Online

בתקופה הקרובה יחל תהליך של דיסבול הזדהות מבוססת Basic Authentication בשירות Exchange Online, ומעבר אל תצורת הזדהות מתקדמת יותר המבוססת על Modern Authentication.

מאמר מתעדכן של ביטול Basic Authentication ומעבר אל Modern Authentication

תצורת הזדהות מבוססת Basic Authentication היא שטח מתקפה רחב ומעולה המאפשר לתוקפים לממש התקפות מבוססות Password, כמו, Brute Force או Password Spary.

מנקודת מבט של אבטחת מידע השינויים שמגיעים אל Office 365, כמו זה של ביטול Basic Authentication ומעבר אל Modern Authentication עושה לנו שירות טוב, כי בשינויים האלה היוזמה היא לא של אבטחת מידע…

טיפ: שיטת הזדהות מבוססת Modern Authentication איננה שומרת את הסיסמאות מקומית בתחנות כמו שהיה עד כה, ולכן מומלץ להגדיר Seamless SSO בצורה מלאה

השינוי בשירות Office 365

המעבר מתצורת Basic Authentication אל Modern Authentication הוכרז באפריל 2019, אך נדחה עקב COVID-19 לתחילת אוקטובר ולמחצית השניה של 2021.

מתוך המאמר המעודכן של Microsoft למעבר אל Basic Authentication – יולי 2020

As announced last year, the Exchange Team is planning to disable Basic Authentication for the EAS, EWS, POP, IMAP, and RPS protocols in the second half of 2021. As a point of clarity, Security Defaults and Authentication Policies are separate but provide complementary features.

We recommend that customers use Authentication Policies to turn off Basic Authentication for a subset of Exchange Online protocols or to gradually turn off Basic Authentication across a large organization. While more details will come in future announcements, as mentioned in April, we plan to begin disabling Basic Authentication in existing tenants with no recorded usage as early as October 2020

למה מצוינים שני תאריכים? מפורט בהמשך המאמר, אך חשוב להדגיש כי בתאריך 13 לאוקטובר מתחיל התהליך אשר משפיע על טננטים מסוימים, ולקראת המחצית השניה של 2021 כל הגישה על גבי Basic Authentication תהיה חסומה.

מתוך העדכון בממשק Office 365 Message Center

מה ידוסבל בשירות?

המעבר אל Modern Authentication נעשה בשלב זה אך ורק בשירות Exchange Online, ולכן רק לרכיבים הבאים יבוצע דיסבול של Basic Authentication:

EWS (Exchange Web Services)
EAS (Exchange ActiveSync)
IMAP4
POP3
RPS (Remote PowerShell) 

הערה: בפרוטוקול SMTP לא יבוצע שינוי בתצורת הזדהות ולכן אין צורך לבצע שינויים 

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

לדוגמה, אם נקח את הרכיב Exchange Web Services והגישה של אפליקציות על גבי API מול Exchange Online, אז רק שינוי אטבחה בודד חל עליו באמצעות SOAP API בשנת 2018, ומאז כל הפיתוח עבר אל Microsoft Graph API.

למי שצריך לשכתב קוד אז האפשרויות של Microsoft Graph הם מגוונות ובעלות ערך והרבה למעבר לאפשרויות שבוצעו עד כה מול Exchange Online (לפחות למי שעבד מול Basic Authentication).

חשוב מאוד לשים לב לתאריכים של שינוי Basic Authentication בשירות Exchange Online בכל המדיות השונות, במאמרים, בהתראות Office 365 וכן הלאה.

ישנם שני תאריכים מרכזיים:

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

בחצי השני של שנת 2021 ידוסבל Basic Authentication באופן מלא לכלל הטננטים

הגיע הזמן להיות מודרני

תצורת הזדהות המבוססת על Basic Authentication נמצאת איתנו שנים ארוכות, וקיימת בכל מערכת Legacy ואפילו במערכות חדשות ומתקדמות.

Basic Authentication מוכר גם כהזדהות Proxy Authentication, ולמעה מדובר על תצורת הזדהות פשוטה (authentication scheme) הרוכבת על גבי פרוטוקול HTTP/HTTPS.

אפליקציות, מערכות והתקנים רבים מבצעים הזדהות על גבי Basic Authentication בין אם מדובר בהתחברות אל רכיב Exchange Web Services או IMAP.

איך עובד Basic Authentication בשירות Exchange Online? במצב של הזדהות עם Basic Authentication בשירות Exchange Online (וגם בשרת דואר מקומי) נעשיה התהליך הבא:

אפליקצית דואר (Outlook) שולח שם משתמש וסיסמה אל Exchange Online

שירות Exchange Online מבצע העברה (forward) או פרוקסי של פרטי הזדהות אל Identity Provider, למשל Azure AD

שירות IdP מבצע אימות של אותם פרטי הזדהות ולאחר מכן מחזיר טיקט את הבקשה אל Exchange Online ומשם אל המשתמש

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

טיפ: במידה ומבוצעת חסימה של Basic Authentication הגישה נחסמת כבר בנקודה הראשונה של הבקשה הראשונה מול Exchange Online -חסימה באמצעות Azure AD

ומהו Modern Authentication? שיטת הזדהות שנמצאת איתנו מספר שנים בודדות ומאגדת בתוכה שילוב של הזדהות, הרשאות ותנאים, למשל תנאים מבוססים Azure AD Conditional Access.

שיטת הזדהות מבוססת Modern Authentication מתבססת על תקנים קיימים ותקנים שהותאמו לסביבת Office 365:

  • סטנדרט מבוסס Open Source API
  • מבוסס על Open ID Connect לביצוע הזדהות
  • מבוסס על OAuth 2.0 לטובת הרשאות
  • תקן ADAL לביצוע אימות בענן (MSOIDCRL)
  • תמיכה באפליקציות ומערכות צד שלישי
  • מאפשר הזדהות על גבי Smart-Card או MFA וכן הלאה

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

הערה: בשיטת הזדהות של Modern Authentication כל האימות וההרשאות נעשות על גבי Azure AD

למה צריך Modern Authentication? שיטת הזדהות אחת עם טוקן אחד לכלל האפליקציות, שליטה טובה יותר בתצורות הזדהות, תמיכה באפליקציות ומערכות צד שלישי, חווית משתמש אחידה ומתקדמת.

הכנה ומעבר אל Modern Authentication

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

  • מיפוי Basic Authentication והוצאת סטטוס ודוחות
  • הפעלת Modern Authentication
  • ניתוב והעברת אפליקציות שתומכות Modern Authentication
  • אכיפת מדיניות ותנאים לאפליקציות מבוססות Basic Authentication

טיפ: ישנם אפליקציות ומערכות בשירות Office 365 שמושפעות מהשינוי של Exchange Online, ולכן גם מערכות אלה מצריכות שינוי בשיטת הזדהות

מיפוי Basic Authentication והוצאת סטטוס ודוחות

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

  • איך מתחברים אל Exchange Online
  • באמצעות איזה אפליקציות מתחברים
  • האם מדובר על אפליקציות שתומכות בשיטת Modern Authentication
  • האם מדובר על אפליקציות מקוסטמות ללא Ownership
  • האם ישנם מכשירים חכמים עם מערכות הפעלה ישנות
  • האם ביטול Basic Authentication יגרום לבעיות באפליקציות מסוימות
  • השפעות של שינוי שיטת הזדהות לאפליקציות שאינן תומכות בשיטת Modern Authentication
  • האם ישנם השלכות נוספות בביטול Basic Authentication
  • האם מערכות נוספות בשירות Office 365 יושפעו מתוך ביטול Basic Authentication

טיפ: במידה וסביבת Exchange Online מוגדרת עם Modern Authentication עדיין צריך לבצע בדיקות לכלל האפליקציות והחיבורים בארגון

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

איך מבצעים מיפוי ומוציאים דוחות

הכלים והמערכות של Microsoft 365 מאפשרות מיפוי והוצאת דוחות ברמת הבורג, החל מהכלים הרגילים של ממשק Report, או באמצעות Azure AD Sign-in, או באמצעות MCAS וכמובן האפשרויות המתקדמות והנהדרות של Azure Sentinel.

מיפוי באמצעות Microsoft 365 נעשה עם דוחות מתוך אפשרויות Reports ולפי השלבים הבאים:

בממשק Microsoft 365 Admin Center באפשרות Reports ולאחר מכן באפשרות Usage נעבוד עם הדוחות הבאים של Apps + Version שם יוצגו אפשרויות ברמת הממשק ואפשר לייצא את הדוחות באופן מפורט יותר לקובץ Excel.

בדיקה ברמת אפליקציות שמבצעות חיבור מול Exchange Online

דוח לגבי משתמשי קצה שמתחברים עם גרסאות שונות

אפשר לייצא את הדוח לקובץ Excel ולקבל רשימה מפורטת ואפשר גם ברמת ברמת הממשק להוסיף עמודות נוספות להצגת עמודות ואפשרויות נוספות

מיפוי באמצעות ממשק Microsoft Security & Compliance עם האפשרויות של Unified Log Search ולפי הקריטריונים של Sign-in Mailbox או Access to Mailbox ושם אפשר גם להוציא דוח מפורט.

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

מיפוי באמצעות Azure AD Sign-In שם האפשרויות מתקדמות יותר ומאפשרות נראות טובה יותר והוצאת דוחות טובים עוד יותר

דוחות מתוך Azure AD Workbook שמכילים דוחות מתקדמים עוד יותר ומאפשרים לבצע מעקב פשוט אחר מתשי קצה ואפליקציות והדרלך שבה הם מבצעים לוגין.

Azure AD Workbook מכיל מספר דוחות כולל Sign-ins using Legacy Authentication
ולכן אין צורך ליצור דוח.

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

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

דוח מבוסס KQL שמתמקד בהזדהות מול Exchange Online בלבד עם כל הפרוטוקולים הנדרשים.

ישנם אפשרויות נוספות להוציא דוחות ולדעת מהו הסטטוס כמו Microsoft Cloud App Security או Microsoft Graph API  וכן PowerShell עם הסקריפט הבא להוצאת נתונים לגבי מכשירים שמתחברים אל שירות Exchange Online

Get-MobileDevice -RestApi -ResultSize Unlimited | select UserDisplayName,@{n=”User”;e={$_.DistinguishedName.Split(“,”)[2..10] -join “,”}},DeviceType,FirstSyncTime,DeviceAccessState*,ClientType\

הוצאת דוחות מועקב אחר הזדהות מבוססת Basic Authentication עם הכלים של Microsoft 365, והכלים של Azure AD וכן כלים נוספים מספק לנו נראות מעולה לגבי התהליך.

הפעלת Modern Authentication

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

איך מפעילים Modern Authentication? ישנם מספר דרכים להפעלת Modern Authentication והעיקריות שבהן הם באמצעות PowerShell או האפשרויות החדשות במשק Microsoft 365 כולל איכפת פוליסי.

טיפ: במידה והטננט הוקם לאחר תאריך אוגוסט 2017 אז Modern Authentication מופעל בשירות Exchange Online

הפעלה של Modern Authentication מתוך PowerShell נעשית באמצעות הפקודות הבאות:

בדיקת מצב קיים

Get-OrganizationConfig | Format-Table Name,OAuth* -Auto

הפעלת Modern Authentication

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

דרך נוספת להפעיל Modern Authentication היא מתוך ממשק Microsoft 365 אדמין

טיפ: מומלץ להפעיל Modern Authentication פוליסי במצבים מסוימים וזאת במידה ועובדים עם Basic Authentication

כאשר עוברים אל שירות מסוים של Microsoft 365 לתצורת Modern AUthentication מומלץ מאוד להעביר את יתר הרכיבים בשירות גם אל Modern Authentication וזאת למוע בעיות של חוסר אחידות במעבר בין הרכיבים, למשל SharePoint Online.

ברכיב SharePoint Online ניתן לבטל תצורת Legacy עם הפקודה הבאה

Set-SPOTenant –LegacyAuthProtocolsEnabled $false

טיפ: לפני שמפעילים Modern Authentication לרכיבי ענן אחרים מומלץ לוודא תאימות של משתמשי קצה ואפליקציות

לאחר הפעלה Modern Authentication ברמת Microsoft 365 צריך להשלים את ההגדרות גם ברמת Azure AD Connect לפי התהליך במאמר המצורף של הגדרת Configure Azure AD Seamless SSO.

ניתוב והעברת אפליקציות שתומכות Modern Authentication

לאחר המיפוי והפעלה של Modern Authentication בשירות Microsoft 365 מגיעים השלבים המורכבים יותר והוא להחליף את האפליקציות ואת אופן הגישה של מערכות מתוך Basic Authentication אל התצורה של Modern Authentication.

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

מערכות אשר תומכות בתצורת Modern Authentication אך עדיין עובדות Basic Authentication, למשל Office 2016 או Office 2013 – השלב הכי קל בו מבצעים עדכון ברמת Office או מוסיפים ערכי רישום (Registry) והגישה של המשתמש באופן אוטומטי הופכת להיות Modern Authentication.

אפליקציות שאינן תומכות כלל בתצורת Modern Authentication וניתן להעביר אותן אל Modern Authentication – שלב עדיין פשוט שבו לוקחים אפליקציה מסוימת שניגשת עם POP3 ומשנים אותה למצב Modern Authentication או לחלופין מנתבים אותה למצב של תמיכה של OAuth2. למאמר Authenticate an IMAP, POP or SMTP connection using OAuth

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

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

אכיפת מדיניות ותנאים

בשלב הרביעי אנו נמצאים במצב שבו הפעלנו Modern Authentiation ויש לנו את המפה הכללית והמפורטת של האפליקציות שניתן להנגיש עם Modern Authentication ואפליקציות שמצריכות שכתוב, בנוסף לכך, אנו נמצאים במצב שבו אנו יכולים להגדיר תנאים מבוססים Azure AD Conditional Access, או להחיל מדיניות מבוססת Authentication Policy לשירות Exchange Online וכן הלאה.

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

הגדרת תנאי לחסימת Legacy Authentication

דוגמה לביצוע חסימה של Legacy Authentication מול משתמשי קצה לאפליקציה מסוימת או לכלל האפליקציות.

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

  • גרסאות Office 2010
  • גרסאות Office 2013 ללא ערך EnableADAL
  • מכשירים חכמים עם אפליקציות מייל Native
  • התקני MAC בגרסאות Office 2013 ומטה (כולל Office 2013)
  • אפליקציות מבוססות IMAP או POP3

בכדי להגדיר תנאי אשר חוסם Basic Authentication בממשק Azure AD Conditional Access יש לבצע את הפעולות הבאות:

טיפ: כמו בכל תנאי מומלץ לבצע על תנאי שאינו שייך לסביבת הייצור, וכן לשים את התנאי במצב Monitor לניטור התנאי

בממשק Azure ניגש אל Conditions ונבחר באפשרות Client Apps, לאחר מכן נבחר באפשרויות הבאות:

הפעלת Authentication Policy היא דרך נוספת המאפשרת לאנבל או לדסבל את הגישה של Basic Authentication אך היא משפיעה על כלל השירות ולכן מומלץ רק במצבים שבהם אין יותר גישה של אפליקציות ומשתמשי קצה בתצורת Basic Authentication.

 

מה דעתך?

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