Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Para comprender cómo implementan los proveedores de recursos de Azure el cifrado en reposo, debe comprender los diferentes modelos de cifrado y sus ventajas y desventajas. Para garantizar una taxonomía y un lenguaje común, los proveedores de recursos de Azure comparten estas definiciones.
Azure cifra automáticamente los datos en reposo de forma predeterminada mediante claves administradas por la plataforma. Opcionalmente, puede elegir otros enfoques de administración de claves en función de los requisitos de seguridad y cumplimiento. El cifrado en el lado del servidor incluye tres escenarios:
Cifrado en el lado del servidor mediante claves gestionadas por plataforma (por defecto).
- Los proveedores de recursos de Azure realizan las operaciones de cifrado y descifrado.
- Microsoft administra automáticamente las claves.
- Habilitado de forma predeterminada sin ninguna configuración necesaria.
- Funcionalidad completa de la nube.
Cifrado en el lado del servidor mediante claves gestionadas por el cliente en Azure Key Vault (opcional).
- Los proveedores de recursos de Azure realizan las operaciones de cifrado y descifrado.
- Controlas las llaves a través de Azure Key Vault.
- Requiere la configuración y administración del cliente.
- Funcionalidad completa de la nube.
Cifrado en el lado del servidor mediante claves gestionadas por el cliente en hardware controlado por el cliente (opción avanzada).
- Los proveedores de recursos de Azure realizan las operaciones de cifrado y descifrado.
- Las claves se controlan en hardware controlado por el cliente.
- Configuración compleja y compatibilidad limitada con el servicio de Azure.
- Funcionalidad completa de la nube.
Los modelos de cifrado del lado servidor hacen referencia al cifrado que realiza el servicio de Azure. En ese modelo, el proveedor de recursos realiza las operaciones de cifrado y descifrado. Por ejemplo, Azure Storage puede recibir datos en las operaciones de texto sin formato y llevará a cabo el cifrado y descifrado internamente. El proveedor de recursos puede usar claves de cifrado que Microsoft o el cliente gestionen, dependiendo de tu configuración.
Cada uno de los modelos de cifrado en reposo del lado servidor tiene características distintivas de administración de claves. Estas características incluyen dónde y cómo se crean y almacenan claves de cifrado, así como los modelos de acceso y los procedimientos de rotación de claves.
Para el cifrado del lado cliente, tenga en cuenta lo siguiente:
- Los servicios de Azure no pueden ver datos descifrados.
- Los clientes administran y almacenan las claves en ubicaciones locales (o en otras ubicaciones seguras). Los servicios de Azure no tienen acceso a las claves.
- Funcionalidad reducida de la nube.
Los modelos de cifrado soportados en Azure se dividieron en dos grupos principales: cifrado de cliente y cifrado del lado del servidor. Independientemente del modelo de cifrado en reposo que use, los servicios de Azure siempre recomiendan el uso de un transporte seguro, como TLS o HTTPS. Por lo tanto, aborde el cifrado durante el transporte mediante el protocolo de transporte. No debería ser un factor importante para determinar qué modelo de cifrado en reposo usar.
Modelo de cifrado del cliente
El modelo de cifrado del cliente se refiere al cifrado que el servicio o la aplicación que llama realiza fuera del proveedor de recursos o de Azure. La aplicación de servicio en Azure o una aplicación que se ejecuta en el centro de datos del cliente puede realizar el cifrado. En cualquier caso, cuando se utiliza este modelo de cifrado, el proveedor de recursos de Azure recibe un blob de datos cifrado sin la posibilidad de descifrar los datos de ninguna manera ni acceder a las claves de cifrado. En este modelo, el servicio de llamada o la aplicación controla la administración de claves y la mantiene opaca en el servicio de Azure.
Cifrado en el lado del servidor mediante claves gestionadas por la plataforma (por defecto)
Para la mayoría de los clientes, el requisito esencial es asegurarse de que los datos estén cifrados siempre que estén en reposo. El cifrado en el lado del servidor mediante claves gestionadas por plataforma (anteriormente llamadas claves gestionadas por servicios) cumple este requisito al proporcionar cifrado automático por defecto. Este enfoque permite el cifrado en reposo sin necesidad de que los clientes configuren o gestionen las claves de cifrado. Microsoft se encarga de tareas de gestión de claves como la emisión, rotación y copia de seguridad.
La mayoría de los servicios de Azure implementan este modelo como comportamiento predeterminado, cifrando automáticamente los datos en reposo mediante claves administradas por la plataforma sin necesidad de ninguna acción del cliente. El proveedor de recursos de Azure crea las claves, las coloca en un almacenamiento seguro y las recupera cuando es necesario. El servicio tiene acceso total a las claves y mantiene el control total sobre la gestión del ciclo de vida de las credenciales. Este control proporciona una protección robusta contra cifrado sin ninguna sobrecarga de gestión para los clientes.
El cifrado del lado servidor mediante claves administradas por la plataforma aborda la necesidad de cifrado en reposo con una sobrecarga cero para el cliente. Este cifrado está habilitado de forma predeterminada en los servicios de Azure, lo que proporciona protección automática de datos sin necesidad de ninguna configuración o administración del cliente. Los clientes se benefician de una protección robusta contra cifrado inmediatamente después de almacenar datos en los servicios de Azure, sin necesidad de pasos adicionales, costes ni gestión continua.
El cifrado en el lado del servidor mediante claves gestionadas por la plataforma significa que el servicio tiene acceso completo para almacenar y gestionar las claves. Aunque es posible que algunos clientes quieran administrar las claves porque sienten que obtienen mayor seguridad, tenga en cuenta el costo y el riesgo asociados a una solución de almacenamiento de claves personalizada al evaluar este modelo. En muchos casos, una organización podría determinar que las restricciones de recursos o los riesgos de una solución local son mayores que el riesgo de la administración en la nube del cifrado en reposo. Sin embargo, este modelo podría no ser suficiente para las organizaciones que tienen requisitos para controlar la creación o el ciclo de vida de las claves de cifrado o tener personal diferente para administrar las claves de cifrado de un servicio al que administra el servicio (es decir, la segregación de la administración de claves de todo el modelo de administración para el servicio).
Acceso a la clave
Cuando se utiliza cifrado en el lado del servidor con claves gestionadas por la plataforma, el servicio se encarga de la creación, almacenamiento y acceso al servicio. Normalmente, los proveedores de recursos fundamentales de Azure almacenan las claves de cifrado de datos en un almacén cercano a los datos y de fácil acceso, mientras que las claves de cifrado de clave residen en un almacén interno seguro.
Ventajas
- Configuración sencilla.
- Microsoft administra la rotación de claves, la copia de seguridad y la redundancia.
- No incurres en costes ni riesgos asociados a la implementación de un esquema personalizado de gestión de claves.
Consideraciones
- Ningún control de cliente sobre las claves de cifrado (especificación de claves, ciclo de vida, revocación, etc.). Esta opción es adecuada para la mayoría de los casos de uso, pero podría no cumplir los requisitos de cumplimiento especializados.
- No es posible separar la administración de claves del modelo de administración general del servicio. Las organizaciones que requieren separación de tareas pueden necesitar claves administradas por el cliente.
Cifrado en el lado del servidor mediante claves gestionadas por el cliente en Azure Key Vault y Azure Key Vault Managed HSM (opcional)
En escenarios en los que las organizaciones tienen requisitos específicos para controlar sus claves de cifrado más allá del cifrado gestionado por la plataforma por defecto, los clientes pueden optar por el cifrado en el lado del servidor utilizando claves gestionadas por el cliente en Key Vault o Azure Key Vault Managed HSM. Este enfoque se basa en el cifrado predeterminado en reposo, lo que permite a los clientes usar sus propias claves mientras Azure sigue controlando las operaciones de cifrado y descifrado.
Algunos servicios pueden almacenar solo la clave de cifrado de clave raíz (KEK) en Azure Key Vault y almacenar la clave de cifrado de datos cifrados (DEK) en una ubicación interna más cercana a los datos. En este escenario, los clientes pueden usar el modelo bring your own key (BYOK) para importar claves a Key Vault o generar nuevas claves en Key Vault, y luego usarlas para cifrar los recursos deseados. Mientras el proveedor de recursos realiza las operaciones de cifrado y descifrado, utiliza el KEK configurado por el cliente como clave raíz para todas las operaciones de cifrado.
La pérdida de claves de cifrado de claves significa también la pérdida de los datos. Por esta razón, no elimines las teclas. Realice siempre copias de seguridad de las claves al crearlas o rotarlas. Cuando se rota un KEK, el servicio envuelve las claves de cifrado de datos con la nueva versión de clave: los datos subyacentes no se vuelven a cifrar. Tanto las versiones antiguas como las nuevas deben permanecer activadas hasta que todas las claves de cifrado de datos estén envueltas con la nueva versión de clave. Para proteger contra la eliminación accidental o maliciosa de la criptografía, debe activarse la protección contra eliminación suave y purga en cualquier bóveda que almacene claves de cifrado de clave. En lugar de eliminar una clave, establezca habilitado como false en la clave de cifrado. Use controles de acceso para revocar el acceso a usuarios o servicios individuales en Azure Key Vault o HSM administrado.
Warning
Si sospechas que una clave está comprometida, no la desactives ni la elimines inmediatamente. Desactivar o eliminar una clave deja fuera de servicio a todos los servicios dependientes, pero no invalida ninguna copia de la clave de la que se haya hecho una copia de seguridad y que se haya restaurado en otra bóveda. Esas copias siguen siendo totalmente funcionales. En su lugar, cambie a una nueva clave y migre todos los servicios dependientes antes de deshabilitar la clave comprometida. Para obtener el procedimiento completo de respuesta a incidentes, consulte Consideraciones de seguridad de copia de seguridad y Respuesta ante compromiso de clave.
Para escenarios de clave gestionados por el cliente, utiliza Azure Key Vault Premium tier (respaldado por HSM) como mínimo para los requisitos de cumplimiento que exigen claves protegidas por HSM. Utiliza Azure Key Vault Managed HSM para cargas de trabajo que requieren soberanía clave o capacidad dedicada de HSM. Para las organizaciones que tienen requisitos regulatorios o contractuales que obligan a que el material clave resida físicamente fuera de la infraestructura de Microsoft, Azure Key Vault Managed HSM también soporta la gestión externa de claves (preview), que mantiene el KEK en un HSM gestionado por el cliente completamente fuera de Azure.
Nota:
Para una lista de servicios que soportan claves gestionadas por clientes en Azure Key Vault y Azure Key Vault Managed HSM, véase Servicios que soportan CMKs en Azure Key Vault y Azure Key Vault Managed HSM.
Acceso a la clave
En el modelo de cifrado del lado del servidor que utiliza claves gestionadas por el cliente en Azure Key Vault, el servicio accede a las claves para cifrar y descifrar según sea necesario. Puede hacer que las claves de cifrado en reposo sean accesibles para un servicio mediante una política de control de acceso. Esta directiva concede el acceso de identidad de servicio para recibir la clave. Puede configurar un servicio de Azure que se ejecuta en nombre de una suscripción asociada con una identidad de esa suscripción. El servicio puede realizar la autenticación Microsoft Entra y recibir un token de autenticación identificándose como ese servicio actuando en nombre de la suscripción. El servicio entonces presenta el token a Key Vault para obtener una clave a la que pueda acceder.
Para las operaciones que usan claves de cifrado, puedes conceder a una identidad de servicio acceso a cualquiera de las siguientes operaciones: decrypt, encrypt, unwrapKey, wrapKey, verify, sign, get, list, update, create, import, delete, backup y restore.
Para obtener una clave para cifrar o descifrar datos en reposo, la identidad de servicio que ejecuta la instancia de servicio del Resource Manager debe tener UnwrapKey (para obtener la clave para descifrar) y WrapKey (para insertar una clave en Key Vault al crear una nueva clave).
Nota:
Para más información sobre la autorización de Key Vault, consulta Secure your Key vault.
Ventajas
- Control total sobre las teclas usadas. Las claves de cifrado se gestionan en tu Key Vault bajo tu control.
- Puedes cifrar varios servicios usando una sola clave raíz.
- Puedes separar la gestión de claves del modelo general de gestión del servicio.
- Puedes definir el servicio y la ubicación clave entre regiones.
Desventajas
- Tiene toda la responsabilidad de la administración del acceso clave.
- Tiene responsabilidad total para la administración del ciclo de vida de las claves.
- Sobrecarga adicional de instalación y configuración.
Cifrado en el lado del servidor mediante claves gestionadas por el cliente en hardware controlado por el cliente (opción especializada)
Algunos servicios de Azure habilitan el modelo de administración de claves de Host Your Own Key (HYOK) para organizaciones con requisitos de seguridad especializados. Este modo de gestión es útil en escenarios altamente regulados que requieren cifrado de datos en reposo y gestión de claves en un repositorio propietario completamente fuera del control de Microsoft. Va más allá del cifrado gestionado por la plataforma por defecto y las claves opcionales gestionadas por el cliente en Azure Key Vault.
En este modelo, el servicio debe usar la clave de un sitio externo para descifrar el DEK. Las garantías de rendimiento y disponibilidad se ven afectadas y la configuración es significativamente más compleja. Además, dado que el servicio no tiene acceso al DEK durante las operaciones de cifrado y descifrado, las garantías generales de seguridad de este modelo son similares a cuando las claves son gestionadas por el cliente en Azure Key Vault. Como resultado, este modelo no es adecuado para la mayoría de las organizaciones a menos que tengan requisitos regulatorios o de seguridad muy específicos que no puedan cumplirse con claves gestionadas por plataforma o por el cliente en Azure Key Vault. Debido a estas limitaciones, la mayoría de los servicios de Azure no soportan cifrado en el lado del servidor utilizando claves gestionadas por el cliente en hardware controlado por el cliente. Una de las dos claves en el Cifrado de Doble Clave sigue este modelo.
Acceso a la clave
Cuando usas cifrado en el lado del servidor con claves gestionadas por el cliente en hardware controlado por el cliente, mantienes las claves de cifrado en un sistema que configuras. Los servicios de Azure que admiten este modelo proporcionan una manera de establecer una conexión segura con un almacén de claves proporcionado por el cliente.
Ventajas
- Tienes control total sobre la clave raíz porque una tienda proporcionada por el cliente gestiona las claves de cifrado.
- Puedes cifrar varios servicios usando una sola clave raíz.
- Puedes separar la gestión de claves del modelo general de gestión del servicio.
- Puedes definir el servicio y la ubicación clave entre regiones.
Desventajas
- Tiene toda la responsabilidad del almacenamiento de claves, la seguridad, el rendimiento y la disponibilidad.
- Tiene toda la responsabilidad de la administración del acceso clave.
- Tiene responsabilidad total para la administración del ciclo de vida de las claves.
- Incurre en costos significativos de instalación, configuración y mantenimiento continuo.
- El modelo aumenta la dependencia de la disponibilidad de red entre el centro de datos del cliente y los centros de datos de Azure.