Wawancara Backend: Bagaimana Cara Mendesain Autentikasi API Key yang Aman?

Perintah dan Skenario yang Berlaku

Sebuah platform B2B multi-tenant mengekspos API server-ke-server. Setiap pelanggan dapat membuat beberapa kunci untuk integrasi yang berbeda. Sistem memerlukan lingkungan live dan test yang terpisah, izin berlingkup, kuota per-kunci dan per-tenant, kedaluwarsa opsional, rotasi zero-downtime, dan pencabutan cepat setelah terjadi kompromi keamanan.

Rancang jalur penerbitan (issuance), penyimpanan, verifikasi, otorisasi, rotasi, pencabutan, dan audit. Jelaskan juga kapan API key menjadi kredensial yang salah. Klien adalah server tepercaya yang mampu melindungi rahasia; aplikasi browser dan seluler berada di luar model kredensial ini.

Desain harus mempertahankan lima invarian:

1. Rahasia lengkap hanya ditampilkan sekali dan tidak pernah disimpan atau dicatat dalam log dalam bentuk plaintext.
2. Kunci yang valid mengidentifikasi principal mesin, tetapi tidak secara otomatis mengotorisasi setiap tindakan.
3. Kunci hanya dimiliki oleh tepat satu tenant dan satu lingkungan.
4. Pencabutan mulai berlaku dalam target propagasi yang terdefinisi dan dapat diuji.
5. Rotasi dapat menumpuk kunci lama dan baru secara tumpang tindih (overlap) tanpa menyembunyikan kredensial mana yang membuat permintaan.

Hal yang Dievaluasi oleh Pewawancara

Sinyal pertama adalah apakah kandidat memisahkan autentikasi dari otorisasi. Memverifikasi rahasia membuktikan principal API-key mana yang mengirimkan permintaan. Layanan tetap harus menegakkan cakupan (scopes), kebijakan endpoint, kepemilikan sumber daya, dan isolasi tenant.

Yang kedua adalah penanganan rahasia (secret handling). Jawaban yang kuat menghasilkan rahasia buram (opaque) dengan entropi tinggi menggunakan generator acak yang aman secara kriptografi, menampilkannya sekali, hanya menyimpan pemverifikasi (verifier), menyensornya (redact) di semua tempat, dan menyimpan pepper sisi server dalam pengelola rahasia (secret manager) khusus.

Yang ketiga adalah desain siklus hidup (lifecycle). Kunci memerlukan nama, lingkungan, status, kedaluwarsa, cakupan, atribusi, rotasi, dan pencabutan. Memperlakukan kunci sebagai satu string database permanen membuat operator menghadapi pembagian yang tidak aman dan penggantian yang mengganggu sistem.

Yang keempat adalah penalaran operasional. Cache, pembatasan laju (rate limits), log, respons insiden, dan ketersediaan semuanya memengaruhi batasan keamanan. "Pencabutan segera" tidaklah benar jika cache edge menerima kunci yang dicabut selama sepuluh menit.

Terakhir, kandidat harus menolak penggunaan API key untuk klien yang tidak tepercaya dan operasi yang cukup sensitif. Rahasia bearer statis yang disalin ke dalam kode frontend dapat dipulihkan oleh pengguna dan penyerang. Alur kerja bernilai tinggi atau yang didelegasikan pengguna mungkin memerlukan kredensial beban kerja (workload) berumur pendek, OAuth, mutual TLS, penandatanganan permintaan (request signing), atau kontrol step-up.

Pertanyaan Klarifikasi Sebelum Menjawab

