DevOps Handbook#10 : Change & Security Compliance

หลังจากที่เรารู้จักทุกๆหลักการและวิถีทางของชาว DevOps ละ ก็วกกลับมาเรื่อง control กันบ้าง เพราะไม่ใช่แค่ทำ release ได้เร็วจะตอบโจทย์ทั้งหมด เรื่อง Security และ Availability ก็เป็นเรื่องสำคัญต่อความน่าเชื่อถือของธุรกิจ

Protecting the deployment pipeline

ในองค์กรก็มักจะมี change process ที่ไว้ควบคุมความเสี่ยงทั้ง operation และ security risk ทีนี้เมื่อเข้ามาสู่ DevOps ที่ใช้ deployment pipeline แล้ว

“เราจะยังต้องมี change management มั้ย”

คำตอบคือ ควรมี เพราะ change management ยังมีส่วนสำคัญในการดูความเสี่ยงและเห็นภาพรวมว่าใครทำอะไรไป แต่กระบวนการ change นั้นควรจะง่ายและไม่ใช้เวลามากอย่างในอดีต เช่น เมื่อเราใช้ deployment pipeline ไปเรื่อยๆจนมีสถิติว่ามันน่าเชื่อถือมากพอว่าไม่เกิดปัญหาในระบบ change เหล่านี้ก็ถูกมองได้ว่าเป็น change ที่มีความเสี่ยงต่ำเพียงพอที่จะเป็น standard change ได้

แล้ว standard change คืออะไร สำหรับคนที่ไม่คุ้น ก่อนอื่นมารู้จักประเภทของ change กันก่อนฮะ

• Standard change — เป็น change ที่ความเสี่ยงต่ำ การควบคุมอาจจมี approval หรืออาจจะมี pre-approve เลยก็ได้ มีขั้นตอนการ approve ที่สั้นง่าย
• Normal change — เป็น change ที่มีความเสี่ยงมากขึ้น ต้องได้รับการ review และ approve จากกลุ่มคนที่กำหนดเช่น Change Advisory Board (CAB)
• Urgent change — เป็นพวกเร่งด่วน ต้องทำเดี๋ยวนี้ พวกนี้ถือว่า risk สูง แต่ต้องทำเดี๋ยวนั้น เช่น การแก้ปัญหา ปกติจะต้องการ approval จากผู้บริหารระดับสูง

คือในอดีตเราอาจจะมี Normal change เยอะ แต่ต่อไป standard change จะมากขึ้น นอกจากนี้ เรายังสามารถเชื่อมต่อ change request นี้กับ item ในพวก tools ที่ใช้บริหารงาน เช่น JIRA, Rally ได้ด้วย ซึ่งการทำแบบนี้ ทำให้เรา trace ทุกอย่างเป็นระบบเดียวกันและย้อนไปดูข้อมูลได้ง่าย

ที่สำคัญ ถึงจะเป็น standard change ก็ต้องมี record ไว้ให้ครบถ้วน และต้องทำให้คนอื่นรับทราบร่วมกันว่ามี change นี้นะ ไม่ใช่ว่านึกอยากทำก็ทำได้โดยไม่บอกใคร

ถ้าอย่างนั้นเราจะยังมี normal change อีกมั้ย คำตอบคือ “มี” อีกนั่นแหละ ส่วนมากคืองาน manual ที่เหลืออยู่ เพราะแม้ว่าเราจะ automate มากแค่ไหน มันก็ไม่ได้ 100% หรือใน change ที่ความเสี่ยงสูง ซึ่ง normal change ก็เข้ากระบวนการเหมือนปกติที่มักทำกันทุกวันนี้ แต่เพื่อให้งานเร็วก็ควรควบคุมให้มีการเตรียมข้อมูลให้พร้อมก่อน review เพื่อให้การ review ทำได้ง่ายและมีประสิทธิภาพสูงสุด

