Audit secret API key tidak cukup berhenti pada pertanyaan “apakah key disimpan di environment variable?”. Pertanyaan yang lebih penting adalah: di mana secret pernah muncul, siapa yang bisa membacanya, kapan ia disalin, dan apakah dependency atau proses build bisa mengambilnya.

Pada aplikasi backend dan web modern, API key bisa hidup di banyak tempat sekaligus: file .env, environment variable runtime, konfigurasi CI/CD, secret manager, image container, build log, crash report, browser bundle, dan memori proses. Jika ada package berbahaya, script postinstall, atau supply-chain compromise, semua lokasi itu menjadi permukaan serangan. Artikel ini membahas cara mengaudit jalur hidup secret secara praktis, anti-pattern yang sering terjadi, dan langkah hardening yang bisa langsung diterapkan tim kecil.

Apa yang sebenarnya diaudit?

Saat melakukan audit secret API key, tujuan Anda bukan hanya menemukan lokasi penyimpanan utama, tetapi memetakan siklus hidup secret dari awal sampai akhir:

  1. Pembuatan: siapa membuat key, untuk layanan apa, dan scope apa yang diberikan.
  2. Penyimpanan: apakah key ada di .env, secret manager, variabel CI, atau tempat lain.
  3. Distribusi: bagaimana key masuk ke aplikasi, container, worker, atau job build.
  4. Penggunaan runtime: proses mana yang membaca key, kapan dibutuhkan, dan apakah key muncul di log/error.
  5. Eksposur turunan: apakah key tersalin ke artefak build, image layer, cache, crash dump, APM, atau browser.
  6. Rotasi dan pencabutan: seberapa cepat key bisa diganti jika bocor.

Audit yang baik selalu menjawab dua pertanyaan:

  • Di mana secret bisa dibaca secara sah?
  • Di mana secret bisa bocor secara tidak sengaja?

Threat model: jika dependency atau package postinstall berbahaya

Threat model yang sering diremehkan adalah dependency yang berjalan pada saat install, build, atau startup. Package tidak harus dipakai di runtime produksi untuk tetap berbahaya. Cukup jika ia berjalan di laptop developer, runner CI, atau fase build image.

Apa yang bisa dilakukan dependency berbahaya?

  • Membaca environment variable proses saat npm install, pip install, atau langkah setup lain.
  • Membaca file .env, file konfigurasi lokal, atau kredensial cloud di home directory.
  • Mengirim isi secret ke endpoint eksternal.
  • Menyisipkan secret ke log build agar bocor lewat sistem observabilitas.
  • Mengubah artefak build sehingga secret ikut masuk ke frontend bundle atau image container.
  • Membaca token CI/CD yang memiliki akses lebih luas daripada API key aplikasi.

Intinya, jika secret tersedia terlalu awal atau terlalu luas, dependency jahat tidak perlu mengeksploitasi aplikasi Anda. Ia cukup “memungut” secret yang sudah ada.

Catatan penting: environment variable bukan mekanisme keamanan. Ia hanya mekanisme konfigurasi. Jika proses dapat berjalan dengan secret itu, proses tersebut atau kode yang dimuatnya biasanya juga dapat membacanya.

Peta lokasi hidup API key yang wajib diaudit

1. File .env dan file konfigurasi lokal

.env praktis untuk pengembangan, tetapi mudah bocor melalui commit Git, backup workstation, sinkronisasi cloud folder, atau tooling debug. Risiko lain: developer menyalin file staging/production ke laptop lokal agar “lebih mudah dites”.

Yang perlu diaudit:

  • Apakah .env pernah ter-commit, termasuk di riwayat lama Git.
  • Apakah ada file seperti .env.local, .env.production, .env.backup, atau salinan ZIP.
  • Apakah secret disimpan di README, wiki internal, chat, atau tiket issue.
  • Apakah workstation developer memiliki full production secret tanpa kebutuhan nyata.

2. Environment variable runtime

Env var lebih baik daripada hardcode di source code, tetapi masih punya risiko:

  • Terbaca oleh proses anak atau tooling yang dijalankan dari proses utama.
  • Muncul di dump diagnostik, crash report, atau debug endpoint.
  • Terekam jika aplikasi mencetak seluruh konfigurasi saat startup.
  • Dapat diakses siapa pun yang punya akses shell/debug ke host atau container, tergantung model isolasi.

