Compartir a través de

Cifrado con claves administradas por el cliente en Microsoft Cloud for Sovereignty

  • Artículo

Los clientes que planeen implementar Microsoft Cloud for Sovereignty podrían usar características de cifrado de datos para satisfacer los requisitos de soberanía de datos. Los clientes con estrictos requisitos de soberanía de datos deben desarrollar planes para implementar la gestión de claves en la nube. Este artículo guía a los arquitectos de la nube, propietarios de sistemas criptográficos y otros responsables de la toma de decisiones técnicas para desarrollar un plan para implementar el cifrado a nivel de plataforma en Azure. La planificación del cifrado en el nivel de plataforma suele implicar la identificación de los requisitos de administración de claves, la elección de tecnologías y la selección de diseños y opciones de configuración para los servicios Azure que se vayan a usar. Este proceso implica tomar decisiones técnicas en tres dominios:

  • Defina los requisitos clave de gestión: ¿Qué debe hacer su organización para proteger los datos confidenciales de los clientes y el material criptográfico confidencial?
  • Seleccione las características de cifrado de datos para proteger los datos de los clientes: ¿cómo, dónde y cuándo debe cifrar los datos de los clientes en Azure?
  • Seleccione soluciones de administración de claves para proteger las claves de los clientes: ¿Qué almacén de claves debe usar para proteger las claves de cifrado de datos que se usan para cifrar los datos de los clientes en Azure?

Defina los requisitos de administración de clave

Los requisitos para la administración de claves pueden incluir requisitos técnicos sobre los servicios criptográficos que se utilizan y requisitos operativos relacionados con el rendimiento, la seguridad y la soberanía. El punto de partida recomendado para tomar decisiones sobre cuándo y cómo cifrar datos en cargas de trabajo de Azure es el sistema de clasificación de datos de una organización. Al alinear los requisitos de cifrado con las clasificaciones de datos, en lugar de sistemas o soluciones específicos, las organizaciones tienen más flexibilidad para seleccionar el nivel óptimo de cifrado durante la planificación de la migración de cargas de trabajo.

Basar los requisitos de cifrado en la clasificación de datos también permite un enfoque escalonado, donde las cargas de trabajo con menor criticidad pueden aprovechar soluciones más simples y al mismo tiempo reservar las configuraciones más complejas para cargas de trabajo con un mayor nivel de riesgo inherente. Un ejemplo de este enfoque sería permitir el uso de claves administradas por Microsoft para cifrar cuentas de almacenamiento para entornos de desarrollo y al mismo tiempo exigir que las cuentas de almacenamiento de producción utilicen claves de cifrado administradas por el Cliente.

Una vez que una organización comprende claramente cómo se relacionan sus requisitos de cifrado con sus clasificaciones de datos, puede comenzar el proceso de selección de características para los servicios de Azure que planean consumir. Algunas de estas características pueden funcionar de manera diferente a sistemas local similares, por lo que se recomienda a las organizaciones que se familiaricen con cómo funciona el cifrado en Azure y revisen las recomendaciones y prácticas recomendadas para diseñar soluciones de cifrado. Los siguientes artículos brindan perspectivas adicionales sobre algunas de las decisiones técnicas que los clientes deben tomar y pueden ser un punto de partida útil para iniciar una conversación sobre los objetivos clave de administración de la nube de una organización.

Seleccionar funciones de cifrado de datos

Muchos servicios de Azure permiten el cifrado mediante claves que Azure genera, almacena y administra completamente, sin ninguna interacción con el cliente. Estas claves administradas por la plataforma pueden ayudar a las organizaciones a implementar el cifrado con poca sobrecarga operativa. Sin embargo, es posible que los clientes con requisitos estrictos de soberanía de datos deban seleccionar características de cifrado de plataforma específicas para proteger los datos confidenciales mientras están en reposo en un servicio de Azure determinado.

Para datos altamente confidenciales, muchos servicios de Azure de uso común permiten a los clientes implementar cifrado doble mediante claves administradas por el cliente (CMK). La implementación de claves administradas por el cliente en los servicios de Azure puede ayudar a los clientes a proteger los datos almacenados en esos servicios contra el acceso no autorizado.

La implementación de claves administradas por el cliente en Azure puede aumentar el costo y la complejidad de una carga de trabajo, por lo que se recomienda a las organizaciones evaluar la necesidad de esta característica para cada carga de trabajo y nivel de clasificación de datos. La implementación de claves administradas por el cliente solo para las cargas de trabajo y los tipos de datos que las necesitan puede ayudar a reducir la sobrecarga operativa de las cargas de trabajo que no manejan datos confidenciales.

Si se requieren claves administradas por el cliente, deben configurarse para cada servicio de Azure. Las organizaciones pueden ayudar a agilizar los esfuerzos de planificación de implementación o migración estableciendo estándares para toda la organización y patrones de diseño repetibles para implementar estas características. Los siguientes artículos proporcionan más información sobre cómo se configura el cifrado de datos en reposo en Azure:

