התוכן הזה עודכן לאחרונה במאי 2024, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
במסמך הזה מוסבר איך אנחנו משתמשים בבדיקות הקוד, בתשתית האבטחה ובבדיקת האכיפה שנקראת Binary Authorization for Borg (BAB) כדי להגן על שרשרת האספקה של התוכנות ב-Google מפני סיכון פנים. בדיקת BAB עוזרת להפחית סיכונים מבפנים, במיוחד כשלקוד שלנו יש גישה למידע רגיש, כי היא מבטיחה שהתוכנות בסביבת הייצור ייבדקו ויאושרו לפני הפריסה. בדיקת BAB חלה על כל השירותים שפועלים ב-Borg. מאז שהמסמך פורסם לראשונה, הוספנו מושגים מרכזיים בנושא BAB למפרט הפתוח Supply-chain Levels for Software Artifacts (SLSA).
המסמך הזה הוא חלק מסדרה של מאמרים טכניים שמתארים פרויקטים שצוות האבטחה של Google פיתח כדי לעזור בשיפור האבטחה, כולל BeyondCorp ו-BeyondProd. במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו למצוא מידע נוסף.
מבוא
סיכון פנים הוא איום אבטחה על נתוני המשתמשים, כולל נתוני תעסוקה, נתונים פיננסיים, או נתונים קנייניים או עסקיים אחרים. סיכון פנים הוא הסכנה שעובדי הארגון ישתמשו בידע הארגוני או בגישה שלהם כדי לבצע פעולות זדוניות, או שתוקף חיצוני ישיג את פרטי הכניסה של העובדים בשביל לעשות זאת.
אנחנו משתמשים ב-BAB כדי למזער את סיכוני הפנים בשרשרת אספקת התוכנות שלנו. בדיקת BAB היא בדיקת אכיפה פנימית שמתבצעת בזמן הפריסה של התוכנה. בדיקת BAB מקפידה שהפריסות של הקוד והתצורה עומדות בסטנדרטים מינימליים מסוימים ובקריטריונים האחידים של מערכות הייצור שלנו.
כדי להגן על נתוני המשתמשים במערכות הייצור שלנו, אנחנו מגבילים את הגישה החד-צדדית של העובדים שלנו. בדיקת BAB עוזרת להבטיח שלעובדים שפועלים לבדם לא תהיה גישה ישירה או עקיפה לנתוני המשתמשים או יכולת לשנות אותם ללא ההרשאה המתאימה וההצדקה לעשות זאת. בעזרת בדיקת BAB ואמצעי הבקרה המשויכים אליה אנחנו יכולים לאכוף את עיקרון ההרשאות המינימליות, ולשפר את מצב האבטחה ללא קשר לאיום מצד גורמים מסוימים. כלומר, בדיקת BAB מגבילה גישה חד-צדדית, בין אם לגורם יש כוונה זדונית, שהחשבון שלו נפרץ או שניתנה לו גישה בטעות.
היתרונות של BAB
לשימוש ב-BAB ולמודל לפריסה בקונטיינרים יש יתרונות אבטחה רבים בתשתית של Google, כולל:
- BAB עוזרת לצמצם את הסיכון הכללי ממשתמשי פנים: בדיקת BAB מחייבת שהקוד יעמוד בסטנדרטים מסוימים ובשיטות עבודה לניהול שינויים, כדי שאפשר יהיה לגשת באמצעותו לנתוני המשתמשים. הדרישה הזו מפחיתה את הסיכון שתתבצע גישה לנתוני משתמשים באופן פרוגרמטי על ידי עובד שפועל לבדו (או באמצעות חשבון עובד שנפרץ).
- BAB תומכת באחידות של מערכות הייצור: בזכות השימוש במערכות בקונטיינרים ואימות דרישות הקוד של BAB לפני הפריסה, קל יותר לנפות באגים במערכות האלה, לשפר את האמינות שלהן ולנהל את השינויים באופן מבוקר. דרישות הקוד של BAB יוצרות שפה משותפת עבור הדרישות של הקוד במערכת הייצור.
- BAB מכתיבה שפה משותפת להגנה על נתונים: הבדיקה עוקבת אחר התאימות בכל המערכות של Google. הנתונים לגבי התאימות הזו מתפרסמים באופן פנימי וזמינים לצוותים אחרים. פרסום נתוני BAB מאפשר לצוותים להשתמש במונחים משותפים כשהם מתקשרים ביניהם לגבי ההגנה על הגישה לנתונים שלהם. השפה המשותפת הזו מצמצמת את העבודה הנדרשת כשעובדים עם נתונים בין צוותים.
- BAB מאפשרת מעקב פרוגרמטי אחר דרישות התאימות: הבדיקות של BAB מפשטות את תהליך התאימות שהתבצע בעבר באופן ידני. בתהליכים מסוימים ב-Google נדרשים אמצעי בקרה הדוקים יותר על האופן שבו אנחנו מטפלים בנתונים. לדוגמה, מערכות הדיווח הפיננסי שלנו חייבות לעמוד בדרישות של חוק Saranes-Oxley Act (SOX). בעבר, הייתה לנו מערכת שעזרה לנו לאמת את התאימות ידנית. עם השקת BAB, רבות מהבדיקות האלה בוצעו אוטומטית בהתאם לכללי המדיניות של BAB עבור שירותים. האוטומציה של הבדיקות האלה אפשרה לצוות התאימות להגדיל את היקף השירותים הכלולים בבדיקות, וגם לאמץ עוד אמצעי בקרה מתאימים לשירותים האלה.
בדיקת BAB היא חלק ממסגרת גדולה יותר שנקראת BeyondProd, שבה אנחנו משתמשים לצמצום סיכוני פנים.
תהליך הפיתוח והייצור שלנו
כברירת מחדל, תהליך הפיתוח והייצור ב-Google כולל ארבעה שלבים הכרחיים: בדיקת הקוד, יצירת גרסאות build מאומתות, פריסה בקונטיינרים ויצירת זהות מבוססת-שירות. בקטעים הבאים נרחיב על השלבים האלה.
שלב 1: בדיקת הקוד
רוב קוד המקור שלנו מאוחסן במאגר מונוליתי מרכזי , ונדרש אישור של לפחות מהנדס אחד שלא כתב את הקוד. codebase מונוליתי מאפשר לאכוף נקודת חנק אחת לבדיקות קוד.
לכל הפחות, תהליך בדיקת הקוד שלנו מחייב את הבעלים של המערכת לאשר את השינויים בקוד במערכת שלהם.
כשמייבאים שינויים מקוד של צד שלישי או מקוד פתוח, אנחנו מוודאים שהשינוי תואם את הבדיקות שלנו (למשל, שזו הגרסה האחרונה). עם זאת, אנחנו בדרך כלל לא משתמשים באותם אמצעי בקרה לכל השינויים בקוד של צד שלישי או בקוד פתוח שנמצא בשימוש אצלנו ומפתחים חיצוניים משנים.
שלב 2: יצירת גרסאות build מאומתות
מערכת ה-build שלנו דומה למערכת Bazel, שבונה ומהדרת את קוד המקור ויוצרת קוד בינארי לפריסה. מערכת ה-build פועלת בסביבה מבודדת ונעולה , שמופרדת מהעובדים שמפתחים את גרסאות ה-build. המערכת יוצרת מקור לכל גרסת build, שנוצר על ידי גרסאות build מאומתות . המקור הזה הוא אישור חתום שכולל תיאור של מקורות הקוד ויחסי התלות שנכללים ב-build, את הגיבובים הקריפטוגרפיים שנעשה בהם שימוש בקבצים הבינאריים או בתוצרי ה-build האחרים, ואת הפרמטרים המלאים של ה-build. השימוש במקור מאפשר לנו:
- לדעת מה קוד המקור ששימש ליצירת הקוד הבינארי. כתוצאה מכך, אנחנו גם יכולים לבדוק מה היה תהליך היצירה והשליחה של קוד המקור שהוא מתאר.
- לאמת שהקובץ הבינארי לא השתנה, מאחר שכל שינוי בקובץ יבטל אוטומטית את התוקף של החתימה בקובץ.
מאחר שפעולות build יכולות להכיל קוד שרירותי, מערכת ה-build שלנו הוקשחה כדי לתמוך בריבוי דיירים. במילים אחרות, מערכת ה-build שלנו נועדה למנוע מגרסת build אחת להשפיע על גרסאות build אחרות. המערכת לא מאפשרת לבצע שינויים שעלולים לפגוע בתקינות המקור של ה-build או במערכת עצמה. לאחר השלמת ה-build, פורסים את השינוי באמצעות Borg.
שלב 3: פריסה בקונטיינרים
אחרי שמערכת ה-build יוצרת את הקובץ הבינארי, הוא נארז בתור קובץ אימג' של קונטיינר ונפרס בתור משימת Borg במערכת תזמור האשכולות שלנו, Borg. אנחנו מריצים מאות אלפי משימות מאפליקציות שונות ובאשכולות שונים, שכל אחד מהם יכול להכיל עשרות אלפי מכונות. למרות קנה המידה הנרחב הזה, סביבת הייצור שלנו היא הומוגנית למדי. כתוצאה מכך, קל יותר לפקח על נקודות המגע שבהן מתבצעת גישה לנתוני המשתמשים ולבצע עליהן בקרה.
לשימוש בקונטיינרים יתרונות חשובים מבחינת אבטחה. אי אפשר לשנות את הקונטיינרים, ופורסים אותם מחדש בתדירות גבוהה מתוך קובץ אימג' מלא שנבנה מחדש. יצירת קונטיינרים מאפשרת לנו לבדוק שינויים בקוד בהקשר המלא שלהם, ומהווה נקודת חנק אחת לשינויים שנפרסים בתשתית שלנו.
הגדרות המשימה ב-Borg מציינות את הדרישות לפריסתה: קובצי האימג' בקונטיינר, הפרמטרים, הארגומנטים והדגלים שנדרשים בזמן הריצה. מערכת Borg מתזמנת את המשימה, תוך התחשבות במגבלות, בעדיפות, במכסות ובכל הדרישות האחרות של המשימה שמצוינות בהגדרות. אחרי פריסת המשימה, המשימה ב-Borg יכולה לקיים אינטראקציה עם משימות אחרות בסביבת הייצור.
שלב 4: יצירת זהות מבוססת-שירות
המשימה שמריצים ב-Borg פועלת בתור זהות של שירות. הזהות הזו משמשת לגישה למאגרי נתונים או לקריאה לשירות מרוחק (RPC) של שירותים אחרים. אפשר להריץ משימות שונות עם אותה זהות. רק העובדים שאחראים להרצת השירות (בדרך כלל (בדרך כללSite Reliability Engineers (SREs)) יכולים לפרוס או לשנות משימות עם זהות מסוימת.
כשמתחילים משימה ב-Borg, מקצים לה פרטי כניסה קריפטוגרפיים. פרטי הכניסה האלה משמשים להוכחת הזהות של המשימה כששולחים בקשות לשירותים אחרים באמצעות מערכת אבטחת שכבת התעבורה של אפליקציה (ALTS). לזהות הזו צריכות להיות ההרשאות הנדרשות כדי שאפשר יהיה לגשת מהשירות לנתונים מסוימים או לשירותים אחרים.
לפי המדיניות שלנו, נדרשת הגנת BAB לזהויות שירות שיש להן גישה לנתוני משתמשים ולכל מידע אישי רגיש אחר. אפשר להריץ משימות של בקרת איכות או פיתוח שאין להן גישה למידע רגיש עם פחות אמצעי בקרה.
הסבר על בדיקת BAB
בדיקת BAB משתלבת במערכת Borg כדי להבטיח שיוכלו להריץ רק משימות מורשות עם הזהות של כל שירות. בנוסף, בדיקת BAB יוצרת נתיב ביקורת של הקוד וההגדרות במשימות שבהן בדיקת BAB מופעלת. נתיב הביקורת הזה מאפשר לנו לעקוב ולהגיב לאירועים.
בדיקת BAB נועדה להבטיח שכל התוכנות וההגדרות בסביבת הייצור ייבדקו, יוכנסו למערכת המעקב אחר שינויים, יעברו גרסת build שאפשר לאמת ויקבלו הרשאה, במיוחד כשלקוד יש גישה לנתוני המשתמשים.
מדיניות ספציפית לשירות
כשבעלי שירותים מצרפים את השירות ל-Borg, הם יוצרים מדיניות BAB שמגדירה את דרישות האבטחה של השירות שלהם. המדיניות הזו נקראת מדיניות ספציפית לשירות. הגדרה או שינוי של המדיניות נחשבים לשינוי בקוד וצריכים לעבור בדיקה.
במדיניות הספציפית לשירות מוגדר איזה קוד ואילו הגדרות מורשים לפעול בתור הזהות של השירות, וכן מוגדרים המאפיינים שנדרשים לקוד ולהגדרות האלה. כל המשימות שפועלות בתור הזהות של השירות חייבות לעמוד בכללי המדיניות הספציפית לשירות.
כל שירותי Borg ב-Google מחויבים להגדיר מדיניות ספציפית לשירות.
כברירת מחדל, השיטה הזו מחייבת את הדרישות הבאות:
- הקוד חייב להיות בר בדיקה: אפשר להגיע מקובץ אימג' של קונטיינר לקוד המקור בפורמט שקריא לאנשים, באמצעות מקור שנוצר על ידי גרסאות build שניתנות לאימות. בזכות מדיניות שמירת נתונים, קוד המקור נשמר בפורמט קריא לבני אדם למשך 18 חודשים לפחות, גם אם הקוד לא נשלח.
- הקוד חייב להיכנס למאגר: הקוד מבוסס על מיקום מסוים במאגר המקור שלנו. באופן כללי, רק קוד שעבר בדיקה נכנס למאגר.
- ההגדרות חייבות להיכנס למאגר: ההגדרות שמשמשות במהלך הפריסה עוברות את אותו תהליך הבדיקה והשליחה כמו הקוד הרגיל. לכן, אי אפשר לשנות ערכים של דגלים בשורת הפקודה, ארגומנטים ופרמטרים ללא בדיקה.
יכול להיות שלשירותים שאין להם גישה למידע אישי רגיש – או בנסיבות נדירות, לשירותים שיש להם חריג תקף ומאושר – תהיה מדיניות מקלה יותר, כמו מדיניות שדורשת רק יכולת ביקורת של הקוד, או אפילו מדיניות שמשביתה לחלוטין את BAB.
המערכות והרכיבים לאכיפת בדיקת BAB עוברים בקרה הדוקה בהתאם לדרישות האוטומטיות המחמירות, ושימוש באמצעי בקרה ידניים נוספים.
מצבי האכיפה
בדיקת BAB פועלת תחת שני מצבי אכיפה כדי לוודא שהמשימות עומדות בדרישות של המדיניות הספציפית לשירות:
- מצב אכיפה בזמן הפריסה, שבו נחסמת היכולת לפרוס משימות שלא תואמות את המדיניות.
- מצב אימות רציף, שבו מתבצע מעקב (כולל התראה) אחרי פריסה של משימות שלא תואמות את המדיניות.
בנוסף, במקרה חירום, אפשר לעקוף את האכיפה בזמן הפריסה בעזרת נוהלי תגובה למקרה חירום.
מצב אכיפה בזמן הפריסה
הבקר המרכזי של Borg נקרא Borg Prime, והוא משמש כרשות האישורים של ALTS. כשנשלחת משימה חדשה, לפני ש-Borg Prime מעניק אישור למשימה ב-ALTS, הוא בודק באמצעות BAB שהמשימה עומדת בדרישות של המדיניות הספציפית לשירות. הבדיקה משמשת כבקרת כניסה: המשימה תופעל ב-Borg רק אם היא עומדת בדרישות של המדיניות הספציפית לשירות. הבדיקה הזו מתבצעת גם אם לעובד או לשירות ששולחים את בקשת הפריסה יש את ההרשאה הנדרשת.
במקרים נדירים, שירותים יוכלו להפסיק להשתמש באכיפה בזמן פריסה, עם הצדקה מספקת.
מצב אימות רציף
לאחר שהמשימה נפרסת, היא ממשיכה לעבור אימות באופן קבוע בכל משך החיים שלה, ללא קשר למצב האכיפה בזמן הפריסה. התהליך של BAB פועל לפחות פעם ביום כדי לבדוק אם המשימות שהופעלו (ואולי עדיין פועלות) תואמות לעדכונים שבוצעו במדיניות שלהן. לדוגמה, במצב האימות הרציף יש בדיקה קבועה לאיתור משימות שפועלות עם מדיניות ישנה או שנפרסו בנוהלי תגובה למקרה חירום. אם נמצאה משימה שלא עומדת בדרישות של המדיניות המעודכנת ביותר, בעלי השירות יקבלו התראה מ-BAB כדי שיוכלו למזער את הסיכון.
נוהלי תגובה למקרה חירום
במקרה של הפסקה זמנית בשירות או אירוע אחר, שחזור השירות הרלוונטי בהקדם האפשרי נמצא בראש סדר העדיפויות שלנו. במקרה חירום, יכול להיות שיהיה צריך להריץ קוד שלא נבדק או שלא אומת. לשם כך, אפשר לעקוף את מצב האכיפה בעזרת הדגל שמפעיל את נוהל התגובה למקרה חירום. נוהלי התגובה למקרה חירום משמשים גם כגיבוי במקרה של כשל בבדיקת BAB, שעלול לחסום את הפריסה. כשהמפתחים פורסים משימה באמצעות נוהל תגובה למקרה חירום, הם צריכים לצרף הצדקה לבקשה שלהם.
במהלך תגובה למקרה חירום, נרשמים ביומן הדיווח של BAB פרטים לגבי משימת ה-Borg המשויכת, ונשלחת הודעה לצוות האבטחה המרכזי של Google ולצוות שאחראי על זהות השירות. רשומה ביומן כוללת הפניה לתמונת מצב של הקוד שנפרס ואת ההצדקה שסופקה על ידי המשתמש. נוהלי תגובה במקרה חירום נועדו לשמש רק כמוצא אחרון.
הרחבת BAB לסביבות אחרות
במקור, בדיקת BAB תמכה רק במשימות בסביבת Borg, והמפתחים נדרשו לפתח את התוכנה באמצעות צינור עיבוד הנתונים המסורתי של Google לניהול הגרסאות, הפיתוח והאריזה. אבל כיום, נוספה לה תמיכה להגנה על סביבות אחרות המשמשות להכנת תוכנה להפצה ולפריסה, ותמיכה במערכות חלופיות לניהול הגרסאות, פיתוח גרסאות ה-build והאריזה. פרטי ההטמעה בסביבות השונות עשויים להשתנות, אבל היתרונות של השימוש בבדיקת BAB נשארים בתוקף.
יש כמה מקרים שלא מתאימים לבדיקות קוד אנושיות לפני הפריסה, בעיקר מקרים של פיתוח איטרטיבי של קוד למידת מכונה או ניתוח נתונים בתדירות גבוהה. במקרים כאלה, אנחנו מפצים על כך באמצעות אמצעי בקרה חלופיים.
שימוש באמצעי בקרה דומים בארגון שלכם
בקטע הזה נסביר מה השיטות המומלצות שלמדנו בתהליך ההטמעה של BAB, כדי שתוכלו לאמץ אמצעי בקרה דומים בארגון שלכם.
יצירת צינור עיבוד נתונים הומוגני של CI/CD בקונטיינרים
תהליך ההטמעה של BAB עבר בקלות בזכות העובדה שרוב הצוותים שלנו השתמשו באותה המערכת לניהול הגרסאות, באותו התהליך לבדיקת הקוד, באותה מערכת build ובאותה מערכת פריסה. מאחר שבדיקות הקוד כבר היו חלק מהתרבות שלנו, יכולנו לשנות דברים בלי יותר מדי שינויים גלויים למשתמשים. כדי שנוכל להטמיע את BAB, התמקדנו בבדיקות קוד, ביצירת גרסאות build מאומתות, בפריסות בקונטיינרים ובזהויות שמבוססות על שירותים לבקרת הגישה. הגישה הזו פישטה את ההטמעה של BAB וחיזקה את הביטחון שפתרון כמו BAB יכול לספק.
בזכות השימוש הנרחב במיקרו-שירותים ובזהויות שמבוססות על שירותים (למשל, חשבונות שירות) במקום בזהויות שמבוססות על המארח (למשל, כתובות IP), אנחנו מסוגלים לשלוט בהרשאות של התוכנות ברמה הפרטנית ולהחליט אילו שירותים הן יכולות להפעיל.
אם הארגון שלכם לא יכול לאמץ באופן ישיר את השימוש בזהות של שירות, תוכלו לנסות להגן על אסימוני הזהות בעזרת אמצעים אחרים כשלב ביניים.
קביעת היעדים והגדרת המדיניות בהתאם לדרישות
את תהליך ההפצה המבוסס על מדיניות כדאי לבנות באופן מדורג. יכול להיות שתצטרכו להטמיע שינויים מסוימים בצינור עיבוד הנתונים של CI/CD לפני שתוכלו להטמיע שינויים אחרים. לדוגמה, יכול להיות שתצטרכו להתחיל לערוך בדיקות קוד באופן רשמי לפני שתוכלו לאכוף אותן בזמן הפריסה.
מניע נהדר להטמעת תהליך הפצה המבוסס על מדיניות הוא תאימות. אם תצליחו לקודד לפחות חלק מדרישות התאימות שלכם במדיניות, זה יאפשר לכם לבצע אוטומציה לבדיקות ולוודא שהן תמיד בתוקף. כדאי להתחיל עם קבוצה של דרישות בסיסיות, ואת הדרישות המתקדמות יותר לקודד בהמשך הדרך.
אכיפת המדיניות בשלבי הפיתוח המוקדמים
קשה להגדיר מדיניות מקיפה לגבי תוכנה מסוימת, בלי לדעת קודם איפה היא תפעל ולאילו נתונים תהיה לה גישה. לכן, אכיפה של מדיניות ספציפית לשירות מתבצעת בזמן פריסת הקוד ובזמן הגישה לנתונים, ולא בזמן כתיבת הקוד. המדיניות מוגדרת במונחים של זהות בסביבת זמן ריצה, ולכן יכול להיות שאותו קוד יפעל בסביבות שונות ויהיה כפוף לכללי מדיניות שונים.
אנחנו משתמשים בבדיקת BAB כדי להגביל את הגישה לנתוני המשתמשים, בנוסף למנגנונים אחרים של בקרת גישה. כך בעלי השירותים יכולים לוודא בצורה מפורטת יותר שרק למשימות שעומדות בדרישות מסוימות של BAB יש גישה לנתונים.
גיוס עזרה מנציגים בצוותים השונים
הדבר שהכי השפיע על שיעור ההצלחה שלנו בהטמעת BAB בכל רחבי Google היה איתור נציג מכל קבוצת מוצרים שיוביל את השינוי. איתרנו כמה בעלי שירותים שזיהו את היתרונות המיידיים שישיגו מאכיפת מדיניות השירות, והיו מוכנים לספק משוב. לפני שביצענו שינויים מחייבים, ביקשנו מבעלי השירותים האלה להתנדב. לאחר שנעזרנו בהם, יצרנו צוות רשמי לניהול השינויים כדי לעקוב אחר השינויים השוטפים. לאחר מכן, איתרנו אנשים מכל צוות מוצר שיהיו אחראים על יישום השינויים.
קביעת אופן הניהול של קוד של צד שלישי
אם אתם צריכים לנהל קוד של צד שלישי, חשוב לתכנן איך תציגו את דרישות המדיניות ל-codebase של צד שלישי. לדוגמה, תוכלו בהתחלה לשמור במאגר את כל הקוד של צד שלישי שאתם משתמשים בו. מומלץ לבדוק באופן קבוע שהקוד תואם לדרישות האבטחה שלכם.
למידע נוסף על ניהול קוד של צד שלישי תוכלו לקרוא את המאמר בנושא הצלחה משותפת בבניית קהילה בטוחה יותר של קוד פתוח.
המאמרים הבאים
- מאמר בנושא BeyondProd, היוזמה שלנו ליצירת מתחם היקפי מאובטח סביב המיקרו-שירותים שלנו.
- במאמר בנושא Supply chain Levels for Software Artifacts (SLSA) מוסבר איך להשתמש בצינור עיבוד נתונים מאובטח של CI/CD.