คู่มือฉบับสมบูรณ์เกี่ยวกับความปลอดภัยของคอนเทนเนอร์ Docker

อินฟอร์เมเทค ดิจิตอล » Recursos » คู่มือฉบับสมบูรณ์เกี่ยวกับความปลอดภัยของคอนเทนเนอร์ Docker

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

หลายทีมยังคงเชื่อมั่นในฉนวนกันความร้อนของตู้คอนเทนเนอร์โดยไม่ไตร่ตรอง และในการจัดการร่วมกับ Kubernetes (ดูเพิ่มเติม) Docker Compose และ Kubernetesราวกับว่ามันเป็นตู้เซฟ ทั้งที่ความจริงแล้วเรากำลังพูดถึงกระบวนการที่ใช้เคอร์เนล เครือข่าย และในหลายๆ กรณีก็มีสิทธิ์การเข้าถึงมากเกินไป มาดูกันในรายละเอียดว่าทำไม ความปลอดภัยของคอนเทนเนอร์ Docker นี่คือเสาหลักที่สำคัญ: ความเสี่ยงที่แท้จริงมีอะไรบ้าง และเทคนิคและเครื่องมือใดบ้างที่ใช้ในปัจจุบันในการผลิตเพื่อลดความเสี่ยงเหล่านั้นโดยไม่กระทบต่อความคล่องตัวของ DevOps

การรักษาความปลอดภัยของคอนเทนเนอร์ Docker คืออะไรกันแน่?

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

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

อีกแง่มุมที่สำคัญคือความปลอดภัยของกระบวนการและการจัดการระบบซึ่งรวมถึงวิธีการทำงานของคอนเทนเนอร์ ผู้ใช้ที่ควบคุม ความสามารถของเคอร์เนลที่คอนเทนเนอร์มี ทรัพยากรที่คอนเทนเนอร์สามารถใช้งานได้ และนโยบายที่ใช้ในคลัสเตอร์ Kubernetes แนวคิดต่างๆ เช่น หลักการให้สิทธิ์ขั้นต่ำ โปรไฟล์ความปลอดภัย (seccomp, AppArmor, SELinux) และนโยบายการควบคุมการเข้าถึงตามบทบาท (RBAC) ก็มีความเกี่ยวข้องเช่นกัน

ความเสี่ยงและปัญหาด้านความปลอดภัยทั่วไปใน Docker

อุบัติเหตุในสภาพแวดล้อมคอนเทนเนอร์มักเกิดจากความผิดพลาดของมนุษย์และการตัดสินใจทางเทคนิคที่ไม่ดีต่อไปนี้คือปัญหาที่พบได้บ่อยที่สุดในการตรวจสอบบัญชีและช่องโหว่ที่เกิดขึ้นจริง

รูปภาพที่อ่อนแอหรือเป็นอันตราย

อิมเมจคอนเทนเนอร์แต่ละตัวเป็นระบบขนาดเล็กที่มีชุดแพ็กเกจและส่วนประกอบที่จำเป็นเฉพาะตัวหากคุณใช้ภาพที่ล้าสมัย มีขนาดใหญ่เกินจริง หรือน่าสงสัย คุณก็จะได้รับช่องโหว่ด้านความปลอดภัย (CVE) ช่องโหว่ลับ และแนวทางปฏิบัติที่ไม่ดีจากภาพเหล่านั้นด้วย การสแกนภาพสาธารณะหลายล้านภาพแสดงให้เห็นว่าภาพจำนวนมากมีมัลแวร์หรือช่องโหว่ด้านความปลอดภัยที่สำคัญอยู่แล้ว

