הגדרת mTLS בקצה העורפי

בדף הזה מוסבר איך להגדיר mTLS בבק-אנד באמצעות אישורים בניהול עצמי.

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

כדי להגדיר mTLS בקצה העורפי, צריך לבצע את הפעולות הבאות. השלבים האלה מתוארים בקטעים הבאים של המסמך הזה.

1. יוצרים משאב של הגדרות אמון שמורכב מאישורי בסיס ואישורי ביניים.
2. יוצרים אישור לקוח ומעלים אותו ל-Certificate Manager.
3. יוצרים משאב של הגדרות אימות בקצה העורפי שמפנה גם להגדרות האמון וגם לאישור הלקוח.
4. מצרפים את משאב ההגדרות של אימות הקצה העורפי לשירות הקצה העורפי של מאזן העומסים.

לפני שמתחילים

• קוראים את הסקירה הכללית על TLS מאומת בקצה העורפי ו-mTLS בקצה העורפי.
• כדאי לעיין במאמר בנושא ניהול הגדרות אמון.

• אם רוצים לפעול לפי ההוראות במדריך הזה באמצעות Google Cloud CLI, צריך להתקין אותו. אפשר למצוא פקודות שקשורות לאיזון עומסים במדריכי העזר ל-API ול-CLI של gcloud.

  אם לא הפעלתם את ה-CLI של gcloud בעבר, אתם צריכים קודם להריץ את הפקודה gcloud init כדי לבצע אימות.

• מפעילים את ממשקי ה-API הבאים: Compute Engine API,‏ Certificate Manager API,‏ Network Security ו-Network Services API. מידע נוסף מופיע במאמר הפעלה של ממשקי API.

• מגדירים מאזן עומסים עם אחד מהקצוות העורפיים הנתמכים הבאים:

  • קצוות עורפיים של קבוצת מכונות וירטואליות
  • קבוצות של נקודות קצה ברשת (NEGs) לקישוריות היברידית
  • קבוצות אזוריות של נקודות קצה ברשת (Zonal NEGs)

הרשאות

בקטע הזה מפורטות ההרשאות שנדרשות כדי להגדיר mTLS בשרת העורפי.

פעולה	הרשאה
יצירת הגדרת אמון	‫certificatemanager.trustconfigs.create בפרויקט היעד Google Cloud
יצירת אישור לקוח	‫certificatemanager.certs.create בפרויקט היעד Google Cloud
יצירת משאב של הגדרות אימות לשרת העורפי	certificatemanager.certs.use באישור היעד ‫certificatemanager.trustconfigs.use בהגדרות של יעד המהימנות ‫networksecurity.backendauthenticationconfigs.create בפרויקט היעד Google Cloud
צירוף משאב של הגדרות אימות לקצה העורפי לשירות הקצה העורפי של מאזן העומסים	‫compute.backendservice.update בשירות הקצה העורפי של היעד ‫networksecurity.backendauthenticationconfigs.use במשאב ההגדרות של אימות ה-Backend של היעד

סקירה כללית של ההגדרה

בקטעים הבאים מפורטים השלבים להגדרת mTLS בבק-אנד על סמך הארכיטקטורה שמוצגת בדיאגרמה הבאה.

רכיבי mTLS של קצה עורפי (לחצו כדי להגדיל).

יצירת אישורי הבסיס ואישורי הביניים

הערה:

אם כבר יש לכם אישורים להעלאה למאגר האישורים, אתם יכולים לדלג על השלב הזה ולעבור אל עיצוב האישורים.

בקטע הזה נעשה שימוש בספריית OpenSSL כדי ליצור את אישור הבסיס (נקודת אמון) ואת אישור הביניים.

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

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

1. יוצרים קובץ תצורה של OpenSSL.

   בדוגמה הבאה, קובץ ההגדרות (example.cnf) מכיל את הקטע [ca_exts], שמציין תוספים מסוג X.509 שמסמנים את האישור כמתאים ל-CA. מידע נוסף על הדרישות לגבי אישורי בסיס ואישורי ביניים זמין במאמר דרישות האישורים.

   cat > example.cnf << EOF
   [req]
   distinguished_name = empty_distinguished_name
   
   [empty_distinguished_name]
   # Kept empty to allow setting via -subj command-line argument.
   
   [ca_exts]
   basicConstraints=critical,CA:TRUE
   keyUsage=keyCertSign
   extendedKeyUsage=serverAuth
   
   EOF
   

