Berbagi pekerjaan browser tanpa membagikan kredensial mentah

Tim sering mengatakan perlu “berbagi login”, padahal tugasnya lebih sempit: meninjau draf, memperbarui toko yang diizinkan, mereproduksi masalah regional, atau melanjutkan layanan dukungan. Memulai dari tugas membuka lebih banyak pilihan daripada memulai dari kata sandi.

Apa yang termasuk kredensial mentah

Contoh jelasnya kata sandi, kode pemulihan, seed kata sandi sekali pakai, kunci privat, dan kata sandi proxy. Pekerjaan browser juga membawa kredensial yang kurang terlihat:

• cookie autentikasi serta ID sesi;
• token akses dan refresh OAuth;
• catatan pengelola kata sandi serta isi otomatis;
• material privat passkey atau akses ke autentikatornya;
• keadaan perangkat tepercaya serta pemulihan;
• arsip profil yang memuatnya.

Panduan sesi NIST menjelaskan kesinambungan berdasarkan penguasaan rahasia sesi. OWASP memperjelas akibatnya: selama berlaku, token sesi dapat setara dengan autentikasi terkuat yang membuatnya.

Arsip terenkripsi di klien menyembunyikan nilai kredensial dari penyedia penyimpanan hanya jika penyedia tidak memiliki kunci dekripsi. Ini juga mengurangi paparan kasual. Namun, setelah perangkat penerima mendekripsi dan menjalankan profil, browser tetap dapat memakai sesi. Kewenangan sudah berpindah meski penerima tidak pernah membaca cookie.

Pisahkan tugas dari kewenangan

Sebelum memilih mekanisme, tulis pernyataan akses:

Operator A boleh melakukan tindakan B pada sumber daya C dari perangkat D yang disetujui sampai waktu E, dengan aturan persetujuan dan audit F.

Kalimat itu menyingkap hak berlebih. Untuk menyetujui draf, sesi administrator penuh terlalu luas. Jika situs sudah menyediakan peran peninjau, berbagi keadaan browser menambah risiko tanpa manfaat baru.

Arsitektur Zero Trust NIST menyarankan akses tiap sumber daya per sesi dengan hak minimum untuk tugas. Prinsip ini berlaku tanpa membeli produk berlabel zero trust dan berguna untuk menilai setiap serah terima.

Utamakan model berikut secara berurutan

1. Akses individu pada layanan tujuan

Gunakan fitur tim, organisasi, peran, delegasi, atau persetujuan milik layanan jika tersedia. Setiap orang masuk dengan akun dan autentikator sendiri. Layanan dapat menegakkan izin, mengenali operator, menerapkan kontrol risiko, serta mencabut satu orang tanpa mengganti kredensial semua anggota.

Biasanya ini paling kuat karena otorisasi berada di tempat yang memahami tindakan. Pengelola browser tidak dapat mengubah sesi administrator bersama menjadi peran peninjau situs secara andal.

Akun kelompok mengurangi tanggung jawab individu. NIST SP 800-53 Revisi 5 menyarankan pembatasan dan syarat eksplisit sebelum mengizinkannya.

2. Delegasi terbatas dari layanan

Jika tersedia OAuth atau protokol delegasi lain, berikan hanya sumber daya, tindakan, dan durasi yang dibutuhkan. RFC 9700 menyarankan hak minimum dan audience terbatas pada server tujuan.

Utamakan izin singkat, dapat dicabut, dan khusus audience. Token terikat pengirim mengurangi replay setelah bocor, tetapi tidak membantu jika penyerang memperoleh token sekaligus kuncinya. Perangkat dan perangkat lunak klien tetap berada dalam model ancaman.

Delegasi cocok untuk otomatisasi: skrip mendapat izin operasi tertentu tanpa kata sandi orang atau sesi umum. Audit perlu menyebut manusia pemrakarsa, pelaku delegasi, sumber daya, cakupan, serta hasil.

3. Menggunakan rahasia tersimpan melalui perantara

Sebagian layanan lama hanya menyediakan kredensial bersama. Broker kredensial atau pengelola kata sandi dapat mengurangi penyalinan dengan memasukkan rahasia ke alur browser yang disetujui tanpa menampilkannya pada chat, tiket, dokumen, atau keluaran normal.

Ini memperbaiki penjagaan, rotasi, dan tinjauan akses, tetapi bukan model akun tujuan. Setelah login, semua operator mungkin tetap menjadi identitas yang sama. Sesi memerlukan batas waktu, pencabutan, serta kontrol perangkat sendiri.

