אבטחה

במסמך הזה מפורטת סקירה כללית שכוללת מושגי ליבה, שכבות ותפקידים תפעוליים לשמירה על אבטחה ב-Google Distributed Cloud ‏ (GDC) עם בידוד פיזי. ‫GDC מיועד לסביבות מנותקות ומאובטחות מאוד, ולעמידה בדרישות מחמירות של ריבונות נתונים.

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

במסמך הזה נסביר על מאפייני האבטחה העיקריים בקטגוריות הבאות:

אסטרטגיית אבטחה

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

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

ל-GDC יש מודל אבטחה משותף לאבטחת כל ערימת האפליקציות. ‫GDC מספקת תשתית כשירות (IaaS), פלטפורמה כשירות (PaaS) ותוכנה כשירות (SaaS). בכל ההגדרות של GDC, ‏ Google והמפעיל אחראים לאבטחת השכבות של התשתית. הלקוח אחראי לאבטחת הגדרת הפרויקט ושכבת האפליקציה, כולל קונטיינרים של אפליקציות, תמונות בסיס ותלות.

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

מבחינת אבטחה, קבוצות הקהלים הבאות מפעילות את GDC:

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

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

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

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

אבטחת מתקנים

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

אבטחת חומרה

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

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

‫GDC מבטיח שרק מערכת ההפעלה (OS) המאובטחת של Node, שאנחנו אורזים בהתאמה אישית, תוכל להיטען במערכות כברירת מחדל. תמונות מוקשחות והגדרות מוקשחות מצמצמות מאוד את שטח ההתקפה. מודולים קריפטוגרפיים שמגנים על נתונים במצב מנוחה ובמעבר עברו אימות FIPS 140-2/3, כלומר הם נבדקו בקפדנות מבחינת אבטחה ונבדקו על ידי מעבדה עצמאית ומוסמכת. ‫GDC מספקת תוכנת אנטי-וירוס למערכת ההפעלה שפועלת בצמתי Bare Metal, ופתרון לסריקת מערכות האחסון. ‫Google מאגדת עדכונים לסורקים האלה, והם כלולים בעדכוני המערכת הרגילים שה-IO מחיל באמצעות תהליך השדרוג של GDC. התראות על זיהוי נשלחות ל-IO. בנוסף, GDC מספקת כלים לניטור שלמות האפליקציה ולזיהוי הפרות, כדי להגן על המערכת מפני שינויים לא מכוונים. בסך הכול, אמצעי האבטחה האלה עוזרים להגן על המערכת מפני מגוון מתקפות. אמצעי האבטחה מקשים על תוקפים לגשת למערכת, לנצל נקודות חולשה ולהתקין תוכנות זדוניות.

Tenancy

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

דיאגרמה של אשכול אדמין ראשי ב-GDC, עם שני אשכולות ארגוניים ואשכולות משתמשים.

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

שכבות של מכשיר אחסון GDC.

אבטחת אפליקציות

כדי להגן מפני התקפות על שרשרת האספקה של תוכנות, כל התוכנות של GDC מפותחות בהתאם ל-Supply chain Levels for Software Artifacts (SLSA), מסגרת אבטחה של שרשרת האספקה ש-Google פיתחה בשיתוף עם ארגונים, כולל CNCF ו-Linux Foundation.

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

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

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

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

אבטחת רשת

בקטע הזה מופיעה סקירה כללית של אבטחת הרשת של GDC.

רשת פיזית

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

