מעבר ל-Chronicle API

נתמך ב:

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

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

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

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

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

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

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

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

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

הגרסה הקודמת של SOAR API מתוכננת לצאת משימוש באופן סופי ב-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.

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

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

  3. ממלאים את השדות בתיבת הדו-שיח Add Mapping (הוספת מיפוי) כדי למפות את הזהות לפרמטרים של בקרת הגישה בפלטפורמה.

    1. בשדה IdP / User group (ספק זהויות / קבוצת משתמשים), מזינים אחת מהאפשרויות הבאות:
      • כתובת האימייל המלאה של חשבון השירות, אם הזהות הוגדרה באמצעות Cloud Identity.
      • מחרוזת של נציג אינטרס של Workload Identity, אם הזהות הוגדרה באמצעות איחוד שירותי אימות הזהות של כוח העבודה.

    2. מגדירים את השדות הבאים של בקרת הגישה:

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

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

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

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

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

בדיקת השילוב

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

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

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