AWS Client VPN: איזה CA צריך להנפיק תעודות לקוח?
CA קיים, מנפיק עצמאי ו-AWS Private CA מחלקים את העבודה אחרת. החליטו מי מאשר, מחדש ומבטל תעודות לקוח לפני ההשקה.
שאלת התעודות ב-AWS Client VPN נשאלת כשאלת מוצר, אך בפועל מדובר בשאלת תפעול. כל אחד משלושת הסידורים הרגילים יחזיק מנהרה עובדת: CA ארגוני קיים, מנפיק עצמאי ייעודי, או AWS Private CA. הם נבדלים במי מאשר מכשיר, מי מחזיק במפתח החתימה, ומי עונה כאשר מחשב נייד נעלם בשעה לא נוחה. בחרו באפשרות שאת הבעלים שלה אתם יכולים לנקוב בשם.
AWS אינה דורשת Private CA לאימות באמצעות תעודות. הצבת תעודת שרת ב-ACM היא שלב פריסה, לא תהליך רישום.
שלושת התנאים שמכריעים
שלושה תנאים מפרידים בין האפשרויות בבירור: האם קיים כבר תהליך רישום מכשירים מאושר, האם אתם יכולים להפעיל מפתח חתימה עם גיבויים ובעלים נקוב, וכיצד ביטול מגיע לנקודת הקצה. כל אחד מהם קרוב לכן או ללא, והלא הראשון מכריע בדרך כלל את הארכיטקטורה.
עברו עליהם לפי הסדר. קפיצה ישירה להשוואת עלויות היא הדרך שבה צוותים נשארים עם CA מנוהל ואיש לא יודע מי ינפיק את תעודת המחשב הנייד הבאה.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
תנאי ראשון: האם הרישום כבר קיים?
אם הארגון שלכם כבר מפעיל CA עם מסלול רישום מכשירים מאושר, הנפקת תעודות לקוח של Client VPN ממנו היא הדרך הקצרה ביותר. האישורים, התהליך ורשומות הנכסים כבר נמצאים שם. מנפיק כפוף ייעודי תחת ההיררכיה הזו עדיף בדרך כלל על ה-CA המנפיק הכללי, משום שהוא נותן ל-VPN גבול אמון משלו ורשימת ביטולים משלו. החזיקו את הרשימה הזו בנפרד משאר ההיררכיה כדי שתקרית VPN לא תאלץ שינוי בכל ה-PKI.
אם תהליך כזה אינו קיים, השאלה האמיתית היא אם אתם רוצים לבנות אחד. CA קל להתחלה ויקר להחזיק בו רע.
תנאי שני: האם אתם יכולים להפעיל מפתח חתימה?
מנפיק עצמאי עובד עם מודל הייבוא המתועד, ו-EasyRSA או כלי פנימי קטן יכולים לייצר את החומר. הרצת הפקודה אינה החלק הקשה. החלק הקשה הוא גיבויים לא מקוונים של מפתח החתימה, מסלול שחזור שמישהו באמת בדק, בעלים שאינו בחופשה, וכלל שהמפתח לעולם לא יגיע לחבילת לקוח או לייצוא תצורה. כתבו זאת כנוהל לפני הנפקת התעודה הראשונה, ולא אחרי התקרית הראשונה.
AWS Private CA מעביר את המשמורת הזו לשירות מנוהל. הוא אינו מעביר את מדיניות הרישום, את שלב האישור או את מסירת התעודה למכשיר.
תנאי שלישי: כיצד מגיע הביטול?
Client VPN צורך רשימת ביטול תעודות לקוח שאתם מייבאים לנקודת הקצה, כמתואר במדריך מחזור החיים של התעודה. פרסום CRL במקום אחר ב-PKI שלכם אינו דוחף אותו לשירות. הייבוא הוא פעולה נפרדת ומתוזמנת, ורשימה שפגה עוצרת חיבורים במקום להידרדר בשקט. שימו את החידוש באותו לוח שנה כמו התעודות עצמן.
זה הופך את החידוש לפריט ניטור עם בעלים, לא למשימה שמסיימים בהשקה. בטלו תעודת בדיקה אחת מקצה לקצה לפני שאתם צריכים את המנגנון באמת.
מה שאף אחת מהאפשרויות אינה מסירה
כל אפשרות עדיין דורשת תעודת לקוח ומפתח נפרדים לכל מכשיר המנוהל באופן עצמאי. מדריך שמחלק זהות אחת לכולם הוא קיצור דרך של מדריך, והוא גם הופך ביטול סלקטיבי לבלתי אפשרי.
לתעודות שרת מיובאות ב-ACM אין חידוש מנוהל, ולכן הבעלים חייב להשיג את התחליף, לייבא אותו מחדש ואז לאשר שנקודת הקצה אימצה אותו. חידוש תעודת השרת אינו מחדש את פרטי הלקוח שכבר נמצאים במחשבים הניידים. אלה מחזורי חיים נפרדים עם לוחות שנה נפרדים.
בדקו את סוגי המפתחות וההרחבות שהשירות מקבל לפני שאתם מנפיקים משהו. העובדה ש-CA תומך באלגוריתם אינה אומרת שנקודת הקצה תקבל אותו.
לפני ההשקה, העבירו חידוש אחד והסרת לקוח אחד דרך זרימת העבודה שבחרתם, ורשמו איזה פריט מידע השתנה, איזו הגדרת נקודת קצה השתנתה ומה קרה למושב הפעיל. אם התרגיל הזה מסתיים בלי בעלים ברור, בחירת המנפיק לא הסתיימה.