หมวดหมู่: Data Governance

ตัวอย่าง Database Schema และ Data Retention Flow ที่รองรับทั้ง Soft Delete (ตาม ISO 27001) และ Hard Purge (ตาม PDPA/GDPR)ตัวอย่าง Database Schema และ Data Retention Flow ที่รองรับทั้ง Soft Delete (ตาม ISO 27001) และ Hard Purge (ตาม PDPA/GDPR)

2013-01-102013-01-10| phunsanitphunsanit| 0 Comment | 07:00

การออกแบบระบบฐานข้อมูลสำหรับองค์กรขนาดใหญ่ (Enterprise-Grade) ไม่ใช่แค่การจัดเก็บข้อมูล แต่คือการสร้างกลไกที่ต้องตอบโจทย์ข้อกำหนดทางกฎหมายและความมั่นคงปลอดภัยที่ขัดแย้งกันสองด้านเสมอ

ในทางหนึ่ง ด้านความมั่นคงปลอดภัยและการตรวจสอบ (ISO/IEC 27001, ISO 15489) ต้องการให้ข้อมูลทุกอย่างมี Audit Trail ที่สมบูรณ์ จึงผลักดันให้ใช้ Soft Delete เพื่อคงสถานะการมีอยู่ของ Record ไว้เพื่อการตรวจสอบย้อนหลัง

ในทางกลับกัน ด้านการคุ้มครองข้อมูลส่วนบุคคล (PDPA, GDPR) กำหนดหลักการ Data Minimization และ Right to Erasure ซึ่งบังคับให้องค์กรต้อง ลบทำลายข้อมูลจริง (Hard Purge) เมื่อพ้นระยะเวลาจัดเก็บ (Retention Period) หรือเมื่อเจ้าของข้อมูลร้องขอ

บทความนี้จะนำเสนอพิมพ์เขียว (Blueprint) อย่างสมบูรณ์ ทั้งในเชิง Database Schema, Data Retention Lifecycle, และ Automated Purge Strategy โดยใช้ PostgreSQL เพื่อให้ระบบของคุณสามารถตอบสนองต่อมาตรฐานทั้งสองได้อย่างไร้รอยต่อ

⚙️ Data Retention Lifecycle Architecture (The 3 Stages)

เพื่อให้ระบบตอบสนองทั้ง ISO 27001 และ PDPA/GDPR ข้อมูลจะต้องเดินทางผ่านวงจร 3 ระดับที่ถูกควบคุมด้วยเวลาและเงื่อนไขทางธุรกิจ:

  1. Active State (ISO Compliant): ข้อมูลใช้งานปกติ (Soft Delete ยังไม่ถูกเรียกใช้)
  2. Soft Deleted State (Audit Trail): สถานะที่ถูกทำเครื่องหมายว่าถูกลบ แต่ยังคงอยู่ในฐานข้อมูลเพื่อการตรวจสอบ (Soft Delete)
  3. Hard Purged State (PDPA Compliant): ข้อมูลถูกลบทำลายออกจากฐานข้อมูลอย่างถาวรเมื่อพ้นระยะเวลาจัดเก็บ

💾 PostgreSQL Schema Design: The Blueprint

เราจะใช้ตารางตัวอย่าง user_data และเพิ่มคอลัมน์ที่จำเป็นสำหรับการควบคุมวงจรชีวิตข้อมูล:

SQL

-- 1. Create Table with necessary columns for compliance
CREATE TABLE user_data (
    id SERIAL PRIMARY KEY,
    user_id VARCHAR(50) NOT NULL,
    personal_data TEXT NOT NULL, -- ข้อมูลที่ต้องถูกลบตาม PDPA
    is_deleted BOOLEAN DEFAULT FALSE,
    deleted_by VARCHAR(100),
    deleted_at TIMESTAMP WITH TIME ZONE,
    retention_period INTERVAL DEFAULT '90 days' -- กำหนดระยะเวลาจัดเก็บ
);

-- 2. Example Insertion
INSERT INTO user_data (user_id, personal_data) VALUES ('user_abc', 'apple,banana,orange');

🔄 Data Flow Implementation: Soft Delete to Hard Purge

กระบวนการนี้ต้องอาศัยการทำงานร่วมกันระหว่าง Application Logic และ Scheduled Job (Cron Job) เพื่อให้เกิดความสมบูรณ์ตามหลักการ:

Step 1: Soft Delete (ISO 27001 Compliance)

เมื่อผู้ใช้หรือ Admin ลบข้อมูล ระบบจะไม่ลบ Record แต่จะอัปเดตสถานะและบันทึกเวลาการลบ

SQL

-- Action: User/Admin initiates deletion
UPDATE user_data
SET is_deleted = TRUE,
    deleted_at = NOW(),
    deleted_by = 'user_abc'
WHERE id = 1;

Step 2: Hard Purge (PDPA/GDPR Compliance)

ระบบต้องมี Scheduled Job (เช่น Cron Job) ที่ทำงานเป็นระยะ (เช่น รายวัน) เพื่อค้นหาและลบข้อมูลที่เกินระยะเวลาจัดเก็บ (Retention Period) ออกจากระบบอย่างถาวร

SQL

-- Action: Scheduled Job runs to purge old data
-- ลบข้อมูลที่ถูก Soft Delete แล้ว และเกินระยะเวลาจัดเก็บ (เช่น 90 วัน)
DELETE FROM user_data
WHERE is_deleted = TRUE
  AND deleted_at < NOW() - INTERVAL '90 days';

✅ บทสรุป: การสร้างระบบที่ยืดหยุ่นและเป็นไปตามกฎหมาย

การออกแบบ Data Retention Lifecycle ที่สมบูรณ์แบบนี้คือการผสานรวมระหว่างความต้องการทางธุรกิจ (Auditability) และข้อกำหนดทางกฎหมาย (Right to Erasure) เข้าด้วยกัน การใช้ Soft Delete ช่วยให้เราเก็บหลักฐานการเปลี่ยนแปลง (Audit Trail) ตามมาตรฐาน ISO 27001 ในขณะที่การมี Scheduled Job ที่ทำงาน Hard Purge ตามเงื่อนไข deleted_at และ retention_period ช่วยให้เราปฏิบัติตาม PDPA/GDPR ได้อย่างสมบูรณ์

ในฐานะ Senior Architect คุณควรให้ความสำคัญกับการสร้างกลไกเหล่านี้เป็นส่วนหนึ่งของ Core Infrastructure ไม่ใช่แค่ฟีเจอร์เสริม เพื่อให้มั่นใจว่าระบบของคุณไม่เพียงแต่ทำงานได้ แต่ยัง Compliant ในทุกมิติของความมั่นคงปลอดภัยและกฎหมายข้อมูลส่วนบุคคล

Read MoreRead More