Seguridad, identidad y cumplimiento normativo en la nube

La seguridad en la nube distribuye el trabajo entre el proveedor y el cliente. Asigna las tareas según la capa que administra cada parte, incluidos los ajustes que elige el cliente.

Separa la infraestructura de las decisiones del cliente

AWS llama seguridad de la nube a la protección de la infraestructura. Abarca las instalaciones, los servidores físicos, el almacenamiento, los equipos de red y el hipervisor que separa las máquinas virtuales en un host. Los clientes se encargan de la seguridad en la nube: sus datos, identidades y configuración. Azure y Google Cloud usan la misma distribución básica. El enfoque de destino compartido de Google añade valores predeterminados seguros, orientación y herramientas para ayudar a los clientes a proteger su parte.

Los proveedores controlan el acceso físico, la alimentación eléctrica, la refrigeración, el mantenimiento del hardware y la retirada segura de las unidades. Auditores independientes examinan estas capas; los clientes usan sus informes para evaluar controles que no aplican por sí mismos.

Mantén asignadas las responsabilidades del cliente

En todos los modelos de servicio, el cliente conserva la responsabilidad de:

• Datos: clasificación, acceso, decisiones de protección y retención.
• Cuentas: creación, mantenimiento y eliminación de identidades.
• Gestión de acceso: roles, MFA y políticas de inicio de sesión.
• Dispositivos cliente: protección de los portátiles y teléfonos usados para conectarse.

Los ajustes elegidos por el cliente siguen siendo responsabilidad suya. Un contenedor público, una regla que expone una base de datos a internet o una cuenta de administrador abandonada pueden exponer una carga de trabajo aunque los controles de infraestructura del proveedor funcionen correctamente.

Algunos controles son compartidos porque cada parte los aplica en sus propias capas. El proveedor aplica parches a la infraestructura; los clientes aplican parches a los sistemas operativos y las aplicaciones que administran. Cada parte configura sus propios sistemas y forma a su propio personal. Asigna las tareas de ambas partes de un control compartido para que ninguna quede desatendida.

Aplica la distribución al almacenamiento de facturas

Una empresa almacena facturas en un contenedor en la nube. El proveedor aplica parches al servicio de almacenamiento, sustituye las unidades averiadas y retira los discos de forma segura. La empresa hace privado el contenedor, concede a su rol de facturación el acceso de lectura necesario y exige MFA a esos usuarios. También selecciona la configuración de cifrado, activa los registros de acceso necesarios y elige cuánto tiempo se conservan las facturas.

Si un empleado hace público el contenedor, el cliente debe corregir el permiso e investigar la exposición. El servicio de almacenamiento puede devolver contenido legible a una solicitud que el cliente haya permitido; la protección física no puede anular esa concesión de acceso.

La infraestructura en la nube y las herramientas especializadas de seguridad pueden ofrecer a un equipo pequeño protecciones que no podría desarrollar por sí solo. Las funciones opcionales siguen necesitando una persona responsable de configurarlas y revisar sus hallazgos. Consulta la documentación sobre responsabilidades de cada servicio al asignar esas tareas.

Los servicios más administrados transfieren más trabajo operativo al proveedor. Las decisiones del cliente sobre identidades, datos y configuración siguen siendo necesarias pese a esos cambios.

Compara las capas

Las responsabilidades de aplicaciones y red pueden compartirse en PaaS. Los clientes de SaaS configuran las funciones de la aplicación aunque el proveedor administre el servicio; la gestión de dispositivos también puede ser compartida. Consulta cada servicio y función para conocer el límite preciso.

Examina los servicios

Para un servidor web en Amazon EC2, Azure Virtual Machines o Google Compute Engine, el cliente instala las actualizaciones de seguridad del sistema operativo invitado y mantiene el servidor web. Restringe la administración remota mediante grupos de seguridad de AWS, grupos de seguridad de red de Azure o reglas de cortafuegos de Google Cloud, y elige la protección de disco y las copias de seguridad.

Con Amazon RDS, Azure SQL Database o Google Cloud SQL, el proveedor mantiene el sistema operativo subyacente y el motor administrado. El cliente sigue seleccionando las rutas de red permitidas, los usuarios, los permisos, la configuración de cifrado, la retención de copias de seguridad y las ventanas de mantenimiento disponibles. La capacidad de hacer copias de seguridad automatizadas no decide cuánto tiempo necesita la empresa conservar sus registros.

Para AWS Lambda, Azure Functions o Google Cloud Run functions, los entornos de ejecución administrados por el proveedor eliminan de la lista del cliente la aplicación de parches a servidores y entornos de ejecución. Los clientes siguen actualizando las dependencias incluidas, validando las entradas, protegiendo los secretos y restringiendo los permisos de ejecución e invocación. Los entornos de ejecución personalizados o los contenedores conllevan responsabilidades adicionales de mantenimiento.

En Microsoft 365 o Google Workspace, el proveedor aplica parches a la aplicación ofimática. Los clientes eliminan las cuentas de los empleados que se marchan, controlan el uso compartido externo y establecen la retención. Algunas organizaciones también mantienen sus propias copias de seguridad de SaaS.

Asigna una tarea desconocida

Identifica la capa y el modelo de servicio, y después consulta la distribución documentada. Un disco físico averiado es responsabilidad del proveedor en todos los modelos. Una actualización del sistema operativo invitado de una máquina virtual es responsabilidad del cliente; una actualización del sistema operativo que sustenta una base de datos administrada corresponde al proveedor. El permiso de un usuario de la base de datos sigue siendo una decisión del cliente. Mantén una lista de tareas por servicio cuando una organización use varios modelos a la vez.

El acceso a la nube comienza identificando a una persona o aplicación. Después comprueba los permisos de esa identidad. Mantener separadas estas decisiones ayuda a explicar por qué un inicio de sesión correcto puede terminar en un mensaje de acceso denegado.

Demuestra la identidad y comprueba el permiso

La autenticación establece quién o qué realiza una solicitud. La autorización decide si esa identidad puede realizar la acción solicitada. La auditoría registra lo ocurrido. Una contraseña y la MFA pueden autenticar a un usuario; aun así, un rol puede denegarle el permiso para eliminar una base de datos.

En Azure y Google Cloud, las asignaciones de roles vinculan a personas, grupos o cargas de trabajo con permisos. En AWS, asumir un rol de IAM genera credenciales temporales de sesión. Una carga de trabajo debe usar ese mecanismo de identidad compatible en lugar de copiar la contraseña de una persona en un archivo de configuración.

