מדיניות נתונים

מניעת אובדן נתונים (DLP) היא היבט קריטי בשמירה על אבטחת נתונים ותאימות בתוך האקוסיסטמה של Microsoft Power Platform.

באפשרותך ליצור מדיניות נתונים שיכולה לשמש כרשת ביטחון כדי לסייע במניעת חשפת נתונים ארגוניים לא מכוונת על ידי ממשתמשים. מרכיב ליבה של Power Apps, Power Automate ו- Microsoft Copilot Studio הוא השימוש במחברים כדי למנות, לאכלס, לדחוף ולמשוך נתונים. מדיניות נתונים במרכז הניהול של Power Platform מאפשרת למנהלי מערכת לשלוט בגישה למחברים אלה בדרכים שונות כדי לסייע בהפחתת הסיכון בארגון שלך.

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

מחברים

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

כאשר מחברים את Power Platform API למחבר, נהיה קל יותר ליצרנים ולמפתחים ללא הכשרה מוקדמת להשתמש ב- API אפליקציות שלהם בתכנות פשוט, בזרימות העבודה והצ'אטבוטים שלהם. לדוגמה, מחבר V2 של Power Platform for Admins הוא הייצוג של ה- Power Platform API ואנו רואים שהפעולה 'קבלת המלצות' היא פשוט גרירה ושחררה לזרימה:

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

מחברים מוסמכים

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

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

מחברים מותאמים אישית

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

מידע נוסף בנושא יצירה וניהול של מחברים מותאמים אישית.

מחברים וירטואליים

מחברים וירטואליים הם מחברים שמוצגים במדיניות הנתונים לשליטה של ​​מנהלי מערכת, אולם הם אינם מבוססים על ממשק API במנוחה. התפשטות המחברים הווירטואליים נבעה מכך שמדיניות נתונים היא אחת מבקרות הפיקוח הפופולריות ביותר ב- Power Platform. עוד יכולות מסוג זה של "הפעלה/כיבוי" צפויות להופיע כחוקים בתוך קבוצות של סביבות.

מספר מחברים וירטואליים מסופקים לפיקוח ב- Microsoft Copilot Studio. מחברים אלה מקלים על היכולת לכבות תכונות שונות של Copilots וצ'אטבוטים.

ניתן ללמוד עוד על מחברים וירטואליים והתפקיד שלהם במניעת אובדן נתונים ב- Microsoft Copilot Studio.

חיבורים

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

זמן עיצוב לעומת זמן ריצה

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

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

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

התהליך לשינויי מדיניות

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

1. תצורת מדיניות הנתונים נשמרת ברמת ניהול הלקוחות.
2. תצורות מועברות לכל סביבה בדייר של הלקוח.
3. משאבים בכל סביבה (כגון אפליקציות, זרמים וצ'אטבוטים) מחפשים מעת לעת תצורות מדיניות מעודכנות.
4. כאשר מזוהה שינוי תצורה, כל אפליקציה, זרימה וצ'אטבוט מוערכים כדי לראות אם הם מפרים את המדיניות.
5. אם מתרחשת הפרה, האפליקציה, הזרימה או הצ'אט בוט מוכנסים למצב השהייה או הסגר כדי שלא יפעלו.
6. החיבורים נסרקים. אם המדיניות חוסמת את כל המחבר אז החיבור מוגדר למצב מושבת כך שהוא לא יכול לפעול.
7. כל המשאבים שפועלים ומנסים להשתמש בחיבור לא פעיל, נכשלים בזמן ריצה.

חשוב

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

שיקולי השהייה

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

למידע נוסף

‏‫ניהול פריטי מדיניות של מניעת אובדן נתונים (DLP)