שיטות מומלצות לשימוש ב-Certificate Manager

בדף הזה מתוארות שיטות מומלצות שונות להגדרה ולניהול של אישורים ב- Google Cloud באמצעות Certificate Manager ו-Certificate Authority Service (CA Service). בדף הזה מוסבר איך לתכנן את הארכיטקטורה של ניהול האישורים.

לפני שקוראים את הדף הזה, חשוב לעיין בדפים סקירה כללית על Certificate Manager וסקירה כללית על Certificate Authority Service.

תכנון ארכיטקטורה לניהול אישורים

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

בקטעים הבאים מוסברות ההמלצות שלנו לכל אחת מהבחירות העיצוביות.

בחירת סוג האישור

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

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

בודקים איזה סוג אישור צריך לבחור.
הערכה של סוג האישור שצריך לבחור (לחצו כדי להגדיל).

הנה כמה קישורים שימושיים למסמכי מידע בנושאים שמוזכרים בתרשים הזרימה:

ייעול ההיררכיה של שירות ה-CA הפרטי

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

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

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

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

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

  • מגדירים את Certificate Manager כך שישתמש במאגר רשויות להנפקת אישורים (CA) שיכול להנפיק אישורים מהימנים פרטיים למשאבים נתמכים.

עיצוב מומלץ של היררכיית רשויות אישורים.
העיצוב המומלץ להיררכיית ה-CA (לחצו כדי להגדיל).

שימוש בכיסוי מקיף של שמות מארחים

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

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

אם אתם מתכננים להוסיף תת-דומיינים או שירותים חדשים בהמשך, השתמשו בתווים כלליים לחיפוש כדי לכלול את תת-הדומיינים או השירותים באישור כבר מההתחלה. לדוגמה, תעודת wildcard לדומיין *.myorg.example.com מאבטחת רק את הרמה הראשונה של תת-הדומיין, ולא את הרמות העמוקות יותר של תת-הדומיין, כמו sub.subdomain.myorg.example.com.

שימוש באישורים שמנוהלים על ידי Google

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

בנוסף, אישורים בניהול Google מציעים שילוב חלק עם שירותים אחרים שלGoogle Cloud . כדי להנפיק אישורים בניהול Google שמהימנים באופן ציבורי, Certificate Manager תומך רק בPublic Certificate Authority (pki.goog) וברשות האישורים Let's Encrypt‏ (letsencrypt.org). הכלי Certificate Manager מקצה אישורים בניהול Google עם תקופת תוקף של 45 ימים או 90 ימים, בהתאם לרשות האישורים המנפיקה:

  • תוקף האישורים שהונפקו על ידי רשות אישורים ציבורית עובר בהדרגה מ-90 יום ל-45 יום. אישורים קיימים ל-90 יום נשארים בתוקף למשך 90 יום עד לחידוש הבא שלהם.
  • אישורים שהונפקו על ידי רשות האישורים Let's Encrypt תקפים למשך 90 יום.

Certificate Manager מתחיל באופן אוטומטי את תהליך החידוש כשנותר בערך שליש מתקופת התוקף של האישור. תהליך החידוש מתחיל כ-15 ימים לפני תאריך התפוגה של אישורים שתקפים ל-45 ימים, וכ-30 ימים לפני תאריך התפוגה של אישורים שתקפים ל-90 ימים.

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

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

פריסה מבוזרת של Certificate Manager

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

בנוסף, מכיוון שהמכסות והמגבלות חלות ברמת הפרויקט ב- Google Cloud , פריסת Certificate Manager בכמה פרויקטים מגדילה את המכסות הכוללות. הסיבה לכך היא שהשימוש במשאב מסוים בפרויקט כלשהו לא משפיע על המכסה שלכם בפרויקטים אחרים.

שימוש באישורים עם מפתחות ECDSA

בקטע הזה נסביר למה אנחנו ממליצים על ECDSA במקום על RSA כשיטה מומלצת למפתחות חתימה על אישורים.

באיזה סוג מפתח להשתמש

ECDSA P-256 הוא סוג המפתח המומלץ לרוב אישורי ה-TLS, כי הוא מציע אבטחה קריפטוגרפית חזקה, ביצועים מצוינים לפעולות חתימה ושימוש יעיל ברוחב הפס של הרשת.

