如何评估团队浏览器：实用检查清单

看价格页之前，先定义决策

有用的评估从工作开始，而不是先列厂商。请写下：

• 获授权流程，以及允许这些流程的系统。
• 人员数、已保存配置文件数、同步配置文件数和同时运行的浏览器会话数。
• 必需的操作系统与处理器架构。
• 必需的浏览器引擎、扩展、代理、身份提供者与自动化客户端。
• 数据驻留、保留、导出、删除与稽核义务。
• 恢复时间及可接受数据损失。
• 操作人员与管理员的无障碍需求。
• 预算、计费周期、支持范围与退出条件。
• 团队禁止、产品也不应协助执行的工作流。

不同资源应分别计算。500 个已保存配置文件、100 个云端同步配置文件、5 个席位和 10 个并发会话，并不等于 500 个同时工作的团队会话。把每个限制换算成工作流实际消耗的单位。

再列出不可妥协的必要条件。常见组合是：

1. 受支持且及时更新的浏览器。
2. 不会无声损坏配置文件或允许并发写入同一状态。
3. 独立身份、可撤销的最小权限访问。
4. 普通日志和自动化输出不含原始机密。
5. 可用的稽核证据。
6. 已测试的还原与退出路径。
7. 合法、获授权，并符合适用服务条款的使用。

必要条件失败时，不要用其他项目分数把它平均掉。精美界面不能补偿未经验证的更新程序，也不能补偿会丢失状态的还原流程。

使用简单的证据分级

每项检查记录结果，以及获得的最有力证据。

结果

• 通过： 已在定义明确的测试环境证明符合要求。
• 存在疑虑： 行为与要求冲突，或带来重大取舍。
• 未验证： 证据缺失、不可访问、过时或过于模糊。
• 不适用： 确实不适用于该流程，并记录原因。

证据

1. 公开宣称： 营销或销售文案。
2. 技术文档： 有版本的产品、安全、API 或支持资料。
3. 观察演示： 厂商用你的场景进行实时演示。
4. 受控试用： 团队使用可丢弃数据复现行为，记录版本和结果。
5. 独立或合同证据： 有明确范围的评估、签署承诺，或覆盖要求的支持条款。

更高等级不总是更适用。独立报告可能排除桌面浏览器，受控试用却直接测试它。每份材料都记录范围、日期、版本与限制。

1. 产品状态与宣称边界

• □ 每个必需平台和架构是否都有可安装的真实构建？
• □ 能否提供当前应用版本、浏览器版本和发布日期？
• □ Beta、预览、实验性与正式可用功能是否分别标识？
• □ 文档与试用中的限制、行为是否一致？
• □ 安全、可用性、加密和性能宣称是否对应具体组件和证据？
• □ 是否公开已知限制、不支持流程与终止支持规则？
• □ 是否避免承诺隐形、账号存活或必定能访问第三方服务？

保留评估日期的安装程序、版本页面、发布说明和相关文档。没有稳定引用的销售回答仍是宣称，不是已验证行为。

2. 配置文件隔离与完整性

先定义产品所谓的配置文件：它可能是持久化浏览器目录、临时上下文、同步封存包、远程会话或一组设置。这些并不等价。

Chromium 说明了用户数据目录的用途和自定义方法，也指出两个运行实例无法共用同一目录的情况。以上游用户数据目录文档为起点，再要求产品自身证据。

• □ 每个持久化配置文件是否有明确存储与进程边界？
• □ 是否阻止两个写入者打开同一可变状态？
• □ Cookie、存储、缓存、历史、扩展、下载、权限和偏好是否按文档隔离？
• □ 临时会话与持久化配置文件是否分别标识？
• □ 干净启动是否只使用预期数据？
• □ 重启是否保留产品承诺的状态？
• □ 扩展权限和安装来源是否受控？
• □ 导入配置文件是否视为不可信输入，并在使用前验证？
• □ 能否隔离损坏或不兼容配置文件，而不覆盖已知正常副本？