Audit perlu memastikan secret hanya tersedia pada proses yang membutuhkannya, bukan seluruh ekosistem host.

3. Secret manager atau vault

Secret manager mengurangi sprawl karena secret tidak disalin ke banyak tempat, tetapi bukan otomatis aman. Yang diaudit bukan hanya “apakah pakai vault”, melainkan:

  • Bagaimana aplikasi melakukan autentikasi ke secret manager.
  • Apakah secret diambil saat runtime atau di-ekspor dulu ke env var permanen.
  • Apakah akses secret dibatasi per layanan, environment, dan fungsi.
  • Apakah ada audit log akses dan mekanisme rotasi.

Vault/secret manager paling berguna jika dipadukan dengan injeksi runtime yang sempit dan identitas workload yang kuat, bukan sekadar menjadi tempat penyimpanan terpusat.

4. CI/CD pipeline

CI sering menjadi titik bocor paling berbahaya karena memiliki banyak kredensial dan banyak dependency yang berjalan. Risiko umum:

  • Secret tersedia pada semua step pipeline, padahal hanya satu step yang membutuhkannya.
  • Build dari pull request tak tepercaya bisa mengakses secret.
  • Command shell seperti set -x atau logging verbose mencetak secret.
  • Artefak build, test report, atau cache menyimpan file konfigurasi sensitif.

Prinsip aman: secret CI harus minimal, scoped, masked, dan hanya tersedia pada job yang benar-benar membutuhkan.

5. Container image dan build context

Banyak kebocoran terjadi bukan di container runtime, tetapi saat build image:

  • ARG atau ENV di Dockerfile menyimpan secret di layer metadata atau image history.
  • File .env ikut ter-copy ke image karena .dockerignore tidak benar.
  • Build tool mengunduh dependency privat memakai token, lalu token tertinggal di cache layer.

Secret tidak boleh menjadi bagian permanen dari image. Image harus bisa dipindah tanpa ikut membawa kunci produksi.

6. Build log, application log, dan crash report

Secret yang terlindungi di storage bisa tetap bocor lewat observabilitas. Kasus umum:

  • Aplikasi mencetak konfigurasi lengkap saat startup.
  • Error handler mengembalikan header request atau body yang berisi token.
  • SDK pihak ketiga mengirim request metadata ke APM atau crash reporter.
  • Build script menulis URL yang mengandung token query parameter.

Audit log harus mencakup logging aplikasi, reverse proxy, job queue, APM, error tracker, dan sistem support yang menerima screenshot/log dari pengguna.

7. Browser dan frontend bundle

Ini area yang paling sering salah paham. Jika API key ada di JavaScript browser, maka key itu pada dasarnya publik untuk siapa pun yang memuat halaman. Menyembunyikannya lewat minify, obfuscation, atau build-time env frontend tidak mengubah fakta itu.

Yang harus dibedakan:

  • Public config: aman untuk browser, misalnya base URL publik atau publishable key dengan scope sangat terbatas.
  • Secret server-side: tidak boleh pernah masuk bundle frontend, source map, HTML, atau response API debug.

8. Proses runtime dan memori

Pada akhirnya, secret dipakai oleh proses. Artinya ia akan berada di memori setidaknya sementara waktu. Anda tidak bisa menghilangkan ini, tetapi bisa membatasi dampaknya:

  • Jalankan aplikasi dengan hak akses minimum.
  • Batasi kemampuan debug shell/exec ke container produksi.
  • Pisahkan service agar satu compromise tidak membuka semua secret.
  • Hindari memuat terlalu banyak secret “untuk jaga-jaga” saat startup.

Perbedaan build-time secret vs runtime secret

Ini salah satu akar masalah paling umum. Banyak tim mencampur secret yang dibutuhkan saat build dengan secret yang dibutuhkan saat runtime.

Build-time secret

Contoh: token untuk menarik dependency privat atau mengakses registry privat saat image dibangun.