Reconoce los nombres de los proveedores

AWS IAM proporciona usuarios, grupos y roles. IAM Identity Center admite el acceso del personal a varias cuentas de AWS. Microsoft Entra ID, antes Azure Active Directory, es el directorio en la nube de Azure, con usuarios, grupos, entidades de servicio e identidades administradas. Google Cloud usa cuentas y grupos en Cloud Identity o Google Workspace, además de cuentas de servicio para cargas de trabajo.

Una instancia de EC2 puede recibir un rol de IAM, un recurso de Azure una identidad administrada y una máquina virtual de Google Cloud una cuenta de servicio asociada. La plataforma proporciona credenciales de corta duración para el acceso compatible, lo que evita almacenar una contraseña de larga duración.

El usuario raíz de AWS tiene poder sobre toda la cuenta. Azure y Google Cloud distribuyen el acceso con privilegios elevados mediante roles como Global Administrator de Entra, Owner de suscripción y Owner de proyecto. Estos roles tienen ámbitos diferentes: el rol de administrador de directorio no es intercambiable con el de administrador de recursos.

Inicia sesión de forma centralizada

El inicio de sesión único (SSO) permite a una persona usar un solo inicio de sesión en varias aplicaciones. La federación de identidades es la relación de confianza que permite a una nube o aplicación aceptar información de identidad de otro proveedor de identidad, normalmente mediante SAML 2.0 u OpenID Connect.

Una empresa usa Entra ID para 200 empleados y federa el acceso a AWS y Google Cloud. Cuando un ingeniero se marcha, desactivar la cuenta central impide nuevos inicios de sesión. La empresa también debe revocar las sesiones activas y eliminar las cuentas locales independientes y las claves de acceso. Esas vías pueden seguir funcionando sin un nuevo inicio de sesión central.

Los socios pueden usar identidades externas: acceso de invitado de Entra B2B, un rol entre cuentas de AWS o roles de Google Cloud concedidos a entidades principales externas. Su empleador administra su identidad de origen; tu organización controla su acceso a tus recursos.

Las aplicaciones antiguas pueden necesitar unión al dominio, Kerberos, NTLM o LDAP. Las ofertas de directorios administrados incluyen Entra Domain Services, AWS Directory Service y Google Cloud Managed Service for Microsoft Active Directory. Estas satisfacen necesidades de aplicaciones diferentes de las que cubre por sí solo un inicio de sesión moderno en la nube.

Un permiso relaciona una acción con un recurso. «Leer objetos de este contenedor» es más preciso que «usar almacenamiento». Los proveedores agrupan permisos en roles o instrucciones de políticas y después los asocian a identidades o recursos.

Relaciona quién, qué y dónde

El control de acceso basado en roles (RBAC) asigna permisos mediante roles laborales. Una asignación de rol de Azure tiene tres partes: la entidad de seguridad, la definición del rol y el ámbito. Los ámbitos van desde el grupo de administración hasta la suscripción, el grupo de recursos y el recurso individual. Las asignaciones se heredan a los recursos incluidos en su ámbito.

Priya tiene Reader en la suscripción Prod y Contributor en su grupo de recursos web-rg. Puede ver los recursos de toda la suscripción Prod y modificar los de web-rg. No puede modificar db-rg ni conceder acceso a otra persona mediante Contributor. Los permisos de Azure se suman entre asignaciones; las funciones compatibles de Azure pueden crear asignaciones de denegación que bloquean acciones que de otro modo estarían permitidas.

Las políticas de autorización de Google Cloud vinculan entidades principales con roles en los recursos. El acceso se hereda a través de la organización, las carpetas, los proyectos y los recursos. Los amplios roles básicos Owner, Editor y Viewer deben sustituirse por roles predefinidos o personalizados adecuados para cada servicio. Modificar la política de autorización de un elemento secundario no elimina el acceso concedido en su elemento principal. Cambia la concesión en el elemento principal o aplica una política de denegación compatible cuando corresponda.

Evalúa una solicitud de AWS

Una política de AWS IAM es un documento JSON que contiene instrucciones con un Effect, una Action, un ARN de Resource y condiciones opcionales. Las políticas pueden asociarse a identidades; una política de recursos, como una política de contenedor, se asocia al recurso. Las políticas administradas por AWS las mantiene el proveedor, las políticas administradas por el cliente son documentos reutilizables del cliente y las políticas en línea pertenecen a una sola identidad.

Para tomar una decisión básica sobre una solicitud:

1. Empieza con una denegación implícita: todavía no hay ningún permiso.
2. Busca una autorización explícita aplicable y comprueba todos los límites de permisos aplicables.
3. Aplica cualquier denegación explícita: prevalece sobre las autorizaciones.

Una política de control de servicios (SCP) de AWS Organizations limita los permisos máximos disponibles. No concede permisos por sí misma. Una solicitud fuera del límite permitido por la SCP falla aunque una política de identidad la autorice.

