Fundamentos de la computación en la nube
Gobernanza y cumplimiento
Cómo la gobernanza en la nube fija las reglas propias de una organización para usar sus recursos, cómo el cumplimiento demuestra que esas reglas satisfacen un marco o una regulación externa, y dónde terminan las certificaciones de un proveedor y empieza la evidencia propia del cliente.
- Distinguir la gobernanza del cumplimiento y explicar qué responde cada una
- Comparar ISO 27001, SOC 2, PCI DSS, HIPAA y GDPR según qué cubre cada uno y quién suele necesitarlo
- Explicar qué demuestra el informe de cumplimiento de un proveedor y qué le queda al cliente por demostrar aparte
- Distinguir la residencia de datos de la soberanía de datos e identificar cuál de las 2 evalúa en verdad un escenario
Un certificado que no cubría lo que pensaban
Una startup de salud contrata a un proveedor de nube grande, ve los sellos de SOC 2 e ISO 27001 en la página de cumplimiento del proveedor, y le dice a su directorio que la plataforma cumple HIPAA. Meses después, una auditoría real de HIPAA le pide sus propios registros de acceso, su configuración de cifrado y sus registros de capacitación de seguridad del personal, nada de lo cual las certificaciones del proveedor prometieron cubrir jamás.
Es el mismo vacío que la primera lección de este tema nombró como error de concepto, ahora completo: la certificación de un proveedor demuestra que su propia infraestructura cumple un estándar. Si la aplicación construida encima de ella cumple ese mismo estándar es una pregunta aparte, y es justo lo que la gobernanza y el cumplimiento, como disciplina, existen para responder.
La gobernanza pregunta hacia adentro, el cumplimiento apunta hacia afuera
La gobernanza es el propio reglamento de una organización sobre cómo se configuran y se usan sus recursos de nube: quién revisa las solicitudes de acceso, cómo se etiquetan los recursos, qué línea base de configuración tiene que cumplir cada servicio nuevo antes de salir a producción. Nace hacia adentro, y una empresa puede tener gobernanza sólida sin ningún marco externo de por medio.
El cumplimiento es distinto: es demostrarle a un auditor, a un regulador o al equipo de compras de un cliente que las prácticas de una organización satisfacen una vara externa específica. Esa vara puede ser un estándar certificable que una empresa elige perseguir, o una ley que no tiene opción de cumplir. Una buena gobernanza hace que el cumplimiento sea más fácil de demostrar, pero las 2 responden preguntas distintas: la gobernanza pregunta "¿lo estamos haciendo de forma consistente?", el cumplimiento pregunta "¿podemos demostrárselo a alguien de afuera?".
El panorama de cumplimiento: qué cubre cada marco en realidad
| Marco | Qué cubre | Quién suele necesitarlo | Certificación o ley |
|---|---|---|---|
| ISO 27001 | Un sistema completo de gestión de seguridad de la información: evaluación de riesgos, control de acceso, gestión de incidentes | Cualquier organización, reconocido a nivel internacional | Certificación, válida 3 años |
| SOC 2 | 5 criterios de servicios de confianza: seguridad, disponibilidad, integridad del procesamiento, confidencialidad, privacidad | Enfocado en Estados Unidos, sobre todo SaaS y proveedores de tecnología | Informe de atestación, la opinión de un auditor |
| PCI DSS | Proteger específicamente los datos de tarjetas de pago, 12 requisitos desde seguridad de red hasta restricción de acceso | Cualquier organización que guarda, procesa o transmite datos de titulares de tarjeta | Estándar certificable |
| HIPAA | Proteger la información de salud de pacientes (PHI) | Organizaciones de salud de Estados Unidos y sus proveedores | Ley federal de Estados Unidos |
| GDPR | Datos personales de personas en la UE, incluidas las reglas de transferencia internacional | Cualquier organización que maneje datos personales de residentes de la UE, sin importar dónde esté la organización | Ley de la UE |
ISO 27001 y SOC 2 se superponen bastante en los controles que revisan, tanto que un programa de cumplimiento bien llevado a veces satisface los 2 sin duplicar el trabajo, pero sirven a audiencias distintas: SOC 2 es lo que suele pedir un cliente empresarial de Estados Unidos, ISO 27001 es lo que suele esperar uno internacional.
Dónde encontrar la mitad del proveedor en la evidencia
Un proveedor de nube no manda sus informes de cumplimiento por correo cuando se los pides; los publica a través de un portal de autoservicio. La versión de AWS se llama AWS Artifact, y le da a cualquier cuenta acceso bajo demanda a los propios informes SOC 1/2/3, ISO y PCI de AWS, cada uno generado con una marca de agua única para quien lo solicita. Ese portal es el punto de partida del cliente cuando un auditor pregunta "muéstrame los controles del proveedor", y es gratis de usar. Lo que nunca puede entregar es la otra mitad de la evidencia, la propia configuración, los registros de acceso y los procesos internos del cliente, porque AWS Artifact solo documenta la mitad de AWS en la línea de responsabilidad compartida.
Residencia de datos frente a soberanía de datos
Estos 2 términos se usan como sinónimos, y vale la pena nombrar el límite entre ellos con claridad, porque el examen lo evalúa directo. La residencia de datos es sobre ubicación física: dónde, geográficamente, están guardados los datos. La soberanía de datos es sobre jurisdicción legal: las leyes de qué país gobiernan esos datos, sin importar dónde estén sentados en realidad.
GDPR es un buen caso de estudio porque deja claro cuál de las 2 le importa en verdad. GDPR no exige que los datos personales de la UE se queden físicamente dentro de la UE. Lo que exige, bajo sus reglas de transferencias internacionales, es que cualquier transferencia de datos personales fuera de la UE o el EEE reciba una protección esencialmente equivalente a la que da el propio GDPR, mediante mecanismos como una decisión de adecuación sobre el país de destino, o cláusulas contractuales estándar entre quien envía y quien recibe. Una empresa puede elegir una región de nube en la UE por buenas razones operativas, menor latencia para sus usuarios en la UE, una historia más simple para sus clientes, pero eso resuelve la residencia, una pregunta de ubicación. No satisface por sí solo la pregunta legal de transferencia que en verdad plantea GDPR si esos mismos datos después se copian, se respaldan o se procesan en algún lugar fuera de la UE.
Un ejemplo trabajado: elegir una región para datos personales de la UE
Digamos que un equipo está construyendo un servicio que guarda datos personales de residentes de la UE. Elegir una región en la UE mantiene esos datos físicamente cerca de sus usuarios y da una respuesta simple a "¿dónde viven nuestros datos?". Pero el equipo igual tiene que revisar cada lugar por el que esos datos viajan después: una herramienta de soporte alojada fuera de la UE, un pipeline de analítica en una región de Estados Unidos, un respaldo replicado en otro continente. Cada uno de esos casos es una transferencia bajo las reglas del Capítulo 5 de GDPR, y cada uno necesita su propia base legal, una decisión de adecuación para ese destino, o cláusulas contractuales, sin importar qué tan bien elegida haya estado la región principal.
Error de concepto, otra vez: heredar un sello
La primera lección de este tema nombró este error de concepto en el contexto de la seguridad en general; aquí es el error específico y recurrente en materia de cumplimiento: asumir que la certificación de un proveedor pasa de forma automática a lo que un cliente construye encima. Nunca pasa. AWS Artifact, o su equivalente en cualquier proveedor, entrega evidencia de los propios controles del proveedor. El cliente igual tiene que armar su propia evidencia: revisiones de acceso, la configuración de cifrado de la lección anterior, capacitación del personal, procesos de respuesta a incidentes, todo lo que HIPAA, PCI DSS o el propio cuestionario de seguridad de un cliente en verdad piden ver.
Pistas de examen: unir el escenario con el marco
| Si el escenario dice... | Apunta a |
|---|---|
| "Información de salud de pacientes", "proveedor de salud" | HIPAA |
| "Datos de tarjetas de crédito", "entorno de datos de titulares de tarjeta" | PCI DSS |
| "Datos personales de personas en la UE", "transferencia internacional" | GDPR |
| "Dónde están guardados físicamente nuestros datos" | Residencia de datos |
| "Las leyes de quién aplican a nuestros datos" | Soberanía de datos |
| "Necesitamos los propios informes de auditoría del proveedor" | AWS Artifact, o el portal equivalente del proveedor |
Dónde te deja esto
El cumplimiento nunca es algo que un cliente hereda entero de la página de sellos de un proveedor; es algo que se arma con la infraestructura certificada del proveedor más los controles propios del cliente encima, el mismo límite que trazó el modelo de responsabilidad compartida al principio de este tema, ahora aplicado de forma específica a demostrárselo a alguien de afuera. Con esto se cierra Seguridad en la nube: ya puedes nombrar quién es dueño de qué tarea de seguridad, cómo la identidad y el cifrado hacen cumplir esa propiedad, y cómo la gobernanza y el cumplimiento demuestran que todo eso resiste una auditoría. El siguiente tema de este dominio deja atrás la seguridad y plantea una pregunta distinta: una vez que un sistema es seguro, ¿cómo se mantiene funcionando?