הגדרת בדיקת TLS

בדף הזה מוסבר איך להגדיר בדיקה של Transport Layer Security‏ (TLS) ב-Cloud Next Generation Firewall.

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

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

הפעלת Certificate Authority Service

‫Cloud NGFW משתמש ב-Certificate Authority Service כדי ליצור רשויות אישורים (CA) ביניים. ‫Cloud NGFW משתמש ברשויות האישורים הביניים האלה כדי ליצור את האישורים שמשמשים לבדיקת TLS.

אפשר להפעיל את CA Service API באמצעות מסוף Google Cloud :

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

להפעלת ה-API

כדי להפעיל את CA Service באמצעות Google Cloud CLI, משתמשים בפקודה הבאה:

   gcloud services enable privateca.googleapis.com
  

הפעלת Certificate Manager

‫Cloud NGFW משתמש בCertificate Manager כדי ליצור הגדרות אמון. אם לא רוצים להשתמש בהגדרות אמון, מדלגים על השלב הזה.

אפשר להפעיל את Certificate Manager API באמצעות מסוף Google Cloud :

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

להפעלת ה-API

כדי להפעיל את Certificate Manager באמצעות Google Cloud CLI, משתמשים בפקודה הבאה:

   gcloud services enable certificatemanager.googleapis.com
  

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

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

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

1. יצירת מאגר של רשויות אישורים

   מאגר אישורי ה-CA שיוצרים בשלב הזה שונה מזה שיוצרים כדי להגדיר את מדיניות הבדיקה של TLS.

2. יוצרים CA בסיסי באמצעות מאגר ה-CA שיצרתם קודם.

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

3. יצירת אישור באמצעות מפתח שנוצר אוטומטית משתמשים באותו שם של מאגר CA שיצרתם קודם.

4. מקבלים את האישור הציבורי של רשות האישורים מהאישור שנוצר.

   $PEM-CERT=$(gcloud privateca roots describe ROOT_CA_NAME \
      --location LOCATION \
      --project PROJECT_ID \
      --pool CA_POOL \
      --format "value(pemCaCertificates)")
   

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

   • ‫ROOT_CA_NAME: השם של רשות האישורים (CA) הבסיסית
   • ‫LOCATION: המיקום של רשות האישורים (CA) הבסיסית
   • ‫PROJECT_ID: מזהה הפרויקט של רשות האישורים הבסיסית
   • ‫CA_POOL: השם של מאגר רשויות האישורים שאתם רוצים ליצור ממנו את האישורים

5. יוצרים ומייבאים הגדרת אמון באמצעות PEM-CERT שהתקבל בשלב הקודם. אם אתם משתמשים ברשות אישורים משלכם, צריך להשתמש באישור הציבורי שהתקבל מרשות האישורים.

משתמשים בהגדרת האמון הזו כדי ליצור מדיניות לבדיקת TLS.

יצירת מאגר רשויות אישורים

כדי להשתמש בשירות CA כדי ליצור CA, צריך ליצור מאגר CA.

חשוב: Cloud NGFW יוצר מעת לעת רשות אישורים ביניים (CA) שמאגר רשויות האישורים ב-Certificate Authority Service חותם עליה, ואז הוא משתמש ברשות האישורים ביניים הזו כדי לחתום על אישורי שרת. ‫Cloud NGFW לא תומך בכללי מדיניות להנפקת אישורים או במגבלות על שמות אישורים שמצורפים למאגר של רשויות אישורים. אם יש מאפייני הגבלה שמשויכים למאגר אישורי ה-CA, ‏ Cloud NGFW יכול ליצור אישורים לא תקפים.

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

משתמשים במאגר רשויות האישורים הזה כדי ליצור מדיניות לבדיקת TLS.

יצירת רשות אישורים (CA) עליונה

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

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

ב-NGFW Enterprise, כדי ליצור רשות אישורים ברמת ביניים, צריך להגביל את אורך הנתיב של אישורים משניים ל-1 לפחות. כברירת מחדל, האישור המשני ו-CSR נוצרים עם הגבלת אורך נתיב של 0. צריך לשנות את זה. נכון לעכשיו, אי אפשר לעשות את זה דרך המסוף, אלא רק דרך פקודות Google Cloud CLI שסופקו על ידי CAS, באמצעות חלק מהדגלים הבאים

• הדגל --extended-key-usages: מציין את השימושים המורחבים במפתח של האישור.

• הדגל --key-usages: מציין את השימושים במפתח עבור האישור.

• הדגל --max-chain-length: מגדיר את העומק המקסימלי של רשויות CA משניות שמותרות במסגרת רשות ה-CA הזו לאישור CA.

gcloud

gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_POOL_ID \
    --location=LOCATION \
    --create-csr --csr-output-file=FILE_NAME \
    --key-algorithm="ec-p256-sha256" \
    --subject="CN=Example Server TLS CA, O=Example LLC
    --key-algorithm=rsa-pss-4096-sha256 \
    --key-usages=cert_sign,crl_sign \
    --extended-key-usages=server_auth \
    --max-chain-length=1"
  

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

• ‫SUBORDINATE_CA_ID: המזהה הייחודי של רשות האישורים המשנית.
• ‫SUBORDINATE_POOL_ID: השם של מאגר רשויות האישורים.
• ‫LOCATION: המיקום של מאגר אישורי ה-CA.
• ‫FILE_NAME: השם של הקובץ שבו נכתב ה-CSR בקידוד PEM.

הפעולה הזו יוצרת את ה-CSR ומחזירה את הפלט הבא

    Created Certificate Authority [projects/my-project-pki/locations/us-west1/caPools/SUBORDINATE_POOL_ID/certificateAuthorities/SUBORDINATE_CA_ID] and saved CSR to FILE_NAME.
    

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

יצירה של חשבון שירות

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

1. יוצרים חשבון שירות:

    gcloud beta services identity create \
        --service networksecurity.googleapis.com \
        --project PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה הפרויקט של חשבון השירות.

   ‫Google Cloud CLI יוצר חשבון שירות בשם [e-mail]. ‫PROJECT_NUMBER הוא המזהה הייחודי של PROJECT_ID שסיפקתם בפקודה הקודמת.

2. נותנים לחשבון השירות הרשאה ליצור אישורים שמשתמשים במאגר רשויות האישורים:

    gcloud privateca pools add-iam-policy-binding CA_POOL \
        --member 'serviceAccount:SERVICE_ACCOUNT' \
        --role 'roles/privateca.certificateRequester' \
        --location REGION
   

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

   • ‫CA_POOL: השם של מאגר רשויות האישורים שאתם רוצים ליצור ממנו את האישורים
   • ‫SERVICE_ACCOUNT: השם של חשבון השירות שיצרתם בשלב הקודם
   • ‫LOCATION: האזור של מאגר אישורי ה-CA

הגדרת בדיקת TLS

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

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

יצירת מדיניות לבדיקת TLS

ההרשאות שנדרשות למשימה הזו

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

הרשאות

• certificatemanager.trustconfigs.list
• certificatemanager.trustconfigs.use
• privateca.caPools.list
• privateca.caPools.use
• privateca.certificateAuthorities.list
• networksecurity.operations.get
• networksecurity.tlsInspectionPolicies.list
• networksecurity.tlsInspectionPolicies.create

תפקידים

• compute.securityAdmin
• compute.networkAdmin

המסוף

1. נכנסים לדף TLS inspection policies במסוף Google Cloud .

   מעבר למדיניות בנושא בדיקת TLS

2. בתפריט לבחירת פרויקטים, בוחרים את הפרויקט הרצוי.

3. לוחצים על יצירת מדיניות לבדיקת TLS.

4. בשדה Name (שם), מזינים שם.

   אל תכללו בשם של מדיניות הבדיקה של TLS מידע רגיש כמו פרטים אישיים מזהים (PII) או נתוני אבטחה.

5. אופציונלי: בשדה תיאור, מזינים תיאור.

6. ברשימה Region, בוחרים את האזור שבו רוצים ליצור את מדיניות הבדיקה של TLS.

7. ברשימה מאגר CA, בוחרים את מאגר ה-CA שממנו רוצים ליצור את האישורים.

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

8. אופציונלי: ברשימה גרסת TLS מינימלית, בוחרים את גרסת ה-TLS המינימלית שהמדיניות תומכת בה.

9. בקטע Trust Configuration (הגדרת אמון), בוחרים באחת מהאפשרויות הבאות:

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

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

     ברשימה Private trust configuration, בוחרים את הגדרת האמון עם מאגר אישורים שהוגדר לשימוש לצורך אמון באישורים של שרתים במעלה הזרם. מידע נוסף על יצירת הגדרות הרשאות שיתוף זמין במאמר יצירת הגדרות הרשאות שיתוף.

   • רשויות אישורים ציבוריות ופרטיות: בוחרים באפשרות הזו אם רוצים להשתמש ברשויות אישורים ציבוריות ופרטיות.

10. אופציונלי: ברשימה Cipher suite profile (פרופיל של חבילת הצפנה), בוחרים את סוג פרופיל ה-TLS. אפשר לבחור אחד מהערכים הבאים:

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

    • בהתאמה אישית: מאפשרת לבחור תכונות TLS בנפרד.

      ברשימה Cipher suites, בוחרים את השם של cipher suites שנתמכות בפרופיל המותאם אישית.

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

