התוכן הזה עודכן לאחרונה ביוני 2024, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
Google מפעילה תשתית מחשוב גלובלית, מבוזרת ורב-דיירית כדי לספק מוצרים ושירותים למיליארדי אנשים ברחבי העולם. התשתית הזו צריכה לאזן בין סדרי העדיפויות המתחרים של אבטחה, אמינות, חוסן (resilience), יעילות, מהירות פיתוח, יכולת ניפוי באגים ועוד.
במסמך הזה מתוארים כמה מהמנגנונים שבהם אנחנו משתמשים כדי לשמור על רמת אבטחה מובילה בתעשייה בשירותים שפועלים בסביבת הייצור של Google. השירותים האלה מכסים את כל הספקטרום של רגישות האבטחה, החל מניסויי פיתוח שאין להם גישה למידע אישי רגיש ועד לתשתית זהויות קריטית. השירותים האלה מבצעים משימות כמו עיבוד נתוני משתמשים, ניהול השקות של תוכנות והקצאת הרשאות וניהול מחזור החיים של מכונות פיזיות פרטניות.
במסמך הזה מתוארים אמצעי האבטחה שעוזרים להגן על שלוש שכבות המפתח הבאות בתשתית שלנו:
- שירותי Production, שכוללים את השירותים הקריטיים ביותר לאבטחה (נקראים גם שירותים בסיסיים)
- מכונות ייצור
- עומסי עבודה בסביבת ייצור
אנחנו מיישמים את אמצעי הבקרה האלה כדי שעובדי Google יוכלו לגשת לשירותים, למכונות ולעומסי עבודה רק למטרות עסקיות לגיטימיות (למשל, גישה לצורך תחזוקה), וכדי להגן מפני סיכונים פנימיים ופריצה לחשבונות של עובדים. אמצעי הבקרה האלה מספקים הגנה נוספת לעומק, בנוסף לאמצעי הבקרה הקיימים לאבטחת התשתית, שעוזרים למנוע פגיעה באבטחת החשבון.
שיפור שוטף
אמצעי הבקרה שמתוארים במסמך הזה נמצאים בשימוש בסביבת הייצור של Google. שירותים רבים, כולל שירותים בסיסיים, משתמשים ברמות הבקרה העדכניות ביותר שאנחנו מציעים. עם זאת, בגלל ההיקף והמורכבות של התשתית של Google, לשירותי ייצור ספציפיים יש לעיתים קרובות דרישות ייחודיות, ויכול להיות שיידרש זמן נוסף כדי ליישם את ההמלצות העדכניות. ב-Google, אנחנו פועלים לשיפור מתמיד של אמצעי האבטחה, ולכן צוותי Site Reliability Engineering (SRE) והאבטחה שלנו מתאימים כל הזמן את אמצעי הבקרה כדי להתמודד עם איומים משתנים.
הגנה על שירותי הפקה
Google עוזרת להגן על התקינות של שירותי הייצור, כך שהצוות של Google יכול לגשת לשירותים רק למטרה עסקית לגיטימית, כמו תחזוקה. יש שתי דרכים עיקריות לקבל גישה לשירותים שפועלים בסביבת הייצור: דרך גישת אדמין ודרך שרשרת אספקת התוכנה.
ברשימה הבאה מתוארים אמצעי הבקרה שעוזרים להגן על כל נתיב גישה.
בקרת גישה אדמיניסטרטיבית: שירותי Production צריכים תחזוקה שוטפת (לדוגמה, השקות של קבצים בינאריים או של הגדרות). ב-Google, המטרה שלנו היא שפעולות כאלה יתבצעו באמצעות אוטומציה, שרתי proxy מאובטחים או גישת חירום שנבדקה, בהתאם לעקרונות של Zero Touch Prod. חבילת אמצעי הבקרה שמסירה גישה אנושית לנכסי ייצור נקראת No Persons (NoPe). השימוש ב-NoPe מאפשר ל-Google לפרוס אמצעי בקרת גישה שמבוססים על הרגישות של שירות ייצור ועל המוכנות שלו להשגת אבטחה חזקה יותר באמצעות שיפור מתמיד.
לדוגמה, Google לא מאפשרת גישה חד-צדדית לשירותים בסיסיים – גם גישת חירום דורשת אישור מעובדים אחרים של Google. גישה היא חד-צדדית אם מישהו יכול לבצע את הגישה ללא אישור מאדם מורשה אחר.
אמצעי בקרה בשרשרת אספקת התוכנה: רוב עומסי העבודה בייצור ב-Google, כולל שירותים בסיסיים, מריצים קבצים בינאריים ותצורות של משימות שנבנים בצורה ניתנת לאימות מקוד שעבר ביקורת עמיתים וממוקם במקור מהימן. אנחנו אוכפים את התהליך הזה באמצעות Binary Authorization for Borg (BAB).
בתרשים הבא מוצגים אמצעי הבקרה שעוזרים להגן על שירות בייצור.
כשאנחנו מיישמים את הרמות הגבוהות ביותר של NoPe ו-BAB, אנחנו עוזרים לוודא שלאיש מהצוות אין גישה חד-צדדית לשירותים בסיסיים, גם במקרי חירום, ושלכל גישה עם הרשאות מיוחדות שהוא מקבל יש היקף ומשך מוגדרים היטב. גישה עם הרשאות מיוחדות היא רמת גישה גבוהה שניתנת לאנשי צוות כדי לנהל שירותי ייצור קריטיים בנסיבות ייחודיות שלא ניתן לטפל בהן באמצעות אוטומציה. אנחנו עושים חריג לכלל הזה כדי לוודא של-Google יש דרך לצאת ממצבים של נעילה.
שירותי ייצור רבים אחרים, כולל מוצרים כמו Filestore או Cloud SQL ומוצרי תשתית פנימיים כמו Borg ו-Spanner, מוגדרים לשימוש ברמות הגבוהות ביותר של NoPe ו-BAB, ואנחנו פועלים באופן רציף כדי להקל על בעלי שירותי ייצור לאמץ את NoPe ו-BAB לאורך זמן.
אמצעי בקרה לגישת אדמין
ב-Borg, חברים בתפקיד הפקה יכולים לקרוא, לכתוב או למחוק את הנתונים שבבעלות תפקיד ההפקה, והם יכולים להריץ קוד באמצעות הסמכות של התפקיד. תפקיד ייצור הוא זהות שיכולה להריץ עומסי עבודה בסביבת הייצור של Google.
חברות קבועה בתפקידי הפקה כרוכה בסיכון לתוצאות לא מכוונות בהפקה, ובסיכון לניצול לרעה של ההרשאות האלה. עם זאת, המשימה של SRE היא לאפשר לצוותים לתחזק את השירותים שהם אחראים להם, ולכן הסרת גישה מלאה לא יכולה להיות אסטרטגיה מעשית.
חבילת NoPe מאפשרת להגדיר גישה שמאזנת בין הדרישות הסותרות של העצמת הצוותים ושמירה על בטיחות מערכות הייצור. ב-NoPe, אנשי Google נתקלים במגבלות על ההרשאות של החשבונות שלהם כשהם מנסים לגשת לשירותי ייצור. NoPe מאפשרת את האילוצים הבאים:
- בקשות גישה דורשות אישור והצדקה: אמצעי בקרה שנקרא הרשאה על ידי גורמים מרובים (MPA) עוזר לוודא שאנשי Google לא יוכלו לקבל גישה לשירותי ייצור בלי הצדקה עסקית ובלי אישור מאדם אחר שמוסמך לאמת את בקשת הגישה.
- אין גישה ישירה לתפקידים בשירותי הייצור: אנשי הצוות יכולים לגשת לשירותי הייצור רק דרך פרוקסי מאובטח ל-NoPe. שרתי Proxy בטוחים מתוכננים כך שניתן להריץ רק קבוצה מוגדרת היטב של פקודות. פקודות שארגוני האבטחה ו-SRE של Google מחשיבים כמסוכנות (לדוגמה, השבתת שירות או גישה לנתונים ומחיקתם) דורשות גם אימות רב-שלבי.
- חברות בתפקיד ייצור לא קבועה: אמצעי בקרה שנקרא גישה על פי דרישה (AoD) מחייב את העובדים לבקש חברות זמנית, במקום לאפשר לחשבונות של העובדים גישה תמידית. אמצעי הבקרה הזה עוזר לוודא שהרשאות מורחבות ניתנות רק באופן זמני ומסיבות ספציפיות.
- מעקב אחרי בקשות גישה של עובדים לשירותי ייצור: Google דורשת ביקורת תקופתית של דפוסי גישה לתפקידי ייצור שמפעילים שירות ייצור. מטרת הביקורת היא לבטל את הצורך בבקשות כאלה בעתיד, באמצעות שיפור מתמשך של ממשקי ה-API לניהול. הגישה לשירותי ייצור צריכה להיות שמורה רק למצבי תגובה לשעת חירום. בשירותים בסיסיים, מספר המקרים שבהם ניתנת גישה הוא כל כך נמוך, שצוות האבטחה מבצע ביקורת על כל גישה שניתנת כדי לוודא שהיא תקפה.
בקטעים הבאים מוסבר כל אמצעי בקרה בפירוט.
קבלת אישור ממספר משתמשים ל-NoPe
כדי לקבל גישה, נדרש אישור של נציג מוסמך אחר של Google.
בנוסף, כדי לקבל גישה לשירותים רגישים מספיק, נדרש מהצוות לספק הצדקה עסקית שמתייחסת למקרה חירום מתמשך בייצור בכל בקשה.
שני התנאים האלה מונעים ניצול לרעה של הגישה.
שרתי proxy בטוחים ל-NoPe
שרתי proxy בטוחים הם כלים שחושפים קבוצה מוגדרת מראש של פקודות ששרת ה-proxy הבטוח יכול להריץ בשם המתקשר. פרוקסי בטוחים מיישמים מדיניות הרשאה פרטנית שמבוססת על כללים, כדי להגביל את הגישה לשירותי ייצור. לדוגמה, כללי המדיניות האלה יכולים לדרוש אישור מאדם מורשה אחר כדי להפעיל פקודות שעלולות להשפיע לרעה על האבטחה או על המהימנות (לדוגמה, פקודות שמוחקות קבצים). בנוסף, מדיניות יכולה לאפשר ביצוע של פקודות בטוחות מסוימות (לדוגמה, פקודות שמציגות את ניצול המשאבים) ללא צורך באישור. הגמישות הזו חיונית לצמצום הטרחה התפעולית.
במקרים של שימוש לרעה בגישה, החשבונות עדיין מוגבלים לפעולות שה-proxy הבטוח מאפשר. החשבון יכול לבצע רק פקודות בטוחות באופן חד-צדדי, בעוד שפעולות עם הרשאות מיוחדות דורשות אישור מאדם מורשה אחר. כל הפעולות משאירות שביל ביקורת ברור.
מידע נוסף על פרוקסי בטוח מופיע במצגת SREcon בנושא zero touch prod. Zero touch prod הוא אוסף של עקרונות וכלים שאוכפים שכל שינוי בסביבת הייצור יתבצע על ידי פעולות אוטומטיות (ללא מעורבות של אנשים), יעבור אימות מראש על ידי תוכנה או יתבצע באמצעות מנגנון מבוקר שיכול לשמש במקרה חירום.
גישה על פי דרישה
גישה על פי דרישה (AoD) מאפשרת ל-Google לצמצם את ההרשאות של העובדים על ידי החלפת חברות קבועה בחברות שעומדת בדרישות.
לחברים שעומדים בדרישות לתפקיד אין גישה להרשאות שלו. במקום זאת, אם חבר בתפקיד שעומד בדרישות צריך גישה, הוא יכול לבקש חברות זמנית, שנקראת מתן גישה לפי דרישה (AoD). אם הבקשה תאושר על ידי אדם מורשה אחר, המבקש יקבל הרשאת AoD ויהפוך לחבר בתפקיד למשך זמן מוגבל, בדרך כלל פחות מיום.
מודל החברות שעומד בדרישות מאפשר לאנשי הצוות לבקש רק את קבוצת המשנה של הגישה שהם צריכים למשך הזמן שהם צריכים. מבחינה רעיונית, אפשר לחשוב על AoD כעל sudoייצור מוגבל בזמן, בדומה לפקודה sudo -u ב-Unix, שמאפשרת להריץ פקודות מסוימות עם הרשאות גבוהות שמשויכות למשתמש ספציפי. עם זאת, בניגוד ל-Unix sudo, כדי לקבל הרשאת AoD נדרשת הצדקה עסקית ו-MPA, והיא משאירה עקבות ביומן הביקורת. גם הרשאות AoD מוגבלות בזמן.
הגנה על הרשאות רגישות באמצעות מינויים שעומדים בדרישות מאפשרת שגם במקרים לא סבירים של שימוש לרעה בגישה, חשבונות יוכלו לגשת להרשאות האלה רק אם יש להם הרשאה פעילה. השימוש בפרוקסי בטוח מייתר במידה רבה את הצורך בהענקת הרשאות כאלה.
מעקב אחרי בקשות גישה
אף על פי שבחלקים רבים של ההפקה ב-Google נעשה שימוש ב-NoPe כשיטה לצמצום הגישה, הענקת הרשאות AoD נדירה ביותר בתפקידים הרגישים ביותר בהפקה, והיא שמורה רק למקרים של תגובה למצבי חירום. בנוסף, כל אירוע מפעיל ביקורת ידנית בדיעבד. מטרת הבדיקה היא להפחית את התדירות של הענקת הרשאות AoD בעתיד (לדוגמה, באמצעות האירועים האלה כדי לעודד שיפורים בממשקי API אדמיניסטרטיביים).
Google עוקבת ברציפות אחרי מענקי AoD ופעולות שבוצעו בזמן שהמענקים האלה היו בתוקף, בכל החברה. אנחנו משתמשים בנתוני המעקב בזמן אמת כדי לזהות פשרות פוטנציאליות ולזהות אזורים שבהם אפשר לצמצם עוד יותר את הגישה. אם מתרחש אירוע, נתיב הביקורת תומך בתגובה מהירה.
Binary Authorization for Borg
כמו ש-NoPe עוזר להגן על נתיבי גישה עם הרשאות, כך Binary Authorization for Borg (BAB) עוזר להגן על שרשרת האספקה של התוכנות ב-Google. בדיקת BAB עוזרת לוודא שהתוכנות בסביבת הייצור והגדרות המשימות ייבדקו ויאושרו לפני הפריסה, במיוחד במקרים שבהם יש להן גישה למידע רגיש. המושגים המרכזיים של BAB, שפותחו במקור עבור תשתית הייצור של Google, כלולים עכשיו במפרט פתוח שנקרא Supply Chain Levels for Software Artifacts (SLSA).
BAB עוזר לוודא שאנשי הצוות לא יכולים לשנות קוד מקור, להריץ קבצים בינאריים או להגדיר משימות בלי ביקורת עמיתים, ושהגדרות של תוכנה או ארטיפקט בינארי נוצרות באופן מאומת מקוד מקור שנבדק ואושר על ידי עמיתים.
מידע נוסף זמין במאמר בנושא Binary Authorization ל-Borg.
הגנה על מכונות ייצור
בנוסף לחיזוק נתיבי גישה עם הרשאות ולשמירה על התקינות של שרשרת האספקה של התוכנה, Google מגנה על המכונות שבהן פועלים שירותי הייצור. באופן ספציפי, אנחנו מיישמים את הפעולות הבאות:
אמצעי בקרה לגישה למעטפת: לרוב אנשי Google אין גישה למעטפת (למשל דרך SSH) למכונות ייצור או לעומסי עבודה שפועלים ב-Borg, מערכת ניהול האשכולות של Google. במקום זאת, אנשים פרטיים צריכים להשתמש בשרתי proxy בטוחים שבהם אדם מורשה אחר צריך לבדוק ולאשר כל פקודה לפני שהיא מופעלת.
רק כמה צוותים שעובדים על תשתית ברמה נמוכה שומרים על גישת מעטפת לא חד-צדדית, כדי שיוכלו לנפות באגים בבעיות המורכבות ביותר שבהן לא מעשי להשתמש בשרתי proxy בטוחים. גישה היא לא חד-צדדית אם היא דורשת אישור מאחד או יותר מאנשי צוות מורשים נוספים. Google עושה חריג אחד שבו מותרת גישה חד-צדדית למעטפת: כדי לוודא של-Google יש דרך לצאת ממצבים של נעילה.
אמצעי בקרה לגישה פיזית: כדי שהמכונות יפעלו בצורה תקינה, צריך לבצע בהן תחזוקה פיזית באופן קבוע. כדי להבטיח שטכנאי מרכזי נתונים יוכלו לגשת למכונות פיזיות רק אם יש להם סיבה עסקית תקפה, Google משתמשת באמצעי בקרה מהפיזי ללוגי.
אמצעי בקרה של קושחה ותוכנת מערכת: Google מיישמת זרימת אבטחה של הפעלה מדודה שמבוססת על Root of Trust בחומרה. Root of Trust בחומרה עוזר לוודא את התקינות של קושחת האתחול ותוכנת המערכת של כל מכונה.
בתרשים הבא מוצגים אמצעי הבקרה שעוזרים להגן על מכונה במרכז נתונים.
אמצעי בקרה לגישת Shell
SSH הוא כלי ניהול בקוד פתוח שמאפשר גישה רחבה לשרתים מבוססי-Linux. בלי אמצעי בקרה על גישת SSH, חשבונות עם פרטי הכניסה הנכונים יכולים לקבל מעטפת שמאפשרת להם להריץ קוד שרירותי באופן שקשה לבדוק.
עם גישה למעטפת של שירות ייצור, החשבון יכול, למשל, לשנות את ההתנהגות של משימה שפועלת, להעביר פרטי כניסה או להשתמש בפרטי כניסה כדי להשיג דריסת רגל קבועה בסביבה.
כדי לצמצם את הסיכון הזה, אנחנו משתמשים בקבוצת אמצעי הבקרה הבאה שמחליפה את גישת ה-SSH למכונות ייצור בשיטות חלופיות ובטוחות:
- ממשקי API מצומצמים: לצוותים עם תהליכי עבודה מוגדרים היטב שבעבר דרשו SSH, אנחנו מחליפים את ה-SSH בממשקי API מצומצמים וניתנים לביקורת.
- שרתי proxy בטוחים ל-SSH: לצוותים שזקוקים לגישה גמישה יותר, שרתי proxy בטוחים מאפשרים לאשר ולבדוק פקודות באופן פרטני.
- MPA: כשמהנדסי SRE צריכים גישת SSH לשעת חירום למכונה, Google דורשת נימוק עסקי ואישור גישה מאדם מורשה. מתבצע רישום של תמלילים מלאים של סשנים של מעטפת.
- תרחישי נעילה: היוצא מן הכלל היחיד שבו מותרת גישת SSH חד-צדדית. מתבצע רישום של תמלילים מלאים של סשנים של מעטפת.
האמצעים האלה מאזנים בין הצורך בגישה לגיטימית למעטפת לבין הסיכון שקשור לגישה רחבה מדי למעטפת.
רקע: SSH ב-Google
בעבר, Google השתמשה ב-SSH כדי לנהל את המכונות שלה. הפיתוח של Borg אפשר לרוב העובדים ב-Google להפסיק לדרוש גישה ישירה למכונות Linux שמריצות את הקבצים הבינאריים שלהם, אבל גישת מעטפת נשארה מסיבות שונות:
- לפעמים אנשי הצוות צריכים גישה ישירה למכונה למטרות ניפוי באגים.
- גישת SSH היא כלי חשוב להוראה, שמאפשר להבין את שכבות ההפשטה השונות.
- בתרחישי התאוששות מאסון בלתי צפויים, יכול להיות שכלי ברמה גבוהה יותר לא יהיה זמין.
כדי לאזן בין הסיבות האלה לבין סיכון האבטחה שהן יוצרות, Google הציבה לעצמה סדרה של אבני דרך שמטרתן להפחית בהדרגה את הסיכון שקשור ל-SSH ואז את השימוש בו.
אבן דרך: מעקב מרכזי ובקרת גישה
Google השקיעה במערכת מרכזית למעקב ולאישור של SSH, שנקראת הרשאת מעקב מבוססת-זהות של מארח (HIBA). HIBA מאפשר לראות את כל השימוש ב-SSH ולאכוף מדיניות הרשאות מחמירה. ניסיונות SSH נרשמים ביומן, לא רק על ידי מכונת היעד, אלא גם על ידי BeyondCorp proxy המרכזי. הפקודות שמופעלות על ידי המעטפת נרשמות ביומן ומוזנות לצינורות של זיהוי התנהגות זדונית. עם זאת, הזיהוי הוא תגובתי במהותו ופגיע להסתרה ולהתחמקות.
השגת אבן דרך: ביטול גישה חד-צדדית
ברוב המקרים, Google הסירה את הגישה למעטפת (למשל, דרך SSH) למכונות ייצור או לעומסי עבודה שפועלים ב-Borg. עם זאת, צוותי הפיתוח יכולים להמשיך לגשת אליו במכונות בדיקה (לדוגמה, מכונות שמשמשות להסמכה של חומרה חדשה או תוכנה חדשה ברמה נמוכה, אבל לא להפעלת שירותי ייצור).
ממשקי API מצומצמים
צוותים מסוימים ב-Google שהסתמכו בעבר על SSH כדי להריץ מספר מוגבל של פקודות מוגדרות במדויק (לדוגמה, ב-playbook), או כדי לקבל נתונים שהמבנה שלהם ניתן לחיזוי, משתמשים עכשיו בממשקי API מוגדרים בצורה מצומצמת שמיועדים לתרחיש השימוש הספציפי ומספקים נתונים מובְנים.
ממשקי API מצומצמים כוללים מספר קטן של שיטות שמתאימות לתהליכים נפוצים שעוברים משתמשים, והם מסתירים פרטים על גישה ברמה נמוכה. לכן, הם הפתרון המועדף של Google כי הם מספקים את האבטחה והיכולת הטובות ביותר לביצוע ביקורת. הבנייה שלהם על תשתית הקריאה לשירות מרוחק (RPC) של Google מאפשרת לנו ליהנות מהשקעה של עשרות שנים באבטחה ובביקורת.
פרוקסי מאובטח ל-SSH
חלק מהצוותים ב-Google לא יכולים לקבוע מראש אילו פקודות הם עשויים להצטרך. במקרה הזה, Google משתמשת בדמון להרצת פקודות שמקבל רק בקשות להרצת פקודות שרירותיות מפרוקסי מהימן שמופעל על ידי צוות אבטחה. הטכנולוגיה הזו דומה לטכנולוגיה שמשמשת בפרוקסי בטוח ל-NoPe.
פרוקסי מאובטח ל-SSH אחראי להרשאה מדויקת של ביצוע פקודות ולביקורת. ההרשאה מבוססת על הארגומנט והסביבה של הפקודה, על פרמטרים של הגבלת קצב, על הצדקות עסקיות ועל MPA. תהליך ההרשאה הזה מאפשר להגדיר הגבלות מדויקות על הפקודות שאפשר להריץ בהתאם לשיטות המומלצות ולספרי ההפעלה של הצוות. במקרים של כשל לא צפוי שלא מתועדים ב-playbooks קיימים, אנשי הצוות עדיין יכולים להריץ את פקודות הניפוי הנדרשות אחרי שאדם מורשה אחר אישר אותן.
MPA for SSH
לצוותים הנותרים שעובדים על תשתית ברמה נמוכה יש גישת מעטפת לא חד-צדדית כדי לנפות באגים בבעיות המורכבות ביותר.
SSH בתרחישי נעילה
Google מאפשרת חריג במקרים שבהם יש גישה חד-צדדית למעטפת: כדי לוודא ש-Google יכולה לפתור מצבים של נעילת חשבון. מפתחות ה-SSH שמשמשים למטרה הזו נוצרים בתהליך נפרד שניתן לביקורת, ונשמרים אופליין בחומרה עמידה בפני חדירה. כשמשתמשים במקשים האלה, מתבצעת רישום של תמלילים מלאים של סשן מעטפת.
אמצעי בקרה על גישה פיזית
מרכזי הנתונים של Google הם סביבה מורכבת של שרתים, ציוד רשתות ומערכות בקרה, שנדרש מגוון רחב של תפקידים ומיומנויות כדי לנהל, לתחזק ולהפעיל אותם.
כדי להגן על עומסי העבודה במרכז הנתונים, Google מטמיעה במכונות עצמן שש שכבות של אמצעי בקרה פיזיים וגם אמצעי בקרה לוגיים רבים. אנחנו גם מגנים על המרחב שבין המכונות, שאנחנו קוראים לו המרחב מהפיזי ללוגי.
אמצעי בקרה פיזיים עד לוגיים מספקים שכבות הגנה נוספות באמצעות אמצעי בקרה שנקראים הקשחת מכונות, בקרת גישה מבוססת-משימות והגנה עצמית במערכת. אמצעי הבקרה מהפיזי ללוגי מגינים מפני תוקף שמנסה לנצל גישה פיזית למכונה כדי להסלים את המתקפה למתקפה לוגית על עומסי העבודה של המכונה.
מידע נוסף זמין במאמר איך Google מגינה על המרחב מהפיזי ללוגי במרכז נתונים.
אמצעי בקרה של קושחה ותוכנת מערכת
מצב האבטחה של מכונה במרכז נתונים נקבע בזמן האתחול. תהליך האתחול של המכונה מגדיר את החומרה של המכונה ומאתחל את מערכת ההפעלה שלה, תוך שמירה על בטיחות המכונה להרצה בסביבת הייצור של Google.
בכל שלב בתהליך האתחול, Google מטמיעה אמצעי בקרה מובילים בתעשייה כדי לאכוף את מצב האתחול שאנחנו מצפים לו ולשמור על בטיחות נתוני הלקוחות. אמצעי הבקרה האלה עוזרים לנו לוודא שהמכונות שלנו מבצעות אתחול לתוכנה המיועדת, וכך אנחנו יכולים להסיר נקודות חולשה שעלולות לפגוע במצב האבטחה הראשוני של המכונה.
מידע נוסף זמין במאמר איך Google אוכפת את תקינות האתחול במכונות ייצור.
הגנה על עומסי עבודה
בהתאם לפילוסופיית אפס האמון שלנו, Google הציגה גם אמצעי בקרה שעוזרים להתגונן מפני איומים של תנועה לרוחב בין עומסי עבודה עם דרישות אבטחה שונות. התשתית של Google משתמשת בהיררכיה של עומסי עבודה שנקראת טבעות אבטחה של עומסי עבודה (WSR). התכונה WSR עוזרת לוודא שעומסי עבודה קריטיים לא מתוזמנים באותן מכונות כמו עומסי עבודה פחות מאובטחים, בלי להשפיע לרעה על ניצול המשאבים. WSR מחלק את עומסי העבודה לארבע רמות רגישות – בסיסית, רגישה, מוקשחת ולא מוקשחת – ומנסה לתזמן אותם במאגרי מכונות שונים.
בתרשים הבא מוצג איך קבוצות WSR מתזמנות עומסי עבודה במכונות בסיסיות, במכונות Production ובמכונות פיתוח.
ה-WSR מספק שכבת הגנה נוספת מפני הסלמת הרשאות מקומית באמצעות התקפות על נקודות חולשה בליבה או התקפות על ערוץ צדדי של המעבד. התכונה WSR עוזרת לוודא שרק עומסי עבודה עם דרישות אבטחה דומות מתוזמנים יחד באותן מכונות. כדי להטמיע WSR, אנחנו:
- סיווג עומסי העבודה בהתאם לדרישות האבטחה שלהם. כל כיתה נקראת טבעת עומסי עבודה.
- כדאי לחלק את המכונות הפיזיות לכמה מאגרי מכונות שמבודדים זה מזה. במילים אחרות, אנחנו מבטלים את נתיבי התנועה הרוחבית בין המאגרים.
- כדי למנוע מעומסי עבודה עם דרישות אבטחה שונות לפעול באותה מכונה, אפשר להחיל אילוצי תזמון. המגבלות האלה על התזמון מפחיתות את הסיכון לפגיעה באבטחה באמצעות הסלמת הרשאות מקומית.
לדוגמה, כדי להשתמש ב-WSR, עומסי עבודה בסיסיים צריכים לפעול במכונות ייעודיות, ואסור לתזמן אותם יחד עם עומסי עבודה לא בסיסיים. המגבלה הזו מספקת בידוד חזק מעומסי עבודה פחות מאובטחים.
שיטות לבידוד עומסי עבודה
תוכנת מערכת מודרנית היא מורכבת, וחוקרי אבטחה מגלים מעת לעת נקודות חולשה שמאפשרות הסלמת הרשאות מקומית, כמו ניצול של פרצות אבטחה ביום האפס בליבה או התקפות חדשות בערוץ צדדי של מעבד. WSR, שהוצג לראשונה ב-USENIX ;login:, מאפשר ל-Google לצמצם את הסיכון שמשויך למיקום משותף של עומסי עבודה, תוך שמירה על ניצול גבוה של משאבים.
כברירת מחדל, Borg משתמש בגבולות של תהליכים ברמת מערכת ההפעלה כדי לבודד קונטיינרים. התהליכים האלה מציעים גבול בידוד חלש יותר מאשר מכונות וירטואליות שמשתמשות בווירטואליזציה מבוססת-חומרה. בידוד חלש יותר כזה הוא בדרך כלל פשרה טובה בין יעילות לאבטחה בסביבות מרובות דיירים שבהן מופעלים עומסי עבודה מהימנים. עומס עבודה מהימן הוא עומס עבודה שבו הקובץ הבינארי וההגדרה נוצרו באופן שניתן לאימות מקוד שנבדק על ידי עמיתים, עם הוכחת מקור. עומסי עבודה מהימנים לא מעבדים נתונים שרירותיים לא מהימנים. דוגמאות לעיבוד נתונים לא מהימנים כוללות אירוח קוד של צד שלישי או קידוד סרטונים.
Google משתמשת ב-BAB כדי לבנות אמון בקבצים הבינאריים שלה. עם זאת, BAB לא מספיק כדי להבטיח את השלמות של עומסי עבודה שמעבדים נתונים לא מהימנים. בנוסף ל-BAB, עומסי עבודה כאלה צריכים לפעול גם בארגז חול. ארגז חול הוא סביבה מוגבלת, כמו gVisor, שמאפשרת להפעיל קובץ בינארי בצורה בטוחה. יש מגבלות גם ב-BAB וגם בסביבות ארגז חול.
בדיקת BAB היא אמצעי בקרה יעיל למוצרים מבוססים, אבל היא עלולה להאט את קצב הפיתוח בשלבים הראשונים של פיתוח מערכות חדשות, וגם כשמריצים ניסויים ללא מידע אישי רגיש (למשל, אופטימיזציה של קידוד נתונים שכבר גלויים לציבור). ההגבלה הזו אומרת שחלק מעומסי העבודה תמיד צריכים לפעול בלי BAB. עומסי עבודה כאלה נמצאים בסיכון גבוה יותר להסלמת הרשאות מקומית (לדוגמה, על ידי ניצול נקודת חולשה בליבה כדי לקבל הרשאת root מקומית במחשב).
הרצה בארגז חול של עומסי עבודה לא מהימנים גם מפחיתה את הסיכון לאבטחה, אבל היא כרוכה בשימוש מוגבר בחישוב ובזיכרון. היעילות יכולה לרדת באחוז דו-ספרתי, בהתאם לעומס העבודה ולסוג ארגז החול. דוגמה להשפעות על הביצועים בעומס עבודה בסביבת ארגז חול מופיעה בנקודות ההשוואה המפורטות במדריך הביצועים של gVisor. ה-WSR מאפשר לנו לטפל במגבלות היעילות שנובעות מבידוד של עומסי עבודה.
טבעות עומס עבודה
Google מגדירה ארבעה סוגים של עומסי עבודה (workloads) בהתאם לדרישות האבטחה שלהם: בסיסיים, רגישים, מוקשחים ולא מוקשחים. בטבלה הבאה מפורטים פרטים נוספים.
| חוג עומסי עבודה | תיאור |
|---|---|
| מאגר בסיסי | עומסי עבודה שחיוניים לאבטחה של Google, כמו שירותים לניהול זהויות והרשאות גישה. לעומסי עבודה בסיסיים יש דרישות האבטחה הגבוהות ביותר, ובדרך כלל הם מתפשרים על יעילות לטובת אבטחה ואמינות משופרות. |
| רגישה | עומסי עבודה שעלולים לגרום להפסקות נרחבות בשירות או שיש להם גישה לנתונים רגישים שספציפיים למוצר, כמו נתוני משתמשים או לקוחות. |
| מוקשח | תמיכה בעומסי עבודה (workloads) שלא נחשבים לקריטיים מבחינת אבטחה, אבל הוטמעו בהם BAB או שהם מבודדים בסביבת ארגז חול, כך שהם לא מהווים סיכון גדול לעומסי עבודה שכנים. |
| לא מוקשח | כל שאר עומסי העבודה, כולל עומסי עבודה שמריצים קוד לא מהימן. |
ב-Google, אנחנו מסווגים עומסי עבודה קריטיים שתומכים במוצרים ספציפיים כעומסי עבודה רגישים, ועומסי עבודה בסיסיים הם עומסי עבודה שיכולים להשפיע על כל המוצרים.
בניגוד לסיווגים 'בסיסי' ו'רגיש', אנחנו יכולים לסווג כל עומס עבודה כ'מאובטח' על סמך אמצעי הבקרה שאומצו והסוג של הקלט שהוא מעבד. כשמדובר בעומסי עבודה מוקשחים, אנחנו מתמקדים בעיקר בהשפעה שלהם על עומסי עבודה אחרים, ולכן פתרונות ההקשחה יכולים לכלול ארגז חול.
מאגרי מכונות
כדי להימנע מתזמון משותף של שירותים רגישים עם עומסי עבודה שפחות מהימנים (לדוגמה, כאלה שמעבדים נתונים לא מהימנים בלי ארגז חול), אנחנו צריכים להריץ אותם במאגרי מכונות מבודדים. בידוד מכונות מקל על ההבנה של אי-השתנות האבטחה, אבל כל מאגר מכונות נוסף יוצר פשרות בשימוש במשאבים ובתחזוקה.
בידוד מכונות מוביל לניצול נמוך יותר של משאבים פיזיים, כי ככל שמוסיפים עוד מאגרי מכונות, קשה יותר לוודא שהמאגרים מנוצלים במלואם. עלות היעילות עשויה להיות משמעותית אם יש כמה מאגרי מכונות גדולים ומבודדים.
כשטביעת הרגל של המשאבים של עומסי העבודה משתנה בכל מאגר, בידוד קפדני מוסיף תקורה לניהול כדי לבצע איזון מחדש של המכונות בין המאגרים ולשנות את הייעוד שלהן מעת לעת. כדי לבצע איזון מחדש כזה, צריך לנקז את כל עומסי העבודה ממכונה, להפעיל מחדש את המכונה ולבצע את תהליך הניקוי המקיף ביותר של המכונה, שעוזר להבטיח אותנטיות ושלמות של קושחה.
השיקולים האלה מצביעים על כך שההטמעה של Google של בידוד מכונות צריכה לספק דרכים לאופטימיזציה של השימוש במשאבים פיזיים, וגם להגן על עומסי עבודה בסיסיים ורגישים מפני יריבים.
ב-Kubernetes, הגישה הזו נקראת בידוד צמתים. אפשר למפות צמתים של Kubernetes למכונות פיזיות או וירטואליות. במאמר הזה אנחנו מתמקדים במכונות פיזיות. בנוסף, Google Cloud מוצרים כמו Compute Engine מציעים שכירות בלעדית כדי לספק בידוד של מכונות פיזיות.
אילוצים בתזמון עומסי עבודה
Google מספקת מכונות בשלושה סוגים של מאגרי מכונות מבודדים: מכונות בסיסיות, מכונות לייצור ומכונות לפיתוח. Google מפעילה כמה מאגרים מבודדים שמארחים עומסי עבודה בסיסיים ורגישים, אבל במסמך הזה כל אחד מהם מוצג כמאגר אחד כדי לפשט את ההסבר.
כדי לספק את ההגנה הכי יעילה, אנחנו פורסים את מגבלות התזמון הבאות עבור WSR:
- עומסי עבודה בסיסיים יכולים לפעול רק במכונות בסיסיות.
- עומסי עבודה רגישים יכולים לפעול רק במכונות ייצור.
- עומסי עבודה שלא עברו חיזוק יכולים לפעול רק במכונות פיתוח.
- אפשר להריץ עומסי עבודה מוקשחים במכונות ייצור או פיתוח, ועדיף במכונות ייצור.
התרשים הבא מציג את מגבלות התזמון.
בדיאגרמה הזו, גבולות הבידוד מפרידים בין סוגים שונים של עומסי עבודה (workloads), גם בין מאגרי מכונות וגם בתוך מאגרי מכונות. עומסי עבודה בסיסיים הם הדיירים היחידים של מכונות בסיסיות ייעודיות. הרשאות בינאריות או ארגז חול (sandboxing) לעומסי עבודה שפועלים במכונות ייצור עוזרים למנוע מתקפות של העלאת הרשאות מקומיות. במכונות פיתוח, קיים סיכון שיורי שעומס עבודה לא מוקשח עלול לפגוע בעומס עבודה אחר, אבל הפגיעה מוגבלת למכונות הפיתוח כי עומסי עבודה מוקשחים לא יכולים ליצור משימות חדשות.
עומסי עבודה מוקשחים מתוזמנים במכונות ייצור או במכונות פיתוח על סמך הזמינות. יכול להיות שזה נראה לא הגיוני לאפשר תזמון בכמה מאגרים, אבל זה חיוני כדי לצמצם את הירידה בשימוש שנגרמת בגלל מגבלות התזמון. עומסי עבודה מוקשחים ממלאים פערים שנוצרים כתוצאה מבידוד של משימות רגישות ולא מוקשחות. בנוסף, ככל שהמשאבים המוקשחים גדולים יותר, כך אפשר לספוג תנודות גדולות יותר בשימוש במשאבים של שתי המחלקות האחרות בלי להצטרך להעביר מכונות יקרות בין טבעות.
בתרשים הבא מוצגים אילוצים בתזמון שמוטלים על סוגים שונים של עומסי עבודה. עומס עבודה מוקשח יכול להיות במכונת ייצור או במכונת פיתוח.
על ידי בידוד עומסי עבודה בסיסיים בכמה מאגרי משאבים בסיסיים, Google מוותרת על יעילות המשאבים לטובת אבטחה גבוהה יותר. למזלנו, בדרך כלל עומס העבודה הבסיסי תופס יחסית מעט משאבים, ולכן למאגרי מכונות ייעודיות קטנים ומבודדים יש השפעה זניחה על ניצול המשאבים הכולל. עם זאת, גם עם פעולות אוטומטיות נרחבות, יש עלות לתחזוקה של כמה מאגרי מכונות, ולכן אנחנו כל הזמן מפתחים את עיצובי המכונות שלנו כדי לשפר את הבידוד.
התכונה WSR מספקת הבטחה חזקה לכך שעומסי עבודה לא בסיסיים לעולם לא יורשו לפעול במכונות בסיסיות. המכונות הבסיסיות מוגנות מפני תנועה לרוחב, כי רק עומסי עבודה בסיסיים יכולים לפעול במכונות האלה.
סיכום אמצעי הבקרה
Google משתמשת במספר אמצעי בקרה בתשתית שלה כדי להגן על שירותי הייצור, על מכונות הייצור ועל עומסי העבודה. אמצעי הבקרה כוללים את האפשרויות הבאות:
- אמצעי בקרה לניהול גישה ו-BAB לשירותי ייצור
- אמצעי בקרה לגישה למעטפת, אמצעי בקרה לגישה פיזית ואמצעי בקרה של קושחה ותוכנת מערכת למכונות ייצור
- WSR לסוגים שונים של עומסי עבודה
יחד, אמצעי הבקרה האלה אוכפים מגבלות שעוזרות להגן על המשתמשים והלקוחות של Google ועל הנתונים שלהם. בתרשים הבא מוצג איך אמצעי הבקרה פועלים יחד כדי לתמוך במצב האבטחה של Google.
המאמרים הבאים
- סקירה כללית על תכנון האבטחה בתשתית של Google – מידע נוסף על אמצעי בקרה לאבטחה בתשתית של Google.
- יצירת מערכות מאובטחות ואמינות (O'Reilly book) – מידע נוסף על תרבות האבטחה של Google.
- מידע נוסף על הרשמה דרך הארגון זמין במצגת SREcon.