צמצום הסיכון של OWASP Top 10:2025 ב-Google Cloud

במסמך הזה מפורטים שירותים ואסטרטגיות מיטיגציה שיכולים לעזור לכם להתגונן מפני התקפות ברמת האפליקציה, כפי שמתואר ב-OWASP Top 10:2025. Google Cloud התקן OWASP Top 10:2025 נוצר על ידי Open Web Application Security (OWASP) Foundation. זהו רשימה של 10 סיכוני האבטחה העיקריים במחזור החיים של פיתוח תוכנה (SDLC). אף שירות לא יכול להבטיח הגנה מלאה מפני הסיכונים האלה, שימוש בשירותים האלה כשזה הגיוני בארכיטקטורה שלכם יכול לתרום לפתרון אבטחה חזק עם כמה שכבות.

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

מטריצת תאימות

השירותים שמפורטים בטבלה הבאה יכולים לעזור בהגנה מפני 10 סיכוני האבטחה העיקריים שזוהו על ידי OWASP Top 10:2025: Google Cloud

קטגוריה OWASP Top 10:2025 אמצעי הבקרה של Primary Google Cloud ו-Wiz

A01: Broken Access Control

‫Access Context Manager, ‏ Agent Gateway, ‏ Agent Identity, ‏ Apigee, ‏ Google Cloud Armor, ‏ Firebase App Check, ‏ Firebase Security Rules, ‏ Cloud Next Generation Firewall (Cloud NGFW), ‏ Identity-Aware Proxy (IAP), ‏ Identity and Access Management (IAM), ‏ שירות מדיניות הארגון, ‏ VPC Service Controls, ‏ Wiz Cloud

A02: Security Misconfiguration

‫Access Context Manager, ‏ מאגר משאבי ענן, ‏ Google Security Operations, ‏ Organization Policy, ‏ Security Command Center Premium, ‏ VPC Service Controls, ‏ Wiz Cloud

A03: כשלים בשרשרת אספקת התוכנה

‫Artifact Registry, ‏ Assured Open Source Software (Assured OSS), ‏ Binary Authorization, ‏ Cloud Build, ‏ Cloud Deploy, ‏ Cloud Workstations, ‏ CodeMender, ‏ Wiz Code

A04: Cryptographic Failures

‫Apigee, ‏ Certificate Authority Service, ‏ Certificate Manager, ‏ Cloud Key Management Service, ‏ Cloud Load Balancing, ‏ Cloud Workstations, ‏ Confidential Computing, ‏ Organization Policy, ‏ Secret Manager, ‏ Sensitive Data Protection, ‏ Wiz Cloud

A05: Injection

‫Apigee, ‏ Cloud Armor, ‏ CodeMender, ‏ Firebase Security Rules, ‏ Cloud Next Generation Firewall (Cloud NGFW), ‏ הגנה מוגברת על המודל, ‏ Security Command Center Premium, ‏ VirusTotal, ‏ Wiz Code

A06: Insecure Design

‫Apigee, ‏ CodeMender, ‏ Mandiant, ‏ Wiz Cloud

‫A07: כשלים באימות

‫Access Context Manager, ‏ Agent Identity, ‏ Apigee, ‏ Cloud Armor, ‏ Cloud Identity, ‏ Firebase App Check, ‏ אימות ב-Firebase, ‏ Google Cloud Fraud Defense, ‏ IAM (Privileged Access Manager, איחוד זהויות של עומסי עבודה, and Workforce Identity Federation), ‏ IAP, ‏ Identity Platform, ‏ Security Command Center Premium, ‏ Secret Manager, ‏ Titan Security Keys, ‏ Wiz Code

‫A08: כשלים בתקינות של תוכנה או נתונים

‫Artifact Analysis, ‏ Assured OSS, ‏ Binary Authorization, ‏ Cloud Armor, ‏ Cloud Build, ‏ Cloud Deploy, ‏ Firebase App Check, ‏ Security Command Center Premium, ‏ VirusTotal, ‏ Wiz Defend

A09: Security Logging & Alerting Failures

‫Access Approval ו-Access Transparency, ‏ Apigee, ‏ Google SecOps, ‏ Cloud Logging, ‏ Cloud Monitoring, ‏ Sensitive Data Protection, ‏ Wiz Defend

A10: Mishandling of Exceptional Conditions

‫Cloud Armor, ‏ Cloud Load Balancing, ‏ Error Reporting, ‏ הגנה מוגברת על המודל

שירותיGoogle Cloud

בקטעים הבאים מפורטות 10 השיטות המומלצות של OWASP לשירותי ליבה שלGoogle Cloud .

Access Approval ו-Access Transparency

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

רלוונטי ל-A09: כשלים ברישום פעולות אבטחה ובהתראות.

כדאי לעיין בשיטות המומלצות הבאות:

  • אוטומציה של תהליך אישור הגישה. כדי לעשות את זה, צריך להגדיר את אישור הגישה כך שישלח מטא-נתונים של בקשות לאישור גישה נכנסות לנושא ב-Pub/Sub. יוצרים מינוי ל-Pub/Sub שמעביר את מטען הנתונים בפורמט JSON לנקודת הקצה של ה-webhook המותאם אישית (למשל, שירות מאומת של Cloud Run, פונקציות של Cloud Run או שער API ארגוני) לצורך עיבוד.
  • התייחסות ליומני Access Transparency כאל טלמטריית אבטחה קריטית. יצירת מדדים מבוססי-יומנים ומדיניות התראות ב-Monitoring כדי לסמן את מרכז פעולות האבטחה (SecOps) אם אנשי Google ניגשים למשאבים רגישים ללא כרטיס תמיכה פעיל ותואם.
  • ייצוא ישיר של יומני Access Transparency אל Google SecOps או אל מערכת SIEM מרכזית של הארגון.
  • יוצרים מדיניות תאימות כדי לבדוק את זרמי היומן באופן קבוע ולוודא שאירועי גישת חירום auto_approved קשורים לאירוע מתועד ברמת חומרה גבוהה.
  • לשליטה קריפטוגרפית, משתמשים בהצדקות לגישה למפתחות כדי לחייב את המערכת לבקש אישור לפענוח מפתח באופן פרוגרמטי.

Access Context Manager

‫Access Context Manager הוא מנוע בקרת הגישה מבוססת-הקשר שלGoogle Cloud. בעזרת Access Context Manager אפשר להגדיר רמות גישה מבוססות-מאפיינים (כמו טווחי כתובות IP של לקוחות, מצב האבטחה של המכשיר ומיקום גיאוגרפי) עבור IAP,‏ VPC Service Controls ו-IAM.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A02: הגדרה שגויה של אבטחה
  • ‫A07: כשלים באימות

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

  • כדאי ליצור רמות אבטחה רב-שכבתיות לשימוש חוזר עבור מדיניות הגישה של הארגון. יצירה של רמות גישה בסיסיות לבדיקה של מאפיינים רגילים. במקרים של תנאים מורכבים עם כמה גורמים, כדאי להטמיע רמות גישה בהתאמה אישית כדי להעריך מצבים מתקדמים של מכשירים ואותות של נקודות קצה של צד שלישי.
  • אפשר להשתמש ב-Endpoint Verification או ב-Chrome Enterprise Core כדי לאכוף הגבלות ברמת המכשיר, כמו הצפנה של כל הדיסק, נעילת מסך פעילה וגרסה מאושרת של מערכת ההפעלה.
  • כדי להגן על מאגרי נתונים בעלי ערך גבוה באמצעות VPC Service Controls, מוסיפים רמות גישה לכללי הכניסה של VPC Service Controls. אם מפתח של חשבון שירות נחשף, תוקף לא יכול להשתמש רק במפתח כדי לשלוח שאילתות ל-BigQuery או ל-Cloud Storage מכתובת IP ציבורית לא מורשית או ממכונה לא מהימנה.
  • כדי להרחיב את ההגנה של גישת אפס-אמון לאפליקציות אינטרנט ולמנהרות אדמיניסטרטיביות של מכונות וירטואליות, צריך לצרף רמות גישה ישירות למשאבים שמאובטחים באמצעות IAP.

כדאי לעיין בשיטות המומלצות הבאות בנושא A02: הגדרת אבטחה שגויה:

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • כדי להגדיר משכי סשן מקסימליים, אפשר להשתמש בהרשאות גישה למשתמשים. מגדירים את מדיניות האימות מחדש כך שתידרש שיטת אימות SECURITY_KEY (FIDO2 או WebAuthn). כדי להחיל אילוצים מחמירים יותר על סביבות בסיכון גבוה, מגדירים את scopedAccessSettings כדי לשנות את משכי ברירת המחדל של הסשנים באפליקציות רגישות.

Agent Gateway וזהות הסוכן

‫Agent Gateway ו-Agent Identity מספקים אכיפה ייעודית של מדיניות רשת ב-Kubernetes, ניהול מחזור החיים של הזהויות ואימות קריפטוגרפי לסוכני AI ולתהליכי עבודה מבוססי-סוכן.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A07: כשלים באימות

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

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

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

Apigee

