שאלות נפוצות על המעבר ל-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.
  • העברת תשתית האימות של סוכנים מרוחקים.

שאלה: מהם השינויים המיידיים אחרי ההעברה?

מיד אחרי ההעברה, תבחינו בכמה שינויים משמעותיים:

  • בעלות על פרויקט 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 Standalone, תצטרכו לשתף איתנו את מזהה הפרויקט שלכם ב- Google Cloud .

שאלה: לקוחות שכבר משתמשים ב-Google SecOps, צריכים להשתמש באותו מזהה פרויקט כמו ב-SIEM או בפרויקט נפרד?

בפריסה מאוחדת של Google SecOps (מערכת SIEM אחת, מערכת SOAR אחת), צריך להשתמש במזהה הפרויקט הקיים ב- Google Cloud שמשויך למערכת ה-SIEM. כך אפשר לנהל באופן אחיד תהליכים אדמיניסטרטיביים, כמו RBAC ויומנים.

שאלה: אילו שלבים נדרשים במכונות של Google SecOps עם שיקולים מיוחדים כמו VPC Service Controls ‏ (VPC-SC)?

כדי לאפשר את ההעברה, צריך להגדיר כללי תעבורת נתונים נכנסת (Ingress) ויוצאת (Egress) במדיניות של VPC-SC. אם בפרויקט Google Cloud יש VPC SC, פנו לצוות התמיכה כדי לקבל הנחיות מפורטות לגבי הכללים הספציפיים האלה.

יש שתי תכונות של API שלא נתמכות ב-VPC-SC:

  • תגובות לפעולה מאתר אחר (webhook)
  • קישורים לאישור פלייבוקים

שאלה: איך אפשר לוודא שההעברה בוצעה בהצלחה?

כדי לוודא שההתקנה הושלמה, עוברים אל הגדרות SOAR > ניהול רישיונות. אחרי שלב 1, אחרי מספר הגרסה של המערכת יופיע הכיתוב Google.com. אחרי שלב 2 של העברת ההרשאות של SOAR לתפקידי IAM , יופיעו גם Google.com וגם CloudIAM Enabled אחרי מספר הגרסה של המערכת.

זמן השבתה והמשכיות

שאלה: האם יש זמן השבתה במהלך ההעברה, ומה ההשפעה שלו?

כן. אלה זמני ההשבתה הצפויים:

  • עד שעתיים ללקוחות SOAR עצמאיים.
  • עד שעה וחצי ללקוחות Google SecOps.

בזמן הזה לא תהיה לך אפשרות להיכנס לפלטפורמה. שירותי SOAR (כולל הטמעה, פלייבוקים, משימות) יושהו, אבל שירותי SIEM ימשיכו לפעול ברקע.

שאלה: האם הנתונים שנוצרו בזמן ההשבתה יוטמעו באופן אוטומטי אחרי ששירותי SOAR יחזרו לפעול?

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

שאלה: מה קורה לפלייבוקים שפועלים כשההשבתה מתחילה?

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

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

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

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

שאלה: מתי אפשר לעבור לנקודות הקצה החדשות של SOAR בגרסה 1 ב-Chronicle API?

החל מאמצע ינואר 2026, אתם יכולים לעבור לנקודות הקצה החדשות של SOAR בגרסה 1 ב-Chronicle API.

הגרסה הקודמת של SOAR API ומפתחות ה-API יוצאו משימוש ולא יפעלו יותר אחרי 31 במרץ 2027. כדי לוודא שהמעבר יהיה חלק, צריך לבצע את שני השלבים הבאים:

  1. קודם צריך להשלים את ההעברה של קבוצות ההרשאות של SOAR ל-Cloud IAM.
  2. מעדכנים את הסקריפטים והשילובים הקיימים כדי להחליף את נקודות הקצה ל-API מדור קודם של SOAR בנקודות הקצה התואמות של Chronicle API.

אימות והרשאות

שאלה: איך מעבירים את ההרשאות וקבוצות ההרשאות של SOAR?

תצטרכו להשתמש בסקריפט העברה במסוף Google Cloud כדי להעביר קבוצות הרשאות קיימות לתפקידים בהתאמה אישית ב-IAM. הסקריפט גם מקצה תפקידים בהתאמה אישית למשתמשים (ללקוחות Cloud Identity) או לקבוצות IdP (ללקוחות של איחוד שירותי אימות הזהות של כוח העבודה).

שאלה: מה קורה אם אני מעדיף לא לבצע מיגרציה של קבוצות הרשאות בהתאמה אישית ולהשתמש רק בתפקידים מוגדרים מראש?

אתם יכולים לבטל את ההסכמה להעברה האוטומטית ולמפות באופן ידני קבוצות IdP לתפקידי Cloud IAM.