ปัญหาจะยิ่งซับซ้อนขึ้นเมื่อใช้ระบบปฏิบัติการแบบทั้งชุดเป็นพื้นฐาน (เช่น Ubuntu, Debian เป็นต้น) สำหรับแอปพลิเคชันที่ต้องการเพียงไลบรารีไม่กี่ตัว แพ็กเกจเสริมอีกหลายร้อยรายการ (โปรแกรมแก้ไขข้อความ เชลล์ ตัวจัดการแพ็กเกจ เครื่องมือเครือข่าย ฯลฯ) กลับเพิ่มช่องโหว่ในการโจมตีโดยไม่เพิ่มคุณค่าใดๆ ในการใช้งานจริง สำหรับผู้โจมตีที่สามารถเข้าถึงได้ การค้นหาช่องโหว่นั้นยากมาก apt-get หรือ โค้ง การดาวน์โหลดมัลแวร์พร้อมๆ กันนั้นถือเป็นของขวัญ

หลุดออกจากคอนเทนเนอร์ไปยังโฮสต์

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

หากคอนเทนเนอร์ที่ถูกบุกรุกกำลังทำงานในฐานะผู้ใช้ root และมีสิทธิ์การเข้าถึงอย่างกว้างขวางการเชื่อมต่อไปยังโฮสต์หรือโครงสร้างพื้นฐานส่วนที่เหลือทำได้ง่ายกว่ามาก ดังนั้นจึงยังคงยืนกรานที่จะไม่ใช้วิธีนี้ต่อไป –สิทธิพิเศษรวมถึงการจำกัดความสามารถของเคอร์เนลและการเรียกใช้กระบวนการด้วยผู้ใช้ที่ไม่มีสิทธิ์พิเศษ ทั้งภายในและภายนอกคอนเทนเนอร์ (เนมสเปซของผู้ใช้, การเข้าถึงแบบไร้สิทธิ์รูท เป็นต้น)

การกำหนดค่าเครือข่ายที่ไม่ปลอดภัย

เครือข่ายเป็นอีกหนึ่งด้านที่มักเกิดปัญหาขึ้นกับ Docker และ Kubernetes: พอร์ตต่างๆ ได้รับการเผยแพร่อย่างมีความสุข การใช้งาน –เครือข่าย=โฮสต์ โดยไม่จำเป็น ไม่มีนโยบายเครือข่ายในคลัสเตอร์ หรือคอนเทนเนอร์สื่อสารกันโดยไม่มีข้อจำกัด

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

Daemon Docker ถูกเปิดเผยหรือมีการป้องกันที่ไม่ดี

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

การปกป้องซ็อกเก็ตของดีมอนและ API ของมันมีความสำคัญอย่างยิ่งการใช้ TLS การจำกัดการเข้าถึงซ็อกเก็ต Unix การไม่เปิดเผยเอนด์พอยต์ TCP เว้นแต่จำเป็นอย่างยิ่ง และการตรวจสอบการกำหนดค่าอย่างสม่ำเสมอ เป็นมาตรการพื้นฐานเพื่อหลีกเลี่ยงการสูญเสียการควบคุมแพลตฟอร์ม

ความลับและตัวแปรด้านสิ่งแวดล้อมถูกเปิดเผย

ข้อผิดพลาดคลาสสิกอย่างหนึ่งในสภาพแวดล้อมคอนเทนเนอร์คือ การทิ้งข้อมูลประจำตัวและคีย์ API ไว้ในที่ที่ไม่ควรอยู่: ฝังอยู่ในไฟล์ Dockerfile ภายในอิมเมจเอง ในตัวแปรสภาพแวดล้อม หรือแม้กระทั่งอัปโหลดไปยังระบบควบคุมเวอร์ชันโดยไม่ได้ตั้งใจ

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

ช่องโหว่ของเคอร์เนลและโฮสต์

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

นอกเหนือจากเคอร์เนลแล้ว ยังรวมถึงการกำหนดค่าระบบปฏิบัติการโฮสต์เองด้วย (cgroups, namespaces, โมดูลที่โหลด, บริการที่ไม่จำเป็น) ส่งผลโดยตรงต่อความเสี่ยง โฮสต์ที่ถูกละเลยจะทำให้การแยกเชิงตรรกะของคอนเทนเนอร์ไร้ความหมาย

ขาดการมองเห็นและการตรวจสอบ

