Temu Duga Backend: Bagaimana Anda Mereka Bentuk Pengesahan Kunci API yang Selamat?

Prompt dan Senario yang Berkenaan

Sebuah platform B2B berbilang penyewa mendedahkan API pelayan-ke-pelayan. Setiap pelanggan boleh mencipta beberapa kunci untuk integrasi yang berbeza. Sistem ini memerlukan persekitaran langsung dan ujian yang berasingan, kebenaran berskop, kuota bagi setiap kunci dan setiap penyewa, tarikh luput pilihan, penggiliran tanpa masa henti, dan pembatalan pantas selepas berlaku kompromi.

Reka bentuk laluan pengeluaran, penyimpanan, pengesahan identiti (verification), pengesahan kebenaran (authorization), penggiliran, pembatalan, dan audit. Terangkan juga situasi di mana kunci API merupakan bukti kelayakan (credential) yang salah. Klien ialah pelayan dipercayai yang berupaya melindungi rahsia; aplikasi pelayar dan mudah alih berada di luar model bukti kelayakan ini.

Reka bentuk ini mesti mengekalkan lima varian kekal (invariants):

1. Rahsia lengkap hanya dipaparkan sekali dan tidak sekali-kali disimpan atau dilog dalam teks biasa (plaintext).
2. Kunci yang sah mengenal pasti prinsipal mesin, tetapi tidak membenarkan setiap tindakan secara automatik.
3. Kunci adalah milik tepat satu penyewa dan satu persekitaran.
4. Pembatalan berkuat kuasa dalam sasaran penyebaran (propagation target) yang ditetapkan dan boleh diuji.
5. Penggiliran boleh bertindih antara kunci lama dan baharu tanpa menyembunyikan bukti kelayakan mana yang membuat permintaan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon memisahkan pengesahan identiti (authentication) daripada pengesahan kebenaran (authorization). Pengesahan rahsia menetapkan prinsipal kunci API mana yang menghantar permintaan. Perkhidmatan masih mesti menguatkuasakan skop, dasar titik akhir (endpoint), pemilikan sumber, dan pengasingan penyewa.

Perkara kedua ialah pengendalian rahsia. Jawapan yang kukuh menjana rahsia legap berentropi tinggi menggunakan penjana rawak selamat secara kriptografi, memaparkannya sekali, hanya menyimpan penentusah (verifier), menyunting/mengaburkannya di semua tempat, dan menyimpan sebarang pepper bahagian pelayan dalam pengurus rahsia khas.

Perkara ketiga ialah reka bentuk kitaran hayat. Kunci memerlukan nama, persekitaran, status, tarikh luput, skop, atribusi, penggiliran, dan pembatalan. Menganggap kunci sebagai satu rentetan pangkalan data kekal mendedahkan pengendali kepada perkongsian yang tidak selamat dan penggantian yang mengganggu perkhidmatan.

Perkara keempat ialah penaakulan operasi. Cache, had kadar (rate limits), log, tindak balas insiden, dan ketersediaan semuanya mempengaruhi sempadan keselamatan. "Pembatalan segera" tidak benar jika cache pinggir (edge cache) menerima kunci yang dibatalkan selama sepuluh minit.

Akhir sekali, calon harus menolak penggunaan kunci API untuk klien yang tidak dipercayai dan operasi yang cukup sensitif. Rahsia pembawa (bearer secret) statik yang disalin ke dalam kod frontend boleh dipulihkan oleh pengguna dan penyerang. Aliran kerja bernilai tinggi atau yang didelegasikan oleh pengguna mungkin memerlukan bukti kelayakan beban kerja (workload) jangka pendek, OAuth, mutual TLS, pemeteraian permintaan (request signing), atau kawalan bertingkat (step-up controls).

Soalan Penjelasan Sebelum Menjawab

