סקירה כללית על תכנון האבטחה

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

ארכיטקטורה

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

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

ארכיטקטורת Cloud Run כוללת רכיבי תשתית רבים ושונים. בתרשים הבא מוצג איך הרכיבים האלה מגיבים לבקשות לשירות ולקריאות ל-Cloud Run Admin API:

איור של רכיבי התשתית של Cloud Run
איור 1. תרשים של רכיבי התשתית של Cloud Run.

בקשות לשירות שלכם

כשמתבצעת בקשה לשירות Cloud Run דרך הדומיין המותאם אישית או ישירות לכתובת ה-URL של run.app, הבקשה מטופלת על ידי הרכיבים הבאים:

  • ממשק הקצה של Google‏ (GFE): שירות התשתית הגלובלי של Google שמסיים חיבורי TLS ומחיל הגנות מפני התקפות DoS כששולחים בקשה לכתובת ה-URL‏ run.app. ‫Cloud Run הוא שירות אזורי, ולכן כשניגשים לבקשה דרך כתובת ה-URL‏ run.app, ממשק הקצה של Google‏ (GFE) מעביר את הבקשה ל-Cloud Run דרך ערוץ מוצפן באזור המתאים.
  • Google Cloud מאזן עומסים: כשמגדירים את Cloud Load Balancing לטיפול בדומיין מותאם אישית, הוא כולל את הפונקציונליות של GFE שצוינה קודם. אפשר גם להגדיר Google Cloud מאזני עומסים לביצוע פונקציות נוספות, כמו ניהול תנועה ובקרת גישה.
  • שרת proxy של HTTP: רכיב אזורי שמאזן עומסים של בקשות HTTP נכנסות למופעים של האפליקציות בסביבת הארגז.
  • מתזמן: בוחר את שרתי האפליקציות לאירוח מופעים של האפליקציות שלכם בארגז חול.
  • שרת אפליקציות: צומת מחשוב אזורי עם דיירים מרובים שיוצר ומנהל את ארגזי החול שמריצים את המופעים של כל מאגר אפליקציות.
  • ארגז חול: מבודד את קוד המשתמש מהמערכת ומהלקוחות האחרים. מידע נוסף זמין בקטע אבטחת מחשוב.
  • אחסון: חושף ממשק של שרת קבצים לתמונות קונטיינרים שיובאו ממאגרי קונטיינרים נתמכים.
  • שרת מטא-נתונים: מספק פרטי כניסה ומטא-נתונים ספציפיים לארגז חול.
  • תעבורת נתונים יוצאת ברשת: ניהול של תעבורת נתונים יוצאת שמופעלת על ידי ארגז החול.

קריאות ל-Cloud Run Admin API

כשמתבצעת בקשה אל Cloud Run Admin API, הרכיבים הבאים מטפלים בבקשה:

  • ממשק קצה של Google‏ (GFE): שירות התשתית הגלובלית של Google שמבטל חיבורי TLS ומיישם הגנות מפני התקפות מניעת שירות (DoS).
  • מישור הבקרה: מאמת את הגדרות האפליקציה וכותב אותן לאחסון.
  • אחסון הגדרות: אחסון של הגדרות האפליקציה ב-Spanner וב-Bigtable לגישה של רכיבים אחרים, כמו שרת האפליקציה, מתזמן ורכיבי רשת.

אבטחת מחשוב

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

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

סביבות הפעלה

רכיבי Cloud Run פועלים במערכת לניהול קונטיינרים של Google,‏ Borg. ב-Cloud Run יש שני סביבות הפעלה לקונטיינרים:

  • דור ראשון: האפשרות הזו מבוססת על פלטפורמת אבטחת הקונטיינרים gVisor, ויש לה בסיס קוד קטן, שמספק שטח פנים קטן יותר להתקפה. כל שינוי נבדק מבחינת אבטחה, ורוב השינויים נכתבים באופן בטוח לזיכרון. הגנה נוספת מושגת באמצעות סינון של קריאות למערכת Secure Computing Mode (seccomp).

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

שתי סביבות ההפעלה האלה משתמשות בשתי שכבות של ארגז חול, שכוללות שכבה שמגובה בחומרה וששווה למכונות וירטואליות (וירטואליזציה של x86), ושכבת ליבת תוכנה, כמו שמוצג בתרשים הבא:

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

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