แนะนำให้ลด Separation Of Duty (SOD)ออกบ้าง เดิมทีเราใช้หลัก SOD เป็นอย่างมากในการควบคุม แต่เมื่อระบบเรา complex มากขึ้น deploy ถี่ขึ้น การคุมแบบ SOD นี้ทำให้งานช้าและ feedback กลับไปที่คนทำงานช้าลง เราจึงเลือกวิธีอื่นๆในการคุมแทนเช่น pair programming, continuous inspection หรือ code review

สรุปของส่วนนี้ คือ เราควรต้องมี change อยู่ดี แต่ต้องทำให้ง่ายสั้นไวตอบโจทย์ธุรกิจและย้ายการลดความเสี่ยงจากการพึ่งพาการ review step ของผู้หลักผู้ใหญ่ ไปเป็นการทำ automate และ review โดยทีมให้มากขึ้น

Information Security as Everyon’s Job, Every Day

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

ก็มีข้อเสนอว่าเราควรรวมงาน Security นี้ไว้เป็นส่วนนึงในทุกๆขั้นของการทำ Software development พวกนี้เป็นคอนเซปที่เรียกว่า DevOpsSec สิ่งหนึ่งที่ควรรู้คือ

การ comply security ตั้งแต่ต้นนั้นถูกกว่าการแก้ในภายหลังมากๆ เพราะยิ่งแก้ตอนท้ายยิ่งยาก และใช้เวลามาก

ดังนั้น เราต้องให้ทีม มีส่วนร่วมในเรื่อง Security ให้เร็วที่สุดตั้งแต่เริ่ม Dev แรกๆเลยในแนวคิดเดิมตอน Dev ใหม่ๆเรามักไม่นึกถึงเรื่องพวกนี้เท่าไหร่ เอาแค่ให้ใช้ได้ก่อน ค่อยมาดู security ตอนจะขึ้น production กัน ซึ่งบ่อยครั้งก็มักจะแก้อะไรไม่ได้มาก เพราะแก้ยาก มีเวลาไม่พอ ธุรกิจรอไม่ได้ สุดท้ายก็ไปจบที่ exception ซึ่งก็เท่ากับปล่อยให้เป็นช่องโหว่กันไป

เทคนิคที่ทำให้งาน Sec เป็นส่วนหนึ่งของงาน DevOps เหมือนงานอื่นๆ

• Track ช่องโหว่ Security ร่วมกับ Defect อื่น — แทนที่จะแยก tools มา track โดยเฉพาะ ก็ track ร่วมกับ defect อื่นนี่แหละ เพราะพอมี tools แยกก็มักจะมีแต่ security เข้ากัน คนอื่นๆก็ไม่ได้ดู ไม่เห็นภาพเดียวกัน
• เมื่อมี security issue ก็ต้องมี Post-Motem คือการสอบสวนหาสาเหตุเหมือน incident อื่นๆ
• ใช้ shared repository เป็น ตัวกลางที่เก็บข้อมูล, script และ library ต่างๆที่ได้มาตรฐาน security เมื่อทุกคนเข้ามาดูก็เห็นและรู้ว่าอะไรคือ update ล่าสุด เป้าหมายสุดท้ายเลยคือ เราควรมี security library, service ไว้ให้บริการกับทุกๆ app
• รวมงาน security ไปอยู่เป็นส่วนหนึ่งของ deployment pipeline คือจะ test app ก็ test security ไปด้วยเลย มันก็มี tools เช่น Gauntlt ที่ design มาให้ integrate กับ deployment pipeline
• ใส่ monitor security ลงไปใน production ด้วย คือ เราจะเก็บ log ดู pattern และ set alert บนสิ่งบ่งชี้ที่น่าสงสัย เพื่อให้มีการแจ้งเตือนและมีข้อมูลที่เพียงพอต่อการวิเคราะห์ โดยใส่มันลงไปใน tools ที่ปกติ Dev, Ops ทีมใช้กันอยู่นั่นแหละ

Ensure security of application

