Cara menilai pelayar pasukan: senarai semak praktikal

Tentukan keputusan sebelum membuka halaman harga

Penilaian yang berguna bermula dengan kerja yang perlu dibuat, bukannya senarai vendor. Catat:

• aliran kerja yang dibenarkan serta sistem yang membenarkannya;
• bilangan orang, profil tersimpan, profil disegerakkan dan sesi pelayar serentak;
• sistem pengendalian dan seni bina pemproses yang disokong;
• enjin pelayar, sambungan, proksi, penyedia identiti dan klien automasi yang diperlukan;
• kewajipan lokasi penyimpanan data, tempoh simpanan, eksport, pemadaman dan audit;
• jangkaan masa pemulihan dan kehilangan data yang boleh diterima;
• keperluan kebolehcapaian pengendali dan pentadbir;
• bajet, tempoh pengebilan, liputan sokongan dan syarat keluar; dan
• aliran kerja terlarang yang produk tidak boleh membolehkan pasukan anda lakukan.

Bezakan jenis sumber. Pelan dengan 500 profil tersimpan, 100 profil disegerakkan ke awan, lima tempat pengguna dan sepuluh sesi serentak tidak menyediakan 500 sesi pasukan serentak. Tukarkan setiap had kepada unit yang digunakan aliran kerja anda.

Kemudian tentukan syarat wajib yang tidak boleh dikompromi. Syarat lazim ialah:

1. binaan pelayar terkini yang disokong;
2. tiada kerosakan profil senyap atau penulis serentak;
3. identiti individu dengan akses keistimewaan minimum yang boleh dibatalkan;
4. tiada rahsia mentah dalam log biasa atau output automasi;
5. bukti audit yang boleh digunakan;
6. laluan pemulihan dan keluar yang telah diuji; dan
7. penggunaan sah serta dibenarkan yang mematuhi syarat perkhidmatan terpakai.

Jangan puratakan kegagalan syarat wajib ke dalam skor angka. Antara muka cantik tidak dapat menampung pengemas kini yang belum disahkan atau proses pemulihan yang kehilangan keadaan.

Gunakan skala bukti yang ringkas

Bagi setiap item, rekodkan hasil dan bukti terkuat yang diperoleh.

Hasil

• Lulus: keperluan dibuktikan dalam persekitaran ujian yang ditetapkan.
• Kebimbangan: tingkah laku bercanggah dengan keperluan atau membawa pertukaran yang penting.
• Belum disahkan: bukti tiada, tidak dapat dicapai, lapuk atau terlalu kabur untuk diputuskan.
• Tidak berkenaan: keperluan memang tidak terpakai pada aliran kerja, dengan sebab direkodkan.

Bukti

1. Dakwaan diterbitkan: bahan pemasaran atau jualan.
2. Dokumentasi teknikal: dokumentasi produk, keselamatan, API atau sokongan yang mempunyai versi.
3. Demonstrasi diperhatikan: demonstrasi langsung vendor menggunakan senario anda.
4. Percubaan terkawal: pasukan menghasilkan semula tingkah laku dengan data pakai buang serta merekodkan versi dan hasil.
5. Bukti bebas atau kontrak: penilaian berskop, komitmen bertandatangan atau syarat sokongan yang meliputi keperluan.

Tahap bukti lebih tinggi tidak semestinya lebih baik dalam setiap keadaan. Laporan bebas mungkin mengecualikan pelayar desktop, sedangkan percubaan terkawal mungkin mengujinya secara langsung. Rekodkan skop, tarikh, versi dan batasan setiap artifak.

1. Status produk dan batas dakwaan

• □ Adakah binaan sebenar yang boleh dipasang tersedia bagi setiap platform dan seni bina yang diperlukan?
• □ Bolehkah vendor mengenal pasti versi aplikasi, versi pelayar dan tarikh keluaran semasa?
• □ Adakah ciri beta, pratonton, eksperimen dan tersedia umum dilabel berasingan?
• □ Adakah dokumentasi dan percubaan sebenar sepadan dari segi had serta tingkah laku?
• □ Adakah dakwaan keselamatan, ketersediaan, penyulitan dan prestasi terhad pada komponen serta bukti tertentu?
• □ Adakah batasan diketahui, aliran kerja tidak disokong dan peraturan tamat sokongan diterbitkan?
• □ Adakah vendor mengelakkan jaminan tidak kelihatan, akaun kekal selamat atau akses kepada perkhidmatan pihak ketiga?

