การลงทะเบียน Passkey คือช่องโหว่ใหม่ขององค์กรคุณ: บทเรียนจาก Pass-the-Passkey สำหรับผู้ดูแล IdP

จุดขายของ Passkey นั้นเรียบง่ายและเป็นความจริง: ไม่มีอะไรให้ Phish ไม่มีสตริงรหัสผ่านที่ผู้ใช้จะถูกหลอกให้พิมพ์ลงในโดเมนปลอม สำหรับองค์กรไทยที่เสียบัญชีให้กับการโจมตีแบบ Credential Phishing มาตลอดสิบปี เหตุผลนี้เพียงพอแล้วที่จะย้ายระบบ

จากนั้นในต้นเดือนสิงหาคม 2026 ทีมวิจัยอิสระสองทีมเผยแพร่ผลงานห่างกันไม่ถึง 48 ชั่วโมง และเปลี่ยนความหมายของประโยคนั้นในทางปฏิบัติ ทั้งสองทีมไม่ได้เจาะระบบเข้ารหัสของ Passkey แต่เลี่ยงมันไป — และทั้งคู่ลงเอยที่จุดเดียวกัน คือ ช่วงเวลาที่ Credential ถูกลงทะเบียน

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

เกิดอะไรขึ้นในเดือนสิงหาคม

Unit 42 วันที่ 3 สิงหาคม นักวิจัย Arie Olshtein เผยแพร่สายการโจมตีสามรูปแบบต่อ Passkey แบบ Sync ของ Google Password Manager ผ่าน Cloud Authenticator ที่ Chrome ใช้บน Windows ทั้งสามรูปแบบตั้งสมมติฐานว่ามีมัลแวร์ทำงานอยู่บนเครื่องแล้วด้วยสิทธิ์ผู้ใช้ทั่วไป — ไม่ต้องมีสิทธิ์ Administrator และไม่มีหน้าต่างแจ้งเตือนใด ๆ ปรากฏบนหน้าจอเหยื่อ

รูปแบบแรกปลอมตัวเป็นอุปกรณ์ที่เชื่อถือได้ต่อ Cloud Authenticator ของ Google และได้ Assertion ที่ถูกต้องมาโดยตรง โดยไม่ต้องแตะเซนเซอร์ลายนิ้วมือหรือกรอก PIN รูปแบบที่สองใช้ประโยชน์จากกระบวนการ Re-enrollment ของอุปกรณ์ โดยมัลแวร์จะทำให้ Verification Key เดิมใช้ไม่ได้หรือลบไฟล์สถานะ Credential ในเครื่อง บังคับให้ Chrome ลงทะเบียนใหม่ แล้วลงทะเบียน Verification Key ของตัวมันเอง เข้าไปในกระบวนการนั้น หลังจากนั้นผู้โจมตีสามารถล็อกอินจากเครื่องของตัวเองได้เลย โดยไม่ต้องแตะเครื่องเหยื่ออีก รูปแบบที่สามซึ่งร้ายแรงที่สุด ดึง Security Domain Secret ขนาด 32 ไบต์ที่ปรากฏชั่วครู่ในหน่วยความจำของ Chrome ระหว่างการลงทะเบียนใหม่ ค่านั้นค่าเดียวถอดรหัส Private Key ของ Passkey ทุกตัวในบัญชี รวมถึงตัวที่สร้างขึ้นภายหลังด้วย และปัจจุบันยังไม่มีกลไกหมุนเวียนหรือเพิกถอนค่านั้นเมื่อมันรั่วไหล

ไม่มีการออก CVE สำหรับสายการโจมตีเหล่านี้ Google ได้ออกมาตรการบรรเทาบางส่วนแล้ว

SpecterOps วันที่ 5 สิงหาคม งาน Black Hat USA Michael Grafnetter นำเสนอกลุ่มการโจมตีที่ตั้งชื่อล้อกับ Pass-the-Hash โดยตั้งใจ สายที่ร้ายแรงที่สุดผสมจุดอ่อนสองอย่างเข้าด้วยกัน: Windows 11 เขียน WebAuthn Assertion Response ฉบับสมบูรณ์ลงใน Event Log ที่ผู้ใช้ที่ผ่านการยืนยันตัวตนแต่ไม่มีสิทธิ์พิเศษสามารถอ่านได้ — และในบางการตั้งค่า อ่านได้จากระยะไกลด้วย — ขณะที่ Microsoft Entra ID ตรวจสอบ Response เหล่านั้นไม่เข้มงวดพอที่จะปฏิเสธการ Replay รวมกันแล้วทำให้ผู้โจมตีสวมรอยเป็น Cloud Identity ระดับสิทธิ์สูงได้ ทั้งที่ยังผ่านเงื่อนไข MFA แบบ Phishing-Resistant งานวิจัยเดียวกันยังพบลายเซ็นเก่าของ Hardware Token ถูกเก็บเป็น Cleartext ในที่ที่บัญชีทั่วไปอ่านได้

