โศกนาฏกรรมของความปลอดภัยที่ดับสูญบนเบ้าหลอมของ DevOps

งานด้านความปลอดภัยไม่เหมือนเดิมอีกต่อไป หรือบางทีอาจเป็นเช่นนี้มาตลอด เพียงแต่ดูต่างออกไปเพราะอุดมคติแบบคนหนุ่มสาวของผมค่อย ๆ จางหายไป

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

โศกนาฏกรรมของความปลอดภัยคือภาพสะท้อนของโศกนาฏกรรมของสาธารณสมบัติ จาก Wikipedia:

compliance ด้านความปลอดภัยส่วนใหญ่ถูกออกแบบมาเพื่อลดความเสี่ยงด้านความปลอดภัย อย่างน้อยก็ในทางทฤษฎี แต่เมื่อเวลาผ่านไป เราได้เห็นมาตรฐานแล้วมาตรฐานเล่า กฎระเบียบแล้วกฎระเบียบเล่า ที่แยกความเสี่ยงออกจาก compliance ธรรมชาติของมาตรฐาน compliance เองนั่นแหละที่ขัดขวางไม่ให้องค์กรปรับมาตรการความปลอดภัยให้สอดคล้องกับความเสี่ยงขององค์กร ผมไม่ได้บอกว่าเป็นเช่นนี้เสมอไป แต่ส่วนใหญ่เป็นเช่นนั้น โดยเฉพาะเมื่อขยายไปสู่องค์กรขนาดใหญ่ ไม่มีหลักฐานใดชี้ว่าการบังคับให้ผู้ใช้ที่มี MFA หรือมีข้อจำกัดแบบมีเงื่อนไขอื่น ๆ ที่ใช้กันทั่วไปในปัจจุบัน ต้องรีเซ็ตรหัสผ่านทุก 90 วันนั้นช่วยเพิ่มความปลอดภัย ผู้คิดค้นข้อกำหนดความซับซ้อนของรหัสผ่านถึงกับออกมาบอกว่าเสียใจที่ทำไป และยืนยันว่ามันไม่ได้ผล ไม่มีทั้งหลักฐานและพื้นฐานทางวิทยาศาสตร์ที่หนักแน่นรองรับการบังคับให้เข้ารหัส storage volume ทั้งหมดในผู้ให้บริการคลาวด์แบบที่ไม่ใช่ค่าเริ่มต้น.

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

นี่คือโศกนาฏกรรมของความปลอดภัย เราแยกความเสี่ยงออกจาก compliance จนทำให้การไม่ปฏิบัติตามข้อกำหนดกลายเป็นความเสี่ยงเสียเอง ยิ่งความเสี่ยงที่แท้จริงถูกแยกออกจาก compliance มากเท่าใด ระบอบ compliance ก็ยิ่งแข็งตัวมากขึ้น ทรัพยากรด้านความปลอดภัยที่เหลือไว้สำหรับการป้องกันก็ยิ่งน้อยลง และการสนับสนุนงานด้านความปลอดภัยจากทีมอื่น ๆ ก็ยิ่งลดลง

ตัวอย่างที่ดีเกิดขึ้นในบทสนทนากับChris Farris สรุปใจความได้ว่า

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

ผมไม่ได้บอกว่า compliance ทั้งหมดเป็นกฎที่ไร้สาระ แต่กฎ compliance บางข้อก็ไร้สาระจริง ๆ และการนำกฎที่ดีไปใช้ผิดที่ผิดทางโดยไม่เชื่อมโยงกับความเสี่ยงนั้นยิ่งไร้สาระหนักเข้าไปอีก

DevOps กลายเป็นเบ้าหลอมของอนาคตด้านความปลอดภัย เพราะในโลกของคลาวด์และ DevOps ทีมแอปพลิเคชันแต่ละทีมต้องรับผิดชอบทั้ง stack รวมถึงงานด้านความปลอดภัยเป็นส่วนใหญ่ เซิร์ฟเวอร์ เครือข่าย และ firewall ใหม่ ๆ อยู่ห่างออกไปเพียงแค่ git commit และการเรียก API ไม่กี่ครั้ง สิ่งนี้ยังเพิ่มภาระให้ทีมเหล่านั้นต้องบริหารจัดการความปลอดภัยและ compliance ของตนเองมากขึ้นด้วย เรายังคงมีหน่วยงานความปลอดภัยส่วนกลางและทรัพยากรด้านความปลอดภัยที่ใช้ร่วมกัน แต่เมื่อถึงแนวหน้าจริง ๆ เราต้องพึ่งพาทีม DevOps มากขึ้นอย่างแน่นอน เราไม่สามารถสร้าง DMZ ขนาดใหญ่สำหรับคลาวด์ได้ เส้นแบ่งระหว่างเครือข่ายภายในและภายนอกไม่สามารถจัดเป็นโซนสำเร็จรูปได้อีกต่อไป แอปพลิเคชันจำนวนมากที่สร้างบนบริการคลาวด์แบบ native ไม่มีเครือข่ายอยู่ด้วยซ้ำ และต้องพึ่งพากฎ IAM และ resource policy ที่เขียนด้วย JSON ซึ่งทีมแอปพลิเคชันเป็นผู้ push ผ่าน infrastructure as code

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

มีแนวทางแก้ไขที่เป็นไปได้อยู่สองทาง

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

อีกทางหนึ่งคือการใช้ระบบอัตโนมัติเพื่อลดภาระด้านความปลอดภัยและ compliance ที่ตกอยู่กับแต่ละบุคคลให้มากที่สุด โดยยังคงให้อิสระและการควบคุมในการพัฒนาอย่างรวดเร็ว ผมไม่ได้เสนอให้ทรัพยากรด้านความปลอดภัยโดยรวมลดลง แต่ให้ใช้ระบบอัตโนมัติและเทคโนโลยีอื่น ๆ เพื่อลดภาระของแต่ละคนในการเสียเวลาไปกับสิ่งที่มีคุณค่าน้อยกว่า

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