במאמר הזה מוסבר איך אפשר להשתמש ב-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 console) או מציינים
GOOGLE_MANAGED_INTERNAL_CAבהגדרהserverCaMode(Cloud SQL Admin API) או בדגל--server-ca-mode(ה-CLI של gcloud) כשיוצרים את המופע. אם לא מציינים את ההגדרה או את הדגל כשיוצרים מופע, האפשרות הזו היא ערך ברירת המחדל של המופע. אי אפשר לעדכן מופע כדי להשתמש באפשרות CA לכל מופע אם המופע מוגדר לשימוש ב-CA משותף או ב-CA בניהול הלקוח.CA משותף: באפשרות הזו נעשה שימוש בהיררכיית CA שכוללת CA בסיסי ו-CA משני לשרתים. רשויות אישורים (CA) של שרתים משניים באזור מסוים חותמות על אישורי השרתים ומשותפות בין מופעים באזור. שימוש בהיררכיית CA משותפת מועיל כשמגדילים את מספר המכונות באזור, כי לא צריך לנהל רשויות CA ייחודיות למכונות נפרדות. אם עוברים ל-CA משותף (
GOOGLE_MANAGED_CAS_CA), אפשר להשתמש בחבילת CA אזורית אחת לכל המופעים באזור, וכך לפשט את ההגדרה בצד הלקוח. Cloud SQL מארח ומנהל את רשות אישורי הבסיס (CA) ואת רשויות האישורים המשניות של השרת ב-Certificate Authority Service (CA Service). Google CloudCloud SQL גם מטפל ברוטציה של רשויות אישורים בסיסיות ושל רשויות אישורים של שרתים משניים, ומספק קישורים שזמינים לציבור לחבילות של אישורי CA שאפשר להוריד. כדי לבחור CA משותף, בוחרים באפשרות Google managed CAS certificate authority במסוף Google Cloud או מצייניםGOOGLE_MANAGED_CAS_CAבהגדרהserverCaMode(Cloud SQL Admin API) או בדגל--server-ca-mode(ה-CLI של gcloud) כשיוצרים או עורכים את האינסטנס. אם אתם משתמשים באפשרות של רשות אישורים לכל מופע או באפשרות של רשות אישורים בניהול הלקוח, אתם יכולים לעדכן מופע קיים כך שישתמש בהיררכיית רשות אישורים משותפת.רשות CA בניהול הלקוח: באפשרות הזו אתם יוצרים ומנהלים היררכיית CA משלכם. כדאי לבחור באפשרות הזו אם רוצים לנהל את רשויות האישורים והאישורים בעצמכם. באמצעות CA בניהול הלקוח (
CUSTOMER_MANAGED_CAS_CA), אתם יכולים לנהל את היררכיית ה-CA שלכם ואת מדיניות הרוטציה באמצעות CA Service. ההגדרה הזו מאפשרת לכם יותר שליטה ועוזרת לכם לעמוד בדרישות התאימות. כדי לבחור CA בניהול הלקוח, צריך ליצור מאגר CA ו-CA בשירות CA. ב-Cloud SQL, מציינים את מאגר רשויות האישורים ואת רשות האישורים ל-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 לכל מופע | Shared CA | CA בניהול הלקוח |
|---|---|---|---|
| מבנה CA | רשות אישורים נפרדת לכל מופע | רשות אישורים (CA) עליונה ורשויות אישורים משניות (CA) שמשותפות בין מופעים באותו אזור | היררכיית רשויות אישורים שאתם יוצרים ומנהלים |
| מאפיינים קריפטוגרפיים | מפתח RSA 2048 ביט עם אלגוריתם SHA256 | אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) עם מפתח 256 ביט ואלגוריתם SHA384 | אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) עם מפתח 256 ביט ואלגוריתם SHA384 |
| תקופת התוקף של רשות ה-CA | 10 שנים | 25 שנים לרשות אישורים (CA) עליונה ו-10 שנים לרשויות אישורים משניות | ניתן להגדרה * |
| תקופת התוקף של אישור השרת | 10 שנים | שנה אחת | שנה אחת** |
| האם המשתמש יכול ליזום רוטציה של CA? | כן | לא. רוטציית אישורים מנוהלת על ידי Cloud SQL | כן |
| האם המשתמש יכול ליזום רוטציה של אישור השרת? | כן | כן | כן |
| האם יש רוטציה אוטומטית של אישור השרת? | לא | כן | כן |
| ישות עוגן אמינה של רשות אישורים לחיבורי TLS | רשות האישורים הייחודית לכל מופע היא נקודת העוגן של האמון עבור המופע המתאים. | רשות אישורים (CA) בסיסית ורשויות אישורים משניות הן נקודות העוגן של האמון בכל המקרים באזור נתון. | רשויות האישורים שאתם יוצרים ומנהלים הן נקודות העוגן של האמון. |
| אימות זהות השרת | אימות של רשות האישורים מאמת את זהות השרת, כי לכל מופע יש רשות אישורים ייחודית. | אימות שם המארח יחד עם אימות ה-CA נדרש לאימות זהות השרת, כי אישורי CA של שרתים משותפים בין מופעים. | יכול להיות שאישור ה-CA לא משותף בין המופעים, אבל כדאי לאמת את שם המארח יחד עם אישור ה-CA. |
| השדה 'שם חלופי של בעלים (subject)' (SAN) באישורי שרת | השדה SAN מכיל את שם המארח (שם ה-DNS של המופע) רק עבור מופעים שמופעל בהם Private Service Connect. אפשר להשתמש בשם המארח לאימות זהות השרת. אם אתם מתחברים למופע Cloud SQL באמצעות שם ה-DNS כשם המארח, אתם צריכים להגדיר פתרון DNS. | השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) עבור כל סוגי המכונות. אפשר להשתמש בשם המארח לאימות זהות השרת. אם אתם מתחברים למופע Cloud SQL באמצעות שם ה-DNS כשם המארח, אתם צריכים להגדיר פתרון DNS. | השדה SAN מכיל את שם המארח (שם ה-DNS של המכונה) עבור כל סוגי המכונות. אפשר להשתמש בשם המארח לאימות זהות השרת. |
| תמיכה בגרסאות של שרת proxy ל-Cloud SQL Auth | תומך בכל הגרסאות של שרת ה-proxy לאימות של Cloud SQL, מגרסה 1 ואילך. | נדרשת גרסה 2.13.0 ואילך של Cloud SQL Auth Proxy. | נדרשת גרסה 2.14.3 ואילך של Cloud SQL Auth Proxy. |
| הגבלות על חיבור לשירות | ללא | אין תמיכה בחיבורים מהשירותים הבאים Google Cloud: |
אין תמיכה בחיבורים מהשירותים הבאים Google Cloud:
|
* באפשרות של CA בניהול הלקוח, תקופת התוקף שמוגדרת כברירת מחדל לאישור CA ב-CA Service היא 10 שנים. אתם יכולים להגדיר תקופת תוקף שונה לאישורי CA. אם תקופת התוקף של רשות האישורים קצרה יותר, יכול להיות שיהיה צורך לבצע רוטציה של רשות האישורים בתדירות גבוהה יותר. בנוסף, תקופת תוקף קצרה משנה עשויה להשפיע על תקופת התוקף של אישורי השרת. מידע נוסף זמין במאמר בנושא ניהול רוטציה של רשויות אישורים.
** באפשרות של 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) של שרתים משניים מנפיקות אישורים לשרתים ומשותפות בין מופעים באזור. Cloud SQL מטפל ברוטציה של אישורי CA של שרתים אזוריים משותפים ומספק קישורים שזמינים לציבור להורדה של חבילות אישורי 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 במסוף Google Cloud .
בתרשים הבא מוצגת ההיררכיה של רשות האישורים המשותפת.
אישורי 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 משני אם אתם מתכננים להגדיר היררכיה של CA בסיסי או שרשרת עד ל-CA חיצוני.
בוחרים באפשרות של רשות אישורים בניהול הלקוח רק אם רוצים לנהל רשויות אישורים ואישורים משלכם. מידע נוסף מופיע במאמר בנושא שימוש ב-CA בניהול הלקוח.
איך מתבצעת רוטציה של אישורי שרת
ב-Cloud SQL יש דרכים להחליף את אישור השרת, כך שאפשר להחליף את האישור החדש בצורה חלקה לפני שהאישור הישן יפוג.
במקרים שבהם נעשה שימוש בהיררכיית CA משותפת או בהיררכיית CA בניהול הלקוח, אפשר להפעיל רוטציה אוטומטית של אישורי שרת במהלך עדכוני תחזוקה עד 180 ימים לפני מועד התפוגה.
במקרים שבהם נעשה שימוש בהיררכיות של רשויות אישורים לכל מכונה, רשויות אישורים משותפות או רשויות אישורים בניהול הלקוח, בעלי הפרויקט מקבלים מ-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.
כדי לבצע רוטציה של רשויות האישורים, משתמשים בתהליך הרוטציה של רשויות האישורים בשירות רשויות האישורים. מידע נוסף זמין במאמר בנושא ניהול רוטציה של רשויות אישורים.
אם לקוח מוגדר לאמת את רשות האישורים או לאמת את שם המארח באישור השרת, החיבורים של הלקוח הזה למופעי Cloud SQL עם אישורי שרת שתוקפם פג ייכשלו. כדי למנוע שיבושים בחיבורים של לקוחות, צריך להחליף את אישור השרת לפני שתוקף האישור יפוג.
לא משנה אם אתם משתמשים ב-CA לכל מכונה, ב-CA משותף או ב-CA בניהול הלקוח במצב שרת, אתם יכולים לאפס את הגדרת ה-SSL של מכונת Cloud SQL בכל שלב.
מגבלות
בקטע הזה מוסבר על מגבלות בהגדרת אישורי SSL/TLS ו-Cloud SQL.
מגבלות על חיבור לשירות
- אם במופע שלכם נעשה שימוש באפשרות של רשות אישורים משותפת (
GOOGLE_MANAGED_CAS_CA) או רשות אישורים בניהול הלקוח (CUSTOMER_MANAGED_CAS_CA) להגדרתserverCaMode, המופע לא יכול לתמוך בחיבורים מהשירותים הבאים Google Cloud :
המאמרים הבאים
מגדירים SSL/TLS במופע Cloud SQL.
- ניהול SSL/TLS במכונה של Cloud SQL.