הצפנה בזמן ההעברה ב-Google Cloud

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

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

הצפנה בזמן העברה מתבססת על טכנולוגיות שונות להגנה על נתונים, כולל Transport Layer Security ‏ (TLS),‏ BoringSSL,‏ Application Layer Transport Security ‏(ALTS) ופרוטוקול האבטחה של PSP. בנוסף להגנה ש-Google מספקת כברירת מחדל, אתם יכולים להוסיף אפשרויות הצפנה כמו IPsec, אישורים מנוהלים של TLS ו-Cloud Service Mesh כדי להגן על הנתונים.

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

אימות, תקינות והצפנה

‫Google משתמשת באמצעי האבטחה הבאים כדי להבטיח את האותנטיות, התקינות והפרטיות של נתונים במעבר:

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

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

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

איך מנותבת תעבורת הנתונים

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

Google Cloud שירות הוא שירות מודולרי בענן שאנחנו מציעים ללקוחות שלנו. השירותים האלה כוללים שירותי מחשוב, אחסון נתונים, ניתוח נתונים ולמידת מכונה. לדוגמה, Cloud Storage הוא שירות. Google Cloud

אפליקציית לקוח היא אפליקציה שמתארחת ב- Google Cloud , ואתם, כלקוחות Google, יכולים ליצור ולפרוס אותה באמצעות שירותי Google Cloud. האפליקציות של הלקוחות או פתרונות של שותפים שמתארחים ב-Google Cloud לא נחשבים לשירותים של Google Cloud . לדוגמה, אפליקציה שאתם יוצרים באמצעות Cloud Run,‏ Google Kubernetes Engine או מכונה וירטואלית ב-Compute Engine היא אפליקציית לקוח.

בתרשים הבא מוצגים נתיבי תעבורה ממשתמש הקצה אל Google, נתיבים בתוך הרשת של Google ואמצעי האבטחה לכל חיבור. מוצגים נתיבי התנועה הבאים:

  • ממשתמש קצה באינטרנט לשירות Google Cloud (מסומן באות A בתרשים)
  • ממשתמש קצה באינטרנט לאפליקציית לקוח שמתארחת ב-Google Cloud (מסומנת באות B בתרשים)
  • ממכונה וירטואלית למכונה וירטואלית (מסומן באות C בתרשים)
  • ממכונה וירטואלית לממשק קצה של Google‏ (GFE) (מסומן באות D בתרשים)
  • ‫GFE לממשקי API ולשירותים של Google (מסומן באות E בתרשים)
  • Google Cloud שירות אל Google Cloud שירות (מסומן באות F בדיאגרמה)

נתיבי תנועה ל-Google.

הצפנה בזמן ההעברה בין משתמש הקצה לבין Google

בקטעים הבאים מפורטים יותר נתוני הבקשות לניתוב משתמשי הקצה שמוצגים בתרשים שלמעלה.

משתמש קצה לשירות של Google Cloud

Google Cloud שירותים כמו Cloud Storage או Compute Engine הם שירותי ענן שאנחנו מציעים ללקוחות ופועלים בסביבת הייצור שלנו. Google Cloud השירותים האלה מקבלים בקשות מרחבי העולם באמצעות מערכת מבוזרת גלובלית שנקראת ממשק הקצה של Google‏ (GFE). ‫GFE מסיים את תעבורת הנתונים הנכנסת בחיבורי HTTP(S), ‏ TCP ו-TLS (אבטחת שכבת התעבורה), מספק אמצעי נגד להתקפות DDoS וכן מאזן עומסים ומנתב את תעבורת הנתונים לשירותים עצמםGoogle Cloud . ברחבי העולם יש נקודות point of presence‏ (PoP) של GFE עם נתיבים שמפורסמים באמצעות Uncast או Anycast.

‫GFE מנתב תעבורת נתונים ממשתמש קצה דרך הרשת של Google אלGoogle Cloud שירות, וממשתמש קצה אל אפליקציית לקוח שמתארחת ב- Google Cloud Google Cloud ומשתמשת ב-Cloud Load Balancing.

בקשות שמועברות מלקוחות אל Google Cloud שירות באמצעות HTTPS,‏ HTTP/2 או HTTP/3 מאובטחות באמצעות TLS. ההטמעה של TLS ב-GFE מבוצעת באמצעות BoringSSL, הטמעה של פרוטוקול TLS בקוד פתוח שמנוהלת על ידי Google. המודול BoringCrypto, המשמש כליבה של BoringSSL, אומת להסמכת FIPS 140-3 ברמה 1.

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