כל תעבורת הנתונים ברשת בין הרשת הפרטית של הלקוח לבין מערכות GDC עוברת דרך חומות אש ומערכות לאיתור ולמניעה של פריצות (IDS/IPS). חומת האש מספקת את קו ההגנה הראשון לשליטה בגישה למערכת. חומת האש ומערכת IDS/IPS שולטות בתעבורה הנכנסת והיוצאת על סמך מדיניות אבטחה שניתנת להגדרה, ומשתמשות בלמידת מכונה כדי לנתח את התעבורה באופן אוטומטי ולחסום כניסה לא מורשית. מערכת IDS/IPS בודקת כברירת מחדל את כל התקשורת הנכנסת והיוצאת בתשתית. חשבונות PA יכולים גם להשתמש במערכת IDS/IPS כדי לבדוק את התנועה של עומסי העבודה שלהם. גם חומות האש וגם מערכות IDS/IPS משולבות עם חבילת הכלים ניראות (observability) של הארגון לעומסי עבודה של לקוחות, ועם חבילת הכלים SIEM של IO לתשתית, כדי לאפשר ניתוח אבטחה נוסף ופורנזיקה דיגיטלית.

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

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

שירותי Networking מוגדרי-תוכנה

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

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

רשת וירטואלית

הרשת הווירטואלית של GDC היא שכבת רשת ברמת הארגון, שמבוססת על רשת השכבה העליונה. הוא מופעל על ידי מנהל התקן (driver) של ממשק רשת מנוהל של קונטיינר (CNI) של GDC – מישור הנתונים של רשת Anthos.

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

  • מדיניות רשת של פרויקט: להגנה על גבולות הפרויקט.
  • מדיניות רשת של הארגון: להגנה על גבולות הארגון.

מדיניות הרשת של הפרויקט ומדיניות הרשת של הארגון מוגדרות כברירת מחדל כ'דחייה' כנקודת התחלה להגנה מפני גישה לא מכוונת ודליפת נתונים.

הגנה מפני התקפת מניעת שירות

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

קריפטוגרפיה

בקטע הזה יש סקירה כללית על הקריפטוגרפיה של GDC.

PKI

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

שירות ניהול מפתחות (KMS)

‫GDC מספק שירות לניהול מפתחות (KMS) שמגובה במודולים לאבטחת חומרה (HSM). ‫KMS הוא שירות צד ראשון. חומר המפתח נשאר ב-KMS, שמגובה על ידי HSM. הגדרות משאבים מותאמות אישית (CRD) מכילות חומר מפתח מוצפן. רק ל-KMS יש גישה לחומר מפתח גולמי בזיכרון. יש KMS אחד לכל ארגון. כל הנתונים באחסון מוצפנים כברירת מחדל באמצעות מפתחות שמגובים על ידי HSM. הלקוחות יכולים גם לבחור לנהל בעצמם את המפתחות הקריפטוגרפיים שלהם. ‫KMS תומך באלגוריתמים שאושרו על ידי FIPS ובמודולים שאומתו על ידי FIPS. מערכת KMS תומכת בייבוא ובייצוא של מפתחות בצורה מאובטחת לתרחישי שימוש של נאמנות מפתחות, מחיקה או תוכנית התאוששות מאסון (DR). התכונות האלה הופכות את KMS לדרך מאובטחת ומהימנה לניהול מפתחות קריפטוגרפיים.

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

הצפנה

בקטע הזה מופיעה סקירה כללית על ההצפנה ב-GDC.

נתונים באחסון

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

  • אחסון בלוקים (כרכים של אפליקציות, דיסקים של מכונות וירטואליות, אחסון מסדי נתונים) מוצפן בשלוש רמות:
    • שכבת תוכנה: הצפנת Linux Unified Key Setup‏ (LUKS) שמתבצעת בחומרת מחשוב ייעודית לדייר עם מפתחות לכל נפח אחסון, שמגובים ב-HSM ומנוהלים על ידי הלקוח.
    • שכבת המכשיר: הצפנה ברמת צבירת נפחים (NVE/NAE) שמתבצעת בתוך מכשיר האחסון עם מפתחות לכל דייר שמגובים על ידי HSM ומנוהלים על ידי הלקוח.
    • שכבת הדיסק: כוננים עם הצפנה עצמית (SED) עם מפתחות לכל כונן, שמגובים על ידי HSM ומנוהלים על ידי ה-IO.
  • אחסון האובייקטים מוצפן בשתי שכבות
    • שכבת Bucket: הצפנת נתוני אובייקט שמתואמת בתוך חומרת מחשוב ייעודית לדייר, עם מפתחות לכל Bucket שמגובים על ידי HSM ומנוהלים על ידי הלקוח.
    • שכבת הדיסק: SED עם מפתחות לכל כונן שמגובים ב-HSM ומנוהלים על ידי ה-IO.
  • אחסון הדיסק בשרת, נתוני הגדרת המערכת לדייר יחיד, מוצפנים בשכבה אחת:
    • שכבת הדיסק: SEDs עם מפתחות לכל כונן, שמגובים על ידי HSM ומנוהלים על ידי הלקוח.

