פריסת ארכיטקטורה מאובטחת בלי שרת (serverless) באמצעות Cloud Run

Last reviewed 2023-03-10 UTC

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

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

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

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

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

כדי לעזור להגדיר אמצעי בקרה מרכזיים שקשורים לאפליקציות בלי שרת (serverless), Cloud Security Alliance (CSA) פרסמה את 12 הסיכונים הקריטיים המובילים לאפליקציות בלי שרת (serverless). אמצעי האבטחה שבהם נעשה שימוש בתוכנית הזו נועדו לתת מענה לסיכונים שרלוונטיים לתרחישי השימוש השונים שמתוארים במסמך הזה.

תרחישי שימוש ב-Serverless

התוכנית תומכת בתרחישי השימוש הבאים:

ההבדלים בין פונקציות Cloud Run לבין Cloud Run כוללים את הדברים הבאים:

  • פונקציות Cloud Run מופעלות על ידי אירועים, כמו שינויים בנתונים במסד נתונים או קבלת הודעה ממערכת העברת הודעות כמו Pub/Sub. הפעלת Cloud Run מתבצעת באמצעות בקשות, כמו בקשות HTTP.
  • השימוש בפונקציות Cloud Run מוגבל לקבוצה של סביבות זמן ריצה נתמכות. אפשר להשתמש ב-Cloud Run בכל שפת תכנות.
  • פונקציות Cloud Run מנהלות את הקונטיינרים ואת התשתית ששולטת בשרת האינטרנט או בזמן הריצה של השפה, כדי שתוכלו להתמקד בקוד. ‫Cloud Run מאפשר לכם להריץ את השירותים האלה בעצמכם, כדי שתוכלו לשלוט בהגדרות של הקונטיינר.

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

ארכיטקטורה

התוכנית הזו מאפשרת להריץ אפליקציות ללא שרת ב-Cloud Run עם VPC משותף. מומלץ להשתמש ב-VPC משותף כי הוא מאפשר לנהל את מדיניות הרשת ולשלוט בכל משאבי הרשת באופן מרכזי. בנוסף, VPC משותף נפרס בתוכנית ה-blueprint של enterprise foundations.

בתמונה הבאה אפשר לראות איך מריצים אפליקציות בלי שרת (serverless) ברשת VPC משותפת.

הארכיטקטורה של התוכנית המוכנה לשימוש ללא שרת.

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

  • מאזן עומסים חיצוני של אפליקציות מקבל את הנתונים שאפליקציות ללא שרתים צריכות מהאינטרנט ומעביר אותם ל-Cloud Run. מאזן העומסים החיצוני של אפליקציות (ALB) הוא מאזן עומסים בשכבה 7.
  • ‫Google Cloud Armor פועל כחומת אש ליישומי אינטרנט (WAF) כדי להגן על האפליקציות חסרות השרתים מפני התקפות מניעת שירות (DoS) ומתקפות באינטרנט.
  • ‫Cloud Run מאפשר להריץ קוד אפליקציה בקונטיינרים ומנהל את התשתית בשבילכם. בתוכנית הזו, הגדרת הכניסה של Cloud Load Balancing פנימי ושל Cloud מגבילה את הגישה ל-Cloud Run, כך ש-Cloud Run יקבל בקשות רק ממאזן העומסים החיצוני של אפליקציות.

  • מחבר הגישה ל-VPC מאפליקציית serverless מחבר את האפליקציה שלכם מאפליקציית serverless לרשת ה-VPC באמצעות חיבור לרשת (VPC) מאפליקציית serverless. חיבור לרשת (VPC) מאפליקציית serverless עוזר לוודא שהבקשות מהאפליקציה שלכם מסוג serverless לרשת ה-VPC לא נחשפות לאינטרנט. בעזרת Serverless VPC Access, ‏ Cloud Run יכול לתקשר עם שירותים אחרים, מערכות אחסון ומשאבים שתומכים ב-VPC Service Controls.

    כברירת מחדל, יוצרים את חיבור לרשת VPC בפרויקט השירות. אפשר ליצור את מחבר הגישה ל-VPC מאפליקציית serverless בפרויקט המארח על ידי ציון true למשתנה הקלט connector_on_host_project כשמריצים את המודול Secure Cloud Run Network. מידע נוסף זמין במאמר השוואה בין שיטות ההגדרה.

  • כללי חומת אש בענן וירטואלי פרטי (VPC) שולטים בזרימת הנתונים לרשת המשנה שמארחת את המשאבים שלכם, כמו שרת של חברה שמתארח ב-Compute Engine או נתונים של חברה שמאוחסנים ב-Cloud Storage.

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

  • VPC משותף מאפשר לכם לחבר את המחבר של חיבור לרשת (VPC) מאפליקציית serverless בפרויקט השירות לפרויקט המארח.

  • ‫Cloud Key Management Service ‏ (Cloud KMS) מאחסן את מפתחות ההצפנה בניהול הלקוח (CMEK) שבהם משתמשים השירותים בתוכנית הזו, כולל האפליקציה חסרת השרתים, Artifact Registry ו-Cloud Run.

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

