ความรู้พื้นฐานกฎหมาย PDPA (บทบาทบุคคล, Data Subject, Data Controller, Data Processor, DPO)

ในยุคที่ข้อมูลส่วนบุคคล (Personal Data) กลายเป็นสินทรัพย์ที่มีมูลค่าสูงสุด การกำกับดูแลข้อมูลจึงเป็นเรื่องเร่งด่วน กฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA) จึงเข้ามาเป็นกรอบการทำงานสำคัญสำหรับทุกองค์กร ไม่ว่าจะเป็นธุรกิจขนาดเล็กหรือระบบเทคโนโลยีขนาดใหญ่

ในฐานะ System Specialist เราไม่ได้มอง PDPA เป็นเพียงข้อบังคับทางกฎหมาย แต่คือหลักการออกแบบสถาปัตยกรรมข้อมูล (Data Architecture) ที่ต้องคำนึงถึงความเป็นส่วนตัวตั้งแต่ต้นทาง (Privacy by Design) การทำความเข้าใจบทบาทหน้าที่ของแต่ละฝ่ายจึงเป็นสิ่งสำคัญอย่างยิ่ง

🔑 บทบาทหลักใน PDPA: ใครควบคุม? ใครประมวลผล?

การแยกแยะบทบาทเหล่านี้ช่วยให้เรากำหนดขอบเขตความรับผิดชอบทางเทคนิคได้อย่างชัดเจน:

• Data Subject (เจ้าของข้อมูล): คือบุคคลที่เป็นเจ้าของสิทธิในข้อมูลส่วนบุคคลนั้น ๆ
• Data Controller (ผู้ควบคุมข้อมูล): คือองค์กรที่มีอำนาจตัดสินใจว่าจะเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลใดบ้าง (เช่น บริษัทที่ออกแบบระบบ)
• Data Processor (ผู้ประมวลผลข้อมูล): คือองค์กรที่ได้รับมอบหมายให้ดำเนินการตามคำสั่งของ Controller เท่านั้น โดยไม่มีสิทธิ์ในการกำหนดวัตถุประสงค์เอง (เช่น Outsource Service Provider)

การทำความเข้าใจขอบเขตนี้จะนำเราไปสู่การออกแบบระบบฐานข้อมูลที่ต้องมีการจำกัดสิทธิ์ (Role-Based Access Control – RBAC) อย่างเข้มงวด

⚙️ การประยุกต์ใช้ PDPA ด้วย PostgreSQL: การควบคุมสิทธิ์และการติดตามข้อมูล

ในทางเทคนิค เราสามารถใช้คุณสมบัติขั้นสูงของ PostgreSQL เพื่อจำลองการแยกบทบาทและความรับผิดชอบตามหลัก PDPA ได้ โดยเฉพาะการใช้ jsonb สำหรับเก็บ Metadata ของความยินยอม และ Recursive CTEs ในการตรวจสอบเส้นทางการไหลของข้อมูล (Data Lineage):

1. การจัดเก็บ Consent Metadata ด้วย JSONB

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

SQL

-- ตารางผู้ใช้งาน (Data Subject) และ Metadata ความยินยอม
CREATE TABLE user_consent (
    user_id INT PRIMARY KEY,
    data_subject_name TEXT NOT NULL,
    consent_metadata JSONB
);

INSERT INTO user_consent (user_id, data_subject_name, consent_metadata) VALUES
(101, 'สมชาย ใจดี', '{ 
  "purpose": "marketing", 
  "granted": true, 
  "timestamp": NOW()
}');

2. การจำลอง Data Lineage ด้วย Recursive CTE

ในฐานะ Controller เราต้องรู้ว่าข้อมูลถูกส่งต่อไปที่ใดบ้าง (Data Flow) ซึ่งสามารถใช้ Recursive Common Table Expression (CTE) เพื่อติดตามการประมวลผล:

SQL

-- ตารางบันทึกการไหลของข้อมูล
CREATE TABLE data_flow_log (
    source_id INT, 
    target_system TEXT,
    data_type TEXT,
    PRIMARY KEY (source_id, target_system)
);

WITH RECURSIVE data_lineage AS (
    SELECT source_id, target_system, data_type FROM data_flow_log WHERE source_id = 101
    UNION ALL
    SELECT dfl.source_id, t2.target_system, dfl.data_type || ' -> ' || t2.data_type 
    FROM data_flow_log dfl JOIN (SELECT * FROM data_flow_log WHERE source_id = 101) t2 ON TRUE
)
SELECT DISTINCT source_id, target_system, data_type FROM data_lineage;
-- ผลลัพธ์นี้ช่วยให้ Controller ทราบว่าข้อมูลถูกส่งไปที่ไหนบ้าง

✅ สรุป: การกำกับดูแลคือการออกแบบระบบ

PDPA ไม่ใช่แค่เอกสาร แต่คือแนวคิดในการออกแบบสถาปัตยกรรมฐานข้อมูล (Database Architecture) ที่ต้องคำนึงถึงหลักการจำกัดสิทธิ์ (Least Privilege) และความสามารถในการตรวจสอบย้อนกลับ (Auditability) เสมอ การใช้เครื่องมืออย่าง PostgreSQL ให้เกิดประโยชน์สูงสุด ทั้งในด้านการจัดการโครงสร้างข้อมูลที่ซับซ้อนและการติดตามเส้นทางของข้อมูล จะช่วยให้องค์กรของคุณไม่เพียงแต่ปฏิบัติตามกฎหมาย แต่ยังสร้างรากฐานความเชื่อมั่นให้กับผู้ใช้งานได้อย่างยั่งยืน