试用应包括跨配置文件测试。在 A 放无害标记，确认 B 没有；重启两者再检查，应用更新后再重复。使用可丢弃账号和合成数据。

3. 浏览器更新时效、沙箱与更新

浏览器是关系到安全的软件组件，需要持续维护。自2026年9月8日发布的 Chrome 153 起，Chrome Stable 改为每两周发布一个新版本。这个发布周期并不直接规定各供应商的具体服务承诺，但说明了为什么仅有“基于 Chromium”的说法还不够，还需要版本和更新方面的证据。

• □ 浏览器构建能否对应确切上游版本？
• □ 是否公开采用上游安全修复的目标或历史？
• □ 谁监控上游发布和紧急修复？
• □ 应用和浏览器更新是否独立于下载连接进行签名和认证？
• □ 能否验证成品摘要、发布来源证明或等效保管链？
• □ 推广是否分阶段、受监控且可停止？
• □ 回退是否避免恢复到当前安全策略认为不安全的版本？
• □ 配置文件结构迁移是否测试了受支持的升级与降级路径？
• □ 正常运行是否启用浏览器沙箱？
• □ 厂商能否解释未沙箱化或高权限进程及其必要性？

Chromium 将沙箱描述为限制不可信代码的边界，并对沙箱代码及控制器应用最小权限。阅读沙箱设计后，要求查看产品实际正式配置。“使用 Chromium”不能证明保留了所有上游防护。

更新完整性可参考 The Update Framework，它明确处理仓库与签名密钥入侵。SLSA 来源证明定义了可验证的构建地点、时间和方式。厂商不必使用这些项目，但应说明如何处理成品身份、密钥泄露、降级、冻结和构建来源。

4. 身份、设备与最小权限

NIST SP 800-53 第 5 版将控制分为访问、稽核、认证、应急、事件响应和供应链风险等类别。用它们辅助提问，不要把声称符合框架当作已实现证据。

• □ 每个人是否有独立身份，而非共享团队登录？
• □ 管理员和敏感角色是否可使用并强制启用多因素认证？
• □ 风险要求时，是否支持更强的抗钓鱼认证？
• □ 需要时能否联合现有身份提供者，而不绕过产品授权？
• □ 角色是否能区分查看、启动、编辑、共享、导出、删除、账务与管理？
• □ 能否限定到组织、工作区、文件夹或明确配置文件集？
• □ 能否迅速撤销设备、会话、用户、服务凭证或邀请？
• □ 服务账号是否有独立身份、到期、范围和速率限制？
• □ 权限变更与授权失败是否可在稽核中看到？
• □ 离场是否能不修改共享密码就移除访问？

当前认证术语与保证级别可参阅 2025 年 7 月 31 日定稿的 NIST SP 800-63B-4。确认宣称覆盖哪些部分：网站登录、桌面解锁、本地 API、云端 API、恢复和支持访问可能采用不同机制。

5. 敏感数据与信任边界

画出桌面管理器、浏览器进程、本地服务、云端控制层、同步存储、更新程序、崩溃报告、支持工具和第三方集成的数据流。对每个边界询问：什么跨越它，为什么？

• □ 哪些配置文件内容默认本地保存？
• □ 同步时上传哪些元数据和敏感内容？
• □ 在哪里加密，哪些人能获得解密密钥？
• □ 本地密钥如何保护、备份、轮替和恢复？
• □ 组织管理员、厂商支持、基础设施运维和自动化客户端能读什么？
• □ 普通界面、日志、遥测、API 和代理输出是否排除 Cookie、密码、代理凭证、双因素机密及密钥？
• □ 崩溃和诊断报告是否可预览、脱敏、尊重同意设置并限定保留期？
• □ 支持能否不索取原始配置文件包或凭证就工作？
• □ 导入扩展、封存包、浏览器下载及更新元数据是否视为不可信？
• □ 删除是否定义到本地副本、云对象、备份、日志及支持材料？

