Seguridad

Cuando la tecnología Docker apareció, la adoraron por el lema: «Build once, run anywhere» (Construye una vez, ejecuta en cualquier lugar). Los desarrolladores dejaron de escuchar la frase «en mi máquina funciona, pero en el servidor no». Pero junto con la comodidad llegó una nueva amenaza.

Un contenedor no es solo tu aplicación. Es todo un mini-sistema operativo (SO) con sus propias bibliotecas, utilidades y llamadas al sistema. Y si no vigilas ese SO, dejas a los atacantes una puerta enorme completamente abierta.

Imagina que estás construyendo una casa. Tú mismo diseñaste las paredes, revisaste cada ladrillo y te aseguraste de no haber olvidado las llaves en la cerradura. Pero ¿y si el hormigón que compraste a un proveedor externo con el tiempo empieza a desmoronarse? ¿O si en los marcos de las ventanas que instalaste hay defectos ocultos?

En el desarrollo moderno la situación es exactamente así. Una aplicación promedio hoy en día está formada en un 80–90% por bibliotecas de código abierto. Solo escribes una pequeña parte del código (la punta del iceberg), que gestiona un enorme volumen de código ajeno oculto «bajo la superficie».

¿Alguna vez te has preguntado cómo los programadores experimentados encuentran errores en el código ajeno con solo mirarlo? Buscan patrones. Saben que si los datos del usuario entran directamente en una consulta SQL —eso es malo. Si la contraseña se compara con un == en lugar de una función segura —es un riesgo.

Pero una persona no puede revisar 100 000 líneas de código sin pasar algo por alto. Aquí entra en escena SAST (Static Application Security Testing).

Imagine la situación: trabajas en un proyecto genial toda la noche. A las 4 de la mañana todo está listo, haces un git push final y te vas a dormir tranquilo. Y por la mañana descubres que tu balance en AWS está a cero y que hay un minero corriendo en tus servidores. ¿Qué pasó? Resulta que en uno de los archivos dejaste la línea: AWS_ACCESS_KEY_ID = "AKIA...".

Es un error clásico por el que han pasado miles de desarrolladores. En este artículo veremos por qué «simplemente borrar la contraseña» no ayuda y cómo configurar una protección automática que físicamente te impedirá cometer el error.

Si su negocio trabaja con usuarios de Rusia, la cuestión de dónde se almacenan los datos personales le concierne directamente. Teléfonos, nombres, direcciones de correo electrónico, solicitudes de formularios, datos de empleados: todo esto está sujeto a estrictos requisitos de localización.

Durante años muchas empresas vivieron en una “zona gris”: los datos aparentemente se almacenaban tanto en Rusia como en el extranjero y la responsabilidad estaba diluida. Pero a partir del 1 de julio de 2025 las reglas cambiaron tanto que muchos esquemas técnicos habituales ahora se consideran una violación directa de la ley.

Gracias a Let’s Encrypt HTTPS se convirtió en el estándar para toda la web. Este proyecto permitió a cualquier administrador de sitios obtener un certificado SSL gratuito literalmente con unos pocos comandos. Pero en el mercado han surgido otros actores que ofrecen más comodidad, integraciones y flexibilidad.

Si quieres probar algo además de Let’s Encrypt, a continuación tienes un repaso de las alternativas más fiables y populares.

1. ZeroSSL — la misma automatización, pero con interfaz cómoda

ZeroSSL (Austria) — el principal competidor de Let’s Encrypt. Es totalmente compatible con el mismo protocolo ACME, pero pone énfasis en la facilidad de uso.

El problema de los certificados a gran escala

En artículos anteriores discutimos que OpenVPN utiliza certificados para la autenticación. Este método es fiable, pero tiene desventajas importantes:

• Incomodidad para los usuarios: Cada usuario necesita recibir e instalar su certificado manualmente.
• Complejidad de gestión: Al despedir a un empleado es necesario revocar su certificado, lo que requiere acciones adicionales.
• Falta de centralización: Cada servicio al que se necesita acceso tiene su propio sistema de autorización.

La solución a este problema es el uso de un proveedor de identidad centralizado, como Keycloak.

VPN: No solo el botón “Encender”

Para muchos usuarios, el VPN es simplemente el botón “Encender”. Sin embargo, cuando se trata de crear un túnel protegido propio, es importante comprender su arquitectura. OpenVPN se basa en dos ideas clave: el modelo cliente-servidor y la infraestructura de clave pública (PKI).

Modelo cliente-servidor

El concepto es sencillo:

• Servidor — es el punto de entrada a su red protegida. Está constantemente “escuchando” solicitudes entrantes y listo para aceptar conexiones.
• Cliente — es su dispositivo (portátil, teléfono), que inicia la conexión al servidor.

Después de que el servidor y el cliente “se ponen de acuerdo”, se crea un túnel protegido entre ellos y todo el tráfico pasa por él.

OpenVPN: Un estándar probado por el tiempo

Introducción

En un mundo donde la velocidad y la simplicidad de WireGuard se han convertido en el nuevo estándar, OpenVPN sigue siendo uno de los protocolos VPN más fiables y flexibles. Funciona tanto en ordenadores clásicos como en equipos de red, ofreciendo compatibilidad multiplataforma y un alto nivel de seguridad. Sin embargo, para entender cómo usarlo, es importante distinguir entre el propio protocolo y sus aplicaciones cliente.

Cuando el control es lo más importante

Servicios como Tailscale y NetBird son convenientes, pero dependen de un servidor de gestión de terceros que se encarga de la autenticación, la distribución de claves y el intercambio de información de rutas. Para quienes, por motivos de seguridad o privacidad, no quieren confiar esa función a nadie, existen dos vías: Headscale y el WireGuard “puro”.

Headscale: Tu propio Tailscale

Headscale es una implementación completamente open-source del servidor de gestión de Tailscale. Permite desplegar tu propio análogo de Tailscale en tu VPS o servidor, utilizando los clientes oficiales de Tailscale.