ฉากเปิด: 15 record ที่หายไปจากระบบตรวจคุณภาพ#

ลองนึก scenario นี้ครับ โรงงานผลิตชิ้นส่วนรถยนต์แห่งหนึ่ง กระบวนการตรวจคุณภาพปกติคือเครื่องวัดที่หน้าไลน์ผลิตจะส่งผลตรวจเข้า application แล้ว application เก็บลง table ชื่อ quality_test_results ใน database ทุก record มี field ชื่อ status ถ้า “PASS” ของไปต่อสายส่งออก ถ้า “FAIL” ของถูกแยกออกไปทำลาย

วันหนึ่งมี order ใหญ่ที่ต้องส่งภายใน 3 วัน กลายเป็นว่ามีของ 15 ชิ้นที่ status = “FAIL” จากการตรวจ ถ้าทำลายของ 15 ชิ้นนั้นก็ส่งไม่ทัน โดนปรับสัญญาเป็นล้านบาท

ผู้จัดการสายผลิตโทรหา DBA คุยกัน 5 นาที DBA เปิด terminal เข้า production database ตรงๆ เลย เพราะเขามีสิทธิ์ แล้วรัน query หนึ่งบรรทัด

1
UPDATE quality_test_results
2
SET status = 'PASS'
3
WHERE order_id = 4823 AND status = 'FAIL';
4
-- 15 rows updated

15 record เปลี่ยนจาก “ไม่ผ่าน” เป็น “ผ่าน” ของถูกบรรจุ ส่งออก ถึงมือลูกค้า

3 เดือนต่อมา ลูกค้ารายงานปัญหาในรถ โรงงานเปิด investigation ทีมเปิด application log ของระบบตรวจคุณภาพเพื่อดูว่า “เกิดอะไรขึ้นกับ order 4823” ปรากฏว่า application log บอกว่า ทุก record ผ่านการตรวจปกติ ไม่มีอะไรผิดปกติ เพราะการเปลี่ยนค่าครั้งนั้น ไม่ผ่าน application มันเข้าตรงที่ database

ในมุมของ application ของชุดนั้นผ่านตามมาตรฐาน ในมุมของ business มีคนเสี่ยงตายเพราะของชุดนั้น ในมุมของ control มี 0 control ที่ catch การกระทำนี้ได้ เพราะคนที่ทำคือคนที่มีกุญแจทุกดอก และเครื่องมือที่ catch ปกติ (application log) ก็ไม่ได้บันทึกการกระทำของเขา

นี่คือสิ่งที่วงการเรียกว่า DBA Bypass และเป็นจุดเริ่มต้นของทุกเรื่องที่ EP.13 จะคุย

DBA คือใคร — และเขาทำอะไรได้บ้าง#

DBA ย่อมาจาก Database Administrator คือคนที่ดูแล database ของบริษัทตั้งแต่ติดตั้ง configure ดูแลให้ทำงาน optimize backup restore จัดสิทธิ์ user

ในบริษัทใหญ่ DBA จะแบ่งเป็น 3 ประเภทตามหน้าที่

Operational DBA คนที่ดูแลให้ database ทำงานได้ทุกวัน Backup รายวัน monitor performance แก้ปัญหาตอน server ช้า อัปเดต patch งานคือ “อย่าให้ database ล่ม”

Development DBA คนที่ทำงานกับทีม developer ออกแบบ schema, optimize query ที่ช้า, ช่วย dev คิดว่าจะเก็บ data ยังไงให้ scale งานคือ “อย่าให้ application ออกแบบ database ผิดตั้งแต่แรก”

Security DBA คนที่จัด access control ทำ audit ดู compliance งานคือ “ใครเข้าถึง data อะไร และมีหลักฐานหรือเปล่า” ในบริษัทเล็กๆ บทบาทนี้มักไม่มี Operational DBA คนเดียวกันทำหมด ซึ่งเป็นปัญหาที่จะคุยทีหลังในส่วน SoD

ทั้ง 3 ประเภท สิทธิ์ที่ถืออยู่ในมือเหมือนกันหมดในแง่เทคนิค คือ

