Petunjuk dan konteks
Pertanyaan system design ini menguji siklus hidup dan batasan otorisasi kredensial sementara. Tantangannya bukan sekadar membungkus API penandatanganan object storage; melainkan menjaga tautan tetap memiliki kapabilitas terbatas dan dapat dikendalikan saat terjadi kebocoran, pencabutan, rotasi kunci, dan akses multi-region.
Hal yang dievaluasi oleh pewawancara
- Apakah signed URL terikat pada tenant, objek, metode, versi, rentang (range), dan masa berlaku.
- Apakah penandatanganan, otorisasi langsung (live authorization), pencabutan, dan izin penyimpanan dibedakan dengan jelas.
- Apakah rotasi kunci, caching singkat, pengiriman CDN, pembatasan laju (rate limits), dan alur audit telah dirancang.
- Apakah trade-off kebocoran, replay, clock skew, kegagalan regional, dan latensi pencabutan dijelaskan dengan baik.
Pertanyaan klarifikasi yang perlu diajukan
Konfirmasikan unduhan versus unggahan, objek tunggal versus batch, kebutuhan Range dan multipart, masa berlaku maksimum, pencabutan tingkat detik, dan keterlibatan CDN. Tanyakan tentang isolasi tenant, retensi audit, manajemen kunci, pemulihan multi-region, dan semantik versi objek.
Kerangka jawaban 30 detik
Layanan otorisasi pertama-tama memvalidasi pemanggil, lalu menandatangani URL yang terikat pada tenant, versi objek, operasi, kondisi, dan masa berlaku singkat. Tanda tangan mencakup permintaan yang dinormalisasi dan versi kunci; penyimpanan atau edge memverifikasinya. Pencabutan berisiko tinggi menggunakan TTL singkat, deny-list, atau penanda versi yang dicabut. URL hanya memberikan kapabilitas yang diperlukan, sementara peristiwa audit yang tidak dapat diubah (immutable), deteksi replay, rate limit, dan rotasi kunci membatasi risiko.
Pembahasan mendalam langkah demi langkah
1. Menentukan model kredensial dan izin
Sertakan tenant, kunci objek atau ID yang tidak dapat ditebak, versi, metode yang diizinkan, rentang byte, batasan content-type, penerbit, masa berlaku, dan versi kunci. URL unggahan juga membatasi ukuran, checksum, dan awalan tujuan. Server melakukan otorisasi objek secara langsung sebelum menandatangani; klien tidak dapat mengedit parameter untuk memperluas izin.
2. Memilih jalur penandatanganan dan verifikasi
Gunakan HMAC yang kompatibel dengan penyimpanan atau tanda tangan asimetris yang mencakup metode, path, parameter kueri, header penting, dan masa berlaku. Kanonisasikan spasi, pengodean, dan urutan parameter. Pemverifikasi memeriksa rentang waktu, versi kunci, tanda tangan, dan kondisi. Operasi sensitif tetap menggunakan pemeriksaan langsung alih-alih memasukkan setiap keputusan otorisasi ke dalam URL yang berdiri sendiri.
3. Merancang pertahanan pencabutan, rotasi, dan replay
Masa berlaku yang singkat membatasi dampak kebocoran. Untuk tautan bernilai tinggi, Redis atau aturan edge dapat menyimpan token ID, pencabutan versi objek, atau deny-list tenant. Selama rotasi kunci, pertahankan versi lama hingga masa berlaku URL terlama berakhir, lalu hapus. Unggahan sekali pakai dapat memerlukan nonce, status objek, dan penanda penyelesaian; unduhan berulang mengikuti kebijakan bisnis yang eksplisit.
4. Menskalakan penyimpanan, CDN, dan penanganan kegagalan
Jaga agar penerbitan tetap stateless, dengan metadata dan pencabutan berada di penyimpanan dengan ketersediaan tinggi. Kirim byte objek langsung melalui penyimpanan atau CDN alih-alih server aplikasi. Kebijakan CDN harus mencakup batas tanda tangan dan izin sehingga respons privat satu tenant tidak dapat digunakan kembali oleh tenant lain. Jika manajemen kunci atau penyimpanan pencabutan tidak tersedia, lakukan fail closed untuk penerbitan baru dan akses berisiko tinggi; perlakukan tautan berisiko rendah yang sudah diterbitkan sesuai dengan TTL yang terdokumentasi.
5. Mengamati, membatasi laju, dan memverifikasi keamanan
Audit penerbit, tenant, objek, metode, hasil, wilayah, ringkasan sidik jari klien, dan alasan pencabutan tanpa mencatat kueri URL lengkap. Batasi laju penerbitan, total byte, dan konkurensi berdasarkan tenant, pengguna, objek, dan IP; deteksi penggunaan ulang yang anomali. Uji manipulasi parameter, masa berlaku, clock skew, rotasi, keterlambatan pencabutan, akses lintas tenant, hit CDN, dan kegagalan regional.
Contoh jawaban yang kuat
Setelah memvalidasi pemanggil, layanan otorisasi menerbitkan URL yang terikat pada tenant, versi objek yang immutable, metode, kondisi, dan masa berlaku singkat. Tanda tangan mencakup path kanonis, kueri, dan header kritis; penyimpanan atau CDN memverifikasinya, sehingga aplikasi tidak memproksi file besar. Tautan berisiko tinggi mendukung pencabutan melalui TTL singkat, deny-list, atau penanda versi. Pertahankan kunci lama hingga tautan terlama kedaluwarsa. Audit penerbitan dan hasil akses tanpa menyertakan URL lengkap, terapkan rate-limit berdasarkan tenant dan objek, serta uji manipulasi, replay, skew, rotasi, pencabutan, akses lintas tenant, dan isolasi CDN.
Kesalahan umum
- Hanya menandatangani path objek tanpa tenant, metode, versi, atau kondisi unggahan.
- Menganggap URL permanen sebagai mekanisme pencabutan dan tidak memiliki mitigasi kebocoran.
- Langsung menghapus kunci lama saat rotasi sehingga merusak tautan yang masih valid.
- Men-cache konten privat hanya berdasarkan path di CDN dan mengabaikan tanda tangan atau tenant.
- Menuliskan signed URL lengkap ke log, analitik, atau pesan kesalahan.
- Hanya menguji validitas tanda tangan dan melewatkan pengujian manipulasi, replay, clock skew, dan latensi pencabutan.
Pertanyaan lanjutan dan jawaban
Mengapa tidak meletakkan semua otorisasi di dalam JWT?
Signed URL mengikat kondisi ke permintaan sumber daya yang dapat diverifikasi oleh penyimpanan tanpa memproksi byte besar, tetapi ini bukan sistem pencabutan real-time. Hak istimewa berisiko tinggi tetap memerlukan TTL singkat, pencabutan versi, atau pemeriksaan langsung.
Bagaimana pencabutan dapat berlaku dalam hitungan detik?
Minta edge atau pemverifikasi memeriksa deny-list berprioritas tinggi, penanda versi objek, atau status tenant dengan TTL cache yang sangat singkat. Ini meningkatkan beban baca dan konsistensi, jadi terapkan berdasarkan tingkat risiko.
Bagaimana URL unggahan mencegah penimpaan (overwriting) objek lain?
Ikat ke kunci immutable atau ID unggahan sekali pakai, If-None-Match, ukuran, dan checksum. Setelah selesai, periksa kembali status tenant dan objek, lalu tolak penggantian path atau penyelesaian duplikat.
Haruskah CDN men-cache signed URL?
CDN dapat men-cache byte hanya jika kunci, header, dan TTL mencegah respons privat melintasi batasan izin. Sumber daya berisiko tinggi atau berumur sangat pendek dapat melewati shared cache, mengorbankan hit rate demi isolasi dan pencabutan yang terkendali.