שאלה: אנחנו לקוחות של SOAR Standalone עם ספק SAML בהתאמה אישית ואימות ידני. אם נשנה את זה למיפוי של קבוצות IdP ל-IdP, איך זה ישפיע על חשבונות המשתמשים הקיימים?

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

שאלה: האם יש דרישות מוקדמות ספציפיות ל-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 המנוהל ימשיך לפעול.

לוגיסטיקה ותמיכה

שאלה: אפשר לבחור משבצת זמן אחרת להעברה?

לא. אי אפשר להעביר את הנתונים מחוץ למשבצות הזמן המוצעות.

שאלה: האם נקבל עדכוני סטטוס בזמן אמת במהלך ההעברה?

תקבלו התראה באימייל בתחילת תהליך ההעברה ובסופו.

שאלה: למי צריך לפנות אם נתקלים בבעיה אחרי ההעברה?

אם אתם נתקלים בבעיות גישה אחרי ההעברה, כנראה שהגדרת האימות לא נכונה. כדי לזהות את הבעיה ולפתור אותה, תצטרכו לפנות לאדמין של 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, ודאו שאתם משתמשים ב-IAM כדי לנהל תפקידים והרשאות בצד של SIEM בפלטפורמה. מידע נוסף זמין במדריך להעברת נתונים (מיגרציה) מ-RBAC מדור קודם ל-RBAC של תכונות.

שאלה: מופיעה הודעת שגיאה כשאני מנסה להריץ את הסקריפטים של ההעברה. מה עליי לעשות?

  • שגיאה – "הקבוצה לא קיימת": כשמשתמשים ב-add-iam-policy-binding commands, צריך לוודא שמשתמשים בכתובת האימייל המלאה של הקבוצה (לדוגמה, your-group@example.com) בדגל --member, ולא רק בשם הקצר של הקבוצה.

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

בעיות גישה אחרי ההעברה

שאלה: למה מופיעה הודעת השגיאה "403 Forbidden" כשאני מנסה לגשת לדפים או לתכונות מסוימים (כמו פלייבוקים או IDE) אחרי המעבר ל-IAM?

אם מופיעה שגיאה 403 אחרי המעבר, יכול להיות ש Google Cloud בתפקיד שהוקצה למשתמש שלכם ב-IAM חסרות הרשאות שנדרשות בצד של SOAR בפלטפורמת Google SecOps. זה קורה בדרך כלל כשמשתמשים בתפקידים בהתאמה אישית ב-IAM.

בודקים את התפקידים וההרשאות ב-Google SecOps. חשוב לוודא שהתפקיד בהתאמה אישית ב-IAM כולל את כל ההרשאות שנדרשות כדי לגשת לתכונות הנדרשות של SOAR.

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

אם אף אחד מהפתרונות האלה לא עוזר, פותחים כרטיס תמיכה.

הרשאות ותפקידים

שאלה: ביצעתי את ההעברה ל-IAM באופן ידני בלי להשתמש בכלי שסופק, ועכשיו יש לי בעיות בהרשאות. איך פותרים את הבעיה?

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

שאלה: נראה שלחלק מהמשתמשים יש יותר הרשאות ב-SOAR מהצפוי אחרי ההעברה. למה זה קורה?

זה יכול לקרות אם משתמשים או קבוצות כבר הוקצו לתפקידים רחבים Google Cloud מוגדרים מראש ב-Chronicle לפני ההעברה. אחרי שתשלימו את ההעברה, התפקידים המוגדרים מראש ב-Chronicle (כמו chronicle.apiAdmin) יכללו באופן אוטומטי את ההרשאות של SOAR. לדוגמה, התפקיד "אדמין של Chronicle API" יכלול מעכשיו הרשאות אדמין של SOAR.

כדי להבטיח גישה עם הרשאות מינימליות, צריך לבצע את השלבים הבאים:

  1. בדף IAM Roles, בודקים את התפקידים המוגדרים מראש, כולל Chronicle API Admin, כדי לזהות את כל החשבונות הראשיים שהוקצו (משתמשים וקבוצות).
  2. מוודאים שרק משתמשים שצריכים הרשאות SOAR מוקצים לתפקידים האלה.
  3. כדי להגביל את הגישה של חשבונות משתמשים ספציפיים ל-SOAR, צריך להסיר אותם מהתפקידים המוגדרים מראש ולהקצות להם תפקיד בהתאמה אישית שלא כולל הרשאות אדמין ב-SOAR.

שאלה: ההעברה הצליחה, אבל אני עדיין רואה את העמודה "קבוצות הרשאות" בדף "מיפוי קבוצות". למה?

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

שיטות מומלצות

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

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.