2. יוצרים מפתח פרטי חדש מסוג RSA ‏ (root.key) ומשתמשים בו כדי ליצור אישור CA בסיסי מסוג X.509 בחתימה עצמית (root.cert), שמשמש כרשות אישורים (CA) בסיסית.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=root' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout root.key -out root.cert
   

3. יוצרים בקשת חתימה על אישור (CSR) (int.req) לאישור הביניים.

   openssl req -new \
       -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=int' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout int.key -out int.req
   

4. יוצרים את אישור הביניים X.509 ‏ (int.cert) מ-CSR. רשות האישורים הבסיסית משתמשת במפתח הפרטי (root.key) ובאישור (root.cert) שלה כדי להנפיק ולחתום על אישור הביניים X.509.

   openssl x509 -req \
       -CAkey root.key -CA root.cert \
       -set_serial 1 \
       -days 3650 \
       -extfile example.cnf \
       -extensions ca_exts \
       -in int.req -out int.cert
   

עיצוב האישורים

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

export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

יצירת הגדרת אמון

הגדרת אמון היא משאב שמייצג את ההגדרה של תשתית המפתח הציבורי (PKI) ב-Certificate Manager.

כדי ליצור משאב של הגדרת אמון, מבצעים את השלבים הבאים:

המסוף

1. נכנסים לדף Certificate Manager במסוף Google Cloud .

   מעבר אל Certificate Manager

2. בכרטיסייה Trust Configs, לוחצים על Add Trust Config.

3. מזינים שם להגדרה.

4. בקטע מיקום, בוחרים באפשרות גלובלי או אזורי.

   המיקום מציין איפה מאוחסן משאב ההגדרה של יחסי האמון. עבור מאזני עומסים גלובליים חיצוניים של אפליקציות ומאזני עומסים פנימיים של אפליקציות חוצי-אזורים, יוצרים משאב תצורת אמון גלובלי. עבור מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB), צריך ליצור משאב אזורי של הגדרת אמון.

5. בקטע מאגר אישורים, לוחצים על Add trust anchor ומעלים את קובץ האישור בקידוד PEM, או מעתיקים את תוכן האישור.

6. לוחצים על הוספה.

7. בקטע Trust store, לוחצים על Add intermediate CA ומעלים את קובץ האישור בקידוד PEM, או מעתיקים את התוכן של האישור. בשלב הזה אפשר להוסיף עוד רמת אמון בין אישור הבסיס לבין אישור השרת.

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

9. כדי להוסיף את האישור שהוספתם לרשימת ההיתרים, לוחצים על הוספה.

10. לוחצים על יצירה.

מוודאים שמשאב ההגדרות החדש של אמון מופיע ברשימת ההגדרות.

gcloud

1. יוצרים קובץ YAML של הגדרות אמון (trust_config.yaml) שמציין את הפרמטרים של הגדרות האמון. משאב ההגדרה של האמון בדוגמה הזו מכיל מאגר אמון עם ישות עוגן אמינה ואישור ביניים. בדוגמה הזו, משאב ההגדרה של אמון קורא את תוכן האישור ממשתני הסביבה שנוצרו בשלב הקודם הגדרת הפורמט של האישורים.

   cat << EOF > trust_config.yaml
   trustStores:
   - trustAnchors:
     - pemCertificate: "${ROOT_CERT}"
     intermediateCas:
     - pemCertificate: "${INTERMEDIATE_CERT}"
   EOF
   

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

2. כדי לייבא את קובץ ה-YAML של הגדרות האמון, משתמשים בפקודה gcloud certificate-manager trust-configs import.

   גלובלי

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

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=global
   

   מחליפים את TRUST_CONFIG_NAME בשם של תצורת האמון.

   אזורי

   במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ובמאזני עומסים פנימיים אזוריים של אפליקציות (ALB), מציינים את האזור שבו מאוחסן משאב הגדרת האמון.

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \
       --source=trust_config.yaml \
       --location=REGION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון
   • ‫REGION: האזור שבו מאוחסן משאב הגדרות האמון

יצירת אישור לקוח

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

ב-mTLS בקצה העורפי, מאזן העומסים פועל כלקוח והקצה העורפי פועל כשרת.

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

