พลังของ Minimum Viable Network

การทำความเข้าใจระบบเครือข่ายบนคลาวด์คือหนึ่งในการปรับตัวครั้งใหญ่ที่สุดขององค์กรที่เพิ่งเริ่มต้นเส้นทางสู่คลาวด์ เมื่อพิจารณาโครงสร้างการกำหนด IP address และองค์ประกอบต่าง ๆ มันดูคล้ายเครือข่าย IP ทั่วไป และในมุมมองส่วนใหญ่ก็ใช่ แต่ในอีกหลายด้านกลับไม่ใช่ เครือข่ายแบบ software-defined network (SDN) อย่างที่ให้บริการบนคลาวด์ ไม่ได้ถูกจำกัดด้วยข้อจำกัดเดียวกับเครือข่ายทางกายภาพ ซึ่งอาจสร้างความสับสนไม่น้อยในช่วงเริ่มต้น

แทนที่จะพยายามทำความเข้าใจว่า SDN ต่างจากเครือข่ายทางกายภาพอย่างไร เรามาโฟกัสกันว่าคุณต้องการให้เครือข่ายทำอะไร และที่สำคัญกว่านั้นคือสิ่งใดที่ไม่ควรอนุญาต หลายท่านคงจำแนวคิดที่เรียกว่า "default deny" ได้ นั่นคือหากไม่ได้อนุญาตการเชื่อมต่อไว้อย่างชัดเจน การเชื่อมต่อนั้นจะถูกบล็อกโดยอัตโนมัติ จากนั้นเว็บก็เข้ามามีบทบาท และการจำกัด Port 80 หรือ 443 ก็เป็นไปไม่ได้อีกต่อไป เพราะแทบทุกแอปพลิเคชันใช้พอร์ตเหล่านี้ ยิ่งไปกว่านั้น "default deny" แทบไม่เคยถูกนำไปใช้เลยพ้นขอบเขต perimeter ขณะที่เครือข่ายภายในของเรามักเป็นแบบ flat และเปิดกว้าง โดยพึ่งพา DMZ ในการกรองทราฟฟิกอันตรายจากภายนอก และอย่างที่เหตุการณ์ข้อมูลรั่วไหลครั้งแล้วครั้งเล่าได้พิสูจน์ โมเดลนี้ได้ผลเพียงปานกลางเท่านั้น

แต่ SDN ช่วยให้เราเข้าใกล้แนวคิด default-deny ได้มากขึ้น ผ่านสิ่งที่เราเรียกว่า "Minimum Viable Network" ซึ่งเปิดทางให้สร้างเครือข่ายเฉพาะทางที่ประกอบด้วยองค์ประกอบเท่าที่จำเป็นต่อการทำงานเท่านั้น ไม่มีส่วนเกิน

Minimum Viable Network ควรเริ่มจากการกำหนดสถาปัตยกรรมของแอปพลิเคชัน แล้วจึงสร้างเฉพาะส่วนเครือข่ายที่จำเป็นต่อการรองรับแอปพลิเคชันนั้นเท่านั้น พร้อมบังคับใช้หลัก least privilege กับ routing และ security group รวมถึงใช้องค์ประกอบแบบ PaaS เช่น cloud load balancer วิธีนี้เปลี่ยนเครือข่ายแบบ packet-switched ให้ทำงานเสมือนเครือข่ายแบบ circuit-switched กล่าวคือ องค์ประกอบของแอปพลิเคชันจะสื่อสารได้เฉพาะกับองค์ประกอบที่ได้รับอนุญาตเท่านั้น และไม่มีสิ่งใดดักจับทราฟฟิกระหว่างกันได้ (ยกเว้นผู้ให้บริการคลาวด์ในบางกรณี) ทราฟฟิกอื่นทั้งหมดจะถูกเครือข่าย drop ทิ้ง สิ่งนี้ทำให้ไม่จำเป็นต้องมีโครงสร้างอย่าง DMZ แบบดั้งเดิมหรือ network zone อีกต่อไป เพราะทั้งเครือข่ายทำงานบนหลัก least privilege และ default deny อยู่แล้ว

ลองมาดูตัวอย่างให้เห็นภาพชัดขึ้น คุณสามารถสร้างสแตกแอปพลิเคชันแบบ 3 ชั้นตามปกติ โดยมี Application Load Balancer ที่เปิดสู่สาธารณะ ด้านหลังเป็นเว็บเซิร์ฟเวอร์ใน private subnet ซึ่งรับทราฟฟิกจาก load balancer เท่านั้น เว็บเซิร์ฟเวอร์เชื่อมต่อได้เฉพาะกับแอปพลิเคชันเซิร์ฟเวอร์ที่ยอมรับการเชื่อมต่อจากเว็บเซิร์ฟเวอร์เหล่านั้น เช่นเดียวกัน แอปพลิเคชันเซิร์ฟเวอร์ส่งทราฟฟิกได้เฉพาะไปยังฐานข้อมูลที่อนุญาตการเชื่อมต่อดังกล่าว แต่ละชั้นใช้หลัก default deny และอนุญาตเฉพาะการเชื่อมต่อขาเข้าจาก load balancer และการเชื่อมต่อขาออกไปยังฐานข้อมูลเท่านั้น ในหลายกรณี คุณสามารถใช้งานรูปแบบนี้ได้โดยไม่ต้องมีการเชื่อมต่ออินเทอร์เน็ตเลย (อยู่ใน private subnet ทั้งหมด) นอกเหนือจาก public load balancer ซึ่งเป็นโครงสร้าง PaaS ที่มีความปลอดภัยสูงและดูแลโดยผู้ให้บริการคลาวด์

