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

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

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

עיצוב ארכיטקטורה לניהול אישורים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בנוסף, אישורים שמנוהלים על ידי Google מאפשרים שילוב חלק עם שירותים אחרים שלGoogle Cloud . תוקף האישורים שמנוהלים על ידי Google הוא 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 הוא אוסף של מספר רשויות אישורים עם מדיניות משותפת להנפקת אישורים ומדיניות משותפת של ניהול זהויות והרשאות גישה (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 ואת המפתח הפרטי לרשות האישורים (CA) ואז מאחזרים את האישור החדש.

  4. מעלים את האישור החדש אל Certificate Manager (ניהול אישורים) למפת אישורים מתאימה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דרישות התאימות

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

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

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

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