‫Apigee מספק מנגנונים מרכזיים ברמת השער באמצעות שרתי proxy של API כדי לאכוף תקני הצפנה, לאמת מטענים חתומים ולהצפין נתוני אפליקציות במעבר ובאחסון. פלטפורמת Apigee פועלת כשער פרוקסי הפוך לתעבורת API, ומבצעת בדיקות של גבולות ומבנה כדי לאמת את המטען הייעודי (payload). ‫Apigee מספק מדיניות מובנית לאימות API, ל-OAuth ולאימות JSON Web Token‏ (JWT) כדי ליצור גבולות חזקים של זהויות. ‫Apigee כולל כמה דרכים לביצוע רישום ביומן, מעקב, טיפול בשגיאות ורישום ביומן ביקורת.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • A04: כשלים קריפטוגרפיים
  • ‫A05: הזרקה
  • ‫A06: עיצוב לא מאובטח
  • ‫A07: כשלים באימות
  • ‫A09: כשלים ברישום ביומן ובשליחת התראות אבטחה

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

  • משתמשים בשרתי proxy ל-API כדי לבצע את הפעולות הבאות:

    • יירוט בקשות שבהן תוקף מנסה לגשת לרשומות של משתמש אחר על ידי שינוי משתני מזהה בנתיב בקשת ה-API.

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

  • במישור הניהול של ה-API, אוכפים בקרת גישה, אימות ואחסון סודות באמצעות מפות מוצפנות של זוגות מפתח/ערך, Secret Manager או Kubernetes Secrets (רק בהטמעות היברידיות).

  • משתמשים במדיניות OAuth ובאסימוני JWT כדי לאמת חתימות. ממפים נקודות קצה ופעולות רגישות להיקפי הרשאות מפורטים של OAuth עם הרשאות גבוהות (לדוגמה, delete:account או write:billing). משתמשים במדיניות OAuthV2 כדי לאמת את היקפי ההרשאות האלה בנקודת הכניסה של ה-API, ומחזירים קוד סטטוס 403 Forbidden של HTTP לכל לקוח שאין לו את ההרשאות הנכונות.

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

  • הצפנה של מידע אישי רגיש באפליקציה ואכיפת אימות קריפטוגרפי קפדני לפני שתעבורת הנתונים מגיעה לאפליקציית ה-Backend. מגדירים את סביבת Apigee עם מפתחות הצפנה בניהול הלקוח (CMEK) באמצעות Cloud KMS.
  • כדי להצפין מידע רגיש ברמת הפרוטוקול, משתמשים ב-TLS חד-כיווני ודו-כיווני. בשילובים עסקיים משרת לשרת או בשילובים עסקיים בסיכון גבוה, מגדירים Mutual TLS ‏(mTLS) בשער הכניסה של Apigee.
  • אפשר להשתמש במדיניות VerifyJWT וVerifyJWS כדי לדרוש שלטוקנים נכנסים תהיה חתימה קריפטוגרפית תקפה לפני שהבקשה מעובדת. כדי להקשיח קריפטוגרפית כל בקשה, כדאי להשתמש בטכניקות OAuth סטנדרטיות וליישם HMAC, גיבוב של מטען ייעודי (payload), אימות של מצב או מספר חד-פעמי (nonce) ומפתח הוכחה להחלפת קוד (PKCE).
  • הסתרת מידע אישי רגיש כדי שהנתונים יוצפנו ויוסתרים כשמשתמשים בכלי לניפוי באגים של Apigee.

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

כדאי לעיין בשיטות המומלצות הבאות בנושא A06: עיצוב לא מאובטח:

  • אימות בקשות נכנסות באמצעות מדיניות OASValidation לבקשות נכנסות או להודעות תגובה בהתאם למפרט OpenAPI.
  • כדי לצמצם את העומס על השרתים האחוריים ולמנוע קפיצות בתנועה, כדאי להטמיע את המדיניות SpikeArrest ואת המדיניות Quota.
  • אפשר להשתמש בכללים לטיפול בשגיאות כדי ליירט שגיאות בשרת העורפי (כמו קריסה של מסד נתונים) ולשכתב אותן לתשובות HTTP כלליות.

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • כדי ש-Apigee יוכל לבדוק אם מפתח ה-API של אפליקציית לקוח קיים, תקין ומורשה לגשת למשאב ה-API המבוקש, צריך להטמיע אימות של מפתח ה-API בממשקי ה-API שפונים למפתחים.
  • כדי למנוע גניבה של טוקנים לסשן והתקפות חוזרות, צריך להטמיע הוכחת בעלות (DPoP). פרוטוקול DPoP קושר טוקנים למפתח הציבורי של השולח כדי לצמצם את הסיכון להפעלת טוקנים מחדש.
  • הגנה על נקודות קצה של יצירת טוקנים ושל התחברות מפני מתקפות אוטומטיות של ניסיונות חוזרים וכושלים לפריצה, באמצעות שילוב של הגבלות קצב SpikeArrest עם שילוב של reCAPTCHA Enterprise.

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

  • הזרמת מטא-נתונים של עסקאות מובנות ב-API באופן אסינכרוני ל-Logging או למערכות SIEM של צד שלישי. מצרפים את MessageLogging מדיניות ל-PostClientFlow, שמופעל אחרי שהתשובה מועברת ללקוח.
  • מרכזים את יומני הביקורת של הפלטפורמה כדי לעקוב אחרי שינויים ב-API proxies, בפרטי הכניסה ובסביבות הפריסה. כדי למנוע מצב שבו שינויים לא מורשים בפרוקסי לא יתגלו, כדאי לשלב את Apigee עם Cloud Audit Logs. מידע נוסף זמין במאמרים יומני ביקורת של Apigee ויומני ביקורת של Apigee API Management.
  • הגדרת התראות Advanced API Security ב'מעקב' כדי להודיע לצוותי SecOps על קמפיינים אוטומטיים של גירוד נתונים, על שימוש לרעה בפרטי כניסה ועל ירידה בציון האבטחה.
  • כדי לבצע סניטציה של משתנים שהמשתמשים סיפקו בתבניות של הודעות היומן, צריך להוסיף אותם לפונקציית escapeJSON().
  • אם אתם מזרימים מטא-נתונים של יומנים למערכת SIEM חיצונית, צריך להגדיר את מדיניות MessageLogging לשימוש ב-Syslog דרך TLS (יציאת TCP‏ 6514) כדי להצפין את הנתונים בזמן ההעברה.

‫Artifact Registry ו-Artifact Analysis

‫Artifact Registry הוא מקום מרכזי שבו הארגון שלכם יכול לנהל קובצי אימג' של קונטיינרים וחבילות שפה. ‫Artifact Analysis מספקת סריקה משולבת לאיתור נקודות חולשה, יצירת רשימת רכיבים בתוכנה (SBOM) ואחסון מטא-נתונים של ארטיפקטים שמאוחסנים ב-Artifact Registry.

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • ‫A08: כשלים בשלמות התוכנה או הנתונים

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

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

Assured OSS

‫Assured OSS מאפשר לכם לשלב בחלק מתהליכי העבודה של המפתחים שלכם את חבילות ה-OSS ש-Google מאמתת ומשתמשת בהן.

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • ‫A08: כשלים בשלמות התוכנה או הנתונים

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

  • מגדירים מאגרי קוד מרוחקים שיצביעו על Assured OSS.
  • מוודאים שהספריות בקוד פתוח בגרסאות ה-build מכילות חתימה תקפה של Google ורשומת אישור המקור של Build שניתנת לאימות על ידי SLSA. מגדירים שערים לאיכות ב-Cloud Build כדי לאמת את האישורים האלה לפני הידור של קובצי הפעלה של האפליקציה.
  • מגדירים את מנהלי החבילות (כמו pip.conf,‏ settings.xml או build.gradle) בקובצי הבסיס של Cloud Workstations כך שיפנו רק למאגרי ה-Assured OSS הפנימיים שלכם.
  • אתם יכולים להשתמש במטא-נתונים שנוצרו על ידי Assured OSS כדי לקבוע אם אפשר לנצל לרעה CVE חדש שפורסם בחבילת קוד פתוח בהקשר הספציפי של הפריסה שלכם.

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

Binary Authorization

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

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • ‫A08: כשלים בשלמות התוכנה או הנתונים

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

  • הגדרת צינורות פריסה כדי להפנות לקובצי אימג' של קונטיינרים ולאכוף אותם באמצעות תקציר קריפטוגרפי ייחודי ובלתי ניתן לשינוי של SHA-256 (למשל @sha256).
  • אפשר לפרוס את האימות הרציף של Binary Authorization באשכולות GKE כדי לעקוב אחרי ה-Pods הפעילים בהתאם למדיניות הפלטפורמה, וליצור התראות ב-Logging אם קונטיינרים פועלים כבר לא עומדים בדרישות.

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

  • אפשר לאכוף יצירה אוטומטית של אישורים בצינורות של Cloud Build או GitHub Actions. יצירת דרישות אימות מתקדמות, כך שהתמונות יעברו שלבי אימות רציפים ככל שהן מתקרבות לשלב הייצור.
  • במקרה של אירועי ייצור ברמת חומרה גבוהה, מומלץ להפעיל פריסות חירום של breakglass. אפשר להגדיר מדיניות התראות של Monitoring על אירועים ביומן הביקורת של breakglass כדי להודיע לצוות SecOps כשמתרחש מעקף של אישור.

שירות CA ומנהל האישורים

Certificate Authority Service (CA Service) מאפשר לפרוס ולנהל רשויות אישורים פרטיות (CA) בצורה פשוטה יותר. ‫Certificate Manager מספק הקצאה, חידוש וניהול מרכזיים של אישורי TLS ל-Cloud Load Balancing ול-Cloud CDN.

רלוונטי ל-A04: כשלים קריפטוגרפיים.

כדאי לעיין בשיטות המומלצות הבאות:

  • משתמשים ב-CA Service כדי לבצע אוטומציה של הנפקת אישורים פרטיים וניהול מחזור החיים שלהם. כדי להגן על מפתחות פרטיים, אפשר לפרוס רשויות אישורים (CA) של שורש ושל ביניים שמגובות על ידי Cloud HSM, ולהשתמש בתבניות של אישורים כדי לאכוף מדיניות קריפטוגרפית (כמו אורכי מפתח מינימליים ושימושים מורשים במפתחות מורחבים).
  • כדאי להפעיל את יומני הביקורת ב-Cloud כדי לעקוב אחרי אירועים אדמיניסטרטיביים בסיכון גבוה (כמו ביטול של רשות אישורים, עדכוני מדיניות או עלייה פתאומית במספר בקשות האישורים). העברת התראות ל-Google SecOps כדי לזהות איומים פנימיים פוטנציאליים או צינורות CI/CD שנפרצו.
  • מגדירים את Certificate Manager לשימוש באישורים שמנוהלים על ידי Google בשילוב עם הרשאות DNS. Certificate Manager מאמת את הבעלות על הדומיין, מנפיק את אישור X.509 ומטפל בחידושים 30 יום לפני שהתוקף פג.
  • מצרפים מיפוי אישורים לשרתי proxy של HTTPS כדי לאפשר בחירה דינמית של אישורים ורוטציה של אישורים בלי שיהיה צורך להפעיל מחדש את ה-proxy או להגדיר מחדש את מאזן העומסים.
  • בשביל מיקרו-שירותים פנימיים או איזון עומסים היברידי, מגדירים מיפוי אישורים כדי להנפיק אישורים פרטיים ישירות ממאגר של רשות CA פרטית בשירות CA.
  • הגדרת מיפוי אישורים כדי להתאים בקשות נכנסות של Server Name Indication‏ (SNI) לאישורים ספציפיים.

