红十字51万人数据泄露后，一个产品经理花3周造了套零成本安全系统

2022年，红十字国际委员会的一次数据泄露，让51.5万名难民、失踪人员、战后寻亲家庭的信息暴露在公网。那个专门帮助他们团聚的项目，被迫关闭。

三年后，一位曾在推特上看到这条消息的产品经理，在凌晨删掉了自己第三个GitHub仓库。前两次他都觉得"肯定有更专业的人在做"，第三次他决定：没人做，那就我来。

被忽视的"高价值靶子"

非政府组织和人权机构是互联网上被攻击最频繁的群体之一。不是因为他们疏忽，恰恰是因为他们手里握着太敏感的东西：难民身份档案、战争罪行证据、异见者保护名单。

讽刺的是，这些机构的IT预算往往接近于零。请不起安全团队，雇不起Kubernetes（容器编排系统）专家，连基础的安全审计都做不起。Red Cross那次事件后，整个行业都在问：为什么没有人给这些人做一套能用的防护？

Jose Lorenzana当时正在滚动推特时间线。他看到那条关于Red Cross的推文，停下来，关上手机，脑子里只有一个问题：为什么不存在能阻止这种事的东西？

他开始调研。发现了Kyverno（策略引擎）、Falco（运行时安全监控）、ArgoCD（持续交付工具）、Grafana（可视化监控平台）。全是开源的，全免费的，功能也足够强。但问题是：没有一个NGO员工能自己把这些东西拼起来跑通。

「肯定有人正在做整合包」，他这么想。几周过去，什么都没出现。

三行命令换四层防御

2月中旬，Lorenzana创建了第一个GitHub仓库，当天删除。第二个，删除。第三个终于留下——Fortress in a Box（盒中堡垒）。

整个安装过程被压缩到三行命令：

git clone → chmod +x install.sh → ./install.sh

跑完之后终端弹出一行ASCII艺术字：「FORTRESS IS ACTIVE :D」。没有配置文件要改，没有证书要申请，没有网络策略要手写。

这套系统叠了四层防御，每层都针对容器化环境最致命的攻击面。

第一层是镜像扫描。每次构建时，Trivy（漏洞扫描器）会自动检查容器镜像里的已知CVE（通用漏洞披露）。发现高危漏洞，流水线直接中断，有问题的代码不可能部署到集群里。

第二层是准入控制。Kyverno在Kubernetes API层面强制执行六条安全策略：禁止以root身份运行、强制只读根文件系统、必须声明资源限制、镜像必须来自可信仓库、禁止特权容器、禁止挂载敏感主机路径。不合规的部署请求在启动前就被拦截，不需要人工审批。

第三层是运行时监控。Falco在内核层面捕捉异常行为：容器里突然出现了shell进程、有进程尝试读取/etc/shadow、网络连接指向了意外的外部IP。这些事件实时推送到Grafana仪表盘，同时触发告警。

第四层是GitOps（基于Git的持续运维）。ArgoCD接管所有部署，集群状态与Git仓库强制同步。有人手动改了生产环境？几分钟后自动回滚。攻击者即使拿到权限，也无法持久化修改。

为什么偏偏是"盒子"

Lorenzana给项目起的名字很直白：Fortress in a Box。盒子里装的是堡垒，开箱即用。

这个命名暴露了他的产品思维。传统安全方案卖给企业客户时，卖的是"能力"——你需要先有一支能驾驭这些能力的团队。但NGO的场景完全不同，他们要的是"结果"，是数据不丢、服务不停、不被勒索软件锁死。

他把所有决策都预置在代码里。镜像扫描只报CRITICAL和HIGH级别漏洞，避免信息过载；Kyverno策略排除了falco、monitoring等系统命名空间，防止自己锁死自己；整个网络策略默认拒绝跨命名空间流量，但给ArgoCD留了必要的通信端口。

这些细节来自他对"零 expertise 用户"的假设：他们不会调优，不会排错，甚至不会看日志。所以系统必须"偏执"——宁可误拦，不可漏放；宁可默认严格，也不要让用户自己决定什么是"足够安全"。

