Network Security

1ภัยคุกคามพื้นฐาน (ทำไมต้องมี Security)

เครือข่ายเป็นทรัพยากรที่ใช้ร่วมกันโดยฝ่ายที่มีผลประโยชน์ต่างกัน — Internet ถูกใช้โดยธุรกิจคู่แข่ง รัฐบาลที่เป็นปรปักษ์กัน และอาชญากรฉวยโอกาส หากไม่มีมาตรการความปลอดภัย การสนทนาบนเครือข่ายหรือ distributed application อาจถูกโจมตีได้ ใช้กรณีลูกค้าสั่งซื้อสินค้าผ่านเว็บด้วยบัตรเครดิตเป็นตัวอย่างไล่ประเด็น:

2Cryptographic Building Blocks

หลักการของ Cipher

Encryption แปลง plaintext เป็น ciphertext ที่ไม่มีความหมายสำหรับผู้ไม่มี decryption function — คู่ encryption/decryption function เรียกว่า cipher เกณฑ์พื้นฐานคือมีแค่ผู้ถือ decryption key เท่านั้นที่กู้ plaintext กลับมาได้

Block cipher เข้ารหัสทีละ block ขนาดคงที่ (64–128 bit) — ถ้าเข้ารหัสแต่ละ block อย่างอิสระ (ECB mode) จะมีจุดอ่อน: plaintext block ค่าเดิมให้ ciphertext เดิมเสมอ ทำให้ pattern ที่ซ้ำใน plaintext เห็นได้ใน ciphertext ง่ายต่อการ cryptanalyze

Symmetric-Key Ciphers

ทั้งสองฝ่ายใช้ กุญแจเดียวกัน ทั้งเข้าและถอดรหัส

Public-Key (Asymmetric) Ciphers

ใช้กุญแจคู่ที่สัมพันธ์กันแต่ต่างกัน: private key (เก็บเป็นความลับ ใช้ถอดรหัส) และ public key (เผยแพร่ได้ ใช้เข้ารหัส) — ต้องเป็นไปไม่ได้ที่จะคำนวณ private key จาก public key

เสนอครั้งแรกโดย Diffie และ Hellman ปี 1976 — cipher ที่รู้จักที่สุดคือ RSA (Rivest, Shamir, Adleman — พึ่งความยากในการแยกตัวประกอบเลขจำนวนมาก) และ ElGamal (พึ่ง discrete logarithm problem ต้อง key ≥ 1024 bit)

Authenticator: Hash, MAC, HMAC, Digital Signature

Cryptographic hash function (message digest / cryptographic checksum) สร้างค่าความยาวคงที่จากข้อความความยาวใดก็ได้ ใช้ตรวจจับการปลอมแปลงข้อความโดยเจตนา (คล้าย CRC แต่ป้องกันการปลอมแปลงเจตนา ไม่ใช่ noise) — ตัวอย่าง: MD5 (128-bit digest), SHA-1 (160-bit digest)

3Key Pre-Distribution

ก่อนใช้ cipher/authenticator ต้องรู้ก่อนว่าใช้กุญแจไหน — แบ่งเป็น session key (กุญแจอายุสั้น ใช้เฉพาะ session หนึ่ง มักเป็น symmetric key เพื่อความเร็ว) กับ pre-distributed key (กุญแจอายุยาว ใช้สร้างความปลอดภัยให้ session key establishment protocol อีกที)

Pre-Distribution ของ Public Key: PKI และ Certificate

ใครก็สร้างคู่ public/private key เองได้ (algorithm เป็นที่รู้กัน) — ปัญหาคือจะ "ประกาศ" ว่า public key นี้เป็นของตนเองอย่างน่าเชื่อถือได้อย่างไร คำตอบคือ Public Key Infrastructure (PKI) ที่เริ่มต้นด้วยการยืนยันตัวตน "out of band" (นอกเครือข่าย เช่น เจอตัวจริง แสดงบัตรประชาชน)

