Change Window ที่ Rollback ได้จริง เช็กลิสต์ก่อน-ระหว่าง-หลัง

การเขียน firewall rule หนึ่งข้อแทบไม่เคยเป็นเรื่องยาก ที่พังมักเป็นทุกอย่างรอบ ๆ มันครับ เช่น ขั้นตอนที่ไม่มีใครเขียนไว้เพราะ "ทำแบบนี้ทุกครั้งอยู่แล้ว" การตรวจที่ถูกข้ามไปเพราะ window เริ่มช้า หรือ rollback ที่ต้องใช้ไฟล์ซึ่งไม่มีใครเซฟไว้ ทีม SRE ของ Google เคยให้ตัวเลขจากประสบการณ์ของตัวเองไว้ว่า ราว 70% ของ outage เกิดจากการเปลี่ยนแปลงในระบบที่ใช้งานจริง

บทความนี้คือบันทึกภาคสนามของผมเรื่องการรัน change window ที่เรียบเรียงใหม่เป็นเช็กลิสต์ให้คัดลอกไปใช้ได้ครับ ผมตั้งใจเขียนให้เป็นกลาง ไม่ผูกกับ vendor ใด ยกเว้นตอนที่ยกฟีเจอร์ของผลิตภัณฑ์หนึ่งมาเป็นตัวอย่าง เช็กลิสต์แบ่งเป็นก่อน ระหว่าง และหลัง โดยมีแนวคิดเดียวร้อยทั้งสามช่วงไว้ด้วยกัน คือ rollback เป็นแผนในตัวเอง ต้องเขียนและทดสอบก่อนเริ่ม change ไม่ใช่สิ่งที่มาคิดเอาตอนที่ต้องใช้

ทำไม change management จึงนับเป็น security control

หลายคนชอบจัด change management ไว้ในหมวด "กระบวนการ" และจัด security ไว้ในหมวด "เทคโนโลยี" แต่ NIST ไม่ได้มองแบบนั้น SP 800-128 Guide for Security-Focused Configuration Management of Information Systems (สิงหาคม พ.ศ. 2554 ปรับปรุงเดือนตุลาคม พ.ศ. 2562) แบ่งงานเป็นสี่เฟส ได้แก่ planning, identifying and implementing configurations, controlling configuration changes และ monitoring ในเฟส change control เป้าหมายคือให้ทุก change "ถูกระบุ เสนอ ทบทวน วิเคราะห์ผลกระทบด้าน security ทดสอบ และอนุมัติอย่างเป็นทางการก่อนนำไปใช้" และเครื่องมือที่เอกสารยกมาเพื่อจำกัด change ที่ไม่ได้รับอนุญาตก็มีทั้ง access control, process automation และ change window (SP 800-128 หัวข้อ 2.2.3)

rollback ก็อยู่ในนั้นด้วย ในรายการสิ่งที่ขั้นตอน configuration change control ควรครอบคลุม SP 800-128 ระบุ "requirements for rollback of changes in the event that problems occur" ไว้ชัดเจน และแบบฟอร์ม change request ตัวอย่างของเอกสารก็มีช่องสำหรับแผนงาน "including change implementation date, deliverables, and backout plan" (SP 800-128)

control catalogue พูดเรื่องเดียวกันในภาษาของ control ใน NIST SP 800-53 Rev. 5 ตระกูล Configuration Management (CM) มี control เหล่านี้ (ฉบับเต็ม PDF)

ถ้าอ่านรวมกัน สี่ข้อนี้ก็คือคำอธิบายของ change window อยู่แล้ว คือ เก็บสถานะเดิมไว้ ตกลง change ทดสอบ แล้วตรวจซ้ำหลังทำ ส่วนที่เหลือของบทความคือการทำเรื่องนี้ให้ได้จริงตอนตีหนึ่งกับทีมที่เหนื่อยแล้วครับ

 CHANGE WINDOW · written go/no-go                      window ◴ 
                                                                
                                                                
  SNAPSHOT     PRE-CHECK    GO/NO-GO      VERIFY        DONE    
                                                                
      ◆────────────○────────────◇────────────○────────────○     
      ▴                         ┆                               
      ┆                         ┆                               
      ┆                         ┆                               
      └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘                               
      rollback: restore snapshot                                
                                                                
  [✓] backup saved               [✓] rollback trigger           
                                                                
  [✓] success criteria           [✓] one go/no-go caller        
                                                                

