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

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

להורדה של גרסת PDF

מבוא

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

במסמך מתוארים הנושאים הבאים:

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

  • אופן התכנון של אבטחת התשתית בשכבות מתקדמות, שכוללות את אלה:

בשאר הקטעים במסמך הזה מתוארות שכבות האבטחה.

תשתית מאובטחת ברמה נמוכה

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

אבטחה של אתרים בשטח

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

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

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

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

תכנון החומרה והמקור שלה

מרכזי הנתונים של Google מורכבים מאלפי שרתים שמחוברים לרשת מקומית. אנחנו מתכננים את לוחות השרתים ואת ציוד הרשת. אנחנו בוחרים את ספקי הרכיבים שאנחנו עובדים איתם ובוחרים רכיבים בקפידה. אנחנו עובדים עם ספקים כדי לבדוק ולאמת את מאפייני האבטחה שהרכיבים מכילים. אנחנו גם מתכננים צ'יפים בהתאמה אישית, כולל צ'יפ לאבטחת חומרה (שנקרא Titan),‏ ואנחנו פורסים אותם בשרתים, במכשירים ובציוד ההיקפי. הצ'יפים מאפשרים לנו לזהות ולאמת מכשירי Google לגיטימיים ברמת החומרה. הם משמשים כ-Roots of Trust של החומרה.

סטאק של הפעלה מאובטחת וזהות מכונה

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

אנחנו שואפים לשפר את השרתים שלנו כל הזמן עם כל דור חדש של חומרה, ולהביא את השיפורים האלה לשאר התעשייה באמצעות השתתפות בתהליכי סטנדרטיזציה עם Trusted Computing Group ו-DMTF.

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

פיתחנו מערכות אוטומטיות שיבצעו את הפעולות הבאות:

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

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

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

שירותי Google הם הקבצים הבינאריים של האפליקציות, שהמפתחים שלנו כותבים ומריצים בתשתית שלנו. דוגמאות לשירותי Google: שרתי Gmail, מסדי נתונים של Spanner, שרתים של Cloud Storage, מקודדי סרטונים ב-YouTube ומכונות וירטואליות של Compute Engine שמפעילות אפליקציות של לקוחות. כדי להתמודד עם עומס העבודה הנדרש, אלפי מכונות עשויות להריץ קבצים בינאריים של אותו השירות. שירות תזמור של אשכולות, שנקרא Borg, שולט בשירותים שפועלים ישירות בתשתית.

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

מאחר שהתשתית נועדה להיות מרובת דיירים (tenants), הנתונים מהלקוחות שלנו (צרכנים, עסקים ואפילו הנתונים שלנו) מופצים בכל התשתית המשותפת. התשתית הזו מורכבת מעשרות אלפי מכונות הומוגניות. התשתית לא מפרידה נתוני לקוחות למכונה בודדת או לקבוצת מכונות, פרט לנסיבות ספציפיות, למשל כשמשתמשים ב- Google Cloud כדי להקצות מכונות וירטואליות לשרתים לדייר יחיד (sole-tenant) ב-Compute Engine.

‫Google Cloud ו-Google Workspace תומכים בדרישות הרגולטוריות בתחום של מיקום הנתונים. מידע נוסף על מיקום נתונים ו-Google Cloudזמין במאמר הגבלת מיקומי משאבים. מידע על מיקום נתונים ו-Google Workspace מופיע במאמר אזורים גיאוגרפיים לאחסון נתונים: בחירת מיקום גיאוגרפי לנתונים.

זהות, תקינות ובידוד של שירות

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

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

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

אנחנו משתמשים בשיטות שונות של בידוד והרצה בארגז חול (sandboxing) כדי להגן על שירות מפני שירותים אחרים שפועלים באותה מכונה. שיטות אלה כוללות הפרדת משתמשים של Linux, הרצה בארגז חול שמבוססת על שפה (כמו Sandboxed API) או על ליבה, ליבה של אפליקציה לקונטיינרים (למשל gVisor) ווירטואליזציה של חומרה. באופן כללי, אנחנו משתמשים בשכבות נוספות של בידוד במקרים של עומסי עבודה עם רמת סיכון גבוהה יותר. עומסי עבודה כאלה כוללים עומסי עבודה שמבצעים עיבוד של קלט לא מחוטא מהאינטרנט. לדוגמה, עומסי עבודה עם רמת סיכון גבוהה יותר כוללים הפעלה של ממירי קבצים מורכבים לקלט לא מהימן, או הרצה של קוד שרירותי כשירות למוצרים כמו Compute Engine.

