rule แบบตายตัวในโลกที่เปลี่ยนแปลงตลอดเวลา: เหตุผลที่ต้องใช้ asset-based security

Zero Trust ควรช่วยให้เราปรับตัวต่อภัยคุกคาม ต่อการเปลี่ยนแปลง และต่อสิ่งที่คาดเดาไม่ได้ แต่ปัญหาคือ นโยบายส่วนใหญ่ของเราไม่ได้ถูกออกแบบมาเพื่อสิ่งเหล่านั้นเลย นโยบายเหล่านั้นหยุดนิ่ง ถูกกำหนดตายตัว และเปลี่ยนแปลงได้ช้ามาก และไม่มีที่ใดชัดเจนไปกว่าการที่เรายังพึ่งพาโครงสร้างเครือข่ายแบบเดิม เช่น zone แบบคงที่ IP แบบตายตัว และ rule ที่เปิดสิทธิ์ค้างไว้ ทั้งหมดนี้ถูกใช้ตัดสินใจเรื่องความน่าเชื่อถือ ในโลกที่ workload ถูกสร้าง ย้าย และหายไปเร็วกว่าที่คุณจะพูดคำว่า “ticket escalation” เสร็จ ถึงเวลาแล้วที่จะพูดถึงว่าเหตุใดรากฐานของ Zero Trust จึงต้องเปลี่ยนแปลงอย่างถึงแก่น และเหตุใด asset-based security จึงเป็นสะพานเชื่อมจากภาวะชะงักงันของนโยบายแบบเดิม ไปสู่ความคล่องตัวของ Zero Trust อย่างแท้จริง

สมอเรือยุคเก่า: zone, เครือข่าย และภาพลวงตาของการควบคุม

IP address, zone และ network segment ไม่เคยถูกออกแบบมาให้เป็นจุดยึดของนโยบายในสภาพแวดล้อมสมัยใหม่ สิ่งเหล่านี้ถูกคิดขึ้นเพื่อโลกที่เครือข่ายอยู่นิ่ง แอปพลิเคชันอยู่กับที่ และ cloud ยังหมายถึงก้อนเมฆบนฟ้า เครือข่ายในปัจจุบันยืดหยุ่น container มีอายุเพียงไม่กี่ชั่วโมง cloud instance เกิดขึ้นและดับไปในพริบตา ส่วนประกอบของแอปพลิเคชันกระจายข้ามภูมิภาค ข้ามผู้ให้บริการ cloud และข้าม trust zone แล้วนโยบายความปลอดภัยของคุณล่ะ ยังคงผูกการเข้าถึงไว้กับ zone และ IP block แบบตายตัว แม้จะมี SDN overlay และเครื่องมือแบบ cloud-native แต่นโยบายส่วนใหญ่ในชั้นการบังคับใช้ยังคงยึดอยู่กับโครงสร้างที่ไม่สะท้อนวิธีการดำเนินธุรกิจ ผลลัพธ์คืออะไร ความไม่สอดคล้องระหว่างเจตนากับการบังคับใช้ ที่ทำให้การเปลี่ยนแปลงช้าลงและเปิดช่องให้เกิดความเสี่ยง

ความเร็วที่ไม่สอดคล้องกัน: asset เปลี่ยน แต่นโยบายไม่เปลี่ยน

zone ทำงานได้ดีในระดับมหภาค แต่สถาปัตยกรรมความปลอดภัยที่อิง zone ไม่สามารถปรับตัวได้ทันต่อการเปลี่ยนแปลงของ asset และการเชื่อมโยงระหว่างกัน และนั่นไม่ใช่เพราะทีมเครือข่ายทำงานช้า แต่เพราะ rule ถูกกำหนดตายตัว ขั้นตอนอนุมัติไม่ยืดหยุ่น และทุกการเปลี่ยนแปลงเหมือนการเปิดกล่องแพนดอร่าของผลกระทบที่ไม่ได้ตั้งใจ ในทางกลับกัน ตัว asset เอง (เซิร์ฟเวอร์ แอปพลิเคชัน และบริการต่าง ๆ) รวมถึงคุณลักษณะของมัน เคลื่อนไหวอย่างรวดเร็ว asset เปลี่ยนแปลงอยู่ตลอดเวลา:

• ทีมพัฒนาสร้างบริการแบบ container ขึ้นใหม่เพื่อทดสอบ
• VM ได้รับการ patch และถูกย้ายข้ามภูมิภาค
• การเชื่อมต่อแบบ SaaS เปลี่ยนเส้นทางการไหลของข้อมูลระหว่างแอป

