במאמר הזה מוסבר על הצפנה במעבר ב-Google Distributed Cloud (GDC) במודל Air-gapped.
סיכום ברמת מנהל מערכות המידע
- GDC משתמשת במספר אמצעי אבטחה כדי להבטיח את האותנטיות, התקינות והסודיות של נתונים במעבר.
- GDC מיישמת על הנתונים במעבר את הגנות ברירת המחדל בהתאם לסוג החיבור שנוצר עבור רכיבי GDC. לדוגמה, את התקשורת בין המשתמש לבין שער הכניסה של GDC Cloud Service Mesh אנחנו מאבטחים באמצעות 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.
הצפנה משמשת להגנה על נתונים בכמה מצבים:
- הצפנה במנוחה נועדה להגן על הנתונים מפני פריצה למערכת וזליגת נתונים, על ידי הצפנת הנתונים בזמן האחסון. במקרים רבים הנתונים באחסון מוצפנים באמצעות תקן הצפנה מתקדם (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 ושירות מנוהל
שירותים מנוהלים שמתארחים ב-Cloud Service Mesh Ingress Gateways מקבלים בקשות מרשת הלקוח באמצעות Cloud Service Mesh Ingress Gateway. שער הכניסה של Cloud Service Mesh משמש כשרת proxy לתעבורת נתונים נכנסת ב-HTTP(S), ומנתב ומאזן עומסים של תעבורת נתונים לשירותים שמנוהלים על ידי GDC. שכבת חומת אש נוספת מספקת אמצעי נגד להתקפות DDoS עם גילוי חדירות ומניעה. החיבור הזה מאומת ומוצפן מ-Cloud Service Mesh Ingress Gateway עד לממשק הקצה הקדמי של השירות שמנוהל על ידי GDC. איור 1 מציג את האינטראקציה הזו כחיבור A.
רוב ממשקי ה-API והשירותים המנוהלים של GDC מתארחים בשערי כניסה של 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 מאפשרת להגדיר מדיניות של תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) לאנשי הצוות המתאימים. איור 1 מציג את האינטראקציה הזו כחיבור F.
שירות GDC cross-site interconnect
הניתוב משירות מנוהל אחד לשירות מנוהל אחר מתבצע בדרך כלל באופן מלא בתוך הגבול הפיזי של GDC. במקרים מסוימים, כמו גיבוי חוצה אתרים, הנתונים מנותבים אל מחוץ לגבול הפיזי של GDC. במקרה כזה, הנתונים מוצפנים גם בשכבת האפליקציה, למשל TLS, ויכולים להיות מוצפנים גם בשכבת הרשת. איור 1 מציג את האינטראקציה הזו כחיבור G.
ממכונה וירטואלית למכונה וירטואלית
החיבורים בין מכונות וירטואליות ב-GDC לא מוצפנים ברמת הרשת. הלקוחות אחראים להצפנת הנתונים באמצעות פרוטוקולים מוצפנים מתאימים או טכנולוגיות ספציפיות כמו מנהרות IPSec.
הצפנה של נתונים במעבר כברירת מחדל
GDC משתמשת בשיטות שונות להצפנה של נתונים במעבר – גם כאלו עם הגדרות ברירת מחדל וגם כאלו עם הגדרות שהמשתמש יכול לשנות. סוג ההצפנה שבו משתמשים תלוי בשכבת ה-OSI, בסוג השירות וברכיב הפיזי של התשתית. בקטע הזה מתוארות הגנות ברירת המחדל שבהן Google משתמשת כדי להגן על נתונים במעבר.
בהמשך מתוארות הגנות ברירת המחדל שבהן Google משתמשת כדי להגן על נתונים במעבר.
הצפנה ממשתמשים לשער כניסה של Cloud Service Mesh
כיום, הרבה מערכות משתמשות בפרוטוקול HTTPS כדי לתקשר באינטרנט. הפרוטוקול מספק אבטחה באמצעות חיבור TLS (אבטחת שכבת התעבורה) שמבטיח את האותנטיות, התקינות והסודיות של בקשות ותשובות. כדי שאפשר יהיה לאשר בקשות HTTPS בצד המקבל, לצורך אימות השרת נדרש זוג מפתחות ציבורי/פרטי ואישור X.509 שהונפק על ידי רשות אישורים (CA). באמצעות זוג המפתחות והאישור אפשר לאמת בקשות של משתמש בשכבת האפליקציה (שכבה 7), כי הם מוכיחים שהצד המקבל הוא הבעלים של שם הדומיין שעבורו מיועדות הבקשות. בתת-הסעיפים הבאים מתוארים הרכיבים המשמשים להצפנה ממשתמש ל-Cloud Service Mesh Ingress Gateway: TLS (אבטחת שכבת התעבורה), BoringSSL ורשות האישורים של GDC שניתנת להגדרה.
Transport layer security (TLS)
כשאתם שולחים בקשה לשירות של GDC, אנחנו מאבטחים את הנתונים במעבר. ההגנה מספקת אימות, תקינות והצפנה באמצעות פרוטוקול HTTPS עם אישור מרשות אישורים מהימנה. כל הנתונים שהמשתמש שולח ל-Cloud Service Mesh Ingress Gateway עבור השירות שמנוהל על ידי 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) ברמה הבסיסית. אם רוצים לאפשר גישה לשרת מכל מקום, רשות האישורים ברמה הבסיסית צריכה להיות מוכרת לכל מכשיר לקוח פוטנציאלי. דפדפנים ומכשירים של לקוחות מוגדרים עם קבוצה של רשויות אישורים (CA) בסיסיות שהם סומכים עליהן, בהתאם לסביבה שבה הלקוח פועל.
ה-CA הבסיסי של GDC תלוי בסביבה שבה הוא נפרס ובדרישות של הלקוחות בסביבה הזו.
מ-Cloud Service Mesh Ingress Gateway לממשקי קצה של אפליקציות
שני מקרים:
- שער הכניסה של Cloud Service Mesh מסיים את ה-TLS, מצפין מחדש את ה-mTLS באמצעות אישורים של Cloud Service Mesh Istio
- mTLS משער Ingress ל-Istio Sidecar Application Frontend
- שער הכניסה של Cloud Service Mesh מפסיק את ה-TLS, מצפין מחדש את ה-TLS לשרת אחר, עם CA מוגדר.
הצפנת תנועה ברשת של אחסון
במערכת האחסון של קבצים ואחסון בלוקים (block storage) ב-GDC, תעבורת הנתונים מנותבת בין האפליקציה שמשתמשת באחסון לבין שירות האחסון. הנתונים האלה מאומתים ומוצפנים בזמן ההעברה באמצעות IPSec. בקרוב תהיה זמינה הצפנה מצד הלקוח לתעבורת הנתונים באחסון. מצב התעבורה של IPSec משמש בין קובץ לתעבורת בלוקים למארח שצריך לגשת לאחסון. האימות מתבצע באמצעות מפתח משותף מראש שנוצר בטיסה ומאוחסן בצורה מאובטחת ב-GDC. אחרי שנוצר IPSec SAs, המידע מועבר באמצעות מנהרת IPSec. החבילות מוצפנות ומפוענחות באמצעות הצפנה קריפטוגרפית שתואמת ל-FIPS, שצוינה ב-IPSec SA.
אימות, תקינות והצפנה בין שירותים
בשכבת האפליקציה (שכבה 7) בתשתית של GDC, אנחנו משתמשים ב-mTLS או ב-TLS לצורך האימות, התקינות וההצפנה של קריאות RPC משער הכניסה של Cloud Service Mesh לשירות מסוים, ומשירות GDC אחד לשירות GDC אחר. כל שירות שפועל ב-GDC פועל בזהות של חשבון שירות עם פרטי כניסה קריפטוגרפיים משויכים. כשמתקשרים באמצעות mTLS דרך Cloud Service Mesh, שירותי GDC משתמשים באישורי לקוח כדי לבצע אימות מול שירותים אחרים. ב-Cloud Service Mesh, האימות של האישורים האלה מתבצע באמצעות רשות אישורים פנימית. כשמתקשרים באמצעות TLS, למשל לשרת GDC Kubernetes API, שירותי GDC משתמשים באסימונים של חשבון שירות ב-Kubernetes כדי לבצע אימות לשירותים. אסימונים של חשבון שירות ב-Kubernetes מאומתים באמצעות המפתחות הציבוריים של מנפיק האסימונים של Kubernetes API Server.