• Siapa yang memegang kredensial? Layanan backend dapat melindungi rahasia; browser, aplikasi seluler, biner desktop, atau repositori publik tidak dapat menjamin kerahasiaan.
• Apa yang diwakili oleh kunci? Tentukan apakah kunci mewakili integrasi tenant, beban kerja internal, atau manusia. Desain ini menggunakan principal mesin milik tenant, bukan sesi pengguna akhir.
• Seberapa sensitif operasinya? Analisis read-only dan pemindahan uang tidak memerlukan kontrol yang identik.
• Apa target pencabutan dan ketersediaannya? Pilih target propagasi yang dapat diukur dan tentukan bagaimana perilaku autentikasi jika penyimpanan kunci utama tidak tersedia.
• Bagaimana lingkungan diisolasi? Kunci test dan live memerlukan prefiks, batasan data, izin, dan kuota yang berbeda.
• Seberapa terperinci (granular) izinnya? Tetapkan cakupan umum (coarse scopes) ditambah otorisasi tingkat sumber daya; hindari bahasa kebijakan kustom tanpa batas kecuali produk membutuhkannya.
• Berapa banyak kunci yang dapat dibuat oleh tenant? Batasan mencegah penumpukan kunci yang tak terkendali (sprawl) dan menghentikan pelanggan melewati kuota per-kunci dengan mencetak kredensial tanpa batas.
• Aturan audit dan kepatuhan apa yang berlaku? Retensi, atribusi pembuat, data penggunaan terakhir, persetujuan, dan akses darurat mungkin diatur oleh regulasi.

Kerangka Jawaban 30 Detik

"Saya akan menerbitkan kunci dengan ID publik yang dapat dicari dan rahasia acak buram, seperti ak_live_7F3KQ2.m8…Vw. Nilai lengkap dikembalikan sekali. Database menyimpan ID publik, tenant, lingkungan, cakupan, status, kedaluwarsa, dan verifier dengan kunci pengaman (keyed verifier), bukan rahasia plaintext.

Pada setiap permintaan TLS, gateway mengekstrak kunci dari header, menemukan baris berdasarkan ID publik, menghitung ulang verifier, membandingkannya dalam waktu konstan (constant time), serta memeriksa status dan kedaluwarsa. Gateway kemudian membuat konteks principal mesin. Cakupan endpoint dan kepemilikan tenant diperiksa secara terpisah. Batas laju berlaku untuk kunci dan tenant, dan log audit hanya berisi ID publik.

Untuk rotasi, buat kunci kedua, terapkan, amati penggunaan kedua ID, lalu cabut kunci lama. Kebocoran memicu pencabutan segera tanpa masa tenggang, peninjauan log, dan penggantian. Pencabutan membatalkan cache dalam target yang ditentukan. Saya akan menggunakan kredensial yang lebih kuat atau berumur pendek untuk klien publik, delegasi pengguna, dan tindakan bernilai tinggi."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Memodelkan identitas dan catatan kunci

Jadikan setiap kunci sebagai principal mesin yang berbeda. Jangan membagikan satu rahasia seluruh tenant ke setiap integrasi. Catatan yang praktis adalah:

ApiKey(
  key_id, tenant_id, environment, name, verifier,
  verifier_version, scopes, status, expires_at,
  created_at, created_by, last_used_at
)

key_id bersifat publik dan dapat dicari. name membantu operator membedakan "ekspor penagihan" dari "sinkronisasi gudang". status mendukung setidaknya status aktif dan dicabut; kedaluwarsa dievaluasi secara independen. created_by dan perkiraan last_used_at meningkatkan atribusi. Jangan memperbarui last_used_at secara sinkron pada setiap permintaan: hal itu menciptakan hotspot penulisan. Agregasikan atau lakukan sampling secara asinkron jika presisi tingkat menit sudah cukup.

Cakupan (scopes) mendeskripsikan kapabilitas umum seperti invoices:read. Cakupan tidak menggantikan otorisasi sumber daya. Setelah menerima kunci, permintaan untuk faktur 123 masih memerlukan kueri yang dibatasi oleh tenant_id yang diautentikasi. Jangan pernah menerima tenant yang disediakan pemanggil sebagai otoritas.

Langkah 2: Buat sekali, tampilkan sekali, simpan verifier

Hasilkan rahasia acak 32-byte dengan generator acak yang aman secara kriptografi. Ini adalah pilihan desain konkret, bukan persyaratan protokol universal. Enkodekan dalam alfabet yang aman untuk transportasi dan gabungkan dengan prefiks yang dapat dikenali serta ID publik:

ak_live_7F3KQ2.m8...opaque-secret...Vw

Prefiks memungkinkan alat dukungan mengidentifikasi jenis kredensial dan lingkungan tanpa mengekspos rahasia. Kembalikan kunci lengkap hanya dalam respons pembuatan yang berhasil. UI harus menyatakan bahwa kunci tidak dapat dipulihkan; kehilangannya berarti harus membuat pengganti.