• Siapakah pemegang bukti kelayakan? Perkhidmatan backend boleh melindungi rahsia; pelayar, aplikasi mudah alih, binari desktop, atau repositori awam tidak dapat menjamin kerahsiaan.
• Apakah yang diwakili oleh kunci? Tentukan sama ada ia mewakili integrasi penyewa, beban kerja dalaman, atau manusia. Reka bentuk ini menggunakan prinsipal mesin milik penyewa, bukan sesi pengguna akhir.
• Sejauh manakah sensitifnya operasi tersebut? Analitis baca sahaja dan pemindahan wang tidak wajar menerima kawalan yang serupa.
• Apakah sasaran pembatalan dan ketersediaan? Pilih sasaran penyebaran yang boleh diukur dan tentukan cara pengesahan berkelakuan jika stor kunci utama tidak tersedia.
• Bagaimanakah persekitaran diasingkan? Kunci ujian dan langsung memerlukan awalan yang berbeza, sempadan data, kebenaran, dan kuota.
• Sejauh manakah keperincian (granularity) kebenaran? Wujudkan skop kasar ditambah dengan pengesahan kebenaran peringkat sumber; elakkan bahasa dasar tersuai yang tidak terhad melainkan produk memerlukannya.
• Berapa banyakkah kunci yang boleh dicipta oleh penyewa? Had menghalang percambahan kunci (key sprawl) dan menghalang pelanggan daripada memintas kuota bagi setiap kunci dengan menghasilkan bukti kelayakan tanpa had.
• Apakah peraturan audit dan pematuhan yang terpakai? Pengekalan, atribusi pencipta, data penggunaan terakhir, kelulusan, dan akses kecemasan mungkin dikawal selia.

Rangka Kerja Jawapan 30 Saat

"Saya akan mengeluarkan kunci dengan ID awam yang boleh dicari dan rahsia rawak legap, seperti ak_live_7F3KQ2.m8…Vw. Nilai lengkap dikembalikan sekali sahaja. Pangkalan data menyimpan ID awam, penyewa, persekitaran, skop, status, tarikh luput, dan penentusah berkunci (keyed verifier), bukan rahsia teks biasa sama sekali.

Pada setiap permintaan TLS, get laluan (gateway) mengekstrak kunci daripada pengepala, mencari baris mengikut ID awam, mengira semula penentusah, membandingkannya dalam masa malar (constant time), dan menyemak status serta tarikh luput. Ia kemudian mencipta konteks prinsipal mesin. Skop titik akhir dan pemilikan penyewa disemak secara berasingan. Had kadar dikenakan pada kedua-dua kunci dan penyewa, dan log audit hanya mengandungi ID awam.

Untuk penggiliran, cipta kunci kedua, gunakannya, perhatikan penggunaan kedua-dua ID, kemudian batalkan kunci lama. Kebocoran mencetuskan pembatalan segera tanpa tempoh tangguh, semakan log, dan penggantian. Pembatalan membatalkan cache dalam sasaran yang diisytiharkan. Saya akan menggunakan bukti kelayakan yang lebih kukuh atau jangka pendek untuk klien awam, delegasi pengguna, dan tindakan bernilai tinggi."

Perbincangan Mendalam Langkah demi Langkah

Langkah 1: Modelkan identiti dan rekod kunci

Jadikan setiap kunci sebagai prinsipal mesin yang berbeza. Jangan kongsi satu rahsia peringkat penyewa merentasi setiap integrasi. Rekod praktikal ialah:

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

key_id adalah awam dan boleh dicari. name membantu pengendali membezakan "billing export" daripada "warehouse sync." status menyokong sekurang-kurangnya status aktif dan dibatalkan; tarikh luput dinilai secara berasingan. created_by dan anggaran last_used_at menambah baik atribusi. Jangan kemas kini last_used_at secara segerak (synchronously) pada setiap permintaan: ini mencipta titik panas penulisan (write hot spot). Kumpulkan atau sampelkannya secara tidak segerak apabila ketepatan tahap minit sudah mencukupi.

Skop menerangkan keupayaan kasar seperti invoices:read. Ia tidak menggantikan pengesahan kebenaran sumber. Selepas menerima kunci, permintaan untuk invois 123 masih memerlukan pertanyaan yang dihadkan oleh tenant_id yang disahkan. Jangan sekali-kali menerima penyewa yang dibekalkan oleh pemanggil sebagai pihak berkuasa.

Langkah 2: Jana sekali, dedahkan sekali, simpan penentusah

Jana rahsia rawak 32 bait dengan penjana rawak selamat secara kriptografi. Ini adalah pilihan reka bentuk konkrit, bukan keperluan protokol sejagat. Enkodkannya dalam abjad yang selamat untuk pengangkutan dan gabungkannya dengan awalan yang boleh dikenali serta ID awam:

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

Awalan ini membolehkan alat sokongan mengenal pasti jenis bukti kelayakan dan persekitaran tanpa mendedahkan rahsia tersebut. Kembalikan kunci lengkap hanya dalam respons penciptaan yang berjaya. UI mesti menyatakan bahawa ia tidak boleh dipulihkan; kehilangannya bermakna penggantian perlu dicipta.

