מעבר לגרסה 2 של Security Command Center API

בדף הזה מוסברים ההבדלים בין גרסה 1 (v1) לגרסה 2 (v2) של Security Command Center API. בנוסף, מוסבר במאמר איך לבצע מיגרציה ל-Security Command Center API בגרסה 2, בשילוב עם Security Command Center Management API בגרסה 1.

החל מ-9 בדצמבר 2024, אם מפעילים את Security Command Center בארגון בפעם הראשונה, אפשר להשתמש רק בגרסה 2 של Security Command Center API בארגון הזה. אין תמיכה בגרסאות קודמות.

אם הפעלתם את Security Command Center ברמת הפרויקט לפני 9 בדצמבר 2024, כל הפרויקטים שתפעילו באותו הארגון יתמכו בכל הגרסאות הזמינות של Security Command Center API.

לכל השילובים עם Security Command Center, מומלץ להשתמש ב-Security Command Center API בגרסה 2 וב-Security Command Center Management API בגרסה 1. מומלץ להשתמש בספריות הלקוח של Cloud או בספק Google Cloud Terraform כדי להתקשר לממשקי ה-API האלה. למידע נוסף, קראו את המאמרים הבאים:

ההבדלים בין גרסה 1 לגרסה 2 של ה-API

במהלך המעבר לגרסה 2 של Security Command Center API, חשוב לשים לב להבדלים הבאים מגרסה 1 של ה-API.

המיקום של נתונים

‫Security Command Center API גרסה 2 תומך במיקום נתונים, שמאפשר לכם לקבל יותר שליטה במיקום הנתונים שלכם ב-Security Command Center.

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

אם לא הפעלתם את התכונה 'שמירת נתונים במיקום מסוים' בארגון שלכם, מומלץ להתקשר לגרסה של כל שיטה שמתבססת על מיקום ולציין את globalהמיקום. כך יהיה קל יותר לאמץ את התכונה 'מיקום הנתונים' בעתיד.

כדי להשתמש בגרסה של כל שיטה שמתבססת על מיקום:

המסוף

Google Cloud המסוף משתמש בגרסה של כל שיטה שמתאימה למיקום כשצריך.

gcloud

כשמריצים פקודות ב-CLI של gcloud שמאפשרות לציין מיקום, כמו gcloud scc findings list, תמיד צריך לציין מיקום. יש כמה דרכים לעשות את זה:

  • משתמשים בדגל --location.
  • אם מציינים את הנתיב המלא של שם המשאב, צריך להשתמש בפורמט שמציין מיקום, כמו projects/123/sources/456/locations/global/findings/a1b2c3.

Terraform

תמיד צריך לציין את הארגומנט location למשאבים שתומכים בו, כמו google_scc_v2_organization_mute_config.

REST

מבצעים קריאה לגרסה של השיטה עם locations בשם שלה. לדוגמה, עדיף להשתמש ב-call organizations.locations.findings.bulkMute במקום ב-organizations.findings.bulkMute.

ספריות לקוח

אפשר לעיין בדוגמאות הקוד של Security Command Center או בהפניה ל-API של ספריית הלקוח.

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

הגדרות של התראות והגדרות של BigQuery Export

‫Security Command Center API בגרסה v1 מאפשר ליצור ולנהל את סוגי הגדרות הייצוא הבאים:

אפשר גם ליצור ולנהל את הגדרות הייצוא האלה באמצעות Security Command Center API בגרסה 2. עם זאת, אם תיצרו הגדרת ייצוא באמצעות Security Command Center API בגרסה 1, היא לא תופיע ב-Security Command Center API בגרסה 2. באופן דומה, אם יוצרים הגדרת ייצוא באמצעות Security Command Center API v2, היא לא תופיע ב-Security Command Center API v1.

בנוסף, אי אפשר להשתמש בשדה source_properties כדי לסנן ממצאים בהגדרות ייצוא שיוצרים באמצעות Security Command Center API בגרסה 2. צריך להשתמש בשדה אחר במקום.

המסוף

במסוף Google Cloud , אם נוצרה הגדרת ייצוא באמצעות Security Command Center API בגרסה 1, תוצג התווית Legacy. אפשר להשתמש במסוףGoogle Cloud כדי לנהל את המשאבים האלה.

אם יוצרים הגדרת ייצוא חדשה במסוף Google Cloud , היא תמיד נוצרת באמצעות Security Command Center API בגרסה 2.

gcloud

כדי לנהל הגדרות ייצוא שנוצרו באמצעות Security Command Center API בגרסה 1, לא מציינים מיקום כשמריצים פקודות של ה-CLI של gcloud כמו gcloud scc notifications describe:

  • לא משתמשים בדגל --location.
  • אם מספקים את הנתיב המלא למזהה התצורה, צריך להשתמש בפורמט שלא מציין מיקום, כמו organizations/123/notificationConfigs/456. אל תשתמשו בפורמט כמו organizations/123/locations/global/notificationConfigs/456.

