Ini adalah tulisan yang merangkum pengalaman beralih ke autentikasi berbasis Role saat meninjau Access Key yang menumpuk di akun AWS dalam proses menanggapi audit lanjutan ISMS.
Latar belakang penerapan
- Saat melihat konsol IAM, Access Key tersebar di berbagai tempat (CI/CD, skrip deployment, pengembangan lokal, dll.), dan sulit melacak di mana serta bagaimana kunci itu digunakan
- Access Key dipertahankan tanpa masa kedaluwarsa, dan jika bocor, hak akses yang diberikan akan langsung terekspos, sehingga risikonya besar
- AWS juga merekomendasikan penggunaan kredensial sementara (Role/STS) alih-alih kredensial jangka panjang (Access Key)
Masalah
- Karena kunci disalin dan digunakan di banyak tempat, sulit menjawab pertanyaan “jika kunci ini bocor, dampaknya sampai sejauh mana?”
- Untuk melakukan rotasi, pengaturan yang tersebar harus diubah secara bersamaan, dan karena beberapa jenis izin menumpuk pada satu IAM User, penerapan least privilege menjadi sulit
- Saat itu, satu IAM User untuk CI/CD menampung sekaligus izin deployment ECR/S3/SSM/ECS dan lainnya
Cara transisi yang diterapkan (ringkas)
- Assume Role: cara meminjam sementara izin dari Role lain pada saat dibutuhkan
- OIDC Web Identity: cara mendapatkan Role menggunakan identitas sistem eksternal seperti GitHub Actions/EKS(=IRSA)
- Instance Profile: cara menempelkan Role langsung ke EC2/Lambda agar otomatis memiliki izin
Proses transisi yang sebenarnya
- Tahap 1: memisahkan izin IAM User yang memiliki kebijakan luas menjadi Role per kebutuhan (push/pull ECR, deployment ECS, cache S3, dll.)
- Tahap 2: menerapkan OIDC pada GitHub Actions (mendaftarkan Identity Provider → membatasi cakupan repo dengan kondisi pada Trust Policy → menggunakan
configure-aws-credentialsdi workflow)
Dampak
- Access Key dihapus dari kode/secret, dan karena berbasis token sementara, sekalipun bocor, cakupan kerusakan dibatasi oleh masa berlaku
- Beban rotasi kunci hilang, dan pelacakan izin per workflow/pekerjaan menjadi lebih jelas
Hal yang perlu diperhatikan
- Jangan membuat kondisi Trust Policy terlalu longgar; batasi ke cakupan minimum (org/repo, kalau memungkinkan sampai branch)
- Jangan langsung menghapus Access Key lama; setelah transisi, nonaktifkan dan jalankan masa verifikasi untuk beberapa waktu sebelum menghapusnya
Belum ada komentar.