פריסת ה-Blueprint

Last reviewed 2025-05-15 UTC

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

מסכם הכול

כדי לפרוס את התשתית הארגונית שלכם בהתאם לשיטות המומלצות ולהמלצות שמופיעות בתוכנית הזו, צריך לבצע את המשימות הכלליות שמסוכמות בקטע הזה. הפריסה דורשת שילוב של שלבי הגדרה מקדימים, פריסה אוטומטית דרך terraform-example-foundation ב-GitHub ושלבים נוספים שצריך להגדיר ידנית אחרי השלמת הפריסה הראשונית של ה-foundation.

עיבוד שלבים

דרישות מוקדמות לפני פריסת המשאבים של צינור הנתונים הבסיסי

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

כדי להתחבר לסביבה קיימת מקומית, צריך להכין את הדברים הבאים:

שלבים לפריסת terraform-example-foundation מ-GitHub

כדי לפרוס את terraform-example-foundation מ-GitHub, פועלים לפי ההוראות בקובץ ה-README לכל שלב:

שלבים נוספים אחרי פריסת IaC

אחרי שפורסים את קוד Terraform, מבצעים את הפעולות הבאות:

אמצעי בקרה אדמיניסטרטיביים נוספים ללקוחות עם עומסי עבודה (workloads) שמכילים מידע רגיש

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

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

כדאי להעריך אם אמצעי הבקרה הבאים מתאימים לכם על סמך דרישות התאימות, רמת הסיכון הרצויה ורגישות הנתונים.

שליטה תיאור

הגנה על המשאבים באמצעות VPC Service Controls

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

הערכה אם הערך של צמצום הסיכונים של העברת נתונים לא מורשית מצדיק את המורכבות המוגברת ואת תקורת התפעול של אימוץ VPC Service Controls. תוכנית ה-blueprint מכינה אמצעי בקרה ברשת שנדרשים מראש וגבול גזרה של VPC Service Controls להרצה יבשה, אבל הגבול לא נאכף עד שמבצעים שלבים נוספים.

הגבלת מיקומי משאבים

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

הפעלת Assured Workloads

‫Assured Workloads מספק אמצעי בקרה נוספים לעמידה בדרישות, שעוזרים לכם לעמוד בדרישות של משטרים רגולטוריים ספציפיים. תוכנית ה-blueprint מספקת משתנים אופציונליים בצינור עיבוד הנתונים לפריסה לצורך הפעלה.

הפעלת יומני גישה לנתונים

יכול להיות שתידרשו לרשום ביומן את כל הגישה לנתונים או למקורות מידע רגישים מסוימים.

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

הפעלת אישור גישה

בזכות אישורי הגישה, המהנדסים ונציגי שירות הלקוחות של Cloud Customer Care צריכים לקבל מכם אישור מפורש כשהם צריכים גישה לתוכן של הלקוח.

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

הפעלת הצדקות גישה למפתחות

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

כדאי להעריך את העלות ואת התקורה התפעולית שקשורות ל-Key Access Justifications, וגם את התלות שלו ב-Cloud External Key Manager ‏ (Cloud EKM).

השבתה של Cloud Shell

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

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

הגבלת הגישה למסוף Google Cloud

Google Cloud מאפשרת להגביל את הגישה ל Google Cloud מסוף על סמך מאפיינים של רמת הגישה כמו חברות בקבוצה, טווחי כתובות IP מהימנים ואימות מכשירים. כדי להשתמש בחלק מהמאפיינים צריך מינוי נוסף ל-Chrome Enterprise Premium.

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

מוסכמות למתן שמות

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

משאב מוסכמה למתן שמות

תיקייה

fldr-environment

‫environment הוא תיאור של המשאבים ברמת התיקייה בארגון Google Cloud. לדוגמה, bootstrap, common, production, nonproduction, development או network.

לדוגמה: fldr-production

מזהה פרויקט