כדי להגביר את האבטחה, שירותים רגישים – כמו שירות תזמור של אשכולות וכמה שירותי ניהול מפתחות (KMS) – פועלים אך ורק במכונות ייעודיות.

ב- Google Cloud, כדי לספק בידוד קריפטוגרפי חזק יותר לעומסי העבודה ולהגן על נתונים שבשימוש, אנחנו תומכים בשירותי Confidential Computing למכונות וירטואליות (VM) ב-Compute Engine ולצמתים ב-Google Kubernetes Engine‏ (GKE).

ניהול הרשאות גישה בין שירותים

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

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

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

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

הזהויות של משתמשי הקצה מנוהלות בנפרד, כפי שמתואר במאמר ניהול הרשאות גישה לנתוני משתמש קצה ב-Google Workspace.

הצפנה של תקשורת בין עומסי עבודה

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

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

ניהול הרשאות גישה לנתונים של משתמשי קצה ב-Google Workspace

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

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

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

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

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

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

תרשים שמציג איך שירות א' ושירות ב' מתקשרים.

מידע על ניהול הרשאות גישה ב- Google Cloudזמין במאמר סקירה כללית על IAM.

ניהול הרשאות הגישה לנתונים של משתמשי קצה ב- Google Cloud

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

ב-Google Cloud אנחנו משתמשים בממשק לניהול זהויות והרשאות גישה (IAM) ובמוצרים מבוססי-הקשר (למשל, שרת proxy לאימות זהויות (IAP)) כדי לנהל את הגישה למשאבים ב-Google Cloud בארגון. ההרשאות של כל בקשות הגישה לשירותי Google Cloud מאומתות באמצעות IAM.

כך נראה תהליך הניהול של הרשאות הגישה:

  1. הבקשה מתקבלת בשירות בממשק הקצה של Google או בשירות בממשק הקצה של Cloud למכונות הווירטואליות של הלקוחות.
  2. הבקשה מנותבת לשירות המרכזי לניהול הזהויות של המשתמשים, שבו מבוצעת בדיקת האימות ומונפקים כרטיסי ההקשר של משתמשי הקצה.
  3. הבקשה מנותבת גם כדי לבדוק את הדברים הבאים, למשל:
  4. אחרי שכל הבדיקות האלה מסתיימות בהצלחה, מתבצעת קריאה לשירותים לקצה העורפי של Google Cloud .

מידע על ניהול הרשאות גישה ב- Google Cloudזמין במאמר סקירה כללית על IAM.

אחסון מאובטח של נתונים

בקטע הזה מוסבר איך אנחנו מטמיעים אבטחה של נתונים שמאוחסנים בתשתית.

הצפנה במנוחה

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

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

בנוסף להצפנה שהתשתית מבצעת באמצעות מפתחות הצפנה בבעלות ובניהול של Google,‏ Google Cloud Google Workspace מספקת שירותי ניהול מפתחות שאתם יכולים להיות הבעלים שלהם ולנהל אותם. ב-Google Cloud,‏ Cloud KMS הוא שירות ענן שמאפשר לכם ליצור מפתחות קריפטוגרפיים משלכם, כולל מפתחות מוסמכים מבוססי-חומרה FIPS 140-3 L3. המפתחות האלה ספציפיים לכם, ולא לשירות Google Cloud , ואתם יכולים לנהל את המפתחות בהתאם למדיניות ולנהלים שלכם. ב-Google Workspace ניתן להשתמש בהצפנה מצד הלקוח. מידע נוסף זמין במאמר הצפנה מצד הלקוח ושיתוף פעולה מוגבר ב-Google Workspace.

מחיקת נתונים

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

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

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

מידע נוסף זמין במאמר מחיקת נתונים ב-Google Cloud. מידע על השבתת מפתחות משלכם באמצעות Cloud Key Management Service זמין במאמר השמדה ושחזור של גרסאות מפתחות.

תקשורת אינטרנט מאובטחת

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

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

שירות ממשק קצה של Google‏ (GFE)

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

למעשה, כל שירות פנימי שחייב לפרסם את עצמו באופן חיצוני משתמש ב-GFE כחזית חכמה של שרת proxy הפוך. GFE מספק אירוח של כתובות IP ציבוריות של שם ה-DNS הציבורי שלו, הגנה מפני מניעת שירות וסיום TLS. ‏GFE פועל בתשתית כמו כל שירות אחר, ויכול להשתנות בהתאם לנפח הבקשות הנכנסות.

