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

Last reviewed 2023-03-10 UTC

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

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

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

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

בארכיטקטורה שמוצגת בתרשים הקודם נעשה שימוש בשילוב של התכונות והשירותים הבאים 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 מאפליקציית serverless נוצר בפרויקט השירות. אפשר ליצור את מחבר הגישה ל-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 ואת האפליקציה חסרת השרתים שלכם בפרימטר של VPC Service Controls בלי רשת 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 .

פרויקטים

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

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

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

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

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

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

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

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

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

קבוצה פרויקט תפקידים
אדמין של 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)

אתם יכולים להגן על האפליקציות בלי שרת (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.

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

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

מדיניות גישה

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

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

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

אם הסביבה שלכם כבר כוללת שרת 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. מידע נוסף מופיע במאמר בנושא שימוש בסודות.

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

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

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

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

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

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

‫Cloud Armor ו-WAF

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

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

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

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

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

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

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

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

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

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

מסכם הכול

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

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

מיפוי תאימות

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

סיכון השבתה זמנית של אותות אכיפה בתוכנית האחריות שלכם
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 (כפי שמוגדר בתוכנית ה-blueprint של 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 להגבלת היקף הגישה ל-API Google Cloud (מסופק באמצעות תוכנית בסיסית לארגונים) ללא
‫10. טיפול לא תקין בחריגים והודעות שגיאה מפורטות ללא שיטות מומלצות לתכנות מאובטח
‫11. פונקציות, משאבי ענן וטריגרים של אירועים שיצאו משימוש כדי לצמצם את שטח הפנים של המתקפה, כדאי להשתמש בעדכונים. עדכונים עוזרים להקטין את הסיכוי להפעלה מקרית של איטרציה קודמת ומיושנת של שירות. בנוסף, הם עוזרים לבדוק את מצב האבטחה של עדכון חדש באמצעות בדיקות A/B, יחד עם כלים למעקב ולרישום ביומן.
  • תשתית כקוד (IaC) לניהול משאבי ענן
  • מעקב אחרי משאבי ענן באמצעות Security Command Center
  • מעקב אחר החיוב ב-Cloud
  • ניקוי משאבי ענן שלא בשימוש כדי לצמצם את שטח ההתקפה
‫12. שמירת נתונים בין הפעלות ללא ללא

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