Simpan pemasang, paparan versi, nota keluaran dan dokumentasi berkaitan pada tarikh penilaian. Jawapan jualan tanpa rujukan stabil kekal sebagai dakwaan diterbitkan, bukannya tingkah laku yang disahkan.

2. Pengasingan dan integriti profil

Tentukan dahulu maksud ‘profil’ bagi produk. Ia mungkin direktori data pelayar kekal, konteks pelayar sementara, arkib disegerakkan, sesi jauh atau himpunan tetapan. Semua ini tidak setara.

Chromium mendokumenkan direktori data pengguna sebagai lokasi data pengguna dan menerangkan pemilihan direktori tersuai. Dokumentasinya juga menyebut keadaan apabila dua tika berjalan tidak boleh berkongsi satu direktori. Gunakan dokumentasi direktori data pengguna huluan sebagai permulaan, kemudian minta bukti khusus produk.

• □ Adakah setiap profil kekal mempunyai sempadan storan dan proses yang jelas?
• □ Adakah produk menghalang dua penulis membuka keadaan boleh ubah bagi profil yang sama?
• □ Adakah kuki, storan, cache, sejarah, sambungan, muat turun, kebenaran dan keutamaan diasingkan seperti didokumenkan?
• □ Adakah sesi sementara dan profil kekal dilabel berbeza?
• □ Adakah pelancaran bersih menggunakan hanya data profil yang dimaksudkan?
• □ Adakah mula semula mengekalkan tepat keadaan yang dijanjikan produk?
• □ Adakah kebenaran sambungan dan sumber pemasangannya dikawal?
• □ Adakah import profil dianggap input tidak dipercayai dan disahkan sebelum digunakan?
• □ Bolehkah profil rosak atau tidak serasi dikuarantin tanpa menimpa salinan yang diketahui baik?

Bukti percubaan perlu merangkumi ujian rentas profil. Letakkan penanda tidak berbahaya dalam profil A, sahkan ia tiada dalam profil B, mulakan semula kedua-duanya dan ulang selepas kemas kini aplikasi. Gunakan akaun pakai buang serta data rekaan.

3. Kesegaran pelayar, sandbox dan kemas kini

Pelayar ialah komponen yang penting untuk keselamatan dan memerlukan penyelenggaraan berterusan. Chrome beralih kepada kitaran keluaran Stable setiap dua minggu melalui Chrome 153 pada 8 September 2026. Jadual keluaran ini tidak menetapkan tahap perkhidmatan tepat yang dijanjikan setiap pembekal, tetapi menunjukkan mengapa dakwaan “berasaskan Chromium” tidak memadai tanpa bukti versi dan kemas kini.

• □ Bolehkah binaan pelayar produk dipadankan dengan versi huluan yang tepat?
• □ Adakah sasaran atau sejarah penerimaan kemas kini keselamatan huluan diterbitkan?
• □ Siapa memantau keluaran huluan dan pembaikan segera?
• □ Adakah kemas kini aplikasi dan pelayar ditandatangani serta disahkan secara berasingan daripada sambungan muat turun?
• □ Bolehkah nilai hash artifak, asal usul keluaran atau rantaian jagaan setara disahkan?
• □ Adakah pelaksanaan kemas kini dibuat berperingkat, dipantau dan boleh dihentikan?
• □ Adakah pengunduran mengelakkan pemulihan versi yang tidak selamat menurut dasar keselamatan semasa?
• □ Adakah migrasi skema profil diuji pada laluan naik taraf dan turun taraf yang disokong?
• □ Adakah sandbox pelayar kekal didayakan dalam operasi biasa?
• □ Bolehkah vendor menerangkan keperluan proses tanpa sandbox atau berkeistimewaan tinggi?

Chromium menerangkan sandbox sebagai sempadan yang mengehadkan kod tidak dipercayai dan menggunakan keistimewaan minimum pada kod dalam sandbox serta pengawalnya. Semak reka bentuk sandbox Chromium, kemudian minta vendor menunjukkan konfigurasi produksi sebenar. Kenyataan bahawa produk ‘menggunakan Chromium’ tidak membuktikan semua mitigasi huluan masih didayakan.

