במאמר הזה מוסבר איך מתבצעת הצפנה במעבר ב-Google Distributed Cloud (GDC) עם air gap.
סיכום ברמת מנהל מערכות המידע
- ב-GDC יש כמה אמצעי אבטחה כדי להבטיח את האותנטיות, התקינות והסודיות של נתונים במעבר.
- בהתאם לסוג החיבור שנוצר, GDC מיישם על הנתונים במעבר את הגנות ברירת המחדל לרכיבי GDC. לדוגמה, אנחנו מאבטחים את התקשורת בין המשתמש לבין שער הכניסה של Cloud Service Mesh ב-GDC באמצעות TLS.
מבוא
אבטחה היא בדרך כלל גורם מכריע בבחירת ספק שירותי ענן. האבטחה ב-Google חשובה לנו מאוד. אנחנו משקיעים מאמצים רבים כדי להגן על הנתונים שלכם – בין שהם מועברים ברשת ובתשתית של Google ובין שהם מאוחסנים בשרתים שלנו.
מרכיבי האבטחה שבהם Google מתמקדת הם אימות, תקינות והצפנה, גם לנתונים באחסון וגם לנתונים במעבר. במאמר הזה נתאר את הגישה שלנו להצפנה במעבר ב-Google Distributed Cloud במודל Air-gapped (GDC).
למידע על נתונים באחסון, קראו את המאמר הצפנה במנוחה. בסקירה הכללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא על האבטחה ב-Google.
למי מיועד המסמך: למנהלי מערכות מידע ולצוותי תפעול אבטחה שמשתמשים ב-GDC או שוקלים להשתמש בו.
דרישות מוקדמות: בנוסף למבוא הזה, צריכה להיות לכם הבנה בסיסית בהצפנה ובפרימיטיבים קריפטוגרפיים.
אימות, תקינות והצפנה
ב-GDC יש כמה אמצעי אבטחה כדי להבטיח את האותנטיות, התקינות והסודיות של נתונים במעבר.
- אימות: אנחנו מאמתים את יעד הנתונים בשכבת הרשת. המקור מאומת על ידי AIS שמנוהל על ידי GDC.
- תקינות: אנחנו מוודאים שהנתונים שאתם שולחים מגיעים ליעדם ללא שינוי, כלומר שהם מוגנים מפני שינויים לא מורשים.
- הצפנה: אנחנו מוודאים שהנתונים יהיו בלתי קריאים בזמן המעבר כדי לשמור על הסודיות שלהם. הצפנה היא תהליך שהופך נתונים קריאים (טקסט ללא הצפנה) לנתונים בלתי קריאים (מידע מוצפן), במטרה להבטיח שהטקסט ללא הצפנה יהיה נגיש רק לצדדים המורשים על ידי בעלי הנתונים. האלגוריתמים שמשמשים בתהליך ההצפנה הם ציבוריים, אבל המפתח שנדרש לפענוח המידע המוצפן הוא פרטי. בהצפנה במעבר בדרך כלל נעשה שימוש בחילופי מפתחות אסימטריים, כמו elliptic-curve-based Diffie-Hellman, כדי ליצור מפתח סימטרי משותף שמשמש להצפנת הנתונים. למידע נוסף על הצפנה, ראו Introduction to Modern Cryptography.
הצפנה משמשת להגנה על נתונים, בכמה מצבים:
- הצפנה במנוחה נועדה להגן על הנתונים מפני פריצה למערכת וזליגת נתונים, על ידי הצפנת הנתונים בזמן האחסון. במקרים רבים הנתונים באחסון מוצפנים באמצעות תקן Advanced Encryption Standard (AES).
- הצפנה במעבר נועדה להגן על הנתונים במקרה שהתקשורת מיורטת בזמן העברת הנתונים בין האתר שלכם לספק שירותי הענן, או בין שני שירותים. ההגנה הזו מתבצעת באמצעות הצפנת הנתונים לפני המעבר, אימות של נקודות הקצה ופענוח ואימות של הנתונים כשהם מגיעים ליעדם, כדי לוודא שלא בוצעו בהם שינויים. לדוגמה, פעמים רבות משתמשים ב- Transport Layer Security (TLS) כדי להצפין את הנתונים במעבר, ובפרוטוקול מאובטח/רב תכליתי להצפנה ואימות של אימיילים (S/MIME) כדי להצפין הודעות אימייל.
הצפנה היא רכיב אחד באסטרטגיית אבטחה רחבה יותר. לאחר יצירת חיבור ואימות שלו, הצפנה במעבר מגינה על הנתונים שלכם מפני תוקפים פוטנציאליים על ידי:
- ביטול הצורך במתן אמון בשכבות הנמוכות יותר של הרשת, שבדרך כלל גורמי צד שלישי מספקים.
- צמצום שטח ההתקפה הפוטנציאלי.
- מניעת גישה של תוקפים לנתונים במקרה של יירוט שלהם.
באמצעות תהליכים הולמים של אימות, תקינות והצפנה, הנתונים יכולים להיות מוגנים במעבר בין משתמשים, מכשירים ותהליכים גם בסביבה עוינת. בהמשך הסקירה נסביר את הגישה של GDC להצפנת נתונים במעבר והיכן היא מיושמת.
תשתית הרשת של GDC
גבולות פיזיים
גבול פיזי הוא המחסום למרחב פיזי שנמצא בשליטתה של Google או בתיאום איתה, שבו אנחנו יכולים לוודא שקיימים אמצעי אבטחה קפדניים. הגישה הפיזית למיקומים האלה מוגבלת, מבוקרת ומנוטרת בקפידה. רק לקבוצה קטנה של עובדים מורשים יש גישה לחומרה. הנתונים במעבר בגבולות הפיזיים האלה מאומתים ומוצפנים בדרך כלל.
כדי להגן על נתונים במעבר, אנחנו משתמשים באימות ובהצפנה חזקים לתקשורת שנכנסת לגבולות הפיזיים של GDC או יוצאת מהם.
איך מנותבת תעבורת הנתונים
כדי להבין איך פועלת ההצפנה במעבר ב-GDC, חשוב להסביר איך תעבורת הנתונים מנותבת אל GDC ובתוכו. בקטע הזה נסביר איך בקשות ממשתמש קצה מגיעות לשירות המתאים ב-GDC או לאפליקציית הלקוח, ואיך תעבורת הנתונים מנותבת בין שירותים באתרים שונים.
שירות מנוהל של GDC הוא שירות מודולרי בענן פרטי. השירותים האלה כוללים שירותי מחשוב, אחסון ולמידת מכונה. לדוגמה, אחסון אובייקטים ב-GDC הוא שירות שמנוהל על ידי GDC. אפליקציית לקוח היא אפליקציה שמתארחת ב-GDC, ואתם, כלקוחות GDC, יכולים ליצור ולפרוס אותה באמצעות שירותי GDC. האפליקציות של הלקוחות או פתרונות של שותפים שמתארחים ב-GDC לא נחשבים לשירותים שמנוהלים על ידי GDC. לדוגמה, אפליקציה שאתם יוצרים באמצעות מכונות וירטואליות של GDC, שירות מסד הנתונים ו-Vertex AI היא אפליקציית לקוח.
באיור 1 מוצגים סוגים שונים של בקשות ניתוב. באיור 1 מוצגות האינטראקציות בין רכיבי הרשת השונים, ואמצעי האבטחה בכל חיבור.
איור 1: תשתית קישוריות בין אתרים
ממשתמש קצה (רשת של לקוח) ל-GDC API ולשירות מנוהל
בשירותים מנוהלים שמתארחים בשערי Ingress של Cloud Service Mesh, הבקשות מתקבלות מרשת הלקוח באמצעות שער Ingress של Cloud Service Mesh. שער הכניסה של Cloud Service Mesh משמש כשרת proxy שמנתב את תעבורת הנתונים הנכנסת ב-HTTP(S), מאזן את העומסים ומנתב את תעבורת הנתונים לשירותים שמנוהלים ב-GDC. שכבה נוספת של חומת אש מספקת אמצעי הגנה מפני התקפות DDoS, עם זיהוי ומניעה של חדירות. החיבור הזה מאומת ומוצפן משער הכניסה של Cloud Service Mesh לממשק הקצה הקדמי של השירות שמנוהל על ידי GDC. באיור 1, האינטראקציה הזו מוצגת כחיבור A.
רוב ממשקי ה-API והשירותים המנוהלים של GDC מתארחים בשערי Ingress של Cloud Service Mesh. עם זאת, שירותים מסוימים מתארחים ישירות במאזן עומסים בשכבה 4 שמנוהל על ידי GDC. לדוגמה, מסדי נתונים של DBS מתארחים במאזן עומסים חיצוני של GDC. השירותים האלה מוגדרים לאמת ולהצפין חיבורים בשכבת האפליקציה באמצעות TLS. איור 1 מציג את האינטראקציה הזו כחיבור B.
ממשתמש קצה (רשת של לקוח) לאפליקציית לקוח שמתארחת ב-GDC
יש כמה דרכים לנתב את תעבורת הנתונים מרשת הלקוח לאפליקציית לקוח שמתארחת ב-GDC. הדרך שבה התנועה מנותבת תלויה בהגדרות שלכם.
חשיפת אפליקציות של לקוחות דרך API Gateway של הלקוח
ב-GDC אפשר לחשוף אפליקציות של לקוחות דרך API Gateway של הלקוח. שירות API Gateway של הלקוח מאפשר למשתמשים לפתח, לפרוס, לאבטח, לנהל ולהתאים את ה-API לעומס לפי הצורך. באיור 1, האינטראקציה הזו מוצגת כחיבור C.
חשיפת עומסי עבודה של לקוחות בקונטיינרים באמצעות מאזן עומסים חיצוני של הלקוח
ב-GDC אפשר לחשוף עומסי עבודה בקונטיינרים שמנוהלים על ידי הלקוח באמצעות מאזן עומסים חיצוני. ב-GDC אפשר להגדיר כללי מדיניות של תעבורת נתונים נכנסת ויוצאת לאנשי הצוות הרלוונטיים. איור 1 מציג את האינטראקציה הזו כחיבור E.
חשיפת עומסי עבודה של מכונות וירטואליות
ב-GDC אפשר לחשוף למשתמשי קצה מכונות וירטואליות שהלקוחות יצרו. ב-GDC אפשר להגדיר כללי מדיניות של תעבורת נתונים נכנסת ויוצאת לאנשי הצוות הרלוונטיים. באיור 1, האינטראקציה הזו מוצגת כחיבור F.
שירות קישוריות בין אתרים ב-GDC
הניתוב משירות מנוהל אחד לשירות מנוהל אחר מתבצע בדרך כלל כולו בתוך הגבול הפיזי של GDC. במקרים מסוימים, כמו גיבוי באתרים שונים, הנתונים מנותבים אל מחוץ לגבולות הפיזיים של GDC. במקרה כזה, הנתונים מוצפנים גם בשכבת האפליקציה, למשל TLS, וגם בשכבת הרשת. באיור 1, האינטראקציה הזו מסומנת בתווית G.
ממכונה וירטואלית למכונה וירטואלית
החיבורים בין מכונות וירטואליות בתוך GDC לא מוצפנים ברמת הרשת. הלקוחות אחראים להצפין את הנתונים באמצעות פרוטוקולים מוצפנים מתאימים או טכנולוגיות ספציפיות כמו מנהרות IPSec.
הצפנה של נתונים במעבר כברירת מחדל
ב-GDC אנחנו משתמשים בשיטות שונות להצפנה של נתונים במעבר – גם כאלו עם הגדרות ברירת מחדל וגם כאלו עם הגדרות שהמשתמש יכול לשנות. סוג ההצפנה שבו משתמשים תלוי בשכבת ה-OSI, בסוג השירות וברכיב הפיזי של התשתית. בקטע הזה מתוארות הגנות ברירת המחדל שבהן Google משתמשת כדי להגן על נתונים במעבר.
בהמשך מתוארות הגנות ברירת המחדל שבהן Google משתמשת כדי להגן על נתונים במעבר.
הצפנה ממשתמשים לשער Ingress של Cloud Service Mesh
כיום, הרבה מערכות משתמשות בפרוטוקול HTTPS כדי לתקשר באינטרנט. הפרוטוקול מספק אבטחה באמצעות חיבור TLS (אבטחת שכבת התעבורה) שמבטיח את האותנטיות, התקינות והסודיות של בקשות ותשובות. כדי שאפשר יהיה לאשר בקשות HTTPS בצד המקבל, לצורך אימות השרת נדרש זוג מפתחות ציבורי/פרטי ואישור X.509 שהונפק על ידי רשות אישורים (CA). באמצעות זוג המפתחות והאישור אפשר לאמת בקשות של משתמש בשכבת האפליקציה (שכבה 7), כי הם מוכיחים שהצד המקבל הוא הבעלים של שם הדומיין שעבורו מיועדות הבקשות. בסעיפי המשנה הבאים מתוארים הרכיבים שמשמשים להצפנה ממשתמש לשער הכניסה של Cloud Service Mesh: TLS (אבטחת שכבת התעבורה), BoringSSL ורשות האישורים שניתנת להגדרה ב-GDC.
Transport Layer Security (TLS)
כשאתם שולחים בקשה לשירות של GDC, אנחנו מאבטחים את הנתונים במעבר. ההגנה מספקת אימות, תקינות והצפנה באמצעות פרוטוקול HTTPS עם אישור מרשות אישורים מהימנה. כל הנתונים שהמשתמש שולח לשער הכניסה של Cloud Service Mesh לשירות שמנוהל על ידי GDC מוצפנים בזמן המעבר באמצעות Transport Layer Security (TLS). בין הלקוח לבין Cloud Service Mesh Ingress Gateway מתנהל משא ומתן לגבי פרוטוקול הצפנה מסוים, בהתאם למה שנתמך בצד הלקוח. שער הכניסה של GDC Cloud Service Mesh אוכף רק אלגוריתמים שאושרו על ידי FIPS כדי לספק אבטחה חזקה יותר.
BoringSSL
BoringSSL הוא הטמעת קוד פתוח של פרוטוקול TLS המנוהלת על ידי Google. ההטמעה הזו שוכפלה (fork) מ-OpenSSL ושונתה, אבל ברוב המקרים הממשק שלה תואם ל-OpenSSL. Google שכפלה ושינתה את OpenSSL, ויצרה את BoringSSL כדי לפשט השימוש ב-OpenSSL – גם לשימוש פנימי וגם לתמיכה טובה יותר ב-Chromium ובפרויקטים של קוד פתוח של Android. המודול BoringCrypto, שמשמש כליבה של BoringSSL, אומת להסמכת FIPS 140-2 ברמה 1.
ההטמעה של TLS בשער הכניסה של Cloud Service Mesh מבוצעת באמצעות BoringSSL. בטבלה 1 מוצגים הפרוטוקולים של הצפנה ש-GDC תומך בהם בתקשורת עם לקוחות.
| פרוטוקולים | אימות | חילופי מפתחות | הצפנה | פונקציות גיבוב (Hash) |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
טבלה 1: הטמעת הצפנה בשער הכניסה של Cloud Service Mesh לשירותי GDC והטמעה בספרייה הקריפטוגרפית של BoringSSL
רשות אישורים שניתנת להגדרה ב-GDC
כחלק מ-TLS (אבטחת שכבת התעבורה), השרת שמקבל את בקשת החיבור חייב להוכיח את זהותו למשתמש. כדי לבצע את אימות הזהות (IDV) בפרוטוקול TLS, השרת צריך להציג אישור שמכיל את הזהות שעליה הוצהר. האישור מכיל את שם המארח של השרת ב-DNS ואת המפתח הציבורי שלו. לאחר שהאישור מוצג, הוא נחתם על ידי רשות אישורים (CA) מנפיקה שנחשבת מהימנה על ידי המשתמש שביקש את החיבור. כתוצאה מכך, משתמשים שמבקשים חיבורים לשרת צריכים רק לבטוח ברשות האישורים (CA) ברמה הבסיסית. אם רוצים לאפשר גישה לשרת מכל מקום, רשות האישורים ברמה הבסיסית צריכה להיות מוכרת לכל מכשיר לקוח פוטנציאלי. הדפדפנים והמכשירים של הלקוחות מוגדרים עם קבוצה של רשויות אישורים ברמה הבסיסית שהם סומכים עליהן, בהתאם לסביבה שבה הלקוח פועל.
רשות האישורים הבסיסית של GDC תלויה בסביבה שבה היא נפרסת, ובדרישות של הלקוחות בסביבה הזו.
משער הכניסה של Cloud Service Mesh לממשקי הקצה של האפליקציות
שני מקרים:
- שער הכניסה של Cloud Service Mesh מסיים את ה-TLS, ומצפין מחדש את ה-mTLS באמצעות אישורי Istio של Cloud Service Mesh
- mTLS משער Ingress לממשק הקצה של אפליקציית Istio Sidecar
- Cloud Service Mesh Ingress Gateway מסיים את ה-TLS, מצפין מחדש את ה-TLS לשרת אחר, עם CA מוגדר.
הצפנת רשת של תנועת אחסון
במערכת האחסון של קבצים ואחסון בלוקים ב-GDC, תעבורת הנתונים מנותבת בין האפליקציה שמשתמשת באחסון לבין שירות האחסון. הנתונים האלה מאומתים ומוצפנים בזמן ההעברה באמצעות IPSec. בקרוב תהיה זמינה הצפנה מצד הלקוח לתנועה באחסון. מצב ההעברה של IPSec משמש בין תעבורת הנתונים של הקבצים והבלוקים לבין המארח שצריך לגשת לאחסון. האימות מתבצע באמצעות מפתח ששותף מראש, שנוצר תוך כדי תנועה ומאוחסן באופן מאובטח ב-GDC. אחרי שנוצרת התאמת אבטחה (SA) של IPSec, המידע מועבר באמצעות מנהרת IPSec. החבילות מוצפנות ומפוענחות באמצעות הצפנה קריפטוגרפית שתואמת ל-FIPS, שצוינה ב-IPSec SA.
אימות, תקינות והצפנה בין שירותים
בשכבת האפליקציה (שכבה 7) בתשתית של GDC, אנחנו משתמשים ב-mTLS או ב-TLS לצורך האימות, התקינות וההצפנה של קריאות RPC משער הכניסה של Cloud Service Mesh לשירות מסוים, ובין שירותים ב-GDC. כל שירות שפועל ב-GDC פועל בזהות של חשבון שירות עם פרטי כניסה קריפטוגרפיים משויכים. כשמתקשרים באמצעות mTLS דרך Cloud Service Mesh, שירותי GDC משתמשים באישורי לקוח כדי לאמת שירותים אחרים. האימות של האישורים האלה ב-Cloud Service Mesh מתבצע באמצעות רשות אישורים פנימית. כשמתקשרים באמצעות TLS, לדוגמה לשרת API של GDC Kubernetes, שירותי GDC משתמשים באסימונים של חשבונות שירות ב-Kubernetes כדי לאמת את השירותים. האסימונים של חשבון השירות של Kubernetes מאומתים באמצעות המפתחות הציבוריים של מנפיק האסימונים של שרת ה-API של Kubernetes.