כשמכונות וירטואליות של לקוחות ברשתות VPC ניגשות לממשקי API ולשירותים של Google שמארחים ישירות ב-Borg, המכונות הווירטואליות של הלקוחות מתקשרות עם ממשקי קצה ספציפיים של Google Front End (GFE) שנקראים ממשקי קצה של Cloud. Google Cloud כדי לצמצם את זמן האחזור, ממשקי הקצה של Cloud ממוקמים באותו אזור בענן כמו המכונה הווירטואלית של הלקוח. ניתוב רשת בין מכונות וירטואליות של לקוחות לבין ממשקי קצה של Cloud לא מחייב שלמכונות הווירטואליות של הלקוחות יהיו כתובות IP חיצוניות. כשמופעלת גישה פרטית ל-Google, מכונות וירטואליות של לקוחות עם כתובות IP פנימיות בלבד יכולות לתקשר עם כתובות ה-IP החיצוניות של Google APIs ושירותים באמצעות ממשקי קצה של Cloud. כל ניתוב הרשת בין מכונות וירטואליות של לקוחות, Google APIs ושירותים של Google תלויים בצעדים הבאים ברשת של סביבת הייצור של Google, גם במכונות וירטואליות של לקוחות שיש להן כתובות IP חיצוניות.

הגנה מפני מניעת שירות (DoS)

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

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

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

אימות משתמשים

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

כשמשתמשים נכנסים לחשבון, בשלב האימות השני הם יכולים להשתמש בגורמים כמו סיסמאות חד-פעמיות (OTP) או מפתחות אבטחה עמידים בפני פישינג, למשל מפתח האבטחה Titan. מפתח האבטחה Titan הוא אסימון פיזי שתומך ב-FIDO Universal 2nd Factor‏ (U2F). עזרנו לפתח את התקן הפתוח U2F יחד עם FIDO Alliance. רוב הפלטפורמות והדפדפנים באינטרנט אימצו את התקן הפתוח הזה לאימות.

אבטחה תפעולית

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

פיתוח בטוח של תוכנות

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

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

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

אנחנו גם משקיעים במציאת מתקפות אפס-ימים ובעיות אבטחה אחרות בתוכנת הקוד הפתוח שבה אנחנו משתמשים. אנחנו מפעילים את Project Zero – צוות חוקרים של Google שמתמקד בחקר נקודות חולשה של אפס-ימים, כולל פרצות Spectre ו-Meltdown. בנוסף, אנחנו שולחים אל hypervisor של Linux KVM הכי הרבה CVEs ותיקוני באגים באבטחה.

אמצעי הגנה על קוד מקור

קוד המקור שלנו מאוחסן במאגרים שמבוססים על תקינות ומינהל מובְנים של המקור, ואפשר לערוך בהם ביקורות לגרסאות הנוכחיות והקודמות של השירות. התשתית מחייבת ליצור את הקבצים הבינאריים של השירות מקוד מקור ספציפי שכבר נבחן, אומת ונבדק. ‫Binary Authorization for Borg‏ (BAB) היא בדיקת אכיפה פנימית שמתבצעת בזמן הפריסה של שירות. בדיקת ה-BAB:

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

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

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

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

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

צמצום של סיכון מבפנים

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

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

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

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

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

מידע נוסף על אמצעי ההגנה על שירותי הייצור זמין במאמר איך Google מגנה על שירותי הייצור שלה.

מעקב אחרי איומים

קבוצת Threat Analysis Group ב-Google עוקבת אחרי גורמי איום והתפתחות הטקטיקות והשיטות שלהם. מטרת הקבוצה היא לשפר את הבטיחות והאבטחה של מוצרי Google ולשתף את התובנות האלה לטובת הקהילה באינטרנט.

לגבי Google Cloud, אפשר להשתמש ב-Google Cloud Threat Intelligence for Google Security Operations וב-VirusTotal כדי לעקוב אחרי הסוגים הרבים של תוכנות זדוניות ולהגיב להן. Google Cloud Threat Intelligence for Google Security Operations הוא צוות של חוקרי איומים שמפתחים מודיעין איומי סייבר לשימוש ב-Google Security Operations. ‏VirusTotal הוא מסד נתונים ופתרון חזותי לתוכנות זדוניות, שאפשר להשתמש בו כדי להבין טוב יותר איך תוכנות זדוניות פועלות בארגון.

מידע נוסף על הפעילויות שלנו למעקב אחרי איומים מופיע בדוח של Threat Horizons.

זיהוי פריצות אבטחה

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

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