יישום Dynamic Row-Level Security ב-Power BI וב-Microsoft Fabric: ארכיטקטורה, תבניות DAX וממשל ברמת ארגון

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

הטמיעו Dynamic Row-Level Security ב-Power BI וב-Microsoft Fabric כדי לשלוט בגישת משתמשים לנתונים, לוודא עמידה בדרישות תאימות ולהתאים את האבטחה לשינויים בארגון.

Automatically translated with AI from the original post. Read the English original

Titelbild: Implementing Dynamic Row-Level Security in Power BI and Microsoft Fabric: Architecture, DAX Patterns, and Enterprise-Grade Governance

כדאי לחשוב על Dynamic Row-Level Security כעל מערכת שמשתנה לאורך זמן. היא גדלה ומשתנה יחד עם הארגון. תכנון מודל הנתונים, ביטויי DAX, זהות המשתמש והממשל קובעים יחד איך האבטחה פועלת ב-Power BI וב-Microsoft Fabric. כשמגדירים אותה נכון, אפשר לקבוע מי יכול לראות נתונים מסוימים.

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

עיקרי הדברים

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

חשיבה מחודשת על מערכות Row-Level Security

אבטחה כמערכת מבוססת מודל

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

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

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

אבטחה ברמת השורה: סטטי לעומת דינמי

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

הנה טבלה המציגה את ההבדלים:

מאפיין	RLS (Static)	DLS (Dynamic)
גמישות	נמוכה	גבוהה
הגדרה	תפקידים ידניים	מבוסס כללים עם מיפוי משתמשים
מקרה השימוש המומלץ	מעט משתמשים / גישה קבועה	משתמשים רבים / גישה מותאמת אישית

Dynamic Row-Level Security מציעה דרכים גמישות יותר לשליטה בגישה. היא משתמשת במנגנונים כמו USERPRINCIPALNAME() וטבלאות מיפוי כדי להתאים כל משתמש לנתונים הנכונים. Static הוא פשוט להגדרה, אבל אינו מתאים כשהארגון גדל או משתנה במידה רבה.

Static Row-Level Security משתמשת בכללים קבועים כדי להגביל את הנתונים.
Dynamic Row-Level Security משנה את מה שהמשתמשים רואים בהתאם לזהותם.
Dynamic Row-Level Security מתאימה במיוחד לארגונים גדולים עם כללים רבים.

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

תבניות של אבטחה דינמית ברמת השורה ב-Fabric

פונקציות DAX: USERPRINCIPALNAME() מול USERNAME()

חשוב להבין איך פועלת הזהות ב-Fabric. שתי פונקציות עיקריות משמשות להגדרת Row-Level Security: USERPRINCIPALNAME() ו-USERNAME(). שתיהן בודקות מי צופה בדוח. USERPRINCIPALNAME() מחזירה את כתובת הדוא"ל של המשתמש בענן. USERNAME() מחזירה לעיתים קרובות שם חשבון מקומי, בעיקר ב-Power BI Desktop. אם משתמשים ב-USERNAME() בענן, הפונקציה עלולה לא לפעול כראוי, וזה עלול להפחית את רמת האבטחה של הנתונים.

טיפ: השתמשו תמיד ב-USERPRINCIPALNAME() עבור אבטחת שורות דינמית (RLS) ב-Fabric. הפונקציה הזו מתאימה לכתובת הדוא"ל העננית של המשתמש ומשמרת את הנתונים שלכם מוגנים.

פונקציה	מחזירה	מקרה השימוש המומלץ
USERPRINCIPALNAME()	כתובת דוא"ל עננית	Fabric, Power BI בענן
USERNAME()	שם חשבון מקומי	לבדיקות ב-Desktop בלבד

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

תבניות DAX מאובטחות ותבניות שגויות

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

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

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

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

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

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

יש תבניות שגויות שעלולות לגרום לדליפת נתונים:

שימוש ב-USERNAME() בענן.
קידוד קשיח של כתובות דוא"ל או דומיינים של משתמשים.
שימת לוגיקת אבטחה בעמודות מחושבות.

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

היררכיות ופונקציית PATH()

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

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

