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

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

ארכיטקטורה

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

כדי לקרוא מידע נוסף על הגישה שלנו לאבטחה, אפשר לעיין ב<a href="https://cloud.google.com/security/whitepaper">סקירה מפורטת</a> סקירה כללית על אבטחה ב-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 פועלים במערכת Borg של Google לניהול קונטיינרים. ב-Cloud Run יש שני סביבות הפעלה לקונטיינרים:

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

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

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

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

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

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

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

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

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

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

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

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

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

אבטחת רשת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שליטה בתעבורת נתונים נכנסת (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 שמוגדרת כברירת מחדל.

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

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

בקרת גישה

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

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

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

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

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

אם אתם משתמשים ביציאת VPC ישירה, אתם יכולים לצרף תגי רשת למשאב 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 כדי להשבית את בדיקת ההרשאות של Cloud Run Invoker IAM ולאפשר גישה לא מאומתת. כשמופעלת בדיקת 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 כבק-אנד של מאזן עומסים (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

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

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

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