Certification Authority (CA) คือหน่วยงานที่น่าเชื่อถือสำหรับยืนยันตัวตนและออก certificate — มีทั้งเชิงพาณิชย์ รัฐบาล และฟรี การเชื่อ CA ใหม่ทำได้ผ่าน chain of certificate ที่ลงนามย้อนไปถึง CA ที่รู้กุญแจอยู่แล้ว

Pre-Distribution ของ Symmetric Key

ยากกว่า public key ด้วยสองเหตุผล: (1) ต้องมี symmetric key แยกสำหรับทุกคู่ที่ต้องการสื่อสาร — ถ้ามี N entity ต้องมี N(N−1)/2 key (ต่างจาก public key ที่พอมี 1 คู่ต่อ entity); (2) symmetric key ต้องเก็บเป็นความลับทั้งสองฝั่ง

โปรโตคอล authentication แบบ symmetric key อื่นที่ใช้จริง ได้แก่ Needham-Schroeder (ต้นแบบของหลายระบบ) และ Kerberos (ใช้ trusted third party ออก ticket)

4Example Systems

หน่วยพื้นฐานของ IPsec คือ Security Association (SA) — connection ทางเดียว (simplex) ที่มี security property หนึ่งชุด การสื่อสารสองทาง (เช่น TCP connection) ต้องใช้ 2 SA เมื่อสร้าง SA จะได้ ID เรียกว่า SPI (Security Parameters Index)

5Firewalls

ระบบที่วางอยู่ ณ จุดเชื่อมต่อระหว่างเครือข่ายที่ต้องป้องกันกับเครือข่ายภายนอก มักอยู่ใน appliance/router (หรือ "personal firewall" บนเครื่อง end user) — Firewall จะได้ผลก็ต่อเมื่อเป็นทางเชื่อมต่อเดียวระหว่างไซต์กับภายนอก (ไม่มีทางลัดผ่าน gateway อื่น, wireless, หรือ dial-up)

6เริ่มจาก Threat Model ก่อนเลือกเครื่องมือ

คำว่า “ทำให้ปลอดภัย” กว้างเกินไปจนออกแบบไม่ได้ เราต้องระบุก่อนว่าปกป้องข้อมูลใด จากใคร บนเส้นทางใด และยอมเสียอะไรได้บ้าง ผู้โจมตีที่ดักฟัง Wi-Fi ได้ต่างจากผู้โจมตีที่ควบคุม server, ขโมยเครื่องผู้ใช้ หรือมีบัญชีภายในอยู่แล้ว เครื่องมือที่ป้องกันคนหนึ่งอาจไม่ช่วยอีกคน

Asset, Adversary, Attack Surface และ Trust Boundary

CIA ยังไม่พอสำหรับอธิบายทุกระบบ

Confidentiality, Integrity และ Availability เป็นแกนพื้นฐาน แต่ระบบจริงยังต้องคิดเรื่อง authentication, authorization, accountability, freshness และ privacy Authentication ตอบว่าเป็นใคร Authorization ตอบว่าทำอะไรได้ ส่วน audit log ช่วยตอบว่าใครทำอะไรเมื่อใด ทั้งสามคำถามคนละเรื่อง

7Encoding, Hashing และ Encryption อย่าสลับกัน

การส่ง password เป็น Base64 จึงเหมือนเขียนจดหมายด้วยตัวอักษรอีกชุด คนที่รู้รูปแบบอ่านกลับได้ทันที ส่วน hash ของ password ก็ต้องใช้ salt และ password hashing function ที่ช้าโดยตั้งใจ ไม่ควรใช้ hash เร็วทั่วไปอย่างเดียว เพราะผู้โจมตีลองคำจำนวนมากได้เร็วเช่นกัน

Salt, Nonce และ IV มีหน้าที่ต่างกัน

Salt ทำให้ password เหมือนกันไม่ให้ hash เหมือนกันและลดประโยชน์ของตารางคำนวณล่วงหน้า Nonce คือค่าที่ควรใช้ครั้งเดียวในบริบทนั้น ส่วน IV เป็นค่าเริ่มต้นของ cipher mode ซึ่งมีเงื่อนไขเรื่องความไม่ซ้ำหรือการสุ่มตาม algorithm การเรียกรวมทุกอย่างว่า random value ทำให้พลาดข้อกำหนดสำคัญ

