CISA Series ตอนที่ 37 : D4 - Database Management — โกดังข้อมูลที่ DBA มีกุญแจทุกดอก

ผมขออธิบาย 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

ตัวอย่าง:

customers table มี customer_id, name, email
orders table มี 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