אפשרויות לצמצום הסיכון של 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 קביעת הצפנים ששרת ה-proxy של SSL או מאזן העומסים של 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 מכשירים לאימות דו-שלבי שעמידים בפני פישינג, עם שבב חומרה מובנה (עם קושחה שפותחה על ידי 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.

הצפנה של נתונים רגישים במנוחה במיפויים של זוגות מפתח/ערך.

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

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

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

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

A04: Insecure Design

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

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, אתם יכולים לזהות נתונים סודיים ולהמיר אותם לטוקנים.‫DLP API יכול לעזור לכם להגביל את החשיפה של נתונים סודיים, כי אחרי שהנתונים הומרו לטוקנים ונשמרו, אתם יכולים להגדיר אמצעי בקרת גישה כדי להגביל את האנשים שיכולים לצפות בנתונים. למידע נוסף, אפשר לעיין במאמרים אוטומציה של סיווג נתונים שהועלו ל-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

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

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

זרימת נתונים משותפת מאפשרת למפתחי API לשלב מדיניות ומשאבים בקבוצה שאפשר לעשות בה שימוש חוזר. באמצעות איסוף של מדיניות ומשאבים שאפשר לעשות בהם שימוש חוזר במקום אחד, זרימת נתונים משותפת עוזרת לכם לשמור על עקביות, לקצר את זמן הפיתוח ולנהל את הקוד. אתם יכולים לכלול זרימת נתונים משותפת בתוך proxy ל-API נפרדים באמצעות מדיניות FlowCallout, או למקם זרימות נתונים משותפות בנקודות חיבור של זרימת נתונים כדי להפעיל באופן אוטומטי את הלוגיקה של זרימת נתונים משותפת לכל 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 (הכללת קבצים מרחוק). לדוגמה, ניצול של הדמיה חוצת אתרים ב-Juice Shop לא מצליח כשמחילים את כללי ה-LFI. משתמשים בכלל evaluatePreconfiguredExpr('lfi-stable') || evaluatePreconfiguredExpr('rfi-stable') כדי לחסום בקשות באמצעות קבוצות הכללים LFI ו-RFI, ומתאימים את הכללים לפי הצורך. אפשר לוודא שפתרון האתגר כבר לא מצליח.

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

  • כדי להימנע משינוי לא מורשה של פועל HTTP, צריך להשתמש בקבוצת הכללים לאכיפת שיטה. משתמשים בכלל evaluatePreconfiguredExpr('methodenforcement-stable') כדי לאסור שימוש ב-HTTP request methods שאינן 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 עוקב אחרי שגיאות אבטחה נפוצות, כמו אי התאמות בסוג התוכן, כותרות אבטחה לא תקינות והצגת תוכן מעורב. הכלי גם עוקב אחרי נקודות חולשה, כמו נקודות חולשה מסוג 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 כולל שלושה שירותים שיעזרו לכם לטפל ברכיבים פגיעים ומיושנים: Container Threat Detection,‏ 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 יוצאת. זיהוי נקודות חולשה שנוצלו בניסיון לבצע התקפות מניעת שירות.

‫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), או JWT, משמשים בדרך כלל לשיתוף טענות או הצהרות בין אפליקציות מקושרות. 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 לאימות זהויות ואימות משתמשים שהוקצו להם הרשאות באמצעות ניהול זהויות וגישה או 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 בפרויקט שתבחרו. סוגי האירועים הבאים שימושיים לזיהוי אימות שנפרץ:

  • פריצה בכוח ל-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 בנוגע לביטול סדרות לא מאובטח מריצות פונקציות וביטויים רגולריים ב-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 מציע מנגנון רב עוצמה ורב-תכליתי לטיפול בשגיאות ב-proxy ל-API. בדומה לאופן שבו תוכנית Java יכולה לזהות חריגים, שרתי proxy ל-API יכולים לזהות תקלות ולקבוע איך להחזיר תשובות מתאימות ללקוחות.
    • הטיפול בשגיאות בהתאמה אישית ב-Apigee מאפשר לכם להוסיף פונקציונליות כמו רישום הודעות ביומן בכל פעם שמתרחשת שגיאה.
  • יומני ביקורת
    • פלטפורמת Apigee שומרת יומן ביקורת שמתעד שינויים ב-API proxies, במוצרים ובהיסטוריית הארגון.
    • היומן הזה זמין דרך ממשק המשתמש או דרך 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

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

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

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

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

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

Identity Platform

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

  • יומני הביקורת Admin Activity
  • יומני ביקורת של Data Access
  • יומני ביקורת של אירועים במערכת
  • יומני ביקורת של Policy denied
  • יומני פעילות של אימות

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

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

Security Command Center

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

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

באמצעות לוח הבקרה של התאימות, אתם יכולים לעקוב אחרי התאימות באופן רציף לבקרות מ-PCI-DSS, מ-CIS Google Cloud Computing Foundations Benchmark ועוד. בדף Assets מוצגת תצוגה מפורטת של כל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 או של מעבר נתיבים. לדוגמה, הכלל הבא מפעיל את שתי קבוצות הכללים:

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.

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