התוכן הזה עודכן לאחרונה במאי 2024, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
במאמר הזה נתאר איך Google מטמיעה את האבטחה בתשתית שלה, באמצעות ארכיטקטורה מבוססת-ענן שנקראת BeyondProd. BeyondProd הוא אוסף של שירותים ואמצעי בקרה בתשתית שלנו, שפועלים יחד כדי להגן על עומסי העבודה (workload) בפרויקטים. עומסי עבודה הם המשימות הייחודיות שאפליקציה משלימה. בעזרת BeyondProd אנחנו מגינים על המיקרו-שירותים (microservices) שאנחנו מפעילים בסביבה שלנו, כולל האופן שבו אנחנו משנים את הקוד וניגשים לנתוני המשתמשים.
המסמך הזה הוא חלק מסדרה של מאמרים טכניים שמתארים את הטכנולוגיות שפיתחנו, כמו Chrome Enterprise Premium, , כדי להגן על הפלטפורמות של Google מפני איומים מתוחכמים. באמצעות Chrome Enterprise Premium אנחנו מטמיעים ארכיטקטורת מודל אבטחה של אפס אמון, שתוכננה לספק גישה מאובטחת לפלטפורמות של Google ולשירותים שפועלים בה. בדומה ל-Chrome Enterprise Premium, גם BeyondProd לא מסתמכת על אמצעי הגנה היקפיים מסורתיים, כמו חומות אש. במקום זאת, בעזרת BeyondProd אפשר ליצור אמון בין מיקרו-שירותים באמצעות מאפיינים כמו מקור הקוד, זהויות של שירותים וחומרה מהימנה. האמון הזה חל גם על תוכנות שפועלות ב- Google Cloud ועל תוכנות שנפרסות על ידי לקוחות Google Cloudומאפשרות להם לגשת אליהן.
במסמך הזה מתוארים היתרונות של ארכיטקטורת BeyondProd, השירותים והתהליכים שכלולים בה והמעבר לשימוש בה. במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו למצוא מידע נוסף.
מבוא
ארכיטקטורות אבטחה מודרניות התקדמו מעבר למודל האבטחה ההיקפי המסורתי, שבו חומת אש מגינה על המתחם וכל המשתמשים והשירותים במתחם נחשבים מהימנים.
כיום המשתמשים ניידים ולרוב פועלים מחוץ למתחם האבטחה המסורתי של הארגון, למשל מהבית, מבית קפה או במטוס. באמצעות Chrome Enterprise Premium אנחנו מעניקים גישה למשאבי החברה על סמך מספר גורמים, כולל זהות המשתמש, זהות המכשיר שממנו ניגשים למשאב, תקינות המכשיר ואותות למהימנות כמו התנהגות המשתמש ורשימות של בקרת גישה.
ב-BeyondProd מתייחסים לאותו החשש ביחס לשירותים בסביבת הייצור, כמו החשש ב-Chrome Enterprise Premium ביחס למשתמשים. בארכיטקטורה מבוססת-ענן, אי אפשר פשוט להסתמך על חומת אש שתגן על רשת הייצור. המיקרו-שירותים נמצאים בתנועה ונפרסים בסביבות שונות אצל מארחים הטרוגניים, והם פועלים ברמות שונות של אמון ורגישות. ב-Chrome Enterprise Premium מציינים שהאמון של המשתמשים צריך להתבסס על מאפיינים כמו מצב המכשירים בהתאם להקשר, ולא על היכולת להתחבר לרשת הארגונית. ב-BeyondProd מציינים שהאמון בשירותים צריך להתבסס על מאפיינים כמו מקור הקוד, חומרה מהימנה וזהות השירות, ולא על המיקום ברשת הייצור, כמו כתובת IP או שם מארח.
תשתית בקונטיינרים
התשתית שלנו פורסת את עומסי העבודה כמיקרו-שירותים אישיים בקונטיינרים. מיקרו-שירותים מפרידים את המשימות הייחודיות שאפליקציות צריכות לבצע, לשירותים נפרדים. אפשר לפתח ולנהל את השירותים בנפרד, ולכל אחד מהם יהיו ממשק API, השקה, התאמה לעומס (scaling) וניהול מכסות משלו. המיקרו-שירותים הם עצמאיים, מודולריים, דינמיים וזמניים. הם ניתנים להפצה אצל הרבה מארחים, אשכולות ואפילו עננים. בארכיטקטורת מיקרו-שירותים, עומס עבודה עשוי להיות מיקרו-שירות אחד או יותר.
תשתית בקונטיינרים פירושה שכל מיקרו-שירות נפרס כקבוצה נפרדת של קונטיינרים שניתנים להעברה ולתזמון. כדי לנהל את הקונטיינרים האלה מבפנים, פיתחנו מערכת לתזמור קונטיינרים שנקראת Borg,שפורסת מיליארדי קונטיינרים בשבוע. מערכת Borg היא המערכת המאוחדת של Google לניהול קונטיינרים, וגם ההשראה ל-Kubernetes.
באמצעות קונטיינרים קל יותר לתזמן ביעילות את עומסי העבודה בין מכונות. האריזה של מיקרו-שירותים בקונטיינרים מאפשרת לפצל עומסי עבודה ליחידות קטנות יותר שניתנות לניהול לצורכי תחזוקה וזיהוי. הארכיטקטורה הזו מתאימה עומסי עבודה לפי הצורך – אם יש ביקוש גבוה לעומס עבודה מסוים, יכולות להיות כמה מכונות שמפעילות עותקים של אותו קונטיינר כדי להתמודד עם ההיקף הנדרש של עומס העבודה.
נושא האבטחה ב-Google ממלא תפקיד קריטי בהתפתחות של הארכיטקטורה שלנו. מטרת הארכיטקטורה של מיקרו-שירותים ותהליך הפיתוח היא לטפל בבעיות אבטחה בשלב מוקדם במחזור החיים של הפיתוח והפריסה, בזמן שעלות הטיפול בבעיות היא יחסית נמוכה, ולעשות זאת בצורה סטנדרטית ועקבית. כתוצאה מכך המפתחים משקיעים פחות זמן באבטחה ועדיין משיגים תוצאות מאובטחות יותר.
היתרונות של BeyondProd
העבודה עם BeyondProd מספקת לתשתית של Google הרבה יתרונות בתחום האוטומציה והאבטחה. היתרונות האלה כוללים:
- הגנה על הרשת בקצה: עומסי העבודה מבוּדדים מהתקפות ברשת ומתעבורת נתונים לא מורשית מהאינטרנט. אמנם גישה היקפית היא לא קונספט חדש, אבל היא עדיין נחשבת לשיטה מומלצת לשמירה על האבטחה בארכיטקטורות בענן. גישה היקפית משמשת להגנה על כמה שיותר תשתיות מפני תעבורת נתונים לא מורשית והתקפות פוטנציאליות מהאינטרנט, כמו התקפת מניעת שירות (DoS) המבוססת על נפח.
- חוסר אמון הדדי מהותי בין שירותים: רק מפעילים ושירותים שהם מוכרים, מהימנים ובעלי הרשאה ספציפית יכולים לגשת לשירותים אחרים. כך תוקפים לא יכולים להשתמש בקוד לא מהימן כדי לגשת לשירות. אם יש פגיעה באבטחה של שירות, היתרון הזה עוזר למנוע מתוקפים לבצע פעולות שמאפשרות להם להרחיב את פוטנציאל החשיפה. חוסר האמון ההדדי, יחד עם בקרת גישה פרטנית, עוזרים להגביל את היקף החשיפה במקרה של פגיעה באבטחה.
- מכונות מהימנות שמפעילות קוד עם מקור ידוע: זהויות השירות מוגבלות לשימוש רק עם קוד הרשאה והגדרות מותרות, ולפעול רק בסביבות מורשות ומאומתות.
- אכיפה עקבית של המדיניות בשירותים שונים: אכיפה עקבית של המדיניות עוזרת להבטיח שההחלטות בנוגע לגישה יהיו עקביות בכל השירותים. לדוגמה, תוכלו להגדיר אכיפת מדיניות שמאמתת בקשות גישה לנתוני משתמשים. כך, משתמש קצה מורשה חייב לספק בקשה מאומתת כדי לקבל גישה לשירות, והאדמין חייב לספק נימוק עסקי.
- השקה פשוטה, אוטומטית וסטנדרטית של שינויים: כך אפשר לבדוק בקלות את ההשפעה של שינויים בתשתית על האבטחה, ולהשיק תיקוני אבטחה שכמעט לא משפיעים על סביבת הייצור.
- בידוד בין עומסי עבודה שחולקים מערכת הפעלה: אם יש פגיעה באבטחה של שירות, אין לה השפעה על האבטחה של עומס עבודה אחר שפועל באותה סביבה מארחת. הבידוד הזה עוזר להגביל את רדיוס הפיצוץ במקרה של פגיעה באבטחה.
- חומרה אמינה ואימות (attestation): באמצעות Root of Trust בחומרה תוכלו לוודא שרק קוד ידוע ומורשה פועל במארח (החל מקוד בקושחה ועד לקוד שמופעל במצב משתמש), עוד לפני שעומסי העבודה מתוזמנים לפעול בו.
בזכות היתרונות האלה ניתן לפרוס קונטיינרים ומיקרו-שירותים שפועלים בתוך ארכיטקטורת הענן שלנו יכולים, והם יכולים לתקשר ביניהם ולפעול זה לצד זה, בלי להחליש את האבטחה בתשתית שלנו. בנוסף, המפתחים של מיקרו-שירותים לא צריכים להכיר את כל הפרטים לגבי האבטחה וההטמעה של התשתית עצמה.
שירותי האבטחה של BeyondProd
כדי ליצור את היתרונות שמוזכרים בקטע היתרונות של BeyondProd, תכננו ופיתחנו כמה שירותי אבטחה של BeyondProd. בקטעים הבאים נתאר את שירותי האבטחה האלה.
ממשק קצה של Google (GFE) להגנה על קצה הרשת
ממשק הקצה של Google (GFE) מספק הגנה על קצה הרשת. GFE מבטל את החיבור ממשתמש הקצה ומשמש כמוקד לאכיפה של שיטות מומלצות הקשורות ל-TLS (אבטחת שכבת התעבורה).
אמנם אנחנו כבר לא מתמקדים באבטחה היקפית, אבל GFE הוא עדיין חלק חשוב באסטרטגיה שלנו להגנה על שירותים פנימיים מפני התקפות מניעת שירות (DoS). GFE הוא נקודת הכניסה הראשונה כשמשתמשים מתחברים לתשתית של Google. לאחר שמשתמשים מתחברים לתשתית שלנו, GFE אחראי גם לאיזון העומסים ולניתוב מחדש של תעבורת הנתונים בין אזורים לפי הצורך. GFE הוא שרת proxy בקצה שמנתב את תעבורת הנתונים למיקרו-השירות המתאים.
מכונות וירטואליות של הלקוח ב- Google Cloud לא נרשמות ב-GFE. במקום זאת הן נרשמות בממשק הקצה של Cloud, שהוא תצורה מיוחדת של GFE, שמשתמש בסטאק הרשת של Compute Engine. ממשק הקצה של Cloud מעניק למכונות הווירטואליות של הלקוחות גישה לשירות Google באופן ישיר, באמצעות כתובת ה-IP הציבורית או הפרטית שלהם (כתובות IP פרטיות זמינות רק כאשר מופעלת גישה פרטית ל-Google).
אבטחת שכבת התעבורה של אפליקציה (ALTS) לבדיקת מהימנות בין שירותים
אבטחת שכבת התעבורה של אפליקציה (ALTS) עוזרת להבטיח חוסר אמון הדדי מהותי בין השירותים. ALTS משמשת לאימות של קריאה לשירות מרוחק (RPC), לבדיקת תקינות, להצפנה של תעבורת נתונים ולזהויות בשירות. ALTS היא מערכת להצפנת תעבורה ולאימות הדדי עבור שירותים בתשתית Google. בדרך כלל זהויות קשורות לשירותים ולא למארח או לשם של שרת ספציפי. כך אפשר לבצע בצורה חלקה רפליקה של מיקרו-שירותים, איזון עומסים ותזמון מחדש בין מארחים.
לכל מכונה יש פרטי כניסה של ALTS שמוקצים באמצעות מערכת התקינות של המארח, ואפשר לפענח אותם רק אם מערכת התקינות של המארח וידאה שההפעלה המאובטחת בוצעה בהצלחה. רוב שירותי Google פועלים כמיקרו-שירותים בנוסף ל-Borg, ולכל מיקרו-שירות יש זהות ALTS משלו. הבקר המרכזי של Borg שנקרא Borg Prime,, מעביר לעומסי עבודה את פרטי הכניסה ל-ALTS של המיקרו-שירותים בהתאם לזהות שלהם. פרטי הכניסה של ALTS ברמת המכונה יוצרים ערוץ מאובטח לצורך הקצאת פרטי כניסה למיקרו-שירותים, כך שרק מכונות שעברו הפעלה מאומתת של בדיקת התקינות של מארחים יכולים לארח עומסי עבודה של מיקרו-שירותים. למידע נוסף על פרטי הכניסה של ALTS, ראו אישורי עומסי עבודה.
Binary Authorization for Borg (BAB) לבדיקת מקור הקוד
Binary Authorization for Borg (BAB) היא בדיקה לאימות מקור הקוד. BAB היא בדיקת אכיפה בזמן פריסה שנועדה לוודא שהקוד עומד בדרישות האבטחה הפנימיות, לפני הפריסה שלו. לדוגמה, בדיקת האכיפה של BAB כוללת בדיקה של שינויים בקוד על ידי מהנדס נוסף לפני שהוא נשלח למאגר קודי המקור שלנו, וכן בינאריים שנוצרים באופן מאומת בתשתית ייעודית. בתשתית שלנו, BAB מגבילה את הפריסה של מיקרו-שירותים לא מורשים.
שימוש בתקינות של המארח לבדיקת מהימנות של מכונה
בדיקת התקינות של המארחמאמתת את התקינות של תוכנת המערכת המארחת באמצעות תהליך של הפעלה מאובטחת. האימות מגובה על ידי צ'יפ אבטחת חומרה מסוג Root of Trust (שנקרא Titan), ככל שהאפשרות הזו נתמכת. בדיקות תקינות של המארח כוללות אימות של חתימות דיגיטליות ב-BIOS, ב-baseboard management controller (BMC),בתוכנת האתחול ובליבה של מערכת ההפעלה. כשהאפשרות הזו נתמכת, בדיקות התקינות של המארח יכולות לכלול קוד שמופעל במצב משתמש וכן קוד שמופעל בקושחה של ציוד היקפי (כמו כרטיסי רשת (NIC)). בנוסף לאימות החתימות הדיגיטליות, הבדיקות האלו עוזרות לוודא שכל מארח מפעיל את הגרסה המיועדת של רכיבי התוכנה האלה.
אכיפת המדיניות באמצעות ניהול הרשאות גישה לשירותים וכרטיסי הֶקשר של משתמשי קצה
ניהול הרשאות גישה לשירותיםוכרטיסי הֶקשר של משתמשי קצה עוזרים לאכוף את המדיניות באופן עקבי בכל השירותים.
ניהול הרשאות הגישה לשירותים מגביל את אופן הגישה לנתונים בין שירותים. כשקריאת RPC נשלחת משירות אחד לאחר, ניהול הרשאות הגישה לשירותים מגדיר את כללי מדיניות ההרשאה והביקורת שנחוצים כדי לגשת לנתונים של השירות המקבל. כך אפשר להגביל את הגישה לנתונים, לתת גישה ברמה המינימלית הנדרשת ולציין איך אפשר לבצע בקרות גישה. בתשתית של Google, ניהול הגישה לשירותים מגביל את הגישה של מיקרו-שירותים לנתונים של מיקרו-שירותים אחרים, ומאפשר ניתוח גלובלי של בקרות הגישה.
כרטיסי הקשר של משתמשי קצה מונפקים על ידי שירות לאימות של משתמשי קצה, ומספקים לשירותים זהות של משתמש שהיא נפרדת מזהות השירות. אלה פרטי כניסה שמונפקים באופן מרכזי, שתקינותם מוגנת ושניתן להעבירם, והם מאמתים את זהות משתמש הקצה ששלח בקשה לשירות. כרטיסי הקשר אלה מפחיתים את הצורך באמון בין שירותים שונים, מכיוון שלעיתים קרובות זהות בין רשתות שכנות באמצעות ALTS לא מספיקה כדי להעניק גישה, והחלטות כאלה לגבי גישה לרוב מבוססות על הזהות של משתמש הקצה.
הכלים של Borg להשקה אוטומטית של שינויים ולהתאמה לעומסים
הכלים של Borg לפריסות כחול-ירוק (blue-green deployment) מאפשרים השקה פשוטה, אוטומטית וסטנדרטית של שינויים. פריסת כחול-ירוק היא דרך להשיק שינוי בעומס עבודה מבלי להשפיע על תעבורת הנתונים הנכנסת, וכך משתמשי הקצה לא נתקלים בזמן השבתה במהלך הגישה לאפליקציה.
משימת Borgהיא אירוע אחד של מיקרו-שירות, ומפעילה חלק מסוים באפליקציה. משימות עוברות התאמה כדי לטפל בעומסים, כך שמשימות חדשות נפרסות כשהעומס גדל ומשימות ישנות נסגרות כשהעומס יורד.
העברת עומסי עבודה פעילים בזמן שאנחנו מבצעים משימות תחזוקה מתבצעת על ידי הכלים של Borg. כשמשימה חדשה נפרסת ב-Borg, תעבורת הנתונים מועברת בהדרגה מהמשימה הקיימת למשימה החדשה באמצעות מאזן עומסים. כך אפשר לעדכן מיקרו-שירות ללא זמן השבתה, בלי לשבש את פעילות המשתמשים.
הכלי הזה משמש גם להחלת שדרוגים של שירותים כשאנחנו מוסיפים תכונות חדשות, וגם להחלת עדכוני אבטחה קריטיים ללא זמן השבתה. כדי לטפל בשינויים שמשפיעים על התשתית שלנו, אנחנו משתמשים במיגרציה פעילה של המכונות הווירטואליות של הלקוחות כדי לוודא שעומסי העבודה לא יושפעו.
למידע נוסף קראו את המאמר Binary Authorization ל-Borg.
בידוד של עומסי עבודה באמצעות ליבת gVisor
ליבת gVisor מאפשרת לבודד בין עומסי עבודה שחולקים מערכת הפעלה. gVisor משתמש בליבה של סביבת המשתמש כדי ליירט קריאות מערכת (syscalls) ולטפל בהן, וכך להפחית את האינטראקציה עם המארח ואת שטח ההתקפה הפוטנציאלי. הליבה הזו מספקת את רוב הפונקציונליות שנחוצה להפעלת אפליקציה, ומגבילה את שטח הליבה של המארח שנגישה לאפליקציה. ליבת gVisor היא אחד הכלים שמשמשים אותנו כדי לבודד את עומסי העבודה הפנימיים מעומסי העבודה של לקוחות Google Cloud שפועלים באותו מארח. ב-Code Sandboxing מפורטים כלים נוספים להרצה בארגז חול.
הגנה על נתוני משתמשים באמצעות BeyondProd
בקטע הזה נתאר איך פועלים שירותי BeyondProd יחד כדי להגן על נתוני המשתמשים בתשתית שלנו. בהמשך מתוארות שתי דוגמאות:
- בקשות לקבל גישה לנתוני משתמש – משלב היצירה עד הגעתן ליעד.
- ביצוע שינוי בקוד – משלב הפיתוח לשלב הייצור.
לא כל הטכנולוגיות שמופיעות משמשות בכל חלקי התשתית שלנו. הדבר תלוי בשירותים ובעומסי העבודה.
גישה לנתוני משתמשים
בתרשים הבא מוצג התהליך שמבוצע בתשתית שלנו כדי לאמת שמשתמש מסוים מורשה לגשת לנתוני משתמשים.
כדי לגשת לחשבונות משתמשים:
- משתמש שולח בקשה לממשק קצה של Google(GFE).
- GFE מסיים את חיבור ה-TLS (אבטחת שכבת התעבורה) ומעביר את הבקשה לחזית של השירות המתאים באמצעות ALTS.
- חזית האפליקציה מבצעת אימות לבקשה של המשתמש דרך שירות מרכזי לאימות של משתמש קצה (EUA), ואם האימות עבר בהצלחה מתקבל כרטיס הקשר של משתמש קצה שהוא מוצפן ובעל אורך חיים קצר.
- חזית האפליקציה מבצעת RPC באמצעות ALTS לשירות אחסון לקצה העורפי, ומתבצעת העברה של הכרטיס בבקשה לקצה העורפי.
- השירות לקצה העורפי משתמש בניהול הרשאות גישה לשירותים כדי לוודא את הקריטריונים הבאים:
- ממשק הקצה עובר אימות באמצעות אישור חוקי שלא בוטל. הבדיקה פועלת במארח מהימן ובדיקות ה-BAB הסתיימו בהצלחה.
- לזהות ה-ALTS של השירות בחזית יש הרשאה לשלוח בקשות לשירות לקצה העורפי ולהציג כרטיס EUC.
- כרטיס ההקשר של משתמש הקצה תקף.
- המשתמש שבכרטיס ה-EUC מורשה לגשת לנתונים המבוקשים.
אם אחת מהבדיקות האלה נכשלת, הבקשה נדחית.
אם הבדיקות מסתיימות בהצלחה, הנתונים מוחזרים לחזית האפליקציה המורשית ונמסרים למשתמש המורשה.
במקרים רבים יש שרשרת של קריאות לקצה העורפי, וכל השירותים המתווכים מבצעים בדיקות של מדיניות גישה לשירותים לגבי קריאות RPC נכנסות, ובנוסף כרטיס ה-EUC מועבר בקריאות RPC יוצאות.
כדי להבין טוב יותר איך תעבורת הנתונים מנותבת בתוך התשתית שלנו, ראו איך מנותבת תעבורת הנתונים.
ביצוע שינוי בקוד
בתרשים הבא מוצגת הפריסה של שינוי בקוד.
כדי לבצע שינוי בקוד:
מפַתח מבצע שינוי בקוד של מיקרו-שירות שמוגן על ידי BAB. השינוי נשלח למאגר קודי המקור המרכזי שלנו,, שבו מתבצעת אכיפה של בדיקת הקוד. לאחר האישור, השינוי נשלח אל מערכת ה-build המהימנה והמרכזית שיוצרת חבילה עם אישור מניפסט build מאומת וחתום.
בזמן הפריסה, בקר ה-BAB מוודא שהאישור החתום עבר תיקוף לאחר מכן בצינור עיבוד הנתונים לגרסת build.
מערכת Borg מטפלת בכל העדכונים של עומסי העבודה באמצעות מודל אמינות שמבטיח הפרעה מינימלית בשירותים, בין שמדובר בהשקה שגרתית ובין שבתיקון אבטחה בשעת חירום.
GFE מעביר את תעבורת הנתונים לפריסה החדשה באמצעות איזון עומסים כדי להבטיח את ההמשכיות של הפעולות.
למידע נוסף על התהליך הזה, ראו תהליך הפיתוח והייצור שלנו.
כל עומסי העבודה מחייבים בידוד. אם עומס העבודה פחות מהימן מכיוון שקוד המקור נוצר מחוץ ל-Google, הפריסה שלו תתבצע עם שכבות בידוד חזקות יותר, למשל בסביבה שמוגנת על ידי gVisor. הבידוד הזה עוזר להכיל מצבים שבהם יריב מצליח לפגוע באפליקציה.
ההשלכות של אבטחה מבוססת-ענן
בקטעים הבאים מוצגת השוואה בין היבטים של אבטחת תשתית מסורתית להיבטים המקבילים בארכיטקטורה מבוססת-ענן.
ארכיטקטורה של אפליקציות
מודל אבטחה מסורתי יותר, שמתמקד באבטחה היקפית, לא יכול להגן בעצמו על ארכיטקטורה מבוססת-ענן. בעבר, יישומים מונוליתיים השתמשו בארכיטקטורה תלת-שכבתית ונפרסו במרכזי נתונים פרטיים של ארגונים, עם קיבולת מספיקה לטיפול בעומסי שיא במהלך אירועים קריטיים. אפליקציות עם דרישות ספציפיות של חומרה או רשת נפרסו באופן מכוון במכונות ספציפיות שבדרך כלל שמרו על כתובות IP קבועות. ההשקות היו גדולות, לא תדירוֹת וקשות לתיאום, מכיוון שהשינויים שהתקבלו השפיעו בו-זמנית על חלקים רבים באפליקציה. הדבר הוביל לאפליקציות שהאריכו ימים והתעדכנו לעתים רחוקות, ושבדרך כלל תיקוני אבטחה הוחלו עליהן בתדירות נמוכה.
עם זאת, במודל מבוסס-ענן האפליקציות יכולות לפעול בעננים ציבוריים, במרכזי נתונים פרטיים או בשירותים של צדדים שלישיים, ולכן הן חייבות להיות ניידות בין סביבות שונות. לכן, במקום יישומים מונוליתיים, השימוש באפליקציות בקונטיינרים בחלוקה למיקרו-שירותים הופך למודל האידיאלי לסביבות בענן. השימוש בקונטיינרים מפריד את הקבצים הבינאריים שדרושים לאפליקציה שלכם מהתשתית של מערכת ההפעלה המארחת, וכך האפליקציות הופכות לניידות יותר. הקונטיינרים שלנו לא ניתנים לשינוי, כלומר הם לא משתנים לאחר הפריסה. במקום זאת, הם נוצרים מחדש ונפרסים שוב לעתים קרובות.
מכיוון שקונטיינרים לעתים קרובות מופעלים מחדש, מופסקים או מתוזמנים מראש, יש שימוש חוזר ושיתוף תדירים יותר של חומרה ורשתות. מאחר שיש תהליך סטנדרטי ונפוץ ליצירה ולהפצה, תהליך הפיתוח עקבי ואחיד יותר בין הצוותים, אפילו שהצוותים מנהלים באופן עצמאי את פיתוח המיקרו-שירותים שלהם. כתוצאה מכך, ניתן לטפל בשיקולי אבטחה (למשל בדיקות אבטחה, סריקת הקוד לגילוי בעיות וניהול נקודות חולשה) בשלב מוקדם יותר במחזור הפיתוח.
תשתית Service mesh
הבנייה של תשתית משותפת ומאובטחת, שכל המפתחים משתמשים בה, מסירה את הנטל מהמפתחים להכיר וליישם את דרישות האבטחה הנפוצות. הפונקציונליות של האבטחה אמורה לפעול עם אינטגרציה מינימלית מול האפליקציות, או אפילו בלי אינטגרציה בכלל. במקום זאת, היא פועלת כמארג שעוטף ומחבר את כל המיקרו-שירותים. למארג הזה קוראים Service mesh. כך גם אפשר לנהל וליישם אבטחה בנפרד מהפעילויות הרגילות של פיתוח ופריסה.
תשתית Service mesh היא מארג משותף בשכבת התשתית, שעוטף ומחבר את כל המיקרו-שירותים. היא מאפשרת תקשורת מסוג שירות-לשירות עם יכולות בקרה על תעבורת הנתונים, יכולות של החלת כללי מדיניות ואפשרות למעקב מרכזי אחרי קריאות שירות.
מודל אבטחה של אפס אמון
במודל אבטחה מסורתי שנפרס במרכזי נתונים פרטיים, האפליקציות של הארגון מסתמכות על חומת אש כדי להגן על עומסי העבודה מפני איומים חיצוניים שמגיעים מהרשת.
במודל אבטחה של אפס אמון, החלטות לגבי הרשאות לא תלויות בחומות אש. במקום זאת, משתמשים באמצעי בקרה אחרים, כמו Workload Identity, אימות והרשאות, כדי לוודא שהחיבורים הפנימיים והחיצוניים של המיקרו-שירותים מאומתים לפני שהם יכולים לתקשר ביניהם. על ידי הסרת התלות בחומות אש או באמצעי בקרה מבוססי-רשת, אפשר ליישם פילוח ברמת המיקרו-שירותים ללא אמון מהותי בין השירותים. בפילוח ברמת המיקרו-שירותים, תעבורת הנתונים יכולה להיות ברמות אמון שונות עם אמצעי בקרה שונים. ההשוואה היא כבר לא רק בין תעבורת נתונים פנימית לעומת חיצונית.
דרישות אבטחה משותפות המשולבות בסטאקים של שירותים
במודל אבטחה מסורתי, כל אפליקציה אחראית לעמידה בדרישות אבטחה משלה, בנפרד משירותים אחרים. הדרישות האלה כוללות ניהול זהויות, סיום TLS וניהול הרשאות גישה לנתונים. הדבר עלול להוביל להטמעות לא עקביות או לבעיות אבטחה שלא מטופלות, מאחר שצריך לתקן את הבעיות האלה במקומות רבים וכתוצאה מכך קשה יותר להחיל תיקונים.
בארכיטקטורה מבוססת-ענן עושים שימוש חוזר ברכיבים בין שירותים לעתים קרובות יותר. צווארי בקבוק מאפשרים לאכוף מדיניות בעקביות בכל השירותים. ניתן לאכוף כללי מדיניות שונים באמצעות שירותי אבטחה שונים. במקום לדרוש מכל אפליקציה להטמיע שירותי אבטחה מהותיים בנפרד, אפשר לפצל את כללי המדיניות השונים למיקרו-שירותים נפרדים. לדוגמה, אפשר ליצור מדיניות שמבטיחה גישה מורשית לנתוני המשתמשים, ומדיניות אחרת שמוודאת שימוש בסט אלגוריתמים מעודכן להצפנה (cipher suite) של TLS.
תהליכי השקה סטנדרטיים עם השקות תכופות יותר
במודל אבטחה מסורתי יש שירותים משותפים מוגבלים, ובדרך כלל הקוד משוכפל ומשולב בפיתוח המקומי. כששיתוף השירותים מוגבל, קשה יותר לקבוע מה ההשפעה של שינוי ואיך הוא עשוי להשפיע על חלקים שונים באפליקציה. כתוצאה מכך, קשה לתאם השקות והן מתבצעות בתדירות נמוכה. כדי לבצע שינוי, יכול להיות שמפתחים יצטרכו לעדכן כל רכיב ישירות (לדוגמה, לפתוח חיבורי SSH לכל מכונה וירטואלית כדי לעדכן הגדרה מסוימת). באופן כללי, המצב הזה עלול להוביל לאפליקציות שמאריכות ימים.
מנקודת מבט של אבטחה, מכיוון שהקוד משוכפל לעתים קרובות, קשה יותר לבדוק אותו וקיים אתגר גדול יותר לוודא שהתיקונים של נקודות חולשה אכן מיושמים בכל מקום.
בארכיטקטורה מבוססת-ענן, ההשקות הן תדירות וסטנדרטיות. התהליך הזה מאפשר לאבטחה לזוז שמאלה במחזור החיים של פיתוח התוכנה. "לזוז שמאלה" מתייחס לחזרה לאחור כמה שלבים במחזור החיים של פיתוח התוכנה, כמו קידוד, יצירה, בדיקה, תיקוף ופריסה. התזוזה שמאלה מאפשרת אכיפה פשוטה ועקבית יותר של האבטחה, כולל היישום של תיקוני אבטחה באופן סדיר.
ביצוע השינוי ל-BeyondProd
המעבר של Google ל-BeyondProd הצריך שינויים בשני תחומים עיקריים – בתשתית ובתהליך הפיתוח שלנו. טיפלנו בשינויים האלה בו-זמנית, אבל אתם יכולים לטפל בהם בנפרד כדי להגדיר משהו דומה בסביבה שלכם.
שינוי התשתית שלנו
המטרה שלנו היא להפוך את האבטחה לאוטומטית בכל התשתית, כי אנחנו מאמינים שבדומה לשירותים, אבטחה צריכה להתאים לעומס. השירותים צריכים להיות מאובטחים כברירת מחדל ולא מאובטחים רק אחרי שהתקבלה החלטה מפורשת לקבל את הסיכונים. התערבות אנושית ישירה בתשתית שלנו צריכה להיות פעולה חריגה ולא פעולה שגרתית, וכאשר היא מתרחשת היא צריכה להיות מתועדת ומבוקרת. כך נוכל לאמת שירות בהתאם לקוד ולתצורה שלו, ולא על סמך האנשים שביצעו את פריסת השירות.
התחלנו בבניית יסודות חזקים של זהות שירות, אימות והרשאה. מיקרו-שירות משתמש בזהות של שירותכדי לאמת את עצמו בפני שירותים אחרים שפועלים בתשתית. יצירת היסודות של זהויות שירות מהימנות עזרה לנו ליישם יכולות אבטחה ברמה גבוהה יותר שתלויות בתיקוף של זהויות השירות האלה, למשל ניהול הרשאות גישה לשירותים וכרטיסי הקשר של משתמשי קצה. כדי להקל על המעבר לשירותים חדשים ולשירותים קיימים, ALTS שימשה בהתחלה כספרייה עם עזרה של דימון (daemon) יחיד. הדימון פעל אצל המארח שאליו התקשרו כל השירותים, ועם הזמן הדימון התפתח לספרייה שמשתמשת בפרטי כניסה של שירותים. ספריית ALTS שולבה באופן חלק עם ספריית RPC המרכזית. בעזרת השילוב הזה, אפשר לבצע בקלות הטמעה נרחבת בלי להעמיס באופן משמעותי על צוותי הפיתוח. היה צורך לבצע השקה של ALTS, לפני ההשקה של ניהול הרשאות גישה לשירותים וכרטיסי הקשר של משתמשי קצה.
שינוי תהליכי הפיתוח שלנו
ל-Google היה מאוד חשוב ליצור תהליך איתן של בדיקת קודים וגרסאות build כדי לוודא את תקינות השירותים. לשם כך, יצרנו תהליך build מרכזי שבו ניתן להתחיל לאכוף דרישות כמו בדיקת הקוד על ידי שני אנשים ובדיקות אוטומטיות בשלב ה-build והפריסה (לפרטים נוספים, ראו Binary Authorization ל-Borg).
לאחר שהיסודות הונחו, התחלנו לטפל בצורך להריץ קוד חיצוני לא מהימן בסביבות שלנו. כדי להשיג את המטרה הזו התחלנו לבצע הרצה בארגז חול (sandboxing) – בהתחלה דרך ptrace, ולאחר מכן באמצעות gVisor. בדומה לכך, פריסות כחול-ירוק הביאו תועלת משמעותית מבחינת אבטחה (למשל תיקון) וגם אמינות.
מהר מאוד גילינו שהתהליך קל יותר אם השירות מתחיל לתעד הפרות של המדיניות במקום לחסום אותן. יש לגישה הזו יתרון כפול:
- בעלי השירות יכלו לבחון את השינוי ולהעריך את ההשפעה (אם הייתה כזו) של מעבר לסביבה מבוססת-ענן בשירות שלהם.
- היא אפשרה לנו לתקן באגים ולזהות פונקציונליות נוספת שאולי נצטרך לספק לצוותי השירותים.
לדוגמה, כששירות מסוים מועבר ל-BAB, בעלי השירות מפעילים מצב 'ביקורת בלבד'. כך הם יכולים לזהות קוד או תהליכי עבודה שאינם עומדים בדרישות שלהם. אחרי הטיפול בבעיות שסומנו במצב 'ביקורת בלבד', בעלי השירות עוברים למצב אכיפה. ב-gVisor התהליך נעשה תחילה באמצעות הרצה בארגז חול של עומסי עבודה, אפילו אם היו פערי תאימות ביכולות ההרצה בארגז החול, ולאחר מכן על ידי טיפול בפערים האלה באופן שיטתי כדי לשפר את ההרצה בארגז החול.
המאמרים הבאים
- סקירה כללית על תכנון האבטחה בתשתית של Google
- מידע נוסף על אופן ההגנה על הפריסות שלנו זמין במאמר Binary Authorization ל-Borg.
- מידע נוסף על האופן שבו אנחנו מגינים על התשתית שלנו מופיע בספר של O'Reilly, Building secure and reliable systems.
- במאמר בנושא Supply chain Levels for Software Artifacts (SLSA) מוסבר איך להשתמש בצינור עיבוד נתונים מאובטח של CI/CD.
- למידע כללי על Google Cloud אבטחה, כולל שיטות מומלצות לאבטחה, קראו את הקטע בנושא אבטחה באתר של Google Cloud .
- למידע על Google Cloud תאימות ועל אישורי תאימות, תוכלו לקרוא את הקטע בנושא תאימות באתר Google Cloud .