שתף באמצעות

המלצות לניהול זהויות וגישה

  • מאמר

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

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

מדריך זה עוסק בהמלצות לאימות והרשאה של זהויות שמנסות לגשת למשאבי עומס העבודה שלך.

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

דוגמאות אופייניות:

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

הגדרות

תנאים הגדרה
אימות (AuthN) תהליך המוודא שזהות היא מי או מה שהיא אומרת שהיא.
מתן הרשאות (AuthZ) תהליך המוודא אם לזהות יש הרשאה לבצע פעולה מבוקשת.
גישה מותנית מערכת כללים המאפשרת פעולות על סמך קריטריונים מוגדרים.
IdP ספק זהויות, כמו Microsoft Entra ID.
אדם פונקציה או תפקיד שיש להם סדרה של תחומי אחריות ופעולות.
מפתחות ששותפו מראש סוג של סוד המשותף בין ספק לצרכן ומשמש באמצעות מנגנון מאובטח ומוסכם.
זהות משאב זהות שמוגדרת עבור משאבי ענן ומנוהלת על ידי הפלטפורמה.
תפקיד קבוצה של הרשאות שמגדירות מה משתמש או קבוצה יכולים לעשות.
טווח‬ רמות שונות של הירארכיה ארגונית שבה לתפקיד מותר לפעול. גם קבוצת תכונות במערכת.
מנהל אבטחה זהות שמספקת הרשאות. זה יכול להיות משתמש, קבוצה או מנהל שירות. כל חברי הקבוצה מקבלים את אותה רמת גישה.
זהות משתמש זהות של אדם, כמו עובד או משתמש חיצוני.
זהות עומס עבודה זהות מערכת עבור יישום או אפליקציה, שירות, סקריפט, גורם מכיל או רכיב אחר של עומס עבודה המשמש לאימות של עצמו כלפי שירותים ומשאבים אחרים.

הערה

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

מזהה Microsoft Entra בתור ספק הזהות עבור Power Platform

כל המוצרים של Power Platform משתמשים במזהה Microsoft Entra (לשעבר Azure Active Directory או Azure AD) לניהול זהויות וגישה. Entra ID מאפשר לארגונים לאבטח ולנהל זהויות עבור סביבות היברידיות וסביבות עם ריבוי שירותי ענן שלהם. Entra ID חיוני גם לניהול אורחים עסקיים שצריכים גישה למשאבי Power Platform. Power Platform משתמש ב-Entra ID גם לניהול יישומים אחרים שצריכים להשתלב עם ממשקי API של Power Platform תוך שימוש ביכולות העיקריות של השירות. על ידי שימוש ב-Entra ID, Power Platform יכול למנף את Entra ID מתכונות אבטחה מתקדמות יותר כמו גישה מותנית והערכת גישה רציפה.

אימות

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

  • שם משתמש וסיסמה חדשים.
  • סוד משותף מראש, כמו מפתח API המעניק גישה.
  • אסימון חתימת גישה משותפת (SAS).
  • אישור המשמש באימות הדדי של Transport Layer Security ‏(TLS).

אימות Power Platform כולל רצף של בקשות, תגובות והפניות מחדש בין דפדפן המשתמש לבין שירותי Power Platform או Azure. הרצף עוקב אחרי זרימת הענקת קוד אימות של Microsoft Entra ID.

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

Authorization

Power Platform משתמש ב- Microsoft Entra ID Microsoft Identity Platform למתן הרשאות לכל קריאות ה-API עם פרוטוקול OAuth 2.0 המקובל בתעשייה.

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

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

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

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

קבע את כל הזהויות לאימות

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

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

קבע פעולות למתן הרשאות

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

  • גישה למישור נתונים. פעולות המתרחשות במישור הנתונים גורמות להעברת נתונים. לדוגמה, אפליקציה שקוראת או כותבת נתונים מ- Microsoft Dataverse, או כותבת יומנים ל- Application Insights.

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

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

ספק הרשאה מבוססת תפקידים

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

חשוב על הנושאים הבאים:

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

