ทำไม admin คือ crown jewel — และที่บริษัทไทยพลาดบ่อยที่สุด#

ในทุกบริษัทมี account ประเภทหนึ่งที่ “ทำได้ทุกอย่าง”. ใน Active Directory เรียก Domain Admin — เปิด encrypt ทุก Windows ในบริษัทได้ในชั่วโมงเดียว. ใน Linux เรียก root — อ่าน database ของ application ทุกตัวบนเครื่องนั้นได้. ใน Microsoft Entra ID เรียก Global Administrator — reset password ของ CEO ก็ได้ ลบบัญชีของทั้งบริษัทก็ได้. ใน AWS เรียก Root Account Owner — ลบ S3 bucket ที่เก็บข้อมูลลูกค้า 10 ล้านคนได้ในคลิกเดียว

หนึ่ง admin = control เครื่องเป็นพัน. หนึ่ง root password ที่หลุด = บริษัทพังในคืนเดียว. ในวงการเรียกตำแหน่งนี้ว่า crown jewel — และเหตุผลที่ Conti, LockBit, REvil — ransomware gang ทุกตัวในยุคนี้ — เป้าหมายแรกคือ Domain Admin ทุกครั้ง. เพราะถ้าได้ Domain Admin = encrypt ทั้งบริษัทได้

ที่ทำให้ Twitter 2020 เกิดได้ ไม่ใช่เพราะ Twitter ไม่รู้เรื่องนี้. Twitter รู้. แต่ admin tool ที่เปลี่ยน email ของ Obama ได้ — พนักงาน support ระดับปกติเข้าถึงได้. ไม่ใช่แค่ 1-2 คน — เป็นหลักร้อยคน. นั่นคือ trap แรก

ที่บริษัทไทยพลาดบ่อยที่สุด — pattern คลาสสิคที่ auditor / pentester รายงานซ้ำๆ เกือบทุกครั้งเหมือนเดิม คือ password ของ admin account อยู่ใน Excel ที่ทีม IT 5 คน share กัน. password ตัวเดียว ใช้มา 4 ปี ไม่เคยเปลี่ยน. คนที่ลาออกไปเมื่อปีก่อน ในทางทฤษฎียังจำ password นั้นได้ ถ้าอยากกลับมาใช้

อีก pattern คือ standing privilege — admin คนหนึ่งเป็น Domain Admin 24 ชั่วโมงต่อวัน 365 วันต่อปี. ความจริงคือเขาใช้สิทธิ์ admin จริงๆ ประมาณ 5% ของเวลา อีก 95% เช็ค email, browse Facebook, นั่งดู YouTube. แต่ session ของเขาตลอด 95% นั้น มีสิทธิ์ Domain Admin. ถ้าเขาคลิก phishing link ตอนพักเที่ยง malware ที่รันขึ้นมา = รันด้วยสิทธิ์ Domain Admin = เกมจบในนาทีนั้น

อีกอันที่อันตรายไม่แพ้กัน — admin ทำงานจาก laptop ที่บ้าน ที่ไม่มี MFA, ไม่ patch มาครึ่งปี, ลูกเล่นเกมในเครื่องเดียวกัน. laptop นั้นเป็นประตูเข้า production. ลองนึก scenario ที่เจอได้ทั่วไป — DBA ของระบบ ERP ทำงานจาก notebook ส่วนตัวที่ลงปี 2019 + ไม่เคย restart มา 8 เดือน. ถ้าวันไหน notebook ตัวนั้นโดน malware เพราะลูกโหลด crack เกมมา ระบบ ERP ทั้งบริษัทก็จบ

นี่ไม่ใช่บริษัทที่ไม่มี security. นี่คือบริษัทที่ลงทุน Firewall + Antivirus + SIEM ครบ — แต่ลืม กุญแจหลัก

PAM — ตู้เซฟของกุญแจ admin (ไม่ใช่ list 5 ข้อ แต่เป็นวิธีคิดเดียว)#

วิธีคิดของ PAM (Privileged Access Management) สั้นๆ คือ — กุญแจของ admin ไม่ควรอยู่กับใคร. มันควรอยู่ในตู้เซฟกลาง. ใครจะใช้ — เดินไปยืม, บอกเหตุผล, มีเวลาคืน, มีกล้องบันทึก. ใช้เสร็จคืนตู้เซฟ