ארכיטקטורה חלופית: Cloud Run ללא רשת VPC משותפת

אם אתם לא משתמשים ברשת VPC משותפת, אתם יכולים לפרוס את Cloud Run ואת אפליקציית ה-serverless שלכם בפרימטר של VPC Service Control בלי רשת VPC משותפת. אפשר להטמיע את הארכיטקטורה החלופית הזו אם משתמשים בטופולוגיה של רכזת וחיבורים.

בתמונה הבאה אפשר לראות איך מריצים אפליקציות ללא שרת בלי Shared VPC.

ארכיטקטורה חלופית לתוכנית ה-serverless.

בארכיטקטורה שמוצגת בתרשים הקודם נעשה שימוש בשילוב של שירותים ותכונות שלGoogle Cloud , בדומה לאלה שמתוארים בקטע הקודם, ארכיטקטורה מומלצת: Cloud Run עם VPC משותף.

מבנה ארגוני

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

בתרשים הבא מוצגת היררכיה של משאבים עם תיקיות שמייצגות סביבות שונות, כמו bootstrap, ‏ common, ‏ production,‏ non-production (או testing) ו-development. היררכיית המשאבים הזו מבוססת על ההיררכיה שמתוארת בתוכנית הבסיסית לארגונים. אתם פורסים את הפרויקטים שצוינו בתוכנית הבסיסית בתיקיות הבאות: Common,‏ Production,‏ Non-production ו-Dev.

מבנה הארגון של תוכנית ה-serverless.

בקטעים הבאים מוסבר התרשים הזה בפירוט.

תיקיות

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

תיקייה תיאור
Bootstrap מכיל משאבים שנדרשים לפריסת תוכנית הבסיס לארגונים.
Common כולל שירותים מרכזיים לארגון, כמו פרויקט האבטחה.
Production כולל פרויקטים עם משאבי ענן שנבדקו ומוכנים לשימוש על ידי לקוחות. בתוכנית הזו, התיקייה Production מכילה את פרויקט השירות ואת הפרויקט המארח.
Non-production מכיל פרויקטים עם משאבי ענן שנמצאים כרגע בשלב הבדיקה וההכנה להשקה. בתוכנית הזו, התיקייה Non-production מכילה את פרויקט השירות ואת הפרויקט המארח.
Dev מכיל פרויקטים עם משאבי ענן שנמצאים כרגע בפיתוח. בתוכנית הזו, התיקייה Dev מכילה את פרויקט השירות ואת הפרויקט המארח.

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

פרויקטים

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

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

כשמחילים את קוד Terraform, מציינים את שם הפרויקט הזה, והתוכנית מפריסה את השירותים.
פרויקט שירות הפרויקט הזה כולל את אפליקציית ה-serverless שלכם, את Cloud Run ואת המחבר של Serverless VPC Access. מצרפים את פרויקט השירות לפרויקט המארח כדי שפרויקט השירות יוכל להשתתף ברשת ה-VPC המשותפת.