Microsoft แก้ไขฝั่ง Windows Logging ในชื่อ CVE-2026-34348 ในชุดอัปเดตวันที่ 14 กรกฎาคม 2026 โดยตัดส่วนลายเซ็นที่บันทึกลง Log ให้เหลือ 6 ไบต์ — พอสำหรับการแก้ปัญหา แต่ไม่พอสำหรับการ Replay ทาง SpecterOps ถือว่าสายการโจมตี Windows-to-Entra ถูกตัดขาดแล้วบนระบบที่แพตช์แล้ว

ประเด็นเชิงโครงสร้าง: ความเสี่ยงย้ายไปที่การลงทะเบียน

ในยุครหัสผ่าน ความลับ คือ ตัวทรัพย์สิน ขโมยมันมา แล้ว Replay ทุกกลไกป้องกันที่เราสร้างขึ้น — การเปลี่ยนรหัสตามรอบ กฎความซับซ้อน MFA การตรวจจับ Impossible Travel — ตั้งอยู่บนสมมติฐานว่าเป้าหมายของผู้โจมตีคือการได้มาซึ่งสิ่งที่ผู้ใช้มีอยู่แล้ว

ในยุค Passkey เป้าหมายนั้นใช้ไม่ได้ผลอีกต่อไป Private Key แบบ Device-Bound ไม่ออกจาก Authenticator และการ Phish Passkey นั้นทำไม่ได้ คำถามของผู้โจมตีจึงเปลี่ยนจาก ฉันจะขโมย Credential ของเขาได้อย่างไร เป็น ฉันจะทำให้ระบบออก Credential ให้ฉันได้อย่างไร

สายการโจมตี Silver Pass-ta-key คือภาพประกอบที่ชัดที่สุด ผู้โจมตีไม่เคยได้ Key ของผู้ใช้เลย เขาแค่เพิ่ม Key ของตัวเองเข้าไป ผ่านกระบวนการที่ระบบมีไว้เพื่อการนั้นโดยเฉพาะ นั่นไม่ใช่การขโมย Credential แต่คือการ ออก Credential — และมันคงทนในแบบที่รหัสผ่านที่ถูกขโมยไม่เคยเป็น เพราะมันรอดพ้นทั้งการเปลี่ยนรหัสผ่านและการยกเลิก Session ที่ปกติใช้ปิดเหตุการณ์

มีเพียงสองจังหวะที่ Identity Provider จะยอมรับ Authenticator ตัวใหม่: การลงทะเบียนครั้งแรก และการกู้คืนหรือลงทะเบียนใหม่ ในการติดตั้งส่วนใหญ่ สองจังหวะนี้คือสองปฏิบัติการที่ถูกเฝ้าระวังน้อยที่สุดและมี Policy ควบคุมน้อยที่สุดในระบบตัวตนทั้งหมด

flowchart TD
    A["การลงทะเบียน Credential"] --> B["การยืนยันตัวตนประจำวัน"]
    B --> C["การกู้คืนหรือลงทะเบียนใหม่"]
    C --> A
    A --> D["ผู้โจมตีลงทะเบียน Authenticator ของตัวเอง"]
    C --> D
    B --> E["Assertion ถูกดักจาก Log แล้วนำมา Replay"]
    C --> F["Master Secret ถูกดึงระหว่างการลงทะเบียนใหม่"]
    D --> G["การเข้าถึงถาวรที่รอดพ้นการรีเซ็ตรหัสผ่าน"]
    E --> G
    F --> G

ข้อสรุปที่ตามมานั้นไม่สบายใจนักแต่ชัดเจน: ความแข็งแกร่งของระบบ Passwordless ของคุณเท่ากับเส้นทางการลงทะเบียนที่อ่อนแอที่สุดพอดี ถ้าเจ้าหน้าที่ Helpdesk สามารถผูก Authenticator ตัวใหม่เข้ากับบัญชีผู้อำนวยการฝ่ายการเงินได้จากการรับโทรศัพท์สายเดียว คุณก็แค่มีกระบวนการรีเซ็ตรหัสผ่านที่สวมชุด Passkey อยู่