Bagi integriti kemas kini, The Update Framework ialah rujukan berguna kerana ia secara jelas menangani repositori dan kunci tandatangan yang terjejas. Asal usul binaan SLSA mentakrifkan maklumat boleh sah tentang tempat, masa dan cara artifak dihasilkan. Vendor tidak wajib menggunakan projek tepat ini, tetapi perlu menerangkan cara reka bentuknya menangani identiti artifak, kunci terjejas, pengunduran, pembekuan dan asal usul binaan.

4. Identiti, peranti dan keistimewaan minimum

NIST SP 800-53 Semakan 5 mengatur kawalan merentas akses, audit, pengesahan, perancangan kontingensi, tindak balas insiden dan risiko rantaian bekalan. Gunakan kumpulan itu sebagai panduan soalan, bukan menganggap penjajaran dengan rangka kerja sebagai bukti pelaksanaan.

• □ Adakah setiap orang menerima identiti individu, bukannya log masuk pasukan bersama?
• □ Adakah pengesahan berbilang faktor tersedia dan boleh diwajibkan bagi pentadbir serta peranan sensitif?
• □ Adakah pilihan pengesahan lebih kukuh yang tahan pancingan data disokong apabila risiko memerlukannya?
• □ Bolehkah identiti difederasikan dengan penyedia anda jika perlu, tanpa memintas kebenaran produk?
• □ Adakah peranan cukup terperinci untuk mengasingkan lihat, lancar, sunting, kongsi, eksport, padam, bil dan pentadbiran?
• □ Bolehkah akses dihadkan kepada organisasi, ruang kerja, folder atau set profil tertentu?
• □ Bolehkah akses peranti, sesi, pengguna, bukti kelayakan perkhidmatan atau jemputan dibatalkan segera?
• □ Adakah akaun perkhidmatan mempunyai identiti, tempoh luput, skop dan had kadarnya sendiri?
• □ Adakah perubahan kebenaran dan percubaan akses ditolak kelihatan dalam jejak audit?
• □ Adakah penamatan keahlian membuang akses tanpa perlu menukar kata laluan bersama?

Untuk istilah pengesahan dan panduan tahap jaminan semasa, rujuk NIST SP 800-63B-4, dimuktamadkan pada 31 Julai 2025. Sahkan bahagian produk yang diliputi dakwaan pengesahan vendor: log masuk laman, buka kunci desktop, API setempat, API awan, pemulihan dan akses sokongan mungkin menggunakan mekanisme berbeza.

5. Data sensitif dan sempadan kepercayaan

Lukis aliran data produk. Tandakan pengurus desktop, proses pelayar, perkhidmatan setempat, kawalan awan, storan penyegerakan, pengemas kini, pelapor ranap, alat sokongan dan integrasi pihak ketiga. Bagi setiap sempadan, tanya apa yang merentasinya dan mengapa.

• □ Kandungan profil mana kekal setempat secara lalai?
• □ Metadata dan kandungan sensitif mana dimuat naik apabila penyegerakan didayakan?
• □ Di mana penyulitan berlaku, dan pihak mana boleh memperoleh kunci penyahsulitan?
• □ Bagaimana kunci setempat dilindungi, disandarkan, digilirkan dan dipulihkan?
• □ Apa yang boleh dibaca pentadbir organisasi, sokongan vendor, pengendali infrastruktur dan klien automasi?
• □ Adakah kuki, kata laluan, bukti kelayakan proksi, rahsia dua faktor dan kunci penyulitan dikecualikan daripada antara muka biasa, log, telemetri, API dan output ejen?
• □ Bolehkah laporan ranap serta diagnostik dipratonton, disunting untuk melindungi maklumat sensitif, mengikut persetujuan dan mempunyai had simpanan?
• □ Bolehkah sokongan berfungsi tanpa meminta arkib profil atau bukti kelayakan mentah?
• □ Adakah sambungan import, arkib, muat turun pelayar dan metadata kemas kini dianggap tidak dipercayai?
• □ Adakah pemadaman ditakrifkan untuk salinan setempat, objek awan, sandaran, log dan artifak sokongan?