כשמתחברים לשרת קצה עורפי, מאזן העומסים מגדיר את חיווי שם השרת (SNI) לשם המארח שצוין בהגדרת ה-TLS. השרת העורפי בוחר את אישור ה-SSL/TLS המתאים על סמך ערך ה-SNI הזה. מאזן העומסים מצפה שערך ה-SNI יתאים ל-Subject Alternative Name‏ (SAN) שמופיע באישור של שרת הקצה העורפי.

אפשר להשתמש באישור לקוח שהוא אישור מנוהל מרשות אישורים פרטית דרך Certificate Authority Service או באישור PKI פרטי בניהול עצמי. בדוגמה הזו, אישור הלקוח מונפק באמצעות אישורים בניהול עצמי. בקטע הזה נעשה שימוש בספרייה OpenSSL כדי ליצור את אישור ה-CA הבסיסי ואת אישור הלקוח.

כדי ליצור אישור לקוח, מבצעים את השלבים הבאים:

1. יוצרים קובץ תצורה של OpenSSL.

   בדוגמה הבאה, קובץ ההגדרות (example.cnf) מכיל את הקטע [ca_exts], שמציין תוספים מסוג X.509 שמסמנים את האישור כמתאים לרשות אישורים (CA). המאפיין extendedKeyUsage מוגדר לערך clientAuth. למידע נוסף על הדרישות לגבי אישורי בסיס ואישורי ביניים, אפשר לעיין במאמר דרישות לגבי אישורים.

     cat > example.cnf << EOF
     [req]
     distinguished_name = empty_distinguished_name
   
     [empty_distinguished_name]
     # Kept empty to allow setting via -subj command-line argument.
   
     [ca_exts]
     basicConstraints=critical,CA:TRUE
     keyUsage=keyCertSign
     extendedKeyUsage=clientAuth
   
     EOF
   

2. יוצרים מפתח פרטי חדש מסוג RSA ‏ (client-root.key) ומשתמשים בו כדי ליצור אישור CA בסיסי בחתימה עצמית מסוג X.509 ‏ (client-root.cert), שמשמש כ-CA בסיסי.

     openssl req -x509 \
         -new -sha256 -newkey rsa:2048 -nodes \
         -days 3650 -subj '/CN=root' \
         -config example.cnf \
         -extensions ca_exts \
         -keyout client-root.key -out client-root.cert
   

3. יוצרים קובץ תצורה כדי ליצור את ה-CSR לאישור הלקוח.

   קובץ התצורה הבא (client.config) מכיל את הקטע [extension_requirements], שבו מצוינות תוספי X.509 שייכללו ב-CSR. מידע נוסף על הדרישות לאישורי לקוח זמין במאמר דרישות האישורים.

     cat > client.config << EOF
     [req]
     default_bits              = 2048
     req_extensions            = extension_requirements
     distinguished_name        = dn_requirements
     prompt                    = no
   
     [extension_requirements]
     basicConstraints          = critical, CA:FALSE
     keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
     extendedKeyUsage          = clientAuth
   
     [dn_requirements]
     countryName               = US
     stateOrProvinceName       = California
     localityName              = San Francisco
     0.organizationName        = example
     organizationalUnitName    = test
     commonName                = test.example.com
     emailAddress              = [e-mail]
   
     EOF
   

4. יוצרים בקשת חתימה על אישור (CSR‏, client.csr) לאישור הלקוח.

     openssl req -new \
         -config client.config \
         -keyout client.key -out client.csr
   

5. יוצרים אישור לקוח (client.cert) מ-CSR. ה-CA הבסיסי משתמש במפתח הפרטי (client-root.key) ובאישור (client-root.cert) שלו כדי להנפיק ולחתום על אישור הלקוח X.509.

     openssl x509 -req \
         -CAkey client-root.key -CA client-root.cert \
         -days 365 \
         -extfile client.config \
         -extensions extension_requirements \
         -in client.csr -out client.cert
   

העלאת אישור הלקוח אל Certificate Manager

כדי להעלות את אישור הלקוח אל Certificate Manager: פועלים לפי השלבים הבאים:

המסוף

1. נכנסים לדף Certificate Manager במסוף Google Cloud .

   מעבר אל Certificate Manager

2. בכרטיסייה אישורים, לוחצים על הוספת אישור.

3. מזינים שם לאישור.

   השם הזה חייב להיות ייחודי בפרויקט.

