FortiGate VPN MFA: โทเค็นภายใน, RADIUS หรือ SAML?

ทุกการออกแบบ FortiGate VPN MFA ต้องตอบคำถามข้อแรกก่อนว่า ใครเป็นผู้ตรวจสอบปัจจัยที่สอง เกตเวย์เองทำได้ด้วยโทเค็นภายในหรือรหัสที่ส่งทางอีเมล แบ็กเอนด์ RADIUS บังคับใช้และส่งคำท้าทายกลับมา หรือผู้ให้บริการตัวตน SAML รับผิดชอบพิธีทั้งหมดในเบราว์เซอร์ แต่ละแบบให้ลำดับการเข้าสู่ระบบที่ต่างกัน ลายเซ็นความล้มเหลวที่ต่างกัน และขั้นตอนกู้คืนที่ต่างกัน และการคัดลอกบล็อกคำสั่งข้ามกันจะได้การตั้งค่าที่ดูสมเหตุสมผลแต่ยืนยันตัวตนใครไม่ได้เลย บทความนี้ว่าด้วยกลไก การออกแบบแต่ละแบบทำอะไรจริงระหว่างการเข้าสู่ระบบ และพังตรงไหน

พิธีการเข้าสู่ระบบเป็นตัวกำหนดว่าใครถือปัจจัย

ในการออกแบบสองแบบแรก FortiGate เป็นฝ่ายที่เชื่อถือ มันรวบรวมข้อมูลรับรอง ตัดสินว่าต้องใช้ปัจจัยที่สองหรือไม่ และตรวจสอบภายในหรือโดยขอคำท้าทาย ในการออกแบบที่สาม เกตเวย์เลิกเป็นผู้ตรวจสอบและกลายเป็นตัวกลาง ส่งต่อไคลเอนต์ไปยังผู้ให้บริการตัวตน รับข้อกล่าวอ้าง และแมปตัวตนที่ยืนยันแล้วกับผู้ใช้และกลุ่ม ในการออกแบบ RADIUS มันอยู่ตรงกลางและขับเคลื่อนการแลกเปลี่ยนคำขอและคำตอบกับแบ็กเอนด์ที่ถือครองนโยบาย

ความต่างนี้กำหนดว่าเก็บหลักฐานอะไรได้บ้าง เมื่อเกตเวย์ตรวจสอบ เอาต์พุตดีบักของมันเองบอกว่าเกิดอะไรขึ้น เมื่อผู้ให้บริการตัวตนตรวจสอบ เกตเวย์รู้เพียงว่ามีข้อกล่าวอ้างมาถึง และคำตอบของคำถามที่ว่า «MFA ถูกเรียกใช้จริงหรือไม่» อยู่ในบันทึกของผู้ให้บริการ ไม่ใช่ในบันทึกของไฟร์วอลล์ การอ่านบันทึกผิดที่เป็นสาเหตุที่พบบ่อยที่สุดในการวินิจฉัยผิดพลาดของการติดตั้งที่ทำงานตรงตามที่ออกแบบไว้ ตัวบริการเองก็จำกัดพิธีเช่นกัน FortiOS 7.6.3 ตัดโหมดอุโมงค์ SSL VPN ออก เพื่อใช้ IPsec ขณะที่โหมดเว็บยังคงดำเนินต่อเป็น Agentless VPN บนรุ่นที่รองรับ ดังนั้นพิธีที่พิสูจน์แล้วบนบริการหนึ่งจึงไม่พร้อมใช้บนอีกบริการโดยอัตโนมัติ

การตรวจสอบภายใน: โทเค็นและรหัสทางอีเมล

ปัจจัยที่ FortiGate จัดการผูกกับออบเจ็กต์ผู้ใช้ FortiToken หรือการผสานโทเค็นที่มีเอกสารต้องมีการลงทะเบียน พิธีตรวจสอบที่รองรับ การอนุญาตใช้สิทธิ์ในที่ที่เกี่ยวข้อง และขั้นตอนการเปลี่ยนแทน รหัสทางอีเมลต้องมีเส้นทาง SMTP ที่ทำงานได้และกล่องจดหมายที่ผู้ใช้เข้าถึงได้ก่อนที่อุโมงค์จะมีอยู่ ซึ่งเป็นสิ่งที่พึ่งพาซึ่งไม่เกี่ยวข้องกับวิทยาการเข้ารหัสเลยและเกี่ยวข้องทั้งหมดกับว่าใครก็ตามจะเข้าสู่ระบบได้หรือไม่

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

การส่งอีเมลเป็นส่วนหนึ่งของความพร้อมใช้ของการยืนยันตัวตน กล่องจดหมายที่เข้าถึงได้เฉพาะผ่าน VPN สร้างวงวนที่ไม่คลี่คลายด้วยตัวเองให้กับใคร และความล่าช้าในการส่ง อายุของรหัส และเวลาหมดอายุของการยืนยันตัวตนระยะไกลเป็นข้อจำกัดแยกกันสามข้อ การเพิ่มข้อใดข้อหนึ่งไม่ซ่อมกล่องจดหมายที่เข้าถึงไม่ได้ และการออกแบบที่ไม่เคยทดสอบวงวนจะค้นพบมันในการรีเซ็ตรหัสผ่านครั้งแรกหลังวันหยุด

