סקירה כללית
ארכיטקטורת העזר הזו מגדירה את התכנון הרעיוני לשילוב של Keyfactor EJBCA Enterprise כרשות אישורים (CA) של צד שלישי ב-Google Distributed Cloud (GDC) עם air gap.
Keyfactor EJBCA Enterprise היא פלטפורמה חזקה וניתנת להתאמה של רשות אישורים שתואמת לתקן FIPS, שמאפשרת לארגונים לנהל תשתית של מפתח ציבורי (PKI) בסביבות הטרוגניות.
GDC עם air gap כולל שירות מקורי של רשות אישורים לניהול אוטומטי של מפתחות ואישורים בתוך גבולות הענן המארח. שירות ה-CA המקורי הוא הפתרון המומלץ לרוב הלקוחות, והוא מספק יכולות PKI מנוהלות באופן מלא בצורה חלקה בתוך הפלטפורמה. עם זאת, ארגונים שהתאימו את תשתית ה-PKI שלהם ל-Keyfactor EJBCA לעומסי עבודה קיימים מחוץ ל-GDC, יכולים להשתמש באותה ארכיטקטורה עקבית של רשות אישורים ובאותן מדיניות ניהול לעומסי עבודה שפועלים בסביבות GDC.
תכונות ויכולות
הפתרון מספק כמה רכיבים פונקציונליים עיקריים לניהול מחזור החיים של האישורים:
- ניהול אוטומטי של מחזור החיים של אישורים: שימוש במנפיק EJBCA בהתאמה אישית בתוך אשכולות רגילים של GDC כדי להפוך את ההקצאה, החידוש והביטול של אישורי שרת לאוטומטיים באמצעות cert-manager.
- אוטומציה סטנדרטית של ACME: תמיכה בפרוטוקול Automatic Certificate Management Environment (ACME) באמצעות אתגרי DNS-01, שמאפשרת לשירותי הפלטפורמה לבקש ולחדש אישורים בצורה חלקה.
- שילוב מאובטח של HSM: הגנה קריפטוגרפית ישירה על כל המפתחות הפרטיים של רשות האישורים בתוך מודול אבטחה לחומרה (HSM) עם אישור CC EAL4+, כדי לוודא שחומר המפתח אף פעם לא יוצא מגבולות האבטחה הפיזיים. ב-Keyfactor EJBCA Enterprise אפשר להשתמש ב-HSM מנוהל משלו או להתחבר ל-HSM חיצוני.
- תאימות ל-Air-Gap: תהליכי עבודה מיוחדים לשיקוף קובץ האימג' של מנפיק cert-manager של EJBCA ממאגרים ציבוריים למאגר Harbor הפרטי של GDC, כדי להבטיח זמינות אופליין.
- בידוד תעבורת הנתונים היוצאת: הגדרת רשת יוצאת באמצעות משאבי GDC Subnet ו-CloudNATGateway כדי להגביל את תעבורת הנתונים של GDC API ישירות לכתובת ה-IP החיצונית של שרת ה-EJBCA.
עקרונות ארכיטקטוניים
- מודל אחריות משותפת: הלקוח מפעיל את שרת ה-EJBCA החיצוני ואת ה-HSM, והוא הבעלים של תשתית ה-PKI הפיזית ומפתחות השורש של ה-CA. לעומת זאת, GDC מספק את שכבות המחשוב, ה-DNS הפנימי והלקוח האוטומטי בתוך האשכול הרגיל.
- עיצוב שמתמקד באבטחה: עומד בדרישות האבטחה עם air gap באמצעות שימוש בשיקוף מקומי של קובצי אימג' של קונטיינרים, ואכיפה של שער תעבורת נתונים יוצאת (egress) מחמיר כדי לצמצם את שטח המתקפה ברשת.
- תקנון פרוטוקולים: מתעדף פרוטוקולים סטנדרטיים (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.
- GDC Egress NAT Gateway: מפנה תנועה יוצאת מפודים של אשכולות לכתובת ה-IP החיצונית של שרת ה-EJBCA.
- Harbor Private Registry: מארח קובצי אימג' של קונטיינרים משוכפלים (כמו מנפיק cert-manager של EJBCA) לפריסה עם air gap.
מושגים וטכנולוגיות
בקטע הזה מפורטים הרכיבים הפונקציונליים, תחומי האחריות שלהם ואופן התקשורת שלהם בתוך המערכת.
תשתית ופלטפורמה
- GDC Standard Cluster: סביבת המחשוב הראשית שבה נמצאים ה-pods של מנפיק ה-EJBCA ושל cert-manager, שמבצעים אוטומציה של אישורים לעומסי עבודה.
- Harbor Registry: המקור המהימן המאובטח והמקומי לכל קובצי האימג' של קונטיינרים ב-GDC. הוא מספק סריקה אוטומטית כדי לוודא שאין בתמונות נקודות חולשה ידועות לפני הפריסה.
- GDC Egress Gateway: משאבי רשת מקוריים בפלטפורמה (Subnet ו-CloudNATGateway) שמנהלים ומאבטחים את תנועת ה-API היוצאת מפודים של אשכולות לשרת ה-CA החיצוני.
שירותים ולוגיקה
- EJBCA Enterprise Server: מנוע ה-CA החיצוני (מכשיר תוכנה או חומרה) שאחראי על ניהול היררכיות ה-CA (ברמה הבסיסית וברמה המשנית), אימות בקשות לאישורים, חתימה על אישורים ורישום רשומות ביקורת.
- מודול אבטחה לחומרה (HSM): המודול הקריפטוגרפי שתואם ל-CC EAL4+ ומטפל ביצירת מפתחות ובחתימה על אישורים, כדי להבטיח שהמפתחות הפרטיים של ה-CA לא ייחשפו אף פעם.
- GDC Internal DNS: מנהל את תחומי ה-DNS הפרטיים (
ManagedDNSZoneו-ResourceRecordSet) שמשמשים את שירות האימות של אתגר ACME כדי לאמת את הבעלות על הדומיין באמצעות רשומות TXT זמניות. - cert-manager עם מנפיק EJBCA: בקר האישורים המקורי של Kubernetes, שמיירט בקשות לאישורים ומשתמש במנפיק EJBCA כדי לתרגם אותן לקריאות מאובטחות ל-API של EJBCA.
זרימת נתונים וממשקים
- פרוטוקול ACME: ממשק ה-API הרגיל להנפקה אוטומטית של אישורי שרת מאומתים לדומיין באמצעות אתגר DNS-01.
- EJBCA REST API: ממשק API בארכיטקטורת REST שמשמש להפעלה מנהלתית ולפעולות פרוגרמטיות (כמו חתימה על CSR וביטול).
- אימות לקוח mTLS: מנגנון האימות הראשי לשילוב של cert-manager, שמאמת את זהות הלקוח באמצעות TLS הדדי באמצעות אישורי לקוח ייעודיים.
לתשומת ליבכם
- יכולת התאמה לעומס וביצועים:
- צריך להתאים את קנה המידה של שרת ה-EJBCA החיצוני (מעבד, זיכרון, קיבולת HSM) כדי לטפל בבקשות אימות וחתימה בו-זמניות, במיוחד במהלך פרופילים של הנפקת פרצים.
- צריך להגדיר את הגודל של משאבי שער היציאה של GDC כדי להבטיח זמן אחזור מינימלי לשרת ה-CA החיצוני, ולמנוע זמן קצוב לתפוגה במהלך מחזורי האימות של cert-manager.
- אבטחה ותאימות:
- בידוד מפתחות הבסיס של רשות האישורים ב-HSM חיצוני עומד בתקני אבטחה ותאימות מחמירים (כמו BSI VS-NfD).
- הרשאת אדמין ל-EJBCA צריכה להיות מוגבלת באמצעות בקרת גישה המבוססת על תפקידים (RBAC) וממופה למספרים סידוריים ייחודיים של אישורי לקוח.
- זמינות ואמינות:
- כדי להבטיח פעולה רציפה ולמנוע נקודת כשל בודדת, מומלץ לפרוס את שרת ה-EJBCA החיצוני בזמינות גבוהה בכמה אזורי זמינות (באמצעות הגדרה פעילה-פסיבית או הגדרה באשכול).
- פריסה של כמה רפליקות של בקר cert-manager ב-GDC מבטיחה שהנפקת האישורים האוטומטית בצד האשכול תישאר עמידה.
- ניהול תפעולי:
- הלקוח שומר על הבעלות על שרת ה-EJBCA, כולל תיקון המערכת, רוטציית מפתחות HSM ופרסום CRL.
- האדמינים של פלטפורמת GDC אצל הלקוח אחראים לתחזק את מנהל האישורים באשכול ואת בקר המנפיק של EJBCA, ולנהל את רשומות ה-DNS הפרטיות בצד של GDC.
החלטה לגבי העיצוב
הבחירות האדריכליות העיקריות בפתרון הזה מתמקדות באיזון בין האוטומציה לבין המגבלות של סביבת ה-air gap.
אפשרות לשילוב של EJBCA
שירות רשות האישורים המובנה של 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 מוגדר מראש עם רשויות האישורים הבסיסיות והמשניות הנדרשות, ועם פרופילים מתאימים של ישויות קצה.
- מנגנון מאובטח (כמו צומת באסטיון או תהליך עבודה של העברה אופליין) זמין לפרסום קובץ האימג' של קונטיינר המנפיק של EJBCA במרשם Harbor של GDC.
- באשכולות Kubernetes רגילים ב-GDC, מנהל האישורים מותקן מראש או מוגדר לפעולה.
מגבלות
- תחזוקה של HSM ו-EJBCA חיצוניים: מישור הבקרה של GDC לא מנהל את שרת ה-EJBCA החיצוני או את ה-HSM שמגבה אותו. פעולות במחזור החיים (גיבויים, שדרוגים, רוטציית מפתחות) מטופלות על ידי צוות התפעול של ה-PKI של הלקוח.
- אילוץ אימות DNSSEC: מכיוון שמשתמשים ב-DNS פנימי פרטי, צריך להשבית את אימות ה-DNSSEC בצד השרת בהגדרות ה-ACME כדי למנוע כשלים ברזולוציה של דומיינים פרטיים מקומיים.
- תלות בקישוריות של תעבורת נתונים יוצאת: השירותים האוטומטיים להנפקת אישורים תלויים בזמינות ובזמן האחזור של הקישור לרשת בין המארז של GDC לבין שרת ה-EJBCA החיצוני.