דוגמה לארכיטקטורה של Keyfactor EJBCA

סקירה כללית

ארכיטקטורת העזר הזו מגדירה את העיצוב הקונספטואלי לשילוב של Keyfactor EJBCA Enterprise כרשות אישורים (CA) של צד שלישי ב-Google Distributed Cloud (GDC) עם בידוד פיזי.

‫Keyfactor EJBCA Enterprise היא פלטפורמה חזקה, ניתנת להרחבה ותואמת לתקן FIPS של רשות אישורים (CA), שמאפשרת לארגונים לנהל תשתית של מפתח ציבורי (PKI) בסביבות הטרוגניות.

‫GDC עם air gap כולל שירות מקורי של רשות אישורים לניהול אוטומטי של מפתחות ואישורים בתוך הגבול של הענן המארח. שירות ה-CA המקורי הוא הפתרון המומלץ לרוב הלקוחות, והוא מספק יכולות PKI מנוהלות במלואן וחלקות בתוך הפלטפורמה. עם זאת, ארגונים שהשתמשו בתשתית PKI של Keyfactor EJBCA עבור עומסי עבודה קיימים מחוץ ל-GDC, עשויים להעדיף להשתמש באותה ארכיטקטורה עקבית של רשות אישורים ומדיניות ניהול עבור עומסי עבודה שפועלים בסביבות GDC שלהם.

תכונות ויכולות

הפתרון כולל כמה רכיבים פונקציונליים מרכזיים לניהול מחזור החיים של האישורים:

• ניהול אוטומטי של מחזור החיים של אישורים: אפשר להשתמש במונפק EJBCA מותאם אישית בתוך אשכולות רגילים של GDC כדי לבצע אוטומציה של הקצאה, חידוש וביטול של אישורי שרת באמצעות cert-manager.
• אוטומציה סטנדרטית של ACME: תמיכה בפרוטוקול ACME (סביבה לניהול אוטומטי של אישורים) באמצעות אתגרי DNS-01, שמאפשרת לשירותי פלטפורמה לבקש ולחדש אישורים בצורה חלקה.
• שילוב מאובטח של HSM: הגנה קריפטוגרפית ישירה על כל המפתחות הפרטיים של רשות האישורים (CA) בתוך מודול אבטחה לחומרה (HSM) עם אישור CC EAL4+, כדי להבטיח שחומר המפתח לא ייצא אף פעם מהגבול הפיזי של האבטחה. ‫Keyfactor EJBCA Enterprise יכול להשתמש ב-HSM מנוהל משלו או להתחבר ל-HSM חיצוני.
• תאימות ל-Air-Gapped: תהליכי עבודה מיוחדים לשיקוף תמונת הנפקת האישורים של EJBCA cert-manager ממאגרי מידע ציבוריים למאגר המידע הפרטי של GDC Harbor, כדי להבטיח זמינות אופליין.
• בידוד תעבורת נתונים יוצאת: הגדרת רשת יוצאת באמצעות משאבי GDC Subnet ו-CloudNATGateway כדי להגביל את תעבורת הנתונים של GDC API ישירות לכתובת ה-IP של שרת EJBCA החיצוני.

עקרונות אדריכליים

• מודל אחריות משותפת: הלקוח מפעיל את שרת EJBCA החיצוני ואת ה-HSM, והוא הבעלים של תשתית ה-PKI הפיזית ומפתחות הבסיס של CA, בעוד ש-GDC מספק את השכבות של מחשוב, DNS פנימי ולקוח אוטומטי בתוך האשכול הרגיל.
• עיצוב שמתמקד באבטחה: עומד בדרישות האבטחה של מערכות מבודדות באמצעות שימוש במראות מקומיות של תמונות קונטיינר ואכיפה של בקרת גישה מחמירה כדי לצמצם את שטח הפנים של הרשת שחשוף להתקפות.
• תקנון הפרוטוקול: מתן עדיפות לפרוטוקולים סטנדרטיים (ACME ו-mTLS REST) לאינטראקציה עם רשות האישורים, כדי להימנע מתלות בממשקי API קנייניים ולאפשר שילובים גמישים של לקוחות.

ארכיטקטורה

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

הרכיבים העיקריים בארכיטקטורה הזו הם:

