פריסת מופע

נתמך ב:

Google secops

במאמר הזה מוסבר איך להטמיע (לפרוס) מופע של Google SecOps‏ (SIEM ו-SOAR) ואיך להפעיל את התכונות של Google SecOps בהתאם לרמת החבילה ולזכויות שלכם ב-Google SecOps. השלבים האלה להצטרפות רלוונטיים לחבילות Google SecOps הבאות: Standard,‏ Enterprise ו-Enterprise Plus.

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

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

לפני שמצטרפים למופע חדש של Google SecOps, צריך לוודא שהארגון עומד בדרישות המוקדמות הבאות:

• רישום פעיל לאחד מחבילות Google SecOps הבאות: ‫Standard,‏ Enterprise או Enterprise Plus.

• חוזה חתום של Google SecOps מהארגון שלכם. החוזה הזה מאפשר לכם להקצות כל מופע חדש של Google SecOps.

• אם בארגון שלכם משתמשים ב-VPC Service Controls, אתם צריכים להגדיר את כללי התעבורה הנכנסת והיוצאת הרלוונטיים, שמתועדים במאמר הגדרת VPC Service Controls ל-Google SecOps.

פריסת מופע חדש של Google SecOps

כדי לפרוס מופע חדש של Google SecOps:

1. חותמים על החוזה של Google SecOps.

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

2. הכנת הסביבה להצטרפות.

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

3. הצטרפות למופע חדש של Google SecOps.

4. פריסת מופעים נוספים.

הכנת הסביבה להצטרפות

מומחה ההצטרפות צריך להכין את הסביבה שלכם לפני ההצטרפות למופע של Google SecOps, כמו שמתואר בקטעים הבאים:

1. מתן הרשאות לביצוע הצטרפות.
2. הגדרת תיקייה ב-Assured Workloads (אופציונלי)
3. הגדרת Google Cloud פרויקט.
4. הגדרת ספק זהויות

מתן הרשאות להפעלת תהליך ההצטרפות

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

הגדרה של תיקיית Assured Workloads (אופציונלי)

כדי ליצור תיקיית Assured Workloads:

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

4. פועלים לפי השלבים שבקטע יצירת תיקיית Assured Workloads עבור....

   הערה: אם אתם מנהלים כמה ארגונים, צריך לבחור את הארגון הנכון שבו תיקיית Assured Workloads צריכה להיווצר. בשדה region, בוחרים באפשרות US, שמתאימה לUS multi-region.

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

• דייר (מופע) שנשלט על ידי תאימות הוא דייר שחייב לעמוד באחד או יותר מהתקנים הבאים של בקרת תאימות: FedRAMP,‏ FedRAMP_MODERATE,‏ PCI_DSS,‏ FedRAMP_HIGH,‏ IL4,‏ IL5,‏ CMEK_V1 או DRZ_ADVANCED.

• כל הקבצים שמשויכים לדייר עם בקרת תאימות צריכים להיות בתיקייה של Assured Workloads שמוגדרת בהתאם לתקן המתאים של בקרת התאימות.

• תיקיית Assured Workloads נוצרת ברמת הארגון.

• ארגון יכול ליצור כמה תיקיות של Assured Workloads, כשכל אחת מהן מוקדשת לחבילת אמצעי בקרה ספציפית לתאימות על סמך הדרישות שלה. לדוגמה, תיקייה אחת יכולה לתמוך במופעים של FedRAMP_MODERATE, ותיקייה אחרת יכולה לתמוך במופעים של FedRAMP_HIGH.

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

• צריך לקשר את הדייר (המופע) עם אמצעי הבקרה לתאימות ל Google Cloudפרויקט שנמצא בתיקייה של Assured Workloads.

• אם אתם מתכננים ליצור פרויקט חדש Google Cloud למופע של Google SecOps, אתם צריכים ליצור את הפרויקט בתיקייה של Assured Workloads שהוגדרה לחבילת בקרת התאימות הנדרשת.

• אם לארגון שלכם אין תיקיית Assured Workloads, אתם צריכים ליצור אחת.