Simpan HMAC-SHA-256(server_pepper, complete_secret) sebagai verifier. Pepper tetap berada di secret manager, terpisah dari database. Digest SHA-256 biasa sudah cukup baik untuk token yang benar-benar acak; keyed verifier menambahkan pertahanan berlapis (defense in depth) jika hanya database yang terekspos. Berikan versi pada verifier sehingga layanan dapat memigrasikan algoritma atau pepper. Migrasi pepper harus mendukung verifikasi ganda terbatas atau rencana penerbitan ulang kunci yang terencana; membatalkan setiap kunci pelanggan secara diam-diam tidak dapat diterima.

Pembuatan adalah tindakan manajemen yang diautentikasi. Terapkan peran tenant, batas jumlah kunci, cakupan yang diizinkan, lingkungan, kebijakan kedaluwarsa, dan persetujuan apa pun yang diperlukan sebelum menghasilkan rahasia. Simpan catatan dan kembalikan rahasia melalui respons yang tidak pernah di-cache. Sensor header otorisasi dan badan respons pada lapisan aplikasi, proxy, pelacakan (tracing), pelaporan kesalahan, dan alat dukungan.

Langkah 3: Mengautentikasi permintaan tanpa memperluas wewenang

Wajibkan TLS dan terima kunci dalam header otorisasi atau header khusus, tidak pernah dalam query string URL. URL biasanya terekam dalam riwayat, analitik, log proxy, dan data perujuk (referrer). Pisahkan dan validasi formatnya, gunakan ID publik untuk pencarian terindeks, dan tolak input yang salah format sebelum melakukan pekerjaan berat.

Untuk baris kandidat, hitung ulang verifier dan gunakan perbandingan waktu konstan (constant-time comparison). Kemudian periksa lingkungan, status aktif, dan kedaluwarsa. Kembalikan kesalahan eksternal generik yang sama untuk kunci yang tidak dikenal, salah format, kedaluwarsa, dan dicabut sehingga endpoint tidak menjadi oracle enumerasi kunci. Secara internal, catat kode alasan yang aman tanpa menyertakan rahasia.

Verifikasi yang berhasil menciptakan konteks yang berisi key_id, tenant_id, lingkungan, dan cakupan. Kebijakan rute memeriksa cakupan yang diperlukan; lapisan data membatasi akses ke tenant dan sumber daya tersebut. Endpoint administratif atau bernilai tinggi dapat menolak principal API-key sepenuhnya atau memerlukan kontrol tambahan.

Langkah 4: Batasi penyalahgunaan dengan kuota berlapis dan pemantauan

Pembatasan laju tidak membuktikan identitas, tetapi membatasi kerusakan dari kredensial yang dicuri atau bermasalah. Terapkan batas lonjakan (burst) dan batas berkelanjutan per kunci, ditambah batas agregat tenant. Lapisan tenant mencegah pelanggan melipatgandakan kapasitas dengan membuat banyak kunci. Endpoint yang mahal mungkin memerlukan anggaran berbobot biaya dan batas konkurensi terpisah.

Catat ID kunci publik, tenant, rute, keputusan, latensi, metadata jaringan sumber yang diizinkan oleh kebijakan, dan ID korelasi permintaan. Jangan pernah mencatat kunci lengkap, verifier, atau header otorisasi yang dapat digunakan kembali. Buat peringatan untuk geografi yang tidak biasa atau perubahan jaringan, lonjakan kegagalan mendadak, lonjakan penolakan cakupan, kunci tidak aktif yang menjadi aktif, dan lalu lintas setelah pemberitahuan rotasi. Ini adalah sinyal investigasi, bukan bukti otomatis terjadinya kompromi.

Batasi endpoint manajemen kunci lebih ketat daripada endpoint data biasa. Endpoint tersebut layak mendapatkan autentikasi manusia yang kuat, perlindungan CSRF untuk konsol berbasis cookie, otorisasi eksplisit, peristiwa audit, batas pembuatan, dan kemungkinan reautentikasi atau persetujuan.

Langkah 5: Rekonsiliasi caching dengan pencabutan cepat