“已加密”不是完整答案。记录数据类别、位置、加密边界、密钥持有人、恢复路径和明文出现情形。

6. 协作与可稽核性

• □ 分配与交接时，配置文件责任是否明确？
• □ 能否防止或明确解决同时编辑？
• □ 邀请、角色变化、启动、停止、共享、导出、删除、自动化和恢复是否有记录？
• □ 每个事件是否标明人员、委派工作、资源、时间、决定和结果？
• □ 重大配置变更是否记录前后值，并遮蔽机密？
• □ 时钟、时区、事件顺序和请求标识是否明确？
• □ 稽核访问、导出格式、保留和删除控制是否有文档？
• □ 管理员能否修改或删除用来审查自身的记录？
• □ 能否导出日志到团队监控或调查系统？
• □ 稽核目的地不可用时，会继续、安全缓冲，还是阻止操作？

OWASP 日志指南建议记录授权失败与高风险行为，保留时间、地点、人物和事件，同时控制访问并避免技术机密。应检查真实导出事件，不只是安全页面截图。

7. 恢复、中断与退出

没有测试还原，备份宣称就不完整。NIST 网络安全框架 2.0涵盖备份创建、保护、维护、测试，以及验证还原资产与还原后系统。

• □ 能否遵守配置文件锁而创建一致备份？
• □ 本地与同步版本是否可识别、有顺序？
• □ 能否还原选定版本而不破坏当前副本？
• □ 恢复工作前是否验证数据与浏览器兼容性？
• □ 浏览器被强制结束、断网、磁盘满、上传中断或应用崩溃会怎样？
• □ 修复失败是否保护最后已知正常版本？
• □ 移除失窃或已撤销设备时，会不会失去唯一恢复路径？
• □ 恢复密钥或代码是否既防意外丢失，也防管理员不受限读取？
• □ 取消服务前能否按文档格式导出并验证数据？
• □ 是否有受支持的删除与关户流程，说明残留保留情况？

除非厂商及团队变更流程明确支持正式演练，否则只用可丢弃试用数据测试。记录恢复时间、丢失状态、手动步骤、警告与版本。一个小配置文件成功，不能证明正式规模的性能和完整性。

8. 自动化与开发者控制

• □ 提供的是有版本的业务操作，还是无限文件系统、进程访问？
• □ API、CLI、SDK、Playwright、CDP、WebDriver、Webhook 和代理能力是否分别说明？
• □ 是否有确切的浏览器与客户端兼容矩阵？
• □ 凭证能否按租户、配置文件、操作、受众、到期、速率与费用限制？
• □ 破坏性、批量、对外可见、携带机密或花费操作是否需要更强策略或批准？
• □ 预览是否绑定确切执行请求？
• □ 修改命令是否幂等，或明确说明结果未知？
• □ 长任务能否取消并安全继续？
• □ 撤销能否在任务运行中生效？
• □ 自动化决定是否与人工操作在同一稽核中可追溯？
• □ 普通输出能否不返回原始会话状态也保持实用？
• □ 错误是否足够具体以帮助恢复，又不泄密？

测试拒绝路径。只读令牌应无法启动配置文件；限定配置文件的令牌应无法访问其他文件夹；过期凭证不能悄悄刷新成更大权限。代理也不能通过改写请求，把拒绝转成管理员批准。

9. 操作体验与无障碍

• □ 键盘能否到达、操作并离开每个控件、对话框、表格、菜单和配置文件操作？
• □ 导航、错误或模态变化后，焦点是否可见且顺序合理？
• □ 标签、错误、状态变化和破坏性确认是否适配屏幕阅读器？
• □ 缩放或增大文字后是否仍可用？
• □ 颜色、动态效果和时限是否可调，或不是必要条件？
• □ 能否不只靠颜色区分组织、配置文件、代理、环境与风险状态？
• □ 批量操作能否审查，而不强迫使用难以访问的密集表格？
• □ 原生平台行为、通知、文件选择器、凭证提示和更新对话框是否一致可靠？

