Policy ที่เร็วทันระดับ DevOps: เหตุใดการบริหารการเปลี่ยนแปลงจึงต้องคิดใหม่

ความคล่องตัวคือหัวใจสำคัญของ IT ระดับองค์กรในปัจจุบัน นักพัฒนาส่งโค้ดขึ้นระบบภายในไม่กี่ชั่วโมง ไม่ใช่หลายสัปดาห์ โครงสร้างพื้นฐานขยายตัวได้อย่างยืดหยุ่น บริการใหม่เปิดใช้งานได้ทันที แต่ขณะที่ธุรกิจเร่งความเร็ว security policy กลับถูกทิ้งไว้ข้างหลัง ติดอยู่กับกระบวนการและเครื่องมือที่ไม่ได้ออกแบบมาเพื่อความเร็วระดับนี้ และนั่นคือปัญหา เพราะหากการควบคุมการเปลี่ยนแปลงตามการเปลี่ยนแปลงไม่ทัน security จะไม่เพียงทำให้ทุกอย่างช้าลง แต่จะกลายเป็นจุดที่ทำให้ระบบพัง

การควบคุมการเปลี่ยนแปลงที่วิ่งอยู่ในเลนช้า

ลองนึกถึงภาพที่คุ้นเคยนี้ ทีม DevOps ปล่อย microservice ตัวใหม่ ซึ่งต้องเข้าถึงฐานข้อมูล backend บริการ authentication และอาจรวมถึง API ของบุคคลที่สาม สภาพแวดล้อมเป็นแบบไฮบริด บางบริการรันอยู่บน cloud container บางส่วนอยู่ใน virtual machine แบบ on-prem ทุกอย่างถูกติด tag เปลี่ยนแปลงตลอดเวลา และถูกแยกออกจากเครือข่ายเบื้องล่าง จากนั้นก็มาถึงส่วนของ security ทีมงานส่งคำขอเปลี่ยนแปลง: เปิดพอร์ตเหล่านี้ ระหว่างระบบเหล่านี้ สำหรับสภาพแวดล้อมนี้ ตั๋วงานถูกสร้างขึ้น ทีม firewall ตรวจสอบคำขอ ตรวจเอกสาร จับคู่คำขอกับโซนหรือช่วง IP และพยายามทำความเข้าใจเส้นทางเครือข่าย ขั้นตอนเหล่านี้จำเป็น แต่ก็ใช้เวลา แม้จะมีเครื่องมือ automation และ workflow management รุ่นใหม่ล่าสุดก็ตาม กว่าการเปลี่ยนแปลงจะเสร็จ บริการนั้นอาจถูก refactor ไปแล้ว นี่ไม่ใช่การตำหนิทีม security พวกเขาทำตามกระบวนการเพื่อให้มั่นใจว่ามาตรการด้านความปลอดภัยครบถ้วน แต่กระบวนการนั้นไม่ได้ถูกสร้างมาเพื่อความเร็วในปัจจุบัน มันถูกสร้างขึ้นในยุคที่โครงสร้างพื้นฐานอยู่กับที่ แอปพลิเคชันมีขอบเขตชัดเจน และ firewall คือแนวป้องกันหลัก แต่ทุกวันนี้ มันเหมือนการปกป้องเขาวงกตที่เปลี่ยนรูปร่างอยู่ตลอดเวลา

workflow แบบเดิม ความเสี่ยงแบบใหม่

ต้นตอของปัญหาอยู่ที่โครงสร้างของการเปลี่ยนแปลง security policy แบบดั้งเดิม ซึ่งช้า ทำด้วยมือ และผูกติดกับโครงสร้างพื้นฐาน

• กฎที่อิง IP ตั้งอยู่บนสมมติฐานว่าสินทรัพย์อยู่กับที่ ซึ่งไม่เป็นจริงในสภาพแวดล้อมคลาวด์
• โมเดลที่อิงโซนจัดกลุ่มสินทรัพย์ตามตำแหน่งที่ตั้ง แทนที่จะจัดตามหน้าที่หรือความเสี่ยง
• การอนุมัติด้วยมือสร้างความล่าช้าและความติดขัด โดยมักไม่ได้ช่วยลดความเสี่ยงอย่างมีนัยสำคัญ