8Hybrid Cryptography: ใช้เครื่องมือให้ตรงงาน

Public-key cryptography ช่วยแก้การแลกกุญแจและ digital signature แต่ช้ากว่า symmetric encryption ระบบจริงจึงใช้แบบ hybrid: ใช้ public key หรือ authenticated key exchange สร้าง shared secret แล้วใช้ symmetric key เข้ารหัสข้อมูลจำนวนมาก TLS, PGP และระบบ VPN ต่างใช้แนวคิดนี้ในรายละเอียดที่ต่างกัน

AEAD: เข้ารหัสพร้อมตรวจความถูกต้อง

การเข้ารหัสอย่างเดียวอาจซ่อนข้อมูลแต่ไม่ป้องกันการแก้ ciphertext ระบบสมัยใหม่จึงใช้ Authenticated Encryption with Associated Data เช่น AES-GCM หรือ ChaCha20-Poly1305 เพื่อให้ confidentiality และ integrity ร่วมกัน Associated data เช่น header บางส่วนอาจไม่ถูกเข้ารหัสแต่ถูกตรวจว่าไม่ถูกแก้

อย่าประดิษฐ์ Cryptographic Protocol เอง

Cipher ที่แข็งแรงอาจถูกใช้ใน protocol ที่อ่อนแอได้ เช่น reuse nonce, ไม่ตรวจ certificate, เปรียบเทียบ MAC ไม่ปลอดภัย หรือเข้ารหัสแต่ไม่ authenticate การเลือก library และ protocol มาตรฐานที่ผ่านการวิเคราะห์จึงสำคัญกว่าการรู้สูตรแล้วนำ primitive มาต่อเอง

9Digital Signature, Certificate และ PKI

Digital signature ใช้ private key ลงนามและใช้ public key ตรวจ ช่วยยืนยันว่าผู้ถือ private key รับรองข้อมูลและข้อมูลไม่ถูกแก้ แต่คำถามถัดไปคือ public key นี้เป็นของใคร Certificate จึงผูกชื่อหรือ identity กับ public key ผ่านลายเซ็นของผู้ออกใบรับรอง

Browser ตรวจ Certificate อะไรบ้าง

1. ชื่อ host ตรงกับชื่อใน certificate หรือไม่
2. Certificate อยู่ในช่วงเวลาที่ใช้งานได้หรือไม่
3. ลายเซ็นและ chain ย้อนถึง trust anchor ที่เชื่อถือได้หรือไม่
4. การใช้งานของ key อนุญาตให้ใช้กับงานนี้หรือไม่
5. ระบบมีข้อมูลว่าถูกเพิกถอนหรือมี policy อื่นที่ต้องตรวจหรือไม่

Forward Secrecy

หาก session key มาจาก ephemeral Diffie-Hellman และลบ private ชั่วคราวหลังใช้งาน การขโมย long-term private key ในอนาคตไม่ควรทำให้ผู้โจมตีถอด session เก่าที่เคยบันทึกไว้ได้ คุณสมบัตินี้เรียกว่า forward secrecy และเป็นเหตุผลที่ key agreement สมัยใหม่ไม่ใช้ long-term key เข้ารหัส session key แบบตรง ๆ เพียงอย่างเดียว

10TLS ป้องกันช่วงไหนของเส้นทาง

HTTPS ป้องกันจาก client ถึง TLS endpoint แต่ endpoint อาจเป็น CDN, reverse proxy หรือ load balancer ไม่จำเป็นต้องเป็น application server ตัวสุดท้าย หาก proxy ถอด TLS แล้วสร้าง connection ใหม่ไป backend Proxy จะเห็น plaintext ได้ การวาด data path และ trust boundary จริงจึงสำคัญกว่าบอกเพียงว่า “ใช้ HTTPS แล้ว”

