Berkongsi kerja pelayar tanpa berkongsi bukti kelayakan mentah

Pasukan sering berkata mereka perlu ‘berkongsi log masuk’ sedangkan keperluan sebenar lebih sempit: menyemak draf, mengemas kini kedai dalam talian yang dibenarkan, menghasilkan semula pepijat serantau atau menyambung aliran sokongan. Bermula dengan tugas memberikan lebih banyak pilihan daripada bermula dengan kata laluan.

Apa yang dianggap bukti kelayakan mentah

Contoh jelas ialah kata laluan, kod pemulihan, rahsia penjana kata laluan sekali guna, kunci persendirian dan kata laluan proksi. Kerja pelayar turut melibatkan bukti kelayakan yang kurang kelihatan:

• kuki pengesahan dan pengecam sesi;
• token akses dan penyegaran OAuth;
• rekod pengurus kata laluan serta data autoisi;
• bahan kunci persendirian kunci laluan atau akses kepada alat pengesahan yang menyimpannya;
• keadaan peranti dipercayai dan pemulihan; dan
• arkib profil yang mengandungi mana-mana perkara di atas.

Panduan sesi NIST menerangkan sesi pelayar sebagai kesinambungan berdasarkan pemilikan rahsia sesi. Panduan Pengurusan Sesi OWASP menjelaskan kesan operasinya: selama masih sah, token sesi boleh setara dengan pengesahan paling kukuh yang menciptanya.

Pakej profil yang disulitkan pada pihak klien menyembunyikan nilai bukti kelayakan daripada penyedia storan hanya jika penyedia itu tidak memegang kunci penyahsulitan. Ia juga mengurangkan pendedahan kepada pemerhati biasa. Selepas peranti penerima yang dibenarkan menyahsulit dan melancarkan profil, pelayar masih boleh menggunakan sesi itu. Serahan telah memindahkan kuasa walaupun penerima tidak pernah membaca satu kuki pun.

Asingkan tugas daripada kuasa

Sebelum memilih mekanisme perkongsian, tulis pernyataan akses ringkas:

Pengendali bernama A boleh melakukan tindakan B pada sumber C, daripada peranti diluluskan D, sehingga masa E, tertakluk pada peraturan kelulusan dan audit F.

Ayat itu mendedahkan kuasa yang tidak diperlukan. Jika tugasnya ‘luluskan draf ini’, sesi pentadbiran penuh berlebihan. Jika perkhidmatan sasaran sudah menyokong peranan penyemak, perkongsian keadaan pelayar menambah risiko tanpa menambah keupayaan.

Seni Bina Zero Trust NIST mengesyorkan akses kepada sumber individu bagi setiap sesi dengan keistimewaan minimum yang diperlukan tugas. Prinsip ini terpakai tanpa perlu menggunakan produk berlabel ‘zero trust’. Ia ujian reka bentuk berguna untuk sebarang serahan pelayar.

Utamakan model berikut mengikut turutan

1. Akses individu bernama pada perkhidmatan sasaran

Gunakan ciri pasukan, organisasi, peranan, akses wakil atau kelulusan milik laman atau aplikasi apabila tersedia. Setiap orang mengesahkan diri menggunakan akaun dan alat pengesahan individu. Perkhidmatan sasaran kemudian boleh menguatkuasakan kebenarannya, mengaitkan tindakan dengan pengendali, menerapkan kawalan risiko dan membatalkan akses seorang individu tanpa menukar bukti kelayakan semua orang.

Ini biasanya model paling kukuh kerana kebenaran berada pada sistem yang memahami tindakan itu. Pengurus pelayar tidak boleh menukar sesi pentadbir bersama sesuatu laman kepada peranan penyemak pada laman itu dengan andal.

Akaun bersama dan kumpulan mengurangkan akauntabiliti. NIST SP 800-53 Semakan 5 menasihatkan organisasi mengehadkan penggunaannya dan menetapkan syarat jelas sebelum membenarkannya.

2. Kebenaran wakil berskop daripada perkhidmatan sasaran

Apabila perkhidmatan menawarkan OAuth atau protokol pemberian kuasa lain, berikan klien atau pelaku hanya sumber, tindakan dan tempoh yang diperlukan. RFC 9700 mengesyorkan keistimewaan token akses minimum dan penerima yang terhad kepada pelayan sumber dimaksudkan.

