אבטחה

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

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

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

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

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

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

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

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

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

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

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

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

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

אבטחת המתקנים

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

אבטחת חומרה

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

דיירים בענן

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

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

אין שיתוף של שרתי מחשוב פיזיים בין ארגונים, וגם שכבות המפעיל שומרות על דיירות. לארגונים בינלאומיים אין גישה לשכבות של הרשות הפלסטינית. באופן דומה, גם ל-AO אין גישה לשכבות של ה-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 מבודדים, הרמטיים ומוגדרים באמצעות העיקרון build-as-code, ולאף אדם אין גישה חד-צדדית בתהליך הכנת תוכנה להפצה.

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

אבטחת רשת

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

רשת פיזית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קריפטוגרפיה

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

PKI

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

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

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

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

הצפנה

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

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

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

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

נתונים במעבר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

גישה במקרה חירום (Break glass)

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

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

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

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

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

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

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

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

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

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

תהליכי תאימות

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

תאימות למדריך הטכני להטמעת אבטחה (STIG)

לפי כלל STIG‏ RHEL-08-040320, החבילה xorg-x11-server-common היא יחסי תלות מאושרים של המערכת שנדרשים למנהלי ההתקנים של NVIDIA GPU ולספריות של שיפור מהירות באמצעות חומרה (כמו Vulkan ו-Mesa). שירות מנהל התצוגה הגרפית מושבת ולא פעיל בתמונות של מערכת ההפעלה של הצומת.