11Network Security ต้องใช้ Defense in Depth

Firewall เพียงตัวเดียวไม่สามารถป้องกัน credential ถูกขโมย ช่องโหว่ใน application หรือ insider ได้ แนวคิด defense in depth ใช้หลาย control ที่ทำหน้าที่ต่างกัน เช่น segmentation จำกัดการเคลื่อนที่, MFA ลดผลจาก password รั่ว, patching ปิดช่องโหว่, EDR เฝ้าระวัง endpoint และ backup ช่วยกู้ availability

Stateless, Stateful และ Application-Aware Firewall

IDS กับ IPS

IDS ตรวจและแจ้งเตือน ส่วน IPS อยู่ในเส้นทางและบล็อกได้ Signature ตรวจรูปแบบที่รู้จัก ขณะที่ anomaly detection หาเหตุการณ์ที่ต่างจาก baseline แต่เสี่ยง false positive มากขึ้น ระบบตรวจจับที่แจ้งเตือนทุกอย่างจนไม่มีใครอ่าน เท่ากับมีสัญญาณกันขโมยที่ดังตลอดวันและสุดท้ายถูกถอดปลั๊ก

Segmentation และ Least Privilege

การแบ่ง zone ไม่ควรอาศัยความเชื่อว่า “ข้างในปลอดภัย” อย่างเดียว ผู้ใช้และ service ควรเข้าถึงเท่าที่ต้องใช้ ถ้า Web server ใน DMZ ถูกยึด มันไม่ควรเชื่อมฐานข้อมูลทุกตัวหรือเปิด remote administration ไปทุกเครื่อง Microsegmentation ลด blast radius โดยยอมเพิ่มงานออกแบบ identity, policy และ observability

12Zero Trust ไม่ได้แปลว่าไม่เชื่อใครเลย

Zero Trust เน้นไม่ให้ตำแหน่งเครือข่ายเป็นหลักฐานความน่าเชื่อถือเพียงอย่างเดียว ทุก request ควรประเมิน identity, device, context และ policy พร้อมให้สิทธิ์เท่าที่จำเป็น แนวคิดนี้ไม่ได้สั่งให้เลิก firewall หรือเข้ารหัส แต่เพิ่มการตัดสินใจที่ละเอียดกว่าคำว่า inside/outside

13Wi-Fi Security: จาก WPA2 ถึง WPA3

WPA2-Personal ใช้รหัสลับร่วมกัน หาก passphrase อ่อน ผู้โจมตีที่เก็บ handshake อาจลองเดาแบบ offline ได้ WPA3-Personal ใช้ SAE ซึ่งออกแบบให้ต้านการเดา offline ได้ดีขึ้นและให้ forward secrecy ในระดับการเชื่อมต่อ ส่วน Enterprise ใช้ 802.1X/EAP กับระบบยืนยันตัวตนกลาง แต่ความปลอดภัยยังขึ้นกับชนิด EAP, certificate validation และการตั้งค่า client

การซ่อน SSID หรือกรอง MAC ไม่ใช่มาตรการหลัก SSID ยังปรากฏผ่านการสื่อสารอื่นได้ และ MAC ปลอมได้ง่าย ควรเน้น authentication ที่แข็งแรง firmware ที่อัปเดต network segmentation และปิด WPS เมื่อไม่จำเป็น

14VPN และ IPsec: Tunnel ไม่ได้แก้ทุก Trust Problem

VPN สร้างช่องทางป้องกันผ่านเครือข่ายที่ไม่เชื่อถือ แต่เมื่อ traffic ออกจาก tunnel endpoint จะถูกจัดการตามเครือข่ายปลายทางอีกครั้ง Remote-access VPN พาผู้ใช้เข้าเครือข่ายองค์กร จึงต้องตรวจอุปกรณ์และจำกัดสิทธิ์ ไม่ควรถือว่าเครื่องที่ต่อ VPN แล้วปลอดภัยกว่าทุกอย่างโดยอัตโนมัติ