Simpan HMAC-SHA-256(server_pepper, complete_secret) sebagai penentusah. Pepper kekal dalam pengurus rahsia, berasingan daripada pangkalan data. Ringkasan SHA-256 biasa boleh digunakan untuk token yang cukup rawak; penentusah berkunci menambah pertahanan berlapis (defense in depth) jika hanya pangkalan data yang terdedah. Versikan penentusah supaya perkhidmatan boleh memindahkan algoritma atau pepper. Migrasi pepper mesti menyokong pengesahan dwi berbatas atau pelan pengeluaran semula kunci yang disengajakan; membatalkan setiap kunci pelanggan secara senyap adalah tidak boleh diterima.

Penciptaan ialah tindakan pengurusan yang disahkan. Kuat kuasakan peranan penyewa, had bilangan kunci, skop yang dibenarkan, persekitaran, dasar tarikh luput, dan sebarang kelulusan yang diperlukan sebelum menjana rahsia. Simpan rekod dan kembalikan rahsia melalui respons yang tidak pernah dicache. Sunting pengepala pengesahan kebenaran dan badan respons pada lapisan aplikasi, proksi, penjejakan (tracing), pelaporan ralat, dan alat sokongan.

Langkah 3: Sahkan permintaan tanpa memperluaskan kuasa

Wajibkan TLS dan terima kunci dalam pengepala kebenaran atau pengepala khas, jangan sekali-kali dalam rentetan pertanyaan URL (query string). URL biasanya sampai ke sejarah, analitis, log proksi, dan data perujuk (referrer). Pisahkan dan sahkan format, gunakan ID awam untuk carian terindeks, dan tolak input yang salah format sebelum melakukan kerja yang menggunakan banyak sumber.

Untuk baris calon, kira semula penentusah dan gunakan perbandingan masa malar. Kemudian semak persekitaran, status aktif, dan tarikh luput. Kembalikan ralat luaran generik yang sama untuk kunci yang tidak diketahui, salah format, luput, dan dibatalkan supaya titik akhir tidak menjadi oracle enumerasi kunci. Secara dalaman, rekodkan kod sebab yang selamat tanpa menyertakan rahsia.

Pengesahan yang berjaya mencipta konteks yang mengandungi key_id, tenant_id, persekitaran, dan skop. Dasar laluan menyemak skop yang diperlukan; lapisan data mengehadkan akses kepada penyewa dan sumber tersebut. Titik akhir pentadbiran atau bernilai tinggi boleh menolak prinsipal kunci API sepenuhnya atau memerlukan kawalan tambahan.

Langkah 4: Hadkan penyalahgunaan dengan kuota berlapis dan pemantauan

Pengehadan kadar tidak membuktikan identiti, tetapi ia mengehadkan kerosakan daripada bukti kelayakan yang dicuri atau mengandungi pepijat. Guna pakai had lonjakan (burst) dan mampan (sustained) bagi setiap kunci, serta had agregat penyewa. Lapisan penyewa menghalang pelanggan daripada menggandakan kapasiti dengan mencipta banyak kunci. Titik akhir yang mahal mungkin memerlukan bajet berwajaran kos dan had keserentakan (concurrency limits) yang berasingan.

Log ID kunci awam, penyewa, laluan, keputusan, kependaman, metadata rangkaian sumber yang dibenarkan oleh dasar, dan ID korelasi permintaan. Jangan sekali-kali melog kunci lengkap, penentusah, atau pengepala pengesahan yang boleh diguna semula. Maklumkan tentang geografi luar biasa atau perubahan rangkaian, lonjakan kegagalan mendadak, lonjakan penafian skop, kunci dorman yang menjadi aktif, dan trafik selepas notis penggiliran. Ini adalah isyarat penyiasatan, bukan bukti kompromi automatik.

Sekat titik akhir pengurusan kunci dengan lebih ketat berbanding titik akhir data biasa. Ia wajar menerima pengesahan manusia yang kukuh, perlindungan CSRF untuk konsol berasaskan kuki, pengesahan kebenaran eksplisit, peristiwa audit, had penciptaan, dan kemungkinan pengesahan semula atau kelulusan.

Langkah 5: Selaraskan caching dengan pembatalan pantas

