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

נתמך ב:

המדריך הזה עוזר לאדמינים ולמהנדסי אבטחה להעביר מופע קיים של Google SecOps, כולל הנתונים שלו, לפרויקט אחר Google Cloud באמצעות המודל Bring Your Own Project (BYOP). Google Cloud התהליך הזה עוזר לכם לאחד משאבים, לשנות את החיוב או להתאים את עצמכם לשינויים בארגון, תוך שמירה על נתוני האבטחה והגדרות המופע.

מונחים חשובים

  • מודל Bring Your Own Project (BYOP): מודל שבו אתם משתמשים ב Google Cloud פרויקט משלכם כדי לארח ולנהל את מופע Google SecOps.
  • הוכחת היתכנות (POC): מופע שאינו מיועד לייצור ומשמש להערכה או לבדיקה.
  • איש קשר טכני (TPOC): איש הקשר שמוגדר בארגון שלכם לקבלת עדכונים טכניים בנוגע למיגרציה.

לפני שמתחילים

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

  • הרשאות: כדי לבצע העברה בשירות עצמי למופע POC, צריך להיות לכם תפקיד IAM‏ chroniclesm.admin, שכולל את ההרשאה chroniclesm.projectLink.enable.

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

  • זמינות הפרויקט: אפשר להשתמש בפרויקט קיים או בפרויקט חדש של Google Cloud :

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

  • מדיניות ארגונית: אם בפרויקט הנוכחי Google Cloud יש מדיניות ארגונית פעילה, כמו VPC Service Controls,‏ CMEK,‏ FedRAMP או מסגרות תאימות אחרות, צריך לפנות אל צוות התמיכה של Google SecOps לקבלת עזרה לפני התחלת ההעברה.

  • ‫Chronicle API: מפעילים את Chronicle API בפרויקט היעד Google Cloud . מידע נוסף זמין במאמר הפעלת Chronicle API.

  • אימות (BYOID בלבד): אם המופע שלכם משתמש ב-Bring Your Own Identity (BYOID), צריך להגדיר את מאגר כוח העבודה בפרויקט היעד. מידע נוסף מופיע במאמר בנושא הגדרת ספק זהויות מצד שלישי.

  • שיוכים ל-SCC-E: אם מופע Google SecOps שלכם מקושר ל-Security Command Center Enterprise‏ (SCC-E), לא תהיה תמיכה בהעברת פרויקט BYOP. לקבלת עזרה, אפשר לפנות אל התמיכה של Google SecOps.

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

העברת המופע לפרויקט BYOP

תהליך ההעברה משתנה בהתאם לסוג המופע שמעבירים – מופע POC או מופע ייצור שאינו POC.

העברה של POC ל-BYOP בסביבת ייצור

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

פועלים לפי ההוראות במאמר קישור מכונת Google SecOps למינוי חדש, במיוחד לפי ההוראות שבסעיף המשנה קישור מכונת Google SecOps קיימת מסוג POC למינוי חדש.

העברת פרויקט שאינו POC ל-BYOP

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

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

במהלך תהליך ההעברה

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

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

השלמת פעולות אחרי ההעברה

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

  • הגדרת הרשאה: מגדירים את כל כללי ההרשאה הנדרשים של IAM בפרויקט היעד. מידע נוסף זמין במאמר הגדרת גישה לפיצ'רים באמצעות IAM.

  • יוצרים מחדש פידים ספציפיים להעלאה:

    • פידים שהועברו אוטומטית: רוב פידים ההעלאה מועברים אוטומטית ולא נדרשת פעולה כלשהי. הפעולה הזו כוללת את פידי ה-STS הבאים, שמקושרים מחדש ומופעלים באופן אוטומטי:

      • Non-FedAuth AMAZON_S3_V2
      • Non-FedAuth AMAZON_SQS_V2
      • Non-FedAuth AZURE_BLOBSTORE_V2

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

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

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

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

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

פתרון בעיות

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

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