זיהוי איומים ב-Cloud Run

כדי לעקוב באופן רציף אחרי מצב המשאבים של Cloud Run ולזהות מתקפות נפוצות בזמן ריצה, כמו קבצים בינאריים חשודים או קוד זדוני, אפשר להשתמש ב-Cloud Run Threat Detection.

הצפנה ואחסון של נתונים

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

אם יש לכם נתונים עם מצב, אתם יכולים לנהל את הנתונים בדרכים הבאות:

בנוסף, Cloud Run משולב עם הרבהGoogle Cloud מערכות אחרות כדי לנהל את הנתונים שלכם ולגשת אליהם בדרכים הבאות:

ב-Across Google Cloud, כל הנתונים שלכם מוצפנים כשהם באחסון.

‫Cloud Run עומד בדרישות של יוזמות כלל-עולמיות בנושא הגנה על נתונים ושקיפות, כולל Access Transparency ומיקום נתונים. Google Cloud

אבטחת רשת

‫Cloud Run וכל שאר השירותים Google Cloud מצפינים את כל התעבורה במעבר. אתם יכולים לשלב אמצעי בקרה על תעבורת נכנסת ויוצאת בשירותים או בעבודות של Cloud Run כדי להוסיף שכבת הגבלה נוספת. אדמינים ארגוניים יכולים גם לאכוף תעבורת נתונים יוצאת (egress) ותעבורת נתונים נכנסת (ingress) על ידי הגדרת מדיניות הארגון.

תנועת נתונים יוצאת

תעבורת נתונים יוצאת שיוצאת מ-Cloud Run נחשבת לשכבת תעבורה 4 (TCP ו-UDP).

כברירת מחדל, תעבורת נתונים יוצאת (egress) עוברת באחד מהנתיבים הבאים כשהיא יוצאת מ-Cloud Run:

  • יעד היעד נמצא ברשת VPC: התעבורה עוברת לרשת VPC או לרשת VPC משותפת בפרויקט באמצעות יציאה ישירה מרשת VPC או מחבר Serverless VPC Access. המחבר הוא משאב אזורי שנמצא ישירות ברשת ה-VPC.
  • יעד הטירגוט לא נמצא ברשת VPC: תעבורת הנתונים מנותבת ישירות ליעד הטירגוט ברשת של Google או באינטרנט הציבורי.
נתיב הרשת של Cloud Run לרשתות VPC ולרשתות שאינן VPC
איור 3. תעבורת נתונים יוצאת (egress) יכולה לעבור לרשת VPC או לרשת שאינה VPC באמצעות תעבורת נתונים יוצאת (egress) ישירה של VPC או מחבר.

שליטה בתעבורת נתונים יוצאת (egress)

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

אחרי שהיא נמצאת ברשת ה-VPC, אפשר להשתמש בכלים של VPC כדי לנהל את התנועה, למשל:

אדמינים בארגון יכולים גם לאכוף תעבורת נתונים יוצאת (egress) על ידי הגדרת האילוץ Allowed VPC egress settings (Cloud Run).

תנועה נכנסת (Ingress)

בניגוד לתעבורת נתונים יוצאת (egress), תעבורת הנתונים הנכנסת (ingress) ב-Cloud Run היא בשכבת האפליקציה 7 (HTTP).

‫Cloud Run מקבל תעבורת נתונים נכנסת מהמקורות הבאים:

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

  • רשת VPC: אתם יכולים לנתב תעבורת נתונים מרשת VPC לשירותי Cloud Run באמצעות גישה פרטית ל-Google,‏ Private Service Connect או מאזן עומסים פנימי של אפליקציות (ALB). תעבורת נתונים מהסוג הזה תמיד נשארת בתוך הרשת של Google.

  • ‫Google Cloud services: התנועה עוברת ישירות אל Cloud Run משירותים אחרים של Google Cloud , כמו BigQuery או אפילו Cloud Run עצמו. במקרים מסוימים, אפשר גם להגדיר את השירותים האלה כך שהם ינותבו דרך רשת VPC. תעבורת נתונים מהסוג הזה תמיד נשארת בתוך הרשת של Google.

