פריסת מכונה

נתמך ב:

Google SecOps

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

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

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

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

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

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

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

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

פריסת מכונה חדשה של 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, או אם אתם מסנכרנים זהויות מספק הזהויות שלכם עם Google Cloud.

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

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

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

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

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

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

  מגדירים את איחוד שירותי אימות הזהות של כוח העבודה של Google ויוצרים מאגר זהויות של כוח העבודה. באמצעות איחוד שירותי אימות הזהות של כוח העבודה של Google, אתם יכולים לתת לעומסי עבודה מקומיים או מרובי עננים גישה למשאבי 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 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‏ (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)
  • אדמין של שימוש בשירות (roles/serviceusage.serviceUsageAdmin)

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

אתם יכולים להשתמש ב-IdP כדי לנהל משתמשים, קבוצות ואימות.

כדי להגדיר IdP, צריך לתת את ההרשאות הבאות למומחה התוכן שמטפל בהצטרפות:

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

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

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

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

• ב-Google Workspace:

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

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

הרשאות להגדרת IdP של צד שלישי

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

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

מקצים למומחה התוכן להכשרת עובדים חדשים את התפקידים וההרשאות הבאים ב-IAM:

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

• הרשאת אדמין של מאגר כוח העבודה ב-IAM‏ (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: כתובת האימייל של האדמין.

• Organization Viewer (resourcemanager.organizations.get) ברמת הארגון.

הרשאות לקישור מכונה של Google SecOps לשירותי Google Cloud

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

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

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

הרשאות להגדרת בקרת גישה לתכונות באמצעות 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	כן	כן
ממשקי API של Chronicle: גישה כללית, הנפקה וניהול של פרטי כניסה באמצעות Cloud Identity	Google Cloud ממשקי API, ‏ 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	ניהול זהויות והרשאות גישה	כן	לא
בקרת גישה המבוססת על תפקידים (RBAC): נתונים	ניהול זהויות והרשאות גישה	כן	כן
בקרות גישה מבוססות-תפקידים: תכונות או משאבים	ניהול זהויות והרשאות גישה	כן	כן
גישה לתמיכה: שליחת בקשות תמיכה, מעקב	Cloud Customer Care	כן	לא
אימות מאוחד ב-SecOps	איחוד שירותי אימות הזהות של כוח העבודה ב-Google	לא	כן

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