מאגר משאבי ענן

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

ההמלצה רלוונטית ל-A02: הגדרת אבטחה שגויה.

כדאי לעיין בשיטות המומלצות הבאות:

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

Cloud Armor

‫Cloud Armor הוא חומת אש (WAF) אדפטיבית לאפליקציות אינטרנט שניתן לפרוס בקצה של רשת Google Cloud כדי להתגונן מפני מתקפות DDoS ולחסום מטענים ייעודיים (payloads) של הזרקות SQLi או XSS. ‫Cloud Armor כולל כללי WAF שהוגדרו מראש כדי להתגונן מפני עשרת נקודות החולשה המובילות של OWASP, להגביל את שטח הפנים של נקודות הקצה של האימות ולחסום פרטי כניסה שנפרצו.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A05: הזרקה
  • ‫A07: כשלים באימות
  • ‫A08: כשלים בשלמות התוכנה או הנתונים
  • ‫A10: טיפול לא תקין בתנאים חריגים

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • הגבלת הגישה לנקודות קצה (endpoints) של אימות ואדמין לכתובות IP או למדינות מורשות.
  • מפעילים את evaluatePreconfiguredWaf כדי ליירט ולחסום בקשות שמיועדות לנצל לרעה פגיעויות במצב הסשן וחטיפת סשנים.
  • משתמשים ב-API‏ securityPolicies.patchRule כדי לחסום בקשות נכנסות שמכילות פרמטר שנפרץ במחרוזת השאילתה או בכותרות בקצה הרשת.

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

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

    request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')

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

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

  • הפעלה של הגנה אדפטיבית של Google Cloud Armor בכללי מדיניות האבטחה כדי ליצור בסיס להשוואה של דפוסי תנועה רגילים, להגדיר התראות על אנומליות ב-L7 וליצור כללי WAF ממוקדים עם חתימות של התקפות.
  • מגדירים כללי הגבלת קצב ב-Cloud Armor בנקודות קצה קריטיות (לדוגמה, ממשקי API של /login,‏ /checkout או חיפוש). כללי הגבלת קצב הבקשות מגבילים את הבקשות על בסיס כתובת IP של לקוח או כותרת HTTP (לדוגמה, הגבלת לקוחות ל-100 בקשות בדקה) ומחזירים קוד סטטוס HTTP‏ 429 Too Many Requests.
  • מגדירים את כלל ברירת המחדל עם העדיפות הכי נמוכה במדיניות האבטחה של Cloud Armor ל-Deny (קוד סטטוס: 403 או 404).

‫Cloud Build ו-Cloud Deploy

‫Cloud Build ו-Cloud Deploy מספקים צינור עיבוד נתונים משולב ומאובטח של אינטגרציה רציפה (CI) ופיתוח רציף (CD) ב-Google Cloud. ‫Cloud Build יוצר ארטיפקטים עם provenance שניתן לאימות לפי SLSA ואימותים קריפטוגרפיים, ו-Cloud Deploy מנהל השקות הדרגתיות, אישורי יעד ואימות אוטומטי ב-GKE וב-Cloud Run.

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • ‫A08: כשלים בשלמות התוכנה או הנתונים

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

  • מגדירים את הערך requestedVerifyOption: VERIFIED בקובץ cloudbuild.yaml כך שמקורות מידע שניתן לאמת יידרשו.
  • פריסת מאגרי Cloud Build פרטיים שמקושרים לרשת VPC פרטית עבור בנייה של פרויקטים רגישים בארגון.
  • מגדירים טריגרים של build להפעלה בחשבונות שירות ייעודיים שמנוהלים על ידי משתמש. מקצים לחשבונות השירות האלה רק את הרשאות ההרשאה המינימליות הנדרשות ב-IAM (למשל, Artifact Registry Writer‏ (roles/artifactregistry.writer) ו-Logs Writer‏ (roles/logging.logWriter)).
  • הגדרת אישורים ידניים בטריגרים של Cloud Build שמיועדים לסביבות Staging או ייצור.
  • מגבילים את כלי ה-build של CI (כמו Cloud Build,‏ GitHub Actions או GitLab) לתפקיד Cloud Deploy Releaser (roles/clouddeploy.releaser) כדי שצינורות ה-build יוכלו ליצור רק מהדורות.
  • כדי לדרוש אישורים ידניים, צריך להגדיר את מניפסט צינור ההפצה (delivery-pipeline.yaml) עם requireApproval: true ביעדי הבמה והייצור.
  • הגדרת סביבות הפעלה עם חשבונות שירות ספציפיים ליעד (לדוגמה, חשבון שירות אחד עם הרשאות שמוגבלות למרחב השמות של סביבת הבדיקה, וחשבון שירות נפרד ומבוקר לסביבת הייצור).
  • פריסת ווים בהתאמה אישית כדי להריץ הצהרות אבטחה מחוץ למסגרת במהלך מחזור החיים של ההשקה. משתמשים ב-pre-deploy hooks כדי לוודא שקלאסטרים של יעד עומדים בבסיסי התאימות, וב-post-deploy hooks כדי להתחיל סריקות אוטומטיות של נקודות חולשה מול נקודות קצה של קונטיינרים פעילים.

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

  • שילוב של Cloud Build עם Cloud KMS ו-Artifact Analysis כדי ליצור ולחתום על אישורים קריפטוגרפיים כשבדיקות היחידות ובדיקות הניתוח הסטטי מסתיימות בהצלחה.
  • משתמשים בסיכומי גיבוב (hash) קריפטוגרפיים מסוג SHA-256 שלא ניתן לשנות (לדוגמה, golang@sha256:...) בשלבי בנייה ב-cloudbuild.yaml.
  • אחסון הגדרות build במאגרי מידע עם בקרת גרסאות שמוגנים על ידי כללים להגנה על ענפים (למשל, דרישה לבדיקות על ידי שני אנשים בבקשות משיכה). כדי להגביל את ההרשאות לשינוי טריגרים לאדמינים מורשים בפלטפורמה, משתמשים בחשבונות שירות שמנוהלים על ידי משתמשים.
  • קידום של מניפסטים של פריסות זהים שעברו רינדור מראש ושל תקצירים (digest) של קובצי אימג' של קונטיינרים שלא ניתן לשנות בשלבי היעד, בלי לאפשר לצינורות CI לשנות מניפסטים בין שלבי ההכנה והייצור.
  • מגדירים משימות אוטומטיות לאימות הפריסה במניפסט skaffold.yaml. ‫Cloud Deploy מפעיל את קונטיינרי האימות האלה אחרי שפריסת ה-Pods מסתיימת, כדי להריץ בדיקות תקינות דינמיות, בדיקות שילוב וטענות לגבי חוזי API.
  • שימוש באסטרטגיות של פריסה של גרסה ראשונית (canary). אם בדיקת האימות של Skaffold נכשלת או אם המערכת לניטור מזהה חריגות בסף במהלך שלב קנרי, Cloud Deploy מפסיק את ההשקה ומחזיר את התנועה לגרסה האחרונה של הגרסה היציבה.
  • הגדרת אשכולות GKE ו-Cloud Run כדי לאכוף מדיניות של Binary Authorization. כש-Cloud Deploy מחיל את המניפסטים, בקרת הכניסה של היעד מאמתת באופן קריפטוגרפי את הגיבובים של קובצי האימג' של הקונטיינרים ודוחה ארטיפקטים לא מהימנים.

‫Cloud Identity ומפתחות אבטחה Titan

‫Cloud Identity מספק ניהול מרכזי של זהויות, מחזור החיים של אישורים וגישה ב- Google Cloudוב-Google Workspace. מפתחות האבטחה Titan הם מכשירי אבטחה פיזיים שעמידים בפני פישינג ומתבססים על קריפטוגרפיה של מפתחות ציבוריים בהתאם לתקני FIDO2 או WebAuthn.

רלוונטי ל-A07: כשלים באימות.

כדאי לעיין בשיטות המומלצות הבאות:

  • כדי להגן על החשבון מפני מתקפות פישינג מסוג "אדם בתווך" (PITM), צריך להגדיר אימות דו-שלבי (2SV) ולהגדיר את השיטה המותרת למפתחות אבטחה בלבד (FIDO2,‏ WebAuthn או מפתחות אבטחה של Titan).
  • הגדרת כניסה יחידה (SSO) שמבוססת על SAML 2.0 או על OIDC באמצעות ספק הזהויות הארגוני שלכם, לצד הקצאת הרשאות אוטומטית.
  • מגדירים את מדיניות משך הפעילות שלGoogle Cloud לסף מקסימלי נמוך כדי לאלץ את המשתמשים לבצע אימות מחדש באופן תקופתי.
  • כדאי לרשום מפתחות אבטחה Titan כמפתחות גישה כדי להפעיל אימות ללא סיסמה, וכך לצמצם באופן משמעותי את הסיכונים של מתקפות כוח ברוטלי ושל פריצה לפרטי הכניסה.
  • הגדרת אימות דו-שלבי באמצעות מפתחות אבטחה Titan עבור זהויות עם הרשאות מיוחדות (כמו בעלי פרויקטים, אדמינים לחיוב וצוותי SecOps) על ידי אכיפת מדיניות מפתחות אבטחה ב-Cloud Identity. להירשם לתוכנית ההגנה המתקדמת עבור משתמשים בסיכון גבוה.

Cloud KMS

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

רלוונטי ל-A04: כשלים קריפטוגרפיים.

