Si usted es un desarrollador que busca aprender más sobre los pasos que puede tomar para comenzar a desplegar una infraestructura segura como código (IaC) en su organización, entonces ha llegado al lugar correcto. Este es el siguiente capítulo de nuestra serie de IaC, diseñada para que te pongas al día en las mejores prácticas de seguridad de IaC.

Antes de empezar, ¿cómo te fue con el desafío de la última entrega? Si dominas la criptografía insegura, veamos cómo te va con la protección insuficiente de la capa de transporte antes de entrar en detalles:

¿Quieres saber más y conseguir una puntuación perfecta? Sigue leyendo:

En nuestro último artículo, hablamos de la importancia de tener una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tienes una encriptación fuerte, actúa como una perfecta última línea de defensa. Incluso si un atacante es capaz de robar esos datos, si están fuertemente encriptados, entonces la información encerrada dentro de esos archivos sigue estando protegida.

Sin embargo, la protección de los datos en reposo es sólo una parte de una defensa completa de los datos. Siempre que los usuarios válidos necesiten acceder a los datos protegidos, hay que enviárselos. A veces, las aplicaciones también compartirán datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, la hace vulnerable tanto al fisgoneo externo como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente de la capa de transporte puede causar graves problemas.

Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre la insuficiente protección de la capa de transporte.

¿Por qué es peligrosa una protección insuficiente de la capa de transporte?

Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los hackers expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones utilizando técnicas como los ataques man-in-the-middle. Probablemente el aspecto más peligroso de este tipo de fisgoneo es que es casi completamente invisible para cualquier plataforma o escáner de ciberseguridad interno porque ocurre fuera de su red y de su control.

Por ejemplo, en un entorno Docker desplegando un servicio 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

La configuración del servicio Nginx no cifrará ni protegerá la conexión, lo que hará que toda la información intercambiada a través del enlace sea vulnerable a diversos ataques o al espionaje.

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;
       }
   }

A menudo, la primera señal de que alguien podría estar fisgoneando a través de sus capas de transporte es cuando se utiliza un gran número de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como la información de los clientes, los registros financieros o los secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que nunca se dé cuenta de que ha sido comprometida.

Y no es sólo la capa de transporte entre usuarios y aplicaciones la que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con servidores más avanzados en la cadena del flujo de trabajo. Aunque estas comunicaciones internas no suelen ser vulnerables al espionaje externo, pueden exponer los datos a usuarios que pueden tener permiso para entrar en la red pero no están autorizados a ver cierta información altamente protegida o sensible.

Asegurar adecuadamente las capas de transporte para una protección total de los datos

La protección de las capas de transporte se realiza mejor mientras se crean las aplicaciones. Este proceso empieza por tener una infraestructura backend segura. En el caso de los sitios web, todo debe hacerse utilizando HTTPS. Nunca mezcles la infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que dirijan automáticamente las peticiones HTTP no seguras a la infraestructura HTTPS.

En el ejemplo anterior, un método adecuado para proteger la capa de transporte sería:

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;
       }
   }

En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente encriptadas. La sección del servidor de la configuración de Nginx solo incluye listen 8443 ssl para forzar que SSL proteja las conexiones.

Para proteger sus datos de las amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte fuerte como TLS 1.2. Una vez que se haya implantado TLS 1.2 o su equivalente, los protocolos más débiles como SSL v2 deberían eliminarse por completo de la infraestructura y prohibirse automáticamente su uso.

Y tenga siempre en cuenta que la seguridad de una aplicación no es completa hasta que tanto los datos en reposo como las capas de transporte están suficientemente protegidos. De este modo, podrá garantizar una protección completa de extremo a extremo para los datos, tanto a nivel interno como cuando fluyan hacia usuarios externos autorizados.
Consulte las páginas del Secure Code Warrior para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.