หากไม่มีระบบบันทึกข้อมูลที่ดีและการตรวจสอบแบบเรียลไทม์ การโจมตีอาจยังคงดำเนินต่อไปได้นานหลายสัปดาห์ โดยที่ไม่มีใครสังเกตเห็น เครื่องมือรักษาความปลอดภัยแบบดั้งเดิม (ตัวอย่างเช่น วาซูห์ คืออะไร?) บ่อยครั้งที่พวกเขาไม่เห็นสิ่งที่เกิดขึ้นภายในคอนเทนเนอร์ หรือไม่เชื่อมโยงสิ่งเหล่านั้นเข้ากับบริบทของ Kubernetes

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

แนวทางปฏิบัติที่ดีที่สุดก่อนการใช้งานคอนเทนเนอร์ Docker

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

เพิ่มความปลอดภัยให้กับระบบโฮสต์

ขั้นตอนแรกคือต้องมีระบบปฏิบัติการโฮสต์ที่สะอาดและทันสมัย ​​ซึ่งออกแบบมาโดยเฉพาะสำหรับคอนเทนเนอร์ (ดู คู่มือการติดตั้งและจัดการเซิร์ฟเวอร์ Ubuntuยิ่งคุณใช้โหนดร่วมกับแอปพลิเคชัน "รุ่นเก่า" น้อยลงเท่าไหร่ โอกาสที่ความล้มเหลวของบริการอื่นจะส่งผลกระทบต่อเวิร์กโหลดแบบคอนเทนเนอร์ของคุณก็จะยิ่งน้อยลงเท่านั้น

อัปเดตเคอร์เนลอย่างรวดเร็วและเลือกใช้เวอร์ชัน LTS ที่มีการสนับสนุนอย่างต่อเนื่อง วิธีนี้ช่วยลดความเสี่ยงที่ช่องโหว่ที่รู้จักจะถูกนำมาใช้เพื่อหลีกเลี่ยงการแยกการทำงานได้อย่างมาก นอกจากนี้ การเปิดใช้งานและการกำหนดค่ากลไกต่างๆ เช่น AppArmor, SELinux และ cgroups อย่างถูกต้อง จะช่วยจำกัดสิ่งที่กระบวนการที่ถูกบุกรุกสามารถทำได้

เลือกภาพที่เป็นทางการและเรียบง่าย

การใช้ภาพที่เป็นทางการและได้รับการตรวจสอบแล้วเป็นพื้นฐานควรเป็นมาตรฐานแหล่งเก็บอิมเมจอย่าง Docker Hub จะระบุผู้เผยแพร่ที่ได้รับการตรวจสอบแล้ว และหลายบริษัทก็ดูแลรักษารีจิสทรีส่วนตัวที่มีอิมเมจที่ได้รับการรักษาความปลอดภัยอย่างดี ซึ่งอยู่ภายใต้การสแกนและการตรวจสอบอย่างต่อเนื่อง

เมื่อใดก็ตามที่เป็นไปได้ ควรเลือกใช้ภาพดิสก์แบบ "slim", Alpine หรือแม้แต่แบบไม่มี distroโดยรวมเฉพาะส่วนประกอบที่จำเป็นอย่างยิ่งเท่านั้น การลดจำนวนแพ็กเกจผู้ใช้และเครื่องมือแบบโต้ตอบจะช่วยลดจำนวนช่องโหว่ที่อาจเกิดขึ้น เร่งการติดตั้งใช้งาน และทำให้ผู้โจมตีสามารถเรียกใช้โค้ดภายในคอนเทนเนอร์ได้ยากขึ้นมาก

สร้าง Dockerfile โดยคำนึงถึงความปลอดภัย

ไฟล์ Dockerfile คือสคริปต์สำหรับทุกสิ่งที่จะอยู่ภายในคอนเทนเนอร์ของคุณดังนั้น จึงควรเขียนโปรแกรมโดยคำนึงถึงความปลอดภัยเป็นหลัก: กำจัดเครื่องมือดีบักในเวอร์ชันใช้งานจริง ไม่ทิ้งร่องรอยข้อมูลประจำตัวใดๆ กำหนดเวอร์ชันแพ็กเกจที่เฉพาะเจาะจง ล้างแคชของตัวจัดการแพ็กเกจ และแยกขั้นตอนการคอมไพล์และการดำเนินการออกเป็นหลายชั้น (การสร้างแบบหลายขั้นตอน)

อีกขั้นตอนสำคัญคือการกำหนดผู้ใช้ที่ไม่ได้รับสิทธิ์พิเศษภายในไฟล์ Dockerfile และเปลี่ยนบริบทการดำเนินการด้วยคำสั่ง USERอย่าเรียกใช้บริการต่างๆ ในฐานะผู้ใช้ root ภายในคอนเทนเนอร์ "เพราะมันง่ายกว่า" เพราะเมื่อใดก็ตามที่มีช่องโหว่ด้านความปลอดภัย ความสะดวกสบายนั้นจะกลายเป็นปัญหาใหญ่

การสแกนภาพอย่างเป็นระบบ

การตรวจสอบภาพเพื่อหาช่องโหว่ที่ทราบแล้วก่อนที่จะนำไปรวมไว้ในฐานข้อมูล ควรเป็นข้อบังคับเครื่องมือต่างๆ เช่น Trivy, Clair, Anchore, Snyk Container หรือความสามารถของ Docker Scout ช่วยให้คุณสามารถวิเคราะห์ได้ทั้งอิมเมจพื้นฐานและบิลด์ที่คุณสร้างขึ้นเอง

ผสานรวมสแกนเนอร์เหล่านี้เข้ากับกระบวนการ CI/CD ป้องกันไม่ให้ภาพที่มีช่องโหว่ CVE ร้ายแรงถูกนำไปใช้งานจริง "เพราะเราลืมตรวจสอบ" โดยควรมีการกำหนดนโยบายที่ชัดเจน เช่น บล็อกการใช้งานหากมีช่องโหว่ที่มีความรุนแรงสูงหรือวิกฤตโดยไม่มีแพทช์แก้ไขหรือไม่มีเหตุผลที่ชัดเจน

การจัดการข้อมูลลับและการกำหนดค่าอย่างปลอดภัย

การจัดการความลับเป็นจุดอ่อนสำคัญอย่างหนึ่งของระบบคอนเทนเนอร์การมีภาพที่สมบูรณ์แบบคงไม่มีประโยชน์อะไรหากภาพนั้นมีรหัสผ่านและกุญแจซ่อนอยู่ในรูปแบบข้อความธรรมดา

กฎทองคำคือ ความลับไม่ควรเป็นส่วนหนึ่งของภาพอย่าเขียนข้อมูลรับรองลงใน Dockerfile หรือคัดลอกข้อมูลรับรองเหล่านั้นเป็นไฟล์เข้าไปในคอนเทนเนอร์ แต่ให้ใช้วิธีการแทรกข้อมูลรับรองในขณะรันไทม์แทน เช่น Docker Secrets (ใน Swarm), ตัวจัดการภายนอกอย่าง HashiCorp Vault, AWS Secrets Manager, Azure Key Vault หรือบริการอื่นๆ ที่เทียบเท่ากัน

หากมีการใช้ตัวแปรสภาพแวดล้อม จะต้องจัดการด้วยความระมัดระวังเป็นอย่างยิ่งหลีกเลี่ยงการบันทึกข้อมูลเหล่านั้น อย่าอัปโหลดไฟล์ที่มีค่าจริงไปยังที่เก็บโค้ด ตรวจสอบว่าคำสั่งวินิจฉัยใดบ้างที่อาจแสดงค่าที่ละเอียดอ่อน และเปลี่ยนคีย์บ่อยๆ การเข้ารหัสข้อมูลลับขณะจัดเก็บและการใช้การควบคุมการเข้าถึงอย่างเข้มงวด (ใครสามารถอ่านอะไรได้บ้าง) จะช่วยปิดช่องโหว่ได้หลายช่อง

เครือข่าย การควบคุมการเข้าถึง และการบังคับใช้ที่เข้มงวดมากขึ้น

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

การออกแบบและการแบ่งส่วนเครือข่าย

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

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

การควบคุมการเข้าถึง การตรวจสอบสิทธิ์ และการลงนามภาพ

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

กลไกการสร้างความน่าเชื่อถือด้านเนื้อหาและการลงนามอิมเมจของ Docker ระบบเหล่านี้รับประกันว่าจะใช้เฉพาะอิมเมจที่ลงนามโดยหน่วยงานที่เชื่อถือได้เท่านั้น ในขณะเดียวกัน RBAC ทั้งใน Kubernetes และในแพลตฟอร์ม CI/CD เอง ก็ควบคุมว่าใครสามารถเริ่มต้น ปรับขนาด แก้ไข หรือลบคอนเทนเนอร์และทรัพยากรที่เกี่ยวข้องได้

เรียกใช้คอนเทนเนอร์ด้วยสิทธิ์ที่ต่ำที่สุดเท่าที่จะเป็นไปได้

ห้ามใช้คอนเทนเนอร์ที่มีพารามิเตอร์ –privileged “เพราะมิเช่นนั้นมันจะใช้งานไม่ได้”ธงดังกล่าวให้สิทธิ์การเข้าถึงโฮสต์โดยสมบูรณ์และลบมาตรการแยกส่วนหลายอย่างออกไป วิธีปฏิบัติที่ถูกต้องคือการเริ่มต้นบริการด้วย –cap-drop=ทั้งหมด จากนั้นค่อยๆ เพิ่มเฉพาะความสามารถของเคอร์เนลที่แอปพลิเคชันต้องการ (ตัวอย่างเช่น NET_BIND_SERVICE (สำหรับการฟังในพอร์ตเสียงต่ำ)

สิ่งสำคัญอีกประการหนึ่งคือควรใช้ระบบไฟล์แบบอ่านอย่างเดียวทุกครั้งที่เป็นไปได้ (-อ่านอย่างเดียวและทำการเมานต์วอลุ่มเฉพาะสำหรับข้อมูลที่จำเป็นต้องคงอยู่ วิธีนี้จะทำให้ผู้โจมตีเขียนไบนารีที่เป็นอันตรายหรือแก้ไขการตั้งค่าภายในคอนเทนเนอร์ได้ยากขึ้น การจำกัดการสร้างกระบวนการใหม่และการปิดใช้งานการยกระดับสิทธิ์จะช่วยให้การรักษาความปลอดภัยมีความปลอดภัยยิ่งขึ้น

โปรไฟล์ความปลอดภัยของเคอร์เนล: seccomp, AppArmor และ SELinux

Docker มีโปรไฟล์ seccomp เริ่มต้นอยู่แล้ว ซึ่งจะกรองการเรียกใช้ระบบที่ถือว่าอันตรายอย่างไรก็ตาม ในหลายกรณี แนะนำให้ปรับแต่งหรือสร้างโปรไฟล์เฉพาะสำหรับแต่ละประเภทของภาระงาน ยิ่งกระบวนการเปิดเผยการเรียกใช้ระบบน้อยลงเท่าใด โอกาสที่ผู้โจมตีจะใช้ประโยชน์ก็จะยิ่งน้อยลงเท่านั้น

ในระบบปฏิบัติการอย่าง Ubuntu และ RHEL นั้น AppArmor และ SELinux ถูกนำมาใช้ กลไกเหล่านี้เพิ่มการควบคุมอีกชั้นหนึ่งเกี่ยวกับสิ่งที่แต่ละคอนเทนเนอร์สามารถทำได้ เช่น การเข้าถึงไฟล์ อุปกรณ์ เครือข่าย เป็นต้น หากกำหนดค่าอย่างถูกต้อง กลไกการควบคุมการเข้าถึงแบบบังคับ (Mandatory Access Control) จะทำให้การโจมตีทำได้ยากขึ้นมาก แม้ว่าจะใช้ประโยชน์จากช่องโหว่ในแอปพลิเคชันก็ตาม

โควตาทรัพยากรและการป้องกันการละเมิด

กำหนดค่า CPU, หน่วยความจำ และ (ถ้ามี) ขีดจำกัด I/O สำหรับแต่ละคอนเทนเนอร์ นอกจากจะช่วยเพิ่มประสิทธิภาพของคลัสเตอร์แล้ว ยังช่วยจำกัดผลกระทบจากการโจมตีที่พยายามใช้ทรัพยากรจนหมด (DoS จากภายใน) หรือบั๊กที่ทำให้เกิดการรั่วไหลของหน่วยความจำอีกด้วย

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

การเฝ้าระวัง การตอบสนองต่อเหตุการณ์ และเครื่องมือเฉพาะทาง

การปิดฉากเรื่องความปลอดภัยของตู้คอนเทนเนอร์โดยไม่พูดถึงการตรวจสอบติดตามถือเป็นความผิดพลาดความเป็นจริงก็คือ ไม่ช้าก็เร็วจะต้องมีช่องโหว่ใหม่ๆ ความผิดพลาดของมนุษย์ หรือพฤติกรรมที่ไม่คาดคิดเกิดขึ้น ความแตกต่างอยู่ที่ว่าคุณใช้เวลานานแค่ไหนในการตรวจจับสิ่งเหล่านั้น และคุณจะตอบสนองต่อมันอย่างไร

รวมศูนย์บันทึกข้อมูลคอนเทนเนอร์ โฮสต์ การจัดการระบบ และรีจิสทรี มันช่วยให้คุณเชื่อมโยงเหตุการณ์ต่างๆ และมองเห็นรูปแบบที่อาจมองข้ามไปหากพิจารณาแต่ละส่วนแยกกัน โซลูชันอย่าง ELK, Grafana Loki หรือบริการคลาวด์แบบจัดการ มักใช้เพื่อจุดประสงค์นี้

ในด้านการตรวจจับภัยคุกคามขณะรันไทม์ Falco ได้กลายเป็นมาตรฐานโอเพนซอร์สที่เป็นที่ยอมรับโดยทั่วไประบบนี้จะตรวจสอบการเรียกใช้ระบบและสร้างการแจ้งเตือนเมื่อตรวจพบกิจกรรมที่น่าสงสัย เช่น เชลล์แบบโต้ตอบในคอนเทนเนอร์ที่ไม่ควรมี การเขียนไปยังเส้นทางที่ละเอียดอ่อน การเชื่อมต่อเครือข่ายที่ผิดปกติ เป็นต้น เมื่อผสานรวมกับเครื่องมือ SIEM หรือแพลตฟอร์มการตอบสนอง จะช่วยให้สามารถตอบสนองได้อย่างรวดเร็ว

เพื่อการครอบคลุมที่ครอบคลุมและครบวงจรมากขึ้น มีแพลตฟอร์มความปลอดภัยที่ทำงานบนระบบคลาวด์ให้เลือกใช้ เช่น Aqua Security, Prisma Cloud, Sysdig Secure, Qualys Container Security หรือชุดซอฟต์แวร์แบบครบวงจรที่เน้นนักพัฒนาอย่าง Aikido Security โซลูชันเหล่านี้รวมการสแกนภาพ การรักษาความปลอดภัยขณะทำงาน การจัดการสถานะระบบคลาวด์ การวิเคราะห์โค้ด การตรวจจับความลับ การสร้าง SBOM และอื่นๆ อีกมากมาย

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

การทำให้ระบบรักษาความปลอดภัยเป็นไปโดยอัตโนมัติในกระบวนการ CI/CD

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

ตามหลักการแล้ว การเปลี่ยนแปลงโค้ดแต่ละครั้งควรทำให้เกิดการเปลี่ยนแปลงต่อเนื่องโดยอัตโนมัติการสร้างอิมเมจ การสแกนช่องโหว่ การวิเคราะห์การพึ่งพา การตรวจสอบไฟล์โครงสร้างพื้นฐานในรูปแบบโค้ด การตรวจสอบนโยบาย (เช่น ตรวจสอบว่าไม่มีคอนเทนเนอร์ใดทำงานในฐานะผู้ใช้ root) และหากทุกอย่างผ่านการตรวจสอบแล้ว จึงค่อยพุชไปยังรีจิสทรีและทำการปรับใช้

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

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

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