Aprenda a configurar servicios de Azure de uso común para cifrar datos en reposo mediante claves administradas por el cliente:

Seleccione soluciones de gestión de claves

Si bien características como el cifrado doble con claves administradas por el cliente pueden ayudar a proteger los datos del cliente que se mantienen en los servicios de Azure, las soluciones de administración de claves basadas en la nube ayudan a proteger las claves de cifrado y otros materiales criptográficos que se utilizan para cifrar datos confidenciales. Los clientes con estrictos requisitos de soberanía de datos deben seleccionar una solución de gestión de claves adecuada en función de sus necesidades de garantía y el perfil de riesgo de sus cargas de trabajo.

Las cargas de trabajo que gestionan datos confidenciales podrían beneficiarse de la garantía agregada que proporcionan soluciones como Azure Managed HSM, que incluyen módulos de seguridad de hardware validados por FIPS-140-2 de nivel 3 que agregan controles de seguridad adicionales para proteger el material criptográfico almacenado.

Los siguientes artículos proporcionan orientación que los clientes pueden utilizar para seleccionar un almacén de claves adecuado para sus escenarios identificados. También proporciona información sobre cómo Microsoft administra los servicios criptográficos que utilizan los clientes como parte de su solución de cifrado.

Modelos de operaciones para la administración de claves

Azure Key Vault implementa el control de acceso basado en roles de diferentes maneras, dependiendo de si está usando el nivel Standard/Premium de Azure Key Vault o Azure Key Vault Managed HSM. Estas diferencias en el control de acceso pueden repercutir en la forma en que una organización usa estas características. En esta sección se describen estas diferencias y cómo pueden afectar a la forma en que una organización decide diseñar sus procesos operativos para la administración de claves en la nube.

Restricciones de cumplimiento para la validación del nivel 3 de FIPS-140

La validación de nivel 3 de FIPS-140 requiere una identificación del operador basada en la identidad. Estas protecciones se implementan y validan en el hardware HSM subyacente que respalda los servicios de Azure Key Vault. Como resultado, las características de RBAC de Azure Key Vault dependen de las capacidades de RBAC del hardware subyacente.

Azure Key Vault Managed HSM aprovecha las asignaciones de RBAC locales que se implementan en el nivel de hardware y permiten asignar roles en el ámbito del dominio de seguridad (por ejemplo, en todo el HSM) o por clave. Esto significa que la creación de claves requiere permisos administrativos sobre todo el dominio de seguridad, ya que no se pueden asignar permisos para una clave que aún no existe. El impacto de este diseño es que cualquiera que necesite almacenar una clave en una instancia de mHSM debe o bien tener permisos completos para todas las claves almacenadas en ese dominio de seguridad, o bien solicitar las claves a un equipo centralizado que tenga esos permisos requeridos sobre el dominio de seguridad. Esto representa un cambio con respecto a la guía para Azure Key Vault que recomienda crear almacenes de claves separados para cada aplicación.

Operaciones de administración de claves en Azure Key Vault Managed HSM

Con el fin de desarrollar procesos operativos para la administración de claves, los clientes deben determinar si requieren Azure Key Vault Managed HSM como parte de la arquitectura de su solución. Las organizaciones que tengan previsto usar HSM administrado deben familiarizarse primero con los modelos de control de acceso utilizados tanto para la administración como para las operaciones criptográficas, y comprender cómo se asigna el control de acceso basado en roles.

Más información sobre el control de acceso en HSM administrado:

Las organizaciones que estén planeando usar el HSM de Azure Key Vault deben revisar la lista de roles de RBAC incorporados y las operaciones permitidas para el HSM administrado y planificar específicamente cómo abordar los siguientes escenarios de operaciones:

  • Creación de una nueva clave en el HSM administrado
  • Operaciones de administración de una clave existente usando el plano de control, como actualizaciones o rotación de claves
  • Uso en el plano de datos de una clave existente por parte de una aplicación o servicio

Actualmente, la única forma de asignar permisos para crear una nueva clave es asignar un rol como el Crypto User que también incluye otros permisos como la rotación y eliminación de claves. Como resultado, conceder a un miembro de un equipo de aplicación los permisos necesarios para crear sus propias claves en el HSM administrado puede infringir los principios de privilegio mínimo, ya que ese usuario también tendría permisos administrativos para todas las claves del HSM. Este problema puede resolverse introduciendo un equipo centralizado con los permisos elevados que pueda facilitar las solicitudes de creación de claves, o introduciendo una automatización que pueda facilitar las nuevas solicitudes de creación de claves a través de procesos de administración de servicios de TI que aprovechen la API REST de HSM administrado.

Contenido relacionado