PATH(Employee[EmployeeID], Employee[ManagerID])

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

טיפ: השתמשו ב-PATH() לאבטחה עם היררכיות. כך מודל הנתונים נעשה גמיש והנתונים נשארים מוגנים.

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

ארכיטקטורת תפקידים וקשרים

תכנון טבלת אבטחה

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

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

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

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

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

תפקידים ברמות פירוט: תפקידים קטנים מול תפקידים גדולים

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

הענקת הרשאות למשתמשים וקבוצות ב-Fabric

קבוצות Azure AD לעומת משתמשים בודדים

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

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

קבוצות חופפות וגישה צללית

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

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

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

סקירות גישה מתוזמנות

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

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

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

פענוח זהות: Desktop לעומת Fabric

פונקציות זהות והבדלי ענן

חשוב להבין כיצד הזהות פועלת ב-Power BI Desktop וב-Microsoft Fabric. ב-Power BI Desktop, הפונקציה USERNAME() בדרך כלל מציגה את שם המחשב שלכם. ב-Microsoft Fabric, הפונקציה USERPRINCIPALNAME() מחזירה את כתובת הדוא"ל שלכם בענן. ההבדל הזה חשוב לשמירה על הנתונים. אם משתמשים ב-USERNAME() בענן, עלולים להופיע נתונים לאנשים הלא נכונים. השתמשו תמיד ב-USERPRINCIPALNAME() לדוחות בענן. כך שומרים על הנתונים ותואמים את מערכת הזהות של הארגון.

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

בעלות על מערך נתונים והגדרות דייר

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

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

סיבות נפוצות לדליפות RLS

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

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

בדיקות, ביקורת וממשל

בדיקות RLS מבוססות ענן

עליך לבדוק את אבטחת השורות (Row-Level Security) בענן. כך תוודא שהנתונים מוגנים עבור משתמשים אמיתיים. הכלי "View As" ב-Desktop מציג רק תצוגה מקדימה. הוא אינו מראה כיצד הכללים פועלים ב-Microsoft Fabric. לאחר פרסום הדוח, בדוק עם משתמשים וקבוצות אמיתיים. כך תראה מה כל אדם יכול לצפות בו. נסה להשתמש בחשבונות בדיקה כדי לוודא שהמשתמשים רואים רק את הנתונים שלהם. בצע בדיקה חוזרת בכל פעם שאתה משנה תפקידים או מעדכן את המודל. בדיקה בענן עוזרת לאתר בעיות לפני שהן פוגעות בעסק.

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

אוטומציה לביקורות ולסקירות

ניתן להשתמש באוטומציה כדי להקל על ביקורות וסקירות ב-Fabric. האוטומציה בודקת הרשאות של סביבות עבודה, זרימות נתונים ותוויות רגישות לפי לוח זמנים. Microsoft Purview מספק לוחות מחוונים למעקב אחר כללים בכל הפלטפורמה. ניתן להשתמש ביומני פעילות ובממשקי ה-Admin API כדי לאתר בעיות תאימות. אוטומציה עוזרת לאתר בעיות מוקדם וחוסכת זמן. מבקרים יכולים לראות את המסלול המלא של עמודות רגישות מהמקור ועד הדוח. כך הסקירות מהירות ומדויקות יותר. אוטומציה גם מקלה ומוזילה את ההקפדה על כללים כמו GDPR ו-HIPAA.

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

תיעוד וניהול שינויים

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

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

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

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

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

שאלות נפוצות

מהי אבטחת שורות דינמית ב-Power BI וב-Fabric?

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

מדוע כדאי להשתמש ב-USERPRINCIPALNAME() במקום ב-USERNAME()?

USERPRINCIPALNAME() מחזיר את כתובת הדוא"ל העננית של המשתמש. זה עובד בצורה הטובה ביותר ב-Power BI וב-Fabric. USERNAME() עשוי להציג שם מקומי, מה שעלול לגרום לבעיות אבטחה בענן.

כיצד קבוצות Azure AD עוזרות לאבטחה?

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

מהי טבלת אבטחה, ומדוע צריך אחת?

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

כל כמה זמן כדאי לבדוק אבטחת שורות בענן?

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