โครงสร้างพื้นฐานเครือข่ายระบบคลาวด์ (Cloud-based Networking)
2.4 ระบบเครือข่ายคลาวด์คอมพิวเตอร์ปลอดภัย (Cloud VPC & Network Topology)
การสร้างระบบจัดเก็บข้อมูลและท่อส่งประมวลผลจำเป็นต้องอยู่ภายใต้กรอบการรักษาความปลอดภัยระดับเครือข่ายขั้นสูงสุด เพื่อปิดกั้นการเข้าถึงจากช่องทางสาธารณะภายนอกและกักกันสิทธิ์ใช้งานเฉพาะโฮสต์ที่มีความน่าเชื่อถือ
3D Isometric Secure Cloud VPC Subnet Routing Architecture
1. การออกแบบที่อยู่ IP เครือข่าย VPC (VPC & CIDR Block Design)
ทฤษฎีและกลไกการทำงาน (How it works): **VPC (Virtual Private Cloud)** คือการจัดแบ่งเครือข่ายแยกส่วนเสมือนจริงในระบบคลาวด์ การประกาศขนาดของ VPC ต้องกำหนดค่าไอพีแบบ **CIDR (Classless Inter-Domain Routing)** ในรูปแบบ `A.B.C.D/Mask` ค่าตัวเลข Mask ด้านหลังจะเป็นตัวระบุจำนวนบิตของที่อยู่ IP ที่จองไว้เป็นตัวเลขเครือข่ายคงที่ เช่น `/16` จะจองช่วงไอพีคงที่ไว้ 2 Octets แรก ทำให้มีพื้นที่ IP ย่อยใช้สอยได้ $2^{32-16} = 65,536$ ที่อยู่ ซึ่งเราต้องระมัดระวังไม่ให้ที่อยู่ IP ของ VPC นี้ไปชนทับกับที่อยู่อื่นของเครือข่ายในองค์กรเมื่อทำการเชื่อมต่อข้ามฝั่ง
# Example block design for a production VPC network
VPC CIDR Range: 10.0.0.0/16 (Allows 65,536 IPs)
- Public Subnet US-East-1A: 10.0.1.0/24 (Allows 256 IPs)
- Private Subnet US-East-1A: 10.0.10.0/24 (Allows 256 IPs)
- Database Subnet US-East-1A: 10.0.20.0/24 (Allows 256 IPs)
Use Case ในชีวิตจริง (Real-world Scenario): วิศวกรคลาวด์ดีไซน์เครือข่าย VPC ขนาดกลางสำหรับแอปพลิเคชันข้อมูลขององค์กร โดยกำหนดย่าน IP ไว้ที่ `10.100.0.0/16` เพื่อหลีกเลี่ยงไม่ให้ชนกับระบบโครงข่ายภายในออนพรีมิส (On-premise network) ที่จองย่าน `10.0.0.0/16` เอาไว้ก่อน
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การจัดสรรขนาด CIDR เล็กเกินไป (เช่น `/28` ซึ่งมีเพียง 16 ไอพี) อาจทำให้ไอพีในซับเน็ตไม่เพียงพอเมื่อต้องขยายโหนดคอมพิวเตอร์แบบขนาน (Auto-scaling) แก้ไขโดยจัดทำแผนงานสเปซไอพีล่วงหน้าและเลือกประกาศ CIDR ขนาดกลางเช่น `/16` สำหรับ VPC และ `/24` (256 ไอพี) สำหรับแต่ละ Subnet
2. การแบ่งสัดส่วนเครือข่ายสาธารณะและส่วนตัว (Public vs. Private Subnets)
ทฤษฎีและกลไกการทำงาน (How it works): เพื่อคุมมาตรฐานความปลอดภัยของเครื่องเซิร์ฟเวอร์ เราต้องแยกซับเน็ตออกเป็น 2 ประเภทหลัก: - **Public Subnet**: ซับเน็ตที่ Route Table มีการจัดเส้นทางปลายทางชี้ไปยัง **Internet Gateway (IGW)** ทำให้อุปกรณ์ในซับเน็ตนี้ได้สิทธิ์สองทางในการคุยกับสาธารณะภายนอก - **Private Subnet**: ซับเน็ตที่ไม่มีเส้นทางออกอินเทอร์เน็ตโดยตรงผ่าน IGW โฮสต์ภายในจะไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตภายนอก ถือเป็นสถานที่ปลอดภัยสำหรับวางข้อมูลสำคัญ
# Route Table configuration for Public Subnet:
Destination: 0.0.0.0/0 -> Target: igw-xxxxxxxx (Internet Gateway)
Destination: 10.0.0.0/16 -> Target: local
# Route Table configuration for Private Subnet:
Destination: 0.0.0.0/0 -> Target: nat-xxxxxxxx (NAT Gateway)
Destination: 10.0.0.0/16 -> Target: local
Use Case ในชีวิตจริง (Real-world Scenario): โครงสร้างพื้นฐานของระบบ ETL วางเซิร์ฟเวอร์ Airflow Worker ที่ต้องดึงข้อมูลดิบและคลังข้อมูล ClickHouse ไว้ใน Private Subnet และติดตั้งเฉพาะหน้าเว็บ API Gateway (เช่น Nginx) ไว้ที่ Public Subnet เพื่อคอยคัดกรองคำขอจากอินเทอร์เน็ต
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การวางเซิร์ฟเวอร์ฐานข้อมูลวิเคราะห์ไว้ผิดที่ใน Public Subnet เป็นความสุ่มเสี่ยงต่อการโดนสแกนพอร์ตเพื่อโจมตีและขโมยข้อมูล แก้ไขโดยย้ายระบบฐานข้อมูลและแอปพลิเคชันประมวลผลทั้งหมดลง Private Subnet ทันทีและสถาปนาการเข้าถึงระบบควบคุมข้ามทางผ่าน Bastion Host เท่านั้น
3. การทำงานของ Internet Gateways และ NAT Gateways ในโครงข่าย
ทฤษฎีและกลไกการทำงาน (How it works): ตัวประสานสองจุดเชื่อมต่อ: - **Internet Gateway (IGW)**: อุปกรณ์เสมือนเชื่อมต่อระหว่าง VPC และอินเทอร์เน็ตสาธารณะ ทำงานแบบไร้สถานะและไม่จำกัดแบนด์วิดท์ - **NAT Gateway (Network Address Translation)**: อุปกรณ์ใน Public Subnet ทำหน้าที่แปลงที่อยู่ IP ส่วนตัวให้กลายเป็น IP สาธารณะ (NAT) เพื่อให้โฮสต์จาก Private Subnet สามารถสื่อสารยิงข้อความออกนอกอินเทอร์เน็ตเพื่อดาวน์โหลดแพ็กเกจหรืออัปเดตระบบได้ โดยจะปฏิเสธไม่ให้สัญญาณภายนอกเจาะจงวิ่งสวนกลับเข้ามาหา Private Host (การสื่อสารทางเดียว)
# Concept of Network Address Translation flow:
Private Host (10.0.10.15) sends request to external API (142.250.4.1)
-> Sent via Private Route Table to NAT Gateway (Public IP: 54.12.34.56)
-> NAT Gateway translates packet headers: Source IP becomes 54.12.34.56
-> Packet is routed via Internet Gateway to 142.250.4.1
Use Case ในชีวิตจริง (Real-world Scenario): ตัวดึงข้อมูลในระบบจ๊อบของ Spark ค้างในซับเน็ตส่วนตัวต้องการดึงข้อมูลพยากรณ์อากาศจาก API นอกคลาวด์เพื่อรันสรุปสถิติ โดยทรานแซกชันจะสามารถดึงค่าได้ปกติผ่าน NAT Gateway ในขณะที่เซิร์ฟเวอร์หลักยังคงปลอดภัยจากการเจาะ
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ตัว NAT Gateway มีค่าบริการรายชั่วโมงและค่าแบนด์วิดท์ส่งผ่านข้อมูลที่ค่อนข้างสูง หากท่อข้อมูลหลักโหลดข้อมูลขนาดใหญ่ระดับเทราไบต์ข้ามผ่าน NAT บิลค่าไฟคลาวด์จะพุ่งขึ้นมหาศาล แก้ไขโดยเปิดใช้งาน **VPC Endpoints** (ทางลัดส่วนตัวเชื่อมหาบริการ S3 หรือ BigQuery ภายในระบบคลาวด์เดียวกันโดยไม่ยอมให้ข้อมูลวิ่งอ้อมผ่าน NAT Gateway)
4. ความแตกต่างระหว่างระบบ Network ACLs (Stateless) และ Security Groups (Stateful)
ทฤษฎีและกลไกการทำงาน (How it works): การคุมกฎความปลอดภัยด้านพอร์ตเครือข่ายแบ่งออกเป็นสองด่านหลัก: - **Network ACLs (NACLs)**: ไฟร์วอลล์ด่านแรกคุมระดับ Subnet ทำงานแบบ **ไร้สถานะ (Stateless)** หมายความว่ากฎขาเข้า (Inbound) และขาออก (Outbound) ต้องระบุแยกจากกันอย่างชัดเจน หากอนุญาตขาเข้าแต่ลืมตั้งขาออก สัญญาณจะตอบกลับไปไม่ได้ - **Security Groups (SGs)**: ไฟร์วอลล์ระดับตัวโฮสต์คอมพิวเตอร์รายตัว ทำงานแบบ **จำสถานะ (Stateful)** หมายความว่าหากอนุญาตสัญญาณขาเข้าให้ผ่านได้แล้ว สัญญาณตอบรับขากลับจะได้รับอนุมัติออกนอกอัตโนมัติโดยไม่ต้องตั้งกฎขาออกแยกอีกครั้ง
| คุณสมบัติ | Network ACLs (Subnet level) | Security Groups (Host level) |
|---|---|---|
| สถานะทำงาน | Stateless (ไร้สถานะ) | Stateful (จำสถานะ) |
| กฎการอนุญาต | รองรับทั้งกฎยอมรับ (Allow) และปฏิเสธ (Deny) | รองรับเฉพาะกฎยอมรับ (Allow) เท่านั้น |
5. การจัดเชื่อมต่อแบบ VPC Peering และการใช้กลไก PrivateLink
ทฤษฎีและกลไกการทำงาน (How it works): เมื่อมีระบบงานข้อมูลกระจายอยู่คนละ VPC หรือต่างบัญชีคลาวด์ การเชื่อมโยงให้หากันทำได้ผ่าน 2 เทคนิค: - **VPC Peering**: เชื่อม VPC สองฝั่งเข้าหากันโดยตรงด้วยเราเตอร์เสมือน ข้อมูลวิ่งหากันผ่านโครงข่ายแบ็คโบนภายในของคลาวด์เสมือนอยู่วงแลนเดียวกัน ทรานแซกชันจะสามารถสแกนหากันได้ทุกพอร์ตหากไม่บล็อก - **AWS PrivateLink / VPC Endpoint Services**: เชื่อมโยงผ่านสถาปัตยกรรมแบบ Service Provider/Consumer โดยข้อมูลจะวิ่งผ่านเครือข่ายส่วนตัวด้วยพอยน์เตอร์การ์ดแลนพิเศษ (Elastic Network Interface - ENI) ยอมให้สื่อสารเฉพาะบริการพอร์ตเป้าหมายที่ระบุเท่านั้น ป้องกันไม่ให้เครือข่ายทั้งสองวงเห็นหน้าตาของโครงข่ายกันทั้งหมด
# Concept of VPC Peering vs PrivateLink connection interfaces
VPC Peering:
VPC A (10.0.0.0/16) <==================> VPC B (10.1.0.0/16)
Full network-to-network connectivity over internal backbone routing.
VPC PrivateLink (Gateway / Interface Endpoint):
VPC A (10.0.0.0/16) -> ENI (10.0.1.45) --------[ PrivateLink ]--------> Target Service (S3/Redshift)
Only specific ports of target service are exposed locally.
Use Case ในชีวิตจริง (Real-world Scenario): บริษัทฟินเทคต้องการให้ระบบดึงข้อมูลไปดึงตารางจากผู้ให้บริการภายนอกคลาวด์ โดยเลี่ยงไม่เปิดเครือข่ายชนกับคู่ค้าผ่าน VPC Peering จึงเลือกตั้งจุดเชื่อมแบบ PrivateLink ยิงตรงไปหาพอร์ตบริการคิวรีข้อมูลของคู่ค้า ทำให้ข้อมูลไหลลื่นและมั่นคงปลอดภัย
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การทำ VPC Peering จะล้มเหลวทันทีและไม่สามารถเชื่อมต่อกันได้หากย่าน CIDR ของ VPC ทั้งสองฝั่งมีช่วง IP **ทับซ้อนกัน** (Overlapping CIDR Blocks) แก้ไขโดยศึกษาการตั้งค่าช่วง IP ให้มีเอกลักษณ์แต่แรก หรือแก้ปัญหาย้อนหลังด้วยการใช้ PrivateLink หรือการติดตั้งเราเตอร์แปลงพิกัด (NAT Gateway) จัดสเปคไอพีแยกเฉพาะบริการ
🛠️ Weekend Sandbox Challenge: Deploy Private Database Network
โจทย์ปฏิบัติการ: จงออกแบบและเขียนไดอะแกรมสถาปัตยกรรมเครือข่ายความปลอดภัยเพื่อจัดวางฐานข้อมูล โดยแบ่งพาร์ทิชัน VPC ออกเป็นซับเน็ตสาธารณะ (Public Subnet) สำหรับรับโหลดแอปพลิเคชัน และซับเน็ตส่วนตัว (Private Subnet) สำหรับเก็บฐานข้อมูล
# Concept VPC Network configurations architecture
VPC CIDR: 10.0.0.0/16
├── Public Subnet (10.0.1.0/24) -> Route Table maps to Internet Gateway
│ └── EC2 Application Instance (Public IP enabled)
└── Private Subnet (10.0.2.0/24) -> Route Table maps to NAT Gateway
└── RDS PostgreSQL Instance (Private IP only)
💼 Senior Technical Interview Q&A
Q1: ความแตกต่างในการปิดกั้นการเข้าถึงระดับเครือข่ายระหว่าง Security Groups และ Network Access Control Lists (NACLs) บน AWS คืออะไร?
A1: Security Groups ทำงานระดับอินสแตนซ์เครื่อง (Instance level) เป็นแบบจำสถานะ (Stateful) โดยสัญญารับเข้าจะเปิดส่งออกให้อัตโนมัติ ในขณะที่ NACLs ทำงานระดับซับเน็ตเครือข่าย (Subnet level) เป็นแบบไร้สถานะ (Stateless) ที่ต้องเขียนกฎระเบียบอนุญาตทิศทางข้อมูลทั้งขาเข้าและขาออกแยกจากกัน
Q2: ทำไมความปลอดภัยในการเก็บข้อมูลดิบ (Raw Datalake) จึงกำหนดให้ใช้ NAT Gateway แทนการต่อตรงอินเทอร์เน็ตผ่าน Internet Gateway?
A2: Internet Gateway เปิดทิศทางการคุยแบบสองทิศทาง ทำให้ผู้ใช้อินเทอร์เน็ตภายนอกสามารถโจมตียิงพอร์ตของอินสแตนซ์ในซับเน็ตได้โดยตรง ในขณะที่ NAT Gateway ยินยอมเฉพาะโหนดในซับเน็ตส่วนตัวส่งข้อมูลออกไปหาอินเทอร์เน็ต (เช่น ดาวน์โหลดไฟล์อัปเดต) แต่บล็อกการเข้าถึงยิงพอร์ตจากภายนอกเข้ามาอย่างเด็ดขาด
ข้อดี / จุดเด่น & ข้อเสีย / ข้อควรระวัง
ข้อดี / จุดเด่น
- • สเกลขนาดทรัพยากรขึ้นลงได้ตามความต้องการ จ่ายเงินตามจริงรายนาที
- • ระบบมีความน่าเชื่อถือสูง มีการสำรองฮาร์ดแวร์แบบ Multi-AZ อัตโนมัติ
ข้อเสีย / ข้อควรระวัง
- • สามารถโดนคิดเงินบานปลายได้หากไม่ได้ตั้งสัญญาณเตือนและลืมปิดเครื่องเซิร์ฟเวอร์
- • การเชื่อมต่อเน็ตเวิร์กที่ซับซ้อนอาจทำให้การดีบักเวลาระบบเชื่อมต่อไม่ผ่านทำได้ยาก
ปฏิบัติการจริง (Lab Practice)
แล็บ: ออกแบบเครือข่ายและสิทธิ์การเข้าถึงคลังข้อมูลอย่างปลอดภัย
💡 คำแนะนำ & ทริกเด็ด
สำหรับงานประมวลผลข้อมูลขนาดใหญ่ การย้ายข้อมูลดิบข้าม Region หรือข้าม Cloud Provider จะโดนคิดเงินค่าโอนย้ายข้อมูล (Egress Fee) แพงมาก แนะนำให้ตั้งคลัสเตอร์ประมวลผลไว้ใน Region เดียวกับที่เก็บข้อมูลหลัก