有几种现代应用架构和开发方法,基本上都采用“使其更小,从而更高效”的形式。
微服务和函数即服务 (FaaS) 都依赖于高度集中的代码的概念。 现在,虽然大多数组织并没有将应用分解为数百个微服务或数千个功能,但他们倾向于这种设计。 这通常是因为它促进了敏捷开发,因为相对较小的团队可以比大型单片应用更快地设计、开发和完善服务。 毕竟,编写和测试 1000 行代码比运行 100,000 行代码的大型应用要容易得多。
但是微服务和 FaaS 还有另一个有趣的好处,但并没有得到应有的重视:安全性。
互联网上有很多讨论 - 我也读过其中的很多 - 试图确定“行业平均”缺陷和漏洞密度。 您会发现各种各样的估计,其中一些基于对开源源代码的实际扫描,另一些则基于自我报告的数字。 例如,美国国家航空航天局 (NASA) 自豪地宣称其极低的缺陷密度是航天飞机计划成功的原因之一。 还有一些基于 WhiteHat 等安全公司客观收集的数据的报告,但其数字主要关注每个应用的漏洞,而不一定关注每行代码的漏洞。
除了同意存在缺陷和漏洞密度之外,并没有关于缺陷和漏洞密度的真正共识。
然而,按理说,编写的代码行越少,可能引入的缺陷和漏洞就越少。 同样重要的是,查找漏洞或缺陷所需要搜索的代码行越少,您找到它并修复它的速度就越快。
事实确实如此的原因之一是范围。 如果我的微服务或功能专注于编码业务逻辑的一个方面,则需要更少的逻辑和更少的库来实现。 范围越小,意味着在实现额外逻辑所需的库(第三方或其他)中引入逻辑错误或漏洞的可能性就越小。 每次您必须包含另一个组件或调用另一个服务时,就会引入缺陷和漏洞的机会。
更少的功能或微服务接口也有助于提高代码的安全性。 每个接口(像 API 调用这样的入口点)都可能引入漏洞,因为您正在处理用户输入。 众所周知,用户输入应始终被视为可疑和潜在恶意的。
如果微服务降低了出现漏洞和缺陷的可能性,那么进一步缩小功能范围应该会进一步降低这种可能性。
现在,这并不是说微服务和 FaaS 本质上比三层和单片系统更安全。 草率的代码就是草率的代码,无论它有多少行。 但事实上,这两种架构都适合于开发和交付实践,从而可以产生更安全的代码。
在评估或实施微服务和/或 FaaS 时牢记安全优势实际上可以帮助防止代码膨胀以及防止引入漏洞。