การรักษาความปลอดภัยของระบบ Cloud ที่คุณไม่ได้สร้าง

คุณเพิ่งได้รับกุญแจเข้าชุดบัญชี cloud ที่เติบโตขึ้นโดยไม่มีการดูแลมาสามปี ไม่มีใครทิ้งเอกสาร IAM มี 40 บทบาทที่มีสิทธิ์ wildcard S3 buckets ที่ไม่มีใครจำได้ว่าสร้าง และบุคคลคนสุดท้ายที่เข้าใจ network topology ออกจากบริษัทในปี 2022 สถานการณ์นี้พบได้บ่อยกว่าที่บัญชีงานส่วนใหญ่ยอมรับ และเดือนแรกสร้างนำหน้าสำหรับทุกอย่างที่ตามมา

รวบรวมสินค้าคงคลังก่อนสัมผัสอะไร

หลีกเลี่ยงแรงกระตุ้นที่จะเริ่มล็อคสิ่งต่างๆ ลงทันที คุณต้องการแผนที่ก่อน เรียกใช้ aws resourcegroupstaggingapi get-resources ในทุกภูมิภาค ไม่ใช่เพียง us-east-1 — ทีมชอบสร้างทรัพยากรทดสอบใน ap-southeast-2 และลืมมันไป จับคู่กับ AWS Config ถ้ามันเปิดใช้งานอยู่แล้ว หรือเปิดใช้ตอนนี้ถ้ายังไม่ได้ บน Azure az resource list --output table piped เข้าสเปรดชีตใช้ได้สำหรับการทำขั้นแรก บน GCP Cloud Asset Inventory gcloud asset search-all-resources ให้มุมมองเดียวกัน

อ้างอิง cross-reference กับการเรียกเก็บเงิน อะไรที่มีค่าใช้จ่ายควรปรากฏในสินค้าคงคลังทรัพยากรของคุณ อะไรในสินค้าคงคลังที่มีกิจกรรมล่าสุดเป็นศูนย์เป็นผู้สมัครสำหรับการเก็บถาวร ความแตกต่างที่นี่คือมักจะซ่อนสิ่งที่น่ากลัว — EC2 instances ที่เปลี่ยนสูญเสียกับ public IPs RDS snapshots ที่ถูกลืมนั่งไม่เข้ารหัส load balancers ชี้ไปที่ไม่มีอะไร

ตรวจสอบ IAM เหมือนเป็นที่เกิดเหตุ

ดึง IAM policy ทุกอันและมองหา "Action": "*" รวมกับ "Resource": "*" การรวมกันนี้ไม่ควรมีอยู่นอกจากหมวดหมู่ขนาดเล็กของบทบาท admin break-glass และแม้แต่สิ่งเหล่านั้นควรมี MFA enforcement และ CloudTrail alerting ที่แนบมา ใช้ IAM Access Analyzer เพื่อค้นหาบทบาทที่ให้สิทธิ์เข้าถึงบัญชีภายนอก — นี่จะจับทั้งความสัมพันธ์การไว้วางใจข้ามบัญชีที่มีจริงและข้อผิดพลาดจากใครบางคนทดสอบโมดูล Terraform กับ account ID ที่ผิด

ตรวจสอบ access keys เก่ากว่า 90 วันด้วย aws iam generate-credential-report สถานสมบัติที่สืบทอดมาเกือบทั้งหมดมี long-lived keys ที่แนบมากับบัญชีบริการ บางครั้ง hardcoded ในตัวแปรสภาพแวดล้อม Lambda หรืองาน Jenkins หมุนเวียนพวกมัน แต่จัดบ้าน — ฆ่าคีย์ที่งาน batch คืนค่ะ ขึ้นอยู่กับเวลา 2 AM คือวิธีที่คุณได้รับเพจระหว่างสัปดาห์แรกของคุณ

ค้นหาการเปิดเผยสาธารณะก่อนที่ผู้โจมตีจะทำ