• CRUD ทุก table — Create, Read, Update, Delete ข้อมูลใน table ใดก็ได้
• DDL (Data Definition Language) — CREATE, ALTER, DROP table ทั้ง table ก็ได้
• GRANT — ให้สิทธิ์ user คนอื่น (รวมถึงให้สิทธิ์ระดับ DBA กับคนอื่นได้)
• Backup / Restore — สำเนา database ทั้งก้อนออกไปได้ restore ทับของเดิมได้
• Read all logs — อ่าน log ของระบบได้ (รวมถึง log ของตัวเอง ถ้าไม่มี control พิเศษ)

ใน CISA D4.37 — Database Management ผมเปรียบ DBA ไว้ว่าเป็น บรรณารักษ์ใหญ่ที่มีกุญแจทุกห้อง เปิดได้ ปิดได้ เพิ่มหนังสือได้ ลบหนังสือได้ และที่สำคัญที่สุด แก้สมุดประวัติของหนังสือได้ด้วย ภาพนี้ตรงกับ scenario โรงงานข้างบนเป๊ะๆ ผลตรวจคุณภาพคือ “สมุดประวัติ” ของชิ้นส่วน DBA แก้ค่าใน “สมุดประวัติ” ได้ตรงๆ โดยไม่ต้องผ่านระบบที่ออก “สมุดประวัติ” นั้น

แล้วทำไมการ “เข้าตรง DB” ถึงเป็นเรื่องใหญ่ เรื่องนั้นคือหัวใจของ EP

DBA Bypass Risk — ทำไมเข้าตรง DB = ไม่ผ่าน business rule#

เพื่อให้เห็นภาพชัด ลองเปรียบ flow ปกติของ user กับ flow ของ DBA

flow ปกติของ user ในระบบ:

1
user → application → business rule → database → application log

user (เช่น พนักงาน QC ที่กรอกผลตรวจ) ทำงานผ่าน application application มี business rule อยู่ในตัว เช่น “ค่า status = FAIL ห้ามแก้กลับเป็น PASS เด็ดขาด” หรือ “ถ้าจะ override ผลตรวจ ต้องมี approval จากหัวหน้าแผนก” application รับ input → เช็ค rule → ถ้าผ่านจึงเขียนลง database แล้วบันทึก log ของการกระทำนี้ไว้ใน application log

flow ของ DBA:

1
DBA → database (ตรง) → ❌ ไม่ผ่าน business rule → ❌ ไม่มี application log

DBA เปิด terminal connect เข้า database ตรง รัน SQL ที่อยากรัน ไม่ผ่าน application เลย control ที่ขาดไปทันทีคือ

• Validation rule ของ application — rule “FAIL ห้ามกลับเป็น PASS” ถูก bypass เพราะ rule อยู่ใน application code ไม่ได้อยู่ใน database
• Workflow approval — เช่น “เปลี่ยนเงินเดือนพนักงานต้องผ่าน HR approve” ถูก bypass เพราะ workflow อยู่ใน HR application
• Audit trail ที่ application เก็บ — application log ที่บันทึก “ใครทำอะไร เมื่อไหร่ จากหน้าจอไหน” ไม่ได้ถูกเขียน เพราะการกระทำไม่ผ่าน application

ในเชิง audit นี่คือเหตุผลที่ ISACA สอนแยกระหว่าง application control กับ database control ชัดเจน และทำไม IS auditor ต้องตรวจ database log แยกจาก application log เสมอ

ใน CyberSecurity Foundation EP.17 — PAM + Zero Trust เล่าเรื่อง crown jewel — account ที่ “ทำได้ทุกอย่าง” DBA account คือ crown jewel ของฝั่ง data layer และ control ที่ EP.17 พูดถึงในเชิง infrastructure (PAM, Zero Trust) ทั้งหมดต้องใช้กับ DBA ด้วย

ทีนี้มาดูเครื่องมือที่บริษัทใหญ่ใช้คุม DBA ทีละชิ้น

PAM (Privileged Access Management) — ตู้เซฟของกุญแจ admin#

แนวคิดของ PAM ง่ายๆ ครับ — DBA ไม่ควรรู้ root password ของ database ตรงๆ

เดิมทีโลกเป็นแบบนี้ DBA แต่ละคนมี password ของ database server เก็บไว้ในเครื่องตัวเอง (หรือใน password manager ส่วนตัว) ปัญหาคือ ถ้า DBA ลาออก ใครเปลี่ยน password ทุกตัวที่เขาเคยรู้? ถ้าโน้ตบุ๊กของ DBA ถูกขโมย password นั้นไปอยู่ในมือใคร? ถ้า DBA share password ให้คนอื่น “ขอใช้ชั่วคราว” ใครติดตามได้?

