הגדרת אישורי SSL/TLS

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

סקירה כללית

כשיוצרים מכונה, Cloud SQL יוצר באופן אוטומטי אישור שרת. מומלץ לאכוף שימוש ב-SSL או ב-TLS בכל החיבורים.

החיבורים ל-SQL Server מוצפנים כברירת מחדל ודורשים אימות של האישור.

ההצפנה מופעלת כברירת מחדל בדרייברים הבאים:

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

צריך להתקין את אישור השרת במכונת הלקוח או להעביר את הדגל TrustServerCertificate=true במחרוזת החיבור של הלקוח. מידע נוסף זמין במאמר ODBC Driver 18.0 for SQL Server released.

אחרת, הלקוחות יכולים להתחבר באופן חופשי בלי שינויים נוספים במחרוזות החיבור או באישורים שלהם, גם אם מגדירים את המכונה עם sslMode שמוגדר ל-ENCRYPTED_ONLY.

למידע נוסף, ראו את הקטע Enable encrypted connections to the המנוע של מסד הנתונים במסמכי התיעוד של SQL Server.

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

אכיפת הצפנת SSL/TLS

אפשר להשתמש בהגדרה מצב SSL כדי לאכוף הצפנת SSL בדרכים הבאות:

  • לאפשר גם חיבורים שהם לא SSL/TLS וגם חיבורים שהם SSL/TLS. (זוהי ברירת המחדל)

  • לאפשר רק חיבורים שמוצפנים באמצעות SSL/TLS.

אם בוחרים באפשרות Allow non-SSL/non-TLS and SSL/TLS connections במכונה של Cloud SQL, המערכת מקבלת חיבורי SSL/TLS וגם חיבורים לא מוצפנים ולא מאובטחים. אם לא דורשים SSL או TLS לכל החיבורים, עדיין אפשר להשתמש בחיבורים לא מוצפנים. לכן, אם אתם ניגשים למכונה באמצעות כתובת IP ציבורית, מומלץ מאוד לאכוף SSL לכל החיבורים.

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

אכיפת SSL מבטיחה שכל החיבורים מוצפנים.

כדי להפעיל את הדרישה ל-SSL או ל-TLS:

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף Overview של מכונה, לוחצים על שם המכונה.
  3. בתפריט הניווט של SQL, לוחצים על Connections.
  4. לוחצים על הכרטיסייה אבטחה.
  5. בוחרים אחת מהאפשרויות הבאות:
    • אישור תנועה ברשת לא מוצפנת (לא מומלץ)
    • לאפשר רק חיבורי SSL. האפשרות הזו מאפשרת רק חיבורים שמשתמשים בהצפנת SSL/TLS.

gcloud

   gcloud sql instances patch INSTANCE_NAME \
   --ssl-mode=SSL_ENFORCEMENT_MODE

מחליפים את SSL_ENFORCEMENT_MODE באחת מהאפשרויות הבאות:

  • ‫ALLOW_UNENCRYPTED_AND_ENCRYPTED מאפשר חיבורים ללא SSL/ללא TLS וחיבורי SSL/TLS. זה ערך ברירת המחדל.
  • ‫ENCRYPTED_ONLY מאפשר רק חיבורים שמוצפנים באמצעות SSL או TLS.

Terraform

כדי לאכוף הצפנת SSL/TLS, משתמשים במשאב של Terraform: 

