יצירת תבנית אישור

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות ליצירת תבנית אישור, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ CA Service Operation Manager (roles/privateca.caManager) בפרויקט, בתיקייה או בארגון. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

יצירת תבנית אישור

כדי ליצור תבנית של אישור, אפשר להשתמש באחת מהשיטות הבאות:

המסוף

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

   כניסה אל Certificate Authority Service

2. לוחצים על הכרטיסייה Template manager ואז על Create template.

3. בוחרים מיקום לתבנית האישור באמצעות הרשימה אזור. זה צריך להיות אותו מיקום כמו מאגר ה-CA שבו אתם מתכוונים להשתמש עם תבנית האישור.

4. מזינים מזהה ייחודי לתבנית האישור בשדה Certificate template ID (מזהה תבנית האישור). אפשר גם להוסיף תיאור לתבנית האישור.

5. לוחצים על הבא.

6. אם רוצים להגדיר ערכי ברירת מחדל של x.509 לאישורים שמשתמשים בתבנית הזו, לוחצים על המתג Include predefined values in certificates issued using this certificate template (הכללת ערכים מוגדרים מראש באישורים שהונפקו באמצעות תבנית האישור הזו). לאחר מכן לוחצים על הגדרת ערכים מוגדרים מראש.

7. מגדירים את הערכים שנקבעו מראש באמצעות המידע הבא:

   הגדרת שימוש בסיסי במפתח

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

   1. כדי לבחור את השימושים הבסיסיים במפתח, לוחצים על המתג Specify base key usages for certificates issued from this CA pool (ציון שימושים בסיסיים במפתח לאישורים שהונפקו ממאגר רשויות האישורים הזה) ואז בוחרים מבין האפשרויות שמופיעות.
   2. לוחצים על הבא.

   הגדרת שימוש מורחב במפתח

   ההגדרה הזו מתייחסת לשדה Extended Key Usage (EKU) באישור דיגיטלי. הוא מספק הגבלות ספציפיות ומדויקות יותר על אופן השימוש במפתח, למשל לאימות שרת, לאימות לקוח, לחתימת קוד, להגנה על אימייל ועוד. מידע נוסף מפורט במאמר בנושא שימוש מורחב במפתחות.

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

   1. כדי לבחור את השימושים במפתח המורחב, לוחצים על המתג Write extended key usages for certificates issued from this CA pool (כתיבת שימושים במפתח מורחב עבור אישורים שהונפקו ממאגר CA הזה), ואז בוחרים מתוך האפשרויות שמופיעות.
   2. לוחצים על הבא.

   הגדרת מזהי מדיניות

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

   מידע נוסף זמין במאמר בנושא מדיניות אישורים.

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

   1. אופציונלי: מוסיפים את מזהה המדיניות בשדה מזהי מדיניות.
   2. לוחצים על הבא.

   הוספה של שרתי OCSP של גישה למידע על רשות (AIA)

   תוסף ה-AIA באישור מספק את המידע הבא:

   • הכתובת של שרתי ה-OCSP שדרכם אפשר לבדוק את סטטוס הביטול של האישור.
   • שיטת הגישה למנפיק האישור.

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

   הוספת שרתי OCSP היא אופציונלית. כדי להוסיף את שרתי ה-OCSP שמופיעים בשדה התוסף AIA באישורים:

   1. לוחצים על Add item.
   2. בשדה Server URL (כתובת ה-URL של השרת), מוסיפים את כתובת ה-URL של שרת ה-OCSP.
   3. לוחצים על סיום.
   4. לוחצים על הבא.

   אפשרויות ב-CA

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

   בוחרים אחת מהאפשרויות הבאות:

   1. כוללים את ההגדרות כדי לתאר את תוספי CA X.509: מציינים את ההגדרות בתבנית אישור ששולטות בתוספי X.509.

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

   3. הכללת ההגדרות לתיאור המגבלה על אורך הנתיב של תוספי X.509: מציינים את ההגדרות שקובעות את האורך המקסימלי של שרשרת אישורים, שמתחילה באישור מסוים.ההגדרה הזו מציינת את המספר המקסימלי של רשויות אישורים שאפשר לשרשר עד לאישור ה-CA הזה. אם האורך המקסימלי של נתיב המנפיק מוגדר כ-0, רשות האישורים יכולה להנפיק רק אישורים של ישויות קצה. אם הערך הוא 1, השרשרת שמתחת לאישור ה-CA הזה יכולה לכלול רק CA משני אחד. אם לא מוצהר ערך, מספר רשויות האישורים המשניות בשרשרת שמתחת לרשות האישורים הזו לא מוגבל.

   4. לוחצים על הבא.

   הגדרת תוספים נוספים

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

   1. לוחצים על Add item.
   2. בשדה Object identifier, מוסיפים מזהה אובייקט תקין שמופיע בפורמט של ספרות מופרדות בנקודות.
   3. בשדה Value, מוסיפים את הערך של המזהה בקידוד Base64.
   4. אם התוסף קריטי, בוחרים באפשרות התוסף קריטי.

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

