สารบัญ
ผมขออธิบาย database management ในมุมที่ตอบคำถามเดียว: “ใครคุมคนที่ถือกุญแจทุกดอก?”
ถ้าเปรียบ organization ข้อมูล = ห้องสมุด — DBA คือบรรณารักษ์ใหญ่ที่มีกุญแจทุกห้อง เปิดได้ ปิดได้ เพิ่มหนังสือได้ ลบหนังสือได้ และสำคัญที่สุด — สามารถแก้สมุดประวัติของหนังสือได้ด้วย
DBA ที่ดี = ผู้พิทักษ์ข้อมูลขององค์กร DBA ที่ไม่มี oversight = single point of failure ที่ใหญ่ที่สุด
ตอนนี้ผมขอลงรายละเอียด Section 4.11 ทั้ง — architecture ของ database, controls ที่ต้องมี, DBA bypass risk และทำไม backup encryption เป็นเรื่อง critical
ทำไม database ถึงเป็น critical asset
ในมุมที่หลายคนไม่ค่อยมอง — database ไม่ใช่แค่ที่เก็บข้อมูล มันคือระบบที่ตัดสินใจว่าข้อมูลแต่ละเรื่องสัมพันธ์กันยังไง
- ลูกค้าคนที่ A ซื้ออะไร? — ต้อง join customer table กับ order table
- พนักงานคนใดเข้า record ของผู้ป่วยคนใด? — ต้อง join user table กับ access log table
ความสัมพันธ์ของข้อมูลคือสิ่งที่ database ให้ — และความสัมพันธ์เหล่านี้คือสิ่งที่ business ใช้ทำงานทุกวัน
ถ้า database — เพี้ยน, ถูก modify, รั่ว, ล่ม — business ทุกฟังก์ชันที่ depend on database ก็เพี้ยนตาม
DBMS architecture: 4 model หลัก
CRM แนะนำ 4 model architecture แต่ใน enterprise ส่วนใหญ่จะเจอ 2 ที่สำคัญ:
Relational (ที่เจอมากสุด)
ข้อมูลเก็บเป็น table ที่มี row + column linking ผ่าน key
ตัวอย่าง:
customerstable มีcustomer_id,name,emailorderstable มีorder_id,customer_id,amount- join ผ่าน
customer_id→ ตอบคำถาม “ลูกค้าคนนี้สั่งอะไรบ้าง”
ส่วนใหญ่ของ ERP, CRM, financial system, billing system ใช้ relational — Oracle, SQL Server, MySQL, PostgreSQL
ความเสี่ยงเฉพาะตัว: SQL injection — attacker ส่ง query ที่ครอบ logic ของ application
Non-relational / NoSQL
ข้อมูลเก็บเป็น document หรือ key-value ไม่ต้องมี schema ตายตัว
ตัวอย่าง: MongoDB, Cassandra, Redis
เจอมากใน — modern web app, mobile backend, real-time analytics
ความเสี่ยงเฉพาะตัว: schema ที่ flexible เกินไป → data integrity ดูแลยาก, access control ที่ไม่มาตรฐาน
Hierarchical + Network
legacy databases — เจอน้อยใน enterprise ปัจจุบัน แต่ยังมีในระบบเก่าของธนาคาร / mainframe
ACID: 4 หลักประกันของ relational database
มาตรฐานที่ relational database ทุกตัวควร support — ACID:
| ตัวอักษร | หมายถึง | ตัวอย่าง |
|---|---|---|
| Atomicity | transaction ทำครบทุกขั้น หรือไม่ทำเลย | โอนเงิน A→B: หัก A 1000, เพิ่ม B 1000 — ถ้าครึ่งทาง crash → rollback ทั้ง 2 ขั้น |
| Consistency | หลัง transaction ข้อมูลยังตามกฎ integrity | foreign key ที่อ้างถึง table อื่น ต้องไม่ orphan |
| Isolation | transaction ที่รันพร้อมกัน ไม่รบกวนกัน | คนสองคนอ่าน/เขียน record เดียวกัน → ผลลัพธ์เหมือนทำคนเดียวจบก่อนค่อยให้อีกคนทำ |
| Durability | committed transaction อยู่รอดแม้ระบบ crash | หลัง commit แล้ว ข้อมูลอยู่ใน persistent storage |
ทำไม auditor ต้องรู้ ACID? — เพราะมันคือ integrity guarantee ที่ database ให้กับ application ถ้า DBMS ที่ใช้ไม่ ACID-compliant → application ต้องสร้าง integrity check เอง — และส่วนใหญ่จะทำไม่ดีพอ
Data Dictionary: การ์ดประจำตัวของข้อมูล
Data Dictionary (DD) = ข้อมูลของข้อมูล (metadata) ที่บอก:
- field นี้ชื่ออะไร
- type อะไร (integer / string / date)
- valid value range
- relationship กับ field อื่น
- ใครเป็น owner
DD มี 2 แบบ:
- Active — bind กับ DBMS, enforce rule แบบ runtime (ค่าที่ผิด type ใส่ไม่ได้เลย)
- Passive — เป็น documentation ไม่ enforce
หลุมพรางของ exam: “Data Dictionary = แค่ documentation” — ผิดถ้าเป็น Active DD active DD เป็น processing control โดยตรง
DD ที่ outdated = data integrity risk เพราะ application ไม่รู้ว่า field ที่ใช้อยู่ตอนนี้ valid range เป็นเท่าไหร่
ใครคุม DBA? — เรื่องที่ exam ออกซ้ำๆ
DBA bypass: ความเสี่ยงที่ใหญ่ที่สุด
normal user เข้าข้อมูลผ่าน application → application enforce business rule → application log activity
DBA เข้าข้อมูลตรงเข้า database → ไม่ต้องผ่าน application → ไม่ผ่าน business rule → ไม่มี application log
ตัวอย่างจริง: ผู้ผลิตชิ้นส่วนรถยนต์ — DBA มีสิทธิ์ INSERT/UPDATE table ของ production quality test
ในการ audit พบว่า — 15 record ถูก modify โดยตรงผ่าน database (ไม่ผ่าน application) ค่า quality test ที่ “ไม่ผ่าน” ถูกเปลี่ยนเป็น “ผ่าน”
application log ไม่เห็น — เพราะ change ไม่ผ่าน application
control ที่ขาด:
- separate logging สำหรับ direct database access
- periodic reconciliation ระหว่าง application transaction กับ database change
- DBA activity monitoring (privileged access management)
ทางออก: Privileged Access Management
วิธีคุม DBA ที่ work:
- ทุก DBA action บน production = log + alert — มี dedicated tool (PAM — Privileged Access Management) ที่ record session, capture command, alert ตอน activity ผิดปกติ
- Direct DB modification ต้องผ่าน change request — ไม่ใช่ DBA decide เอง
- Periodic access review — ทุก quarter review ว่า DBA แต่ละคนยังต้องการสิทธิ์ที่ตัวเองมีรึเปล่า
- Separation of duties — DBA ที่ดูแล production ≠ DBA ที่ดูแล log ของ production
เดี๋ยว D5 จะลงเรื่อง IAM (Identity and Access Management) + privileged access detail
Field-level access control
อีกประเด็นที่ exam ออก — table-level access ≠ field-level access
ตัวอย่างจริง: โรงพยาบาลแห่งหนึ่ง — ทุก hospital staff (receptionist, surgeon, IT support, billing clerk) ใช้ role เดียวกัน “hospital_staff” เพื่อ access patient table
table นั้นมี column: name, id, address, phone, diagnosis, medication
receptionist ต้องใช้ — name, id, phone (เพื่อ check-in)
surgeon ต้องใช้ — ทุก field
billing clerk ต้องใช้ — name, id, address (เพื่อออกใบเสร็จ)
ถ้าทุกคนเข้าผ่าน role เดียวกัน — receptionist เห็น diagnosis + medication ทั้งที่ไม่ควร
PDPA ของไทย + ทั่วโลก ระบุชัด: access ต้องneed-to-know + need-to-do basis ไม่ใช่ “convenient ที่สุด”
control ที่ต้องมี: field-level access control ที่ DBMS — ทุก role เห็น column ที่จำเป็นเท่านั้น
Database Backup: เรื่องที่ห้ามมองข้าม
backup เป็นเรื่องที่จะลงละเอียดใน ตอน 39 แต่สำหรับ database มี 2 จุดที่ต้อง emphasize ตอนนี้:
Encryption ของ backup file
production database อาจถูก secure แน่นหนา — แต่ถ้า backup file ไม่ถูก encrypt → backup คือจุดอ่อน
ตัวอย่างจริง: e-commerce ของไทย — backup ของ customer database (ที่มี tokenized credit card data) เก็บที่ NAS ที่ทุก IT staff access ได้
junior sysadmin คนหนึ่ง copy backup file ไปที่ external drive “เพื่อทดสอบ”
ใน backup มี customer record 2 ล้าน — ชื่อ, ที่อยู่, เบอร์โทร, transaction history
ถ้า encrypt → external drive ไม่มีค่า ถ้าไม่ encrypt → data breach ที่ต้อง report ตาม PDPA
กฎเหล็ก: ถ้า production database มี personal data → backup ต้อง encrypt เสมอ
Restoration testing
backup ที่ไม่เคย test restoration = promise ที่ไม่รู้ว่าทำได้รึเปล่า
ตัวอย่างที่เจอบ่อย: บริษัทค้าปลีก backup รายวันมา 3 ปี วันที่ disk fail จริง — restore ไม่ได้ เพราะ backup format ไม่ compatible กับ database version ใหม่ (database upgrade ไป 8 เดือนก่อน แต่ restoration ไม่เคย retest)
เดี๋ยวตอน 39 จะลงเรื่อง backup และ restoration testing เต็มรูปแบบ
ที่ auditor ต้องตรวจในมุม database
5 จุดหลัก:
| จุดตรวจ | คำถาม | finding ที่บ่อย |
|---|---|---|
| DBA access logging | activity ของ DBA log ทุกตัวมั้ย? log อยู่ที่ไหน? ใครเข้าได้? | log อยู่ใน server เดียวกับที่ DBA admin → tampering risk |
| Field-level access | sensitive column (PII, health, financial) มี restriction มั้ย? | ทุกคนใน role เดียวกันเห็นทุก column |
| Schema change control | DDL change (CREATE/ALTER/DROP) ผ่าน change management มั้ย? | DBA แก้ schema ตรง production โดยไม่มี approval |
| Backup encryption | backup file encrypt มั้ย? key อยู่ที่ไหน? | backup เก็บแบบ plain |
| Restoration testing | test restore ครั้งสุดท้ายเมื่อไหร่? ผ่าน RTO มั้ย? | ไม่เคย test |
Trap patterns ที่ exam ออก
| หลุมพราง | คำตอบที่ถูก |
|---|---|
| ”DBA = trusted, ไม่ต้อง audit” | DBA = highest privileged → ต้อง strict logging + SoD + periodic review |
| ”Table-level access พอ” | sensitive data ต้อง field-level |
| ”Data Dictionary = documentation” | active DD = processing control ที่ enforce rule |
| ”SQL = relational ทั้งหมด” | บาง modern database (NoSQL) ใช้ SQL syntax แต่ไม่ relational |
| ”backup = recovery” | backup คือ data, recovery คือ process — ต้อง test restoration ถึงจะรู้ว่า work |
Cross-domain connection
| หัวข้อ | เชื่อมไป |
|---|---|
| Application controls | ตอน 27 — input/processing/output validation ของ application |
| Change management สำหรับ schema | ตอน 35 |
| Backup detail | ตอน 39 (จะตามมา) |
| DBA access ในมุม security | D5 — IAM + privileged access |
ปิดบท: trust แต่ verify
DBA = role ที่ต้องมี trust ระดับสูง — ไม่ใช่บริษัทใหญ่ไหนจะ run โดยไม่มี DBA ได้
แต่ trust ≠ ไม่มี control
Trust + verify = trust ใน intent ของ DBA + verify ทุก action ผ่าน log + monitoring + periodic review
ในมุมผม — ทุก enterprise ที่ผมเข้าไปดูแล จะมี 1 ใน 3 ปัญหาเรื่อง DBA เสมอ:
- DBA log อยู่ที่ DBA admin เอง (= log ที่ tamper ได้)
- ไม่มี separation ระหว่าง production DBA กับ change approver
- PAM tool ลงไว้แต่ alert ไม่ได้ tune
ถ้า audit แล้วองค์กรไหนผ่านทั้ง 3 ข้อนี้ — นั่นคือ organization ที่ mature จริง
ตอนถัดไปเราเปลี่ยน gear — ออกจาก Part A (operations) เข้าPart B (Business Resilience) ที่ตอบคำถามใหญ่: เมื่อระบบล่มไปจริงๆ — เราจะรอดยังไง? และคำถามแรกของ Part B = BIA
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.11 Database Management