אלה כמה מהסיבות האפשריות לשימוש בסוגים אחרים של מפתחות אישורים:

  • אם אתם צריכים לתמוך בלקוחות מדור קודם שלא תומכים באישורי ECDSA, אתם יכולים לספק אישורי RSA-2048 בנוסף לאישורי ECDSA P-256.
  • אם יש לכם דרישות תאימות ספציפיות שמחייבות שימוש במפתחות גדולים יותר או בסוגי מפתחות מסוימים, אתם יכולים להשתמש במפתחות ECDSA P-384,‏ RSA-2048,‏ RSA-3072 ו-RSA-4096.

למה כדאי לבחור ב-ECDSA במקום ב-RSA

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

לדוגמה:

  • מפתח ECDSA של 256 ביט מספק רמת אבטחה דומה לזו של מפתח RSA-3072.
  • מפתח ECDSA בגודל 384 ביט מספק רמת אבטחה גבוהה יותר מכל גודל של מפתח RSA שנתמך באופן נרחב.

היתרונות העיקריים של ECDSA:

  • ביצועים: פעולות החתימה של ECDSA דורשות הרבה פחות משאבי מחשוב מאשר פעולות RSA שמספקות רמת אבטחה מקבילה. הדבר מפחית את העומס על ה-CPU ואת זמן האחזור, וזה חשוב במיוחד במערכות עם תפוקה גבוהה או במערכות שרגישות לזמן האחזור.

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

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

שימוש במאגר רשויות להנפקת אישורים (CA) כדי להנפיק אישורים מרשויות CA פרטיות

מומלץ להשתמש במאגרי CA בשביל רשויות ה-CA המנפיקות. מאגר רשויות להנפקת אישורים (CA) הוא אוסף של כמה רשויות אישורים עם מדיניות משותפת להנפקת אישורים ומדיניות משותפת לניהול זהויות והרשאות גישה (IAM). שימוש במאגר CA מגדיל את המספר הכולל של שאילתות יעילות לשנייה (QPS) באמצעות איזון עומסים והפצה של בקשות האישורים הנכנסות בין כל רשויות ה-CA שמופעלות במאגר. כך אפשר לשפר את הביצועים בלי להשפיע על עומס העבודה או על שינויים בצד הלקוח.

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

שימוש במיפוי לאישורים

כדי להבטיח יכולת התאמה אופטימלית, מומלץ להשתמש במפות אישורים עם משאבים נתמכים. מפות אישורים מיועדות להתאמה לעומס, והן תומכות באלפי רשומות של אישורים כברירת מחדל ויכולות לטפל במיליוני אישורים. כשמשתמשים ברשומות מיפוי לאישורים במאזני עומסים, הן מקבלות קדימות על פני אישורים אחרים, כמו אישורי SSL של Compute Engine.

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

בחירת סוג ההרשאה הנכון לדומיין

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

בטבלה הבאה מתוארים השיקולים לכל גישה:

תכונה הרשאה למאזן עומסים הרשאת DNS
מורכבות ההגדרה לא צריך לבצע שלבי הגדרה נוספים או לשנות את הגדרות ה-DNS. צריך ליצור הרשאה ל-DNS ולהוסיף את רשומת ה-CNAME התואמת להגדרות ה-DNS.
אבטחת רשת צריך שתהיה גישה מלאה למאזן העומסים דרך האינטרנט ביציאה 443, כולל הגדרת ה-DNS לכל הדומיינים שמוגשים על ידי אישור. אי אפשר להשתמש בהרשאה של מאזן העומסים עם הגדרות אחרות. הרשאת DNS פועלת עם הגדרות מורכבות מאוד, כמו יציאות שאינן 443 ושכבות CDN לפני שרת ה-Proxy לחלוקת העומס.
מהירות הקצאת המשאבים הקצאה מהירה יותר. אפשר להקצות אישורים רק אחרי שמגדירים את מאזן העומסים באופן מלא והוא מטפל בתנועה ברשת. אפשר להקצות אישורים מראש, לפני ששרת ה-proxy לחלוקת העומס מוכן לטפל בתנועה ברשת.
תעודות wildcard לא נתמך. יש תמיכה.