• ‫EJBCA Enterprise Server: פריסה חיצונית כמכשיר חומרה או כמכשיר תוכנה של Keyfactor, שכולל את רשויות האישורים (בסיסית ומשנית) ויוצר את כל נתוני המפתח של רשות האישורים בתוך HSM עם אישור CC EAL4+.
• ‫Default VPC: רשת VPC שבה נפרסות עומסי העבודה של המשתמשים, באשכולות Kubernetes רגילים או במכונות וירטואליות.
• ‫GDC Internal DNS: מנהל אזורי DNS פרטיים מקומיים (באמצעות שם הדומיין הפרטי שהוגדר במשתני הסביבה) שמשמשים לפתרון אתגרים של ACME DNS-01.
• שער NAT יוצא של GDC: מכוון תעבורת נתונים יוצאת מתרמילי אשכול לכתובת ה-IP של שרת EJBCA חיצוני.
• ‫Harbor Private Registry: מארח תמונות קונטיינרים משוכפלות (כמו EJBCA cert-manager issuer) לפריסה במערכות מבודדות.

מושגים וטכנולוגיות

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

תשתית ופלטפורמה

• ‫GDC Standard Cluster: סביבת המחשוב הראשית שבה נמצאים פודי ה-cert-manager וה-EJBCA issuer, שמבצעים אוטומציה של אישורים לעומסי עבודה.
• Harbor Registry: המקור המקומי המאובטח והמהימן לכל תמונות הקונטיינרים ב-GDC. הוא מספק סריקה אוטומטית כדי לוודא שהתמונות לא מכילות נקודות חולשה ידועות לפני הפריסה.
• GDC Egress Gateway: משאבי רשת מקוריים לפלטפורמה (Subnet ו-CloudNATGateway) ששולטים בתנועת API יוצאת מתרמילי אשכול לשרת CA חיצוני ומאבטחים אותה.

שירותים ולוגיקה

• ‫EJBCA Enterprise Server: מנוע רשות האישורים (CA) החיצוני (תוכנה או מכשיר חומרה) שאחראי על ניהול היררכיות של רשויות אישורים (בסיסית ומשנית), אימות בקשות לאישורים, חתימה על אישורים ורישום רשומות ביקורת.
• מודול אבטחה לחומרה (HSM): מודול קריפטוגרפי שתואם ל-CC EAL4+‎, שמטפל ביצירת מפתחות ובחתימה על אישורים, ומבטיח שהמפתחות הפרטיים של רשות האישורים לא ייחשפו לעולם.
• ‫GDC Internal DNS: מנהל אזורי DNS פרטיים (ManagedDNSZone ו-ResourceRecordSet) שמשמשים את שירות האימות של אתגר ACME כדי לאמת את הבעלות על הדומיין באמצעות רשומות TXT זמניות.
• ‫cert-manager עם EJBCA Issuer: בקר האישורים המקורי של Kubernetes שמיירט בקשות לאישור ומשתמש ב-EJBCA Issuer כדי לתרגם אותן לקריאות מאובטחות ל-EJBCA API.

זרימת נתונים וממשקים

• פרוטוקול ACME: ממשק API סטנדרטי להנפקת אישורי שרת מאומתים לדומיין באופן אוטומטי באמצעות אתגר DNS-01.
• EJBCA REST API: ממשק API בארכיטקטורת REST שמשמש לאתחול אדמיניסטרטיבי ולפעולות פרוגרמטיות (כמו חתימה על CSR וביטול).
• אימות לקוח mTLS: מנגנון האימות העיקרי לשילוב cert-manager, שמאמת את זהות הלקוח באמצעות TLS דו-כיווני (mTLS) באמצעות אישורי לקוח ייעודיים.

לתשומת ליבכם

• מדרגיות וביצועים:
  • צריך לשנות את קנה המידה של שרת EJBCA החיצוני (CPU, זיכרון, קיבולת HSM) כדי שיוכל לטפל בבקשות אימות וחתימה בו-זמניות, במיוחד במהלך פרופילים של הנפקת פרצים.
  • צריך להתאים את הגודל של משאבי שער היציאה של GDC כדי להבטיח השהיה מינימלית לשרת CA חיצוני, וכך למנוע פסק זמן במהלך מחזורי האימות של cert-manager.
• אבטחה ותאימות:
  • בידוד מפתחות הבסיס של רשות האישורים (CA) בתוך HSM חיצוני עומד בתקני אבטחה ותאימות גבוהים (כמו BSI VS-NfD).
  • צריך להגביל את הגישה האדמיניסטרטיבית ל-EJBCA באמצעות בקרת גישה מבוססת-תפקידים (RBAC) ולמפות אותה למספרים סידוריים ייחודיים של אישורי לקוח.