IPsec tunnel mode ป้องกัน IP packet ชั้นในระหว่าง gateway ส่วน transport mode ป้องกัน payload ของ IP packet เดิมตามรูปแบบที่ใช้ ในระบบจริง ESP พบมากกว่า AH เพราะ NAT และความต้องการ confidentiality การบอกว่า IPsec เป็น mandatory ใน IPv6 ก็ควรระวัง: มาตรฐานรองรับ IPsec แต่ไม่ได้หมายความว่า traffic IPv6 ทุกก้อนถูกเข้ารหัสโดยอัตโนมัติ

15Incident Thinking: ป้องกัน ตรวจพบ ตอบสนอง และฟื้นตัว

Security ไม่จบเมื่อ deploy control ระบบต้องมี log ที่เชื่อมเวลาได้ alert ที่มีเจ้าของ runbook สำหรับเหตุการณ์สำคัญ การแยกเครื่องที่ถูกยึด การหมุนกุญแจ และ backup ที่ทดสอบกู้คืนแล้ว การมี backup แต่ไม่เคย restore เหมือนมีร่มชูชีพที่ยังอยู่ในกล่องและไม่รู้ว่าเปิดได้หรือไม่

16Replay, Freshness และ Session Binding

ข้อความที่มีลายเซ็นถูกต้องอาจยังเป็นอันตรายหากผู้โจมตีบันทึกแล้วส่งซ้ำ เช่นคำสั่งโอนเงินเดิม Authentication บอกว่าใครสร้างข้อความ แต่ไม่บอกว่าข้อความใหม่หรือใช้ใน session นี้ ระบบจึงต้องใช้ nonce, sequence number, timestamp หรือ challenge ผูกข้อความกับบริบทและปฏิเสธของเก่า

Randomness คือ Dependency ด้าน Security

Key, nonce และ token ต้องมาจาก cryptographically secure random generator หาก entropy ต่ำ ผู้โจมตีเดาค่าได้แม้ algorithm แข็งแรง VM ที่ clone state หรืออุปกรณ์ embedded ที่เริ่มระบบคล้ายกันอาจสร้างค่าซ้ำ การตรวจแหล่ง randomness และห้าม reuse nonce ตามข้อกำหนดของ cipher จึงเป็นส่วนหนึ่งของ protocol design

17Password, MFA และ Session Security

Password ควรเก็บด้วย password hashing function เช่น Argon2id, scrypt, bcrypt หรือ PBKDF2 ตามบริบท พร้อม salt เฉพาะบัญชีและ cost ที่ปรับตามกำลังเครื่อง ไม่ควรถอดกลับได้ การเข้ารหัส password ไว้ด้วย key กลางสร้างจุดที่เมื่อ key รั่ว password ทุกบัญชีถูกเปิดพร้อมกัน

MFA ป้องกันอะไร

MFA ลดผลจาก password รั่ว แต่ชนิด factor ต่างกัน OTP ทาง SMS ยังถูกโจมตีผ่าน SIM swap หรือ phishing แบบ real-time ได้ TOTP ดีกว่าในหลายกรณีแต่ยังถูกหลอกกรอก ส่วน FIDO2/WebAuthn ผูกการตอบกับ origin และใช้ public-key credential จึงต้าน phishing ได้มากกว่า อย่างไรก็ตาม recovery flow ที่อ่อนแอสามารถกลายเป็นประตูหลังของ MFA ที่แข็งแรง

Session Token คือกุญแจชั่วคราว

หลัง login ระบบมักออก session cookie หรือ access token ผู้ที่ขโมย token อาจไม่ต้องรู้ password จึงต้องใช้ TLS, Secure/HttpOnly/SameSite ตามบริบท จำกัดอายุ scope และ revoke เมื่อมีเหตุ Token ที่อยู่ได้นานและใช้ได้ทุกบริการเพิ่ม blast radius แม้ระบบ login จะแข็งแรง

18Security ตามชั้นของเครือข่าย

