การยืนยันตัวตนของ AWS Client VPN: สิทธิ์ IAM ไม่ใช่วิธีเข้าสู่ระบบ
สิทธิ์ในคอนโซลไม่ได้ยืนยันอุโมงค์ เปรียบเทียบวิธีใบรับรอง AD และ SAML แล้วดูว่าเมื่อใดการส่งต่อพอร์ตผ่าน SSM เหมาะกับฐานข้อมูลส่วนตัวหนึ่งฐาน
การให้ผู้ใช้มีสิทธิ์สร้างหรืออธิบายปลายทาง AWS Client VPN ไม่ได้ทำให้ผู้ใช้รายนั้นเชื่อมต่อกับปลายทางได้ ทั้งสองเป็นตัวตนคนละประเภท: IAM ควบคุมการเรียก AWS API และปลายทางยอมรับเฉพาะวิธีตรวจสอบสิทธิ์ไคลเอนต์ที่กำหนดไว้บนปลายทางเท่านั้น ผู้ใช้จึงอาจมีสิทธิ์กว้างในคอนโซลแต่ไม่มีอะไรที่ไคลเอนต์ VPN จะนำเสนอได้ ตัดสินใจว่าปลายทางเชื่อถือวิธีใด แล้วตัดสินใจว่าอุโมงค์เต็มรูปแบบเป็นรูปแบบที่ถูกต้องสำหรับการเข้าถึงที่คุณให้หรือไม่
ตัวตนของ API ไม่ใช่ตัวตนของอุโมงค์
เมื่อมีคนพูดว่า «บทบาท IAM ถูกแนบแล้ว ทำไม VPN ยังล้มเหลว» คำตอบมักคือไม่มีขั้นตอนใดในลำดับการเชื่อมต่อที่อ่านบทบาทนั้นเลย ไคลเอนต์นำเสนอใบรับรอง ชื่อผู้ใช้และรหัสผ่าน AD หรือข้อความยืนยัน SAML ปลายทางตรวจสอบหนึ่งในนั้นแล้วจึงกำหนดที่อยู่
IAM ยังสำคัญอยู่ เพียงแต่ช้ากว่าและที่อื่น: การสร้างปลายทาง การเชื่อมโยงซับเน็ต การเผยแพร่เส้นทาง และการเขียนกฎการอนุญาตเป็นการกระทำผ่าน API จำกัดสิทธิ์เหล่านั้นไว้กับผู้ปฏิบัติงานที่ต้องการ แทนที่จะให้ผู้ใช้ทุกคนสามารถเขียนกฎการเข้าถึงของปลายทางใหม่
เลือกจากวิธีที่ปลายทางรองรับ
AWS Client VPN ยอมรับการยืนยันตัวตนแบบสองทางด้วยใบรับรอง การยืนยันตัวตนผ่าน Active Directory และการยืนยันตัวตนแบบสหพันธ์บนพื้นฐาน SAML ต้องมีใบรับรองเซิร์ฟเวอร์ไม่ว่าจะเลือกวิธีไคลเอนต์ใด และการกำหนดค่าที่รวมหลายวิธีต้องให้ทั้งสองวิธีสำเร็จ ไม่ใช่เพียงวิธีเดียว
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
ใบรับรองติดตั้งถูกที่สุดและผิดพลาดได้ง่ายที่สุดในระดับใหญ่ เพราะผู้ใช้ทุกคนต้องมีข้อมูลรับรองและทุกการจากไปต้องมีการเพิกถอน การยืนยันตัวตนผ่านไดเรกทอรีจะย้ายวงจรชีวิตนั้นไปยังระบบที่มีอยู่แล้ว การสหพันธ์ย้ายไปยังผู้ให้บริการระบุตัวตนและเพิ่มขั้นตอนเบราว์เซอร์ให้ไคลเอนต์
อ่านการกำหนดค่าของปลายทางเองก่อนแก้ไขปัญหาไคลเอนต์ หากเปิดใช้การยืนยันตัวตนแบบสองทางควบคู่กับวิธีที่อิงผู้ใช้ ไคลเอนต์ที่มีใบรับรองถูกต้องแต่ไม่มีบัญชีไดเรกทอรียังคงล้มเหลว และข้อผิดพลาดมักดูเหมือนปัญหาการจับมือทั่วไป
การสหพันธ์ไม่ใช่การส่งต่อคีย์การเข้าถึง
การตั้งค่า SAML ไม่ได้ป้อนคีย์การเข้าถึง IAM หรือโทเค็นของบทบาทที่สวมสิทธิ์ลงในอุโมงค์ ผู้ให้บริการระบุตัวตนยืนยันตัวบุคคล ส่งข้อความยืนยันกลับมา และปลายทางยอมรับภายใต้ความเชื่อถือที่คุณกำหนดไว้ เซสชันที่ได้จึงเป็นเซสชัน VPN ไม่ใช่เซสชัน AWS API
ความแตกต่างนี้กำหนดว่าใครวินิจฉัยอะไรได้ ปัญหา IdP ปรากฏเป็นข้อผิดพลาดของเบราว์เซอร์หรือไคลเอนต์ก่อนที่อุโมงค์จะเกิดขึ้น ขณะที่ปัญหาอุโมงค์ปรากฏหลังข้อความยืนยันสำเร็จ ถามตัวเองว่ากำลังดูอยู่ระหว่างสองอย่างนี้ก่อนเปิดคอนโซลใด ๆ
หลังเข้าสู่ระบบ เส้นทางและการอนุญาตยังคงเป็นตัวตัดสิน
การยืนยันตัวตนให้ที่อยู่กับเซสชัน แต่ไม่ได้ให้ปลายทางกับเซสชัน เส้นทางของปลายทางบอกไคลเอนต์ว่าส่งไปยังซับเน็ตใด กฎการอนุญาตกำหนดว่าผู้ใช้ใดเข้าถึงซับเน็ตใดได้ และกลุ่มความปลอดภัยกับสิทธิ์ของเป้าหมายเองเป็นตัวกำหนดส่วนที่เหลือ
นี่คือเหตุผลที่ผู้ใช้ที่ยืนยันตัวตนสำเร็จอาจยังเข้าถึงฐานข้อมูลไม่ได้ ตรวจสอบการเชื่อมโยงตารางเส้นทางของซับเน็ต กฎการอนุญาตของกลุ่มผู้ใช้ และกลุ่มความปลอดภัยบนเป้าหมายตามลำดับนั้น เพราะแต่ละอย่างสร้างการหมดเวลาแบบต่างกัน
สำหรับฐานข้อมูลส่วนตัวหนึ่งฐาน เปรียบเทียบกับการส่งต่อพอร์ต
หากงานจริงคือการเชื่อมต่อที่ได้รับอนุมัติหนึ่งรายการไปยังฐานข้อมูลส่วนตัวหนึ่งฐาน อุโมงค์เครือข่ายเต็มรูปแบบเป็นทางเลือกไม่ใช่ข้อบังคับ AWS Systems Manager Session Manager เปิดเซสชันส่งต่อพอร์ตไปยังโหนดที่จัดการผ่าน IAM ได้ และโหนดนั้นเข้าถึงฐานข้อมูลในเครือข่ายส่วนตัว ผู้ใช้ไม่เคยได้รับที่อยู่ VPC โหนดที่จัดการกลายเป็นโฮสต์เดียวที่เข้าถึงพอร์ตฐานข้อมูลได้ ซึ่งมักเป็นสิ่งที่การตรวจสอบความปลอดภัยต้องการ จากนั้นผู้ใช้ต้องมีไคลเอนต์ภายในเครื่องและคำสั่งเซสชันแทนโปรไฟล์ VPN
การแลกเปลี่ยนคือขอบเขตกับข้อกำหนดเบื้องต้น การส่งต่อพอร์ตต้องมีเอเจนต์ SSM บนโหนดที่จัดการ การเข้าถึงเครือข่ายจากโหนดนั้นไปยังฐานข้อมูล ปลั๊กอิน Session Manager บนเครื่องของผู้ใช้ และสิทธิ์ในการเริ่มเซสชันนั้นโดยเฉพาะ ไม่ใช่เส้นทางเข้าทุกซับเน็ต และจะไม่บรรทุกโปรโตคอลใด ๆ แบบที่อุโมงค์ทำ
ไม่ว่ากรณีใด จงรักษาตัวตนของฐานข้อมูลเองไว้ ตรวจสอบ TLS และการยืนยันตัวตนของฐานข้อมูลไม่หายไปเพราะเส้นทางได้รับอนุญาตจาก IAM และเซสชันที่ได้รับอนุมัติไม่ได้บอกอะไรเกี่ยวกับตารางที่ผู้ใช้อ่านได้
เลือกตามขอบเขตและวงจรชีวิต: อุโมงค์เมื่อผู้ใช้จำนวนมากต้องการปลายทางจำนวนมากและคุณดูแลวงจรชีวิตใบรับรองหรือไดเรกทอรีได้ เซสชันส่งต่อเมื่อคนจำนวนน้อยต้องการบริการเดียวและคุณไม่อยากแจกที่อยู่เครือข่าย ไม่ว่ากรณีใด บันทึกวิธีการยืนยันตัวตน กฎการอนุญาต และการเข้าสู่ระบบฐานข้อมูลเป็นข้อเท็จจริงแยกกันสามข้อ เพราะมันล้มเหลวแยกกัน