כל מופע חדש של Google SecOps צריך להיות מקושר לGoogle Cloud פרויקט. אפשר להשתמש בפרויקט קיים Google Cloud או ליצור פרויקט חדש.

כדי ליצור Google Cloud פרויקט חדש:

1. בדייר (מופע) שתואם ל-FedRAMP, יוצרים את הפרויקט בתיקיית Assured Workloads של הארגון. אם לארגון שלכם אין תיקייה של Assured Workloads לחבילת הבקרה הנדרשת, צריך ליצור אחת.

2. פועלים לפי השלבים במאמר בנושא יצירת פרויקט.

   הערה: צריך להשתמש במוסכמת השמות <CUSTOMER-name>-chronicle ולוודא שהחשבון לחיוב של הפרויקט זהה לחשבון לחיוב של מופע Google SecOps.
   הערה: כדי להקצות חיובים לחשבון אחר לחיוב, צריך להזין הזמנה חדשה.

הגדרת Google Cloud פרויקט

Google Cloud פרויקט משמש כשכבת הבקרה של מופע Google SecOps המקושר.

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

הגדרת ספק זהויות

הגדרת ספק זהויות לניהול משתמשים, קבוצות ואימות עבור מופע Google SecOps.

יש שתי אפשרויות נתמכות:

• אפשרות 1: Google Cloud זהות:

  משתמשים באפשרות הזו אם יש לכם חשבון Google Workspace או אם אתם מסנכרנים זהויות מספק ה-IdP שלכם אל Google Cloud.

  1. יצירת חשבונות משתמשים מנוהלים כדי לשלוט בגישה למשאבים של Google Cloud ולמופע של Google SecOps.

  2. הגדרת כללי מדיניות ב-IAM באמצעות תפקידים מוגדרים מראש או תפקידים בהתאמה אישית, כדי להעניק למשתמשים ולקבוצות גישה לפיצ'רים.

  הוראות מפורטות זמינות במאמר בנושא הגדרת ספק Google Cloud זהויות.

  הערה: האפשרות הזו לא נתמכת עבור לקוחות שעומדים בדרישות של FedRAMP,‏ IL4 או IL5.

• אפשרות 2: איחוד שירותי אימות הזהות של כוח עבודה:

  כדאי להשתמש באפשרות הזו אם אתם משתמשים ב-IdP של צד שלישי (כמו Okta או Azure AD).

  מגדירים את איחוד שירותי אימות הזהות של כוח העבודה של Google ויוצרים מאגר זהויות של כוח עבודה. השירות המשולב לזיהוי עומסי עבודה של Google מאפשר לתת לעומסי עבודה מקומיים או מרובי עננים (multi-cloud) גישה למשאבים של Google Cloud , בלי להשתמש במפתחות של חשבונות שירות.

  הוראות מפורטות מופיעות במאמר בנושא הגדרת ספק זהויות של צד שלישי.

הוספת מופע חדש של Google SecOps

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

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

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

• לוחצים על קישור ההפעלה באימייל ההזמנה.

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

  1. מגדירים מכונת Google SecOps חדשה ומקשרים אותה ל Google Cloud פרויקט.
  2. הגדרת גישה לפיצ'רים באמצעות IAM
  3. הגדרת RBAC לנתונים עבור משתמשים.
  4. מיפוי קבוצות ב-IdP לפרמטרים של בקרת גישה כדי להשלים את הפריסה.

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

בקטע הזה מפורטים התפקידים וההרשאות שנדרשים לפריסת מופע של Google SecOps. נותנים את ההרשאות האלה למומחה בנושא הצטרפות שמבצע את משימות הפריסה:

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

נותנים למומחה להטמעה את התפקידים וההרשאות שמפורטים בקטעים הבאים:

1. הרשאות בחשבון לחיוב ב-Google
2. תפקידי IAM מוגדרים מראש
3. הרשאות ליצירת תיקיית Assured Workloads
4. הרשאות להוספת Google Cloud פרויקט
5. הרשאות להגדרת ספק זהויות
   1. הרשאות להגדרת Cloud Identity או Google Workspace
   2. הרשאות להגדרת ספק זהויות של צד שלישי
