แนวปฏิบัติที่ดีที่สุดสำหรับแอปพลิเคชันธนาคารแบบไฮบริดคลาวด์ การใช้งานที่ปลอดภัยและเป็นไปตามข้อกำหนดบน IBM Cloud และ Satellite - IBM Blog

ลูกค้าบริการทางการเงินต่างมองหาวิธีปรับปรุงแอปพลิเคชันของตนให้ทันสมัยมากขึ้น ซึ่งรวมถึงการปรับปรุงการพัฒนาและบำรุงรักษาโค้ดให้ทันสมัย ​​(ช่วยเหลือด้วยทักษะที่ขาดแคลน และช่วยให้เกิดนวัตกรรมและเทคโนโลยีใหม่ๆ ที่ผู้ใช้ปลายทางต้องการ) ตลอดจนการปรับปรุงการใช้งานและการดำเนินงาน โดยใช้เทคนิคที่คล่องตัวและ DevSecOps.

ในฐานะส่วนหนึ่งของเส้นทางแห่งการปรับปรุงให้ทันสมัย ​​ลูกค้าต้องการความยืดหยุ่นในการกำหนดตำแหน่งการติดตั้งใช้งานที่ "เหมาะสมตามวัตถุประสงค์" ที่ดีที่สุดสำหรับแอปพลิเคชันของตน ซึ่งอาจอยู่ในสภาพแวดล้อมใดๆ ที่ Hybrid Cloud รองรับ (ภายในองค์กร บนคลาวด์ส่วนตัว บนคลาวด์สาธารณะ หรือบน Edge) IBM Cloud Satellite® ตอบสนองข้อกำหนดนี้โดยการอนุญาตให้แอปพลิเคชันคลาวด์เนทีฟสมัยใหม่สามารถทำงานได้ทุกที่ที่ไคลเอ็นต์ต้องการ ขณะเดียวกันก็รักษาระดับการควบคุมที่เป็นมาตรฐานและสม่ำเสมอสำหรับการบริหารแอปพลิเคชันบนไฮบริดคลาวด์

นอกจากนี้ แอปพลิเคชันบริการทางการเงินจำนวนมากยังรองรับปริมาณงานที่ได้รับการควบคุม ซึ่งจำเป็นต้องมีการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดในระดับที่เข้มงวด รวมถึงการป้องกันปริมาณงานแบบ Zero Trust IBM Cloud for Financial Services ตอบสนองความต้องการดังกล่าวโดยมอบเฟรมเวิร์กการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดแบบ end-to-end ที่สามารถใช้เพื่อนำไปใช้และ/หรือปรับปรุงแอปพลิเคชันให้ทันสมัยอย่างปลอดภัยบนไฮบริดคลาวด์

ในบทความนี้ เราจะแสดงวิธีการปรับใช้แอปพลิเคชันธนาคารกับทั้งสองอย่างอย่างง่ายดาย IBM Cloud สำหรับบริการทางการเงิน และ ดาวเทียมโดยใช้ไปป์ไลน์ CI/CD/CC อัตโนมัติในลักษณะทั่วไปและสม่ำเสมอ สิ่งนี้ต้องการการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดในระดับลึกตลอดกระบวนการสร้างและการปรับใช้ทั้งหมด

ความรู้เบื้องต้นเกี่ยวกับแนวคิดและผลิตภัณฑ์

วัตถุประสงค์ของ IBM Cloud for Financial Services คือการจัดหาความปลอดภัยและการปฏิบัติตามข้อกำหนดสำหรับบริษัทผู้ให้บริการทางการเงิน มันทำได้โดยการใช้ประโยชน์จากมาตรฐานอุตสาหกรรมเช่น นิสท์ 800-53 และความเชี่ยวชาญของลูกค้าบริการทางการเงินมากกว่าร้อยรายที่เป็นส่วนหนึ่งของ Financial Services Cloud Council โดยมอบกรอบการควบคุมที่สามารถนำมาใช้งานได้อย่างง่ายดายโดยใช้สถาปัตยกรรมอ้างอิง บริการคลาวด์ที่ผ่านการรับรอง และ ISV รวมถึงการเข้ารหัสระดับสูงสุดและการปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง (CC) บนไฮบริดคลาวด์

