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

נתמך ב:

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

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

  • הבאת פרויקט משלכם (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 ל-BYOP

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

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

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

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

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

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

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

  • הגדרת הרשאות: מגדירים את כל כללי ההרשאות הנדרשים ב-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.