การป้องกันชั้นล่างครอบคลุม application หลายตัวได้ แต่ endpoint อาจกว้างและไม่เข้าใจความหมายของข้อมูล การป้องกันระดับ application ผูก policy กับ user และ field ได้ละเอียด แต่ต้องสร้างในแต่ละระบบ Defense in depth จึงวาง control หลายระดับโดยรู้ว่าแต่ละชั้นสิ้นสุดตรงไหน

End-to-End กับ Hop-by-Hop

Email อาจใช้ TLS ระหว่าง mail server ทีละช่วง แต่ server กลางอ่านเนื้อหาได้ หากต้องการให้มีเพียงผู้ส่งกับผู้รับอ่าน ต้องเข้ารหัสตัวข้อความแบบ end-to-end เช่น OpenPGP หรือ S/MIME ในทางกลับกัน end-to-end encryption อาจทำให้ gateway ตรวจ malware หรือ DLP ได้ยากขึ้น Security objective สองด้านจึงอาจขัดกันและต้องตัดสินเชิงนโยบาย

19DNS และ Email Security

DNSSEC กับ DoH/DoT

DNSSEC ใช้ลายเซ็นช่วยตรวจที่มาและ integrity ของ DNS record ตาม chain of trust แต่ไม่ได้เข้ารหัส query ส่วน DoH/DoT เข้ารหัสช่องทางระหว่าง client กับ resolver แต่ resolver ยังเห็นชื่อและคำตอบ กลไกหนึ่งเน้นความถูกต้องของข้อมูล อีกกลไกเน้นความลับของช่องทาง จึงไม่แทนกัน

SPF, DKIM และ DMARC

SPF ประกาศว่า server ใดส่ง mail ในนาม domain ได้ DKIM ลงลายเซ็นส่วนของข้อความด้วย key ของ domain ส่วน DMARC กำหนด alignment และ policy เมื่อการตรวจไม่ผ่าน ทั้งสามลด domain spoofing แต่ไม่รับรองว่า account ภายในไม่ถูกยึดหรือเนื้อหาไม่หลอกลวง

20การออกแบบ Firewall Rule แบบคิดจาก Flow

กฎ “อนุญาต port 443” กว้างเกินไปหากไม่บอก source, destination, direction และเหตุผล ควรเริ่มจาก data flow ที่จำเป็น เช่น Internet → reverse proxy:443, reverse proxy → application:8443, application → database:5432 และปฏิเสธเส้นทางอื่นโดยค่าเริ่มต้น พร้อมบันทึก owner กับวันทบทวน

Stateful firewall อนุญาต response ของ connection ที่เริ่มจากฝั่งถูกต้องได้โดยไม่ต้องเปิด inbound port กว้าง แต่ UDP ไม่มี connection state แบบ TCP Firewall จึงสร้าง pseudo-state จาก tuple และ timeout หาก timeout ไม่เหมาะ application อาจขาดหรือช่องเปิดอยู่นานเกินจำเป็น

21Security Observability และ Detection Engineering

Log ที่มีประโยชน์ต้องตอบ identity, source, action, target, result และเวลา โดยไม่เก็บ secret เกินจำเป็น ควรส่งไปยังที่ซึ่งผู้โจมตีแก้ย้อนหลังได้ยากและรักษาเวลาของเครื่องให้ตรงกัน มิฉะนั้น event จากหลายระบบเรียงเหตุการณ์ไม่ได้

จาก Alert ไปเป็น Detection

Rule ที่พบ login ผิดหนึ่งครั้งสร้าง noise แต่รูปแบบผิดหลายประเทศภายในนาทีเดียวแล้วสำเร็จจากอุปกรณ์ใหม่มีบริบทมากกว่า Detection ที่ดีระบุ hypothesis, data source, threshold, false positive ที่คาด และขั้นตอนตรวจต่อ ไม่ใช่เพียงค้น keyword แล้วส่งอีเมล

ตัวชี้วัดที่ควรระวัง

22กรณีศึกษา: API Key รั่วใน Repository

