Google Cloud VPC Service Controls ขยาย Perimeter ตาม Folder ได้

Google Cloud ประกาศวันที่ 15 ตุลาคม 2026 ถึงความสามารถใหม่ของ VPC Service Controls หรือ VPC-SC ที่ช่วยออกแบบ perimeter ตามโครงสร้างองค์กรได้ง่ายขึ้น ได้แก่การใส่ folder เป็นสมาชิกของ perimeter, ใช้ folder และ organization ในกฎ ingress/egress, ระบุ Private Service Connect endpoint และแนวทางแก้การละเมิด policy แบบมีข้อเสนอเฉพาะจุด ข่าวนี้เกี่ยวข้องกับทีมที่มีหลายโปรเจกต์ เพราะปัญหาเดิมคือ policy ต้องตามการเกิด ย้าย และลบโปรเจกต์อยู่ตลอด

ให้ perimeter ตามโครงสร้าง folder

เดิมผู้ดูแลจำนวนมากกำหนดรายชื่อโปรเจกต์ใน perimeter โดยตรง เมื่อมีโปรเจกต์ใหม่เกิดใน folder ของทีม หากลืมเพิ่มรายชื่อก็เกิดช่องว่างการป้องกัน ฟีเจอร์ใหม่ให้ใส่ folder เป็นสมาชิก โปรเจกต์และ subfolder ภายในจึงรับนโยบายตามลำดับชั้น และเมื่อย้ายโปรเจกต์ สมาชิกภาพของ perimeter จะปรับตาม การเปลี่ยนนี้ช่วยให้โครงสร้าง resource hierarchy กลายเป็นส่วนหนึ่งของการควบคุมข้อมูล แต่ก็ทำให้การย้ายโปรเจกต์เป็นการเปลี่ยน security boundary โดยตรง ทีม platform จึงควรมี review สำหรับการย้ายด้วย

Google ระบุว่า dry-run mode รองรับ folder membership เพื่อให้ลองนโยบายกับทราฟฟิกจริงโดยไม่บล็อกก่อนเปิดบังคับใช้ ขั้นตอนนี้สำคัญมากในองค์กรที่มีบริการข้ามทีม เพราะ perimeter ที่เข้มเกินอาจทำให้แอปหยุดทันที ขณะที่ perimeter ที่กว้างเกินอาจไม่ป้องกันการนำข้อมูลออกตามที่ตั้งใจ การดู dry-run log ควรแยกทราฟฟิกที่คาดไว้จากทราฟฟิกที่ไม่รู้จัก แล้วติดตามเจ้าของก่อนแก้กฎ

กฎข้ามโปรเจกต์ที่อ่านง่ายขึ้น

Ingress และ egress rules สามารถอ้าง folder หรือ organization โดยตรง แทนการสะสมรายชื่อโปรเจกต์จำนวนมาก แนวทางนี้ช่วยลดจำนวน attribute ในกฎและรวมโปรเจกต์ใหม่ที่สร้างภายใต้ hierarchy เดิมโดยอัตโนมัติ แต่ความสะดวกมีผลอีกด้าน หากใส่ folder ที่กว้างเกิน โปรเจกต์ที่ไม่ควรได้รับสิทธิ์อาจถูกเปิดทางไปด้วย ควรออกแบบ folder ให้สะท้อน boundary ด้านข้อมูลจริง ไม่ใช้ folder ตามชื่อทีมเพียงอย่างเดียวถ้าภายในมีระดับความลับต่างกัน

ประกาศยังเพิ่มการใช้ Private Service Connect endpoint สำหรับ Google APIs เป็น attribute ใน ingress/egress rules ผู้ดูแลจึงเขียนกฎให้คำขอผ่าน private endpoint ที่กำหนดได้ แทนการอนุญาตตามปลายทางกว้าง ๆ สำหรับองค์กรที่ใช้ Network Connectivity Center ส่งต่อ endpoint ภายใน นี่ช่วยให้ policy สอดคล้องกับ topology ของเครือข่าย แต่ต้องตรวจว่า workload ทั้งหมดใช้เส้นทางที่คาดจริง ไม่เช่นนั้น request ที่เคยผ่าน public path อาจถูกปฏิเสธเมื่อเปิด enforcement

จำกัด API และแก้ violation อย่างมีขอบเขต

Service patterns ใน VPC accessible services ช่วยระบุรูปแบบ URL ของ Google API ที่อนุญาตผ่าน private VIP ได้ละเอียดขึ้น และรองรับการเติม org-restriction headers ในคำขอขาออกตามที่ Google อธิบาย วิธีนี้ทำให้ไม่จำเป็นต้องเปิดทั้งบริการหรือสร้าง egress proxy เพื่อแก้กรณีใช้งานที่แคบ แต่ผู้ดูแลต้องระวัง wildcard และ pattern ที่จับกว้างเกิน จึงควรมี test URL ทั้งที่อนุญาตและที่ต้องถูกบล็อก

เมื่อมีคำขอถูกปฏิเสธ Violation Analyzer เพิ่ม Guided Violation Remediation เพื่อเสนอการเปลี่ยนกฎที่เฉพาะเจาะจง เช่น ingress, egress, access level หรือ VPC accessible services ข้อเสนอช่วยลดเวลาตามหาสาเหตุ แต่ไม่ควรกดรับทั้งหมดโดยไม่ดูผลกระทบ ควรตรวจ identity ของผู้เรียก ข้อมูลปลายทาง เหตุผลทางธุรกิจ และนำกฎที่เสนอไปทดสอบใน dry-run ก่อนเสมอ เพราะความล้มเหลวหนึ่งครั้งอาจเกิดจากแอปตั้งค่าผิด ไม่ใช่ perimeter เข้มเกิน

ขั้นตอนเริ่มใช้กับระบบจริง

เริ่มจากทำแผนที่ folder กับระดับความสำคัญของข้อมูล ตรวจว่าโปรเจกต์ใหม่ถูกสร้างใต้ folder ใด และใครมีสิทธิ์ย้ายโปรเจกต์ จากนั้นสร้าง perimeter ใน dry-run เก็บ log สักช่วงที่ครอบคลุมงานปกติและงานตามรอบ เช่น backup หรือ batch รายสัปดาห์ ปรับ ingress/egress ให้แคบตามหลัก least privilege แล้วจึงเปิด enforcement ทีละขอบเขต พร้อมเตรียมวิธีย้อนกลับเมื่อแอปสำคัญถูกบล็อก

การขยาย perimeter ตาม folder ทำให้ดูแลหลายโปรเจกต์ได้ง่ายขึ้น แต่ความปลอดภัยขึ้นกับการวาง hierarchy และการตรวจ traffic จริง หากโครงสร้าง folder ไม่ตรงกับขอบเขตข้อมูล ควรแก้โครงสร้างหรือกำหนดข้อยกเว้นอย่างรอบคอบก่อนบังคับ policy

แหล่งข่าวและวันที่ประกาศ: Google Cloud Blog, 15 ตุลาคม 2026