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

בדף הזה מוסבר איך אפשר להשתמש ב-Secure Socket Layer‏ (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. יש שלוש אפשרויות:

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

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

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

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

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

Feature CA לכל מופע Shared CA CA בניהול הלקוח
מבנה ה-CA רשות אישורים נפרדת לכל מכונה רשות אישורים (CA) עליונה ורשויות אישורים משניות שמשותפות בין מופעים באותו אזור היררכיית רשויות אישורים שאתם יוצרים ומנהלים
מאפיינים קריפטוגרפיים מפתח RSA 2048-bit עם אלגוריתם SHA256 אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) עם מפתח 256 ביט ואלגוריתם SHA384 אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) עם מפתח 256 ביט ואלגוריתם SHA384
תקופת התוקף של רשות ה-CA ‫10 שנים 25 שנים לרשות אישורים (CA) עליונה ו-10 שנים לרשויות אישורים משניות ניתן להגדרה *
תקופת התוקף של אישור השרת ‫10 שנים שנה אחת שנה אחת**
האם המשתמש יזם את הרוטציה של CA? כן לא. רוטציית אישורים מנוהלת על ידי Cloud SQL כן
האם המשתמש יכול ליזום רוטציה של אישור השרת? כן כן כן
עוגן אמינה של רשות אישורים לחיבורי TLS רשות האישורים הייחודית לכל מופע היא ישות עוגן אמינה עבור המופע המתאים. רשות אישורים (CA) בסיסית ורשויות אישורים משניות הן נקודות העוגן של האמון בכל המופעים באזור נתון. רשויות האישורים שאתם יוצרים ומנהלים הן נקודות העוגן של האמון.
אימות זהות השרת אימות של רשות האישורים מאמת את זהות השרת, כי לכל מופע יש רשות אישורים ייחודית. אימות שם המארח יחד עם אימות ה-CA נדרש לאימות זהות השרת, כי אישורי CA של השרת משותפים בין המופעים. יכול להיות שאישור ה-CA לא משותף בין המקרים, אבל כדאי לאמת את שם המארח יחד עם אימות ה-CA.
השדה 'שם חלופי של בעלים' (SAN) באישורי שרת השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) רק במכונות שמופעל בהן Private Service Connect. אפשר להשתמש בשם המארח לאימות זהות השרת. אם אתם מתחברים למופע Cloud SQL באמצעות שם ה-DNS כשם המארח, אתם צריכים להגדיר פתרון DNS. השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) עבור כל סוגי המכונות. אפשר להשתמש בשם המארח לאימות זהות השרת. אם אתם מתחברים למופע Cloud SQL באמצעות שם ה-DNS כשם המארח, אתם צריכים להגדיר פתרון DNS. השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) עבור כל סוגי המכונות. אפשר להשתמש בשם המארח לאימות זהות השרת.
תמיכה בגרסאות של שרת proxy ל-Cloud SQL Auth תומך בכל הגרסאות של 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 ב-CA Service היא 10 שנים. אתם יכולים להגדיר תקופת תוקף שונה לאישורי רשות האישורים. אם תקופת התוקף של רשות האישורים קצרה יותר, יכול להיות שיהיה צורך לבצע רוטציה של רשות האישורים בתדירות גבוהה יותר, ותקופת תוקף קצרה משנה עשויה להשפיע על תקופת התוקף של אישורי השרת. מידע נוסף זמין במאמר בנושא ניהול רוטציה של רשויות אישורים.

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

רשות אישורים (CA) לכל מופע שמתארחת ב-Cloud SQL

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

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

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

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

תרשים של היררכיית הרשות שמנפיקה את האישורים (CA) פנימית לכל מופע.

רשויות CA משותפות שמתארחות בשירות CA

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

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

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

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

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

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

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

אישורי CA בניהול הלקוח

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

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

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

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

איך פועל תהליך הרוטציה של אישורי השרת

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

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

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

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

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

תפוגה של אישור SSL

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

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

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

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

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

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

מגבלות

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

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

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