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

ทฤษฎีและกลไกการทำงาน (How it works): นโยบายความปลอดภัยใช้หลักการให้สิทธิ์ต่ำสุดเท่าที่จำเป็น (Least Privilege) ผ่าน 2 กลไก: - **Role-based Access Control (RBAC)**: กำหนดกลุ่มสิทธิ์ตามบทบาท เช่น บทบาท "Data Analyst" สามารถคิวรี่ตารางวิเคราะห์สรุปผล แต่ไม่มีสิทธิ์ดูข้อมูลดิบ - **Column-level Security (CLS)**: ซ่อนฟิลด์เฉพาะคอลัมน์ที่เป็นข้อมูลส่วนบุคคลอ่อนไหว (เช่น เลขบัตรเครดิต) โดยผู้ใช้ที่ไม่มีสิทธิ์จะไม่สามารถเลือกเรียกดูได้ หรือจะมองเห็นเป็นค่าปิดบัง (Masked values)

-- SQL syntax creating a column-level security mask on Snowflake / BigQuery
CREATE OR REPLACE MASKING POLICY secure_credit_card_mask AS (val string) 
  RETURNS string ->
    CASE 
      WHEN CURRENT_ROLE() IN ('SECURITY_ADMIN') THEN val
      ELSE 'XXXX-XXXX-XXXX-' || SUBSTR(val, 13, 4) -- Mask card numbers for analyst roles
    END;
                    

Use Case ในชีวิตจริง (Real-world Scenario): ตารางประวัติชำระเงินของห้างสรรพสินค้า ฝ่ายนักวิจัยตลาดสามารถเขียนโค้ดคิวรี่ดูพฤติกรรมยอดซื้อเฉลี่ยของลูกค้าได้ตามปกติ แต่ฟิลด์เบอร์โทรศัพท์และเลขบัตรเครดิตจะถูกปิดบังเป็นรหัส 'XXXX' อัตโนมัติ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การจำกัดสิทธิ์ในระดับตารางอาจทำให้คำสั่งเขียนของนักพัฒนาในสภาพแวดล้อมจำลองขัดข้อง แก้ไขโดยการแยกใช้โพรไฟล์สิทธิ์ IAM แยกขาดระหว่างสภาพแวดล้อมจำลอง (Staging) และระบบจริง (Production)

ทฤษฎีและกลไกการทำงาน (How it works): เพื่อรักษาความเป็นส่วนตัวของข้อมูล PII (Personally Identifiable Information เช่น เลขบัตรประจำตัวประชาชน) เราจะแปลงค่าฟิลด์เหล่านั้นให้อยู่ในรูปคีย์แฮชที่ไม่สามารถถอดคืนได้ด้วยอัลกอริทึม **SHA-256** และเพื่อป้องกันการแฮกเกอร์แกะรอยย้อนหลังผ่านรายการประมวลผลดัชนีสำเร็จรูป (Rainbow Table Attack) เราต้องสุ่มผสมข้อความลับคำแฝงหรือ **Salt** เพิ่มเติมลงไปในข้อความดิบก่อนทำแฮช

# Python script demonstrating PII Salt-Hashing function
import hashlib

def anonymize_email(raw_email: str, system_salt: str = "SecurePipeCraftSalt102") -> str:
    if not raw_email:
        return ""
    # Merge string with salt to prevent dictionary attacks
    salted_input = raw_email.lower().strip() + system_salt
    # Return 64-character hexadecimal digest representation
    return hashlib.sha256(salted_input.encode('utf-8')).hexdigest()

print(anonymize_email("somchai@pipecraft.com"))
                    

Use Case ในชีวิตจริง (Real-world Scenario): ท่อส่งข้อมูลบริษัทฟินเทคแปลงรหัสอีเมลลูกค้าขาเข้าทั้งหมดให้กลายเป็นค่าแฮช SHA-256 ตั้งแต่เลเยอร์ Bronze ทำให้ระบบวิเคราะห์เลเยอร์ถัดไปไม่มีการสัมผัสข้อมูลดิบของลูกค้าตรงตัว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): หากลืมบันทึกหรือทำตัวแปร Salt หลักสูญหาย จะทำให้ไม่สามารถทำแฮชคีย์เทียบเพื่อรวมคีย์ตารางข้อมูลเก่าในคลังได้อีกเลย แก้ไขโดยการเก็บรักษาค่า Salt ไว้ในระบบ Secret Manager ที่มีการควบคุมรัดกุมสูงสุด

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

# 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): ทุกครั้งที่จ๊อบ Airflow ETL เริ่มโหลดข้อมูล API ระบบจะยิงขอ AWS Secrets Manager เพื่อดึง Bearer Token ล่าสุดมาเซตตัวแปรใช้งานชั่วคราว ปลอดภัยจากการแชร์โค้ดระบบ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การจำกัดจำนวนโควต้าการขอดึงคีย์ (Throttling limits) บ่อยครั้งในการรันระบบระดับวินาที แก้ไขโดยการตั้งจำข้อมูลคีย์ไว้ในแรมระบบชั่วคราว (Local caching with custom TTL)

ทฤษฎีและกลไกการทำงาน (How it works): เพื่อตอบคำถามผู้ตรวจสอบสิทธิ์ว่า "ข้อมูลนี้เดินทางมาจากตารางไหน และผ่านขั้นตอนทรานฟอร์มด้วยสูตรใดบ้าง" ระบบการกำกับดูแลใช้มาตรฐาน **OpenLineage** ฝังตัวดักจับเหตุการณ์รันงานของเอนจิ้น (Spark, dbt, Airflow) เพื่อบันทึกสร้างแผนภาพความเชื่อมโยงข้อมูลโดยอัตโนมัติ

# Concept of OpenLineage event registering a dataset conversion state
{
  "eventType": "COMPLETE",
  "inputs": [{"namespace": "s3://datalake", "name": "bronze_clicks"}],
  "outputs": [{"namespace": "s3://datalake", "name": "silver_user_clicks"}]
}
                    

Use Case ในชีวิตจริง (Real-world Scenario): เมื่อฝ่ายรายงานระบุตัวเลขยอดช้อปเฉลี่ยในแดชบอร์ดเพี้ยน ทีมข้อมูลใช้ OpenLineage ไล่ย้อนดูต้นกำเนิดตารางวิเคราะห์กลับไปพบว่ามีท่อส่งข้อมูลต้นทางคัดกรองอักขระผิดพลาด ทำให้หาสาเหตุเจอได้ในไม่กี่นาที

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): เอนจิ้นรุ่นเก่าบางประเภทอาจไม่รองรับ OpenLineage API แก้ไขโดยใช้ระบบจัดระเบียบแมนนวลแมปสตรีมผ่านสเปคเขียนกำกับรายละเอียดลงในแคตตาล็อกระบบส่วนกลาง (เช่น Datahub หรือ Apache Atlas)