Utamakan pemberian kebenaran berjangka pendek, boleh dibatalkan dan terhad penerimanya. Token yang terikat pada pengirim boleh mengurangkan penggunaan semula jika token bocor, tetapi tidak membantu apabila penyerang memperoleh kedua-dua token dan bahan kunci yang mengikatnya. Peranti dan perisian klien kekal dalam sempadan ancaman.

Pemberian kuasa amat berguna untuk automasi kerana skrip boleh menerima kebenaran bagi operasi tertentu tanpa menerima kata laluan seseorang atau sesi pelayar umum. Peristiwa audit perlu mengenal pasti orang yang memulakan tindakan, pelaku diberi kuasa, sumber, skop dan hasil.

3. Penggunaan rahsia tersimpan melalui perantara

Sesetengah perkhidmatan lama hanya menyediakan bukti kelayakan bersama. Perantara bukti kelayakan terkawal atau pengurus kata laluan boleh mengurangkan penyalinan dengan membenarkan aliran pelayar diluluskan menggunakan rahsia tanpa menunjukkannya dalam sembang, tiket, dokumen atau output aplikasi biasa.

Ini memperbaik penjagaan rahsia, penggiliran dan semakan akses, tetapi tidak membaiki model akaun perkhidmatan sasaran. Selepas log masuk, setiap pengendali mungkin masih bertindak sebagai identiti laman yang sama. Sesi terhasil kekal sensitif dan memerlukan had masa, pembatalan serta kawalan peranti sendiri.

Panduan Pengurusan Rahsia OWASP mengesyorkan akses terperinci, interaksi manusia minimum dengan nilai rahsia, kawalan kitar hayat dan audit tentang siapa meminta serta menggunakan rahsia. Jika boleh, produk pelayar perlu berintegrasi melalui rujukan legap dan bukannya menjadi satu lagi stor rahsia serba guna.

4. Serahan sesi pelayar terlindung

Gunakan profil bersama yang telah disahkan hanya apabila perkhidmatan sasaran tidak mempunyai pemberian kuasa yang memadai dan aliran kerja dibenarkan memang memerlukan kesinambungan sesi. Ini serahan biasa berisiko paling tinggi kerana penerima memperoleh keupayaan bertindak melalui akaun aktif.

Kawalan minimum termasuk:

• pemilik jelas dan penerima diluluskan;
• tugas, sumber dan waktu tamat yang dinyatakan;
• satu penulis aktif atau model konflik yang diuji;
• penyulitan pihak klien sebelum sebarang muat naik awan;
• kebenaran peranti penerima dan perlindungan setempat;
• kunci penggunaan yang menghalang kerja serentak yang kabur;
• peristiwa audit bagi pemberian akses, muat turun, pembukaan, tindakan sensitif, penutupan, pembatalan dan pemulihan;
• antara muka biasa yang memulangkan keadaan dengan maklumat sensitif disembunyikan, bukannya kuki atau token; dan
• pelan pembatalan sesi pada perkhidmatan sasaran.

Model ini boleh mengurangkan penyalinan nilai bukti kelayakan secara biasa. Perlindungan kandungan daripada penyedia storan awan turut memerlukan penyedia itu tidak dapat mengakses kunci penyahsulitan. Model ini tidak boleh membuat perkhidmatan sasaran membezakan dua orang yang menggunakan akaun terautentikasi sama. Ia juga tidak dapat melindungi sesi daripada perisian hasad, sambungan berniat jahat atau penerima dibenarkan yang menyalahgunakan kuasa diberikan.

5. Pemindahan bukti kelayakan mentah

Menyalin kata laluan, kuki, kod pemulihan, kunci laluan atau arkib profil ke dalam mesej, hamparan, tiket, skrip atau eksport tidak terlindung mencipta rahsia tahan lama dengan salinan tidak diketahui dan pembatalan lemah. Elakkannya.

Jika proses lama yang luar biasa memerlukan pemindahan, kendalikannya mengikut prosedur bukti kelayakan diluluskan organisasi, minimumkan penerima serta tempoh, kemudian gilirkan atau batalkan bukti kelayakan. Jangan anggap penyulitan mesej menggantikan akauntabiliti individu atau rekod setiap salinan.

Bandingkan kuasa, bukan kemudahan sahaja

