אישור באמצעות אישורי SSL/TLS

בדף הזה מוסבר איך להשתמש ב-שכבת שקע מאובטחת (SSL), שנקראת עכשיו Transport Layer Security‏ (TLS), מהאפליקציה כדי להצפין חיבורים למכונות של Cloud SQL.

סקירה כללית

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

אישורי שרת

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

אישורי לקוחות

אתם יכולים ליצור ולהוריד אישורי לקוח יחד עם מפתחות למכונה המארחת של הלקוח, לצורך אימות הדדי (אימות זהות של השרת והלקוח). אי אפשר לבחור את סוג ה-CA שבו Cloud SQL משתמש כדי לחתום על אישור הלקוח.

חיבור באמצעות SSL/TLS

כשמתחברים למכונה של Cloud SQL מלקוחות, אפשר להשתמש ב-SSL/TLS לחיבורים ישירים וגם לחיבורים שמשתמשים ב-Cloud SQL Auth Proxy או ב-Cloud SQL Language Connectors.

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

  • בחיבורים שמשתמשים ב-Cloud SQL Auth Proxy או במחברי שפה של Cloud SQL, החיבורים מוצפנים באופן אוטומטי באמצעות SSL/TLS, יחד עם אימות זהות של הלקוח והשרת, בלי שתצטרכו להוריד אישור CA של השרת ואישור לקוח.

למידע נוסף על אפשרויות הקישוריות של Cloud SQL, קראו את המאמר מידע על חיבורי Cloud SQL.

מידע נוסף על הגדרת SSL/TLS בצד הלקוח זמין במסמכי התיעוד של המנוע של מסד הנתונים.

היררכיות של רשויות אישורים (CA)

בקטע הזה מתוארים שלושת הסוגים של רשויות אישורים (CA) לשרתים שאפשר לבחור למכונות Cloud SQL. יש 3 אפשרויות:

  • ‫Per-instance CA: באפשרות הזו, רשות אישורים פנימית שמוקדשת לכל מכונה של Cloud SQL חותמת על אישור השרת של אותה מכונה. מערכת Cloud SQL יוצרת ומנהלת את רשויות האישורים האלה. כדי לבחור רשות אישורים לכל מכונה, בוחרים באפשרות Google managed internal certificate authority (Google Cloud מסוף) או מציינים את GOOGLE_MANAGED_INTERNAL_CA בהגדרה serverCaMode (Cloud SQL Admin API) או בדגל --server-ca-mode (ה-CLI של gcloud) כשיוצרים את המכונה. אם לא מציינים את ההגדרה או הדגל כשיוצרים מכונה, האפשרות הזו היא ערך ברירת המחדל של המכונה. אי אפשר לעדכן מכונה כך שתשתמש באפשרות של רשות אישורים לכל מכונה, אם המכונה מוגדרת להשתמש ברשות אישורים משותפת או ברשות אישורים בניהול הלקוח.

  • ‫Shared CA: באפשרות הזו משתמשים בהיררכיית CA שמורכבת מ-CA ברמה הבסיסית ומ-CA משני ברמת השרת. רשויות האישורים המשניות של השרת באזור חותמות על אישורי השרת ומשותפות בין המכונות באזור. השימוש בהיררכיית CA משותפת עוזר כשמגדילים את מספר המכונות באזור, כי לא צריך לנהל רשויות אישורים ייחודיות למכונות נפרדות. אם תעברו ל-CA משותף (GOOGLE_MANAGED_CAS_CA), תוכלו להשתמש בחבילת CA אזורית אחת לכל המכונות באזור, וכך לפשט את ההגדרות בצד הלקוח. ‫Cloud SQL מארח ומנהל את רשות אישורי הבסיס (CA) ואת רשויות האישורים המשניות של השרת ב- Google CloudCertificate Authority Service (שירות CA). ‫Cloud SQL גם מטפל ברוטציה של אישורי CA בסיסיים ואישורי CA של שרתים משניים, ומספק קישורים שזמינים לציבור להורדה של חבילות אישורי CA. כדי לבחור רשות אישורים משותפת, בוחרים באפשרות Google managed CAS certificate authority במסוף Google Cloud או מציינים את הערך GOOGLE_MANAGED_CAS_CA בהגדרה serverCaMode (Cloud SQL Admin API) או בדגל --server-ca-mode (gcloud CLI) כשיוצרים או עורכים את המכונה. אם אתם משתמשים באפשרות של רשות אישורים לכל מכונה או באפשרות של רשות אישורים בניהול הלקוח, אתם יכולים לעדכן מכונה קיימת כדי להשתמש בהיררכיה של רשות אישורים משותפת.

  • רשות אישורים בניהול הלקוח: באפשרות הזו אתם יוצרים ומנהלים היררכיית רשות אישורים משלכם. כדאי לבחור באפשרות הזו אם רוצים לנהל את רשויות האישורים והאישורים בעצמכם. באמצעות רשות אישורים בניהול הלקוח (CUSTOMER_MANAGED_CAS_CA), אתם יכולים לנהל את היררכיית רשויות האישורים ואת מדיניות הרוטציה שלכם באמצעות CA Service. ההגדרה הזו נותנת לכם יותר שליטה ועוזרת לכם לעמוד בדרישות התאימות. כדי לבחור רשות אישורים בניהול הלקוח, צריך ליצור מאגר רשויות להנפקת אישורים ורשות להנפקת אישורים ב-CA Service. ב-Cloud SQL, מציינים את מאגר ה-CA ואת רשות האישורים של CAS בניהול הלקוח (Google Cloud מסוף), CUSTOMER_MANAGED_CAS_CA להגדרה serverCaMode (Cloud SQL Admin API) או הדגל --server-ca-mode (ה-CLI של gcloud) כשיוצרים או עורכים את המכונה. אם אתם משתמשים באפשרות של רשות אישורים לכל מכונה או באפשרות של רשות אישורים משותפת, אתם יכולים לעדכן מכונה קיימת כך שתשתמש בהיררכיית רשות אישורים בניהול הלקוח.

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