4. אופציונלי: מזינים תיאור לאישור. התיאור עוזר לכם לזהות אישור ספציפי בהמשך.

5. בקטע מיקום, בוחרים באפשרות גלובלי או אזורי.

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

6. בקטע היקף, בוחרים באפשרות אימות לקוח.

7. בקטע Certificate type (סוג האישור), בוחרים באפשרות Create Self-managed certificate (יצירת אישור בניהול עצמי).

8. בשדה אישור, מעלים קובץ אישור בקידוד PEM או מעתיקים ומדביקים את התוכן של אישור בקידוד PEM.

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

10. מציינים תווית לשיוך לאישור. אפשר להוסיף יותר מתווית אחת, אם צריך. כדי להוסיף תווית, לוחצים על הלחצן Add label ומציינים key ו-value בשביל התווית.

11. לוחצים על יצירה. מוודאים שהאישור החדש מופיע ברשימת האישורים.

gcloud

1. כדי להעלות את אישור הלקוח ל-Certificate Manager, משתמשים בפקודה gcloud certificate-manager certificates create. ההיקף של האישור הזה הוא client-auth, מה שמציין שהאישור הזה משמש כאישור לקוח ב-mTLS של השרת העורפי.

   גלובלי

   עבור מאזני עומסים גלובליים חיצוניים של אפליקציות ומאזני עומסים פנימיים של אפליקציות חוצי-אזורים, צריך ליצור אישור של Certificate Manager ברמה הגלובלית.

   gcloud certificate-manager certificates create CLIENT_ CERTIFICATE_NAME \
       --certificate-file=client.cert \
       --private-key-file=client.key \
       --scope=client-auth \
       --location=global
   

   מחליפים את CLIENT_CERTIFICATE_NAME בשם של משאב אישור הלקוח. אישור הלקוח הזה עם ההיקף client-auth משמש את משאב ההגדרה של אימות ה-Backend.

   אזורי

   עבור מאזני עומסים חיצוניים אזוריים של אפליקציות ומאזני עומסים פנימיים אזוריים של אפליקציות, צריך ליצור אישור אזורי של Certificate Manager.

   gcloud certificate-manager certificates create CLIENT_ CERTIFICATE_NAME \
       --certificate-file=client.cert \
       --private-key-file=client.key \
       --scope=client-auth \
       --location=REGION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫CLIENT_CERTIFICATE_NAME: השם של משאב אישור הלקוח. אישור הלקוח הזה עם ההיקף client-auth משמש את משאב ההגדרה של אימות ה-Backend.
   • ‫REGION: האזור שבו ייצור האישור.

יצירת משאב של הגדרות אימות לשרת העורפי

כדי ליצור משאב של הגדרת אימות בקצה העורפי (BackendAuthenticationConfig), פועלים לפי השלבים הבאים.

המסוף

1. נכנסים לדף Authentication Configuration במסוף Google Cloud .

   מעבר אל Authentication Configuration

2. בכרטיסייה Backend Authentication (אימות בקצה העורפי), לוחצים על Create (יצירה).
3. מזינים שם למשאב של הגדרת האימות של ה-Backend.
4. בקטע מיקום, בוחרים באפשרות גלובלי או אזורי.
5. בוחרים את משאב אישור הלקוח שיצרתם קודם.
6. אופציונלי: בוחרים את שורשי האמון הציבוריים.
7. בוחרים את משאב הגדרת האמון שיצרתם קודם.
8. אופציונלי: לוחצים על Equivalent code (קוד מקביל) כדי לראות את הגדרת Terraform של המשאב הזה.
9. לוחצים על יצירה.

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

gcloud