มุมกฎหมายไทยที่ต้องพิจารณาควบคู่

สองเรื่องนี้เปลี่ยนน้ำหนักของประเด็นข้างต้นสำหรับองค์กรในไทย

PDPA และการแจ้งเหตุภายใน 72 ชั่วโมง เมื่อผู้โจมตีเข้าถึงระบบผ่าน Credential ที่ ลงทะเบียนอย่างถูกต้อง ในนามพนักงาน คำถามแรกของทีมสอบสวนคือ "เข้าถึงข้อมูลส่วนบุคคลใดบ้าง และตั้งแต่เมื่อไร" หากคุณไม่มีบันทึกว่า Authenticator แต่ละตัวถูกลงทะเบียนเมื่อใดและจากที่ใด คุณจะตอบคำถามนั้นไม่ได้ภายในกรอบเวลาแจ้งเหตุ 72 ชั่วโมง Credential Inventory จึงไม่ใช่แค่เรื่องความปลอดภัย แต่เป็นเอกสารหลักฐานที่ต้องมีอยู่ก่อนเกิดเหตุ

พ.ร.บ. การรักษาความมั่นคงปลอดภัยไซเบอร์ มาตรา 59 สำหรับหน่วยงานที่เข้าข่ายโครงสร้างพื้นฐานสำคัญทางสารสนเทศ ข้อกำหนดเรื่องการควบคุมการเข้าถึงและการเก็บ Log ครอบคลุมถึงการเปลี่ยนแปลงสิทธิ์ ไม่ใช่แค่การล็อกอิน เหตุการณ์ "เพิ่ม Authenticator ให้บัญชีสิทธิ์สูง" ควรอยู่ในชุด Log ที่เก็บและเฝ้าระวัง ไม่ใช่เหตุการณ์ที่มีอยู่ในระบบแต่ไม่มีใครดู

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

หกสิ่งที่ต้องตั้งค่าบน Identity Provider

1. ปฏิบัติต่อการลงทะเบียนเสมือนปฏิบัติการที่ต้องใช้สิทธิ์พิเศษ

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

กำหนดเงื่อนไขการลงทะเบียนไว้หลังสิ่งที่ Cookie อย่างเดียวผ่านไม่ได้ — อุปกรณ์ที่อยู่ในการจัดการและผ่านเกณฑ์ Compliance, การยืนยันตัวตนเพิ่มระดับที่ทำใหม่ภายในไม่กี่นาทีที่ผ่านมา, ช่วง Network ที่รู้จัก หรือหน้าต่างเวลาที่ผู้ดูแลเปิดให้เป็นการเฉพาะ ใน Entra ID คือการใช้ Authentication Methods Policy ร่วมกับกฎ Conditional Access ที่เจาะจง User Action สำหรับการลงทะเบียนข้อมูลความปลอดภัย ใน Authentik คือการสร้าง Enrollment Flow แยกต่างหากที่มี Stage และ Policy ของตัวเอง แทนที่จะปล่อยให้ Login Flow ปกติผูกอุปกรณ์ใหม่เป็นผลพลอยได้

หลักที่ควรยึด: Credential ที่ใช้อนุมัติการเพิ่ม Credential ตัวใหม่ ควรแข็งแรงอย่างน้อยเท่ากับตัวที่กำลังจะเพิ่ม

2. เลิกถือว่า Flag "ยืนยันผู้ใช้แล้ว" เป็นหลักฐานว่ามีคนอยู่ตรงนั้น

Relying Party จำนวนมากยอมรับบิต User-Verified ใน Assertion เป็นหลักฐานว่ามีคนแตะเซนเซอร์หรือกรอก PIN ข้อค้นพบของ Unit 42 คือ Authenticator ที่ถูกยึดสามารถตั้งบิตนั้นได้โดยไม่มีใครแตะอะไรเลย

ในระบบที่คุณเป็นเจ้าของ Relying Party เอง ให้ตรวจสอบ Assertion ทั้งชุดแทนการอ่านค่า Boolean ตัวเดียว: Origin, ความสดของ Challenge, พฤติกรรมของ Signature Counter และรหัสรุ่นของ Authenticator เทียบกับ Allowlist ในระบบที่คุณไม่ได้เป็นเจ้าของ — ซึ่งก็คือ SaaS ส่วนใหญ่ — มาตรการชดเชยต้องอยู่ที่ Identity Provider โดยจำกัดว่ารุ่นใดของ Authenticator ที่ได้รับอนุญาตให้ลงทะเบียนตั้งแต่แรก

