מיקרוסופט Purview: סוגי מידע רגיש מותאמים אישית – בניית Regex וראיות תומכות שבאמת עובדים
By Mirko Peters ·
למדו לבנות סוגי מידע רגיש מותאמים אישית ב-Microsoft Purview. הכירו את הדרך לכתיבת Regex יעיל, שימוש בראיות תומכות והסרת התראות שגויות.
Automatically translated with AI from the original post. Read the English original

גלו כיצד לבנות סוגי מידע רגיש מותאמים אישית בעלי דיוק גבוה ב-Microsoft Purview, על ידי שילוב ביטויים רגולריים, הגדרות קרבה ומילות מפתח תומכות. הפסיקו להיאבק בהתראות שגויות ולמדו לתכנן גלאי נתונים מדויקים, שמגנים על מידע קנייני של החברה מבלי להציף את צוות ה-IT בהתראות רועשות.
עיקרי הדברים
- סוגי מידע רגיש מותאמים אישית נשענים על ביטויים רגולריים (Regex) כדי לזהות תבניות קנייניות, כגון מזהי עובדים, קודי פרויקטים פנימיים ומספרי חוזים מיוחדים.
- תבניות גולמיות ללא הקשר אינן מספיקות; שילוב של Regex עם מילות מפתח כראיות תומכות וכללי קרבה מחמירים מפחית באופן משמעותי התראות שגויות.
- מילוני מילות מפתח מייעלים את הניהול, בכך שמאפשרים לקבץ מאות מונחים קשורים לאובייקט אחד לשימוש חוזר.
- בדיקה יסודית עם מסמכים לדוגמה מהעולם האמיתי לפני הפריסה מבטיחה שהכללים מזהים דליפות אמיתיות, בלי לחסום פעילות עסקית שגרתית.
- בחירה נכונה של רמות הביטחון מונעת מלוח המחוונים להתמלא ברעש הנובע ממחרוזות מספריות גנריות, כמו מספרי הזמנה או שלוחות טלפון.
המגבלות של גלאים מובנים ב-Microsoft Purview
Microsoft מספקת מאות סוגי מידע רגיש מוכנים מראש, החלממספרי כרטיסי אשראי ומספרי ביטוח לאומי אמריקאיים, דרך מספרי IBAN אירופיים ועד מזהים רפואיים. הגלאים המובנים הללו חיוניים לעמידה בדרישות הציות הכלליות. עם זאת, הם מכסים רק נתונים שנראים זהים בכל חברה בעולם. לעסק שלכם יש מבני נתונים פנימיים ייחודיים, שאף ספק תוכנה מעולם לא ראה.
כשצריך להגן על מידע קנייני – כגון מספריםסידוריים פנימיים של עובדים, קודי פרויקטים מוגבלים, מספרי חשבון ייעודיים של לקוחות או פורמטים של כרטיסי קריאה ממערכות ישנות – גלאים מובנים פשוט אינם מספיקים. כאן צריך לעבור מעבר לתבניות הגנריות ולתכנן סוגי מידע רגיש מותאמים אישית. בניית כללים כאלה מהיסוד דורשת כוונון קפדני, כך שהכללים יזהו בדיוק את טביעת הנתונים הייחודית של הארגון, מבלי להתייחס לכל רצף ספרות אקראי כאל פריצת אבטחה בסיכון גבוה.
כתיבת ביטויים רגולריים יעילים לזיהוי נתונים
הליבה של כל סוג מידע רגיש מותאם אישית היא ביטוי רגולרי, או Regex. Regex הוא קוד תמציתי שמתאר את המבנה המדויק של מחרוזת, ולא את תוכנה הליטרלי. לדוגמה, אם מספרי החוזים הפנימיים שלכם תמיד מתחילים באותיות "CN" ואחריהן מקף, שנה בת ארבע ספרות, מקף נוסף ושישה ספרות סיום, ביטוי רגולרי מובנה היטב יתפוס כל מחרוזת שתואמת בדיוק לפורמט הזה.
עם זאת, התאמת תבניות בלבד טומנת בחובה סיכונים חמורים אם לא מטפלים בה כראוי. כתיבת regex רופף מדי, כזה שמתאים לכל מספר בן שבע ספרות רק משום שנראה מהיר ונוח בבדיקות הראשוניות, תיכשל מיד בסביבת הייצור. ברגע שהכלל יופעל, תבנית רופפת תסמן מספרי טלפון, מיקודים, מספרי חשבוניות וגיליונות כספיים שגרתיים. regex שאין בו משמעת מבנית פועל בסופו של דבר רקככלי לזיהוי מספרים אקראיים, והוא מציף את יומני הביקורת שלכם ב-Purview ברעש רב.
כוחן של ראיות תומכות וקרבה
כדי להפוך תבנית תווים בסיסית לגלאי נתונים חכם, יש לשלב ראיות תומכות וכללי קרבה. הצורה לבדה אינה שווה משמעות. מזהה עובד פנימי שמורכב מהאות "E" ואחריה שבע ספרות עלול בקלות להתנגש במקטי מוצר של ספקים או באסמכתאות משלוח רגילות.
על ידי הוספת מילות מפתח תומכות, כגון "מספר עובד", "רשומת משאבי אנוש" או "פרופיל עובד", אתם מעניקים למנוע הזיהוי הקשר סמנטי. יתרה מזו, עליכם להגדיר כללי קרבה שקובעים כמה קרובות חייבות להיות מילות המפתח לתבנית שנמצאה. אם מילת מפתח מופיעה בכותרת התחתונה של מסמך, שלושה עמודים משם, ליד מחרוזת מספרית, היא לא צריכה להפעיל התאמה. הידוק חלון הקרבה מבטיח שההקשר קשור באמת לערך הנתונים.
שימוש במילונים של מילות מפתח להתרחבות
ניהול רשימות גדולות של מונחים ישירות בתוך כללים בודדים הופך במהרה לסיוט ניהולי. במקום להקליד עשרות או מאות מילים בכל כלל מותאם אישית, כדאי לארגונים להשתמש במילוני מילות מפתח. מילון מילות מפתח מאגד רשימה גדולה של מונחים קשורים, כגון שמות קוד של מערכות פנימיות, תגיות של פרויקטים סודיים או ישויות לקוח החתומות על הסכם סודיות פעיל, לתוך אובייקט אחד וקל לניהול.
בבניית מילונים, האיכות חשובה הרבה יותר מהכמות. הוספת אלפיים מילים גנריות כמו "תוכנית", "סיכום" ו"סקירה" למילון תפגע בדיוק הזיהוי, מפני שמילים אלה מופיעות בתכתובת עסקית רגילה כל היום. כל מונח שנוסף למילון חייב להיות ספציפי מספיק כדי לציין רגישות באופן משמעותי כשהוא מופיע יחד עם התבנית הבסיסית.
בדיקה ואימות לפני פריסה בסביבת הייצור
הטעות הגדולה ביותר שצוותי ציות עושים היא פריסת סוג מידע רגיש מותאם אישית חדש ישירות למדיניות אכיפה ללא בדיקה אמפירית. לעולם אל תסתמכו אך ורק על דוגמאות בדיקה מומצאות שכתבתם בעצמכם כדי להוכיח שהכלל עובד. במקום זאת, אספו מסמכים והודעות דוא"ל אמיתיים מסביבת העבודה העסקית.
Microsoft Purview מאפשר להעלות קבצים לדוגמה ישירות לפורטל כדי לבדוק מה סוג המידע המותאם שלכם מזהה ומה הוא מחמיץ. בנו קבוצת בדיקה מאוזנת הכוללת מסמכים שאמורים להתאים, מסמכים שבהחלט לא אמורים להתאים, ומקרי קצה גבוליים. אם גלאי המותאם אישית שלכם מסמן משהו שלא היה צריך לסמן, בדקו מדוע. בדרך כלל הבעיה נובעת מתבנית regex רחבה מדי, מחלון קרבה לקוי, או ממילת מפתח שמופיעה תדיר מדי בתקשורת עסקית רגילה. חדדו את הכלל, בדקו שוב, וחזרו על התהליך עד שיחס האות לרעש יהיה מדויק לחלוטין. לחקירה רחבה יותר של האופן שבו הרכיבים המותאמים האלה משתלבים באסטרטגיות פריסה מקיפות, האזינו לפרק המלא וגלו כיצד לתכנן מדיניות שמגנה באמת על סביבת הענן שלכם, בלי להרחיק את עובדיכם.
שאלות נפוצות
מהי המטרה העיקרית של סוג מידע רגיש מותאם אישית ב-Microsoft Purview?
סוגי מידע רגישים מותאמים אישית מאפשרים לארגונים לזהות ולהגן על פורמטים ייחודיים של נתונים שמאפיינים את העסק שלהם, כגון מזהי עובדים פנימיים, קודי פרויקטים מותאמים או מספרי חשבון מיוחדים, שאינם מכוסים על ידי ספריית הזיהוי המובנית של Microsoft.
כיצד הגדרות הקרבה מונעות התאמות שגויות בכללים מבוססי regex?
הגדרות הקרבה מגבילות את המרחק שבו מילות המפתח התומכות חייבות להופיע מהתבנית שזוהתה. על ידי דרישה שמילות המפתח יופיעו במרחק תווים מסוים, המנוע נמנע מהפעלת התאמות על מילים לא קשורות הפזורות בחלקים שונים של המסמך.
מדוע כדאי להימנע משימוש במילים גנריות במילון מילות מפתח?
מילים גנריות מופיעות לעיתים קרובות בתקשורת היומיומית הרגילה. הכללת מונחים נפוצים במילון מילות מפתח גורמת למנוע הזיהוי להפעיל התראות שגויות כל הזמן, מה שפוגע באמון המשתמשים ויוצר רעש מנהלתי מיותר.
איך אפשר לבדוק סוג מידע רגיש מותאם אישית לפני פריסתו?
Microsoft Purview מאפשר להעלות לפורטל מסמכים ומיילים לדוגמה מהעולם האמיתי כדי להעריך את הביצועים. ניתן לבדוק את הכללים המותאמים אישית מול תערובת של קבצים חיוביים, שליליים וגבוליים כדי לוודא את הדיוק לפני הפעלת המדיניות עבור המשתמשים הסופיים.