Model	Perkhidmatan sasaran mengenal pasti pengendali	Skop boleh sepadan dengan tugas	Sempadan pembatalan	Risiko utama yang masih tinggal
Ahli bernama pada perkhidmatan sasaran	Biasanya ya	Biasanya paling kukuh	Buang seorang ahli atau peranan	Kebenaran berlebihan pada perkhidmatan sasaran
Token wakil berskop	Pelaku dan klien boleh diwakili	Kukuh apabila skop dan penerima sempit	Batalkan pemberian kuasa atau token	Token, klien atau kunci terjejas
Log masuk bersama melalui perantara	Sering tidak selepas log masuk	Terhad oleh akaun bersama	Gilirkan rahsia dan tamatkan sesi	Identiti laman bersama dan sesi aktif
Sesi pelayar tersulit	Biasanya tidak pada perkhidmatan sasaran	Pada peringkat profil, sering luas	Batalkan perkongsian serta sesi sasaran	Peranti penerima boleh menggunakan seluruh kuasa sesi
Salinan bukti kelayakan mentah	Tiada identiti individu yang andal	Biasanya luas	Cari salinan, gilirkan rahsia dan tamatkan sesi	Salinan tidak diketahui dan akauntabiliti lemah

Jadual ini menjelaskan sebab ‘tiada siapa boleh melihat kata laluan’ bukan kriteria kejayaan yang lengkap. Hasil penting ialah kuasa yang boleh digunakan penerima, tempohnya dan sistem yang boleh membatalkannya.

Kunci laluan memperbaik pengesahan, tetapi perkongsian masih ada batas

WebAuthn mencipta bukti kelayakan kunci awam berskop pihak bergantung. Spesifikasi WebAuthn Tahap 3 menyatakan alat pengesahan memegang kunci persendirian dan skrip laman menerima hasil bertandatangan, bukannya bukti kelayakan persendirian itu sendiri. Ini memberikan pengesahan tahan pancingan data apabila dilaksanakan dengan betul.

Kunci laluan tidak mencipta peranan pasukan secara automatik. Perkhidmatan sasaran boleh mendaftarkan bukti kelayakan berasingan bagi setiap ahli bernama, lalu mengekalkan akses individu. Penyedia kunci laluan juga mungkin menyokong penyegerakan atau perkongsian kunci pengesahan. NIST SP 800-63B-4 mengiktiraf model itu dan mengenal pasti risiko seperti penggunaan kunci tanpa kebenaran, penyebaran merentas peranti, sistem penyegerakan terjejas serta kesukaran pembatalan.

Bagi pasukan yang dibenarkan, utamakan satu akaun bernama pada perkhidmatan dan satu alat pengesahan bagi setiap orang. Jika kunci laluan bersama satu-satunya model disokong, anggap ia alat pengesahan bersama, dokumentasikan penerima dan peranti terurus yang dibenarkan, serta sahkan cara penyedia memaparkan, membatalkan dan memulihkan kunci bersama. Perkhidmatan sasaran mungkin masih merekodkan semua tindakan di bawah satu akaun.

Takrifkan serahan pelayar sebagai kontrak

Serahan terkawal perlu menjawab soalan berikut sebelum keadaan profil dipindahkan:

1. Siapa bertindak? Gunakan identiti organisasi bernama, bukan label pengendali umum.
2. Siapa membenarkannya? Rekodkan pemilik atau keputusan dasar tanpa menyimpan rahsia kelulusan.
3. Apa dikongsi? Namakan profil dan tugas. Elakkan senarai mentah kuki atau bukti kelayakannya.
4. Apa boleh dilakukan penerima? Asingkan kebenaran melancar, menyunting, mengeksport, mengautomasi, berkongsi dan mentadbir.
5. Di mana ia boleh dijalankan? Hadkan akses kepada peranti berdaftar dan dipercayai yang sesuai dengan data.
6. Berapa lama? Tetapkan tempoh tamat dan tutup sesi melahu.
7. Bolehkah dua penulis bertindak? Gunakan satu penulis aktif kecuali tingkah laku konflik direka dan diuji secara sengaja.
8. Apa direkodkan? Log pelaku, peranti, rujukan profil, tindakan, hasil dan masa. Kecualikan nilai rahsia serta kandungan halaman secara lalai.
9. Bagaimana dibatalkan? Liputi pemberian perkongsian pelayar dan sesi perkhidmatan sasaran.
10. Bagaimana dipulihkan? Kekalkan versi terakhir yang diketahui baik tanpa mengaktifkan semula kebenaran dibatalkan secara tidak sengaja.