כדאי לעיין בשיטות המומלצות הבאות:

  • משתמשים ב-Cloud KMS Autokey כדי להפוך את ההקצאה וההקצאה לאוטומטיות. עם Autokey, אין צורך להקצות מראש מחזיקי מפתחות, מפתחות וחשבונות שירות. במקום זאת, מפתחות ואוספי מפתחות נוצרים לפי דרישה כחלק מיצירת משאבים.
  • משתמשים במפתחות Cloud KMS כדי להצפין נתונים רגישים לפני שהם נשלחים למאגרי אחסון או למסדי נתונים. אתם יכולים להשתמש ב-Cloud KMS API או בספריות לקוח כדי להשתמש במפתחות Cloud KMS להצפנה בצד הלקוח.
  • אימות של תקינות הנתונים מקצה לקצה באמצעות אימות של סכומי ביקורת במהלך ההעברה.
  • כדי לעמוד בדרישות מחמירות של תאימות ורגולציה, מומלץ לאחסן ולהפעיל את הפעולות הקריפטוגרפיות באמצעות Cloud HSM. ב-Cloud HSM המפתחות מאוחסנים במודולים של אבטחת חומרה (HSM) עם אימות FIPS 140-3 ברמה 3.
  • הגדרת לוחות זמנים לרוטציית מפתחות אוטומטית בפרק זמן מוגדר (לדוגמה, כל 90 יום).

Cloud Load Balancing

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

ההגדרה הזו חלה על:

  • ‫A04: כשלים קריפטוגרפיים
  • ‫A10: טיפול לא תקין בתנאים חריגים

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

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

Google Cloud Observability (רישום ביומן, מעקב ו-Error Reporting)

‫Google Cloud Observability מספקת ניהול מלא של יומנים באמצעות Logging, מדדים והתראות באמצעות Monitoring ומעקב בזמן אמת אחרי קריסות של אפליקציות באמצעות Error Reporting.

ההגדרה הזו חלה על:

  • ‫A09: כשלים ברישום ביומן ובשליחת התראות אבטחה
  • ‫A10: טיפול לא תקין בתנאים חריגים

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

  • מומלץ להפעיל יומני גישה לנתונים למאגרי נתונים בעלי ערך גבוה (כמו Cloud Storage,‏ BigQuery ו-Spanner) שמאחסנים מידע אישי רגיש. יומני הגישה לנתונים מאפשרים לכם לבצע ביקורת על כל אירוע קריאה, כתיבה ושאילתה של מידע אישי רגיש.
  • אפשר לאכוף נעילת קטגוריות ומדיניות שמירת נתונים בקטגוריית הרישום המותאמת אישית כדי למנוע מתוקפים או מאדמינים לא מורשים למחוק יומנים כדי לטשטש את עקבותיהם.
  • אפשר להשתמש במאגרי נתונים משולבים כדי לאסוף ולנתב רשומות ביומן למאגר מרכזי יחיד עבור צוותי SecOps. כדי להימנע מאחסון יומנים בכמות גדולה, כמו יומני גישה לנתונים, ביותר ממקום אחד, צריך להגדיר את היירוט של מאגרי נתונים מצטברים.
  • מגדירים כללי מדיניות להתראות שמבוססות על יומנים לגבי אינדיקטורים קריטיים של פריצה, כמו שגיאות IAM של 'נדחתה הרשאה', יצירות לא צפויות של מפתחות API או שינויים פתאומיים בהגדרות של חומת האש.
  • פריסת מדיניות התראות שמבוססת על יומנים ב-Logs Explorer או ב-Monitoring. כדאי לציין מסננים מדויקים שמטרגטים אירועים ברמת חומרה גבוהה, כמו שינויים לא מורשים במדיניות IAM או ביטולים של מפתחות KMS, כדי שתישלח התראה על אירוע כשמערכת הניתוח תזהה רשומה תואמת ביומן.
  • אפשר ליצור מדדים של מונה מבוסס-יומן ב-Logging כדי להמיר רשומות יומן תואמות לנתונים של סדרת זמן. לאחר מכן, יוצרים ב-Monitoring מדיניות התראות שמבוססת על מדדים, שתתחיל אירוע כשהשיעור יעלה על סף מסוים (לדוגמה, יותר מ-50 ניסיונות כניסה שנכשלו בחמש דקות).
  • הגדרת מדיניות התראות שמבוססת על יומנים, שמנטרת קריאות אדמיניסטרטיביות ל-Cloud Logging API ושולחת התראות על שינויים לא צפויים ביעד לייצוא יומנים או על מחיקות של קטגוריות.
  • הגדרת ערוצי התראות באמצעות תבניות ברורות של תיעוד. כדי לעזור למהנדס התורן לטפל באירוע במהירות, כדאי לכלול קישורי עומק ישירים לשאילתה בכלי Logs Explorer, נהלים סטנדרטיים (SOP) ושלבים מפורשים לתיקון.

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

  • משלבים Error Reporting SDKs ישירות בקוד האפליקציה או מגדירים רישום ביומן כדי לנתח פורמטים מובנים של חריגות ב-JSON.
  • כדי לקבל הודעה לצוותי SecOps כשמופיע סוג חדש של חריגה, צריך להגדיר ערוצי התראות של Error Reporting או מדיניות התראות של מעקב.

Cloud NGFW

‫Cloud NGFW הוא שירות מנוהל של חומת אש שמאפשר בדיקה עם שמירת מצב ושליטה באפליקציות של Layer 7 עבור תעבורת נתונים מצפון לדרום וממזרח למערב.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A05: הזרקה

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

  • מגדירים את שירות הזיהוי והמניעה של פריצות באמצעות קבוצת פרופילי אבטחה שדוחה איומים שתואמים לחתימות של הזרקת SQL, הזרקת פקודות למערכת ההפעלה וניצול לרעה של הרצת קוד מרחוק.
  • מגדירים בדיקת TLS ב-Cloud NGFW כדי לפענח תעבורת HTTPS נכנסת ויוצאת, להחיל בדיקות חתימה של הזרקת IPS על מטען ייעודי (payload) בטקסט לא מוצפן ולהצפין מחדש את הסשן לפני המסירה לבק-אנד.
  • אכיפה של כללי חומת אש ליציאה שמבוססים על FQDN במסדי נתונים של קצה עורפי וברשתות משנה של Compute. הגבלת חיבורים יוצאים לדומיינים חיצוניים מאושרים ומוגדרים מראש, כדי למנוע מאפליקציות פגיעות ליצור מעטפות הפוכות לא מורשות.
  • מפעילים רישום ביומן של כללי חומת אש בפרופילים למניעת איומים ומנתבים את היומנים האלה אל Google SecOps כדי ליצור קורלציה בין חתימות של הזרקת רשת חסומה לבין טלמטרייה ברמת המארח, וכך לזהות עומסי עבודה ממוקדים לתיקון בעדיפות גבוהה.

תחנות עבודה בענן

‫Cloud Workstations מספקת סביבות פיתוח מנוהלות ב- Google Cloud עם אבטחה מובנית ואפשרויות התאמה אישית.

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • A04: כשלים קריפטוגרפיים

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

CodeMender

‫CodeMender הוא סוכן AI אוטונומי וייעודי להנדסה. CodeMender יכול לתקן פגיעויות חדשות שהתגלו ולשכתב קוד מדור קודם כדי לטפל בפגיעויות קיימות. אתם יכולים להתקין ולהגדיר את CodeMender ב-Gemini Enterprise Agent Platform.

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • ‫A05: הזרקה
  • ‫A06: עיצוב לא מאובטח

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

  • אפשר לשלב את CodeMender CLI בסביבות עבודה מקומיות של מפתחים ובצינורות CI/CD כדי לסרוק מודולים ממוקדים, לאמת את האפשרות לניצול לרעה ולזהות נקודות חולשה באבטחה לפני שהקוד נשמר.
  • ייבוא של דוחות ניתוח הרכב התוכנה (SCA) ודוחות על נקודות חולשה בתלות אל CodeMender כדי להריץ אימותים של ניצול הוכחת היתכנות, סינון של תוצאות חיוביות שגויות לפני בדיקה על ידי מפתחים.

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A06: עיצוב לא מאובטח:

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

Confidential Computing

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

רלוונטי ל-A04: כשלים קריפטוגרפיים.

כדאי לעיין בשיטות המומלצות הבאות:

  • מומלץ להשתמש ב-Confidential VMs או ב-Confidential Google Kubernetes Engine Nodes לעומסי עבודה רגישים במיוחד (כמו פרטים אישיים מזהים, רשומות פיננסיות או משקלים קנייניים של מודלים של AI).
  • כשכמה ארגונים צריכים לאגד מידע אישי רגיש לצורך ניתוח או אימון AI (בלי לחשוף את הנתונים הגולמיים אחד לשני), אפשר להשתמש ב- Confidential Space כדי לאכוף אימות קריפטוגרפי ובידוד נתונים.

‫Firebase (אימות ב-Firebase,‏ Firebase App Check ו-Firebase Security Rules)

פלטפורמת Firebase מספקת אמצעי בקרה לאבטחה שמתמקדים במפתחים, בתחומי הזהות, אימות הלקוח והגישה למסד הנתונים. אימות ב-Firebase מטפל בזהות המשתמש ובניהול הסשנים, App Check מאמתת את תקינות האפליקציה של הלקוח, וכללי האבטחה של Firebase אוכפים בקרת גישה מבוססת-מאפיינים ואימות סכימה עבור Firestore ו-Cloud Storage.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A05: הזרקה
  • ‫A07: כשלים באימות
  • ‫A08: כשלים בשלמות התוכנה או הנתונים

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

  • היקף ההרשאות קורא וכותב למזהה של המשתמש המאומת בכללי האבטחה של Firebase. אל תשתמשו בכללי ברירת מחדל מתירים כמו allow read, write: if true;.
  • לתפקידי אדמין, משתמשים ב-Firebase Admin SDK כדי להגדיר טענות מותאמות אישית באסימוני המזהים של המשתמשים, ומאמתים את הטענות האלה בכללי האבטחה במקום לאפשר כתיבת פרופילים מצד הלקוח.
  • אוכפים את השימוש ב-App Check בכללי האבטחה של Firebase כדי לחסום גישה של לקוחות לא מאומתים או מזויפים בשכבת מסד הנתונים.

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

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

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • כדי להפעיל אמצעי הגנה לארגונים כמו MFA עם TOTP ופונקציות חסימה, צריך לשדרג לאימות ב-Firebase עם Identity Platform.
  • כדאי לאמת טוקנים של מזהי Firebase בקצה העורפי באמצעות SDK של Firebase לאדמינים לפני שמעניקים גישה לנתונים רגישים של האפליקציה.
  • אפשר להשתמש בספק של ניפוי באגים כדי ליצור אסימונים זמניים של ניפוי באגים עם היקף מוגדר למפתחים ולצינורות CI/CD בסביבות פיתוח.

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

