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

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

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

מבוא

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

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

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

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

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

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

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

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

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

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

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

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

השרתים של Google משתמשים בטכנולוגיות שונות כדי לוודא שהם מפעילים את סטאק התוכנות המתאים. אנחנו משתמשים בחתימות קריפטוגרפיות לרכיבים ברמה נמוכה, כמו baseboard management controller‏ (BMC),‏ BIOS, תוכנת אתחול, ליבה ותמונת מערכת הפעלה בבסיס. ניתן לאמת את החתימות האלה במהלך כל מחזור הפעלה או עדכון. בדיקת התקינות הראשונה של שרתי Google משתמשת ב-Root of Trust של חומרה. הרכיבים נשלטים על ידי Google, עם דגש על אימות התקינות שלהם. בכל דור חדש של חומרה, אנחנו שואפים כל הזמן לשפר את האבטחה. לדוגמה, בהתאם לדור שבו תוכנן השרת, ה-Root of Trust של שרשרת האתחול נמצא באחד מהרכיבים הבאים:

  • צ'יפ החומרה Titan
  • צ'יפ קושחה שניתן לנעול
  • מיקרו-בקר שמפעיל את קוד האבטחה שלנו

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

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

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

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

שירותי 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) ווירטואליזציה של חומרה. באופן כללי, אנחנו משתמשים בשכבות נוספות של בידוד במקרים של עומסי עבודה עם רמת סיכון גבוהה יותר. עומסי עבודה כאלה כוללים פריטים שסופקו על ידי משתמשים ושמחייבים עיבוד נוסף. לדוגמה, עומסי עבודה עם רמת סיכון גבוהה יותר כוללים הפעלה של ממירי קבצים מורכבים לנתונים שסופקו על ידי משתמשים, או הרצה של קוד שמשתמש סיפק למוצרים כמו App Engine או Compute Engine.

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

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

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

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

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

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

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

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

הצפנה של תקשורת בין שירותים

התשתית דואגת לסודיות ולתקינות של נתוני RPC ברשת. כל התעבורה ברשת הווירטואלית של 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.

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

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

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

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

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

הצפנה במנוחה

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

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

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

מחיקת נתונים

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

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

מידע נוסף זמין במאמר מחיקת נתונים ב-Google Cloud.

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

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

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

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

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

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

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

הגנה מפני מניעת שירות (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 למידע של משתמשי קצה. צוות האבטחה שלנו עוקב אחרי דפוסי הגישה וחוקר אירועים חריגים.

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

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

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

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

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

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

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