Panduan rahasia OWASP menyarankan hak terperinci, interaksi manusia minimal dengan nilai, pengelolaan siklus, serta audit pemintaan dan penggunaan. Produk browser sebaiknya memakai referensi opak bila memungkinkan, bukan menjadi penyimpanan rahasia umum tambahan.

4. Serah terima sesi browser terlindungi

Gunakan profil terautentikasi bersama hanya jika layanan tidak menyediakan delegasi memadai dan pekerjaan yang diizinkan benar-benar membutuhkan kesinambungan. Ini serah terima biasa dengan risiko tertinggi karena penerima mendapat kemampuan bertindak melalui akun aktif.

Kontrol minimum:

• pemilik serta penerima yang disetujui;
• tugas, sumber daya, dan kedaluwarsa jelas;
• satu penulis aktif atau model konflik teruji;
• enkripsi klien sebelum unggahan cloud;
• otorisasi perangkat penerima dan perlindungan lokal;
• kunci penggunaan untuk mencegah kerja bersamaan yang ambigu;
• audit pemberian, pengunduhan, pembukaan, tindakan sensitif, penutupan, pencabutan, serta pemulihan;
• antarmuka biasa mengembalikan keadaan tanpa cookie atau token;
• rencana penghentian sesi pada layanan tujuan.

Model ini mengurangi penyalinan kasual dan dapat melindungi nilai dari penyedia cloud jika penyedia tidak memiliki kunci. Namun, situs tetap tidak dapat membedakan dua orang yang memakai akun sama. Sesi juga tidak terlindungi dari malware, ekstensi berbahaya, atau penerima yang menyalahgunakan hak.

5. Pemindahan kredensial mentah

Menyalin kata sandi, cookie, kode pemulihan, passkey, atau arsip ke pesan, spreadsheet, tiket, skrip, maupun ekspor terbuka menciptakan rahasia tahan lama dengan salinan tak diketahui dan pencabutan lemah. Hindari.

Jika prosedur lama yang luar biasa mengharuskannya, ikuti aturan kredensial organisasi, minimalkan penerima serta durasi, lalu rotasi atau cabut. Enkripsi pesan tidak menggantikan tanggung jawab individu atau catatan semua salinan.

Bandingkan hak, bukan kenyamanan saja

Model	Layanan mengenali operator	Kesesuaian cakupan tugas	Batas pencabutan	Risiko tersisa
Anggota individu layanan	Biasanya ya	Biasanya paling kuat	Hapus anggota atau peran	Izin tujuan berlebihan
Token delegasi terbatas	Pelaku dan klien dapat dicatat	Kuat jika scope dan audience sempit	Cabut grant atau token	Kompromi token, klien, atau kunci
Login bersama melalui broker	Sering tidak setelah masuk	Dibatasi akun bersama	Rotasi rahasia dan hentikan sesi	Identitas bersama serta sesi aktif
Sesi browser terenkripsi	Biasanya tidak pada tujuan	Tingkat profil, sering luas	Cabut berbagi serta sesi tujuan	Perangkat penerima memakai seluruh hak sesi
Salinan mentah	Tidak ada identitas individu andal	Biasanya luas	Cari salinan, rotasi, hentikan sesi	Salinan tak diketahui dan tanggung jawab lemah

“Tidak ada yang melihat kata sandi” bukan ukuran keberhasilan yang lengkap: yang penting adalah hak penerima, durasinya, dan sistem yang mampu mencabutnya.

Passkey memperkuat login, dengan catatan untuk berbagi

WebAuthn membuat kredensial kunci publik khusus relying party. Spesifikasi Level 3 menyatakan autentikator menyimpan kunci privat dan skrip situs menerima hasil bertanda tangan, bukan kuncinya. Jika benar, ini memberi autentikasi tahan phishing.

Passkey tidak otomatis membuat peran tim. Layanan dapat mendaftarkan kredensial terpisah tiap anggota. Penyedia passkey juga mungkin menyinkronkan atau berbagi kunci. NIST SP 800-63B-4 mengakui model itu serta risikonya: penggunaan tak sah, penyebaran antarperangkat, kompromi sistem sinkronisasi, dan pencabutan sulit.

Utamakan akun serta autentikator sendiri per orang. Jika hanya passkey bersama yang didukung, perlakukan sebagai autentikator bersama, tentukan penerima dan perangkat terkelola, lalu verifikasi cara penyedia menampilkan, mencabut, serta memulihkannya. Semua tindakan mungkin tetap dicatat sebagai satu akun.

Jadikan serah terima sebuah kontrak kerja

