מושגי אבטחה ב- Microsoft Dataverse

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

אבטחה מבוססת תפקידים

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

יחידות עסקיות

עצה

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

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

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

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

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

מבנה הירארכי של גישה לנתונים

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

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

משתמש A שייך לחטיבה A ומוקצה לו תפקיד אבטחה Y מחטיבה A. הדבר מאפשר למשתמש A לגשת לרשומות איש קשר מספר 1 ואיש קשר מספר 2. משתמש B בחטיבה B אינו יכול לגשת לרשומות איש הקשר של חטיבה A, אבל יכול לגשת לרשומה של איש קשר מספר 3.

דוגמה למבנה מטריצה לגישה לנתונים

מבנה מטריצה לגישה לנתונים (מודרניזציה של יחידות עסקיות - Preview)

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

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

משתמש A יכול להיות משויך לכל אחת מהיחידות העסקיות, כולל היחידה העסקית הבסיסית. תפקיד אבטחה Y מחטיבה A מוקצה למשתמש A, מה שמענית למשתמש גישה לרשומות של איש קשר מספר 1 ואיש קשר מספר 2. תפקיד אבטחה Y מחטיבה B מוקצה למשתמש A, מה שמענית למשתמש גישה לרשומה של איש קשר מספר 3.

דוגמה למבנה הירארכי של גישה לנתונים

כדי לאפשר מבנה מטריצה זה של גישה לנתונים (Preview):

הערה

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

  1. היכנס אל מרכז הניהול של Power Platform כמנהל מערכת (מנהל מערכת Dynamics 365, מנהל מערכת כללי או מנהל מערכת של Microsoft Power Platform).
  2. בחר את הכרטיסיה  תגים , ולאחר מכן בחר את הסביבה שעבורה ברצונך להפוך תכונה זו לזמינה.
  3. בחר הגדרות > מוצר > תכונות.
  4. הפעל את המתג בעלות על רשומות ביחידות עסקיות.

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

הערה

מתג תכונה זה מאוחסן ב הגדרות מסד הנתונים של סביבת EnableOwnershipAcrossBusinessUnits וניתן להגדיר אותו גם באמצעות כלי OrgDBOrgSettings עבור Microsoft Dynamics CRM.

ה‏‫יחידה העסקית המהווה בעלים

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

הערה

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

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

כדי לאפשר למשתמש שלך להגדיר שדה זה, באפשרותך להפעיל שדה זה במקטע הבא:

  1. טופס - גם הגוף וגם הכותרת.
  2. תצוגה.
  3. מיפויי עמודות. אם אתה משתמש ב- AutoMapEntity, באפשרותך לציין את השדה במיפוי העמודה שלך.

הערה

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

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

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

בעלות על טבלה/רשומה

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

כדי לתת דוגמה נוספת, נניח שמשתמש A משויך למחלקה A, ואנחנו נותנים לו גישת קריאה ברמת יחידה עסקית לאיש קשר. הוא יוכל לראות את איש הקשר מס' 1 ומס' 2, אבל לא את איש הקשר מס' 3.

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

הרשאות תפקידי אבטחה.

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

מפתח של הרשאות תפקידי אבטחה.

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

Teams

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

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

שיתוף רשומות

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

אבטחה ברמת רשומה ב- Dataverse

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

אבטחה ברמת שדה ב- Dataverse

לעיתים שליטה בגישה ברמת הרשומה אינה מספיקה עבור תרחישים עסקיים מסוימים. Dataverse כולל תכונת אבטחה ברמת שדה המאפשרת שליטה ‏‫ברמת פירוט גבוהה יותר על אבטחה ברמת השדה. ניתן להפעיל אבטחה ברמת השדה בכל השדות המותאמים אישית וברוב שדות המערכת. מרבית שדות המערכת הכוללים מידע אישי המאפשר זיהוי אישי (PII) מסוגלים להיות מאובטחים באופן אינדיבידואלי. המטה-נתונים של כל שדה מגדירים אם זו אפשרות זמינה עבור שדה המערכת.

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

ניהול אבטחה בסביבות מרובות

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

הגדרת אבטחה בסביבת משתמשים

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

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

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

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

למידע נוסף

קביעת התצורה של אבטחת סביבה
תפקידי אבטחה והרשאות