保险库守住了。入口从来不在那里。

本月，LastPass 再次遭到入侵。所有人提心吊胆的那部分并没有发生。没有保险库被破解。没有主密码失守。加密的机密数据原封未动。LastPass 确认其「产品、服务和基础设施未受影响」，且客户保险库「保持安全」。[1]

攻击者从未靠近保险库。他们从一个供应商走了进来。

机制是关键，所以把链条讲清楚。6 月 11 日，一个自称 Icarus 的团伙攻入了 Klue，即 @LastPass 内部使用的一个市场情报平台。据处理该事件的 @HuntressLabs 称，他们的入口是「一条长期休眠的 API 凭证，最初为一个已废弃的第三方集成原型而创建」。[2] 一把为一个早已不存在的项目、为一个无人记得的用途而制造的密钥，仍然有效。进入 Klue 之后，他们投放了恶意代码，收割 Klue 为其客户持有的 OAuth 令牌：那些长期授权，使 Klue 能够代表这些公司读取 @salesforce、Slack、HubSpot 等系统。其中一枚令牌属于 LastPass。攻击者借此读取了 LastPass 的 Salesforce CRM：姓名、邮箱、电话号码、地址、支持工单内容。然后是勒索信：付钱，否则就挂到泄露站点上。

在爆炸半径内的不止 LastPass。Huntress、Recorded Future、Tanium、Jamf、BeyondTrust。大多是安全公司。靠这个吃饭的那种。

该肯定的还是要肯定。LastPass 的密码学兑现了它的承诺。保险库不是这个故事。这个故事是关于一类几乎没人当作机密的机密：某个您批准过一次、之后再没看过一眼的 SaaS 集成里，那枚长期有效的令牌。它不会过期，也不知道自己已被窃取。它授予的权限远超创建它的初衷，而且会一直静默地授予下去，直到有人想起来去把它关掉。通常没有人会想起来。

这就是变化所在。威胁模型从「他们能否破解保险库」变成了「有多少把被遗忘的钥匙，还插在您不再看守的门上」。一个废弃原型留下的一条失效凭证，就足以触及一连串公司的客户数据。数学从来不是薄弱环节。散乱的暴露面才是。

这正是凭证应当拒绝发生的那类失败。Clavitor 签发的机密短时效、限定范围。它只为一次操作做代理，自行过期，并与使用它的机器绑定、可追溯归属。这样的令牌不可能变成这次造成损害的那种东西：一个被遗忘的授权，在有人想起它存在很久之后才被收割，从陌生人的基础设施上重放，且没有任何东西将其指向某个行为体。它在被发现之前就已消失，而且从未越出那一次任务的边界。

有一个界限值得直说。Clavitor 管辖的是它所持有的凭证，而不是您交给某个厂商平台的长期 OAuth 授权。那枚令牌存在于他们的系统中，受他们的控制，没有哪个密码库能伸手替您让它过期。改变的是 Clavitor 职责范围内的所有事情。它拒绝成为一个可以静默存放永不过期机密的地方。Klue 因其缺失而失守的那套纪律（短时效、紧范围、真实的归属追溯），在这里是默认行为，而不是某个指望有人记得去开启的设置。

留下的是一个令人不安的问题。您一年前接入、之后再没想过的那些厂商中，有多少枚仍然有效的令牌？

我们整理了在把任何东西托付给一枚凭证之前，它应当具备的那几项属性。[3]

Clavitor (@clavitorai) 是为 AI 智能体而建、也是防着 AI 智能体的凭证保险库。clavitor.ai

来源

[1] BleepingComputer, "LastPass confirms data breach in Klue supply chain attack" — @BleepinComputer

[2] Huntress incident findings, reported via Help Net Security, "Klue breach lead to Salesforce data theft, Huntress affected" — @HuntressLabs, @helpnetsecurity

[3] The Ten Rules of Credential Management (native X Article) — @clavitorai