Documento técnico de referencia. Complementa la Política de Seguridad de la Información (documento 10) y el DPA (documento 5). Aplica al servicio Cloud Alfa en su conjunto.
1. Modelo de defensa en profundidad
La seguridad de Cloud Alfa se estructura en siete capas concéntricas, de modo que el fallo de una no comprometa el conjunto. Este enfoque sigue las recomendaciones del CCN-CERT para servicios cloud y los controles del anexo A de ISO/IEC 27001:2022.
Las capas son:
Capa física
Capa de red
Capa de perímetro
Capa de aplicación
Capa de identidad y acceso
Capa de datos
Capa de monitorización y respuesta
2. Capa física
Controles aplicables
Proveedor VPS: [PROVEEDOR VPS], ubicado en [PAÍS/REGIÓN], con certificaciones ISO 27001 y SOC 2 Type II.
Almacenamiento de objetos: [PROVEEDOR R2], con cifrado en reposo gestionado y replicación multi-región.
Separación de entornos: producción, preproducción y desarrollo con credenciales y redes distintas.
Aislamiento de tenant: cada tenant dispone de esquema lógico separado; los objetos se almacenan con prefijos por tenant.
Justificación normativa
El art. 32.1.b RGPD exige "la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento". La separación física y lógica es medida de cumplimiento.
3. Capa de red
Controles aplicables
Segmentación: subredes separadas para base de datos, aplicación, almacenamiento y gestión.
Firewall: reglas mínimas, denegación por defecto, solo puertos necesarios.
Red privada: comunicación entre servicios a través de red interna, nunca por Internet.
VPN/administración: acceso administrativo exclusivamente por VPN con MFA.
Cifrado de red: TLS 1.3 obligatorio entre todos los servicios.
Justificación normativa
El art. 32.1.a RGPD exige cifrado de datos personales. La segmentación de red es medida de contención del art. 32.1.b.
4. Capa de perímetro
Controles aplicables
WAF (Web Application Firewall): reglas OWASP Top 10 actualizadas.
Mitigación DDoS: protección volumétrica y de aplicación.
Rate limiting: límites por IP, por usuario y por endpoint.
Bot management: detección de scraping y credential stuffing.
Geoblocking opcional: restricción a países donde no se comercializa el servicio.
Justificación normativa
El considerando 83 RGPD exige evaluar los riesgos de destrucción, pérdida, alteración, divulgación no autorizada o acceso accidental. El perímetro es la primera línea de defensa.
5. Capa de aplicación
Controles aplicables
Validación de entrada: esquemas estrictos, rechazo por defecto.
Codificación de salida: prevención de XSS.
Consultas parametrizadas: prevención de SQL injection.
CSRF tokens: en formularios y operaciones sensibles.
Cabeceras de seguridad: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
SAST/DAST: análisis estático y dinámico en CI/CD.
Escaneo de dependencias: detección de vulnerabilidades en librerías.
Pentest anual: por tercero independiente.
Justificación normativa
El art. 25 RGPD (protección de datos desde el diseño y por defecto) exige integrar la seguridad en el ciclo de desarrollo.
6. Capa de identidad y acceso
Controles aplicables
Autenticación: contraseñas con política robusta (mínimo 12 caracteres, complejidad, sin diccionario).
Hashing: bcrypt o argon2id con factores de coste actualizados.
MFA: obligatoria para owner/admin; opcional para socios.
RBAC: roles owner, admin, staff, socio con permisos granulares.
Tenant enforcement: cada operación verifica el tenant del usuario autenticado.
Políticas RLS: Row Level Security en PostgreSQL cuando sea viable.
Sesiones: expiración por inactividad, rotación de token, revocación centralizada.
Credential stuffing: bloqueo progresivo tras intentos fallidos.
Justificación normativa
El art. 32.1.b RGPD exige garantizar la confidencialidad. El art. 5.1.f exige integridad y confidencialidad. El principio de mínimo privilegio es medida organizativa del art. 32.4.
7. Capa de datos
Controles aplicables
Cifrado en tránsito: TLS 1.3.
Cifrado en reposo: AES-256-GCM.
Gestión de claves: rotación periódica, separación de funciones, almacenamiento en KMS.
Backups cifrados: con retención definida y pruebas de restauración.
Minimización: solo los datos necesarios para cada finalidad.
Pseudonimización: cuando sea posible.
Anonimización: para analítica agregada.
Borrado seguro: conforme a la Política de Retención y Borrado.
Justificación normativa
El art. 32.1.a RGPD exige el cifrado de datos personales. El art. 5.1.c y 5.1.e exigen minimización y limitación del plazo de conservación.
8. Capa de monitorización y respuesta
Controles aplicables
Logs estructurados: JSON con campos normalizados.
Centralización: SIEM con correlación de eventos.
Inmutabilidad: logs con hash encadenado o almacenamiento WORM.
Retención: mínimo 6 meses, máximo 2 años.
Alertas: umbrales por severidad, notificaciones 24/7.
Métricas: Prometheus/Grafana o equivalente.
Trazas: OpenTelemetry para peticiones críticas.
Health checks: endpoint /health con verificación de dependencias.
Plan de respuesta: conforme al documento 12.
Justificación normativa
El art. 33 RGPD exige notificar violaciones en 72 horas. La monitorización es requisito para detectar y caracterizar incidentes.