การปกป้องข้อมูลระหว่างส่งผ่านเครือข่าย: TLS, VPN และเครือข่ายภายใน

เวลาทีมวิศวกรรมพูดคุยเรื่องการรักษาความปลอดภัยของข้อมูลระหว่างส่งผ่านเครือข่าย คำตอบแรกมักง่ายมาก: “ใส่ HTTPS ให้มันซะ” สำหรับทราฟฟิกเว็บสาธารณะ TLS กลายเป็น baseline ที่ทุกคนถือว่าต้องมีอยู่แล้ว แต่การมองการเข้ารหัสระหว่างส่งผ่านเป็นเพียง check box อัตโนมัติ ทำให้เรามองข้ามว่า network security ทำงานจริงอย่างไร protocol พังตรงจุดไหน และผู้โจมตีดักจับทราฟฟิกภายใน environment สมัยใหม่ได้ทางไหน

ข้อมูลระหว่างส่งผ่าน (data in transit) ครอบคลุมทุก byte ที่วิ่งผ่านสายเครือข่าย คลื่นวิทยุ หรือ virtual overlay การปกป้องทราฟฟิกเหล่านี้ต้องตอบคำถามที่แตกต่างกันสามข้อ:

1. จะยืนยันตัวตนของระบบปลายทางอีกฝั่งอย่างไร
2. จะกันคนดักฟัง (eavesdropper) ไม่ให้อ่าน payload ได้อย่างไร
3. จะกันตัวกลางแอบแก้ไขข้อมูลโดยไม่มีใครรู้อย่างไร

เพื่อสร้างสถาปัตยกรรมที่ตั้งอยู่ได้จริงและผ่านมาตรฐานอย่าง PCI DSS Requirement 4 วิศวกรต้องเข้าใจว่า TLS ทำงานใต้ฝากระโปรงอย่างไร มันรับประกันอะไร (และไม่รับประกันอะไร) และ hop ภายในเครือข่าย, cluster แบบ containerised และ VPN เปลี่ยนสมการนี้อย่างไร

TLS ทำงานอย่างไร: TCP Handshake และการเจรจา TLS #

Transport Layer Security (TLS ปัจจุบันใช้กันที่เวอร์ชัน 1.2 และ 1.3) นั่งอยู่ระหว่าง transport layer (TCP) กับ application layer (HTTP, SMTP, gRPC) ก่อนที่ข้อมูลแอปพลิเคชันที่เข้ารหัสแม้แต่ byte เดียวจะเริ่มเดินทาง ต้องมี handshake ต่อเนื่องกันสองชุด: TCP 3-way handshake และ TLS cryptographic handshake

ขั้นที่ 1: TCP 3-Way Handshake #

TCP สร้างการเชื่อมต่อแบบ stream สองทางที่เชื่อถือได้ข้ามเครือข่าย:

1. SYN: client ส่ง packet Synchronise พร้อมหมายเลข sequence เริ่มต้น
2. SYN, ACK: server ตอบกลับด้วย packet Synchronise และ Acknowledgement พร้อมหมายเลข sequence ของตัวเอง
3. ACK: client ส่ง Acknowledgement ตัวสุดท้าย ตอนนี้ TCP socket ดิบถูกสร้างเรียบร้อย แต่ยังไม่มีการเข้ารหัสใด ๆ ทั้งสิ้น

ขั้นที่ 2: TLS Cryptographic Handshake (TLS 1.3) #

ใน TLS 1.3 สมัยใหม่ (กำหนดใน RFC 8446) handshake ด้านความปลอดภัยเสร็จใน round-trip เดียว:

1. ClientHello: client ส่ง cipher suite ที่รองรับ พร้อม public key share แบบ ephemeral Diffie-Hellman (ขั้นที่ 4 ในลำดับ)
2. ServerHello & Key Exchange: server เลือก cipher suite ส่ง public key share ของตัวเอง และแสดง certificate X.509 (ขั้นที่ 5)
3. การ derive session key และ Finished: ทั้งสองฝ่ายคำนวณ symmetric key ที่เหมือนกันโดยไม่เคยส่ง secret key ผ่านสายเลย และ client ยืนยันการเสร็จสิ้น (ขั้นที่ 6)
4. Application Traffic: เริ่มแลกเปลี่ยนข้อมูลแอปพลิเคชันที่เข้ารหัสแล้วทันที (ขั้นที่ 7)

นัยสำคัญ: ตัวตนไม่ใช่การเข้ารหัส #

ความเข้าใจผิดที่พบบ่อยคือคิดว่า certificate TLS ที่ valid การันตีความปลอดภัยแบบ end-to-end ความจริงคือ TLS แก้ปัญหาแยกกันสามเรื่อง: Authentication, Integrity และ Confidentiality