resource "google_sql_database_instance" "sqlserver_instance" {
  name             = "sqlserver-instance"
  region           = "asia-northeast1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"
  settings {
    tier = "db-custom-2-7680"
    ip_configuration {
      ssl_mode = "ENCRYPTED_ONLY"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

החלה של השינויים

כך מחילים את ההגדרות של Terraform בפרויקט ב- Google Cloud :

הכנת Cloud Shell

  1. מפעילים את Cloud Shell.

  2. מגדירים את פרויקט ברירת המחדל ב- Google Cloud שבו רוצים להחיל את ההגדרות של Terraform.

    תצטרכו להריץ את הפקודה הזו רק פעם אחת לכל פרויקט, ותוכלו לעשות זאת בכל ספרייה.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

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

הכנת הספרייה

לכל קובץ תצורה של Terraform צריכה להיות ספרייה משלו (שנקראת גם מודול ברמה הבסיסית).

  1. יוצרים ספרייה חדשה ב-Cloud Shell ובה יוצרים קובץ חדש. שם הקובץ חייב לכלול את הסיומת .tf, למשל main.tf. במדריך הזה, הקובץ נקרא main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. אם אתם עוקבים אחרי המדריך, תוכלו להעתיק את הקוד לדוגמה בכל קטע או שלב.

    מעתיקים את הקוד לדוגמה בקובץ main.tf החדש שיצרתם.

    לחלופין, אפשר גם להעתיק את הקוד מ-GitHub. כדאי לעשות את זה כשקטע הקוד של Terraform הוא חלק מפתרון מקצה לקצה.

  3. בודקים את הפרמטרים לדוגמה ומשנים אותם בהתאם לסביבה שלכם.
  4. שומרים את השינויים.
  5. מפעילים את Terraform. צריך לעשות זאת רק פעם אחת לכל ספרייה. 
    terraform init

    אופציונלי: תוכלו לכלול את האפשרות -upgrade, כדי להשתמש בגרסה העדכנית ביותר של הספק של Google: 

    terraform init -upgrade

החלה של השינויים

  1. בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם: 
    terraform plan

    מתקנים את ההגדרות לפי הצורך.

  2. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform: 
    terraform apply

    ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!‎".

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

למחוק את השינויים

כדי למחוק את השינויים:

  1. כדי להשבית את ההגנה מפני מחיקה, בקובץ התצורה של Terraform מגדירים את הארגומנט deletion_protection לערך false. 
    deletion_protection =  "false"
  2. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform המעודכנות: 
    terraform apply

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

    terraform destroy

REST v1

  1. לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫SSL_ENFORCEMENT_MODE: משתמשים באחת מהאפשרויות הבאות:
      • ‫ALLOW_UNENCRYPTED_AND_ENCRYPTED: מאפשרת חיבורים שהם לא מסוג SSL/TLS וחיבורים מסוג SSL/TLS.
      • ‫ENCRYPTED_ONLY: מאפשר רק חיבורים שמוצפנים באמצעות SSL או TLS.
    • ‫INSTANCE_ID: מזהה המכונה

    ה-method של ה-HTTP וכתובת ה-URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

    תוכן בקשת JSON: 

    
{
  "settings": {
    "ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"}
  }
}

    כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

    אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

  1. לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫SSL_ENFORCEMENT_MODE: משתמשים באחת מהאפשרויות הבאות:
      • ‫ALLOW_UNENCRYPTED_AND_ENCRYPTED: מאפשרת חיבורים שהם לא מסוג SSL/TLS וחיבורים מסוג SSL/TLS.
      • ‫ENCRYPTED_ONLY: מאפשר רק חיבורים שמוצפנים באמצעות SSL או TLS.
    • ‫INSTANCE_ID: מזהה המכונה

    ה-method של ה-HTTP וכתובת ה-URL: 

    PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

    תוכן בקשת JSON: 

    {
  "settings": {
    "ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"}
  }
}

    כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

    אתם אמורים לקבל תגובת JSON שדומה לזו:

אישורי שרת

כשיוצרים מכונה, Cloud SQL יוצר באופן אוטומטי אישור שרת. כל עוד אישור השרת תקף, אין צורך לנהל את אישור השרת באופן פעיל. ב-Cloud SQL אתם יכולים לבחור בין שלוש היררכיות שונות של רשויות אישורים (CA). ההיררכיה של רשות האישורים שתבחרו תהפוך למצב של רשות האישורים של השרת במכונה. אם אתם משתמשים ב-CA לכל מכונה כמצב ה-CA של השרת במכונה, תאריך התפוגה של אישורי השרת הוא 10 שנים. אם אתם משתמשים ב-CA משותף או ב-CA בניהול הלקוח כמצב ה-CA של השרת במכונה, תאריך התפוגה של אישור השרת הוא שנה אחת*. אחרי תאריך התפוגה, אישור השרת כבר לא תקף, והלקוחות לא יכולים יותר ליצור חיבור מאובטח למכונה באמצעות האישור הזה. אם הלקוח מוגדר לאמת את ה-CA או את שם המארח באישור השרת, החיבורים של הלקוח למכונות Cloud SQL עם אישורי שרת שפג תוקפם ייכשלו. כדי למנוע שיבושים בחיבורים של הלקוחות, צריך להפעיל רוטציה אוטומטית של אישורי השרת או לבצע רוטציה ידנית של אישור השרת לפני שתוקף האישור יפוג. מדי פעם תקבלו התראה על כך שתוקף האישור של השרת עומד לפוג. ההתראות נשלחות במספר הימים הבא לפני תאריך התפוגה: 90, 30, 10, 2 ו-1.

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

הצגת רשימה ויצירה של אישורי שרת

כדי לראות את פרטי אישורי השרת במסוף Google Cloud , נכנסים לדף Connections ולוחצים על הכרטיסייה Security.

בטבלת האישורים אפשר לראות את הפרטים הבאים:

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

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

המסוף

במכונות שמשתמשות באישורי שרת בחתימה עצמית (רשות אישורים לכל מכונה):

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף Overview של מכונה, לוחצים על שם המכונה.
  3. בתפריט הניווט של SQL, לוחצים על Connections.
  4. לוחצים על הכרטיסייה אבטחה.
  5. עוברים לקטע ניהול אישורי CA של שרת.
  6. לוחצים על ניהול אישורים כדי להרחיב את הקטע.
  7. לוחצים על יצירת אישור CA חדש.

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

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

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף Overview של מכונה, לוחצים על שם המכונה.
  3. בתפריט הניווט של SQL, לוחצים על Connections.
  4. לוחצים על הכרטיסייה אבטחה.
  5. עוברים לקטע ניהול אישורי שרת.
  6. לוחצים על ניהול אישורים כדי להרחיב את הקטע.
  7. לוחצים על יצירת אישור שרת.

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

gcloud

במכונות שמשתמשות באישורי שרת בחתימה עצמית (רשות אישורים לכל מכונה):

  1. כדי לקבל מידע על אישור השרת, משתמשים בפקודה sql ssl server-ca-certs list: 
    gcloud sql ssl server-ca-certs list \
--instance=INSTANCE_NAME
  2. כדי ליצור אישור שרת, משתמשים בפקודה sql ssl server-ca-certs create: 
    gcloud sql ssl server-ca-certs create \
--instance=INSTANCE_NAME
  3. מורידים את פרטי האישור לקובץ PEM מקומי: 
    gcloud sql ssl server-ca-certs list \
--format="value(cert)" \
--instance=INSTANCE_NAME > \
FILE_PATH/FILE_NAME.pem
  4. מעדכנים את כל הלקוחות כך שישתמשו במידע החדש. לשם כך, מעתיקים את הקובץ שהורדתם למכונות המארחות של הלקוחות ומחליפים את קובצי ה-server-ca.pem הקיימים.

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

  1. כדי לקבל מידע על אישור השרת, משתמשים בפקודה sql ssl server-certs list: 
    gcloud sql ssl server-certs list \
   --instance=INSTANCE_NAME
  2. כדי ליצור אישור שרת, משתמשים בפקודה sql ssl server-certs create: 
    gcloud sql ssl server-certs create \
   --instance=INSTANCE_NAME
  3. מורידים את פרטי האישור לקובץ PEM מקומי: 
    gcloud sql ssl server-certs list \
   --format="value(ca_cert.cert)" \
   --instance=INSTANCE_NAME > \
   FILE_PATH/FILE_NAME.pem
  4. כדי לעדכן את כל הלקוחות כך שישתמשו במידע החדש, מעתיקים את הקובץ שהורדתם למכונות המארחות של הלקוחות ומחליפים את קובצי ה-server-ca.pem הקיימים.

Terraform

כדי לספק את פרטי האישור של השרת כפלט, משתמשים במקור נתונים של Terraform:

  1. מוסיפים את הקוד הבא לקובץ התצורה של Terraform: 
       data "google_sql_ca_certs" "ca_certs" {
     instance = google_sql_database_instance.default.name
   }

   locals {
     furthest_expiration_time = reverse(sort([for k, v in data.google_sql_ca_certs.ca_certs.certs : v.expiration_time]))[0]
     latest_ca_cert           = [for v in data.google_sql_ca_certs.ca_certs.certs : v.cert if v.expiration_time == local.furthest_expiration_time]
   }

   output "db_latest_ca_cert" {
     description = "Latest CA certificate used by the primary database server"
     value       = local.latest_ca_cert
     sensitive   = true
   }
  2. כדי ליצור את הקובץ server-ca.pem, מריצים את הפקודה הבאה: 
       terraform output db_latest_ca_cert > server-ca.pem

שימוש בחיבורים מוצפנים

איך SQL Server משתמש בחיבורים מוצפנים

אימות זהות השרת

אימות הזהות של השרת תלוי בהגדרת ההיררכיה של רשות האישורים (CA) של השרת במכונה של Cloud SQL.

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

אם יש לכם CA לכל מכונה, אתם יכולים לבצע אימות זהות של שרת שמבוסס על שם DNS רק במכונות שהוגדרו באמצעות Private Service Connect. אם יש לכם רשות אישורים משותפת, אתם יכולים לבצע אימות זהות של שרתים על סמך שם DNS לכל סוגי המכונות, כלומר מכונות של Private Service Connect, גישה לשירותים פרטיים וכתובות IP ציבוריות.

אם אתם משתמשים ברשות אישורים בניהול הלקוח, אתם יכולים לאמת את שרשרת האמון של רשות האישורים ולבצע אימות זהות של השרת על סמך שם ה-DNS, בכל סוג של מכונה שמשתמשת ברשות אישורים בניהול הלקוח בשביל serverCAmode.

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

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

הפעלת אימות זהות השרת

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

במכונות שמשתמשות ב-CA משותף כמצב ה-CA של השרת, שם ה-DNS של המכונה מופיע בשדה Subject Alternative Name (SAN) של אישור השרת. כדי לקבל את שם ה-DNS הזה, אפשר להשתמש ב-API לחיפוש מכונות ולהשתמש בתשובה כשם מארח לאימות זהות השרת. צריך להגדיר פענוח DNS לשם ה-DNS.

כדי להפעיל אימות של זהות השרת במכונה שמשתמשת ב-CA משותף, מבצעים את הפעולות הבאות:

  1. מאחזרים את שם ה-DNS.

    1. כדי להציג מידע מסכם על מכונה של Cloud SQL, כולל שם ה-DNS של המכונה, משתמשים בפקודה gcloud sql instances describe:

      gcloud sql instances describe INSTANCE_NAME \
  --project=PROJECT_ID

      מחליפים את הפרטים הבאים:

      • ‫INSTANCE_NAME: השם של מכונת Cloud SQL
      • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud שמכיל את המכונה

    2. בתשובה, מחפשים את השדה dnsNames:. השדה הזה יכול להחזיר כמה שמות DNS, בפורמטים הבאים:

      הגדרת רשת פורמט שם DNS רמת השם
      ‫Private Service Connect או כתובת IP ציבורית INSTANCE_UID.PROJECT_DNS_LABEL.REGION_NAME.sql.goog.

      לדוגמה:
      1a23b4cd5e67.1a2b345c6d27.us-central1.sql.goog.       		Instance
      גישה לשירותים פרטיים INSTANCE_UID.PROJECT_DNS_LABEL.REGION_NAME.sql-psa.goog.

      לדוגמה:
      1a23b4cd5e67.1a2b345c6d27.us-central1.sql-psa.goog.       		Instance

  2. יצירת רשומת DNS בתחום DNS. אם אתם מתחברים באופן פרטי, צרו את רשומת ה-DNS בתחום DNS פרטי ברשת ה-VPC המתאימה.

  3. כשמתחברים למכונה של Cloud SQL ל-SQL Server, מגדירים את שם ה-DNS או את כתובת ה-IP בתור שם המארח. לאחר מכן מפעילים את אימות זהות השרת על ידי ציון הדגל -N עבור sqlcmd או על ידי בחירה באפשרות Encrypt Connection/Encryption של SSMS.

    למנהלי התקנים אחרים של SQL Server יש דגלים או הגדרות דומים.

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