Infraestructura segura para startups: cómo proteger tu negocio desde el día uno
Tener un servidor mal configurado puede costarle millones a una startup. Lecciones prácticas sobre Linux, Docker, backups y monitoreo para construir sobre bases sólidas.
Contenido
- 1. La realidad de las startups chilenas
- 2. Linux: lo básico bien hecho
- 3. Docker: consistencia y aislamiento
- 4. Backups que no fallan
- 5. Monitoreo: saber antes de que ocurra
- 6. Seguridad de red y acceso
- 7. VPS, Cloud o físico: ¿qué elegir?
- 8. Infraestructura que crece con tu startup
- 9. Cómo puede ayudar Lanedu
1. La realidad de las startups chilenas
Conocemos bien la historia: una startup nace con un MVP, lo deployan en un VPS barato o en una cuenta de algún cloud provider, y durante meses (o años) nadie toca la configuración del servidor. "Si funciona, no lo toques", dicen.
El problema es que esa filosofía funciona hasta que deja de funcionar. Y cuando falla, suele ser feo: datos perdidos, sitio caído por horas, acceso de terceros no autorizados o —cada vez más seguido— una filtración de datos personales que además de ser un desastre operacional, ahora con la Ley 21.719 puede significar multas millonarias.
La buena noticia es que construir una infraestructura segura no es caro ni complicado cuando se hace bien desde el principio. Este artículo cubre los pilares esenciales para que cualquier startup pueda dormir tranquila.
💡 El principio clave
La seguridad no se agrega al final. Se diseña desde el día uno. Cambiar la configuración de infraestructura después de lanzada una aplicación es 10 veces más caro que hacerlo bien desde el comienzo.
2. Linux: lo básico bien hecho
La mayoría de los servidores en producción corren Linux. Y la mayoría de los problemas de seguridad vienen de configuraciones básicas mal hechas. Estas son las prácticas mínimas que cualquier servidor debería tener:
a) Deshabilitar acceso root por SSH
Parece obvio, pero es impactante cuántos servidores en producción tienen el acceso root habilitado con contraseña:
Use solo claves SSH para acceder. Cada developer con su propia clave. Si alguien se va del equipo, revocar una clave es inmediato.
b) Firewall: solo lo necesario
Con ufw (Uncomplicated Firewall) se puede tener un firewall básico en minutos:
Solo puertos 22 (SSH), 80 (HTTP) y 443 (HTTPS). Nada más. Si necesita acceso a BD, hágalo por túneles SSH, no abriendo puertos.
c) Actualizaciones automáticas
Las vulnerabilidades críticas aparecen todas las semanas. Automatice las actualizaciones de seguridad con unattended-upgrades:
Configure para que solo instale parches de seguridad, no nuevas versiones. Así evita sorpresas con cambios de comportamiento.
d) Fail2ban contra fuerza bruta
Fail2ban bloquea IPs que tengan múltiples intentos fallidos de conexión. Se configura en 5 minutos y detiene el 99% de los ataques automatizados:
En 24 horas de operación, es normal ver cientos de intentos de conexión bloqueados por fail2ban. En servidores sin protección, bastaría uno exitoso.
3. Docker: consistencia y aislamiento
Docker no es solo una moda. Es una capa de seguridad y consistencia que toda startup debería adoptar. Estas son las razones prácticas:
📦 Aislamiento de aplicaciones
Cada servicio corre en su propio contenedor. Si una aplicación tiene una vulnerabilidad, el atacante queda atrapado en ese contenedor (si está bien configurado) y no accede al servidor completo ni a los otros servicios.
🔒 Reproducibilidad
Con Dockerfile y docker-compose, cualquier developer puede levantar el mismo entorno que está en producción. Adiós al "en mi máquina funciona". Y adiós a los accesos directos a BD de producción para hacer pruebas.
📦 Imágenes inmutables
Nunca haga cambios manuales en un contenedor en producción. Si necesita cambiar algo, modifique el Dockerfile, reconstruya la imagen y redeploye. Esto deja trazabilidad de cada cambio.
Buenas prácticas con Docker
Note que los puertos se exponen solo en localhost (127.0.0.1:3000:3000)
y se usa un reverse proxy (Nginx, Caddy) para el acceso público. Además, las
contraseñas se manejan como secretos, no en variables de entorno visibles.
⚠️ Importante: Docker no es seguro por sí solo. Un contenedor
mal configurado puede ser tan inseguro como un servidor sin protección. No ejecute
contenedores como root, no monte /var/run/docker.sock innecesariamente
y use imágenes oficiales verificadas.
4. Backups que no fallan
Si no tiene backups automatizados y probados, no tiene backups. Tener un script que "alguien ejecuta de vez en cuando" no es un plan de recuperación.
Backup de PostgreSQL
Este script: 1) comprime, 2) cifra, 3) sube a almacenamiento externo, 4) limpia locales antiguos. Pruébelo al menos una vez al mes restaurando en un entorno de prueba.
La regla 3-2-1 sigue siendo la mejor práctica: 3 copias de los datos, en 2 tipos de soporte diferentes, con 1 copia fuera del sitio (off-site). Para startups, esto puede ser: servidor principal + backup local cifrado + cloud (S3, Backblaze, Wasabi).
5. Monitoreo: saber antes de que ocurra
No tener monitoreo es como tener una alarma de incendio que solo suena cuando ya ves el humo. Estas son las herramientas mínimas que cualquier startup debería tener:
| Herramienta | Para qué | Costo |
|---|---|---|
| Uptime Kuma | Monitoreo de disponibilidad (HTTP, ping, puertos) | Gratis, self-hosted |
| Netdata | Métricas del servidor en tiempo real (CPU, RAM, disco, red) | Gratis, self-hosted |
| Prometheus + Grafana | Métricas históricas, alertas avanzadas y dashboards | Gratis, self-hosted |
| Healthchecks.io | Monitoreo de cron jobs y backups (avisa si no se ejecutan) | Gratis (100 checks) |
| Better Uptime | Monitoreo todo-en-uno con página de estado | Gratis limitado / desde $20/mes |
Configure al menos alertas para: disco lleno (>80%), RAM sobre el 90%, caída del servicio web, y fallo del backup. Recibirlas por correo o Slack es suficiente para empezar.
6. Seguridad de red y acceso
La red es su perímetro. Y el perímetro de una startup suele ser más poroso de lo que parece:
- VPN para acceso interno: WireGuard es simple, rápido y seguro. Úselo para que developers accedan a servidores de staging o producción.
- Reverse proxy con SSL: Caddy o Nginx con Let's Encrypt. SSL automático. Nunca exponga servicios directamente al internet.
- Autenticación en dos factores (2FA): Para paneles de administración, acceso a cloud providers y cuentas de administración del servidor.
- Principio de mínimo privilegio: Cada usuario solo tiene los permisos que necesita. No todos los developers necesitan acceso root ni a BD de producción.
7. VPS, Cloud o físico: ¿qué elegir?
Una pregunta recurrente en startups con presupuesto ajustado. Acá una visión práctica:
| VPS (Hetzner, DigitalOcean) | Cloud (AWS, GCP, Azure) | Físico (Servidor propio) | |
|---|---|---|---|
| Costo mensual | $10–40 USD | $30–100+ USD | $50–150+ USD + electricidad |
| Escalabilidad | Media | Alta | Baja |
| Mantención | Tú administras | Compartida | Total |
| Cumplimiento Ley 21.719 | Tú eres responsable | Responsabilidad compartida | Tú eres responsable |
| Recomendado para | Startups en etapa temprana | Startups en crecimiento | Casos muy específicos |
Para la mayoría de las startups chilenas, un VPS de Hetzner o DigitalOcean con Docker es el punto óptimo. Cuesta ~$20 USD al mes y con una configuración adecuada cumple perfectamente con los requisitos de seguridad de la Ley 21.719. Cloud tiene sentido cuando necesita escalar horizontalmente o usa servicios administrados (RDS, S3, etc.).
8. Infraestructura que crece con tu startup
El error más común es diseñar infraestructura para el día 1000 cuando estás en el día 1. Acá una progresión recomendada:
MVP / Early stage
VPS con Docker, docker-compose, backups automáticos y monitoreo básico (Uptime Kuma + Netdata). Setup en un día, ~$20/mes.
Crecimiento / Tracción
Dos VPS (app + BD separados), CI/CD con GitHub Actions, Prometheus + Grafana para monitoreo avanzado, backups cifrados a cloud. ~$50–80/mes.
Escalamiento
Kubernetes (K3s ligero), múltiples servicios, alta disponibilidad, VPC para aislamiento de red. Cloud o VPS gestionado con balanceadores. $200+/mes.
La clave está en no saltarse etapas. Lo que funciona para 100 usuarios no será suficiente para 10.000, pero diseñar para 10.000 desde el día 1 es una pérdida de tiempo y dinero.
9. Cómo puede ayudar Lanedu
En Lanedu trabajamos con startups y empresas establecidas en la implementación y mantención de infraestructura tecnológica segura y escalable:
🐳 Setup de Docker y docker-compose
Configuramos entornos contenerizados para desarrollo, staging y producción.
🔧 Administración de servidores Linux
Hardening, monitoreo, actualizaciones y mantención continua de servidores.
💾 Backups y recuperación
Diseñamos estrategias de backup automatizadas, cifradas y probadas.
📊 Monitoreo y alertas
Configuramos monitoreo 24/7 con alertas tempranas para evitar caídas.
🛡️ Cumplimiento Ley 21.719
Adecuamos su infraestructura a los requisitos de seguridad de la nueva ley de datos.
🎓 Capacitación para el equipo
Formamos a su equipo en Linux, Docker, seguridad y buenas prácticas de infraestructura.
Cristian López
Consultor en protección de datos e infraestructura · Lanedu
Este artículo fue elaborado con base en la experiencia práctica de Lanedu en administración de servidores Linux, contenerización con Docker y seguridad de infraestructura para startups y empresas en Chile. Para consultas específicas, contáctanos.