设计人们真正能够操作的安全产品

我设计数字产品大约二十五年，其中不少在网络安全领域：在 Exein 担任设计负责人三年，从事嵌入式安全工作；如今是 Shorium 的联合创始人兼 CTO。

我一再重新学到的一课很简单：一款安全产品的价值，取决于人们借助它能做出的决策。

检测、分析和密码学可能都很出色。但如果屏幕前的人看不出什么重要、为什么重要、下一步该做什么，产品就会在最需要它的时候失效。

安全界面失败的两种方式

什么都展示。 每一条告警、每一个发现、每一行日志，视觉权重完全相同。界面在技术上是完整的，在实践中却无法使用。人们学会忽略它，这比什么都没有更糟。

什么都隐藏。 一个分数、一枚绿色徽章、一盏红绿灯。看起来简单又令人安心。但当有人问“为什么是红色？“或”我们确定这是绿色吗？“时，界面给不出答案。

两者都源于同一个错误：把简洁理解为删除信息，而不是组织信息。

1. 从决策出发，而不是从数据出发。 在设计一个界面之前，先写下用户在这里必须做出的决策。现在修补还是稍后？升级还是关闭？涉及哪个产品？界面上的每个元素都应服务于其中某个决策。

2. 让严重程度有意义。 严重程度应结合问题本身有多严重与这个具体系统的暴露程度。不可访问组件中的严重漏洞，与暴露接口上的中等漏洞并不相同。要展示某项为何被排在那个位置。

3. 始终展示来源。 这个发现从何而来？哪次扫描、哪条规则、哪些数据、什么时间？在安全领域，对工具的信任取决于能否对其进行核查。

4. 在操作之前展示后果。 如果用户即将吊销证书、轮换密钥或推送更新，先展示有哪些东西依赖于它。安全领域代价最高的错误，往往是出于好意却带来隐形副作用的改动。

5. 为事件而设计，而不是为演示而设计。 演示发生在平静的日子里，数据干净。真实使用发生在凌晨两点，压力之下，信息不全。在这些条件下测试你的界面：疲惫的用户、不完整的数据、大量同时出现的告警。

6. 记录决策过程。 安全工作需要接受审计，像《网络韧性法案》这样的法规要求提供证据。界面应该让记录“谁基于什么信息做了什么决定”变得容易。

7. 让它无障碍。 安全团队中的人能力各异，使用不同设备，常常处于压力之下。在这里，无障碍不是礼貌，而是运营韧性。

安全之所以复杂，是因为它所保护的系统复杂。设计的任务不是让复杂性消失，而是让它可以被驾驭：先看全局，按需查看细节，并提供一条从“出问题了”到“我们这样处理”的清晰路径。

这一原则影响着我们在 Shorium 对 Trust Twin 的思考。密码依赖关系模型只有在人能够借助它进行推理时才有用。我在《我为什么要做 Shorium》中写过这一点。

好的安全设计不是让人感到安全，而是帮助人做出正确的判断。