רוטציה אוטומטית של אישורים בניהול עצמי

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

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

  1. מעקב אחרי תפוגת התוקף של האישורים באמצעות התראות ו-Cloud Monitoring. מומלץ ליצור התראה על אישורים שתוקפם יפוג ב-15 עד 30 הימים הבאים.
  2. יוצרים בקשת חתימה על אישור (CSR) ומפתח פרטי לשליחה לרשות האישורים.
  3. שולחים את ה-CSR ואת המפתח הפרטי לרשות האישורים, ואז מאחזרים את האישור החדש.

  4. מעלים את האישור החדש למפת האישורים המתאימה ב-Certificate Manager.

    • אם שמות הדומיינים באישור החדש תואמים לאישור שעומד לפוג, משתמשים בשיטה UpdateCertificate במשאב האישור הקיים.
    • אם לאישור החדש יש שמות דומיין שונים, קודם צריך להשתמש בשיטה CreateCertificateRequest עם קובצי ה-PEM (דואר עם פרטיות משופרת) החדשים כדי ליצור אותו. לאחר מכן, משתמשים בUpdateCertificateMapEntry method כדי להחליף את ההפניה לאישור הישן במפת האישורים בהפניה לאישור החדש.

    חשוב: צריך להשלים את התהליך הזה בקריאה אחת ל-API בלי לגרום לזמן השבתה.

החלת בקרת גישה מתאימה

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

החלת העיקרון של הרשאות מינימליות

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

תכנון הפרדת התפקידים

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

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

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

בפרויקטים שמארחים CA ברמה הבסיסית (root), אל תקצו תפקידים בסיסיים כמו בעלים (roles/owner), עריכה (roles/editor) ואדמין של CA Service‏ (roles/privateca.admin) לאף משתמש או קבוצה. השיטה הזו מונעת מחיקה בטעות, הגדרה שגויה וחשיפה מוגזמת. במקום זאת, השתמשו ב-Privileged Access Manager‏ (PAM) כדי לקבל גישה בדיוק בזמן (JIT) לפי הצורך, עם הצדקה ואישורים אחרי שרשות ה-CA הבסיסית הותקנה והוגדרה.

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

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

פרסונה תיאור תפקידי IAM
אדמינים של אישורים להגדיר ולנהל את התשתית של רשות האישורים והאישורים. בעלים של Certificate Manager‏ (roles/certificatemanager.owner),
אדמין של CA Service‏ (roles/privateca.admin)
מגיש הבקשה לאישור לבקש אישורים לעומסי עבודה. מבקש אישורים ב-Certificate Authority Service‏ (roles/privateca.certificateRequester)
עומסי עבודה (חשבונות שירות לאוטומציה) משמש עומסי עבודה או צינורות עיבוד נתונים כדי לבקש אישורים. מבקש אישור עומס עבודה של Certificate Authority Service‏ (roles/privateca.workloadCertificateRequester)
מהנדסי אבטחה או בעלי PKI ניהול מדיניות האישורים, הביטול ומחזור החיים. מנהל תפעול של CA Service‏ (roles/privateca.caManager), Certificate Manager של Certificate Authority Service‏ (roles/privateca.certificateManager)
מהנדסי DevOps או מהנדסי פלטפורמה לנהל את הפריסה של אישורים במאזני עומסים ועוד. עריכה ב-Certificate Manager ‏ (roles/certificatemanager.editor)
ניהול כללים לביקורת או תאימות מעקב אחרי אישורים והשימוש בהם. צפייה במנהל האישורים (roles/certificatemanager.viewer), ביקורת של Certificate Authority Service‏ (roles/privateca.auditor)

שימוש בהרשאת DNS לכל פרויקט לפריסות מרובות אזורים ומרובות עננים

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

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

שימוש ברשומות CAA כדי להגן על הדומיינים

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

כדי להבטיח את האמינות של בקשות ההנפקה והחידוש של אישורים בניהול Google, מומלץ לאשר באופן ידני את:

Cloud Logging,‏ Cloud Monitoring וניראות

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

הפעלה וצבירה של רישום ביומן ביקורת

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

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

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

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

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

הדרישות בהתאם לסיווג

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

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

כדי לקבל מידע נוסף על האופן שבו שירותי Google Cloud יכולים לעזור לעמוד בדרישות שונות של מסגרות תאימות, אפשר לעיין במקורות המידע הבאים:

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