prj-environmentcode-description-randomid

  • ‫environmentcode הוא קיצור של שדה הסביבה (אחד מהערכים b,‏ c,‏ p,‏ n,‏ d או net). בפרויקטים של מארחי VPC משותפים נעשה שימוש בערך environmentcode של הסביבה המשויכת. פרויקטים של משאבי רשת שמשותפים בין סביבות, כמו פרויקט interconnect, משתמשים בקוד הסביבה net.
  • ‫description הוא מידע נוסף על הפרויקט. אפשר להשתמש בקיצורים קצרים שאנשים יכולים לקרוא.
  • ‫randomid הוא סיומת אקראית שנועדה למנוע התנגשויות בשמות של משאבים שצריכים להיות ייחודיים באופן גלובלי, ולצמצם את הסיכון לתוקפים שינחשו את שמות המשאבים. התוכנית מוסיפה באופן אוטומטי מזהה אלפאנומרי אקראי באורך ארבעה תווים.

לדוגמה: prj-c-logging-a1b2

רשת VPC

vpc-environmentcode-vpctype

  • ‫environmentcode הוא קיצור של שדה הסביבה (אחד מהערכים b,‏ c,‏ p,‏ n,‏ d או net).
  • ‫vpctype הוא אחד מהערכים svpc, float או peer.

לדוגמה: vpc-p-svpc

תת-רשת

sn-environmentcode-vpctype-region{-description}

  • ‫environmentcode הוא קיצור של שדה הסביבה (אחד מהערכים b,‏ c,‏ p,‏ n,‏ d או net).
  • ‫vpctype הוא אחד מהערכים svpc, float או peer.
  • ‫region הוא כל Google Cloudאזור תקין שבו נמצא המשאב. כדי לא לחרוג ממגבלת התווים, מומלץ להסיר מקפים ולהשתמש בקיצור של שמות אזורים וכיוונים מסוימים. לדוגמה, au (אוסטרליה), na (צפון אמריקה), sa (דרום אמריקה), eu (אירופה), se (דרום-מזרח) או ne (צפון-מזרח).
  • ‫description הוא מידע נוסף על רשת המשנה. אפשר להשתמש בקיצורים קצרים וקלים לקריאה.

לדוגמה: sn-p-svpc-uswest1

מדיניות חומת אש

fw-firewalltype-scope-environmentcode{-description}

  • ‫firewalltype הוא hierarchical או network.
  • ‫scope is global או Google Cloudהאזור שבו נמצא המשאב. כדי לא לחרוג ממגבלת התווים, מומלץ להסיר מקפים ולהשתמש בקיצורים של שמות אזורים וכיוונים. לדוגמה, au (אוסטרליה), na (צפון אמריקה), sa (דרום אמריקה), eu (אירופה), se (דרום-מזרח) או ne (צפון-מזרח).
  • ‫environmentcode הוא קיצור של שדה הסביבה (אחד מהערכים b,‏ c,‏ p,‏ n,‏ d או net) שכולל את משאב המדיניות.
  • description מידע נוסף על מדיניות חומת האש ההיררכית. אפשר להשתמש בקיצורים קצרים שקל לקרוא.

לדוגמה:

fw-hierarchical-global-c-01

fw-network-uswest1-p-svpc

Cloud Router

cr-environmentcode-vpctype-region{-description}

  • ‫environmentcode הוא קיצור של שדה הסביבה (אחד מהערכים b,‏ c,‏ p,‏ n,‏ d או net).
  • ‫vpctype הוא אחד מהערכים svpc, float או peer.
  • ‫region הוא כל אזור תקין Google Cloudשבו נמצא המשאב. כדי לא לחרוג ממגבלת התווים, מומלץ להסיר מקפים ולהשתמש בקיצורים של שמות אזורים וכיוונים. לדוגמה, au (אוסטרליה), na (צפון אמריקה), sa (דרום אמריקה), eu (אירופה), se (דרום-מזרח) או ne (צפון-מזרח).
  • ‫description הוא מידע נוסף על Cloud Router. אפשר להשתמש בקיצורים קצרים שקל לקרוא.

לדוגמה: cr-p-svpc-useast1-cr1

חיבור Cloud Interconnect