การ Test app ก็ต้องมองว่าไม่ใช่แค่ความถูกต้องของฟังก์ชัน (happy paths) อย่างเดียวต้อง test เรื่อง InfoSec, Fraud ด้วย (Sad paths) ในการ test เราควรมี

• Static analysis — อันนี้ตรวจใน non-runtime environment แบบ inside-out เช่น ตรวจ code ว่าตรงไหนน่าจะเป็นช่องโหว่ได้บ้าง
• Dynamic analysis — อันนี้คือ test บน program ที่ run เลย ว่าที่ run แล้วมันมีช่องที่เจาะได้จริงมั้ย เป็นแบบ outside-in tools ที่ใช้ เช่น Arachni, OWASP ZAP อันนี้เราอาจรวมการทำ pen test บางอย่างไว้ตรงนี้ได้
• Dependency scanning — เป็นประเภทย่อยของแบบ static ว่ามี libraries หรือ executable files อะไรที่เกี่ยวข้อง และ dependencies เหล่านี้ปลอดภัย มักใช้ตรวจตอน build
• Source code integrity and code signing — ทุก version ที่ commit ต้องมีการ sign ทำ hash และเก็บ hash ไว้เป็น log เผื่อมาตรวจสอบได้ภายหลังว่าไฟล์โดนเปลี่ยนไปมั้ย

OWASP จะมี guidance ในการ set สิ่งต่างๆให้มี security เช่นควร store password ยังไง จะต้องการ cross site scripting ยังไง เป็นต้น ก็เป็นสิ่งที่ใครสนใจก็น่าไปหาอ่านกันต่อไป

Audit and compliance

ในส่วนของการ audit นั้น ก็ต้องเปลี่ยนไป ปกติในแบบเดิม Auditor จะมาสุ่มดู screenshot ของ setting ต่างๆ ซึ่งก็อาจจะไม่ได้เหมาะกับเครื่องที่ขึ้นลงเป็นว่าเล่นในเทคโนโลยีแบบนี้แล้ว เพราะ screenshot ตรงที่ดูไป ไม่แน่อีกห้านาทีข้างหน้ามันอาจจะถูกพังทิ้งแล้วก็ได้ ดังนั้นในแต่ละครั้งที่เราทำงานเราก็ต้องแน่ใจว่าเราเก็บหลักฐานต่างๆไว้ให้ตรวจสอบได้ เช่น การส่งข้อมูลที่ audit สนใจไปที่ telemetry ของเรา เช่น Splunk, Kibana สิ่งที่ auditor ต้องการก็จะอยู่ในที่ ที่ซึ่ง auditor สามารถไปดึงมาดูเองได้ และเห็น trace ของสิ่งที่เกิดขึ้น ในการเลือกเก็บข้อมูลต่างๆเหล่านี้ทีม security, compliance และ DevOps ต้องทำงานร่วมกันอย่างใกล้ชิดเพื่อให้เข้าใจ requirement ของข้อบังคับต่างๆ เช่น SOX-404, HIPAA, PCI DSS และตัดสินใจเก็บข้อมูลได้อย่างถูกต้อง

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

Note: อันนี้เป็นสรุปจากการอ่านหนังสือ DevOps Handbook อาจมีผิดถูกบ้าง + มีคหสตบ้างเล็กน้อย ถ้าสนใจไปซื้อหาอ่านเล่มจริงกันต่อได้

ติดตามตอนอื่นๆ

• DevOps Handbook #1: Introduction
• DevOps Handbook #2 : The three ways
• DevOps Handbook #3 : The three ways (Cont.)
• DevOps Handbook #4 : Where to start
• DevOps Handbook #5 : Team & Organization
• DevOps Handbook#6 : The technical practices of flow
• DevOps Handbook#7 : Automated and enable low-risk release
• DevOps Handbook#8 : The Technical Practices of Feedback
• DevOps Handbook#9 : The Technical practices of Continual Learning & Experimentation
• DevOps Handbook#10 : Change & Security Compliance