3. ตัดสินใจเรื่อง Synced กับ Device-Bound แยกตามระดับความสำคัญ ไม่ใช่ตั้งค่าเดียวทั้งองค์กร

Passkey แบบ Sync คือเหตุผลที่การใช้งาน Passkey แพร่หลายได้จริง เพราะเรื่องราวการกู้คืนคือสิ่งที่ทำให้คนทั่วไปใช้งานได้ แต่มันก็มีรัศมีความเสียหายเท่ากับบัญชี Cloud ทั้งบัญชี และ Golden Pass-ta-key แสดงให้เห็นว่า Master Secret เบื้องหลังการ Sync นั้นยังไม่มีกลไกเพิกถอนในวันนี้

การแบ่งที่ป้องกันตัวได้: Credential แบบ Sync ใช้ได้กับแอปพลิเคชันภายในกลุ่มทั่วไป ส่วน Hardware Authenticator แบบ Device-Bound ที่ต้องผ่าน Attestation ตอนลงทะเบียน ให้ใช้กับบทบาทผู้ดูแลระบบ ระบบการเงิน และทุกอย่างที่สามารถโอนเงินหรือแก้ไขการตั้งค่าตัวตนได้ บังคับด้วย Attestation และ Allowlist ระดับรุ่นในขั้นตอนลงทะเบียนจริง เพราะเอกสารนโยบายหยุดคำขอลงทะเบียนไม่ได้

4. เส้นทางการกู้คืนคือระดับความปลอดภัยจริงของคุณ

ทุกระบบ Passwordless ต้องมีทางสำรอง เพราะคนทำโทรศัพท์หาย ไม่ว่าจะเป็น OTP ทาง SMS, Magic Link ทางอีเมล, การรีเซ็ตโดย Helpdesk หรือ Temporary Access Pass

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

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

5. สร้าง Credential Inventory แล้วแจ้งเตือนเมื่อมีการเปลี่ยนแปลง

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

สร้างรายงานนั้นก่อน จากนั้นแจ้งเตือนรูปแบบที่สำคัญ — การลงทะเบียนจากประเทศใหม่, Credential ตัวที่สองที่เพิ่มเข้ามาไม่กี่นาทีหลังตัวแรก, การลงทะเบียนนอกเวลาทำการ และการเปลี่ยนแปลง Credential ใด ๆ บนบัญชีที่ถือบทบาทสิทธิ์สูง สิ่งเหล่านี้ควรเรียกคนขึ้นมาดู ไม่ใช่นอนอยู่ใน Audit Log ที่จะถูกอ่านหลังเกิดเหตุแล้ว

การปิดบัญชีพนักงานลาออกก็สำคัญเช่นกัน เหตุการณ์ SCIM Deprovisioning ต้องยกเลิกทั้ง Session และ ถอน Credential ที่ลงทะเบียนไว้ บัญชีที่ถูกปิดแต่ยังมี Authenticator ผูกอยู่คือการเปิดใช้งานใหม่ที่รอเกิดขึ้น — และนั่นคือช่องว่างประเภทที่ ระบบตัวตนแบบรวมศูนย์มีไว้เพื่อปิด

6. ยืนยันว่าแพตช์เดือนกรกฎาคมลงจริง

CVE-2026-34348 ออกเมื่อวันที่ 14 กรกฎาคม 2026 สายการ Replay จาก Windows ไป Entra ขึ้นอยู่กับการที่แพตช์นี้ยังไม่ถูกติดตั้ง ตรวจสอบการติดตั้งทั่วทั้งองค์กร และให้ความสนใจเป็นพิเศษกับเครื่องของผู้ดูแลระบบและ Jump Host ซึ่งเป็นทั้งเป้าหมายมูลค่าสูงสุด และในหลายองค์กรก็เป็นเครื่องที่มักถูกยกเว้นจากรอบแพตช์มาตรฐาน

หน้าตาของ Flow ที่แข็งแรงแล้ว

