הצפנה בכל Google Cloud האזורים
כל תעבורת הנתונים מ-VM ל-VM בתוך רשת VPC ורשת VPC שמקושרת לרשתות שכנות, עוברת הצפנה.
הצפנה בין מאזני עומסים של שרתי proxy לבין קצה עורפי
במאזני עומסים מסוימים של שרת proxy (ראו טבלה 1), Google מצפינה באופן אוטומטי את התנועה אל השרתים העורפיים שנמצאים ברשתות Google Cloud VPC. ההצפנה הזו נקראת הצפנה אוטומטית ברמת הרשת. ההצפנה האוטומטית ברמת הרשת חלה רק על תקשורת עם סוגי ה-Backend הבאים:
- קבוצות של מכונות
- Zonal NEGs (נקודות קצה
GCE_VM_IP_PORT)
בנוסף, Google Cloud מספקת אפשרויות לפרוטוקולים מאובטחים להצפנת התקשורת עם שירות הקצה העורפי.
חלק ממאזני העומסים משתמשים בממשקי קצה של Google (GFE) כלקוח לשרתי הקצה, ואחרים משתמשים בEnvoy proxy בקוד פתוח. Google Cloud בכל המקרים, מאזן העומסים תומך בסטים של אלגוריתמים להצפנה (cipher suites) שמפורטים בסעיף 9.1 ב-RFC 8446 עבור TLS 1.3. ב-TLS 1.2 ובגרסאות קודמות, מאזן העומסים תומך בחבילות ההצפנה שמשויכות לפרופיל מדיניות SSL COMPATIBLE.
בטבלה הבאה מפורטים מאזני העומסים של ה-proxy שמצפינים את התנועה לשרתי הקצה.
| מאזן עומסים של שרת proxy | שרת Proxy (מהלקוח אל ה-Backend) | הצפנה אוטומטית ברמת הרשת | אפשרויות פרוטוקול של שירות לקצה העורפי |
|---|---|---|---|
| מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) | GFE (עם תוכנת Envoy לתכונות מתקדמות של ניתוב) | HTTP, HTTPS ו-HTTP/2 בוחרים באפשרות HTTPS או HTTP/2 אם נדרשת הצפנה בנתונים בזמן העברה שניתנת לביקורת בקצה העורפי. |
|
| מאזן עומסים קלאסי של אפליקציות (ALB) | GFE | HTTP, HTTPS ו-HTTP/2 בוחרים באפשרות HTTPS או HTTP/2 אם נדרשת הצפנה בנתונים בזמן העברה שניתנת לביקורת בקצה העורפי. |
|
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | שרת proxy של Envoy | HTTP, HTTPS ו-HTTP/2 בוחרים באפשרות HTTPS או HTTP/2 אם נדרשת הצפנה בנתונים בזמן העברה שניתנת לביקורת בקצה העורפי. |
|
| מאזן עומסים פנימי אזורי של אפליקציות (ALB) | שרת proxy של Envoy | HTTP, HTTPS ו-HTTP/2 בוחרים באפשרות HTTPS או HTTP/2 אם נדרשת הצפנה בנתונים בזמן העברה שניתנת לביקורת בקצה העורפי. |
|
| מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים | שרת proxy של Envoy | HTTP, HTTPS ו-HTTP/2 בוחרים באפשרות HTTPS או HTTP/2 אם נדרשת הצפנה בנתונים בזמן העברה שניתנת לביקורת בקצה העורפי. |
|
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy | GFE (עם תוכנת Envoy לתכונות מתקדמות של ניתוב) | SSL או TCP בוחרים באפשרות SSL לפרוטוקול של שירות הקצה העורפי אם נדרשת הצפנה בשידור שניתנת לביקורת לקצה העורפי. |
|
| מאזן עומסי רשת קלאסי בשרת proxy | GFE | SSL או TCP בוחרים באפשרות SSL לפרוטוקול של שירות הקצה העורפי אם נדרשת הצפנה בשידור שניתנת לביקורת לקצה העורפי. |
|
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | שרת proxy של Envoy | TCP | |
| מאזן עומסי רשת פנימי אזורי בשרת proxy | שרת proxy של Envoy | TCP | |
| מאזן עומסי רשת פנימי בשרת proxy בין אזורים | שרת proxy של Envoy | TCP | |
| Cloud Service Mesh | שרת proxy בצד הלקוח | HTTPS ו-HTTP/2 |
תרחישי שימוש בפרוטוקול מאובטח של קצה עורפי
מומלץ להשתמש בפרוטוקול מאובטח כדי להתחבר למכונות קצה (backend) במקרים הבאים:
כשנדרש חיבור מוצפן שניתן לביקורת ממאזן העומסים (או מ-Cloud Service Mesh) למופעי הבק-אנד.
כשמאזן העומסים מתחבר לשרת עורפי שאינו נמצא ב-Google Cloud (עם NEG לאינטרנט). תקשורת עם קצה עורפי של NEG באינטרנט עשויה לעבור דרך האינטרנט הציבורי. כשמאזן העומסים מתחבר ל-NEG באינטרנט, האישור הציבורי שחתום על ידי CA צריך לעמוד בדרישות האימות.
שיקולים לגבי פרוטוקול מאובטח של ה-backend
כשמשתמשים בפרוטוקול מאובטח של שירות קצה עורפי, חשוב לזכור את הנקודות הבאות:
הנקודות או המופעים של הקצה העורפי של מאזן העומסים צריכים לפעול באמצעות אותו פרוטוקול כמו שירות הקצה העורפי. לדוגמה, אם הפרוטוקול של שירות לקצה העורפי הוא HTTPS, הבק-אנד צריך להיות שרתי HTTPS.
אם פרוטוקול שירות לקצה העורפי הוא HTTP/2, הבק-אנדים חייבים להשתמש ב-TLS. הוראות להגדרה מופיעות במסמכי התיעוד של התוכנה שפועלת במופעי הקצה או בנקודות הקצה של ה-Backend.
כדי שהם יפעלו כשרתי HTTPS או SSL, צריך להתקין מפתחות פרטיים ואישורים במופעי ה-Backend או בנקודות הקצה. האישורים האלה לא צריכים להיות זהים לאישורי ה-SSL של הקצה הקדמי של מאזן העומסים. הוראות ההתקנה מופיעות במסמכי התיעוד של התוכנה שפועלת במופעים או בנקודות הקצה של ה-Backend.
חוץ ממאזני עומסים מסוג HTTPS עם קצה עורפי של NEG באינטרנט, מאזני עומסים לא משתמשים בתוסף Server Name Indication (SNI) לחיבורים לקצה העורפי.
כשמאזן עומסים מתחבר לשרתי בק-אנד שנמצאים בתוך Google Cloud, מאזן העומסים מקבל כל אישור ששרתי הבק-אנד מציגים. במקרה כזה, מאזן העומסים מבצע רק אימות מינימלי של האישור.
לדוגמה, אישורים נחשבים תקפים גם בנסיבות הבאות:
- האישור הוא עם חתימה עצמית.
- האישור נחתם על ידי רשות אישורים (CA) לא מוכרת.
- האישור לא בתוקף או שתוקפו פג.
- המאפיינים
CNו-subjectAlternativeNameלא תואמים לכותרתHostאו לרשומת PTR של DNS.
באישורי RSA, החל מ-28 באפריל 2025, מאזן העומסים יקבל רק אישורי RSA שכוללים את התוסף X509v3 Key Usage, וגם את הפרמטרים Digital Signature ו-Key Encipherment. מידע נוסף זמין בהערת הגרסה שפורסמה ב-24 בינואר 2025.
פרוטוקולים מאובטחים של הקצה הקדמי
כשמשתמשים ב-HTTPS או בשרת proxy של SSL כיעד כחלק מההגדרה,Google Cloud משתמש בפרוטוקול מאובטח של חזית האתר.
מאזני עומסים חיצוניים של אפליקציות (ALB) ומאזני עומסי רשת חיצוניים לשרת proxy משתמשים בספריית BoringCrypto של Google. פרטים על FIPS 140-2 זמינים באישור #3678 של תוכנית האימות של מודול קריפטוגרפי של NIST.
מאזני עומסים פנימיים של אפליקציות (ALB) משתמשים בספריית BoringSSL של Google. פרטים על FIPS 140-2 מופיעים במסמכי Envoy. Google בונה שרתי proxy של Envoy למאזני עומסים פנימיים של אפליקציות במצב תאימות ל-FIPS.
Cloud Service Mesh תומך בשרתי proxy של Envoy שנוצרו במצב תאימות ל-FIPS.