Jangan terima ‘disulitkan’ sebagai jawapan lengkap. Rekodkan kategori data, lokasi, sempadan penyulitan, pemegang kunci, laluan pemulihan dan keadaan apabila teks biasa wujud.

6. Kerjasama dan kebolehauditan

• □ Adakah pemilikan profil kekal jelas sepanjang penugasan dan serahan?
• □ Bolehkah produk menghalang atau menyelesaikan penyuntingan serentak secara jelas?
• □ Adakah jemputan, perubahan peranan, pelancaran, penghentian, perkongsian, eksport, pemadaman, panggilan automasi dan tindakan pemulihan direkodkan?
• □ Adakah setiap peristiwa mengenal pasti manusia yang bertindak, beban kerja diberi kuasa, sumber, masa, keputusan kebenaran dan hasil?
• □ Adakah nilai sebelum dan selepas perubahan konfigurasi penting direkodkan dengan rahsia disembunyikan?
• □ Adakah jam, zon waktu, urutan peristiwa dan pengecam permintaan tidak kabur?
• □ Adakah akses audit, format eksport, tempoh simpanan dan kawalan pemadaman didokumenkan?
• □ Bolehkah pentadbir mengubah atau memadam rekod yang digunakan untuk menyemak tindakannya sendiri?
• □ Bolehkah pasukan mengeksport log ke sistem pemantauan atau siasatan sendiri?
• □ Adakah pengelogan diteruskan, ditimbal dengan selamat atau operasi ditolak dengan selamat apabila destinasi audit tidak tersedia?

Panduan pengelogan OWASP mengesyorkan merekodkan kegagalan kebenaran dan tindakan berisiko tinggi, mencatat bila, di mana, siapa dan apa, sambil mengawal akses log serta mengecualikan rahsia teknikal. Terapkan ujian itu pada peristiwa sebenar yang dieksport produk, bukan sekadar tangkapan skrin halaman keselamatan.

7. Pemulihan, gangguan dan keluar

Dakwaan sandaran belum lengkap sehingga pemulihan diuji. Rangka Kerja Keselamatan Siber NIST 2.0 merangkumi hasil penciptaan, perlindungan, penyelenggaraan dan pengujian sandaran, serta pengesahan aset dan sistem yang dipulihkan.

• □ Bolehkah sandaran konsisten dicipta sambil mematuhi kunci penggunaan profil?
• □ Adakah versi setempat dan disegerakkan boleh dikenal pasti serta disusun?
• □ Bolehkah pengendali memulihkan versi dipilih tanpa memusnahkan salinan semasa?
• □ Adakah data dipulihkan dan keserasian pelayar disahkan sebelum penggunaan biasa disambung?
• □ Apa berlaku selepas proses pelayar dihentikan paksa, rangkaian hilang, cakera penuh, muat naik terganggu atau aplikasi ranap?
• □ Adakah versi terakhir yang diketahui baik dilindungi daripada pembaikan gagal?
• □ Bolehkah peranti hilang atau dibatalkan dibuang tanpa kehilangan satu-satunya laluan pemulihan?
• □ Adakah kunci atau kod pemulihan dilindungi daripada kehilangan tidak sengaja dan akses pentadbir tanpa had?
• □ Bolehkah pasukan mengeksport data dalam format didokumenkan dan mengesahkan eksport sebelum membatalkan perkhidmatan?
• □ Adakah proses pemadaman dan penutupan akaun disokong dengan penjelasan jelas tentang baki data yang disimpan?

Jalankan ujian pemulihan hanya dengan data percubaan pakai buang, kecuali vendor dan proses perubahan anda secara jelas menyokong latihan produksi. Rekodkan masa pemulihan, keadaan hilang, langkah manual, amaran dan versi produk. Demonstrasi berjaya pada satu profil kecil tidak membuktikan prestasi atau integriti pada skala produksi anda.

8. Automasi dan kawalan pembangun