ก่อนเปิด window

งานส่วนใหญ่ของ change window ที่ราบรื่นเกิดขึ้นหลายวันก่อน window จะเปิด

1. เขียน change เป็นขั้นตอน รวมถึงขั้นตอนที่ทำ "ตามความเคยชิน"

ขั้นตอนที่สร้างปัญหาคือขั้นตอนที่คนมีประสบการณ์ทำโดยไม่ต้องคิด เช่น ปิดแล้วเปิด NAT rule กลับ เพิ่ม static route หรือ clear ARP ที่อุปกรณ์ข้างเคียงหลังย้ายสาย ถ้าขั้นตอนไหนอยู่แค่ในหัวของใครสักคน มันก็จะหายไปจาก rollback ด้วย ให้ใส่ทุกขั้นลงในแผนเป็น pre-task, task หรือ post-task ที่มีหมายเลขกำกับครับ

2. เก็บสถานะปัจจุบันไว้ในที่ที่เข้าถึงได้

backup running configuration แล้วเก็บสำเนาไว้นอกอุปกรณ์ด้วย CM-2(3) ของ SP 800-53 ขอเรื่องนี้ตรง ๆ และนี่คือสิ่งเดียวที่ rollback ขาดไม่ได้ ถ้าเป็นงาน migrate ข้ามแพลตฟอร์ม ให้เทียบ config เก่ากับใหม่แบบวางคู่กันโดยขยาย object และ group ออกมาให้หมด object ที่หายไปจะได้โผล่ให้เห็นบนกระดาษ ไม่ใช่บน production ครับ

3. เก็บหลักฐานสถานะ "ก่อน"

รันการตรวจที่คุณจะรันหลัง change ตั้งแต่ตอนนี้ แล้วเซฟผลไว้ เช่น ping จากแต่ละ interface ไปยังเพื่อนบ้านที่รู้จัก routing table จำนวน session สถานะ VPN tunnel และการ login เข้าแอปพลิเคชันหลัก คำว่า "ก่อนหน้านี้มันก็ใช้ได้" มีประโยชน์ก็ต่อเมื่อคุณแสดงหลักฐานได้ครับ

4. เขียนว่าความสำเร็จหน้าตาเป็นอย่างไร

เลือกรายการตรวจสั้น ๆ ที่ผ่านหรือไม่ผ่านชัดเจน คำแนะนำของ Google เรื่อง canary release แนะนำให้เลือกเฉพาะ metric สำคัญไม่กี่ตัว "perhaps no more than a dozen" และเริ่มจากตัวชี้วัดที่บอกปัญหาจริงของบริการ (SRE Workbook, Canarying Releases) วินัยเดียวกันนี้ใช้กับ firewall change ได้ ถ้าบอกล่วงหน้าไม่ได้ว่าผลแบบไหนแปลว่า "หยุด" ตอนตีสองก็จะไม่มีใครตกลงกันได้ครับ

5. เขียน rollback trigger และเวลาไว้

แผนควรระบุเป็นลายลักษณ์อักษร

• เวลาเริ่ม
• เวลา checkpoint ที่ change ต้องผ่านการตรวจให้ได้
• deadline ที่ตัว rollback เองต้องเสร็จ โดยเผื่อเวลาไว้ก่อนที่ traffic ช่วงทำการจะกลับมา
• trigger คือผลลัพธ์ที่ชัดเจนว่าแปลว่า "rollback" เช่น มีการตรวจข้อใดข้อหนึ่งไม่ผ่านที่ checkpoint

