סקירה כללית על המעבר ל-SOAR

נתמך ב:

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

ההעברה הזו נדרשת כדי לספק שדרוגים קריטיים לתשתית, כולל אמינות משופרת, אבטחה משופרת, תאימות רחבה יותר ובקרת גישה מפורטת יותר. הוא גם מאפשר גישה ליכולות של AI אקטיבי באמצעות שילוב של Model Context Protocol‏ (MCP) ושירותים מובילים, כולל IAM לבקרת גישה, Cloud Monitoring ויומני ביקורת של Cloud.

ההעברה מתבצעת בשני שלבים – שלב 1 ושלב 2.

שלב 1 כולל את ההעברות הבאות:

  • העברת פרויקט ה-SOAR שבבעלות Google לתשתית של Google Cloud . ‫Google מבצעת את התהליך הזה.
  • העברת האימות של SOAR אל Google Cloud (רלוונטי רק ללקוחות של SOAR Standalone).

שלב 2 כולל את ההעברות הבאות:

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

איך בודקים שההעברה בוצעה בהצלחה

  • כדי לוודא ששלב 1 הושלם בהצלחה, עוברים אל הגדרות SOAR > ניהול רישיונות ומוודאים שמופיע הכיתוב Google.com אחרי מספר הגרסה של המערכת.

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

שלב 1 בתהליך המעבר ללקוחות Google SecOps Unified

כדי לבדוק את תאריך ההעברה של שלב 1, צריך לעיין בהתראה במוצר. כדי לאשר את משבצת הזמן, צריך למלא את הטופס המצורף של Google Forms. שלב 1 כולל את ההעברות הבאות.

  • העברת פרויקט SOAR שבבעלות Google אל Google Cloud

ההעברה כוללת זמן השבתה של עד 90 דקות, שבהן פלטפורמת Google SecOps לא נגישה. במהלך ההשבתה, שירותי ה-SIEM ימשיכו לפעול ברקע, אבל שירותי ה-SOAR יושהו באופן זמני. אחרי זמן ההשבתה, הפלטפורמה תהיה נגישה ושירותי SOAR ימשיכו לעבד את כל ההתראות שנוצרו או נטמעו במהלך זמן ההשבתה.

כשההעברה תסתיים, נשלח לך אימייל.

שלב 1 בהעברה ללקוחות SOAR עצמאיים

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

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

  • אפשרות 2 – פריסת מכונה חדשה של Google SecOps: אם אין לכם מכונת SIEM קיימת או שאתם צריכים להפריד בין הפריסות של SOAR ו-SIEM, אתם יכולים לפרוס מכונה חדשה של Google SecOps בפרויקט Google Cloud ייעודי.

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

  1. מזהים או מגדירים את הפרויקט ב- Google Cloud בהתאם לאפשרות ההעברה שנבחרה:
    • אפשרות 1 (איחוד עם SIEM קיים): משתמשים בפרויקט הקיים ב- Google Cloud שמקושר למכונה של SIEM.
    • אפשרות 2 (פריסת מכונה חדשה של Google SecOps): מגדירים פרויקט ב- Google Cloud . אתם יכולים גם להשתמש Google Cloud בפרויקט שהוגדר כדי לגשת לתמיכה של Google SecOps, אבל עדיין אין לו מכונה של Google Security Operations.
  2. מפעילים את Chronicle API בפרויקט ב- Google Cloud (אם הוא עדיין לא מופעל).
  3. מגדירים אימות ב- Google Cloud כדי לגשת ל-SOAR. איך מגדירים אימות כדי לגשת ל-SOAR Google Cloud
  4. מזינים את מזהה הפרויקט Google Cloud בטופס ב-Google Forms שבהודעה במוצר, ומאשרים את התאריך ואת משבצת הזמן של ההעברה לפני ששולחים את הטופס.
  5. מאשרים את ההזמנה באימייל לדף "Get Google Security Operations" ומשלימים את ההגדרה (אם פורסים מכונה חדשה של Google SecOps). חשוב לוודא שפרטי האזור מדויקים.
  6. כדי לוודא שהשלבים הקודמים הוגדרו בצורה נכונה, אפשר לעיין במדריך לאימות לפני ההעברה.

אחרי שתסיימו את השלבים, Google תבצע את ההעברה בתאריך ובשעה שקבעתם. ההעברה דורשת כ-2 שעות של השבתה של שירותי SOAR. בסיום התהליך, תקבלו אימייל עם כתובת ה-URL החדשה לגישה לפלטפורמת SOAR. כתובת ה-URL הישנה תמשיך לפעול עד 30 ביוני 2026, ותפנה לכתובת ה-URL החדשה.

הגדרת אימות Google Cloud כדי לגשת ל-SOAR

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

אפשרות 1: הגדרת אימות של Cloud Identity ב- Google Cloud (חשבונות בניהול Google)