Karakteristik aman:

  • Hanya tersedia selama langkah build tertentu.
  • Tidak disimpan ke layer image akhir.
  • Tidak diekspor ke binary, bundle, atau file konfigurasi final.

Runtime secret

Contoh: API key untuk memanggil layanan eksternal saat aplikasi melayani request.

Karakteristik aman:

  • Disuntikkan saat container/proses dijalankan, bukan saat image dibangun.
  • Hanya diberikan ke service yang memakainya.
  • Mudah dirotasi tanpa rebuild image.

Jika runtime secret dimasukkan saat build, secret sering tertinggal di image, cache, artefak, atau frontend bundle. Ini anti-pattern yang sangat sering terjadi.

Pola aman untuk secret injection

Opsi 1: Environment variable runtime

Ini masih pola yang layak untuk banyak tim kecil jika dilakukan dengan disiplin.

Pilih opsi ini jika:

  • Jumlah service masih sedikit.
  • Rotasi secret belum terlalu sering.
  • Platform deployment Anda sudah punya mekanisme secret injection yang cukup baik.

Syarat amannya:

  • Secret dimasukkan saat deploy/run, bukan bake ke image.
  • Proses logging tidak mencetak env.
  • Akses ke host/container dibatasi.
  • Secret dipisah per environment dan per service.

Opsi 2: Secret manager/Vault dengan fetch saat startup atau runtime

Ini cocok jika kebutuhan kontrol akses, audit log, dan rotasi lebih tinggi.

Pilih opsi ini jika:

  • Anda punya banyak service atau environment.
  • Butuh audit trail siapa mengakses secret.
  • Ingin mengurangi distribusi secret statis ke banyak tempat.

Trade-off:

  • Arsitektur lebih kompleks.
  • Aplikasi bergantung pada akses ke secret manager atau agent sidecar.
  • Perlu desain fallback agar startup tidak rapuh.

Prinsip umum injeksi yang aman

  • Inject late: berikan secret sedekat mungkin ke waktu pemakaian.
  • Scope narrowly: satu service, satu environment, satu fungsi.
  • Prefer identity over static secret: jika platform mendukung, gunakan identitas workload untuk mengambil secret alih-alih menyimpan banyak token statis.
  • Never persist unnecessarily: jangan tulis ulang secret ke file, image, cache, atau artefak.

Contoh alur audit secret API key yang praktis

Berikut contoh alur audit yang bisa dilakukan tim kecil dalam 1-2 sesi kerja.

Langkah 1: inventaris semua secret

Buat daftar sederhana:

  • Nama secret
  • Layanan tujuan
  • Environment pemakaian
  • Service yang memakai
  • Pemilik bisnis/teknis
  • Metode rotasi

Tanpa inventaris ini, audit akan berubah menjadi pencarian acak.

Langkah 2: telusuri jalur hidup satu secret penting

Ambil satu API key prioritas tinggi, lalu jawab:

  1. Dibuat di mana?
  2. Disimpan pertama kali di mana?
  3. Bagaimana masuk ke CI/deploy?
  4. Bagaimana masuk ke runtime?
  5. Proses apa yang bisa membacanya?
  6. Apakah pernah muncul di browser, log, artefak, atau image?
  7. Bagaimana cara mencabut dan menggantinya?

Ulangi untuk secret yang paling sensitif atau paling luas dampaknya.

Langkah 3: audit repository dan riwayat Git

Cari indikasi secret di source code dan riwayat commit:

git grep -nE '(API_KEY|SECRET|TOKEN|PRIVATE_KEY|PASSWORD)'

git log -p -- . ':!package-lock.json' ':!yarn.lock'

Tambahkan pemindaian dengan secret scanning di repository dan CI. Jika pernah ada kebocoran di commit lama, menghapus file di commit terbaru tidak cukup; secret harus dianggap bocor dan dirotasi.

Langkah 4: audit pipeline CI/CD

Periksa:

  • Job mana yang menerima secret.
  • Apakah build dari branch/PR tak tepercaya bisa membaca secret.
  • Apakah ada command debug yang mencetak env.
  • Apakah artefak atau cache berisi file konfigurasi sensitif.

