העברת נקודות קצה של SOAR ל-Chronicle API

נתמך ב:

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

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

ממשק ה-API של SOAR מהדור הקודם ומפתחות ה-API יהיו זמינים עד 30 בספטמבר 2026. אחרי התאריך הזה הם יפסיקו לפעול.

דרישות מוקדמות

לפני שמבצעים את ההעברה של SOAR API, צריך לבצע את הפעולות הבאות:

שינויים ושיפורים מרכזיים

בטבלה הבאה מפורטים ההבדלים העיקריים בין הגרסה הישנה לגרסה החדשה של ממשקי ה-API:

אזור התכונה Old API ממשק API חדש פרטים
אימות טוקן API OAuth 2.0 שיטת האימות החדשה משפרת את האבטחה ומייעלת את התהליך.
מודלים של נתונים מבנים שטוחים עיצוב מבוסס-משאבים העיצוב החדש משפר את העקביות של הנתונים ומפשט את הטיפול באובייקטים.
מתן שמות לנקודות קצה לא עקבי RESTful וסטנדרטי שיטה עקבית למתן שמות הופכת את ה-API לאינטואיטיבי יותר וקל יותר לשילוב.

תזמון שהוצא משימוש

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

שלבים בהעברה

בקטע הזה מפורטים השלבים להעברת האפליקציות שלכם ל-Chronicle API:

עיון בתיעוד

חשוב לקרוא את מאמרי העזרה המקיפים של ה-API החדש, כולל מדריך ה-API של Chronicle.

מיפוי נקודות קצה (endpoints) לממשק API חדש

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

אופציונלי: יצירת שילוב לצורך בדיקה

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

עדכון נקודת הקצה של השירות וכתובות ה-URL

נקודת קצה של שירות היא כתובת ה-URL הבסיסית שמציינת את כתובת הרשת של שירות API. לשירות אחד יכולים להיות כמה נקודות קצה של שירות. ‫Chronicle הוא שירות אזורי, והוא תומך רק בנקודות קצה אזוריות.

לכל נקודות הקצה החדשות יש קידומת עקבית, כך שכתובת נקודת הקצה הסופית צפויה. בדוגמה הבאה מוצג המבנה החדש של כתובת ה-URL של נקודת הקצה:

[api_version]/projects/[project_id]/locations/[location]/instances[instance_id]/...

המבנה הזה יוצר את הכתובת הסופית לנקודת הקצה באופן הבא:

https://[service_endpoint]/[api_version]/projects/[project_id]/locations/[location]/instances/[instance_id]/...

כאשר:

  • service_endpoint: כתובת למקרי חירום אזורית
  • ‫api_version: גרסת ה-API שאליה רוצים לשלוח שאילתה. האפשרויות הן v1alpha,‏ v1beta או v1.
  • ‫project_id: מזהה הפרויקט (אותו פרויקט שהגדרתם להרשאות IAM)
  • ‫location: המיקום של הפרויקט (אזור); זהה לנקודות הקצה האזוריות
  • ‫instance_id: מספר הלקוח שלכם ב-Google Security Operations SIEM.

כתובות אזוריות:

  • ‫africa-south1: ‏ https://chronicle.africa-south1.rep.googleapis.com

  • ‫asia-northeast1: ‏ https://chronicle.asia-northeast1.rep.googleapis.com

  • ‫asia-south1: ‏ https://chronicle.asia-south1.rep.googleapis.com

  • ‫asia-southeast1: https://chronicle.asia-southeast1.rep.googleapis.com

  • ‫asia-southeast2: ‏ https://chronicle.asia-southeast2.rep.googleapis.com

  • ‫australia-southeast1: ‏ https://chronicle.australia-southeast1.rep.googleapis.com

  • europe-west12: https://chronicle.europe-west12.rep.googleapis.com

  • ‫europe-west2: ‏ https://chronicle.europe-west2.rep.googleapis.com

  • ‫europe-west3: ‏ https://chronicle.europe-west3.rep.googleapis.com

  • ‫europe-west6: ‏ https://chronicle.europe-west6.rep.googleapis.com

  • europe-west9: https://chronicle.europe-west9.rep.googleapis.com

  • me-central1: https://chronicle.me-central1.rep.googleapis.com

  • me-central2: https://chronicle.me-central2.rep.googleapis.com

  • me-west1: https://chronicle.me-west1.rep.googleapis.com

  • ‫northamerica-northeast2: ‏ https://chronicle.northamerica-northeast2.rep.googleapis.com

  • ‫southamerica-east1: https://chronicle.southamerica-east1.rep.googleapis.com

  • us: https://chronicle.us.rep.googleapis.com

  • eu: https://chronicle.eu.rep.googleapis.com

לדוגמה, כדי לקבל רשימה של כל בקשות התמיכה בפרויקט בארה"ב:

GET 
  https://chronicle.us.rep.googleapis.com/v1alpha/projects/my-project-name-or-id/locations/us/instances/408bfb7b-5746-4a50-885a-50a323023529/cases

עדכון שיטת האימות

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

מיפוי חשבון השירות או Workload Identity לפרמטרים של SOAR

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

כדי למפות את חשבון השירות:

  1. עוברים אל SOAR Settings > Advanced > Group Mapping (הגדרות SOAR > מתקדם > מיפוי קבוצות).

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

  3. בתיבת הדו-שיח Add Role, מזינים את כתובת האימייל המלאה של חשבון השירות או את מחרוזת הנציג של Workload Identity בשדה IAM Role / IdP group.

  4. בוחרים את התפקידים והסביבות המתאימים ב-SOC.

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

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

עדכון הלוגיקה של ה-API

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

בדיקת השילוב

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

  1. יוצרים תוכנית בדיקה: מגדירים תרחישי בדיקה שמכסים את כל הפונקציות שהועברו.
  2. ביצוע בדיקות: מריצים בדיקות אוטומטיות וידניות כדי לוודא שהנתונים מדויקים ותקפים.
  3. מעקב אחרי הביצועים: הערכת הביצועים של האפליקציה באמצעות ה-API החדש.

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