---
title: "รายการตรวจสอบการเสริมความแข็งแกร่งด้านความปลอดภัยของ GCP | Snow Tree"
url: "https://www.snow-tree.com/th/gcp-security-hardening/"
---

โครงสร้างพื้นฐาน GCP ที่ปลอดภัย

# รายการตรวจสอบการเสริมความแข็งแกร่งด้านความปลอดภัยของ GCP สำหรับทีมขนาดเล็กและขนาดกลาง

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

## ในหน้านี้

1. [เส้นทางภัยคุกคามที่พบบ่อยใน GCP](https://www.snow-tree.com/th/#threat-paths)
2. [ข้อมูลระบุตัวตนและการเข้าถึง](https://www.snow-tree.com/th/#identity)
3. [เครือข่ายและขอบเครือข่าย](https://www.snow-tree.com/th/#network)
4. [ข้อมูลและความลับ](https://www.snow-tree.com/th/#data)
5. [การเสริมความแข็งแกร่งของ GKE](https://www.snow-tree.com/th/#gke)
6. [การตรวจจับและการกู้คืน](https://www.snow-tree.com/th/#detection)
7. [รายการตรวจสอบตามลำดับความสำคัญสำหรับ 30, 60 และ 90 วัน](https://www.snow-tree.com/th/#checklist)
8. [ข้อมูลอ้างอิงอย่างเป็นทางการ](https://www.snow-tree.com/th/#references)

## เส้นทางภัยคุกคามที่พบบ่อยใน 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 สามารถวางพื้นฐานนี้ให้ได้ผ่านการดำเนินงานแพลตฟอร์มที่มีการจัดการ หรืองานที่ปรึกษาที่มุ่งเน้นเฉพาะเรื่อง

[แพลตฟอร์มที่มีการจัดการ](https://www.snow-tree.com/th/managed-platform/) [ที่ปรึกษา](https://www.snow-tree.com/th/consulting/)

## ข้อมูลอ้างอิงอย่างเป็นทางการ

ใช้คำแนะนำล่าสุดของ Google เป็นแหล่งอ้างอิงทางเทคนิคหลักเมื่อค่าเริ่มต้นของแพลตฟอร์มหรือความสามารถของผลิตภัณฑ์เปลี่ยนแปลง

- [Google Cloud: แนวทางปฏิบัติที่ดีที่สุดในการเสริมความแข็งแกร่งให้คลัสเตอร์ GKE ของคุณ](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [Google Cloud: แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของ GKE](https://docs.cloud.google.com/docs/security/gke-security-bps)

แพลตฟอร์มที่มีการจัดการ

## ให้ Snow Tree สร้าง โฮสต์ และดำเนินงานซอฟต์แวร์

[เริ่มโครงการ](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)