PAM แก้ปัญหานี้ด้วยการตั้ง ตู้เซฟกลาง ของ password

flow ใหม่กลายเป็นแบบนี้ DBA ที่อยากเข้า database แทนที่จะเปิด terminal กรอก password ที่ตัวเองรู้ เขา login เข้า PAM tool ก่อน → request access ไปยัง database server X → ระบบออก temporary credential (password ชั่วคราวที่หมดอายุใน 8 ชั่วโมง) → DBA ใช้ credential นั้นเข้า database พอหมดเวลา credential ก็ใช้ไม่ได้อีก ต้องขอใหม่

ที่สำคัญกว่านั้นคือ ทุก action ที่ผ่าน PAM ถูก log + recorded ไว้นอก reach ของ DBA ใครขออะไร เมื่อไหร่ ใช้กี่นาที ทำอะไรในนั้นบ้าง ทั้งหมดเก็บไว้ในระบบกลาง

tool ที่ตลาดใช้กัน — CyberArk (ตัวใหญ่สุดในตลาด enterprise), BeyondTrust, HashiCorp Vault (ฝั่ง open source / cloud-native), Teleport (modern alternative ที่นิยมในวงการ DevOps)

PAM ลึกกว่านี้เยอะ EP.17 ของซีรีส์ CyberSecurity Foundation อธิบายไว้ละเอียดกว่าตรงนี้มาก แนะนำให้อ่านควบคู่กันครับ

มุมผู้บริหาร: ถ้า DBA ของคุณยังจำ root password ของ production database ได้เป็นตัวๆ แปลว่าบริษัทคุณยังไม่มี PAM และถ้า DBA ลาออกพรุ่งนี้ ทีมที่เหลือต้องไล่เปลี่ยน password ของทุก server ที่เขาเคยเข้าได้ภายในวันเดียว ไม่งั้น account เก่าของเขาก็ยังเปิดประตูได้อยู่

Session Recording — บันทึกทุก SQL ที่ DBA รัน#

PAM คุมว่า “ใครได้กุญแจไปตอนไหน” Session Recording คุมว่า “ตอนถือกุญแจ เขาทำอะไรบ้างในห้องนั้น”

แนวคิดคือ ทุก session ที่ DBA เปิดเข้า production database ทุก SQL command ถูกบันทึก เป็น log + บางระบบบันทึกเป็นวิดีโอของหน้าจอ replay ได้ ถ้าเกิด incident ขึ้น (เช่น มี record หายไป 15 record) ทีม security เปิด session recording ของ DBA ทุกคนในช่วงเวลานั้น แล้วไล่ดูได้ว่าใครรัน SQL อะไร เมื่อไหร่

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

ทำไมเรื่องนี้สำคัญ — เพราะมันคือ forensic capability ในวันที่ทุกอย่างเรียบร้อย session recording ดูเหมือนเสีย budget เปล่า แต่ในวันที่เกิด data breach หรือ fraud ขึ้น มันคือสิ่งเดียวที่ตอบได้ว่า “เกิดอะไรขึ้น ใครทำ”

ที่ต้องระวังคือ scope session recording ควรครอบคลุมแค่ production system + critical database ไม่ใช่ dev machine ส่วนตัวของ DBA ทุกเครื่อง เกินขอบเขตเมื่อไหร่ มันเริ่มกลายเป็นเรื่อง surveillance พนักงาน ซึ่งมีปัญหาทั้งกฎหมาย (PDPA) และวัฒนธรรมองค์กร

มุมผู้บริหาร: ถามทีม IT คำถามเดียว “ถ้ามีคนรัน DELETE FROM customers WHERE 1=1 ใน production คืนนี้ พรุ่งนี้เช้าเรารู้ได้ไหมว่าใครทำ และเอา query ที่เขารันมาดูเป็นบรรทัดๆ ได้ไหม” ถ้าคำตอบคือ “ไม่” แปลว่าขาด session recording

Just-In-Time (JIT) Access — DBA ขอสิทธิ์ตอนต้องการใช้#

