Cara membagikan kunci API dengan aman
Tanpa mengekspos rahasia Anda
Kunci API tidak seharusnya berada di Slack, Teams, email, tiket, atau riwayat Git. Pelajari alur yang lebih aman: batasi cakupan kunci, enkripsi secara lokal, gunakan tautan sekali pakai, dan rotasi setelah penyerahan selesai.
Poin utama
- Jangan pernah menempelkan kunci API ke email, obrolan, tiket, dokumen, atau Git.
- Gunakan kunci yang paling sempit: hak akses minimum, umur singkat, rotasi setelah selesai.
- Kirim rahasia melalui tautan sekali pakai yang dienkripsi di browser.
- Untuk kunci berisiko tinggi, enkripsi secara lokal terlebih dahulu; bagikan hanya teks sandi.
- Pantau pemakaian yang tidak biasa setelah berbagi—PrivateNote adalah penyerahan, bukan brankas.
Di halaman ini
Setiap pengembang pada akhirnya perlu mengirim kunci API kepada orang lain — untuk akses pra-produksi, kontraktor, integrasi webhook, atau penyerahan kepada klien. Jalur tercepat biasanya juga jalur yang meninggalkan jejak terpanjang.
Perlakukan kunci API seperti kata sandi produksi
Kunci API pada dasarnya adalah kata sandi untuk perangkat lunak. Bergantung pada izinnya, kunci yang bocor dapat mengekspos data pelanggan, memakai sumber daya berbayar, men-deploy infrastruktur awan, mengirim email melalui domain terverifikasi Anda, atau menaikkan tagihan AI.
Berbeda dari kata sandi manusia, kunci API sering tetap berlaku selama berbulan-bulan, berada di dalam file konfigurasi, dan sepenuhnya melewati autentikasi multifaktor. Jika kunci bocor, penyerang dapat beroperasi sebagai aplikasi Anda — dan lalu lintas berbahaya dapat menyatu dengan pemakaian produksi biasa sampai biaya melonjak atau data sudah terekspos.
Jangan pernah menempelkan kunci API ke sistem permanen
Saluran ini nyaman karena menyimpan riwayat. Itulah persis alasan saluran ini tempat yang salah untuk rahasia.
- Slack, Microsoft Teams, Discord, atau riwayat obrolan lain
- Email, SMS, atau utas kotak masuk yang diteruskan
- Jira, Trello, Notion, Confluence, atau isu GitHub
- Dokumen teks biasa, lembar sebar, dan folder awan bersama
- Commit Git, pull request, dan komentar kode
Di mana kunci API sebenarnya bocor
Sebagian besar kebocoran bukan pembobolan kriptografi yang canggih. Kebocoran terjadi saat seseorang menyalin rahasia ke sistem yang dibangun untuk menyimpan catatan.
Email menciptakan salinan yang berumur panjang. Kunci dapat bertahan di kotak masuk, arsip, cadangan, sinkronisasi seluler, utas yang diteruskan, dan indeks pencarian lama setelah tugas selesai.
Obrolan tim
Slack dan Teams menyimpan konteks — yang membuatnya berisiko untuk rahasia. Satu kunci yang ditempel dapat dicari oleh anggota ruang kerja di masa depan atau bocor melalui perangkat yang disusupi.
Alat proyek
Jira, Notion, Confluence, Trello, dan GitHub Issues bukan brankas kredensial. Tiket yang dihapus mungkin masih ada di ekspor, cadangan, jejak audit, dan pencarian berbantuan AI.
Repositori Git
Riwayat Git lengket. Menghapus kunci di commit berikutnya tidak menghapus commit sebelumnya. Repositori publik dipindai terus-menerus, dan kredensial awan yang terekspos dapat disalahgunakan dalam hitungan menit.
Kunci berisiko tinggi: enkripsi secara lokal terlebih dahulu
Sebagian besar kunci API dapat diganti: token pra-produksi, rahasia integrasi berumur singkat, dan kredensial bercakupan sempit yang Anda rencanakan untuk dirotasi. Untuk itu, pengiriman sekali pakai yang dienkripsi di browser biasanya cukup.
Beberapa kunci membawa bobot lebih besar — akses admin produksi, kunci penandatanganan, kredensial awan root, atau apa pun yang berumur panjang dan menyakitkan atau mustahil dicabut dengan bersih. Perlakukan seperti rahasia induk: enkripsi secara lokal sebelum unggahan web apa pun, lalu kirim teks sandi melalui PrivateNote.
- age — bawaan paling sederhana untuk enkripsi file (
age -p -o key.txt.age key.txt) - OpenSSL — CLI tepercaya jika Anda sudah mengenal opsinya
- Unggah file terenkripsi dengan PrivateNote; kirim frasa sandi dekripsi lewat saluran terpisah (Signal, telepon, secara langsung)
Alur kerja yang sama berlaku untuk frasa pemulihan mata uang kripto dan rahasia induk lain yang tidak tergantikan. Lihat frasa pemulihan kripto dan tautan sekali pakai untuk panduan lengkap age/OpenSSL, kiat frasa sandi, serta kapan tautan sekali pakai — dan kapan tidak — merupakan alat yang tepat.
Alur penyerahan yang lebih aman
Saat manusia yang memerlukan kunci—bukan saat aplikasi mengambilnya pada waktu berjalan—ikuti urutan ini.
Batasi cakupan kunci
Hanya izin minimum
Enkripsi secara lokal
Kunci tidak pernah meninggalkan browser Anda
Kirim tautan
Bukan rahasia mentah
Cabut setelah selesai
Rotasi setelah penyerahan
Bagikan kata sandi catatan apa pun melalui saluran terpisah — jangan pernah dalam pesan yang sama dengan tautan.
Bagaimana PrivateNote berperan dalam penyerahan
PrivateNote dibuat untuk momen manusia ke manusia: kunci API, kunci privat SSH, kredensial basis data, kode pemulihan, rahasia penandatanganan webhook, dan kata sandi sementara yang perlu sampai ke satu orang tanpa menjadi catatan permanen.
Jika rahasianya adalah kunci SSH, bukan kredensial API, lihat cara membagikan kunci SSH dengan aman untuk kunci publik dibanding kunci privat, kunci penerapan, dan ekstensi editor.
Rahasia dienkripsi di browser Anda sebelum diunggah. PrivateNote menyimpan teks sandi, bukan teks biasa. Kunci dekripsi berada di fragmen URL — bagian setelah # — yang tidak dikirim browser ke server saat memuat halaman. Itulah model tautan rahasia sekali pakai yang diterapkan pada kredensial API.
https://privatenote.ai/note/abc123#kL8mN4...
- Server menerima ID catatan dan muatan terenkripsi.
- Server tidak menerima kunci dekripsi.
- Hapus setelah dibaca dan kedaluwarsa membatasi berapa lama catatan terenkripsi ada.
PrivateNote melengkapi penyimpanan rahasia khusus — menutup celah saat Anda perlu mengirim kunci Stripe kepada mitra integrasi, membagikan kunci OpenAI sementara kepada kontraktor, atau memberi rekan tim akses sekali pakai ke kredensial pra-produksi.
Pertanyaan yang sering diajukan
Mengapa tidak cukup memakai variabel lingkungan?
Variabel lingkungan baik untuk menjalankan perangkat lunak lokal. Variabel itu tidak menyelesaikan masalah pengiriman saat Anda perlu menyerahkan nilai itu kepada rekan tim, kontraktor, klien, atau mitra integrasi.
Haruskah kunci API selalu kedaluwarsa?
Jika penyedia mendukungnya, ya. Kredensial berumur singkat mempersempit jendela penyalahgunaan setelah pengungkapan yang tidak disengaja dan menjadikan rotasi bagian dari alur kerja biasa.
Apa alur kerja yang paling aman?
Buat kunci dengan cakupan sempit, kirim melalui tautan sekali pakai yang dienkripsi di browser, bagikan kata sandi opsional melalui saluran terpisah, lalu rotasi atau cabut kunci saat tugas selesai. Untuk kunci berisiko tinggi atau berumur panjang, enkripsi secara lokal dengan age atau OpenSSL terlebih dahulu dan unggah hanya teks sandi.
Apakah PrivateNote pengelola rahasia?
Tidak. PrivateNote menyelesaikan pengiriman aman dari manusia ke manusia. Untuk penyimpanan rahasia mesin ke mesin, gunakan HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, atau Azure Key Vault.
Intinya
Sebagian besar kebocoran kunci API tidak terjadi karena kriptografi gagal. Kebocoran terjadi karena seseorang menyalin rahasia ke sistem permanen yang dapat dicari demi kenyamanan. Batasi cakupan kunci dengan ketat, bagikan hanya saat perlu, dan hindari meninggalkan jejak teks biasa di obrolan, tiket, email, atau Git. Untuk sisi jalur pengiriman—.env yang di-commit, log CI, dan riwayat GitHub—lihat [rahasia di CI/CD, file .env, dan GitHub](blog:secrets-in-cicd-env-github-leaks).
Bagikan kunci API tanpa meninggalkannya di obrolan
Buat tautan PrivateNote yang dienkripsi di browser dan dihapus setelah dibaca. Akun tidak diperlukan untuk catatan sekali pakai.
Buat PrivateNote ->
