אישור באמצעות אישורי 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)

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

  • רשות אישורים לכל מכונה: באפשרות הזו, רשות אישורים פנימית שמוקדשת לכל מכונה של 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) כשיוצרים את המכונה. אם לא מציינים את ההגדרה או הדגל כשיוצרים מכונה, האפשרות הזו היא ערך ברירת המחדל של המכונה. אי אפשר לעדכן מכונה כך שתשתמש באפשרות של רשות אישורים לכל מכונה, אם המכונה מוגדרת להשתמש ברשות אישורים משותפת או ברשות אישורים בניהול הלקוח.

  • רשות אישורים משותפת: באפשרות הזו משתמשים בהיררכיה של רשות אישורים שמורכבת מרשות אישורים בסיסית ומרשויות אישורים משניות של שרתים. רשויות האישורים המשניות של השרת באזור חותמות על אישורי השרת ומשותפות בין המכונות באזור. השימוש בהיררכיית רשויות אישורים משותפת עוזר כשמגדילים את מספר המכונות באזור, כי לא צריך לנהל רשויות אישורים ייחודיות למכונות נפרדות. אם תעברו ל-CA משותף (GOOGLE_MANAGED_CAS_CA), תוכלו להשתמש בחבילת CA אזורית אחת לכל המכונות באזור, וכך לפשט את ההגדרות בצד הלקוח. ‫Cloud SQL מארח ומנהל את ה-CA הבסיסי ואת ה-CAs של שרת המשנה ב- 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.

התכונה רשות אישורים לכל מכונה רשות אישורים משותפת רשות אישורים בניהול הלקוח
מבנה ה-CA רשות אישורים נפרדת לכל מכונה רשות אישורים ראשית ורשויות אישורים משניות שמשותפות בין מכונות באותו אזור היררכיית רשויות אישורים שאתם יוצרים ומנהלים
מאפיינים קריפטוגרפיים מפתח RSA של 2048 ביט עם אלגוריתם SHA256 אלגוריתם חתימה דיגיטלית של עקומה אליפטית (ECDSA) עם מפתח של 256 ביט עם אלגוריתם SHA384 אלגוריתם חתימה דיגיטלית של עקומה אליפטית (ECDSA) עם מפתח של 256 ביט עם אלגוריתם 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 שפועלים בסביבת הפעלה מהדור הראשון (יש תמיכה בשירותי Cloud Run בסביבת הפעלה מהדור השני)

‫* באפשרות של CA בניהול הלקוח, תקופת התוקף שמוגדרת כברירת מחדל לאישור 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.

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

כדי לתת אמון גם ברשות האישורים הבסיסית וגם ברשות האישורים המשנית של המכונה, בוחרים באחת מהאפשרויות הבאות:

  • מורידים את החבילה של global.pem כדי לתת אמון ברשות אישורי הבסיס ובכל רשויות האישורים המשניות שלה.
  • מורידים את החבילה האזורית של המיקום האזורי של המכונה כדי לתת אמון ברשות אישורי הבסיס וברשויות האישורים המשניות של אותו אזור. לדוגמה, אם המכונה נמצאת באזור asia-east1, צריך להוריד את החבילה asia-east1.pem.
  • מורידים את server-ca.pem של המכונה כדי לתת אמון ברשות אישורי הבסיס וברשות האישורים המשנית שמנפיקה את אישור השרת למכונה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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