Penyulitan sebahagian daripada kontrak ini. Ia melindungi data ketika disimpan atau dipindahkan. Kebenaran menentukan siapa boleh mendapatkan laluan penyahsulitan. Kepercayaan peranti dan pengasingan setempat melindungi penggunaan. Audit menyokong akauntabiliti dan siasatan. Tiada satu kawalan menggantikan yang lain.

Kekalkan automasi di luar sempadan rahsia

API, SDK, alat baris perintah dan ejen sering perlu melancarkan profil atau melakukan tindakan kitar hayat yang diluluskan. Ia jarang memerlukan nilai kuki, kata laluan, kunci laluan, bukti kelayakan proksi atau arkib profil mentah.

Antara muka sempit boleh menerima rujukan profil atau rahsia yang legap dan memulangkan:

• sama ada tindakan dibenarkan;
• keadaan tanpa maklumat sensitif, seperti sedia, dikunci, luput atau dibatalkan;
• rujukan proses atau sesi berjangka terhad;
• ralat berstruktur dan langkah pemulihan; dan
• rujukan peristiwa audit.

Ia tidak sepatutnya memulangkan bukti kelayakan hanya kerana pemanggil boleh melancarkan profil. Eksport, perkongsian pukal atau operasi lain yang membawa rahsia memerlukan dasar berasingan dan, jika sesuai, kelulusan jelas.

Kandungan laman web dan input automasi juga kekal tidak dipercayai. Arahan pada halaman tidak boleh memujuk ejen mendedahkan bahan sesi melalui log, output alat, tangkapan skrin atau saluran sokongan.

Pembatalan akses mempunyai dua lapisan

Membuang rakan sekerja daripada ruang kerja pelayar menghentikan akses dibenarkan pada masa depan melalui ruang kerja itu. Ia tidak membuktikan sesi perkhidmatan sasaran tidak lagi sah. Peranti mungkin sudah memegang keadaan dinyahsulit, dan sesi yang disalin atau masih berjalan mungkin berterusan.

Apabila akses tamat secara biasa:

1. batalkan pemberian akses pasukan dan tutup pajakan profil;
2. buang bahan setempat tersulit mengikut dasar penyimpanan;
3. tamatkan sesi berkaitan pada perkhidmatan sasaran jika disokong;
4. buang keahlian atau pemberian kuasa individu pada perkhidmatan sasaran; dan
5. simpan bukti audit dengan maklumat sensitif disembunyikan untuk tempoh diluluskan.

Jika disyaki berlaku pencerobohan, kuarantin juga versi profil terjejas, batalkan sesi dan token aktif, buang alat pengesahan tanpa kebenaran, gilirkan rahsia bersama yang terdedah dan semak peristiwa audit. Memulihkan petikan profil lama boleh mengembalikan rahsia sesi lama, jadi pemulihan mesti mematuhi keadaan pembatalan akses.

Batas yang kekal selepas serahan berhati-hati

• Penyulitan pihak klien melindungi data tersimpan dan dipindahkan, tetapi peranti dibenarkan mesti menyahsulit apa yang diperlukan pelayar.
• Kunci penggunaan pelayar mengawal penggunaan serentak pada peringkat produk, bukan setiap tindakan pada perkhidmatan sasaran.
• Sesi bersama biasanya memberikan perkhidmatan sasaran satu identiti akaun, walaupun jejak audit produk pelayar lebih terperinci.
• Peranti atau sambungan terjejas boleh bertindak melalui sesi sah tanpa mengekstrak kata laluan yang boleh dibaca.
• Pembatalan pemberian akses ruang kerja dan pembatalan sesi laman ialah operasi berasingan.
• Syarat perkhidmatan sasaran, kontrak pelanggan dan undang-undang terpakai masih menentukan sama ada aliran kerja boleh diwakilkan.
• Sesetengah perkhidmatan tidak menyediakan pengganti selamat bagi akses individu. Dalam keadaan itu, mengecilkan skop atau menolak serahan mungkin keputusan yang bertanggungjawab.

RFC 6265 menerangkan kuki sebagai kuasa yang disertakan secara automatik: pelayar boleh melampirkannya pada permintaan walaupun pihak yang menyebabkan permintaan tidak pernah mengetahui nilai kuki. Inilah batas utama perkongsian sesi. Menyembunyikan bukti kelayakan mengurangkan pendedahan; ia tidak mengurangkan kuasa yang boleh digunakan pelayar.