WCAG 2.2包含键盘、焦点顺序与可见性、目标大小、错误识别和无障碍认证等可测试要求。桌面产品可能同时包含原生与网页界面，应在每个支持系统上结合相关标准和辅助技术测试。

10. 商务与运营适配

• □ 席位、保存与同步配置文件、容量、流量、并发会话、API 速率、自动化工作程序与支持等级是否分别清楚计价？
• □ 哪些限制直接阻止操作，哪些产生超额费用或受合理使用条款约束？
• □ 账务或容量变更会不会未经管理员批准发生？
• □ 支持的代理协议、认证、扩展和网络环境是否有文档？
• □ 支持政策是否覆盖更新事故、配置文件损坏、恢复失败、安全报告和账号恢复？
• □ 状态页面、事件沟通和升级渠道是否真实有人监控？
• □ 合同是否定义数据返还、删除、调价、暂停和终止？
• □ 离开后是否保留证明安全迁移所需的证据？

按峰值并发工作、预计同步状态、自动化量和支持需求计算成本。记录税费、年约、超额费用和迁移人力，不要只比较价格页上最大的配置文件数字。

受控试用计划

使用测试账号、合成凭证和专用配置文件，不要为了真实感导入正式 Cookie。

1. 记录环境。 应用和浏览器版本、系统、硬件、网络、代理、扩展、账号方案和日期。
2. 建立两种角色与多个配置文件。 包含管理员、受限操作人员、不同文件夹，以及至少一个不允许其访问的配置文件。
3. 执行正常流程。 启动、使用、停止、交接、重开，记录预期与实际状态。
4. 测试拒绝。 用受限身份尝试范围外配置文件、导出、改角色与自动化命令。
5. 测试中断。 用可丢弃数据，通过厂商支持或其他安全方法中断停止或同步，验证恢复。
6. 还原并比较。 已知快照恢复到新副本，核验完整性，验收前保留当前副本。
7. 撤销访问。 移除用户、设备、会话和服务凭证，确认界面与 API 都拒绝，并检查稽核。
8. 检查可携带性。 导出允许数据、查看格式；支持时导入可丢弃目标，记录遗漏。
9. 检查无障碍。 在各必要平台用键盘与相关辅助技术完成核心任务。
10. 核对成本与宣称。 将观察到的资源使用及支持回复对照提案和合同。

决策记录模板

要求	优先级	结果	证据与日期	限制或风险	负责人及下一步
示例：操作人员不能导出会话状态	必要条件	通过	受控试用，版本 X，YYYY-MM-DD	仅 API，CLI 未测	安全负责人测试 CLI

评估结束时明确列出四份清单：

• 有充分证据支持通过的必要条件。
• 具名负责人已接受、且有复查日期的疑虑。
• 仍未验证的项目。
• 触发重新评估的变化，例如浏览器引擎、身份提供者、更新器、计费模型或配置文件格式。

常见警讯

遇到以下情况应暂停决策：

• 无法确认浏览器版本。
• 正常使用必须关闭沙箱。
• 管理员和自动化共用永久凭证。
• 团队交接依赖原始 Cookie 或密码共享。
• API 能导出界面宣称保护的机密。
• 稽核事件缺少执行者或无法导出。
• “备份”只是有云副本，未展示还原。
• 无法解释写入中断或并发访问。
• 关键流程无法无障碍使用，也无替代方案。
• 安全报告要求通过普通邮件发送机密。
• 宣称无法检测、保证账号访问或规避平台执行措施。

“未验证”不是指控，而是准确说明缺少证据。在厂商补充证据、团队完成测试，或决策负责人接受风险前，应保持可见。