התרחיש הזה רלוונטי אם אתם מנהלים את חשבונות המשתמשים ישירות ב-Cloud Identity, באמצעות שמות משתמשים וסיסמאות שמנוהלים על ידי Google. היא לא חלה אם אתם משתמשים ב-Cloud Identity לכניסה יחידה (SSO) עם ספק זהויות של צד שלישי, כמו Okta או Azure AD.

כך עושים את זה:

  1. הגדרת Cloud Identity ב- Google Cloud.

    אתם יכולים לדלג על השלב הזה אם כבר הגדרתם את Cloud Identity עם שם משתמש וסיסמה בניהול Google.

  2. מוודאים שכל משתמשי ה-SOAR הקיימים מוגדרים במסוף Admin של Cloud Identity.

  3. מקצים את התפקידים הנדרשים ב-IAM לפי הפורמט של הקצאת תפקידים לחשבונות Google.

    1. מקצים את תפקידי ה-IAM המוגדרים מראש הבאים ב- Google Cloud למומחה התוכן שמצטרף:

    2. מקצים את אחד מהתפקידים המוגדרים מראש הבאים ב-IAM לכל משתמשי ה-SOAR הקיימים:

  4. כדי להשלים את הגדרת האימות ב-SOAR, ממפים כל משתמש (כולל אדמינים) לקבוצת משתמשים באימייל.

    1. עוברים אל SOAR Settings > Advanced > Group Mapping.

    2. לוחצים על הוספה Add וממלאים את הפרטים הבאים:

      • ספק זהויות (IdP) / קבוצת משתמשים: השם של קבוצת המשתמשים באימייל (למשל מנתחי נתונים T1).
      • קבוצות הרשאות: בוחרים את קבוצות ההרשאות.
      • תפקידי SOC: בוחרים את תפקידי ה-SOC.
      • סביבות: בוחרים את הסביבות (למשל כל הסביבות).
      • חברי הקבוצה: מזינים את כתובות האימייל של המשתמשים הרלוונטיים. לוחצים על Enter אחרי כל כתובת אימייל שמוסיפים.

    3. לוחצים על הוספה.

      בכל פעם שמשתמש נכנס לפלטפורמה, הוא מתווסף באופן אוטומטי לדף SOAR Settings > Organization > User Management. המופע שהועבר שומר על המיפויים האלה, שמשמשים כבסיס לקביעת הגישה של המשתמשים ל-SOAR. כדי שכל משתמש יוכל לגשת ל-Google SecOps, צריך לוודא שהוא ממופה בדף הזה.

אפשרות 2: הגדרת אימות של איחוד שירותי אימות הזהות של כוח העבודה ב- Google Cloud

התרחיש הזה רלוונטי אם אתם מנהלים את זהויות המשתמשים באמצעות ספקי זהויות של צד שלישי, כמו Microsoft Azure Active Directory,‏ Okta,‏ Ping Identity ו-AD FS.

  1. מגדירים את איחוד שירותי אימות הזהות של כוח העבודה ב- Google Cloud. אם כבר הגדרתם את האיחוד, אתם יכולים לדלג על השלב הזה.
  2. מוודאים שכל המשתמשים הקיימים ב-SOAR הם חלק מהקבוצות של מאגר כוח העבודה שהוגדרו באיחוד שירותי אימות הזהות של כוח העבודה.

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

    1. מקצים את כל התפקידים המוגדרים מראש הבאים ב-IAM למומחה התוכן שמצטרף.

    2. מקצים אחד מהתפקידים הבאים ב-IAM לכל משתמשי ה-SOAR הקיימים:

  4. משלימים את הגדרת האימות ב-SOAR על ידי מיפוי כל הקבוצות של ספק הזהויות שצריכות גישה ל-SOAR.

    מוודאים שהמשתמשים הקיימים ממופים לפחות לאחת מהקבוצות של ספק הזהויות.

    1. עוברים אל SOAR Settings > Advanced > Group Mapping.
    2. לוחצים על הוספה וממלאים את הפרטים הבאים:
      • ספק זהויות (IdP) / קבוצת משתמשים: מזינים את שם הקבוצה מספק הזהויות.
      • קבוצות הרשאות: בוחרים את קבוצות ההרשאות.
      • תפקידי SOC: בוחרים את תפקידי ה-SOC.
      • סביבות: בוחרים את הסביבות (למשל כל הסביבות).
    3. מוודאים שהוספתם את קבוצת ה-IdP של האדמין עם הרשאות אדמין לקבוצות ההרשאות, לתפקידי SOC ובוחרים באפשרות "כל הסביבות".
    4. אם יש לכם מיפויים קיימים של קבוצות IdP בדף External Authentication, כדאי להשאיר אותם כמו שהם כדי לא לשנות את אימות ה-SOAR הקיים. כדי שהאימות החדש Google Cloud יאפשר גישה ל-SOAR, עדיין צריך להגדיר מיפוי קבוצות של ספק הזהויות בדף הגדרות > הגדרות SOAR > מתקדם > מיפוי קבוצות.
    5. לוחצים על הוספה. בכל פעם שמשתמש נכנס לפלטפורמה, הוא מתווסף באופן אוטומטי לדף הגדרות > ארגון > ניהול משתמשים. המופע שהועבר שומר על המיפויים האלה, שמשמשים כבסיס לקביעת הגישה של המשתמשים ל-SOAR. כדי שכל משתמש יוכל לגשת ל-Google SecOps, צריך לוודא שהוא ממופה בדף הזה.