จำกัดเวลาของการตัดสินใจ ไม่ใช่แค่ของงาน คำถามที่ checkpoint ไม่ใช่ "เราแก้ได้ไหม" แต่คือ "มันผ่านไหม" ถ้าคำตอบคือไม่ แผนก็บอกไว้แล้วว่าต้องทำอะไรต่อครับ

6. กำหนดคนเดียวที่เป็นผู้ประกาศ go หรือ no-go

บทเรื่อง incident ในหนังสือ SRE อธิบายเหตุผลของการมี incident commander คนเดียวที่ถือภาพรวมของสถานการณ์ และเล่าว่า change หนึ่งที่ทำด้วยเจตนาดีแต่ไม่ได้ประสานกับใครทำให้ outage แย่ลง (Managing Incidents) change window ก็คือสถานการณ์แบบเดียวกันที่วางแผนไว้ล่วงหน้า ให้คนคนเดียวประกาศแต่ละ checkpoint ส่วนคนอื่นรายงานข้อเท็จจริงให้คนนั้นครับ

ระหว่าง window

7. ทำทีละขั้นเล็ก ๆ และตรวจหลังทุกขั้น

ทำ change ตามลำดับที่เขียนไว้ และรันการตรวจที่เกี่ยวข้องหลังแต่ละขั้น แทนที่จะรวมไปตรวจตอนท้ายทีเดียว เมื่อมีอะไรพัง คุณจะรู้ทันทีว่าขั้นไหนเป็นต้นเหตุครับ บท release engineering ของ Google ให้เหตุผลเดียวกันในสเกลที่ใหญ่กว่า คือการ release บ่อยทำให้มี "fewer changes between versions" ซึ่งทำให้ทดสอบและแก้ปัญหาได้ง่ายขึ้น (Release Engineering)

8. ทำให้ขั้นตอนทางกายภาพย้อนกลับได้ด้วย

ถ้าต้องย้ายสาย ให้ติดป้ายพอร์ตเก่าและพอร์ตใหม่ก่อนแตะ การเสียบกลับที่เดิมจะได้เป็นขั้นตอนที่ใครก็ทำตามได้ที่หน้างานครับ

9. "test ผ่าน แต่ production ไม่ผ่าน" แปลว่าหยุด

นี่คือกฎที่รักษายากที่สุดและมีประโยชน์ที่สุด ถ้าการตรวจไม่ผ่านที่ checkpoint ให้เริ่ม rollback การ debug บน production เลย checkpoint ไปแล้วจะกินเวลาที่ rollback ต้องใช้ และแผนที่คุณเขียนอย่างใจเย็นเมื่อสัปดาห์ก่อนตัดสินได้ดีกว่าทีมที่อยู่ในช่วงท้ายของคืนที่ยาวนานครับ

10. สื่อสารวงเล็กและเป็นข้อเท็จจริงก่อน

อัปเดตคนใน change room ด้วยสิ่งที่เห็นจริง และยังไม่ประกาศวงกว้างจนกว่าจะรู้สาเหตุชัดเจน จะได้ไม่ต้องตามแก้ทีหลัง

ฟีเจอร์ของ vendor ที่ช่วยได้

firewall ส่วนใหญ่เก็บประวัติ configuration และให้ restore ได้ PAN-OS ของ Palo Alto Networks เป็นตัวอย่างที่เห็นภาพชัด เพราะแยก configuration ออกเป็นสองชุด ชุดแรกคือ candidate configuration ที่เก็บการแก้ไขที่ยังรออยู่ ชุดที่สองคือ running configuration ที่ firewall บังคับใช้จริง และ commit คือการทำให้การแก้ไขที่รออยู่มีผล (Commit, Validate, and Preview; Revert Firewall Configuration Changes)

การแยกแบบนี้ให้เครื่องมือหลายอย่างสำหรับ change window