นี่เป็นแนวคิดที่บริษัท modern ทุกที่กำลังย้ายไปใช้ และมันเปลี่ยน mindset ของการให้สิทธิ์ทั้งหมด

โลกเก่า — Standing Access: DBA มีสิทธิ์เข้า production database ตลอดเวลา 24 ชม. login ได้ทุกเมื่อ ใช้ได้เลย สะดวกในแง่ทำงาน ปัญหาเกิดตอนตี 3 ก็เข้าไปแก้ได้ทันที

ปัญหาของ standing access คือ attack surface ใหญ่ตลอดเวลา ถ้า account ของ DBA ถูก compromise ตอนตี 3 (เช่น phishing สำเร็จ หรือ laptop ถูกขโมย) ผู้โจมตีมี access ใช้ได้ทันทีเพราะ account นั้น “เปิดอยู่เสมอ”

โลกใหม่ — JIT Access: DBA ไม่มีสิทธิ์ standing เลย เวลาต้องการเข้า production ต้อง submit request → ระบุเหตุผล + ระยะเวลาที่ต้องใช้ → approver (อีกคนหนึ่ง ไม่ใช่ตัวเอง) approve → access window เปิด 4 ชั่วโมง → หมดเวลา auto-revoke

flow แบบนี้ทำให้ตอนที่ account DBA “ไม่ได้ใช้งาน” สิทธิ์ของมัน effectively = 0 โจรที่ขโมย credential ไปตอน 3am ก็ใช้อะไรไม่ได้ เพราะไม่มีอะไรให้ใช้

tool ที่นิยม — AWS IAM Identity Center (สำหรับ AWS workload), Azure PIM (Privileged Identity Management สำหรับ Microsoft stack), Teleport (cross-platform), HashiCorp Boundary

ที่ต้อง balance คือ friction กับ security ถ้า approval ใช้เวลา 2 ชั่วโมง ตอน production พังไม่มีใครรอได้ ระบบ JIT ที่ดีต้องมี break-glass account สำหรับ emergency (account พิเศษที่ใช้ได้ทันทีในกรณีฉุกเฉิน แต่การใช้แต่ละครั้งจะ trigger alert ไปหา CIO + security team ทันที)

มุมผู้บริหาร: ถามตัวเอง “ตอนนี้ตี 3 ถ้า account DBA ของบริษัทผม leak ไปอยู่ในมือ hacker ภายในกี่นาทีเขาจะเข้า production database ได้” ถ้าคำตอบคือ “ทันที” บริษัทยังเป็น standing access ถ้าคำตอบคือ “เขาเข้าไม่ได้ ต้องรอจนกว่าจะมีคน approve request” แปลว่าเป็น JIT แล้ว

Separation of Duties (SoD) — DBA production ≠ DBA log#

นี่คือ principle ที่ผู้บริหารฝั่งบัญชีน่าจะคุ้นที่สุด เพราะมันคือเรื่องเดียวกับที่ accountant กับ approver ในระบบจ่ายเงินต้องเป็นคนละคน

หลักการคือ คนที่มีอำนาจทำ action ≠ คนที่ตรวจ action ถ้าคนเดียวกันถือทั้ง 2 หน้าที่ เขาสามารถทำผิดแล้วลบหลักฐานของตัวเองได้

ในบริบท database ถ้า DBA คนเดียวกัน admin production database + admin log server เขาสามารถ

1. รัน SQL ที่ไม่ควรรันใน production
2. เปิด log server ของตัวเอง ลบ entry ที่บันทึกการกระทำนั้นทิ้ง
3. ในบันทึกของระบบ ไม่มีอะไรเกิดขึ้น

implementation ที่ถูกต้องคือ production DBA team กับ security/audit team ต้องเป็นคนละทีม รายงานไปคนละสายบังคับบัญชา

เคสที่เจอบ่อยในวงการคือบริษัทขนาดเล็ก-กลางที่ทีม IT มี 3 คนทำทุกอย่าง คนเดียวคือทั้ง sysadmin, DBA, network admin, security admin SoD พังตั้งแต่วันแรกเพราะ ไม่มีจำนวนคนพอจะแบ่งหน้าที่