• Authentication (ตัวตน): certificate ดิจิทัลพิสูจน์ว่า server ที่ถือครอง domain name นั้นตรงกับ public key ที่นำเสนอ โดยอาศัย Certificate Authority (CA) ที่เชื่อถือได้
• Integrity: Message Authentication Code (HMAC หรือ AEAD tag) ทำให้ packet ถูกแก้ไประหว่างทางไม่ได้
• Confidentiality (การเข้ารหัส): symmetric cipher (อย่าง AES-256-GCM หรือ ChaCha20-Poly1305) ปกปิดเนื้อหา

certificate TLS ที่ valid รับประกันแค่ว่าคุณกำลังคุยกับใคร แต่ไม่รับประกันว่า connection นั้นใช้ protocol ความปลอดภัยรุ่นล่าสุด หรือแม้แต่มีการเข้ารหัสเลย ในอดีตสเปก protocol อนุญาต cipher suite แบบ “null cipher” ที่ authenticate ตัว server ได้แต่ส่งข้อมูลเป็น cleartext นอกจากนี้ server ที่ config พลาดอาจ downgrade เงียบ ๆ ไปใช้ protocol ที่ตกรุ่น (อย่าง TLS 1.0 หรือ 1.1) ที่มี cipher อ่อนแอ เหตุผลที่ framework และหน่วยงานกำกับดูแลจำนวนมากจึงบังคับชุด cipher ที่แข็งแรงแน่นอน เช่น ชุดที่ TLS 1.3 กำหนดอย่างเคร่งครัด

ปัญหา Edge Termination: เครือข่ายสาธารณะ vs เครือข่ายภายใน #

ภายใต้ PCI DSS Requirement 4 องค์กรต้องใช้ cryptography ที่แข็งแรงและ protocol ความปลอดภัยเพื่อปกป้องข้อมูลบัตรที่อ่อนไหวระหว่างส่งผ่านเครือข่ายสาธารณะเปิด (เช่น อินเทอร์เน็ต เครือข่ายมือถือ หรือ Wi-Fi สาธารณะ)

องค์กรส่วนใหญ่ทำสิ่งนี้ที่ edge ด้วย Reverse Proxy, Application Delivery Controller (ADC) หรือ Cloud Load Balancer:

ช่องโหว่ความปลอดภัยภายใน LAN และ environment แบบ containerised #

เมื่อ TLS terminate ที่ edge load balancer แล้ว ทราฟฟิกภายในระหว่าง microservices, database cluster และ cache ภายในมักวิ่งเป็น HTTP cleartext บนเครือข่ายส่วนตัว (LAN, VPC หรือ container network overlay)

ในอดีตวิศวกรมักถือว่าเครือข่ายส่วนตัวน่าเชื่อถือโดยปริยาย แต่มีหลายภัยที่ทำลายสมมติฐานนี้:

• Shared Cloud Infrastructure: ช่องโหว่ข้าม tenant หรือ VPC routing ที่ config พลาด
• Container ภายในที่ถูก compromise: ถ้าผู้โจมตีได้ remote code execution บน container หนึ่ง การรันเครื่องมือดักจับ packet (tcpdump, wireshark) บน container network ที่ไม่เข้ารหัสจะเห็นทราฟฟิก east-west ของ service ข้าง ๆ ทั้งหมด
• Monitoring และ logging proxy: network tap และ service mesh sidecar ที่ log ตัว HTTP body ที่ไม่เข้ารหัส

ถ้าคุณเก็บข้อมูลที่อ่อนไหว การจับคู่ transit security กับคู่มือของเราเรื่อง เทคนิคการทำให้ข้อมูลกำบัง และ การแยกข้อมูลออกจากระบบ จะช่วยให้ node ภายในที่ถูก compromise ไม่สามารถประกอบ credential ทั้งหมดกลับคืนได้

แนวทางทางเลือกในการปกป้องข้อมูลระหว่างส่งผ่าน #

ขึ้นกับ layer ของเครือข่ายและข้อกำหนดทางสถาปัตยกรรม ทีมวิศวกรรมใช้โมเดลการปกป้องหลายแบบ:

1. Mutual TLS (mTLS) และ Service Mesh #

TLS มาตรฐานยืนยันตัวตนเฉพาะ server แต่ Mutual TLS (mTLS) บังคับให้ทั้ง client และ server ต้องแสดงและตรวจสอบ certificate X.509 ฝ่ายละด้าน

Client (Presents Client Cert) ◄────[mTLS Bidirectional Auth]────► Server (Presents Server Cert)

• วิธีทำงาน: ใช้อย่างกว้างขวางใน service mesh (อย่าง Istio, Linkerd หรือ Envoy) และสถาปัตยกรรม Zero Trust ภายใน
• ข้อดี: เข้ารหัสทราฟฟิก east-west แบบ pod-to-pod ใน cluster แบบ containerised ทั้งหมดโดยอัตโนมัติ พร้อมบังคับนโยบาย service identity ที่เข้มงวด
• ข้อแลกเปลี่ยน: ต้องมี Public Key Infrastructure (PKI) ภายในเพื่อดูแลการออก certificate, การหมุนเวียนอัตโนมัติ และการเพิกถอน