באופן דומה, כדי ליצור או לנהל הגדרות ייצוא באמצעות Security Command Center API בגרסה 2, צריך לציין מיקום כשמריצים את ה-CLI של gcloud. כשיוצרים הגדרות חדשות, מומלץ להשתמש ב-Security Command Center API v2.

Terraform

בקובץ התצורה של Terraform מוגדרים משאבי ייצוא בגרסה 1 או בגרסה 2. לדוגמה, אפשר לעיין במשאבים בנושא הגדרות התראות:

כשיוצרים הגדרות חדשות, מומלץ ליצור משאבים בגרסה 2.

REST

כדי לנהל הגדרות ייצוא שנוצרו באמצעות Security Command Center API בגרסה 1, צריך להשתמש ב-Security Command Center API בגרסה 1.

כשיוצרים הגדרות חדשות, מומלץ להשתמש ב-Security Command Center API בגרסה 2.

ספריות לקוח

כדי לנהל הגדרות ייצוא שנוצרו באמצעות Security Command Center API בגרסה v1, צריך להשתמש בספריות הלקוח של Cloud עבור Security Command Center API בגרסה v1.

כשיוצרים הגדרות חדשות, מומלץ להשתמש ב-Security Command Center API בגרסה 2.

שירותים מובנים ומודולים בהתאמה אישית

גרסה 1 של Security Command Center API מאפשרת לכם להציג ולעדכן את סוגי המשאבים הבאים:

כדי לנהל את סוגי המשאבים האלה, משתמשים ב-Security Command Center Management API ובספריות הלקוח שלו. אי אפשר לנהל את סוגי המשאבים האלה באמצעות Security Command Center API בגרסה 2.

אם הארגון שלכם הפעיל את Security Command Center לפני 20 ביוני 2023, יכול להיות שאתם משתמשים ב-Security Command Center API בגרסה v1 כדי להציג נכסים בארגון, בתיקייה או בפרויקט. התכונות האלה של ניהול נכסים ב-Security Command Center הוצאו משימוש ולא זמינות בגרסה 2 של Security Command Center API. התכונות האלה יוסרו מגרסה 1 של Security Command Center API ב-20 ביוני 2024 או אחרי התאריך הזה.

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

אפשר גם להשתמש ב-Security Command Center API בגרסה 2 כדי לעדכן את תגי האבטחה של הנכסים. המתודות של Security Command Center API שמעדכנות את תגי האבטחה לא הוצאו משימוש.

עדכון ספריות לקוח וספק Terraform

כדי לעדכן את הקוד כך שישתמש ב-Security Command Center API v2:

Terraform

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

בנוסף, מעדכנים את קובץ התצורה של Terraform כדי ליצור משאבים שמתחילים בקידומת google_scc_v2_ או google_scc_management_. חשוב לזכור שאין שיתוף בין גרסה 1 לגרסה 2 של ה-API של מקורות המידע הבאים:

אם תפעילו תוכנית ביצוע של Terraform שמחליפה את המשאבים האלה במשאבים מקבילים מגרסה 2, Terraform תמחק את ההגדרות מגרסה 1 ותיצור הגדרות חדשות מגרסה 2.

C++

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

#include "google/cloud/securitycenter/v2/security_center_client.h"

בנוסף, צריך לעדכן את האפליקציה כדי להשתמש במחלקות במרחב השמות v2:

namespace securitycenter = ::google::cloud::securitycenter_v2;

C#

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

Install-Package Google.Cloud.SecurityCenter.V2

Go

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

go get cloud.google.com/go/securitycenter/apiv2

Java

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

בנוסף, צריך לעדכן את האפליקציה כדי להשתמש במחלקות, בממשקים ובסוגי הנתונים המנויים (enums) בחבילה com.google.cloud.securitycenter.v2.

Node.js

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

בנוסף, צריך לעדכן את האפליקציה כדי להשתמש ב-v2.SecurityCenterClient ובמחלקות, בממשקים ובסוגי הנתונים המנויים במרחב השמות protos.google.cloud.securitycenter.v2.

PHP

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

בנוסף, צריך לעדכן את האפליקציה כדי להשתמש במחלקות ובסוגי הנתונים המנויים (enum) ב-מרחב השמות Google \ Cloud \ SecurityCenter \ V2.

Python

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

בנוסף, צריך לעדכן את האפליקציה כדי להשתמש במחלקות בחבילה google.cloud.securitycenter_v2.

Ruby

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

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

אם אתם צריכים לנהל באופן פרוגרמטי את השירותים המובנים של Security Command Center ואת מצבי ההפעלה שלהם, או מודולים בהתאמה אישית ל-Event Threat Detection או ל-Security Health Analytics, אתם צריכים גם להתקין ספריית לקוח ל-Security Command Center Management API ולעדכן את האפליקציה כך שתשתמש בספריית הלקוח הזו.