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

איך 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, ה-GFE מעביר את הבקשה ל-Cloud Run דרך ערוץ מוצפן באזור המתאים.
  • Google Cloud מאזן העומסים: כשמגדירים את Cloud Load Balancing לטיפול בדומיין בהתאמה אישית, הוא כולל את הפונקציונליות של GFE שצוינה קודם. אפשר גם להגדיר מאזני עומסים Google Cloudכדי לבצע פונקציות נוספות, כמו ניהול תעבורת נתונים ובקרת גישה.
  • Proxy ל-HTTP: רכיב אזורי שמאזן עומסים של בקשות HTTP נכנסות למכונות של האפליקציות בארגז החול.
  • מתזמן: בוחר את שרתי האפליקציות שיארחו מכונות של האפליקציות בארגז החול.
  • שרת אפליקציות: צומת מחשוב אזורי ורב-דיירים שיוצר ומנהל את ארגזי החול שמריצים את המכונות של מאגר האפליקציה.
  • ארגז חול (sandbox): מבודד את קוד המשתמש מהמערכת ומלקוחות אחרים. מידע נוסף זמין בקטע אבטחת Compute בהמשך.
  • אחסון: חשיפת ממשק של שרת קבצים לקובצי אימג' של קונטיינרים שיובאו מContainer Registry נתמכים.
  • שרת מטא-נתונים: מספק פרטי כניסה ומטא-נתונים ספציפיים לארגז החול.
  • רשת יוצאת: ניהול תעבורת הנתונים היוצאת שנוצרת על ידי ארגז החול.

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

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

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

אבטחת מחשוב

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

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

סביבות הפעלה

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

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

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

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

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

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

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

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

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

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

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

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

בכל שירותי Google Cloud, כל הנתונים שלכם מוצפנים במנוחה.

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

אבטחת רשת

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

תנועת נתונים יוצאת (egress)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • הפניית תנועה לכתובת ה-URL שמוגדרת כברירת מחדל ב-run.app: כדי שהתנועה תיכנס ל-Cloud Run, כתובת ה-URL של run.app תמיד דורשת HTTPS. תשתית ה-frontend של 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, ב-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 יש כמה אפשרויות שונות לקבוע מי יפעיל את השירות או יריץ את המשימה.

אמצעי בקרה על תעבורת נתונים נכנסת (ingress)

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

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

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

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

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

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

כדי לוודא שרק גורמים בארגון יכולים להפעיל שירות Cloud Run, Organization Administrator יכול להגדיר את מדיניות הארגון הגבלה לפי דומיין. מנהלי הארגון יכולים גם לבטל את ההסכמה לשירותים ספציפיים של Cloud Run. כדי ליצור כתובות URL ציבוריות, בוחרים באפשרות Allow public access כשהשיתוף מוגבל לדומיין.

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

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

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

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

אם הגדרתם שירות Cloud Run בתור בק-אנד של מאזן עומסים (LB) של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

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

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

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

Binary Authorization

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

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

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

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

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

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

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

איך מגדירים עדכוני אבטחה בסביבת ההפעלה

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