• ก่อน commit: Preview Changes เทียบ candidate configuration กับ running configuration ส่วน Validate Changes รายงาน error และ warning ที่ commit จะเจอ โดยไม่แตะ running configuration (หน้าเดียวกัน)
• Snapshot: firewall สร้าง configuration version ให้ทุกครั้งที่ commit และคุณยังเซฟ named snapshot แล้ว export ไปเก็บที่ external host ได้ด้วย (Save and Export Firewall Configurations)
• Revert: คุณ revert candidate กลับไปเป็น running configuration เพื่อทิ้งการแก้ไขที่ยังไม่ commit ได้ หรือ load configuration version ก่อนหน้าหรือ named snapshot ก็ได้ การ load จะไปแทนที่ candidate configuration ดังนั้นค่าที่ restore มาจะมีผลก็ต่อเมื่อคุณ commit (Revert Firewall Configuration Changes)
• หลังจากนั้น: Config Audit เทียบ configuration สองเวอร์ชันและแสดงว่าใคร commit อะไร มีข้อจำกัดหนึ่งที่เอกสารระบุไว้ คือ audit ไม่บันทึกการ load และ revert (Perform a Config Audit) ดังนั้นให้เขียนการ rollback ไว้ใน change record ด้วยตัวเอง

                                                                
 ┌─ RUNNING CONFIG ────●┐             ┌─ SNAPSHOT ───────────┐  
 │                      │             │                      │  
 │ [ zones            ] │             │                      │  
 │ [ interfaces       ] │             │                      │  
 │ [ routes           ] │             │                      │  
 │ [ nat rules        ] │             │                      │  
 │ [ security rules   ] │             │                      │  
 │                      │             │                      │  
 │                      │             │                      │  
 └──────────────────────┘             └──────────────────────┘  
                                                                
 health checks after commit:                                    
                                                                
 ping ·   routes ·   app login ·                                
                                                                

บางแพลตฟอร์มทำได้มากกว่านั้นอีกขั้น คือ rollback ให้เอง ใน Junos OS ของ Juniper คำสั่ง commit confirmed จะเปิดใช้ change แบบชั่วคราว ถ้าไม่มีใครยืนยันภายใน 10 นาที (ค่า default) อุปกรณ์จะ "automatically rolls back to the previous configuration" (เอกสารของ Juniper) ฟีเจอร์นี้ป้องกันความผิดพลาดคลาสสิกอย่างการล็อกตัวเองออกจากอุปกรณ์ที่อยู่ไกล ไม่ว่าแพลตฟอร์มของคุณจะมีอะไรให้ ก็ควรลองใน lab ก่อนจะพึ่งมันใน window จริงครับ

rollback คือแผนชั้นหนึ่ง

แผน rollback ควรได้รับความใส่ใจเท่ากับแผน change ในทางปฏิบัติแปลว่า

1. มีขั้นตอนของตัวเอง เรียงลำดับ และเขียนละเอียดเท่าขั้นตอนเดินหน้า รวมถึงขั้นตอน "ตามความเคยชิน" ในลำดับย้อนกลับ
2. ระบุไฟล์หรือเวอร์ชัน ที่จะ restore และระบุว่าไฟล์อยู่ที่ไหน
3. เคยลองมาแล้ว อย่างน้อยใน lab หรือบนคู่อุปกรณ์ที่ไม่ใช่ production การ restore ที่ไม่เคยรันเลยเป็นแค่ความหวัง ไม่ใช่แผน
4. ทำเสร็จทันในเวลาที่เหลือ ถ้า rollback ใช้เวลา 40 นาที checkpoint ก็ต้องอยู่ก่อน deadline มากกว่า 40 นาที
5. มีการตรวจของตัวเอง คือรันหลักฐานสถานะ "ก่อน" จากข้อ 3 ซ้ำอีกครั้ง

หลังปิด window

ตรวจยืนยัน แล้วเฝ้าดูต่อ