IBM Cloud Satellite มอบประสบการณ์ไฮบริดคลาวด์ที่แท้จริง Satellite ช่วยให้สามารถรันปริมาณงานได้ทุกที่โดยไม่กระทบต่อความปลอดภัย กระจกบานเดียวช่วยให้มองเห็นทรัพยากรทั้งหมดได้อย่างง่ายดายในแดชบอร์ดเดียว เพื่อปรับใช้แอปพลิเคชันในสภาพแวดล้อมที่แตกต่างกันเหล่านี้ เราได้พัฒนาชุดเครื่องมือ DevSecOps ที่แข็งแกร่งเพื่อสร้างแอปพลิเคชัน ปรับใช้ในตำแหน่งดาวเทียมในลักษณะที่ปลอดภัยและสม่ำเสมอ และตรวจสอบสภาพแวดล้อมโดยใช้แนวทางปฏิบัติ DevOps ที่ดีที่สุด

ในโปรเจ็กต์นี้ เราใช้แอปพลิเคชันการสร้างสินเชื่อที่ได้รับการปรับปรุงให้ทันสมัยเพื่อใช้ Kubernetes และไมโครเซอร์วิส เพื่อให้บริการนี้ แอปพลิเคชันธนาคารใช้ระบบนิเวศของแอปพลิเคชันพันธมิตรที่ทำงานร่วมกันโดยใช้ เบียน กรอบ.

ภาพรวมของแอปพลิเคชัน

แอปพลิเคชันที่ใช้ในโครงการนี้เป็นแอปพลิเคชันการกำเนิดสินเชื่อที่พัฒนาขึ้นโดยเป็นส่วนหนึ่งของ เบียน คอร์เลส ความคิดริเริ่ม 2.0 ลูกค้าได้รับสินเชื่อส่วนบุคคลผ่านช่องทางออนไลน์ที่ปลอดภัยที่นำเสนอโดยธนาคาร แอปพลิเคชันใช้ระบบนิเวศของแอปพลิเคชันคู่ค้าที่ทำงานร่วมกันบนสถาปัตยกรรม BIAN ซึ่งใช้งานบน IBM Cloud for Financial Services BIAN Coreless Initiative ช่วยให้สถาบันการเงินสามารถเลือกพันธมิตรที่ดีที่สุดเพื่อช่วยนำบริการใหม่ๆ ออกสู่ตลาดได้อย่างรวดเร็วและมีประสิทธิภาพผ่านสถาปัตยกรรม BIAN แต่ละองค์ประกอบหรือโดเมนบริการ BIAN ได้รับการปรับใช้ผ่านไมโครเซอร์วิส ซึ่งใช้งานบนคลัสเตอร์ OCP บน IBM Cloud

ส่วนประกอบของแอปพลิเคชันที่อิงตามโดเมนบริการ BIAN

• ไดเรกทอรีผลิตภัณฑ์: รักษาไดเรกทอรีที่ครอบคลุมของผลิตภัณฑ์และบริการของธนาคาร

• สินเชื่ออุปโภคบริโภค: จัดการการปฏิบัติตามผลิตภัณฑ์สินเชื่อผู้บริโภค ซึ่งรวมถึงการตั้งค่าเริ่มต้นของวงเงินสินเชื่อ และความสำเร็จของงานการประมวลผลผลิตภัณฑ์ตามกำหนดเวลาและเฉพาะกิจ

• กระบวนการเสนอลูกค้า/API: จัดเตรียมการประมวลผลข้อเสนอผลิตภัณฑ์สำหรับลูกค้าใหม่หรือลูกค้าที่จัดตั้งขึ้น

