Bảo mật Cloud Estate Mà Bạn Không Xây Dựng

Bạn vừa nhận được chìa khóa của một tài khoản cloud đã phát triển suốt ba năm mà không ai quản lý. Không ai để lại tài liệu. IAM có 40 role với wildcard permissions, có các S3 bucket mà không ai nhớ tạo, và người cuối cùng hiểu về network topology đã rời công ty vào năm 2022. Điều này phổ biến hơn hầu hết các bài đăng việc làm thừa nhận, và tháng đầu tiên sẽ định hình mọi thứ sau đó.

Lấy danh sách kho trước khi bạn chạm vào bất cứ điều gì

Không vội vàng bắt đầu khóa chặt ngay lập tức. Bạn cần một bản đồ trước. Chạy aws resourcegroupstaggingapi get-resources trên mọi region, không chỉ us-east-1 — các team thích tạo test resources ở ap-southeast-2 rồi quên mất. Kết hợp điều đó với AWS Config nếu nó đã được bật, hoặc bật ngay bây giờ nếu chưa. Trên Azure, az resource list --output table pipe vào một spreadsheet hoạt động tốt cho một đánh giá ban đầu. Trên GCP, Cloud Asset Inventory's gcloud asset search-all-resources cung cấp cho bạn cùng một view.

So sánh chéo với billing. Bất cứ điều gì tốn tiền đều phải xuất hiện trong danh sách tài nguyên của bạn; bất cứ điều gì trong danh sách với hoạt động gần đây là không có sẵn là ứng cử viên cho lưu trữ. Sự không khớp ở đây thường là nơi những thứ đáng sợ ẩn nấp — các EC2 instances bị bỏ rơi với public IP, RDS snapshots bị quên không được mã hóa, load balancers chỉ vào không có gì.

Kiểm toán IAM như nó là một hiện trường tội phạm

Kéo mọi IAM policy và tìm "Action": "*" kết hợp với "Resource": "*". Sự kết hợp đó không nên tồn tại ngoài một số ít break-glass admin role, và ngay cả những cái đó cũng phải có MFA enforcement và CloudTrail alerting được gắn kèm. Sử dụng IAM Access Analyzer để tìm các role cấp access cho external account — điều này bắt cả cross-account trust relationship có ý định và các lỗi từ ai đó kiểm tra Terraform module với account ID sai.

Kiểm tra access key cũ hơn 90 ngày với aws iam generate-credential-report. Các inherited estate hầu như luôn có các key dài hạn được gắn vào service account, đôi khi được hardcode trong Lambda environment variable hoặc một Jenkins job. Xoay vòng chúng, nhưng tổ chức từng bước — giết một key mà một nightly batch job phụ thuộc vào lúc 2 AM là cách bạn bị gọi trong tuần đầu tiên của bạn.

Tìm public exposure trước khi kẻ tấn công làm điều đó

Chạy kiểm tra network reachability trên các VPC của bạn. Security group với 0.0.0.0/0 trên bất cứ cái gì ngoài 80/443 cần lý do, không phải giả định. Các tool như ScoutSuite hoặc Prowler sẽ xử lý một tài khoản trong vài phút và spit ra một báo cáo được xếp hạng theo mức độ nghiêm trọng — bắt đầu từ đó thay vì xây dựng danh sách kiểm tra của riêng bạn từ đầu.

S3 bucket đáng được chú ý đặc biệt vì chúng là inherited-estate landmine cổ điển. Kiểm tra cả bucket policy và account-level Block Public Access setting; ai đó có thể đã vô hiệu hóa default tài khoản cách đây nhiều năm cho một static site một lần và không bao giờ bật nó lại. aws s3api list-buckets kết hợp với một vòng lặp kiểm tra get-bucket-acl và get-bucket-policy-status trên mỗi một cái cho bạn một bức tranh sạch sẽ trong vòng mười phút đối với hầu hết các tài khoản.

Thiết lập logging trước khi bạn thiết lập trust

Nếu CloudTrail, VPC Flow Log, hoặc GuardDuty chưa chạy ở mọi nơi, bật chúng ngay bây giờ, trước khi bạn thực hiện bất kỳ thay đổi nào khác. Bạn muốn một bản ghi về những gì xảy ra từ thời điểm này trở đi, và bạn muốn nó trước khi bạn bắt đầu xóa những thứ, bởi vì xóa chính xác khi những lỗi được thực hiện và được đổ lỗi cho người mới. Ship log sang một tài khoản hoặc subscription riêng nếu có thể, để một workload bị xâm phạm cũng không thể xóa chứng cứ của chính nó.

Thiết lập GuardDuty hoặc Azure Defender for Cloud với alerting được định tuyến đến một nơi mà một con người thực sự kiểm tra — không phải một Slack channel có 400 tin nhắn chưa đọc. Giá trị của tooling phát hiện gần như bằng không nếu các cảnh báo hạ cánh trong một khoảng trống.

Sửa những vấn đề lớn nhất trước, ghi lại mọi thứ

Bạn sẽ không sửa một inherited estate trong một sprint. Triage theo blast radius: public data exposure trước tiên, sau đó overprivileged identity, sau đó network segmentation, sau đó mọi thứ khác. Ghi lại những gì bạn tìm thấy và những gì bạn thay đổi, ngay cả trong một Google Doc thuần túy, vì người tiếp theo kế thừa cái này từ bạn xứng đáng nhận được điều tốt hơn những gì bạn nhận được.

Hãy mong đợi sự phản đối khi bạn siết chặt một security group và integration test của một dev bắt đầu thất bại. Đó là bình thường — nó có nghĩa là audit đang hoạt động. Nói chuyện với team sở hữu workload trước khi bạn thay đổi bất cứ điều gì trong production, và giữ một kế hoạch rollback sẵn sàng cho hai tuần đầu tiên.

Để tìm hiểu thêm về các tool và lý do đằng sau cloud audit, hãy xem các segment của Korra Studio về IAM hardening và cloud detection engineering — cả hai đều phù hợp tốt với quy trình công việc ở trên.