מדריך

עומסי עבודה של GKE צריכים לגשת לממשקי API של GCP ללא צורך בניהול מפתחות של חשבונות שירות.

→הפעלה והגדרה של Workload Identity באשכול ה-GKE. מיפוי חשבונות שירות של Kubernetes (KSA) לחשבונות שירות של Google (GSA).

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

מקור↗

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

→השתמשו ב-Identity-Aware Proxy (IAP) עם Access Context Manager. הגדירו רמות גישה המבוססות על IP, מצב מכשיר (באמצעות Endpoint Verification) וזהות משתמש.

למה: מעביר את בקרת הגישה מההיקף הרשתי למשתמשים ומכשירים בודדים, תוך אכיפת עקרונות "אפס אמון" (zero-trust).

מקור↗

צינור CI/CD (לדוגמה, GitHub Actions, GitLab) צריך לגשת למשאבי GCP ללא פרטי כניסה ארוכי טווח.

→השתמשו ב-Workload Identity Federation. צרו מאגר ספקים עבור IdP חיצוני (לדוגמה, GitHub OIDC) והגדירו תנאי תכונות להגבלת גישה למאגרים או ענפים ספציפיים.

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

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

→השתמשו באילוצי מדיניות ארגונית (Organization Policy constraints) כגון `iam.disableServiceAccountKeyCreation` ו-`iam.allowedPolicyMemberDomains`.

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

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

→השתמשו ב-Privileged Access Manager (PAM) עבור גישת "just-in-time" (JIT). המשתמש מבקש תפקיד ספציפי לזמן מוגבל, העובר תהליך אישור.

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

צוותים מרובים חולקים אשכול GKE. כל צוות חייב לנהל משאבים רק בתוך ה-namespace שלו.

→העניקו תפקיד IAM `roles/container.clusterViewer` ברמת הפרויקט. השתמשו ב-Kubernetes RBAC `Role` וב-`RoleBinding` בתוך כל namespace כדי להעניק הרשאות ספציפיות (לדוגמה, עריכה, צפייה).

למה: מפריד אימות ברמת האשכול (IAM) מאישור ברמת ה-namespace (Kubernetes RBAC), ומספק בקרה עדינה מרובת דיירים.

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

→השתמשו בהתחזות (impersonation) של חשבון שירות. העניקו ל-"principal" את התפקיד `roles/iam.serviceAccountTokenCreator` בחשבון שירות יעד כדי ליצור אסימוני גישה קצרי טווח של OAuth 2.0.

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

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