הקצאת תפקיד

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

שאל שאלות כמו:

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

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

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

פשרות‬: גישת בקרה של גישה פרטנית, שמאפשרת בקרה וניטור טובים יותר של פעילויות המשתמשים.

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

בחירות של גישה מותנית

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

  • שעה. כמה זמן הזהות יכולה לגשת לסביבה שלך.
  • הרשאה. רמת ההרשאות.

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

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

רק מספיק גישה (JEA) לפי גישה זו, מספקים רק את ההרשאות הנדרשות.

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

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

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

חשבונות עם השפעה קריטית

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

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

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

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

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

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

  • אכיפת תכונות אבטחה מפתחות באמצעות מדיניות גישה מותנית.

  • ביטול חשבונות ניהול שאינם בשימוש.

הקמת תהליכים לניהול מחזור חיי הזהות

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

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

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

הגן על סודות שאינם מבוססי זהות

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

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

ודא שיש לך את היכולת לבטל סודות.

החל שיטות תפעול לטיפול במשימות כמו סבב מפתחות ותפוגה.

למידע על מדיניות סבב, ראה הפוך את הסבב של סוד לאוטומטי למשאבים שיש להם שתי קבוצות של אישורי אימות וגם ‏‫ערכת לימוד: עדכון אוטומטי של אישור תדירות סבב ב-Key Vault.

שמירה על אבטחה בסביבות פיתוח

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

שמור על נתיב ביקורת

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

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

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

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

  • עקוב אחר התקדמות או חריגה מדרישות התאימות.

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

סיוע ל- Power Platform

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

Microsoft Entra ID

כל המוצרים של Power Platform משתמשים במזהה Microsoft Entra (לשעבר Azure Active Directory או Azure AD) לניהול זהויות וגישה. Entra ID מאפשר לארגונים לאבטח ולנהל זהויות עבור סביבות היברידיות וסביבות עם ריבוי שירותי ענן שלהם. Entra ID חיוני גם לניהול אורחים עסקיים שצריכים גישה למשאבי Power Platform. Power Platform משתמש ב-Entra ID גם לניהול יישומים אחרים שצריכים להשתלב עם ממשקי API של Power Platform תוך שימוש ביכולות העיקריות של השירות. על ידי שימוש ב-Entra ID, Power Platform יכול למנף את Entra ID מתכונות אבטחה מתקדמות יותר כמו גישה מותנית והערכת גישה רציפה.

תרשים של מערכת מחשוב ענן.

הקצאת רשיון

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

מדיניות גישה מותנית

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

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

גישה רציפה

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

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

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

ניהול גישה לקבוצה

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

למידע נוסף, ראה בקרת גישה מאובטחת באמצעות קבוצות ב- Microsoft Entra ID.

זיהוי איומים

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

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

רישום זהויות

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

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

תפקידים של מנהל שירות

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

ניתן להשתמש ב- ‎ ‎Privileged Identity Management (PIM)‎ של Microsoft Entra לניהול תפקידי מנהלי מערכת עם רמת הרשאות גבוהה במרכז הניהול של Power Platform.

אבטחת נתוני Dataverse

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

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

רוב הפעולות, התמיכה ופתרון הבעיות שמבוצעים על ידי עובדי Microsoft (כולל מעבדי משנה) לא דורשים גישה לנתוני לקוחות. בעזרת כספת הלקוח של Power Platform, אנחנו מספקים ממשק שבאמצעותו לקוחות יכולים לסקור ולאשר (או לדחות) בקשות גישה לנתונים במקרים הנדירים שבהם נדרשת גישה לנתוני לקוח. למשל, הוא נמצא בשימוש כאשר מהנדס של Microsoft זקוק לגישה לנתוני לקוח, בין אם כתגובה לכרטיס תמיכה שהלקוח יזם או כתוצאה מבעיה שזוהתה על ידי Microsoft. למידע נוסף, ראה גישה מאובטחת לנתוני לקוחות באמצעות 'כספת לקוח' ב- Power Platform ו- Dynamics 365.

למידע נוסף

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

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

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