移动应用程序安全：小型团队的架构

小团队会经历残酷的数学。同样的两个、三个、五个人需要处理产品、代码、基础设施、支持以及安全性。没有专门的专家。日程安排上没有任何懈怠。有些好人利用剩下的时间尽力而为。

在这种情况下，通常的安全建议听起来几乎是令人反感的。聘请安全团队，定期进行笔测试，建立治理计划。太好了，和什么人在一起？有什么预算？

本文从一个不同的前提开始。你们很少，而且会持续一段时间，而且您仍然需要保护您的应用程序。正确的问题不是“如何拥有一支安全团队”，而是“如何使安全成为这个小团队工作方式的自然组成部分”。

小团队的具体问题

小团队不存在初创公司寻求验证的问题，也不存在公司寻求规模的问题。存在超载问题。

每个人都积累角色。知识是集中的，有时集中在一个人的头脑中。当有人去度假或去公司时，漏洞就会出现。而安全性，因为它在工作时是看不见的，所以当日子变得艰难时，它是第一个被牺牲的东西。

因此，小团队的安全策略不能依赖于英雄主义或持续的纪律。它必须取决于结构。安全的路径也必须是最简单的路径。

这是我的立场。在小团队中，安全问题不可能靠更多的人来解决。它是通过标准决策和嵌入在过程中的选择来解决的，这些选择是通过惯性而不是努力来保护的。

当安全依赖于某人记得做某事时，它就会失败。人们会忘记，尤其是过度劳累的人。但是，当保险成为系统的默认行为时，即使在糟糕的日子里也会发生保护。

这改变了“我们如何使其更安全？”的问题。到“我们如何使不安全的事情难以意外发生？”。这是一种心态的改变，完全符合少数人的现实。

对于小团队来说，最好的安全措施是现成的。使用默认执行正确操作的框架和库。将云服务安全地配置为初始状态，而不是事后的想法。

当项目模板已经强制使用 HTTPS、已经验证输入并且已经将秘密保留在代码之外时，小团队就可以在不浪费注意力的情况下获得安全性。在组装图案时，集中精力一次，此后每次都会得到回报。

您无法每周手动审核依赖项。所以不要这样做。当库存在已知漏洞时，让自动工具向您发出警告。在管道中进行安全检查，以便有明显问题的代码不会在没有警告的情况下溜走。

自动化是小团队的力量倍增器。每项自动检查都是一项您无需记住再次执行的任务。这使得少数人可以腾出时间来处理需要人类判断的问题。

事情越少，出错的可能性就越小。对于小团队来说，简单就是安全。

收集更少的数据。使用更少的集成。保持更少的服务运行。每个附加组件都需要配置、监控和修复一件事情。精益系统不仅运行成本更低，维护起来的危险也更小。

小团队的致命弱点是一个人头脑中的知识。当那个人离开时，安全也会随之而去。

不需要大量的文档。要点就足够了：秘密在哪里，[身份验证0]如何工作，系统的敏感点是什么。一份简短的、更新的文档比一本无人阅读的庞大手册更有价值。连续性是一种安全形式，小团队常常会忽视它，直到为时已晚。

想象一下，一个由三人组成的团队正在维护诊所的日程安排应用程序。它们处理健康数据，这些数据本质上是敏感的，并受到 [LGPD1] 的保护。团队里没有一个有“保安”称号的人。

现实的方法不是制定安全计划。这是关于将保护纳入工作模式。该项目诞生于后端的秘密和设备上的安全存储。管道已经运行依赖性检查。通过有意识的决定，数据收集最少。有一份一页的文档告诉您这一切是如何运作的。

这些措施都不需要专家。它们都要求团队一次性决定这是标准。此后，安全性几乎自行运行。

最大的风险是错误地认为安全是大公司的问题。小型应用程序一直受到攻击，攻击者通常是不根据大小进行攻击的自动化攻击。少数并不会让你被忽视。

第二个风险是倦怠。试图通过野蛮的努力来获得安全，没有结构，会导致放弃。团队累了，就把它放在一边，保护也随着能量消失了。这就是为什么必须把赌注押在自动化和标准上，而不是意志力上。

三是知识的集中。当一个人只了解系统的安全性时，你就没有安全性，就会出现单一的人为故障点。传播基本理解至关重要。

对于小团队来说，最好的安全架构是一种日常工作不会造成负担的架构。这无需持续关注即可提供保护。它能度过假期、郊游和混乱的日子。

这是通过冷静地做出结构性决策而建立的，而不是在压力下进行英勇的警惕。明白这一点的小团队将其局限性转化为纪律：因为它不能做太多事情，但基本的事情却可以很好地自动完成。

安全不需要军队。您需要良好的标准和尊重这些标准的决定。

如果您所在的团队试图平衡交付和安全性，那么改变想法是值得的。我的博客上还有其他关于自动化、良好实践和 [LGPD2] 的文章，这些文章专门为那些少花钱多办事的人而设计。