בטבלה הבאה מוצגת השוואה בין שלוש האפשרויות של היררכיית ה-CA.

התכונה רשות אישורים לכל מכונה רשות אישורים משותפת רשות אישורים בניהול הלקוח
מבנה רשות האישורים רשות אישורים נפרדת לכל מכונה רשות אישורים בסיסית ורשויות אישורים משניות שמשותפות בין מכונות באותו אזור היררכיית רשויות אישורים שאתם יוצרים ומנהלים
מאפיינים קריפטוגרפיים מפתח RSA של 2048 ביט עם אלגוריתם SHA256 אלגוריתם חתימה דיגיטלית של עקומה אליפטית (ECDSA) עם מפתח של 384 ביט עם אלגוריתם SHA384 אלגוריתם חתימה דיגיטלית של עקומה אליפטית (ECDSA) עם מפתח של 384 ביט עם אלגוריתם SHA384
תקופת התוקף של רשות האישורים ‫10 שנים ‫25 שנים לרשות אישורי בסיס ו-10 שנים לרשויות אישורים משניות ניתן להגדרה *
תקופת התוקף של אישור השרת ‫10 שנים שנה אחת שנה**
רוטציה של רשות אישורים (CA) ביוזמת המשתמש? כן לא. רוטציית ה-CA מנוהלת על ידי Cloud SQL כן
האם המשתמש יזם את הרוטציה של אישור השרת? כן כן כן
רוטציה אוטומטית של אישור השרת? לא כן כן
ישות עוגן אמינה של רשות אישורים לחיבורי TLS רשות האישורים הייחודית לכל מכונה היא ישות העוגן האמינה של המכונה המתאימה. רשות אישורים בסיסית ורשויות אישורים משניות הן ישויות העוגן האמינות לכל המכונות באזור נתון. רשויות האישורים שאתם יוצרים ומנהלים הן ישויות העוגן האמינות.
אימות זהות השרת אימות ה-CA מאמת את זהות השרת, כי לכל מכונה יש CA ייחודי. כדי לאמת את זהות השרת, צריך לאמת את שם המארח יחד עם אימות ה-CA, כי רשויות האישורים של השרת משותפות בין המכונות. יכול להיות שרשות האישורים לא משותפת בין המופעים, אבל כדאי לאמת את שם המארח יחד עם אימות רשות האישורים.
השדה "שם חלופי של בעלים" (SAN) באישורי שרת השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) רק במכונות שמופעל בהן Private Service Connect. אפשר להשתמש בשם המארח כדי לאמת את זהות השרת. אם אתם מתחברים למכונה של Cloud SQL באמצעות שם ה-DNS כשם המארח, אתם צריכים להגדיר פענוח DNS. השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) של כל סוגי המכונות. אפשר להשתמש בשם המארח כדי לאמת את זהות השרת. אם אתם מתחברים למכונה של Cloud SQL באמצעות שם ה-DNS כשם המארח, אתם צריכים להגדיר פענוח DNS. השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) של כל סוגי המכונות. אפשר להשתמש בשם המארח כדי לאמת את זהות השרת.
תמיכה בגרסאות של Cloud SQL Auth Proxy תמיכה בכל הגרסאות של Cloud SQL Auth Proxy, גרסה 1 ואילך. נדרשת גרסה 2.13.0 ומעלה של Cloud SQL Auth Proxy. נדרשת גרסה 2.14.3 ומעלה של Cloud SQL Auth Proxy.
מגבלות על חיבור לשירות ללא לא תומך בחיבורים משירותי Google Cloudהבאים: לא תומך בחיבורים משירותי Google Cloudהבאים:
  • סביבת ברירת המחדל ב-App Engine
  • סביבה גמישה ב-App Engine
  • שירותי Cloud Run שפועלים בסביבת זמן ריצה מהדור הראשון

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

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