ที่วงการเรียกว่า JIT (Just-In-Time) = admin ไม่ใช่ admin ตลอด 24 ชั่วโมง ปกติเขาคือพนักงานธรรมดาคนหนึ่ง ตอนต้องทำงาน admin ก็เปิดระบบ PAM ระบุงานที่จะทำ (เช่น “patch Windows server, 2 ชั่วโมง”) ระบบ approve เขาก็ได้สิทธิ์ admin เฉพาะ 2 ชั่วโมงนั้น หมดเวลา = สิทธิ์หายอัตโนมัติ ไม่ต้องรอใครมา revoke ถ้าวันนั้นเขาโดน phish ตอนทาน lunch session ที่ malware รัน = session ของพนักงานธรรมดา ไม่ใช่ admin damage จำกัด

ที่วงการเรียกว่า password vault = admin ไม่รู้ password ของ admin account ที่ตัวเองใช้ vault จัดการให้ flow คือ admin login เข้า vault ด้วย credential ของตัวเอง (พร้อม MFA) vault inject password เข้า session ที่กำลังจะ connect ไป server admin ทำงาน เสร็จ vault rotate password ใหม่อัตโนมัติ admin ตัวจริงไม่เคยเห็น password ของ admin account — phishing ขโมยไม่ได้ในสิ่งที่ไม่มีคนรู้

ที่วงการเรียกว่า session recording = ทุก action ของ admin ใน window นั้นถูกบันทึกเป็น video + keystroke + command log ที่สำคัญกว่าการได้ evidence ตอนเกิดเหตุ มันคือ deterrent คนรู้ว่า session ถูกอัด = ไม่เผลอทำอะไรนอกขอบเขต

และที่ทุกบริษัทใหญ่ต้องมี — break-glass account = admin พิเศษ 1-2 ตัว ที่เก็บ password ในตู้เซฟทางกายภาพ (ตู้เหล็กจริงๆ ในห้อง CFO) ไม่ผ่าน PAM ไม่ผ่าน SSO ใช้ได้เฉพาะกรณี disaster เช่น PAM พังเอง / IdP ล่ม / ทีม IT เข้า cloud ไม่ได้ ทุกครั้งที่หยิบใช้ = alarm ส่งถึงทุกคนใน leadership ทันที + ต้องเปลี่ยน password หลังใช้

ลองย้อนกลับไป Twitter 2020 ครับ. ถ้า Twitter มี PAM ที่ทำงานจริง — admin tool ที่เปลี่ยน email ของ verified account ขนาด Obama ไม่ควรเปิดได้แค่ login. ต้องมี business reason ที่ระบุชัดเจน — ต้องมี supervisor approve ภายในกี่นาที — ต้องมี session ที่ recorded แบบ real-time + มี anomaly detection ที่จับได้ว่า “ทำไมพนักงาน support ระดับนี้กำลังเปลี่ยน email ของ Obama ตอนตี 2”. ถ้ามีสามข้อนี้ — Clark จะหลอก IT helpdesk สำเร็จ แต่ใช้ admin tool ไม่ได้

PAM ไม่ใช่ luxury ของแบงค์. บริษัทไทยขนาด 100+ คน + มี admin หลายคน + มี data ลูกค้า = ควรเริ่มมีแล้ว. ถ้างบจำกัดสุด — เริ่มที่ Microsoft Entra ID Privileged Identity Management (PIM) ที่ติดมาใน license Microsoft 365 E5 หรือ E3 + add-on. เปิด policy เดียว — “admin role ทุกตัวต้อง activate on-demand + ต้องระบุเหตุผล + auto-expire ใน 4 ชั่วโมง” — ลดความเสี่ยง standing privilege ลงครึ่งหนึ่งในวันเดียว ไม่ต้องลงทุนใหม่

