Manajemen API Key LLM: Anggaran, Rotasi, dan Akses Aplikasi yang Lebih Aman
Oleh Nicho
API key LLM adalah kredensial yang bisa memberi izin pengeluaran dan akses. Mengelolanya dengan baik berarti menjawab empat pertanyaan: di mana disimpan, apa yang bisa dilakukannya, berapa banyak pemakaiannya, dan seberapa cepat kamu bisa mencabutnya?
Permintaan pertama yang berhasil tidak menjawab satu pun pertanyaan itu. Sebelum prototipe menjadi aplikasi bersama, tetapkan siklus hidup key dan batas akses yang bisa kamu jelaskan tanpa membuka kredensial mentah siapa pun.
Simpan key penyedia di balik aplikasimu
Jangan menyematkan API key penyedia yang berumur panjang di JavaScript browser, bundel aplikasi ponsel, atau penyimpanan browser. Mengirim rahasia ke perangkat pengguna akhir membuatnya berada di luar kendali servermu. OpenAI secara eksplisit merekomendasikan agar permintaan dirutekan melalui backend daripada mengekspos key di lingkungan sisi klien. Panduan keamanan API key OpenAI
Untuk aplikasi web konvensional, gunakan batas ini:
Signed-in user → your authenticated backend → LLM provider
Browser melakukan autentikasi ke aplikasimu. Backend kamu memilih model yang diizinkan dan mengambil kredensial penyedia dari penyimpanan rahasia sisi server.
Tapi memindahkan key ke backend saja tidak cukup. Proxy tanpa autentikasi masih bisa membuat orang asing menghabiskan saldomu tanpa pernah melihat rahasianya. Terapkan otorisasi pengguna, batas ukuran permintaan, operasi yang diizinkan, dan kontrol pemakaian per pengguna sebelum meneruskan pekerjaan. Jangan biarkan URL sembarang dari klien menentukan ke mana backend kamu mengirim header otorisasinya.
Pisahkan beban kerja sebelum berbagi kredensial
Hindari satu key untuk produksi, staging, laptop developer, dan impor terjadwal. Pemisahan memudahkan mengidentifikasi pemakaian dan mencabut satu beban kerja tanpa merusak yang lain.
Inventaris awal yang berguna tidak memuat rahasia mentah:
| Kolom | Contoh |
|---|---|
| Beban kerja | Peringkas dukungan pelanggan |
| Lingkungan | Produksi |
| Pemilik | Tim aplikasi |
| Referensi rahasia | Nama entri secret manager |
| Akses yang dituju | Model peringkas yang disetujui |
| Pemicu peninjauan | Perubahan deployment atau pemilik keluar |
| Prosedur pencabutan | Tautan ke runbook internal |
Gunakan batas project atau service account penyedia jika tersedia, bukan sekadar mengganti nama key yang izinnya tetap sama. Dokumentasi project OpenAI, misalnya, menjelaskan service account dan resource yang tercakup dalam project. Itu kemampuan khusus penyedia, bukan jaminan bahwa setiap gateway yang kompatibel menawarkan isolasi yang sama. Manajemen project OpenAI
Simpan rahasia tanpa membagikannya tanpa perlu
Utamakan sistem manajemen rahasia khusus dengan akses terbatas hanya untuk beban kerja dan operator yang membutuhkannya. Catat kepemilikan dan metadata siklus hidup secara terpisah dari nilai kredensial. OWASP merekomendasikan akses yang terperinci dan pengelolaan rahasia di seluruh proses pembuatan, rotasi, pencabutan, dan kedaluwarsa. Cheat Sheet Manajemen Rahasia OWASP
Untuk deployment kecil, variabel lingkungan server yang dilindungi bisa jadi mekanisme integrasi, tapi itu bukan strategi keamanan yang lengkap. Tinjau siapa yang bisa membaca pengaturan deployment, menjalankan perintah debug, atau memeriksa laporan crash. Jangan pernah mencetak seluruh environment saat mendiagnosis masalah koneksi.
Jauhkan kredensial dari file sumber, image container, screenshot, tiket, dan pesan chat. Gunakan contoh konfigurasi yang sudah disunting di dokumentasi. Rekan tim yang menangani error biasanya hanya butuh endpoint, model, error yang sudah dibersihkan, dan identifier permintaan, bukan key itu sendiri.
Tentukan arti "anggaran" yang sebenarnya
Jangan anggap setiap anggaran di dasbor sebagai batas pengeluaran keras yang langsung berlaku. Sebelum mengandalkan sebuah kontrol, pastikan:
- Apakah kontrol itu mengirim peringatan atau menolak permintaan tambahan.
- Apakah kontrol itu berlaku untuk key, proyek, akun, atau pengguna aplikasi.
- Periode reset dan zona waktunya, jika ada.
- Bagaimana permintaan bersamaan dan pencatatan pemakaian yang tertunda ditangani.
- Siapa yang menerima peringatan dan siapa yang bisa mengubah pengaturan itu.
Dokumentasikan hal yang belum diketahui daripada berasumsi perilakunya menguntungkan. Tetap jalankan kontrol penerimaan di sisi aplikasi dan pemantauan meski penyedia menawarkan fitur anggaran.
Misalnya, aplikasi bantuan mungkin hanya mengizinkan model yang disetujui, membatasi ukuran input, membatasi output yang diminta, dan membatasi operasi harian tiap pelanggan. Kontrol-kontrol ini punya tujuan berbeda: pembatasan model membatasi pilihan, batas permintaan membatasi volume, dan kontrol pengeluaran membatasi eksposur finansial. Tidak ada yang menggantikan yang lain.
Konfigurasikan kontrol key yang dipublikasikan cheapaimodel
Halaman harga publik cheapaimodel menjelaskan anggaran per key, tanggal kedaluwarsa, daftar model yang diizinkan, dan daftar IP yang diizinkan. Di sana juga dinyatakan bahwa anggaran sebuah key tidak boleh melebihi dana yang bisa ditanggung saldo akun, dan saldo akun yang habis membuat permintaan gateway mengembalikan 403.
Untuk integrasi baru, pilih daftar model yang diizinkan yang sempit dan anggaran yang sesuai dengan beban kerja itu. Beri tanggal kedaluwarsa untuk integrasi sementara. Pertimbangkan daftar IP yang diizinkan kalau server kamu punya alamat keluar yang diketahui dan stabil; perhitungkan infrastruktur failover sebelum mengaktifkannya.
Rekomendasi ini berdasarkan deskripsi produk yang dipublikasikan, bukan audit independen atas waktu penegakannya. Jangan menjanjikan nol kelebihan pengeluaran saat ada permintaan bersamaan atau menganggap pembatasan IP bisa menggantikan kerahasiaan kredensial. Periksa dokumentasi cheapaimodel terkini sebelum mengonfigurasi deployment.
Rotasi dengan sengaja; cabut segera saat terekspos
Untuk rotasi terencana, gunakan serah terima yang terkendali:
- Identifikasi setiap deployment dan pekerjaan latar belakang yang memakai kredensial lama.
- Buat pengganti dengan pembatasan yang diinginkan.
- Perbarui referensi atau nilai secret lewat proses deployment biasanya.
- Pastikan beban kerja yang terdampak sudah memakai penggantinya.
- Cabut kredensial lama dan catat penyelesaiannya.
Tumpang tindih apa pun harus disengaja dan singkat. Jangan biarkan key lama tetap aktif tanpa batas “untuk berjaga-jaga.” Kedaluwarsa juga butuh pemilik: kredensial yang kedaluwarsa tanpa rencana perpanjangan bisa jadi gangguan yang sebenarnya bisa dihindari.
Key yang terekspos berbeda. Prioritaskan pencabutan dan penanganan daripada mempertahankan masa migrasi yang nyaman. Periksa pemakaian, identifikasi deployment yang terdampak, dan pulihkan layanan dengan pengganti yang dikirim lewat saluran rahasia yang disetujui.
Menghapus key yang bocor dari commit Git terbaru tidak membatalkannya atau menghapus salinan yang ada. Panduan GitHub menempatkan pencabutan atau rotasi kredensial sebelum pembersihan riwayat repositori dan menjelaskan kenapa pembersihan butuh koordinasi. Panduan penghapusan data sensitif GitHub
Buat kepemilikan key jadi operasional
Sebelum peluncuran, pastikan ada yang bisa menjawab: siapa pemilik key ini, layanan mana yang memakainya, apa yang menghentikan pemakaian abusif, dan bagaimana kita menonaktifkannya?
Integrasi yang terkelola punya jawaban yang spesifik. Kalau jawabannya “semua orang pakai key yang sama,” perbaiki batas itu sebelum menambah traffic. Pengelolaan key yang lebih aman bukan soal trik penyimpanan yang cerdik, tapi soal menjaga akses tetap sempit, pengeluaran terlihat, dan pencabutan yang praktis.