אבטחת אתר Power Pages שלכם: צלילה לעומק בהרשאות טבלה והיקפים

By Mirko Peters · 2026-08-11

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

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

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

בפוסט הזה נעמיק מאוד במושגי האבטחה הארכיטקטוניים המרכזיים שדנו בהם בפרק האחרון שלנו. אם עדיין לא האזנתם לו, כדאי מאוד לצפות בפרק Build Customer Portals with Power Pages and Dataverse, שמציג הדרכה מלאה להקמת הסביבה, טיפול בזהויות חיצוניות ופריסת פורטל הפתרון הראשון שלכם.

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

מבוא לאבטחה ב-Power Pages

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

האבטחה ב-Power Pages נשענת על אסטרטגיית הגנה רב-שכבתית. בשכבה החיצונית נמצאים מנגנוני האימות, כגון Azure AD B2C, חשבונות מקומיים או ספקי זהות חיצוניים, שמוודאים שהמשתמשים מוכיחים מי הם. בשכבה הפנימית נמצאים תפקידי רשת (Web Roles) והרשאות טבלה ב-Dataverse. ההרשאות האלה קובעות בדיוק מה זהויות מאומתות יכולות לראות, ליצור, לעדכן או למחוק. ביצוע נכון של כל זה הוא ההבדל בין פורטל ארגוני מאובטח לבין פרצת נתונים עצומה שממתינה לקרות.

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

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

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

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

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

הבנת ההבדל בין היקפי איש קשר לחשבון

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

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

מצד שני, Account Scope נועד לארכיטקטורות פורטל מסוג B2B. בתרחיש B2B, מנהל לקוח או רכז רכש ראשי צריכים לראות את כל הפניות, ההזמנות והחשבוניות המשויכות לחשבון האם הארגוני שלהם. כאשר מקצים Account scope להרשאת טבלה (Table Permission), הפורטל בודק את חשבון האם המקושר לרשומת איש הקשר של המשתמש המחובר, ולאחר מכן מציג את כל רשומות הבת הקשורות לאותו ארגון. מיפוי נכון של הקשר הזה ב-Dataverse הוא קריטי להצלחה ב-B2B.

הגדרת תפקידי אינטרנט והימנעות ממלכודת Authenticated Users

תפקידי אינטרנט (Web Roles) הם הגשר בין המשתמשים המאומתים שלכם לבין הרשאות הטבלאות ב-Dataverse. מהרגע הראשון Power Pages כולל תפקיד ברירת מחדל בשם "Authenticated Users". כאן נופלים מנהלים רבים למלכודת אבטחה מסוכנת.

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

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

CustomerUser: ממופה ל-Contact scope עבור טבלאות תפעוליות כמו Cases ו-Orders, ומאפשר למשתמשים לעקוב אחר האינטראקציות שלהם.
AccountManager: ממופה ל-Account scope, ומעניק למובילים ארגוניים מוגדרים נראות לנכסים בכל החברה.
KnowledgeBaseViewer: ממופה ברמה גלובלית, אך מוגבל בצורה קפדנית לפעולות קריאה בלבד במאמרי התמיכה הציבוריים.

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

הקשחת נראות ברמת שדה והגנה על מידע מזהה אישי (PII)

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

בעת בניית רשימות וטפסים בסיסיים ב-Power Pages, דאגו לנקות את התצוגות מעמודות רגישות. עובדה שעמודה מוסתרת בפריסת הטופס בצד הלקוח לא אומרת שאי אפשר לבדוק אותה או למשוך אותה דרך ממשקי ה-API של הרקע, אם ההרשאות רחבות מדי. השתמשו בתצוגות נפרדות ומוקשחות (כמו "PublicView" ייעודי) שמכילות אך ורק עמודות בטוחות ומנוקות. אם עמודות מסוימות חייבות להישאר בטבלה במסד הנתונים, שקלו להטמיע אבטחה ברמת עמודה (Column-level security) ב-Dataverse כדי לחסום לחלוטין את הגישה ברמת מנוע מסד הנתונים.

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

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

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

סיכום ושיטות עבודה מומלצות

אבטחת פורטל Power Pages דורשת תכנון מכוון, היצמדות קפדנית לעקרון ההרשאה המינימלית, והבנה מעמיקה של הרשאות הטבלאות וה-scopes ב-Dataverse. על ידי מעבר מברירות מחדל מסוכנות כמו תפקיד Authenticated Users, צמצום מדויק של הגישה לטבלאות לרמת Contact או Account, והקשחת הנראות ברמת השדה, תוכלו לבנות פורטל לקוחות שהוא גם פונקציונלי מאוד וגם מאובטח במיוחד.

כדי להעמיק עוד יותר בנושא ולקבל מדריך יישום מלא מקצה לקצה, הכולל הגדרת זהויות חיצוניות, תכנון ארכיטקטורת הפתרון והכנה לעלייה לאוויר, מומלץ להאזין לפרק הפודקאסט המשלים שלנו: Build Customer Portals with Power Pages and Dataverse. תודה שקראתם, ואל תפספסו עוד טיפים מעשיים לשליטה ב-Microsoft Power Platform!