רשות אישורים לכל מכונה שמתארחת ב-Cloud SQL

היררכיית ה-CA לכל מכונה היא הגדרת ברירת המחדל של מצב ה-CA של השרת כשיוצרים מכונה באמצעות ה-CLI של gcloud, ‏Cloud SQL Admin API או Terraform.

כשיוצרים מכונה חדשה, Cloud SQL יוצר רשות אישורים חדשה לשרת עם חתימה עצמית לכל מכונה. כדי להשתמש בהגדרה הזו, צריך להגדיר את serverCaMode ל-GOOGLE_MANAGED_INTERNAL_CA כשיוצרים את המכונה. אתם יכולים להשאיר את ההגדרה serverCaMode לא מוגדרת באמצעות Cloud SQL Admin API או ה-CLI של gcloud, או לבחור באפשרות Google internal Certificate Authority במסוף Google Cloud .

אי אפשר לעדכן את serverCaMode של מכונה שמשתמשת בהיררכיית CA משותפת או בהיררכיית CA בניהול הלקוח, כדי להשתמש בהיררכיית CA לכל מכונה.

בתרשים הבא מוצגת ההיררכיה של רשות האישורים לכל מכונה.

תרשים של היררכיית רשות אישורים פנימית לכל מכונה.

רשויות אישורים משותפות שמתארחות ב-CA Service

מודל ה-CA הזה של השרת מורכב מ-CA ברמה הבסיסית ומ-CA משניים של השרת בכל אזור. רשויות האישורים המשניות של השרת מנפיקות אישורים לשרת ומשותפות בין מכונות באזור. מערכת Cloud SQL מטפלת ברוטציה של רשויות האישורים (CA) של השרתים האזוריים המשותפים, ומספקת קישורים שזמינים לכולם להורדת חבילות אישורי ה-CA.

אתם יכולים להגדיר מכונה כך שתשתמש בהיררכיית רשויות אישורים של שרת, שבה רשויות האישורים המנפיקות משותפות בין המכונות באותו אזור. כדי להשתמש בהגדרה הזו, צריך להגדיר את serverCaMode לערך GOOGLE_MANAGED_CAS_CA כשיוצרים או עורכים את המכונה. אפשר גם לבחור באפשרות Google Managed CAS Certificate Authority במסוף Google Cloud .

בתרשים הבא מוצגת ההיררכיה של ה-CA המשותף.

תרשים של היררכיית רשות אישורים משותפת

רשויות אישורים בניהול הלקוח

מצב ה-CA הזה בשרת מאפשר לכם להגדיר היררכיית CA משלכם ב-CA Service.