มุมผู้บริหาร: สามคำถามที่ผู้บริหารควรถามทีม IT สัปดาห์นี้ — (1) admin account ของเราใช้ shared password ในไฟล์ Excel ไหม? (2) session ของ admin ตอนทำงาน production ถูก record ไหม? (3) admin ของเรา “เป็น admin 24 ชั่วโมง” หรือ activate ตอนใช้?. ถ้าคำตอบสามข้อนี้ตอบไม่ได้หรือตอบว่า “ไม่” — Twitter 2020 ของบริษัทคุณรอเกิดอยู่ ไม่ใช่คำถามว่า “จะเกิดไหม” แต่เป็น “เมื่อไหร่”

Zero Trust — เมื่อ “ในกำแพง” หายไปแล้ว#

ทีนี้ขยับกล้องออกไปไกลกว่า admin account ครับ. PAM ปกป้องกุญแจหลัก. แต่ภาพใหญ่กว่านั้น — ทั้งบริษัทออกแบบ network ยังไงในยุคที่ไม่มี “ข้างใน” กับ “ข้างนอก” อีกแล้ว?

โลก network security ตั้งแต่ปี 1980s ถึง 2010s เดินอยู่บน mental model เดียว — Castle-and-Moat. ปราสาทมีกำแพง (firewall) ล้อมรอบ + คูน้ำ (DMZ) คั่นกลาง + ประตูใหญ่ (VPN) ที่ตรวจคนเข้า. ข้างในปราสาท — ทุกคนเชื่อใจกัน เพราะผ่านประตูเข้ามาแล้ว. ในแบบของ enterprise model นี้แปลว่า — service ใน network เดียวกันคุยกันได้ฟรี ไม่ต้อง authenticate ทุกครั้ง. คนที่ผ่าน VPN เข้ามา = “กลายเป็น insider” = ใช้ระบบในได้เหมือนนั่งในออฟฟิศ

แล้วโลกเปลี่ยน. ปี 2010s cloud มา — Salesforce, Microsoft 365, Slack, AWS — application ไม่อยู่ใน data center ของบริษัทอีกแล้ว. มือถือมา — พนักงานใช้มือถือส่วนตัวเช็ค email บริษัท ในร้าน Starbucks, ในรถไฟฟ้า, ที่บ้านพ่อแม่ต่างจังหวัด. โควิด 2020 มา — ทั้งโลก work from home ในสองสัปดาห์, VPN ทุกบริษัทพังเพราะคนเข้าพร้อมกัน. supply chain attack มา — SolarWinds 2020 = vendor ที่ trust ของบริษัทตัวเองถูก hack แล้วใช้สถานะ “trusted vendor” เข้าเครือข่ายลูกค้าได้

ผลที่ตามมาคือ เส้นแบ่ง “ข้างใน vs ข้างนอก” หายไป. โจรเก่งๆ ในยุคนี้ไม่เจาะกำแพง — เขา phish พนักงาน 1 คน → กลายเป็น insider → เดินอย่าง trusted user ใน network → ขโมยทุกอย่าง. Castle-and-Moat ตอบ scenario นี้ไม่ได้ เพราะ model นี้เชื่อว่า “ในกำแพง = ปลอดภัย”

เรื่องที่เปลี่ยนวงการคือเรื่องของ Google. ปลายปี 2009 Google ค้นพบว่าโดน hack หนัก — กลุ่ม APT จากจีน (Operation Aurora) เจาะเข้า internal network ของ Google ผ่าน 0-day ของ Internet Explorer + spear phishing พนักงาน. โจร lateral movement ใน Google network ในฐานะ “trusted user” — เข้าถึง source code ของ Google + ข้อมูล Gmail ของ activist สิทธิมนุษยชน

Google เปิดเผยเหตุการณ์ในเดือนมกราคม 2010 — แต่สิ่งที่สำคัญกว่าคือ คำถามที่ทีม security ของ Google ตั้งหลังเหตุการณ์ — “ถ้า internal network ของเราถูก compromise อยู่แล้ว — เราจะออกแบบให้ application ปลอดภัยได้ยังไง?”. 5 ปีต่อมา — ปี 2014 — Google ตอบคำถามนี้ผ่าน whitepaper ชื่อ BeyondCorp. หลักการสรุปเป็นประโยคเดียว: Never trust, always verify

