既然可以放弃密码，为什么还要保护它？

一个我们早已习以为常的问题

几乎所有 Web 应用程序都有一个管理面板，而管理面板通常也有一个登录地址、一个身份验证表单、一组用户名和密码。

我们对这种模式早已习以为常，以至于几乎不再问：一切真的非得这样运行吗？

当你只有一个网站时，这个问题似乎并不严重。设置一个复杂的密码，启用双重身份验证，限制登录尝试次数，然后继续工作。

但当项目增加到十个、二十个，甚至三十个时，会发生什么？

就我而言，这涉及 DigiMeld 生态系统，它包含三十多个独立的软件项目。每个项目都有自己的架构、服务器端逻辑和管理界面。

因此，每个项目都需要一种管理访问机制。

很长一段时间里，我采用的是相当常见的做法：为每个项目设置独立的管理凭据、复杂密码，并将它们保存在浏览器中。

这套做法确实可行。

但后来我开始思考：为什么我非得保存这么多管理密码？为什么我不仅要保护服务器，还要保护获取服务器访问权限的手段？

有没有可能摆脱这种需求？

我逐渐形成了一个想法，后来它成了我的解决方案的基础：

也许，我们应该保护的不是一个长期存在的登录入口，而是临时获取访问权限的资格。

复杂密码并不能消除问题本身

现代工具可以生成熵值很高的密码。正确生成的长随机密码，几乎不可能通过穷举破解。

但无论密码有多复杂，都必须在某处保存，然后再拿来使用。

我们可以使用密码管理器、硬件密钥、多因素身份验证和额外的访问限制。这些措施确实能提高安全性。

然而，架构上的基本模式依然存在：用户仍要通过某个特定界面提交自己的凭据。

攻击者可以向它发送请求、对它进行扫描，它也可能成为自动化攻击的目标。

我们可以隐藏管理面板的地址，用一串很长的随机字符替换默认路径，或者按 IP 限制访问。

但这样又会带来一个新问题：这个地址该存在哪里，又该如何使用？

更重要的是，如果我们只在特定时刻才需要管理访问，为什么还要保留一个长期存在的入口？

我最终得出了一个想法，后来它成了我的解决方案的基础：

也许，我们应该保护的不是一个长期存在的登录入口，而是临时获取访问权限的资格。

如果传统的登录页面根本不存在呢？

我决定在自己的项目中放弃传统的管理身份验证模式。

不是简单地把登录表单藏起来。

不是更改登录地址。

也不是换成一个更复杂的密码。

而是消除长期存在的密码登录入口。

当然，管理界面并没有消失。管理应用程序依然离不开它们。

改变的是获取访问权限的方式。

现在，登录已接入的项目管理面板时，不需要输入保存好的用户名和密码。

取而代之的是，我使用自己开发的身份识别与访问管理系统 MeldID。

基本思路很简单：只有在确有需要时，才向特定用户授予对特定项目的管理访问权限。

而且，仅仅拥有一个账户，并不意味着有权打开管理面板。

这项权限必须单独授予。

一分钟前还不存在的访问权限

这大概是整个理念中最有意思的部分。

在传统模式下，管理员始终拥有登录凭据。只要凭据仍然有效，他今天、明天或一个月后都可以使用它们。

我决定改变这一原则。

系统不再使用长期有效的管理凭据，而是提供一种临时发起登录的方式。

用户可以通过可信任的移动设备按需创建这种方式。它包含具有密码学强度的随机成分，并且有效期有限。

但即使拿到了这个临时链接，也不代表已经获得访问权限。

这一点至关重要。

假设有人通过某种方式拿到了链接。在一个完全依赖地址保密性的系统中，这种泄露可能会成为严重问题。

而在我的模式中，这个链接只能用于启动确认流程。

若要继续操作，还必须通过 MeldID 可信任的移动设备单独批准。

没有相应的确认，就不会创建管理会话。

正因如此，我将临时链接视为访问授权流程的一环，而不是密码的替代品。

知道该去哪里，与拥有进入权限，是完全不同的两回事。

手机成为访问管理工具

在这种模式中，移动设备扮演的角色远不止生成一次性验证码。

它用于确认与管理访问有关的操作。

当我想打开管理面板时，系统会要求通过 MeldID 进行确认。

我会在可信任的设备上看到相应请求，并确认这项操作。

只有验证成功后，系统才允许继续登录流程。

而且，确认针对的是具体操作，而不仅仅是手机已解锁这一事实。

移动设备的生物识别功能在本地验证用户身份，服务器端则验证来自已注册设备的密码学签名。

采用这种方式，就不必只依赖密码，也不必只相信用户据称已经确认登录的提示。

这里还有一个额外的优势：可信任设备可以统一管理。

如果某台设备不再应该用于确认访问权限，可以撤销它的可信状态。

之后，这台设备就不再是相关操作的有效身份验证手段。

一个系统，多个彼此独立的项目

开始开发这套机制时，我的一项主要任务是保持每个项目的独立性。

我不想把所有管理面板合并成一个庞大的应用程序。

DigiMeld 的每项服务都应继续管理自己的逻辑、设置、用户和数据。

因此，我把这两项职责分开了。

MeldID 负责身份识别和授予管理访问资格。

而项目本身则负责自己的管理功能，并验证当前有效的权限。

由此形成了集中式的访问管理模式，却无需将应用程序本身集中起来。

此外，权限是分别授予的。

某个项目的管理员不会仅仅因为拥有 MeldID 账户，就自动获得其他项目的访问权限。

每个管理范围都可以单独指定获准访问的用户。

普通用户权限与管理权限也彼此分离。

