שאלות נפוצות בנושא העברה של SOAR
תשובות לשאלות נפוצות על תהליך ההעברה של SOAR כאן אפשר למצוא פתרונות לבעיות נפוצות ושיטות מומלצות למעבר מוצלח.
היקף ההעברה וההשפעה שלה
שאלה: למה צריך לבצע את ההעברה הזו?
אנחנו מבצעים מודרניזציה בתשתית SOAR על ידי מעבר אל Google Cloud. השדרוג החשוב הזה מספק יתרונות מרכזיים, כולל אמינות משופרת, אבטחה משופרת, תאימות משופרת ובקרה מפורטת יותר על הגישה. בנוסף, הוא מאפשר גישה ליכולות AI אג'נטיות באמצעות שילוב של Model Context Protocol (MCP).
ההעברה מספקת את היתרונות הבאים:
- שיפור האמינות והיכולות של SOAR באמצעות שכבת ה-API הטובה ביותר של Google. השכבה הזו מספקת פתרון API מוביל עם תכונות מתקדמות לניהול מכסות, לביקורת ולניטור.
- ביטול הנעילה מאפשר להשתמש בבקרת גישה שמבוססת על תפקידים (RBAC) לתכונות ולנתונים בכל הפלטפורמה.
- התוכנית מספקת פונקציונליות גבוהה יותר של תאימות, כמו VPC Service Controls, מיקום לאחסון נתונים ומפתחות הצפנה בניהול הלקוח (CMEK).
ש: מה היקף ההעברה?
ההעברה כוללת את הרכיבים הבאים:
- העברת פרויקט SOAR לפרויקט בבעלות הלקוח Google Cloud .
- העברת אימות והרשאות SOAR אל Google Cloud IAM.
- מעבירים ממשקי SOAR API אל Chronicle API.
- העברת סוכנים מרוחקים.
- העברה של יומני ביקורת של SOAR.
ש: אילו שינויים יחולו מיד אחרי ההעברה?
מיד אחרי ההעברה, יחולו כמה שינויים חשובים:
- בעלות על פרויקט GCP: פרויקט SOAR שלכם יועבר מבעלות של Google לפרויקט Google Cloud בבעלות הלקוח.
- אימות:
- לקוחות Unified SecOps: אין שינוי. האימות ימשיך להתבצע על ידי Google Cloud IAM.
- לקוחות של SOAR Standalone: האימות ינוהל עכשיו על ידי Google Cloud IAM. למשתמשים ב-SAML, המשמעות היא מעבר לאיחוד שירותי אימות הזהות של כוח העבודה. הגדרת ה-SAML לא תישמר יותר ולא תנוהל בתוך מערכת ה-SOAR עצמה, מה שיוביל לאמצעי אבטחה חזקים יותר.
- RBAC: הרשאות המשתמשים יהיו מפורטות יותר וינוהלו באמצעות IAM. הסביבות והתפקידים ב-SOC ימשיכו להיות מנוהלים במודול SOAR באמצעות קבוצות של ספק הזהויות (IdP).
- רישום ביומן ביקורת: יומני הביקורת יהיו מפורטים יותר וינוהלו בתוך **יומני הביקורת של Cloud **.
- כתובת URL חדשה (SOAR בלבד): משתמשי SOAR עצמאיים יקבלו כתובת URL חדשה (דומיין חדש) לגישה ל-SOAR.
ש: איך הלקוחות או השותפים מקבלים הודעה על ההעברה הזו?
חלון קופץ במוצר מוצג לכל הלקוחות והשותפים, והוא כולל את תאריך ההעברה וקישור לטופס למילוי. הם יתבקשו לאשר את התאריך והשעה של ההעברה.
ש: האם עלויות התשתית שלנו ישתנו כתוצאה מהקישור של SOAR לפרויקט Google Cloud ?
לא, העלויות לא יושפעו. לא אמור להיות שינוי בחלק הגלוי של האתר. לא יופעלו משאבים חדשים בפרויקט, ולכן לא יהיו עלויות שקשורות אליו.
ש: איך מקשרים את הפרויקט שלנו ל-SOAR?
Google תעביר את פרויקט ה-SOAR אל הפרויקט Google Cloud שלך. אם אתם לקוחות Unified SecOps, כבר יש לנו את מזהה הפרויקט שלכם ב- Google Cloud . אם אתם לקוחות עצמאיים של SOAR, תצטרכו לשתף איתנו את Google Cloud מספר הפרויקט שלכם.
שאלה: ללקוחות שכבר יש להם פריסה של Google SecOps, האם צריך להשתמש באותו מזהה פרויקט כמו ב-SIEM, או שצריך פרויקט נפרד?
בפריסה מאוחדת של Google SecOps (מערכת SIEM אחת ומערכת SOAR אחת), צריך להשתמש במזהה הפרויקט הקיים שמשויך למערכת ה-SIEM. Google Cloud כך אפשר לנהל באופן אחיד תהליכים אדמיניסטרטיביים, כמו בקרת גישה מבוססת-תפקידים (RBAC) ויומנים.
ש: אילו שלבים צריך לבצע במקרים מיוחדים של מופעי Google SecOps, כמו VPC Service Controls (VPC SC)?
כדי להפעיל את ההעברה, צריך להגדיר כללי תעבורת נתונים נכנסת (ingress) וגם יוצאת (egress) במדיניות של VPC SC. אם בפרויקט Google Cloud שלכם הופעל VPC SC, אתם יכולים לפנות לצוות התמיכה כדי לקבל הנחיות מפורטות לגבי הכללים הספציפיים האלה.
ש: איך אפשר לבדוק שההעברה בוצעה בהצלחה?
כדי לבדוק שהפעולה הושלמה בהצלחה, עוברים אל SOAR Settings > License Management (הגדרות SOAR > ניהול רישיונות). אחרי שלב 1, המילה Google.com תופיע אחרי מספר גרסת המערכת. אחרי ההעברה לשלב 2 של הרשאות SOAR לתפקידי IAM , יופיעו גם Google.com וגם CloudIAM Enabled אחרי מספר גרסת המערכת.
זמן השבתה והמשכיות
ש: האם יש זמן השבתה במהלך ההעברה, ומה ההשפעה שלו?
כן. זמן ההשבתה הצפוי הוא:
- עד שעתיים ללקוחות SOAR עצמאיים.
- עד שעה וחצי ללקוחות Google SecOps.
במהלך התקופה הזו, לא תהיה לך אפשרות להיכנס לפלטפורמה. שירותי SOAR (כולל הטמעה, תוכניות פעולה ומשימות) יושהו, אבל שירותי SIEM ימשיכו לפעול ברקע.
ש: האם נתונים שנוצרו במהלך ההשבתה ייקלטו אוטומטית אחרי ששירותי SOAR יחזרו לפעולה?
כן. אחרי שהמערכת תחזור למצב אונליין, תהליך ההטמעה והפעלת ה-Playbook יתחדשו, וכל ההתראות שנוצרו או הוטמעו במהלך ההשבתה יעברו עיבוד.
ש: מה קורה לתוכניות הפעולה שפועלות כשההשבתה מתחילה?
שירות ה-Playbook יושבת לפני תחילת המיגרציה. יכול להיות שחלק מה-Playbook הפעילים ייכשלו, ותצטרכו להפעיל אותם מחדש באופן ידני או שהם ימשיכו לפעול אחרי שהמיגרציה תושלם.
ש: האם יש תוכנית חזרה או תוכנית מגירה למקרה שמשהו ישתבש במהלך ההעברה?
כן. תהליך ההעברה שומר על המכונה הקיימת של SOAR ללא שינוי (אבל היא מושבתת). אם תהליך ההעברה לא יושלם בהצלחה, נוכל לחזור למופע הקיים ולהסיר את המופע החדש. תהליך החזרה לגרסה הקודמת נמשך עד 30 דקות. אנחנו נבצע בדיקות נרחבות ומעקב צמוד, עם צוות בכוננות כדי להבטיח שהמיגרציה תצליח.
אם נתקלתם בבעיות גישה אחרי ההעברה, סביר להניח שהגדרת האימות לא נכונה. כדי לזהות את הבעיה ולפתור אותה, תצטרכו לתאם עם מנהל הזהויות, ספק ה-IDP או Google Cloud ולהשתמש במדריך לפתרון בעיות. אם הבעיה נמשכת או אם היא לא קשורה לגישה, אפשר לפתוח כרטיס תמיכה כדי לתעד את הבעיה ולעקוב אחרי הפתרון שלה.
ש: מתי אוכל לעבור לנקודות הקצה החדשות של SOAR גרסה 1 ב-Chronicle API?
אפשר לעבור לנקודות הקצה החדשות של SOAR בגרסה v1 של Chronicle API מאמצע ינואר 2026.
SOAR API ומפתחות ה-API מדור קודם יצאו משימוש ולא יפעלו יותר אחרי 30 בספטמבר 2026. כדי שהמעבר יהיה חלק, צריך לבצע את שני השלבים הבאים:
- קודם צריך להשלים את ההעברה של קבוצות ההרשאות ב-SOAR אל Cloud IAM.
- צריך לעדכן את הסקריפטים והשילובים הקיימים כדי להחליף את נקודות הקצה של SOAR API מדור קודם בנקודות הקצה התואמות של Chronicle API.
אימות והרשאות
ש: איך מעבירים את קבוצות ההרשאות וההרשאות של SOAR?
תשתמשו בסקריפט להעברה במסוף Google Cloud כדי להעביר קבוצות הרשאות קיימות לתפקידים בהתאמה אישית ב-IAM. הסקריפט גם מקצה תפקידים בהתאמה אישית למשתמשים (ללקוחות Cloud Identity) או לקבוצות בספק הזהויות (ללקוחות איחוד שירותי אימות הזהויות של כוח העבודה).
שאלה: מה קורה אם אני מעדיף לא להעביר קבוצות הרשאות בהתאמה אישית ולהשתמש רק בתפקידים מוגדרים מראש?
אתם יכולים לבטל את ההסכמה להעברה האוטומטית ולמפות באופן ידני קבוצות של ספק הזהויות לתפקידים ב-Cloud IAM.
ש: אנחנו לקוחות עצמאיים של SOAR עם ספק SAML בהתאמה אישית שדורש אימות ידני. אם נשנה את זה לקבוצות של ספק זהות למיפוי ספק זהות, מה תהיה ההשפעה על חשבונות משתמשים קיימים?
בהנחה שהמשתמשים הקיימים שלכם תואמים לאחת מהקבוצות וההרשאות ממופות בצורה נכונה, לא אמורה להיות השפעה על חשבונות המשתמשים הקיימים. עם זאת, אם המשתמשים לא ממופים לקבוצות, הם לא יוכלו להיכנס. אם ההרשאות ממופות בצורה שונה, המשתמשים יקבלו הרשאות חדשות על סמך המיפוי החדש.
ש: האם יש תנאים מוקדמים ספציפיים לספקי MSSP שמשתמשים בכמה ספקי זהויות?
לקוחות שהגדירו כמה ספקי זהויות בדף האימות החיצוני של SOAR צריכים להגדיר איחוד שירותי אימות זהות של כוח עבודה לאימות וליצור מאגר נפרד של כוח עבודה לכל ספק. כל ספק משויך לתת-דומיין אחר. מידע נוסף זמין במדריך להעברת נתונים של ספקי MSSP.
ש: איך מאמתים את Chronicle API?
פועלים לפי ההוראות במאמר אימות ל-Chronicle API.
ש: מהן כתובות ה-IP החדשות שנדרשות כדי לגשת ל-SOAR API החדש? אין צורך להוסיף כתובות IP לרשימת ההיתרים כדי לגשת ל-Chronicle API. אפשר גם להוסיף לרשימת ההיתרים את טווח כתובות ה-IP שמצוין כאן וכאן.
רישום ביומן ומעקב
ש: השלמנו את השלב הראשון של ההעברה, אבל אנחנו לא רואים יומנים ביומני Cloud Audit Logs.
היומנים מאוחסנים בפלטפורמת SOAR אחרי השלמת השלב הראשון של המיגרציה. היומנים יהיו זמינים בפרויקט Google Cloud אחרי השלמת שלב המיגרציה השני.
ש: האם לקוחות ששולחים נתוני SOAR למופע מנוהל של BigQuery (BQ) עדיין יוכלו לגשת לנתוני BigQuery האלה אחרי ההעברה?
כן. הגרסה הקיימת של BigQuery המנוהל תמשיך לפעול.
לוגיסטיקה ותמיכה
ש: אפשר לבחור חלון זמן אחר להעברה?
לא. אי אפשר לבצע העברה מחוץ למשבצות הזמן המוצעות.
ש: האם נקבל עדכוני סטטוס בזמן אמת במהלך ההעברה?
תקבלו הודעה באימייל בתחילת תהליך ההעברה ובסופו.
ש: למי צריך לפנות אם מתעוררת בעיה אחרי ההעברה?
אם נתקלים בבעיות גישה אחרי ההעברה, סביר להניח שהגדרת האימות לא נכונה. כדי לזהות את הבעיה ולפתור אותה, תצטרכו לתאם עם מנהל הזהויות, ספק ה-IDP או Google Cloud ולהשתמש במדריך לפתרון בעיות. אם הבעיה נמשכת או אם היא לא קשורה לגישה, אפשר לפתוח כרטיס תמיכה כדי לתעד את הבעיה ולעקוב אחרי הפתרון שלה.
העברת קבוצות של הרשאות SOAR ל-IAM
בקטע הבא מפורטות בעיות נפוצות שנתקלים בהן במהלך העברת ההרשאות ל-IAM ואחריה.
בעיות בכלי ההעברה ובסקריפט
ש: למה אני לא יכול לראות או לטעון את סקריפט ההעברה במסוף Google Cloud?
יש שתי סיבות אפשריות לכך:
הרשאות חסרות: כדי להשתמש בכלי ההעברה, לחשבון המשתמש שלכם צריכות להיות הרשאות מספיקות גם ב- Google Cloud וגם במופע של Google SecOps. חשוב לוודא שאתם מחוברים לחשבון שיש לו את תפקידי ה-IAM הנדרשים ב- Google Cloud , ושהוא גם משתמש מוכר ב-Google SecOps SOAR. שימוש בחשבונות שונים ב- Google Cloud וב-SOAR עלול לגרום לכשלי הרשאה. אם יש לכם את ההרשאות הנדרשות ואתם עדיין לא מצליחים לטעון את סקריפט ההעברה, פתחו כרטיס תמיכה.
SIEM לא משתמש ב-Cloud IAM: אם אתם לקוחות של Google SecOps Unified, ודאו שאתם משתמשים ב-IAM כדי לנהל תפקידים והרשאות בצד ה-SIEM של הפלטפורמה. מידע נוסף זמין במדריך להעברה מ-RBAC מדור קודם ל-RBAC של תכונות.
ש: מופיעה שגיאה כשאני מנסה להפעיל את סקריפטים ההעברה. מה עליי לעשות?
שגיאה – 'הקבוצה לא קיימת': כשמשתמשים ב-
add-iam-policy-binding commands, צריך להקפיד להשתמש בכתובת האימייל המלאה של הקבוצה (לדוגמה,your-group@example.com) בשביל הדגל--member, ולא רק בשם הקצר של הקבוצה.שגיאות שקשורות לתפקידים קיימים: יכול להיות שיהיו התנגשויות כשמבצעים קישור לחשבון משתמש שכבר יש לו קישורים מותנים. כדי לפתור את הבעיה, מריצים מחדש את הסקריפט ומוודאים שבוחרים באפשרות ללא במקום באפשרות ציון תנאי חדש.
בעיות בגישה אחרי ההעברה
ש: למה מופיעה השגיאה '403 אסור' כשמנסים לגשת לדפים או לתכונות מסוימים (כמו Playbooks או IDE) אחרי ההעברה של IAM?
שגיאה 403 אחרי ההעברה עשויה להצביע על כך שחסרות הרשאות בתפקיד IAM שהוקצה למשתמש, שנדרשות בצד SOAR של פלטפורמת Google SecOps. Google Cloud זה קורה בדרך כלל אם משתמשים בתפקידי IAM בהתאמה אישית.
בודקים את התפקידים וההרשאות ב-Google SecOps. מוודאים שתפקיד ה-IAM המותאם אישית כולל את כל ההרשאות שנדרשות לגישה לתכונות ה-SOAR הנדרשות.
אפשר גם לבדוק את כלי הפיתוח של הדפדפן כדי לזהות קריאות ספציפיות ל-API שמחזירות שגיאת 403. מטען הייעודי (payload) של התגובה מתעד את ההרשאה החסרה, ובנוסף מופיע באנר התראה בממשק עם פרטים על הגישה הנדרשת.
אם אף אחד מהפתרונות האלה לא עוזר, אפשר לפתוח כרטיס תמיכה.
הרשאות ותפקידים
ש: ביצעתי את ההעברה של IAM באופן ידני בלי להשתמש בכלי שסיפקתם, ועכשיו יש לי בעיות בהרשאות. איך אפשר לפתור את הבעיה?
העברה ידנית של IAM עלולה לגרום לפעמים לכך שהרשאות נחוצות לתפקידי SOAR לא יועברו. מומלץ מאוד להשתמש בסקריפט ההעברה שסיפקנו כדי לוודא שכל ההרשאות הנדרשות מוגדרות בצורה נכונה. אם אתם עדיין מתכננים לבצע העברה ידנית, כדאי לעיין בקפידה בהרשאות IAM ב-Google SecOps כדי ליצור את התפקידים בהתאמה אישית עם ההרשאות הנדרשות.
ש: נראה שלחלק מהמשתמשים יש יותר הרשאות ב-SOAR מהצפוי אחרי ההעברה. למה זה קורה?
זה יכול לקרות אם למשתמשים או לקבוצות כבר הוקצו תפקידים מוגדרים מראש ב-Chronicle לפני ההעברה. Google Cloud
אחרי שתשלימו את ההעברה, תפקידים מוגדרים מראש ב-Chronicle (כמו chronicle.apiAdmin) יכללו באופן אוטומטי הרשאות SOAR. לדוגמה, התפקיד 'אדמין של Chronicle API' יכלול עכשיו הרשאות אדמין של SOAR.
כדי לוודא שהגישה היא לפי עיקרון ההרשאות המינימליות, פועלים לפי השלבים הבאים:
- כדאי לעיין בתפקידים המוגדרים מראש בדף IAM Roles, כולל Chronicle API Admin, כדי לזהות את כל הגורמים שהוקצו (משתמשים וקבוצות).
- מוודאים שרק משתמשים שזקוקים להרשאות SOAR מוקצים לתפקידים האלה.
- כדי להגביל את הגישה ל-SOAR לחשבונות משתמשים ספציפיים, צריך להסיר אותם מהתפקידים המוגדרים מראש ולהקצות להם תפקיד מותאם אישית שלא כולל במפורש הרשאות של אדמין SOAR.
ש: ההעברה הצליחה אבל העמודה 'קבוצות הרשאות' עדיין מופיעה בדף 'מיפוי קבוצות'. למה?
אחרי שההעברה מסתיימת בהצלחה, העמודה קבוצות הרשאות עדיין מוצגת בדף מיפוי קבוצות לצורך תאימות לאחור. אל תמחקו את ההקצאות האלה. העמודה תוסר עד 30 בספטמבר 2026, ולא תהיה לכך השפעה על הלקוחות.
שיטות מומלצות
- שימוש בסקריפט ההעברה: מומלץ להשתמש בסקריפט ההעברה הרשמי ב- Google Cloud כדי לטפל במעבר מקבוצות הרשאות SOAR לתפקידי IAM.
- בדיקת הרשאות IAM: חשוב להכיר את הרשאות ה-IAM הנדרשות Google Cloud לתפקידים ולפונקציות שונות ב-SOAR.
- מבצעים בדיקות יסודיות: אחרי ההעברה, כדאי לבדוק את הגישה לתפקידים ולפרסונות שונים של משתמשים כדי לוודא שהכול פועל כמו שצריך.
- פנייה לתמיכה: אם נתקלתם בשגיאות חוזרות או בהתנהגות לא צפויה, פנו אל התמיכה וספקו כמה שיותר פרטים.
הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.