שתף באמצעות

המלצות לניטור וזיהוי איומים

  • מאמר

חל על המלצה זו של Well Architected Framework Reliability של Power Platform:

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

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

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

הגדרות

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

אסטרטגיות מרכזיות בתכנון

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

ניתן לגשת לניטור מנקודות מבט שונות:

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

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

    עם זאת, אם ישות פנימית נכנסת למסד נתונים, היקף הנזק הפוטנציאלי אינו ודאי.

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

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

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

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

הסעיפים הבאים מספקים שיטות עבודה מומלצות המשלבות את פרספקטיבות הניטור הקודמות.

לכידת נתונים כדי לעקוב אחר הפעילויות

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

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

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

זרימות משתמש בעומס עבודה

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

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

חשוב

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

ניטור זהויות וגישה

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

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

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

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

ניטור רשת

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

יש יומני גישה לבקשות חיבור נכנסות. יומנים אלה מתעדים את כתובות ה-IP של המקור שיוזמות את הבקשות, את סוג הבקשה (GET, POST) וכל שאר המידע שמהווה חלק מהבקשות.

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

חשוב לעקוב אחר בקשות DNS בלתי צפויות או בקשות DNS המכוונות לנקודות קצה ידועות של פיקוד ובקרה.

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

לכוד שינויים במערכת

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

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

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

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

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

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

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

חשוב

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

בתוכניות הבדיקה, כלול את האימות של רישום והתראה כמקרי בדיקה עם עדיפות.

אחסון, צבירה וניתוח נתונים

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

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

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

זיהוי איומים מרכזי עם יומנים מתואמים

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

מערכת SIEM יכולה ליצור התראות בהתבסס על נתונים מתואמים ומנורמלים. התראות אלו הן משאב משמעותי בתהליך תגובה לאירוע.

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

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

כמה אפשרויות חסכוניות מסופקות על ידי Microsoft. מוצרי Microsoft Defender רבים מספקים את פונקציונליות ההתראה של מערכת SIEM, אך ללא תכונת צבירת נתונים.

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

זיהוי שימוש לרעה

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

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

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

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

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

סיוע ל- Power Platform

הסעיפים הבאים מתארים את המנגנונים שבהם אתה יכול להשתמש כדי לנטר ולזהות איומים ב- Power Platform.

Microsoft Sentinel

פתרון Microsoft Sentinel עבור Microsoft Power Platform מאפשר ללקוחות לזהות פעילויות חשודות שונות, כולל:

  • הפעלה של Power Apps ממקומות גיאוגרפיים לא מורשים
  • הרס נתונים חשוד על ידי Power Apps
  • מחיקה בכמות גדולה של Power Apps
  • התקפות דיוג בוצעו ב- Power Apps
  • פעילות זרימה ב- Power Automate על ידי עובדים שעוזבים
  • מחברי Microsoft Power Platform שנוספו לסביבה
  • עדכון או הסרה של מדיניות למניעת אובדן נתונים מ- Microsoft Power Platform

למידע נוסף, ראה מבט כולל על פתרון Microsoft Sentinel עבור Microsoft Power Platform.

רישום פעילויות ב- Microsoft Purview

מבוצע מעקב אחר רישום פעילות של Power Apps, Power Automate, מחברים, מניעת אובדן נתונים וניהול Power Platform דרך פורטל התאימות של Microsoft Purview.

לקבלת מידע נוסף, ראה:

ביקורת ב- Dataverse

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

ניתוח מדידת שימוש באמצעות Application Insights

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

באפשרותך גם:

  • להגדיר סביבת Application Insights לקבלת נתוני מדידת שימוש על ניתוח וביצועים שנלכדים על-ידי פלטפורמת Dataverse.
  • להירשם כמנוי לקבלת נתוני מדידת שימוש אודות פעולות שיישומים מבצעים במסד הנתונים של Dataverse שלך ובתוך יישומים מונחי-דגמים. נתוני מדידת שימוש אלה מספקים מידע שבאפשרותך להשתמש בו כדי לנתח ולפתור בעיות הקשורות לשגיאות וביצועים.
  • להגדיר זרימות ענן ב- Power Automate לאינטגרציה עם Application Insights.
  • לכתוב אירועים ופעילות מיישומי בד ציור ב- Power Apps ל- Application Insights.

למידע נוסף, ראה מבט כולל על אינטגרציה עם Application Insights.

זהות

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

  • השתמש בדיווח במזהה Microsoft Entra. לקבלת מידע נוסף, ראה מה זה הגנה על זהות? וגם הגנה על זהות.

  • השתמש בחברי API לזיהוי סיכונים בהגנה על זהות כדי לקבל גישה פרוגרמטית לזיהויי אבטחה באמצעות Microsoft Graph. למידע נוסף, ראה riskDetection וגם riskyUser.

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

קווי צינור ב- Azure

DevOps דוגל בניהול שינויים של עומסי עבודה באמצעות אינטגרציה מתמשכת ואספקה מתמשכת (CI/CD). הקפד להוסיף אימות אבטחה בקווי צינורות. עקוב אחר ההנחיות המתוארות באבטחת קווי צינורות ב- Azure.

למידע נוסף

רשימת תיוג של אבטחה

עיין במכלול ההמלצות המלא.

רשימת התיוג של אבטחה