פריסת ארכיטקטורה מאובטחת בלי שרת (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

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

ההבדלים בין פונקציות 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 משותפת.

הארכיטקטורה של תוכנית הבסיס בלי שרת (serverless).

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

  • מאזן עומסים חיצוני של אפליקציות מקבל את הנתונים שאפליקציות בלי שרתים צריכות מהאינטרנט ומעביר אותם ל-Cloud Run. מאזן העומסים החיצוני של אפליקציות (ALB) הוא מאזן עומסים בשכבה 7.
  • ‫Google Cloud Armor פועל כחומת אש ליישומי אינטרנט (WAF) כדי להגן על האפליקציות בלי שרת (serverless) מפני התקפות מניעת שירות (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) מאפליקציית serverless בפרויקט השירות. אפשר ליצור את מחבר הגישה ל-VPC ללא שרת בפרויקט המארח על ידי ציון 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 משותפת. אפשר להטמיע את הארכיטקטורה החלופית הזו אם משתמשים בטופולוגיה של רכזת וחישורים.

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

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

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

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

הגדרות של מערכת ה-build

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

תנועה ב-SSL

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

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

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

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

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

אמצעי בקרה להיקף

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

מדיניות גישה

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

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

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

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

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

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

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

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

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

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

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

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

רישום ביומן

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

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

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

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

מעקב והתראות

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

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

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

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

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

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

בדיקות קישוריות לא מופעלות על ידי קוד 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
מומלץ לפרוס את התוכנית הזו אחרי פריסת התוכנית של התשתית הארגונית.

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

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

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

מסכם הכול

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

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

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

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

סיכון צמצום הסיכון בתוכנית האחריות שלכם
1. החדרת נתוני אירועים לפונקציה ‫Cloud Armor ומאזני עומסים חיצוניים של אפליקציות (ALB) עוזרים להגן מפני 10 הסיכונים המובילים של OWASP, כפי שמתואר באפשרויות לצמצום הסיכונים של OWASP Top 10 2021 ב- 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 Enterprise Foundations)
 ללא
5. מעקב ורישום ביומן לא מספקים של פונקציות Cloud Logging לוחות בקרה ומבנה התראות ב-Cloud Monitoring
6. תלות לא מאובטחת בצד שלישי ללא הגנה על צינור ה-CI/CD באמצעות סריקת קוד וניתוח לפני הפריסה
7. אחסון לא מאובטח של סודות באפליקציה Secret Manager ניהול סודות בקוד אפליקציה
‫8. התקפת מניעת שירות (DoS) וניצול משאבים פיננסיים
  • Cloud Armor
  • זמן קצוב לתפוגה של שירות Cloud Run (ברירת המחדל היא 120 שניות)
 ללא
‫9. שינוי לוגיקה עסקית ללא שרת ‫VPC Service Controls להגבלת היקף הגישה ל- Google Cloud API (מסופק באמצעות תוכנית אב-טיפוס של Enterprise Foundations) ללא
‫10. טיפול לא תקין בחריגים והודעות שגיאה מפורטות ללא שיטות מומלצות לתכנות מאובטח
‫11. פונקציות, משאבי ענן וטריגרים לאירועים שיצאו משימוש כדי לצמצם את שטח הפנים של המתקפה, אפשר להשתמש בעדכונים. הגרסאות עוזרות לצמצם את הסיכוי להפעלה מקרית של איטרציה קודמת ומיושנת של שירות. גרסאות חדשות גם עוזרות לכם לבדוק את מצב האבטחה של גרסה חדשה באמצעות בדיקת A/B, יחד עם כלי ניטור ורישום ביומן.
  • תשתית כקוד (IaC) לניהול משאבי ענן
  • מעקב אחרי משאבי ענן באמצעות Security Command Center
  • מעקב אחר החיוב ב-Cloud
  • ניקוי משאבי ענן שלא בשימוש כדי לצמצם את שטח המתקפה
‫12. שמירת נתונים בין הפעלות ללא ללא

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