תרשים של רכיבי התשתית של Cloud Run
איור 4. תעבורת נתונים נכנסת (ingress) ברשת HTTP בשכבה 7 אל Cloud Run.

מודל אבטחת הרשת של Cloud Run כולל את המאפיינים הבאים של תנועת נכנסת:

  • תנועה ישירה לכתובת ה-URL של run.app שמוגדרת כברירת מחדל: תמיד נדרש פרוטוקול HTTPS כדי שהתנועה תיכנס ל-Cloud Run דרך כתובת ה-URL של run.app. תשתית שרת הקצה של Google מסיימת את ה-TLS ואז מעבירה את תעבורת הנתונים ל-Cloud Run ולמיכל שלכם דרך ערוץ מוצפן. אפשר להשבית את כתובת ה-URL שמוגדרת כברירת מחדל.
  • תנועה לדומיין מותאם אישית שמשויך למאזן העומסים שלכם ב- Google Cloud : בתנועת HTTPS, מאזני עומסים פנימיים וחיצוניים ב- Google Cloud מסיימים את ה-TLS ומעבירים את התנועה ל-Cloud Run ולמאגר התגים שלכם דרך ערוץ מוצפן.מאזני עומסים ב- Google Cloud מאפשרים גם להחיל תכונות אבטחה נוספות כמו IAP,‏ Cloud Armor ומדיניות SSL.

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

שליטה בתעבורת נתונים נכנסת (Ingress)

אמצעי בקרת תעבורת נתונים נכנסת (ingress) ב-Cloud Run מאפשרים לנהל את התעבורה שנכנסת ל-Cloud Run כדי לוודא שהתעבורה מגיעה רק ממקורות מהימנים.

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

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

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

אדמינים ארגוניים יכולים גם לאכוף כניסה על ידי הגדרת מדיניות ארגונית.

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

בקרת גישה

אמצעי בקרת גישה משמשים להגבלת הגישה לשירותים ולמשימות שלכם ב-Cloud Run.

מי יכול לנהל את השירות או את העבודה

כדי לקבוע מי יכול לנהל את השירות או את המשימה שלכם ב-Cloud Run, נעשה שימוש ב-IAM כדי להעניק הרשאה למשתמשים ולחשבונות שירות.

הגישה של השירות או העבודה שלכם

כדי לשלוט במה שעומסי העבודה של Cloud Run יכולים לגשת אליו דרך הרשת, אפשר להעביר את כל התעבורה דרך רשת ה-VPC ולהחיל כללי חומת אש של VPC, כפי שמתואר בקטע אבטחת רשת.

אם אתם משתמשים ב-Direct VPC egress, אתם יכולים לצרף תגי רשת למשאב Cloud Run ולהפנות לתגי הרשת בכלל חומת האש. אם אתם משתמשים בחיבור לרשת (VPC) מאפליקציית serverless, אתם יכולים להחיל כללי חומת אש על מופעי המחבר.

משתמשים ב-IAM כדי לקבוע לאילו משאבים בשירות או בעבודה של Cloud Run תהיה גישה. שירותים ועבודות משתמשים בחשבון השירות של Compute Engine שמוגדר כברירת מחדל כברירת מחדל. לעומסי עבודה רגישים, מומלץ להשתמש בחשבון שירות ייעודי כדי שתוכלו להעניק רק את ההרשאות שעומס העבודה צריך כדי לבצע את העבודה שלו. מידע נוסף על שימוש בזהות לכל שירות לניהול חשבון שירות ייעודי במאמר אבטחת שירותי Cloud Run באמצעות Recommender מוסבר איך Cloud Run מזכיר למשתמשים ליצור חשבון שירות ייעודי.

מי יכול להפעיל את השירות או את העבודה

ב-Cloud Run יש כמה אפשרויות שונות לקבוע מי יכול להפעיל את השירות או את המשימה.

אמצעי בקרה על תעבורה נכנסת

בסעיף הקודם מוסבר איך לנהל את התעבורה הנכנסת של שירותי Cloud Run ברמת הרשת.

משימות ב-Cloud Run לא מטפלות בבקשות, ולכן הן לא משתמשות באמצעי בקרה על תעבורת נכנסת כשהן מופעלות.