Lihat juga dependency install step. Di sinilah package postinstall berbahaya paling relevan.

Langkah 5: audit Dockerfile dan image

Cari anti-pattern seperti ini:

FROM node:alpine
ARG API_KEY
ENV API_KEY=$API_KEY
COPY . .
RUN npm install
RUN npm run build

Masalahnya:

  • Secret tersedia saat build untuk semua script build/dependency.
  • Secret berisiko masuk ke layer image atau bundle hasil build.
  • Jika frontend dibangun di langkah ini, key bisa ikut ter-embed.

Pola yang lebih aman adalah image dibangun tanpa secret runtime, lalu secret diberikan saat container dijalankan.

Langkah 6: validasi frontend tidak menerima secret server-side

Lakukan pemeriksaan nyata, bukan asumsi:

  • Inspect bundle JavaScript hasil build.
  • Cari string yang menyerupai token atau nama env sensitif.
  • Periksa response HTML awal, source map, dan endpoint debug/config.
  • Buka DevTools Network dan lihat apakah browser memanggil layanan pihak ketiga langsung dengan key sensitif.

Untuk framework frontend modern, hanya variabel yang memang ditandai untuk publik yang boleh tersedia di browser. Namun, aturan penamaan berbeda antar framework, jadi prinsip utamanya tetap sama: jika dibutuhkan browser, anggap publik; jika rahasia, harus tetap di server.

Langkah 7: audit logging dan observability

Simulasikan error dan lihat apa yang tercatat. Cek:

  • Application log
  • Proxy/load balancer log
  • Job worker log
  • APM/tracing
  • Error tracker
  • Support tooling dan incident chat

Sering kali kebocoran justru terjadi saat tim sedang debug insiden.

Anti-pattern umum yang perlu dihentikan

  • Menyimpan secret di repository privat. Privat bukan berarti aman dari salah akses atau supply-chain issue.
  • Memakai satu API key untuk semua environment. Kebocoran di development bisa menjadi insiden produksi.
  • Menyuntikkan semua secret ke semua service. Ini melanggar least privilege.
  • Build frontend memakai secret backend. Jika sampai bundle membutuhkan key itu, desainnya kemungkinan salah.
  • Mencetak konfigurasi lengkap saat startup. Praktis untuk debug, berbahaya untuk produksi.
  • Mengandalkan obfuscation di browser. Secret di frontend tetap bisa diekstrak.
  • Menyimpan secret di image container. Image mudah tersebar ke registry, cache, atau laptop developer.
  • Tidak memisahkan token CI dengan token aplikasi. Token CI sering punya akses jauh lebih luas.

Hardening yang bisa langsung diterapkan tim kecil

1. Pisahkan secret per environment dan per service

Jangan gunakan satu key global. Minimal pisahkan dev, staging, dan production. Lebih baik lagi, satu integrasi penting punya key sendiri per service.

2. Terapkan least privilege

Jika penyedia API mendukung scope, batasi hanya ke endpoint atau operasi yang dibutuhkan. Jika ada opsi pembatasan IP, referrer, atau project, gunakan sesuai konteks. Ini tidak menggantikan kerahasiaan, tetapi mengurangi dampak kebocoran.

3. Hapus runtime secret dari fase build

Pastikan Dockerfile, static site build, dan asset pipeline tidak menerima secret backend. Build harus reproducible tanpa kredensial produksi.

4. Kurangi akses secret di CI

  • Berikan secret hanya pada job deploy atau job yang benar-benar perlu.
  • Jangan expose secret pada build dari fork/PR tak tepercaya.
  • Matikan shell tracing verbose pada langkah sensitif.
  • Review dependency install step secara berkala.

5. Pasang secret scanning

Aktifkan scanning pada repository, pull request, dan artefak jika memungkinkan. Ini bukan pengganti desain yang baik, tetapi sangat membantu mendeteksi kebocoran dini.

6. Redaksi log dan error

Buat utility untuk menyamarkan nilai sensitif sebelum logging. Lebih aman memblok logging field tertentu daripada berharap semua developer ingat untuk tidak mencetaknya.

7. Batasi kemampuan debug produksi