Fraud Defense

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

רלוונטי ל-A07: כשלים באימות.

כדאי לעיין בשיטות המומלצות הבאות:

  • משלבים את reCAPTCHA עם WAF קיים, כמו Google Cloud Armor, כדי להציג אתגרים אוטומטיים או לחסום תנועת בוטים בסיכון גבוה לפני שהבקשות מגיעות לנקודות קצה של אימות.
  • הגנה על חשבונות בנקודות קצה של התחברות, איפוס סיסמה וחידוש סשן. קבלת ציוני סיכון של השתלטות על חשבון (ATO) על סמך מהירויות הכניסה של המשתמשים וטביעות האצבע של המכשירים.
  • הגנה מפני הונאות טלפון ב-SMS בטפסים של הרשמה ואימות דו-שלבי, על ידי הערכת פרופילי הסיכון של מספרי הטלפון לפני שליחת הודעות SMS יוצאות.
  • כדי להפחית את מספר התוצאות החיוביות הכוזבות ולאמן מודלים להערכת סיכונים ספציפיים לאתר, חשוב להוסיף הערות ולשלוח משוב על עסקאות באופן קבוע.
  • בדיקת סיסמאות במהלך תהליכי הכניסה של משתמשים ויצירת חשבונות, כדי לזהות אם פרטי הכניסה שנשלחו מופיעים במסדי נתונים של פרצות באבטחת מידע של צד שלישי באינטרנט.

Google SecOps

‫Google Security Operations היא פלטפורמה לתפעול אבטחה שמשלבת ניתוח טלמטריה של אבטחה (SIEM), תזמור אבטחה, אוטומציה ותגובה (SOAR) ומודיעין איומי סייבר של Mandiant בחזית, והכול בפלטפורמה אחת.

ההגדרה הזו חלה על:

  • ‫A02: הגדרה שגויה של אבטחה
  • ‫A09: כשלים ברישום ביומן ובשליחת התראות אבטחה

כדאי לעיין בשיטות המומלצות הבאות בנושא A02: הגדרת אבטחה שגויה:

  • אפשר להטמיע ממצאים מ-Security Command Center ב-Google SecOps כדי לשלב ממצאים סטטיים של הגדרות שגויות (לדוגמה, PUBLIC_BUCKET_ACL או CMEK_DISABLED) עם טלמטריה של רשתות וחומות אש בזמן אמת.
  • יצירת ספרי הפעלה אוטומטיים של SOAR להפעלת פעולות של בלימה.
  • אפשר להשתמש ב-Gemini כדי לזרז את תהליך המיון של טעויות בהגדרות, ולקבל סיכומים מסונתזים של נכסים עם הגדרות שגויות, תפקידי IAM מצורפים והנחיות מפורטות לתיקון.

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

  • נרמול של טלמטריה של יומנים למודל נתונים מאוחד (UDM) כדי לאפשר חיפוש מהיר, סטנדרטי ורב-ענני ומתאם ללא התקורה של ניתוח יומנים גולמיים.
  • לכתוב כללי זיהוי של YARA-L 2.0 כדי לעקוב אחרי שינויים בהגדרות שעלולים לסכן את האבטחה, כמו השבתה של OS Login, מחיקה של יעד ליומנים או שינויים בהיקפי האבטחה של VPC Service Controls.
  • אפשר להשתמש בזיהויים של איומים שנוצרו על ידי Mandiant Threat Intelligence כדי להשוות את נתוני האירועים שלכם לנתוני Mandiant Threat Intelligence.
  • אתם יכולים להשתמש ב-Gemini ב-Google SecOps כדי ליצור כללי זיהוי של YARA-L מתיאורים בשפה טבעית, ולסכם ציר זמן מורכב של אירועים רב-שלביים לסיכומי אירועים למנהלים.

שרת proxy לאימות זהויות (IAP)

‫IAP יוצר שכבת הרשאה מרכזית לאפליקציות שאפשר לגשת אליהן באמצעות HTTPS וחיבורי TCP אדמיניסטרטיביים. ‫IAP מאמת את הזהות וההקשר של המשתמש לפני שהוא מעניק גישה למשאבים ב-Cloud Run,‏ App Engine,‏ Compute Engine,‏ GKE ולמשאבים מקומיים.

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A07: כשלים באימות

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

  • אפשר לאכוף בקרות גישה מפורטות לאפליקציות אינטרנט, למכונות וירטואליות, ל-API ולאפליקציות Google Workspace על סמך זהות המשתמש, חברות בקבוצה וההקשר של הבקשה. Google Cloud
  • שילוב עם Agent Gateway כדי לאכוף את אמצעי בקרת הגישה לזהויות הסוכנים.
  • משתמשים בהעברת TCP של IAP כדי ליצור מנהרות HTTPS מוצפנים למופעי ה-Backend ולהסיר נקודות קצה של SSH (יציאה 22) ו-RDP (יציאה 3389) שפונות לאינטרנט.

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • אימות משתמשים שניגשים לממשקי ניהול ולאפליקציות אינטרנט דרך IAP באמצעות זהויות שהוקצו ב-IAM או ב-Cloud Identity.
  • מאמתים את הצהרת ה-JWT החתומה בתוך הכותרת x-goog-iap-jwt-assertion בשכבת האפליקציה. מאמתים את החתימה מול המפתחות הציבוריים של Google ומוודאים שהצהרת הקהל (aud) זהה למזהה של שירות לקצה העורפי.
  • כדי למנוע מהתוקפים לעקוף את האימות של IAP, צריך להגדיר את הגדרות הכניסה (ingress) של Cloud Run כך שיתאפשר רק מעבר של תעבורת נתונים פנימית ותעבורת נתונים של Cloud Load Balancing, ולחסום גישה ציבורית ישירה לכתובות ה-URL של מאגרי ה-backend. במכונות וירטואליות או בצמתי GKE, צריך להגדיר כללים של חומת אש ב-VPC כך שיתקבל רק מעבר של תעבורת נתונים נכנסת (ingress) שמגיעה מטווח כתובות ה-IP של מאזן העומסים.

ניהול זהויות והרשאות גישה

ניהול זהויות והרשאות גישה (IAM) מאפשר לכם לנהל גישה פרטנית לשירותים ולמשאבים ב- Google Cloud. ‫IAM כולל תכונות כמו:

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A07: כשלים באימות

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

  • כדי להגביל את ההרשאות למשאב ספציפי או לצרכים של משתמש מסוים, צריך להשתמש בתפקידים מוגדרים מראש או בתפקידים בהתאמה אישית (ולא בתפקידים בסיסיים).
  • הגבלת ההרשאות להקצאת התפקידים 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) ו'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator).
  • אפשר להשתמש בכלי ההמלצות של IAM כדי לנתח את יומני השימוש הפעיל של הארגון ולהסיר חשבונות עם הרשאות מוגזמות.
  • כותבים IAM Conditions בקישורי התפקידים כדי להוסיף הרשאה מבוססת-הקשר ולהגביל את הגישה לפי תאריך, שעה ביום או כתובת IP שממנה מגיעה הבקשה.
  • פריסת מדיניות לקביעת הגישה לישויות מורשות (PAB) כדי להגדיר את הארגונים, התיקיות או הפרויקטים שקבוצת חשבונות משתמשים יכולה לגשת אליהם. אם תוקף גונב סשן פעיל או אם לחשבון שירות ניתנות בטעות הרשאות גישה רחבות ב-IAM, ‏ PAB חוסם את הגישה אם המשאב שצוין נמצא מחוץ לגבול המיועד של הזהות.
  • מצרפים מדיניות דחייה ב-IAM ברמת הארגון או התיקייה כדי לחסום הרשאות בסיכון גבוה (כמו iam.serviceAccountKeys.create או resourcemanager.projects.delete).
  • כשמגדירים כללי דחייה ב-IAM, צריך להצהיר על קבוצת אבטחה ייעודית לגישה במקרה חירום ברשימה exceptionPrincipals. כדאי להשתמש בתגי משאבים בתנאי הדחייה (למשל resource.matchTag('env', 'prod')), כדי לחסום פעולות הרסניות במשאבי הייצור, ובמקביל לאפשר למפתחים גמישות תפעולית בפרויקטים של ארגז חול לפיתוח.

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות שרלוונטיים ל-Privileged Access Manager:

  • המרת תפקידי אדמין קריטיים (כמו בעלים (roles/owner), אדמין ארגוני (roles/resourcemanager.organizationAdmin) ואדמין אבטחה (roles/iam.securityAdmin)) מקישורי IAM סטטיים להרשאות ב-Privileged Access Manager. מגדירים את ההרשאות האלה כך שתידרש הצדקה תפעולית לפני שתינתן העלאת הרשאות.
  • בסביבות ייצור, מגדירים מדיניות של הרשאות ב-Privileged Access Manager עם מאשרים חובה, כמו קבוצת SecOps מרכזית או ראשי צוותים.
  • מגדירים את משך הזמן המקסימלי להרשאות ב-Privileged Access Manager לחלון התפעולי הקצר ביותר האפשרי (לדוגמה, שעתיים לתחזוקה רגילה, 30 דקות לפעולות במקרה חירום). אחרי שהטיימר יפוג, Google Cloud הקישור הזמני של תפקיד IAM יוסר.
  • ניהול של תשתית Terraform באמצעות משאבי IAM לא סמכותיים (לדוגמה, google_project_iam_member או google_folder_iam_member במקום google_project_iam_policy או google_project_iam_binding). כך נמנעת דריסה של צינורות Terraform או ביטול הסנכרון של הקצאות זמניות של תפקידים ב-Privileged Access Manager, בזמן שאדמין מתקן באופן פעיל תקרית.
  • מפעילים את יומני הביקורת של Cloud ב-Privileged Access Manager כדי לתעד פעולות של הרשאות ואירועים של תפוגה. כדאי להטמיע את היומנים האלה ב-Google SecOps כדי לקבל התראות על דפוסי הרשאה חשודים, כמו בקשות רבות להעלאת הרשאות בשעות לא שגרתיות או בקשות חוזרות ממיקומים גיאוגרפיים לא צפויים.