6. הרשאות לקישור מופע של Google SecOps אל Google Cloud שירותים
7. הרשאות להגדרת גישה לפיצ'רים באמצעות IAM
8. הרשאות להגדרת בקרת גישה לנתונים
9. הדרישות לשימוש ביכולות המתקדמות של Google SecOps

הרשאות בחשבון לחיוב ב-Google

מעניקים למומחה להטמעה את ההרשאה billing.resourceAssociations.list בחשבון לחיוב ב-Google שצוין בחוזה. הוראות מפורטות זמינות במאמר בנושא עדכון הרשאות משתמשים בחשבון לחיוב ב-Cloud.

תפקידים מוגדרים מראש ב-IAM

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

• Chronicle API Admin
• אדמין של שירות Chronicle

• אדמין Chronicle SOAR

  הערה: צריך להעניק את תפקיד ה-IAM גם כשפורסים מופע שאינו SOAR.

הרשאות ליצירת תיקיית Assured Workloads

הערה: ההרשאות האלה נדרשות כדי לבצע את השלבים במאמר יצירת תיקייה חדשה של Assured Workloads.

נותנים למומחה להטמעה את התפקיד Assured Workloads Administrator (roles/assuredworkloads.admin), שכולל את הרשאות ה-IAM המינימליות ליצירה ולניהול של תיקיות Assured Workloads.

הרשאות להוספת פרויקט Google Cloud

הערה: ההרשאות האלה ב-IAM נדרשות כדי לבצע את השלבים במאמר הגדרת פרויקט Google Cloud ל-Google SecOps.

נותנים למומחה להטמעה את ההרשאות ליצירת פרויקט שנדרשות כדי ליצור Google Cloud פרויקט ולהפעיל את Chronicle API:

• אם למומחה בנושא צירוף משתמשים יש הרשאות ליצירת פרויקטים (resourcemanager.projects.create) ברמת הארגון, לא נדרשות הרשאות נוספות.

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

  • אדמין של שירות Chronicle‏ (roles/chroniclesm.admin) (אם התפקיד הזה לא הוקצה קודם)
  • עריכה (roles/editor)
  • אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin)
  • אדמין של Service Usage (roles/serviceusage.serviceUsageAdmin)

הרשאות להגדרת ספק זהויות

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

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

הרשאות להגדרת Cloud Identity או Google Workspace

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

• אם בחרתם ב-Cloud Identity:

  אם אתם משתמשים ב-Cloud Identity, צריך להעניק למומחה להטמעה את התפקידים וההרשאות שמתוארים במאמר ניהול גישה לפרויקטים, לתיקיות ולארגונים.

• ל-Google Workspace:

  אם אתם משתמשים ב-Google Workspace, למומחה להטמעה צריך להיות חשבון אדמין ב-Cloud Identity, והוא צריך להיות מסוגל להיכנס למסוף Admin.

מידע נוסף על שימוש ב-Cloud Identity או ב-Google Workspace כספק הזהויות זמין במאמר הגדרת Google Cloud ספק הזהויות.

הרשאות להגדרת ספק זהויות (IdP) של צד שלישי

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

הערה: ההרשאות האלה נדרשות כדי לבצע את השלבים במאמר הגדרת ספק זהויות (IdP) של צד שלישי.

מקצים למומחה בנושא צירוף משתמשים את תפקידי ה-IAM וההרשאות הבאים:

• עריכה (roles/editor): הרשאות עריכת פרויקט בפרויקט שקשור ל-Google SecOps.

• הרשאה IAM Workforce Pool Admin (roles/iam.workforcePoolAdmin) ברמת הארגון.

  בדוגמה הבאה מוגדר התפקיד roles/iam.workforcePoolAdmin:

    gcloud organizations add-iam-policy-binding ORGANIZATION_ID \
    --member "user:USER_EMAIL" \
    --role roles/iam.workforcePoolAdmin
  

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

  • ‫ORGANIZATION_ID: מזהה הארגון (מספרי).
  • USER_EMAIL: כתובת האימייל של האדמין.

• ההרשאה צפייה בארגון (resourcemanager.organizations.get) ברמת הארגון.

