Mengamankan Cloud Estate yang Tidak Anda Bangun

Anda baru saja mendapat kunci ke akun cloud yang telah berkembang tanpa pengawasan selama tiga tahun. Tidak ada dokumentasi yang ditinggalkan. IAM memiliki 40 peran dengan izin wildcard, ada bucket S3 yang tidak ada yang ingat membuatnya, dan orang terakhir yang memahami topologi jaringan meninggalkan perusahaan pada 2022. Ini lebih umum daripada yang kebanyakan lowongan kerja akui, dan bulan pertama menentukan nada untuk segalanya setelahnya.

Dapatkan inventaris sebelum Anda menyentuh apa pun

Tahan dorongan untuk langsung mulai mengamankan sesuatu. Anda membutuhkan peta terlebih dahulu. Jalankan aws resourcegroupstaggingapi get-resources di setiap wilayah, bukan hanya us-east-1 — tim suka memutar sumber daya uji di ap-southeast-2 dan melupakannya. Pasangkan itu dengan AWS Config jika sudah diaktifkan, atau aktifkan sekarang jika belum. Di Azure, az resource list --output table yang di-pipe ke spreadsheet berfungsi baik untuk perjalanan pertama. Di GCP, Cloud Asset Inventory gcloud asset search-all-resources memberikan Anda tampilan yang sama.

Referensi silang terhadap penagihan. Apa pun yang mengeluarkan biaya harus muncul di inventaris sumber daya Anda; apa pun dalam inventaris tanpa aktivitas terbaru adalah kandidat untuk pengarsipan. Perbedaan di sini biasanya adalah tempat hal-hal menakutkan bersembunyi — instance EC2 yatim dengan IP publik, snapshot RDS yang terlupakan terletak tanpa enkripsi, load balancer yang menunjuk ke tidak ada apa pun.

Audit IAM seperti itu adalah tempat kejadian

Tarik setiap kebijakan IAM dan cari "Action": "*" dikombinasikan dengan "Resource": "*". Kombinasi itu seharusnya tidak ada di luar segelintir peran admin break-glass, dan bahkan itu seharusnya memiliki penegakan MFA dan peringatan CloudTrail yang terlampir. Gunakan IAM Access Analyzer untuk menemukan peran yang memberikan akses ke akun eksternal — ini menangkap hubungan kepercayaan lintas akun yang disengaja dan kesalahan dari seseorang yang menguji modul Terraform terhadap ID akun yang salah.

Periksa kunci akses yang lebih tua dari 90 hari dengan aws iam generate-credential-report. Estate yang diwarisi hampir selalu memiliki kunci yang tahan lama yang terlampir pada akun layanan, kadang-kadang hardcoded dalam variabel lingkungan Lambda atau pekerjaan Jenkins. Rotasi mereka, tetapi tahap — membunuh kunci yang bergantung pada pekerjaan batch malam hari pada jam 2 pagi adalah cara Anda mendapat paging selama minggu pertama Anda.

Temukan paparan publik sebelum penyerang melakukannya

Jalankan pemeriksaan jangkauan jaringan di seluruh VPC Anda. Kelompok keamanan dengan 0.0.0.0/0 pada apa pun selain 80/443 memerlukan pembenaran, bukan asumsi. Alat seperti ScoutSuite atau Prowler akan mengunyah akun dalam hitungan menit dan mengeluarkan laporan yang diberi peringkat menurut keparahan — mulai dari sana alih-alih membangun daftar periksa Anda sendiri dari awal.

Bucket S3 layak perhatian khusus karena mereka adalah ranjau estasi warisan klasik. Periksa kebijakan bucket dan pengaturan Block Public Access tingkat akun; seseorang mungkin telah menonaktifkan default akun bertahun-tahun yang lalu untuk situs statis sekali dan tidak pernah menghidupkannya kembali. aws s3api list-buckets dikombinasikan dengan loop memeriksa get-bucket-acl dan get-bucket-policy-status pada masing-masing memberikan Anda gambaran yang jelas dalam waktu kurang dari sepuluh menit untuk sebagian besar akun.

Tetapkan logging sebelum Anda menetapkan kepercayaan

Jika CloudTrail, VPC Flow Logs, atau GuardDuty belum berjalan di mana-mana, aktifkan sekarang, sebelum Anda membuat perubahan lain apa pun. Anda ingin catatan apa yang terjadi dari saat ini, dan Anda menginginkannya sebelum Anda mulai menghapus sesuatu, karena penghapusan adalah saat kesalahan dibuat dan disalahkan pada orang baru. Kirim log ke akun atau langganan terpisah jika mungkin, sehingga beban kerja yang dikompromikan tidak dapat juga menghapus bukti miliknya sendiri.

Tetapkan GuardDuty atau Azure Defender untuk Cloud dengan peringatan yang dirutekan ke tempat manusia benar-benar memeriksa — bukan saluran Slack dengan 400 pesan yang belum dibaca. Nilai alat deteksi hampir nol jika peringatan mendarat di kekosongan.

Perbaiki masalah paling keras terlebih dahulu, dokumentasikan semuanya

Anda tidak akan memperbaiki estasi warisan dalam sprint. Triage menurut radius ledakan: eksposur data publik terlebih dahulu, kemudian identitas yang terlalu istimewa, kemudian segmentasi jaringan, kemudian semua yang lain. Tulis apa yang Anda temukan dan apa yang Anda ubah, bahkan di Google Doc biasa, karena orang berikutnya yang mewarisi ini dari Anda layak mendapatkan lebih baik daripada apa yang Anda dapatkan.

Harapkan perlawanan ketika Anda mengencangkan grup keamanan dan tes integrasi pengembang mulai gagal. Itu normal — ini berarti audit sedang bekerja. Bicaralah dengan tim yang memiliki beban kerja sebelum Anda membalik apa pun dalam produksi, dan siapkan rencana rollback untuk dua minggu pertama.

Untuk lebih lanjut tentang alat dan alasan di balik audit cloud, lihat segmen Korra Studio tentang hardening IAM dan rekayasa deteksi cloud — keduanya berpasangan dengan baik dengan alur kerja di atas.