• โปรไฟล์การกำหนดเส้นทางปาร์ตี้: รักษาโปรไฟล์เล็กๆ ของตัวบ่งชี้หลักสำหรับลูกค้าที่ถูกอ้างอิงในระหว่างการโต้ตอบกับลูกค้า เพื่ออำนวยความสะดวกในการตัดสินใจเกี่ยวกับการกำหนดเส้นทาง การบริการ และการปฏิบัติตามผลิตภัณฑ์/บริการ

ภาพรวมกระบวนการปรับใช้

เวิร์กโฟลว์ DevSecOps ที่คล่องตัวถูกนำมาใช้เพื่อทำให้การปรับใช้งานบนไฮบริดคลาวด์เสร็จสมบูรณ์ เวิร์กโฟลว์ DevSecOps มุ่งเน้นไปที่กระบวนการส่งมอบซอฟต์แวร์ที่บ่อยครั้งและเชื่อถือได้ วิธีการนี้เป็นแบบวนซ้ำแทนที่จะเป็นเชิงเส้น ซึ่งช่วยให้ทีม DevOps สามารถเขียนโค้ด บูรณาการ รันการทดสอบ ส่งมอบรุ่น และปรับใช้การเปลี่ยนแปลงร่วมกันแบบเรียลไทม์ ขณะเดียวกันก็รักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดไว้

