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

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

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

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

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

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

הרשאות

בקטע הזה מפורטות ההרשאות שנדרשות כדי להגדיר 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 בשרת העורפי.
    רכיבי mTLS של ה-Backend (לחצו כדי להגדיל).

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

    בקטע הזה נעשה שימוש בספריית 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. יוצרים אישור בסיס X.509 בחתימה עצמית (root.cert). אישור הבסיס הוא בחתימה עצמית עם המפתח הפרטי שלו (root.key).

      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. חותמים על ה-CSR כדי ליצור את אישור הביניים X.509 ‏ (int.cert). ה-CSR נחתם באמצעות אישור הבסיס.

      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. בקטע מאגר אישורים, לוחצים על ישות עוגן אמינה ומעלים את קובץ האישור בקידוד PEM, או מעתיקים את תוכן האישור.

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

    7. בקטע מאגר אישורים, לוחצים על 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: האזור שבו מאוחסן משאב הגדרות האמון

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

    ב-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. למידע נוסף על הדרישות לגבי אישורי הרמה הבסיסית (root) ואישורי ביניים, אפשר לעיין במאמר דרישות לגבי אישורים.

        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. יוצרים אישור X.509 של רשות CA בסיסית בחתימה עצמית (root.cert). אישור הבסיס חתום בחתימה עצמית עם המפתח הפרטי שלו (root.key).

        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 לאישור הלקוח.

      קובץ התצורה הבא (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              = test@example.com

  EOF

    4. יוצרים את ה-CSR (client.csr) לאישור הלקוח.

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

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

        openssl x509 -req \
      -CAkey root.key -CA 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. לוחצים על יצירה.

    מוודאים שמוצג משאב ההגדרה של אימות ה-Backend.

    gcloud

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

      גלובלי

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

      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), יוצרים משאב אזורי של הגדרת אימות קצה עורפי. מצרפים את אישור הלקוח למשאב ההגדרה של האימות בעורף המערכת כדי להפעיל mTLS בעורף המערכת.

      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. כדי לייבא את הגדרת האימות של הבק-אנד, משתמשים בפקודה 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 resource) לשירות לקצה העורפי של מאזן העומסים, מבצעים את השלבים הבאים.

    המסוף

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

      כניסה לדף איזון עומסים

    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

      רושמים את השם של שירות לקצה העורפי שאליו רוצים לצרף את משאב 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_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_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.

      גלובלי

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

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

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

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

      אזורי

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

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

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

      • ‫BACKEND_SERVICE_NAME: השם של שירות לקצה העורפי
      • ‫BACKEND_SERVICE_FILENAME: השם של קובץ ה-YAML של הגדרות שירות הקצה העורפי
      • ‫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              = test@examplepetstore.com

EOF

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

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

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

      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

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