利用 NGINX 现代application安全安全地释放 DevOps

到目前为止，几乎所有从事现代软件开发的人都熟悉“DevSecOps”的概念，它有望从根本上加强应用的安全性并减轻DevOps 和安全团队之间的摩擦。

在 DevSecOps 模型下，安全性被左移并直接融入到 DevOps 开发和部署过程中。 具体来说，安全性嵌入在持续集成/持续部署（CI/CD）管道的每个阶段，以帮助更早地识别安全漏洞。 与传统的安全模型不同，DevSecOps 将安全置于开发的核心，帮助更接近问题的起源点来识别问题，减少昂贵（且耗时）的修订并防止漏洞影响生产。

然而尽管推动了 DevSecOps，安全团队似乎仍然落后于 DevOps 的步伐。 根据 snyk 的DevSecOps Insights 2020报告，48% 的开发人员仍然认为安全性是他们快速交付软件能力的主要制约因素。

为什么application安全仍然太慢？

虽然大多数企业认识到他们的安全态势需要达到什么水平，但意图和现实却是两码事。 根据 Contrast Security 的《2020 年DevSecOps 状况报告》 ，超过 99% 的组织被迫承认其生产中的平均应用至少存在 4 个漏洞，而近 80% 的组织报告称，正在开发的应用中存在超过 20 个漏洞。 因此，尽管 GitLab 2021 年全球 DevSecOps 调查中接受调查的 70% 的安全团队表示他们已将安全性左移并且正在与开发人员进行比以往更紧密的合作，但显然仍然存在重大的安全漏洞。

通过与 NGINX 客户的对话，我们发现了三大挑战持续减缓或阻碍安全团队采用 DevOps 实践：

1. 不断变化的分布式周界
   与 20 年前不同，安全团队很少只负责保卫一个易于保护的周边区域。 相反，他们必须保护由 DevOps 团队开发和部署的应用程序，这些团队可以自由选择帮助他们最快迭代的环境、平台和工具。 DevOps 实践对于创新非常有益，但对于必须保护通过 API 相互通信的一系列服务、端点和设备的安全专业人员来说却是个坏消息。 事实上，只有一半的GitLab 调查受访者表示，他们有使用现代开发策略（包括微服务和容器）创建的应用程序的监控和保护流程。

2. 无法自动化并将安全策略嵌入到 CI/CD 管道中
   不同团队之间的转型并不是以相同的速度发生的，并且安全团队可用的大多数传统工具并不是为左移环境而设计的。 结果，安全团队被迫调整和集成那些不太适合自动化和现代基础设施的工具到管道中。 更糟糕的是，这些工具缺乏自助服务功能，因此开发人员和 DevOps 工程师必须等到安全部门完成对策略和流程的手动审核才能继续前进。

3. 难以获得集中的可视性和安全洞察
   大多数企业应用程序不仅是分布式的，而且所有权区域也是分布式的，每个所有权区域都使用不同的工具。 这使得获取对组织内部安全态势的综合可见性变得非常痛苦。 安全团队经常浪费时间尝试整合和关联来自不同地方的数据，而不是深入挖掘问题的根本原因。

当然，大多数企业并不是只为少数几个应用程序克服这些障碍——他们要处理分布在多个团队的数百种产品和服务，运行自己的技术堆栈、工具链和流程，所有这些都需要审核和检查，以确保漏洞不会给攻击留下空隙。

企业团队转向平台运营

那么，您可以做些什么来帮助您的应用安全团队变得更加敏捷，同时还使开发人员能够继续快速而安全地行动？

残酷的事实是，如果你找不到应对上述挑战的方法，你就无法改进你的实践和流程。 更快地迭代可能感觉像是每个人都需要的胜利，但继续扩展 DevOps 以充分发挥其潜力的唯一方法是使整个软件开发生命周期中的安全性尽可能顺畅和适应性强。

我们看到越来越多的企业采用一种效仿 Gartner 的方法，我们称之为“平台运营” 。 其核心概念是通过专门构建以满足公司内部团队需求的平台提供 DevOps 功能。 使用内部平台不仅可以减少在重复任务上浪费时间的可能性，还可以帮助多个产品团队持续有效地协作而不会减慢速度。

