Cloud-Native Security อยู่ในอากาศที่ KubeCon/CloudNativeCon 2022

ในฐานะที่เป็นคอหนังที่รู้จักตัวเองดี สายหนังบางแนวก็เกาะติดผมตลอดหลายปีที่ผ่านมา หนึ่งในนั้นมาจาก Ridley Scott's นักต่อสู้ในสมัย​​โรมัน (2000) เมื่อวุฒิสมาชิกชาวโรมันกล่าวว่า “หัวใจของกรุงโรมไม่ใช่หินอ่อนของวุฒิสภา แต่เป็นเม็ดทรายของโคลอสเซียม”

บรรทัดนั้นผุดขึ้นมาในหัวของฉันขณะที่ฉันเดินไปรอบ ๆ ห้องโถงที่ KubeCon/CloudNativeCon (“KubeCon”) ซึ่งเป็นงานปะรำสำหรับ มูลนิธิ Cloud Native Computing (CNCF). สำหรับฉันแล้ว หัวใจสำคัญของการรักษาความปลอดภัยแบบคลาวด์เนทีฟคือ KubeCon แน่นอนที่สุด

งานในอเมริกาเหนือของปีนี้จัดขึ้นเมื่อสัปดาห์ที่แล้วที่เมืองดีทรอยต์ โดยมีผู้เข้าร่วมหลายพันคนในสถานที่และคนอื่นๆ อีกจำนวนมากจากระยะไกล นอกเหนือจากงานหลักที่มีระยะเวลา XNUMX วันแล้ว ความสนใจที่เพิ่มขึ้นในโครงการเฉพาะทำให้ Cloud Native Computing Foundation จัดให้มี “งานกิจกรรมร่วมกัน” ขึ้นก่อนการประชุมหลัก

สำหรับงานปี 2022 นั้นไม่ได้มีแค่งาน CloudNativeSecurityCon สองวันเท่านั้น แต่ยังมีเนื้อหาความปลอดภัยมากมายในงานอื่นๆ เช่น Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon และอีกมากมาย ซึ่งสะท้อนให้เห็นถึงความสนใจอย่างกว้างขวางในระบบคลาวด์ หัวข้อความปลอดภัยดั้งเดิม ที่น่าสนใจคืองาน CloudNativeSecurityCon ได้ "เสร็จสิ้น" ไปแล้วสำหรับกิจกรรมอิสระที่จะจัดแยกกันในเดือนกุมภาพันธ์

การรักษาความปลอดภัยบนคลาวด์เนทีฟ: การพัฒนาเทียบกับการดำเนินการ

ดังนั้น สถานะปัจจุบันของการสนทนาด้านความปลอดภัยบนคลาวด์เนทีฟอยู่ที่ไหน สำหรับ Omdia มีจุดแยกที่ชัดเจน: ข้อกังวลที่มีการพัฒนาเป็นศูนย์กลางและข้อกังวลที่มีการดำเนินงานเป็นศูนย์กลาง การเรียกสิ่งเหล่านี้ว่า "Dev" และ "Ops" นั้นไม่เป็นประโยชน์ เนื่องจากโครงสร้างทีมมีอยู่อย่างฟุ่มเฟือยในหลายองค์กร: บางองค์กรอาจมีทีมวิศวกรรมความน่าเชื่อถือของไซต์ (SRE) บางทีมอาจเรียกว่าทีมปฏิบัติการ ทีมแพลตฟอร์ม และอื่นๆ

ในด้านการพัฒนาของบัญชีแยกประเภท หัวข้อที่น่าสนใจสามหัวข้อ ได้แก่ ที่มา สัญญาณรบกวน และการเปิดเผย

Provenance ถามคำถามพื้นฐาน: เราสามารถไว้วางใจความสมบูรณ์ขององค์ประกอบภายนอกที่เรารวมเข้ากับซอฟต์แวร์ไปป์ไลน์ของเราได้หรือไม่? แม้ว่าจะมีตัวอย่างมากมาย การโจมตี SolarWinds ในปี 2020 เป็นจุดเปลี่ยนสำหรับความสนใจในความสมบูรณ์ของห่วงโซ่อุปทานของซอฟต์แวร์ ที่ KubeCon มีแรงผลักดันที่ชัดเจนอยู่เบื้องหลังแนวคิดในการเซ็นชื่อซอฟต์แวร์อิมเมจ: The ร้านป้าย โครงการได้รับการประกาศให้เป็นความพร้อมใช้งานทั่วไปและกำลังใช้งานโดย Kubernetes และโครงการสำคัญอื่นๆ

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

