编码员征服安全基础设施即代码系列。传输层保护不充分

如果你是一名开发人员，想了解更多关于在你的组织中开始部署安全的基础设施即代码（IaC）的步骤，那么你就来对地方了。这是我们IaC系列的下一章，旨在提高你的IaC安全最佳实践水平。

在我们开始之前，你在上一期的挑战中表现得如何？如果你已经掌握了不安全的加密技术，在我们深入讨论细节之前，让我们看看你在传输层保护不足的情况下是如何进行的。

想了解更多并取得满分吗？请继续阅读。

在上一篇文章中，我们谈到了拥有安全加密技术以保护应用程序和程序所存储的任何重要或个人数据的重要性。如果你有强大的加密技术，它就可以作为一个完美的最后一道防线。即使攻击者能够窃取这些数据，如果它是强加密的，那么锁定在这些文件中的信息仍然受到保护。

然而，保护静止的数据只是完整的数据防御的一部分。每当有效的用户需要访问受保护的数据时，必须将其发送给他们。有时，应用程序也会与其他程序共享数据，作为整个工作负载的一部分。除非传输层受到保护，否则会使其容易受到外部窥探和未经授权的内部查看。因此，传输层保护不足会导致严重的问题。

这是一个常见的问题。OWASP安全组织甚至维护了一个关于传输层保护不足的完整页面。

为什么传输层保护不足是危险的？

如果你没有充分保护你的传输层，那么熟练的黑客就很容易使用中间人攻击等技术截获你的用户和你的应用程序之间流动的信息。这种窥探最危险的方面可能是，它几乎完全看不到任何内部网络安全平台或扫描，因为它发生在你的网络和你的控制之外。

例如，在Docker环境中部署一个Nginx服务。

services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: :/etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy。*default-restart_policy
resources:*default-resources_policy

Nginx服务配置不会对连接进行加密或保护，使得通过该链接交换的所有信息容易受到各种攻击或窥探。

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

很多时候，有人可能通过你的传输层进行窥探的第一个信号是，大量被盗的用户密码被用于后续攻击。如果其他数据，如客户信息、财务记录或重要的公司机密通过不安全的传输层被盗，你甚至可能永远不会意识到你已经被破坏了。

而且，需要保护的不仅仅是用户和应用程序之间的传输层。在后端，许多应用程序彼此之间以及与工作流程中更远的服务器进行通信。虽然这些内部通信通常不容易被外界窥探，但它会将数据暴露给那些可能被允许进入网络但未被授权查看某些高度保护或敏感信息的用户。

妥善保护传输层，实现全面数据保护

保护传输层最好是在创建应用程序时进行。这个过程从拥有一个安全的后端基础设施开始。对于网站来说，一切都应该使用HTTPS来完成。切勿混合使用HTTP和HTTPS基础设施。你甚至应该将你的网站设置为自动将不安全的HTTP请求转到HTTPS基础设施上。

在上面的例子中，保护传输层的正确方法是。

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

在这个例子中，所有与Nginx服务的连接都是强加密的。Nginx配置的服务器部分只包括listen 8443 ssl ，以便强迫SSL保护连接。

为了保护你的数据免受内部威胁，开发人员应该采用强大的传输层加密协议，如TLS 1.2。一旦你有了TLS 1.2或其等同物，像SSL v2这样较弱的协议应从你的基础设施中完全删除，并自动禁止使用。

并始终牢记，只有在静态数据和传输层得到充分保护时，才能确保应用程序的安全。这样，你就可以保证对内部数据和流向授权外部用户的数据进行完整的端对端保护。
。 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试演示一下Secure Code Warrior 培训平台，以保持你所有的网络安全技能得到磨练和更新。