1. יוצרים קובץ YAML שמציין באופן הצהרתי את המאפיינים השונים של משאב ההגדרה של אימות ה-Backend.

   גלובלי

   בשביל מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ומאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים, צריך ליצור משאב גלובלי של הגדרות אימות בק-אנד. מצרפים את אישור הלקוח למשאב ההגדרה של אימות ה-backend כדי להפעיל mTLS של ה-backend.

   cat << EOF > BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME.yaml
   name: projects/PROJECT_ID/locations/global/backendAuthenticationConfigs/BACKEND_AUTH_CONFIG_NAME
   trustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
   clientCertificate: projects/PROJECT_ID/locations/global/certificates/CLIENT_ CERTIFICATE_NAME
   wellKnownRoots: PUBLIC_ROOTS
   EOF
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME : השם של קובץ ה-YAML שבו מוגדר משאב התצורה של אימות ה-Backend
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
   • ‫BACKEND_AUTH_CONFIG_NAME: השם של משאב ההגדרות של אימות ה-Backend
   • ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון שיצרתם קודם
   • ‫CLIENT_CERTIFICATE_NAME: השם של משאב אישור הלקוח שיצרתם קודם

   אזורי

   עבור מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB), יוצרים משאב אזורי של הגדרת אימות בקצה העורפי. מצרפים את אישור הלקוח למשאב ההגדרה של אימות ה-backend כדי להפעיל mTLS של ה-backend.

   cat << EOF > BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME.yaml
   name: projects/PROJECT_ID/locations/REGION/backendAuthenticationConfigs/BACKEND_AUTH_CONFIG_NAME
   trustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
   clientCertificate: projects/PROJECT_ID/locations/REGION/certificates/CLIENT_ CERTIFICATE_NAME
   wellKnownRoots: PUBLIC_ROOTS
   EOF
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME : השם של קובץ ה-YAML שבו מוגדר משאב התצורה של אימות ה-Backend
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
   • ‫REGION: שם האזור
   • ‫BACKEND_AUTH_CONFIG_NAME: השם של משאב ההגדרות של אימות ה-Backend
   • ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון שיצרתם קודם
   • ‫CLIENT_CERTIFICATE_NAME: השם של משאב אישור הלקוח שיצרתם קודם

2. כדי לייבא את הגדרת האימות של ה-backend, משתמשים בפקודה gcloud network-security backend-authentication-configs import.

   גלובלי

   במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים, מגדירים את הדגל --location לערך global.

   gcloud network-security backend-authentication-configs import BACKEND_AUTH_CONFIG_NAME \
       --source=BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME.yaml \
       --location=global
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_AUTH_CONFIG_NAME: השם של משאב ההגדרות של אימות ה-Backend

   • ‫BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME: השם של קובץ ה-YAML שבו מוגדר משאב ההגדרה של אימות ה-Backend

   אזורי

   במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ובמאזני עומסים פנימיים אזוריים של אפליקציות (ALB), צריך להגדיר את הדגל --location לאזור שבו מאזן העומסים מוגדר.

   gcloud network-security backend-authentication-configs import BACKEND_AUTH_CONFIG_NAME \
       --source=BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME.yaml \
       --location=REGION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_AUTH_CONFIG_NAME: השם של משאב ההגדרות של אימות ה-Backend

   • ‫BACKEND_AUTHENTICATION_CONFIG_RESOURCE_FILENAME: השם של קובץ ה-YAML שבו מוגדר משאב ההגדרה של אימות ה-Backend

   • ‫REGION: האזור שבו מוגדר מאזן העומסים

צירוף משאב של הגדרות אימות לקצה העורפי לשירות הקצה העורפי של מאזן העומסים

כדי לחבר את הגדרת האימות של ה-backend (BackendAuthenticationConfig משאב) לשירות לקצה העורפי של מאזן העומסים, מבצעים את השלבים הבאים.

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף Load balancing

2. בכרטיסייה Backends (שרתי קצה עורפיים), בוחרים את שירות הקצה העורפי שרוצים להפעיל בו TLS מאומת של הקצה העורפי ו-mTLS של הקצה העורפי.

3. לוחצים על עריכה.

4. מרחיבים את הקטע הגדרות מתקדמות.

5. בקטע Backend authentication, מסמנים את התיבה Enable.

6. אופציונלי: מציינים את שם המארח של SNI ואת שמות הנושא החלופיים (SAN) שאושרו כדי לאמת את האישור של ה-backend.

7. כדי לצרף את משאב ההגדרה של אימות ה-Backend לשירות ה-Backend, ברשימה Backend authentication config בוחרים את משאב ההגדרה של אימות ה-Backend.

8. לוחצים על Continue.

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

gcloud

1. כדי להציג את כל משאבי שירותי הקצה העורפי בפרויקט, משתמשים בפקודה gcloud compute backend-services list.

   gcloud compute backend-services list
   

   רושמים את השם של שירות ה-Backend שאליו רוצים לצרף את משאב BackendAuthenticationConfig. השם הזה נקרא BACKEND_SERVICE_NAME בשלבים הבאים.