flowchart TD
    U["ผู้ใช้ขอลงทะเบียน Authenticator ใหม่"] --> P1["ตรวจว่าอุปกรณ์อยู่ในการจัดการและผ่าน Compliance"]
    P1 --> P2["บังคับยืนยันตัวตนเพิ่มระดับใหม่"]
    P2 --> P3["ตรวจ Attestation เทียบ Allowlist ของรุ่น"]
    P3 --> T["ประเมินระดับความสำคัญของบัญชี"]
    T --> H["บัญชีสิทธิ์สูงต้องใช้ Hardware Key แบบ Device Bound"]
    T --> S["บัญชีทั่วไปใช้ Passkey แบบ Sync ได้"]
    H --> L["บันทึกเหตุการณ์และแจ้งเตือน"]
    S --> L
    L --> R["ลงทะเบียน Credential และเพิ่มเข้า Inventory"]

ถ้าคุณดูแลระบบตรวจจับด้วย

มาตรการควบคุมการลงทะเบียนข้างต้นคือการแก้ที่ยั่งยืน หากคุณมีระบบเก็บ Telemetry จากเครื่องปลายทางอยู่แล้ว มีสัญญาณสามอย่างที่แมปกับเทคนิคของ Unit 42 ได้ตรงและควรเพิ่มเข้าชุดกฎ: การเข้าถึงหน่วยความจำของเบราว์เซอร์โดย Process ที่ไม่ได้เซ็นหรือผิดปกติ, ไฟล์สถานะ Credential ของเบราว์เซอร์ที่ถูกสร้างหรือลบโดยสิ่งที่ไม่ใช่เบราว์เซอร์ และการอ่านฐานข้อมูล Sync ของเบราว์เซอร์โดย Process ภายนอก บนระบบที่ใช้ Sysmon สิ่งเหล่านี้คือ Event ID 10 และ 11 บวกกับ Telemetry การเข้าถึงไฟล์มาตรฐาน

ฝั่งระบบตัวตน เหตุการณ์ที่ควรยกออกจาก Audit Log มาเป็นการแจ้งเตือนคือ การลงทะเบียนและการถอดวิธียืนยันตัวตน, การออก Temporary Access Pass, ความล้มเหลวในการตรวจ Attestation และการเปลี่ยนแปลง Credential ใด ๆ ที่แตะบทบาทสิทธิ์สูง หากคุณใช้ ระบบเฝ้าระวังบน Wazuh อยู่แล้ว สิ่งเหล่านี้คือแหล่ง Log เพิ่มเติม ไม่ใช่เครื่องมือใหม่

การตรวจสอบสั้น ๆ ที่ทำได้ภายในสัปดาห์นี้

1. ทำรายการทุกเส้นทางใน Tenant ของคุณที่สามารถลงทะเบียน Authenticator ตัวใหม่ได้ รวมถึงขั้นตอนของ Helpdesk ไม่ใช่แค่ Flow ทางเทคนิค
2. สำหรับแต่ละเส้นทาง เขียนไว้ว่าผู้โจมตีที่มี Session ที่ขโมยมาและไม่มีอะไรอื่นอีก ต้องเอาชนะอะไรบ้าง
3. ตรวจว่าการลงทะเบียนถูกควบคุมด้วย Device Compliance และการยืนยันเพิ่มระดับที่ทำใหม่ หรือควบคุมด้วย Session ที่มีอยู่เท่านั้น
4. ดึง Credential Inventory ของทุกบัญชีที่ถือบทบาทผู้ดูแลระบบ มองหาสิ่งที่ลงทะเบียนจากอุปกรณ์หรือเวลาที่ไม่คาดคิด
5. ยืนยันว่าวิธีกู้คืนใดบ้างที่ทำให้เกิด Passkey ตัวใหม่ได้ และใครเป็นผู้เรียกใช้ได้
6. ตรวจการติดตั้ง CVE-2026-34348 บนเครื่องผู้ดูแลระบบโดยเฉพาะ
7. ตรวจว่ากระบวนการปิดบัญชีถอน Credential ไม่ใช่แค่ Session ทดสอบด้วยบัญชีจริง

คำถามที่พบบ่อย

เราควรหยุดใช้ Passkey หรือไม่

ไม่ควร Passkey กำจัด Credential Phishing ซึ่งยังคงเป็นช่องทางเข้าถึงเริ่มต้นที่พบบ่อยที่สุดอย่างทิ้งห่าง งานวิจัยเดือนสิงหาคมไม่ได้เปลี่ยนข้อเท็จจริงนั้น สิ่งที่มันเปลี่ยนคือสมมติฐานว่าการติดตั้ง Passkey เท่ากับงานด้านตัวตนเสร็จแล้ว — มันย้ายงานไปที่การลงทะเบียน การกู้คืน และ Inventory ซึ่งเป็นจุดที่งานควรอยู่ตั้งแต่แรก