• □ Adakah produk menyediakan operasi domain berversi, bukannya akses sistem fail atau proses tanpa had?
• □ Adakah keupayaan API, CLI, SDK, Playwright, CDP, WebDriver, webhook dan ejen didokumenkan secara berasingan?
• □ Adakah matriks keserasian pelayar dan klien yang tepat tersedia?
• □ Bolehkah bukti kelayakan dihadkan mengikut tenant, profil, operasi, penerima, tempoh luput, kadar dan kos?
• □ Adakah tindakan merosakkan, pukal, kelihatan kepada pihak luar, membawa rahsia atau melibatkan perbelanjaan memerlukan dasar atau kelulusan lebih ketat?
• □ Adakah pratonton terikat pada permintaan tepat yang akan dilaksanakan?
• □ Adakah arahan yang mengubah keadaan idempoten atau jelas tentang hasil tidak diketahui?
• □ Bolehkah operasi panjang dibatalkan dan disambung dengan selamat?
• □ Adakah pembatalan akses berkuat kuasa semasa tugas aktif?
• □ Bolehkah keputusan automasi dikaitkan dengan pelakunya dalam jejak audit yang sama dengan tindakan manusia?
• □ Bolehkah output automasi biasa kekal berguna tanpa memulangkan keadaan sesi mentah?
• □ Adakah mesej ralat cukup khusus untuk pemulihan tanpa membocorkan rahsia?

Uji laluan penolakan. Token baca sahaja sepatutnya gagal melancarkan profil. Token berskop profil sepatutnya gagal mengakses folder lain. Bukti kelayakan luput tidak sepatutnya diperbaharui secara senyap menjadi akses lebih luas. Ejen tidak sepatutnya dapat menukar panggilan ditolak menjadi kelulusan pentadbir dengan menulis semula permintaan.

9. Pengalaman pengendali dan kebolehcapaian

• □ Bolehkah pengguna papan kekunci mencapai, menggunakan dan meninggalkan setiap kawalan, dialog, jadual, menu dan tindakan profil?
• □ Adakah fokus kelihatan dan tersusun secara logik selepas navigasi, ralat dan perubahan dialog modal?
• □ Adakah label, ralat, perubahan status dan pengesahan tindakan merosakkan berfungsi dengan pembaca skrin?
• □ Adakah antara muka masih boleh digunakan apabila dizum atau saiz teks ditambah?
• □ Adakah warna, gerakan dan had masa boleh dilaras atau tidak penting untuk penggunaan?
• □ Bolehkah pengendali membezakan organisasi, profil, proksi, persekitaran dan keadaan risiko dipilih tanpa bergantung pada warna sahaja?
• □ Bolehkah tindakan pukal disemak tanpa memaksa pengguna melalui jadual padat yang tidak boleh dicapai?
• □ Adakah tingkah laku platform natif, pemberitahuan, pemilih fail, gesaan bukti kelayakan dan dialog kemas kini konsisten?

WCAG 2.2 menyediakan kriteria kandungan web yang boleh diuji, termasuk operasi papan kekunci, urutan dan keterlihatan fokus, saiz sasaran, pengenalpastian ralat serta pengesahan boleh capai. Produk desktop mungkin mengandungi antara muka natif dan web, jadi gabungkan pemeriksaan piawaian berkaitan dengan ujian teknologi bantuan pada setiap sistem pengendalian disokong.

10. Kesesuaian komersial dan operasi

• □ Adakah tempat pengguna, profil tersimpan, profil disegerakkan, storan, trafik, sesi serentak, kadar API, pekerja automasi dan tahap sokongan dihargakan secara berasingan serta jelas?
• □ Had mana merupakan sekatan mutlak, caj lebihan atau syarat penggunaan saksama?
• □ Bolehkah perubahan bil atau kapasiti berlaku tanpa kelulusan pentadbir?
• □ Adakah protokol proksi, kaedah pengesahan, sambungan dan persekitaran rangkaian disokong didokumenkan?
• □ Adakah dasar sokongan meliputi insiden kemas kini pelayar, kerosakan profil, pemulihan gagal, laporan keselamatan dan pemulihan akaun?
• □ Adakah status perkhidmatan, komunikasi insiden dan laluan eskalasi benar-benar tersedia serta dipantau?
• □ Adakah kontrak mentakrifkan pemulangan data, pemadaman, perubahan harga, penggantungan dan penamatan?
• □ Bolehkah anda keluar tanpa kehilangan bukti yang diperlukan untuk membuktikan migrasi selamat?

Kira kos menggunakan puncak kerja serentak, keadaan disegerakkan yang dijangka, jumlah automasi dan keperluan sokongan. Rekodkan cukai, komitmen tahunan, caj lebihan dan tenaga kerja migrasi. Elakkan membandingkan hanya angka profil terbesar pada setiap halaman harga.