ทางออกในกรณีนี้คือ third-party log destination แทนที่จะเก็บ log ใน server เดียวกับที่ DBA admin ก็ส่ง log ออกไปนอกระบบเลย ไป SIEM (Security Information and Event Management) อย่าง Splunk, Elastic Stack, Datadog, หรือ cloud service อย่าง AWS CloudWatch / Google Cloud Logging ที่ DBA “touch ไม่ได้” ต่อให้ทีม IT เล็กแค่ไหน ถ้า log ไปอยู่นอก reach ของคนที่ admin database ก็ยังมี SoD ในระดับเครื่องมือ

(เรื่อง log management ลึกกว่านี้อยู่ใน CISA D4.36 — Log Management ของซีรีส์ CISA สำหรับใครที่อยากเจาะ)

มุมผู้บริหาร: ถ้าทีม IT บอกว่า “เรามีคนน้อย แบ่งหน้าที่ไม่ได้” คำตอบไม่ใช่ “งั้นช่างมัน” คำตอบคือ “เอา log ออกไปอยู่นอก reach ของทีม” ราคาของ SIEM cloud service ถูกกว่า cost ของ undetected fraud มากมาย

Periodic Access Review — ตรวจสิทธิ์ทุกไตรมาส#

ทุก control ข้างบนสร้างไว้สำหรับ “วันแรก” คือวันที่ DBA เข้าทำงาน ตั้งสิทธิ์ให้ configure PAM/JIT Periodic Access Review คือ control สำหรับ “วันที่ 100, 365, 1095” เพราะคนเปลี่ยนทีม คนลาออก คนได้ promotion สิทธิ์ที่เคยเหมาะสมเมื่อ 1 ปีที่แล้ว อาจไม่เหมาะสมแล้ววันนี้

หลักการคือทุก 3 เดือน (หรืออย่างน้อยปีละครั้งสำหรับสิทธิ์ระดับสูง) เจ้าของระบบ + security team ทบทวนว่า

• ใครมีสิทธิ์อะไร ใน database ตัวไหน
• คนนั้นยัง active อยู่ไหม (ลาออกแล้ว? ย้ายแผนกแล้ว?)
• สิทธิ์ที่มีอยู่ “ใช้จริงหรือเปล่า” ในรอบ 90 วันที่ผ่านมา
• revoke สิทธิ์ของคนที่ “ไม่ใช้แล้ว” / “ย้ายแผนกแล้ว” / “ออกแล้ว”

มาตรฐาน compliance ทุกตัว require อันนี้ — SOX (สำหรับบริษัทใน US ที่จดทะเบียน), ISO 27001, PDPA / GDPR สำหรับ data ส่วนบุคคล

ปัญหาที่เห็นบ่อยในวงการคือ review กลายเป็น checkbox exercise ทีม security ส่ง spreadsheet 200 บรรทัดให้หัวหน้าแผนก หัวหน้าแผนกไล่กดคำว่า “approve” ทุกบรรทัดในเวลา 5 นาที แล้วส่งกลับ compliance ผ่าน แต่ไม่มีใครได้ตรวจอะไรจริงๆ

วิธีทำให้ meaningful

1. แสดง “last used” — แต่ละ access record มี timestamp ของการใช้งานครั้งล่าสุด สิทธิ์ที่ไม่ได้ใช้ในรอบ 180 วัน → flag ให้ระบุเหตุผลถ้าจะคงไว้
2. แสดง “what changed” — ใน review ครั้งนี้ มีอะไรเพิ่มหรือลดจาก review ครั้งก่อน focus ไปที่ delta ไม่ใช่อ่านทั้ง list
3. owner accountability — หัวหน้าที่กด approve ลวกๆ ต้องรับผิดถ้าเกิด incident ที่เกี่ยวข้องกับสิทธิ์ที่เขา approve

มุมผู้บริหาร: ถามว่า “review สิทธิ์ DBA ครั้งล่าสุดเมื่อไหร่ และคนกี่คนถูก revoke จาก review รอบนั้น” ถ้าคำตอบคือ “0 คน” ติดต่อกัน 4 รอบ review นั้นอาจจะไม่ใช่ review จริง

Audit Log Tampering — ป้องกัน DBA ลบหลักฐานของตัวเอง#

ใน scenario โรงงานเปิดเรื่อง สมมติบริษัทนั้นมี database log ที่บันทึก SQL ทุก command ไว้ แต่ถ้า log นั้นเก็บไว้ใน server เดียวกัน กับที่ DBA admin DBA ก็สามารถเปิด log table แล้ว DELETE entry ที่บันทึกการ UPDATE ของตัวเองได้