2. כדי לייצא את הגדרות שירות לקצה העורפי לקובץ, משתמשים בפקודה gcloud compute backend-services export.

   גלובלי

   במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים, מגדירים את הדגל --location לערך global.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_FILENAME.yaml \
       --global
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫BACKEND_SERVICE_FILENAME: השם והנתיב של קובץ YAML שאליו מיוצאת הגדרת השירות לקצה העורפי

   אזורי

   במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ובמאזני עומסים פנימיים אזוריים של אפליקציות (ALB), צריך להגדיר את הדגל --location לאזור שבו מאזן העומסים מוגדר.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_FILENAME.yaml \
       --region=REGION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫BACKEND_SERVICE_FILENAME: השם והנתיב של קובץ YAML שאליו מיוצאת הגדרת השירות לקצה העורפי
   • ‫REGION: השם שלGoogle Cloud האזור שבו נמצא שירות הקצה העורפי

3. מעדכנים את מאפיין tlsSettings של שירות הקצה העורפי ומפנים אותו למשאב התצורה של אימות הקצה העורפי. בנוסף, אפשר להגדיר את שם המארח של SNI ואת ה-SAN המקובלים בשירות לקצה העורפי כדי לאמת את האישור העורפי.

   גלובלי

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

   הערכים של SNI ו-SAN בהצהרת ה-YAML הבאה הם דוגמאות בלבד. אפשר להחליף אותם בערכים מהעולם האמיתי שרלוונטיים להגדרה שלכם.

     cat << EOF >> BACKEND_SERVICE_FILENAME.yaml
     tlsSettings:
       authenticationConfig: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/global/backendAuthenticationConfigs/BACKEND_AUTH_CONFIG_NAME
       sni: examplepetstore.com
       subjectAltNames:
       - dnsName: examplepetstore.com
       - dnsName: api.examplepetstore.com
     EOF
     

   מחליפים את מה שכתוב בשדות הבאים:

   • BACKEND_SERVICE_FILENAME: השם של קובץ ה-YAML שאליו מיוצאת ההגדרה של שירות ה-Backend

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

   • ‫BACKEND_AUTH_CONFIG_NAME: השם של משאב ההגדרות של אימות ה-Backend

   אזורי

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

   הערכים של SNI ו-SAN בהצהרת ה-YAML הבאה הם דוגמאות בלבד. אפשר להחליף אותם בערכים מהעולם האמיתי שרלוונטיים להגדרה שלכם.

     cat << EOF >> BACKEND_SERVICE_FILENAME.yaml
     tlsSettings:
       authenticationConfig: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/REGION/backendAuthenticationConfigs/BACKEND_AUTH_CONFIG_NAME
       sni: examplepetstore.com
       subjectAltNames:
       - dnsName: examplepetstore.com
       - dnsName: api.examplepetstore.com
     EOF
     

   מחליפים את מה שכתוב בשדות הבאים:

   • BACKEND_SERVICE_FILENAME: השם של קובץ ה-YAML שאליו מיוצאת ההגדרה של שירות ה-Backend

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

   • ‫REGION: השם שלGoogle Cloud האזור שבו נוצרת ההגדרה של אימות ה-Backend

   • ‫BACKEND_AUTH_CONFIG_NAME: השם של משאב ההגדרות של אימות ה-Backend

4. כדי לייבא את ההגדרות המעודכנות של שירות הקצה העורפי מקובץ, משתמשים בפקודה gcloud compute backend-services import.

   גלובלי

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

     gcloud compute backend-services import BACKEND_SERVICE_NAME \
         --source=BACKEND_SERVICE_FILENAME.yaml \
         --global
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫BACKEND_SERVICE_FILENAME: השם של קובץ ה-YAML של הגדרות שירות ה-Backend

   אזורי

   במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ובמאזני עומסים פנימיים אזוריים של אפליקציות (ALB), צריך להגדיר את הדגל --region לאזור שבו ממוקם מאזן העומסים.

     gcloud compute backend-services import BACKEND_SERVICE_NAME \
         --source=BACKEND_SERVICE_FILENAME.yaml \
         --region=REGION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫BACKEND_SERVICE_FILENAME: השם של קובץ ה-YAML של הגדרות שירות ה-Backend
   • ‫REGION: השם שלGoogle Cloud האזור שבו נמצא שירות הקצה העורפי

