ในยุคที่แอปพลิเคชันดิจิทัลมีความซับซ้อนสูง การจัดการข้อมูลและตรรกะทางธุรกิจ (Business Logic) จึงต้องอาศัยการออกแบบระบบฐานข้อมูลที่รัดกุม การเข้าถึงส่วนประกอบสำคัญของระบบ ไม่ว่าจะเป็นตารางข้อมูล (Tables) หรือโค้ดที่ใช้ในการประมวลผล (Stored Procedures/Functions) จึงต้องถูกควบคุมอย่างเข้มงวด
สำหรับ PostgreSQL ซึ่งเป็นระบบฐานข้อมูลเชิงสัมพันธ์ที่ทรงพลัง การควบคุมการเข้าถึง (Access Control) ไม่ได้จำกัดอยู่แค่การป้องกันการลบข้อมูลเท่านั้น แต่ยังรวมถึงการกำหนดสิทธิ์ว่าใครสามารถเรียกใช้ฟังก์ชัน (Function) หรือดูโครงสร้างของ Schema ได้ด้วย การจัดการสิทธิ์เหล่านี้จึงเป็นเสมือนการควบคุม ‘Source Code’ และ ‘พื้นที่เก็บข้อมูล’ ที่เป็นหัวใจของแอปพลิเคชัน
หลักการควบคุมการเข้าถึงใน PostgreSQL (Schema & Code Access)
ในบริบทของ PostgreSQL, การควบคุมการเข้าถึงโค้ดหรือตรรกะทางธุรกิจจะถูกจัดการผ่านระบบ Role-Based Access Control (RBAC) ซึ่งเป็นกลไกที่กำหนดว่าผู้ใช้แต่ละคน (Role) มีสิทธิ์ในการทำอะไรกับ Object ใดบ้าง (เช่น Tables, Views, Functions) การกำหนดสิทธิ์ที่ถูกต้องจึงเป็นสิ่งสำคัญที่สุดในการรักษาความสมบูรณ์และความปลอดภัยของข้อมูล
การจัดการสิทธิ์ (GRANT และ REVOKE)
เราใช้คำสั่ง GRANT เพื่อมอบสิทธิ์ที่จำเป็น และใช้ REVOKE เพื่อถอดสิทธิ์เมื่อบทบาทนั้นๆ ไม่จำเป็นต้องใช้งานสิทธิ์ดังกล่าว การจำแนกสิทธิ์ที่สำคัญในที่นี้คือ:
- SELECT: สิทธิ์ในการอ่านข้อมูล (Read-only access)
- EXECUTE: สิทธิ์ในการเรียกใช้โค้ด (เช่น การรัน Stored Function)
- USAGE: สิทธิ์ในการเข้าถึง Schema หรือ Object
ตัวอย่างการจำลองการควบคุมการเข้าถึงฟังก์ชัน (ซึ่งเปรียบเสมือน Source Code) สำหรับการประมวลผลข้อมูล:
SQL
-- 1. สร้าง Role สำหรับผู้ใช้งานภายนอกที่ต้องการรันโค้ดเท่านั้น แต่ไม่ต้องการเห็น Source Code หรือข้อมูลดิบ<br>CREATE ROLE external_user;<br><br>-- 2. สร้างฟังก์ชันที่ใช้ในการประมวลผลข้อมูล<br>CREATE OR REPLACE FUNCTION process_data(data_list text) RETURNS text AS $$
SELECT 'Processed: ' || data_list;
$$ LANGUAGE SQL;<br><br>-- 3. มอบสิทธิ์ในการเรียกใช้ฟังก์ชัน (EXECUTE) ให้กับ Role นั้น<br>GRANT EXECUTE ON FUNCTION process_data(text) TO external_user;<br><br>-- 4. (สำคัญ) ไม่มีการ GRANT SELECT หรือ USAGE บน Schema/Table ต้นทาง<br>-- ทำให้ external_user รันฟังก์ชันได้ แต่ไม่สามารถ Query ข้อมูลดิบได้โดยตรง<br>
บทสรุป: ความสำคัญของสถาปัตยกรรมที่รัดกุม
การควบคุมการเข้าถึงใน PostgreSQL ไม่ใช่เพียงแค่การป้องกันการเข้าถึงข้อมูล แต่คือการรักษาความสมบูรณ์ของตรรกะทางธุรกิจ (Business Logic Integrity) ด้วยการใช้ระบบ Role และสิทธิ์อย่างเหมาะสม เราสามารถสร้างชั้นการป้องกันที่ซับซ้อน ทำให้มั่นใจได้ว่าผู้ใช้งานแต่ละกลุ่มจะได้รับสิทธิ์เท่าที่จำเป็น (Principle of Least Privilege) ซึ่งเป็นหลักการสำคัญที่สุดในการเป็น Senior Architect ในการออกแบบระบบที่ปลอดภัยและยืดหยุ่น