ระบบความปลอดภัยและการควบคุมข้อมูล (Security, Governance & Privacy)

ทฤษฎีและกลไกการทำงาน (How it works): การให้สิทธิ์เข้าถึงข้อมูลยึดหลัก Least Privilege: - **RBAC**: กำหนดสิทธิ์ตาม "บทบาท" (เช่น Role: Data_Analyst มีสิทธิ์ SELECT ตารางการเงิน) - **ABAC**: ล้ำลึกกว่าโดยกำหนดสิทธิ์จาก "คุณลักษณะ" (Attributes) เช่น แผนก, เวลา, หรือพิกัด (เช่น อนุญาตให้เข้าถึงตารางการเงิน *เฉพาะ* พนักงานแผนกบัญชีที่ล็อกอินจาก IP ภายในบริษัทในเวลางานเท่านั้น)

-- IAM Policy JSON example for ABAC in AWS Lake Formation
{
  "Effect": "Allow",
  "Action": "lakeformation:GetDataAccess",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/Department": "Finance" -- ABAC condition
    }
  }
}
                    

Use Case ในชีวิตจริง (Real-world Scenario): บริษัทข้ามชาติมีนโยบาย Data Sovereignty (อธิปไตยข้อมูล) วิศวกรใช้ ABAC กำหนดแท็ก `region=EU` ไว้ที่ตารางของชาวยุโรป ทำให้พนักงานที่ล็อกอินจากสิงคโปร์ (ซึ่งมีแท็ก `region=APAC`) ไม่สามารถคิวรี่ข้อมูลชาวยุโรปได้เลยแม้จะมี Role เป็น Admin ก็ตาม

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การกำหนด Policy ของ ABAC ที่ซับซ้อนเกินไปอาจทำให้เกิดสภาวะ "สิทธิ์ขัดแย้ง" จนไม่มีใครเข้าตารางได้ แก้ไขโดยใช้ระบบประเมินผล Policy Simulator ทดสอบสิทธิ์ก่อนประกาศใช้จริง

ทฤษฎีและกลไกการทำงาน (How it works): เพื่อปกป้องข้อมูล PII (เช่น รหัสบัตรเครดิต): - **Column-Level Encryption**: ข้อมูลจะถูกเข้ารหัสทางคณิตศาสตร์เก็บลงดิสก์ (Encryption at rest) หากแฮกเกอร์ขโมยไฟล์ไปได้ จะเห็นแค่ตัวอักษรขยะ - **Dynamic Data Masking (DDM)**: การปิดบังข้อมูล *ขณะกำลังคิวรี่ (On-the-fly)* โดยที่ข้อมูลในดิสก์ยังเป็นของจริง หากผู้ไม่มีสิทธิ์คิวรี่ ระบบจะพ่นค่า `XXXX` ออกมาแทน

-- SQL syntax creating a Dynamic Data Masking policy in Snowflake
CREATE OR REPLACE MASKING POLICY secure_credit_card_mask AS (val string) 
  RETURNS string ->
    CASE 
      WHEN CURRENT_ROLE() IN ('SECURITY_ADMIN') THEN val -- See real data
      ELSE 'XXXX-XXXX-XXXX-' || SUBSTR(val, 13, 4) -- Masked for everyone else
    END;

ALTER TABLE sales MODIFY COLUMN card_number SET MASKING POLICY secure_credit_card_mask;
                    

Use Case ในชีวิตจริง (Real-world Scenario): คอลเซ็นเตอร์เปิดหน้าจอประวัติลูกค้าเพื่อรับสาย ระบบฐานข้อมูลใช้ DDM ปิดบังเลขบัตรเครดิตเหลือแค่ 4 ตัวท้ายบนหน้าเว็บ แต่เมื่อฝ่ายบัญชี (มีสิทธิ์พิเศษ) รันสรุปยอด จะสามารถดึงเลขบัตรเต็มไปตัดเงินได้ปกติ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเข้ารหัส Column-Level Encryption ทำให้ไม่สามารถรันคำสั่งกลุ่ม `GROUP BY` หรือค้นหา `WHERE` แบบ Exact Match ได้รวดเร็วเพราะต้องถอดรหัสก่อน แก้ไขโดยหลีกเลี่ยงการเข้ารหัสฟิลด์ที่ต้องใช้เป็นคีย์เชื่อมตารางหลัก (Join Keys)