แต่ละเหตุการณ์เหล่านี้ล้วนส่งผลต่อความปลอดภัย แต่นโยบายพื้นฐานกลับตามไม่ทัน การเปลี่ยนแปลง firewall ถูกจัดเข้าคิว การอนุมัติล่าช้า และโครงการทางธุรกิจต้องรอทีมความปลอดภัย ไม่ใช่เพราะทำผิด แต่เพราะกระบวนการเปราะบาง นี่คือจุดที่ Zero Trust มักหยุดชะงัก ไม่ใช่ในเชิงหลักการ แต่ในทางปฏิบัติ คุณไม่สามารถบังคับใช้ความน่าเชื่อถือแบบปรับเปลี่ยนได้ด้วยการควบคุมที่ตายตัว

เหตุใด asset-based security จึงเป็นจุดเปลี่ยน

asset-based security พลิกรูปแบบเดิม แทนที่จะยึดการตัดสินใจเรื่องการเข้าถึงไว้กับโครงสร้างพื้นฐาน (เช่น zone หรือ IP) มันยึดไว้กับตัว asset ว่าคืออะไร ทำหน้าที่อะไร และมีความเสี่ยงเพียงใด asset จึงกลายเป็นบริบท และบริบทคือทุกสิ่งใน Zero Trust โมเดลนโยบายแบบอิง asset อาศัยองค์ประกอบต่าง ๆ ได้แก่:

• Tag: เมตาดาต้าจาก cloud, CMDB หรือระบบ inventory
• Role: การจัดกลุ่มตามหน้าที่ทางธุรกิจหรือตามแอปพลิเคชัน
• Posture: ตัวชี้วัดความเสี่ยง สถานะ compliance หรือข้อมูลเชิงลึกด้านช่องโหว่

สิ่งนี้ทำให้ทีมความปลอดภัยกำหนดนโยบายในลักษณะนี้ได้:

• “อนุญาตทราฟฟิกฐานข้อมูลเฉพาะจาก workload ที่ติด tag PCI และมี posture ที่ปลอดภัยเท่านั้น”
• “บล็อกการเข้าถึงอินเทอร์เน็ตขาออกทั้งหมดจาก asset สำคัญที่ถูกระบุว่ามีช่องโหว่ระดับความรุนแรงสูง”
• “อนุญาตการเข้าถึงแบบ just-in-time สำหรับ role ผู้ดูแลระบบในช่วงหน้าต่างการบำรุงรักษาที่ได้รับอนุมัติ”

นโยบายเหล่านี้ไม่สนใจว่า asset อยู่ที่ใด cloud, on-prem หรือ hybrid ก็ไม่สำคัญ สิ่งที่สำคัญคือตัวตน วัตถุประสงค์ และสถานะของ asset นั่นคือจุดเริ่มต้นของการก้าวจากการบังคับใช้แบบคงที่ ไปสู่ guardrail ที่ปรับเปลี่ยนได้

ปิดช่องว่าง: เหตุใด firewall จึงต้องเรียนรู้ภาษาของ asset และคุณลักษณะ

ขอให้ชัดเจนว่า นี่ไม่ใช่การเปลี่ยน firewall ของคุณ แต่คือการสอนภาษาใหม่ให้มัน ภาษาที่สอดคล้องกับตรรกะทางธุรกิจและเจตนาด้านความปลอดภัยมากขึ้น ทุกวันนี้ ทีมความปลอดภัยเครือข่ายมักต้องแปลคำขออย่างเช่น “อนุญาตให้แอป analytics ตัวใหม่เชื่อมต่อกับฐานข้อมูล production” ให้กลายเป็นสิ่งที่มีลักษณะแบบนี้ “อนุญาตทราฟฟิกจาก 10.42.0.0/16 ไปยัง 172.19.8.0/24 บน TCP port 5432” การแปลงเช่นนี้เกิดข้อผิดพลาดได้ง่าย ใช้เวลานาน และหลุดออกจากเจตนาทางธุรกิจเดิมโดยสิ้นเชิง ที่แย่กว่านั้น เมื่อแอป analytics ย้ายไปอยู่ subnet อื่น หรือมีการเปิดภูมิภาคใหม่ นโยบายก็ใช้งานไม่ได้ หรือแย่กว่านั้นคือยังเปิดค้างไว้และสร้างความเสี่ยง นโยบายแบบอิง asset ขจัดช่องว่างของการแปลงนี้ออกไป โดยอธิบายการเข้าถึงในเชิงธุรกิจ และระบบบังคับใช้จะแปลงให้แบบไดนามิกตามสถานะและ inventory ของ asset แบบเรียลไทม์ เปรียบเสมือนการมอบกุญแจถอดรหัสโครงสร้างพื้นฐานสมัยใหม่ให้กับ firewall ของคุณ

