אישור באמצעות אישורי 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 משותף (GOOGLE_MANAGED_CAS_CA), אפשר להשתמש בחבילת CA אזורית אחת לכל המופעים באזור, וכך לפשט את ההגדרה בצד הלקוח. ‫Cloud SQL מארח ומנהל את רשות האישורים הבסיסית ואת רשויות האישורים המשניות של השרת ב- Google CloudCertificate Authority Service (שירות CA). ‫Cloud 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 בניהול הלקוח (CUSTOMER_MANAGED_CAS_CA), אתם יכולים לנהל את היררכיית ה-CA שלכם ואת מדיניות הרוטציה באמצעות CA Service. ההגדרה הזו מעניקה לכם יותר שליטה ועוזרת לכם לעמוד בדרישות התאימות. כדי לבחור ב-CA בניהול הלקוח, צריך ליצור מאגר CA ו-CA ב-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) Shared CA CA בניהול הלקוח
מבנה CA רשות אישורים נפרדת לכל מופע רשות אישורים (CA) בסיסית ורשויות אישורים משניות שמשותפות בין מופעים באותו אזור היררכיית רשויות אישורים שאתם יוצרים ומנהלים
מאפיינים קריפטוגרפיים מפתח RSA 2048-bit עם אלגוריתם SHA256 אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) עם מפתח 256 ביט ואלגוריתם SHA384 אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) עם מפתח 256 ביט ואלגוריתם SHA384
תקופת התוקף של רשות ה-CA ‫10 שנים ‫25 שנים לרשות אישורים בסיסית ו-10 שנים לרשויות אישורים משניות ניתן להגדרה *
תקופת התוקף של אישור השרת ‫10 שנים שנה אחת שנה אחת**
האם המשתמש יכול ליזום רוטציה של CA? כן לא. החלפת אישורים (CA) מנוהלת על ידי Cloud SQL כן
האם המשתמש יזם את הרוטציה של אישור השרת? כן כן כן
האם מתבצעת רוטציה אוטומטית של אישור השרת? לא כן כן
ישות עוגן אמינה של רשות אישורים לחיבורי TLS רשות האישורים הייחודית לכל מופע היא נקודת העוגן של האמון במופע המתאים. רשות אישורים (CA) בסיסית ורשויות אישורים משניות הן נקודות העוגן של האמון בכל המקרים באזור נתון. רשויות האישורים שאתם יוצרים ומנהלים הן נקודות העוגן של האמון.
אימות זהות השרת אימות של רשות האישורים מאמת את זהות השרת, כי לכל מופע יש רשות אישורים ייחודית. אימות שם המארח יחד עם אימות ה-CA נדרש לאימות זהות השרת, כי אישורי CA של שרתים משותפים בין מופעים. יכול להיות שאישור ה-CA לא משותף בין המופעים, אבל כדאי לאמת את שם המארח יחד עם אימות ה-CA.
השדה Subject Alternative Name (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 ב-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 משניות של שרתים בכל אזור. רשויות אישורים משניות של שרתים מנפיקות אישורים לשרתים ומשותפות בין מופעים באזור. ‫Cloud SQL מטפל ברוטציה של אישורי CA של שרת אזורי משותף ומספק קישורים זמינים לציבור להורדה של חבילות אישורי CA.

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

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

  • מורידים את חבילת global.pem כדי לתת אמון ב-CA הבסיסי ובכל רשויות האישורים המשניות שלו.
  • מורידים את חבילת האזור למיקום האזורי של המופע כדי לתת אמון ברשות אישורי הבסיס וברשויות אישורי המשנה באזור הזה. לדוגמה, אם המיקום של המופע הוא באזור 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 משלכם ב-CA Service.

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

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

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

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

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

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

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

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

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

אחרי שמעדכנים את כל לקוחות SQL Server, שולחים פקודת החלפה (ל-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 שנים, ותקופת התוקף של אישור ה-CA המשני המשותף היא 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.

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

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