รันการตรวจความสำเร็จอีกรอบแล้วเทียบกับหลักฐานสถานะ "ก่อน" นี่คือ CM-4(2) ในทางปฏิบัติ คือยืนยันว่า control ที่เปลี่ยนไป "operating as intended" (SP 800-53 Rev. 5) จากนั้นเฝ้าดู log และ monitoring ต่ออีกพักหนึ่ง เพราะปัญหาบางอย่างจะโผล่ก็ต่อเมื่อ traffic ช่วงเช้ามาถึงครับ

เขียนสรุปสั้น ๆ โดยไม่โทษใคร

อัปเดต change record และเอกสาร baseline ถ้าต้อง rollback การเขียนสรุปสั้น ๆ จะช่วยความพยายามครั้งถัดไป หนังสือ SRE นิยาม postmortem ว่าเป็น "a written record of an incident, its impact, the actions taken to mitigate or resolve it" พร้อม root cause และ action ที่ต้องตามต่อ และบอกว่า postmortem แบบ blameless จะโฟกัสที่สาเหตุโดยไม่กล่าวโทษบุคคล (Postmortem Culture) ถ้ามี vendor เกี่ยวข้อง ให้ขอให้เขา reproduce ปัญหาใน lab และตกลงวันของความพยายามครั้งถัดไปไว้ในการคุยครั้งเดียวกันครับ

เช็กลิสต์

ก่อน

• เขียนทุกขั้นตอนไว้ รวมถึงขั้นตอนที่ทำตามความเคยชิน
• backup running configuration และมีสำเนานอกอุปกรณ์
• เทียบ config เก่าและใหม่แล้ว (สำหรับงาน migrate)
• เก็บหลักฐานสถานะ "ก่อน" แล้ว
• มีการตรวจความสำเร็จที่ผ่าน/ไม่ผ่านชัดเจน
• เขียนเวลาเริ่ม checkpoint deadline และ rollback trigger ไว้แล้ว
• กำหนดผู้ประกาศ go/no-go หนึ่งคน
• เขียนขั้นตอน rollback และลองใน lab แล้ว

ระหว่าง

• ทำทีละขั้น ตรวจหลังทุกขั้น
• ติดป้ายสายก่อนย้าย
• ประกาศ checkpoint ตรงเวลา ไม่ผ่านแปลว่า rollback
• อัปเดตวงเล็กและเป็นข้อเท็จจริง

หลัง

• รันการตรวจซ้ำและเทียบกับสถานะ "ก่อน"
• เฝ้าดู monitoring ไปจนถึงช่วงเวลาทำการ
• อัปเดต change record และ baseline
• เขียนสรุปสั้น ๆ แบบ blameless ถ้ามีอะไรผิดพลาด

ทั้งหมดนี้ไม่มีอะไรฉลาดล้ำเลย และนั่นคือประเด็น change window จะไปได้ดีเมื่อการตัดสินใจที่ยากถูกทำไว้ตอนกลางวัน โดยคนที่เขียนมันลงไปให้ชัดครับ

แหล่งอ้างอิง

• NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems (หน้าเอกสาร)
• NIST SP 800-128 (PDF)
• NIST SP 800-53 Rev. 5, Security and Privacy Controls (หน้าเอกสาร)
• NIST SP 800-53 Rev. 5 (PDF)
• Google SRE Book: Introduction
• Google SRE Book: Release Engineering
• Google SRE Book: Managing Incidents
• Google SRE Book: Postmortem Culture
• Google SRE Workbook: Canarying Releases
• Palo Alto Networks: Commit, Validate, and Preview Firewall Configuration Changes (PAN-OS 11.1)
• Palo Alto Networks: Save and Export Firewall Configurations (PAN-OS 11.1)
• Palo Alto Networks: Revert Firewall Configuration Changes (PAN-OS 11.1)
• Palo Alto Networks: Perform a Config Audit (PAN-OS 11.1)
• Juniper Networks: Commit the Configuration (Junos OS CLI User Guide)