1. ถือว่า key ถูกเปิดเผยทันที แม้ commit ถูกลบ เพราะอาจถูก clone หรือ cache แล้ว
2. Revoke และออก key ใหม่ก่อน ไม่รอพิสูจน์ว่ามีคนใช้หรือไม่
3. ค้น log ว่า key ถูกใช้จากที่ใด เวลาใด และเข้าถึงข้อมูลอะไร
4. ตรวจ history, build artifact, CI log และ package ที่อาจมีสำเนา
5. ย้าย secret ไป secret manager จำกัด scope และอายุ
6. เพิ่ม secret scanning และ pre-commit/CI control เพื่อป้องกันซ้ำ

การ rotate key อย่างเดียวแก้อาการ แต่ไม่แก้กระบวนการ หาก developer ยังต้องคัด secret ลงไฟล์ทุกวัน เหตุการณ์จะกลับมา Security engineering จึงต้องทำทางที่ปลอดภัยให้ใช้ง่ายกว่าทางที่เสี่ยง

23กรณีศึกษา: Ransomware และ Availability

Ransomware แสดงว่า security ไม่ได้มีเพียง confidentiality ระบบต้องแยก privilege, จำกัด lateral movement, ตรวจพฤติกรรมผิดปกติ และมี backup ที่ immutable หรือแยก credential จาก production Backup ต้องทดสอบ restore พร้อมวัด Recovery Time Objective และ Recovery Point Objective

24Checklist ก่อนเปิดบริการสู่ Internet

25Software Supply Chain Security

Application อาจเขียน code เองเพียงส่วนหนึ่ง ที่เหลือมาจาก package, container image, compiler และ CI/CD หาก dependency หรือ build system ถูกยึด ผู้โจมตีส่ง code ผ่านช่องทางที่องค์กรเชื่อถือได้ การสแกน source อย่างเดียวจึงไม่พอ ต้องรู้ที่มาของ artifact และลดสิทธิ์ของ pipeline

26Secure Key Lifecycle

Key มีวงจรตั้งแต่สร้าง แจก เก็บ ใช้ หมุน เพิกถอน สำรอง และทำลาย การใช้ algorithm แข็งแรงแต่เก็บ private key ในไฟล์ที่ทุก process อ่านได้ทำให้ระบบอ่อนแอ HSM หรือ KMS ช่วยจำกัดการเข้าถึงและบันทึกการใช้ แต่ policy กับ identity ที่เรียก KMS ยังต้องปลอดภัย

27Privacy ต่างจาก Security

ระบบอาจเข้ารหัสและควบคุมสิทธิ์ดี แต่เก็บข้อมูลมากเกินจำเป็นหรือใช้เกินวัตถุประสงค์ Privacy จึงถามเพิ่มว่าเก็บอะไร เพราะอะไร นานเท่าใด ใครใช้ และผู้ใช้ควบคุมได้เพียงใด Data minimization ลดทั้งผลกระทบด้าน privacy และ blast radius เมื่อ breach

Metadata ยังบอกเรื่องราว

แม้ content เข้ารหัส ผู้สังเกตอาจเห็นคู่สื่อสาร เวลา ขนาด และความถี่ของ traffic จากรูปแบบเหล่านี้อาจอนุมานกิจกรรมได้ Encryption จึงจำเป็นแต่ไม่ทำให้ anonymous อัตโนมัติ ระบบที่ต้องปกปิดความสัมพันธ์ต้องมีกลไกเพิ่มเติมและยอมรับต้นทุนด้าน latency/bandwidth

28Security Testing หลายระดับ

การผ่าน scan ไม่ได้แปลว่าปลอดภัย และพบ CVE ไม่ได้แปลว่าต้องหยุดทุกอย่างทันที Risk prioritization ต้องดู exposure, exploitability, privilege, data impact และ compensating control พร้อมกำหนดเวลาจัดการที่ตรวจสอบได้

29Security Anti-Patterns