ממשתמש קצה לאפליקציית לקוח שמתארחת ב- Google Cloud

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

אתם יכולים להשתמש ב-TLS עם מאזן עומסים חיצוני של אפליקציות (ALB) או במאזן עומסי רשת בשרת proxy חיצוני כדי להתחבר לאפליקציה שפועלת ב- Google Cloud. כשמשתמשים במאזן עומסים בשכבה 7, החיבור בין משתמש הקצה לבין מאזן העומסים מוצפן באמצעות TLS כברירת מחדל (בתנאי שאפליקציית הלקוח של משתמש הקצה תומכת ב-TLS). ‏GFE מסיים את חיבורי TLS ממשתמשי הקצה שלכם באמצעות אישורי TLS בניהול עצמי או בניהול Google. מידע נוסף על התאמה אישית של האישורים זמין בסקירה הכללית על אישורי SSL. כדי להפעיל הצפנה בין מאזן העומסים לבין מכונת ה-VM שמארחת את אפליקציית הלקוח, קראו את המאמר הצפנה ממאזן העומסים לקצה העורפי.

כדי להגדיר TLS דו-צדדי (mTLS), אפשר לעיין במאמר סקירה כללית של TLS דו-צדדי. שימוש ב-Cloud Service Mesh בעומסי עבודה ב-GKE וב-Compute Engine, כדי שתוכלו להשתמש ב-mTLS לאימות הדדי (לקוח ושרת) ולהצפין את התקשורת במעבר באמצעות אישורים שאתם מנהלים.

לאירוח ב-Firebase ולדומיינים מותאמים אישית ב-Cloud Run, כדאי להשתמש באישורי TLS האוטומטיים והחינמיים שלנו. באמצעות דומיינים מותאמים אישית ב-Cloud Run, תוכלו גם לספק אישורי SSL משלכם ולהשתמש בכותרת HTTP Strict Transport Security‏ (HSTS).

הצפנה במעבר ברשתות של Google

‫Google Cloud הצפנה של נתוני לקוחות במעבר ברשתות של Google, אלא אם צוין אחרת בסעיף הזה.

חיבורים ייעודיים עם ביצועים גבוהים במיוחד שמקשרים בין TPU או GPU במחשבי העל של Google AI, נפרדים מהרשתות שמתוארות במסמך הזה. ב- Google Cloud, חיבורים מהירים במיוחד בין רכיבים הם ICI ל-TPU ו-NVLink ל-GPU. מידע נוסף זמין במאמרים בנושא ארכיטקטורת TPU וסוגי מכונות GPU.

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

Google Cloud אימות והצפנה של רשתות וירטואליות

Google Cloudהרשת הווירטואלית של Google Cloud מצפינה את תעבורת הנתונים בין המכונות הווירטואליות, מגנה על השלמות שלה ומאמתת אותה.

ההצפנה של תעבורת נתונים מכתובת IP פרטית באותה רשת VPC או ברשתות VPC שכנות ומקושרות ברשת הווירטואלית של Google Cloud, מתבצעת בשכבת הרשת.

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

החיבורים בין מכונות וירטואליות בתוך רשתות VPC או רשתות VPC שמקושרות לרשתות שכנות ברשת של סביבת הייצור של Google, עוברים הצפנה ומוגנים מפני שינויים לא מורשים. החיבורים האלה כוללים חיבורים בין מכונות וירטואליות של הלקוחות לבין מכונות וירטואליות המנוהלות על ידי הלקוח או על ידי Google, כמו Cloud SQL. התרשים במאמר איך התנועה מנותבת מציג את האינטראקציה הזו (החיבור המסומן בתווית C). חשוב לזכור: Google מפעילה הצפנה אוטומטית על סמך השימוש בכתובות IP פנימיות, ולכן חיבורים בין מכונות וירטואליות באמצעות כתובות IP חיצוניות לא מוצפנים באופן אוטומטי.

Google Cloudהרשת הווירטואלית של Google Cloud מאמתת את כל תעבורת הנתונים בין המכונות הווירטואליות. האימות ברמת הרשת, שמנוהל באמצעות אסימוני אבטחה, מספק הגנה מפני שליחת חבילות (packets) מזויפות ברשת כאשר מארח נפרץ.

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

קישוריות לממשקי API ולשירותים של Google