แนวทางเหล่านี้ใช้ได้ผลเมื่อ IT ยังคาดการณ์ได้ แต่ทุกวันนี้กลับสร้างความย้อนแย้งที่อันตราย: เพื่อบังคับใช้ security คุณต้องชะลอนวัตกรรม หรือแย่กว่านั้น ทีมงานข้ามกระบวนการไปเลยเพื่อให้ทันกำหนดส่ง ก่อให้เกิดเส้นทางการเข้าถึงที่มองไม่เห็นและความเสี่ยงที่ไม่มีใครบริหารจัดการ นี่คือเหตุผลที่ security สูญเสียการมองเห็น นี่คือที่มาของ policy drift และนี่คือเหตุผลที่ความพยายามด้านการทำ segmentation แบบ Zero Trustมักถูกจำกัดขอบเขต เพราะเมื่อถึงเวลาจริง ความพยายามที่ต้องใช้ในการขยายผลนั้นมากเกินกว่าที่คาดไว้

Policy ไม่ควรเป็นคอขวด

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

เหตุใดบริบทของสินทรัพย์จึงสำคัญ

สินทรัพย์ในปัจจุบันไม่ได้มีแค่เซิร์ฟเวอร์ แต่รวมถึง container, serverless function, cloud-native app และ VM ชั่วคราว สินทรัพย์เหล่านี้มีเมตาดาตาที่หลากหลาย ทั้งชื่อ บทบาท tag หน่วยธุรกิจ security posture สถานะด้าน compliance และอื่น ๆ security policy ที่เข้าใจและนำบริบทเหล่านี้มาใช้จะทนทานกว่าและบริหารจัดการง่ายกว่า ตัวอย่างเช่น:

• แทนที่จะอนุมัติกฎสำหรับ IP 172.16.5.34 ให้อนุมัติการเข้าถึงสำหรับ "Production CRM Services ที่ติด tag PCI-Compliant"
• แทนที่จะบล็อกทั้ง subnet ให้จำกัดการเข้าถึงตาม device posture ตัวตนของผู้ใช้ หรือบทบาทของแอปพลิเคชัน
• แทนที่จะคอยตรวจตั๋วงานไม่รู้จบสำหรับทุกคำขอเข้าถึงใหม่ ให้กำหนดกฎที่อิงเจตนา ซึ่งปรับตัวโดยอัตโนมัติเมื่อคุณลักษณะของสินทรัพย์เปลี่ยนไป

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

จุดที่เครื่องมือแบบดั้งเดิมยังคงโดดเด่น

แน่นอนว่านี่ไม่ได้หมายความว่าถึงเวลาทิ้งตำราเดิมทั้งหมด เครื่องมืออย่าง Policy Planner ของ FireMon ยังคงมีบทบาทสำคัญ โดยเฉพาะในสภาพแวดล้อมที่อยู่ภายใต้การกำกับดูแล และสำหรับการเปลี่ยนแปลงสิทธิ์เข้าถึงที่มีโครงสร้างและทำซ้ำได้ ต้องทบทวนสิทธิ์เข้าถึงของผู้ให้บริการภายนอกหรือไม่ ต้องเพิ่มกฎบน firewall ของ DMZ หรือไม่ ต้องเตรียม audit trail สำหรับการตรวจสอบ PCI หรือ HIPAA หรือไม่ Policy Planner คือคำตอบ เพราะช่วยนำความรัดกุม เอกสารประกอบ และความรับผิดชอบเข้าสู่กระบวนการ ช่วยลดความผิดพลาดจากคน บังคับใช้ workflow การอนุมัติ และทำให้มั่นใจว่าแม้การเปลี่ยนแปลงที่ซับซ้อนก็ผ่านการตรวจสอบอย่างถูกต้อง อย่างไรก็ตาม จุดที่ยังเป็นความท้าทายคือสภาพแวดล้อมที่เปลี่ยนแปลงบ่อยและรวดเร็ว เช่น การ deploy บนคลาวด์ การจัดการ container หรือกลยุทธ์ microsegmentation แบบไดนามิก ซึ่งการรอหลายวันเพื่อเปลี่ยนกฎหนึ่งข้อนั้นใช้ไม่ได้ ในสถานการณ์เหล่านี้ ตัว policy เองต้องสะท้อนแหล่งข้อมูลที่เป็นความจริงเพียงหนึ่งเดียวของสภาพแวดล้อม ต้องถูกกำหนดด้วยเจตนาและขับเคลื่อนด้วยบริบท ไม่ใช่ผูกกับ IP หรือกระบวนการที่ทำด้วยมือ