ic-dc-colo

  • ‫dc הוא השם של מרכז הנתונים שאליו מחובר Cloud Interconnect.
  • ‫colo הוא השם של מתקן האירוח המשותף שאליו מתבצע פירינג של Cloud Interconnect ממרכז הנתונים המקומי.

לדוגמה: ic-mydatacenter-lgazone1

צירוף ל-VLAN ב-Cloud Interconnect

vl-dc-colo-environmentcode-vpctype-region{-description}

  • ‫dc הוא השם של מרכז הנתונים שאליו מחובר Cloud Interconnect.
  • ‫colo הוא שם מתקן האירוח המשותף שאליו מתבצעת פירינג של Cloud Interconnect ממרכז הנתונים המקומי.
  • ‫environmentcode הוא קיצור של שדה הסביבה (אחד מהערכים b,‏ c,‏ p,‏ n,‏ d או net).
  • ‫vpctype הוא אחד מהערכים svpc, float או peer.
  • ‫region הוא כל אזור תקין Google Cloudשבו נמצא המשאב. כדי לא לחרוג ממגבלת התווים, מומלץ להסיר מקפים ולהשתמש בקיצורים של שמות אזורים וכיוונים. לדוגמה, au (אוסטרליה), na (צפון אמריקה), sa (דרום אמריקה), eu (אירופה), se (דרום-מזרח) או ne (צפון-מזרח).
  • ‫description הוא מידע נוסף על ה-VLAN. אפשר להשתמש בקיצורים קצרים וקלים לקריאה.

לדוגמה: vl-mydatacenter-lgazone1-p-svpc-useast1-cr1

קבוצה

grp-gcp-description@example.com

כאשר description הוא מידע נוסף על הקבוצה. אפשר להשתמש בקיצורים קצרים שאנשים יכולים לקרוא.

לדוגמה: grp-gcp-billingadmin@example.com

תפקיד בהתאמה אישית

rl-description

כאשר description הוא מידע נוסף על התפקיד. אפשר להשתמש בקיצורים קצרים וקריאים.

לדוגמה: rl-customcomputeadmin

חשבון שירות

sa-description@projectid.iam.gserviceaccount.com

כאשר:

  • ‫description הוא מידע נוסף על חשבון השירות. אפשר להשתמש בקיצורים קצרים שקל לקרוא.
  • ‫projectid הוא מזהה הפרויקט הייחודי הגלובלי.

לדוגמה: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

קטגוריית אחסון

bkt-projectid-description

כאשר:

  • ‫projectid הוא מזהה הפרויקט הייחודי הגלובלי.
  • ‫description הוא מידע נוסף על קטגוריית האחסון. אפשר להשתמש בקיצורים קצרים שקל לקרוא.

לדוגמה: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

חלופות להמלצות שמוגדרות כברירת מחדל

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

אזור ההחלטה חלופות אפשריות

ארגון: תוכנית ה-Blueprint משתמשת בארגון יחיד כצומת הבסיסי לכל המשאבים.

המאמר בנושא Google Cloud החלטה על היררכיית משאבים לאזור הנחיתה מציג תרחישים שבהם עדיף להשתמש בכמה ארגונים, כמו:

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

מבנה התיקיות: לתוכנית יש מבנה תיקיות שמחלק את עומסי העבודה לתיקיות production, non-production ו-development בשכבה העליונה.

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

  • תיקיות שמבוססות על סביבות אפליקציה
  • תיקיות שמבוססות על ישויות או חברות-בנות אזוריות
  • תיקיות שמבוססות על מסגרת האחריות

מדיניות הארגון: תוכנית ה-Blueprint אוכפת את כל האילוצים של מדיניות הארגון בצומת הארגון.

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

כלים לצינור עיבוד נתונים לפריסה: התוכנית משתמשת ב-Cloud Build כדי להריץ את צינור העיבוד האוטומטי.

יכול להיות שתעדיפו מוצרים אחרים לצינור עיבוד הנתונים לפריסה, כמו Terraform Enterprise,‏ GitLab Runners,‏ GitHub Actions או Jenkins. התוכנית כוללת הוראות חלופיות לכל מוצר.