הרשאות לקישור מופע של Google SecOps אל Google Cloud שירותים

הערה: ההרשאות האלה נדרשות כדי לבצע את השלבים במאמר קישור שירותים ל-Google SecOps Google Cloud .

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

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

הרשאות להגדרת בקרת גישה לפיצ'רים באמצעות IAM

הערה: ההרשאות האלה נדרשות כדי לבצע את השלבים במאמר הגדרת גישה לפיצ'רים באמצעות IAM.

• מקצים למומחה להטמעה את התפקיד אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin) ברמת הפרויקט. ההרשאה הזו נדרשת כדי להקצות ולשנות קישורי תפקידים ב-IAM לפרויקט.

• הקצאת תפקידים ב-IAM למשתמשים על סמך תחומי האחריות שלהם. דוגמאות מופיעות במאמר הקצאת תפקידים למשתמשים ולקבוצות.

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

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

הערה: ההרשאות האלה נדרשות כדי להגדיר בקרת גישה מבוססת-תפקידים (RBAC) לנתונים עבור משתמשים.

נותנים למומחה להטמעה את תפקידי ה-IAM הבאים:

• התפקידים 'אדמין Chronicle API' (roles/chronicle.admin) ו'צפייה בתפקידים' (roles/iam.roleViewer), להגדרת RBAC של נתונים למשתמשים.
• התפקיד 'אדמין IAM בפרויקט' (roles/resourcemanager.projectIamAdmin) או 'אדמין אבטחה' (roles/iam.securityAdmin), כדי להקצות את ההיקפים למשתמשים.

אם אין לכם את התפקידים הנדרשים, מקצים את התפקידים ב-IAM.

הדרישות לשימוש ביכולות המתקדמות של Google SecOps

בטבלה הבאה מפורטות היכולות המתקדמות של Google SecOps והתלות שלהן ב Google Cloud פרויקט שסופק על ידי הלקוח ובאיחוד שירותי אימות הזהות של כוח העבודה של Google.

יכולת	Google Cloud foundation	נדרש Google Cloud פרויקט?	האם נדרש שילוב עם IAM?
יומני ביקורת של Cloud: פעילויות אדמין	יומני ביקורת של Cloud	כן	כן
יומני ביקורת של Cloud: גישה לנתונים	יומני ביקורת של Cloud	כן	כן
חיוב ב-Cloud: מינוי אונליין או תשלום לפי שימוש	חיוב ב-Cloud	כן	לא
ממשקי API של Chronicle: גישה כללית, יצירה וניהול של פרטי כניסה באמצעות ספק זהויות (IdP) של צד שלישי	Google Cloud ממשקי API	כן	כן
ממשקי Chronicle API: גישה כללית, יצירה וניהול של פרטי כניסה באמצעות Cloud Identity	‫Google Cloud APIs, Cloud Identity	כן	כן
אמצעי בקרה תואמים: CMEK	Cloud Key Management Service או Cloud External Key Manager	כן	לא
אמצעי בקרה תואמים: FedRAMP High ומעלה	Assured Workloads	כן	כן
אמצעי בקרה תואמים: שירות מדיניות הארגון	שירות מדיניות הארגון	כן	לא
ניהול אנשי קשר: גילוי נאות כנדרש בחוק	אנשי קשר חיוניים	כן	לא
מעקב אחר תקינות: הפסקות זמניות בצינורות להטמעת נתונים	Cloud Monitoring	כן	לא
העברה: webhook, ‏ Pub/Sub, ‏ Azure Event Hub, ‏ Amazon Kinesis Data Firehose	ניהול זהויות והרשאות גישה	כן	לא
אמצעי בקרה על גישה מבוססת-תפקידים: נתונים	ניהול זהויות והרשאות גישה	כן	כן
בקרת גישה מבוססת-תפקידים: תכונות או משאבים	ניהול זהויות והרשאות גישה	כן	כן
גישה לתמיכה: שליחה ומעקב של בקשות תמיכה	Cloud Customer Care	כן	לא
אימות מאוחד של SecOps	איחוד שירותי אימות הזהות של כוח עבודה ב-Google	לא	כן

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