נתונים במעבר

כל התעבורה ב-GDC מוצפנת כברירת מחדל באמצעות מודולים קריפטוגרפיים עם אישור FIPS 140-2 ופרוטוקולים סטנדרטיים בתעשייה כמו TLS 1.2+,‏ HTTPS ומנהרות IPSec. בנוסף, הלקוחות צפויים להשתמש באלגוריתמים מוצפנים בשכבת האפליקציה, על סמך מודל האחריות המשותפת, כדי לוודא שדרישות ההצפנה מתקיימות בכל האפליקציות שנפרסות על GDC.

ניהול זהויות והרשאות גישה (IAM)

הגישה למערכת מבוססת על העיקרון של הרשאות מינימליות. למשתמשים ניתנת גישה רק למשאבים שהם צריכים. התהליך הזה מגן על המערכת מפני גישה לא מורשית ושימוש לרעה. בנוסף, המערכת אוכפת הפרדת תפקידים, למשל אין גישה חד-צדדית. אין אדם אחד שיש לו שליטה מלאה על מערכת או תהליך כלשהם. התהליך הזה עוזר למנוע הונאות ושגיאות. ‫GDC יכול להשתלב עם ספק הזהויות הקיים של הלקוחות. המערכת תומכת ב-SAML 2.0 וב-OIDC לאיחוד של ספקי זהויות. התמיכה הזו מאפשרת למשתמשים לאמת את המשתמשים במערכת באמצעות ספק הזהויות הקיים שלהם, כדי לנהל את המשתמשים במקום אחד. כל המשתמשים ועומסי העבודה מאומתים לפני שהם מקבלים גישה למערכת. מערכות RBAC ו-ABAC משמשות לאישור כל הגישה למישור הבקרה ולנתונים. למשתמשים מותר לגשת למשאבים ולבצע פעולות רק אם הם עברו אימות וקיבלו הרשאה. כל הגישות מתועדות ביומן הביקורת, כך שאדמינים יכולים לעקוב אחרי מי ניגש למשאב ומתי. התהליך הזה עוזר לזהות גישה לא מורשית ושימוש לרעה.

תפעול אבטחה (SecOps)

צוות GDC Security Operations (SecOps) מספק מידע על אבטחה לישויות עם דרישות מחמירות בנוגע לאבטחה, לתאימות ולריבונות, כדי להבטיח סודיות, יושרה וזמינות מקסימליות של עומסי עבודה (workload) מוסדרים של לקוחות שמוגנים על ידי פער אוויר. ארכיטקטורת האבטחה הזו נועדה לעמוד ביעדים הבאים:

  • הצלבת נתונים מרישום ביומן של פלטפורמת GDC לצורך ניתוח אבטחה ותגובה.
  • זיהוי מהיר של נקודות חולשה באבטחה, דיווח עליהן ומעקב אחריהן.
  • הגנה על כל הנכסים של OIC ו-GDC באמצעות Endpoint Detection & Response (EDR).
  • מספקים כלים, תהליכים וספרי הדרכה כדי לאפשר למרכז התפעול של SecOps לבצע מעקב רציף לצורך זיהוי, הכלה, מיגור והתאוששות מאירועי אבטחת סייבר.
