BeyondProd: גישה חדשה לאבטחה מבוססת-ענן

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
יש מספר סקירות מפורטות שנכתבו על ידי Google וaעוסקות בפרויקטים שפותחו באופן פנימי במטרה לשפר את האבטחה. גישת BeyondProd חוזרת בכוונה לקונספט של BeyondCorp – בדיוק כמו שמודל אבטחה היקפי כבר לא מתאים למשתמשי קצה, הוא גם לא מתאים למיקרו-שירותים (microservices). לכן המאמר המקורי של BeyondCorp עודכן באופן הבא: "השערות המפתח של המודל לא תקפות יותר: המתחם הוא כבר לא רק המיקום הפיזי של הארגון [מרכז הנתונים], ומה שנמצא בתוך המתחם כבר לא נחשב למקום מוגן ובטוח לאירוח מכשירי מחשוב אישיים ואפליקציות ארגוניות [מיקרו שירותים]."

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

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

מילון מונחים

במסמך הזה מופיעות ההגדרות הבאות:

  • מיקרו-שירות (microservice) מפריד את המשימות האישיות שאפליקציה צריכה לבצע, לשירותים נפרדים. אפשר לפתח ולנהל את השירותים בנפרד, ולכל אחד מהם יהיו ממשק API, השקה, התאמה לעומס (scaling) וניהול מכסות משלו. בארכיטקטורה מודרנית יותר ניתן להפעיל אפליקציה (למשל אתר) כאוסף של מיקרו-שירותים, במקום כשירות מונוליתי בודד. המיקרו-שירותים הם עצמאיים, מודולריים, דינמיים וזמניים. הם ניתנים להפצה אצל הרבה מארחים, אשכולות ואפילו עננים.

  • עומס עבודה (workload) הוא משימה ייחודית שאפליקציה משלימה. בארכיטקטורת מיקרו-שירותים, עומס עבודה עשוי להיות מיקרו-שירות אחד או יותר.

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

  • מיקרו-שירות משתמש בזהות שירות כדי לאמת את עצמו בפני שירותים אחרים שפועלים בתשתית.

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

סיכום ברמת מנהל מערכות המידע

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

  • התשתית של Google תוכננה מראש עם מחשבה על נושא האבטחה, ולא כתוצר לוואי מאוחר יותר. ההנחה של התשתית שלנו היא שאין אמון בין השירותים שנמצאים בה.

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

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

למה בחרנו לעשות זאת?

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

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

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

אבטחה מבוססת-ענן ב-Google

מיקרו-שירותים (microservices) בקונטיינרים

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

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

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

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

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

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

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

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

פיתוח מבוסס-ענן ופיתוח אפליקציות

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

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

השלכות על האבטחה

דיברנו הרבה על האופן שבו מודל של חלל פנימי לא מהימן עם משתמשים ב-BeyondCorp יכול לחול גם על מיקרו-שירותים ב-BeyondProd. אבל איך נראה השינוי? בטבלה 1 מוצגת השוואה בין היבטים של אבטחת תשתית מסורתית להיבטים המקבילים בארכיטקטורה מבוססת-ענן. בטבלה גם מפורט מה נדרש כדי לעבור מתחום אבטחה אחד לשני. אחרי הטבלה מוצגים פרטים נוספים לגבי כל שורה בה.

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

טבלה 1: דרישות משתמעות לגבי אבטחה לצורך מעבר לארכיטקטורה מבוססת-ענן

מעבר מאבטחה היקפית למודל אבטחה של אפס אמון

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

מעבר מכתובות IP קבועות וחומרה אל משאבים משותפים גדולים יותר

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

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

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

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

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

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

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

מעבר מעומסי עבודה שמבודדים באמצעות מכונות פיזיות או hypervisors לעומסי עבודה מסודרים בקונטיינרים (bin-packed) שפועלים באותה מכונה ומצריכים בידוד חזק יותר

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

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

עקרונות האבטחה

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

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

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

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

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

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

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

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

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

