1. Masalah dan konteks
Sebuah layanan menerima permintaan untuk membaca atau menulis sumber daya. Layanan itu sendiri memiliki izin yang luas, sedangkan pemanggil seharusnya hanya menerima otoritas yang sempit. Jika layanan menggunakan jalur atau ID sumber daya yang dikontrol oleh pemanggil dan kemudian bertindak dengan hak istimewanya sendiri, penyerang dapat membuatnya melakukan tindakan yang tidak dapat dilakukan pemanggil secara langsung. AWS menyebut ini sebagai masalah confused deputy.
Keamanan berbasis kapabilitas mengatasi hal ini dengan membuat otoritas menjadi eksplisit dalam sebuah referensi atau token yang mengidentifikasi sumber daya sekaligus membawa hak untuk menggunakannya. Kapabilitas harus tidak dapat dipalsukan (unforgeable), dibatasi cakupannya (scoped), dan hanya diteruskan ke kode yang membutuhkannya. Pertanyaan ini adalah diskusi model keamanan umum; tidak terbatas pada satu penyedia cloud atau bahasa pemrograman tertentu.
2. Hal yang dievaluasi oleh pewawancara
- Penalaran otoritas: Dapatkah Anda membedakan autentikasi, otorisasi, dan kepemilikan otoritas yang didelegasikan?
- Pemodelan ancaman: Dapatkah Anda menunjukkan deputy, input yang membingungkan, tindakan berhak istimewa, dan batas yang dikendalikan penyerang?
- Hak istimewa terendah (Least privilege): Apakah Anda melemahkan (attenuate) kapabilitas ke satu operasi, objek, penyewa (tenant), atau jendela waktu tertentu?
- Pertimbangan siklus hidup: Dapatkah Anda menjelaskan pencabutan, masa kedaluwarsa, auditabilitas, dan kebocoran tanpa mengklaim bahwa kapabilitas menyelesaikan segalanya?
- Kejelasan kompromi (trade-offs): Dapatkah Anda membandingkan kapabilitas dengan identitas ambient dan pemeriksaan kebijakan di bawah batasan operasional yang realistis?
Jawaban yang lemah mengatakan "gunakan token". Jawaban yang kuat menjelaskan apa yang diotorisasi oleh token tersebut, bagaimana token dibatasi, dan apa yang terjadi jika token bocor atau harus dicabut.
3. Pertanyaan untuk diklarifikasi terlebih dahulu
Apakah deputy tersebut merupakan kode lokal, layanan, atau peran cloud?
Polanya sama, tetapi batasannya berubah. Sebuah pustaka dapat secara tidak sengaja mewarisi handle file; sebuah layanan dapat menggunakan identitas beban kerjanya (workload identity); sebuah peran cloud dapat dikelabui untuk bertindak pada sumber daya lintas akun. Sebutkan prinsipal yang memiliki otoritas luas tersebut.
Sumber daya dan operasi apa yang didelegasikan?
Klarifikasi apakah otoritas tersebut berupa baca, tulis, tambah (append), hapus, panggil (invoke), atau operasi gabungan. Kapabilitas untuk satu objek dan satu metode lebih mudah diaudit dan dicabut daripada nama sumber daya wildcard.
Apa saja persyaratan pencabutan dan kebocoran?
Tanyakan apakah diperlukan pencabutan segera, penggunaan offline, isolasi multi-tenant, atau audit yang tidak dapat disangkal (non-repudiable). Batasan ini menentukan apakah akan menggunakan referensi dalam memori, token yang ditandatangani, lease, broker, atau pemeriksaan kebijakan terpusat.
4. Kerangka jawaban 30 detik
"Confused deputy muncul ketika pemanggil dengan hak istimewa lebih rendah memberikan nama sumber daya ke layanan yang lebih berhak istimewa, dan layanan tersebut menggunakan otoritasnya sendiri tanpa mengikat permintaan ke cakupan yang dimaksudkan pemanggil. Keamanan kapabilitas membuat otoritas menjadi eksplisit: teruskan referensi atau token yang tidak dapat dipalsukan yang menyebutkan satu sumber daya dan operasi yang diizinkan, serta wajibkan deputy untuk hanya menggunakan referensi tersebut. Saya akan melemahkan kapabilitas saat delegasi, mengikatnya ke tenant dan audiens, mengakhiri atau mencabutnya sesuai risiko, serta mencatat penerbitan dan penggunaannya. Kapabilitas mengurangi otoritas ambient dan risiko confused deputy, tetapi kebocoran, replay, pemulihan, dan audit tetap menjadi masalah desain."
5. Penjelasan langkah demi langkah
Langkah 1: Pisahkan identitas dari otoritas
Autentikasi menjawab siapa yang memanggil. Otorisasi menjawab apa yang boleh dilakukan identitas tersebut berdasarkan kebijakan. Kapabilitas adalah referensi pembawa otoritas yang konkret: kepemilikan ditambah integritas referensi yang tidak dapat dipalsukan memberikan tindakan tertentu. Model ini dapat berdampingan dengan identitas, tetapi tidak bergantung pada pemeriksaan identitas ambient global di setiap panggilan internal.
Langkah 2: Gambarkan alur confused deputy
Misalkan sebuah layanan laporan dapat membaca file apa pun di bawah identitas beban kerjanya. Pengguna mengirimkan file=/reports/other-tenant.csv. Jika layanan hanya memvalidasi bahwa permintaan tersebut terautentikasi, layanan tersebut menjadi deputy: pengguna memberikan nama, dan layanan menggunakan hak istimewanya yang lebih luas. Pengikatan yang hilang adalah "pemanggil ini secara eksplisit diberi otoritas atas objek ini."
Langkah 3: Ganti nama dengan otoritas berlingkup
Sebagai gantinya, pemilik yang berwenang membuat kapabilitas untuk laporan dan operasi tertentu, seperti akses hanya-baca untuk tenant A hingga batas waktu tertentu. Pemanggil meneruskan kapabilitas tersebut ke layanan. Layanan mendereferensikan kapabilitas atau menyajikannya ke broker; layanan tidak mengubah jalur arbitrer menjadi otoritas. Penelitian kapabilitas objek menggambarkan pola ini sebagai penyandian hak akses dalam objek individual dan pembatasan interaksinya.
Langkah 4: Lemahkan (attenuate) saat pendelegasian
Ketika suatu komponen mendelegasikan, ia harus menghasilkan kapabilitas yang lebih lemah: lebih sedikit metode, satu objek anak, masa berlaku lebih pendek, batasan tenant, atau pembatasan laju (rate limit). Jangan pernah memperluas kapabilitas hanya demi kemudahan komponen downstream. Wrapper yang hanya mengekspos readMetadata() lebih aman daripada meneruskan handle sistem file dengan hak tulis dan hapus.
Langkah 5: Tangani token dan replay
Jika kapabilitas melintasi batas proses, gunakan referensi yang dilindungi seperti token bertanda tangan yang terikat ke audiens atau handle yang dikeluarkan broker. Sertakan sumber daya, tindakan, tenant, penerbit, audiens, kedaluwarsa, dan ID unik jika replay menjadi masalah. Verifikasi integritas dan konteks sebelum digunakan. Enkripsi dapat menyembunyikan konten, tetapi enkripsi itu sendiri tidak menegakkan cakupan atau menghentikan replay.
Langkah 6: Rencanakan pencabutan dan pemulihan
Kapabilitas murni dalam memori mudah diteruskan tetapi sulit dicabut secara global. Lease, masa kedaluwarsa pendek, indireksi melalui penyimpanan pencabutan, atau rotasi kunci menukar kontrol langsung dengan ketersediaan dan latensi. Jika token bocor, cabut handle atau pengikatannya, putar kunci yang relevan jika perlu, dan periksa log penggunaan; menghapus rekaman pengguna saja mungkin tidak membatalkan kapabilitas yang sudah diterbitkan.
Langkah 7: Pertahankan batas audit dan kebijakan
Catat siapa yang menerbitkan kapabilitas, cakupan apa yang dibawanya, deputy mana yang menggunakannya, dan hasilnya. Pertahankan konteks identitas untuk akuntabilitas bahkan ketika kapabilitas merupakan primitif otorisasi. Untuk tindakan berisiko tinggi, kombinasikan pemeriksaan kapabilitas dengan pemeriksaan kebijakan seperti status tenant, penahanan hukum (legal hold), atau autentikasi bertahap (step-up authentication).
6. Contoh jawaban berkualitas tinggi
"Confused deputy adalah ketidakcocokan hak istimewa. Pemanggil menyediakan nama sumber daya, tetapi layanan dengan hak lebih luas yang melakukan operasi tersebut. Layanan menjadi bingung karena nama tersebut diperlakukan sebagai otoritas. AWS mendokumentasikan pola ini untuk akses lintas akun dan lintas layanan.
Saya akan meneruskan kapabilitas eksplisit sebagai gantinya: referensi yang tidak dapat dipalsukan atau token yang dilindungi yang dibatasi untuk satu tenant, objek, operasi, audiens, dan masa kedaluwarsa. Deputy hanya dapat menggunakan kapabilitas tersebut, dan delegasi membuat anak yang dilemahkan. Untuk token jarak jauh, saya akan memverifikasi integritas, konteks, dan batasan replay, lalu mencatat penerbitan dan penggunaannya.
Pencabutan adalah komprominya. Saya mungkin menggunakan lease berumur pendek atau handle yang dapat dicabut untuk tindakan sensitif, dengan menerima biaya pencarian (lookup). Kapabilitas mengurangi otoritas ambient dan membuat alur data lebih mudah diperiksa, tetapi kapabilitas tidak menghilangkan persyaratan kebocoran, pemulihan, audit, atau kebijakan. Saya akan menguji upaya lintas tenant, replay token, nama yang membingungkan, dan race condition pada pencabutan."
7. Kesalahan umum
- "Autentikasi saja sudah cukup" → Membiarkan identitas layanan yang luas menentukan cakupan → Ikat operasi ke otoritas yang eksplisit dan dibatasi.
- "Token yang ditandatangani otomatis menjadi kapabilitas" → Mengabaikan audiens, operasi, kedaluwarsa, dan replay → Perlakukan integritas sebagai satu properti dan tegakkan cakupan secara terpisah.
- "Gunakan jalur pemanggil setelah memeriksa login" → Membuat ulang alur confused deputy → Teruskan kapabilitas atau handle broker daripada nama arbitrer.
- "Kapabilitas menghilangkan kebijakan otorisasi" → Melewatkan status tenant dan aturan kontekstual → Gabungkan pemeriksaan kapabilitas dengan pemeriksaan kebijakan berisiko tinggi.
- "Pencabutan tidak memerlukan biaya" → Mengabaikan salinan terdistribusi dan penggunaan offline → Pilih lease, indireksi, atau kedaluwarsa berdasarkan persyaratan pencabutan.
- "Sembunyikan semua konteks identitas" → Membuat investigasi insiden menjadi tidak mungkin → Pertahankan penerbit, subjek, cakupan, dan peristiwa penggunaan untuk audit.
8. Pertanyaan lanjutan
Apa perbedaan kapabilitas dengan pencarian ACL?
Pencarian ACL dimulai dengan identitas dan nama sumber daya, kemudian berkonsultasi dengan kebijakan pada saat penggunaan. Kapabilitas membawa referensi otoritas yang didelegasikan melalui alur data. ACL memusatkan kebijakan dan pencabutan; kapabilitas membuat otoritas eksplisit dan dapat mengurangi otoritas ambient, tetapi memerlukan kontrol siklus hidup dan kebocoran.
Bisakah kapabilitas disalin?
Referensi dalam proses sering kali dapat disalin oleh kode yang sudah memegangnya. Batas keamanannya adalah siapa yang dapat menerimanya dan apakah kapabilitas tersebut dilemahkan. Token jarak jauh dapat di-replay kecuali diikat ke saluran, nonce, audiens, atau lease pendek. Kemampuan untuk disalin adalah risiko yang harus dimodelkan, bukan alasan untuk berasumsi bahwa token tersebut tidak berbahaya.
Bagaimana Anda mengamankan URL kapabilitas?
Perlakukan sebagai kredensial pembawa (bearer credential): gunakan HTTPS, cakupan sempit, kedaluwarsa pendek, entropi yang tidak dapat ditebak, pengikatan audiens, pembatasan laju, dan penyembunyian (redaction) dari log dan referrer. Untuk tindakan sensitif atau yang dapat digunakan kembali, lebih baik gunakan pertukaran sekali pakai untuk handle yang dapat dicabut.
Di mana confused deputy masih muncul dalam sistem cloud?
Masalah ini muncul ketika peran layanan, build runner, atau proksi penyimpanan menerima pengidentifikasi sumber daya yang dikontrol pengguna dan menggunakan perannya sendiri yang luas. Ikat permintaan ke kebijakan sumber daya, tenant, dan tindakan yang dimaksudkan; panduan lintas akun AWS adalah contoh konkret dari batasan ini.