移动应用程序的安全性：适合需要扩展的架构

当应用程序增长时，安全性会发生一些奇怪的事情。对于一万名用户来说效果良好的决策开始在一千万用户身上失效。一个细节变成了系统性风险。最糟糕的是：这一时刻很少被宣布。

攀登不仅仅是支撑更多的负载。这是关于承受更多关注。用户群越大，目标的价值就越高，攻击者就越老练，错误的代价就越高。一个在不重新考虑安全性的情况下进行扩展的应用程序只是以与成功率成倍相同的速度增加其攻击面。

本文适用于那些已经通过产品验证阶段、现在需要确保安全架构能够应对增长压力的用户。

秤到达后会发生什么变化

在小范围内，许多安全问题因其无关性而被隐藏。没有人会花精力去攻击用户较少的应用程序。这是虚假的安慰。

当基数增长时，三件事会同时发生变化。您保管的敏感数据量不断增加，泄露的影响也随之增加。基础设施的复杂性不断增加，服务之间的接缝处也出现了差距。可见性也会增加，吸引以前甚至不知道您存在的攻击者。

实际结果是安全性不再是一个清单，而是成为架构的一个属性。您无法通过粘贴补丁来扩展安全性。

这是本文的中心位置。从规模上看，移动应用程序的安全性并不在于应用程序本身。它存在于支持它的架构中。

原因很简单。用户设备上安装的应用程序超出了他们的控制范围。它可以被反编译、检查、修改。实际上，其中包含的任何秘密都是公开的。任何仅在客户端上完成的验证都可以被绕过。

真正的防线在于服务器、API 以及设备和后端之间建立信任模型的方式。了解此设计的团队可以安全地扩展。不理解的团队通常会在第一次严重事件发生后发现困难。

从规模上看，该应用程序只是访问 API 的多种方式之一。攻击者绕过接口，直接到达源头。因此，每个端点都需要被视为公共端点。

这意味着强大的身份验证、对每个请求的验证授权以及对每个输入的严格验证。它还意味着经过良好校准的速率限制，以便单个参与者无法滥用系统或使其瘫痪。随着规模的扩大，API 网关成为控制中心，并且在设计时需要牢记这一职责。

适用于数千名用户的身份验证可能会成为数百万人的瓶颈。设计不当的会话会消耗资源，使撤销变得困难并造成漏洞。

[OAuth1 2.0 和带有刷新令牌的短期访问令牌等标准有助于平衡安全性和性能。空头代币如果被泄露，会限制暴露窗口。当您拥有大型数据库时，快速撤销访问的能力至关重要，单个受感染的设备无法成为永久端口。

传输中的数据必须使用 TLS，无一例外。但从规模来看，这是最低限度。静态敏感数据需要加密，密钥需要认真管理，最好是在专用密钥管理服务中，而不是分布在整个应用程序中。

在设备上，敏感数据必须使用平台提供的安全存储。永远不会出现在公共文件中，也不会出现在日志中。从规模上看，任何监督都会在数百万台设备上复制。

一个能够很好扩展的架构也是一个失败的架构。当某些东西受到损害时，需要控制损害。

这意味着责任分离、每项服务的最低权限和分段，以防止一个组件受到损害而无法访问所有内容。从一开始就考虑遏制是孤立事件与灾难的区别。

想象一下，一个市政公共服务应用程序最初只是为一个城市提供服务，但突然被数十个城市采用。一夜之间，它存储了数十万公民的数据：文件、收据、健康信息。

在初始阶段，也许[身份验证3]会很简单，并且验证将部分存在于应用程序中。这没有引起注意。规模扩大后，它就变成了一颗定时炸弹。了解 API 结构的攻击者可以尝试批量访问公民数据。

要扩展的架构需要重新考虑一切：集中且可审计的身份验证、按数据类型进行精细授权、一致的加密、检测异常访问模式的监控以及明确遵守 [LGPD4?。这不是奢侈品。这是负责任地增长的代价。

最大的风险不是技术性的。这是文化和组织的。

面临增长压力的团队往往将安全视为摩擦。 “我们稍后再解决”成为口头禅。问题在于，大规模安全的“后续”成本要高得多，因为现在你必须修补一个活生生的系统，数百万用户和真实数据都面临风险。

另一个风险是现代基础设施带来的虚假信任。默认情况下，使用云、容器和托管服务并不保证任何内容的安全。配置错误是事故的主要原因之一，并且它会随着其他因素的增加而扩大。

还有[可观察性5]的挑战。从规模上看，您无法保护看不到的东西。如果没有监控、日志和检测功能，攻击可能会持续数月而不被注意到。

增长是几乎所有产品的目标。但增长意味着对不断增加的数据量和他人的信任承担责任。

规模化安全架构并不是要添加更多工具。这是关于尽早做出决定，以便在数字太大而不能犯错误时保持正确。那些考虑到规模的设计并没有夸大其词，他们正在避免随后痛苦的重写。

该应用程序是可见的提示。真正的安全性在于没有人看到但每个人都依赖的架构。

如果您的组织正在经历这种增长转型，并且安全性正在追逐产品，那么值得停下来谈谈。我还有其他有关架构、API 和大规模安全性的博客文章，可以帮助构建此讨论。