Belajar Cloud Computing - Securing Cloud Access & Temporary Credentials

#Pendahuluan

Di episode 3, kalian memahami IAM sebagai sistem izin: siapa boleh mengakses apa. Episode 4 menjawab pertanyaan praktik yang menyusul: bagaimana cara memakai IAM tanpa membahayakan akun?

Materi episode ini adalah perbedaan antara praktik amatir dan profesional. Banyak kebocoran cloud terjadi bukan karena teknologi canggih dibobol, melainkan karena praktik dasar yang salah: memakai akun root, menyimpan API key di kode, dan tidak mencatat siapa melakukan apa. Mari perbaiki kebiasaan itu dari awal.

#Mengapa Akun Root/Owner Tidak Boleh Dipakai Sehari-hari

Saat kalian membuat akun cloud, kalian menerima akun root (AWS), owner account (GCP), atau akun Global Administrator (Azure). Akun ini punya izin tak terbatas dan tidak bisa dibatasi policy apa pun — memang didesain begitu, karena hanya boleh dipakai sekali untuk hal-hal tertentu.

Bayangkan memiliki kunci master yang membuka semua pintu di gedung, tanpa CCTV dan tanpa catatan siapa masuk kapan. Menggunakannya untuk pekerjaan sehari-hari berarti satu kesalahan login sudah cukup untuk menghancurkan semuanya — itulah blast radius maksimal.

Aturannya sederhana:

1. Gunakan akun root hanya untuk membuat user administratif pertama dan mengaktifkan MFA.
2. Buat user harian dengan izin terbatas (least privilege).
3. Aktifkan MFA wajib pada semua user — termasuk root.
4. Jangan pernah memakai akun root untuk eksplorasi atau eksperimen.

#Bahaya Hardcoded Long-Lived API Key

Long-lived credentials adalah kredensial yang berlaku terus-menerus sampai dicabut manual — access key AWS, service account key GCP, atau password aplikasi Azure. Masalahnya: sekali bocor, ia kompromi akun kalian tanpa batas waktu.

Tiga jalur kebocoran paling umum:

• Commit ke git — developer menempel kredensial di kode, lalu push ke repository publik. Alat seperti git-secrets dan pemindaian GitHub akan menandainya, tapi lebih baik mencegah dari awal.
• File konfigurasi yang ikut ter-deploy — .env yang tidak sengaja masuk ke image container.
• Berbagi antar developer — kredensial dikirim lewat chat, lalu tersebar.

Bayangkan menaruh kunci rumah di bawah keset dengan label "kunci cadangan". Itu long-lived credential yang tersimpan tidak aman. Solusinya bukan menyimpan lebih baik — tapi menghindari kredensial panjang umur sama sekali.

#Temporary Credentials: Batasi Blast Radius dengan Waktu

Solusi modern untuk masalah di atas: temporary credentials — kredensial yang berlaku singkat (biasanya 15 menit sampai 12 jam), diterbitkan melalui peran yang di-asumsikan. Kalau bocor, masa berlakunya berakhir sendiri.

Di AWS, mekanismenya adalah STS AssumeRole: kalian meminta token sementara untuk memakai role tertentu.

aws sts assume-role \
  --role-arn "arn:aws:iam::123456789012:role/DeployRole" \
  --role-session-name "deploy-session" \
  --duration-seconds 3600

Perintah aws sts assume-role mengembalikan tiga nilai: access key, secret key, dan session token — semuanya berlaku satu jam. Contoh respons:

{
    "Credentials": {
        "AccessKeyId": "ASIAEXAMPLEACCESSKEY",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luEXAMPLE",
        "Expiration": "2026-08-03T14:00:00Z"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROEXAMPLEID:deploy-session",
        "Arn": "arn:aws:sts::123456789012:assumed-role/DeployRole/deploy-session"
    }
}

Nilai-nilai ini lalu dipakai sebagai kredensial sesi:

export AWS_ACCESS_KEY_ID=ASIAEXAMPLEACCESSKEY
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luEXAMPLE
aws sts get-caller-identity

Perhatikan: export AWS_SESSION_TOKEN=... memakai variabel lingkungan, bukan kode. Di AWS SDK modern, mekanisme ini bahkan otomatis: proses yang berjalan di EC2, ECS, atau Lambda memakai instance profile yang mengasumsikan role tanpa perlu menyimpan satu pun kredensial statis.

#GCP: Service Account Impersonation

GCP memakai pola service account impersonation: sebuah identitas (misalnya CI/CD) meminta izin untuk "meminjam" identitas service account tertentu untuk sementara, dan kredensialnya diterbitkan sebagai token sementara.

gcloud auth application-default login \
  --impersonate-service-account deploy-sa@my-project.iam.gserviceaccount.com

Cara ini menghindari men-download service account key (file JSON rahasia) yang sering bocor — kunci imporsisasi dikeluarkan on-demand dan berusia pendek.

#Azure: Workload Identity Federation

Azure memakai managed identity dan workload identity federation: aplikasi yang berjalan di Azure otomatis mendapat identitas yang dikelola platform, tanpa secret sama sekali. Untuk CI/CD, federasi menghubungkan identitas workload (misalnya GitHub Actions) langsung ke service principal Azure — sehingga tidak ada rahasia yang perlu disimpan di pipeline.

az ad app federated-credential create \
  --id 00000000-0000-0000-0000-000000000000 \
  --parameters parameters.json

Pola ketiga penyedia ini punya satu esensi yang sama: jangan simpan kredensial panjang umur — pinjam identitas, dan biarkan masa berlakunya pendek.

#Audit Logging: Jejak Digital yang Wajib

Kredensial sementara mengurangi risiko, tapi tidak ada sistem yang sempurna. Pertanyaan terakhir yang harus selalu bisa dijawab: siapa melakukan apa, kapan? Itulah tugas audit logging.

Audit log adalah "black box" akun cloud: merekam setiap API call, oleh siapa, dari IP mana, dan dengan hasil apa. Dengan log ini, insiden bisa ditelusuri, dan praktik buruk seperti pemakaian akun root bisa terdeteksi.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole

Perintah aws cloudtrail lookup-events mencari jejak siapa yang mengasumsikan role kapan. Kebiasaan yang disarankan: aktifkan audit logging sejak hari pertama — bukan saat sudah terjadi masalah.

#Checklist Keamanan Akses Cloud

• Root/owner hanya untuk setup awal dan MFA — bukan untuk kerja harian.
• Tidak ada API key panjang umur di kode, commit, atau .env yang ikut ter-deploy.
• Pakai temporary credentials: STS AssumeRole, service account impersonation, atau managed identity.
• Aktifkan MFA untuk semua user, termasuk root.
• Nyalakan audit logging dan rutin periksa event yang mencurigakan.

#Penutup

Episode 4 menutup blok keamanan dasar seri ini:

• Akun root punya blast radius maksimal dan hanya untuk setup.
• Long-lived API key berbahaya karena bocor = kompromi permanen.
• Temporary credentials membatasi kerusakan dengan waktu: AWS STS, GCP impersonation, Azure managed identity.
• Audit logging menjawab "siapa melakukan apa" — aktifkan sejak awal.

Di episode 5, kalian masuk ke tulang punggung infrastruktur cloud: Virtual Private Cloud & networking — subnet publik dan privat, gateway, dan cara menghubungkan resource cloud dengan aman.