ไม่มี trusted network อีกแล้ว. network ในออฟฟิศ Google = ไม่ปลอดภัยเท่า Starbucks WiFi. ทุก request — ทั้งจาก laptop ในออฟฟิศและจากบ้าน — ต้อง authenticate + authorize ใหม่ทุกครั้ง. ไม่ใช่แค่ user — device ที่ใช้ก็ต้องตรวจด้วย (corporate-managed, patch แล้ว, มี endpoint protection). VPN ของ Google ภายในส่วนใหญ่ — ยกเลิก. แทนด้วย access proxy ที่ตรวจทุก request ตัวต่อตัว

นี่คือ Zero Trust ในรูปสมบูรณ์ครั้งแรก. หลายปีต่อมา NIST ออก 800-207 Zero Trust Architecture ในปี 2020 — เป็น standard ของรัฐบาลสหรัฐ — และทุก vendor security ในโลกเริ่ม package solution ของตัวเองในชื่อนี้

ทางปฏิบัติของบริษัทไทย — Zero Trust ไม่ใช่ product ที่ซื้อแล้วเสร็จ. มันคือ mindset ที่เปิดทีละ control. ที่เริ่มได้ในงบจำกัดสุด ถ้าบริษัทใช้ Microsoft 365 อยู่แล้ว — เปิด Conditional Access ของ Entra ID — เป็น engine ที่ตัดสินทุกครั้งที่ user พยายาม login ว่า “user นี้ + device นี้ + ที่นี่ + เวลานี้ + risk score เท่านี้ = allow / require MFA / block”. policy แรกที่ทำได้ในวันเดียว — “ทุก login จากนอก Thailand = block” + “ทุก admin role = ต้องผ่าน Passkey + ใช้ corporate device เท่านั้น”. เปิดแค่ 2 policy นี้ = ปิด attack surface ของบริษัท 80%

ที่ Twitter 2020 ตอบเรื่องนี้ไม่ได้ในวันนั้น — admin tool ของ Twitter ไม่มี device check, ไม่มี risk-based MFA, ไม่มี Conditional Access ที่ตรวจ context. พนักงานคนเดียวที่ถูก phish — credential ใช้ได้จากเครื่องไหน + เวลาไหน + IP ของประเทศไหนก็ได้. นี่คือ Castle-and-Moat ในยุคที่ไม่ควรมี Castle-and-Moat แล้ว

ปิด Part 2 — Identity คือ perimeter ใหม่#

ครับ — EP.17 จบ. Part 2 จบ. 8 EPs ที่เดินมาด้วยกัน (EP.10-17) — ผมขอให้คุณถือสรุปสั้นๆ ในใจกลับไป:

EP.10 เล่าเรื่อง lifecycle — ใครเข้า, ใครย้าย, ใครออก. EP.11 เล่าเรื่อง 3 factors — Know / Have / Are. EP.12 เล่าเรื่อง password — ทำไม MD5 ห่วย ทำไม bcrypt ดี. EP.13 เล่าเรื่อง MFA 5 ระดับ — และทำไม Passkey คือยอด. EP.14 เล่าเรื่อง Kerberos — ระบบ check-in โรงแรมของ Microsoft. EP.15 เล่าเรื่อง SSO — passport ดิจิทัล. EP.16 เล่าเรื่อง authorization — บัตรนี้เข้าห้องไหนได้บ้าง. EP.17 เล่าเรื่อง PAM + Zero Trust — ตู้เซฟกุญแจหลัก + ตำรวจตรวจทุกประตู

ทั้ง 8 EPs ตอบคำถามเดียว — “คนนี้คือใคร + เขาทำสิ่งนี้ได้ไหม”. และถ้าผมต้องสรุป Part 2 เป็นประโยคเดียว — มันคือประโยคนี้ครับ:

Identity คือ perimeter ใหม่. ไม่ใช่ firewall, ไม่ใช่ network — Identity.

ในยุค Castle-and-Moat — perimeter คือกำแพง. ในยุค cloud + remote work + supply chain — กำแพงไม่มีอีกแล้ว. สิ่งเดียวที่ยังตามคนได้ทุกที่ — laptop ในบ้าน, มือถือบนรถไฟฟ้า, browser ในร้าน Starbucks ที่ Bangkok หรือ Tokyo — คือ ตัวตน. ตัวตนที่ verify ทุกครั้ง + พ่วงกับ device + พ่วงกับ context + พ่วงกับ risk = perimeter ของยุคนี้