Pencarian verifikasi terindeks itu sederhana dan memberi database keputusan otoritatif, tetapi volume permintaan yang sangat tinggi dapat membenarkan penggunaan cache. Cache hanya verifier dan metadata otorisasi minimal di bawah ID publik, enkripsi transportasi, dan batasi jumlah entri. Jangan pernah menyimpan rahasia yang diserahkan ke dalam cache.

Pencabutan menulis status otoritatif terlebih dahulu dan memublikasikan pembatalan ke gateway. TTL pendek adalah cadangan jika pembatalan hilang. Produk harus menyatakan target yang dapat diukur—untuk skenario ini, kunci yang dicabut berhenti mengautentikasi di setiap gateway dalam waktu lima detik—dan mengujinya dalam kondisi kehilangan paket dan restart node. TTL sepuluh menit tidak dapat mendukung janji tersebut.

Pilih perilaku kegagalan berdasarkan risiko. Untuk penulisan sensitif, kegagalan mendapatkan status kunci yang cukup baru harus berstatus fail closed. Untuk pembacaan berisiko rendah tertentu, entri cache yang valid sebelumnya dan sedikit usang (stale) dapat menjadi kompromi ketersediaan eksplisit, tetapi ini melanggar pencabutan segera yang ketat dan tidak boleh dijadikan sebagai perilaku default.

Langkah 6: Rotasi dan pencabutan sebagai alur kerja yang berbeda

Rotasi rutin membutuhkan tumpang tindih (overlap):

1. Buat kunci baru dengan hak istimewa tidak lebih dari kunci lama.
2. Kirimkan melalui jalur manajemen rahasia pelanggan.
3. Terapkan dan lakukan uji canary pada kunci baru.
4. Amati permintaan berdasarkan ID kunci publik sampai kunci lama tidak lagi aktif.
5. Cabut kunci lama dan verifikasi bahwa tidak ada lalu lintas yang masih bergantung padanya.

Jangan mengubah rahasia lama di tempat (in-place); dua ID terpisah mempertahankan atribusi dan rollback selama migrasi. Kedaluwarsa dapat menegakkan masa pakai maksimum, tetapi kedaluwarsa paksa tanpa telemetri adopsi menciptakan pemadaman (outages) yang seharusnya dapat dihindari.

Dugaan kebocoran mengikuti urutan yang berbeda: cabut terlebih dahulu tanpa masa tenggang, batalkan cache, identifikasi tenant, cakupan, rute, dan jendela waktu yang terpengaruh, tinjau bukti audit, terbitkan pengganti berhak istimewa paling rendah (least-privilege), dan perbaiki sumber kebocoran. Menghapus baris secara langsung dapat menghilangkan bukti insiden yang berguna; simpan metadata non-rahasia sesuai kebijakan.

Langkah 7: Ketahui kapan API key tidak memadai

API key adalah kredensial bearer: kepemilikan sudah cukup untuk menggunakannya. Kunci ini tidak membuktikan bahwa pemanggil masih berjalan pada beban kerja yang diharapkan, tidak memberikan persetujuan pengguna akhir, atau mencegah replay dengan sendirinya. Jangan pernah menyematkan kunci rahasia dalam JavaScript browser, biner seluler, kode sampel, image kontainer, atau repositori.

Untuk beban kerja cloud, prioritaskan identitas beban kerja berumur pendek jika tersedia. Untuk akses yang didelegasikan pengguna, gunakan protokol otorisasi dengan persetujuan sempit dan token yang dapat kedaluwarsa. Untuk panggilan antar-layanan yang sangat sensitif, pertimbangkan mutual TLS atau penandatanganan permintaan sehingga nilai database yang disalin saja tidak cukup. Pilihan yang tepat mengikuti model ancaman; menambahkan setiap mekanisme ke setiap API hanya menciptakan kompleksitas operasional.

Langkah 8: Uji keamanan, siklus hidup, dan mode kegagalan

Bangun matriks adversarial yang mencakup:

1. prefiks salah format, ID tidak dikenal, rahasia salah, dan penanganan verifier waktu konstan;
2. kunci kedaluwarsa, dicabut, test-in-live, dan cakupan tidak mencukupi;
3. akses objek lintas-tenant setelah autentikasi yang sebenarnya valid;
4. penyensoran rahasia pada output proxy, aplikasi, trace, error, dan audit;
5. tumpang tindih rotasi, telemetri penggunaan kunci lama, kedaluwarsa, dan pencabutan darurat;
6. entri cache usang, pembatalan yang hilang, restart gateway, dan pemadaman penyimpanan kunci;
7. penegakan kuota per-kunci dan per-tenant, termasuk banyak kunci dari satu tenant;
8. pembuatan bersamaan, pencabutan selama permintaan sedang berjalan (in-flight), dan panggilan manajemen duplikat.

Pindai juga repositori dan konfigurasi deployment untuk mencari prefiks kunci yang dapat dikenali. Detektor adalah alat bantu pemulihan, bukan izin untuk menaruh rahasia di kontrol sumber. Verifikasi simulasi insiden dengan kunci uji: ukur waktu dari konfirmasi pencabutan hingga penolakan di setiap gateway dan konfirmasikan bahwa log mempertahankan atribusi tanpa menyimpan rahasia.

Contoh Jawaban yang Kuat

"Saya akan memperlakukan setiap API key sebagai principal mesin bernama yang dimiliki oleh satu tenant dan satu lingkungan. Nilai yang diterbitkan berisi ID pencarian publik dan rahasia acak buram. Saya mengembalikannya sekali melalui TLS, menyimpan keyed verifier ditambah metadata siklus hidup, dan menyensor nilai lengkap dari setiap lapisan pencatatan dan pelacakan.

Gateway mencari ID publik, menghitung ulang verifier, membandingkannya dalam waktu konstan, serta memeriksa lingkungan, status, dan kedaluwarsa. Penerimaan menghasilkan konteks dengan tenant dan cakupan; setiap rute tetap memeriksa cakupannya, dan setiap kueri data tetap menegakkan kepemilikan tenant. Batas per-kunci mengisolasi satu integrasi, sementara batas tenant menghentikan penggandaan kuota.

Jika metadata verifikasi di-cache, pencabutan memperbarui sumber kebenaran (source of truth) dan mendorong pembatalan, dengan TTL pendek sebagai cadangan. Saya akan menentukan dan menguji target pencabutan lima detik. Rotasi rutin membuat kunci kedua, melakukan canary, mengamati kedua ID publik, lalu mencabut kunci lama. Dugaan kebocoran melewati masa tenggang: cabut, selidiki cakupan kunci dan jendela aktivitas, terbitkan pengganti yang lebih sempit, dan perbaiki sumber paparan.

Saya tidak akan menggunakan rahasia statis ini di browser atau aplikasi seluler, sebagai identitas pengguna akhir, atau sebagai satu-satunya kontrol untuk tindakan bernilai tinggi. Kasus-kasus tersebut memerlukan kredensial yang didelegasikan, berumur pendek, terikat beban kerja, atau yang lebih kuat."

Kesalahan Umum

• Menyimpan kunci dalam bentuk plaintext agar dapat ditampilkan lagi. Kemudahan pemulihan mengubah pembacaan database menjadi pengungkapan kredensial. Tampilkan sekali dan dukung pembuatan pengganti.
• Hanya menggunakan hash global tanpa metadata siklus hidup. Verifikasi saja tidak dapat menjawab pertanyaan terkait tenant, lingkungan, cakupan, kedaluwarsa, atribusi, atau pencabutan.
• Menempatkan kunci dalam query string. URL secara rutin disalin dan dicatat. Gunakan header melalui TLS.
• Memperlakukan cakupan sebagai otorisasi tenant. invoices:read tidak membuktikan bahwa faktur 123 adalah milik tenant yang diautentikasi.
• Memberikan satu kunci tenant bersama untuk setiap integrasi. Kebocoran kemudian memiliki radius dampak yang lebih besar dan atribusi menjadi ambigu.
• Menerapkan rate limiting hanya per kunci. Tenant dapat membuat atau merotasi beberapa kunci dan melipatgandakan lalu lintas yang diizinkan.
• Mengklaim pencabutan segera padahal menggunakan cache selama beberapa menit. Nyatakan target propagasi, batalkan secara aktif, dan uji kegagalan cache.
• Melakukan rotasi dengan menimpa rahasia. Ini menghilangkan tumpang tindih, atribusi, canarying, dan jalur rollback yang bersih.
• Menggunakan rahasia statis di klien publik. Obfuskasi tidak dapat menciptakan batasan penyimpanan rahasia yang aman.
• Mencatat kredensial dalam log untuk mendebug autentikasi. Catat ID publik dan kode alasan yang aman; jangan pernah mencatat rahasia yang dapat digunakan kembali.