Pelan percubaan terkawal

Gunakan akaun ujian, bukti kelayakan rekaan dan profil yang dicipta untuk penilaian. Jangan import kuki produksi semata-mata untuk menjadikan percubaan realistik.

1. Rekodkan persekitaran. Catat versi aplikasi dan pelayar, sistem pengendalian, perkakasan, rangkaian, jenis proksi, set sambungan, pelan akaun dan tarikh ujian.
2. Cipta dua peranan dan beberapa profil. Sertakan pentadbir, pengendali terhad, folder berasingan dan sekurang-kurangnya satu profil yang tidak boleh dicapai pengendali.
3. Jalankan aliran kerja biasa. Lancarkan, gunakan, hentikan, serahkan dan lancarkan semula profil. Rekodkan keadaan dijangka serta sebenar.
4. Uji penolakan. Cuba profil di luar skop, eksport, perubahan peranan dan arahan automasi menggunakan identiti terhad.
5. Uji gangguan. Dengan data pakai buang, ganggu penghentian pelayar atau langkah penyegerakan menggunakan kaedah disokong vendor atau kaedah selamat lain. Sahkan laluan pemulihan.
6. Pulihkan dan bandingkan. Pulihkan petikan keadaan diketahui ke salinan baharu, sahkan integritinya dan simpan salinan semasa sehingga diterima.
7. Batalkan akses. Buang pengguna, peranti, sesi dan bukti kelayakan perkhidmatan; sahkan penolakan antara muka serta API dan periksa peristiwa audit.
8. Periksa kebolehpindahan. Eksport data dibenarkan, periksa format didokumenkan, import semula ke destinasi pakai buang jika disokong dan kenal pasti perkara dikecualikan.
9. Semak kebolehcapaian. Selesaikan tugas utama menggunakan papan kekunci dan teknologi bantuan berkaitan pada setiap platform diperlukan.
10. Padankan kos dan dakwaan. Bandingkan penggunaan sumber diperhatikan serta respons sokongan dengan cadangan dan kontrak.

Templat rekod keputusan

Keperluan	Keutamaan	Hasil	Bukti dan tarikh	Batasan atau risiko	Pemilik dan tindakan seterusnya
Contoh: pengendali tidak boleh mengeksport keadaan sesi	Syarat wajib	Lulus	Percubaan terkawal, versi X, YYYY-MM-DD	API sahaja; CLI belum diuji	Ketua keselamatan menguji CLI

Tutup penilaian dengan empat senarai jelas:

• syarat wajib yang lulus dengan bukti mencukupi;
• kebimbangan yang diterima pemilik bernama serta tarikh semakan;
• item yang masih belum disahkan;
• keadaan yang mencetuskan penilaian semula, seperti enjin pelayar, penyedia identiti, pengemas kini, model harga atau format profil baharu.

Tanda amaran lazim

Tangguhkan keputusan apabila:

• versi pelayar tidak dapat dikenal pasti;
• sandbox mesti dinyahdayakan untuk penggunaan biasa;
• pentadbir dan automasi berkongsi bukti kelayakan kekal;
• produk bergantung pada perkongsian kuki atau kata laluan mentah untuk serahan pasukan;
• API boleh mengeksport rahsia yang didakwa dilindungi oleh antara muka;
• peristiwa audit tidak menyatakan pelaku atau tidak boleh dieksport;
• ‘sandaran’ hanya bermaksud salinan awan wujud, tanpa pemulihan yang ditunjukkan;
• vendor tidak dapat menjelaskan penulisan terganggu atau akses profil serentak;
• aliran kerja penting tidak boleh dicapai dan tiada alternatif;
• laporan keselamatan memerlukan penghantaran rahsia melalui e-mel biasa; atau
• dakwaan produk menjanjikan tidak dapat dikesan, akses akaun terjamin atau pengelakan penguatkuasaan platform.

Hasil ‘belum disahkan’ bukan tuduhan. Ia pernyataan tepat tentang bukti yang tiada. Kekalkan status itu sehingga vendor menyediakan bukti, pasukan menguji tingkah laku atau pemilik keputusan menerima risikonya.