สารบัญ
Series: CyberSecurity Foundation — รากฐาน Security สำหรับยุค AI (ภาษาคน)
Part 0 — WHY: เมืองนี้ทำไมต้องมียาม
- EP.00 (Prologue) — 5 Generations + PPT + CISA vs CISA
- EP.01 — Cybersecurity คือเรื่องของคุณ
- EP.02 — 4 เคสที่เปลี่ยนวงการ
- EP.03 — CIA Triad
- EP.04 — Defense in Depth + Diversity
- EP.05 — Assume Breach + Risk
Part 1 — HOW: ระบบนิเวศของเมือง
- EP.06 — ระบบนิเวศของโจร
- EP.07 — ระบบนิเวศของผู้ป้องกัน: Blue / Red / Purple
- EP.08 — Framework: ISO / NIST / COBIT / CIS
- EP.09 — Compliance Theater
Part 2 — Identity: บัตรประชาชน + กุญแจห้อง
- EP.10 — IAM Lifecycle
- EP.11 — Authentication: 3 Factors + AAA ← คุณอยู่ตรงนี้
- EP.12 — Password 101
- EP.13 — MFA + Biometric
- EP.14 — Kerberos
- EP.15 — Federation + SSO
- EP.15.5 — Web Services Trio: SOAP / WSDL / UDDI (Primer)
- EP.16 — Authorization: RBAC / ABAC / MAC / DAC
- EP.17 — PAM + Zero Trust
Part 3 — Data: ของในเซฟ
- EP.18 — Data Classification + Lifecycle
- EP.19 — Cryptography 101
- EP.20 — Symmetric Crypto: AES
- EP.21 — Asymmetric Crypto: RSA + DH
- EP.22 — Hashing: SHA Family
- EP.23 — PKI + Certificates
- EP.24 — TLS / HTTPS
- EP.25 — Email Security: SPF / DKIM / DMARC
- EP.26 — Privacy Engineering
Part 4 — Infrastructure: ถนน กำแพง ท่อ
- EP.26.5 — Network Anatomy: 7 ชั้นของถนนในเมือง (Primer)
- EP.27 — Network Basics + Firewall Generations
- EP.28 — Segmentation + DMZ + Microsegmentation
- EP.29 — IDS / IPS / WAF / RASP
- EP.30 — VPN + Proxy + DNS Security
- EP.31 — DDoS + DLP
- EP.32 — Cloud + Shared Responsibility
- EP.32.5 — Cloud Stack Anatomy: 9 ชั้นของระบบ (Primer)
- EP.33 — Container + Kubernetes Security
- EP.33.5 — Beyond Container: MicroVM / Wasm / Unikernel
- EP.34 — DevSecOps + Shift-Left
- EP.35 — Mobile + Wireless
- EP.36 — IoT + OT / ICS Security
- EP.37 — Remote Work + ZTNA
- EP.38 — AI Security + Blockchain Security
Part 5 — Operations: ตำรวจ ดับเพลิง สืบสวน
- EP.39 — Kill Chain + MITRE ATT&CK
- EP.40 — Social Engineering: Phishing / BEC / Vishing
- EP.41 — Malware Taxonomy
- EP.42 — Web App Attacks: OWASP Top 10
- EP.43 — Detection: SOC + SIEM + EDR / XDR / SOAR
- EP.44 — Threat Hunting + Deception
- EP.45 — Vuln Scan / Pen Test / Red Team / BAS
- EP.46 — Incident Response (NIST 800-61)
- EP.47 — Digital Forensics
Part 6 — Governance: เทศบาล + กฎหมายเมือง
EP.10 ผมพาคุณดู lifecycle ของบัตรประจำตัวพนักงานครบทั้ง 3 ขั้น — เข้า / ย้าย / ออก แต่ตั้งใจทิ้งคำถามค้างไว้ในย่อหน้าสุดท้ายของ EP ครับ — ตอนพนักงานคนนี้ login จริงๆ ตอนเช้าวันจันทร์ ระบบรู้ยังไงว่าคนที่กำลังพิมพ์ password อยู่ในเครื่อง = คนคนเดียวกับที่ HR เพิ่ง onboard ไปเมื่อสัปดาห์ที่แล้ว?
คำตอบของวงการมีคำสั้นๆ คำเดียว — Authentication แปลตรงตัวคือ “การพิสูจน์ตัวตน”
เพื่อให้ติดภาพในหัวจริงๆ ขอเปลี่ยน metaphor จาก “บัตรประจำตัว” ของ EP.10 ไปเป็นภาพที่จับต้องได้กว่า — ยามหน้าคอนโด ยามที่ยืนอยู่หน้าตึก ถามคำถามเดียวกันกับทุกคนที่เดินเข้ามา “พี่เป็นใครครับ”
ฟังดูง่าย แต่ยามที่ดีรู้ว่าคำตอบจากปากเปล่าไม่พอ ต้องมีหลักฐาน และวงการ security ค้นพบมาแล้วว่าหลักฐานที่พิสูจน์ตัวตนคน มีอยู่แค่ 3 ประเภท ในโลกใบนี้
AAA — 3 คำที่คนสับสนตลอด
ก่อนเจาะเข้า 3 ประเภทหลักฐาน ขอวางคำใหญ่ก่อน 1 คำ เพราะถ้าคำนี้สับสน ทุก EP ที่เหลือใน Part 2 จะกลายเป็นตัวย่อเยอะจนงงหมด
ในตำรา security ทุกเล่ม จะเปิดเรื่อง identity ด้วย framework ชื่อ AAA (อ่านว่า “ทริปเปิ้ลเอ”) ย่อมาจาก 3 คำที่ขึ้นต้นด้วย Auth- เหมือนกัน — Authentication / Authorization / Accountability — และเป็น 3 คำที่แม้แต่คนทำสาย IT มาหลายปียังเขียนสลับกันบ่อยมาก ผมก็เคย ทุกคนเคย
3 คำนี้ ถ้าอธิบายด้วยภาพคอนโดเดิม แบ่งหน้าที่กันชัดดังนี้:
- Authentication = ยามหน้าตึกที่ถาม “คุณเป็นใคร” — งานเดียวคือพิสูจน์ตัวตน. ผ่านหรือไม่ผ่าน
- Authorization = รปภ. ห้องควบคุมที่กดเปิดประตู — รู้แล้วว่าคุณคือใคร แต่คุณมีสิทธิ์ขึ้นไปชั้น 30 ของเจ้าของห้องไหม
- Accountability = กล้องวงจรปิด + สมุดเซ็นชื่อ — บันทึกไว้ว่าคืนนี้คุณเข้ามากี่โมง เดินไปไหนบ้าง ออกตอนไหน
3 หน้าที่นี้ดูเหมือนเรื่องเดียวกัน แต่ รวมในคนเดียวไม่ได้ ลองคิดดู — ถ้ายามคนเดียวกันที่ตรวจบัตรคุณ ก็เป็นคนกดเปิดประตูห้องเอง ก็เป็นคนถือสมุดเซ็นชื่อเอง ปัญหามาทันที 2 ข้อ
- ข้อแรก ถ้าโจรหลอกยามคนนี้ได้ = ยึดได้ทุกชั้นในตึก
- ข้อสอง ยามคนนี้กลายเป็นทั้งผู้ตรวจสอบและผู้ถูกตรวจสอบในเวลาเดียวกัน อยากแอบทำผิด เขาแก้สมุดเซ็นชื่อของตัวเองได้
นี่คือสาเหตุที่วงการแยก 3 หน้าที่ออกจากกันชัดเจน ใน EP นี้เรา focus แค่ตัวแรก ตัวที่สอง (Authorization) จะ dedicate ให้ทั้ง EP ที่ EP.16 เพราะลึกมาก ตัวที่สาม (Accountability) จะกลับมาตอน Part 5 เรื่อง audit log + SIEM
Scenario ที่ทำให้เห็นความต่างของ AuthN กับ AuthZ ในชีวิตจริง
ผมเล่าเคสที่ทุกคนน่าจะเคยเห็นในชีวิต — ลูก 8 ขวบ login Facebook ของแม่
ขั้นแรก — ลูกเดินไปดู iPad ของแม่ตอนแม่ไม่อยู่. รู้ว่าแม่ใส่ password อะไร (เพราะแม่ใช้รหัส 4 หลักจดบนกระดาษติดข้างเตียง). ลูกกรอก password ของแม่ → ระบบเปิดให้เข้า. ขั้นนี้ผ่าน Authentication เพราะคนที่กรอกรหัสได้ — ระบบเชื่อว่าเป็นแม่. ระบบไม่มีทางรู้ว่าคนที่อยู่หน้าจอจริงๆ คือเด็ก 8 ขวบ
ขั้นที่สอง — ลูกอยากเข้าหน้า “Settings → Delete Account”. ตรงนี้แม้จะ login ในฐานะ “แม่” — Facebook ก็จะถามอีกชั้นว่า “คุณแน่ใจไหม? ใส่รหัสอีกครั้ง + ยืนยันผ่าน email”. ขั้นนี้คือ Authorization — Facebook ถาม “คุณมีสิทธิ์ทำอะไรที่ severe ระดับนี้ไหม”. ใส่รหัสซ้ำ → ลูกใส่ได้ (รหัสเดิม) — แต่ขั้น verify email — ต้องไปเปิด Gmail ของแม่ที่มี 2FA = ลูกไม่ผ่าน
เห็นภาพไหมครับ — Authentication ผ่าน (ระบบเชื่อว่าคนนี้คือแม่). Authorization ไม่ผ่าน (เพราะการทำเรื่อง severe ต้องการหลักฐานเพิ่ม). ถ้าระบบรวม 2 ตัวนี้เข้าด้วยกัน — login ผ่านครั้งเดียวจบ ทำได้ทุกอย่าง — เด็ก 8 ขวบลบ account ของแม่ในคลิกเดียว
นี่คือเหตุผลที่ AAA ต้องแยก. และนี่คือเหตุผลที่ EP นี้ — เรา focus แค่ “ยามหน้าคอนโด” — Authentication. ตัว AuthZ + Accountability ค้างไว้ EP หลัง
3 ประเภทของหลักฐาน — ที่ยามทั่วโลกใช้ตรงกัน
กลับมาที่ภาพยามหน้าคอนโดครับ. ยามไม่รู้จักคุณเป็นการส่วนตัว — คอนโดมีลูกบ้าน 500 คน + แขก + ช่าง + พนักงานส่งของ — ยามจำหน้าทุกคนไม่ได้. ยามต้องการ “หลักฐาน”. และวงการ security ค้นพบว่า — หลักฐานที่พิสูจน์ตัวตนคน — มีอยู่แค่ 3 ประเภท. ไม่ใช่ 4. ไม่ใช่ 5. 3 — และทุกสิ่งที่คุณเคยใช้ login (ตั้งแต่ password จนถึง iris scan) ก็จัดอยู่ใน 3 ประเภทนี้ทั้งหมด
3 ประเภทคือ:
- Something you Know — สิ่งที่คุณรู้ในหัว
- Something you Have — สิ่งที่คุณถือในมือ
- Something you Are — สิ่งที่ติดอยู่กับตัวคุณ
มาดูทีละตัวครับ ผมจะไม่เล่าด้วย bullet ขนานกัน เพราะแต่ละตัวมีนิสัยของมันเอง ขอเล่าทีละเรื่อง
Know — รหัสลับที่ยามขอให้พูดเบาๆ
ลองนึก scenario นี้ — คุณเดินเข้าคอนโดตอนกลางคืน ยามไม่จำหน้าคุณ. ยามชะโงกหน้าถาม “รหัสห้องอะไรครับ?”. คุณกระซิบ “1408”. ยามพยักหน้า เปิดประตูให้ — เพราะคนที่รู้รหัสห้องนี้ น่าจะเป็นลูกบ้านห้องนั้น
นี่คือหลักฐานประเภทแรก — Something you Know. ความรู้บางอย่างในหัวที่คนอื่นไม่รู้ — password, PIN, คำถามลับ (“ชื่อสัตว์เลี้ยงตัวแรกของคุณ?”), passphrase. รหัสในหัวเป็นหลักฐานที่มนุษย์ใช้มาเป็นพันปี — ตั้งแต่รหัสลับของชุมชนคริสเตียนยุคต้น จนถึง password ของ Gmail ของคุณวันนี้
ปัญหาของรหัสในหัว — มันคือข้อมูลที่ “ส่งต่อกันได้”. ถ้าโจรอยากขโมยลายนิ้วมือของคุณ — เขาต้องเจอตัวคุณ + ทำอะไรกับตัวคุณจริงๆ. ถ้าโจรอยาก hack hardware key ของคุณ — เขาต้องล้วงกระเป๋าคุณตอนคุณไม่ระวัง. แต่ถ้าโจรอยากขโมย password ของคุณ — เขาแค่ส่ง email หลอกให้คุณกรอกในเว็บปลอม. คุณนั่งกินกาแฟอยู่ที่กรุงเทพฯ — โจรนั่งอยู่ที่ Lagos — ในไม่กี่วินาที password ของคุณก็อยู่ในมือเขา. ไม่ต้องเจอหน้ากันเลย
นี่คือเหตุที่ Verizon Data Breach Investigations Report ทุกปี — รายงานตรงกันว่า กว่าครึ่งของ data breach ในโลกเกี่ยวข้องกับ password ที่ถูกขโมยหรืออ่อนแอ. ไม่ใช่ encryption ที่ถูกเจาะ ไม่ใช่ zero-day ที่ราคาเป็นล้านดอลลาร์. แค่ password — หลักฐานที่ขโมยง่ายที่สุดของวงการ. EP.12 ทั้ง EP ผมจะ dedicate ให้กับเรื่อง password เพราะมันลึก + กับดักเยอะกว่าที่คนทั่วไปคิด
Have — กุญแจในกระเป๋าที่โจรลอกไม่ได้ถ้าไม่จับของจริง
ทีนี้ลอง scenario คนละแบบ — คุณกลับมาตอนกลางคืนเหมือนเดิม. แต่คอนโดนี้ยกระดับแล้ว — ไม่มียามถามรหัส. แทนที่ — มีเครื่อง scan ที่ประตู. คุณ tap บัตร RFID ของคุณ → ประตูเปิด. ใครไม่ได้บัตรนี้ — เข้าไม่ได้
นี่คือหลักฐานประเภทที่สอง — Something you Have ของจริงที่อยู่ในมือคุณตอนนั้น และโจรต้องขโมยของจริงถึงจะใช้ได้
ในวงการ security หลักฐานประเภทนี้มีหลายรูปแบบ:
- Hardware token — กล่องพลาสติกแสดงตัวเลขเปลี่ยนทุก 30 วินาที เช่น YubiKey, RSA SecurID
- Authenticator app — Google Authenticator, Microsoft Authenticator
- SMS OTP — รหัสที่ส่งมาทาง SMS
- Smart card — บัตรชิปที่ใช้กับ reader
- Push notification — มือถือเด้งแจ้งเตือนถาม “นี่คุณกำลัง login ใช่ไหม”
จุดเด่นของหลักฐานประเภทนี้ — โจรต้องเข้าใกล้คุณ. โจรที่ห่างคุณเป็นพันกิโลเลียนแบบไม่ได้ — เพราะของอยู่ในกระเป๋าคุณ. และตัวเลข 6 หลักของ Authenticator app — อายุแค่ 30 วินาที. โจรขโมยมาช้ากว่า 30 วินาที = ใช้ไม่ได้
แต่ — ของในมือก็มีจุดอ่อนของมันเอง. ลืมที่บ้านได้ (scenario คลาสสิคของวงการ — ลืม YubiKey ไว้ที่บ้าน เข้าระบบบริษัทไม่ได้ทั้งวัน). พังได้ (มือถือจอแตก = Authenticator app ที่ลงไว้หายไปกับมัน). และที่สำคัญที่สุด — กรณี SMS OTP มี attack ชื่อ SIM swap ที่กำลังระบาดในไทยตอนนี้ — โจรหลอก call center ของค่ายมือถือให้ย้ายเบอร์ของคุณไปอยู่ใน SIM ใหม่ของโจร → SMS ทั้งหมดเข้าโจรแทน. ปี 2017 NIST ของอเมริกาประกาศไม่แนะนำ SMS OTP เป็น factor หลักด้วยเหตุนี้ — แต่ธนาคารไทยส่วนใหญ่ปี 2026 ยังใช้กันสบายๆ
Are — ของที่ติดมากับตัวคุณตั้งแต่เกิด
scenario สุดท้าย — คอนโดยุคใหม่. ไม่มียาม ไม่มีบัตร RFID. คุณเดินเข้าไปหน้าประตู — เครื่องสแกนใบหน้าจดจำได้ในเสี้ยววินาที — ประตูเปิด. คุณไม่ต้องพกอะไรเลย — แค่หน้าของคุณ
นี่คือหลักฐานประเภทที่สาม — Something you Are ตัวอย่าง:
- ลายนิ้วมือ (Touch ID)
- ใบหน้า (Face ID)
- ม่านตา (iris scan)
- เสียง (voice authentication)
- เส้นเลือดในฝ่ามือ (palm vein — บางธนาคารใช้)
- รูปแบบการพิมพ์ของคุณ (behavioral biometrics)
วงการเรียกหลักฐานประเภทนี้รวมๆ ว่า Biometric
ฟังดูเป็นคำตอบที่สมบูรณ์ใช่ไหมครับ — ติดตัวคุณตลอด ไม่ลืมบ้าน ไม่ทำหาย ขโมยยาก. แต่ — และนี่คือกับดักที่คนส่วนใหญ่ไม่ตระหนัก — ถ้า biometric ของคุณถูกขโมย คุณเปลี่ยนนิ้วของคุณไม่ได้ตลอดชีวิต
ในปี 2015 — OPM (Office of Personnel Management) ของรัฐบาลอเมริกาโดน hack. ข้อมูลที่หลุดออกไป — รวมถึง ลายนิ้วมือของพนักงาน federal 5.6 ล้านคน. คนเหล่านั้น — ไม่มีทางเปลี่ยนลายนิ้วมือของตัวเองได้ตลอดชีวิต. ลายนิ้วมือพวกเขาอยู่ในมือคนที่ไม่ทราบจำนวนตลอดไป. ทุกระบบที่ใช้ biometric ของพนักงานเหล่านี้ — เสี่ยงตลอดไป. ถ้า password leak — เปลี่ยนใหม่ได้ในนาที. ถ้านิ้วมือ leak — จบ. คือ trade-off ใหญ่ของ biometric — convenience สูงสุด แต่ recovery เป็นศูนย์ถ้าถูก hack
และที่ผมจะเล่าใน EP.13 — biometric ยังหลอกได้ด้วยเทคนิคต่างๆ ตั้งแต่ silicone fingerprint mold ที่ Chaos Computer Club ใช้ hack iPhone Touch ID ภายใน 24 ชั่วโมงหลังเปิดตัว จนถึง deepfake voice ที่หลอกพนักงาน finance ให้โอนเงินหลายสิบล้านยูโรในเคสจริงปี 2024
MFA — กฎที่คนเข้าใจผิดบ่อย
ตอนนี้คุณรู้จัก 3 ประเภทครบแล้วครับ. คำถามถัดมา — ใช้กี่ประเภทพอ?
วงการมีศัพท์เรียก 3 ระดับ:
- SFA (Single-Factor) — 1 ประเภท
- 2FA (Two-Factor) — 2 ประเภท
- MFA (Multi-Factor) — 2 ประเภทขึ้นไป
แต่นี่คือจุดที่คนเข้าใจผิดบ่อยที่สุดในวงการ มีกฎเหล็กข้อหนึ่งที่ต้องท่องไว้ — factors ต้องเป็นคนละประเภท ถึงจะนับเป็น MFA ได้
ลองดูตัวอย่างที่คนคิดว่าเป็น MFA แต่จริงๆ ไม่ใช่ — password + คำถามลับ ฟังดูเหมือน 2 ขั้น แต่ทั้งคู่คือ “Something you Know” ประเภทเดียวกัน โจรที่ทำ phishing ได้ หลอกเอาทั้ง password และคำตอบของคำถามลับพร้อมกันในเว็บปลอมเดียวกัน ไม่ได้ยกระดับการกัน attack เพิ่มเลย นี่คือ “Know + Know” = ไม่ใช่ MFA จริง
ส่วน MFA จริง ต้องเป็น คนละประเภท:
- Know + Have — password + Authenticator app
- Know + Are — password + Fingerprint
- Have + Are — YubiKey + Face ID
หลักการคือ ถ้าโจรขโมย Know ได้ผ่าน phishing แล้วก็จริง ก็ยังต้องเข้าถึงมือถือคุณเพิ่ม (Have) หรือ ตัวคุณจริงๆ เพิ่ม (Are) ซึ่งเป็นเทคนิค attack คนละชุดเลย โจรคนเดียวที่เก่งทั้ง 2 ชุดแบบ หายากมาก
MFA ไม่ใช่ของใหม่ — ATM ใช้มาตั้งแต่ 1967
ที่ผมอยากให้คุณเห็นภาพชัด — MFA ไม่ใช่เทคโนโลยีใหม่. ปี 1967 — ธนาคาร Barclays ในลอนดอนเปิด ATM เครื่องแรกของโลก. และตั้งแต่วันแรกนั้น — ATM ใช้ MFA แล้ว. บัตร (Have) + PIN (Know). ฝากเงินถอนเงิน ต้องการ 2 ประเภทเสมอ — บัตรอย่างเดียวไม่พอ, PIN อย่างเดียวไม่พอ
คำถามที่ตามมาเป็นเรื่องที่ผมรู้สึกแปลกใจตลอดเวลาเล่า — ทำไม mobile banking ที่เกิดในไทยปี 2010+ ถึงเพิ่งบังคับ MFA จริงจังในช่วงปี 2020s — กว่า 50 ปีหลังจาก ATM? คำตอบ — เพราะธนาคารยุค mobile banking มอง “ความสะดวก” สำคัญกว่า “ความปลอดภัย” จนเกิดความเสียหายจริงในวงกว้าง. และในที่สุด — ธนาคารแห่งประเทศไทยก็ต้องออก regulation บังคับ MFA หลังเคส scam call center บูมในปี 2023-2024
สำหรับผู้บริหารบริษัท — ผมอยากให้คุณคิดแบบนี้ครับ. ในปี 2019 Microsoft ประกาศผลการศึกษากับ Azure AD account นับล้าน — MFA ลดอัตราการถูก takeover ลงกว่า 99%. ตัวเลขนี้ถ้าเทียบกับยา = ยา 1 เม็ดที่ลดความน่าจะเป็นโรคใหญ่ลง 99%. และที่น่าตกใจ — Microsoft Authenticator + Google Authenticator + Authy — ทั้งหมดฟรี. ปี 2024 — Microsoft เลิกแนะนำ MFA + บังคับเลย — ใครไม่เปิดในระบบของเขา = ใช้ไม่ได้. นี่คือ shift จาก “MFA = best practice” ไปเป็น “MFA = baseline requirement” ของวงการ
Adaptive Authentication — ยามที่ฉลาดขึ้น
ทีนี้ — ลองสมมติว่าคอนโดของคุณติด AI ที่ฉลาด. ปกติคุณเดินเข้าตอน 6 โมงเย็นทุกวันหลังเลิกงาน — ยามแค่พยักหน้า. แต่คืนนึงคุณเดินเข้าตอนตี 3 + ใส่ชุดที่ไม่เคยใส่ + มีคนแปลกหน้าเดินตามมา — ยามขอตรวจบัตรเพิ่ม + โทรไปยืนยันที่นิติฯ
นี่คือสิ่งที่วงการเรียกว่า Adaptive Authentication หรือ Risk-based Authentication — ระบบที่ปรับความเข้มของการตรวจตามบริบท (context). พฤติกรรมที่ดูปกติ — ตรวจน้อย. พฤติกรรมที่ดูแปลก — ตรวจเข้ม
scenario ในชีวิตจริง — คุณ login Gmail จาก laptop ที่ทำงานทุกวันตอน 10 โมง — Google ให้ผ่านสบายๆ. แต่วันที่คุณ login จาก IP address ที่อยู่ในรัสเซีย เวลาตี 3 ตามเวลาไทย — Google จะเด้งถาม MFA ทันที + ส่ง email “เราเห็นการ login จาก device ใหม่ที่ Moscow — เป็นคุณหรือเปล่า?”. Google ใช้ระบบนี้มาตั้งแต่ราวๆ ปี 2017 — และเป็นเหตุที่คุณเห็นข้อความนี้บ่อยเวลาเดินทาง
trade-off ของ Adaptive Authentication คือ — ดีต่อ user experience (พนักงานไม่ต้องกด MFA ทุกครั้งที่ทำงานปกติ) แต่ต้องลงทุน risk engine ที่เรียนรู้พฤติกรรม + ทีมที่ tune model. บริษัทระดับ enterprise (ใช้ Okta / Microsoft Entra ID ระดับ premium) มี feature นี้พร้อม. SME ส่วนใหญ่ยังไม่ถึง — แต่อย่างน้อย Google Workspace + Microsoft 365 plans ทั่วไป มี baseline risk-based MFA มาให้ฟรี — แค่เปิดใช้
AAA Protocols — RADIUS / TACACS+ / Diameter ที่วงการใช้จริง
คำว่า “AAA” ที่วางไว้ตอนต้น EP คือ framework — Authentication / Authorization / Accountability. แต่พอเข้าโลกจริง เวลายามหลายตึกในเมืองเดียวกันต้องคุยกัน ส่งคำถาม “คนนี้ใครครับ ผ่านได้ไหม” ไปถามที่ส่วนกลาง เขาคุยกันด้วย “protocol” ที่มีชื่อเฉพาะ ทั้งวงการ network + IS audit ใช้ 3 ชื่อนี้ตรงกันทั้งโลกครับ คือ RADIUS / TACACS+ / Diameter. ถ้าดูระบบ Wi-Fi ของออฟฟิศ หรือ login ของ router/switch ที่ทีม IT ใช้ มี 1 ใน 3 ตัวนี้นั่งทำงานอยู่หลังบ้านเสมอ
ลองนึกภาพแบบนี้ สำนักงานของคุณมี Wi-Fi enterprise (พนักงานต้อง login ด้วย account บริษัท ไม่ใช่รหัสเดียวกันทุกคน). พอพนักงานเปิด laptop เชื่อม Wi-Fi laptop ก็ส่ง username + password ไปที่ Wi-Fi access point ตัว access point ไม่ใช่คนตัดสินใจเอง มันส่งต่อคำถามไปที่ “ส่วนกลาง” ที่เก็บรายชื่อพนักงานทั้งหมด ส่วนกลางตอบกลับ “ผ่าน” หรือ “ไม่ผ่าน” ภาษาที่ access point ใช้คุยกับส่วนกลางนั่นแหละครับ คือ AAA protocol
RADIUS — ตัวที่วงการใช้กว้างที่สุด
RADIUS ย่อจาก Remote Authentication Dial-In User Service ชื่อย้อนยุค (มาจากยุค dial-up modem ที่ผู้ใช้โทรเข้า server) แต่ทุกวันนี้กลายเป็นมาตรฐานกลางของวงการไปแล้ว เป็น IETF standard (open standard ใช้ได้ทุกค่าย), วิ่งบน UDP (เร็วแต่ไม่ guarantee delivery), port 1812 สำหรับ auth + port 1813 สำหรับ accounting
จุดที่ต้องจำของ RADIUS คือ encrypt เฉพาะส่วน password username + ข้อมูล accounting ส่งไปแบบ plain text แล้วก็ รวม Authentication + Authorization ในข้อความเดียว (ตอบ “ผ่าน” พร้อมส่งสิทธิ์มาเลย ไม่แยกขั้น) use case ที่เจอบ่อยคือ Wi-Fi enterprise (WPA2-Enterprise / WPA3-Enterprise), VPN concentrator ของบริษัท, Network Access Server (NAS)
TACACS+ — ตัวของ Cisco ที่ตรวจเข้มกว่า
TACACS+ ย่อจาก Terminal Access Controller Access-Control System Plus เกิดจาก Cisco (proprietary ของ Cisco เดิม แต่ตอนนี้ค่ายอื่นรองรับเยอะแล้ว) วิ่งบน TCP (reliable กว่า UDP) ที่ port 49
จุดต่างจาก RADIUS ที่สำคัญมีอยู่ 2 ข้อ ข้อแรก คือ encrypt ทั้ง payload (ทั้ง username + password + ข้อมูลสิทธิ์) ข้อสอง คือ แยก 3 A ออกจากกันชัดเจน (Auth / Authz / Accounting เป็น 3 process อิสระ ไม่รวมในข้อความเดียว) use case ที่เจอบ่อยคือ การ login เข้า CLI ของ router/switch ที่ทีม network admin ใช้ เพราะการแยก Authz ออกชัด ช่วยให้ define ได้ว่า admin คนนี้พิมพ์คำสั่งอะไรได้บ้าง (เช่น ห้ามพิมพ์ reload ห้าม config terminal)
Diameter — ตัวที่สืบทอด RADIUS
Diameter เป็น successor รุ่นใหม่ของ RADIUS ชื่อเล่นมาจากมุข geometry (diameter = 2 × radius) เป็น IETF standard เหมือนกัน, วิ่งบน TCP หรือ SCTP (reliable), port 3868, ใช้ TLS encrypt ทั้ง connection use case หลักคือ ระบบ carrier มือถือ 4G/5G + IMS (IP Multimedia Subsystem) พนักงาน IT ทั่วไปแทบไม่เจอ แต่ถ้าอยู่ในวงการ telecom Diameter อยู่หลังบ้านของทุก SIM card
ตาราง comparison
| Feature | RADIUS | TACACS+ | Diameter |
|---|---|---|---|
| Transport | UDP | TCP | TCP / SCTP |
| Port | 1812 / 1813 | 49 | 3868 |
| Encryption | password เท่านั้น | payload ทั้งหมด | TLS |
| AAA split | รวม Auth + Authz | แยก 3 ขั้น | แยก 3 ขั้น |
| Vendor | open standard | Cisco origin | open standard |
| Use case หลัก | Wi-Fi / VPN auth | network device admin | carrier 4G/5G |
มุมผู้บริหาร: ถ้าทีม IT บอกว่า “เราใช้ RADIUS สำหรับ Wi-Fi office” นั่นคือ baseline ที่ดีครับ. แต่ถ้าทีม network admin ของคุณ login เข้า router/switch ด้วย password เดียวกันทุกคน (ไม่มี TACACS+ หรือ RADIUS เป็นตัวกลาง) = ไม่มีทาง audit ได้ว่าใครพิมพ์คำสั่งอะไร = หายนะรอเกิดเวลามีปัญหา คำถามที่ควรถามทีมตรงๆ คือ “admin login เข้า network device เราใช้ central auth ไหม หรือ shared password?”
Certificate-based Authentication — กุญแจดิจิทัลที่ผูกกับตัวเครื่อง
ก่อนปิด EP มีอีก 1 รูปแบบของ authentication ที่ ISACA สอบบ่อยและวงการใช้กว้างขึ้นเรื่อยๆ คือ Certificate-based Authentication แทนที่จะใช้ password ก็ใช้ digital certificate ตามมาตรฐาน X.509 (มาตรฐานเดียวกับ HTTPS ของเว็บ)
หลักการง่ายๆ ครับ เครื่องของคุณถือ certificate ที่มี Certificate Authority (CA) ที่บริษัทเชื่อใจเซ็นรับรอง ตอน login server ตรวจ 2 อย่าง คือ (1) certificate นี้ CA ที่เราเชื่อใจเซ็นจริงไหม (verify chain) (2) certificate ยังไม่หมดอายุและยังไม่ถูกเพิกถอน (revocation status) ถ้าผ่านทั้ง 2 ก็ login สำเร็จ ไม่ต้องพิมพ์ password สักตัว use case ที่เจอบ่อยคือ Mutual TLS (mTLS) ระหว่าง microservice ในบริษัท, smart card login ของหน่วยงานราชการ/military, EAP-TLS ของ Wi-Fi เกรด enterprise สูงสุด
จุดเด่นเทียบ password คือกัน phishing ได้ในตัว (โจรหลอกให้กรอก cert ไม่ได้ เพราะ private key ไม่ได้อยู่ในความรู้ของมนุษย์ มันอยู่ในเครื่อง) กัน replay attack ได้ (cert ผูกกับ session signing) จุดอ่อนคือ จัดการ lifecycle ของ cert ปวดหัว (ออก / ต่ออายุ / เพิกถอน / กระจายไปทุกเครื่อง) บริษัทเล็กที่ไม่มี PKI team = ปวดหัวจริงๆ ครับ
Authorization แบบหยาบ vs แบบละเอียด
ปิดท้ายเรื่องคำใหญ่อีก 1 คู่ที่ CRM ของ ISACA สอบบ่อยครับ คือ coarse-grained vs fine-grained authorization ตัวนี้จริงๆ ก้าวข้าม EP นี้ไปแตะ EP.16 (Authorization) แล้ว แต่อยากให้เห็นภาพคู่นี้ก่อน เพราะตอนเรียนเรื่อง RBAC / ABAC ภายหลัง คำนี้จะกลับมาอีก
Coarse-grained = สิทธิ์ระดับหยาบ ระบบควบคุมที่ระดับ application หรือ module ตอบคำถาม “พนักงานคนนี้เข้า HR system ได้ไหม” (ผ่าน/ไม่ผ่าน) ง่ายต่อการตั้งและบริหาร แต่ครอบคลุมไม่ละเอียด
Fine-grained = สิทธิ์ระดับละเอียด ระบบควบคุมที่ระดับ field หรือ operation ตอบคำถาม “พนักงาน HR คนนี้ดู column ‘salary’ ของ record พนักงาน level director ได้ไหม” กันรั่วได้ดีกว่ามาก แต่ overhead ในการ design + maintain สูงกว่าหลายเท่า ระบบ enterprise ที่จัดการข้อมูล sensitive (HRIS / financial / healthcare) มักต้องไป fine-grained เพราะ regulator (เช่น HIPAA, PDPA) บังคับ
ลองนึก scenario บริษัทมี HRIS coarse-grained = “พนักงาน HR ทุกคนเห็นข้อมูลพนักงานทุกคน” fine-grained = “HR officer junior เห็นข้อมูลพนักงาน level junior-mid เท่านั้น, HR director เห็น executive salary ได้” ระดับการกันรั่วต่างกันคนละโลกเลยครับ
ทำไม MFA ก็ไม่ใช่ silver bullet
ผมต้องจบ EP นี้ด้วยข้อหนึ่งที่สำคัญมาก — เปิด MFA แล้วไม่ได้แปลว่าปลอดภัย. MFA ลดความเสี่ยงเยอะมาก — แต่มี attack หลายชนิดที่ข้าม MFA ได้
ที่ผมอยากเล่า — เคส Uber 2022. โจรอายุ 18 ปีขโมย password ของพนักงาน Uber คนหนึ่งได้ — แต่ติดที่ MFA แบบ push notification. โจรไม่ยอมแพ้ — กดปุ่ม login ของพนักงานคนนั้นซ้ำๆ ทุกๆ 1-2 นาที. มือถือของพนักงานเด้งแจ้งเตือนรัวๆ — “Approve login? Approve login? Approve login?” — ตอนตี 3 ของคืน. หลัง notification กว่า 100 ครั้ง — พนักงานก็กด “Approve” ด้วยความรำคาญ + เพื่อหยุดเสียงเด้ง. โจรเข้าระบบ Uber สำเร็จ — และต่อจากนั้นเขาเดินไปทั่ว internal network. วงการเรียก attack แบบนี้ว่า MFA Fatigue — ยอมแพ้ของมนุษย์ ไม่ใช่ technology ที่พัง
scenario อีกแบบที่ระบาดในไทยช่วงนี้ — SIM swap ที่ผมกล่าวไปแล้ว. คนดังไทยหลายคนในปี 2024-2025 โดนโจรย้าย SIM แล้ว reset password ของ social account + ระบบ banking. ทุกคนเปิด MFA แต่เป็น MFA แบบ SMS — ซึ่งใช้เบอร์มือถือเป็น Have factor — และเบอร์ก็ย้ายข้าม SIM ได้
scenario ที่ 3 — Adversary-in-the-Middle (AiTM). โจรตั้งเว็บ phishing ที่หน้าตาเหมือน Microsoft 365 login. คุณกรอก password — เว็บโจรส่งต่อให้ Microsoft จริง. Microsoft ขอ MFA — เว็บโจรส่งหน้าขอ MFA ที่หน้าตาเหมือน Microsoft จริงมาให้คุณ. คุณกด Approve — เว็บโจรเก็บ session cookie ไปแล้ว. โจรไม่ต้องรู้ password คุณ ไม่ต้องรู้ MFA ของคุณ — เขามี session cookie ที่ใช้แทนคุณได้เลย. เครื่องมือชื่อ Evilginx ทำให้ attack ระดับนี้กลายเป็นเรื่องที่ script kiddie ก็ทำได้
ทั้ง 3 scenarios นี้ — มีคำตอบเดียวที่วงการกำลังเร่งผลัก — FIDO2 / Passkey — มาตรฐานใหม่ที่ Apple + Google + Microsoft ร่วมกันผลักให้แทน password ทั้งหมดในระยะยาว. Passkey กัน 3 attacks นี้ได้หมด — ผมจะเจาะใน EP.13 แบบเต็ม
สรุปแบบเก็บใส่หัว
EP.11 เก็บ 3 ข้อใส่หัวก่อนปิดครับ:
- 3 factors ของวงการคือ Know / Have / Are — แค่นี้. ทุกหลักฐานที่คุณเคยใช้ login จัดได้ใน 3 ตะกร้านี้
- MFA = ใช้ ≥2 factors คนละประเภทกัน — password + คำถามลับ ไม่ใช่ MFA (เพราะทั้งคู่คือ Know). password + Authenticator app ถึงจะนับ
- Adaptive Authentication = ระบบฉลาดเลือกความเข้มของ check ตาม context — login ปกติเวลาปกติ ผ่านง่าย. login เวลาแปลกที่แปลก ตรวจเพิ่ม
มุมผู้บริหาร: ถ้าวันนี้บริษัทคุณ — admin account ของ Microsoft 365 / Google Workspace / Salesforce / VPN ยังไม่บังคับ MFA — นั่นคือเรื่องที่จะแก้ก่อนสิ้นเดือนนี้. ไม่ใช่ก่อนสิ้นปี. การลงทุน ส่วนใหญ่ฟรี (Microsoft Authenticator + policy บน admin console). ผลตอบแทน — ลดความน่าจะเป็นถูก takeover เกือบหมด ตามตัวเลขของ Microsoft เอง. ในวงการ security ไม่มี control ตัวไหนที่ ROI สูงกว่านี้
EP.12 ผมจะกลับมาขุดเรื่อง Factor 1 (Know) ลึก ทำไม MD5 ที่ใช้กันมา 30 ปี กลายเป็นของห่วยในปี 2026? bcrypt กับ argon2 ดีกว่ายังไง? Salt กับ Pepper ที่ chef เก็บ password คืออะไร?
และ Colonial Pipeline 2021 ที่บริษัท pipeline น้ำมันใหญ่ที่สุดของอเมริกาหยุดทั้ง east coast เพราะ VPN password 1 ตัวที่ leak
เจอกัน EP หน้าครับ
