אפשרויות לצמצום הסיכון של 10 נקודות התורפה המובילות של OWASP בשנת 2021 ב-Google Cloud

Last reviewed 2024-07-31 UTC

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

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

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

.

סקירות כלליות על מוצרים

המוצרים Google Cloud שמופיעים בטבלה הבאה יכולים לעזור בהגנה מפני 10 סיכוני האבטחה המובילים:

מוצר סיכום A01 A02 A03 A04 A05 A06 A07 A08 A09 A10
Access Transparency הרחבת הבקרה והשקיפות של ספק שירותי הענן בעזרת יומני גישה של אדמינים ובקרות על אישורי גישה ✓ ✓
Apigee עיצוב, אבטחה והתאמה של ממשקי תכנות אפליקציות (API) ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Artifact Registry אחסון מרכזי של פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ויחסי תלות בגרסת build ✓
Binary Authorization מוודאים שרק תמונות קונטיינרים מהימנות נפרסות ב-Google Kubernetes Engine ✓ ✓
Cloud Armor חומת אש לאפליקציות אינטרנט (WAF) שמוצבת בקצה הרשת של Google כדי להגן מפני וקטורים נפוצים של התקפות ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
מאגר משאבי ענן הצגה, ניטור וניתוח של כל הנכסים ב- Google Cloud וב-Google Distributed Cloud או בענן מרובה בפרויקטים ובשירותים שונים ✓ ✓ ✓ ✓
Cloud Build בנייה, בדיקה ופריסה ב Google Cloud ✓
Cloud Key Management Service ניהול של מפתחות הצפנה ב Google Cloud ✓ ✓
Cloud Load Balancing קביעת הצפנים ששרת ה-SSL proxy או מאזן העומסים של HTTPS מנהלים משא ומתן לגביהם ✓ ✓ ✓ ✓
Cloud Logging ניהול וניתוח של יומנים בזמן אמת בקנה מידה נרחב ✓
Cloud Monitoring איסוף וניתוח של מדדים, אירועים ומטא-נתונים משירותי Google Cloud וממגוון רחב של אפליקציות ושירותים של צד שלישי ✓
Cloud Source Repositories אחסון, ניהול ומעקב אחר קוד במקום אחד לצוות ✓
‫Google Security Operations למצוא איומים בזמן אמת ובקנה מידה גדול באופן אוטומטי באמצעות התשתית, טכניקות הזיהוי והאותות של Google ✓
Identity Platform הוספת יכולות של ניהול זהויות והרשאות גישה לאפליקציות, הגנה על חשבונות משתמשים והרחבת ניהול הזהויות ✓ ✓
שרת proxy לאימות זהויות (IAP) שימוש בזהויות ובהקשר כדי לאבטח את הגישה לאפליקציות ולמכונות הווירטואליות ✓ ✓ ✓
reCAPTCHA הגנה על אתר האינטרנט מפני פעילות שמקורה בתרמית, ספאם והתנהלות פוגעת ✓
Secret Manager אחסון מפתחות API, סיסמאות, אישורים ומידע אישי רגיש נוסף ✓ ✓
‫Security Command Center תצוגה מרכזית של ניתוח אבטחה ומודיעין איומי סייבר, שעוזרת לזהות נקודות חולשה באפליקציות ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Sensitive Data Protection גילוי, סיווג והגנה על המידע האישי הרגיש ביותר שלכם ✓ ✓ ✓
מפתחות אבטחה Titan מכשירים לאימות דו-שלבי (2FA) שעמידים בפני פישינג, עם שבב חומרה מובנה (עם קושחה שפותחה על ידי Google) לאימות התקינות של המפתח, עוזרים להגן על משתמשים בעלי ערך גבוה ✓
חומות אש של ענן וירטואלי פרטי (VPC) אישור או דחייה של חיבורים למכונות וירטואליות (VM) או מהן ✓
VirusTotal ניתוח של קבצים וכתובות URL חשודים כדי לזהות סוגים של תוכנות זדוניות, ושיתוף אוטומטי שלהם עם קהילת האבטחה ✓ ✓
VPC Service Controls בידוד משאבים בשירותים מרובי-דיירים Google Cloud כדי לצמצם את הסיכון לזליגת נתונים ✓ ✓
Google Cloud עדכוני אבטחה דחופים עדכוני האבטחה הדחופים האחרונים שקשורים למוצרי Google Cloud ✓

‫A01: בקרת גישה פגומה

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

Apigee

תרחיש לדוגמה:

  • אכיפה של בקרת גישה
  • הגבלת מניפולציה של נתונים

‫Apigee תומך בגישה שכבתית להטמעת אמצעי בקרת גישה כדי למנוע מגורמים זדוניים לבצע שינויים לא מורשים או לגשת למערכת.

הגדרת בקרת גישה מבוססת-תפקידים (RBAC) כדי לאפשר למשתמשים גישה רק למשאבים ולהגדרות שהם צריכים. יוצרים מפות מוצפנות של צמדי מפתח/ערך כדי לאחסן צמדי מפתח/ערך רגישים, שמוצגים מוסתרים בממשק המשתמש של Edge ובקריאות ל-Management API. מגדירים כניסה יחידה (SSO) באמצעות ספק הזהויות של החברה.

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

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

תרחיש לדוגמה:

  • מעקב אחר IT לא מורשה (שנקרא גם shadow IT)
  • מכונות מיושנות של Compute

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

Cloud Load Balancing

תרחיש לדוגמה:

  • שליטה מדויקת בהצפנה ב-SSL וב-TLS

כדי למנוע שימוש בהצפנת SSL או TLS חלשות, מקצים קבוצה מוגדרת מראש או רשימה מותאמת אישית של הצפנות ש-Cloud Load Balancing יכול להשתמש בהן.

Cloud Armor

תרחיש לדוגמה:

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

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

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

