2FA / MFA สำหรับ HIS: ยืนยันตัวตนอย่างไรให้ปลอดภัย และทีมรักษายังทำงานคล่อง

ถ้ามีคนได้รหัสผ่านของแพทย์ไป เขาจะเปิด HIS จากนอกโรงพยาบาลได้ทันทีหรือไม่?

คำถามนี้พาเราไปไกลกว่าหน้าจอ Login เพราะบัญชีเดียวอาจเชื่อมทั้งเวชระเบียน ผลตรวจ และงานหลายหน่วยงาน ขณะที่บุคลากรต้องสลับเครื่อง เปลี่ยนเวร และดูแลผู้ป่วยต่อเนื่องตลอดวัน

Two-factor authentication (2FA) และ Multi-factor authentication (MFA) ช่วยเพิ่มหลักฐานในการยืนยันตัวตน แต่สำหรับโรงพยาบาล การออกแบบต้องครอบคลุมทั้งความเสี่ยงของบัญชีและความพร้อมใช้งานของงานรักษา ตั้งแต่วันแรกที่ลงทะเบียนอุปกรณ์ ไปจนถึงคืนที่มือถือหายหรือระบบยืนยันตัวตนขัดข้อง

บทความนี้รวบรวมแนวทางจาก NHS England, HHS และ NIST แล้วนำมาประยุกต์เป็นคำถามและตัวอย่างสำหรับทีม IT โรงพยาบาล ตัวอย่างการทำงานในบทความเป็นสถานการณ์สมมติสำหรับการออกแบบระบบ

ทำไม MFA จึงเป็นประเด็นสำคัญของระบบสุขภาพ

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

ในภาคสุขภาพสหรัฐฯ HHS Healthcare and Public Health Cybersecurity Performance Goals จัด MFA ไว้ในกลุ่ม Essential Goals โดยให้เพิ่มการป้องกันแก่บัญชีและทรัพยากรที่เข้าถึงโดยตรงจากอินเทอร์เน็ต ในจุดที่ปลอดภัยและรองรับทางเทคนิค เป้าหมายชุดนี้เป็นแนวทางสมัครใจเพื่อช่วยจัดลำดับงานความปลอดภัยขององค์กรสุขภาพ

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

2FA กับ MFA ต่างกันอย่างไร และอะไรนับเป็นอีกปัจจัย

2FA ใช้สองปัจจัย ส่วน MFA ใช้ตั้งแต่สองปัจจัยขึ้นไป โดยปัจจัยต้องมาจากประเภทที่แตกต่างกัน แนวคิดพื้นฐานแบ่งเป็นสามกลุ่ม

• สิ่งที่รู้: เช่น รหัสผ่าน
• สิ่งที่มี: เช่น อุปกรณ์หรือแอปที่ถือกุญแจยืนยันตัวตน
• สิ่งที่เป็น: เช่น ลายนิ้วมือที่ใช้ร่วมกับอุปกรณ์ยืนยันตัวตน

ตัวอย่างที่เข้าใจง่ายคือ Password ร่วมกับรหัสจาก Authenticator ส่วนการให้กรอก Password แล้วตอบคำถามลับยังอาศัยความรู้เหมือนกัน การเพิ่มจำนวนช่องกรอกจึงไม่ได้เพิ่มชนิดของปัจจัยโดยอัตโนมัติ

อีกกรณีคือกุญแจยืนยันตัวตนที่ต้องปลดล็อกด้วย PIN หรือไบโอเมตริกในอุปกรณ์ การยืนยันหนึ่งครั้งอาจใช้หลายปัจจัยอยู่ภายในได้ ตาม NIST SP 800-63B-4 ระดับ AAL2 ไบโอเมตริกเพียงอย่างเดียวไม่ถือเป็น authenticator และต้องมีอุปกรณ์ยืนยันตัวตนร่วมด้วย

แนวทางสากลกำหนดอะไร และมีขอบเขตแค่ไหน

แหล่งอ้างอิง: NHS England · HHS · NIST AAL2

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