Twitter 2020 เกิดได้ — เพราะ Twitter ลงทุนใน Castle-and-Moat (firewall, network, VPN) ครบ — แต่ admin tool ที่ทำได้ทุกอย่าง ไม่มี identity perimeter ที่หนักพอ. คน 1 คนถูก phish + ไม่มี PAM + ไม่มี Conditional Access = Obama, Elon, Bill Gates ทวีตพร้อมกัน

ทุกบริษัทบนโลกในปี 2026 มี Twitter 2020 ของตัวเองรอเกิดอยู่ — ถ้า admin account ของบริษัทคุณ ตอนนี้ ไม่มี PAM + ไม่มี JIT + ไม่มี Conditional Access. คำถามไม่ใช่ “บริษัทเราพอใหญ่ที่จะโดนหรือยัง” — คำถามคือ “ระบบ admin ของเรารอวันที่ social engineer คนเดียวจะมาทดสอบหรือเปล่า”

มุมผู้บริหาร: ถ้าคุณเดินกลับโต๊ะวันนี้ แล้วลงทุนได้อย่างเดียวจาก Part 2 ทั้งหมด — ผมเสนอข้อนี้ครับ: ขอ list จากทีม IT ภายในสัปดาห์นี้ ของทุก admin account ในบริษัท (Domain Admin / Global Admin / DBA / root / Cloud Owner / SaaS admin). นับว่ามีกี่ตัว ถือโดยกี่คน. ถ้าตัวเลขเกิน 20 บัญชี หรือคนถือเกิน 10 — เริ่มที่นี่. ลด, แยก, ใส่ PAM. อันเดียวที่ Twitter 2020 สอนชัดเจน = ไม่ใช่ทุกคนต้องเป็น admin ตลอดเวลา. ไม่มีใครต้องเป็น admin ตลอดเวลา

Part 3 — จาก “กุญแจ” สู่ “ของในเซฟ”#

Part 2 ปกป้องคน. Part 3 ปกป้องของ

ผมจบ EP.17 ด้วยภาพนี้ — สมมุติว่าทุก control ของ Part 2 พังหมดในคืนวันหนึ่ง. attacker login ในฐานะ Domain Admin. เปิดประตูห้อง database. ดูสิ่งที่อยู่ในเซฟ

คำถามคือ — สิ่งที่อยู่ในเซฟ เป็น plain text ที่อ่านได้ทันที? หรือเป็น ciphertext ที่อ่านไม่ออกถ้าไม่มี key?

นี่คือคำถามของ Part 3. EP.18 ถัดไป — Data Classification + Data Lifecycle — เริ่มที่ “ของในเซฟมีกี่ระดับ + อายุของมันเป็นยังไง”. จากนั้น EP.19-22 — cryptography, symmetric, asymmetric, hashing — วิธีหุ้มห่อของให้อ่านไม่ออก. EP.23 — DLP — วิธีกันของไม่ให้เดินออกจากเซฟ

ทุกบริษัทบนโลกในปี 2026 — มีข้อมูลที่เป็น crown jewel. ข้อมูลลูกค้า, ข้อมูลพนักงาน, source code, financial data, trade secret. ถ้า identity พังในวันที่ data หุ้มห่อดี — ยังกู้ได้. ถ้า identity ดีในวันที่ data ไม่หุ้มห่อ — วันที่ identity พังคือวันที่ทุกอย่างหลุด

ขอบคุณที่เดินมาด้วยกันใน Part 2 ครับ — 8 EPs ที่ลึกที่สุดของเรื่อง identity ในวงการ. ผมหวังว่าคุณจะหยิบของชิ้นหนึ่งจาก EP.17 ไปใช้ในบริษัทคุณตั้งแต่สัปดาห์นี้ — list admin account, เริ่มที่ PIM, เปิด Conditional Access policy แรก. แค่ของเล็กๆ ในสัปดาห์นี้ — ลด risk ของ Twitter 2020 ในบริษัทคุณลง 80%

→ EP.18 — Data Classification + Data Lifecycle: ของในเซฟมีกี่ระดับ