El grupo de Lena puede leer sales-reports/* y ningún control de protección restringe esa lectura. Una descarga está permitida. Una carga falla porque no existe una autorización para s3:PutObject. Otra política deniega explícitamente la eliminación; añadir s3:* más tarde sigue sin poder autorizarla. La lectura de un contenedor no relacionado tampoco tiene una autorización.

Separa la administración de recursos del acceso a datos

Un administrador puede administrar una cuenta de almacenamiento mediante el plano de control sin recibir un rol de datos de Entra para leer sus blobs a través del plano de datos. Para esa lectura se necesita un rol como Storage Blob Data Reader. Comprueba la acción y el ámbito en lugar de suponer que un título de administración de recursos con privilegios elevados resuelve todas las cuestiones de acceso a datos.

El mínimo privilegio concede a una identidad las acciones, los recursos y el tiempo que necesita para su tarea. Reduce el radio de impacto: el daño que puede causar un error o una credencial robada.

Crea una concesión ajustada

Primero enumera el trabajo, elige un rol o una política limitados, establece el ámbito útil más reducido y administra a las personas mediante grupos o roles. Limita en el tiempo el acceso con privilegios elevados y revísalo periódicamente. Un contratista que carga registros en un contenedor durante 30 días necesita acceso de carga en ese contenedor, no acceso de lectura a todo el almacenamiento ni una identidad permanente de administrador.

El acceso justo a tiempo limita cuándo puede una persona obtener permisos elevados. Entra Privileged Identity Management puede exigir aprobación y MFA para una activación de duración limitada. Google Privileged Access Manager proporciona concesiones temporales de roles previa solicitud. Los roles de AWS emiten credenciales de duración limitada mediante Security Token Service, pero un derecho permanente a asumir un rol de administrador permite iniciar nuevas sesiones repetidamente. Las credenciales de corta duración por sí solas no eliminan el privilegio permanente.

La segregación de funciones concede a distintas personas el control de las partes sensibles de un proceso. Quien solicita un cambio y quien lo aprueba deben ser personas distintas; la administración de claves y la lectura de datos también deben separarse.

Protege las identidades con privilegios elevados

Activa la MFA para el usuario raíz de AWS, asígnale una contraseña segura y única y no crees claves de acceso raíz. Úsalo solo para tareas que lo requieran. Algunos ejemplos son cambiar su propio correo electrónico o contraseña, cerrar una cuenta independiente, recuperar el acceso tras el bloqueo de un administrador de IAM, activar el acceso de IAM a facturación, registrarse como vendedor en EC2 Reserved Instance Marketplace y activar la eliminación con MFA en S3. Las organizaciones pueden eliminar de forma centralizada las credenciales raíz de las cuentas miembro.

Mantén estrictamente limitados los roles con privilegios elevados de Entra y Google Cloud. Microsoft recomienda menos de cinco Global Administrators. Los administradores necesitan identidades separadas para el uso diario y el uso con privilegios elevados, así como MFA resistente al phishing. La planificación del acceso de emergencia de Entra usa dos cuentas de emergencia almacenadas de forma segura y supervisadas, para que un fallo del inicio de sesión normal no deje a todos sin acceso; el diseño de estas cuentas sigue las instrucciones del propio proveedor.

Prefiere el acceso de corta duración y los secretos administrados

Las claves de acceso de larga duración siguen siendo utilizables hasta que se desactivan o eliminan. Da preferencia a las identidades de cargas de trabajo, los roles y el SSO. Rota las claves inevitables y mantenlas fuera del código fuente. Si una clave se filtra, elimina su acceso; borrar un fragmento de código visible no revoca la credencial.

Almacena las contraseñas de bases de datos, las claves de API y los certificados en AWS Secrets Manager o Systems Manager Parameter Store, Azure Key Vault o Google Cloud Secret Manager. Las aplicaciones obtienen los secretos necesarios durante la ejecución mediante identidades de cargas de trabajo. Configura la recopilación de auditoría cuando sea necesario, por ejemplo, mediante la configuración de diagnóstico de Azure Key Vault.

Para las contraseñas restantes, la guía del NIST de 2025 exige al menos 15 caracteres cuando se usa un solo factor, o al menos 8 como parte de la MFA, y admitir al menos 64 caracteres. Pide comprobarlas frente a contraseñas comunes y filtradas, rechaza las combinaciones obligatorias de tipos de caracteres y los cambios periódicos programados, y exige cambiarlas cuando se sospecha que han sido comprometidas.

Usa evidencias para reducir el acceso: AWS IAM Access Analyzer, informes de credenciales y datos de último acceso; revisiones de acceso de Entra; y recomendaciones de roles de IAM de Google. Si un rol permite usar 40 servicios pero solo se usaron 3 en 90 días, revisa los permisos de los otros 37 servicios. Comprueba las próximas tareas legítimas antes de eliminarlos; la inactividad identifica candidatos, pero no ofrece una visión completa de las necesidades de la empresa.

La autenticación multifactor (MFA) requiere al menos dos categorías diferentes de factores: algo que una persona sabe, tiene o es. Una contraseña y una respuesta de seguridad son factores de conocimiento y siguen constituyendo una autenticación de un solo factor.

Compara los métodos de autenticación

El NIST restringe el envío por la red telefónica. Una configuración habitual de TOTP usa seis dígitos que cambian cada 30 segundos: un millón de valores posibles da a un único intento al azar una probabilidad de uno entre un millón. Las implementaciones pueden usar otras longitudes o intervalos.

Una página de phishing puede enviar una contraseña y un código recién generado al sitio real antes de que caduque. La prueba de una clave de acceso sin contraseña vinculada al dominio no puede ser reutilizada por el dominio falso para el servicio real. Windows Hello for Business y los métodos compatibles basados en certificados también ofrecen opciones resistentes al phishing.

Un ataque de fatiga de autenticación multifactor envía solicitudes de aprobación repetidas con la esperanza de que alguien acepte. La coincidencia de números vincula la aprobación a una pantalla de inicio de sesión, lo que reduce la aceptación accidental; no proporciona la misma vinculación al dominio que un método resistente al phishing.

Comprueba los factores en el inicio de sesión sin contraseña

El inicio de sesión sin contraseña elimina la contraseña. Una credencial almacenada en un dispositivo y desbloqueada mediante un PIN o un dato biométrico verificado combina la posesión con un segundo factor. El PIN se comprueba localmente y no se envía al servicio. Comprueba qué factores verifica el método concreto antes de clasificarlo como MFA. Google llama a su servicio de MFA verificación en 2 pasos.

Los proveedores exigen MFA para algunos accesos administrativos, incluidos el usuario raíz de AWS y el inicio de sesión en el portal de Azure. Los clientes siguen estableciendo los requisitos para sus propios usuarios y aplicaciones, con los métodos más sólidos para el acceso con privilegios elevados.

Aplica el contexto y protege la recuperación

Entra Conditional Access evalúa el usuario, la aplicación, el estado del dispositivo, la ubicación y el riesgo del inicio de sesión. Puede permitir el acceso, exigir una autenticación más sólida o un dispositivo que cumpla los requisitos, o bloquearlo. Para las nóminas, exige un dispositivo administrado y una autenticación resistente al phishing; bloquea los inicios de sesión de alto riesgo. Las condiciones de AWS IAM y el acceso basado en el contexto de Google ofrecen controles relacionados con un comportamiento distinto según el servicio.

Protege la recuperación de cuentas con un cuidado similar: una vía de recuperación débil puede sustituir a un método de autenticación sólido. Rechaza las solicitudes de aprobación inesperadas e infórmalas mediante el proceso de la organización. El mínimo privilegio y la supervisión siguen limitando el riesgo si se roba una sesión autenticada.

El cifrado transforma texto en claro legible en texto cifrado mediante una clave. La clave correcta permite descifrarlo. Protege la confidencialidad; el cifrado autenticado también detecta manipulaciones. No impide una eliminación autorizada ni mantiene en funcionamiento una aplicación que ha fallado.

Distingue tres transformaciones

Cualquiera puede decodificar texto Base64 como «aGVsbG8=» y obtener «hello». No ofrece confidencialidad. El almacenamiento de contraseñas necesita una función de resumen de contraseñas con sal y deliberadamente lenta, como Argon2, bcrypt, scrypt o PBKDF2. Un único resumen rápido SHA-256 no es adecuado para esa tarea.

El cifrado simétrico usa la misma clave para cifrar y descifrar. AES-256 es habitual para grandes volúmenes de datos en la nube. La criptografía asimétrica usa un par de claves pública y privada para operaciones como el intercambio de claves y las firmas digitales; las operaciones compatibles dependen del algoritmo. El cifrado con clave pública permite a un remitente proteger datos para un destinatario que los descifra con su clave privada. Una firma digital permite a otras personas comprobar una firma creada con la clave privada.

Una clave simétrica de 256 bits tiene $2^{256}\approx \mathrm{1,16}\times {10}^{77}$ valores posibles. Incluso probando ${10}^{18}$ posibilidades por segundo, comprobarlas todas lleva unos $\mathrm{3,7}\times {10}^{51}$ años. En la práctica, proteger el acceso a las claves importa mucho más que planear cómo superar ese espacio de búsqueda.

Aplica el cifrado a los datos almacenados

Los datos en reposo incluyen objetos, discos, bases de datos, copias de seguridad e instantáneas. El cifrado protege el contenido almacenado sin procesar si alguien obtiene una unidad o copia el almacenamiento sin la clave necesaria. El cifrado del lado del servidor se realiza dentro del servicio antes de escribir los datos. El cifrado del lado del cliente se realiza antes de la carga y deja al proveedor solo el texto cifrado. Perder una clave de cliente que no se puede sustituir hace que el contenido resulte ilegible.

La configuración predeterminada varía según el servicio. Amazon S3 cifra de forma predeterminada todas las cargas de objetos nuevos desde el 5 de enero de 2023. Azure Storage cifra los datos almacenados y esto no se puede desactivar. Google Cloud cifra de forma predeterminada los datos de clientes en reposo. El cifrado predeterminado de Amazon EBS es una opción de cuenta que el cliente activa en cada región.

Sigue una lectura autorizada

Un objeto de factura está cifrado en disco. Un usuario lo solicita mediante el servicio de almacenamiento. El servicio comprueba los permisos, descifra el objeto mediante su mecanismo de claves configurado y devuelve contenido legible al usuario autorizado. Si el cliente concede lectura pública, ese proceso también puede atender a personas externas.

Por tanto, el cifrado en reposo funciona junto con la configuración de acceso privado y el registro de actividad. Empieza con la clasificación de datos: públicos, internos, confidenciales o restringidos. La clasificación orienta quién puede leer el contenido, los requisitos de control de claves y la retención. Las copias de seguridad necesitan la misma atención porque una base de datos protegida aún puede tener una copia expuesta.

Un registro puede estar cifrado en el almacenamiento y aun así quedar expuesto mientras cruza una red o se procesa. Sigue su recorrido para identificar dónde se necesita cada protección.

Cifra los datos en movimiento con TLS

Los datos en tránsito se desplazan entre navegadores, aplicaciones, bases de datos, oficinas o regiones. La seguridad de la capa de transporte (TLS) protege una conexión frente a la lectura y la modificación, y autentica el servidor mediante un certificado. HTTPS es HTTP transportado sobre TLS, normalmente en el puerto 443. Usa configuraciones compatibles de TLS 1.2 o 1.3; SSL y TLS 1.0 y 1.1 están obsoletos.

Un certificado digital asocia un dominio con una clave pública. Una autoridad de certificación de confianza lo firma para que el navegador pueda comprobar la asociación. Los servicios de certificados incluyen AWS Certificate Manager, las funciones de certificados de Azure Key Vault o App Service y Google Cloud Certificate Manager. La renovación administrada reduce el riesgo de caducidad cuando es compatible y está configurada. Un certificado caducado puede interrumpir conexiones y un servicio.

Una conexión HTTPS válida confirma la protección hasta ese dominio. Un sitio de phishing también puede tener un certificado válido para su propio dominio, por lo que el candado por sí solo no indica si esa empresa o página merece confianza.

Sigue una solicitud del navegador

1. El navegador establece una conexión HTTPS con un equilibrador de carga y comprueba su certificado.
2. El equilibrador de carga termina esa conexión TLS y ve la solicitud en texto en claro.
3. Una conexión TLS independiente protege el siguiente salto hasta un servidor de aplicaciones.
4. La aplicación usa una conexión cifrada con la base de datos, configurada para exigirla.

El HTTPS de entrada solo protege su propia conexión. Comprueba cada salto posterior. Una política de S3 puede denegar solicitudes cuando aws:SecureTransport es falso; Azure Storage ofrece la opción de exigir transferencia segura; Cloud SQL puede exigir TLS. Las redes internas también necesitan protección del tráfico porque un atacante puede haber accedido ya a ellas.

Distingue una ruta privada del cifrado

Una VPN IPsec de sitio a sitio cifra el tráfico entre una red de oficina y una red en la nube a través de internet. Los servicios incluyen AWS Site-to-Site VPN, Azure VPN Gateway y Google Cloud VPN.

Los enlaces dedicados (AWS Direct Connect, Azure ExpressRoute y Google Cloud Interconnect) evitan el internet público, pero su ruta privada por sí sola no proporciona cifrado de extremo a extremo predeterminado. Usa protección adecuada mediante TLS, IPsec o MACsec compatible cuando sea necesario. MACsec protege el segmento de enlace compatible; comprueba también la protección de la ruta completa de la aplicación.

Protege los datos durante el procesamiento

Los datos durante su procesamiento se están procesando, a menudo en memoria descifrada. La computación confidencial añade aislamiento respaldado por hardware, con cifrado de memoria en las tecnologías compatibles. Las máquinas virtuales confidenciales de Azure y Google cifran la memoria mediante claves conservadas en el procesador. AWS Nitro Enclaves aísla la memoria y las CPU de la instancia principal y sus administradores.

Para el historial de un paciente, el cifrado de la base de datos protege el almacenamiento, TLS protege su entrega a un médico y una máquina virtual confidencial puede proteger una tarea de análisis sensible mientras se ejecuta. Estos controles cubren exposiciones diferentes. La aplicación sigue necesitando permiso para procesar el historial y continúa siendo responsable de lo que genera.

Quién controla las claves afecta tanto al control de seguridad como al riesgo operativo. Un cliente que obtiene la capacidad de desactivar una clave también obtiene una forma de interrumpir todos los servicios que dependen de ella.

Compara las opciones de control

Los servicios de claves en la nube incluyen AWS KMS, Azure Key Vault y Google Cloud KMS. Controlan las operaciones criptográficas y pueden registrar el uso de las claves. Activa los registros necesarios, incluidas las opciones de diagnóstico de Azure y el registro de auditoría Data Access de Google Cloud KMS.

Los ejemplos de claves proporcionadas por el cliente incluyen los flujos compatibles de Amazon S3 SSE-C y Google CSEK. Las opciones externas incluyen los almacenes de claves externas de AWS KMS y Google Cloud External Key Manager. Estas funciones dependen del servicio; el servicio de datos elegido debe admitir la opción.

Un módulo de seguridad de hardware (HSM) protege las claves en hardware especializado. AWS CloudHSM, Azure Managed HSM y Google Cloud HSM ofrecen protección mediante hardware. HSM describe cómo se protegen las claves; el control del proveedor, del cliente o externo describe quién gobierna su uso. Son decisiones diferentes.

Comprende el cifrado de sobre

El almacenamiento en la nube suele cifrar grandes volúmenes de contenido con una clave de datos. Después cifra esa clave más pequeña con una clave de cifrado de claves conservada en un servicio de claves. La clave de datos cifrada puede almacenarse junto al texto cifrado. Esto es el cifrado de sobre: no es necesario enviar grandes volúmenes de datos a KMS para cada operación criptográfica.

Para leer el contenido, el servicio necesita permiso para descifrar la clave de datos. Desactivar la clave que la protege bloquea esa vía. La destrucción permanente de la clave puede hacer ilegibles todos los datos que dependen de ella, incluidas las copias de seguridad antiguas.

Examina la elección de un hospital

Un hospital elige una clave de KMS administrada por el cliente de AWS para sus imágenes médicas. El rol de su aplicación puede descifrar; el equipo de seguridad administra la clave sin permiso habitual para leer las imágenes. Esto separa el uso de los datos de la administración de claves. Las evidencias de auditoría deben mostrar los permisos previstos y el uso de la clave.

La clave rota cada año. La rotación proporciona nuevo material para el cifrado futuro y conserva las versiones anteriores necesarias para leer el contenido existente. No significa que todas las imágenes antiguas se vuelvan a cifrar inmediatamente.

Al terminar el servicio, el hospital comprueba todos los datos restantes y las dependencias de las copias de seguridad antes de programar la eliminación de la clave. AWS KMS usa un período de espera de 7 a 30 días. Tras la eliminación, el texto cifrado que depende de ella no puede recuperarse mediante esa clave. Destruir el acceso mediante la destrucción de la clave es el borrado criptográfico.

Ajusta el control a un requisito

Elige claves administradas por el cliente o externas cuando un contrato, una norma, un requisito de revocación, un requisito de auditoría o la segregación de funciones exijan ese control. El mismo algoritmo de cifrado puede proteger los datos en cualquiera de estos modelos de gestión. El control adicional de las claves cambia la responsabilidad, la planificación de la disponibilidad y las evidencias; no hace que AES sea matemáticamente más sólido.

La defensa en profundidad combina controles independientes. Si uno falla, otro puede bloquear la siguiente acción, limitar el daño o revelar el ataque.

Sitúa los controles en capas

La visión de siete capas de Microsoft va desde la seguridad física, pasando por identidad y acceso, perímetro, red, cómputo y aplicación, hasta los datos en el centro.

La asignación de responsabilidades sigue el modelo compartido. Los proveedores aplican los controles físicos; los clientes controlan las identidades y los datos. Quién mantiene el cómputo depende de si se trata de una máquina virtual del cliente o de una plataforma administrada.

Sigue una toma de cuenta

Un atacante obtiene la contraseña de un desarrollador de una tienda. La MFA puede bloquear un nuevo inicio de sesión. Supongamos que el atacante roba una sesión ya autenticada. Los siguientes controles deben ocuparse de lo que esa sesión puede hacer.

El rol del desarrollador permite leer registros, pero no consultar la base de datos, por lo que la autorización rechaza una solicitud directa de datos de clientes. Las reglas de red restringen por separado las conexiones a la base de datos a la ruta permitida de la aplicación. La supervisión puede detectar actividad inusual. Las copias de seguridad protegidas permiten la recuperación si un atacante obtiene más tarde acceso para realizar acciones destructivas.

El cifrado de disco protege el almacenamiento sin procesar cuando no se tiene la clave. No bloquearía el contenido legible devuelto a una identidad comprometida con permisos legítimos de lectura y descifrado. Evalúa la ruta real antes de atribuir a un control la capacidad de detenerla.

Combina el bloqueo con la detección

Un control preventivo detiene una solicitud, como la creación de almacenamiento público. Un control de detección informa de un evento o una condición, como actividad inusual o acceso excesivo. Asigna una respuesta que investigue, contenga y corrija lo detectado.

Dos cortafuegos con la misma regla incorrecta pueden fallar a la vez. Una comprobación de identidad independiente, la validación de la aplicación y un rol de datos limitado abordan diferentes pasos del ataque. Sigue una solicitud desde el usuario hasta los datos, identifica los controles a lo largo de esa ruta y asigna responsables para su configuración y sus alertas.

La confianza cero no concede autorización automática según la ubicación en la red. Una dirección interna no establece el permiso para usar una aplicación o leer sus datos.

Aplica tres principios

Verifica explícitamente: evalúa la identidad y el contexto, incluidos el estado del dispositivo, la ubicación, el servicio solicitado, la sensibilidad de los datos y el comportamiento inusual.

Usa el mínimo privilegio: concede solo el acceso necesario para la tarea, con elevación de privilegios por tiempo limitado cuando sea necesario. Un usuario autenticado sigue necesitando permiso para la acción.

Asume una vulneración de seguridad: restringe el movimiento, cifra el tráfico y supervisa la actividad para que una identidad o un dispositivo comprometidos no puedan acceder libremente a todo.

NIST SP 800-207 describe el enfoque de arquitectura. Microsoft lo expresa mediante estos tres principios. Las organizaciones implementan la estrategia mediante controles coordinados y pueden adoptarla paso a paso.

Cambia el límite de acceso

Un modelo de perímetro tradicional tiende a confiar en los dispositivos después de que entran en la red. Una conexión VPN amplia puede permitir entonces que un portátil infectado acceda a muchos sistemas. El trabajo remoto, SaaS y la multinube hacen que la ubicación por sí sola sea un límite de acceso poco fiable.

Un proxy basado en la identidad evalúa el acceso a una aplicación concreta. Google Identity-Aware Proxy, AWS Verified Access y Microsoft Entra Private Access proporcionan capacidades relacionadas. El enfoque BeyondCorp de Google es un ejemplo de sustitución de la confianza automática en la red interna por un acceso evaluado.

La segmentación y los cortafuegos siguen limitando el alcance después de que falle otro control. Cifra también las conexiones internas: un atacante puede estar ya dentro del entorno.

Evalúa la solicitud de una enfermera

Una enfermera solicita desde casa acceso a la aplicación de planificación de turnos del personal. Un servicio de acceso verifica su identidad mediante autenticación resistente al phishing, comprueba que el portátil esté administrado y actualizado y confirma que tiene el rol de planificación. Le concede una sesión para esa aplicación.

Una solicitud de acceso a nóminas requiere su propia decisión de permisos. La sesión de planificación no concede acceso a nóminas. Si más tarde la supervisión detecta que el portátil está infectado, una política puede bloquear o revocar el acceso afectado. La autenticación de la mañana no resuelve la cuestión del estado del dispositivo por la tarde.

Los servicios de identidad establecen quién realiza la solicitud; las comprobaciones de dispositivos y el acceso condicional evalúan el contexto. Los roles restringen las acciones, los proxies y segmentos restringen el alcance y TLS protege las conexiones. La supervisión proporciona nuevas evidencias para decisiones posteriores. Al comprar un solo producto, la organización sigue teniendo que establecer estas reglas de acceso y decisiones de respuesta.

Empieza por la función que debe cumplir el control. Los principales proveedores ofrecen categorías de seguridad que se solapan, y un solo producto puede proporcionar varios tipos de hallazgos. Una debilidad de software detectada requiere una respuesta diferente de una inundación de tráfico.

Bloquea inundaciones y ataques web

La protección contra DDoS aborda el tráfico destinado a saturar un servicio. AWS Shield Standard proporciona protección básica automática; Shield Advanced añade capacidades de pago y soporte de respuesta. Azure ofrece protección de infraestructura predeterminada con niveles de pago de Azure DDoS Protection. Google Cloud Armor protege las aplicaciones compatibles situadas detrás de equilibradores de carga.

Un cortafuegos de aplicaciones web (WAF) inspecciona las solicitudes web en busca de ataques como la inyección SQL, las secuencias de comandos entre sitios y los bots abusivos. AWS WAF, Azure Web Application Firewall y las políticas de seguridad de Cloud Armor ofrecen esta categoría. Pueden filtrar solicitudes de aplicaciones o limitar su frecuencia. Un cortafuegos de red controla el tráfico de red en otro nivel: AWS Network Firewall, Azure Firewall y Google Cloud Next Generation Firewall son ejemplos. AWS Firewall Manager ayuda a aplicar las protecciones compatibles en varias cuentas.

Detecta amenazas y debilidades conocidas

La detección de amenazas examina la actividad en busca de indicios de que se haya producido una vulneración. Una máquina virtual que se comunica con un servicio de minería conocido es una señal de alerta sobre su comportamiento. GuardDuty analiza fuentes que incluyen información de API, flujo de red y DNS. Una plataforma SIEM, como Microsoft Sentinel o Google Security Operations, reúne eventos de seguridad de muchas fuentes para su análisis e investigación.

La gestión de vulnerabilidades identifica debilidades conocidas en el software instalado o en las imágenes. Inspector evalúa las cargas de trabajo compatibles de EC2, contenedores y Lambda. Un paquete vulnerable puede existir antes de observar cualquier actividad de un atacante; su detección debe conducir a una actualización u otra medida de mitigación adecuada.

La gestión de la postura de seguridad en la nube (CSPM) comprueba la configuración frente a prácticas y estándares. Un recurso de almacenamiento accesible públicamente es un problema de postura aunque no se haya detectado ningún acceso malicioso. AWS Security Hub reúne los hallazgos; Security Hub CSPM proporciona controles de configuración. Defender for Cloud y Security Command Center también ofrecen evaluación de la postura.

Busca datos sensibles y actúa sobre los hallazgos

Macie puede localizar contenido sensible en S3. Purview detecta, clasifica y etiqueta los datos de la organización. Google Sensitive Data Protection puede detectar, clasificar y desidentificar contenido sensible. Encontrar números de pasaporte en una exportación olvidada indica al equipo dónde se necesitan controles más sólidos de acceso o retención; la detección por sí sola no cambia todos los permisos.

Para un servicio en línea, relaciona el síntoma con la categoría. Usa protección contra DDoS para una inundación, un WAF para entradas web maliciosas, evaluación de vulnerabilidades para una biblioteca desactualizada, detección de amenazas para actividad sospechosa durante la ejecución y CSPM para ajustes arriesgados de recursos. Pueden necesitarse varios a la vez.

AWS Trusted Advisor, Azure Advisor y Google Recommender proporcionan recomendaciones adicionales; las comprobaciones disponibles y los planes de pago varían. Los mercados de los proveedores ofrecen productos de terceros. La documentación oficial de seguridad, los centros de respuesta, los blogs y los boletines ayudan a los equipos a mantenerse al día. Asigna responsables a los hallazgos y activa los planes de servicio pertinentes: un panel lleno de alertas sin revisar deja la exposición subyacente sin resolver.

Los registros responden preguntas sobre eventos; la supervisión convierte las observaciones en acciones. Contar con buenas evidencias depende de recopilar pronto los eventos adecuados, conservarlos durante suficiente tiempo y protegerlos frente a modificaciones.

Elige la evidencia según la pregunta

Los registros de auditoría o actividad muestran quién realizó acciones en la consola o la API. El historial de configuración muestra cómo cambiaron los ajustes de un recurso. Las métricas miden el estado y el rendimiento. Los registros de acceso a datos registran los accesos pertinentes al contenido y los registros de flujo de red describen los flujos de tráfico.

El historial de eventos de CloudTrail conserva los últimos 90 días de eventos de administración por región. Crea un registro de seguimiento para entregar los registros a S3 y conservarlos durante más tiempo, y opcionalmente también a CloudWatch Logs. Las métricas de rendimiento de CloudWatch son una evidencia diferente del registro de CloudTrail sobre quién cambió una política.

El registro de actividad de Azure también conserva 90 días de forma predeterminada. La configuración de diagnóstico puede enviar los registros a almacenamiento, Log Analytics o Event Hubs. Los registros Admin Activity de Google están siempre activados y no se pueden desactivar. Los registros Data Access deben activarse para la mayoría de los servicios; BigQuery tiene valores predeterminados importantes que difieren. Los registros de acceso de Key Vault y la actividad de datos de Google KMS también necesitan las opciones de recopilación pertinentes.

Conserva las evidencias antes de necesitarlas para una investigación

Un contenedor se hace público el 2 de marzo de 2026. La investigación comienza el 1 de julio, 121 días después. El evento queda fuera del período predeterminado de 90 días. Una exportación configurada previamente puede conservar quién cambió el ajuste, cuándo y desde qué dirección IP; activar ahora una exportación no puede recrear un registro que ya ha caducado.

El historial de configuración puede mostrar el ajuste anterior y posterior al evento. Usa ambos registros para comprender el cambio, revertir la exposición e investigar el acceso a los datos mediante los registros pertinentes que estén activados. Un evento de administración por sí solo no es una lista completa de los archivos leídos.

Evita cambios y detecta excepciones

Los controles de protección preventivos bloquean una acción no permitida: Azure Policy Deny, las restricciones compatibles de SCP y las restricciones de organización de Google son ejemplos. Los controles de protección de detección identifican una condición después de que ocurra: reglas de AWS Config, Azure Policy Audit y hallazgos de postura.

Una política de ubicación puede bloquear recursos nuevos en regiones no permitidas. Una comprobación de configuración puede informar de recursos que infringen una regla. Esta última necesita una respuesta y no revierte un cambio por el mero hecho de emitir un hallazgo.

Restringe el acceso a los registros, recopila evidencias en una cuenta o proyecto separados y usa controles de integridad o inmutabilidad cuando sea necesario. La validación de archivos de registro de CloudTrail puede revelar modificaciones en los archivos entregados. Establece la retención según el requisito aplicable; PCI DSS exige al menos 12 meses de historial de auditoría, con los últimos 3 meses disponibles de inmediato. Configura alertas para eventos como inicios de sesión raíz o cambios en roles con privilegios elevados, y asigna a alguien para responder.

El cumplimiento normativo consiste en satisfacer los requisitos aplicables y mostrar evidencias. Los controles auditados de un proveedor de servicios en la nube pueden apoyar tus obligaciones, pero tu organización también debe aplicar y documentar los controles que le corresponden.

Identifica el tipo de requisito

ISO/IEC 27001 trata un sistema de gestión de seguridad de la información, o SGSI. Los organismos de certificación acreditados emiten certificados, normalmente con un ciclo de tres años y auditorías de seguimiento. ISO/IEC 27017 añade controles de seguridad en la nube. ISO/IEC 27018 trata la protección de datos personales para los encargados del tratamiento en nubes públicas; su edición actual es de 2025.

Elige el informe SOC según la pregunta

SOC 1 se refiere a los controles relevantes para la información financiera de los clientes. SOC 2 aborda los criterios de servicios de confianza aplicables: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Es un informe detallado que suele compartirse bajo condiciones de confidencialidad. SOC 3 es un informe de uso general adecuado para su distribución pública.

Un informe de tipo 1 evalúa el diseño de los controles en un momento dado. Un informe de tipo 2 también comprueba la eficacia de su funcionamiento durante un período determinado. Para obtener evidencias de que los controles pertinentes de un proveedor funcionaron durante meses, solicita un informe SOC 2 de tipo 2 vigente e inspecciona su alcance real. SOC 2 es un atestiguamiento, no una certificación.

Reconoce las necesidades sectoriales y gubernamentales

PCI DSS se aplica a las organizaciones que almacenan, procesan o transmiten datos de titulares de tarjetas. El alcance del servicio en la nube importa junto con el diseño y los controles de pago del cliente.

La HIPAA protege la PHI incluida en su alcance: la que poseen las organizaciones sanitarias cubiertas y sus asociados de negocios. Un proveedor que mantiene PHI electrónica en nombre de una entidad cubierta es un asociado de negocios, incluso cuando almacena datos cifrados sin la clave. Debe existir un acuerdo con un asociado de negocios (BAA). No existe una certificación oficial de HIPAA que sustituya estas obligaciones.

FedRAMP aborda la evaluación y la supervisión continua de los servicios en la nube para los usos de agencias federales de Estados Unidos incluidos en su alcance. Los casos de uso de las agencias y las exclusiones importan; vender software instalable a una agencia por sí solo no lo activa. Otros esquemas de garantía incluyen C5 de Alemania, ENS de España, IRAP de Australia e ISMAP de Japón. CSA STAR publica autoevaluaciones de la nube e información de garantía independiente.

Comprueba el alcance del servicio antes de basarte en las evidencias

Una clínica comprueba tanto su BAA como la lista de servicios aptos del proveedor antes de introducir PHI electrónica en un servicio. Un comercio que procesa datos de titulares de tarjetas comprueba los requisitos de PCI DSS y también puede tener obligaciones del RGPD para los datos personales. Una obligación no sustituye a otra.

Un certificado o informe especifica un límite: servicios, ubicaciones y fechas de evaluación. Registra qué controles del proveedor hereda tu carga de trabajo y después implementa tus propios permisos, configuraciones, procedimientos y evidencias. Una acreditación corporativa general del proveedor no puede responder si un servicio o región nuevos concretos están incluidos.

Las evidencias de cumplimiento son útiles cuando corresponden al servicio, la ubicación y el período de los que dependes. Descargar un documento inicia la revisión; su contenido determina en qué garantías puedes basarte.

Busca los documentos del proveedor

Los informes SOC detallados suelen exigir la aceptación de condiciones de confidencialidad o de un acuerdo de confidencialidad. Los informes SOC 3 de uso general y muchos certificados son públicos. Las páginas públicas de cumplimiento ayudan a identificar los programas disponibles y los servicios incluidos en su alcance.

Lee un informe SOC 2 de tipo 2 en orden

1. Lee la opinión del auditor. Una opinión sin salvedades proporciona una garantía favorable dentro del alcance indicado; una opinión con salvedades identifica una reserva que debes comprender.
2. Relaciona la descripción y el alcance del sistema con los servicios y las ubicaciones que has elegido.
3. Comprueba el período del informe y cuánto tiempo ha pasado desde que terminó.
4. Lee los controles probados y las excepciones, incluido cómo afectan a tu uso.
5. Identifica los controles complementarios de la entidad usuaria (CUEC): controles que tu organización debe aplicar.
6. Revisa la función y el tratamiento de las organizaciones de servicios subcontratados de las que depende el proveedor.

Un informe puede ser favorable y aun así exigir que tu organización administre el acceso de los usuarios, revise los registros o configure un ajuste. Incorpora esas obligaciones a tu propio plan de controles y asigna responsables.

El 15 de marzo de 2026, un equipo revisa un informe que cubre del 1 de octubre de 2024 al 30 de septiembre de 2025. El período de pruebas de doce meses terminó 166 días antes. Una carta puente proporciona la declaración del proveedor sobre los cambios relevantes desde esa fecha de finalización. No es una nueva auditoría independiente de cada día del intervalo. Obtén el siguiente informe cuando esté disponible.

Conserva los contratos junto con las evidencias

El RGPD exige un contrato adecuado entre el responsable y el encargado del tratamiento, que suele proporcionarse como un acuerdo de encargo del tratamiento de datos o un anexo. Algunos ejemplos de proveedores son el anexo de AWS para el RGPD, Products and Services Data Protection Addendum de Microsoft y Cloud Data Processing Addendum de Google. Las relaciones con asociados de negocios sujetas a HIPAA requieren un BAA.

Un informe describe los controles evaluados. Un acuerdo crea los compromisos contractuales pertinentes. Ninguno de los documentos puede cumplir la función del otro. Mantén aceptados y vigentes los acuerdos aplicables a los servicios utilizados.

Supervisa también los controles del cliente

Registra los controles del proveedor como heredados y después recopila tus propias revisiones de acceso, resultados de configuración, registros, políticas y constancias de formación, según corresponda. Los paquetes de conformidad de AWS Config agrupan comprobaciones técnicas de configuración; no evalúan todas las políticas ni todos los procedimientos del personal. Purview Compliance Manager proporciona acciones de mejora y una puntuación de cumplimiento. Google Assured Workloads aplica controles compatibles para cargas de trabajo reguladas, incluidas restricciones de ubicación y acceso.

Trata las puntuaciones y los hallazgos como una lista de trabajo con evidencias que debes inspeccionar. Resuelve las lagunas de alcance o fechas antes de presentar los documentos a un comprador o auditor, y comprueba si un servicio o región recién adoptados requieren una nueva revisión.

La protección de datos combina decisiones sobre la finalidad, el acceso, la ubicación y los derechos de las personas. Trasladar los registros a una región elegida solo resuelve la parte relativa a la ubicación.

Conoce los roles y las obligaciones

El RGPD, aplicable desde el 25 de mayo de 2018, regula el tratamiento de datos personales incluido en su alcance en toda la UE y el EEE. También se aplica a las organizaciones fuera de la UE que ofrecen bienes o servicios a personas en la UE o supervisan su comportamiento allí. No se limita a los ciudadanos de la UE.

El responsable del tratamiento decide las finalidades y los medios del tratamiento. El encargado del tratamiento actúa en nombre del responsable. Para los registros alojados del cliente, este suele ser el responsable y el proveedor de servicios en la nube, su encargado. El artículo 28 exige un contrato de tratamiento por escrito. Los roles dependen de la relación real de tratamiento, no simplemente de la denominación de la empresa en la nube.

Las obligaciones relevantes para la nube incluyen una base legal, la recopilación solo de los datos necesarios (minimización de datos), una seguridad adecuada al riesgo, los derechos de acceso y supresión de las personas y la notificación aplicable de vulneraciones. El artículo 32 menciona el cifrado y la seudonimización como ejemplos de medidas de seguridad.

Según el artículo 33, un responsable notifica una vulneración de datos personales a su autoridad de control sin dilación indebida y, cuando sea posible, en un plazo de 72 horas desde que tenga conocimiento de ella, salvo que sea improbable que suponga un riesgo para los derechos y libertades de las personas. Un encargado informa a su responsable sin dilación indebida. Si se tiene conocimiento el lunes a las 09:00, las 72 horas terminan el jueves a las 09:00; esto no autoriza a esperar cuando es posible notificar antes. Una notificación tardía a la autoridad debe explicar el retraso.

El nivel superior del artículo 83 permite un máximo de 20 millones de euros o el 4 % del volumen de negocios anual mundial del año anterior, la cantidad que sea mayor. Para un volumen de negocios de 1,5 mil millones de euros, el 4 % son 60 millones de euros; para 300 millones de euros son 12 millones de euros, por lo que el límite de 20 millones de euros es mayor. Las sanciones reales dependen de la infracción y de su evaluación.

Distingue los requisitos de ubicación

Comprueba los compromisos de ubicación de un servicio, las copias de seguridad, las réplicas y el acceso de soporte. La elección de una región no es una garantía general para todas las funciones del servicio. Las ofertas gubernamentales y soberanas, como AWS GovCloud (US), Azure Government y las opciones soberanas europeas, atienden requisitos concretos con criterios de admisión y un alcance definidos.

Las transferencias fuera del EEE necesitan una vía legal aplicable, como una decisión de adecuación, cláusulas contractuales tipo o normas corporativas vinculantes. La vía de adecuación del Marco de Privacidad de Datos UE-EE. UU. se aplica a las transferencias cubiertas hacia organizaciones participantes certificadas. El acceso por parte de personal situado en otro país también puede requerir un análisis de la transferencia, aunque el almacenamiento permanezca en una región de la UE.

Una aseguradora que mantiene reclamaciones en la UE selecciona regiones de la UE para almacenamiento y copias de seguridad, aplica controles de protección de ubicación compatibles, controla el acceso a las claves y revisa su DPA y las condiciones de transferencia. Las claves administradas por el cliente por sí solas no resuelven las obligaciones de residencia o transferencia.

Los datos personales cifrados siguen siendo datos personales para una parte que pueda descifrarlos. Un cifrado eficaz puede eliminar la obligación de notificar a las personas afectadas según el artículo 34 cuando se cumplen sus condiciones; la notificación a la autoridad tiene sus propios criterios. Otras leyes, incluidas la CCPA de California modificada por la CPRA y la LGPD de Brasil, tienen sus propios alcances y obligaciones.