כשמחילים את קוד Terraform, מציינים את שם הפרויקט הזה. התוכנית פורסת את Cloud Run,‏ Cloud Armor, מחבר חיבור לרשת (VPC) מאפליקציית serverless ומאזן העומסים.
פרויקט אבטחה הפרויקט הזה כולל את השירותים הספציפיים לאבטחה, כמו Cloud KMS ו-Secret Manager.

כשמחילים את קוד Terraform, מציינים את שם הפרויקט הזה, והתוכנית פורסת את Cloud KMS. אם משתמשים במודול Secure Cloud Run Harness, ‏ Artifact Registry נפרס גם הוא.

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

אם פורסים כמה מופעים של תוכנית ה-Blueprint הזו בלי תוכנית ה-Blueprint של Enterprise Foundations, לכל מופע יש פרויקט אבטחה משלו.

מיפוי תפקידים וקבוצות לפרויקטים

צריך לתת לקבוצות משתמשים שונות בארגון גישה לפרויקטים שמרכיבים את הארכיטקטורה בלי שרת (serverless). בטבלה הבאה מפורטות ההמלצות לתוכניות Blueprint לגבי קבוצות משתמשים והקצאות תפקידים בפרויקטים שאתם יוצרים. אפשר להתאים אישית את הקבוצות כך שיתאימו למבנה הקיים של הארגון, אבל מומלץ לשמור על הפרדה דומה של התפקידים והקצאת התפקידים.

קבוצה פרויקט תפקידים
אדמין של Serverless

grp-gcp-serverless-admin@example.com		 פרויקט שירות
אדמין לענייני אבטחה ללא שרת

grp-gcp-serverless-security-admin@example.com		 פרויקט אבטחה
מפתח Cloud Run

grp-gcp-secure-cloud-run-developer@example.com		 פרויקט אבטחה
משתמש Cloud Run

grp-gcp-secure-cloud-run-user@example.com		 פרויקט שירות

אמצעי בקרה לאבטחה

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

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

אמצעי בקרה לאבטחת אפליקציות בלי שרת (serverless)

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

אמצעי בקרה של מערכת ה-Build

כשפורסים את האפליקציה בלי שרת (serverless), משתמשים ב-Artifact Registry כדי לאחסן את קובצי האימג' של קונטיינר ואת הקבצים הבינאריים. שירות Artifact Registry תומך ב-CMEK, כך שאתם יכולים להצפין את המאגר באמצעות מפתחות הצפנה משלכם.

תנועה ב-SSL

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

כללי רשת וחומת אש

כללי חומת אש של ענן וירטואלי פרטי (VPC) שולטים בזרימת הנתונים אל המתחמים. יוצרים כללי חומת אש שחוסמים את כל התעבורה היוצאת, למעט חיבורים ספציפיים ביציאת TCP 443 משמות דומיין מיוחדים של restricted.googleapis.com. השימוש בדומיין restricted.googleapis.com מציע את היתרונות הבאים:

  • הוא עוזר לצמצם את השטח החשוף להתקפה ברשת באמצעות Private Google Access כשעומסי עבודה מתקשרים עם ממשקי API ושירותים של Google.
  • הוא מוודא שאתם משתמשים רק בשירותים שתומכים ב-VPC Service Controls.

מידע נוסף זמין במאמר הגדרת גישה פרטית ל-Google.

אמצעי בקרה להיקף ההרשאות

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

מדיניות גישה

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

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

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

אם הסביבה שלכם כבר כוללת שרת proxy לאימות זהויות (IAP), אתם יכולים להגדיר את מאזן העומסים החיצוני של אפליקציות (ALB) כך שישתמש ב-IAP כדי לאשר תעבורת נתונים לאפליקציה בלי שרת (serverless). ‫IAP מאפשר לכם ליצור שכבת הרשאה מרכזית לאפליקציה ללא שרתים, כך שתוכלו להשתמש באמצעי בקרה לגישה ברמת האפליקציה במקום להסתמך על חומות אש ברמת הרשת.

