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 นั้นเป็นเส้นทางที่สั้นที่สุด การอนุมัติ กระบวนการ และบันทึกสินทรัพย์มีอยู่แล้ว ผู้ออก subordinate ที่อุทิศให้ภายใต้ลำดับชั้นนั้นมักดีกว่า CA ผู้ออกทั่วไป เพราะให้ขอบเขตความเชื่อถือของ VPN เองและรายการเพิกถอนของตัวเอง แยกรายการนั้นออกจากส่วนที่เหลือของลำดับชั้น เพื่อให้เหตุการณ์ VPN ไม่บังคับให้ต้องเปลี่ยนแปลงทั้ง PKI
หากไม่มีกระบวนการดังกล่าว คำถามจริงคือคุณต้องการสร้างขึ้นมาหรือไม่ CA เริ่มต้นง่ายและมีค่าใช้จ่ายสูงหากดูแลไม่ดี
เงื่อนไขที่สอง: คุณดูแลกุญแจลงนามได้หรือไม่
ผู้ออกที่ดูแลเองทำงานกับรูปแบบการนำเข้าที่มีเอกสารกำกับ และ EasyRSA หรือเครื่องมือภายในขนาดเล็กสามารถสร้างวัสดุได้ การรันคำสั่งไม่ใช่ส่วนที่ยาก ส่วนที่ยากคือ การสำรองกุญแจลงนามแบบออฟไลน์ เส้นทางการกู้คืนที่ใครบางคนทดสอบจริง เจ้าของที่ไม่ได้ลาพักร้อน และกฎที่ว่ากุญแจจะไม่ไปอยู่ในบันเดิลไคลเอนต์หรือการส่งออกการกำหนดค่า เขียนสิ่งนี้เป็นขั้นตอนก่อนออกใบรับรองใบแรก ไม่ใช่หลังเหตุการณ์แรก
AWS Private CA ย้ายการเก็บรักษานั้นไปยังบริการที่มีการจัดการ แต่ไม่ได้ย้ายนโยบายการลงทะเบียน ขั้นตอนการอนุมัติ หรือการส่งมอบใบรับรองไปยังอุปกรณ์
เงื่อนไขที่สาม: การเพิกถอนมาถึงอย่างไร
Client VPN ใช้รายการเพิกถอนใบรับรองไคลเอนต์ที่คุณนำเข้าไปยังปลายทาง ตามที่อธิบายในคู่มือวงจรชีวิตใบรับรอง การเผยแพร่ CRL ที่อื่นใน PKI ของคุณไม่ได้ผลักดันเข้าไปในบริการ การนำเข้าเป็นการดำเนินการแยกและมีการกำหนดเวลา และรายการที่หมดอายุจะหยุดการเชื่อมต่อแทนที่จะเสื่อมลงอย่างเงียบ ๆ วางการต่ออายุไว้ในปฏิทินเดียวกับใบรับรองเอง
นั่นทำให้การต่ออายุเป็นรายการติดตามที่มีเจ้าของ ไม่ใช่งานที่เสร็จตอนเปิดตัว เพิกถอนใบรับรองทดสอบหนึ่งใบตั้งแต่ต้นจนจบก่อนที่คุณจะต้องใช้กลไกนี้จริง ๆ
สิ่งที่ไม่มีตัวเลือกใดกำจัดได้
ทุกตัวเลือกยังต้องมี ใบรับรองและกุญแจไคลเอนต์แยกกันสำหรับแต่ละอุปกรณ์ที่จัดการอย่างอิสระ บทแนะนำที่แจกอัตลักษณ์เดียวให้ทุกคนเป็นทางลัดของบทแนะนำ และยังทำให้การเพิกถอนแบบเลือกทำไม่ได้
ใบรับรองเซิร์ฟเวอร์ที่นำเข้าใน ACM ไม่มีการต่ออายุที่มีการจัดการ เจ้าของจึงต้องจัดหาตัวแทน นำเข้ากลับมา แล้วยืนยันว่าปลายทางรับไปแล้ว การต่ออายุใบรับรองเซิร์ฟเวอร์ไม่ได้ต่ออายุข้อมูลรับรองไคลเอนต์ที่อยู่ในแล็ปท็อปแล้ว สิ่งเหล่านี้เป็นวงจรชีวิตแยกกันพร้อมปฏิทินแยกกัน
ตรวจสอบชนิดกุญแจและส่วนขยายที่บริการยอมรับก่อนออกอะไรก็ตาม การที่ CA รองรับอัลกอริทึมไม่ได้หมายความว่าปลายทางจะยอมรับ
ก่อนเปิดตัว ให้รันการต่ออายุหนึ่งครั้งและการนำไคลเอนต์ออกหนึ่งครั้งผ่านลำดับงานที่คุณเลือก และบันทึกว่าข้อมูลรับรองใดเปลี่ยน การตั้งค่าปลายทางใดเปลี่ยน และเกิดอะไรกับเซสชันที่ใช้งานอยู่ หากแบบฝึกหัดนั้นจบลงโดยไม่มีเจ้าของชัดเจน การเลือกผู้ออกยังไม่เสร็จ