9. בשלב הבא, עוברים לקטע הגדרת מגבלות על התוסף. בוחרים אחת מהאפשרויות הבאות:

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

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

    • העתקת הנושא מבקשות האישורים אל האישור
    • העתקת שמות חלופיים של נושאים (SAN) מבקשות האישורים אל האישור
    אופציונלי: בקטע Configure identity constraints (הגדרת אילוצים על הזהות), מוסיפים ביטוי ב-Common Expression Language‏ (CEL) כדי להגדיר הגבלות על נושאי האישורים. מידע נוסף זמין במאמר בנושא שימוש ב-CEL.

12. לוחצים על הבא ואז על סיום.

gcloud

gcloud privateca templates create TEMPLATE_ID \
  --copy-subject \
  --copy-sans \
  --identity-cel-expression <expr> \
  --predefined-values-file FILE_PATH \
  --copy-all-requested-extensions \
  --copy-extensions-by-oid <1.2.3.4,5.6.7.8> \
  --copy-known-extensions <ext1,ext2>

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

• ‫TEMPLATE_ID: המזהה הייחודי של תבנית האישור
• ‫FILE_PATH: קובץ ה-YAML שמתאר את ערכי X.509 שהוגדרו על ידי תבנית האישור

הדגל --copy-sans מאפשר להעתיק את התוסף Subject Alternative Name (שם חלופי של נושא) מבקשת האישור אל האישור החתום. אפשר גם לציין --no-copy-sans כדי להסיר מבקשת האישור את כל שמות ה-SAN שצוינו על ידי המתקשר.

הדגל --copy-subject מאפשר להעתיק את הנושא מבקשת האישור אל האישור החתום. אפשר גם לציין --no-copy-subject כדי להסיר מהבקשה לאישור את הנושאים שצוינו על ידי המתקשר.

הערה: כדי לוודא שחובה להשתמש בתבנית עם שיקוף הזהות, צריך לציין את הדגלים --no-copy-subject ו---no-copy-sans ביחד. מידע נוסף על שיקוף זהויות זמין במאמר שיקוף זהויות.

הדגל --identity-cel-expression מקבל ביטוי CEL שמוערך מול הבעלים (subject) והשם החלופי של בעלים (subject) באישור לפני שהוא מונפק, ומחזיר ערך בוליאני שמציין אם לאשר את הבקשה. מידע על שימוש בביטוי Common Expression Language ‏ (CEL) בתבנית אישור זמין במאמר שימוש ב-CEL בתבניות אישורים.

הדגל --predefined-values-file מציין את הנתיב לקובץ YAML שמתאר את כל ערכי X.509 המוגדרים מראש שהוגדרו על ידי התבנית הזו. התוספים שצוינו מועתקים לכל בקשות האישורים שמשתמשות בתבנית הזו, והם מקבלים עדיפות על פני כל התוספים המותרים בבקשת האישור. אם מעדכנים חלק כלשהו מהערכים המוגדרים מראש של X.509, העדכון מחליף את כל קבוצת הערכים המוגדרים מראש של X.509.

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

אם הדגל --copy-extensions-by-oid מוגדר, מזהי אובייקט ספציפיים מועתקים מבקשת האישור אל האישור החתום.

אם הדגל --copy-known-extensions מוגדר, הרחבות ספציפיות מועתקות מבקשת האישור אל האישור החתום. התוספים המוכרים האלה יכולים להיות אחד מהבאים: base-key-usage, extended-key-usage, ca-options, policy-ids או aia-ocsp-servers.

הערה: אי אפשר להשתמש בתג --copy-all-requested-extensions עם התגים --copy-known-extensions ו---copy-extensions-by-oid.

מסירים את הדגל --copy-all-requested-extensions כדי להתעלם מכל התוספים מסוג X.509 בבקשת האישור, אבל עדיין לשמור על ערכים מוגדרים מראש שמוגדרים בתבנית הזו.

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

דוגמה להגדרת תבנית אישור:

keyUsage:
  baseKeyUsage:
    digitalSignature: true
    keyEncipherment: true
    contentCommitment: false
    dataEncipherment: false
    keyAgreement: false
    certSign: false
    crlSign: false
    encipherOnly: false
    decipherOnly: false
  extendedKeyUsage:
    serverAuth: true
    clientAuth: false
    codeSigning: false
    emailProtection: false
    timeStamping: false
    ocspSigning: false