כדי להפעיל רכישות מתוך האפליקציה באפליקציה שלכם, בקובץ loadbalancer.tf, מגדירים את iap_config.enable ל-true.

מידע נוסף על IAP זמין במאמר סקירה כללית על שרת proxy לאימות זהויות (IAP).

חשבונות שירות ואמצעי בקרה לגישה

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

  • חשבון שירות של Cloud Run‏ (cloud_run_sa) עם התפקידים הבאים:

    • roles/run.invoker
    • roles/secretmanager.secretAccessor

    מידע נוסף זמין במאמר מתן גישה של Cloud Run לסוד.

  • חשבון של מחבר חיבור לרשת (VPC) מאפליקציית serverless‏ (gcp_sa_vpcaccess) עם התפקיד roles/compute.networkUser.

  • חשבון שני של מחבר חיבור לרשת (VPC) מאפליקציית serverless‏ (cloud_services) עם התפקיד roles/compute.networkUser.

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

  • זהות שירות להרצת Cloud Run‏ (run_identity_services) עם התפקיד roles/vpcaccess.user.

  • סוכן שירות של Google APIs (cloud_services_sa) עם התפקיד roles/editor. חשבון השירות הזה מאפשר ל-Cloud Run לתקשר עם מחבר הגישה לרשת (VPC) מאפליקציית serverless.

  • זהות שירות ל-Cloud Run‏ (serverless_sa) עם התפקיד roles/artifactregistry.reader. חשבון השירות הזה מספק גישה ל-Artifact Registry ולמפתחות הצפנה ופענוח של CMEK.

ניהול מפתחות

אתם משתמשים במפתחות CMEK כדי להגן על הנתונים ב-Artifact Registry וב-Cloud Run. אתם משתמשים במפתחות ההצפנה הבאים:

  • מפתח תוכנה ל-Artifact Registry שמאשר את הקוד של האפליקציה ללא שרתים.
  • מפתח הצפנה להצפנת קובצי האימג' של הקונטיינרים שנפרסים ב-Cloud Run.

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

ניהול סודות

‫Cloud Run תומך ב-Secret Manager לאחסון הסודות שאולי נדרשים לאפליקציה שלכם ללא שרת. הסודות האלה יכולים לכלול מפתחות API ושמות משתמשים וסיסמאות למסדי נתונים. כדי לחשוף את הסוד כנפח מוטמע, משתמשים במשתנים volume_mounts ו-volumes במודול הראשי.

כשפורסים את תוכנית הבסיס הזו באמצעות תוכנית הבסיס של Enterprise Foundations, צריך להוסיף את הסודות לפרויקט הסודות לפני שמחילים את הקוד של Terraform. תוכנית ה-blueprint תעניק לחשבון השירות של Cloud Run את התפקיד Secret Manager Secret Accessor. מידע נוסף מופיע במאמר בנושא שימוש בסודות.

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

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

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

מגבלת מדיניות תיאור הערך המומלץ
constraints/run.allowedIngress אפשר תעבורת נתונים נכנסת (ingress) רק משירותים פנימיים או ממאזן עומסים חיצוני של אפליקציות (ALB). internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress הגדרת הדרישה שעדכונים של שירות Cloud Run ישתמשו במחבר של חיבור לרשת (VPC) מאפליקציית serverless, ולוודא שהגדרות תעבורת הנתונים היוצאת (egress) של ה-VPC של העדכונים מוגדרות כך שרק טווחים פרטיים מורשים. private-ranges-only

אמצעי בקרה תפעוליים

אתם יכולים להפעיל רישום ביומן ותכונות של Security Command Center Premium, כמו ניתוח של מצב האבטחה וזיהוי איומים. אמצעי הבקרה האלה מאפשרים לכם:

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

רישום ביומן

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

אחרי שמפעילים את תוכנית האב, מומלץ להגדיר את הדברים הבאים:

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

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

מעקב והתראות