תכונה תיאור
ניהול מידע ואירועים בנושא אבטחה ‫Splunk Enterprise היא פלטפורמה לניהול אבטחת מידע ואירועים (SIEM) שאוספת, יוצרת אינדקס ומנתחת נתוני אבטחה ממגוון מקורות, כדי לעזור לארגונים לזהות איומים ולהגיב להם.
ניהול נקודות חולשה ‫Tenable Security Center היא פלטפורמה לניהול נקודות חולשה שעוזרת לארגונים לזהות ולתקן נקודות חולשה באבטחה.
זיהוי ותגובה בנקודות קצה Trellix HX,‏ Windows Defender ו-ClamAV. פלטפורמות אבטחה מאוחדות שמספקות לארגונים תצוגה מקיפה של מצב האבטחה שלהם, כדי לזהות איומים ולהגיב להם בצורה יעילה יותר.
ניהול מאובטח של בקשות תמיכה פתרון תוכנה שמאפשר לארגונים לנהל את מחזור החיים של אירועי אבטחה.

דיאגרמה של תפעול אבטחה ב-GDC שמתארת את רכיבי התוכנה ואת תהליכי העבודה של האנשים.

‫GDC SecOps מאפשר ל-IOs לספק פונקציות של Security Operations. צוות GDC SecOps מספק תהליכים שמבוססים על אנשים, כולל תגובה לאירועים, ניהול נקודות חולשה, הנדסת אבטחה וניהול סיכונים בשרשרת האספקה. ‫GDC SecOps מאפשר למרכז אבטחה (SOC) לבצע את הפעולות הבאות:

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

ניהול נקודות חולשה

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

תגובה לאירוע אבטחה

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

לכל CVE או תקרית שמתגלים, מוקצה מפקד תקרית (IC) כדי להפעיל את תהליך התגובה. ה-IC אחראי לניהול התהליך, שכולל אימות של האירוע, הקצאת ציון של נקודת החולשה לפי Common Vulnerability Scoring System (CVSS), ניהול התהליך של יצירת תיקון והכנתו למסירה ויצירת אמצעי התקשורת המתאימים.

פעולות שקשורות לאמינות

בקטע הזה מופיעה סקירה כללית של פעולות האמינות של GDC.

רישום ביומן ומעקב

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

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

אירועים קריטיים ביומן הביקורת כוללים את התחומים הבאים:

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

גישה במצב חירום

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

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

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

תוכנית התאוששות מאסון (DR)

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

שדרוג ועדכון המערכת

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

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

ניהול שינויים – תשתית כקוד

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

תהליכי עמידה בדרישות

‫GDC מוכן לתאימות למשטרים נפוצים כמו NIST 800-53, ‏ SOC 2 ועוזר לקבל אישורים כמו FIPS 140-2 ו-3. בנוסף, GDC עובר תהליכי אישור שונים ועומד בתקני האבטחה של Google. התאימות היא תהליך מתמשך. כדי לאפשר ללקוחות ולמפעילים להשתמש ב-GDC, המערכת מספקת ניטור ובדיקות שוטפים. כחלק משיטות האבטחה בתהליך הניטור המתמשך, GDC עוקב אחרי שינויים במלאי, כמו תוכנה וחומרה לא מוכרות, או הוספה של תוכנה או חומרה חדשות. ‫GDC עורכת בדיקות חדירה באופן קבוע על ידי הדמיית מתקפות של גורמים זדוניים. ‫GDC סורקת את המערכות מעת לעת כדי לזהות תוכנות זדוניות, ומודיעה ל-GDC על כל הדבקה. תהליך הבדיקה של תוכנית התאוששות מאסון (DR) בודק את היכולת של GDC להתאושש ממצב שכולל אסון. התהליכים האלה מבטיחים שהנתונים והמערכות של GDC יהיו מאובטחים.