Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שימוש ב-mTLS בחזית עם Secure Web Proxy

אתם יכולים להגדיר Mutual TLS (mTLS) בקצה הקדמי של Secure Web Proxy כדי לשפר את האבטחה של עומסי העבודה, כמו סוכני AI. ‫Secure Web Proxy משתמש ב-mTLS בקצה הקדמי כדי לאמת את זהויות הלקוחות באמצעות אישורים.

השילוב הזה מאפשר לכם להשתמש בזהויות לקוח מאומתות בכללי הרשאה ב-Secure Web Proxy כדי לאכוף בקרת גישה מפורטת לתנועה יוצאת.

איך זה עובד

בשלבים הבאים מוסבר איך Secure Web Proxy משתמש ב-mTLS של קצה קדמי כדי לאבטח תעבורת נתונים יוצאת:

חיבור מפורש לשרת proxy: אתם יכולים להגדיר את הלקוח להשתמש ב-Secure Web Proxy כשרת proxy מפורש. הלקוח יוזם בקשת HTTPS CONNECT לשרת הקצה הקדמי של Secure Web Proxy, במקום להתחבר ישירות לאינטרנט.
לחיצת יד (handshake) של TLS הדדי: במהלך הגדרת החיבור, Secure Web Proxy והלקוח מבצעים לחיצת יד של mTLS בחלק הקדמי של ה-proxy. שרת ה-Proxy משתמש במשאב TrustConfig מוגדר כדי לאמת את האישור של הלקוח, והלקוח מאמת את אישור השרת של ה-Proxy.
שליפת זהות: אחרי לחיצת יד מוצלחת, Secure Web Proxy שולף תכונות ייחודיות של זהות, כמו URI_SAN, ישירות מאישור הלקוח שאומת.
הרשאה מבוססת-זהות: Secure Web Proxy מעריך את הבקשה היוצאת בהתאם למדיניות ההרשאות שהגדרתם. כדי לקבוע אם הבקשה מורשית, שרת ה-proxy משתמש בזהות של הלקוח, שאומתה באופן קריפטוגרפי במהלך לחיצת היד של mTLS.
אבטחת תעבורת נתונים יוצאת: אחרי שהבקשה מאושרת ואם יש כלל תואם ליעד חיצוני, Secure Web Proxy ממלא את הבקשה ליעד.

יתרונות מרכזיים

הגדרת mTLS בקצה הקדמי ב-Secure Web Proxy מספקת את היתרונות הבאים מבחינת אבטחה ותפעול:

אבטחה משופרת: השגת גישה של אפס אמון (Zero Trust) על ידי דרישת אימות mTLS בקצה הקדמי לכל תעבורת הנתונים היוצאת. כך מוודאים שרק עומסי עבודה עם זהות מאומתת יכולים ליצור חיבור לפרוקסי כדי לגשת לשירותים חיצוניים.
הגדרה פשוטה יותר של עומסי עבודה: אפשר להשתמש במצב הניתוב לשרת proxy מפורש עבור Secure Web Proxy כדי לנצל את היכולת של השרת ליירט בקשות ולאמת אותן.
שליטה מפורטת: אפשר לאכוף כללי מדיניות מפורטים שמודעים לזהות כדי לקבוע לאילו שירותים חיצוניים כל עומס עבודה ספציפי יכול לגשת.

תרחיש לדוגמה: אימות הזהות של עומסי העבודה

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

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

הגדרת אימות mTLS בקצה הקדמי של Secure Web Proxy

בקטע הזה מוסבר איך להגדיר אימות mTLS בחלק הקדמי של מופע Secure Web Proxy.

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

מעיינים בדף ניהול הגדרות אמון.
התקנה של Google Cloud CLI
מפעילים את ממשקי ה-API הנדרשים
צריך לבקש מהאדמין של ניהול הזהויות והרשאות הגישה (IAM) להקצות לכם את התפקידים הבאים:
- התפקיד 'בעלים' ב-Certificate Manager (roles/certificatemanager.owner)
- התפקיד Compute Network Admin ‎ (roles/compute.networkAdmin)
- תפקיד Security Admin ב-Compute (roles/compute.securityAdmin)
- תפקיד אדמין של אבטחת רשת (roles/networksecurity.admin)
אתם צריכים שיהיה לכם מופע של Secure Web Proxy שפרסתם במצב ניתוב של proxy מפורש.

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

בקטע הזה מוסבר איך להשתמש ב-OpenSSL כדי ליצור אישור של רשות אישורי בסיס (CA) (ישות עוגן אמינה) ואישור CA ביניים אופציונלי. שרת ה-Proxy המאובטח לאינטרנט משתמש באישורים האלה כדי לאמת את אישורי הלקוח שמצורפים לעומסי העבודה במהלך תהליך לחיצת היד של mTLS בחלק הקדמי. התהליך הידני הזה מיועד לבדיקה ולפיתוח של סביבות כדי לספק את נקודת האמון ש-Secure Web Proxy צריך כדי לאמת אישורי לקוח.

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

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

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

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

יוצרים אישור בסיס 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