OTP, Push และ Passkey ให้การป้องกันต่างกันอย่างไร

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

NIST ระบุว่า OTP ที่ผู้ใช้กรอกเองไม่ต้านทาน phishing และจำกัดการใช้ SMS/เสียงผ่านเครือข่ายโทรศัพท์ ขณะที่ NHS แยกตัวเลือก strong MFA เช่น FIDO2 และ PKI ออกจากวิธีพื้นฐานอย่าง OTP และ Push — NIST: Authenticators และ NHS: Implementation options

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

เริ่มจาก Remote, Admin และ Vendor แล้วขยายตามความเสี่ยง

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

• Remote access: ตรวจทุกทางเข้าที่ใช้จริง รวมถึงทางเข้าตรงสู่แอป เพื่อไม่ให้ช่องทางหนึ่งบังคับ MFA แต่อีกช่องทางยังใช้เพียงรหัสผ่าน
• บัญชีผู้ดูแล: แยกจากบัญชีงานประจำ จำกัดสิทธิ์ตามหน้าที่ และติดตามการใช้สิทธิ์สำคัญ
• Vendor: ใช้บัญชีที่ระบุบุคคลได้ เปิดสิทธิ์ตามช่วงงานที่อนุมัติ และบันทึกกิจกรรม
• ระบบเชื่อมต่อ: แยก service account ออกจากผู้ใช้บุคคล ใช้ตัวตนของระบบและกุญแจที่จัดการวงจรชีวิตได้ แทนการออกแบบให้คนคอยกรอก OTP ให้โปรแกรม

ลำดับข้างต้นเป็นข้อเสนอในการนำไปใช้ ไม่ใช่ข้อกำหนดตายตัวของทุกโรงพยาบาล ส่วนแนวคิดบัญชีรายบุคคล การแยกบัญชีผู้ดูแล และการถอนสิทธิ์เมื่อพ้นหน้าที่เป็นหัวข้อที่ HHS CPGs ให้ความสำคัญร่วมกับ MFA — HHS Essential Goals

เครื่องประจำวอร์ดและการเปลี่ยนเวร ต้องออกแบบ Session ด้วย

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

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

SSO ช่วยลดการ Login ซ้ำหลายระบบได้ แต่ควรตรวจขอบเขต Session ของแต่ละแอปด้วย ตาม NIST: Session Management Session ของระบบบัญชีกลางและแอปที่พึ่งพากันอาจมีอายุและการยุติแยกกัน การออกจากระบบหนึ่งจึงไม่ควรถูกตีความว่าทุกระบบออกตามโดยไม่ทดสอบ

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

มือถือหายและการกู้คืนบัญชี เป็นส่วนหนึ่งของระบบความปลอดภัย

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

แนวทาง NIST: Authenticator Event Management ครอบคลุมการผูกอุปกรณ์ การสูญหาย การเพิกถอน และการกู้คืน อีกทั้งส่งเสริมให้มีวิธียืนยันตัวตนสำรองมากกว่าหนึ่งทาง เพื่อลดการพึ่งกระบวนการกู้คืนเมื่ออุปกรณ์หลักใช้ไม่ได้

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

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

เมื่อระบบ MFA ล่ม โรงพยาบาลต้องทำงานต่ออย่างไร

ความขัดข้องอาจเกิดที่ระบบบัญชีกลาง เครือข่าย อุปกรณ์อ่านบัตร หรือช่องทางรับรหัส ทีม IT จึงควรวางแผนร่วมกับทีมรักษาว่าจะให้บริการต่อได้อย่างไรในแต่ละกรณี และทดสอบก่อนใช้งานจริง

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

NHS อนุญาตข้อยกเว้นเฉพาะบางกรณี รวมถึงกรณีที่ MFA ก่อความเสี่ยงหรือความยากลำบากด้านคลินิกหรือการปฏิบัติงานอย่างไม่สมส่วน โดยต้องบันทึก ประเมิน อนุมัติ ทบทวน และมีมาตรการชดเชย พร้อมแผนลดข้อยกเว้น — NHS: Exceptions

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

