הצטרפות למופע של Google SecOps

נתמך ב:

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.

פריסת מופע חדש של 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, שמתאימה לארה"ב במספר אזורים.

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

• דייר (מופע) שנמצא בבקרה לצורך תאימות הוא דייר שחייב לעמוד באחד או יותר מהתקנים הבאים של בקרה לצורך תאימות: 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 SecOps, אתם צריכים ליצור את הפרויקט בתיקייה של Assured Workloads שהוגדרה לחבילת בקרת התאימות הנדרשת. Google Cloud

• אם לארגון שלכם אין תיקיית 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. מיפוי קבוצות של ספק זהות לפרמטרים של בקרת גישה כדי להשלים את הפריסה.

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

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

• צריך להעניק את כל התפקידים וההרשאות ברמת הפרויקט. הרשאות הגישה האלה חלות רק על פרויקט Google Cloud ספציפי ועל המופע המשויך של Google SecOps. כדי לפרוס מופעים נוספים, אפשר לפנות לצוות ניהול החשבון או לצוות השותפים.
• אם פורסים עוד מופע של 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 של צד שלישי	ממשקי API שלGoogle Cloud	כן	כן
ממשקי Chronicle API: גישה כללית, יצירה וניהול של פרטי כניסה באמצעות Cloud Identity	‫Google Cloud APIs, Cloud Identity	כן	כן
אמצעי בקרה תואמים: CMEK	‫Cloud Key Management Service או Cloud External Key Manager	כן	לא
אמצעי בקרה תואמים: FedRAMP High ומעלה	Assured Workloads	כן	כן
אמצעי בקרה תואמים: שירות מדיניות הארגון	Organization Policy Service	כן	לא
ניהול אנשי קשר: גילוי נאות	אנשי קשר חיוניים	כן	לא
מעקב אחר תקינות: הפסקות פעולה של צינורות להטמעת נתונים	Cloud Monitoring	כן	לא
העברה: webhook, ‏ Pub/Sub, ‏ Azure Event Hub, ‏ Amazon Kinesis Data Firehose	ניהול זהויות והרשאות גישה	כן	לא
אמצעי בקרה על גישה לנתונים שמבוססים על תפקידים	ניהול זהויות והרשאות גישה	כן	כן
אמצעי בקרה על גישה מבוססת-תפקידים: תכונות או משאבים	ניהול זהויות והרשאות גישה	כן	כן
גישה לתמיכה: שליחה ומעקב של בקשות תמיכה	Cloud Customer Care	כן	לא
אימות מאוחד של SecOps	איחוד שירותי אימות הזהות של כוח העבודה ב-Google	לא	כן

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