caOptions:
  isCa: true
  maxIssuerPathLength: 1
policyIds:
- objectIdPath:
  - 1
  - 2
  - 3
additionalExtensions:
- objectId:
    objectIdPath:
    - 1
    - 2
    - 3
  critical: false
  value: "base64 encoded extension value"

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

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

• keyUsage
• policyIds
• additionalExtensions
• השדה maxIssuerPathLength בתוסף caOptions

אם לא מציינים ערך, ערך ברירת המחדל של התוספים הבאים הוא false:

• השדה isCa בתוסף caOptions

יצירת תבנית של אישור לתרחישים נפוצים

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

אישורים לשרתי TLS של DNS לכל דומיין

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

1. יוצרים קובץ בשם leaf_server_tls_values.yaml ומוסיפים לו את הגדרות ה-TLS הבאות של שרת ישות הקצה:

   leaf_server_tls_values.yaml

   keyUsage:
     baseKeyUsage:
       digitalSignature: true
       keyEncipherment: true
     extendedKeyUsage:
       serverAuth: true
   caOptions:
     isCa: false
   

2. כדי לאפשר רק אישורים עם ערכי SAN מסוג DNS, מריצים את הפקודה gcloud הבאה:

   gcloud

   gcloud privateca templates create server-tls \
     --predefined-values-file leaf_server_tls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == DNS)"
   

   מידע נוסף על הפקודה gcloud privateca templates create זמין במאמר gcloud privateca templates create.

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

כדי ליצור תבנית אישור להנפקת אישורי TLS לשרת עם שמות SAN של DNS שמוגבלים לדומיינים לבדיקה, משתמשים בפקודה הבאה של gcloud:

gcloud

gcloud privateca templates create server-tls \
  --predefined-values-file leaf_server_tls_values.yaml \
  --copy-sans --no-copy-subject \
  --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.test.example.com'))"

התוכן של הקובץ leaf_server_tls_values.yaml צריך להיות זהה לתוכן בדוגמה הקודמת.

מידע נוסף על שימוש בביטויי CEL כדי לוודא ששמות DNS מתחילים או מסתיימים במחרוזת מסוימת זמין במאמר ביטויי CEL לדוגמה.

אישורים של זהויות עומסי עבודה

כדי ליצור תבנית אישורים להנפקת אישורי TLS בו-זמני (mTLS), פועלים לפי ההוראות הבאות:

1. יוצרים קובץ בשם leaf_mtls_values.yaml ומוסיפים לו את ההגדרות הבאות של TLS דו-כיווני של ישות קצה.

   leaf_mtls_values.yaml

   keyUsage:
     baseKeyUsage:
       digitalSignature: true
       keyEncipherment: true
     extendedKeyUsage:
       serverAuth: true
       clientAuth: true
   caOptions:
     isCa: false
   

2. כדי לאפשר רק אישורים עם כתובות URI של SPIFFE SAN, משתמשים בפקודה gcloud הבאה:

   gcloud

   gcloud privateca templates create workload-spiffe \
     --predefined-values-file leaf_mtls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == URI && san.value.startsWith('spiffe://'))"
   

   מידע נוסף על הפקודה gcloud privateca templates create זמין במאמר gcloud privateca templates create.

מידע נוסף על שימוש בביטויי CEL כדי לוודא ששמות DNS מתחילים או מסתיימים במחרוזת מסוימת זמין במאמר ביטויי CEL לדוגמה.

הענקת גישה לתבנית האישור

אפשר להשתמש בתבנית אישור אם יש לכם את התפקיד 'משתמש בתבנית אישור של שירות CA' (roles/privateca.templateUser). מומלץ שיוצרי תבנית האישור יקצו את התפקיד CA Service Certificate Template User (משתמש בתבנית אישור של שירות CA) לחברים בארגון שעשויים להשתמש בתבנית האישור הזו.

כדי להעניק את התפקיד CA Service Certificate Template User ‏ (roles/privateca.templateUser) לכל מי שנמצא בדומיין example.com, משתמשים בפקודה gcloud הבאה:

gcloud

gcloud privateca templates add-iam-policy-binding TEMPLATE_ID \
  --member "domain:example.com" \
  --role "roles/privateca.templateUser"

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

• ‫TEMPLATE_ID: המזהה הייחודי של תבנית האישור

מידע נוסף על הפקודה gcloud privateca templates add-iam-policy-binding זמין במאמר gcloud privateca templates add-iam-policy-binding.

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

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

• מידע נוסף על Common Expression Language
• איך משתמשים ב-Common Expression Language
• מידע על פרופילים של אישורים