הפעלת גישה שמבוססת על אישורים לאפליקציות אינטרנט

בדף הזה מוסבר איך להפעיל גישה מבוססת-אישורים(CBA) לאפליקציות האינטרנט שלכם. אתם יכולים להשתמש ב-CBA כדי לאבטח גישה ממכשירים מהימנים לאפליקציות אינטרנט ארגוניות שפועלות ב- Google Cloud.

סקירה כללית

ב-CBA לאפליקציות אינטרנט נעשה שימוש בתכונות של בקרת גישה מבוססת-הקשר ב-Chrome Enterprise Premium ובGoogle Cloud רשתות כדי לאבטח את הגישה באמצעות TLS דו-כיווני (mTLS). אלה הרכיבים העיקריים שבהם משתמשים כדי להפעיל CBA באפליקציות אינטרנט:

• ‫Access Context Manager: מאפשר ליצור רמות גישה שדורשות אישורים כשקובעים גישה לאפליקציות אינטרנט.
• שרת proxy לאימות זהויות (IAP): מאמת את גישת המשתמשים לאפליקציות אינטרנט.
• Google Cloud מאזן עומסים ב-HTTPS: מספק אימות הדדי (mTLS) בין משתמשים לבין אפליקציות אינטרנט.
• מדיניות Chrome Enterprise: מספקת אימות הדדי (mTLS) בין משתמשים לבין אפליקציות אינטרנט כשמשתמשים בדפדפן Chrome.

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

מריצים את הפקודה הבאה כדי לוודא שמותקנת הגרסה העדכנית של Google Cloud CLI:

gcloud components update

הגדרת mTLS למאזן עומסים חיצוני מסוג HTTPS

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

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

יוצרים הגדרת אמון שתייצג את סוג תשתית המפתח הציבורי (PKI) שלכם.

כדי לבצע את המשימה הזו, צריכה להיות לכם הרשאת certificatemanager.trustconfigs.create בפרויקט היעד Google Cloud .

אפשר ליצור הגדרת אמון באמצעות אישור שהונפק על ידי Google (שיטה 1), באמצעות אישור משלכם (שיטה 2) או באמצעות אישור עם חתימה עצמית עם אימות נקודת קצה (שיטה 3).

שיטה 1

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

1. פועלים לפי השלבים ליצירת רשות אישורים (CA) בסיסית.

2. מאחזרים את התוכן של קובץ ה-PEM:

   gcloud privateca roots describe ROOT_CA_ID \
       --pool=POOL_ID \
       --location=CA_LOCATION \
       --format='value(pemCaCertificates)'
   

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

   • ‫ROOT_CA_ID: המזהה של אישור הבסיס.
   • ‫POOL_ID: המזהה של מאגר אישורי הבסיס.
   • ‫CA_LOCATION: המיקום של הרשות המאשרת.

3. מאחזרים את אישור הבסיס שמוחזר בשדה pemCaCertificates. האישור הוא המחרוזת שבין התווים BEGIN CERTIFICATE ל-END CERTIFICATE, והוא כולל את שני התווים.

4. שומרים את אישור הבסיס בפורמט PEM בקובץ.