ข้อกำหนดด้านการรับประกันก็อยู่ตรงนี้ด้วย ก่อนการเลือกผลิตภัณฑ์ NIST SP 800-63B ถือว่าอีเมลเป็นสิ่งที่ยอมรับไม่ได้สำหรับการยืนยันตัวตนนอกช่องทาง ดังนั้นการติดตั้งที่อ้างความสอดคล้องจึงใช้อีเมลเป็นปัจจัยที่สองไม่ได้ ไม่ว่าจะสะดวกเพียงใด การมีคุณสมบัติอยู่ในอุปกรณ์ไม่ใช่ถ้อยแถลงว่าคุณสมบัตินั้นเป็นไปตามมาตรฐานที่กำหนด

RADIUS: เกตเวย์ถาม แบ็กเอนด์ตัดสิน

ด้วย RADIUS นั้น FortiGate ส่งข้อมูลรับรองไปยังแบ็กเอนด์ที่ถือครองนโยบายปัจจัย การแลกเปลี่ยนอาจเป็นการยอมรับหรือปฏิเสธอย่างง่าย หรืออาจมีคำท้าทายที่ไคลเอนต์ต้องตอบ ซึ่งหมายความว่าทั้งบริการ VPN และไคลเอนต์ต้องรองรับรูปแบบคำท้าทายนั้น แบ็กเอนด์ที่บังคับการอนุมัติแบบพุชและไคลเอนต์ที่รู้เพียงวิธีต่อรหัสหกหลักท้ายรหัสผ่านจะไม่พบกันตรงกลาง

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

ทดสอบแบ็กเอนด์แยกต่างหากก่อนโทษอุโมงค์ หากการทดสอบ authserver สำเร็จแต่การเข้าสู่ระบบ VPN ไม่สำเร็จ ความต่างอยู่ที่การจัดการคำท้าทายไม่ใช่ข้อมูลรับรอง และดีบักของดีมอนยืนยันตัวตนของเกตเวย์คือที่ที่เห็นสิ่งนั้น

diagnose debug application fnbamd -1
diagnose debug enable

SAML: เบราว์เซอร์ออกจากเกตเวย์

ในการออกแบบ SAML ไคลเอนต์ถูกส่งต่อไปยังผู้ให้บริการตัวตน ยืนยันตัวตนที่นั่น และกลับมาพร้อมข้อกล่าวอ้างที่เกตเวย์ตรวจสอบกับความสัมพันธ์ความไว้วางใจและการแมปกลุ่ม เกตเวย์ไม่เคยเห็นรหัสผ่านหรือปัจจัยที่สอง ซึ่งเป็นการปรับปรุงความปลอดภัยและความซับซ้อนในการปฏิบัติการในเวลาเดียวกัน ความล้มเหลวเกิดขึ้นแล้วในเซสชันเบราว์เซอร์ที่ไฟร์วอลล์ตรวจสอบไม่ได้

การยอมรับข้อกล่าวอ้างไม่ได้พิสูจน์ว่าผู้ให้บริการเรียกใช้ MFA สำหรับการเข้าสู่ระบบนั้น นโยบายของผู้ให้บริการที่ใช้ MFA กับบางแอปพลิเคชันและไม่ใช้กับอื่นจะให้การเข้าสู่ระบบตามที่ขอและไม่ให้การรับประกันที่สันนิษฐานไว้เลย ตรวจสอบนโยบายของผู้ให้บริการสำหรับแอปพลิเคชันนี้โดยเฉพาะ และตรวจสอบว่าการแมปข้อเรียกร้องกลุ่มกับกลุ่ม FortiGate ยังตรงกันหลังการเปลี่ยนชื่อใด ๆ ในฝ่ายใด

การรองรับไคลเอนต์สำคัญที่นี่มากกว่าที่อื่นใด ไคลเอนต์ VPN บางตัวจัดการการส่งต่อเบราว์เซอร์โดยธรรมชาติ บางตัวเปิดเบราว์เซอร์ของระบบ และไคลเอนต์แบบไม่มีหน้าจอหรือแบบบรรทัดคำสั่งอาจไม่สามารถทำขั้นตอนให้เสร็จได้เลยทดสอบกับไคลเอนต์ที่ผู้ใช้ใช้จริง บนแพลตฟอร์มที่พวกเขาใช้จริง ก่อนเผยแพร่โปรไฟล์

การกู้คืนเป็นส่วนหนึ่งของกลไก

ทุกการออกแบบข้างต้นมีสิ่งที่พึ่งพาซึ่งล้มเหลวได้ทีละผู้ใช้ กล่องจดหมายที่เข้าถึงไม่ได้ โทเค็นที่หายไป แบ็กเอนด์ที่ปฏิเสธคำท้าทาย บัญชีผู้ให้บริการตัวตนที่ถูกล็อก ตัดสินใจตอนนี้ว่าใครกู้คืนการเข้าถึงได้ ด้วยขั้นตอนที่รองรับใด และด้วยการตรวจสอบผู้ขออย่างไร บัญชีผู้ดูแลระบบภายในฉุกเฉินที่แยกจากเส้นทาง VPN คือมาตรการควบคุมและการข้ามผ่านด้วยรหัสผ่านอย่างเดียวโดยไม่อธิบายคือเหตุการณ์ที่รอการค้นพบ

จากนั้นทดสอบการเข้าสู่ระบบสามกรณีก่อนการติดตั้ง คือกรณีปกติ ปัจจัยที่ถูกปฏิเสธหรือหมดอายุ และการกู้คืนตัวยืนยันที่สูญหายซึ่งอนุมัติแล้ว บันทึกว่าแต่ละกรณีปรากฏในบันทึกใด บันทึกนั้นคือสิ่งที่เปลี่ยน «เปิดใช้ MFA แล้ว» ให้เป็นการออกแบบที่คนอื่นดูแลได้