Pertanyaan Lanjutan dan Jawabannya

Mengapa menggunakan ID publik ditambah rahasia daripada melakukan hashing pada seluruh kunci dan memindai setiap baris?

ID publik memberikan pencarian terindeks, pengidentifikasi dukungan yang aman, dan atribusi yang berguna. Rahasia tetap menjadi bukti verifikasi. Memindai setiap verifier lambat dan mendorong pencatatan log yang berbahaya atau indeks sekunder. ID publik sengaja dibuat tidak rahasia, sehingga mengetahuinya tidak boleh membantu menurunkan rahasia.

Apakah fungsi hash cepat aman untuk verifier API key?

Itu bisa aman jika rahasia memiliki keacakan kriptografi yang cukup, karena tidak seperti kata sandi manusia, rahasia tidak diambil dari kamus yang dapat ditebak. Keyed HMAC menambahkan perlindungan saat database terekspos tanpa pepper yang terpisah. Hash kata sandi tetap menjadi alat yang tepat untuk kata sandi yang dipilih manusia; model ancamannya berbeda.

Bagaimana cara merotasi pepper di sisi server?

Simpan versi verifier pada setiap baris. Selama migrasi terbatas, verifier dapat memilih pepper lama atau baru, dan kunci versi lama yang berhasil diautentikasi dapat diverifikasi ulang di bawah versi baru jika rahasia yang diserahkan tersedia di memori. Pilihan lain adalah penerbitan ulang kunci pelanggan yang terjadwal. Jangan pernah menghapus pepper lama sebelum semua verifier yang bergantung telah dimigrasikan atau kedaluwarsa.

Haruskah last_used_at bersifat presisi?

Biasanya tidak. Memperbarui satu baris pada setiap permintaan menambah beban penulisan dan pertikaian (contention). Kirim peristiwa penggunaan sampel atau agregat dan perbarui secara berkala. Peristiwa audit keamanan dapat tetap berstatus append-only di lapisan permintaan, sementara UI manajemen melabeli last_used_at sebagai perkiraan.

Bagaimana Anda menangani persaingan (racing) pencabutan dengan permintaan yang sedang berjalan?

Tentukan batasannya secara eksplisit. Autentikasi dapat menjamin bahwa permintaan yang dimulai setelah propagasi akan ditolak. Operasi sensitif dapat memeriksa ulang otorisasi sebelum melakukan commit atau mengikat status kunci yang diautentikasi ke dalam kebijakan yang sadar transaksi. Pencabutan tidak dapat menghapus operasi yang telah di-commit secara retroaktif, sehingga respons insiden harus memeriksa jendela waktu tersebut.

Haruskah kunci kedaluwarsa secara otomatis?

Kedaluwarsa membatasi paparan tanpa batas waktu, tetapi ini bukan pengganti rotasi atau pencabutan. Platform harus memberi tahu pemilik, memperlihatkan penggunaan kunci lama, memungkinkan tumpang tindih yang aman, dan menolak setelah batas waktu. Masa pakai maksimum yang tepat bergantung pada risiko dan apakah kredensial berumur pendek yang lebih baik tersedia.

Apakah IP allowlisting menyelesaikan masalah pencurian kunci?

Ini adalah pembatasan tambahan opsional untuk pelanggan dengan alamat egress yang stabil. Ini tidak menggantikan verifikasi rahasia, dan dapat menyebabkan pemadaman atau rasa percaya diri palsu saat jaringan berubah atau proxy digunakan bersama. Perlakukan ini sebagai salah satu sinyal atau lapisan kebijakan, bukan akar dari identitas.

Apa yang harus dimuat dalam respons create-key?

Kembalikan kunci lengkap sekali, ID publik atau prefiksnya, nama, lingkungan, cakupan, kedaluwarsa, dan metadata pembuatan. Tandai respons sebagai non-cacheable dan jangan pernah mengembalikan verifier atau pepper. API daftar (list API) selanjutnya hanya mengembalikan pengidentifikasi publik dan metadata.