• เชื่อว่าอยู่หลัง firewall แล้วไม่ต้อง authenticate service ภายใน
• ใช้ shared administrator account จนระบุผู้กระทำไม่ได้
• เก็บ secret ใน source code หรือ image แล้วหวังว่า repository เป็น private
• ปิด certificate validation เพื่อแก้ error ชั่วคราวแล้วไม่เปิดกลับ
• สร้าง encryption algorithm เองเพราะ library “ซับซ้อนเกินไป”
• เก็บ log ทุกอย่างรวม password/token จนระบบ log กลายเป็นแหล่งข้อมูลรั่ว
• มี backup ออนไลน์ด้วย credential ชุดเดียวกับ production
• ซื้อเครื่องมือเพิ่มโดยไม่มีคนรับผิดชอบ alert และ response

30Data at Rest, in Transit และ in Use

ข้อมูลมีความเสี่ยงต่างกันตามสถานะ in transit เดินระหว่าง endpoint จึงใช้ TLS/IPsec หรือ message protection at rest อยู่ใน disk, database และ backup จึงใช้ storage encryption กับ access control ส่วน in use อยู่ใน memory ที่ application ต้องอ่านได้ Endpoint ที่ถูกยึดจึงอ่านข้อมูลได้แม้ disk กับ network เข้ารหัส

Full-disk encryption ช่วยเมื่อ disk หรือเครื่องถูกขโมยขณะปิด แต่เมื่อระบบ boot และ key ถูกปลด Application กับผู้โจมตีที่ได้ privilege อาจอ่านไฟล์ได้ Column-level หรือ application-level encryption จำกัดขอบเขตเพิ่ม แต่ทำ query, key management และ rotation ซับซ้อนขึ้น ต้องเลือกจาก threat model ไม่ใช่เข้ารหัสซ้อนให้มากที่สุด

Backup และ Key Dependency

Backup ที่เข้ารหัสต้องสำรอง key อย่างปลอดภัย หาก key หายข้อมูลกู้ไม่ได้ หากเก็บ key ข้าง backup ผู้ขโมยได้ทั้งสองอย่าง การออกแบบ recovery ต้องทดสอบทั้ง restore data, restore key และสิทธิ์ของทีมฉุกเฉิน พร้อม audit การใช้ key นอกเวลาปกติ

31Human และ Process เป็นส่วนของ Protocol

ระบบอาจใช้ cryptography ถูกต้องแต่เจ้าหน้าที่ถูกหลอกให้ reset MFA หรืออนุมัติ certificate ผิด Social engineering โจมตีขั้นตอนที่มนุษย์ทำแทนการเจาะ cipher การออกแบบควรมี verification หลายช่องทางสำหรับงานสำคัญ จำกัดสิทธิ์ help desk และแจ้งเตือนผู้ใช้เมื่อ recovery information เปลี่ยน

Change Management

Firewall rule ชั่วคราว certificate exception และ shared account มักเกิดจากเหตุเร่งด่วน หากไม่มีวันหมดอายุ owner และ review มันจะกลายเป็นโครงสร้างถาวร ควรสร้าง break-glass process ที่บันทึกเหตุผล จำกัดเวลา และตรวจย้อนหลัง เพื่อให้ความเร็วในการแก้ incident ไม่สร้างช่องโหว่ระยะยาว

32สรุปและขั้นตอนถัดไป

การออกแบบที่ปลอดภัยไม่ได้เริ่มจากซื้อ firewall หรือเลือก cipher แต่เริ่มจากรู้ว่าข้อมูลเดินทางอย่างไร ใครควรเข้าถึง และหาก control หนึ่งล้มยังเหลืออะไรป้องกันอยู่ ทุกข้อยกเว้น เส้นทางกู้บัญชี และคนที่มีสิทธิ์ฉุกเฉินเป็นส่วนของระบบเดียวกัน จึงต้องทดสอบพร้อมกับ protocol และ code ไม่ใช่ตรวจเฉพาะเอกสารก่อนเปิดบริการ

Security ที่ใช้งานได้จริงจึงเป็นความสามารถของระบบและองค์กร ไม่ใช่คุณสมบัติของผลิตภัณฑ์ชิ้นใดชิ้นหนึ่ง