• זמינות ומהימנות:
  • מומלץ לפרוס את שרת EJBCA החיצוני בזמינות גבוהה בכמה אזורי זמינות (באמצעות הגדרה פעילה-סבילה או מקובצת) כדי להבטיח פעולה רציפה ולמנוע נקודת כשל יחידה.
  • פריסת כמה רפליקות של בקר cert-manager בתוך GDC מבטיחה שהנפקת האישורים האוטומטית בצד האשכול תישאר עמידה.
• ניהול תפעולי:
  • הלקוח שומר על הבעלות על שרת EJBCA, כולל תיקון המערכת, רוטציית מפתחות HSM ופרסום CRL.
  • אדמינים בפלטפורמת GDC של הלקוח אחראים לתחזוקה של cert-manager ושל בקר הנפקת EJBCA בתוך האשכול, ולניהול רשומות DNS פרטיות בצד GDC.

החלטה בנוגע לעיצוב

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

אפשרות שילוב של EJBCA

שירות Certificate Authority המקורי של GDC הוא פתרון ה-PKI המומלץ לרוב הלקוחות, והוא מספק יכולות PKI חלקות ומנוהלות במלואן בסביבות GDC עם air gap. עם זאת, לארגונים שכבר ביצעו סטנדרטיזציה של תשתית ה-PKI שלהם ב-Keyfactor EJBCA לעומסי עבודה מחוץ ל-GDC, מוצעת אפשרות להצטרף לשילוב של שרת CA חיצוני קיים. כך הם יכולים לעשות שימוש חוזר בתבניות PKI, במדיניות אבטחה ובמודלים תפעוליים קיימים בלי לעצב מחדש את היררכיית האמון או להעביר תהליכי עבודה מרכזיים.

אפשרויות אימות של אתגר ACME

יש תמיכה מלאה בפרוטוקולי האימות של אתגרי ACME‏ HTTP-01 ו-DNS-01. במדריך הארכיטקטורה הזה מודגש האתגר DNS-01 באמצעות DNS פנימי של GDC (שמתאים באופן אידיאלי לסביבות פרטיות ומבודדות שלא יכולות לתמוך בתנועת HTTP ציבורית נכנסת), אבל לקוחות יכולים לבחור באחת משיטות האימות בהתאם לטופולוגיית הרשת הספציפית שלהם, למדיניות האבטחה ולדרישות העומס.

המלצה לגבי ערוץ ניהול mTLS

מומלץ להשתמש ב-Mutual TLS ‏ (mTLS) כשיטת אימות חזקה ל-cert-manager וללקוחות משולבים. ‏mTLS מספק אימות קריפטוגרפי מאובטח מאוד של זהות הלקוח באמצעות אישורי לקוח, אבל הלקוח יכול לבחור להגדיר מנגנוני אימות אחרים שנתמכים על ידי מופע EJBCA שלו בהתאם למדיניות האבטחה הארגונית שלו.

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

הנחות

• שרת EJBCA חיצוני נפרס, הוגדר וניתן להגיע אליו באמצעות כתובת IP יציבה.
• שרת EJBCA מוגדר מראש עם רשויות ה-CA הבסיסיות והמשניות הנדרשות, ועם פרופילים מתאימים של ישויות קצה.
• קיים מנגנון מאובטח (כמו צומת bastion או תהליך עבודה של העברה אופליין) לפרסום תמונת מאגר ההנפקות של EJBCA במאגר GDC Harbor.
• בדרך כלל, באשכולות Kubernetes רגילים ב-GDC,‏ cert-manager מותקן מראש או מוגדר להפעלה.

מגבלות

• תחזוקה של HSM חיצוני ו-EJBCA: מישור הבקרה של GDC לא מנהל את שרת ה-EJBCA החיצוני או את ה-HSM שמשמש כגיבוי שלו. פעולות מחזור החיים (גיבויים, שדרוגים, החלפת מפתחות) מבוצעות על ידי צוות פעולות ה-PKI של הלקוח.
• הגבלת אימות DNSSEC: בגלל השימוש ב-DNS פנימי פרטי, צריך להשבית את אימות DNSSEC בצד השרת בהגדרת ACME כדי למנוע כשלים ברזולוציה של דומיינים פרטיים מקומיים.
• תלות בקישוריות יוצאת: השירותים האוטומטיים להנפקת אישורים תלויים בזמינות ובזמן האחזור של קישור הרשת בין מתלה GDC לבין שרת EJBCA חיצוני.