לדוגמה, אם מתקפות זיוף של בקשות בין אתרים (CSRF) אפשריות כי שרת האינטרנט שלכם מיישם שיתוף משאבים בין מקורות (CORS) בצורה לא טובה, כמו שמוצג באתגר CSRF Juice Shop, אתם יכולים לצמצם את הבעיה הזו על ידי חסימת בקשות ממקורות לא צפויים לחלוטין באמצעות כלל מותאם אישית. הכלל הבא תואם לכל הבקשות שמקורן שונה מ-example.com ומ-google.com:

has(request.headers['origin']) &&
!((request.headers['origin'] == 'https://example.com')||
(request.headers['origin'] == 'https://google.com') )

כשנחסמת תנועה שתואמת לכלל כזה, הפתרון לאתגר CSRF מפסיק לפעול.

האתגר של שינוי פרטי הסל משתמש בזיהום פרמטרים של HTTP‏ (HPP) כדי להראות לכם איך לתקוף את החנות באמצעות פתרון האתגר. התקפות HPP מזוהות כחלק מהכללים של פרוטוקול ההתקפה. כדי לחסום מתקפות מסוג זה, אפשר להשתמש בכלל הבא: evaluatePreconfiguredExpr('protocolattack-stable').

שרת proxy לאימות זהויות (IAP) ובקרת גישה מבוססת-הקשר

תרחיש לדוגמה:

  • בקרת גישה מרכזית
  • פועל בענן ובשרתים מקומיים
  • הגנה על חיבורי HTTP ו-TCP
  • בקרת גישה מבוססת הקשר

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

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

Security Command Center

‫Security Command Center כולל שני שירותים שעוזרים לכם לטפל בבעיות בבקרת הגישה: Security Health Analytics ו-Web Security Scanner.

‫Security Health Analytics תומך בתרחישי השימוש הבאים:

  • אכיפה של MFA או אימות דו-גורמי
  • הגנה על מפתחות API
  • מעקב אחר מדיניות SSL

כדי למנוע בקרת גישה לקויה, הכלי Security Health Analytics עוקב אחרי התאימות לאימות רב-שלבי, אחרי מדיניות SSL ואחרי תקינות מפתחות ה-API.

‫Web Security Scanner תומך בתרחישי השימוש הבאים:

  • מאגרים שחשופים לציבור
  • אימות לא מאובטח של כותרת הבקשה

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

‫A02: כשלים קריפטוגרפיים

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

Apigee

תרחיש לדוגמה:

  • הגנה על מידע אישי רגיש

להשתמש ב-TLS חד-כיווני ודו-כיווני כדי להגן על מידע רגיש ברמת הפרוטוקול.

כדי להסיר מידע אישי רגיש לפני שהוא מוחזר ללקוח, אפשר להשתמש במדיניות כמו Assign Message policy ו-JavaScript policy.

מומלץ להשתמש בטכניקות OAuth סטנדרטיות, ולשקול להוסיף טכניקות כמו HMAC, ‏ hash, ‏ state, ‏ nonce, ‏ PKCE או טכניקות אחרות כדי לשפר את רמת האימות של כל בקשה.

ביצוע אנונימיזציה לנתונים רגישים בכלי Edge Trace.

הצפנה של מידע אישי רגיש באחסון ב-key value maps.

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

תרחיש לדוגמה:

  • שירות חיפוש
  • כלי לניתוח הרשאות גישה

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

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

Cloud Data Loss Prevention API (חלק מ-Sensitive Data Protection)

תרחיש לדוגמה:

  • גילוי וסיווג של מידע רגיש
  • הסתרת נתונים אוטומטית

באמצעות Cloud Data Loss Prevention API (DLP API) אפשר לסרוק מידע אישי רגיש פוטנציאלי שמאוחסן בדליים או במסדי נתונים, כדי למנוע דליפת מידע לא מכוונת. אם המערכת מזהה נתונים אסורים, היא יכולה לסמן אותם או לצנזר אותם באופן אוטומטי.

Cloud Key Management Service

תרחיש לדוגמה:

  • ניהול מאובטח של מפתחות קריפטוגרפיים

‫(Cloud KMS) עוזר למנוע חשיפה פוטנציאלית של המפתחות הקריפטוגרפיים שלכם. אפשר להשתמש בשירות ניהול מפתחות (KMS) שמתארח בענן כדי לנהל מפתחות קריפטוגרפיים סימטריים ואסימטריים לשירותי הענן שלכם, בדיוק כמו שאתם עושים בשרתים מקומיים. אתם יכולים ליצור, להשתמש, להחליף ולמחוק מפתחות קריפטוגרפיים מסוג AES256,‏ RSA 2048,‏ RSA 3072,‏ RSA 4096,‏ EC P256 ו-EC P384.

Cloud Load Balancing

תרחיש לדוגמה:

  • שליטה מדויקת בהצפנה ב-SSL וב-TLS

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

Cloud Armor

תרחיש לדוגמה:

  • סינון של כתובות URL ידועות של התקפות
  • הגבלת הגישה לנקודות קצה רגישות

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

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

request.path.contains("%00") || request.path.contains("%2500")

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

