在下方公众号后台回复【网络安全】，可获取给你准备的最新网安教程全家桶。
微服务带来了敏捷和韧性，但是其安全价值却常被忽视。
微服务技术革命在过去几年席卷了全球的企业IT市场，根据statista 2021年的调查，71%的企业报告称将采用该架构。但是，当我们讨论微服务时，更多关注的是微服务给企业IT带来的敏捷性和灵活性优势，对企业安全的影响却鲜有提及。
在单体应用程序时代，一个安全问题可能意味着要花费数百甚至数千个工时重构应用程序。除了修补安全漏洞，安全团队往往还需要审查和重新构建应用程序依赖关系，有时还需要对整个应用程序进行逆向工程。
微服务的出现颠覆了这种范式，DevOps可以隔离并解决安全漏洞，而不必担心破坏整个应用程序堆栈，企业可以大幅缩短安全补丁周期，同时整个DevOps团队和IT堆栈更具弹性和效率。
微服务为什么能够隔离风险？首先我们简单回顾一下微服务架构的定义：微服务架构是将单个的整体应用程序分割成更小的项目关联的独立的服务，可独立部署并通过API等轻量中介松散绑定在一起。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。
实际上，容器是用于交付微服务架构的技术。这些轻量级独立包将应用程序代码与轻量级操作系统、运行时、库和配置数据捆绑在一起。通过像Kubernetes这样的编排系统，各个容器可以相互交换输出，执行以前需要通过单体应用程序实现的总体任务。
由容器交付的微服务架构“先天”能够隔离许多安全风险。由于各个微服务仅通过协调它们的中介交换信息，因此对单个微服务的入侵或破坏很难影响到整个应用程序。
微服务自带的“风险隔离”在实践中意味着什么呢？以下是一个假想实验：
几年前产品制造商们发现，如果设备日期更改为1970年1月1日，会导致许多消费端设备将无法使用。假设企业环境中的日历应用程序也存在类似的漏洞，而且有黑帽攻击者在安全团队之前发现了这个漏洞，通过获取某位员工的凭证，成功将日历应用程序中的日期更改为1970年1月1日。
如果企业的DevOps团队使用单体应用程序，他们将必须执行以下操作：
首先，他们将不得不应对攻击引起的大面积系统故障，只有解决漏洞才能修复这些故障。
其次，假设DevOps团队发现漏洞位于日历应用程序中，将不得不检查该应用程序的整个源代码并手动查找问题所在。
最后，团队将不得不审查整个日历应用程序的源代码，以更改对与错误代码行相关的变量或语句的任何引用。
如果同一个DevOps团队使用了微服务架构，情况会是怎样？
首先，一旦黑帽攻击者更改了日期，DevSecOps就会注意到包含该漏洞的特定微服务出现故障。
其次，假设团队正在使用容器，他们的Kubernetes发行版将标记特定容器未发送有效的输出数据。
最后，团队将失陷容器的设置恢复到恶意日期更改之前是一件简单的事情。
一旦他们通过设置回滚完成了初始诊断和解决方法，团队就可以着手修复导致漏洞的潜在缺陷。在整个过程中，日历应用程序主体——以及依赖它的所有东西——都保持在线可用。
上面的“案例”表明，微服务能极大提升企业系统的安全弹性和主动安全能力。
因为在微服务架构中，只有存在缺陷或漏洞的组件需要更换或更新，而不是整个应用程序。系统故障或漏洞导致的停机时间会减少，因为团队可以识别并恢复受损的单个微服务。此外，微服务还能大大减少DevOps和安全团队缓解漏洞的工作量，因为他们只需要重新设计一个单独的微服务，这比重构一个完整的单体应用程序需要编写的代码量少很多。
通过隔离风险和漏洞的“防护栏”，微服务能提高团队的主动性。团队能够不断改进单个微服务，而无需考虑应用程序的其余部分。
这意味着DevSecOps专业人员可以专注于注意漏洞或推出安全更新。无需管理或后勤工作来阻止安全更新破坏应用程序中的另一个微服务。在修复零日漏洞或保护您的应用程序免受新出现的威胁时，这种灵活性和自由度是无价的。
微服务使DevSecOps团队能比以往更快、更有效地响应安全威胁。在主动安全方面，微服务可以大幅提升团队强化系统的速度。
总而言之，微服务改变企业IT安全的根本原因是：能够极大提高开发人员、运维人员和安全团队的工作效率，并且提供前所未有的灵活性。
微服务是企业IT架构的一次重大变革，同时也对企业网络安全演进产生重大影响。微服务架构采用独立部署、松散绑定的服务，通过容器隔离安全风险。在缓解安全漏洞时，微服务架构使DevOps团队能更快定位并解决问题，减少停机时间。此外，微服务让团队更加主动，可以专注于处理漏洞或推出安全更新，而无需担心更新会破坏或影响应用程序的其他部分。总的来说，微服务架构让开发人员、运维人员和安全团队的工作速度更快，并且具有前所未有的主动性、灵活性和弹性。
- END -
近期课程上新：
如有侵权请联系:admin#unsafe.sh