השיטות המומלצות הבאות בנושא A07: כשלים באימות רלוונטיות לאיחוד שירותי אימות הזהות של כוח עבודה:

  • פריסת מאגרי זהויות של כוח העבודה באמצעות SAML 2.0 או OpenID Connect ‏ (OIDC) כדי לאחד ספקי זהויות חיצוניים עםGoogle Cloud.
  • מגדירים את משך הסשן במאגר הזהויות של כוח העבודה כדי להגביל את משך החיים של טוקנים של משתמשים מאוחדים.
  • אפשר לאכוף תנאי מאפיינים על ספקי זהויות של כוח עבודה כדי לצמצם את הסיכון לזיוף אסימונים של ספקי זהויות מרובי-דיירים או להתחזות חוצת-ארגונים.
  • מיפוי של חברות בקבוצות חיצוניות כדי להקצות תפקידי IAM לקבוצות של משתמשים מאוחדים (לדוגמה, principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

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

  • יצירת ספקים ומאגרי זהויות של עומסי עבודה לעומסי עבודה חיצוניים. שימוש באסימוני OIDC לטווח קצר, והחלפתם באופן דינמי באמצעות Security Token Service באסימוני גישה זמניים שתוקפם פג תוך דקות.
  • אוכפים תנאים של מאפיינים על ספקי זהויות של עומסי עבודה, כדי שפלטפורמות חיצוניות מרובות דיירים לא יוכלו לבצע אימות למאגר ממאגרים או מחשבונות לא מורשים.
  • לקשר תפקידי IAM ישירות לקבוצות ספציפיות של חשבונות משתמשים שמסוננות לפי מאפיינים מותאמים אישית.
  • כשמגדירים גישה לעומסי עבודה, צריך להעניק תפקידי IAM ישירות למזהה המאוחד principalSet:// במשאב היעד.
  • כדי לאכוף את השימוש באיחוד זהויות של עומסי עבודה, מגדירים את ההגבלה constraints/iam.disableServiceAccountKeyCreation בארגון.

Identity Platform

‫Identity Platform היא פלטפורמה לניהול זהויות והרשאות של לקוחות (CIAM) עבור לקוחות של Google Cloud . Identity Platform מספקת אימות עם תמיכה בריבוי פרוטוקולים באמצעות ערכות SDK וממשקי API. פלטפורמת Identity Platform תומכת באימות רב-שלבי (MFA), בשילוב עם שירותי אימות של צד שלישי ובמעקב אחר פעילות שניתן לביקורת.

רלוונטי ל-A07: כשלים באימות.

כדאי לעיין בשיטות המומלצות הבאות:

  • הפעלה של MFA בכל בסיס המשתמשים. מומלץ לתת עדיפות לשיטות שקשה יותר לפרוץ, כמו TOTP (אפליקציות לאימות) או WebAuthn (מידע ביומטרי ומפתחות אבטחה).
  • פורסים פונקציות חסימה של Cloud Run באמצעות טריגרים של beforeCreate ו-beforeSignIn כדי להריץ קוד אבטחה בהתאמה אישית לפני שמירת משתמש או הנפקת אסימון. השיטה הזו מאפשרת לחסום דומיינים של כתובות אימייל זמניות, להגביל כתובות IP או לדרוש אימות של כתובות אימייל.
  • שילוב עם reCAPTCHA Enterprise כדי להעריך בקשות להתחברות, להרשמה ולאיפוס סיסמה, ולזהות תנועה של בוטים, ניסיונות להחדרת פרטי כניסה וניצול לרעה אוטומטי.
  • הגדרת מדיניות סיסמאות כדי לאכוף אורך מינימלי של תווים, לדרוש מורכבות ספציפית של תווים (כמו מספרים וסמלים) ולחסום רצפים צפויים.
  • אם משתמשים באימות רב-שלבי (MFA) שמבוסס על טלפון, צריך להגדיר אזורים של SMS ולהפעיל את הגנת reCAPTCHA מפני SMS כדי להגביל את הודעות האימות לקודי המדינה שבהם נמצאים משתמשי היעד.

פתרונות ייעוץ בנושא אבטחת AI של Mandiant

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

ההגדרה רלוונטית ל-A06: עיצוב לא מאובטח.

כדאי לעיין בשיטות המומלצות הבאות:

  • כדאי להזמין יועצים של Mandiant לפני תחילת הפיתוח כדי להשלים סדנאות בנושא ארכיטקטורה וליישם אמצעי בקרת אבטחה מההתחלה.
  • כדאי לשתף פעולה עם מומחים למיפוי איומים כדי למפות את דיאגרמות זרימת הנתונים של האפליקציה. צריך להגדיר איפה מידע אישי רגיש חוצה גבולות של אמון כדי לזהות איפה צריך לאכוף אמצעי בקרה קפדניים לאימות, להצפנה ולתיקוף.
  • במהלך סדנאות הארכיטקטורה, כדאי להשתמש במסגרות מובְנות למידול איומים (כמו STRIDE). יועצי Mandiant יכולים לעזור לכם לתעדף את הפגמים בעיצוב שזוהו על סמך יכולת הניצול שלהם בעולם האמיתי וההשפעה שלהם על העסק.
  • הגדרת בסיסי אבטחה לניהול AI בתהליכי עבודה מבוססי-סוכנים ובפריסות של LLM, והגדרת גבולות ברורים של אמון בין סוכני AI, שרתי MCP ומקורות נתונים של קצה עורפי בארגון.

הגנה מוגברת על המודל

‫Model Armor נועד לסנן הנחיות, תשובות וקריאות לכלים של MCP במודלים גדולים של שפה (LLM). ‫Model Armor בודק מטענים ייעודיים (payloads) של AI גנרטיבי כדי לזהות ולחסום החדרה של הנחיות, ניסיונות לפריצת חומות הגנה, כתובות URL זדוניות, תוכן רעיל ודליפה של נתונים רגישים.

ההגדרה הזו חלה על:

  • ‫A05: הזרקה
  • ‫A10: טיפול לא תקין בתנאים חריגים

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

  • פריסת מדיניות הגנה מוגברת על המודל בשכבת API Gateway באמצעות שילוב של Apigee או Agent Gateway כדי לסנן פרומפטים נכנסים ותשובות יוצאות של מודלים לפני שתעבורת הנתונים מגיעה למנועי היקש או לזמני ריצה של כלים.
  • מגדירים הגדרות אבטחה מינימליות ברמת הארגון או התיקייה כדי ליצור אמצעי הגנה בסיסיים שצוותי פרויקטים לא יכולים לעקוף.
  • יצירת תבניות מותאמות אישית של Model Armor עם ספי ביטחון מותאמים (לדוגמה, LOW_AND_ABOVE או MEDIUM_AND_ABOVE) לזיהוי של הזרקת הנחיות ופריצה לנקודות קצה ציבוריות.
  • מפעילים את האפשרות לזיהוי כתובות URL זדוניות ואת האפשרות לסריקת קובצי PDF וקבצים אחרים בתבנית הגנה מוגברת על המודל כדי לבדוק כתובות URL מוטמעות מול מסדי הנתונים של Google למודיעין איומי סייבר. הסרת הנחיות שמכילות תוכנות זדוניות או וקטורים של פישינג לפני ההרצה.
  • כדי לבדוק את תנועת היציאה של המודל, צריך להפעיל את Sensitive Data Protection בתבנית Model Armor. מגדירים הסרת פרטי הזיהוי אוטומטית או מיסוך כדי להחליף מידע אישי רגיש שזוהה במחזיקי מקום לפני שהתשובה יוצאת מהגבול.

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

  • מגדירים את קוד האפליקציה כך שיעצור את MATCH_FOUNDההחלטות ויחזיר תשובה כללית, כדי שהמערכת לא תבצע את ההנחיה כברירת מחדל או תחשוף עקבות חריגות גולמיות.
  • כדאי להטמיע ארכיטקטורה של fail-closed (fail-secure) בקוד האפליקציה כדי לדחות הנחיות נכנסות ל-AI גנרטיבי אם קריאות ל-API של הגנה מוגברת על המודל נתקלות בפסק זמן ברשת, במגבלות קצב או בשגיאות HTTP 5xx שלא טופלו.

מדיניות הארגון

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

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A02: הגדרה שגויה של אבטחה
  • ‫A04: כשלים קריפטוגרפיים

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

  • אפשר לאכוף את constraints/storage.publicAccessPrevention כדי לבטל מדיניות IAM או רשימות ACL ברמת הקטגוריה שמנסות להעניק גישה ל-allUsers או ל-allAuthenticatedUsers.
  • אפשר להשתמש ב-constraints/iam.allowedPolicyMemberDomains כדי להגביל את הקישורים של מדיניות IAM רק למזהי הלקוחות המאומתים שלכם ב-Google Workspace או ב-Cloud Identity.
  • אפשר לאכוף את constraints/iam.disableServiceAccountKeyCreation בתיקיות של סביבת הייצור כדי למנוע ממשתמשים להוריד מפתחות של חשבונות שירות, וכך לחייב את צוותי ההנדסה להשתמש בחלופות לטווח קצר כמו איחוד שירותי אימות הזהות של עומסי עבודה.
  • אוכפים את האילוץ constraints/iam.automaticIamGrantsForDefaultServiceAccounts כדי ש- Google Cloud לא יקצה באופן אוטומטי לחשבונות שירות שמוגדרים כברירת מחדל את התפקיד 'עריכה' (roles/editor) שכולל הרשאות רבות.
  • אם יש דרישות שלא נכללות באילוצים המוגדרים מראש, אפשר לפרוס אילוצים מותאמים אישית כדי לאכוף הגדרות משאבים מפורטות. כדאי לשקול להגביל את יצירת המכונות הווירטואליות רק למשפחות מכונות שאושרו, להגביל את הגדלים של הקצאת דיסקים קבועים או לדרוש הגדרות ספציפיות של תגי חומת אש ברשת.

כדאי לעיין בשיטות המומלצות הבאות בנושא A02: הגדרת אבטחה שגויה:

  • משתמשים ב-constraints/compute.requireShieldedVm כדי לדרוש מכונה וירטואלית מוגנת, וכך עוזרים להגן על מכונות וירטואליות מפני ערכות כלים להשגת הרשאות רוט בקרנל, ערכות כלים להשגת הרשאות רוט באתחול ושיבוש קושחה.
  • האפשרות constraints/compute.requireOsLogin מאפשרת לדרוש ממופעי Linux להשתמש ב-OS Login, שמקשר את הגישה ל-SSH ישירות לזהויות IAM של המשתמשים ולאימות הדו-שלבי.
  • אפשר לאכוף את ההגדרה constraints/compute.disableSerialPortAccess כדי לחסום חיבורים אינטראקטיביים למסוף הטורי בין פרויקטים.
  • אוכפים את constraints/compute.skipDefaultNetworkCreation כדי שלא תיווצר רשת VPC כברירת מחדל, וכך הצוותים נאלצים ליצור רשתות VPC מותאמות אישית עם תת-רשתות ייעודיות ומדיניות חומת אש מחמירה.
  • אפשר להשתמש ב-constraints/sql.restrictPublicIp כדי לאכוף שרק כתובות IP פנימיות פרטיות מסוג RFC 1918 יוקצו למכונות Cloud SQL, וב-constraints/compute.vmExternalIpAccess כדי להגביל את כתובות ה-IPv4 הציבוריות במכונות הווירטואליות.
  • הוספת ההגבלה constraints/gcp.resourceLocations כדי להגביל את יצירת המשאבים לאזורים מורשים Google Cloud .

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

  • כדי לחייב שימוש ב-CMEK, צריך להחיל את constraints/gcp.restrictNonCmekServices ברמת הארגון או בתיקייה ברמה העליונה, להגדיר את סוג המדיניות ל-Deny ולציין את Google Cloud השירותים הנתמכים. לפני שמפעילים את האילוץ, צריך לוודא שסוכן השירות לכל שירות יעד קיים ושהוקצה לו התפקיד Cloud KMS CryptoKey Encrypter/Decrypter ‏(roles/cloudkms.cryptoKeyEncrypterDecrypter) במאגרי המפתחות הרלוונטיים.
  • האילוץ constraints/gcp.restrictCmekCryptoKeyProjects מגביל את בחירת המפתחות לפרויקטים ייעודיים של Cloud KMS.

Secret Manager

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

ההגדרה הזו חלה על:

  • A04: כשלים קריפטוגרפיים
  • ‫A07: כשלים באימות

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • מסירים ערכים רגישים כמו מפתחות API מקוד המקור, מקבצי .env ומקובצי הגדרות של בניית קונטיינרים, ומאחסנים את פרטי הכניסה ב-Secret Manager. אחזור ערכים מפוענחים בזמן ריצה באמצעות ספריות לקוח שלGoogle Cloud , מנהלי התקן של GKE Secret Store CSI או קשירת סודות של Cloud Run.
  • כדאי להחיל את הקישורים של מדיניות IAM ישירות על סודות ספציפיים, ולהעניק למיקרו-שירותים את התפקיד Secret Manager Secret Accessor ‏ (roles/secretmanager.secretAccessor) רק על הסודות הספציפיים שהם צריכים.
  • הגדרת תזמונים של רוטציה אוטומטית ב-Secret Manager. כשמתחיל מרווח זמן של רוטציה, Secret Manager מפרסם התראה SECRET_ROTATE בנושא Pub/Sub ייעודי. מגדירים פונקציות Cloud Run או שירות Cloud Run כדי לקרוא את ההתראה, ליצור ערך סודי חדש, להוסיף את הגרסה החדשה ל-Secret Manager ולהשמיד את הגרסה שיצאה משימוש.
  • כדי לעקוב אחרי אירועים של יצירה, השמדה וגישה למטען ייעודי (payload) של גרסאות סודות, צריך להפעיל את יומני הביקורת של Cloud ב-Secret Manager. אפשר להפנות את היומנים האלה אל Google SecOps כדי לקבל התראות על אירועי גישה חשודים, כמו חשבון שירות שנפרץ וניסה לגשת לסודות מחוץ לשעות הפעילות הרגילות או ניסה לקרוא משאבי סודות שלא אושרו.

Security Command Center Premium

‫Security Command Center Premium מאפשר לכם למצוא ולטפל בבעיות אבטחה שנובעות מהגדרות שגויות ובאיומים פעילים בזמן ריצה, כולל כשלים בזיהוי ובאימות, בסביבה ובאפליקציות האינטרנט שלכם. Google Cloudשירות Web Security Scanner יכול לעקוב אחרי נקודות חולשה באפליקציות, כולל נקודות חולשה של XML external entity ‏ (XXE), באמצעות סריקות שמיועדות לכיסוי 10 אמצעי הבקרה המובילים של OWASP.

ההגדרה הזו חלה על:

  • ‫A02: הגדרה שגויה של אבטחה
  • ‫A05: הזרקה
  • ‫A07: כשלים באימות
  • ‫A08: כשלים בשלמות התוכנה או הנתונים

כדאי לעיין בשיטות המומלצות הבאות בנושא A02: הגדרת אבטחה שגויה:

  • החלת מסגרות מובנות (כמו CIS Benchmarks או NIST) באמצעות Compliance Manager כדי להעריך את הגדרות הענן בהשוואה למסגרות רגולטוריות לאבטחה ולמדדים בתחום.
  • הפעלת ניהול הרשאות בתשתית ענן כדי לנהל את הזהויות שיש להן גישה למשאבים בפריסות הענן ולצמצם את הפגיעות הפוטנציאליות שנובעות מטעויות בהגדרות.
  • כדי לתקן כותרות אבטחה של תגובות HTTP שהוגדרו בצורה שגויה, כותרות מקור CORS לא תקינות והצגת תוכן מעורב, צריך לעיין בממצאים של Web Security Scanner ולתקן את הבעיות.

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

  • מגדירים את Web Security Scanner לסריקת נקודות קצה (endpoints) באינטרנט כדי למצוא באגים בהפעלה שמבוססים על חתימה, וליצור ממצא STRUTS_INSECURE_DESERIALIZATION ברמת חומרה גבוהה אם אפליקציה מריצה גרסה פגיעה של Apache Struts.
  • כדי לפתור את הממצא שזוהה ב-STRUTS_INSECURE_DESERIALIZATION, צריך לשדרג את גרסת ספריית ה-framework הפגיעה או לפרוס את Assured OSS כדי למשוך חלופה שאומתה על ידי Google.

Sensitive Data Protection

Sensitive Data Protection מאפשר לכם לסרוק מידע אישי רגיש פוטנציאלי שמאוחסן בקטגוריות, במסדי נתונים, בהנחיות ל-AI גנרטיבי או במטענים ייעודיים (payloads) של אפליקציות סטרימינג, כדי למנוע דליפת מידע לא מכוונת. אם מזוהים נתונים אסורים, Sensitive Data Protection יכול להתריע או לצנזר אותם.

ההגדרה הזו חלה על:

  • A04: כשלים קריפטוגרפיים
  • ‫A09: כשלים ברישום ביומן ובשליחת התראות אבטחה

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

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

  • מגדירים את יעד ה-sink של Logging לשליחת יומנים של אפליקציות לנושא Pub/Sub. מצרפים מנוי Cloud Run שמשתמש ב-Sensitive Data Protection API כדי לסרוק את מטען היומן ולבטל את הזיהוי שלו לפני כתיבת יומנים נקיים לקטגוריית היומנים הסופית.
  • כדי להעביר רק יומנים לא מובנים בסיכון גבוה (כמו שגיאות גולמיות באפליקציה, מטען ייעודי (payload) של רישום משתמשים ויומני עסקאות) דרך צינור הסניטציה, משתמשים במסנני החרגה ב-Logging sinks.

VirusTotal

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

ההגדרה הזו חלה על:

  • ‫A08: כשלים בשלמות התוכנה או הנתונים
  • ‫A05: הזרקה

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

  • אפשר להשתמש במודול VirusTotal Private Scanning כדי לסרוק העלאות רגישות בבידוד ולא לשתף קבצים שהועלו עם צדדים שלישיים.
  • כדי לזהות קודי סטטוס של HTTP 429 Too Many Requests, מטמיעים בקוד ההעברה הגבלת קצב של API וטיפול בחריגים.

VPC Service Controls

בעזרת VPC Service Controls תוכלו ליצור מתחמים היקפיים מסביב למשאבי Google Cloud ים כדי למנוע זליגת נתונים ולצמצם את הסיכון למתקפות זיוף של בקשות בצד השרת (SSRF). ‫VPC Service Controls דוחה קריאות ל-API שחוצות את גבולות הגזרה, אלא אם הן מורשות באופן מפורש על ידי כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress).

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A02: הגדרה שגויה של אבטחה

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

  • כדי להגביל את הגישה ל-API לרשתות VPC מורשות ולזהויות מהימנות, כדאי לכלול היקף שירות שכולל שירותים קריטיים (כמו Cloud Storage, ‏ BigQuery, ‏ Spanner ו-Agent Platform).
  • מגדירים כללים של גבולות גזרה של תעבורת נתונים יוצאת במשאבים בלי שרת כדי לחסום זליגת נתונים לא מורשית שנגרמת על ידי קריאות ל-API יוצאות ליעדים חיצוניים שלא נכללים בגבולות הגזרה.
  • הגבלת גישה ל-API בין גבולות ובין ארגונים באמצעות כללי כניסה ויציאה מפורשים שמציינים את מקורות הפרויקט שאושרו, ממשקי ה-API של היעד וזהויות המתקשרים.