การโจมตีนี้กระทบเราไหมถ้าเราไม่ได้ใช้ Google Password Manager

สายการโจมตีของ Unit 42 เจาะจงไปที่ระบบ Passkey แบบ Sync ของ Google บน Windows แต่บทเรียนเชิงโครงสร้างใช้ได้กับระบบ Credential แบบ Sync ทุกระบบ และสายของ SpecterOps พุ่งเป้าไปที่ Windows 11 กับ Entra ID โดยตรง หากพนักงานของคุณยืนยันตัวตนกับ Microsoft 365 งานวิจัยชุดที่สองคือชุดที่ควรอ่านก่อน

Hardware Security Key ยังคุ้มค่าอยู่ไหม

สำหรับบัญชีสิทธิ์สูง คุ้ม — Credential แบบ Device-Bound ที่มี Attestation ยังเป็นตัวเลือกที่แข็งแรงที่สุดที่มีอยู่ และปัญหา Master Secret ของการ Sync ไม่มีผลกับมัน งานวิจัยเดือนสิงหาคมพบว่าลายเซ็นของ Hardware Token ถูกเปิดเผยใน Log ของ Windows ซึ่งเป็นเหตุผลให้แพตช์ ไม่ใช่เหตุผลให้เลิกใช้ Hardware Token

เราเป็นบริษัทขนาดกลางที่ไม่มีทีมดูแลตัวตนโดยเฉพาะ ควรเริ่มตรงไหน

เริ่มที่การควบคุมการลงทะเบียนและเส้นทางการกู้คืน สองมาตรการนี้ปิดความเสี่ยงในทางปฏิบัติได้เกือบทั้งหมด และไม่ต้องซื้อซอฟต์แวร์ใหม่ — เป็นการเปลี่ยนการตั้งค่าบน Identity Provider ที่คุณใช้อยู่แล้ว Credential Inventory ค่อยตามมา เพราะคุณแจ้งเตือนการเปลี่ยนแปลงของสิ่งที่ไม่เคยนับไว้ไม่ได้

การรวมศูนย์ไว้ที่ Identity Provider เดียวทำให้แย่ลงหรือไม่ เพราะเป็นการกระจุกความเสี่ยง

มันกระจุก จุดควบคุม ซึ่งตรงข้ามกับการกระจุกความเสี่ยง เมื่อมีระบบล็อกอินแยกกัน 24 ระบบ ก็มีเส้นทางลงทะเบียนและกู้คืน 24 ชุด ซึ่งส่วนใหญ่ไม่เคยมีใครตรวจสอบเลย เมื่อมี Identity Provider เดียว ก็มีเส้นทางชุดเดียวให้ทำให้แข็งแรง Inventory ชุดเดียวให้ดูแล และที่เดียวให้เพิกถอน

---

จุดที่เรื่องนี้เชื่อมโยง

ระบบตัวตนแบบรวมศูนย์คือเงื่อนไขเบื้องต้นของทุกอย่างข้างต้น คุณไม่สามารถควบคุมการลงทะเบียน บังคับระดับ Attestation หรือดูแล Credential Inventory ข้ามระบบที่กระจัดกระจายซึ่งแต่ละแอปจัดการล็อกอินของตัวเองได้ — ซึ่งเป็นเหตุผลพื้นฐานของการรวมศูนย์ตั้งแต่แรก

Simplico สร้างและดูแล simpliSSO ระบบ Identity Portal บน Authentik ที่เชื่อมต่อกับ Microsoft 365 และ Azure AD ครอบคลุม OIDC, SAML2, LDAP, Step-up MFA Policy และ SCIM Provisioning ทั่วทั้งระบบงาน หากคุณกำลังทำงานเรื่องการทำให้การลงทะเบียนแข็งแรงขึ้นบนระบบที่มีอยู่ หรือกำลังกำหนดขอบเขตระบบใหม่ เรายินดีดูสภาพแวดล้อมของคุณ: hello@simplico.net

---

แหล่งที่มา:

• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication — Unit 42
• New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA — The Hacker News
• New Pass-ta-key attacks let malware hijack Google-synced passkeys — BleepingComputer
• Flaws in Passkey Implementation Show Old Attacks Still Work — Dark Reading
• Pass-the-Passkey Family of Attacks at Black Hat USA 26 — DSInternals