จากคอขวดของนโยบาย สู่ตัวขับเคลื่อนธุรกิจ

เมื่อนโยบายเครือข่ายกลายเป็นแบบไดนามิกและรับรู้ asset สิ่งสำคัญก็เกิดขึ้น ความปลอดภัยเลิกเป็นคอขวด และเริ่มเป็นตัวขับเคลื่อนธุรกิจ

• ความคล่องตัวเพิ่มขึ้น เพราะนักพัฒนาไม่ต้องหยุดรอการแก้ไข firewall rule ด้วยมือ
• ความเสี่ยงลดลง เพราะสิทธิ์การเข้าถึงที่เปิดค้างไว้ถูกจำกัดให้น้อยที่สุด และนโยบายปรับตามการเปลี่ยนแปลงของ posture ของ asset
• compliance ดีขึ้น เพราะการควบคุมสอดคล้องโดยตรงกับระบบและข้อมูลที่ต้องการปกป้อง

ที่สำคัญที่สุด ความปลอดภัยสามารถเคลื่อนไปด้วยความเร็วเดียวกับธุรกิจ ไม่ใช่ตามหลังอยู่สองไตรมาส

มุมมองของ FireMon: นโยบายที่คิดในเชิงธุรกิจ

ที่ FireMon เราใช้เวลากว่าสองทศวรรษช่วยองค์กรจัดระเบียบความวุ่นวายของนโยบายความปลอดภัย และมีสิ่งหนึ่งที่ชัดเจน หากคุณต้องการให้ Zero Trust ใช้ได้จริงในโลกแห่งความเป็นจริง นโยบายของคุณจะอิงกับโครงสร้างพื้นฐานที่ตายตัวไม่ได้ แต่ต้องสะท้อนบริบทที่เปลี่ยนแปลงตลอดเวลา นั่นหมายถึง:

• บริหารการเข้าถึงโดยยึด asset ไม่ใช่ address
• กำหนดนโยบายด้วยตรรกะทางธุรกิจ ไม่ใช่ subnet
• บังคับใช้การควบคุมตามความเสี่ยงและ posture ไม่ใช่ตามสมมติฐานที่ตายตัว

ด้วยแนวคิดนี้ ทีมความปลอดภัยจะได้การควบคุมที่แท้จริง ไม่ใช่ด้วยการล็อกทุกอย่างให้แน่นขึ้น แต่ด้วยการตัดสินใจเรื่องความน่าเชื่อถืออย่างชาญฉลาดขึ้น

ถึงเวลาเลิกใช้ rule แบบตายตัว

rule แบบตายตัวเคยสมเหตุสมผลเมื่อโครงสร้างพื้นฐานอยู่นิ่ง แต่โลกแบบนั้นหมดไปแล้ว ทุกวันนี้ ความปลอดภัยต้องสะท้อนการเคลื่อนไหวตลอดเวลาของผู้ใช้ workload ภัยคุกคาม และความเสี่ยง นั่นหมายความว่านโยบายต้องพัฒนาจากแข็งตัวและตั้งรับ ไปสู่ความเป็นไดนามิกและเชิงพรรณนา asset-based security ไม่ใช่คำโฆษณา แต่คือสะพานเชื่อมระหว่างวิธีที่เรามองความปลอดภัย กับวิธีที่เรานำไปใช้งานจริง ดังนั้น หากโครงการ Zero Trust ของคุณรู้สึกติดขัด ลองถามตัวเองว่า คุณกำลังบังคับใช้นโยบายตามสิ่งที่ asset เคยเป็น หรือสิ่งที่มันเป็นอยู่ในขณะนี้ คำตอบนั้นอาจเป็นกุญแจที่ทำให้คุณก้าวต่อไปได้ ต้องการยกระดับสู่ความทันสมัยโดยไม่ต้องเปลี่ยนโครงสร้างพื้นฐานหรือไม่ ให้ FireMon แสดงให้คุณเห็นว่านโยบายแบบไดนามิกที่รับรู้ asset ปลดล็อกความคล่องตัวของ Zero Trust ได้อย่างไร จองการสาธิตวันนี้