אחרי שמפעילים את התוכנית, אפשר להגדיר התראות כדי להודיע למרכז האבטחה (SOC) שלכם שאולי מתרחש אירוע אבטחה. לדוגמה, אפשר להשתמש בהתראות כדי לעדכן את אנליסטים האבטחה כשמשתנה הרשאה בתפקיד IAM. מידע נוסף על הגדרת התראות ב-Security Command Center זמין במאמר בנושא הגדרה של התראות על ממצאים.

לוח הבקרה של Cloud Run Monitoring, שהוא חלק מספריית לוחות הבקרה לדוגמה, מספק לכם את המידע הבא:

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

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

ניפוי באגים ופתרון בעיות

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

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

אמצעי בקרה לזיהוי

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

‫Cloud Armor ו-WAF

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

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

שם הכלל של Cloud Armor שם הכלל ב-ModSecurity
הרצת קוד מרחוק rce-v33-stable
הכללה של קובץ מקומי lfi-v33-stable
מתקפת פרוטוקול protocolattack-v33-stable
הכללת קבצים מרחוק rfi-v33-stable
זיהוי סורקים scannerdetection-v33-stable
מתקפת קיבוע סשן sessionfixation-v33-stable
הזרקת SQL sqli-v33-stable
פרצת אבטחה XSS‏ (cross-site scripting) xss-v33-stable

כשהכללים האלה מופעלים, Cloud Armor דוחה באופן אוטומטי כל תנועה שתואמת לכלל.

מידע נוסף על הכללים האלה זמין במאמר בנושא התאמה של כללי WAF שהוגדרו מראש ב-Google Cloud Armor.

זיהוי בעיות אבטחה ב-Cloud Run

אפשר לזהות בעיות אבטחה פוטנציאליות ב-Cloud Run באמצעות Recommender. הכלי להמלצות יכול לזהות בעיות אבטחה כמו:

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

בערך יום אחרי הפריסה של Cloud Run, שירות Recommender מתחיל לספק את הממצאים וההמלצות שלו. הכלי Recommender מציג את הממצאים שלו ואת פעולות התיקון המומלצות ברשימת השירותים של Cloud Run או בActive Assist.

מצבי פריסה של Terraform

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

מצב פריסה מודולים של Terraform
מומלץ לפרוס את התוכנית הזו אחרי פריסת התוכנית Enterprise foundations.

האפשרות הזו פורסת את המשאבים של תוכנית ה-blueprint הזו באותו מתחם היקפי של VPC Service Controls שבו נעשה שימוש בתוכנית ה-blueprint של Enterprise Foundations. מידע נוסף זמין במאמר איך להתאים אישית את Foundation v2.3.1 לפריסה מאובטחת של שרתים וירטואליים.

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

כדי להשתמש באפשרות הזו, צריך ליצור היקף של VPC Service Controls.		 משתמשים במודולים הבאים של Terraform:

מסכם הכול

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

  1. צריך לעיין בREADME של תוכנית ה-Blueprint ולוודא שאתם עומדים בכל הדרישות המוקדמות.
  2. יוצרים אישור SSL לשימוש במאזן עומסים חיצוני של אפליקציות.
    אם לא תבצעו את השלב הזה, תוכנית האב תשתמש באישור בחתימה עצמית כדי לפרוס את איזון העומסים, והדפדפן יציג אזהרות לגבי חיבורים לא מאובטחים כשתנסו לגשת לאפליקציה ללא שרת.
  3. בסביבת הבדיקה, פורסים את הדוגמה המאובטחת של Cloud Run כדי לראות את תוכנית האב בפעולה. במסגרת תהליך הבדיקה, כדאי לבצע את הפעולות הבאות:
    1. אפשר להשתמש ב-Security Command Center כדי לסרוק את הפרויקטים בהתאם לדרישות תאימות נפוצות.
    2. מחליפים את האפליקציה לדוגמה באפליקציה אמיתית ומריצים תרחיש פריסה טיפוסי.
    3. כדאי לעבוד עם צוותי הנדסת האפליקציות והתפעול בארגון כדי לבדוק את הגישה שלהם לפרויקטים ולוודא שהם יכולים לבצע אינטראקציה עם הפתרון בצורה שהם מצפים לה.
  4. פורסים את התוכנית בסביבה שלכם.