כדאי לעיין בשיטות המומלצות הבאות בנושא A02: הגדרת אבטחה שגויה:

  • לקבץ פרויקטים לגבולות גזרה ייעודיים שמסודרים לפי רמת האבטחה של הסביבה (לדוגמה, גבול גזרה של סביבת ייצור). אפשר להשתמש בשירותים שנגישים ל-VPC כדי להגביל את האפשרות להפעיל ממשקי Google APIs פנימיים בתוך ה-perimeter.
  • ניתוב בקשות API יוצאות מעומסי עבודה ללא שרת דרך רשת ה-VPC. מגדירים שירותי Cloud Run ופונקציות Cloud Run לשימוש בתעבורת נתונים יוצאת (egress) ישירה של VPC או במחבר של חיבור לרשת (VPC) מאפליקציית serverless עם תעבורת נתונים נכנסת (ingress) שמוגדרת רק לגישה פנימית.
  • מקשרים רמות גישה של Access Context Manager לכללי תעבורת הנתונים הנכנסת (ingress) של גבולות הגזרה, שבודקים שילוב של רשתות משנה של כתובות IP ארגוניות, טענות זהות מאומתות ואותות תקינות המכשיר מאימות נקודות קצה.
  • חשוב לשמור על תהליך אדמיניסטרטיבי שאושר מראש לשימוש ב-breakglass במקרה של תגובה לאירוע חירום, ולהגדיר התראות ב-מעקב על אירועים בלתי צפויים של חדירה לגבולות גזרה.