→העניקו את תפקיד ה-IAM הנדרש עם תנאי IAM מבוסס זמן, לדוגמה, `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.

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

אפשרו רק תמונות קונטיינר שנחתמו על ידי צינור ה-CI/CD להיפרס לאשכולות GKE בייצור.

→יישמו Binary Authorization. צרו אישור (attestation) בצינור ה-CI לחתימת תמונות. הגדירו מדיניות Binary Authorization באשכול ה-GKE לדרוש אישור זה.

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

מקור↗

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

→השתמשו בתנאי IAM עם ביטויי תגי משאבים, כמו `resource.matchTag("123456789/env", "prod")`.

למה: מאפשר בקרת גישה מבוססת תכונות (ABAC) ניתנת להרחבה. הרשאות הן דינמיות ומיושמות אוטומטית כאשר משאבים מתויגים.

אפשרו לפרויקט שירות לפרוס מכונות וירטואליות בפרויקט מארח של Shared VPC מבלי להעניק זכויות מנהל רשת.

→בפרויקט המארח, העניקו לחשבון השירות של פרויקט השירות את התפקיד `roles/compute.networkUser` על תת-הרשת(ות) הספציפית(ות) שעליו להשתמש בהן.

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

משתמש עם הרשאת `storage.admin` אינו יכול ליצור bucket. עליכם לזהות את שורש הבעיה.

→בדקו קיום מדיניות מניעה (Deny Policy) של IAM ברמה גבוהה יותר (תיקייה, ארגון) השוללת את הרשאת `storage.buckets.create`.

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

הפעלת SSO למשתמשי Active Directory מקומיים לגישה למסוף Google Cloud.

→השתמשו ב-Google Cloud Directory Sync (GCDS) כדי לסנכרן זהויות ל-Cloud Identity. הגדירו איחוד (SAML) בין Cloud Identity ל-AD FS (או IdP אחר).

למה: שומר על Active Directory כמקור האמת לזהויות תוך מתן חווית SSO מאוחדת וחלקה למשתמשים.

הצפנת נתונים ב-GCP, אך מפתחות ההצפנה אסור שיעזבו את ה-HSM המקומי.

→השתמשו ב-Cloud External Key Manager (EKM). זה מאפשר לשירותי GCP להשתמש במפתחות ממערכת ניהול מפתחות חיצונית עבור פעולות CMEK.

למה: מספק שליטה מרבית ועומד בדרישות ריבונות נתונים קפדניות על ידי שמירת חומר המפתח מחוץ ל-Google Cloud.

מקור↗

מציאה וסיווג אוטומטיים של נתונים רגישים (PII, PHI) בכל נכסי Cloud Storage ו-BigQuery.

→הגדירו סריקות גילוי של Cloud Data Loss Prevention (DLP). התוצאות יכולות לאכלס אוטומטית את Data Catalog עם תגים.

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

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

→השתמשו בתבנית ביטול זיהוי (de-identification) של Cloud DLP עם הצפנה דטרמיניסטית או גיבוב קריפטוגרפי.

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

מסגרת ציות (לדוגמה, לשירותים פיננסיים) דורשת שמפתחות הצפנה יהיו מוגנים על ידי HSM מאושר FIPS 140-2 Level 3.

→השתמשו ב-Cloud KMS עם רמת הגנה של HSM. זה יוצר מפתחות בתוך Hardware Security Module מנוהל.

למה: עומד בדרישות ציות ברמה גבוהה על ידי שימוש בחומרת ניהול מפתחות ייעודית ומאושרת מבלי לנהל את ה-HSM הפיזיים.

ודאו שמשאבים חדשים (לדוגמה, GCS buckets, BigQuery datasets) מוצפנים תמיד עם מפתחות בניהול לקוח (CMEK), ולא עם מפתחות בניהול Google.

→החילו את מדיניות הארגון `constraints/gcp.restrictNonCmekServices`.

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

נתונים חייבים להישמר במצב בלתי ניתן לשינוי (WORM - Write-Once-Read-Many) לתקופת שמירה ספציפית מסיבות משפטיות או ציות.

→הגדירו Cloud Storage bucket עם מדיניות שמירה והפעילו Bucket Lock.

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

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

→השתמשו ב-Secret Manager עם סיבוב אוטומטי מוגדר. הסיבוב מפעיל Cloud Function שמעדכנת את הסיסמה במסד הנתונים ויוצרת גרסת סוד חדשה.

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

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

→השתמשו ב-Confidential Computing על ידי פריסת עומס העבודה על Confidential VMs.

למה: מספק הצפנת זיכרון מבוססת חומרה, המגנה על נתונים מה-hypervisor וממכונות וירטואליות אחרות. השתמשו באישור (attestation) כדי לאמת את שלמות הסביבה.

הגבילו גישה לעמודות רגישות ספציפיות בטבלת BigQuery מבלי ליצור תצוגות נפרדות.

→השתמשו באבטחת רמת עמודה של BigQuery. החילו תגי מדיניות (policy tags) של Data Catalog על עמודות רגישות והעניקו את התפקיד "Fine-Grained Reader" על תגי מדיניות אלה למשתמשים/קבוצות מורשים.

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

הגנו על נתונים רגישים ב-GCS bucket גם אם הרשאות IAM מוגדרות באופן שגוי ומעניקות גישה ציבורית.

→הצפינו אובייקטים עם מפתח הצפנה בניהול לקוח (CMEK) ובקרו באופן הדוק את הגישה למפתח זה ב-Cloud KMS.

למה: יוצר מערכת דו-מפתחית. תוקף זקוק להרשאות גם עבור אובייקט GCS וגם עבור מפתח KMS כדי לפענח את הנתונים, מה שמספק הגנה רב-שכבתית (defense-in-depth).

מניעת מחיקה מיידית מקרית או זדונית של מפתחות Cloud KMS קריטיים.

→בעת יצירת המפתח, הגדירו את המאפיין `destroy_scheduled_duration` לערך כמו 30 יום.

למה: אוכף תקופת המתנה לפני שמפתח נמחק לצמיתות, ומספק חלון זמן להתאוששות ממחיקה מקרית.

דרישה משפטית להוכיח שקובץ ב-Cloud Storage לא שונה מאז שהועלה.

→בעת ההורדה, חשבו מחדש את גיבוב ה-MD5 או CRC32C של הקובץ והשוו אותו לגיבוב המאוחסן במטא-הנתונים של אובייקט Cloud Storage.

למה: מספק הוכחה קריפטוגרפית של שלמות אובייקט. Cloud Storage מחשב ומאחסן באופן אוטומטי גיבובים אלה בעת ההעלאה.

מניעת העתקת נתונים מפרויקט רגיש ל-bucket ציבורי, גם על ידי משתמש עם תפקיד `owner`.

→הציבו את הפרויקט הרגיש בתוך היקף של VPC Service Controls. זה מגביל תנועת נתונים לפרויקטים אחרים מחוץ להיקף.

למה: VPC Service Controls פועלים כחומת אש ממוקדת נתונים העוקפת הרשאות IAM ליציאת נתונים, ומספקת הגנה עוצמתית מפני זליגת נתונים.

מקור↗

הגנת יישום ווב הפונה לציבור מפני התקפות DDoS בנפח גבוה וניצולי אינטרנט נפוצים (לדוגמה, SQLi, XSS).

→מקמו את היישום מאחורי Global External HTTP(S) Load Balancer וצרפו מדיניות אבטחה של Cloud Armor עם כללי WAF מוגדרים מראש.

למה: מאזן העומסים סופג התקפות DDoS בקצה הרשת של Google. Cloud Armor מספק חומת אש מנוהלת ליישומי ווב לחסימת 10 האיומים המובילים של OWASP.

Dedicated Interconnect משמש לקישוריות מהשטח ל-GCP, אך התעבורה חייבת להיות מוצפנת לצורך ציות.

→הגדירו מנהרת HA VPN מעל חיבורי ה-VLAN של Cloud Interconnect.

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

מערכות מקומיות צריכות לקרוא לממשקי API של Google (לדוגמה, BigQuery, GCS) מבלי לעבור דרך האינטרנט הציבורי.

→הגדירו Private Google Access למארחים מקומיים. השתמשו ב-Cloud Interconnect או VPN, והגדירו DNS כדי לפתור את `*.googleapis.com` לטווח ה-VIP המוגבל.

למה: שומר את התעבורה לשירותי Google ברשת הפרטית של Google, משפר את האבטחה ועשוי להפחית עלויות יציאה.

אכיפת mTLS (mutual TLS) לכל תקשורת שירות-לשירות בתוך אשכול GKE.

→פרוסו את Anthos Service Mesh (או Istio) והפעילו אימות עמית mTLS קפדני עבור ה-namespaces הרלוונטיים.

למה: מצפין ומאמת אוטומטית את כל התעבורה בתוך הרשת (mesh), משיג מודל רשת "אפס אמון" ללא שינויים בקוד היישום.

VPC צרכן צריך לגשת באופן פרטי לשירות (לדוגמה, API פנימי) הפועל ב-VPC יצרן מבלי להשתמש ב-peering או בכתובות IP ציבוריות.

→היצרן מפרסם את השירות באמצעות Private Service Connect. הצרכן יוצר נקודת קצה ב-VPC שלו המנתבת באופן פרטי לשירות.

למה: מפריד קישוריות רשת מגישה לשירותים. זוהי הדרך המודרנית והניתנת להרחבה למתן גישה פרטית לשירותים על פני VPCs וארגונים.

פרוסו אשכול GKE שבו לצמתים אין כתובות IP ציבוריות ושמישור הבקרה אינו חשוף לאינטרנט.

→צרו אשכול GKE פרטי. הפעילו Private Google Access בתת-הרשת לגישת צמתים לממשקי API של GCP. הגדירו רשתות מאושרות ראשיות (master authorized networks) להגבלת גישת מישור הבקרה לכתובות IP ספציפיות (לדוגמה, רשת ארגונית).

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

באשכול GKE, יש לאפשר לפודים של שירות `frontend` לתקשר רק עם פודים של שירות `backend`, ושום דבר אחר.

→צרו משאבי Kubernetes NetworkPolicy. החילו מדיניות כניסה (ingress policy) על פודי ה-`backend` המאפשרת תעבורה רק מפודים של `frontend`, בהתבסס על תוויות פודים.

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

מכונות וירטואליות ללא כתובות IP חיצוניות צריכות לגשת לאינטרנט. כל תעבורת היציאה חייבת להגיע מקבוצה קטנה של כתובות IP צפויות לצורך רישום לבן (allowlisting) על ידי צדדים שלישיים.

→הגדירו Cloud NAT עבור תת-הרשת המכילה את המכונות הווירטואליות.

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

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

→צרו מדיניות חומת אש היררכית (Hierarchical Firewall Policy) ברמת הארגון או התיקייה עם כלל מניעה עבור פורט 22 מ-`0.0.0.0/0` בעדיפות גבוהה.

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

פתרון שמות מארחים פנימיים בתוך VPC מבלי להדליף שאילתות לשרתי DNS ציבוריים.

→הגדירו אזור מנוהל פרטי של Cloud DNS עבור הדומיינים הפנימיים שלכם וקשרו אותו ל-VPC שלכם.

למה: מספק DNS סמכותי למשאבים פנימיים בתוך רשת ה-VPC, ומשפר את האבטחה והניהוליות.

כאשר Security Command Center מזהה איום (לדוגמה, כריית קריפטו), בודדו אוטומטית את המכונה הווירטואלית המושפעת.

→הגדירו את SCC לפרסם ממצאים לנושא Pub/Sub. הפעילו Cloud Function המקבלת את הממצא ומשנה את תגי הרשת של המכונה הווירטואלית כדי להחיל כלל חומת אש "הסגר" מוגדר מראש.

למה: מאפשר תגובה אוטומטית כמעט בזמן אמת לאירועים, ומפחית את הזמן שיש לתוקף בסביבה.

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

→צרו כיור יומן ברמת הארגון (organization-level log sink) ל-Cloud Storage bucket. הגדירו את bucket היעד עם מדיניות שמירה של 7 שנים ו-Bucket Lock.

למה: כיור מצרפי מרכז יומנים. Bucket Lock מבטיח שהיומנים חסינים מפני שינויים ועומדים בדרישות שמירה מחמירות לצורך ציות.

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

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

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

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

→הפעילו את שכבת ה-Premium של Security Command Center, הכוללת Event Threat Detection. שירות זה מנתח יומנים עבור התנהגות חריגה.

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

צוות אבטחה מרכזי צריך לנתח ולתאם אותות אבטחה מ-GCP, AWS ומערכות מקומיות בפלטפורמה אחת.

→הזינו את כל היומנים והטלמטריה הרלוונטיים ל-Chronicle Security Operations (SIEM).

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

זיהוי מתי משאבי GCP המנוהלים על ידי Terraform משוּנים ידנית דרך המסוף, מה שיוצר סחיפת תצורה (configuration drift).

→הגדירו ערוץ Cloud Asset Inventory כדי לשלוח התראות על שינויים בנכסים בזמן אמת לנושא Pub/Sub. שירות יכול אז להשוות שינויים אלה למצב ה-Terraform.

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

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

→השתמשו ב-Attack Path Simulation ב-SCC Premium. הגדירו נכסים בעלי ערך גבוה והסימולציה תזהה ותתעדף ממצאים היוצרים נתיב ישיר לאותם נכסים.

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

זיהוי פעילות זדונית בתוך קונטיינר GKE פועל, כגון מעטפת בלתי צפויה (unexpected shell) או חיבור מעטפת הפוכה (reverse shell).

→הפעילו את Container Threat Detection ב-Security Command Center.

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

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

→הגדירו Packet Mirroring כדי לשכפל תעבורה ממכונות וירטואליות המקור ולשלוח אותה למכונה וירטואלית אוספת המריצה כלי בדיקה כמו Wireshark או Zeek.

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

מניעת פריסת תצורות Terraform לא מאובטחות (לדוגמה, GCS buckets ציבוריים).

→שלבו כלי בדיקת אבטחה סטטית (SAST) כמו `tfsec` או Checkov לתוך צינור ה-CI/CD. כשלו את ה-build אם נמצאו הפרות אבטחה.

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

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

→החילו את אילוץ מדיניות הארגון `gcp.resourceLocations`, המאפשר רק אזורי האיחוד האירופי שצוינו.

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

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

→הפעילו Access Approval והגדירו מאשרים. כל בקשות הגישה מ-Google יצרו בקשה שחייבת להיות מאושרת.

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

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

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

למה: מספק עקבת ביקורת בלתי ניתנת לשינוי של פעולות מנהלי Google, מעניק נראות ותומך בדרישות ציות.

ניטור מתמשך של סביבת GCP לתצורות המפרות תקן ציות ספציפי, כמו PCI DSS או HIPAA.

→השתמשו ב-Security Health Analytics ב-Security Command Center, כאשר תקן הציות הרלוונטי מופעל בלוח המחוונים.

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

מבקר מבקש את דוח SOC 2 Type II של Google ואישור ציות PCI DSS.

→השתמשו ב-Compliance Reports Manager במסוף Google Cloud כדי לגשת ולהוריד דוחות ביקורת ואישורים.

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

סוכנות ממשלתית בארה"ב צריכה לפרוס עומס עבודה העומד בדרישות ציות FedRAMP High.

→פרוסו את היישום בתוך סביבת Assured Workloads המוגדרת למשטר הציות FedRAMP High.

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