Jawab sebelum data berpindah:

1. Siapa bertindak? Identitas organisasi tertentu, bukan label operator umum.
2. Siapa memberi izin? Catat pemilik atau keputusan kebijakan tanpa rahasia persetujuan.
3. Apa dibagikan? Sebut profil dan tugas, bukan daftar cookie mentah.
4. Apa boleh dilakukan? Pisahkan peluncuran, edit, ekspor, otomatisasi, berbagi, serta administrasi.
5. Di mana boleh berjalan? Perangkat terdaftar dan tepercaya sesuai data.
6. Berapa lama? Tetapkan kedaluwarsa dan tutup sesi menganggur.
7. Bolehkah dua penulis? Satu aktif kecuali konflik sengaja dirancang serta diuji.
8. Apa dicatat? Pelaku, perangkat, referensi profil, tindakan, hasil, serta waktu; tanpa nilai rahasia dan konten halaman secara bawaan.
9. Bagaimana dicabut? Mencakup izin berbagi browser dan sesi tujuan.
10. Bagaimana dipulihkan? Pertahankan versi baik tanpa mengembalikan hak yang dicabut.

Enkripsi melindungi penyimpanan atau pemindahan. Otorisasi menentukan pihak yang memperoleh jalur dekripsi. Kepercayaan perangkat serta isolasi lokal melindungi penggunaan. Audit mendukung tanggung jawab dan investigasi. Satu kontrol tidak menggantikan yang lain.

Jauhkan otomatisasi dari nilai rahasia

API, SDK, CLI, dan agen sering perlu menjalankan profil atau tindakan siklus hidup yang disetujui. Jarang perlu nilai cookie, kata sandi, passkey, kredensial proxy, atau arsip mentah.

Antarmuka sempit dapat menerima referensi opak dan mengembalikan:

• apakah tindakan diizinkan;
• keadaan tanpa rahasia seperti siap, terkunci, kedaluwarsa, atau dicabut;
• referensi proses atau sesi berbatas waktu;
• kesalahan terstruktur dan langkah pemulihan;
• referensi audit.

Hak peluncuran tidak berarti hak membaca kredensial. Ekspor, berbagi massal, serta operasi pembawa rahasia membutuhkan kebijakan terpisah dan persetujuan eksplisit bila sesuai.

Konten web dan masukan otomatisasi tetap tidak tepercaya. Instruksi halaman tidak boleh membujuk agen membocorkan sesi melalui log, keluaran alat, tangkapan layar, atau dukungan.

Pencabutan memiliki dua lapisan

Menghapus rekan dari ruang kerja menghentikan akses berwenang berikutnya melalui ruang kerja itu. Ini tidak membuktikan sesi situs tidak berlaku. Perangkat mungkin sudah memegang data terbuka dan sesi salinan atau yang masih berjalan dapat berlanjut.

Saat akses berakhir normal:

1. cabut izin tim dan akhiri hak penggunaan aktif profil;
2. hapus materi lokal terenkripsi menurut retensi;
3. hentikan sesi tujuan jika didukung;
4. hapus keanggotaan atau delegasi pada layanan tujuan;
5. simpan audit tanpa rahasia selama jangka disetujui.

Jika diduga kompromi, karantina versi terdampak, cabut sesi serta token, hapus autentikator tak sah, rotasi rahasia bersama yang terbuka, dan tinjau audit. Snapshot lama bisa mengembalikan rahasia sesi lama, sehingga pemulihan harus mengikuti keadaan pencabutan saat ini.

Batas yang tetap ada

• Enkripsi klien melindungi penyimpanan serta transfer, tetapi endpoint berwenang harus mendekripsi.
• Kunci browser mengendalikan konkurensi produk, bukan semua tindakan situs.
• Sesi bersama biasanya mewakili satu identitas situs meski audit produk lebih rinci.
• Perangkat atau ekstensi terkompromi dapat bertindak tanpa mengambil kata sandi terbaca.
• Pencabutan ruang kerja dan sesi situs berbeda.
• Ketentuan layanan, kontrak klien, serta hukum menentukan izin delegasi.
• Sebagian layanan tidak punya pengganti aman untuk akses individu. Mengurangi cakupan atau menolak serah terima bisa menjadi pilihan bertanggung jawab.

RFC 6265 menyebut cookie sebagai kewenangan otomatis: browser dapat melampirkannya pada permintaan meski pemicu tidak mengetahui nilainya. Itulah batas utama berbagi sesi. Menyembunyikan nilai mengurangi pengungkapan, bukan hak yang dapat digunakan browser.