5. יוצרים הגדרת אמון:

   1. מגדירים את משתני הסביבה הבאים:

      ROOT_PEM_FILE=TRUST_ANCHOR_PATH
      INT_PEM_FILE1=IM_CERT_PATH
      INT_PEM_FILE2=SECOND_IM_CERT_PATH
      

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

      • ‫TRUST_ANCHOR_PATH: הנתיב לעוגן האמון בפורמט PEM.
      • ‫IM_CERT_PATH: הנתיב לאישור הביניים בקידוד PEM.
      • ‫SECOND_IM_CERT_PATH: הנתיב לאישור הביניים השני בקידוד PEM.

   2. מכינים את התוכן של קובץ ה-YAML של הגדרות האמון:

      ROOT=$(cat ROOT_PEM_FILE | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
      INT_1=$(cat INT_PEM_FILE1 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
      INT_2=$(cat INT_PEM_FILE2 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
      

   3. יוצרים את קובץ ה-YAML של הגדרות האמון:

      cat << EOF > trust_config.yaml
      name: "${TRUST_CONFIG_NAME?}"
      trustStores:
      - trustAnchors:
        - pemCertificate: "${ROOT?}"
        intermediateCas:
        - pemCertificate: "${INT_1?}"
        - pemCertificate: "${INT_2?}"
       EOF
      

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

   4. מייבאים את הגדרות האמון אל Google Cloud Certificate Manager:

      gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \
        --project=GCP_PROJECT \
        --source=${PWD?}/trust_config.yaml
      

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

      • ‫TRUST_CONFIG_NAME: השם של הגדרת האמון.
      • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .

אם אתם פורסים מבנה מורכב יותר עם רשויות אישורים ברמת ביניים (intermediate) שנחתמות על ידי רשות האישורים הבסיסית (root), אתם צריכים להוסיף את רשויות האישורים ברמת הביניים כ-intermediateCAs.

שיטה 2

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

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

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

1. מגדירים את משתני הסביבה הבאים:

   ROOT_PEM_FILE=TRUST_ANCHOR_PATH
   INT_PEM_FILE1=IM_CERT_PATH
   INT_PEM_FILE2=SECOND_IM_CERT_PATH
   

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

   • ‫TRUST_ANCHOR_PATH: הנתיב לעוגן האמון בפורמט PEM.
   • ‫IM_CERT_PATH: הנתיב לאישור הביניים בקידוד PEM.
   • ‫SECOND_IM_CERT_PATH: הנתיב לאישור הביניים השני בקידוד PEM.

2. מכינים את התוכן של קובץ ה-YAML של הגדרות האמון:

   ROOT=$(cat ROOT_PEM_FILE | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
   INT_1=$(cat INT_PEM_FILE1 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
   INT_2=$(cat INT_PEM_FILE2 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
   

3. יוצרים את קובץ ה-YAML של הגדרות האמון:

   cat << EOF > trust_config.yaml
   name: "${TRUST_CONFIG_NAME?}"
   trustStores:
   - trustAnchors:
     - pemCertificate: "${ROOT?}"
     intermediateCas:
     - pemCertificate: "${INT_1?}"
     - pemCertificate: "${INT_2?}"
   EOF
   

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

4. מייבאים את הגדרות האמון אל Google Cloud Certificate Manager:

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \
     --project=GCP_PROJECT \
     --source=${PWD?}/trust_config.yaml
   

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

   • ‫TRUST_CONFIG_NAME: השם של הגדרת האמון.
   • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .

שיטה 3

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

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

יצירת מדיניות TLS כדי להפעיל mTLS במאזן העומסים החיצוני

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

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

• ‫certificatemanager.trustconfigs.use בהגדרת ההרשאות שיתוף שיצרתם עבור ServerTlsPolicy
• ‫networksecurity.serverTlsPolicies.create בפרויקט היעד Google Cloud

1. יוצרים את קובץ ה-YAML של מדיניות ה-TLS של השרת:

   cat << EOF > server_tls_policy.yaml
   name: "SERVER_TLS_POLICY_NAME"
   mtlsPolicy:
     clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
     clientValidationTrustConfig: projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME
   EOF
   

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

   • ‫SERVER_TLS_POLICY_NAME: השם של מדיניות ה-TLS של השרת.
   • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .
   • ‫TRUST_CONFIG_NAME: הגדרת האמון שיצרתם בשלב הקודם.

   מידע על אפשרויות האימות של לקוח clientValidationMode זמין במאמר מצבי אימות של לקוח MTLS.

2. מייבאים את קובץ ה-YAML של מדיניות ה-TLS של השרת אל Google Cloud הפרויקט:

   gcloud network-security server-tls-policies import ${SERVER_TLS_POLICY_NAME?} \
     --project=GCP_PROJECT \
     --source=${PWD?}/server_tls_policy.yaml \
     --location=global
   

   מחליפים את GCP_PROJECT במזהה הפרויקט. Google Cloud

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

איך מצרפים מדיניות TLS למדיניות HTTPS של יעד

כדי לבצע את המשימה הזו, צריכה להיות לכם הרשאת compute.targetHttpsProxies.get בפרויקט Google Cloud שמיועד.

1. מייצאים את שרת ה-proxy הקיים של HTTPS ליעד לקובץ מקומי:

   gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
       --project=GCP_PROJECT \
       --global \
       --destination=${PWD?}/xlb-mtls-target-proxy.yaml
   

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

   • ‫TARGET_HTTPS_PROXY_NAME: שרת ה-proxy ל-HTTPS של היעד.
   • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .

2. מוסיפים את ServerTlsPolicy להגדרת ה-Proxy ל-HTTPS של היעד:

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

   • ‫networksecurity.serverTlsPolicies.use ב-ServerTlsPolicy שיצרתם עבור ה-Proxy ל-HTTPS עם יעד
   • ‫compute.targetHttpsProxies.update בפרויקט Google Cloud היעד

   echo "serverTlsPolicy:
   //networksecurity.googleapis.com/projects/GCP_PROJECT/locations/global/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> xlb-mtls-target-proxy.yaml
   

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

   • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .
   • ‫SERVER_TLS_POLICY_NAME: מדיניות TLS של השרת.

3. מעדכנים את שרת ה-proxy של HTTPS על ידי ייבוא ההגדרה החדשה מהקובץ המקומי:

   gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
       --project=GCP_PROJECT \
       --global \
       --source=${PWD?}/xlb-mtls-target-proxy.yaml
   

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

   • ‫TARGET_HTTPS_PROXY_NAME: שרת ה-proxy ל-HTTPS של היעד.
   • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .

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

המסוף

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

2. מוסיפים את הביטוי הבא לרמת הגישה המותאמת אישית:

   אם יצרתם הגדרת אמון (שיטה 1 או שיטה 2), מוסיפים את הביטוי הבא בשדה תנאים של רמת הגישה המותאמת אישית כדי להשתמש בקשירת אישור PKI בזמן האימות:

   certIsPkiAttested(origin, ["TLS_POLICY_FULL_RESOURCE_PATH1", "TLS_POLICY_FULL_RESOURCE_PATH2", …]) == true
   

   כאשר TLS_POLICY_FULL_RESOURCE_PATH1 ו-TLS_POLICY_FULL_RESOURCE_PATH2 הם הנתיבים שמייצגים כמה הגדרות של אמון: certificatemanager.googleapis.com/projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME.

   צריך לספק לפחות נתיב אחד להגדרת אמון.

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

   • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .
   • ‫TRUST_CONFIG_NAME: השם של הגדרת האמון.

   אם השתמשתם באישור בחתימה עצמית שהונפק על ידי Google (שיטה 3), צריך להוסיף את הביטוי הבא בשדה תנאים של רמת הגישה המותאמת אישית כדי להשתמש בקישור האישור במהלך האימות:

   certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE
   

gcloud

אם יצרתם הגדרת אמון (שיטה 1 או שיטה 2), מריצים את הפקודה הבאה כדי ליצור רמת גישה מותאמת אישית שמשתמשת באימות של איגוד אישור PKI:

gcloud access-context-manager levels create ACCESS_LEVEL_NAME \
    --title=TITLE \
    --custom-level-spec=FILE \
    --description=DESCRIPTION \
    --policy=POLICY_NAME

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

• ‫ACCESS_LEVEL_NAME: שם ייחודי לרמת הגישה.
• ‫TITLE: שם קריא לאנשים.

• ‫FILE: קובץ YAML שמכיל את הביטוי הבא:

  certIsPkiAttested(origin, ["TLS_POLICY_FULL_RESOURCE_PATH1", "TLS_POLICY_FULL_RESOURCE_PATH2", …]) == true

  כאשר TLS_POLICY_FULL_RESOURCE_PATH1 ו-TLS_POLICY_FULL_RESOURCE_PATH2 הם הנתיבים שמייצגים כמה הגדרות של אמון: certificatemanager.googleapis.com/projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME.

  צריך לספק לפחות נתיב אחד להגדרת אמון.

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

  • ‫GCP_PROJECT: מזהה הפרויקט ב- Google Cloud .
  • ‫TRUST_CONFIG_NAME: השם של הגדרת האמון.

• ‫DESCRIPTION: תיאור מפורט של רמת הגישה.

• ‫POLICY_NAME: מדיניות הגישה של הארגון.

אם אין לכם הגדרת אמון כי אתם משתמשים באישור בחתימה עצמית עם Endpoint Verification (שיטה 3), מוסיפים את הביטוי הבא לרמת הגישה המותאמת אישית:

certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE

אכיפת גישה שמבוססת על אישורים באמצעות שרת proxy לאימות זהויות (IAP)

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

כדי להפעיל רכישות מתוך האפליקציה ולהגדיר את מדיניות ה-CBA:

1. אם לא הגדרתם רכישות מתוך האפליקציה, אתם צריכים לפעול לפי ההוראות כדי להגדיר אותן.
2. עוברים אל IAP כדי לצרף את רמת הגישה שיצרתם קודם:
   מעבר אל IAP
3. בוחרים את המשאב שרוצים לאבטח באמצעות CBA ולוחצים על הגדרות.
4. בשדה רמות גישה, מזינים את השם של רמת הגישה שיצרתם.

כדי להשתמש ב-Google Cloud CLI כדי להגדיר מדיניות CBA ב-IAP, אפשר לעיין במסמכי התיעוד של Google Cloud CLI.

הגדרת הדפדפן לבחירה אוטומטית של האישור

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

Chrome

מגדירים את מדיניות Chrome‏ AutoSelectCertificateForURLs כך ש-Chrome ישתמש באישור הנכון במהלך לחיצת היד של mTLS.

1. מוודאים שדפדפן Chrome מנוהל על ידי הממשק המרכזי לניהול דפדפן Chrome או על ידי מדיניות קבוצתית של Windows:

   • ‫Windows‏, macOS‏, Linux: מבצעים את השלבים להגדרת פרופיל Chrome מנוהל.
   • ‫Chrome: רישום המכשיר לארגון.

2. מוסיפים את המדיניות AutoSelectCertificateForUrls:

   1. במסוף Admin, עוברים אל מכשירים > Chrome > הגדרות > הגדרות משתמש ודפדפן > אישורי לקוח.
   2. בוחרים ארגון.
   3. מוסיפים AutoSelectCertificateForUrlsמדיניות לכתובת ה-URL של אפליקציית האינטרנט ומידע על אישור הבסיס.

מידע נוסף זמין במאמר בנושא סכימת המדיניות. הנה דוגמה להגדרת מדיניות שמשתמשת באישור מאימות נקודות קצה:

{
  "pattern":"https://[*.].mysite.com",
  "Filter":{
    "ISSUER":{
      "CN":"Google Endpoint Verification"
    }
  }
}

Safari

מגדירים את העדפת הזהות:

1. פותחים את אפליקציית Keychain Access ובוחרים באפשרות All Items (כל הפריטים).
2. בוחרים את האישור שרוצים להגדיר.
3. לוחצים על קובץ > העדפה חדשה של זהות.
4. מזינים את כתובת ה-URL ולוחצים על הוספה.

הפעולה הזו יוצרת רשומה חדשה של העדפות זהות ב-Keychain שאפשר לעדכן.

Edge

מגדירים את המדיניות של AutoSelectCertificateForUrls Edge לפי ההוראות במסמכי התיעוד של Edge.