יוצרים את בקשת החתימה על האישור (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

חותמים על בקשת החתימה על האישור (CSR) כדי ליצור את אישור הביניים X.509 (int.cert).

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

יצירת אישור לקוח לבדיקה

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

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

מריצים את הפקודה הבאה של OpenSSL כדי ליצור מפתח RSA פרטי בשם client.key:
```
openssl genpkey -algorithm RSA -out client.key
```

יוצרים קובץ תצורה בשם client.cnf שמציין שם DNS עבור השם החלופי של בעלים (subject) (SAN). כך אפשר לוודא שהאישור תואם לדרישות האבטחה המודרניות.

cat > client.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = my-client.example.com

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = my-client.example.com

EOF

אפשר לשנות את הערכים של CN ושל DNS.1 לפי הצורך לצורך בדיקה.

מריצים את פקודת הבקשה של OpenSSL באמצעות המפתח הפרטי וקובץ ההגדרות שיצרתם כדי ליצור קובץ client.req.
```
openssl req -new -key client.key -out client.req -config client.cnf
```
משתמשים בפקודה x509 של OpenSSL כדי לחתום על הבקשה באמצעות אישור הביניים (int.cert) והמפתח (int.key). מגדירים תקופת תוקף, למשל 365 ימים, ומוודאים שהתוספים מקובץ ההגדרות מוחלים על קובץ client.cert שנוצר.
```
openssl x509 -req -in client.req -CA int.cert -CAkey int.key \
  -set_serial 02 -days 365 -out client.cert \
  -extfile client.cnf -extensions v3_req
```
במהלך התהליך הזה נוצר הקובץ client.cert. מתעדים את הערך שמשמש ב-DNS SAN (לדוגמה, my-client.example.com) בתור זהות הלקוח. אפשר להשתמש בערך הזה כדי לזהות את עומס העבודה כשיוצרים מדיניות הרשאות ל-Secure Web Proxy.

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

מעצבים את האישורים הבסיסיים ואישורי הביניים כמשתני סביבה לשימוש בקובץ trust_config.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. הגדרת האמון מציינת למופע של Secure Web Proxy אילו אישורים של רשות אישורים (CA) מהימנים כשמאמתים אישורי לקוח שמוצגים במהלך לחיצת יד של mTLS בקצה הקדמי.

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

יוצרים קובץ trust_config.yaml.

cat << EOF > trust_config.yaml
trustStores:
  TRUST_CONFIG_NAME:
    trustAnchors:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----
    intermediateCAs:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----

EOF

מחליפים את TRUST_CONFIG_NAME בשם של משאב trustConfig.

מייבאים את הקובץ trust config.yaml באמצעות הפקודה gcloud certificate-manager trust-configs import.
```
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\
  --source=trust_config.yaml \
  --location=LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון
- ‫LOCATION: האזור שבו מאוחסן משאב הגדרות האמון

יצירת משאב `ServerTlsPolicy`

ServerTlsPolicy משאב – נקרא גם משאב לאימות לקוח – מגדיר איך Secure Web Proxy מאמת אישורים של לקוחות. היא מאפשרת לכם לציין את מצב ה-TLS בצד השרת ואת משאב הגדרות האמון לצורך אימות האישור.

המאפיין clientValidationMode קובע איך המערכת מטפלת בחיבור כשלקוח מספק אישור לא תקין או לא מספק אישור בכלל. מידע נוסף זמין במאמר בנושא מצבי אימות של לקוח mTLS בקצה הקדמי.

אלה הערכים של מאפיין clientValidationMode:

‫REJECT_INVALID: Secure Web Proxy מאפשר רק חיבורים מלקוחות שמציגים אישור תקף שנחתם על ידי רשות אישורים בהגדרת האמון שלכם. המערכת דוחה חיבורים עם אישורים לא תקינים או חסרים.
‫ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Secure Web Proxy מאפשר את בקשת החיבור גם אם אישור הלקוח לא תקף, לא ניתן לאמת אותו מול הגדרת האמון או שהוא חסר לחלוטין.

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

כדי ליצור משאב ServerTlsPolicy:

יוצרים קובץ server_tls_policy.yaml. בוחרים אחת מהאפשרויות הבאות עבור clientValidationMode:
- אפשרות 1: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
- אפשרות 2: REJECT_INVALID
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: REJECT_INVALID
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVER_TLS_POLICY_NAME: השם של ServerTlsPolicy המשאב
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
- ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון
- ‫LOCATION: האזור שבו מוגדרת מכונת Secure Web Proxy
מייבאים את המשאב ServerTlsPolicy באמצעות הפקודה gcloud network-security server-tls-policies import.
```
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\
  --source=server_tls_policy.yaml \
  --location=LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVER_TLS_POLICY_NAME: השם של ServerTlsPolicy המשאב
- ‫LOCATION: האזור שבו מוגדרת מכונת Secure Web Proxy
אופציונלי: כדי להציג רשימה של כל המשאבים של ServerTlsPolicies, משתמשים בפקודה gcloud network-security server-tls-policies list.
```
gcloud network-security server-tls-policies list \
  --location=LOCATION
```
מחליפים את LOCATION באזור שבו מוגדרת מכונת Secure Web Proxy.

משייכים את משאב `ServerTlsPolicy` למופע Secure Web Proxy

מצרפים את המשאב ServerTlsPolicy לקובץ gateway.yaml של מופע Secure Web Proxy.
```
echo "serverTlsPolicy:
//networksecurity.googleapis.com/projects/PROJECT_ID/locations/
LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME"
>> gateway.yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
- ‫LOCATION: האזור שבו מוגדרת מכונת Secure Web Proxy
מייבאים את התצורה של מכונת ה-Secure Web Proxy מקובץ gateway.yaml באמצעות הפקודה gcloud network-services gateways import.
```
gcloud network-services gateways import GATEWAY_NAME\
    --source=gateway.yaml \
    --location=LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GATEWAY_NAME: השם של מופע Secure Web Proxy
- ‫LOCATION: האזור שבו מוגדרת מכונת Secure Web Proxy

הגדרת מדיניות הרשאות

מידע נוסף זמין במאמר בנושא הגדרת מדיניות הרשאות ל-Secure Web Proxy.

רישום ביומן

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

מגבלות

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

מידע נוסף מופיע בקטע מגבלות של mTLS בחלק הקדמי.

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

פריסת Secure Web Proxy כשירות Private Service Connect