כדי להשתמש באפשרות של רשות אישורים בניהול הלקוח ב-Cloud SQL, צריך ליצור מאגר רשויות להנפקת אישורים (CA) באותו אזור שבו נמצאות המכונות של Cloud SQL. לאחר מכן יוצרים לפחות רשות אישורים אחת. כשיוצרים את מכונת Cloud SQL, מציינים את המזהה של מאגר ה-CA בשדה serverCaPool ומגדירים את השדה serverCaMode עם הערך CUSTOMER_MANAGED_CAS_CA. שירות CA מספק CA ממאגר ה-CA ומשתמש בו כדי להנפיק את אישור השרת למכונה.

כשיוצרים רשויות אישורים ב-CA Service, אפשר ליצור רשות אישורים בסיסית או רשות אישורים משנית, בהתאם לתרחיש לדוגמה. לדוגמה, אם אתם מתכננים להגדיר היררכיה של רשות אישורים בסיסית או שרשרת לרשות אישורים חיצונית, כדאי ליצור רשות אישורים משנית.

בחרו באפשרות של רשות אישורים בניהול הלקוח רק אם אתם רוצים לנהל בעצמכם את רשויות האישורים והאישורים. מידע נוסף מופיע במאמר שימוש ב-CA בניהול הלקוח.

איך פועלת החלפת אישורים בשרת

ב-Cloud SQL יש דרכים להחליף את אישור השרת, כך שאפשר להחליף את האישור הישן באישור החדש בצורה חלקה לפני שתוקף האישור הישן פג.

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

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

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

לפני שתוקף האישור הנוכחי של השרת יפוג, צריך להוריד את קובץ ה-server-ca.pem החדש, שמכיל את פרטי האישור של השרת הנוכחי ושל השרת החדש. מעדכנים את לקוחות PostgreSQL כך שישתמשו בקובץ החדש, על ידי העתקה שלו לכל המכונות המארחות של לקוחות PostgreSQL והחלפת הקובץ הקיים.

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

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

תפוגת התוקף של אישור ה-SSL

במכונות Cloud SQL שמשתמשות ברשויות אישורים לכל מכונה (serverCaMode מוגדר ל-GOOGLE_MANAGED_INTERNAL_CA), אישורי ה-SSL תקפים ל-10 שנים. לפני שהאישורים האלה יפוגו, צריך לבצע רוטציה של אישורי CA של השרת.

במכונות שמשתמשות ברשויות אישורים משותפות (serverCaMode מוגדר ל-GOOGLE_MANAGED_CAS_CA), תוקף אישורי השרת הוא שנה אחת. לפני שהתוקף יפוג, צריך לבצע רוטציה של אישור השרת או להפעיל רוטציה אוטומטית של אישור השרת. תוקף האישור של רשות אישורי הבסיס (CA) הוא 25 שנים, ותוקף האישור של רשות האישורים המשנית המשותפת הוא 10 שנים. ‫Cloud SQL מטפל ברוטציה שלהם.

אם אתם משתמשים ב-CA בניהול הלקוח (serverCaMode מוגדר ל-CUSTOMER_MANAGED_CAS_CA), אתם יכולים לבצע רוטציה של אישורי CA על ידי רוטציה של רשויות האישורים במאגר רשויות האישורים שיצרתם. תקופת התפוגה של רשות אישורים היא בדרך כלל 10 שנים, אבל אפשר להגדיר תקופת תוקף קצרה יותר לרשות האישורים ב-CA Service.

כדי לבצע רוטציה של רשויות האישורים, משתמשים בתהליך הרוטציה של רשויות האישורים ב-CA Service. מידע נוסף זמין במאמר ניהול רוטציה של רשויות אישורים.

אם הלקוח מוגדר לאמת את ה-CA או את שם המארח באישור השרת, החיבורים של הלקוח למכונות Cloud SQL עם אישורי שרת שפג תוקפם ייכשלו. כדי למנוע שיבושים בחיבורים של הלקוחות, צריך להחליף את אישור השרת לפני שהתוקף שלו פג.

לא משנה אם אתם משתמשים בשרת CA לכל מכונה, בשרת CA משותף או בשרת CA בניהול הלקוח, אתם יכולים לאפס את הגדרות ה-SSL של מכונת Cloud SQL בכל שלב.

מגבלות

בקטע הזה נסביר על המגבלות בהגדרת אישורי SSL/TLS ו-Cloud SQL.

מגבלות על חיבור לשירותים

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