เรียกใช้การตรวจสอบความสามารถในการเข้าถึงเครือข่ายข้าม VPCs ของคุณ Security groups ที่มี 0.0.0.0/0 บนสิ่งใดอื่นนอกจาก 80/443 ต้องการการพิสูจน์ไม่ใช่สมมติฐาน เครื่องมือเช่น ScoutSuite หรือ Prowler จะเคี้ยวผ่านบัญชีในไม่กี่นาทีและพ่นรายงานจัดลำดับตามความร้ายแรง — เริ่มต้นที่นั่นแทนการสร้างเช็คลิสต์ของคุณเองจากศูนย์

S3 buckets สมควรได้รับความสนใจพิเศษเพราะพวกเขาเป็น landmine สถานสมบัติที่สืบทอดมาแบบคลาสสิก ตรวจสอบทั้งนโยบาย bucket และการตั้งค่า Block Public Access ระดับบัญชี คนบางคนอาจปิดใช้งานค่าเริ่มต้นบัญชีหลายปีมาแล้วสำหรับเว็บไซต์คงที่แบบครั้งเดียวและไม่เปิดใช้งานกลับมา aws s3api list-buckets รวมกับลูปตรวจสอบ get-bucket-acl และ get-bucket-policy-status ในแต่ละอันให้คุณภาพนั้นสะอาดในเวลาต่ำกว่า 10 นาทีสำหรับบัญชีส่วนใหญ่

สร้างการบันทึกก่อนสร้างความเชื่อ

ถ้า CloudTrail VPC Flow Logs หรือ GuardDuty ไม่ได้เรียกใช้อยู่แล้วทุกที่ เปิดใช้ตอนนี้ ก่อนที่คุณจะทำการเปลี่ยนแปลงอื่น ๆ คุณต้องการบันทึกสิ่งที่เกิดขึ้นจากจุดนี้ไปข้างหน้า และคุณต้องการมันก่อนที่คุณเริ่มลบสิ่งต่างๆ เพราะการลบคือสถานที่ที่ข้อผิดพลาดเกิดขึ้นและความผิดถูกโยนให้คนใหม่ ส่งบันทึกไปยังบัญชีหรือสมาชิกแยกต่างหากถ้าทำได้เลย เพื่อให้ workload ที่ถูกจากรรมการไม่สามารถลบหลักฐานของมันเองได้เช่นกัน

ตั้งค่า GuardDuty หรือ Azure Defender for Cloud ด้วยการแจ้งเตือนที่ส่งไปยังที่ที่บุคคลตรวจสอบจริง ๆ — ไม่ใช่ช่อง Slack ที่มี 400 ข้อความที่ยังไม่อ่าน มูลค่าของเครื่องมือตรวจจับใกล้ศูนย์ถ้าการแจ้งเตือนลงจอดในเป็นศูนย์

แก้ไขปัญหาที่ดังที่สุดก่อน เอกสารทุกอย่าง

คุณจะไม่แก้ไขสถานสมบัติที่สืบทอดมาในสปรินต์ triage ด้วย blast radius: ข้อมูลสาธารณะเปิดเผยก่อน จากนั้นตัวตนที่มีสิทธิ์มากเกินไป จากนั้นการแบ่งส่วนเครือข่าย จากนั้นทุกอย่างอื่น เขียนลงในสิ่งที่คุณพบและสิ่งที่คุณเปลี่ยน แม้ในเอกสาร Google ธรรมดา เพราะคนคนต่อไปที่สืบทอดนี้จากคุณสมควรได้ดีกว่าสิ่งที่คุณได้รับ

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเครื่องมือและเหตุผลเบื้องหลังการตรวจสอบ cloud ให้ดู Korra Studio ของส่วนบน IAM hardening และ cloud detection engineering — ทั้งคู่จับคู่ได้ดีกับ workflow ด้านบน