You Inherited a Cloud Mess. Where Do You Start?

คุณเพิ่งเข้าไปครอบครองบัญชี cloud (หรือสิบบัญชี) ที่คนอื่นสร้างขึ้นเป็นเวลา 3 ปี โดยไม่มีเอกสาร มีผู้รับเหมาที่เปลี่ยนไปมา และ Slack channel ชื่อ #aws-help ที่ไม่ได้ใช้งานตั้งแต่ปี 2022 นี่คือสถานการณ์ที่พบเห็นได้บ่อยที่สุดในงาน cloud security และจึงรู้สึกไม่สบายใจเพราะคุณรับผิดชอบในสิ่งที่ยังอธิบายไม่ได้

นี่คือวิธีเปลี่ยนจากไม่มีการมองเห็นเลยไปถึงสถานะที่สามารถป้องกันได้ โดยไม่ต้องทำให้เป็นปัญหาขนาดใหญ่

หยุดการคาดเดาและทำสินค้าคงคลังก่อน

คุณไม่สามารถรักษาความปลอดภัยสิ่งที่มองไม่เห็น ก่อนที่จะแก้ไข IAM policy เพียงรายการเดียว ให้ทำการนับรวมครั้งแรก:

• AWS: aws organizations list-accounts เพื่อดูโครงสร้างบัญชีทั้งหมด จากนั้น Steampipe หรือ AWS Config aggregators เพื่อดึงทรัพยากรจากทั้งหลาย account เข้าไปในมุมมองที่สามารถค้นหาได้
• Azure: Resource Graph queries (az graph query) ข้ามชั้น subscription เนื่องจาก Azure's tenant/subscription model อาจซ่อนการขยายตัวได้ง่าย
• GCP: gcloud asset search-all-resources ที่ระดับ organization

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

ค้นหาว่าใครสามารถทำอะไรได้ ก่อนที่จะค้นหาว่าอะไรเสีย

ความผิดพลาดในการตั้งค่าได้รับหัวข้อข่าวสารใจ แต่ identity คือที่ที่สัมผัสที่แท้จริงมักจะอยู่ในสภาพแวดล้อมที่คุณสืบทอดมา ดึง IAM user, role, และ service account ทุกตัวออกมา แล้วถามคำถามสามข้อ: สิ่งนี้ยังต้องมีอยู่หรือไม่, มันมีสิทธิ์ที่ไม่ได้ใช้หรือไม่, และมันเป็นมนุษย์หรือเครื่องจักร

เรียกใช้ AWS IAM Access Analyzer หรือ iam-lint-style tooling เพื่อจดหมายถึงสิทธิ์ที่ไม่ได้ใช้ในช่วง 90 วันที่ผ่านมา ในทางปฏิบัติ บัญชีที่สืบทอดมาเกือบทั้งหมดมี IAM user อย่างน้อยหนึ่งคน ที่มี access keys ระยะยาวที่ควรจะเป็น