在计算机安全领域,“边界”是概念意义上的一条线,线的内部是应用及其他基础设施组件的“信任区”。
在采用“城堡护城河”方法的传统基础设施环境中,边界将内网(内部网络)与外网或互联网分隔开来,并且假定内网是安全的,威胁仅来自外部。安全态势是静态的,通过数据包检查和访问控制措施在内网周围建立防御。
然而,久而久之,外部攻击者找到了绕开安全控制措施和破坏内网组件的方法,或者制造外部攻击,使请求看起来像来自默认安全的边界内部。这促使人们转向了零信任安全模型,在建立信任之前所有实体(内部和外部)都会被持续评估。人们不再认为内网是安全的。
与此同时,数字化转型和微服务等新型应用架构也带来了新的安全挑战。许多企业应用都托管在公有云中,或者分布在云和本地拓扑中,这意味着保护应用的安全基础设施不再完全由本地管理员控制。因此,许多组织现在都围绕单个应用(或者在结构上具有直接依赖关系的一小组应用)建立边界。在下图中,绿色虚线表示边界。
无论采用哪种架构模型,边界上都有一个“门卫”来检查入站流量并实施保护内部应用的安全策略。我们将这个“门卫”称为“边缘”。在下图所示的三种常见部署模式中,红框(保护 PROTECT)表示“边缘”。
此概念同样适用于 Kubernetes 框架等容器化架构。Ingress controller(Ingress 控制器)充当整个 Kubernetes 集群的边缘,管理来自外部客户端的访问,并将请求路由到集群中的 Kubernetes 服务。但安全策略也可在集群内按 Pod 和 Service 进行更细粒度的实施(如下图所示):
- 在按 Pod 提供保护(如左图所示)的模式中,Pod 定义了一个或多个容器中应用或应用组件的边界。
- 在按 Service 提供保护(如右图所示)的模式中,Service 通过一个或多个 Pod 公开应用部署的实例,并沿 Service 背后的 Pod 建立边界。
使用 NGINX App Protect 保护边界安全
NGINX App Protect 是基于 F5 市场领先的 Web 应用防火墙(WAF)技术构建的现代应用安全解决方案。无论采用哪种部署环境和应用架构(本地、云、混合、微服务化或容器化),NGINX App Protect 都能确保边界安全,为您的应用提供敏捷保护。更多信息,请参阅《NGINX App Protect 简介:面向 NGINX Plus 的 F5 高级应用安全解决方案》。
使用 NGINX App Protect 实施边缘安全的一大优势是能够在边界之外执行安全措施。本质上,流量检查和访问控制都发生在边缘,可防止威胁越过边界。作为访问应用前的最后一站,边缘是最能清楚查看应用威胁的类型和数量的地方。
以下代码配置 NGINX App Protect 为边界内单独访问的三个应用(app1、app2 和 app3)提供保护:
load_module modules/ngx_http_app_protect_module.so;
error_log /var/log/nginx/error.log debug;
http {
# 在“http”上下文中启用 NGINX App Protect
app_protect_enable on;
# 启用远程日志记录
app_protect_security_log_enable on;
# 默认 JSON 安全策略
app_protect_policy_file "/etc/nginx/NginxDefaultPolicy.json";
# 设置远程日志记录选项(在引用的文件中)和日志服务器 IP 地址/端口
app_protect_security_log "/etc/nginx/log-default.json" syslog:server=127.0.0.1:515;
server {
listen 80;
server_name app1.com;
app_protect_policy_file "/etc/nginx/NginxApp1Policy.json"; # 应用 1 的 JSON 策略
location / {
proxy_pass http://www.app1.com:8080$request_uri;
}
}
server {
listen 80;
server_name app2.com;
app_protect_policy_file "/etc/nginx/NginxApp2Policy.json"; # 应用 2 的 JSON 策略
location / {
proxy_pass http://www.app2.com:8080$request_uri;
}
}
server {
listen 80;
server_name app3.com;
app_protect_policy_file "/etc/nginx/NginxApp3Policy.json"; # 应用 3 的 JSON 策略
location / {
proxy_pass http://www.app3.com:8080$request_uri;
}
}
}
以下代码配置 NGINX App Protect 为边界内以单个应用的形式嵌入和呈现的 app1、app2 和 app3 提供保护:
load_module modules/ngx_http_app_protect_module.so;
error_log /var/log/nginx/error.log debug;
http {
server {
listen 80;
server_name app.com;
# 在“http”上下文中启用 NGINX App Protect
app_protect_enable on;
# 启用远程日志记录
app_protect_security_log_enable on;
# 默认 JSON 安全策略
app_protect_policy_file "/etc/nginx/NginxDefaultPolicy.json";
# 设置远程日志记录选项(在引用的文件中)和日志服务器 IP 地址/端口
app_protect_security_log "/etc/nginx/log-default.json"
syslog:server=10.1.20.6:5144;
location / {
# 主 JSON 策略文件
app_protect_policy_file "/etc/nginx/policy/policy_main.json";
proxy_pass http://app.com$request_uri;
}
location /app1 {
# 应用 1 的 JSON 策略文件
app_protect_policy_file "/etc/nginx/policy/policy_app1.json";
proxy_pass http://app.com$request_uri;
}
location /app2 {
# 应用 2 的 JSON 策略文件
app_protect_policy_file "/etc/nginx/policy/policy_app2.json";
proxy_pass http://app.com$request_uri;
}
location /app3 {
# 应用 3 的 JSON 策略文件
app_protect_policy_file "/etc/nginx/policy/policy_app3.json";
proxy_pass http://app.com$request_uri;
}
}
}
这两种配置均针对每个应用提供了单独的 app_protect_policy_file
指令,并为每个应用分配了一个不同的安全策略,以满足其不同的安全要求。
如欲了解更多 NGINX App Protect 配置,请参阅文档。
使用 NGINX App Protect 实现 CI/CD 流水线中的边界安全
NGINX App Protect 解决了现代应用面临的可扩展性和自动化安全挑战。通过将 NGINX App Protect 直接插入 CI/CD 流水线中的多个集成点,您可以在更接近代码的地方保护应用、Pod 和 Service,从而弥合开发、运营和安全之间的鸿沟。
通过直接将安全防护集成到应用开发周期中,您可以自动执行安全测试,以发现应用和应用组件存在的安全风险。您还可以定义安全策略,如果不满足安全合规要求,则可撤回已发布的应用。通过在新版应用发布之前将 NGINX App Protect 集成于其中,您可以始终确保交付安全的应用。
准备好使用 NGINX App Protect 保护边界安全了吗?
立即下载 NGINX App Protect 和 NGINX Plus 的 30 天免费试用版,或与我们联系以讨论您的用例。您还可以阅读产品文档,了解有关全套 F5 Web 应用和 API 保护解决方案的更多信息。