ทำไม 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 แรก

ที่บริษัทไทยพลาดบ่อยที่สุด — และผมเจอซ้ำๆ ในงาน audit หลายปีมานี้ — เกือบทุกครั้ง pattern เดียวกัน. 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. ผมเคยเจอบริษัทที่ 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: ของในเซฟมีกี่ระดับ (เร็วๆ นี้)