האם קיצורי דרך ב-Microsoft Fabric יורשים הרשאות משתמש באופן אוטומטי?

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

מה קורה לנתונים אם אני מוחק קיצור דרך ב-Microsoft Fabric?

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

כיצד קיצורי דרך לענן חיצוני מטפלים באימות מול AWS S3 או Google Cloud Storage?

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

מה המשמעות של כלל האבטחה stricter-wins ב-Fabric?

כלל stricter-wins קובע שבעת הערכת הגישה, Fabric אוכף את קבוצת ההרשאות המגבילה ביותר שנמצאת לאורך נתיב קיצור הדרך ונתיב היעד. אם אחד המיקומים שולל גישה או מגביל יכולות, המגבלות הללו חלות על המשתמש הקצה.

הרשאות קיצורי דרך ב-Microsoft Fabric: כללי אבטחה פנימיים מול חיצוניים

By Mirko Peters · 2026-10-30

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

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

Cover: Microsoft Fabric Shortcuts - Simply Explained

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

עיקרי הדברים

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

כך פועלות הרשאות קיצורי דרך ב-Microsoft Fabric

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

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

קיצורי דרך פנימיים והעברת זהות המשתמש

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

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

קיצורי דרך חיצוניים וזהויות חיבור מאוחסנות

קיצורי דרך חיצוניים משנים לחלוטין את הדינמיקה האבטחתית. כאשר מצביעים lakehouse של Fabric על חשבון Azure Data Lake Storage Gen2, על Amazon S3, על Google Cloud Storage או על מיקום רשתי מקומי דרך שער נתונים, העברת זהות המשתמש נעצרת בגבול של Fabric. במקום זאת, קיצורי דרך חיצוניים מאמתים באמצעות זהות חיבור מאוחסנת.

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

כלל ההרשאה המחמירה מנצחת

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

הערכת הכלל הזה דורשת התבוננות בשני קצוות המצביע:

הרשאות נתיב קיצור הדרך: שיוך התפקידים (Admin, Member, Contributor, Viewer) בסביבת העבודה וב-lakehouse שבהם נמצא קיצור הדרך.
הרשאות נתיב היעד: רשימות בקרת הגישה (ACL), מדיניות IAM או הרשאות מסד נתונים שהוחלו ישירות על קבצי המקור או הטבלאות.

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

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

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

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

סיכום

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

שאלות נפוצות

האם קיצורי דרך של Microsoft Fabric יורשים הרשאות משתמש באופן אוטומטי?

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

מה קורה לנתונים אם אני מוחק קיצור דרך של Microsoft Fabric?

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

איך קיצורי ענן חיצוניים מטפלים באימות ל-AWS S3 או ל-Google Cloud Storage?

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

מה המשמעות של כלל האבטחה "המחמיר גובר" ב-Fabric?

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