request.path.contains("/metrics") && !(inIpRange(origin.ip, '1.2.3.4/32')

מחליפים את 1.2.3.4/32 בטווח כתובות ה-IP שצריכות לקבל גישה לממשק המדדים.

קבצי יומן שנחשפו בטעות משמשים לפתרון אחת מהבעיות ב-Juice Shop. כדי למנוע חשיפה של יומנים, מגדירים כלל שאוסר גישה לקובצי יומן לחלוטין: request.path.endsWith(".log").

שרת proxy לאימות זהויות (IAP) ובקרת גישה מבוססת-הקשר

תרחיש לדוגמה:

  • גישה מאובטחת מרחוק לשירותים רגישים
  • בקרת גישה מרכזית
  • בקרת גישה מבוססת הקשר

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

באמצעות בקרת גישה מבוססת-הקשר, אפשר לאכוף בקרות גישה מפורטות לאפליקציות אינטרנט, למכונות וירטואליות (VM),ל-API ולאפליקציות Google Workspace על סמך זהות המשתמש וההקשר של הבקשה, ללא VPN רגיל. Google Cloud 'בקרת גישה מבוססת הקשר' היא תכונה הנסמכת על מודל האבטחה 'אפס אמון' ועל שיטת BeyondCorp של Google, והיא מאפשרת לכם לספק למשתמשים שלכם גישה, לאכוף בקרות מפורטות ולהשתמש בפלטפורמה אחת גם לאפליקציות ולתשתיות שלכם שבענן וגם לאלה המקומיות של הארגון.

Secret Manager

תרחיש לדוגמה:

  • מפתחות הצפנה
  • מפתחות API
  • פרטי כניסה אחרים למערכת

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

‫Secret Manager לא מיועד לפעולות בהיקף נרחב, כמו יצירת טוקנים של כרטיסי אשראי או אחסון סיסמאות של משתמשים פרטיים. אפליקציות כאלה צריכות להסתמך על Identity Platform לניהול זהויות והרשאות של לקוחות (CIAM), על Cloud Identity לחברי הארגון או על תוכנה ייעודית ליצירת טוקנים.

Security Command Center

Security Command Center כולל שני שירותים שעוזרים לכם לטפל בכשלים קריפטוגרפיים: Security Health Analytics ו-Web Security Scanner.

‫Security Health Analytics תומך בתרחישי השימוש הבאים:

  • אכיפה של MFA/2FA
  • הגנה על מפתחות API
  • אכיפה של רוטציית מפתחות API
  • פרטיות של תמונות Compute
  • אכיפת כללי מפתחות SSH
  • מעקב אחר הפעלה מאובטחת
  • אבטחת הגישה ל-API
  • מעקב אחר מדיניות SSL
  • השבתת רישום ביומן
  • התרעות על רשימות ACL של קטגוריות שגלויות לכולם

כדי למנוע חשיפה של מידע אישי רגיש, הכלי Security Health Analytics עוקב אחרי התאימות לאימות רב-שלביואחרי התקינות של מפתחות ה-API. קבלת התראות על הגדרות לא מאובטחות באחסון של קובצי אימג' של קונטיינרים, ב-Cloud Storage, במדיניות SSL, במדיניות של מפתחות SSH, ברישום ביומן, בגישה ל-API ועוד.

‫Web Security Scanner תומך בתרחיש השימוש הבא:

  • סיסמאות לא מוצפנות שמועברות ברשת

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

VirusTotal

תרחיש לדוגמה:

  • מניעת דיוג

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

VPC Service Controls

תרחיש לדוגמה:

  • חומת אש לשירותים מנוהלים

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

Web Application Scanner

תרחיש לדוגמה:

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

כדי למנוע חשיפה של מידע אישי רגיש באפליקציית האינטרנט, חשוב לוודא שהסיסמאות לא נשלחות בטקסט מפורש. כדי למנוע חשיפה של קוד מקור גולמי שעלולה להיות הרסנית, צריך לבדוק אם יש מאגרי קוד מקור של git ו-Apache Subversion שחשופים. הסריקות האלה מיועדות לכיסוי של אמצעי בקרה ספציפיים מתוך רשימת 10 המובילים של OWASP.

A03: הזרקה

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

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

Apigee

תרחיש לדוגמה:

  • חסימת הזרקת SQL
  • חסימת הזרקת NoSQL
  • חסימה של החדרת LDAP
  • חסימת הזרקת JavaScript

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

יש כמה גישות לאימות קלט בפלטפורמת Apigee:

Cloud Armor

תרחיש לדוגמה:

  • סינון של הזרקת SQL
  • סינון של הזרקת PHP

‫Cloud Armor יכול לחסום התקפות נפוצות של הזרקת קוד לפני שהן מגיעות לאפליקציה שלכם. ל-SQL injection (הזרקת SQL), ‏ Cloud Armor כולל קבוצת כללים מוגדרת מראש שמבוססת על קבוצת הכללים המרכזית של OWASP Modsecurity. אתם יכולים ליצור מדיניות אבטחה שחוסמת מתקפות SQLi נפוצות שמוגדרות בקבוצת הכללים המרכזית, באמצעות הכלל evaluatePreconfiguredExpr('sqli-stable') לבד או בשילוב עם כללים מותאמים אישית אחרים. לדוגמה, אפשר להגביל את החסימה של SQLi לאפליקציות ספציפיות באמצעות מסנן של נתיב כתובת ה-URL.

יש קבוצת כללים שהוגדרה מראש להזרקת PHP. אפשר להשתמש בכלל evaluatePreconfiguredExpr('php-stable') כדי לחסום מתקפות נפוצות של הזרקת PHP.

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

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

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

Security Command Center

‫Security Command Center כולל שני שירותים שעוזרים לטפל בפגמים בהזרקה: זיהוי איומים בקונטיינר ו-Web Security Scanner.

זיהוי איומים בקונטיינר תומך בתרחישי השימוש הבאים:

  • זיהוי סקריפטים זדוניים
  • זיהוי reverse shell
  • זיהוי התקנה של תוכנות זדוניות

הגלאי Malicious Script Executed של זיהוי איומים בקונטיינר מנתח כל סקריפט מעטפת שמופעל במערכת ומדווח על סקריפטים שנראים זדוניים. הגלאי הזה מאפשר לכם לגלות מתקפות של הזרקת פקודות מעטפת. אחרי הזרקת פקודת מעטפת מוצלחת, תוקף יכול ליצור מעטפת הפוכה, שמפעילה את גלאי Reverse Shell. לחלופין, הם יכולים להתקין תוכנה זדונית, שתפעיל את אמצעי הזיהוי Added Binary Executed ו-Added Library Loaded.

‫Web Security Scanner תומך בתרחישי השימוש הבאים:

  • מעקב אחר פרצות אבטחה מסוג XSS‏ (cross-site scripting)
  • ניטור של הזרקת SQL

הכלי Web Security Scanner סורק את אפליקציות האינטרנט שלכם כדי לאתר נקודות חולשה, ומספק גלאים שעוקבים אחרי תקיפות של Cross-Site Scripting והזרקת SQL.

A04: עיצוב לא מאובטח

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

Apigee

תרחישים לדוגמה:

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

‫Apigee מאפשרת לכם לאמת בקשות ותגובות נכנסות לאפליקציה באמצעות מדיניות OASValidation. בנוסף, כדי להגן על הגישה, אפשר להגדיר כניסה יחידה (SSO), בקרת גישה מבוססת-תפקידים (RBAC), להגביל את הגישה לממשקי API (באמצעות Auth0 למשל) ולהגביל את כתובות ה-IP שיש להן גישה לסביבה שלכם. באמצעות כללים לטיפול בשגיאות, אפשר להתאים אישית את האופן שבו proxy ל-API מגיב לשגיאות.

כדי להגן על משתמשי Apigee ברחבי העולם מפני סיסמאות לא בטוחות, Apigee מספקת אפשרויות של תפוגת סיסמה, נעילה ואיפוס סיסמה. בנוסף, אפשר להפעיל אימות דו-שלבי (2FA).

Cloud Data Loss Prevention API (חלק מ-Sensitive Data Protection)

תרחיש לדוגמה:

  • זיהוי וצנזור של מידע סודי

באמצעות Cloud Data Loss Prevention API, אתם יכולים לזהות נתונים סודיים ולבצע טוקניזציה שלהם. ה-API של DLP יכול לעזור לכם להגביל את החשיפה של נתונים סודיים, כי אחרי שהנתונים עוברים טוקניזציה ונשמרים, אתם יכולים להגדיר בקרת גישה כדי להגביל את האנשים שיכולים לראות את הנתונים. מידע נוסף זמין במאמרים הגדרת סיווג אוטומטי של נתונים שמועלים ל-Cloud Storage והסרת פרטים מזהים וזיהוי מחדש של פרטים אישיים מזהים (PII) במערכי נתונים רחבי היקף באמצעות Sensitive Data Protection.

Secret Manager

תרחיש לדוגמה:

  • הגנה על אחסון פרטי הכניסה

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

Security Command Center

שירות Web Security Scanner, שהוא חלק מ-Security Command Center, תומך בתרחיש השימוש הבא:

  • זיהוי נקודות חולשה באבטחה באפליקציות.

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

‫A05: הגדרת אבטחה שגויה

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

Apigee

תרחיש לדוגמה:

  • ניהול הגדרות אבטחה
  • מעקב אחרי הגדרות האבטחה

Shared flow מאפשר למפתחי API לשלב מדיניות ומשאבים בקבוצה שאפשר לעשות בה שימוש חוזר. הזרימה המשותפת מאפשרת לכם לנהל את הקוד, לקצר את זמן הפיתוח ולשמור על עקביות, כי היא מאפשרת לכם לתעד משאבים ועקרונות מדיניות לשימוש חוזר במקום אחד. אפשר לכלול מדיניות FlowCallout כדי להשתמש בזרימת נתונים משותפת בתוך proxy ל-API ספציפי, או להשתמש בנקודות עצירה (hooks) של זרימת נתונים כדי להפעיל באופן אוטומטי את הלוגיקה של זרימת נתונים משותפת לכל proxy ל-API שנפרס באותה סביבה.

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

תרחיש לדוגמה:

  • שירות התראות בזמן אמת

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

Cloud Load Balancing

תרחיש לדוגמה:

  • שליטה מדויקת בהצפנה ב-SSL וב-TLS

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

Cloud Armor

תרחיש לדוגמה:

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

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

חומת אש של אפליקציית אינטרנט (WAF), כמו Cloud Armor, לא יכולה לעזור לכם לתקן את הטעות בהגדרה, אבל אתם יכולים לחסום את הגישה לחלקים מהאפליקציה באופן מלא או לכולם חוץ מכתובות IP או מדינות ספציפיות. הגבלת הגישה יכולה להפחית את הסיכון לניצול לרעה של טעויות בהגדרות.

לדוגמה, אם האפליקציה שלכם חושפת ממשק אדמין באמצעות כתובת URL נפוצה כמו /admin, אתם יכולים להגביל את הגישה לממשק הזה גם אם הוא מאומת. אפשר לעשות זאת באמצעות כלל דחייה – לדוגמה:

request.path.contains("/admin") && !(inIpRange(origin.ip,
'1.2.3.4/32')

מחליפים את 1.2.3.4/32 בטווח כתובות ה-IP שאמורות להיות להן גישה לממשק האדמין.

אפשר לצמצם חלק מהבעיות שנובעות מהגדרות שגויות באמצעות קבוצות הכללים המוגדרות מראש של הכללת קבצים מקומיים (LFI) או הכללת קבצים מרחוק (RFI). לדוגמה, ניצול של האתגר cross-site imaging ב-Juice Shop לא מצליח כשמחילים את כללי ה-LFI. משתמשים בכלל evaluatePreconfiguredExpr('lfi-stable') || evaluatePreconfiguredExpr('rfi-stable') כדי לחסום בקשות באמצעות קבוצות הכללים LFI ו-RFI, ומתאימים את הכללים לפי הצורך. אפשר לוודא שפתרון האתגר כבר לא מצליח.

אפשר גם לצמצם את ההשפעה של חלק מהתקפות ה-HTTP באמצעות קבוצות כללים שהוגדרו מראש:

  • כדי להימנע משיבוש של פועל HTTP, צריך להשתמש בקבוצת הכללים לאכיפת שיטה. משתמשים בכלל evaluatePreconfiguredExpr('methodenforcement-stable') כדי לאסור שימוש בשיטות של בקשות HTTP שאינן השיטות GET, HEAD, POST ו-OPTIONS
  • כדי לחסום מתקפות נפוצות נגד ניתוח של HTTP ושרתי proxy, כמו הברחת בקשות HTTP, פיצול תגובות HTTP והחדרת כותרות HTTP, צריך להשתמש בקבוצת הכללים של מתקפות פרוטוקול באמצעות הכלל evaluatePreconfiguredExpr('protocolattack-stable').

Security Command Center

Security Command Center כולל שני שירותים שעוזרים לכם לטפל בבעיות בהגדרות האבטחה: Security Health Analytics ו-Web Security Scanner.

‫Security Health Analytics תומך בתרחיש השימוש הבא:

  • ניטור והתראות לגבי אמצעי בקרה לצורכי אבטחה

כדי לוודא שהאפליקציה שלכם עומדת בשיטות המומלצות לאבטחה, הכלי Security Health Analytics מנטר אותות רבים דרך ממשק יחיד.

‫Web Security Scanner תומך בתרחישי השימוש הבאים:

  • סורק אפליקציות אינטרנט שמותאם ל-OWASP Top 10
  • שגיאות בהגדרת שרת HTTP
  • תוכן מעורב של HTTP/HTTPS
  • ישות חיצונית של XML‏ (XXE)

Web Security Scanner עוקב אחרי שגיאות אבטחה נפוצות, כמו אי-התאמות של content-type, כותרות אבטחה לא חוקיות והצגה של תוכן מעורב. בנוסף, Web Security Scanner עוקב אחרי נקודות חולשה, כמו נקודות חולשה מסוג XXE. הסריקות האלה מיועדות לכיסוי 10 אמצעי הבקרה המובילים של OWASP. הגלאים הבאים סורקים כדי לאתר טעויות בהגדרות האבטחה:

  • INVALID_CONTENT_TYPE
  • INVALID_HEADER
  • MISMATCHING_SECURITY_HEADER_VALUES
  • MISSPELLED_SECURITY_HEADER_NAME
  • MIXED_CONTENT
  • XXE_REFLECTED_FILE_LEAKAGE

מידע נוסף על הגלאים האלה ועל גלאים אחרים זמין במאמר סקירה כללית של Web Security Scanner.

‫A06: רכיבים פגיעים ולא מעודכנים

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

Binary Authorization

תרחיש לדוגמה:

  • הגבלת אשכולות GKE לקונטיינרים מהימנים

Binary Authorization הוא אמצעי בקרה לאבטחה בזמן הפריסה, שעוזר לוודא שרק תמונות קונטיינר מהימנות נפרסות ב-Google Kubernetes Engine‏ (GKE). באמצעות Binary Authorization, אתם יכולים לדרוש שתמונות ייחתמו על ידי רשויות מהימנות במהלך תהליך הפיתוח, ולאחר מכן לאכוף את אימות החתימה במהלך הפריסה. אכיפת האימות מבטיחה שתהליך הבנייה וההפצה ישתמש רק בתמונות מאומתות.

Cloud Load Balancing

תרחיש לדוגמה:

  • שליטה מדויקת בהצפנה ב-SSL וב-TLS

כדי למנוע שימוש בצפנים ידועים של SSL או TLS שפגיעים, אפשר להקצות קבוצה מוגדרת מראש או רשימה מותאמת אישית של צפנים ש-Cloud Load Balancing יכול להשתמש בהם.

Cloud Armor

תרחיש לדוגמה:

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

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

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

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

`request.path.contains("/component") && !(inIpRange(origin.ip,
'1.2.3.4/32')

מחליפים את מה שכתוב בשדות הבאים:

  • ‫/component: הנתיב של הרכיב עם נקודות החולשה הידועות
  • ‫1.2.3.4/32: טווח כתובות ה-IP שצריך לשמור על הגישה לממשק.

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

Google Cloud עדכוני אבטחה דחופים

תרחיש לדוגמה:

  • מעקב אחרי עדכוני אבטחה דחופים
  • ‫CVEs for Google Cloud products

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

Security Command Center

‫Security Command Center כולל שלושה שירותים שיעזרו לכם לטפל ברכיבים פגיעים ומיושנים: זיהוי איומים בקונטיינר, Event Threat Detection ו-Web Security Scanner.

זיהוי איומים בקונטיינר תומך בתרחישי השימוש הבאים:

  • זיהוי סקריפטים זדוניים
  • זיהוי reverse shell
  • זיהוי התקנה של תוכנות זדוניות

אם תוקף מנצל רכיב פגיע ומריץ סקריפט זדוני, גלאי Malicious Script Executed של זיהוי איומים בקונטיינר יוצר ממצא. אם תוקף יוצר מעטפת הפוכה, גלאי Reverse Shell יוצר ממצא. אם תוקף מתקין תוכנה זדונית, גלאי Added Binary Executed ו-Added Library Loaded יוצרים ממצאים.

הכלי Event Threat Detection תומך בתרחישי השימוש הבאים:

  • זיהוי כריית מטבעות וירטואליים
  • גילוי תוכנות זדוניות
  • זליגת נתונים
  • מתקפת DoS יוצאת

הכלי Event Threat Detection עוקב אחרי הזרם של Cloud Logging ומחיל לוגיקת זיהוי ומודיעין איומים ברמה מפורטת. כש-Event Threat Detection מזהה איום, הוא כותב ממצא ב-Security Command Center ובפרויקט Cloud Logging. כללי הזיהוי הבאים שימושיים לזיהוי ההשפעות של שימוש ברכיבים עם נקודות חולשה ידועות:

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

‫Web Security Scanner תומך בתרחישי השימוש הבאים:

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

‫Web Security Scanner עוקב אחרי ספריות לא עדכניות שכלולות באפליקציית האינטרנט שלכם. אתם יכולים לעקוב אחרי הממצאים האלה במרכז הבקרה של Security Command Center.

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

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

Access Transparency

תרחיש לדוגמה:

  • ניטור של ספק השירות
  • הצדקות גישה

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

Apigee

תרחיש לדוגמה:

  • אימות המפתחות
  • אימות טוקן
  • מדיניות OAuth

‫Apigee מספק מדיניות של VerifyApiKey,‏ OAuth ו-JSON Web Token‏ (JWT), שעוזרת להגן מפני הסיכון הזה.

אימות מפתח API הוא הצורה הפשוטה ביותר של אבטחה מבוססת-אפליקציה שאפשר להגדיר עבור API. אפליקציית לקוח שולחת מפתח API עם הבקשה שלה. ‫Apigee Edge, באמצעות מדיניות שמצורפת ל-proxy ל-API, בודק שמפתח ה-API נמצא במצב מאושר עבור המשאב שמבוקש.

מסגרת ההרשאות OAuth 2.0 מאפשרת לאפליקציה של צד שלישי לקבל גישה מוגבלת לשירות HTTP, או בשם בעל המשאב על ידי תיאום אינטראקציית אישור בין בעל המשאב לבין שירות ה-HTTP, או בשם עצמה על ידי מתן גישה לאפליקציה של צד שלישי.

אסימוני JWT‏ (JSON Web Tokens) משמשים בדרך כלל לשיתוף טענות או הצהרות בין אפליקציות מקושרות. ‫Apigee מספק תמיכה ב-JWT באמצעות שלוש מדיניות.

Cloud Armor

תרחיש לדוגמה:

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

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

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

אם מנגנוני אבטחה אחרים מזהים שסיסמאות, מפתחות או טוקנים של סשנים נפרצו, אפשר לחסום את הגישה לבקשות שמכילות את הפרמטרים האלה במחרוזת שאילתה באמצעות כלל מותאם אישית. אפשר לעדכן כללים שהגדרתם בעבר באמצעות ה-method‏ securityPolicy.patchRule. יכול להיות שתוכלו לזהות אסימונים שנגנבו באמצעות מנגנונים לזיהוי אנומליות ביומני איזון עומסים של HTTP. אפשר גם לזהות יריבים פוטנציאליים על ידי סריקה של סיסמאות נפוצות ביומנים האלה.

אתם יכולים לחסום מתקפות נפוצות של קיבוע סשן באמצעות קבוצת הכללים המוגדרת מראש של ModSecurity לקיבוע סשן. כדי להשתמש בקבוצת הכללים, מוסיפים את הכלל המוגדר מראש evaluatePreconfiguredExpr('sessionfixation-stable') למדיניות האבטחה.

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

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

תרחיש לדוגמה:

  • בקרת גישה מרכזית
  • פועל בענן ובשרתים מקומיים
  • הגנה על חיבורי HTTP ו-TCP
  • בקרת גישה מבוססת הקשר

‫IAP משתלב עם איזון עומסים מסוג HTTP(S), כך שאתם יכולים להשתמש בזהות ובהקשר כדי ליצור חומת אימות והרשאה מאובטחת סביב האפליקציה. כדי למנוע אימות לא תקין באפליקציה שפונה לציבור, צריך להקצות משתמשים חיצוניים ב-Identity Platform (מידע נוסף מופיע בקטע הבא).

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

Identity Platform

תרחיש לדוגמה:

  • אימות כשירות
  • אימות רב-שלבי
  • SLA ל-Enterprise
  • תמיכה רחבה בפרוטוקולים
  • הגנה חכמה על חשבון Google

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

reCAPTCHA

תרחיש לדוגמה:

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

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

Security Command Center

‫Security Command Center כולל שלושה שירותים שעוזרים לכם לטפל בבעיות בזיהוי ובאימות: Event Threat Detection,‏ Security Health Analytics ו-Web Security Scanner.

הכלי Event Threat Detection תומך בתרחישי השימוש הבאים:

  • זיהוי מתקפות Brute Force
  • זיהוי שימוש לרעה ב-IAM

הכלי Event Threat Detection עוקב אחרי הזרם של Cloud Logging ומחיל לוגיקת זיהוי ומודיעין איומים קנייני ברמה מפורטת. כש-Event Threat Detection מזהה איום, הוא כותב ממצא ב-Security Command Center וב-Cloud Logging בפרויקט שתבחרו. סוגי האירועים הבאים שימושיים לזיהוי אימות שנכשל:

  • מתקפת Brute Force על SSH. זיהוי של ניסיון מוצלח לכניסה בכוח ל-SSH במארח.
  • הענקת הרשאה חריגה. זיהוי הרשאות שניתנו למשתמשים בניהול הזהויות והרשאות הגישה (IAM) מחוץ לארגון שלכם ב- Google Cloud .

‫Security Health Analytics תומך בתרחישי השימוש הבאים:

  • אכיפה של MFA/2FA
  • הגנה על מפתחות API
  • אכיפה של רוטציית מפתחות API

Security Command Center עוזר למנוע אימות לא תקין על ידי מעקב אחרי התאימות לאימות רב-שלבי (MFA) והתקינות של מפתחות ה-API. אתם יכולים לזהות בקשות חשודות ולחסום אותן או לסמן אותן לטיפול מיוחד.

‫Web Security Scanner תומך בתרחיש השימוש הבא:

  • דליפות של מזהה הסשן

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

מפתחות אבטחה של Titan

תרחיש לדוגמה:

  • אימות דו-שלבי עמיד בפני פישינג
  • אימות במחשב ובנייד

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

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

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

Artifact Registry

תרחיש לדוגמה:

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

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

Binary Authorization

תרחיש לדוגמה:

  • מוודאים שרק קונטיינרים מהימנים נפרסים

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

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

תרחיש לדוגמה:

  • שירות חיפוש

  • כלי לניתוח הרשאות גישה

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

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

Cloud Build

תרחיש לדוגמה:

  • בדיקת שינויים בקוד

  • הרצת בדיקות

  • סטנדרטיזציה של פריסות

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

Cloud Armor

תרחיש לדוגמה:

  • חסימת הרצת קוד מרחוק

רוב ההתקפות נגד תוכנות ותקינות נתונים הן ספציפיות לאפליקציות, ולכן יש רק כמה דרכים לצמצם את ההתקפות האלה – למשל, שימוש בחומת אש ליישומי אינטרנט (WAF) כמו Cloud Armor. ב-OWASP מומלץ לא לקבל אובייקטים שעברו סריאליזציה ממקורות לא מהימנים. אם אפשר, אפשר להגביל את נקודות הקצה שמקבלות את האובייקטים האלה לקבוצה של כתובות IP מהימנות באמצעות כלל דחייה שדומה לכלל הבא:

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

מחליפים את מה שכתוב בשדות הבאים:

  • ‫/endpoint: הנתיב של נקודת הקצה שמקבלת אובייקטים שעברו סריאליזציה
  • ‫1.2.3.4/32: טווח כתובות ה-IP שצריך לשמור על הגישה לממשק.

כדי לצמצם את הסיכון להתקפות אופייניות על תוכנה ועל תקינות נתונים שמשתמשות בהרצת קוד מרחוק (RCE), כדאי להשתמש בקבוצת הכללים המוגדרת מראש נגד התקפות RCE. אפשר להשתמש בכלל evaluatePreconfiguredExpr('rce-stable') כדי לחסום מתקפות נפוצות של RCE נגד UNIX ו-Windows Shells.

התקפות ה-RCE שמתוארות במאמר Juice Shop challenges for insecure deserializations מריצות פונקציות וביטויים רגולריים ב-Node.js בשרת. סוגי התקפות כאלה לא נחסמים על ידי קבוצת הכללים המוגדרת מראש של RCE וכלל OWASP Modsecurity התואם, וצריך לצמצם את הסיכון שלהם באמצעות תיקונים בצד השרת או כללים מותאמים אישית.

VirusTotal

תרחיש לדוגמה:

  • סריקת נתונים לא מהימנים

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

Security Command Center

שירות Web Security Scanner ב-Security Command Center תומך בתרחיש השימוש הבא:

  • Insecure deserialization

‫Web Security Scanner סורק את אפליקציות האינטרנט שלכם כדי למצוא נקודות חולשה. לדוגמה, אם אתם משתמשים בגרסה של Apache Struts שחושפת את האפליקציה שלכם לנקודות חולשה להתקפות של החדרת קוד מרחוק, Web Security Scanner יוצר ממצא מסוג STRUTS_INSECURE_DESERIALIZATION.

‫A09: כשלים ברישום ביומן ובמעקב אחר אבטחה

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

Access Transparency

תרחיש לדוגמה:

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

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

Apigee

תרחיש לדוגמה:

  • ייצוא יומנים של Apigee ל-SIEM
  • שימוש בממשק המשתמש של Apigee Monitoring
  • פעולה בהתאם לשיטות המומלצות לניטור

יש כמה דרכים לבצע רישום ביומן, מעקב, טיפול בשגיאות ורישום ביומן ביקורת ב-Apigee:

  • רישום ביומן
    • אפשר לשלוח הודעות יומן ל-Splunk או לנקודות קצה אחרות של syslog באמצעות המדיניות MessageLogging.
    • אפשר לשלוף נתונים אנליטיים של API דרך Analytics API ולייבא או לייצא אותם למערכות אחרות.
    • ב-Edge for Private Cloud, אפשר להשתמש במדיניות MessageLogging כדי לכתוב לקובצי יומן מקומיים. קבצי יומן מכל אחד מהרכיבים הפועלים זמינים גם כן.
    • אפשר להשתמש במדיניות JavaScript כדי לשלוח הודעות יומן לנקודת קצה של רישום ביומן REST באופן סינכרוני או אסינכרוני.
  • מעקב
    • אפשר להשתמש בממשק המשתמש או ב-API של API Monitoring כדי לעקוב באופן קבוע אחרי ממשקי API ומערכות עורפיות ולהפעיל התראות.
    • כדאי להשתמש במעקב אחרי תקינות כדי לעקוב באופן קבוע אחרי שרתים בעורף היעד.
    • ‫Apigee מספק המלצות למעקב אחרי Edge for Private Cloud.
    • ב-Apigee יש גם שיטות מומלצות שהצוות יכול להשתמש בהן כדי לעקוב אחרי תוכנית ה-API.
  • טיפול בשגיאות
    • ‫Apigee מציע מנגנון רב-עוצמה ורב-תכליתי לטיפול בשגיאות ב-API proxies. בדומה לאופן שבו תוכנית Java יכולה לזהות חריגים, שרתי proxy ל-API יכולים לזהות תקלות ולקבוע איך להחזיר תשובות מתאימות ללקוחות.
    • הטיפול בשגיאות בהתאמה אישית ב-Apigee מאפשר לכם להוסיף פונקציונליות כמו רישום הודעות ביומן בכל פעם שמתרחשת שגיאה.
  • יומני ביקורת
    • פלטפורמת Apigee שומרת יומן ביקורת שמתעד שינויים ב-API Proxy, במוצרים ובהיסטוריית הארגון.
    • היומן הזה זמין דרך ממשק המשתמש או דרך Management API.

Google Security Operations

תרחיש לדוגמה:

  • זיהוי איומים
  • אזהרה מוקדמת

צוותי אבטחה יכולים לשלוח את נתוני הטלמטריה שלהם ל-Google Security Operations כדי שתוכלו להחיל כללי זיהוי מתקדמים על מערך נתונים מאוחד.

Sensitive Data Protection

תרחיש לדוגמה:

  • הסתרה אוטומטית של מידע אישי רגיש

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

Cloud Key Management Service

תרחיש לדוגמה:

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

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

Cloud Logging

תרחיש לדוגמה:

  • צבירת יומנים
  • אחסון יומנים
  • חיפוש ביומן
  • ניתוח יומנים

בעזרת Cloud Logging תוכלו לאחסן, לחפש, לנתח ולנטר נתונים ואירועים ביומן, וגם לקבל התראות מ- Google Cloud ומ-Amazon Web Services. הוא כולל גישה לשירות BindPlane, שבו אפשר להשתמש כדי לאסוף נתוני רישום ממעל 150 רכיבי אפליקציה נפוצים, ממערכות מקומיות וממערכות ענן היברידי.

Cloud Monitoring

תרחיש לדוגמה:

  • מעקב אחר יומנים
  • התראות על אירועים

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

Cloud Source Repositories

תרחיש לדוגמה:

  • שיוך של שינוי בקוד
  • רישום ביומן הביקורת של גישה

יומני הביקורת של Cloud שנוצרים על ידי Cloud Source Repositories מאפשרים לקבל תובנות לגבי הפעולות שבוצעו במאגר, כולל איפה ומתי.

Error Reporting

תרחיש לדוגמה:

  • תיעוד שגיאות פנימיות באפליקציה ב-Cloud Logging
  • איסוף דוחות קריסה מחוץ למופע החישוב שקרס

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

Cloud Armor

תרחיש לדוגמה:

  • רישום ביומן של מדיניות האבטחה
  • לוחות בקרה למעקב
  • התראות על חריגות בתנועה

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

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

‫Cloud Armor כותב באופן אוטומטי יומני ביקורת של פעילות אדמין, שבהם מתועדות פעולות שמשנות את ההגדרות או את המטא-נתונים של משאב. אפשר גם להגדיר את השירות כך שיכתוב יומני ביקורת של Data Access שמכילים קריאות ל-API שקוראות את ההגדרות או את המטא-נתונים של משאבים, וגם קריאות ל-API שמבוססות על פעולות של משתמשים ויוצרות, משנות או קוראות נתוני משאבים שסופקו על ידי משתמשים.

Identity Platform

תרחיש לדוגמה:

  • יומני הביקורת Admin Activity
  • יומני ביקורת של Data Access
  • יומני ביקורת System Event
  • יומני ביקורת של מדיניות שנדחתה
  • יומני פעילות של אימות

‫Identity Platform היא פלטפורמת ה-CIAM של Google Cloud שמתעדת כברירת מחדל פעילות אימות.

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

Security Command Center

תרחישים לדוגמה:

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

באמצעות לוח הבקרה של התאימות, אתם יכולים לעקוב באופן רציף אחרי התאימות לבקרות מ-PCI-DSS, מ-CIS Google Cloud Computing Foundations Benchmark ועוד. בדף נכסים מוצגים כלGoogle Cloud המשאבים, שנקראים נכסים, בארגון שלכם. בדף אפשר לראות את הנכסים של כל הארגון, או לסנן את הנכסים לפי פרויקט ספציפי, לפי סוג הנכס או לפי סוג השינוי. לבסוף, תוכלו לעיין במלאי ממצאים מפורט לגבי כל הנכסים של הארגון, כדי לראות את סיכוני האבטחה הפוטנציאליים.

בנוסף, שירות Event Threat Detection של Security Command Center תומך בתרחישי השימוש הבאים:

  • מתקפת Brute Force
  • כריית מטבעות וירטואליים
  • שימוש לרעה ב-IAM
  • תוכנה זדונית
  • פישינג

הכלי Event Threat Detection עוקב אחרי הזרם של Cloud Logging ומחיל לוגיקת זיהוי ומודיעין איומים קנייני ברמה מפורטת. התכונה Event Threat Detection (זיהוי איומים באירועים) מזהה רשומות חשובות ביומנים ומעבירה אותן לבדיקה. כש-Event Threat Detection מזהה איום, הוא כותב ממצא ב-Security Command Center ובפרויקט Cloud Logging.

‫A10: מתקפת Server-Side Request Forgery‏ (SSRF)

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

Apigee

תרחיש לדוגמה:

  • חסימת מתקפות SSRF באמצעות LFI או RFI

ל-Apigee יש מנתחי XML ו-JSON מובנים שמשתמשים ב-XPath או ב-JSONPath כדי לחלץ נתונים. יש בו מדיניות XMLThreatProtection להגנה מפני מטען ייעודי (payload) של XML זדוני, ומדיניות JSONThreatProtection להגנה מפני מטען ייעודי (payload) של JSON זדוני.

בעזרת מדיניות ExtractVariables של Apigee אפשר לחלץ את התוכן מבקשה או מתגובה ולהקצות את התוכן הזה למשתנה. אפשר לחלץ כל חלק מההודעה, כולל כותרות, נתיבי URI, מטען ייעודי (payload) בפורמט JSON ו-XML, פרמטרים של טופס ופרמטרים של שאילתה. המדיניות פועלת על ידי החלת תבנית טקסט על תוכן ההודעה, וכשהיא מוצאת התאמה, היא מגדירה משתנה עם תוכן ההודעה שצוין.

Cloud Armor

תרחיש לדוגמה:

  • סינון מתקפות SSRF באמצעות LFI או RFI

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

אף אחד מהכללים בקבוצת הכללים המרכזית של OWASP ModeSecurity לא מגן באופן ספציפי מפני מתקפות SSRF, אבל הכללים של הכללת קבצים מקומיים (LFI) והכללת קבצים מרחוק (RFI) יכולים לעזור להתגונן מפני חלק מהמתקפות האלה. כדי למנוע מתוקף לאחזר קבצים מקומיים בשרת, משתמשים בכלל evaluatePreconfiguredExpr('lfi-stable') במדיניות אבטחה של Cloud Armor.

האתגר של SSRF Juice Shop משתמש בקבוצות הכללים המוגדרות מראש של הכללת קבצים מרחוק (RFI) או הכללת קבצים מקומיים (LFI) כדי לעזור לצמצם חלק מהמתקפות האלה, כי הן חוסמות הכללה של כתובות URL או Path traversal. לדוגמה, הכלל הבא מאפשר את שני סטים הכללים:

evaluatePreconfiguredExpr('lfi-stable') ||
evaluatePreconfiguredExpr('rfi-stable')

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

VPC Service Controls

תרחיש לדוגמה:

  • הגדרת היקפים של רשתות כדי לפלח שרתים

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

חומת אש של ענן וירטואלי פרטי (VPC)

תרחיש לדוגמה:

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

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

Security Command Center

שירות Web Security Scanner ב-Security Command Center תומך בתרחיש השימוש הבא:

  • מעקב אחרי אפליקציות אינטרנט

‫Web Security Scanner סורק את אפליקציות האינטרנט שלכם כדי למצוא נקודות חולשה. לדוגמה, אם האפליקציה שלכם חשופה לזיוף בקשות בצד השרת, Web Security Scanner יוצר ממצא של SERVER_SIDE_REQUEST_FORGERY.

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