Carian pengesahan terindeks adalah mudah dan memberikan pangkalan data keputusan yang berwibawa, tetapi volum permintaan yang sangat tinggi mungkin mewajarkan penggunaan cache. Hanya simpan penentusah dan metadata pengesahan kebenaran minimum dalam cache di bawah ID awam, enkrip pengangkutan, dan pastikan entri terhad. Jangan sekali-kali menyimpan rahsia yang dikemukakan dalam cache.

Pembatalan menulis status berwibawa terlebih dahulu dan menerbitkan pembatalan tidak sah (invalidations) ke get laluan. TTL pendek adalah sandaran jika pembatalan tidak sah terputus. Produk mesti menyatakan sasaran yang boleh diukur—untuk senario ini, kunci yang dibatalkan berhenti mengesahkan di setiap get laluan dalam masa lima saat—dan mengujinya di bawah senario kehilangan paket dan permulaan semula nod. TTL sepuluh minit tidak dapat menyokong janji tersebut.

Pilih tingkah laku kegagalan mengikut risiko. Bagi operasi penulisan sensitif, kegagalan untuk mendapatkan keadaan kunci yang cukup segar harus gagal secara tertutup (fail closed). Bagi operasi bacaan terpilih yang berisiko rendah, entri cache yang sah sebelumnya yang lapuk seketika mungkin merupakan pertukaran ketersediaan yang eksplisit, tetapi ia melanggar pembatalan segera yang ketat dan tidak boleh diseludup masuk sebagai tetapan lalai.

Langkah 6: Gilir dan batalkan sebagai aliran kerja yang berbeza

Penggiliran rutin memerlukan pertindihan:

1. Cipta kunci baharu tanpa keistimewaan yang lebih daripada kunci lama.
2. Hantarkannya melalui laluan pengurusan rahsia pelanggan.
3. Sebarkan dan lakukan ujian kanari (canary) pada kunci baharu.
4. Perhatikan permintaan mengikut ID kunci awam sehingga kunci lama menjadi senyap.
5. Batalkan kunci lama dan sahkan bahawa tiada trafik yang masih bergantung padanya.

Jangan ubah rahsia lama di tempatnya (in place); dua ID berasingan mengekalkan atribusi dan membolehkan pengembalian semula (rollback) semasa migrasi. Tarikh luput boleh menguatkuasakan jangka hayat maksimum, tetapi tarikh luput yang dipaksa tanpa telemetri penggunaan menimbulkan gangguan perkhidmatan yang boleh dielakkan.

Kebocoran yang disyaki mengikut urutan yang berbeza: batalkan dahulu tanpa tempoh tangguh, batalkan cache, kenal pasti penyewa, skop, laluan, dan tetingkap masa yang terjejas, semak bukti audit, keluarkan pengganti berkeistimewaan paling rendah (least-privilege), dan selesaikan punca kebocoran. Memadam baris serta-merta boleh memadam bukti insiden yang berguna; kekalkan metadata bukan rahsia mengikut dasar.

Langkah 7: Ketahui bila kunci API tidak mencukupi

Kunci API ialah bukti kelayakan pembawa: pemilikan sudah mencukupi untuk menggunakannya. Ia tidak membuktikan pemanggil masih berjalan pada beban kerja yang dijangkakan, memberikan persetujuan pengguna akhir, atau menghalang serangan ulangan (replay) dengan sendirinya. Jangan sekali-kali membenamkan kunci rahsia dalam JavaScript pelayar, binari mudah alih, kod contoh, imej kontena, atau repositori.

Untuk beban kerja awan, utamakan identiti beban kerja jangka pendek jika tersedia. Untuk akses yang didelegasikan pengguna, gunakan protokol pengesahan kebenaran dengan persetujuan sempit dan token yang mempunyai tarikh luput. Untuk panggilan pelayan-ke-pelayan yang amat sensitif, pertimbangkan mutual TLS atau pemeteraian permintaan supaya nilai pangkalan data yang disalin sahaja tidak mencukupi. Pilihan yang betul mengikut model ancaman; menambah setiap mekanisme pada setiap API hanya akan menimbulkan kerumitan operasi.

Langkah 8: Uji keselamatan, kitaran hayat, dan mod kegagalan

Bina matriks persaingan (adversarial matrix) yang merangkumi:

1. awalan salah format, ID tidak diketahui, rahsia salah, dan pengendalian penentusah masa malar;
2. kunci luput, dibatalkan, kunci ujian dalam persekitaran langsung, dan skop tidak mencukupi;
3. akses objek merentas penyewa selepas pengesahan identiti yang sebaliknya sah;
4. penyuntingan rahsia dalam output proksi, aplikasi, surih, ralat, dan audit;
5. pertindihan penggiliran, telemetri penggunaan kunci lama, tarikh luput, dan pembatalan kecemasan;
6. entri cache lapuk, pembatalan tidak sah yang tercicir, permulaan semula get laluan, dan gangguan stor kunci;
7. penguatkuasaan kuota setiap kunci dan setiap penyewa, termasuk banyak kunci daripada satu penyewa;
8. penciptaan serentak, pembatalan semasa permintaan sedang diproses (in-flight), dan panggilan pengurusan pendua.

Imbas juga repositori dan konfigurasi penyebaran untuk mencari awalan kunci yang boleh dikenali. Pengesan ialah alat bantuan pemulihan, bukan kebenaran untuk meletakkan rahsia dalam kawalan sumber. Sahkan latihan insiden dengan kunci ujian: ukur masa dari pengesahan pembatalan hingga penolakan di setiap get laluan dan sahkan bahawa log mengekalkan atribusi tanpa mengekalkan rahsia.

Contoh Jawapan yang Kukuh

"Saya akan menganggap setiap kunci API sebagai prinsipal mesin bernama yang dimiliki oleh satu penyewa dan satu persekitaran. Nilai yang dikeluarkan mengandungi ID carian awam dan rahsia rawak legap. Saya mengembalikannya sekali melalui TLS, menyimpan penentusah berkunci serta metadata kitaran hayat, dan menyunting nilai lengkap daripada setiap lapisan pengelogan dan penjejakan.

Get laluan mencari ID awam, mengira semula penentusah, membandingkannya dalam masa malar, dan menyemak persekitaran, status, serta tarikh luput. Penerimaan menghasilkan konteks dengan penyewa dan skop; setiap laluan masih menyemak skopnya, dan setiap pertanyaan data masih menguatkuasakan pemilikan penyewa. Had bagi setiap kunci membendung satu integrasi, manakala had penyewa menghalang penggandaan kuota.

Jika metadata pengesahan disimpan dalam cache, pembatalan mengemas kini punca kebenaran (source of truth) dan menolak pembatalan tidak sah, dengan TTL pendek sebagai sandaran. Saya akan menentukan dan menguji sasaran pembatalan lima saat. Penggiliran rutin mencipta kunci kedua, melakukan ujian kanari, memerhatikan kedua-dua ID awam, dan kemudian membatalkan kunci lama. Kebocoran yang disyaki melangkau tempoh tangguh: batalkan, siasat skop kunci dan tetingkap aktiviti, keluarkan pengganti yang lebih sempit, dan baiki punca pendedahan.

Saya tidak akan menggunakan rahsia statik ini dalam pelayar atau aplikasi mudah alih, sebagai identiti pengguna akhir, atau sebagai kawalan tunggal untuk tindakan bernilai tinggi. Kes-kes tersebut memerlukan bukti kelayakan yang didelegasikan, jangka pendek, terikat beban kerja, atau lebih kukuh."

Kesilapan Biasa

• Menyimpan kunci teks biasa supaya ia boleh dipaparkan semula. Kemudahan pemulihan mengubah pembacaan pangkalan data menjadi pendedahan bukti kelayakan. Tunjukkan sekali dan sokong penggantian.
• Hanya menggunakan cincangan global tanpa metadata kitaran hayat. Pengesahan semata-mata tidak dapat menjawab persoalan penyewa, persekitaran, skop, tarikh luput, atribusi, atau pembatalan.
• Meletakkan kunci dalam rentetan pertanyaan (query string). URL kerap disalin dan direkodkan. Gunakan pengepala melalui TLS.
• Menganggap skop sebagai pengesahan kebenaran penyewa. invoices:read tidak membuktikan bahawa invois 123 adalah milik penyewa yang disahkan.
• Memberikan satu kunci penyewa yang dikongsi kepada setiap integrasi. Kebocoran kemudiannya mempunyai radius impak (blast radius) yang lebih besar dan atribusi menjadi kabur.
• Pengehadan kadar hanya bagi setiap kunci. Penyewa boleh mencipta atau menggilirkan berbilang kunci dan menggandakan trafik yang dibenarkan.
• Mendakwa pembatalan segera semasa melakukan caching selama beberapa minit. Nyatakan sasaran penyebaran, batalkan secara aktif, dan uji kegagalan cache.
• Menggilir dengan menulis ganti rahsia. Ini menghapuskan pertindihan, atribusi, ujian kanari, dan laluan pengembalian semula yang bersih.
• Menggunakan rahsia statik dalam klien awam. Pengaburan (obfuscation) tidak dapat mewujudkan sempadan penyimpanan sulit.
• Melog bukti kelayakan untuk menyahpepijat pengesahan. Log ID awam dan kod sebab yang selamat; jangan sekali-kali melog rahsia yang boleh diguna semula.