Kurangi akses shell langsung ke host/container produksi. Jika perlu debug, gunakan prosedur yang diaudit dan sementara. Semakin sedikit pihak yang bisa membaca environment runtime, semakin kecil risikonya.

8. Rencanakan rotasi sebelum insiden

Rotasi yang baik tidak dimulai saat kebocoran terjadi. Dokumentasikan:

  • siapa yang berwenang membuat key baru,
  • bagaimana deploy key pengganti,
  • urutan cutover,
  • bagaimana memverifikasi key lama sudah tidak dipakai.

Contoh validasi agar key tidak bocor ke frontend

Tambahkan pemeriksaan sederhana di pipeline setelah build frontend. Tujuannya bukan membuktikan tidak ada kebocoran secara matematis, tetapi menangkap kesalahan yang jelas.

# contoh pendekatan generik
# cari nama env sensitif atau pola token pada direktori hasil build

grep -R -nE 'API_KEY|SECRET|TOKEN|sk-[A-Za-z0-9]+' dist/ build/ .next/ 2>/dev/null || true

Ini bukan detektor sempurna, tetapi berguna sebagai guardrail. Lebih kuat lagi jika dipadukan dengan daftar denylist nama variabel sensitif milik tim Anda.

Pada sisi aplikasi, desain yang benar biasanya seperti ini:

  • Browser memanggil backend Anda.
  • Backend menyimpan dan memakai API key rahasia untuk memanggil layanan eksternal.
  • Browser hanya menerima data yang dibutuhkan, bukan credential.

Checklist audit insiden jika diduga ada kebocoran

Jika ada indikasi secret bocor, lakukan langkah berikut secara berurutan:

  1. Identifikasi secret yang terdampak dan layanan mana yang menggunakannya.
  2. Asumsikan secret sudah terekspos jika muncul di Git, log, browser, atau CI.
  3. Rotasi/revoke segera jika memungkinkan, jangan tunggu analisis selesai total.
  4. Periksa scope dan penyalahgunaan: log akses provider, penggunaan tidak biasa, lonjakan request, atau asal IP aneh.
  5. Telusuri jalur bocor: commit, image, log, artifact, dependency, workstation, atau dashboard observability.
  6. Audit secret saudara: key lain yang disimpan/disuntikkan dengan cara serupa mungkin juga berisiko.
  7. Perbaiki kontrol permanen: pemisahan build/runtime, masking log, pembatasan CI, least privilege.
  8. Dokumentasikan timeline dan tindakan untuk postmortem dan perbaikan proses.

Contoh kebijakan minimum untuk tim kecil

Jika tim Anda belum punya sistem secret management yang matang, kebijakan minimum berikut sudah memberi peningkatan nyata:

  • Semua secret produksi disimpan di mekanisme secret deployment platform, bukan di repository.
  • File .env hanya untuk lokal, tidak boleh berisi secret produksi.
  • Secret produksi tidak pernah dipakai saat build frontend atau build image umum.
  • Setiap service hanya menerima secret yang benar-benar ia butuhkan.
  • CI untuk pull request tak tepercaya tidak mendapat secret sensitif.
  • Logging konfigurasi mentah dilarang di produksi.
  • Rotasi secret prioritas tinggi diuji berkala.
  • Scanning secret di repo dan review dependency menjadi bagian checklist merge.

Penutup

Audit secret API key yang efektif berfokus pada jalur hidup secret, bukan sekadar lokasi utamanya. Env var, file .env, vault, CI/CD, container image, log, browser, dan memori runtime semuanya bisa menjadi titik eksposur. Risiko meningkat tajam ketika dependency atau package postinstall mendapat kesempatan membaca secret terlalu awal atau terlalu luas.

Untuk tim kecil, perbaikan paling berdampak biasanya bukan alat paling kompleks, melainkan disiplin dasar: pisahkan build-time dan runtime secret, gunakan least privilege, batasi akses secret di CI, jangan pernah kirim secret backend ke frontend, dan siapkan rotasi sebelum insiden terjadi. Jika Anda bisa menjawab dengan jelas “di mana key ini pernah hidup?”, Anda sudah berada jauh di depan banyak sistem yang tampak rapi tetapi sebenarnya rapuh.