מאגר קוד לפריסה: התוכנית משתמשת ב-Cloud Source Repositories כמאגר Git פרטי מנוהל.

מומלץ להשתמש במערכת לניהול גרסאות המועדפת עליכם לניהול מאגרי קוד, כמו GitLab,‏ GitHub או Bitbucket.

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

ספק זהויות: תוכנית הפריסה מבוססת על Active Directory מקומי ומאחדת זהויות עם Cloud Identity באמצעות Google Cloud Directory Sync.

אם אתם כבר משתמשים ב-Google Workspace, אתם יכולים להשתמש בזהויות Google שכבר מנוהלות ב-Google Workspace.

אם אין לכם ספק זהויות קיים, אתם יכולים ליצור ולנהל את זהויות המשתמשים ישירות ב-Cloud Identity.

אם יש לכם ספק זהויות קיים, כמו Okta,‏ Ping או Azure Entra ID, אתם יכולים לנהל את חשבונות המשתמשים בספק הזהויות הקיים ולסנכרן אותם עם Cloud Identity.

אם יש לכם דרישות של ריבונות נתונים או תאימות שמונעות מכם להשתמש ב-Cloud Identity, ואם אתם לא צריכים זהויות משתמשים מנוהלות ב-Google לשירותי Google אחרים כמו Google Ads או Google Marketing Platform, יכול להיות שתעדיפו איחוד שירותי אימות הזהות של כוח העבודה. במקרה כזה, חשוב להיות מודעים למגבלות של השירותים הנתמכים.

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

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

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

הקצאת כתובות IP: התוכנית מספקת קבוצה של טווחי כתובות IP.

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

רשת היברידית: תוכנית האב משתמשת ב-Dedicated Interconnect בכמה אתרים פיזיים ובכמה אזורים שלGoogle Cloud כדי להשיג רוחב פס וזמינות מקסימליים.

בהתאם לדרישות שלכם לגבי עלות, רוחב פס ואמינות, יכול להיות שתגדירו במקום זאת Partner Interconnect או Cloud VPN.

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

אם אין לכם סביבה מקומית קיימת, יכול להיות שלא תצטרכו רשת היברידית בכלל.

גבולות גזרה של VPC Service Controls: התוכנית המפורטת ממליצה על גבול גזרה יחיד שכולל את כל פרויקטי השירות עבור טופולוגיית ה-VPC המשותף.

יכול להיות שיש לכם תרחיש שימוש שבו נדרשים כמה היקפים לארגון, או שאתם מחליטים לא להשתמש ב-VPC Service Controls בכלל.

מידע נוסף זמין במאמר בנושא איך להחליט איך לצמצם את הסיכון להוצאת נתונים דרך ממשקי Google API.

‫Secret Manager: תוכנית ה-Blueprint פורסת פרויקט לשימוש ב-Secret Manager בתיקייה common בשביל סודות ברמת הארגון, ופרויקט בכל תיקיית סביבה בשביל סודות שספציפיים לסביבה.

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

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

‫Cloud KMS: תוכנית הפריסה פורסת פרויקט לשימוש ב-Cloud KMS בתיקייה common עבור מפתחות ברמת הארגון, ופרויקט לכל תיקיית סביבה עבור מפתחות בכל סביבה.

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

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

אובייקטים נצברים מסוג sink ביומן: תוכנית ה-blueprint מגדירה קבוצה של אובייקטים מסוג sink ביומן בצומת הארגון, כך שצוות אבטחה מרכזי יכול לבדוק יומני ביקורת מכל הארגון.

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

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

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

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

ייצוא ל-SIEM: תוכנית האב-טיפוס מנהלת את כל הממצאים בנושא אבטחה ב-Security Command Center.

מחליטים אם לייצא ממצאים בנושא אבטחה מ-Security Command Center לכלים כמו Google Security Operations או ל-SIEM הקיים, או אם הצוותים ישתמשו במסוף כדי לראות ולנהל את הממצאים בנושא אבטחה. יכול להיות שתגדירו כמה ייצואים עם מסננים ייחודיים לצוותים שונים עם היקפים ואחריות שונים.

המאמרים הבאים