การใช้งาน IBM Cloud for Financial Services ประสบความสำเร็จในคลัสเตอร์แลนดิ้งโซนที่ปลอดภัย และการปรับใช้โครงสร้างพื้นฐานยังเป็นแบบอัตโนมัติโดยใช้นโยบายเป็นโค้ด (terraform- แอปพลิเคชันประกอบด้วยส่วนประกอบต่างๆ แต่ละส่วนประกอบถูกปรับใช้โดยใช้ส่วนประกอบของตัวเอง บูรณาการอย่างต่อเนื่อง (CI), การจัดส่งแบบต่อเนื่อง (CD) และ การปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง (CC) ไปป์ไลน์บน RedHat OpenShift Cluster เพื่อให้บรรลุผลในการใช้งานบนดาวเทียม ท่อ CI/CC จึงถูกนำมาใช้ซ้ำ และสร้างไปป์ไลน์ CD ใหม่

บูรณาการอย่างต่อเนื่อง

แต่ละองค์ประกอบของการปรับใช้ IBM Cloud มีไปป์ไลน์ CI ของตัวเอง ชุดของขั้นตอนและวิธีการที่แนะนำจะรวมอยู่ในห่วงโซ่เครื่องมือ CI เครื่องสแกนโค้ดแบบคงที่จะใช้เพื่อตรวจสอบพื้นที่เก็บข้อมูลแอปพลิเคชันเพื่อหาความลับใดๆ ที่จัดเก็บไว้ในซอร์สโค้ดของแอปพลิเคชัน รวมถึงแพ็คเกจที่มีช่องโหว่ใดๆ ที่ใช้เป็นการขึ้นต่อกันภายในโค้ดของแอปพลิเคชัน สำหรับคอมมิต Git แต่ละรายการ อิมเมจคอนเทนเนอร์จะถูกสร้างขึ้น และแท็กจะถูกกำหนดให้กับอิมเมจตามหมายเลขบิลด์ การประทับเวลา และรหัสคอมมิต ระบบการติดแท็กนี้ช่วยให้มั่นใจในการติดตามของภาพ ก่อนที่จะสร้างอิมเมจ Dockerfile จะได้รับการทดสอบ รูปภาพที่สร้างขึ้นจะถูกบันทึกไว้ในรีจิสตรีรูปภาพส่วนตัว สิทธิ์การเข้าถึงสำหรับการปรับใช้คลัสเตอร์เป้าหมายได้รับการกำหนดค่าโดยอัตโนมัติโดยใช้โทเค็น API ซึ่งสามารถเพิกถอนได้ ทำการสแกนช่องโหว่ด้านความปลอดภัยบนอิมเมจคอนเทนเนอร์ ลายเซ็นนักเทียบท่าจะถูกใช้เมื่อดำเนินการเสร็จสิ้น การเพิ่มแท็กรูปภาพที่สร้างขึ้นจะอัปเดตบันทึกการใช้งานทันที การใช้เนมสเปซที่ชัดเจนภายในคลัสเตอร์มีจุดประสงค์เพื่อแยกการใช้งานแต่ละรายการ โค้ดใดๆ ที่รวมเข้ากับสาขาที่ระบุของที่เก็บ Git ซึ่งมีไว้สำหรับการใช้งานบนคลัสเตอร์ Kubernetes โดยเฉพาะ จะถูกสร้างขึ้น ตรวจสอบ และนำไปใช้โดยอัตโนมัติ

รายละเอียดของอิมเมจ Docker แต่ละอิมเมจจะถูกจัดเก็บไว้ในพื้นที่เก็บข้อมูล ซึ่งมีการอธิบายโดยละเอียดในส่วนการใช้งานต่อเนื่องของบล็อกนี้ นอกจากนี้ ยังมีการรวบรวมหลักฐานตลอดทุกการเดินท่อ หลักฐานนี้อธิบายว่างานใดบ้างที่ดำเนินการใน toolchain เช่น การสแกนช่องโหว่และการทดสอบหน่วย หลักฐานนี้ถูกจัดเก็บไว้ในพื้นที่เก็บข้อมูล git และที่เก็บข้อมูลออบเจ็กต์บนคลาวด์ เพื่อให้สามารถตรวจสอบได้หากจำเป็น

เราใช้ toolchains CI ปัจจุบันที่ใช้สำหรับการปรับใช้ IBM Cloud ที่ระบุไว้ข้างต้นสำหรับการปรับใช้ Satellite เนื่องจากแอปพลิเคชันยังคงไม่เปลี่ยนแปลง จึงไม่จำเป็นต้องสร้างไปป์ไลน์ CI ใหม่สำหรับการปรับใช้ใหม่

การปรับใช้อย่างต่อเนื่อง

สินค้าคงคลังทำหน้าที่เป็นแหล่งที่มาของความจริงเกี่ยวกับสิ่งประดิษฐ์ใดที่ถูกนำไปใช้ในสภาพแวดล้อม/ภูมิภาคใด ซึ่งสามารถทำได้โดยใช้สาขา git เพื่อแสดงสภาพแวดล้อม โดยมีไปป์ไลน์โปรโมชันที่อัปเดตสภาพแวดล้อมในแนวทางที่ใช้ GitOps ในการปรับใช้ครั้งก่อน สินค้าคงคลังยังโฮสต์ไฟล์การปรับใช้ด้วย นี่คือไฟล์ทรัพยากร YAML Kubernetes ที่อธิบายแต่ละองค์ประกอบ ไฟล์การปรับใช้เหล่านี้จะได้รับการอัปเดตด้วยตัวอธิบายเนมสเปซที่ถูกต้อง พร้อมด้วยอิมเมจ Docker เวอร์ชันใหม่ล่าสุดสำหรับแต่ละองค์ประกอบ

อย่างไรก็ตาม เราพบว่าแนวทางนี้ยากด้วยเหตุผลบางประการ จากมุมมองของแอปพลิเคชัน การเปลี่ยนแปลงค่าแท็กรูปภาพและเนมสเปซจำนวนมากโดยใช้เครื่องมือทดแทน YAML (เช่น YQ) ถือเป็นเรื่องหยาบและซับซ้อน สำหรับ Satellite เอง เรากำลังใช้กลยุทธ์การอัปโหลดโดยตรง โดยไฟล์ YAML แต่ละไฟล์ที่ให้มาจะนับเป็น "เวอร์ชัน" เราต้องการให้เวอร์ชันสอดคล้องกับแอปพลิเคชันทั้งหมด ไม่ใช่แค่องค์ประกอบเดียวหรือไมโครเซอร์วิส

ต้องการแนวทางที่แตกต่างออกไป ดังนั้นเราจึงออกแบบกระบวนการปรับใช้ใหม่เพื่อใช้แผนภูมิ Helm แทน สิ่งนี้ทำให้เราสามารถกำหนดพารามิเตอร์ค่าที่สำคัญ เช่น เนมสเปซและแท็กรูปภาพ และแทรกค่าเหล่านั้นเข้าไปในเวลาปรับใช้ การใช้ตัวแปรเหล่านี้ช่วยลดความยุ่งยากในการแยกวิเคราะห์ไฟล์ YAML สำหรับค่าที่กำหนด แผนภูมิหางเสือถูกสร้างขึ้นแยกต่างหากและจัดเก็บไว้ในรีจิสตรีคอนเทนเนอร์เดียวกันกับอิมเมจ BIAN ที่สร้างขึ้น ขณะนี้เรากำลังดำเนินการพัฒนาไปป์ไลน์ CI เฉพาะสำหรับตรวจสอบความถูกต้องของแผนภูมิหางเสือ สิ่งนี้จะทำให้แผนภูมิเป็นเส้น บรรจุหีบห่อ ลงนามเพื่อความถูกต้อง (ซึ่งจะได้รับการตรวจสอบเมื่อถึงเวลาใช้งาน) และจัดเก็บแผนภูมิ ในตอนนี้ ขั้นตอนเหล่านี้ดำเนินการด้วยตนเองเพื่อพัฒนาแผนภูมิ มีปัญหาประการหนึ่งในการใช้แผนภูมิหางเสือและการกำหนดค่าดาวเทียมร่วมกัน: ฟังก์ชันการทำงานของหางเสือจำเป็นต้องเชื่อมต่อโดยตรงกับคลัสเตอร์ Kubernetes หรือ OpenShift เพื่อให้ทำงานได้อย่างมีประสิทธิภาพสูงสุด และแน่นอนว่า Satellite จะไม่อนุญาตให้ทำเช่นนั้น ดังนั้น เพื่อแก้ไขปัญหานี้ เราใช้ "เทมเพลตหางเสือ" เพื่อส่งออกแผนภูมิที่มีรูปแบบถูกต้อง จากนั้นจึงส่งไฟล์ YAML ที่เป็นผลลัพธ์ไปยังฟังก์ชันอัปโหลดผ่านดาวเทียม จากนั้นฟังก์ชันนี้จะใช้ประโยชน์จาก IBM Cloud Satellite CLI เพื่อสร้างเวอร์ชันการกำหนดค่าที่มีแอปพลิเคชัน YAML มีข้อเสียอยู่บางประการ: เราไม่สามารถใช้ฟังก์ชันที่มีประโยชน์บางอย่างที่ Helm มอบให้ได้ เช่น ความสามารถ ย้อนกลับ เป็นเวอร์ชันแผนภูมิก่อนหน้าและการทดสอบที่สามารถทำได้เพื่อให้แน่ใจว่าแอปพลิเคชันทำงานอย่างถูกต้อง อย่างไรก็ตาม เราสามารถใช้กลไกการย้อนกลับของดาวเทียมแทนและใช้การกำหนดเวอร์ชันเป็นพื้นฐานสำหรับสิ่งนี้

การปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง

ไปป์ไลน์ CC มีความสำคัญสำหรับการสแกนอาร์ติแฟกต์และที่เก็บข้อมูลที่ปรับใช้อย่างต่อเนื่อง ค่าที่นี่คือการค้นหาช่องโหว่ที่รายงานใหม่ซึ่งอาจค้นพบหลังจากปรับใช้แอปพลิเคชันแล้ว คำจำกัดความล่าสุดของช่องโหว่จากองค์กรต่างๆ เช่น สนุ๊ก และ โปรแกรม CVE ใช้เพื่อติดตามปัญหาใหม่เหล่านี้ CC toolchain รันเครื่องสแกนโค้ดแบบคงที่ในช่วงเวลาที่ผู้ใช้กำหนดบนที่เก็บแอปพลิเคชันซึ่งมีไว้เพื่อตรวจจับความลับในซอร์สโค้ดของแอปพลิเคชันและช่องโหว่ในการขึ้นต่อกันของแอปพลิเคชัน

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

ข้อมูลเชิงลึก DevOps มีคุณค่าในการติดตามปัญหาและมาตรการรักษาความปลอดภัยโดยรวมของแอปพลิเคชันของคุณ เครื่องมือนี้ประกอบด้วยตัววัดทั้งหมดจาก Toolchain ก่อนหน้านี้ที่ทำงานในทั้งสามระบบ: การบูรณาการอย่างต่อเนื่อง การปรับใช้ และการปฏิบัติตามข้อกำหนด ผลการสแกนหรือการทดสอบใดๆ จะถูกอัปโหลดไปยังระบบนั้น และ ล่วงเวลาคุณสามารถสังเกตได้ว่ามาตรการรักษาความปลอดภัยของคุณมีการพัฒนาไปอย่างไร

การรับ CC ในสภาพแวดล้อมคลาวด์มีความสำคัญสำหรับอุตสาหกรรมที่มีการควบคุมอย่างเข้มงวด เช่น บริการทางการเงินที่ต้องการปกป้องข้อมูลลูกค้าและแอปพลิเคชัน ในอดีต กระบวนการนี้ทำได้ยากและต้องทำด้วยมือ ซึ่งทำให้องค์กรตกอยู่ในความเสี่ยง แต่ด้วย ศูนย์ความปลอดภัยและการปฏิบัติตามข้อกำหนดของ IBM Cloudคุณสามารถเพิ่มการตรวจสอบการปฏิบัติตามข้อกำหนดอัตโนมัติรายวันลงในวงจรการพัฒนาของคุณเพื่อช่วยลดความเสี่ยงนี้ได้ การตรวจสอบเหล่านี้รวมถึงการประเมินต่างๆ ของห่วงโซ่เครื่องมือ DevSecOps เพื่อให้มั่นใจในความปลอดภัยและการปฏิบัติตามข้อกำหนด

จากประสบการณ์ของเรากับโปรเจ็กต์นี้และโปรเจ็กต์อื่นที่คล้ายคลึงกัน เราได้สร้างชุดแนวทางปฏิบัติที่ดีที่สุดเพื่อช่วยทีมในการปรับใช้โซลูชันคลาวด์แบบไฮบริดสำหรับ IBM Cloud for Financial Services และ IBM Cloud Satellite:

• การบูรณาการอย่างต่อเนื่อง
  • ดูแลรักษาไลบรารีสคริปต์ทั่วไปสำหรับแอปพลิเคชันที่คล้ายกันใน toolchains ที่แตกต่างกัน นี่คือชุดคำสั่งที่กำหนดว่า CI toolchain ของคุณควรทำอะไร ตัวอย่างเช่น กระบวนการสร้างสำหรับแอปพลิเคชัน NodeJS โดยทั่วไปจะเป็นไปตามโครงสร้างเดียวกัน ดังนั้นจึงเหมาะสมที่จะเก็บไลบรารีการเขียนสคริปต์ไว้ในที่เก็บแยกต่างหาก ซึ่งกลุ่มเครื่องมือจะอ้างอิงถึงเมื่อสร้างแอปพลิเคชัน ซึ่งช่วยให้มีแนวทางที่สอดคล้องกันกับ CI ส่งเสริมการใช้ซ้ำ และเพิ่มการบำรุงรักษา
  • อีกทางหนึ่ง CI toolchains สามารถนำมาใช้ซ้ำได้สำหรับแอปพลิเคชันที่คล้ายกันโดยใช้ทริกเกอร์ ทริกเกอร์ที่แยกจากกันเหล่านี้สามารถใช้เพื่อระบุแอปพลิเคชันที่จะถูกสร้างขึ้น รหัสสำหรับแอปพลิเคชันอยู่ที่ไหน และการปรับแต่งอื่นๆ

• การปรับใช้อย่างต่อเนื่อง
  • สำหรับแอปพลิเคชันที่มีองค์ประกอบหลายองค์ประกอบ ให้คงไว้ซึ่งรายการเดียวและด้วยเหตุนี้ จึงมีห่วงโซ่เครื่องมือการปรับใช้เดียวเพื่อปรับใช้ส่วนประกอบทั้งหมดที่แสดงอยู่ในรายการสินค้าคงคลัง ซึ่งจะช่วยป้องกันการทำซ้ำได้มาก ไฟล์การปรับใช้ YAML ของ Kubernetes ทั้งหมดมีกลไกการปรับใช้เหมือนกัน ดังนั้น toolchain เดี่ยวที่วนซ้ำแต่ละไฟล์ตามลำดับจึงมีเหตุผลมากกว่าการรักษา CD toolchain หลายอัน ซึ่งทั้งหมดล้วนทำสิ่งเดียวกันเป็นหลัก ความสามารถในการบำรุงรักษาเพิ่มขึ้น และมีงานที่ต้องทำน้อยลงในการปรับใช้แอปพลิเคชัน ทริกเกอร์ยังคงสามารถใช้เพื่อปรับใช้ไมโครเซอร์วิสแต่ละรายการได้ หากต้องการ
  • ใช้แผนภูมิ Helm สำหรับการใช้งานที่มีหลายองค์ประกอบที่ซับซ้อน การใช้ Helm ในโครงการ BIAN ทำให้การปรับใช้ง่ายขึ้นมาก ไฟล์ Kubernetes เขียนด้วย YAML และการใช้ตัวแยกวิเคราะห์ข้อความแบบ bash นั้นยุ่งยากหากจำเป็นต้องปรับแต่งค่าหลายค่าในเวลาปรับใช้ Helm ทำให้สิ่งนี้ง่ายขึ้นโดยใช้ตัวแปร ซึ่งทำให้การทดแทนค่ามีประสิทธิภาพมากขึ้น นอกจากนี้ Helm ยังมีคุณสมบัติอื่นๆ เช่น การกำหนดเวอร์ชันทั้งแอปพลิเคชัน การกำหนดเวอร์ชันแผนภูมิ การจัดเก็บรีจิสทรีของการกำหนดค่าการใช้งาน และความสามารถในการย้อนกลับในกรณีที่เกิดความล้มเหลว แม้ว่าการย้อนกลับจะไม่ทำงานในการปรับใช้เฉพาะดาวเทียม แต่สิ่งนี้รองรับโดยการกำหนดเวอร์ชันการกำหนดค่าดาวเทียม
• การปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง
  • เราขอแนะนำอย่างยิ่งให้ตั้งค่ากลุ่มเครื่องมือ CC เป็นส่วนหนึ่งของโครงสร้างพื้นฐานของคุณเพื่อสแกนโค้ดและอาร์ติแฟกต์อย่างต่อเนื่องเพื่อหาช่องโหว่ที่เพิ่งถูกเปิดเผย โดยทั่วไปแล้ว การสแกนเหล่านี้สามารถทำงานได้ทุกคืนหรือตามกำหนดเวลาที่เหมาะสมกับแอปพลิเคชันและสถานการณ์ด้านความปลอดภัยของคุณ เพื่อติดตามปัญหาและมาตรการรักษาความปลอดภัยโดยรวมของแอปพลิเคชันของคุณ เราขอแนะนำให้คุณใช้ DevOps Insights
  • นอกจากนี้เรายังแนะนำให้ใช้ศูนย์ความปลอดภัยและการปฏิบัติตามข้อกำหนด (SCC) เพื่อทำให้มาตรการรักษาความปลอดภัยของคุณเป็นแบบอัตโนมัติ สรุปหลักฐานที่สร้างโดยไปป์ไลน์สามารถอัปโหลดไปยัง SCC โดยที่แต่ละรายการในสรุปหลักฐานจะถือเป็น "ข้อเท็จจริง" ที่เกี่ยวข้องกับงานที่เสร็จสมบูรณ์ใน toolchain ไม่ว่าจะเป็นการสแกนช่องโหว่ การทดสอบหน่วย หรือสิ่งอื่น ๆ ที่คล้ายคลึงกัน . จากนั้น SCC จะทำการทดสอบการตรวจสอบกับหลักฐานเพื่อพิจารณาว่ามีการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดที่เกี่ยวข้องกับ toolchains
• สินค้าคงคลัง
  • ดังที่กล่าวไว้ก่อนหน้านี้ ด้วยการปรับใช้อย่างต่อเนื่อง ควรรักษารายการแอปพลิเคชันเดียวโดยที่จะจัดเก็บรายละเอียดไมโครเซอร์วิสทั้งหมดของคุณ พร้อมด้วยไฟล์การปรับใช้ Kubernetes (หากไม่ได้ใช้ Helm) ซึ่งทำให้มีแหล่งความจริงเพียงแหล่งเดียวเกี่ยวกับสถานะการปรับใช้ของคุณ เนื่องจากสาขาในสินค้าคงคลังของคุณเป็นตัวแทนของสภาพแวดล้อม การรักษาสภาพแวดล้อมเหล่านี้ในคลังสินค้าคงคลังหลายแห่งจึงกลายเป็นเรื่องยุ่งยากได้อย่างรวดเร็ว
• หลักฐาน
  • วิธีการจัดเก็บหลักฐานควรได้รับการปฏิบัติที่แตกต่างจากสินค้าคงคลัง ในกรณีนี้ ควรใช้ที่เก็บหลักฐานหนึ่งแห่งต่อส่วนประกอบ หากคุณรวมเข้าด้วยกัน หลักฐานที่เก็บไว้อาจมีล้นหลามและยากต่อการจัดการ การค้นหาชิ้นส่วนหลักฐานที่เฉพาะเจาะจงจะมีประสิทธิภาพมากกว่ามากหากหลักฐานนั้นถูกจัดเก็บไว้ในที่เก็บข้อมูลเฉพาะสำหรับส่วนประกอบ สำหรับการปรับใช้ ล็อกเกอร์หลักฐานตัวเดียวเป็นที่ยอมรับได้ เนื่องจากมีที่มาจากชุดเครื่องมือการปรับใช้เดี่ยว
  • เราขอแนะนำอย่างยิ่งให้จัดเก็บหลักฐานในที่เก็บข้อมูลออบเจ็กต์บนคลาวด์ รวมถึงการใช้ตัวเลือกพื้นที่เก็บข้อมูล git เริ่มต้น เนื่องจากบัคเก็ต COS สามารถกำหนดค่าให้ไม่เปลี่ยนรูปได้ ซึ่งช่วยให้เราสามารถจัดเก็บหลักฐานได้อย่างปลอดภัยโดยไม่มีโอกาสถูกแก้ไข ซึ่งเป็นสิ่งสำคัญมากในกรณีของเส้นทางการตรวจสอบ        

สรุป

ในบล็อกนี้ เราจัดแสดงประสบการณ์ของเราในการใช้งานแอปพลิเคชันธนาคารที่ใช้ BIAN ทั่วทั้งไฮบริดคลาวด์ นั่นคือการใช้ไปป์ไลน์ DevSecOps เพื่อปรับใช้ปริมาณงานทั้งบน IBM Cloud และในสภาพแวดล้อมดาวเทียม เราได้พูดคุยถึงข้อดีข้อเสียของแนวทางต่างๆ และแนวทางปฏิบัติที่ดีที่สุดที่เราได้รับหลังจากดำเนินโครงการนี้ เราหวังว่าสิ่งนี้จะช่วยให้ทีมอื่นๆ ประสบความสำเร็จบนเส้นทางคลาวด์แบบไฮบริดด้วยความสม่ำเสมอและรวดเร็วยิ่งขึ้น แจ้งให้เราทราบความคิดของคุณ

สำรวจสิ่งที่ IBM นำเสนอในวันนี้