บริการ MFA ล่ม: ตัดสินใจการเข้าถึง VPN ก่อนจะล้มเหลว

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

ขั้นตอนที่ 1: ตั้งชื่อผลลัพธ์ทั้งสามแยกกัน

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

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

ขั้นตอนที่ 2: อ่านโหมดความล้มเหลวที่พร็อกซี่ใช้จริง

หาการตั้งค่าที่ควบคุมพฤติกรรมเมื่อติดต่อบริการไม่ได้ และอ่านจากการกำหนดค่าที่กำลังทำงานไม่ใช่จากเทมเพลต ในพร็อกซี่ RADIUS ของ Duo ค่า failmode ที่มีเอกสารระบุ คือ safe และ secure โดย safe อนุญาตให้ลองได้เฉพาะเมื่อการยืนยันตัวตนขั้นต้นสำเร็จ และ secure จะปฏิเสธความพยายามในเงื่อนไขนั้น

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

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

หยุดหากไม่มีใครบอกได้ว่าโหมดใดทำงานอยู่ ส่วนที่เหลือของคู่มือขึ้นอยู่กับคำตอบนั้น

ขั้นตอนที่ 3: ทำให้การลองใหม่สอดคล้องกับโฟลว์

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

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

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

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

ขั้นตอนที่ 4: กำกับการเข้าถึงฉุกเฉินแยกต่างหาก

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

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

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

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