Externalizar los datos hacia el cloud aligera la infraestructura interna, pero desplaza la cuestión de seguridad —no la resuelve—. Lo que garantiza tu VPN cloud de empresa y lo que sigue siendo tu responsabilidad son dos perímetros distintos que muchas organizaciones confunden. Esta página detalla los riesgos reales, el marco reglamentario aplicable y las medidas que cuentan.
El modelo de responsabilidad compartida
AWS, Azure, Google Cloud: todos publican un modelo de responsabilidad compartida. El principio es constante —el proveedor se hace cargo de la seguridad de la infraestructura cloud (infraestructura física y una parte de las capas técnicas subyacentes), mientras que la seguridad en el cloud sigue del lado del cliente—. La extensión exacta de ese reparto depende del modelo de servicio: IaaS, PaaS o SaaS. Quedan invariablemente a tu cargo: la configuración de los servicios, la gestión de los accesos, el cifrado de los datos de aplicación, el comportamiento de los usuarios.
En la práctica, un bucket de almacenamiento mal configurado, permisos demasiado amplios en una cuenta de servicio o identificadores comprometidos no comprometen la responsabilidad del proveedor. Son tus datos, tu configuración, tu exposición. Los errores de configuración figuran entre las causas más frecuentes de exposición en el cloud: el problema viene a menudo menos del proveedor que de una gobernanza incompleta de los accesos, los parámetros y los usos.
Los vectores de riesgo reales
En muchas organizaciones, los incidentes cloud tienen que ver con tres familias de problemas:
- Errores de configuración — almacenamiento abierto públicamente por descuido, reglas de cortafuegos demasiado permisivas, registro desactivado. Frecuentes en migraciones rápidas o despliegues sin revisión de seguridad.
- Accesos no revocados — cuentas de antiguos colaboradores, tokens de API olvidados, accesos de proveedores nunca desactivados. El principio del mínimo privilegio rara vez se aplica con rigor en las pymes.
- Movilidad y BYOD — acceder a los recursos internos desde un wifi público sin camino controlado amplía la superficie de ataque: secuestro de DNS, portales cautivos, exposición de metadatos, acceso sin política uniforme. El reto no es solo el cifrado del contenido (TLS ya cubre una parte de los intercambios de aplicación), sino la ausencia de punto de salida controlado y de política de acceso homogénea.
Lo que dice el marco reglamentario
Reglamentaciones de protección de datos (como el RGPD europeo, artículo 32, o las leyes locales equivalentes): imponen medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adaptado al riesgo. El cifrado de los datos se cita explícitamente entre esas medidas. Esto se aplica a todo dato personal almacenado o tratado en el cloud.
Directiva NIS2: amplía las obligaciones de ciberseguridad a las entidades esenciales e importantes en sectores definidos —gestión de los riesgos, continuidad de actividad, notificación de los incidentes—. Incluye exigencias sobre la seguridad de la cadena de suministro: las entidades concernidas deben encuadrar los riesgos ligados a sus proveedores críticos, lo que puede repercutir contractualmente obligaciones de seguridad sobre los encargados del tratamiento.
Certificaciones cloud nacionales: según los países, calificaciones oficiales atestiguan que un proveedor ofrece garantías sobre la localización de los datos, la resistencia a las imposiciones extranjeras y las prácticas de seguridad. Pertinente para las organizaciones que tratan datos sensibles o sujetas a obligaciones sectoriales.
Lo que una VPN cubre aquí —y lo que no cubre—
Una VPN cloud de empresa asegura el tránsito: el enlace entre el equipo del colaborador y los recursos internos está cifrado, la IP de origen se oculta, y el acceso puede condicionarse a una autenticación fuerte.
Lo que una VPN no cubre. El cifrado de los datos en reposo en el cloud, la gestión de los derechos de acceso, la configuración de los servicios, la detección de los comportamientos anormales. Una VPN no reemplaza ni una política IAM rigurosa, ni el cifrado at-rest, ni un SIEM.
Para los entornos mayoritariamente SaaS (suites ofimáticas en línea, herramientas colaborativas, CRM cloud), la VPN de empresa no siempre es el control prioritario. Según la arquitectura, un acceso condicional, una solución CASB, control de postura de los terminales o un enfoque Zero Trust pueden ser más estructurantes. La VPN sigue siendo pertinente para el acceso a los recursos internos y a los entornos híbridos; se vuelve insuficiente sola en cuanto lo esencial del trabajo pasa por aplicaciones cloud de terceros. Su papel es preciso: imponer un camino controlado, una política de acceso uniforme y un perímetro controlado para el tráfico hacia los recursos internos. Una medida necesaria en ese perímetro, no una respuesta universal. Para el aspecto de red, consulta también cómo asegurar los puntos de acceso de una red profesional.
Las confusiones más frecuentes
«Nuestros datos están en un gran proveedor, así que están seguros.» La infraestructura puede ser robusta sin decir nada de la calidad de tus configuraciones, del rigor de tus derechos de acceso o del comportamiento de tus usuarios. Tres problemas distintos que el proveedor no resuelve en tu lugar.
«El cifrado nativo del almacenamiento basta.» Protege los datos en reposo contra un acceso físico no autorizado a los discos. No protege contra una cuenta legítima demasiado permisiva, identificadores comprometidos o un acceso de proveedor nunca revocado. El cifrado at-rest no es una política de acceso.
«Trabajamos sobre todo en SaaS, una VPN basta.» En un entorno mayoritariamente SaaS, el túnel de red no es el control principal. El reto es la identidad, el estado del terminal y las políticas de acceso condicionales. Un colaborador con la cuenta comprometida, el terminal no gestionado o los permisos demasiado amplios representa un riesgo que la VPN no reduce.
Priorizar según tu entorno
Las buenas medidas no son las mismas según la arquitectura real de la organización.
| Perfil | A priorizar |
|---|---|
| Pyme mayoritariamente SaaS | MFA en todas las cuentas, acceso condicional, gestión de los terminales (MDM), revisión regular de los derechos, registro de las conexiones. La VPN es secundaria si los recursos internos son limitados. |
| Pyme híbrida con recursos internos | VPN o ZTNA para el acceso remoto, segmentación de los accesos, bastión de administración, logs centralizados. El túnel de red controlado se vuelve estructurante. |
| Datos sensibles / restricciones sectoriales | Localización de los datos, gobernanza de las claves de cifrado, elección de un proveedor certificado, trazabilidad completa, exigencias repercutidas sobre los proveedores. |
Las medidas que cuentan
- Cifrado in-transit — TLS 1.2 como mínimo, TLS 1.3 en cuanto sea posible, y VPN o ZTNA para los accesos remotos a los recursos internos.
- Cifrado at-rest — activar el cifrado nativo de los servicios de almacenamiento. Gestionar las claves por separado (KMS, HSM) si la sensibilidad lo justifica.
- IAM estricto — mínimo privilegio sistemático, revisión regular de los accesos, eliminación inmediata de las cuentas en las salidas, MFA obligatoria en todas las cuentas con privilegios.
- Registro y detección — activar los logs de acceso y de configuración, definir alertas sobre los comportamientos anormales (conexiones desde geografías inhabituales, volúmenes atípicos).
- Copias de seguridad y restauración — conservar copias separadas del sistema principal, verificar su integridad y probar realmente la restauración. Una copia no probada es una hipótesis, no una garantía.
- Plan de respuesta a incidentes — definir antes del incidente quién hace qué, en qué plazos, con qué procedimientos de notificación, incluida la obligación legal de notificar la violación a la autoridad de control en los plazos reglamentarios.
El riesgo principal del cloud no es el alojamiento externalizado en sí: es la creencia de que un proveedor, por excelente que sea, absorbe en tu lugar la responsabilidad de los accesos, las configuraciones y la gobernanza. En numerosas organizaciones, los incidentes tienen que ver menos con una falla del proveedor que con derechos demasiado amplios, configuraciones frágiles o una gobernanza incompleta.