แล้วอะไรที่ต้องเปลี่ยน

หากกระบวนการเปลี่ยนแปลง policy ในปัจจุบันของคุณกลายเป็นคอขวด หรือแย่กว่านั้นคือเป็นต้นเหตุของความเสี่ยง ถึงเวลาทบทวนรากฐานใหม่ นี่คือจุดเริ่มต้นบางประการ:

• ตรวจสอบงานค้างด้านการเปลี่ยนแปลง: ดูว่าการเปลี่ยนแปลงแต่ละครั้งใช้เวลานานเท่าใด กฎใดถูกแก้ไขซ้ำ ๆ และมีการอนุมัติกี่รายการที่เป็นเพียงขั้นตอนตามระเบียบ
• ใช้ประโยชน์จากเมตาดาตาของสินทรัพย์ที่มีอยู่ เช่น บทบาท สภาพแวดล้อม เจ้าของ และระดับความเสี่ยง เพื่อสร้างโมเดล policy ที่อิงเจตนา
• แบ่งเซกเมนต์ตามตรรกะทางธุรกิจ: จัดกลุ่มสินทรัพย์ไม่เพียงตามตำแหน่งในเครือข่าย แต่ตามหน้าที่และระดับความอ่อนไหว กำหนดสิทธิ์เข้าถึงระหว่างกลุ่ม ไม่ใช่ระหว่าง IP
• ทำการตัดสินใจที่ความเสี่ยงต่ำให้เป็นอัตโนมัติ: สำหรับการเปลี่ยนแปลงที่สอดคล้องกับ policy ที่กำหนดไว้หรือผ่านการตรวจสอบความเสี่ยงที่กำหนดไว้ล่วงหน้า ควรพิจารณาลดขั้นตอนการอนุมัติ

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

บทสรุป: security ที่ปรับตัวได้

การเปลี่ยนแปลง policy ไม่จำเป็นต้องเจ็บปวด เพียงแต่ต้องพัฒนาให้ทันยุค เมื่อโครงสร้างพื้นฐานขององค์กรเคลื่อนไปสู่สภาพแวดล้อมแบบ cloud-native ไฮบริด และชั่วคราวมากขึ้น ทีม security ก็ต้องพัฒนาตามด้วย policy แบบคงที่และ workflow ที่แข็งตัวไม่เพียงพออีกต่อไป แนวทางที่ปรับตัวได้และเต็มไปด้วยบริบทต่างหากที่ใช่ นั่นไม่ได้หมายถึงการละทิ้งการกำกับดูแล แต่หมายถึงการวางแนวกั้นที่เปิดทางให้นวัตกรรมเดินหน้าได้เร็ว เครื่องมืออย่าง Policy Planner จำเป็นอย่างยิ่งสำหรับการเปลี่ยนแปลงที่มีขอบเขตชัดเจนและตรวจสอบย้อนหลังได้ แต่เพื่อปกป้องสภาพแวดล้อมที่เปลี่ยนแปลงตลอดเวลา เราต้องนำโมเดลใหม่ที่เคลื่อนที่ได้เร็วกว่าและสอดคล้องกับวิธีการสร้าง deploy และขยายแอปพลิเคชันในปัจจุบันเข้ามาใช้ด้วย เพราะ policy ไม่ควรเป็นสิ่งกีดขวาง แต่ควรเป็นตัวเร่ง