เชื่อม MFA กับ Audit Log ให้เห็นทั้งการเข้าใช้และการเปลี่ยนสิทธิ์

เหตุการณ์ที่ควรติดตามไม่ได้มีแค่ Login สำเร็จหรือไม่สำเร็จ แต่ยังรวมการเพิ่มอุปกรณ์ การ Reset MFA การเปลี่ยนนโยบาย การใช้สิทธิ์ฉุกเฉิน และการเพิกถอน Session

ตัวอย่างชุดข้อมูลสำหรับทีม IT คือ ผู้ใช้ เวลา แอปที่เข้าใช้ วิธีและผลการยืนยันตัวตน รหัสอ้างอิงเหตุการณ์ และเหตุผลการใช้ช่องทางพิเศษ โดยกำหนดการเข้าถึงและระยะเวลาเก็บตามความจำเป็น หลีกเลี่ยงการบันทึก OTP, recovery code, กุญแจลับ หรือ Session token ที่นำไปใช้ต่อได้

หลักฐานการยืนยันตัวตนควรเชื่อมกับธุรกรรมใน HIS ได้ แต่ความสำเร็จของ MFA ยังไม่พิสูจน์ว่าบุคคลทำทุกกิจกรรมด้วยตนเองเสมอไป ต้องพิจารณาการแชร์บัญชี Session ที่เปิดทิ้งไว้ และบริบทอื่นร่วมกัน อ่านต่อเรื่อง Audit Log ของ HIS: ออกแบบให้ตอบได้ว่าใครเปลี่ยนอะไรและเพราะอะไร

สามสถานการณ์สำหรับใช้ทดสอบก่อนเปิดใช้งานจริง

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

Checklist สำหรับทีม IT และการประเมินระบบ HIS

• สำรวจบัญชี ผู้ใช้ ระบบ และช่องทางเข้าถึงครบแล้วหรือยัง รวม Remote, Vendor และบัญชีสิทธิ์สูง
• ระบุได้หรือไม่ว่าวิธีที่เลือกเป็น MFA แบบใด และต้านทาน phishing ได้หรือไม่
• รองรับการเชื่อมระบบบัญชีกลาง และปิดทางเข้าที่ข้ามนโยบายได้หรือไม่
• ทดสอบเครื่องใช้ร่วมกัน การเปลี่ยนเวร และขอบเขต Logout/Session ของแต่ละแอปแล้วหรือยัง
• มีอุปกรณ์ทางเลือกสำหรับคนที่ใช้มือถือส่วนตัวไม่ได้หรือไม่
• การลงทะเบียนอุปกรณ์ใหม่และ Recovery มีหลักฐานยืนยันตัวตนและผู้รับผิดชอบหรือไม่
• เพิกถอนอุปกรณ์ บัญชี และ Session เมื่อพ้นหน้าที่หรือเกิดเหตุได้หรือไม่
• แผนฉุกเฉินมีขอบเขตสิทธิ์ การบันทึก และการทบทวนที่ทดสอบแล้วหรือยัง
• ตรวจสอบเหตุการณ์ MFA ร่วมกับ Audit Log ของ HIS ได้หรือไม่

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

แหล่งอ้างอิงและขอบเขตบทความ

• NHS England: Multi-factor authentication policy
• HHS: Healthcare and Public Health Cybersecurity Performance Goals
• NIST SP 800-63B-4: Authentication Assurance Levels
• NIST SP 800-63B-4: Authenticator and Verifier Requirements
• NIST SP 800-63B-4: Authenticator Event Management
• NIST SP 800-63B-4: Session Management

ตรวจสอบแหล่งอ้างอิงวันที่ 16 ตุลาคม 2026 บทความนี้อธิบายแนวทางและตัวอย่างการออกแบบทั่วไป การกำหนดนโยบายของแต่ละโรงพยาบาลต้องพิจารณาขอบเขตข้อกำหนด ความเสี่ยง และการใช้งานจริงร่วมกัน