יצירת אישור לשרת קצה עורפי

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

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

1. יוצרים קובץ תצורה כדי ליצור את ה-CSR לאישור השרת.

   קובץ התצורה הבא (server.config) מכיל את הקטע [extension_requirements], שמציין את התוספים מסוג X.509 שייכללו ב-CSR. מידע נוסף על הדרישות לגבי אישורי שרת זמין במאמר דרישות לגבי אישורים.

   cat > server.config << EOF
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = critical, CA:FALSE
   keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
   extendedKeyUsage          = serverAuth
   subjectAltName            = @alt_names
   
   [alt_names]
   DNS.1 = examplepetstore.com
   DNS.2 = api.examplepetstore.com
   
   [dn_requirements]
   countryName               = US
   stateOrProvinceName       = California
   localityName              = San Francisco
   0.organizationName        = example
   organizationalUnitName    = test
   commonName                = examplepetstore.com
   emailAddress              = [e-mail]
   
   EOF
   

2. יוצרים את ה-CSR ‏ (server.csr) לאישור השרת.

   openssl req -new \
       -sha256 -newkey rsa:2048 -nodes \
       -config server.config \
       -keyout server.key -out server.csr
   

3. יוצרים את אישור השרת X.509 ‏ (server.cert) מ-CSR. רשות האישורים הביניים משתמשת במפתח הפרטי שלה (int.key) ובאישור שלה (int.cert) כדי להנפיק ולחתום על אישור הלקוח X.509.

   openssl x509 -req \
       -CAkey int.key -CA int.cert \
       -days 365 \
       -extfile server.config \
       -extensions extension_requirements \
       -in server.csr -out server.cert
   

   כשמאזן העומסים מתחבר לשרת העורפי, השרת העורפי מציג את האישור שלו (server.cert) כדי לאמת את עצמו מול מאזן העומסים, וכך משלים את תהליך האימות של העורף.

אפשרויות נוספות להגדרת SSL בשרת אינטרנט של Apache

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

1. מעתיקים את המפתח הפרטי של השרת (server.key) ואת אישור השרת (server.cert) לשרת האינטרנט של Apache.

       cat > server.key << EOF
       -----BEGIN PRIVATE KEY-----
       [...]
       -----END PRIVATE KEY-----
       EOF
   
       sudo cp ./server.key /etc/ssl/private/server.key
       

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

       cat > server.cert << EOF
       -----BEGIN CERTIFICATE-----
       [...]
       -----END CERTIFICATE-----
       EOF
   
       sudo cp ./server.cert /etc/ssl/certs/server.cert
       

   מחליפים את [...] באישור השרת בקידוד PEM שיצרתם קודם לכן.

2. מעלים את אישור הלקוח להגדרת האמון של השרת כדי לאמת את אישור הלקוח.

         cat > client.cert << EOF
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
         EOF
   
         sudo cp ./client.cert /etc/ssl/certs/client.cert
         

   מחליפים את [...] באישור הלקוח בקידוד PEM שיצרתם קודם.

3. מעדכנים את הגדרות ה-SSL של שרת האינטרנט Apache.

   מעדכנים את הגדרת ה-SSL של Apache כדי להפעיל תעבורת HTTPS באמצעות אישור ה-SSL והמפתח הפרטי שצוינו.

       sudo vi /etc/apache2/sites-available/default-ssl.conf
   
       ----
       SSLCertificateFile      /etc/ssl/certs/server.cert
       SSLCertificateKeyFile /etc/ssl/private/server.key
       ----
       

   מעדכנים את הגדרות ה-SSL של Apache כדי לדרוש אימות של אישור הלקוח ומציינים את אישור ה-CA לצורך אימות.

       sudo vi /etc/apache2/sites-available/default-ssl.conf
   
       ----
       SSLVerifyClient require
       SSLVerifyDepth 5
       SSLCACertificateFile /etc/ssl/certs/client.cert
       ----
       

4. מבצעים גיבוב מחדש של אישורי ה-CA.

       sudo c_rehash /etc/ssl/certs/
       

5. מפעילים מחדש את שרת האינטרנט של Apache כדי להחיל את השינויים.

       sudo systemctl restart apache2.service
       

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

• סקירה כללית על mTLS
• הגדרת mTLS עם CA פרטי