GitHub仓库的README里有一句话：「Built specifically for NGOs, journalists, and human rights organizations」。不是"也支持"，是专门为这些人建的。

开源安全工具的"最后一公里"

Fortress in a Box的技术选型没有追逐新潮。Kyverno 2019年开源，Falco 2016年，ArgoCD 2018年，全是经过生产环境验证的工具。Lorenzana做的不是技术创新，是集成创新——把已经存在的积木，搭成一座不用说明书就能住的房子。

这种"最后一公里"工程在开源世界极其稀缺。大厂的安全团队有能力自己整合这些工具，但他们不会公开分享；安全厂商的"开源版"往往是商业产品的阉割诱饵，部署复杂度故意保留。

真正需要保护的中小机构，卡在中间：商业方案买不起，开源方案用不起。

Lorenzana的解决方案是极端的 opinionated（固执己见）。没有插件系统，没有配置开关，没有"高级模式"。你想要自定义？fork仓库自己改。默认安装就是唯一支持的安装方式。

这种设计在工程社区可能引发争议，但对于目标用户是解脱。一个在人权组织做IT的志愿者告诉我，他们之前尝试过自己搭Falco，花了两个周末读文档，最后因为一条内核模块编译错误放弃。「如果当时有这个，我们半小时就能跑起来」。

从"应该有人做"到"我做"

项目发布后的反馈超出了Lorenzana的预期。不是流量暴涨那种——GitHub star数增长平稳——而是邮件。来自墨西哥的人权律师，来自东欧的调查记者，来自非洲的医疗NGO技术负责人。他们的问题都很具体：能不能支持ARM架构？旧版本的Kubernetes行不行？没有公网IP怎么收告警？

他在Issues区逐条回复，把常见需求记进TODO列表。但核心原则没变：保持简单，拒绝膨胀。有人提议加入WAF（Web应用防火墙），他拒绝了，因为那会引入新的配置维度；有人想要多集群管理，他说那是v2.0才考虑的事——如果真的有v2.0的话。

这种克制与开源社区常见的"功能竞赛"形成对比。很多项目为了吸引贡献者，不断堆叠特性，最终变成需要专职维护的庞然大物。Lorenzana似乎有意在抵抗这种趋势。他的目标不是做一个"伟大的开源项目"，是解决一个具体的人遇到的问题。

那个问题始于2022年Red Cross的泄露事件，终于2025年一个可以复制的安全基线。

当"足够好"成为最优解

安全行业有个默认假设：防护强度与复杂度正相关。Fortress in a Box挑战了这个假设。它的四层防御没有一项是顶尖水平——Trivy的漏洞库不如商业扫描器全，Kyverno策略不如OPA（开放策略代理）灵活，Falco规则集是社区版而非企业定制。但组合在一起，对大多数自动化攻击已经构成有效屏障。

更重要的是，它降低了"有防护"和"没防护"之间的门槛。对于预算为零的组织，从0到1的价值远大于从1到10。

Lorenzana在仓库的Contributing指南里写了一句很有意思的话：「如果你发现某个配置不够安全，请开Issue讨论；但如果你只是想加一个'可选'的开关，大概率会被拒绝。」

这种产品哲学听起来有些霸道，但放在特定语境下完全合理。他的用户不是安全工程师，是被迫兼任IT的程序员、是志愿者、是资源极度受限的公益机构。他们不需要选择，需要默认正确。

项目发布三个月后，有人提交了第一个生产环境部署报告：一个记录战争罪行的档案库，运行在非洲某国的边缘节点上。之前他们用的是裸机Docker，没有任何隔离。现在有了命名空间隔离、网络策略、运行时监控——全部来自那三行命令。

如果2022年Red Cross用的是类似方案，那51.5万人的数据泄露是否可以避免？没有人能保证。但至少现在，面对同样困境的机构有了一个不需要安全专家也能启用的选项。

而那个在凌晨删掉两个GitHub仓库的产品经理，现在收到的问题变成了：这套系统能不能扩展到小型新闻room？能不能打包成离线的air-gapped版本？下一步，他该优先回应哪个？