ออกแบบว่าใครเข้าถึงอะไรจากไหน

หัวข้อนี้วัดว่าเราออกแบบขอบเขตการเข้าถึงเป็นไหม ระบบจริงมีทั้งส่วนที่เปิดให้คนนอกใช้ และส่วนที่ให้เฉพาะภายในองค์กร DCE ต้องแยกสองส่วนนี้ออกและวาง control ให้เหมาะ เพราะถ้าออกแบบพลาด เช่นเปิด database ออก public โดยไม่จำเป็น ก็กลายเป็นช่องโหว่ใหญ่ ผู้สัมภาษณ์อยากเห็นว่าเราคิดเรื่องนี้ตั้งแต่ออกแบบ ไม่ใช่ตามแก้ทีหลัง

Internal access คือการเข้าถึงจากภายในองค์กรหรือภายในเครือข่ายที่เชื่อถือได้ เช่นพนักงานเข้าระบบหลังบ้าน หรือ service ภายในคุยกัน มักเดินผ่าน private network ไม่ออก public internet

External access คือการเข้าถึงจากภายนอก เช่นลูกค้าทั่วไปเข้าเว็บหรือเรียก API ผ่าน public internet ส่วนนี้ต้องป้องกันเข้มกว่าเพราะเปิดสู่โลกภายนอก

หลักการสำคัญคือ "เปิดเท่าที่จำเป็น" component ที่ไม่จำเป็นต้องเข้าถึงจากภายนอก เช่น database หรือ internal service ควรอยู่ใน private subnet ไม่มี public IP ส่วนที่ต้อง public เช่น web frontend หรือ public API ให้เปิดผ่านชั้นป้องกันเท่านั้น

• VPC และ subnet: แยก public subnet สำหรับ component ที่ต้องรับ traffic ภายนอก กับ private subnet สำหรับ component ภายใน
• Public access ผ่านชั้นป้องกัน: traffic ภายนอกควรเข้าผ่าน Cloud Load Balancing ที่มี Cloud Armor กรองการโจมตี ไม่ใช่ชี้ตรงเข้า compute
• Private resources: ใช้ instance ที่ไม่มี external IP สำหรับ backend และ database
• Private Google Access: ให้ resource ที่ไม่มี public IP เข้าถึง Google API และ service ได้โดยไม่ต้องออก public internet
• Private Service Connect: เชื่อมต่อ service แบบ private ภายใน Google network
• Identity-Aware Proxy (IAP): ควบคุมการเข้าถึงแอปภายในตามตัวตนผู้ใช้ ทำให้พนักงานเข้าระบบหลังบ้านได้อย่างปลอดภัยโดยไม่ต้องเปิด VPN และไม่ต้องเปิดแอปออก public
• VPC Service Controls: สร้าง perimeter กันข้อมูลรั่วออกนอกขอบเขตที่กำหนด เป็นชั้นป้องกันสำคัญสำหรับข้อมูลอ่อนไหว
• การเชื่อม on-premises (internal hybrid): ใช้ Cloud VPN สำหรับการเชื่อมผ่าน internet แบบเข้ารหัส หรือ Cloud Interconnect สำหรับการเชื่อมเฉพาะที่ throughput สูงและเสถียรกว่า ทำให้ระบบ on-prem กับ GCP คุยกันเหมือนอยู่ในเครือข่ายเดียว

แนวคิดเดิมคือ "เชื่อทุกอย่างที่อยู่ในเครือข่ายภายใน" ซึ่งอันตราย เพราะถ้าผู้โจมตีเข้ามาในเครือข่ายได้ก็เข้าถึงทุกอย่าง zero trust เปลี่ยนเป็น "ไม่เชื่อใครโดยอัตโนมัติ" ทุกการเข้าถึงต้องพิสูจน์ตัวตนและตรวจ context ไม่ว่าจะมาจากภายในหรือภายนอก Google ใช้แนวทางนี้ในชื่อ BeyondCorp ซึ่งย้ายการตัดสินใจเข้าถึงจาก "อยู่ใน network ไหน" ไปเป็น "เป็นใครและอุปกรณ์น่าเชื่อถือแค่ไหน" ทำให้ internal กับ external เริ่มไม่ได้แบ่งด้วยเส้น network อย่างเดียวอีกต่อไป แต่แบ่งด้วยตัวตนและ context

ถาม: "ออกแบบให้พนักงานเข้าระบบ admin ภายในได้อย่างปลอดภัย โดยไม่เปิดออก public" ตอบ: วาง admin app ใน private subdomain แล้วใช้ IAP ควบคุมการเข้าถึงตามตัวตน แทนการเปิด VPN หรือ public endpoint

ถาม: "database ควรเข้าถึงจากภายนอกได้ไหม" ตอบ: ไม่ควร ให้อยู่ใน private subnet ไม่มี public IP แล้วให้เฉพาะ application layer ภายใน VPC เข้าถึง

ถาม: "จะเชื่อมระบบ on-prem กับ GCP อย่างไร" ตอบ: Cloud VPN สำหรับเริ่มต้นหรือ throughput ไม่สูง, Cloud Interconnect สำหรับ throughput สูงและเสถียร

ถาม: "อธิบายแนวคิด zero trust" ตอบ: ไม่เชื่อใครโดยอัตโนมัติแม้อยู่ใน network เดียวกัน ตรวจตัวตนและ context ทุกครั้ง ลดความเสี่ยงเมื่อ perimeter ถูกเจาะ

เปิด component ออก public มากเกินจำเป็น โดยเฉพาะ database; ชี้ traffic ภายนอกเข้า compute ตรงโดยไม่ผ่าน load balancer และ Cloud Armor; พึ่ง network perimeter อย่างเดียวโดยไม่ใช้ identity-based control; ไม่รู้จัก IAP จึงเสนอ VPN กับทุกกรณี; สับสนว่าเมื่อไหร่ใช้ Cloud VPN เมื่อไหร่ Cloud Interconnect; ลืม VPC Service Controls สำหรับข้อมูลอ่อนไหว

แยกชัดว่าส่วนไหน public-facing ส่วนไหน internal-only แล้วเปิดเท่าที่จำเป็น traffic ภายนอกต้องผ่านชั้นป้องกัน component ภายในอยู่ใน private subnet ใช้ IAP สำหรับการเข้าถึงแอปภายในตามตัวตนแทน VPN เชื่อม on-prem ด้วย Cloud VPN หรือ Cloud Interconnect ตามความต้องการ throughput และยึดแนวคิด zero trust ที่ตัดสินการเข้าถึงด้วยตัวตนและ context ไม่ใช่แค่ตำแหน่งในเครือข่าย