แทนที่จะสร้างเครือข่ายขึ้นมาก่อนแล้วนำแอปพลิเคชันไปวางไว้ข้างใน คุณออกแบบแอปพลิเคชันก่อน แล้วจึงปรับเครือข่ายให้สอดคล้องกับความต้องการของแอปพลิเคชัน แนวทางนี้ลดพื้นที่การโจมตีของสแตกแอปพลิเคชันลงอย่างมาก และลดความเสี่ยงขององค์กรลงตามไปด้วย

เราใช้หลักการเหล่านี้ในการสร้างเว็บไซต์ securosis.com ดังที่เห็นในแผนผังสถาปัตยกรรมด้านล่าง หากพิจารณาการออกแบบนี้ด้วยมุมมองด้าน network security จะเห็นว่า:

• การเข้าถึงถูกจำกัดจาก cloud WAF เพื่อให้เฉพาะทราฟฟิกที่สะอาดเท่านั้นเข้าสู่ VPC
• application load balancer (ALB) เป็นทรัพยากรเดียวที่อยู่ใน subnet ที่เปิดสู่สาธารณะ และอนุญาตเฉพาะทราฟฟิก 80/443 เท่านั้น
• อินสแตนซ์ทั้งหมดอยู่ใน private subnet และรับทราฟฟิกจาก ALB เท่านั้น
• อินสแตนซ์ "admin" รองรับการล็อกอิน แต่เฉพาะจาก VPN ที่โฮสต์อยู่ในสภาพแวดล้อมอื่นเท่านั้น
• สิ่งที่ไม่ได้แสดงในแผนผังคือ subnet สำหรับฐานข้อมูล RDS ซึ่งเป็นแบบ private เท่านั้นเช่นกัน และรับทราฟฟิกจากอินสแตนซ์เท่านั้น หากจำเป็นต้องล็อกอินโดยตรงหรือเข้าถึง RDBMS เพื่อจัดการข้อมูล จะมีการแก้ไขกฎของ security group เพื่อเปิดการเข้าถึงชั่วคราว
• การเชื่อมต่อไปยัง S3 ทำผ่าน service endpoint จึงไม่จำเป็นต้องใช้ NAT Gateway สำหรับการเข้าถึงอินเทอร์เน็ต
• SSH ถูกปิดใช้งานบนอินสแตนซ์ที่ไม่ใช่ admin อินสแตนซ์เหล่านี้เป็นแบบ autoscale และ immutable โดยจะแก้ไขได้ด้วยการเปลี่ยน base image เท่านั้น
• ไม่มี self-referencing security group (security group ที่อนุญาตการเข้าถึงภายใน) เพื่อป้องกันการโจมตีในแนวราบ security group ใน AWS ทำงานในระดับทรัพยากร ไม่ใช่ระดับ subnet ซึ่งมีประสิทธิภาพสูงมากในการสกัดการโจมตีแบบ East/West
• สถาปัตยกรรมนี้ลดพื้นที่การโจมตีโดยรวมลงอย่างมาก เครือข่ายอนุญาตเฉพาะการเชื่อมต่อขั้นต่ำที่จำเป็น และประกอบด้วย subnet กับ route table เท่าที่จำเป็นต่อการเข้าถึงเท่านั้น เราได้ปรับเครือข่ายให้พอดีกับแอปพลิเคชันอย่างแท้จริง อันที่จริง เครือข่ายถูกออกแบบขึ้นหลังจากวางสถาปัตยกรรมของสแตกแอปพลิเคชันเสร็จแล้วเท่านั้น
• นี่เป็นเพียงตัวอย่างง่าย ๆ ของเว็บไซต์ขนาดเล็ก แต่หลักการเดียวกันนี้ใช้ได้กับสถาปัตยกรรมขนาดใหญ่กว่ามาก ที่มีจำนวนชั้นมากกว่า มี internal load balancer, API Gateway และองค์ประกอบ PaaS ต่าง ๆ

จะเห็นได้ว่าโครงสร้างเครือข่ายบนคลาวด์ให้ความยืดหยุ่นอย่างมหาศาล คุณสามารถสร้างเครือข่ายตามที่แอปพลิเคชันต้องการได้เสียที แทนที่จะต้องปรับแอปพลิเคชันให้เข้ากับเครือข่ายที่มีอยู่ แต่ความยืดหยุ่นนี้ก็มาพร้อมโอกาสที่จะตั้งค่าผิดพลาดและเปิดโครงสร้างพื้นฐานส่วนใหญ่ของคุณสู่อินเทอร์เน็ตสาธารณะ เราจึงแนะนำเสมอให้คุณเฝ้าติดตาม cloud security posture และบังคับใช้แนวปฏิบัติที่ดีที่สุดด้วยแพลตฟอร์ม cloud security operations (เช่นแพลตฟอร์มที่ DisruptOps นำเสนอ)