‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הוספה של מדיניות הנפקת אישורים

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

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

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

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

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

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

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

המסוף

נכנסים לדף Certificate Authority Service במסוףGoogle Cloud . כניסה אל Certificate Authority Service
בדף CA pool manager, לוחצים על השם של מאגר CA שרוצים להוסיף לו מדיניות הנפקת אישורים.
בדף מאגר אישורים, לוחצים על עריכה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשרויות של CA

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

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

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

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

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

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

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

gcloud

כדי להשתמש ב-Google Cloud CLI כדי להוסיף מדיניות הנפקת אישורים למאגר רשויות אישורים, צריך ליצור קובץ YAML שמתאר את ההגבלות על האישורים שמאגר רשויות האישורים יכול להנפיק. התוכן תואם ל-IssuancePolicy.

באמצעות Cloud Shell Editor, יוצרים קובץ policy.yaml עם התוכן הבא:
```
identityConstraints:
  allowSubjectPassthrough: true
  allowSubjectAltNamesPassthrough: true
```
כאשר:
- השדה allowSubjectPassthrough הוא חובה. אם השדה allowSubjectPassthrough מוגדר לערך true, השדה subject מועתק מבקשת אישור לאישור החתום. אחרת, הנושא המבוקש יימחק.
- אם השדה allowSubjectAltNamesPassthrough מוגדר לערך true, התוסף SubjectAltNames מועתק מבקשת אישור לאישור החתום. אחרת, המערכת מתעלמת מה-SubjectAltNames המבוקש.
כדי לעדכן את מדיניות הנפקת האישורים של מאגר רשויות אישורים באמצעות הקובץ שנוצר בשלב הקודם, מריצים את הפקודה הבאה:
```
gcloud privateca pools update POOL_NAME --location LOCATION --issuance-policy FILE_PATH
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POOL_NAME: השם של מאגר רשויות האישורים
- ‫LOCATION: המיקום של מאגר הרשות שמנפיקה את האישורים. כאן מפורטת רשימת המיקומים המלאה.
- ‫FILE_PATH: הנתיב של קובץ policy.yaml
מידע נוסף על הפקודה gcloud privateca pools update זמין במאמר gcloud privateca pools update.

הגבלות נתמכות

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

הגבלה או אכיפה של ערכי X.509 מותרים

אפשר להגדיר מאגר של רשויות אישורים כך שיגביל את הערכים המותרים של X.509 בבקשות לאישור באמצעות השדה passthrough_extensions.

מאגר CA יכול גם לציין במפורש ערכי X.509 שיוגדרו בכל האישורים שהונפקו ממנו, ולדרוס את כל הערכים המבוקשים, באמצעות השדה baseline_values.

הערכים של baseline_values במאגר CA מאפשרים לציין את המאפיינים הבאים:

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

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

דוגמה: הגבלת רשות אישורים להנפקת אישורים של ישויות קצה בלבד עם ערכי X.509 עבור TLS הדדי (mTLS).

policy.yaml

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

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

policy.yaml

baselineValues:
  caOptions:
    isCa: false
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
    extendedKeyUsage:
      codeSigning: true
  aiaOcspServers:
    -   "http://foo.bar/revocation"
  additionalExtensions:
  -   objectId:
        objectIdPath:
          -   1
          -   2
          -   3
      critical: false
      value: "base64 encoded extension value"

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

הגבלת שדות הזהות המותרים

כדי להגביל את הזהות של אישורים שהונפקו דרך מאגר CA, אפשר להוסיף ביטוי [Common Expression Language (CEL)][4]{: .external} לשדה identity_constraints של מדיניות ההנפקה. ביטויים ב-CEL מאפשרים הגבלות שרירותיות על שם הדומיין של הנושא (כולל השם הנפוץ) ועל ה-SAN של אישור.

מידע נוסף על שימוש בביטוי CEL כדי להגביל את הנושא ואת ה-SANs מופיע במאמר שימוש ב-CEL.

דוגמה מאפשרים לרשות האישורים להנפיק רק אישורים שתואמים לנושא שצוין.
policy.yaml
identityConstraints: allowSubjectPassthrough: true allowSubjectAltNamesPassthrough: false celExpression: expression: 'subject.organization == "Example LLC" && subject.country_code in ["US", "UK"]'
השדה celExpression הוא אופציונלי. כדי לאמת את נושא X.509 ואת SAN שנפתרו לפני חתימה על אישור, צריך להשתמש בביטוי Common Expression Language ‏(CEL). מידע נוסף על שימוש בביטויי CEL זמין במאמר שימוש ב-CEL.

דוגמה: מתן הרשאה רק ל-SAN עם שמות DNS כמו us.google.org או עם סיומת .google.com.

policy.yaml

identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: 'subject_alt_names.all(san, san.type == DNS && (san.value == "us.google.org" || san.value.endsWith(".google.com")) )'

דוגמה: מתן הרשאה רק ל-SAN עם מזהי URI‏ https://google.com/webhp או כאלה שמתחילים ב-spiffe://example-trust-domain-1/ns/namespace1/sa/.

policy.yaml

identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: 'subject_alt_names.all(san, san.type == URI && (san.value == "https://google.com/webhp" || san.value.startsWith("spiffe://example-trust-domain-1/ns/namespace1/sa/")) )'

דוגמה: אפשר להשתמש רק ב-SAN עם כתובות אימייל example@google.com או עם סיומת @google.org.

policy.yaml

identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: 'subject_alt_names.all(san, san.type == EMAIL && (san.value == "example@google.com" || san.value.endsWith("@google.org")) )'

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

policy.yaml

identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: 'subject_alt_names.all(san, san.type == CUSTOM && san.oid == [1, 2, 3, 4] && san.value == "custom-data" )'

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

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

אפשרות 1: שינוי תאריך אוטומטי ברמת המאגר

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

משתמשים בשדה backdate_duration. הערך של not_before_time באישורים שווה לזמן ההנפקה פחות משך הזמן שצוין. הערך של not_after_time משתנה כדי לשמור על תוחלת החיים המבוקשת. הערך של backdate_duration חייב להיות קטן מ-48 שעות או שווה לו.

דוגמה

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

policy.yaml

backdateDuration: 3600s

אפשרות 2: תארוך לאחור מותאם אישית שצוין על ידי השולח

מאפשר למגישי הבקשה לציין not_before_time מותאם אישית לכל בקשת אישור.

משתמשים בשדה allow_requester_specified_not_before_time. אם מגדירים את הערך true, מבקשי האישור יכולים לספק ערך ספציפי של requested_not_before_time כשהם יוצרים אישור.

מגבלות:

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

דוגמה

כדי לאפשר שינוי תאריך רטרואקטיבי בהתאמה אישית:

policy.yaml

allowRequesterSpecifiedNotBeforeTime: true

אחרי שמגדירים את המדיניות הזו במאגר אישורים של CA, המבקשים צריכים לציין שעת התחלה (באמצעות הדגל requested_not_before_time) בכל בקשת אישור (לדוגמה, באמצעות הדגל --requested-not-before-time ב-gcloud).

הגבלת משך החיים המקסימלי של האישורים שהונפקו

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

דוגמה

כדי לאפשר משך חיים מקסימלי של 30 ימים, משתמשים בקובץ policy.yaml הבא:

policy.yaml

maximumLifetime: 2592000s

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

אפשר לבקש אישור באמצעות בקשה לחתימת אישור (CSR) או תיאור מוטבע של הערכים המבוקשים. יכול להיות שארגונים מסוימים יעדיפו להגביל את האפשרות שבה אפשר להשתמש, כי בשיטה השנייה לא נדרש אישור בעלות על המפתח הפרטי המשויך. אפשר להגדיר את ההגבלות האלה באמצעות השדה [allowedIssuanceModes][1].

למידע נוסף על הגדרת הדרכים שבהן אפשר לבקש אישורים ממאגר CA, אפשר לעיין במאמר [IssuanceModes][2].

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

דוגמה: מתן אישור להנפקת CSR בלבד.

policy.yaml

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

הגבלת אלגוריתמים של מפתחות ציבוריים בבקשת האישור

כדי להגביל את אורך המפתח המינימלי ואת האלגוריתמים של המפתח הציבורי שבהם אפשר להשתמש באישורים, אפשר להשתמש בשדה [allowedKeyTypes][3] בקובץ ה-YAML של מדיניות הנפקת האישורים. אם השדה הזה מצוין, המפתח הציבורי של בקשת האישור חייב להיות תואם לאחד מסוגי המפתחות שמופיעים בקובץ ה-YAML. אם לא מציינים את השדה הזה, אפשר להשתמש בכל מפתח, למעט מפתחות RSA שגודל המודולוס שלהם קטן מ-2048 ביט. אם רוצים להשתמש במפתח RSA עם גודל מודולוס קטן מ-2048 ביט, צריך לאפשר זאת באופן מפורש באמצעות מדיניות הנפקת האישורים.

דוגמה: אפשר להשתמש במפתחות RSA עם גודל מודולוס בין 3,072 ל-4,096 ביט (כולל), או במפתחות של אלגוריתם חתימה דיגיטלית של עקומות אליפטיות (ECDSA) מעל עקומת NIST P-256.

policy.yaml

allowedKeyTypes:
-   rsa:
  minModulusSize: 3072
  maxModulusSize: 4096
-   ellipticCurve:
      signatureAlgorithm: ECDSA_P256

אפשר לבחור באחד מאלגוריתמי החתימה הבאים של עקומות אליפטיות:

‫EC_SIGNATURE_ALGORITHM_UNSPECIFIED – אפשר להשתמש בכל אלגוריתם חתימה.
‫ECDSA_P256 – חתימה דיגיטלית של עקומה אליפטית על עקומת NIST P-256.
‫ECDSA_P384 – חתימה דיגיטלית של עקומה אליפטית על פני עקומת NIST P-384.
‫EDDSA_25519 – אלגוריתם חתימה דיגיטלית של עקומת אדוארדס על עקומה 25519, כפי שמתואר ב-RFC 8410.

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

‫[1]: /certificate-authority-service/docs/reference/rest/v1/projects.locations.caPools#IssuancePolicy.FIELDS.allowed_issuance_modes [2]: /certificate-authority-service/docs/reference/rest/v1/projects.locations.caPools#IssuanceModes [3]: /certificate-authority-service/docs/reference/rest/v1/projects.locations.caPools#IssuancePolicy.FIELDS.allowed_key_types