מיפויים של תאימות

כדי לעזור להגדיר אמצעי אבטחה מרכזיים שקשורים לאפליקציות בלי שרת (serverless), Cloud Security Alliance (CSA) פרסמה את 12 הסיכונים הקריטיים המובילים לאפליקציות בלי שרת (serverless). אמצעי האבטחה שמשמשים בתוכנית הזו עוזרים לכם לטפל ברוב הסיכונים האלה, כמו שמתואר בטבלה הבאה.

סיכון הפחתת הסיכון בתוכנית האחריות שלכם
1. החדרת נתוני אירועים לפונקציה ‫Cloud Armor ומאזני עומסים חיצוניים של אפליקציות (ALB) עוזרים להגן מפני עשרת סיכוני האבטחה המובילים של OWASP, כפי שמתואר במאמר מזעור עשרת סיכוני האבטחה המובילים של OWASP:2025 ב- Google Cloud שיטות קידוד מאובטחות כמו טיפול בחריגים, כפי שמתואר ב-OWASP Secure Coding Practices וב-Supply chain Levels for Software Artifacts (SLSA)
2. אימות פגום ללא IAP ו-Identity Platform לאימות משתמשים בשירות
3. הגדרת פריסה לא מאובטחת של שרתים CMEK עם Cloud KMS
 ניהול מפתחות הצפנה משלכם
4. הרשאות ותפקידים של פונקציות עם הרשאות יתר
  • חשבון שירות בהתאמה אישית לאימות שירות (לא חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine)
  • תפקידי IAM עם היקף מצומצם בחשבון השירות של Cloud Run
  • ‫VPC Service Controls להגבלת היקף הגישה ל- Google Cloud API (כפי שסופק באמצעות תוכנית הבסיס הארגונית של Google Cloud )
 ללא
5. מעקב ורישום ביומן לא מספקים של פונקציות Cloud Logging לוחות בקרה ומבנה התראות ב-Cloud Monitoring
6. תלות לא מאובטחת בצד שלישי ללא הגנה על פייפליין CI/CD באמצעות סריקת קוד וניתוח לפני פריסה
7. אחסון לא מאובטח של סודות באפליקציה Secret Manager ניהול סודות בקוד אפליקציה
‫8. התקפת מניעת שירות (DoS) וניצול יתר של משאבים פיננסיים
  • Cloud Armor
  • זמן קצוב לתפוגה של שירות Cloud Run (ברירת המחדל היא 120 שניות)
 ללא
‫9. שינוי לוגיקה עסקית ללא שרת ‫VPC Service Controls להגבלת היקף הגישה ל-API Google Cloud (מסופק באמצעות תוכנית בסיסית לארגונים) ללא
‫10. טיפול לא תקין בחריגים והודעות שגיאה מפורטות ללא שיטות מומלצות לתכנות מאובטח
‫11. פונקציות, משאבי ענן וטריגרים של אירועים שיצאו משימוש כדי לצמצם את שטח הפנים של המתקפה, אפשר להשתמש בעדכונים. הגרסאות עוזרות לצמצם את הסיכוי להפעלה בטעות של איטרציה קודמת ומיושנת של שירות. בנוסף, גרסאות עוזרות לכם לבדוק את מצב האבטחה של גרסה חדשה באמצעות בדיקת A/B, יחד עם כלי ניטור ורישום ביומן.
  • תשתית כקוד (IaC) לניהול משאבי ענן
  • מעקב אחרי משאבי ענן באמצעות Security Command Center
  • מעקב אחר החיוב ב-Cloud
  • ניקוי משאבי ענן שלא בשימוש כדי לצמצם את שטח ההתקפה
‫12. שמירת נתונים בין הפעלות ללא ללא

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