Merapikan AWS Access Key yang Berawal dari Persiapan ISMS: Transisi ke Autentikasi Berbasis Role

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-credentials di 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