שלב 2 בהעברה לכל הלקוחות

חשוב: צריך להשלים את שלב 1 לפני שמתחילים את ההעברה של שלב 2.

החל מ-26 בינואר 2026, שלב 2 של ההעברה זמין לכלל המשתמשים.

המועד האחרון להשלמת המעבר של שלב 2 לתפקידי IAM הוא 30 בנובמבר 2026. המועד האחרון להעברת ה-API נדחה ל-31 במרץ 2027.

העברת קבוצות ההרשאות של SOAR ל- Google Cloud IAM

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

במאמר העברת הרשאות SOAR ל- Google Cloud IAM מוסבר בהרחבה על סקריפט ההעברה ועל הפקודות של Terraform.

מידע נוסף על הגדרת הרשאות זמין במאמר הגדרת גישה לתכונות.

אחרי העברת ההרשאות, קורים הדברים הבאים:

  • הדף הגדרות SOAR > ארגון > הרשאות עדיין זמין עד 31 במרץ 2027 (כדי לשמור על תאימות לדורות קודמים עם ממשקי API מדור קודם). אל תבצעו שינויים בדף הזה. כל ההרשאות מנוהלות באמצעות IAM.
  • העמודה קבוצת הרשאות בדף מיפוי קבוצות מוצגת לצורך תאימות לדורות קודמים עם SOAR API מדור קודם. אל תמחקו את המטלות האלה. העמודה תוסר באופן אוטומטי עד 31 במרץ 2027 בלי להשפיע על הלקוחות.
  • הקטע "פעולות מוגבלות" בדף הרשאות יועבר לדף מיפוי קבוצות.

העברת ממשקי SOAR API אל Chronicle API

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

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

העברת תגובות לפעולה מאתר אחר (webhook)

כדי להעביר את ה-webhooks של SOAR ל-Chronicle API, צריך לבצע את הפעולות הבאות לפני 31 במרץ 2027:

מעדכנים את כתובת ה-webhook בצד הלקוח: מחליפים את הדומיין הקודם siemplify-soar.com בדומיין החדש googleapis.com באמצעות פורמט הבקשה החדש. הדומיין הקודם siemplify-soar.com ימשיך לפעול עד 31 במרץ 2027.

לדוגמה, webhook שמוגדר בכתובת: https://xxxx.siemplify-soar.com/api/external/v1/webhooks/{webhook_id}?api_key=xxxx

צריך לעדכן את הכתובת ל: https://us-chronicle.googleapis.com/v1alpha/projects/{project_id}/locations/{location}/instances/{instance/{instance_id}/webhooks/{webhook_id}?api_key=xxxx

האימות של ה-webhooks נשאר ללא שינוי. ה-Webhooks ממשיכים להשתמש במפתח ה-API שנוצר בהתחלה לצד הקישור ל-Webhook.

העברת תשתית האימות של הסוכן המרוחק

בשלבים הבאים מוסבר איך להעביר את תשתית האימות של הסוכנים המרוחקים לאימות באמצעות חשבון שירות ב- Google Cloud . בתהליך הזה לא צריך להעביר או להחליף את המארחים או המכונות של Remote Agent.

  1. יוצרים חשבון שירות במקום מפתח API לסוכן המרוחק.
  2. שדרוג גרסה ראשית של הסוכן המרוחק.

סוכנים מרוחקים קיימים יהיו זמינים עד 30 בנובמבר 2026, ואחרי התאריך הזה הם יפסיקו לפעול. הוראות מפורטות זמינות במאמר העברת סוכנים מרוחקים ל-Google Cloud.

ההשפעה על יומני הביקורת של SOAR

יומני SOAR יהיו זמינים ב- Google Cloud אחרי שתשלימו את העברת ההרשאות ל-IAM. כל הקריאות ל-API הקודם של SOAR עד 31 במרץ 2027 יישארו נגישות ביומני הביקורת של SOAR. לקוחות Google SecOps יכולים לעיין במאמר איסוף יומנים של Google SecOps SOAR. לקוחות SOAR עצמאיים, ראו איסוף יומני SOAR

שינויים נוספים אחרי ההעברה:

סוג הרישיון סוג הרישיון נקבע עכשיו לפי ההרשאות שהוקצו למשתמש ב-IAM.

דף נחיתה דף הנחיתה יעבור מהדף "הרשאות" לתפריט העדפות משתמש, שאפשר לגשת אליו מהדמות שלכם.

המאמרים הבאים

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