23
การปกป้อง Deployment Pipeline
T ลอดทั้งบทนี้ เราจะมาดูวิธีการปกป้อง deployment pipeline ของเรา รวมถึงวิธีการบรรลุเป้าหมายด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด (compliance) ในสภาพแวดล้อมการควบคุม (control environment) ของเรา ซึ่งรวมถึงการจัดการการเปลี่ยนแปลง (change management) และการแบ่งแยกหน้าที่ (separation of duty)
ผสานความปลอดภัยและการปฏิบัติตามข้อกำหนด (Compliance) เข้ากับกระบวนการอนุมัติการเปลี่ยนแปลง
องค์กร IT ที่มีขนาดใหญ่พอสมควรแทบทุกแห่งจะมีกระบวนการจัดการการเปลี่ยนแปลง (change management processes) อยู่แล้ว ซึ่งเป็นมาตรการควบคุมหลักในการลดความเสี่ยงด้านการดำเนินงานและความปลอดภัย ผู้จัดการด้าน compliance และผู้จัดการด้านความปลอดภัยจะพึ่งพากระบวนการจัดการการเปลี่ยนแปลงเพื่อตอบสนองข้อกำหนดด้าน compliance และพวกเขามักต้องการหลักฐานว่าการเปลี่ยนแปลงทั้งหมดได้รับการอนุมัติอย่างเหมาะสม
หากเราสร้าง deployment pipeline อย่างถูกต้องเพื่อให้การ deploy มีความเสี่ยงต่ำ การเปลี่ยนแปลงส่วนใหญ่ของเราจะไม่จำเป็นต้องผ่านกระบวนการอนุมัติการเปลี่ยนแปลงแบบ manual เพราะเราจะพึ่งพามาตรการควบคุมอย่างการทดสอบอัตโนมัติ (automated testing) และการตรวจสอบการผลิตเชิงรุก (proactive production monitoring)
ในขั้นตอนนี้ เราจะทำสิ่งที่จำเป็นเพื่อให้แน่ใจว่าเราสามารถผสานความปลอดภัยและ compliance เข้ากับกระบวนการจัดการการเปลี่ยนแปลงที่มีอยู่ได้อย่างสำเร็จ นโยบายการจัดการการเปลี่ยนแปลงที่มีประสิทธิผลจะยอมรับว่ามีความเสี่ยงที่แตกต่างกันสำหรับการเปลี่ยนแปลงแต่ละประเภท และการเปลี่ยนแปลงเหล่านั้นควรได้รับการจัดการที่แตกต่างกัน กระบวนการเหล่านี้ถูกกำหนดไว้ใน ITIL ซึ่งแบ่งการเปลี่ยนแปลงออกเป็นสามประเภท:
Standard changes (การเปลี่ยนแปลงมาตรฐาน): คือการเปลี่ยนแปลงที่มีความเสี่ยงต่ำซึ่งเป็นไปตามกระบวนการที่กำหนดไว้และได้รับการอนุมัติแล้ว แต่ก็สามารถได้รับการอนุมัติล่วงหน้าได้เช่นกัน ตัวอย่างเช่น การอัปเดตตารางภาษีของแอปพลิเคชันหรือรหัสประเทศประจำเดือน การเปลี่ยนแปลงเนื้อหาและสไตล์ของเว็บไซต์ และการแพตช์แอปพลิเคชันหรือระบบปฏิบัติการบางประเภทที่เข้าใจผลกระทบเป็นอย่างดี ผู้เสนอการเปลี่ยนแปลงไม่จำเป็นต้องได้รับการอนุมัติก่อนดำเนินการ deploy และการ deploy การเปลี่ยนแปลงสามารถทำได้โดยอัตโนมัติทั้งหมดและควรมีการบันทึกเพื่อให้สามารถตรวจสอบย้อนกลับได้
Normal changes (การเปลี่ยนแปลงปกติ): คือการเปลี่ยนแปลงที่มีความเสี่ยงสูงกว่าซึ่งจำเป็นต้องได้รับการตรวจสอบหรืออนุมัติจากผู้มีอำนาจอนุมัติการเปลี่ยนแปลงที่ตกลงกันไว้ ในหลายองค์กร ความรับผิดชอบนี้ถูกวางไว้อย่างไม่เหมาะสมกับคณะกรรมการที่ปรึกษาการเปลี่ยนแปลง (change advisory board หรือ CAB) หรือคณะกรรมการที่ปรึกษาการเปลี่ยนแปลงฉุกเฉิน (emergency change advisory board หรือ ECAB) ซึ่งอาจขาดความเชี่ยวชาญที่จำเป็นในการทำความเข้าใจผลกระทบทั้งหมดของการเปลี่ยนแปลง ซึ่งมักนำไปสู่ระยะเวลารอคอยที่ยาวนานเกินกว่าจะยอมรับได้ ปัญหานี้เป็นปัญหาโดยเฉพาะอย่างยิ่งกับการ deploy โค้ดขนาดใหญ่ ซึ่งอาจมีโค้ดใหม่หลายแสนหรือแม้กระทั่งหลายล้านบรรทัด ที่ถูกส่งโดยนักพัฒนาหลายร้อยคนตลอดระยะเวลาหลายเดือน เพื่อให้ normal changes ได้รับการอนุมัติ CAB จะต้องมีแบบฟอร์มคำขอเปลี่ยนแปลง (request for change หรือ RFC) ที่กำหนดอย่างชัดเจนว่าต้องใช้ข้อมูลใดบ้างสำหรับการตัดสินใจ go/no-go โดยทั่วไปแบบฟอร์ม RFC จะรวมถึงผลลัพธ์ทางธุรกิจที่ต้องการ utility และ warranty ที่วางแผนไว้ * กรณีทางธุรกิจพร้อมความเสี่ยงและทางเลือก และกำหนดการที่เสนอ †
Urgent changes (การเปลี่ยนแปลงเร่งด่วน): คือการเปลี่ยนแปลงฉุกเฉินและส่งผลให้มีความเสี่ยงสูงที่ต้องนำไปใช้งานในการผลิตทันที (เช่น การแพตช์ความปลอดภัยเร่งด่วน การกู้คืนบริการ) การเปลี่ยนแปลงเหล่านี้มักต้องการการอนุมัติจากผู้บริหารระดับสูง แต่อนุญาตให้จัดทำเอกสารภายหลังได้ เป้าหมายหลักของแนวปฏิบัติ DevOps คือการปรับปรุงกระบวนการ normal change ของเราให้เหมาะสำหรับการเปลี่ยนแปลงฉุกเฉินด้วย
จัดประเภทการเปลี่ยนแปลงที่มีความเสี่ยงต่ำกว่าใหม่เป็น Standard Changes
ตามหลักการแล้ว เมื่อมี deployment pipeline ที่เชื่อถือได้ เราจะสร้างชื่อเสียงในด้านการ deploy ที่รวดเร็ว เชื่อถือได้ และปราศจากปัญหา ถึงจุดนี้ เราควรขอความเห็นชอบจากฝ่ายปฏิบัติการ (Operations) และผู้มีอำนาจด้านการเปลี่ยนแปลงที่เกี่ยวข้องว่าการเปลี่ยนแปลงของเราได้แสดงให้เห็นแล้วว่ามีความเสี่ยงต่ำพอที่จะถูกกำหนดให้เป็น standard changes ซึ่งได้รับการอนุมัติล่วงหน้าจาก CAB ซึ่งจะช่วยให้เราสามารถ deploy สู่ระบบผลิตได้โดยไม่ต้องขออนุมัติเพิ่มเติม แม้ว่าการเปลี่ยนแปลงยังคงต้องถูกบันทึกอย่างถูกต้องก็ตาม
วิธีหนึ่งในการสนับสนุนข้อกล่าวอ้างว่าการเปลี่ยนแปลงของเรามีความเสี่ยงต่ำคือการแสดงประวัติการเปลี่ยนแปลงในช่วงเวลาที่มีนัยสำคัญ (เช่น หลายเดือนหรือหลายไตรมาส) และให้รายการปัญหาที่เกิดขึ้นในการผลิตในช่วงเวลาเดียวกันทั้งหมด หากเราสามารถแสดงอัตราความสำเร็จของการเปลี่ยนแปลงที่สูงและ MTTR ที่ต่ำ เราสามารถยืนยันได้ว่าเรามีสภาพแวดล้อมการควบคุมที่ป้องกันข้อผิดพลาดในการ deploy ได้อย่างมีประสิทธิภาพ รวมถึงพิสูจน์ว่าเราสามารถตรวจจับและแก้ไขปัญหาที่เกิดขึ้นได้อย่างรวดเร็วและมีประสิทธิภาพ
แม้ว่าการเปลี่ยนแปลงของเราจะถูกจัดประเภทเป็น standard changes แต่ก็ยังคงต้องแสดงให้เห็นและบันทึกในระบบจัดการการเปลี่ยนแปลงของเรา (เช่น Remedy หรือ ServiceNow) ตามอุดมคติแล้ว การ deploy ควรดำเนินการโดยอัตโนมัติผ่านเครื่องมือ configuration management และ deployment pipeline ของเรา และผลลัพธ์ควรถูกบันทึกโดยอัตโนมัติเช่นกัน การทำเช่นนี้จะทำให้ทุกคนในองค์กรของเรา (ไม่ว่าจะเป็น DevOps หรือไม่) สามารถมองเห็นการเปลี่ยนแปลงของเราได้ นอกเหนือจากการเปลี่ยนแปลงอื่นๆ ทั้งหมดที่เกิดขึ้นในองค์กร
เราสามารถเชื่อมโยงบันทึกคำขอเปลี่ยนแปลงเหล่านี้กับรายการเฉพาะในเครื่องมือวางแผนงานของเรา (เช่น JIRA, Rally, LeanKit) โดยอัตโนมัติ ซึ่งช่วยสร้างบริบทเพิ่มเติมให้กับการเปลี่ยนแปลงของเรา เช่น การเชื่อมโยงไปยัง defects ของฟีเจอร์ incidents ในการผลิต หรือ user stories ซึ่งสามารถทำได้ในลักษณะที่มีน้ำหนักเบาโดยการใส่หมายเลข ticket ‡ จากเครื่องมือวางแผนในคอมเมนต์ที่เกี่ยวข้องกับการ check-in ใน version control การทำเช่นนี้ทำให้เราสามารถสืบย้อนจากการ deploy ในระบบผลิตไปยังการเปลี่ยนแปลงใน version control และจากนั้นสืบย้อนต่อไปยัง tickets ในเครื่องมือวางแผน
การสร้างความสามารถในการตรวจสอบย้อนกลับและบริบทนี้ควรทำได้ง่ายและไม่สร้างภาระหนักเกินไปสำหรับวิศวกร การเชื่อมโยงไปยัง user stories ข้อกำหนด หรือ defects ก็เพียงพอแล้ว—รายละเอียดเพิ่มเติมใดๆ เช่น การเปิด ticket สำหรับทุก commit ใน version control มักจะไม่มีประโยชน์ เป็นสิ่งที่ไม่จำเป็นและไม่พึงปรารถนา เพราะจะสร้างแรงเสียดทานอย่างมากในการทำงานประจำวัน
สิ่งที่ต้องทำเมื่อการเปลี่ยนแปลงถูกจัดประเภทเป็น Normal Changes
สำหรับการเปลี่ยนแปลงที่ไม่สามารถจัดให้เป็น standard changes ได้ การเปลี่ยนแปลงเหล่านั้นจะถูกพิจารณาว่าเป็น normal changes และจะต้องได้รับการอนุมัติจาก CAB อย่างน้อยบางส่วนก่อนการ deploy ในกรณีนี้ เป้าหมายของเรายังคงอยู่ที่การทำให้แน่ใจว่าสามารถ deploy ได้อย่างรวดเร็ว แม้ว่าจะไม่ได้เป็นระบบอัตโนมัติเต็มรูปแบบก็ตาม
ในกรณีนี้ เราต้องแน่ใจว่าคำขอเปลี่ยนแปลงที่ส่งไปนั้นสมบูรณ์และถูกต้องมากที่สุดเท่าที่จะเป็นไปได้ โดยให้ข้อมูลทุกอย่างที่ CAB ต้องการเพื่อประเมินการเปลี่ยนแปลงของเรา—เพราะถ้าคำขอเปลี่ยนแปลงของเรามีรูปแบบที่ไม่ถูกต้องหรือไม่สมบูรณ์ มันก็จะถูกส่งกลับมาให้เรา ทำให้เวลาในการนำขึ้นสู่ระบบผลิตนานขึ้น และทำให้เกิดข้อสงสัยว่าเราเข้าใจเป้าหมายของกระบวนการจัดการการเปลี่ยนแปลงจริงหรือไม่
เราสามารถทำให้การสร้าง RFC ที่สมบูรณ์และถูกต้องเป็นไปโดยอัตโนมัติได้เกือบแน่นอน โดยการกรอกรายละเอียดว่าสิ่งใดจะถูกเปลี่ยนแปลงลงใน ticket ตัวอย่างเช่น เราสามารถสร้าง ServiceNow change ticket โดยอัตโนมัติพร้อมลิงก์ไปยัง JIRA user story พร้อมด้วย build manifests และผลลัพธ์การทดสอบจากเครื่องมือ deployment pipeline ของเรา และลิงก์ไปยังสคริปต์ที่จะทำงานและผลลัพธ์ dry run ของคำสั่งเหล่านี้
เนื่องจากการเปลี่ยนแปลงที่เราส่งจะถูกประเมินโดยคนด้วยตนเอง การอธิบายบริบทของการเปลี่ยนแปลงจึงยิ่งมีความสำคัญมากขึ้น ซึ่งรวมถึงการระบุว่าเหตุใดจึงทำการเปลี่ยนแปลง (เช่น ให้ลิงก์ไปยังฟีเจอร์ ข้อบกพร่อง หรือ incidents) ใครบ้างที่ได้รับผลกระทบจากการเปลี่ยนแปลง และสิ่งใดที่จะถูกเปลี่ยนแปลง
เป้าหมายของเราคือการแบ่งปันหลักฐานและ artifacts ที่ทำให้เรามั่นใจว่าการเปลี่ยนแปลงจะทำงานในระบบผลิตได้ตามที่ออกแบบไว้ แม้ว่าโดยทั่วไปแล้ว RFC จะมีช่องข้อความอิสระ (free-form text fields) เราควรให้ลิงก์ไปยังข้อมูลที่เครื่องอ่านได้ (machine-readable data) เพื่อให้ผู้อื่นสามารถบูรณาการและประมวลผลข้อมูลของเราได้ (เช่น ลิงก์ไปยังไฟล์ JSON)
ใน toolchains หลายๆ ระบบ สามารถทำได้ในลักษณะที่สอดคล้องกับข้อกำหนดและเป็นอัตโนมัติเต็มรูปแบบ โดยการเชื่อมโยงหมายเลข ticket กับทุก commit ใน version control เมื่อเราปล่อยการเปลี่ยนแปลงใหม่ เราสามารถรวบรวม commits ที่รวมอยู่ในการเปลี่ยนแปลงนั้นโดยอัตโนมัติ และประกอบ RFC ขึ้นมาโดยการแจกแจง ticket หรือ bug ทุกรายการที่เสร็จสมบูรณ์หรือถูกแก้ไขในการเปลี่ยนแปลงเหล่านี้
เมื่อส่ง RFC แล้ว สมาชิกที่เกี่ยวข้องของ CAB จะตรวจสอบ ดำเนินการ และอนุมัติการเปลี่ยนแปลงเหล่านี้เช่นเดียวกับคำขอเปลี่ยนแปลงอื่นๆ ที่ส่งมา หากทุกอย่างเป็นไปด้วยดี ผู้มีอำนาจด้านการเปลี่ยนแปลงจะชื่นชอบความละเอียดถี่ถ้วนและรายละเอียดของการเปลี่ยนแปลงที่เราส่ง เพราะเราได้ให้พวกเขาสามารถตรวจสอบความถูกต้องของข้อมูลที่เราให้ได้อย่างรวดเร็ว (เช่น การดูลิงก์ไปยัง artifacts จากเครื่องมือ deployment pipeline ของเรา) อย่างไรก็ตาม เป้าหมายของเราควรคือการแสดงประวัติความสำเร็จของการเปลี่ยนแปลงที่เป็นแบบอย่างอย่างต่อเนื่อง เพื่อที่เราจะได้รับความเห็นชอบในที่สุดว่าการเปลี่ยนแปลงอัตโนมัติของเราสามารถจัดประเภทเป็น standard changes ได้อย่างปลอดภัย
CASE STUDY
การเปลี่ยนแปลงโครงสร้างพื้นฐานอัตโนมัติในรูปแบบ Standard Changes ที่ Salesforce.com (2012)
Salesforce ก่อตั้งขึ้นในปี 2000 โดยมีเป้าหมายเพื่อทำให้การจัดการความสัมพันธ์กับลูกค้า (customer relationship management) พร้อมใช้งานและส่งมอบเป็นบริการได้ง่าย ผลิตภัณฑ์ของ Salesforce ได้รับการยอมรับอย่างกว้างขวางในตลาด นำไปสู่การเข้าตลาดหลักทรัพย์ (IPO) ที่ประสบความสำเร็จในปี 2004 3 ภายในปี 2007 บริษัทมีลูกค้าองค์กรมากกว่าห้าหมื่นเก้าพันราย ประมวลผลธุรกรรมหลายร้อยล้านรายการต่อวัน โดยมีรายได้ต่อปี 497 ล้านดอลลาร์ 4
อย่างไรก็ตาม ในช่วงเวลาเดียวกันนั้น ความสามารถในการพัฒนาและปล่อยฟังก์ชันใหม่ ๆ ให้กับลูกค้ากลับชะงักงัน ในปี 2006 พวกเขาปล่อย major release ให้ลูกค้า 4 ครั้ง แต่ในปี 2007 พวกเขาทำได้เพียงครั้งเดียว แม้จะจ้างวิศวกรเพิ่มขึ้นก็ตาม 5 ผลลัพธ์คือจำนวนฟีเจอร์ที่ส่งมอบต่อทีมลดลงเรื่อย ๆ และระยะห่างระหว่าง major releases ก็เพิ่มมากขึ้นเรื่อย ๆ และเนื่องจาก batch size ของแต่ละ release ใหญ่ขึ้นเรื่อย ๆ ผลลัพธ์ของการ deploy ก็แย่ลงเรื่อย ๆ เช่นกัน
Karthik Rajan ซึ่งดำรงตำแหน่ง VP of Infrastructure Engineering ในขณะนั้น รายงานในการนำเสนอปี 2013 ว่าปี 2007 เป็น "ปีสุดท้ายที่ซอฟต์แวร์ถูกสร้างและจัดส่งโดยใช้กระบวนการ waterfall และเป็นช่วงที่เราเริ่มเปลี่ยนไปสู่กระบวนการส่งมอบที่เพิ่มมากขึ้น (incremental delivery process)" 6
ในงาน DevOps Enterprise Summit ปี 2014 Dave Mangot และ Reena Mathew ได้บรรยายถึงการเปลี่ยนแปลงสู่ DevOps ที่กินเวลาหลายปีซึ่งเริ่มต้นในปี 2009 ตามที่ Mangot และ Mathew กล่าว โดยการนำหลักการและแนวปฏิบัติของ DevOps มาใช้ บริษัทสามารถลดระยะเวลารอคอยในการ deploy จากหกวันเหลือห้านาทีภายในปี 2013 ส่งผลให้พวกเขาสามารถขยายขีดความสามารถได้ง่ายขึ้น ทำให้สามารถประมวลผลธุรกรรมมากกว่าหนึ่งพันล้านรายการต่อวัน 7
หนึ่งในหัวข้อหลักของการเปลี่ยนแปลงของ Salesforce คือการทำให้วิศวกรรมคุณภาพ (quality engineering) เป็นหน้าที่ของทุกคน ไม่ว่าพวกเขาจะอยู่ในฝ่าย Development, Operations หรือ Infosec เพื่อให้บรรลุเป้าหมายนี้ พวกเขาบูรณาการการทดสอบอัตโนมัติ (automated testing) เข้ากับทุกขั้นตอนของการสร้างแอปพลิเคชันและสภาพแวดล้อม รวมถึงกระบวนการ continuous integration และ deployment และสร้างเครื่องมือโอเพนซอร์สชื่อ Rouster เพื่อทำการทดสอบฟังก์ชัน (functional testing) ของ Puppet modules ของพวกเขา 8
พวกเขายังเริ่มทำ destructive testing อย่างสม่ำเสมอ ซึ่งเป็นคำที่ใช้ในอุตสาหกรรมการผลิตหมายถึงการทดสอบความทนทานเป็นเวลานานภายใต้สภาวะการทำงานที่รุนแรงที่สุดจนกระทั่งชิ้นส่วนที่ถูกทดสอบเสียหาย ทีม Salesforce เริ่มทดสอบบริการของตนภายใต้โหลดที่สูงขึ้นเรื่อย ๆ อย่างสม่ำเสมอจนกว่าบริการจะพัง ซึ่งช่วยให้พวกเขาเข้าใจโหมดความล้มเหลว (failure modes) และแก้ไขได้อย่างเหมาะสม ไม่น่าแปลกใจที่ผลลัพธ์คือคุณภาพบริการที่สูงขึ้นอย่างมีนัยสำคัญภายใต้โหลดการผลิตปกติ 9
ฝ่ายความปลอดภัยของข้อมูล (Information Security) ยังทำงานร่วมกับวิศวกรรมคุณภาพ (Quality Engineering) ตั้งแต่ขั้นตอนแรกสุดของโครงการ โดยร่วมมือกันอย่างต่อเนื่องในขั้นตอนสำคัญ เช่น การออกแบบสถาปัตยกรรมและการออกแบบทดสอบ รวมถึงการบูรณาการเครื่องมือด้านความปลอดภัยเข้ากับกระบวนการทดสอบอัตโนมัติอย่างเหมาะสม 10
สำหรับ Mangot และ Mathew หนึ่งในความสำเร็จที่สำคัญจากความสามารถในการทำซ้ำและความเข้มงวดที่พวกเขาออกแบบไว้ในกระบวนการคือการที่กลุ่มจัดการการเปลี่ยนแปลง (change management group) แจ้งว่า "การเปลี่ยนแปลงโครงสร้างพื้นฐานที่ทำผ่าน Puppet จะถูกปฏิบัติเสมือนเป็น 'standard changes' ซึ่งต้องการการอนุมัติจาก CAB น้อยลงมากหรือแทบไม่ต้องอนุมัติเลย" อย่างไรก็ตาม พวกเขาตั้งข้อสังเกตว่า "การเปลี่ยนแปลงโครงสร้างพื้นฐานที่ทำด้วยตนเอง (manual) ยังคงต้องได้รับการอนุมัติ" 11
Salesforce ไม่เพียงแต่บูรณาการกระบวนการ DevOps เข้ากับกระบวนการจัดการการเปลี่ยนแปลงเท่านั้น แต่ยังสร้างแรงจูงใจเพิ่มเติมในการทำให้กระบวนการเปลี่ยนแปลงเป็นอัตโนมัติสำหรับโครงสร้างพื้นฐานส่วนอื่น ๆ ของพวกเขาอีกด้วย
ใช้การตรวจสอบโค้ด (Code Review) เพื่อสร้างการแบ่งแยกหน้าที่ (Separation of Duty)
เป็นเวลาหลายทศวรรษที่เราใช้การแบ่งแยกหน้าที่ (separation of duty) เป็นหนึ่งในมาตรการควบคุมหลักในการลดความเสี่ยงของการทุจริตหรือข้อผิดพลาดในกระบวนการพัฒนาซอฟต์แวร์ แนวปฏิบัติที่ยอมรับกันใน SDLC ส่วนใหญ่คือการให้การเปลี่ยนแปลงของนักพัฒนาถูกส่งไปยัง code librarian ซึ่งจะเป็นผู้ตรวจสอบและอนุมัติการเปลี่ยนแปลงก่อนที่ IT Operations จะนำการเปลี่ยนแปลงนั้นขึ้นสู่ระบบผลิต
ยังมีการแบ่งแยกหน้าที่ที่ไม่เป็นที่ถกเถียงอีกมากมายในงาน Ops เช่น ผู้ดูแลเซิร์ฟเวอร์ควรจะสามารถดู logs ได้ แต่ไม่ควรลบหรือแก้ไข logs เพื่อป้องกันไม่ให้ผู้ที่มีสิทธิ์เข้าถึงระดับสูงลบหลักฐานการทุจริตหรือปัญหาอื่น ๆ
เมื่อเราทำการ deploy สู่ระบบผลิตน้อยครั้ง (เช่น ปีละครั้ง) และเมื่องานของเรามีความซับซ้อนน้อยลง การแบ่งงานเป็นส่วน ๆ และการส่งต่องานก็เป็นวิธีที่ทำได้ อย่างไรก็ตาม เมื่อความซับซ้อนและความถี่ในการ deploy เพิ่มขึ้น การทำ deploy สู่ระบบผลิตให้ประสบความสำเร็จนั้นต้องการให้ทุกคนใน value stream สามารถเห็นผลลัพธ์ของการกระทำของตนได้อย่างรวดเร็ว
แนวทางดั้งเดิมในการใช้การแบ่งแยกหน้าที่มักจะขัดขวางสิ่งนี้โดยการชะลอและลด feedback ที่วิศวกรได้รับจากงานของตน ซึ่งป้องกันไม่ให้วิศวกรรับผิดชอบอย่างเต็มที่ต่อคุณภาพของงานของตน และลดความสามารถขององค์กรในการสร้างการเรียนรู้ขององค์กร (organizational learning)
ดังนั้น เมื่อใดก็ตามที่เป็นไปได้ เราไม่ควรใช้การแบ่งแยกหน้าที่เป็นมาตรการควบคุม แต่เราควรเลือกมาตรการควบคุมอื่น เช่น การเขียนโปรแกรมแบบคู่ (pair programming) การตรวจสอบ code check-ins อย่างต่อเนื่อง และการตรวจสอบโค้ด (code review) มาตรการควบคุมเหล่านี้สามารถให้ความมั่นใจที่จำเป็นเกี่ยวกับคุณภาพของงานของเรา ยิ่งไปกว่านั้น การนำมาตรการควบคุมเหล่านี้มาใช้ หากจำเป็นต้องมีการแบ่งแยกหน้าที่ เราสามารถแสดงให้เห็นว่าเราได้ผลลัพธ์ที่เทียบเท่ากับมาตรการควบคุมที่เราสร้างขึ้น
CASE STUDY
การปฏิบัติตาม PCI Compliance และเรื่องราวเชิงเตือนใจเกี่ยวกับการแบ่งแยกหน้าที่ที่ Etsy (2014) §
Bill Massie เป็น development manager ที่ Etsy และรับผิดชอบแอปพลิเคชันการชำระเงินที่ชื่อ ICHT (ย่อมาจาก "I Can Haz Tokens") ICHT รับคำสั่งซื้อด้วยเครดิตของลูกค้าผ่านชุดแอปพลิเคชันการประมวลผลการชำระเงินที่พัฒนาภายในองค์กร ซึ่งจัดการการสั่งซื้อออนไลน์โดยการรับข้อมูลบัตรของลูกค้า ทำการ tokenize สื่อสารกับผู้ประมวลผลการชำระเงิน และดำเนินการธุรกรรมคำสั่งซื้อให้เสร็จสมบูรณ์ 12
เนื่องจากขอบเขตของสภาพแวดล้อมข้อมูลผู้ถือบัตร (cardholder data environment หรือ CDE) ตามมาตรฐาน Payment Card Industry Data Security Standards (PCI DSS) คือ "บุคลากร กระบวนการ และเทคโนโลยีที่จัดเก็บ ประมวลผล หรือส่งข้อมูลผู้ถือบัตรหรือข้อมูลรับรองความถูกต้องที่ละเอียดอ่อน" รวมถึงส่วนประกอบของระบบที่เชื่อมต่อใด ๆ แอปพลิเคชัน ICHT จึงอยู่ในขอบเขตของ PCI DSS 13
เพื่อจำกัดขอบเขตของ PCI DSS แอปพลิเคชัน ICHT ถูกแยกทางกายภาพและทางตรรกะจากส่วนอื่น ๆ ขององค์กร Etsy และถูกจัดการโดยทีมแอปพลิเคชันที่แยกต่างหากโดยสิ้นเชิง ซึ่งประกอบด้วยนักพัฒนา วิศวกรฐานข้อมูล วิศวกรเครือข่าย และวิศวกร ops สมาชิกในทีมแต่ละคนได้รับแล็ปท็อปสองเครื่อง: เครื่องหนึ่งสำหรับ ICHT (ซึ่งถูกกำหนดค่าแตกต่างกันไปตามข้อกำหนด DSS และถูกล็อกในตู้เซฟเมื่อไม่ใช้งาน) และอีกเครื่องหนึ่งสำหรับงานอื่น ๆ ของ Etsy
การทำเช่นนี้ทำให้พวกเขาสามารถแยกสภาพแวดล้อม CDE ออกจากส่วนอื่น ๆ ขององค์กร Etsy โดยจำกัดขอบเขตของข้อบังคับ PCI DSS ไว้เฉพาะพื้นที่ที่แยกออกไป ระบบที่ประกอบเป็น CDE ถูกแยกออก (และจัดการแตกต่างกัน) จากสภาพแวดล้อมอื่น ๆ ของ Etsy ในระดับกายภาพ เครือข่าย ซอร์สโค้ด และโครงสร้างพื้นฐานเชิงตรรกะ นอกจากนี้ CDE ยังถูกสร้างและดำเนินการโดยทีมข้ามสายงาน (cross-functional team) ที่รับผิดชอบเฉพาะ CDE เท่านั้น
ทีม ICHT ต้องปรับเปลี่ยนแนวปฏิบัติ continuous delivery ของตนเพื่อรองรับความจำเป็นในการอนุมัติโค้ด ตามข้อ 6.3.2 ของ PCI DSS v3.1 ทีมควรตรวจสอบโค้ดที่กำหนดเองทั้งหมดก่อนปล่อยสู่ระบบผลิตหรือลูกค้าเพื่อระบุช่องโหว่ที่อาจเกิดขึ้น (โดยใช้กระบวนการ manual หรือ automated) ดังนี้: 14
• การเปลี่ยนแปลงโค้ดได้รับการตรวจสอบโดยบุคคลอื่นที่ไม่ใช่ผู้เขียนโค้ดต้นฉบับ และโดยบุคคลที่มีความรู้เกี่ยวกับเทคนิคการตรวจสอบโค้ดและแนวปฏิบัติการเขียนโค้ดที่ปลอดภัยหรือไม่?
• การตรวจสอบโค้ดช่วยรับรองว่าโค้ดถูกพัฒนาตามแนวปฏิบัติการเขียนโค้ดที่ปลอดภัยหรือไม่?
• มีการแก้ไขที่เหมาะสมก่อนการปล่อยหรือไม่?
• ผลลัพธ์การตรวจสอบโค้ดได้รับการตรวจสอบและอนุมัติโดยฝ่ายจัดการก่อนการปล่อยหรือไม่?
เพื่อให้เป็นไปตามข้อกำหนดนี้ ทีมงานตัดสินใจในตอนแรกที่จะให้ Massie เป็นผู้ approve การเปลี่ยนแปลงที่รับผิดชอบในการ deploy การเปลี่ยนแปลงใด ๆ สู่ระบบผลิต การ deploy ที่ต้องการจะถูกทำเครื่องหมายใน JIRA และ Massie จะทำเครื่องหมายว่ามีการตรวจสอบและอนุมัติแล้ว และทำการ deploy ด้วยตนเองสู่ระบบผลิตของ ICHT 15
สิ่งนี้ทำให้ Etsy สามารถปฏิบัติตามข้อกำหนด PCI DSS และได้รับรายงานการปฏิบัติตาม (Report of Compliance) ที่ลงนามจากผู้ประเมินของพวกเขา อย่างไรก็ตาม ในส่วนของทีมงาน ได้เกิดปัญหาที่สำคัญตามมา
Massie สังเกตว่าผลข้างเคียงที่น่ากังวลอย่างหนึ่งคือ "ระดับของ 'การแบ่งเป็นส่วน ๆ' (compartmentalization) ที่เกิดขึ้นในทีม ICHT ซึ่งไม่มีกลุ่มอื่นใดที่ Etsy ประสบ ตั้งแต่เราใช้การแบ่งแยกหน้าที่และมาตรการควบคุมอื่น ๆ ที่ PCI DSS กำหนด ไม่มีใครสามารถเป็น full-stack engineer ในสภาพแวดล้อมนี้ได้" 16
ส่งผลให้ ในขณะที่ทีม Development และ Operations อื่น ๆ ที่ Etsy ทำงานร่วมกันอย่างใกล้ชิดและ deploy การเปลี่ยนแปลงได้อย่างราบรื่นและมั่นใจ Massie ตั้งข้อสังเกตว่า:
ภายในสภาพแวดล้อม PCI ของเรา มีความกลัวและความลังเลเกี่ยวกับการ deploy และการบำรุงรักษา เพราะไม่มีใครมองเห็นภาพนอกส่วนของตนใน software stack การเปลี่ยนแปลงที่ดูเหมือนเล็กน้อยที่เราทำกับวิธีการทำงานของเรา ดูเหมือนจะสร้างกำแพงที่ทะลุผ่านไม่ได้ระหว่าง developers และ ops และสร้างความตึงเครียดที่ปฏิเสธไม่ได้ ซึ่งไม่มีใครที่ Etsy ประสบมาตั้งแต่ปี 2008 แม้ว่าคุณจะมั่นใจในส่วนของคุณ มันเป็นไปไม่ได้ที่จะมั่นใจว่าการเปลี่ยนแปลงของคนอื่นจะไม่ทำให้ส่วนของคุณใน stack เสียหาย 17
กรณีศึกษานี้แสดงให้เห็นว่าการปฏิบัติตามข้อกำหนด (compliance) เป็นไปได้ในองค์กรที่ใช้ DevOps อย่างไรก็ตาม เรื่องราวที่อาจเป็นเครื่องเตือนใจก็คือ คุณธรรมทั้งหมดที่เราเชื่อมโยงกับทีม DevOps ที่มีประสิทธิภาพสูงนั้นเปราะบาง—แม้แต่ทีมที่มีประสบการณ์ร่วมกันด้วยความไว้วางใจสูงและเป้าหมายร่วมกัน ก็สามารถเริ่มต้นดิ้นรนเมื่อกลไกการควบคุมที่ใช้ความไว้วางใจต่ำถูกนำมาใช้
CASE STUDY: NEW TO THE SECOND EDITION
ความร่วมมือระหว่างฝ่ายธุรกิจและเทคโนโลยีสู่การปล่อย "แบบไม่ต้องกลัว" สิบครั้งต่อวันที่ Capital One (2020)
ในช่วงเจ็ดปีที่ผ่านมา Capital One ได้ดำเนินการเปลี่ยนแปลงสู่ Agile/DevOps ในช่วงเวลานั้น พวกเขาเปลี่ยนจาก waterfall เป็น Agile จาก outsource เป็น insource และ open-source จาก monolithic เป็น microservices จาก data centers สู่ระบบคลาวด์
แต่พวกเขายังคงเผชิญกับปัญหาใหญ่: แพลตฟอร์มบริการลูกค้าที่มีอายุมาก แพลตฟอร์มนี้ให้บริการลูกค้าบัตรเครดิต Capital One หลายสิบล้านรายและสร้างมูลค่าหลายร้อยล้านดอลลาร์ให้กับธุรกิจ 18 มันเป็นแพลตฟอร์มที่สำคัญ แต่ก็เริ่มแสดงอาการเก่าลงและไม่สามารถตอบสนองความต้องการของลูกค้าหรือความต้องการเชิงกลยุทธ์ภายในของบริษัทได้อีกต่อไป พวกเขาจำเป็นต้องไม่เพียงแค่แก้ปัญหาด้านเทคโนโลยี/ความเสี่ยงทางไซเบอร์ของแพลตฟอร์มที่มีอายุมากเท่านั้น แต่ยังต้องเพิ่ม NPV (net present value) ของระบบอีกด้วย
"สิ่งที่เรามีคือผลิตภัณฑ์จาก vendor ที่ใช้ mainframe ซึ่งถูกปะแผลจนถึงจุดที่ทีมระบบและทีมปฏิบัติการมีขนาดใหญ่เท่าตัวผลิตภัณฑ์เอง ... เราต้องการระบบที่ทันสมัยเพื่อแก้ปัญหาทางธุรกิจ" Rakesh Goyal ผู้อำนวยการฝ่ายวิศวกรรมเทคโนโลยี (Director, Technology Engineering) ที่ Capital One กล่าว 19
พวกเขาเริ่มต้นด้วยชุดหลักการในการทำงาน ประการแรก พวกเขาทำงานย้อนกลับจากความต้องการของลูกค้า ประการที่สอง พวกเขาตั้งใจที่จะส่งมอบคุณค่าแบบเพิ่มทีละน้อย (iteratively) เพื่อเพิ่มการเรียนรู้สูงสุดและลดความเสี่ยงให้เหลือน้อยที่สุด และประการที่สาม พวกเขาต้องการหลีกเลี่ยง anchoring bias นั่นคือ พวกเขาต้องการให้แน่ใจว่าพวกเขาไม่ได้แค่สร้างม้าที่เร็วและแข็งแรงขึ้น แต่กำลังแก้ปัญหาจริง ๆ 20
ด้วยหลักการชี้นำเหล่านี้ พวกเขาเริ่มดำเนินการเปลี่ยนแปลง ก่อนอื่น พวกเขามองดูแพลตฟอร์มและกลุ่มลูกค้าของตน จากนั้นพวกเขาแบ่งลูกค้าออกเป็นกลุ่มตามความต้องการและฟังก์ชันการทำงานที่จำเป็น สิ่งสำคัญคือ พวกเขาคิดเชิงกลยุทธ์เกี่ยวกับว่าใครคือลูกค้าของพวกเขา เพราะไม่ใช่แค่ผู้ถือบัตรเครดิตเท่านั้น ลูกค้าของพวกเขาคือหน่วยงานกำกับดูแล นักวิเคราะห์ธุรกิจ พนักงานภายในที่ใช้ระบบ ฯลฯ
"เราใช้การออกแบบที่เน้นมนุษย์เป็นศูนย์กลางอย่างเข้มข้น (human-centered design) เพื่อให้แน่ใจว่าเรากำลังตอบสนองความต้องการ [ของลูกค้า] จริง ๆ และไม่ใช่แค่ทำซ้ำสิ่งที่มีอยู่ในระบบเก่า" Biswanath Bosu ผู้อำนวยการอาวุโสฝ่ายธุรกิจ (Senior Business Director) ด้าน Anti-Money Laundering-Machine Learning and Fraud ที่ Capital One กล่าว 21
จากนั้นพวกเขาจัดลำดับกลุ่มเหล่านี้ตามลำดับที่จะ deploy แต่ละกลุ่มเป็นส่วนบาง ๆ (thin slice) ที่พวกเขาสามารถทดลอง ดูว่าสิ่งใดใช้ได้และสิ่งใดใช้ไม่ได้ แล้วจึงทำซ้ำจากจุดนั้น
"แม้ว่าเราจะมองหา MVP [minimum viable product] แต่เราไม่ได้มองหาตัวส่วนร่วมที่น้อยที่สุด (least common denominator) เรากำลังมองหาประสบการณ์ขั้นต่ำที่ใช้งานได้ (minimum viable experience) ที่เราสามารถมอบให้กับลูกค้าของเรา ไม่ใช่แค่ผลิตภัณฑ์เล็ก ๆ ที่เราสามารถคิดขึ้นมาได้ เมื่อเราทดสอบส่วนนั้นแล้วและมันใช้งานได้ สิ่งต่อไปที่เราจะทำคือขยายขนาดมันขึ้น" Bosu อธิบาย 22
ในฐานะส่วนหนึ่งของการเปลี่ยนแปลงแพลตฟอร์ม มันชัดเจนว่าพวกเขาจะต้องย้ายไปยังระบบคลาวด์ พวกเขายังต้องลงทุนและพัฒนาเครื่องมือในชุดเครื่องมือของตน รวมถึงลงทุนในการพัฒนาทักษะใหม่ (reskilling) ให้กับวิศวกรของตน เพื่อให้พวกเขามีเครื่องมือที่เหมาะสมในการทำงานแบบคล่องตัว (agile) ในระหว่างการเปลี่ยนแปลงนี้
พวกเขาตัดสินใจสร้างระบบสถาปัตยกรรมแบบ microservices ที่ขับเคลื่อนด้วย API เป้าหมายคือการรักษาและสร้างมันแบบเพิ่มทีละน้อย ค่อย ๆ ขยายไปสู่กลยุทธ์ทางธุรกิจต่าง ๆ
"คุณสามารถคิดถึงสิ่งนี้เหมือนกับการมีกองรถยนต์อัจฉริยะที่สร้างขึ้นสำหรับ workloads เฉพาะ แทนที่จะมีรถยนต์แห่งอนาคตคันเดียว" Goyal อธิบาย 23
พวกเขาเริ่มต้นด้วยการใช้ประโยชน์จากเครื่องมือระดับองค์กรที่ผ่านการพิสูจน์แล้ว โดยการสร้างมาตรฐาน พวกเขาสามารถตอบสนองต่อสถานการณ์ที่วิศวกรจำเป็นต้องมีส่วนร่วมกับทีมอื่นหรือย้ายจากทีมหนึ่งไปยังอีกทีมหนึ่งได้รวดเร็วยิ่งขึ้น
การสร้าง CI/CD pipeline ทำให้สามารถปล่อยแบบ incremental และเพิ่มอำนาจให้ทีมงานโดยการลด cycle time และความเสี่ยง ในฐานะสถาบันการเงิน พวกเขายังต้องจัดการกับข้อกำหนดด้านกฎระเบียบและการควบคุม (regulatory and compliance controls) การใช้ pipeline ทำให้พวกเขาสามารถบล็อกการปล่อยเมื่อไม่เป็นไปตามมาตรการควบคุมบางอย่าง
pipeline ยังช่วยให้ทีมสามารถมุ่งเน้นไปที่ฟีเจอร์ของผลิตภัณฑ์ เนื่องจาก pipeline เป็นเครื่องมือที่ใช้ประโยชน์ได้มากกว่าที่จะเป็นการลงทุนที่จำเป็นจากแต่ละทีม ในช่วงที่ความพยายามสูงสุด พวกเขามีทีมงานยี่สิบห้าทีมที่ทำงานและมีส่วนร่วมพร้อมกัน
การมุ่งเน้นความต้องการของลูกค้าและการสร้าง CI/CD pipeline ช่วยให้ Capital One ไม่เพียงแต่ตอบสนองความต้องการทางธุรกิจเท่านั้น แต่ยังดำเนินการได้รวดเร็วยิ่งขึ้นอีกด้วย
รับรองเอกสารและหลักฐานสำหรับผู้ตรวจสอบ (Auditors) และเจ้าหน้าที่ Compliance
ในขณะที่องค์กรเทคโนโลยีนำรูปแบบ DevOps มาใช้มากขึ้น ความตึงเครียดระหว่าง IT และ Audit ก็เพิ่มมากขึ้นกว่าที่เคย รูปแบบ DevOps ใหม่เหล่านี้ท้าทายความคิดแบบดั้งเดิมเกี่ยวกับการตรวจสอบ การควบคุม และการลดความเสี่ยง
ดังที่ Bill Shinn สถาปนิกโซลูชันความปลอดภัยหลัก (principal security solutions architect) ที่ Amazon Web Services กล่าวว่า
DevOps คือการเชื่อมช่องว่างระหว่าง Dev และ Ops ในบางแง่มุม ความท้าทายในการเชื่อมช่องว่างระหว่าง DevOps และผู้ตรวจสอบ (auditors) และเจ้าหน้าที่ compliance นั้นยิ่งใหญ่กว่าด้วยซ้ำ ตัวอย่างเช่น มีผู้ตรวจสอบกี่คนที่สามารถอ่านโค้ดได้ และมีนักพัฒนากี่คนที่เคยอ่าน NIST 800-37 หรือ Gramm-Leach-Bliley Act? สิ่งนี้สร้างช่องว่างของความรู้ และชุมชน DevOps จำเป็นต้องช่วยเชื่อมช่องว่างนั้น 24
CASE STUDY
การพิสูจน์การปฏิบัติตามข้อกำหนดในสภาพแวดล้อมที่มีกฎระเบียบ (2015)
การช่วยให้ลูกค้าองค์กรขนาดใหญ่แสดงให้เห็นว่าพวกเขายังคงปฏิบัติตามกฎหมายและข้อบังคับที่เกี่ยวข้องทั้งหมดได้นั้นเป็นหนึ่งในความรับผิดชอบของ Bill Shinn ในฐานะสถาปนิกโซลูชันความปลอดภัยหลักที่ Amazon Web Services ตลอดหลายปีที่ผ่านมา เขาใช้เวลากับลูกค้าองค์กรมากกว่าหนึ่งพันราย รวมถึง Hearst Media, GE, Phillips, และ Pacific Life ซึ่งได้เปิดเผยต่อสาธารณะถึงการใช้ระบบคลาวด์สาธารณะในสภาพแวดล้อมที่มีการกำกับดูแลสูง
Shinn กล่าวว่า "ปัญหาหนึ่งคือผู้ตรวจสอบได้รับการฝึกฝนด้วยวิธีการที่ไม่เหมาะกับรูปแบบการทำงานของ DevOps ตัวอย่างเช่น หากผู้ตรวจสอบเห็นสภาพแวดล้อมที่มีเซิร์ฟเวอร์การผลิตหนึ่งหมื่นเครื่อง พวกเขาได้รับการฝึกฝนตามปกติให้ขอตัวอย่างเซิร์ฟเวอร์หนึ่งพันเครื่อง พร้อมด้วยหลักฐานภาพหน้าจอของการจัดการสินทรัพย์ การตั้งค่าการควบคุมการเข้าถึง การติดตั้ง agent บันทึกของเซิร์ฟเวอร์ และอื่น ๆ" 25
"นั่นใช้ได้ดีกับสภาพแวดล้อมทางกายภาพ" Shinn กล่าวต่อ "แต่เมื่อโครงสร้างพื้นฐานคือโค้ด (infrastructure is code) และเมื่อ auto-scaling ทำให้เซิร์ฟเวอร์ปรากฏและหายไปตลอดเวลา คุณจะสุ่มตัวอย่างอย่างไร? คุณเจอปัญหาเดียวกันเมื่อมี deployment pipeline ซึ่งแตกต่างจากกระบวนการพัฒนาซอฟต์แวร์แบบดั้งเดิมอย่างมาก ที่ฝ่ายหนึ่งเขียนโค้ดและอีกฝ่ายนำโค้ดนั้นไป deploy ในระบบผลิต" 26
เขาอธิบายว่า "ในงานตรวจสอบภาคสนาม (audit fieldwork) วิธีการรวบรวมหลักฐานที่พบบ่อยที่สุดยังคงเป็นภาพหน้าจอและไฟล์ CSV ที่เต็มไปด้วยการตั้งค่า Configuration และ logs เป้าหมายของเราคือการสร้างวิธีการนำเสนอข้อมูลทางเลือกที่แสดงให้ผู้ตรวจสอบเห็นอย่างชัดเจนว่ามาตรการควบคุมของเราทำงานและมีประสิทธิภาพ" 27
เพื่อช่วยเชื่อมช่องว่างนั้น เขาให้ทีมทำงานร่วมกับผู้ตรวจสอบในกระบวนการออกแบบการควบคุม (control design process) พวกเขาใช้แนวทางแบบ iterative โดยกำหนดการควบคุมเพียงรายการเดียวต่อ sprint เพื่อพิจารณาว่าต้องการหลักฐานการตรวจสอบอะไรบ้าง ซึ่งช่วยให้มั่นใจว่าผู้ตรวจสอบจะได้รับข้อมูลที่ต้องการเมื่อบริการอยู่ในระบบผลิต ตามความต้องการทั้งหมด (on demand)
Shinn กล่าวว่าวิธีที่ดีที่สุดในการบรรลุเป้าหมายนี้คือ "ส่งข้อมูลทั้งหมดไปยังระบบ telemetry ของเรา เช่น Splunk หรือ Kibana วิธีนี้ผู้ตรวจสอบสามารถได้รับสิ่งที่ต้องการได้ด้วยตนเองโดยสมบูรณ์ (self-serviced) พวกเขาไม่ต้องขอตัวอย่างข้อมูล—แต่พวกเขาล็อกอินเข้าไปใน Kibana และค้นหาหลักฐานการตรวจสอบที่ต้องการสำหรับช่วงเวลาที่กำหนด ตามอุดมคติแล้ว พวกเขาจะเห็นอย่างรวดเร็วว่ามีหลักฐานสนับสนุนว่ามาตรการควบคุมของเรากำลังทำงานอยู่" 28
Shinn กล่าวต่อ "ด้วย audit logging, chat rooms, และ deployment pipelines ที่ทันสมัย ทำให้มีการมองเห็นและความโปร่งใสที่ไม่เคยมีมาก่อนเกี่ยวกับสิ่งที่เกิดขึ้นในระบบผลิต โดยเฉพาะอย่างยิ่งเมื่อเปรียบเทียบกับวิธีการดำเนินงาน (Operations) ในอดีต ซึ่งมีความน่าจะเป็นของข้อผิดพลาดและช่องโหว่ด้านความปลอดภัยที่ต่ำกว่ามาก ดังนั้น ความท้าทายคือการเปลี่ยนหลักฐานทั้งหมดนั้นให้เป็นสิ่งที่ผู้ตรวจสอบรู้จัก" 29
ซึ่งจำเป็นต้องดึงข้อกำหนดทางวิศวกรรมจากกฎระเบียบที่เกิดขึ้นจริง Shinn อธิบายว่า
เพื่อค้นหาว่า HIPAA ต้องการอะไรจากมุมมองของความปลอดภัยของข้อมูล คุณต้องดูที่กฎหมาย 45 CFR Part 160 แล้วเข้าไปที่ Subparts A และ C ของ Part 164 ถึงอย่างนั้น คุณต้องอ่านต่อไปจนกว่าจะถึง 'มาตรการป้องกันทางเทคนิคและการควบคุมการตรวจสอบ (technical safeguards and audit controls)' เพียงเท่านั้นคุณถึงจะเห็นว่าสิ่งที่ต้องการคือเราต้องกำหนดกิจกรรมที่จะถูกติดตามและตรวจสอบที่เกี่ยวข้องกับข้อมูลสุขภาพของผู้ป่วย (Patient Healthcare Information) จัดทำเอกสารและimplement มาตรการควบคุมเหล่านั้น เลือกเครื่องมือ และสุดท้ายทบทวนและบันทึกข้อมูลที่เหมาะสม 30
Shinn กล่าวต่อ "วิธีการปฏิบัติตามข้อกำหนดนั้นคือการสนทนาที่ต้องเกิดขึ้นระหว่างเจ้าหน้าที่ compliance และ regulatory กับทีม security และ DevOps โดยเฉพาะอย่างยิ่งเกี่ยวกับวิธีการป้องกัน ตรวจจับ และแก้ไขปัญหา บางครั้งสามารถปฏิบัติตามได้ด้วยการตั้งค่าใน version control ในบางครั้งก็เป็นการควบคุมผ่านการตรวจสอบ (monitoring control)" 31
Shinn ยกตัวอย่าง "เราอาจเลือกที่จะ implement หนึ่งในการควบคุมเหล่านั้นโดยใช้ AWS CloudWatch และเราสามารถทดสอบว่าการควบคุมทำงานได้ด้วยคำสั่งเดียวใน command line ยิ่งไปกว่านั้น เราต้องแสดงให้เห็นว่า logs ไปที่ไหน—ในอุดมคติ เราจะส่งทั้งหมดนี้เข้าไปใน logging framework ของเรา ซึ่งเราสามารถเชื่อมโยงหลักฐานการตรวจสอบกับข้อกำหนดการควบคุมที่เกิดขึ้นจริง" 32
เพื่อช่วยแก้ปัญหานี้ DevOps Audit Defense Toolkit ได้อธิบายเรื่องราวแบบ end-to-end ของกระบวนการ compliance และการตรวจสอบสำหรับองค์กรสมมติ (Parts Unlimited จาก The Phoenix Project ) โดยเริ่มต้นด้วยการอธิบายเป้าหมายขององค์กร กระบวนการทางธุรกิจ ความเสี่ยงสูงสุด และสภาพแวดล้อมการควบคุมที่เกิดขึ้น รวมถึงวิธีที่ฝ่ายจัดการสามารถพิสูจน์ได้สำเร็จว่ามาตรการควบคุมมีอยู่และมีประสิทธิภาพ นอกจากนี้ยังมีการนำเสนอข้อโต้แย้งในการตรวจสอบ (audit objections) และวิธีเอาชนะสิ่งเหล่านั้น 33
ชุดเครื่องมือ (toolkit) อธิบายว่ามาตรการควบคุมสามารถถูกออกแบบใน deployment pipeline เพื่อลดความเสี่ยงที่ระบุไว้ได้อย่างไร และให้ตัวอย่างของคำรับรองการควบคุม (control attestations) และ artifacts การควบคุมเพื่อแสดงประสิทธิภาพของการควบคุม โดยตั้งใจให้เป็นแนวทางทั่วไปสำหรับวัตถุประสงค์การควบคุมทั้งหมด รวมถึงการสนับสนุนการรายงานทางการเงินที่ถูกต้อง การปฏิบัติตามกฎระเบียบ (เช่น SEC SOX-404, HIPAA, FedRAMP, EU Model Contracts และข้อบังคับ SEC Reg-SCI ที่เสนอ) ภาระผูกพันตามสัญญา (เช่น PCI DSS, DOD DISA) และการดำเนินงานที่มีประสิทธิภาพและประสิทธิผล
กรณีศึกษานี้แสดงให้เห็นว่าการสร้างเอกสารช่วยเชื่อมช่องว่างระหว่างแนวปฏิบัติ Dev และ Ops กับข้อกำหนดของผู้ตรวจสอบได้อย่างไร โดยแสดงให้เห็นว่า DevOps สามารถปฏิบัติตามข้อกำหนดและปรับปรุงการประเมินความเสี่ยงและการลดความเสี่ยงได้
CASE STUDY
การพึ่งพา Production Telemetry สำหรับระบบ ATM (2013)
Mary Smith (นามแฝง) เป็นหัวหน้าโครงการ DevOps สำหรับธุรกิจธนาคารผู้บริโภคขององค์กรบริการทางการเงินขนาดใหญ่แห่งหนึ่งในสหรัฐฯ เธอตั้งข้อสังเกตว่าฝ่ายความปลอดภัยของข้อมูล (Information Security) ผู้ตรวจสอบ และหน่วยงานกำกับดูแลมักให้ความสำคัญกับการตรวจสอบโค้ด (code reviews) มากเกินไปในการตรวจจับการทุจริต แต่พวกเขาควรพึ่งพามาตรการควบคุมการตรวจสอบการผลิต (production monitoring controls) นอกเหนือจากการใช้การทดสอบอัตโนมัติ การตรวจสอบโค้ด และการอนุมัติ เพื่อลดความเสี่ยงที่เกี่ยวข้องกับข้อผิดพลาดและการทุจริตอย่างมีประสิทธิภาพ 34
เธอกล่าวว่า:
หลายปีก่อน เรามีนักพัฒนาที่แอบแทรก backdoor ในโค้ดที่เรา deploy ไปยังเครื่อง ATM ของเรา พวกเขาสามารถทำให้ ATM เข้าสู่โหมดบำรุงรักษาในช่วงเวลาหนึ่ง ทำให้พวกเขาสามารถนำเงินออกจากเครื่องได้ เราสามารถตรวจจับการทุจริตได้อย่างรวดเร็ว และไม่ใช่ผ่านการตรวจสอบโค้ด backdoor ประเภทนี้ตรวจจับได้ยากหรือแทบจะเป็นไปไม่ได้เลยเมื่อผู้กระทำความผิดมีวิธีการ แรงจูงใจจ และโอกาสที่เพียงพอ
อย่างไรก็ตาม เราตรวจพบการทุจริตได้อย่างรวดเร็วในระหว่างการประชุมทบทวนการดำเนินงานตามปกติ เมื่อมีคนสังเกตเห็นว่า ATM ในเมืองหนึ่งถูกทำให้เข้าสู่โหมดบำรุงรักษาในเวลาที่ไม่ได้กำหนดไว้ เราพบการทุจริตก่อนที่กระบวนการตรวจสอบเงินสดตามกำหนด ซึ่งเป็นการกระทบยอดจำนวนเงินใน ATM กับธุรกรรมที่ได้รับอนุญาต 35
ในกรณีศึกษานี้ การทุจริตเกิดขึ้นแม้จะมีการแบ่งแยกหน้าที่ระหว่าง Development และ Operations และมีกระบวนการอนุมัติการเปลี่ยนแปลง แต่ก็ถูกตรวจจับและแก้ไขได้อย่างรวดเร็วผ่าน production telemetry ที่มีประสิทธิภาพ
ดังที่กรณีศึกษานี้แสดงให้เห็น การพึ่งพาการตรวจสอบโค้ดและการแบ่งแยกหน้าที่ระหว่าง Dev และ Ops มากเกินไปของผู้ตรวจสอบสามารถสร้างช่องโหว่ได้ Telemetry ช่วยให้มองเห็นสิ่งที่จำเป็นในการตรวจจับและดำเนินการกับข้อผิดพลาดและการทุจริต ช่วยลดความจำเป็นที่รับรู้ในการแยกหน้าที่หรือสร้างคณะกรรมการตรวจสอบการเปลี่ยนแปลงเพิ่มเติม
บทสรุป (Conclusion)
ตลอดทั้งบทนี้ เราได้พูดถึงแนวปฏิบัติที่ทำให้ความปลอดภัยของข้อมูลเป็นหน้าที่ของทุกคน โดยที่วัตถุประสงค์ด้านความปลอดภัยของข้อมูลทั้งหมดของเราถูกบูรณาการเข้ากับงานประจำวันของทุกคนใน value stream การทำเช่นนี้ช่วยให้เราปรับปรุงประสิทธิผลของมาตรการควบคุมของเราได้อย่างมีนัยสำคัญ เพื่อให้เราสามารถป้องกันการละเมิดความปลอดภัยได้ดีขึ้น รวมถึงตรวจจับและกู้คืนจากการละเมิดได้รวดเร็วยิ่งขึ้น และเรายังลดงานที่เกี่ยวข้องกับการเตรียมและผ่านการตรวจสอบ compliance ได้อย่างมีนัยสำคัญ
ITIL กำหนด utility ว่า "สิ่งที่บริการทำ" ในขณะที่ warranty ถูกกำหนดว่า "วิธีการที่บริการถูกส่งมอบและสามารถใช้เพื่อพิจารณาว่าบริการ 'เหมาะสมต่อการใช้งาน (fit for use)' หรือไม่" 1 | |
เพื่อจัดการความเสี่ยงของการเปลี่ยนแปลงเพิ่มเติม เราอาจมีกฎที่กำหนดไว้ เช่น การเปลี่ยนแปลงบางอย่างสามารถดำเนินการได้โดยกลุ่มหรือบุคคลใดบุคคลหนึ่งเท่านั้น (เช่น เฉพาะ DBA เท่านั้นที่สามารถ deploy การเปลี่ยนแปลง schema ของฐานข้อมูลได้) โดยทั่วไปแล้ว การประชุม CAB จะจัดขึ้นทุกสัปดาห์ โดยที่คำขอเปลี่ยนแปลงจะได้รับการอนุมัติและจัดตารางเวลา ตั้งแต่ ITIL เวอร์ชัน 3 เป็นต้นไป การเปลี่ยนแปลงสามารถได้รับการอนุมัติทางอิเล็กทรอนิกส์แบบ just-in-time ผ่านเครื่องมือจัดการการเปลี่ยนแปลงได้ นอกจากนี้ยังแนะนำโดยเฉพาะว่า "ควรระบุ standard changes ตั้งแต่เนิ่น ๆ เมื่อสร้างกระบวนการ Change Management เพื่อส่งเสริมประสิทธิภาพ มิฉะนั้น การนำ Change Management ไปปฏิบัติอาจสร้างระดับการบริหารจัดการและการต่อต้านกระบวนการ Change Management ที่สูงโดยไม่จำเป็น" 2 | |
คำว่า ticket ถูกใช้โดยทั่วไปเพื่อระบุรายการงานที่สามารถระบุตัวตนได้ไม่ซ้ำกัน | |
ผู้เขียนขอขอบคุณ Bill Massie และ John Allspaw ที่ใช้เวลาทั้งวันกับ Gene Kim เพื่อแบ่งปันประสบการณ์ด้าน compliance ของพวกเขา |