นี่คือ Audit Log Tampering Risk และมันเป็นเหตุผลที่ control เรื่อง log ต้องคิดในระดับ architecture ไม่ใช่แค่ feature

3 layer ของ defense

1. External log shipping — ส่ง log ออกไปยัง destination ที่ DBA ไม่มีสิทธิ์เลย ใช้ Splunk, Elastic Stack (ELK), AWS CloudWatch, Google Cloud Logging, Datadog log ออกไปแล้วไปเลย ไม่กลับมาให้ลบ

2. Immutable / WORM storage — WORM ย่อมาจาก Write Once, Read Many log ที่เขียนเข้า storage ประเภทนี้เขียนได้ครั้งเดียว อ่านได้ตลอด แก้ไม่ได้ ลบไม่ได้ แม้แต่ admin ของระบบ AWS S3 Object Lock, Azure Immutable Blob Storage เป็นตัวอย่าง

3. Chain of custody — แต่ละ log entry ผูกกับ entry ก่อนหน้าด้วย hash (เหมือน blockchain) ถ้ามีคนแก้ entry ใดเข้าไป hash ของ entry ถัดๆ ไปจะเพี้ยนทั้งสาย forensic team จับได้ว่ามีการแก้ ถึงแม้จะไม่รู้ว่าค่าเดิมเป็นอะไร

ใน CyberSecurity Foundation EP.17 — PAM + Zero Trust เล่าเรื่อง “trust แต่ verify” และ verify จะใช้ได้ก็ต่อเมื่อ หลักฐานที่ใช้ verify อยู่นอก reach ของคนที่ถูก verify

มุมผู้บริหาร: ถาม CIO “log ของ DBA action เก็บที่ไหน และ DBA delete log นั้นได้ไหม” ถ้าคำตอบคือ “เก็บใน database server เดียวกับที่ DBA admin” — log นั้น effectively = 0 ในมุม forensic

Cloud DBA Era — บทบาทเปลี่ยน แต่ไม่หายไป#

มีคำถามที่ผู้บริหารถามบ่อยตอนนี้ “ในยุค cloud + serverless database (Supabase, Neon, RDS) ที่ vendor ดูแลให้หมด เรายังต้องมี DBA ไหม”

คำตอบคือ บทบาทเปลี่ยน แต่ไม่หายไป

เดิม Operational DBA ทำงานหนักมาก patch OS, patch database engine, ทำ backup, restore, replication, failover ในยุค serverless DB งานพวกนี้ vendor ทำให้เกือบหมด ดังนั้น Operational DBA ที่ “ดูแล server ให้ทำงาน” ลดบทบาทลงจริง

แต่อีก 2 บทบาทยังมีอยู่เต็มที่ และอาจจะสำคัญกว่าเดิม

Data DBA คนที่เข้าใจว่า business data ของบริษัทเก็บอย่างไร schema ออกแบบยังไงให้ scale query ตัวไหนช้าและทำไม จะ migrate อย่างไรเมื่อ business เปลี่ยน งานนี้ยังอยู่กับมนุษย์ ไม่มี vendor ทำให้

Security DBA คนที่จัด IAM (ใครเข้าถึงอะไรได้บ้าง), encryption (data at rest, data in transit), audit, compliance ใน cloud vendor ดู infrastructure ให้ แต่ customer ดู configuration เอง ตั้ง IAM permission ผิด → data ของลูกค้า leak ออก S3 bucket public ได้ในคลิกเดียว

นี่คือสิ่งที่วงการเรียกว่า Shared Responsibility Model vendor รับผิดชอบ “security of the cloud” (infrastructure ที่ระบบรันอยู่) customer รับผิดชอบ “security in the cloud” (configuration, IAM, schema, access control) หลายบริษัทเข้าใจผิดว่า “ขึ้น cloud = vendor ดูแลทุกอย่าง” แล้วเจอ data breach ที่เกิดจาก misconfiguration ของฝั่งตัวเอง

(เรื่อง shared responsibility ลึกกว่านี้อยู่ใน CyberSec Foundation EP.32 — Cloud + Shared Responsibility)