在平台运营模型下，安全团队向开发团队提供自助服务、可消费的政策。 此外，安全工具已完全集成到应用交付过程中。 这样，开发人员可以更快地部署，同时仍然遵循知识渊博的安全专家设定的最佳实践、治理和访问要求。

对于应用安全团队来说，最大的胜利在于，平台操作创建了一个环境，在这个环境中，开发人员不再将安全性视为减慢他们速度的障碍，而是将其作为他们已经使用的流程和工具的一个组成部分。 这促使应用程序交付团队采用能够确保整个企业更好安全的模式。

NGINX 如何提供帮助

在 NGINX，我们认识到提供工具的重要性，例如 Web应用防火墙 (WAF)，它可以轻松左移以在开发过程的任何地方提供安全性并与 CI/CD 管道完全集成。 拥有不会占用 CPU 或降低性能的轻量级解决方案也至关重要。

我们还发现，当安全只是一道护栏而不是一扇大门时，开发和 DevOps 团队会更加高兴。 当安全性在共享的自助服务平台上提供强大、一致的控制和策略时，开发和安全团队可以更轻松地以最少的交互和中断来协调指导方针。

NGINXapplication平台实现这一功能的具体方式如下：

• NGINX App Protect WAF是一种轻量级、现代的 WAF，您可以在构建和管理应用程序的任何地方部署它。 App Protect WAF 基于 F5 市场领先的 WAF 技术构建，无论架构或部署环境如何（无论是云、混合、基于微服务的容器化还是本地），均可防御OWASP Top 10和其他高级威胁。 App Protect WAF 作为NGINX Plus的动态模块部署，使您能够自动化安全配置和策略，以便可以在 CI/CD 管道中直接配置它们。

• NGINX App Protect DoS提供自动、自适应保护，以识别和防止拒绝服务 (DoS)攻击。 在 F5 安全专家的支持下，App Protect DoS 使用自适应机器学习和内置异常检测来保护您的应用和微服务免受应用层攻击。 无论您需要阻止有针对性的攻击，还是仅仅防止无意的错误配置破坏应用程序性能，App Protect DoS 都能提供零接触保护，可无缝集成到现代应用架构、开发工具和框架中。

• 控制器应用程序交付application的 NGINX 控制器应用程序安全 <.htmla> 插件使您能够提高开发人员的工作效率，而不会影响操作和安全合规性。 控制器应用安全提供值得信赖的应用保护和集中的应用层威胁可见性，可以在多云环境中运行的基于 HTTP 的应用和 API 之间实现标准化。 它还使安全团队能够提供预先批准的指南，开发人员和 DevOps 团队可以以自助服务的方式使用这些指南轻松地为他们的应用程序添加应用程序保护。

• NGINX 控制器 API 管理模块的高级安全性为现代应用提供了分布式 API 安全性：

  • NGINX App Protect WAF现在可以与 API 网关共置，为分布式环境提供 API 流量管理和安全性。 在 NGINX 解耦架构的支持下，数据平面（由 API 网关和现在的 NGINX App Protect WAF 组成）在控制平面上没有运行时依赖性，NGINX 为托管在本地、公共、私有或混合云的 API 提供一流的高性能和安全性。
  • API 管理模块的NGINX 控制器应用安全插件将强大的安全性与部署在任何地方的 NGINX API 网关（裸机、虚拟机、容器和云环境）无缝集成。 开箱即用，该插件可防御OWASP API 安全十大漏洞以及 SQL 注入和远程命令执行 (RCE) 等漏洞。 它验证允许的文件类型和响应状态代码，并检查格式错误的 JSON、XML 和 cookie。 该插件还可以检测用于掩盖攻击的逃避技术并确保符合 HTTP RFC。

准备好让安全变得简单且无痛苦吗？

开始免费试用NGINX Plus、NGINX App Protect和NGINX Controller 30 天，查看我们在云端的产品（ AWS 、 Google Cloud Platform 、 Microsoft Azure ），并报名参加由讲师指导的NGINX App Protect 简介课程。