โครงสร้างพื้นฐาน GCP ที่ปลอดภัย
รายการตรวจสอบการเสริมความแข็งแกร่งด้านความปลอดภัยของ GCP สำหรับทีมขนาดเล็กและขนาดกลาง
แนวทางพื้นฐานที่ใช้งานได้จริงสำหรับทีมที่รันเวิร์กโหลดโปรดักชันบน Google Cloud โดยไม่มีแผนกความปลอดภัยโดยเฉพาะ เริ่มจากจุดที่เส้นทางซึ่งมีแนวโน้มนำไปสู่เหตุการณ์ร้ายแรงมากที่สุดนั้นลดได้ง่ายที่สุด
เส้นทางภัยคุกคามที่พบบ่อยใน GCP
เหตุการณ์บนคลาวด์ส่วนใหญ่เริ่มจากช่องว่างเล็กๆ ด้านความเป็นเจ้าของหรือการกำหนดค่า ตรวจหาเส้นทางเหล่านี้ก่อนที่ผู้โจมตีจะพบ
- ผู้ใช้ บัญชีบริการ หรือข้อมูลระบุตัวตนของเวิร์กโหลดที่มีสิทธิ์มากเกินไป อาจทำให้ข้อมูลเข้าสู่ระบบที่ถูกขโมยเพียงชุดเดียวกลายเป็นการเข้าถึงในวงกว้างข้ามโปรเจกต์
- ปลายทางการจัดการที่เปิดเผยสู่ภายนอก พอร์ตดีบัก หรือกฎไฟร์วอลล์ที่อนุญาตกว้างเกินไป อาจข้ามผ่านการควบคุมทุกอย่างที่ออกแบบไว้สำหรับการรับส่งข้อมูลปกติของแอปพลิเคชัน
- บัคเก็ตพื้นที่เก็บข้อมูลที่เป็นสาธารณะหรือ URL ที่ลงนามซึ่งให้สิทธิ์กว้างเกินไป อาจเปิดเผยข้อมูลลูกค้าได้โดยไม่มีร่องรอยให้เห็นว่าแอปพลิเคชันถูกเจาะระบบ
- เวิร์กโหลดที่ค้างเก่าสร้างความเสี่ยงระยะยาวเมื่ออิมเมจเก่า เนมสเปซที่ถูกลืม บัญชีบริการที่ไม่ได้ใช้ และทรัพยากรที่ไม่มีเจ้าของยังคงนำไปติดตั้งใช้งานได้
- หลักฐานการตรวจสอบที่ขาดหายหรือเก็บไว้ในระยะสั้น ทำให้ระบุได้ยากว่าใครเปลี่ยนนโยบาย การเข้าถึงเริ่มขึ้นเมื่อใด และมีการเข้าถึงข้อมูลใดไปบ้าง
- การสำรองข้อมูลที่ยังไม่ผ่านการทดสอบเป็นเพียงความหวัง การกู้คืนที่ล้มเหลว การเก็บรักษาที่ไม่ครบถ้วน และคีย์การเข้ารหัสที่เข้าถึงไม่ได้ อาจเปลี่ยนเหตุการณ์ด้านความปลอดภัยให้กลายเป็นการสูญเสียถาวร
ข้อมูลระบุตัวตนและการเข้าถึง
ให้ถือว่าข้อมูลระบุตัวตนเป็นระนาบควบคุมหลัก มนุษย์ กระบวนการอัตโนมัติ และเวิร์กโหลดทุกรายการควรมีข้อมูลระบุตัวตนแยกเฉพาะที่มีวัตถุประสงค์จำกัดชัดเจน
ทำให้ขอบเขตทรัพยากรชัดเจน
ใช้องค์กรและโฟลเดอร์เป็นราวกั้น และแยกสภาพแวดล้อมการพัฒนา สเตจจิง และโปรดักชันออกเป็นโปรเจกต์หรือขอบเขตความน่าเชื่อถือที่เข้มแข็งกว่า ใช้นโยบายองค์กรในระดับสูงสุดที่ทำได้จริง จำกัดการใช้บริการ และหลีกเลี่ยงการใช้โปรเจกต์โปรดักชันร่วมกันระหว่างผลิตภัณฑ์ที่ไม่เกี่ยวข้องกัน
มอบบทบาทขั้นต่ำในขอบเขตที่แคบที่สุด
เลือกใช้บทบาทที่กำหนดไว้ล่วงหน้าหรือบทบาทที่กำหนดเองแทนบทบาทพื้นฐานที่กว้าง มอบบทบาทให้กลุ่มและข้อมูลระบุตัวตนของเวิร์กโหลด และใช้เงื่อนไข IAM ในกรณีที่ชื่อทรัพยากรหรือแท็กช่วยจำกัดการเข้าถึงให้แคบลงได้ ตรวจสอบสิทธิ์ที่ไม่ได้ใช้ และยกเลิกสิทธิ์เข้าถึงโปรดักชันแบบถาวรที่ควรมีไว้สำหรับกระบวนการเข้าถึงฉุกเฉิน (break-glass) เท่านั้น
ยกเลิกข้อมูลเข้าสู่ระบบที่มีอายุยาว
ใช้ Workload Identity Federation for GKE เพื่อให้พ็อดได้รับข้อมูลเข้าสู่ระบบอายุสั้นโดยไม่ต้องใช้คีย์บัญชีบริการที่ส่งออกมา บล็อกการสร้างและการอัปโหลดคีย์ด้วยนโยบายองค์กรเมื่อทำได้ จัดทำรายการคีย์ที่ยังเหลืออยู่ทั้งหมด และตั้งการแจ้งเตือนเมื่อมีการเปลี่ยนแปลง IAM ที่มีความเสี่ยงสูงใน Cloud Audit Logs
เครือข่ายและขอบเครือข่าย
สมมติว่าข้อบกพร่องของแอปพลิเคชันบางอย่างจะสามารถเข้าถึงได้จากเครือข่ายในที่สุด จำกัดสิ่งที่ข้อบกพร่องนั้นสามารถเข้าถึงได้
เริ่มต้นด้วยการปฏิเสธและเพิ่มเส้นทางที่มีชื่อ
ใช้กฎไฟร์วอลล์ VPC ตามหลักการให้สิทธิ์น้อยที่สุด และ Kubernetes NetworkPolicies สำหรับการรับส่งข้อมูลของพ็อด แยกสภาพแวดล้อมออกเป็นเครือข่ายที่แยกจากกัน จัดทำเอกสารเส้นทางขาเข้าทุกเส้นทาง และลบกฎดีบักแบบกว้างที่อนุญาตพอร์ตการจัดการหรือทุกโปรโตคอลจากช่วงที่อยู่ขนาดใหญ่
รักษาโหนดและระนาบควบคุมให้เป็นส่วนตัว
ปิดใช้ที่อยู่ IP ภายนอกบนโหนด GKE เลือกใช้ปลายทางระนาบควบคุมแบบส่วนตัวที่ใช้ DNS และเมื่อหลีกเลี่ยงปลายทาง IP ไม่ได้ ให้จำกัดด้วยเครือข่ายที่ได้รับอนุญาต กำหนดเส้นทางขาออกที่ตั้งใจไว้ให้เวิร์กโหลด แทนการเปิดให้เข้าถึงอินเทอร์เน็ตอย่างกว้าง
เผยแพร่เฉพาะบริการสาธารณะที่ตั้งใจเปิดเท่านั้น
เปิดให้เข้าถึงแอปพลิเคชันผ่านเกตเวย์หรือโหลดบาลานเซอร์ที่ผ่านการตรวจสอบแล้ว ไม่ใช่ผ่านที่อยู่ของพ็อดหรือโหนดที่บังเอิญเข้าถึงได้ สิ้นสุดการเชื่อมต่อ TLS ด้วยใบรับรองที่มีการจัดการ จำกัดโฮสต์และเส้นทางขาเข้า กำหนดขีดจำกัดคำขอและอัตรา และเก็บอินเทอร์เฟซการดูแลระบบไว้หลังการควบคุมการเข้าถึงตามข้อมูลระบุตัวตน
ข้อมูลและความลับ
ปกป้องข้อมูลทั้งขณะจัดเก็บ ระหว่างการรับส่ง และขณะใช้งาน จากนั้นพิสูจน์ว่าคุณกู้คืนข้อมูลได้ การค้นหาและจัดทำรายการข้อมูลเป็นส่วนหนึ่งของการควบคุม
ป้องกันการเข้าถึงสาธารณะโดยไม่ได้ตั้งใจ
บังคับใช้การป้องกันการเข้าถึงแบบสาธารณะและการเข้าถึงระดับบัคเก็ตแบบเดียวกันบน Cloud Storage จัดประเภทบัคเก็ตตามระดับความอ่อนไหวของข้อมูล จำกัดการเข้าถึงออบเจ็กต์และคีย์ เปิดใช้การบันทึกสำหรับข้อมูลที่มีมูลค่าสูง และใช้คีย์การเข้ารหัสที่ลูกค้าจัดการในกรณีที่โมเดลความเสี่ยงหรือข้อกำหนดด้านการปฏิบัติตามกฎระเบียบของคุณกำหนดไว้
เก็บความลับไว้นอกอิมเมจและซอร์สโค้ด
จัดเก็บข้อมูลเข้าสู่ระบบไว้ใน Secret Manager และให้สิทธิ์เข้าถึงแก่ข้อมูลระบุตัวตนของเวิร์กโหลดที่เจาะจงและเวอร์ชันของความลับที่เจาะจง หมุนเวียนความลับอย่างมีแผน หลีกเลี่ยงการคัดลอกความลับลงใน Git หรืออิมเมจคอนเทนเนอร์ และอย่าถือว่า Kubernetes Secrets แบบปกติเป็นขอบเขตการป้องกันที่สมบูรณ์
ทดสอบการกู้คืน ไม่ใช่แค่การสร้างการสำรองข้อมูลเท่านั้น
กำหนดเป้าหมายจุดกู้คืน (RPO) และเวลาในการกู้คืน (RTO) เก็บสำเนาไว้นอกโดเมนความล้มเหลวของโปรดักชัน และป้องกันไม่ให้ข้อมูลระบุตัวตนของเวิร์กโหลดเข้าถึงข้อมูลสำรองและคีย์การเข้ารหัสได้ กู้คืนลงในสภาพแวดล้อมที่แยกต่างหากตามกำหนดเวลา ตรวจสอบความถูกต้องของข้อมูล และบันทึกเวลาที่ใช้ไปและขั้นตอนใดๆ ที่ต้องทำด้วยตนเอง
การเสริมความแข็งแกร่งของ GKE
GKE รักษาความปลอดภัยของระนาบควบคุมที่มีการจัดการ แต่การกำหนดค่าคลัสเตอร์ เนมสเปซ นโยบายการรับเข้า และเวิร์กโหลดยังคงเป็นสิ่งที่คุณต้องกำกับดูแลเอง
ใช้เนมสเปซเป็นข้อตกลงด้านการแยกส่วน
แยกทีมและสภาพแวดล้อมออกเป็นเนมสเปซหรือคลัสเตอร์ ผูกบทบาท Kubernetes RBAC ที่มีขอบเขตแคบไว้ในระดับนั้น และใช้โควต้าทรัพยากรและ NetworkPolicies หลีกเลี่ยงการให้สิทธิ์เขียนทั่วทั้งคลัสเตอร์สำหรับการส่งมอบแอปพลิเคชัน และให้แต่ละเวิร์กโหลดมีบัญชีบริการของตัวเองเมื่อต้องการข้อมูลระบุตัวตนแยกเฉพาะ
อนุญาตเฉพาะอิมเมจและการกำหนดค่าที่คุณเชื่อถือเท่านั้น
บังคับใช้มาตรฐาน Pod Security ระดับ Restricted หรือกฎ Policy Controller ที่เทียบเท่า ติดตั้งใช้งานอิมเมจด้วยไดเจสต์ที่เปลี่ยนแปลงไม่ได้ สแกนหาช่องโหว่ ใช้ Binary Authorization เมื่อแหล่งที่มาของอิมเมจมีความสำคัญ และปฏิเสธการเข้าถึงโฮสต์ที่ไม่คาดคิด การยกระดับสิทธิ์ และการผูกบทบาท cluster-admin
ลบสิทธิ์คอนเทนเนอร์ที่ไม่จำเป็นออก
รันในฐานะผู้ใช้ที่ไม่ใช่ root ตัดความสามารถ (capabilities) ของ Linux ออก ใช้ระบบไฟล์ root แบบอ่านอย่างเดียวเมื่อเป็นไปได้ และใช้โปรไฟล์ seccomp แบบ RuntimeDefault อย่าเมานต์โทเค็นบัญชีบริการหากไม่จำเป็น หลีกเลี่ยงโหมด privileged และเนมสเปซของโฮสต์ จำกัดสิทธิ์บัญชีบริการของโหนดให้น้อยที่สุด และใช้ Shielded Nodes ร่วมกับ Container-Optimized OS
การตรวจจับและการกู้คืน
การควบคุมย่อมล้มเหลวได้ ให้พึ่งพาหลักฐานและการดำเนินการที่ซ้อมไว้แล้ว ไม่ใช่ความมั่นใจว่าไม่มีใครทำพลาด
รวบรวมหลักฐานที่คุณจะต้องใช้
เก็บ Cloud Audit Logs รวมถึงบันทึกระบบและบันทึกเวิร์กโหลดของ GKE ไว้ที่ปลายทางส่วนกลาง โดยกำหนดระยะเวลาเก็บรักษาให้ตรงกับความต้องการในการสืบสวนของคุณ เปิดใช้บันทึกการตรวจสอบการเข้าถึงข้อมูลเฉพาะสำหรับข้อมูลที่อ่อนไหว จำกัดการเข้าถึงบันทึก และบันทึกการเปลี่ยนแปลงด้านการดูแลระบบที่มีต่อ IAM ไฟร์วอลล์ พื้นที่เก็บข้อมูล และการกำหนดค่าคลัสเตอร์
แจ้งเตือนการเปลี่ยนแปลงที่มีความหมายด้านความปลอดภัย
แจ้งเตือนเมื่อพื้นที่เก็บข้อมูลถูกเปิดเป็นสาธารณะ การเปลี่ยนแปลงไฟร์วอลล์หรือ IAM แบบกว้าง คีย์บัญชีบริการที่ไม่คาดคิด การปฏิเสธการรับเข้า ระนาบควบคุมที่ถูกเปิดเผย การยืนยันตัวตนที่ล้มเหลวซ้ำๆ การบันทึกที่ถูกปิดใช้ การสำรองข้อมูลที่ล้มเหลว และใบรับรองที่ใกล้หมดอายุ ส่งการแจ้งเตือนแต่ละรายการไปยังผู้รับผิดชอบพร้อมขั้นตอนในการยืนยันหรือปฏิเสธการแจ้งเตือนนั้น
ซ้อมการตอบสนอง
เขียนรันบุ๊กสั้นๆ สำหรับกรณีข้อมูลเข้าสู่ระบบรั่วไหล ข้อมูลถูกเปิดเป็นสาธารณะ เวิร์กโหลดถูกเจาะระบบ และการสูญเสียรีเจียนหรือโปรเจกต์ ระบุว่าใครมีอำนาจอนุมัติการควบคุมความเสียหาย วิธีเพิกถอนการเข้าถึง วิธีเก็บรักษาหลักฐาน และวิธีกู้คืนบริการ ทดสอบรันบุ๊กร่วมกับผู้ที่จะใช้งานจริง
รายการตรวจสอบตามลำดับความสำคัญสำหรับ 30, 60 และ 90 วัน
หากคุณเริ่มต้นจากพื้นฐานที่ไม่สมบูรณ์ ให้จัดลำดับงานเพื่อลดการเปิดเผยก่อน และทำให้การทบทวนในภายหลังทำซ้ำได้
วันที่ 1 ถึง 30: หยุดเส้นทางที่ชัดเจน
จัดทำรายการโปรเจกต์และเจ้าของ ยกเลิกข้อมูลเข้าสู่ระบบที่ไม่ได้ใช้และที่มีอายุยาว ยืนยันว่าเปิดการบันทึกการตรวจสอบแล้ว บล็อกบัคเก็ตสาธารณะ ตรวจสอบกฎไฟร์วอลล์และสิทธิ์ IAM ที่กว้างที่สุด ระบุช่องว่างด้านการสำรองข้อมูลของโปรดักชัน และแก้ไขปลายทางสาธารณะที่ไม่มีเจ้าของ กำหนดผู้รับผิดชอบและวันครบกำหนดให้กับทุกข้อค้นพบ
วันที่ 31 ถึง 60: ทำให้พื้นฐานทำซ้ำได้
ย้ายการกำหนดค่าเครือข่าย ข้อมูลระบุตัวตน และเวิร์กโหลดไปเป็นโครงสร้างพื้นฐานในรูปแบบโค้ดที่ผ่านการรีวิว และการส่งมอบด้วย GitOps นำ Workload Identity โหนดส่วนตัว Pod Security ระดับ Restricted การตรวจสอบอิมเมจที่เชื่อถือได้ บันทึกแบบรวมศูนย์ และการแจ้งเตือนสำหรับการเปลี่ยนแปลงที่สำคัญที่สุดมาใช้
วันที่ 61 ถึง 90: พิสูจน์และดำรงไว้
ทดสอบการกู้คืนและจัดการซ้อมรับมือเหตุการณ์แบบ Tabletop ทบทวนสิทธิ์การเข้าถึงระดับสูงและวันหมดอายุของข้อยกเว้น สแกนอิมเมจและ dependency อีกครั้ง ยืนยันว่าเจ้าของได้รับการแจ้งเตือน และวัดช่องว่างที่ยังเหลืออยู่ นำการตรวจสอบเหล่านี้เข้าสู่รอบการทบทวนที่ทำเป็นประจำก่อนที่หลักฐานจะล้าสมัย
ใช้รายการตรวจสอบนี้เป็นจุดเริ่มต้น Snow Tree สามารถวางพื้นฐานนี้ให้ได้ผ่านการดำเนินงานแพลตฟอร์มที่มีการจัดการ หรืองานที่ปรึกษาที่มุ่งเน้นเฉพาะเรื่อง
ข้อมูลอ้างอิงอย่างเป็นทางการ
ใช้คำแนะนำล่าสุดของ Google เป็นแหล่งอ้างอิงทางเทคนิคหลักเมื่อค่าเริ่มต้นของแพลตฟอร์มหรือความสามารถของผลิตภัณฑ์เปลี่ยนแปลง
แพลตฟอร์มที่มีการจัดการ