มุมผู้บริหาร: ขึ้น cloud ไม่ได้แปลว่า “ลด headcount DBA” มันแปลว่า “DBA เปลี่ยนจากคน patch server เป็นคนออกแบบ data architecture + คุม access control” ตำแหน่งเดิม รับผิดชอบใหม่

มุมผู้บริหาร: 3 คำถามที่ board ควรถาม CIO เรื่อง DBA control#

ทุกอย่างที่คุยมาทั้ง EP สรุปได้เป็น 3 คำถามที่บอร์ดควรถาม CIO อย่างน้อยปีละครั้งครับ คำถามเรียบง่าย แต่คำตอบบอกได้ทันทีว่าบริษัทอยู่ระดับไหน

คำถามที่ 1: “เรามี DBA กี่คน และคนไหนมีสิทธิ์ใน production DB ตัวไหนบ้าง”

ถ้า CIO ตอบไม่ได้ภายใน 1 นาที แปลว่าไม่มี access matrix ที่อัปเดต คือ DBA มีสิทธิ์ “งอกเงย” ตามเวลา ไม่มีใครรู้แน่ว่าใครถืออะไร

คำถามที่ 2: “DBA action ใน production ถูก log + replay ได้ไหม และ log อยู่นอก reach ของ DBA หรือเปล่า”

ถ้าคำตอบคือ “log อยู่ใน database server เดียวกัน” แปลว่ามี Audit Log Tampering Risk ระดับสูง ถ้าคำตอบคือ “ไม่มี session recording เลย” แปลว่าตอนเกิด incident จะไม่มีใครรู้ว่าใครทำอะไร

คำถามที่ 3: “เรามี SoD ระหว่าง production DBA กับ security/audit team หรือเปล่า”

ถ้าคำตอบคือ “ทีมเดียวกัน คนเดียวกัน” control เป็น 0 ในบริษัทเล็ก ถ้าแบ่งคนไม่ได้ ต้องแบ่งเครื่องมือ ส่ง log ออกไปนอก reach ของทีม IT ภายในด้วย third-party SIEM

3 คำถามนี้ใช้เวลาประชุม 5 นาที แต่ตอบได้ครบทั้ง 3 คำถาม → บริษัทอยู่ในระดับ governance ที่ 90% ของบริษัทไทยยังไปไม่ถึง

ปิดบท + ข้ามไป EP.14#

EP.13 จบที่นี่ครับ หัวใจของทั้ง EP คือประโยคเดียว — DBA = trust แต่ verify เราต้องไว้ใจ DBA เพราะถ้าไม่ไว้ใจ ทำงานไม่ได้ แต่ trust ที่ไม่มี verify = ระบบที่ไม่มี control PAM, Session Recording, JIT, SoD, Audit Log Defense ทุกชิ้นที่คุยมาไม่ใช่เพื่อ “จับผิด DBA” มันเพื่อให้ระบบมีหลักฐานว่าเกิดอะไรขึ้นในวันที่อยากรู้ ซึ่งหวังว่าจะไม่ถึง แต่ถ้าถึงต้องมี

ที่สำคัญ ระบบที่ DBA ดูแล log ของตัวเอง = ระบบที่ไม่มี control เก็บประโยคนี้ไว้คุยกับ CIO

EP.13 เราคุยเรื่อง “คนภายใน” ที่มีอำนาจ DBA, admin, คนที่ถือกุญแจของบริษัทเอง แต่อันตรายของ database ไม่ได้มาจากภายในอย่างเดียว คนภายนอก ที่พยายามเข้าถึง database จาก network — hacker, ransomware operator, nation-state attacker — เป็นอีกเรื่องที่ใหญ่ไม่แพ้กัน data ที่เก็บอยู่ใน database ปลอดภัยจากการอ่านโดยคนที่ไม่ควรเห็นไหม? ถ้า disk ถูกขโมยไป data ในนั้นใครเปิดอ่านได้บ้าง? การเชื่อมต่อระหว่าง application กับ database ถูก eavesdrop ได้ไหม?

EP.14 จะเข้าเรื่อง Database Security + Encryption — encryption at rest, encryption in transit, key management, network isolation, และ defense layer ทั้งหมดที่ป้องกัน database จากภัยคุกคามภายนอก

→ EP.14 — Database Security + Encryption (เร็วๆ นี้)