การเปิดเผย: สำหรับช่องโหว่ใด ๆ ที่เราได้รับในฐานะองค์กรเป็นอย่างไร? ไม่มีตัวอย่างใดที่ดีกว่านี้ในประวัติศาสตร์อุตสาหกรรมเมื่อเร็วๆ นี้มากกว่า Log4j แน่นอน นี่คือขอบเขตของการอภิปรายเกี่ยวกับรายการวัสดุของซอฟต์แวร์ (SBOMs) เนื่องจากเกี่ยวข้องกับการรู้ว่าส่วนประกอบใดที่อาจใช้เป็นรูปภาพที่อยู่ในรีจิสตรีหรือใช้งานจริง น่าสนใจ ขณะที่บทความนี้กำลังเขียน มีการแจ้งให้ทราบล่วงหน้าว่าข้อมูลเกี่ยวกับช่องโหว่ที่สำคัญใน OpenSSL 3.x จะถูกเปิดเผยในไม่ช้า ซึ่งน่าจะเป็นกรณีการใช้งานที่ดีสำหรับ SBOMs อีกกรณีหนึ่ง ซึ่ง OpenSSL 3.x ใช้ในองค์กรของเราที่ใด เนื่องจากความครอบคลุมของ SBOM ยังไม่แพร่หลาย Omdia คาดว่าจะมีการใช้งาน SBOM น้อยที่สุดในเวลานี้

ทีมปฏิบัติการมักจะมุ่งเน้นไปที่การจัดหาและดำเนินการแพลตฟอร์มพื้นฐานที่ซับซ้อนมากขึ้นและดำเนินการดังกล่าวอย่างปลอดภัย คำว่า "แพลตฟอร์ม" มีความเกี่ยวข้องเป็นพิเศษที่นี่: มีความสนใจอย่างมากในการจัดระเบียบ Kubernetes และโครงการ CNCF ที่เพิ่มขึ้นจำนวนมาก (140 ในขณะที่เขียนนี้ ระหว่างขั้นตอนต่างๆ ของการบ่มเพาะโครงการ: แซนด์บ็อกซ์ การบ่ม การสำเร็จการศึกษา) ให้ง่ายขึ้น - เพื่อบริโภคแพลตฟอร์ม ความสนใจเฉพาะสำหรับผู้ชมความปลอดภัย โครงการเช่น Cilium (ใช้ฟังก์ชัน eBPF พื้นฐาน) สำหรับเครือข่ายและความสามารถในการสังเกต SPIFFE/SPIRE (สำหรับการสร้างข้อมูลประจำตัว) Falco (สำหรับการรักษาความปลอดภัยรันไทม์) Open Policy Agent (สำหรับนโยบายเป็นรหัส) , Cloud Custodian (สำหรับการกำกับดูแล) และอื่นๆ ที่ควรค่าแก่การพิจารณา ความคาดหวังคือโครงการเหล่านี้จะทำงานร่วมกันมากขึ้นในด้าน "ความสามารถในการสังเกต" ของ cloud-native และจะปรับใช้โดยใช้แนวทางปฏิบัติเช่น GitOps

เหตุผลของการมองในแง่ดีเกี่ยวกับความปลอดภัยแบบ Cloud-Native

เราจะไปจากที่นี่ที่ไหน? เห็นได้ชัดว่าชุมชนที่ใช้ระบบคลาวด์ให้ความสำคัญกับความปลอดภัยเป็นอย่างมาก และกำลังก้าวไปข้างหน้าอย่างรวดเร็วด้วยการจัดการกับหัวข้อต่างๆ รอบตัว คำแนะนำสำหรับทีมรักษาความปลอดภัยคือการเร่งดำเนินการโครงการและความคิดริเริ่มต่างๆ เหล่านี้อย่างรวดเร็ว สิ่งสำคัญคือต้องทราบว่าสำหรับหลายๆ องค์กร สิ่งนี้จะไม่มาในรูปแบบของการใช้โครงการชุมชนอย่างชัดเจน (แม้ว่าบางองค์กรจะทำเช่นนั้น) แต่เป็นส่วนหนึ่งของแพลตฟอร์มแบบแพ็คเกจจากผู้ขาย เช่น Red Hat, SUSE, Canonical และอื่นๆ หรือโดยตรงจากผู้ให้บริการคลาวด์ เช่น AWS, Google Cloud, Azure, Oracle และอื่นๆ

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