ทฤษฎีและกลไกการทำงาน (How it works): เมื่อข้อมูลใน Data Lake มีเป็นแสนตาราง องค์กรต้องมี **Data Catalog** (สมุดบัญชีข้อมูล เช่น Apache Atlas หรือ Amundsen) ทำหน้าที่เป็น "Google Search สำหรับข้อมูลภายใน" ให้พนักงานค้นหาตาราง ดูพจนานุกรมข้อมูล (Data Dictionary) และดู **Data Lineage** (แผนภาพต้นน้ำ-ปลายน้ำ) ว่าข้อมูลนี้ไหลมาจากไหนและใครเป็นเจ้าของ

# Example configuration injecting OpenLineage metadata from Spark to Data Catalog
spark.conf.set("spark.extraListeners", "io.openlineage.spark.agent.OpenLineageSparkListener")
spark.conf.set("spark.openlineage.transport.url", "http://atlas-catalog-server:21000")
spark.conf.set("spark.openlineage.namespace", "pipecraft-prod")
                    

Use Case ในชีวิตจริง (Real-world Scenario): นักวิเคราะห์การตลาดต้องการสร้างแคมเปญใหม่ แต่ไม่รู้ว่ามีตาราง "อายุลูกค้า" อยู่ที่ไหน จึงพิมพ์ค้นหาใน Amundsen ระบบแสดงตารางพร้อมขึ้น Data Lineage ชี้ให้เห็นว่าตารางนี้ถูกสร้างมาจากท่อส่งของทีม Data Engineer ชื่อ "A" ทำให้ติดต่อขอใช้งานได้ถูกคน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การติดตั้ง Catalog แต่ปล่อยให้ Metadata เก่าไม่อัปเดต (Stale Data) จะทำให้ไม่มีใครเชื่อถือระบบ แก้ไขโดยบังคับให้ CI/CD ดึง Schema ล่าสุดส่งอัปเดตเข้า Data Catalog อัตโนมัติทุกครั้งที่มีการเปลี่ยนโค้ดตาราง

ทฤษฎีและกลไกการทำงาน (How it works): การเขียนรหัสผ่าน Database หรือ API Key ฝังลงในซอร์สโค้ด (Hardcoded Credentials) ถือเป็นข้อผิดพลาดด้านความปลอดภัยขั้นร้ายแรง ระบบโปรดักชันจะนำรหัสเหล่านี้ไปฝากไว้ในตู้เซฟกลางเช่น **HashiCorp Vault** หรือ **AWS Secrets Manager** โค้ดของเราจะใช้ IAM Role ขอสิทธิ์เข้าไปเบิกคีย์มาใช้ชั่วคราวใน RAM ตอนรันไทม์เท่านั้น

# Retrieving database credentials securely from AWS Secrets Manager
import boto3
import json

def get_secret_credentials(secret_name, region_name="ap-southeast-1"):
    client = boto3.client(service_name='secretsmanager', region_name=region_name)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response['SecretString'])
                    

Use Case ในชีวิตจริง (Real-world Scenario): วิศวกรลาออก ระบบ Secrets Manager รองรับฟีเจอร์ Key Rotation สั่งหมุนเปลี่ยนรหัสผ่านฐานข้อมูลใหม่ทั้งหมดอัตโนมัติทุกๆ 30 วัน โดยที่แอปพลิเคชัน Airflow ไม่ล่มเลยเพราะมันดึงคีย์ใหม่ผ่าน API ทุกครั้งที่เริ่มงาน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ถ้าระบบยิงขอ API ถี่เกินไป (เช่น 1,000 ครั้งต่อวินาที) จะโดนบล็อก Throttling Limit แก้ไขโดยให้โค้ดทำ Local Caching เก็บค่าในแรมชั่วคราวไว้ 5 นาที แล้วค่อยขอใหม่