בניית סוכן AI ל-GRC עם Microsoft Purview, Power Automate ו-Copilot Studio: דוחות ציות אוטומטיים

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

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

למה דיווח GRC ידני נכשל

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

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

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

מהו סוכן GRC ומאילו רכיבים הוא בנוי

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

• Microsoft Purview – הזיכרון. כאן נמצאים יומני הביקורת, נתוני הסיווג ואירועי התאימות. כל פעולה במיקרוסופט 365, כמו שיתוף מסמך, יצירת מדיניות או שינוי תווית שמירה, נרשמת ביומן.
• Power Automate – מערכת העצבים. הוא אוסף אותות, מסנן רעשים ומוודא שהתהליך רץ לפי לוח זמנים. הוא ממושמע: לא שוכח צעד ולא מאלתר. כשהגדרות שגויות, הזרימה נכשלת, אך מתעדת את הכישלון בפירוט.
• Copilot Studio – הפה והמתרגם. הוא מקבל סיכום מובנה, למשל טבלת JSON שסופרת פעולות מסוכנות לפי משתמש, ומפיק ממנו סיכומי סיכונים בשפה טבעית.

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

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

בניית צינור הנתונים מ-Microsoft Purview

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

חילוץ הנתונים

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

בקרת גישה והרשאות

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

• לחשבון השירות יש תפקיד של קורא יומני ביקורת ב-Purview;
• הוא יכול להזדהות ללא הפרעות של MFA, כי אוטומציה לא תאשר בקשת אימות באמצע הלילה;
• האישורים נשמרים ב-Azure Key Vault או בהפניות לחיבורים (connection references).

סינון לפי מזהי סיכון אמיתיים

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

פענוח ה-JSON

כאן ההבדל בין אוטומציה אמיתית להעתק-הדבק. יש להמיר את גושי ה-JSON לעמודות מובנות באמצעות הפעולה Parse JSON עם סכימה שנלקחה מאירוע Purview לדוגמה. כל מאפיין, כמו מזהה משתמש, פעולה, עומס עבודה, סטטוס תוצאה וכתובת IP של הלקוח, הופך למשתנה נפרד. חלק משדות הביקורת מגיעים כמערכים גם כשהם מכילים ערך בודד, ואחרים מוסתרים בכמה רמות קינון. Power Automate מטפל בזה באמצעות ביטויים. טעות הקלדה קטנה בביטוי מייצרת שטויות בהמשך, ולכן כדאי לבדוק כל חילוץ בהרצות ניסיון קטנות.

אחסון ביניים ותזמון

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

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

שכבת הלוגיקה ב-Power Automate: ספים ורמות סיכון

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

1. טריגר מחזוריות לפי אזור הזמן של המבקרים, כך שהזרימה מתחילה בלי תזכורת אנושית.
2. אתחול משתנים כמו סך האירועים, ספירת סיכון גבוה ותאריך הדוח. הם משמשים כזיכרון העבודה של הסוכן.
3. סינון מערך להסרת רעש. דפוס נפוץ הוא להתעלם מרשומות שבהן סוג המשתמש הוא שירות ראשי (service principal) ולשמור רק פעולות הקשורות לממשל נתונים או לשינויי מדיניות.
4. הסרת כפילויות בעזרת איחוד (union) או השוואה בלולאה, כי זרמי לוגים חוזרים לעיתים על אירועים זהים.
5. קיבוץ של הרשומות הנותרות לפי שם משתמש ופעולה בעזרת Compose או Select, והזנת הספירות ללולאות Apply to Each שמסכמות כל קטגוריה.

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

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

Copilot Studio: איך הסוכן לומד לכתוב

עד כאן הסוכן יעיל אך אילם. Copilot Studio מעניק לו דיבור והופך את ה-JSON ש-Power Automate מייצר לסיכום מסודר של פעולות משתמשים, ספירות סיכון ורישומי אירועים. התוצאה היא פסקאות שמתאימות להנהלה ומדויקות מספיק למבקרים.

סוגי התקשורת וההנחיות

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

חיבור ל-Power Automate

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

משמעת בהנדסת הנחיות

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

אימות והפצה

תנאי ב-Power Automate בודק שהתגובה אינה ריקה. אם היא ריקה, הכישלון נרשם ביומן והזרימה מנסה שוב פעם אחת. להפצה משתמשים בשני ענפים של אותה זרימה: אחד מפרסם את הסיכום בערוץ Teams, והשני שומר גרסת HTML מלאה ב-SharePoint. ההנהלה קוראת בטימס, המבקרים פותחים את הארכיון, ושני הצדדים מקבלים חותמת זמן אוטומטית וניסוח זהה.

טעויות נפוצות ואבני נתקל

• חשבון שירות ללא הרשאות. הסוכן עלול לדווח על אפס בעיות רק כי הוא "עיוור". האוטומציה אוכפת בדיוק את מה שנתתם לה. אחד הבונים של סוכן כזה גילה זאת בהרצה הראשונה: דוח נקי לחלוטין, שנבע מכך שלחשבון השירות חסר התפקיד של קורא יומני ביקורת.
• משיכת כל פיד הביקורת. בלי הגדרת היקף, הזרימה נעשית כבדה ולא ממוקדת.
• אזור זמן שגוי. הגדרה ל-UTC גורמת לדוחות להגיע בשעות מוזרות.
• טעויות בביטויי JSON. שגיאה קטנה בחילוץ מייצרת תוצאות שגויות בהמשך, ולכן בודקים כל חילוץ בהרצות קטנות.
• התעלמות משגיאות API. ה-API של Purview עלול להחזיר שגיאה של יותר מדי בקשות. עוטפים את קריאות ה-HTTP בקונטיינר Scope עם מדיניות ניסיון חוזר של שלושה ניסיונות והשהיה אקספוננציאלית, ובענף הכשל רושמים את הודעת השגיאה, חותמת הזמן ומזהה ריצת הזרימה בטבלה כמו "בריאות אוטומציה". אפשר להוסיף הודעת Teams כשמשהו חורג מהצפוי. מבקרים לא מענישים על טעויות אלא על היעדר תיעוד שלהן.
• הנחיות רופפות. בלי כותרות וטון מוגדרים, הפלט של Copilot ינסה להרשים במקום לדווח.

תיעוד, גרסאות ושחזור לביקורת

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

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

טיפים מעשיים לבנייה

• הגדירו ב-Purview רק את האירועים שמשפיעים על הציות, והגבילו את ההיקף כבר בשאילתה.
• ודאו שלחשבון השירות יש תפקיד קורא יומני ביקורת ואימות ללא MFA, ושמרו אישורים ב-Azure Key Vault.
• המירו את ה-JSON לשדות מובנים באמצעות Parse JSON ובדקו כל ביטוי בהרצות ניסיון.
• שמרו נתונים מנוקים ב-SharePoint או ב-Dataverse, והעדיפו Dataverse כשצריך קשרים בין נתונים או נפח גדול.
• הגדירו ספי סיכון מספריים ברורים, ותנו לזרימה להחליט לפיהם.
• רשמו תמיד "אין ממצאים" במקום שתיקה.
• עטפו קריאות HTTP במדיניות ניסיון חוזר ותעדו כשלים בטבלת בריאות האוטומציה.
• הגדירו ב-Copilot Studio כותרות, טון ומדדים קבועים, והשתמשו במשתני הקשר לתאריך ולספירת רשומות.
• הפיצו גם ל-Teams וגם לארכיון ב-SharePoint, וגרסו הן את הזרימה והן את ההנחיות.

סיכום

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