‫IAM לשירות שלכם

משתמשים בהרשאה run.routes.invoke כדי להגדיר למי יש גישה לשירות Cloud Run בדרכים הבאות:

  • נותנים את ההרשאה לבחור חשבונות שירות או קבוצות כדי לאפשר גישה לשירות. כל הבקשות חייבות לכלול כותרת הרשאה של HTTP שמכילה אסימון מזהה של OpenID Connect שנחתם על ידי Google עבור אחד מחשבונות השירות המורשים.

  • בוחרים באפשרות Allow public access כדי להשבית את בדיקת IAM של Cloud Run Invoker ולאפשר גישה לא מאומתת. כשמופעלת בדיקת IAM של Cloud Run Invoker,‏ Cloud Run מבצע בדיקת IAM בכל בקשה.

כדי לוודא שרק חברים בארגון יכולים להפעיל שירות Cloud Run, אדמין בארגון יכול להגדיר את מדיניות הארגון Domain restricted sharing (שיתוף מוגבל לדומיין). אדמינים בארגון יכולים גם להשבית את האפשרות הזו בשירותים ספציפיים של Cloud Run. כדי ליצור כתובות URL ציבוריות, צריך לבחור באפשרות שיתוף באופן גלוי לכולם כשמופעל שיתוף מוגבל לדומיין.

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

הפעלת שרת proxy לאימות זהויות (IAP) בשירות Cloud Run

מפעילים את IAP ב-Cloud Run כדי לאבטח את התעבורה לשירות Cloud Run על ידי ניתוב שלה ל-IAP לצורך אימות. אפשר גם להשתמש באיחוד שירותי אימות הזהות של כוח העבודה עם IAP ב-Cloud Run. איך מגדירים שרת proxy לאימות זהויות (IAP) ל-Cloud Run

תכונות אבטחה של מאזן עומסים בשירות

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

IAM לתפקיד שלכם

משתמשים בהרשאה run.jobs.run כדי להגדיר מי יכול להריץ את משימת Cloud Run בדרכים הבאות:

  • נותנים הרשאה לבחור חשבונות שירות או קבוצות כדי לאפשר גישה לעבודה. אם ההפעלה של העבודה מתבצעת על ידי שירות אחר, כמו Cloud Scheduler, לחשבון השירות שבו נעשה שימוש צריכה להיות ההרשאה run.jobs.run בעבודה.

  • נותנים למשתמש המחובר הרשאה להפעיל משימה ממסוף Google Cloud. אם הג'וב מופעל על ידי שירות אחר, כמו Cloud Scheduler, לחשבון השירות או לקבוצה שמשמשים להפעלת הג'וב צריכה להיות ההרשאה run.jobs.run לגבי הג'וב.

כדי להבטיח שרק חברים בארגון יוכלו להריץ משימה ב-Cloud Run, אדמין בארגון יכול להגדיר את האילוץ Domain restricted sharing (שיתוף מוגבל לדומיין). אדמינים בארגון יכולים גם להשבית את האפשרות הזו למשימות ספציפיות של Cloud Run.

VPC Service Controls

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

אבטחת שרשרת האספקה

קובצי אימג' בסיסיים שמנוהלים על ידי Buildpacks של Google Cloud

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

אבטחת שרשרת האספקה הפנימית ב-Cloud Run

מכיוון ש-Cloud Run פועל על Borg, הוא מיישם את כל אמצעי האבטחה בשרשרת האספקה שהם סטנדרטיים בכל שירותי Google, כמו Gmail ו-YouTube. מידע נוסף על שיטות העבודה של Google בשרשרת האספקה זמין במסמכים הטכניים BeyondProd ו-Binary Authorization ל-Borg.

Binary Authorization

ב-Cloud Run יש תמיכה מובנית בBinary Authorization כדי לוודא שרק קובצי אימג' של קונטיינר מהימנים נפרסים ב-Cloud Run. מידע נוסף זמין במאמר סקירה כללית על הגדרת Cloud Run.

תובנות בנושא אבטחת שרשרת האספקה של תוכנות

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

אבטחה של סביבת ההפעלה

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

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

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

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

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