שירותי האבטחה הפנימיים של Google

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

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

  • אבטחת שכבת התעבורה של אפליקציה (ALTS): נמצאת בשימוש כדי לבצע אימות של קריאה לשירות מרוחק (RPC), לוודא את תקינותה ולהצפין אותה. ‏ALTS היא מערכת להצפנת תעבורה ולאימות הדדי עבור שירותים בתשתית של Google. בדרך כלל זהויות קשורות לשירותים ולא למארח או לשם של שרת ספציפי. כך מתאפשר לבצע בצורה חלקה שכפול של מיקרו-שירותים, איזון עומסים ותזמון מחדש בין מארחים.

  • Binary Authorization for Borg ו-Host Integrity נמצאים בשימוש עבור מיקרו-שירותים ואימות התקינות של מכונות, בהתאמה:

    • Binary Authorization for Borg‏ (BAB): בדיקת אכיפה בזמן פריסה כדי לוודא שהקוד עומד בדרישות האבטחה הפנימיות, לפני הפריסה שלו. בדיקות BAB כוללות שינויים שנבדקים על ידי מהנדס נוסף, קוד שנשלח למאגר קודי המקור שלנו ובינאריים שנוצרים באופן מאומת בתשתית ייעודית. בתשתית שלנו, BAB מגביל את הפריסה של מיקרו-שירותים לא מורשים.
    • Host Integrity ‏(HINT): אימות התקינות של תוכנת המערכת המארחת באמצעות תהליך הפעלה מאובטחת. האימות מגובה על ידי חומרה מאובטחת של מיקרו-בקרים, ככל שהאפשרות הזו נתמכת. בדיקות HINT כוללות אימות של חתימות דיגיטליות ב-BIOS, ב-BMC, בתוכנת האתחול ובליבה של מערכת ההפעלה.
  • מדיניות גישה לשירותים וכרטיסי הקשר של משתמשי קצה מאפשרים את הגבלת הגישה לנתונים:

    • מדיניות גישה לשירותים: מגבילה את אופן הגישה לנתונים בין שירותים. כאשר קריאת RPC נשלחת משירות אחד לאחר, מדיניות הגישה לשירותים מגדירה את מדיניות האימות, ההרשאה והביקורת שנחוצות כדי לגשת לנתונים של השירות המקבל. המדיניות הזו מגבילה את הגישה לנתונים, מעניקה גישה ברמה המינימלית הנדרשת ומציינת איך אפשר לבצע בקרה על רמת הגישה. בתשתית של Google, מדיניות הגישה לשירותים מגבילה את הגישה של מיקרו-שירות לנתונים של מיקרו-שירות אחר, ומאפשרת ניתוחים גלובליים של בקרות גישה.
    • כרטיסי הקשר של משתמשי קצה (EUC)‏: כרטיסים המונפקים על ידי שירות לאימות של משתמשי קצה, ומספקים שירותים באמצעות זהות המשתמש שנפרדת מזהות השירות. אלה פרטי כניסה שמונפקים באופן מרכזי, שתקינותם מוגנת ושניתן להעבירם, והם מאמתים את זהות משתמש הקצה ששלח בקשה לשירות. הדבר מפחית את הצורך באמון בין שירותים שונים, מכיוון שלעיתים קרובות זהות בין רשתות שכנות באמצעות ALTS לא מספיקה כדי להעניק גישה, והחלטות כאלה לגבי אימות לרוב מבוססות על הזהות של משתמש הקצה.
  • כלים של Borg לפריסות כחול-ירוק3: כלי שאחראי להעברה של עומסי עבודה פעילים בזמן הביצוע של משימות תחזוקה. פריסת משימה חדשה של Borg מתבצעת במקביל למשימת Borg קיימת, ומאזן עומסים מעביר בהדרגה את תעבורת הנתונים ממשימה אחת לשנייה. כך אפשר לעדכן מיקרו-שירות ללא זמן השבתה, בלי לשבש את פעילות המשתמשים. הכלי הזה משמש להחלת שדרוגים של שירותים כשמוסיפים תכונות חדשות, וגם להחלת עדכוני אבטחה מהותיים ללא זמן השבתה (לדוגמה, פרצות Heartbleed ו-Spectre/Meltdown). כדי לטפל בשינויים שמשפיעים על תשתית Google Cloud, אנחנו משתמשים במיגרציה פעילה כדי לוודא שעומסי העבודה של מכונות וירטואליות לא מושפעים מכך.

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

טבלה 2 מחברת בין העקרונות המתוארים בקטע שדן על עקרונות האבטחה, לבין הכלים המתאימים ליישום העקרונות ב-Google.

עקרון האבטחה כלי/שירות האבטחה הפנימי של Google
הגנה על הרשת בקצה ממשק קצה של Google‏ (GFE) – כדי לנהל סיום TLS ומדיניות תעבורת נתונים נכנסת
חוסר אמון הדדי מהותי בין השירותים אבטחת שכבת התעבורה של אפליקציה (ALTS) – כדי לבצע אימות של קריאת RPC, לוודא את תקינותה, להצפין אותה וליצור לה זהויות שירות
מכונות מהימנות שמריצות קוד ממקור ידוע Binary Authorization for Borg‏ (BAB) – כדי לאמת את מקור הקוד

Host Integrity‏ (HINT) – כדי לוודא את תקינות המכונה

צווארי בקבוק כדי לבצע אכיפה עקבית של המדיניות בכל השירותים מדיניות גישה לשירותים – כדי להגביל את אופן הגישה לנתונים בין שירותים

כרטיסי הקשר של משתמשי קצה (EUC) – כדי לאמת את הזהות של מגיש הבקשה המקורי

השקה פשוטה, אוטומטית וסטנדרטית של שינויים כלים של Borg – כדי לבצע פריסות כחול-ירוק (blue-green deployment)
בידוד בין עומסי עבודה שחולקים מערכת הפעלה gVisor – כדי לבודד עומסי עבודה

טבלה 2: עקרונות וכלי אבטחה להטמעת אבטחה מבוססת-ענן ב-Google

איך הכל משתלב יחד

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

גישה לנתוני משתמשים