הטיפול בתעבורת הנתונים משתנה בהתאם למיקום שבו מתארח השירות Google Cloud .

רוב ממשקי ה-API והשירותים של Google מתארחים בממשקי קצה של Google‏ (GFE). בתעבורת הנתונים ממכונות וירטואליות ל-GFE נעשה שימוש בכתובות IP חיצוניות כדי להגיע לשירותים, אבל אפשר להגדיר גישה פרטית כדי להימנע משימוש בכתובות IP חיצוניות. Google Cloud החיבור בין GFE לשירות עובר אימות והצפנה.

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

כשמשתמש שולח בקשה לשירות, אנחנו מאבטחים את הנתונים במעבר (מספקים אימות, תקינות והצפנה) באמצעות פרוטוקול HTTPS עם אישור מרשות אישורים (ציבורית) באינטרנט. Google Cloud כל הנתונים שהמשתמש שולח ל-GFE מוצפנים בזמן המעבר באמצעות TLS או QUIC. בין הלקוח לבין GFE מתנהל משא ומתן לגבי פרוטוקול הצפנה מסוים, בהתאם למה שנתמך בצד הלקוח. כשהדבר אפשרי, המשא ומתן מול GFE יתקיים גם לגבי פרוטוקולים מודרניים יותר של הצפנה.

אימות, תקינות והצפנה בין שירותים

בתשתית של Google נעשה שימוש ב-ALTS לצורך האימות, התקינות וההצפנה של חיבורים מ-GFE ל Google Cloud שירות, ומשירות Google Cloud אחד לשירות Google Cloud אחר.

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

‫ALTS משתמשת בהצפנה ובהגנה קריפטוגרפית על התקינות של התנועה שנושאת Google Cloud נתונים מ-GFE לשירות מסוים ובין שירותים שפועלים בסביבת הייצור של Google.

במנגנוני RPC שמשמשים את תעבורת הנתונים בין ממשקי קצה של Google לבין שירותי Google Cloud, נעשה שימוש ב-ALTS גם כדי לבצע אנקפסולציה של הקריאות עבור פרוטוקולים אחרים בשכבה 7, כמו HTTP. ההגנה הזו עוזרת לבודד את שכבת האפליקציה ומסירה כל תלות באבטחה של נתיב הרשת.

שיטות הצפנה בזמן ההעברה

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

הצפנת רשתות באמצעות פרוטוקול PSP

פרוטוקול PSP הוא פרוטוקול שאינו תלוי בתשתית התקשורת, מאפשר אבטחה ברמת החיבור ותומך בהעברת ההצפנה לכרטיס רשת חכם (SmartNIC) בחומרה. בכל פעם שיש כרטיסי SmartNICs זמינים, מערכת ALTS משתמשת ב-PSP כדי להצפין את הנתונים במעבר ברשת שלנו.

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

אבטחת שכבת התעבורה של אפליקציות (ALTS)

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

  • פרוטוקול לחיצת יד: הלקוח יוזם החלפת מפתחות משולבת של עקומת אליפסה ומפתח בטוח מקוונטים. בסוף לחיצת היד, השירותים המעורבים מאמתים את הזהויות זה של זה על ידי החלפה ואימות של אישורים חתומים, ומחשבים מפתח משותף לתנועה. בין האלגוריתמים שנתמכים לגזירת מפתח התעבורה המשותף נמצא האלגוריתם הפוסט-קוונטי של NIST‏ ML-KEM (FIPS 203). מידע נוסף זמין במאמר בנושא קריפטוגרפיה פוסט-קוונטית.

  • פרוטוקול תיעוד: הנתונים משירות לשירות מוצפנים בזמן ההעברה באמצעות מפתח תעבורת הנתונים המשותף. כברירת מחדל, ALTS משתמש בהצפנת AES-128-GCM לכל התעבורה. הנתונים בזמן ההעברה במערכת האחסון ברמה הנמוכה ביותר של Google מוצפנים באמצעות AES-256, ו-ALTS מספקת אימות הודעות AES. ההצפנה ב-ALTS מסופקת על ידי BoringSSL או PSP. ההצפנה הזו מאומתת ברמה 1 של FIPS 140-2 או ברמה 1 של FIPS 140-3.

מפתחות החתימה של אישורים ברמה הבסיסית של ALTS מאוחסנים ברשות האישורים (CA) הפנימית של Google.

המאמרים הבאים