对于拥有数十项服务的生态系统来说，这一点尤其方便。

为什么我更喜欢临时访问，而不是长期访问

我还在系统中有意采用了另一项原则。

管理访问不应无限期保留。

权限只在有限时间内有效，无论用户是否仍在浏览器中工作，到期后都会失效。

如果要在期限结束后继续工作，就必须重新完成确认流程。

这样可以避免一次身份验证就变成长期有效的权限。

但仅仅限制有效期还不够。

提前终止已授予的访问权限同样很重要。

因此，MeldID 支持集中撤销管理授权。

授权被撤销时，已接入的项目会收到相应事件，并废止相关的管理会话。

因此，访问管理不会在用户成功登录的那一刻结束。

在我看来，撤销权限的能力，与授予权限的能力同样重要。

与此同时，分布式系统必须考虑事件传递延迟、个别组件暂时不可用以及其他运维情况。会话有效期限制则提供了额外的一道边界。

日常工作发生了什么变化？

首先，我不再需要频繁查找保存好的管理密码。

我不必再在浏览器中保存一组组凭据，用来登录每个已接入的管理面板。

取而代之的是，我通过统一机制管理授权。

选择所需的项目，确认访问，然后开始工作。

不再需要管理访问时，就可以撤销它。

特别方便的一点是，新增项目时，不必重新设计整套管理身份验证系统。

只需将新项目接入现有模式，并设置所需的权限即可。

当然，这并不意味着所有安全风险都消失了。

临时授权、可信任设备、服务器会话和中心基础设施同样需要保护。

但我不再需要为每个应用程序单独解决同一个管理密码问题。

这正是我最初的目标之一。

这类技术不是早就存在了吗？

当然存在。

无密码身份验证、特权访问管理、临时授权以及通过可信任设备确认操作，在信息安全行业早已不是什么新鲜事。

这些方法常见于身份与访问管理（Identity and Access Management）、特权访问管理（Privileged Access Management）系统以及零信任（Zero Trust）理念中。

我并不声称这些原则是我发明的。

我的目标有所不同。

我需要创建一套集成的自有系统，解决 DigiMeld 基础设施中的具体问题，并能够管理多个独立项目的管理访问权限。

最终，我将几种已有方法整合进一个符合自身需求的架构中。

我认为，工程工作的价值不一定在于发明一种全新的技术。

有时，价值在于正确地界定问题，并找到合适的解决方案。

MeldID 不仅用于管理面板

这里需要特别说明一点。

MeldID 的开发目的并不只是管理我自己的访问权限。

它还为开发者提供 SDK，方便他们在自己的应用程序中集成身份识别和登录确认机制。

而且，这个 SDK 可免费使用。

例如，第三方开发者可以将 MeldID 作为用户身份验证的额外确认层。

即使应用程序仍然采用传统的用户名和密码登录，正确输入这些信息也可能不足以完成身份验证。

系统会向用户的可信任移动设备发送请求，用户可以在设备上确认或拒绝此次登录尝试。

当凭据遭到泄露时，这有助于降低未经授权访问的风险。

需要区分 MeldID 这项面向公众开放的功能，以及我为 DigiMeld 项目开发的管理访问模式。

它们采用了相同的信任与操作确认原则，但解决的是不同的问题。

安全不仅意味着保护现有机制

开发这套系统的过程，让我以不同的视角看待习以为常的身份验证机制。

我们常常试图保护那些只是因为历史原因而存在的东西。

于是，我们不断增加检查、限制、额外密码和防护层。

有时这确实是必要的。

但有时，换一个问题来问会更有帮助：

我们正在保护的机制，真的必须以原来的形式存在吗？

对我来说，答案是否定的。

我并不需要一个始终开放的管理登录表单。

我需要的是在确有必要时安全地获取管理权限。

这是两个不同的问题。

从前一个问题转向后一个问题，不仅改变了技术架构，也改变了我日常管理项目的方式。

不是终点，而是选定的方向

如今，这套架构已经在 DigiMeld 生态系统的很大一部分中投入使用。

其余项目也在逐步迁移到新的管理访问模式。

我会逐步进行迁移，检查每个应用程序的运行情况，并计划在迁移完成后对整个系统进行额外审计。

部分界面元素和会话管理规则仍可能发生变化。

但核心理念已经确定。

我不想再回到这样的模式：为了管理数十个自己的项目，我必须长期保存并使用数十个管理密码。

与此同时，我并不认为自己的实现适用于所有人。

不同组织有不同的需求、基础设施、威胁模型和管理方式。

适合 DigiMeld 生态系统的做法，不一定是其他开发者的最佳选择。

不过，临时授予权限这一原则值得关注。

结语

我决定分享这段经历，不是因为我认为自己发明了一种新的身份验证方式。

也不是因为我想把某个系统包装成绝对安全的方案。

绝对安全并不存在。

我只是觉得，这个问题本身很有意思。

与其无休止地保护一个长期存在的管理登录入口，不如重新审视它是否有存在的必要。

与其保存一大堆密码，不如使用临时授权。

与其在首次身份验证后自动信任用户，不如针对具体权限的授予进行确认。

与其只能等待会话过期，不如提供集中撤销访问权限的能力。

最后，与其在每个项目中单独实现登录机制，不如构建一个统一的管理访问系统，同时保留各个应用程序的独立性。

我并不声称这种方法能够杜绝被攻破的可能。

它只是把重点从保护长期存在的凭据，转移到了对权限授予与撤销的可控管理上。

也许，有时缩小攻击面最有效的办法，不是再增加一层防护，而是舍弃系统完全可以不依赖的东西。

对我来说，MeldID Admin Gateway 的故事正是从这个想法开始的。