כפי שמוצג באיור 1, כשממשק GFE מקבל בקשה של משתמש (שלב 1), הוא מסיים את חיבור ה-TLS ומעביר את הבקשה לחזית של השירות המתאים באמצעות ALTS‏4 (שלב 2). חזית האפליקציה מבצעת אימות לבקשה של המשתמש דרך שירות מרכזי לאימות של משתמש קצה (EUA), ואם האימות עבר בהצלחה מתקבל כרטיס הקשר של משתמש קצה (EUC) שהוא מוצפן ובעל אורך חיים קצר (שלב 3).

תרשים

איור 1: אמצעי האבטחה לארכיטקטורה מבוססת-הענן של Google – גישה לנתוני משתמש

לאחר מכן, חזית האפליקציה מבצעת קריאת RPC באמצעות ALTS לשירות אחסון לקצה העורפי, ומתבצעת העברה של כרטיס ה-EUC בבקשה לקצה העורפי (שלב 4). השירות לקצה העורפי משתמש במדיניות גישה לשירותים כדי לוודא את הדברים הבאים:

  1. לזהות ה-ALTS של השירות בחזית יש הרשאה לשלוח בקשות לשירות לקצה העורפי ולהציג כרטיס EUC.
  2. הזהות של החזית מוגנת על ידי Binary Authorization for Borg‏ (BAB).
  3. כרטיס ה-EUC תקף.

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

לכל מכונה יש פרטי כניסה של ALTS שמוקצים באמצעות מערכת HINT, ואפשר לפענח אותם רק אם מערכת HINT אישרה שהפעלת המערכת בוצעה בהצלחה. רוב שירותי Google פועלים כמיקרו-שירותים בנוסף ל-Borg, ולכל מיקרו-שירות יש זהות ALTS משלו. Borgmaster‏5 מעביר לעומסי עבודה את פרטי הכניסה ל-ALTS של המיקרו-שירותים בהתאם לזהות שלהם, כפי שמתואר באיור 1. פרטי הכניסה של ALTS ברמת המכונה יוצרים ערוץ מאובטח לצורך הקצאת פרטי כניסה למיקרו-שירותים, כך שרק מכונות שעברו הפעלה מאומתת של HINT יכולים בפועל לארח עומסי עבודה של מיקרו-שירותים.

ביצוע שינוי בקוד

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

תרשים

איור 2: אמצעי האבטחה לארכיטקטורה מבוססת-הענן של Google – ביצוע שינוי בקוד

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

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

הפעלת BeyondProd

ללכת עד הסוף

המעבר לתשתית מאובטחת מבוססת-ענן מאפשר ל-Google להציע מאפייני אבטחה חזקים מאוד לעומסי העבודה הפנימיים והחיצוניים (Google Cloud).

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

מעבר למודל מבוסס-ענן

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

שינוי התשתית שלנו

התחלנו בבניית יסודות חזקים של זהות שירות, אימות והרשאה. יצירת היסודות של זהויות שירות מהימנות עזרה לנו ליישם יכולות אבטחה ברמה גבוהה יותר שתלויות בתיקוף של זהויות השירות האלה, למשל מדיניות גישה לשירותים וכרטיסי EUC. כדי להקל על המעבר לשירותים חדשים ולשירותים קיימים, ALTS שימשה בהתחלה כספריה עם עזרה של דימון (daemon) יחיד. הדימון פעל אצל המארח שאליו התקשרו כל השירותים, ועם הזמן הדימון התפתח לספרייה שמשתמשת בפרטי כניסה של שירותים. בעזרת השילוב החלק של ספריית ALTS עם ספריית RPC המרכזית, אפשר בקלות לבצע הטמעה נרחבת בלי להעמיס באופן משמעותי על צוותי הפיתוח. היה צורך לבצע השקה של ALTS לפני ביצוע ההשקה של מדיניות גישה לשירותים וכרטיסי EUC.

שינוי תהליכי הפיתוח שלנו

ל-Google היה חשוב ליצור תהליך איתן של בדיקת קודים וגרסאות build. כך יכולנו להבטיח את תקינות השירותים הפועלים, ולוודא שהזהויות שבהן נעשה שימוש ב-ALTS הן משמעותיות. יצרנו תהליך build מרכזי שבו ניתן להתחיל בביצוע אכיפה של דרישות, כמו בדיקת קודים על ידי שני אנשים ובדיקה אוטומטית בזמני build ופריסות (פרטים נוספים על הפריסה זמינים בסקירה המפורטת על Binary Authorization for Borg).

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

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

היתרונות של ביצוע השינוי

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

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

הערות

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

2 "לזוז שמאלה" מתייחס לחזרה לאחור כמה שלבים במחזור החיים של פיתוח התוכנה, כמו קידוד, יצירה, בדיקה, תיקוף ופריסה. בדרך כלל תרשימים של מחזורי חיים מאוירים משמאל לימין, לכן שמאל מתייחס לשלב מוקדם יותר.

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

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

5 הבקר המרכזי של Borg נקרא Borgmaster, והוא מנהל את תזמון המשימות ויוצר קשר עם משימות שכבר רצות כדי לברר את הסטטוס שלהן.