Soalan Susulan dan Jawapan

Mengapa menggunakan ID awam ditambah rahsia dan bukannya mencincang keseluruhan kunci serta mengimbas setiap baris?

ID awam menyediakan carian terindeks, pengecam sokongan yang selamat, dan atribusi yang berguna. Rahsia kekal sebagai bukti. Mengimbas setiap penentusah adalah perlahan dan mendorong pengelogan berbahaya atau indeks sekunder. ID awam sengaja dijadikan bukan rahsia, jadi mengetahuinya tidak boleh membantu mendapatkan rahsia tersebut.

Adakah cincangan pantas selamat untuk penentusah kunci API?

Ia boleh menjadi selamat apabila rahsia mempunyai rawak kriptografi yang mencukupi, kerana tidak seperti kata laluan manusia, ia tidak diambil daripada kamus yang boleh diteka. HMAC berkunci menambah perlindungan jika pangkalan data terdedah tanpa pepper yang berasingan. Cincangan kata laluan kekal sebagai alat yang tepat untuk kata laluan pilihan manusia; model ancamannya berbeza.

Bagaimanakah anda menggilirkan pepper bahagian pelayan?

Simpan versi penentusah dengan setiap baris. Semasa migrasi berbatas, penentusah boleh memilih pepper lama atau baharu, dan kunci versi lama yang berjaya disahkan boleh disahkan semula di bawah versi baharu jika rahsia yang dikemukakan tersedia dalam memori. Pilihan lain ialah pengeluaran semula kunci pelanggan yang dijadualkan. Jangan sekali-kali membuang pepper lama sebelum semua penentusah yang bergantung telah berhijrah atau luput.

Patutkah last_used_at tepat?

Biasanya tidak. Mengemas kini satu baris pada setiap permintaan menambah beban penulisan dan pertikaian (contention). Hantar peristiwa penggunaan yang disampel atau diagregatkan dan kemas kini secara berkala. Peristiwa audit keselamatan mungkin kekal secara tambah sahaja (append-only) pada lapisan permintaan, manakala UI pengurusan melabelkan last_used_at sebagai anggaran.

Bagaimanakah anda mengendalikan pembatalan yang berlumba (racing) dengan permintaan yang sedang diproses?

Tentukan sempadan secara eksplisit. Pengesahan boleh menjamin bahawa permintaan yang bermula selepas penyebaran akan ditolak. Operasi sensitif boleh menyemak semula kebenaran sebelum komit atau mengikat status kunci yang disahkan ke dalam dasar yang peka transaksi. Pembatalan tidak boleh memadamkan operasi yang telah dilakukan secara retroaktif, jadi tindak balas insiden mesti memeriksa tetingkap tersebut.

Patutkah kunci luput secara automatik?

Tarikh luput mengehadkan pendedahan tanpa had, tetapi ia bukan pengganti untuk penggiliran atau pembatalan. Platform harus memberitahu pemilik, mendedahkan penggunaan kunci lama, membenarkan pertindihan yang selamat, dan menolak selepas tarikh akhir. Jangka hayat maksimum yang betul bergantung pada risiko dan sama ada bukti kelayakan jangka pendek yang lebih baik tersedia.

Adakah senarai dibenarkan IP (IP allowlisting) menyelesaikan kecurian kunci?

Ia merupakan sekatan tambahan pilihan untuk pelanggan yang mempunyai alamat keluar (egress) yang stabil. Ia tidak menggantikan pengesahan rahsia, dan ia boleh menyebabkan gangguan atau keyakinan palsu apabila rangkaian berubah atau proksi dikongsi. Anggap ia sebagai satu isyarat atau lapisan dasar, bukan punca identiti.

Apakah yang perlu terkandung dalam respons cipta kunci?

Kembalikan kunci lengkap sekali sahaja, ID awam atau awalannya, nama, persekitaran, skop, tarikh luput, dan metadata penciptaan. Tandakan respons sebagai tidak boleh dicache dan jangan sekali-kali mengembalikan penentusah atau pepper. API penyenaraian seterusnya hanya mengembalikan pengecam awam dan metadata.