הגדרת מפתח חתימה של CA
רשות אישורים (CA) ב-Certificate Authority Service (CA Service) דורשת מפתח קריפטוגרפי כדי לחתום על האישורים שהיא מנפיקה. מפתח החתימה הזה יוצר אמון בתשתית המפתח הציבורי (PKI).
במסמך הזה מתוארות אסטרטגיות לניהול מפתחות שאפשר לבחור עבור מפתח החתימה של רשות האישורים (CA), ומוסבר איך להגדיר אותו. אתם יכולים לבחור Google-owned and managed key כדי ליהנות מניהול פשוט עם הגדרה מינימלית, או לבחור מפתח בניהול לקוח כדי לקבל שליטה ישירה יותר במחזור החיים ובמאפיינים של המפתח.
שימוש ב- Google-owned and managed key
כשמשתמשים ב- Google-owned and managed key, בוחרים את האלגוריתם הקריפטוגרפי ואת גודל המפתח. שירות CA יוצר ומנהל את מחזור החיים של מפתח ייעודי של Cloud Key Management Service בפרויקט שמנוהל על ידי Google.
בדיקת אלגוריתמים נתמכים של מפתחות חתימה
Cloud KMS תומך בשתי משפחות של אלגוריתמים לפעולות חתימה אסימטריות שמתאימות ל-CA: RSA ו-ECDSA.
RSA
סכמות חתימה מבוססות RSA מציעות תאימות רחבה. משתמשים ב-RSA אם צריך לתמוך במערכות מדור קודם. Cloud KMS מציע וריאציות של RSA_SIGN_PSS ו-RSA_SIGN_PKCS1. מידע נוסף זמין ב-RFC 8017.
RSA-PSS הוא סכמת החתימה החדשה יותר והמאובטחת יותר, והיא מומלצת לרוב ההטמעות החדשות. האפשרות RSA_SIGN_PKCS1 מסופקת לצורך תאימות למערכות קודמות שעדיין לא תומכות ב-PSS.
ECDSA
מפתחות של עקומות אליפטיות מספקים אבטחה דומה ל-RSA עם גדלים קטנים יותר של מפתחות. Cloud KMS תומך ב-EC_SIGN_P256 וב-EC_SIGN_P384. במערכות מודרניות, לרוב מעדיפים להשתמש ב-ECDSA בגלל הביצועים והיעילות שלו.
שרשראות מעורבות
שימוש במשפחות שונות של אלגוריתמים באותה שרשרת אישורים עלול לגרום לבעיות במערכות מסוימות. כדי לצמצם בעיות פוטנציאליות, מומלץ ליצור שרשרות נפרדות ל-RSA ול-ECDSA.
בדיקת גדלי המפתחות הנתמכים
גם אם גדלים גדולים יותר של מפתחות באותה משפחה מספקים אבטחה חזקה יותר, המפתחות האלה גם גורמים לאחסון ולשידור של יותר נתונים. בנוסף, פעולות הצפנה וחתימה עשויות לפעמים להימשך זמן רב יותר ככל שגודל המפתח גדול יותר, אם כי יכול להיות שההבדל לא יהיה מורגש.
כדי להשתמש במפתחות לטווח ארוך יותר, כמו אלה שמשויכים ל-CA בסיסי או ל-CA משני לטווח ארוך, אפשר להשתמש בגדלים של מפתחות עם רמת אבטחה גבוהה יותר מאשר במפתחות אחרים. לדוגמה, אפשר להשתמש במפתח RSA של 4096 ביט עבור רשות אישורים (CA) בסיסית, ובמפתחות RSA של 2048 ביט עבור רשויות אישורים משניות עם תוקף קצר יותר.
בחירת אלגוריתם חתימה למפתח של רשות האישורים
כשבוחרים אלגוריתם חתימה למפתח של רשות האישורים, כדאי לפעול לפי השלבים הבאים:
בוחרים משפחה של אלגוריתמים.
אם יוצרים CA משני שמתחבר ל-CA בסיסי קיים, צריך להשתמש באותה משפחה כמו ב-CA הבסיסי.
אם אתם יוצרים רשות אישורים (CA) חדשה מסוג Root, אבל אתם צריכים לעבוד עם מערכות מדור קודם שלא תומכות ב-ECDSA, אתם יכולים להשתמש באחד מאלגוריתמי החתימה של RSA.
אחרת, אם אף אחד מהתנאים האלה לא חל עליכם, מומלץ להשתמש באחד מאלגוריתמי החתימה של עקומות אליפטיות.
RSA only: Choose a signature algorithm.
אם אתם מתכננים לעבוד עם ספריות או מסגרות מדור קודם שלא תומכות ב-PSS, השתמשו באחד מאלגוריתמי
RSA_SIGN_PKCS1.אחרת, צריך להשתמש באחד מהאלגוריתמים
RSA_SIGN_PSS.בוחרים גודל מפתח.
אם מדובר ב-CA בסיסי חדש או ב-CA משני שאמור להיות פעיל למשך כמה שנים, מומלץ להשתמש בגודל המפתח הכי גדול שזמין לאותה משפחת אלגוריתמים.
- ב-RSA, גודל המפתח הנתמך הגדול ביותר הוא 4096 ביט.
- ב-ECDSA, גודל המפתח הנתמך הגדול ביותר הוא 384 ביט.
עבור רשויות אישורים משניות עם משך חיים קצר יותר, אפשר להשתמש בגדלים קטנים יותר של מפתחות, כמו 2048 ביט עבור RSA או 256 ביט עבור ECDSA.
שימוש במפתח בניהול הלקוח
אתם יכולים להגדיר את הרשות להנפקת אישורים (CA) כך שתשתמש במפתח חתימה אסימטרי חדש או קיים שמנוהל בפרויקט Cloud KMS שלכם. האפשרות הזו מספקת שליטה ישירה במחזור החיים, בהרשאות ובמאפיינים של המפתח. ב-Cloud KMS מוגדרים האלגוריתם והגודל של המפתח. כשמגדירים ויוצרים את ה-CA, בוחרים את גרסת המפתח הקיימת ולא את פרמטרים של האלגוריתם.
ההבדל בין מפתחות חתימה לבין מפתח הצפנה
השימוש במפתח של Cloud Key Management Service כמפתח חתימה של CA שונה מהשימוש במפתח אחד או יותר של Cloud KMS להצפנת נתונים במנוחה. ההבדל העיקרי בין שני סוגי המפתחות האלה הוא CryptoKeyPurpose שמוגדר להם ב-Cloud KMS:
- מפתחות חתימה של רשות אישורים: נדרש מפתח עם
CryptoKeyPurposeשלASYMMETRIC_SIGN. המפתחות האלה מבצעים פעולות של חתימה דיגיטלית לצורך הנפקת אישורים. - מפתחות להצפנת נתונים במנוחה: נדרש מפתח עם הרשאה
CryptoKeyPurposeשלENCRYPT_DECRYPT. המפתחות האלה מצפינים ומפענחים נתונים. מפתחות הצפנה של נתונים במנוחה נקראים גם מפתחות הצפנה בניהול הלקוח (CMEK).
אי אפשר להשתמש במפתח Cloud KMS יחיד גם לחתימה וגם להצפנת נתונים במנוחה. השימושים האלה הם ייחודיים, ואתם מגדירים אותם כשיוצרים את המפתחות.
שירות CA תומך גם בהצפנת נתונים במנוחה למשאבים כמו מאגרי CA, שאותם מגדירים בנפרד באמצעות מפתחות עם ENCRYPT_DECRYPTמטרה. מידע נוסף זמין במאמר בנושא יצירת מאגר של רשויות אישורים.
לפני שמתחילים
צריך לוודא שהדרישות הבאות מתקיימות:
- המפתח צריך להיות בפרויקט Cloud KMS. איך יוצרים מפתחות
המטרה של המפתח חייבת להיות
ASYMMETRIC_SIGN.האלגוריתם של המפתח חייב להיות אלגוריתם חתימה אסימטרי נתמך.
המפתח צריך להיות באותו מיקום שבו נמצא מאגר רשויות האישורים. לדוגמה, אם מאגר רשויות האישורים נמצא ב-
us-central1, מפתח Cloud KMS חייב להיות גם ב-us-central1. מידע על מיקומים ב-Cloud KMS זמין במאמר מיקומים ב-Cloud KMS.גרסת המפתח שבה אתם מתכננים להשתמש צריכה להיות מופעלת.
התפקידים הנדרשים
כדי לוודא שלחשבון השירות יש את ההרשאות הנדרשות לשימוש במפתח בניהול הלקוח לפעולות חתימה, צריך לבקש מהאדמין לתת לחשבון השירות את תפקיד ה-IAM Cloud Key Management Service CryptoKey Signer/Verifier (roles/cloudkms.signerVerifier) במפתח של Cloud Key Management Service.
יכול להיות שהאדמין גם יוכל לתת לחשבון השירות את ההרשאות שנדרשות באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.
איך מקבלים את מזהה המשאב של גרסת המפתח
כשיוצרים את רשות האישורים, צריך לספק את מזהה המשאב המלא של CryptoKeyVersion ספציפי ב-Cloud KMS. מעתיקים את המחרוזת הזו כדי להשתמש בה בתהליך יצירת רשות האישורים.
הפורמט הנדרש של מזהה המשאב הוא:
projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KMS_KEY/cryptoKeyVersions/VERSION
מחליפים את מה שכתוב בשדות הבאים:
- KMS_PROJECT_ID: מזהה הפרויקט שמכיל את מפתח ה-KMS
- LOCATION: המיקום של מפתח ה-KMS. המיקום הזה צריך להיות זהה למיקום של מאגר רשויות האישורים.
- KEY_RING: השם של אוסף מפתחות KMS
- KMS_KEY: השם של מפתח ה-KMS
- VERSION: גרסת מפתח ה-KMS
מידע נוסף זמין במאמר קבלת מזהה משאב של Cloud KMS. משתמשים במזהה הזה כשיוצרים רשות אישורים.
המאמרים הבאים
- איך יוצרים רשות אישורים (CA) בסיסית
- איך יוצרים רשות אישורים (CA) משנית
- מידע נוסף על Cloud KMS: מטרות ואלגוריתמים של מפתחות
- מידע נוסף על Cloud KMS: חתימות דיגיטליות
- איך מגדירים קטגוריות אחסון