ธนาคารมอบหมายโครงการให้ผู้รับเหมาหลายราย เขียนโค้ด "ภายนอก" จากนั้นส่งผลในรูปแบบที่ไม่สะดวกมาก โดยเฉพาะอย่างยิ่ง กระบวนการมีลักษณะดังนี้: พวกเขาส่งมอบโปรเจ็กต์ที่ผ่านการทดสอบการทำงานให้กับพวกเขา และจากนั้นก็ได้รับการทดสอบภายในขอบเขตของธนาคารสำหรับการบูรณาการ โหลด และอื่นๆ มักพบว่าการทดสอบล้มเหลว จากนั้นทุกอย่างก็กลับไปที่นักพัฒนาภายนอก ดังที่คุณเดาได้ นี่หมายถึงระยะเวลารอคอยที่ยาวนานในการแก้ไขข้อบกพร่อง
ธนาคารตัดสินใจว่าเป็นไปได้และจำเป็นต้องลากไปป์ไลน์ทั้งหมดไว้ใต้ปีกของมันตั้งแต่ข้อผูกพันไปจนถึงการปล่อย เพื่อให้ทุกอย่างมีความสม่ำเสมอและอยู่ภายใต้การควบคุมของทีมงานที่รับผิดชอบผลิตภัณฑ์ในธนาคาร นั่นคือราวกับว่าผู้รับเหมาภายนอกกำลังทำงานอยู่ที่ไหนสักแห่งในห้องถัดไปของสำนักงาน บนกองขององค์กร นี่คือดีโวปธรรมดา
ส.ค. มาจากไหน? การรักษาความปลอดภัยของธนาคารมีความต้องการอย่างมากว่าผู้รับเหมาภายนอกสามารถทำงานในส่วนเครือข่ายได้อย่างไร บุคคลที่มีสิทธิ์เข้าถึงอะไร อย่างไรและใครทำงานกับรหัส เพียงแต่ว่า IB ยังไม่รู้ว่าเมื่อผู้รับเหมาทำงานภายนอก มีการปฏิบัติตามมาตรฐานการธนาคารเพียงเล็กน้อย และในอีกสองสามวัน ทุกคนจะต้องเริ่มสังเกตพวกมัน
การเปิดเผยง่ายๆ ที่ผู้รับเหมาสามารถเข้าถึงรหัสผลิตภัณฑ์ได้อย่างเต็มที่ได้ทำให้โลกของพวกเขาพลิกคว่ำไปแล้ว
ในขณะนี้ เรื่องราวของ DevSecOps ได้เริ่มต้นขึ้น ซึ่งฉันอยากจะเล่าให้คุณฟัง
ธนาคารได้ข้อสรุปเชิงปฏิบัติอะไรบ้างจากสถานการณ์นี้
มีการถกเถียงกันมากมายเกี่ยวกับความจริงที่ว่าทุกสิ่งทุกอย่างดำเนินไปในทางที่ผิด นักพัฒนากล่าวว่าการรักษาความปลอดภัยนั้นยุ่งอยู่กับการพยายามแทรกแซงการพัฒนาเท่านั้น และพวกเขาก็เหมือนกับยามที่พยายามห้ามโดยไม่ต้องคิด ในทางกลับกัน ผู้เชี่ยวชาญด้านความปลอดภัยลังเลที่จะเลือกระหว่างมุมมอง: “นักพัฒนาสร้างช่องโหว่ในวงจรของเรา” และ “นักพัฒนาไม่ได้สร้างช่องโหว่ แต่เป็นพวกเขาเอง” ข้อพิพาทจะดำเนินต่อไปเป็นเวลานานหากไม่ใช่เพื่อความต้องการของตลาดใหม่และการเกิดขึ้นของกระบวนทัศน์ DevSecOps เป็นไปได้ที่จะอธิบายได้ว่ากระบวนการอัตโนมัติโดยคำนึงถึงข้อกำหนดด้านความปลอดภัยของข้อมูล "นอกกรอบ" จะช่วยให้ทุกคนยังคงมีความสุข ในแง่ที่ว่ากฎจะถูกเขียนลงทันทีและไม่เปลี่ยนแปลงในระหว่างเกม (ความปลอดภัยของข้อมูลจะไม่ห้ามสิ่งที่ไม่คาดคิด) และผู้พัฒนาจะคอยแจ้งให้ความปลอดภัยของข้อมูลทราบทุกสิ่งที่เกิดขึ้น (ความปลอดภัยของข้อมูลไม่พบสิ่งที่กะทันหัน) . แต่ละทีมยังต้องรับผิดชอบต่อความปลอดภัยขั้นสูงสุด ไม่ใช่พี่ชายที่เป็นนามธรรมบางคน
- เนื่องจากพนักงานภายนอกสามารถเข้าถึงรหัสและระบบภายในจำนวนหนึ่งได้แล้ว จึงอาจเป็นไปได้ที่จะลบข้อกำหนด "การพัฒนาจะต้องดำเนินการทั้งหมดบนโครงสร้างพื้นฐานของธนาคาร" ออกจากเอกสาร
- ในทางกลับกัน เราจำเป็นต้องเสริมสร้างการควบคุมสิ่งที่เกิดขึ้น
- การประนีประนอมคือการสร้างทีมงานข้ามสายงานซึ่งพนักงานทำงานอย่างใกล้ชิดกับบุคคลภายนอก ในกรณีนี้ คุณต้องแน่ใจว่าทีมงานใช้งานเครื่องมือบนเซิร์ฟเวอร์ของธนาคาร ตั้งแต่ต้นจนจบ
นั่นคือสามารถอนุญาตให้ผู้รับเหมาเข้ามาได้ แต่ต้องแยกส่วนออกจากกัน เพื่อไม่ให้มีการติดเชื้อจากภายนอกเข้าสู่โครงสร้างพื้นฐานของธนาคาร และเพื่อไม่ให้เห็นเกินความจำเป็น เพื่อบันทึกการกระทำของพวกเขา DLP สำหรับการป้องกันการรั่วไหล ทั้งหมดนี้รวมอยู่ด้วย
โดยหลักการแล้ว ทุกธนาคารจะต้องมาถึงจุดนี้ไม่ช้าก็เร็ว ที่นี่เราเดินไปตามเส้นทางที่ไม่มีใครเคยรู้จักและตกลงเกี่ยวกับข้อกำหนดสำหรับสภาพแวดล้อมที่ "บุคคลภายนอก" ทำงาน มีเครื่องมือควบคุมการเข้าถึง เครื่องมือตรวจสอบช่องโหว่ การวิเคราะห์การป้องกันไวรัสในวงจร ชุดประกอบ และการทดสอบที่หลากหลาย สิ่งนี้เรียกว่า DevSecOps
ทันใดนั้นก็เห็นได้ชัดว่าหากก่อนหน้านี้ความปลอดภัยทางธนาคารของ DevSecOps ไม่สามารถควบคุมสิ่งที่เกิดขึ้นในฝั่งนักพัฒนาได้ ดังนั้นในกระบวนทัศน์ใหม่ การรักษาความปลอดภัยก็จะถูกควบคุมในลักษณะเดียวกับเหตุการณ์ปกติบนโครงสร้างพื้นฐาน เฉพาะตอนนี้เท่านั้นที่มีการแจ้งเตือนเกี่ยวกับแอสเซมบลี การควบคุมไลบรารี และอื่นๆ
สิ่งที่เหลืออยู่คือการย้ายทีมไปสู่รูปแบบใหม่ สร้างโครงสร้างพื้นฐาน แต่สิ่งเหล่านี้เป็นเรื่องเล็ก ๆ น้อย ๆ มันเหมือนกับการวาดรูปนกฮูก จริงๆ แล้ว เราได้ช่วยเหลือในเรื่องโครงสร้างพื้นฐาน และในขณะนั้นกระบวนการพัฒนาก็เปลี่ยนแปลงไป
มีอะไรเปลี่ยนแปลงบ้าง
เราตัดสินใจดำเนินการในขั้นตอนเล็กๆ เพราะเราเข้าใจว่ากระบวนการต่างๆ มากมายจะพังทลาย และ “บุคคลภายนอก” จำนวนมากอาจไม่สามารถทนต่อสภาพการทำงานใหม่ภายใต้การดูแลของทุกคนได้
อันดับแรก เราสร้างทีมข้ามสายงานและเรียนรู้ที่จะจัดระเบียบโครงการโดยคำนึงถึงข้อกำหนดใหม่ ในความหมายขององค์กร เราได้หารือกันว่ากระบวนการใด ผลลัพธ์ที่ได้คือไดอะแกรมของไปป์ไลน์การประกอบโดยผู้ที่รับผิดชอบทั้งหมด
- ซีไอ: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase
- การทดสอบ: Sonarqube, SoapUI, jMeter, ซีลีเนียม: MF Fortify, ศูนย์ประสิทธิภาพ, MF UFT, Ataccama
- การเสนอ (การรายงาน การสื่อสาร): Grafana, Kibana, Jira, Confluence, RocketChat
- การดำเนินการ (การบำรุงรักษา การจัดการ): Ansible, Zabbix, Prometheus, Elastic + Logstash, ผู้จัดการบริการ MF, Jira, Confluence, MS Project
สแต็กที่เลือก:
- ฐานความรู้ - การบรรจบกันของ Atlassian;
- ตัวติดตามงาน - Atlassian Jira;
- ที่เก็บสิ่งประดิษฐ์ - "Nexus";
- ระบบบูรณาการอย่างต่อเนื่อง - “Gitlab CI”;
- ระบบวิเคราะห์ต่อเนื่อง - “SonarQube”;
- ระบบวิเคราะห์ความปลอดภัยของแอปพลิเคชัน - “Micro Focus Fortify”;
- ระบบการสื่อสาร - “GitLab สำคัญที่สุด”;
- ระบบการจัดการการกำหนดค่า - "Ansible";
- ระบบตรวจสอบ - "ELK", "TICK Stack" (“InfluxData”)
พวกเขาเริ่มสร้างทีมที่พร้อมจะดึงผู้รับเหมาเข้าไปข้างใน มีความตระหนักว่ามีสิ่งสำคัญหลายประการ:
- ทุกอย่างควรรวมเป็นหนึ่งเดียว อย่างน้อยก็ตอนส่งโค้ด เนื่องจากมีผู้รับเหมาจำนวนมากพอๆ กับที่มีกระบวนการพัฒนาที่แตกต่างกันมากมายที่มีลักษณะเฉพาะของตนเอง จำเป็นต้องปรับทุกคนให้เป็นหนึ่งเดียว แต่มีตัวเลือกต่างๆ
- มีผู้รับเหมาจำนวนมาก และการสร้างโครงสร้างพื้นฐานด้วยตนเองไม่เหมาะสม งานใหม่ควรเริ่มต้นอย่างรวดเร็ว กล่าวคือ อินสแตนซ์ควรถูกปรับใช้เกือบจะในทันที เพื่อให้นักพัฒนามีชุดโซลูชันในการจัดการไปป์ไลน์ของตน
เพื่อก้าวแรก จำเป็นต้องเข้าใจว่ากำลังทำอะไรอยู่ และเราต้องตัดสินใจว่าจะไปที่นั่นได้อย่างไร เราเริ่มต้นด้วยการช่วยวาดสถาปัตยกรรมของโซลูชันเป้าหมายทั้งในโครงสร้างพื้นฐานและระบบอัตโนมัติ CI/CD จากนั้นเราก็เริ่มประกอบสายพานลำเลียงนี้ เราต้องการโครงสร้างพื้นฐานแบบเดียวกันสำหรับทุกคน โดยที่สายพานลำเลียงแบบเดียวกันจะทำงาน ธนาคารคิด เราเสนอทางเลือกพร้อมการคำนวณ จากนั้นจึงตัดสินใจว่าจะสร้างอะไรและใช้เงินทุนเท่าใด
ต่อไปคือการสร้างวงจร - การติดตั้งซอฟต์แวร์การกำหนดค่า การพัฒนาสคริปต์สำหรับการปรับใช้และการจัดการโครงสร้างพื้นฐาน ถัดมาคือการเปลี่ยนไปใช้ระบบรองรับสายพานลำเลียง
เราตัดสินใจทดสอบทุกอย่างกับนักบิน สิ่งที่น่าสนใจคือในระหว่างการนำร่อง มีกองหนึ่งปรากฏขึ้นในธนาคารเป็นครั้งแรก เหนือสิ่งอื่นใด มีการเสนอผู้จำหน่ายในประเทศสำหรับหนึ่งในโซลูชันสำหรับขอบเขตของโครงการนำร่องเพื่อการเปิดตัวที่รวดเร็ว เจ้าหน้าที่รักษาความปลอดภัยได้รู้จักเขาในขณะที่เขาขับเครื่องบิน และมันก็สร้างความประทับใจไม่รู้ลืม เมื่อเราตัดสินใจเปลี่ยน โชคดีที่ชั้นโครงสร้างพื้นฐานถูกแทนที่ด้วยโซลูชันของ Nutanix ซึ่งเคยมีอยู่ในธนาคารมาก่อน ยิ่งไปกว่านั้น ก่อนหน้านั้นมีไว้สำหรับ VDI แต่เรานำมาใช้ซ้ำสำหรับบริการโครงสร้างพื้นฐาน ในปริมาณน้อยมันไม่เหมาะกับเศรษฐกิจ แต่ในปริมาณมากก็กลายเป็นสภาพแวดล้อมที่ยอดเยี่ยมสำหรับการพัฒนาและการทดสอบ
ส่วนที่เหลือของสแต็กนั้นทุกคนคุ้นเคยไม่มากก็น้อย มีการใช้เครื่องมืออัตโนมัติใน Ansible และผู้เชี่ยวชาญด้านความปลอดภัยก็ทำงานอย่างใกล้ชิดกับพวกเขา ธนาคารใช้สแต็ค Atlassin ก่อนเริ่มโครงการ เครื่องมือรักษาความปลอดภัยของ Fortinet - เสนอโดยเจ้าหน้าที่รักษาความปลอดภัยเอง กรอบการทดสอบถูกสร้างขึ้นโดยธนาคาร ไม่มีการถามคำถาม ระบบพื้นที่เก็บข้อมูลทำให้เกิดคำถาม ฉันต้องทำความคุ้นเคย
ผู้รับเหมาได้รับกองใหม่ พวกเขาให้เวลาเราในการเขียนใหม่สำหรับ GitlabCI และย้าย Jira ไปยังส่วนการธนาคาร และอื่นๆ
เป็นขั้นเป็นตอน
ขั้นตอนที่ 1 ขั้นแรก เราใช้โซลูชันจากผู้ขายในประเทศ ผลิตภัณฑ์เชื่อมต่อกับส่วนเครือข่าย DSO ที่สร้างขึ้นใหม่ แพลตฟอร์มดังกล่าวได้รับเลือกเนื่องจากเวลาในการจัดส่ง ความยืดหยุ่นในการปรับขนาด และความเป็นไปได้ของระบบอัตโนมัติเต็มรูปแบบ ดำเนินการทดสอบ:
- ความเป็นไปได้ของการจัดการโครงสร้างพื้นฐานแพลตฟอร์มการจำลองเสมือนที่ยืดหยุ่นและเป็นอัตโนมัติเต็มรูปแบบ (เครือข่าย ระบบย่อยของดิสก์ ระบบย่อยทรัพยากรคอมพิวเตอร์)
- ระบบอัตโนมัติของการจัดการวงจรชีวิตของเครื่องเสมือน (การสร้างเทมเพลต สแน็ปช็อต การสำรองข้อมูล)
หลังจากการติดตั้งและการกำหนดค่าพื้นฐานของแพลตฟอร์ม จะใช้เป็นจุดในการวางตำแหน่งระบบย่อยขั้นที่สอง (เครื่องมือ DSO, โครงร่างการพัฒนาระบบการค้าปลีก) ชุดไปป์ไลน์ที่จำเป็นถูกสร้างขึ้น - การสร้าง, การลบ, การแก้ไข, การสำรองข้อมูลของเครื่องเสมือน ไปป์ไลน์เหล่านี้ถูกใช้เป็นขั้นตอนแรกของกระบวนการปรับใช้
ผลลัพธ์ก็คืออุปกรณ์ที่ให้มาไม่ตรงตามข้อกำหนดของธนาคารในด้านประสิทธิภาพและความทนทานต่อข้อผิดพลาด DIT ของธนาคารตัดสินใจสร้างคอมเพล็กซ์โดยใช้แพ็คเกจซอฟต์แวร์ของ Nutanix
ขั้นตอนที่ 2. เรานำสแต็กที่กำหนดไว้ และเขียนการติดตั้งอัตโนมัติและสคริปต์หลังการกำหนดค่าสำหรับระบบย่อยทั้งหมด เพื่อให้ทุกอย่างถูกถ่ายโอนจากโปรแกรมนำร่องไปยังวงจรเป้าหมายโดยเร็วที่สุด ระบบทั้งหมดได้รับการปรับใช้ในการกำหนดค่าที่ทนทานต่อข้อผิดพลาด (โดยที่ความเป็นไปได้นี้ไม่ถูกจำกัดโดยนโยบายการออกใบอนุญาตของผู้จำหน่าย) และเชื่อมต่อกับหน่วยวัดและระบบย่อยการรวบรวมเหตุการณ์ IB วิเคราะห์การปฏิบัติตามข้อกำหนดและให้ไฟเขียว
ขั้นตอนที่ 3. การย้ายระบบย่อยทั้งหมดและการตั้งค่าไปยัง PAC ใหม่ สคริปต์การทำงานอัตโนมัติของโครงสร้างพื้นฐานถูกเขียนใหม่ และการโยกย้ายระบบย่อย DSO เสร็จสมบูรณ์ในโหมดอัตโนมัติเต็มรูปแบบ โครงร่างของการพัฒนา IP ถูกสร้างขึ้นใหม่โดยขั้นตอนของทีมพัฒนา
ขั้นตอนที่ 4 ระบบอัตโนมัติของการติดตั้งซอฟต์แวร์แอพพลิเคชั่น งานเหล่านี้ถูกกำหนดโดยหัวหน้าทีมของทีมใหม่
ขั้นตอนที่ 5 การเอารัดเอาเปรียบ
การเข้าถึงระยะไกล
ทีมพัฒนาขอความยืดหยุ่นสูงสุดในการทำงานกับวงจร และข้อกำหนดในการเข้าถึงระยะไกลจากแล็ปท็อปส่วนตัวได้รับการยกระดับขึ้นในช่วงเริ่มต้นของโครงการ ธนาคารมีการเข้าถึงระยะไกลอยู่แล้ว แต่ไม่เหมาะสำหรับนักพัฒนา ความจริงก็คือโครงการใช้การเชื่อมต่อของผู้ใช้กับ VDI ที่ได้รับการป้องกัน เหมาะสำหรับผู้ที่ต้องการเพียงไปรษณีย์และแพ็คเกจสำนักงานในที่ทำงาน นักพัฒนาต้องการไคลเอนต์จำนวนมาก ประสิทธิภาพสูง พร้อมทรัพยากรจำนวนมาก และแน่นอนว่าพวกเขาจะต้องคงที่เนื่องจากการสูญเสียเซสชันผู้ใช้สำหรับผู้ที่ทำงานกับ VStudio (ตัวอย่าง) หรือ SDK อื่น ๆ เป็นสิ่งที่ยอมรับไม่ได้ การจัดระเบียบ VDI แบบคงที่จำนวนมากสำหรับทีมพัฒนาทั้งหมดทำให้ต้นทุนของโซลูชัน VDI ที่มีอยู่เพิ่มขึ้นอย่างมาก
เราตัดสินใจที่จะทำงานเกี่ยวกับการเข้าถึงทรัพยากรของกลุ่มการพัฒนาจากระยะไกลโดยตรง Jira, Wiki, Gitlab, Nexus, สร้างและทดสอบบัลลังก์, โครงสร้างพื้นฐานเสมือน เจ้าหน้าที่รักษาความปลอดภัยเรียกร้องให้มีการเข้าถึงได้เฉพาะในกรณีต่อไปนี้:
- โดยใช้เทคโนโลยีที่มีอยู่แล้วในธนาคาร
- โครงสร้างพื้นฐานไม่ควรใช้ตัวควบคุมโดเมนที่มีอยู่ซึ่งจัดเก็บบันทึกของวัตถุบัญชีที่มีประสิทธิผล
- การเข้าถึงควรจำกัดเฉพาะทรัพยากรที่ทีมใดทีมหนึ่งต้องการ (เพื่อให้ทีมผลิตภัณฑ์หนึ่งไม่สามารถเข้าถึงทรัพยากรของทีมอื่นได้)
- การควบคุม RBAC สูงสุดในระบบ
ด้วยเหตุนี้ จึงมีการสร้างโดเมนแยกต่างหากสำหรับส่วนนี้ โดเมนนี้เก็บทรัพยากรส่วนการพัฒนาทั้งหมด ทั้งข้อมูลรับรองผู้ใช้และโครงสร้างพื้นฐาน วงจรชีวิตของบันทึกในโดเมนนี้ได้รับการจัดการโดยใช้ IdM ที่มีอยู่ในธนาคาร
การเข้าถึงระยะไกลโดยตรงได้รับการจัดการตามอุปกรณ์ที่มีอยู่ของธนาคาร การควบคุมการเข้าถึงถูกแบ่งออกเป็นกลุ่ม AD ซึ่งกฎเกณฑ์ในบริบทสอดคล้องกัน (กลุ่มผลิตภัณฑ์หนึ่งกลุ่ม = กลุ่มกฎหนึ่งกลุ่ม)
การจัดการเทมเพลต VM
ความเร็วของการสร้างแอสเซมบลีและลูปการทดสอบเป็นหนึ่งใน KPI หลักที่กำหนดโดยหัวหน้าหน่วยการพัฒนา เนื่องจากความเร็วในการเตรียมสภาพแวดล้อมส่งผลโดยตรงต่อเวลาดำเนินการโดยรวมของไปป์ไลน์ มีการพิจารณาสองตัวเลือกสำหรับการเตรียมอิมเมจ VM พื้นฐาน ประการแรกคือขนาดภาพขั้นต่ำ ค่าเริ่มต้นสำหรับผลิตภัณฑ์ระบบทั้งหมด การปฏิบัติตามนโยบายการตั้งค่าของธนาคารสูงสุด ภาพที่สองคืออิมเมจพื้นฐานที่ติดตั้ง POPPO สำหรับงานหนัก ซึ่งเวลาในการติดตั้งอาจส่งผลอย่างมากต่อความเร็วในการดำเนินการของไปป์ไลน์
ข้อกำหนดด้านโครงสร้างพื้นฐานและความปลอดภัยยังถูกนำมาพิจารณาในระหว่างการพัฒนาด้วย คอยดูแลให้อิมเมจทันสมัยอยู่เสมอ (แพตช์ ฯลฯ) บูรณาการกับ SIEM การตั้งค่าความปลอดภัยตามมาตรฐานธนาคาร
ด้วยเหตุนี้ เราจึงตัดสินใจใช้รูปภาพให้น้อยที่สุดเพื่อลดต้นทุนในการอัปเดตรูปภาพให้ทันสมัย การอัปเดตระบบปฏิบัติการพื้นฐานนั้นง่ายกว่าการแพตช์แต่ละอิมเมจสำหรับ POPPO เวอร์ชันใหม่มาก
จากผลลัพธ์ รายการชุดระบบปฏิบัติการขั้นต่ำที่จำเป็นถูกสร้างขึ้น ซึ่งการอัปเดตดำเนินการโดยทีมงานปฏิบัติการ และสคริปต์จากไปป์ไลน์มีหน้าที่รับผิดชอบในการอัปเดตซอฟต์แวร์ทั้งหมด และหากจำเป็น ให้เปลี่ยนเวอร์ชัน ของซอฟต์แวร์ที่ติดตั้ง - เพียงโอนแท็กที่ต้องการไปยังไปป์ไลน์ ใช่ การดำเนินการนี้กำหนดให้ทีมผลิตภัณฑ์ Devops มีสถานการณ์การปรับใช้ที่ซับซ้อนมากขึ้น แต่จะช่วยลดเวลาดำเนินการที่ต้องใช้ในการรองรับอิมเมจพื้นฐานได้อย่างมาก ซึ่งอาจต้องใช้อิมเมจ VM พื้นฐานมากกว่าหนึ่งร้อยรายการในการบำรุงรักษา
การเข้าถึงอินเทอร์เน็ต
สิ่งที่สะดุดอีกประการหนึ่งเกี่ยวกับการรักษาความปลอดภัยของธนาคารคือการเข้าถึงทรัพยากรอินเทอร์เน็ตจากสภาพแวดล้อมการพัฒนา นอกจากนี้ การเข้าถึงนี้สามารถแบ่งออกเป็นสองประเภท:
- การเข้าถึงโครงสร้างพื้นฐาน
- การเข้าถึงของนักพัฒนา
การเข้าถึงโครงสร้างพื้นฐานได้รับการจัดระเบียบโดยการพร็อกซีที่เก็บข้อมูลภายนอกด้วย Nexus นั่นคือไม่มีการเข้าถึงโดยตรงจากเครื่องเสมือน สิ่งนี้ทำให้สามารถประนีประนอมกับความปลอดภัยของข้อมูลได้ ซึ่งโดยเด็ดขาดแล้วไม่ให้เข้าถึงโลกภายนอกจากส่วนการพัฒนา
นักพัฒนาจำเป็นต้องเข้าถึงอินเทอร์เน็ตด้วยเหตุผลที่ชัดเจน (stackoverflow) และถึงแม้ว่าคำสั่งทั้งหมดดังที่ได้กล่าวมาข้างต้นจะสามารถเข้าถึงวงจรจากระยะไกลได้ แต่ก็ไม่สะดวกเสมอไปเมื่อคุณไม่สามารถกด ctrl+v จากที่ทำงานของนักพัฒนาในธนาคารใน IDE ได้
มีการบรรลุข้อตกลงกับ IS ว่าในขั้นต้นในขั้นตอนการทดสอบ การเข้าถึงจะได้รับผ่านพร็อกซีของธนาคารตามบัญชีขาว เมื่อโครงการเสร็จสิ้น การเข้าถึงจะถูกโอนไปยังบัญชีดำ ตารางการเข้าถึงขนาดใหญ่ได้รับการจัดเตรียมไว้ ซึ่งระบุทรัพยากรหลักและพื้นที่เก็บข้อมูลที่จำเป็นต้องเข้าถึงเมื่อเริ่มต้นโครงการ การประสานการเข้าถึงเหล่านี้ใช้เวลาพอสมควร ซึ่งทำให้สามารถยืนกรานที่จะเปลี่ยนไปสู่บัญชีดำได้เร็วที่สุด
ผลการวิจัย
โครงการสิ้นสุดน้อยกว่าหนึ่งปีที่ผ่านมาเล็กน้อย น่าแปลกที่ผู้รับเหมาทั้งหมดเปลี่ยนไปใช้กลุ่มใหม่ตรงเวลาและไม่มีใครเหลือเนื่องจากระบบอัตโนมัติแบบใหม่ IB ไม่รีบร้อนที่จะแบ่งปันความคิดเห็นเชิงบวก แต่ก็ไม่บ่นเช่นกัน ซึ่งเราสามารถสรุปได้ว่าพวกเขาชอบมัน ความขัดแย้งลดลงเนื่องจากความปลอดภัยของข้อมูลสามารถควบคุมได้อีกครั้ง แต่ไม่รบกวนกระบวนการพัฒนา ทีมงานได้รับความรับผิดชอบมากขึ้นและทัศนคติโดยรวมต่อความปลอดภัยของข้อมูลก็ดีขึ้น ธนาคารเข้าใจว่าการเปลี่ยนไปใช้ DevSecOps แทบจะหลีกเลี่ยงไม่ได้ และในความคิดของฉัน ก็ได้ดำเนินการด้วยวิธีที่อ่อนโยนและถูกต้องที่สุด
อเล็กซานเดอร์ ชูบิน สถาปนิกระบบ
ที่มา: will.com