PlusMagi's Blog By Pitt Phunsanit Cybersecurity AEAD: Authenticated Encryption with Associated Data

AEAD: Authenticated Encryption with Associated Data

ในโลกของระบบฐานข้อมูลที่ข้อมูลถูกส่งผ่านเครือข่ายหรือถูกจัดเก็บในสภาพแวดล้อมที่ไม่น่าไว้วางใจ การเข้ารหัสข้อมูล (Encryption) ถือเป็นรากฐานสำคัญในการปกป้องความเป็นส่วนตัว อย่างไรก็ตาม การเข้ารหัสแบบดั้งเดิมมักให้ความสำคัญกับเพียงแค่ ‘ความลับ’ (Confidentiality) เท่านั้น ซึ่งหมายความว่าแม้ผู้โจมตีจะดักจับข้อมูลได้ เขาก็จะไม่สามารถอ่านมันได้ แต่ไม่ได้หมายความว่าเขาจะไม่สามารถ ‘แก้ไข’ หรือ ‘ปลอมแปลง’ ข้อมูลระหว่างทางได้

AEAD คืออะไร? การป้องกันข้อมูลแบบครบวงจรสำหรับ PostgreSQL

Authenticated Encryption with Associated Data (AEAD) คือมาตรฐานทางคริปโตกราฟีขั้นสูงที่ถูกออกแบบมาเพื่อปิดช่องโหว่ดังกล่าว AEAD ไม่ได้ทำหน้าที่เพียงแค่ทำให้ข้อความอ่านไม่ออกเท่านั้น แต่ยังรับประกันองค์ประกอบที่สำคัญถึง 3 ประการพร้อมกันในการประมวลผลข้อมูลใน PostgreSQL:

  1. ความลับ (Confidentiality): ข้อมูลถูกเข้ารหัส ทำให้ผู้ที่ไม่ได้รับอนุญาตอ่านไม่ได้
  2. ความสมบูรณ์ (Integrity): มีการสร้างค่าแฮช (MAC) เพื่อรับประกันว่าบิตข้อมูลไม่ได้ถูกเปลี่ยนแปลงแม้แต่น้อยตั้งแต่ต้นทางจนถึงปลายทาง
  3. ความถูกต้องแท้จริง (Authenticity): ยืนยันได้ว่าข้อมูลนี้ถูกสร้างขึ้นโดยระบบที่ถูกต้องตามที่คาดหวัง ไม่ใช่การปลอมแปลงจากภายนอก

Associated Data (AD): ข้อมูลที่ต้องตรวจสอบแต่ไม่เข้ารหัส

หัวใจสำคัญที่ทำให้ AEAD แตกต่างคือแนวคิดของ Associated Data (AD) AD คือข้อมูลเมตา (Metadata) ที่จำเป็นต้องได้รับการตรวจสอบความสมบูรณ์และความถูกต้อง แต่เราไม่ต้องการเข้ารหัสมันด้วยเหตุผลด้านประสิทธิภาพหรือข้อกำหนดทางธุรกิจ ตัวอย่างเช่น ในการบันทึกธุรกรรมทางการเงิน ข้อมูล user_id หรือ transaction_timestamp อาจต้องถูกตรวจสอบว่าไม่มีใครแก้ไขค่าเหล่านี้ได้ แต่เราไม่จำเป็นต้องเข้ารหัสค่าเหล่านี้ เพราะมันถูกใช้ในการทำดัชนี (Indexing) หรือการค้นหา

เมื่อใช้ AEAD ในบริบทของ PostgreSQL การส่งค่า AD เข้าไปในการเข้ารหัสจะช่วยให้เราสามารถผูกมัดความสมบูรณ์ของข้อมูลหลัก (Payload) เข้ากับข้อมูลเมตาเหล่านี้ได้อย่างแน่นหนา

ตัวอย่างการใช้งานแนวคิด AEAD ใน PostgreSQL

แม้ว่า PostgreSQL จะไม่มีฟังก์ชันคริปโตกราฟี AEAD โดยตรงในระดับไวยากรณ์ (Syntax) แต่ในระดับสถาปัตยกรรม (Architectural Level) เราสามารถใช้หลักการนี้ในการออกแบบฟังก์ชันที่รับประกันความสมบูรณ์ของข้อมูลได้ ตัวอย่างนี้แสดงการเข้ารหัสข้อมูลหลัก (Payload) พร้อมกับการระบุ Associated Data (AD) ที่ต้องถูกตรวจสอบความสมบูรณ์:

SQL

-- สมมติว่าเรามีฟังก์ชันที่ใช้ AEAD Algorithm (เช่น AES-GCM)</code>
-- ฟังก์ชันนี้รับ Payload, Associated Data, และ Key

SELECT encrypt_aead('user_data_payload', 'user_id:123|session:XYZ', 'encryption_key')
INTO encrypted_result;

-- encrypted_result จะประกอบด้วย: [Ciphertext | Authentication Tag]
-- หากมีการแก้ไข 'user_id' หรือ 'user_data_payload' ในระหว่างทาง, การถอดรหัสจะล้มเหลวและส่งคืน NULL หรือข้อผิดพลาด

การออกแบบเช่นนี้ทำให้มั่นใจว่า หากผู้โจมตีพยายามแก้ไข user_id (AD) หรือเนื้อหาของข้อมูล (Payload) ระบบจะตรวจพบความไม่สอดคล้องกันทันทีเมื่อมีการถอดรหัส

บทสรุป: การยกระดับความปลอดภัยในระดับสถาปัตยกรรม

สำหรับ Senior Architect ที่ออกแบบระบบด้วย PostgreSQL การทำความเข้าใจ AEAD ไม่ใช่แค่การรู้ว่ามันคืออะไร แต่คือการรู้ว่าต้องออกแบบฟังก์ชันการเข้ารหัสอย่างไรให้ครอบคลุมทั้ง 3 มิติ (Confidentiality, Integrity, Authenticity) การใช้ AEAD ช่วยยกระดับความปลอดภัยของข้อมูลให้เหนือกว่าการเข้ารหัสแบบดั้งเดิม ทำให้ระบบของคุณมีความทนทานต่อการโจมตีแบบ Man-in-the-Middle ได้อย่างแท้จริง

Exit mobile version