gcloud

1. יוצרים קובץ YAML TLS_INSPECTION_FILE.yaml. מחליפים את TLS_INSPECTION_FILE בשם קובץ לבחירתכם.

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

   name: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_NAME
   caPool: projects/PROJECT_ID/locations/REGION/caPools/CA_POOL
   minTlsVersion: TLS_VERSION
   tlsFeatureProfile: PROFILE_TYPECIPHER_NAME
   excludePublicCaSet: `TRUE`|`FALSE`
   trustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
   

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

   • ‫PROJECT_ID: מזהה הפרויקט של מדיניות בדיקת ה-TLS
   • ‫REGION: האזור שבו נוצרת מדיניות בדיקת ה-TLS
   • ‫TLS_INSPECTION_NAME: השם של מדיניות הבדיקה של TLS
     אל תכללו בשם של מדיניות הבדיקה של TLS מידע רגיש כמו פרטים אישיים מזהים או נתוני אבטחה.

   • ‫CA_POOL: השם של מאגר רשויות האישורים שאתם רוצים ליצור ממנו את האישורים

     מאגר אישורי ה-CA חייב להיות באותו אזור.

   • ‫TLS_VERSION: ארגומנט אופציונלי שמציין את גרסת ה-TLS המינימלית שנתמכת על ידי Cloud NGFW

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

     • TLS_1_0
     • TLS_1_1
     • TLS_1_2

   • ‫PROFILE_TYPE: ארגומנט אופציונלי שמציין את סוג פרופיל ה-TLS

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

     • ‫PROFILE_COMPATIBLE: מאפשר את קבוצת הלקוחות הרחבה ביותר, כולל לקוחות שתומכים רק בתכונות TLS לא עדכניות, לנהל משא ומתן על TLS.
     • ‫PROFILE_MODERN: תומך במגוון רחב של תכונות TLS, ומאפשר ללקוחות מודרניים לנהל משא ומתן על TLS.
     • ‫PROFILE_RESTRICTED: תומך בקבוצה מצומצמת של תכונות TLS שמיועדות לעמוד בדרישות תאימות מחמירות יותר.
     • ‫PROFILE_CUSTOM: מאפשרת לבחור תכונות TLS בנפרד.

   • ‫CIPHER_NAME: ארגומנט אופציונלי שמשמש לציון השם של סט האלגוריתמים להצפנה שפרופיל המותאם אישית תומך בו

     מציינים את הארגומנט הזה רק אם סוג הפרופיל מוגדר ל-PROFILE_CUSTOM.

   • ‫excludePublicCaSet: דגל אופציונלי להכללה או להחרגה של קבוצת רשויות אישורים ציבוריות. כברירת מחדל, ההגדרה של הדגל הזה היא false. אם הדגל הזה מוגדר כ-true, חיבורי TLS לא נסמכים על שרתי CA ציבוריים. במקרה כזה, Cloud NGFW יכול ליצור חיבורי TLS רק לשרתים עם אישורים שחתומים על ידי רשויות אישורים בהגדרת המהימנות.

   • ‫TRUST_CONFIG_NAME: ארגומנט אופציונלי לציון השם של משאב הגדרות האמון

3. מייבאים את מדיניות בדיקת ה-TLS שיצרתם בקטע יצירת מדיניות בדיקת TLS.

   gcloud network-security tls-inspection-policies import TLS_INSPECTION_NAME \
       --source TLS_INSPECTION_FILE.yaml \
       --location REGION
   

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

   • ‫TLS_INSPECTION_NAME: השם של מדיניות הבדיקה של TLS
   • ‫TLS_INSPECTION_FILE: השם של קובץ ה-YAML של מדיניות בדיקת ה-TLS

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

הוספת מדיניות בדיקה של TLS לשיוך של נקודת קצה לחומת אש

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

הגדרת כללי מדיניות חומת אש עם בדיקת TLS

כדי להפעיל בדיקת TLS ברשת של הענן הווירטואלי הפרטי (VPC), צריך להגדיר את הדגל --tls-inspect בכלל מדיניות חומת האש. התג הזה מציין שאפשר לבצע את הבדיקה של TLS כשמוחל פרופיל האבטחה.

כאן אפשר לקרוא מידע נוסף על הפעלת הדגל --tls-inspect בכללים של מדיניות חומת אש היררכית.

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

מה השלב הבא?

• ניהול בדיקת TLS
• הגדרת שירות סינון כתובות URL
• הגדרת שירות גילוי ומניעת חדירות
• יצירה וניהול של נקודות קצה של חומת אש