2. Virtual Private Network (VPN) และ IPsec Overlay #

VPN ทำงานที่ network layer (Layer 3) ไม่ใช่ application layer (Layer 7):

• IPsec (IP Security): เข้ารหัส IP packet ระหว่าง network gateway หรือ host แต่ละเครื่องโดยใช้ Encapsulating Security Payload (ESP)
• WireGuard / OpenVPN: สร้าง encrypted point-to-point tunnel ระหว่าง server ระยะไกลหรือสำนักงานสาขา
• บทบาทต่อ compliance: PCI DSS ยอมรับ tunnel IPsec หรือ WireGuard ที่ config ถูกต้องว่าเพียงพอสำหรับรักษาความปลอดภัยทราฟฟิกบนเครือข่ายที่ไม่น่าเชื่อถือ แม้ protocol ของแอปพลิเคชันด้านล่างไม่มีการเข้ารหัสในตัว
• ข้อจำกัด: VPN รักษาความปลอดภัยเฉพาะ tunnel ระหว่าง network gateway สองจุด พอ packet ออกจาก tunnel interface แล้ว มันจะวิ่งเป็น plaintext บน subnet ภายในต่อไป

3. การเข้ารหัส Payload ที่ Application Layer (JWE / Envelope Encryption) #

สำหรับ environment ธนาคารที่ต้องการการรับประกันสูง การเข้ารหัสเฉพาะ transport layer อาจยังไม่พอ หน่วยงานกำกับอย่างธนาคารแห่งประเทศไทยบังคับให้เข้ารหัส payload ที่ application layer สำหรับช่องทางการชำระเงินที่อ่อนไหว ตามที่เราเจาะลึกไว้ในบทวิเคราะห์ กฎการเข้ารหัส API payload ของธนาคารแห่งประเทศไทย

ด้วยการเข้ารหัส JSON payload โดยตรงด้วย JSON Web Encryption (JWE) ก่อนส่งผ่าน TLS ข้อมูลจะยังอ่านไม่ได้แม้ TLS จะ terminate ที่ gateway ตัวกลาง, reverse proxy หรือ edge cache

ตารางเปรียบเทียบ: กลไกปกป้องข้อมูลระหว่างส่งผ่าน #

กรอบการตัดสินใจทางสถาปัตยกรรมสำหรับการปกป้องข้อมูลระหว่างส่งผ่าน #

ใช้ลำดับนี้เลือกกลไกที่เหมาะกับ workload ของคุณ:

ประเด็นสำคัญที่ต้องจำ #

1. TLS รับประกันตัวตนของ server ไม่ใช่ความปลอดภัยของ backend: แม่กุญแจสีเขียวใน browser พิสูจน์แค่ว่าใครเป็นเจ้าของ domain แต่ไม่ได้พูดอะไรเรื่องข้อมูลถูกจัดการอย่างปลอดภัยแค่ไหนหลังรับไปแล้ว
2. อย่าปล่อยทราฟฟิก east-west ไว้โดยไม่เข้ารหัส: การ terminate TLS ที่ load balancer ทิ้งช่องให้ microservices ภายในและ query ฐานข้อมูลเปิดรับการดักฟังในเครือข่ายภายใน
3. ใช้ mTLS กับสถาปัตยกรรม containerised: Mutual TLS ให้ทั้งตัวตนเชิง cryptography และการเข้ารหัสการสื่อสาร container-to-container โดยไม่ต้องแก้ code ด้วยมือ
4. แยกขอบเขตความเชื่อถือของเครือข่าย: กัน environment การชำระเงินและฐานข้อมูลสำคัญไว้หลังขอบเขต VPC ที่เข้มงวดพร้อมการควบคุมการเข้าถึงผ่าน firewall
5. จับคู่ความปลอดภัยตอนส่งกับตอนจัดเก็บ: การเข้ารหัสระหว่างส่งผ่านปกป้องข้อมูลเฉพาะตอนมันเคลื่อนที่ พอเขียนลงดิสก์แล้ว ให้พึ่ง การกำบังข้อมูล การ hashing และ tokenisation ที่ถูกต้อง เพื่อปกป้องข้อมูลถาวร

เริ่มจากตรงไหน #

• ตรวจสอบสอบควบคุมความปลอดภัย API: นัด API & Application Security Review เพื่อทดสอบการใช้งาน TLS ความปลอดภัยของ token และการป้องกัน endpoint
• ตรวจขอบเขต compliance: ทำ PCI DSS Gap Assessment เพื่อประเมินการเข้ารหัสทั้งเครือข่ายสาธารณะและส่วนตัวภายใต้ Requirement 4
• ทดสอบเจาะเครือข่าย: ตรวจการแบ่ง segment ภายในและการควบคุมการเข้ารหัสเครือข่ายด้วย บริการ Penetration Testing