שירותי Wiz

בקטעים הבאים מתוארות 10 השיטות המומלצות של OWASP לשירותי Wiz שמשולבים עםGoogle Cloud.

Wiz Code

‫Wiz Code מרחיב את אבטחת הענן לתהליכי עבודה של מפתחים ולצינורות CI/CD. ‫Wiz Code מבצעת קורלציה בין טלמטריית קוד לבין טלמטריית ענן, סורקת תשתית כקוד (IaC), מנתחת תלות (SCA), מזהה פרטי כניסה חשופים ומבצעת בדיקות אבטחה סטטיות של אפליקציות (SAST).

ההגדרה הזו חלה על:

  • A03: כשלים בשרשרת אספקת התוכנה
  • ‫A05: הזרקה
  • ‫A07: כשלים באימות

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

  • משלבים את Wiz CLI בצינורות CI/CD כדי לחסום מיזוג של בקשות משיכה אם הן כוללות CVE קריטיות, סודות חשופים או הגדרות שגויות חמורות של IaC בענפים מוגנים.
  • כדי לשמור על שקיפות רציפה של שרשרת האספקה ב-Wiz Cloud, צריך ליצור ולייצא SBOM לכל בנייה.
  • אפשר לפרוס תוספים של Wiz Code IDE כדי לספק למפתחים משוב בזמן אמת, ולזהות חבילות פגיעות, מפתחות API שמוצפנים בקוד ושגיאות תחביר לפני ביצוע קומיט של הקוד.
  • משלבים את Wiz Code עם CodeMender בצינורות CI/CD כדי ליצור, לבדוק ולשלוח בקשות משיכה כשמזוהים יחסי תלות פגיעים של צד שלישי.

כדאי לעיין בשיטות המומלצות הבאות בנושא A05: הזרקה:

  • חסימת מיזוג של בקשות משיכה אם סורק ה-SAST מזהה קלט לא מהימן של משתמש שמועבר לשאילתות במסד נתונים או לפקודות במערכת ההפעלה ללא חיטוי מתאים.
  • משלבים את הפלאגין Wiz Code בסביבות פיתוח משולבות (IDE) של מפתחים כדי לספק התראות בזמן אמת אם מפתחים מקלידים שאילתת SQL לא בטוחה, שרשור או תבניות של הרצת פקודות.
  • כש-Wiz Code מסמן פגם בהחדרה, הוא מעביר את עקבות זרימת הנתונים אל CodeMender כדי ליצור טיוטה של תיקון מאומת.

כדאי לעיין בשיטות המומלצות הבאות בנושא A07: כשלים באימות:

  • הטמעה של סריקה אוטומטית של סודות בממשקי IDE למפתחים, בווים מקומיים לפני ביצוע קומיט ובצינורות CI/CD כדי לזהות פרטי כניסה שנחשפו.
  • כדי לצמצם את הסיכון לגניבת פרטי כניסה, כדאי להחליף פרטי כניסה סטטיים לטווח ארוך באסימונים דינמיים לטווח קצר ובגישה שקשורה לזהות (כמו איחוד שירותי אימות הזהות של עומסי עבודה או אימות מבוסס OIDC).
  • מטמיעים Playbook אוטומטי לתגובה לאירועים כדי להסיר סודות שזוהו מקוד, ממשתני סביבה ומיומני בנייה.

Wiz Cloud

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

ההגדרה הזו חלה על:

  • A01: Broken Access Control (בקרת גישה פגומה)
  • ‫A02: הגדרה שגויה של אבטחה
  • A04: כשלים קריפטוגרפיים
  • ‫A06: עיצוב לא מאובטח

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

  • אפשר לעקוב אחרי נתיבי העלאת הרשאות מורכבים עם כמה קפיצות בין תפקידים ומדיניות ב-IAM, ולסמן אותם כדי לזהות איפה תוקפים יכולים לנוע לרוחב או להעלות הרשאות.
  • מיפוי הרשאות גישה פעילות בחשבונות משתמשים, בחשבונות שירות ובסוכני AI למאגרי נתונים קריטיים, וביטול הרשאות מוגזמות.
  • שילוב של ממצאי הרשאות גישה לזהויות עם פלטפורמות תזמור כדי להחליף קשרי תפקידים אדמיניסטרטיביים קבועים בגישה בזמן אמת (JIT).
  • מעקב אחרי תנועת הנתונים והצגתם באופן חזותי כדי לזהות מקרים שבהם פרטים אישיים מזהים (PII) בסביבת הייצור מועתקים או מסונכרנים לסביבות פיתוח או לסביבות זמניות לא מאובטחות.

כדאי לעיין בשיטות המומלצות הבאות בנושא A02: הגדרת אבטחה שגויה:

  • הערכה של הסיכון בהגדרת הענן וקביעת סדר עדיפויות לטיפול בו על ידי שילוב של הגדרות שגויות עם גורמי תקיפה רבים באמצעות Wiz Security Graph.
  • החלת מסגרות תאימות מובנות (כמו OWASP Top 10,‏ CIS Benchmarks ו-NIST) כדי למדוד את הגדרות הענן בהשוואה לתקנים בתחום.
  • משלבים את סורק Wiz CLI בצינורות CI/CD כדי לבדוק את הגרסאות או לתקן שגיאות בהגדרות IaC לפני הפריסה.

כדאי לעיין בשיטות המומלצות הבאות בנושא A04: כשלים בהצפנה:

  • כדאי לתת עדיפות לתיקון של מסדי נתונים וקטגוריות אחסון שמכילים פרטי כניסה בטקסט גלוי, מפתחות לא מגובבים או נתונים רגישים שמאוחסנים ללא הצפנה.
  • מריצים את Wiz Cloud data discovery בספריות אימון של AI, במסדי נתונים וקטוריים ובצינורות RAG כדי לוודא שנתונים קנייניים ומידע אישי רגיש (PII) עברו עריכה לפני הטמעה ב-LLM.
  • סורקים סביבות כדי לזהות נכסי נתונים לא מנוהלים ומוחקים נתונים מיותרים כדי לצמצם את שטח ההתקפה.

כדאי לעיין בשיטות המומלצות הבאות בנושא A06: עיצוב לא מאובטח:

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

Wiz Defend

‫Wiz Defend מספקת זיהוי ותגובה בענן (CDR), הגנה על זמן הריצה של עומסי עבודה ואבטחת גישה ל-Kubernetes. ‫Wiz Defend עוקב אחרי פעילות במישור הבקרה, מזהה אנומליות בזמן ריצה, אוכף מדיניות של קבלת קונטיינרים ומפעיל בלימה אוטומטית.

ההגדרה הזו חלה על:

  • ‫A08: כשלים בשלמות התוכנה או הנתונים
  • ‫A09: כשלים ברישום ביומן ובשליחת התראות אבטחה

כדאי לעיין בשיטות המומלצות הבאות בנושא A08: Software or Data Integrity Failures (כשלים בשלמות התוכנה או הנתונים):

  • מגדירים את כללי הגישה של Wiz Defend כדי לבדוק ולדחות מניפסטים של פריסת Kubernetes שמנסים להריץ קונטיינרים עם הרשאות root, לבקש מרחבי שמות של רשת המארח או להפעיל את privileged: true.
  • כדי לחסום קונטיינרים לא מהימנים אם אי אפשר להגיע לתגובה לפעולה מאתר אחר (webhook), צריך להגדיר תגובות לפעולות מאתר אחר (webhook) של קבלה (admission) של אבטחה קריטית עם failurePolicy: Fail (fail-closed) בסביבת הייצור.

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

  • מייצאים Google Cloud יומני ביקורת באמצעות sink ביומן לנושא Pub/Sub כדי ש-Wiz Defend יוכל להטמיע ולנתח פעילויות של מישור הבקרה ואירועים של עומסי עבודה.
  • פריסת Wiz Runtime Sensor באשכולות GKE ובמכונות וירטואליות (VM) של Compute Engine בעלות ערך גבוה כדי לזהות איומים בזמן ריצה, ניצול לרעה של זיכרון ופריצות פעילות.
  • אפשר להשתמש ב-playbooks אוטומטיים של בלימה כדי להשבית באופן מיידי חשבונות שירות של IAM שנפרצו או לבודד עומסי עבודה שנפרצו.
  • משתמשים ב-Wiz Blue Agent כדי לחקור זיהויים בזמן ריצה, תוך שילוב של טלמטריה של תהליכים בזמן אמת והקשר של הזהות כדי לקבוע את שורשי הבעיה ואת הנכסים המושפעים.

שמירה על תאימות ל-OWASP Top 10:2025

‫Wiz כולל מסגרת תאימות ל-OWASP Top 10 2025 שמאפשרת להעריך ולנטר את מצב האבטחה. מסגרת התאימות OWASP Top 10 2025 ממפה מדיניות מובנית של Wiz לקטגוריות הסיכון הרלוונטיות של OWASP, ויוצרת ממצאים אם אמצעי בקרה לא עומד בדרישות. אתם יכולים לעקוב אחרי ציון התאימות לאורך זמן. אם נדרש, אפשר להתאים אישית את מסגרת התאימות OWASP Top 10 2025 כדי לעמוד בדרישות העסקיות שלכם.

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

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