Seguridad de Azure Key Vault
Azure Key Vault protege las claves criptográficas, los certificados (y las claves privadas asociadas a estos) y los secretos (como cadenas de conexión y contraseñas) en la nube. No obstante, cuando almacena datos confidenciales y críticos para la empresa, debe tomar medidas para maximizar la seguridad de los almacenes y de los datos almacenados en estos.
Seguridad de red
Puede reducir la exposición de los almacenes si especifica las direcciones IP que tienen acceso a ellos. Los puntos de conexión de servicio de red virtual para Azure Key Vault permiten restringir el acceso a una red virtual especificada. También permiten restringir el acceso a una lista de intervalos de direcciones IPv4 (protocolo de Internet, versión 4). A todos los usuarios que se conecten a su almacén de claves desde fuera de esos orígenes se les negará el acceso.
Una vez que las reglas del firewall están en vigor, los usuarios solo pueden leer datos de Key Vault cuando las solicitudes se originan desde redes virtuales o rangos de direcciones IPv4 permitidos. Esto también se aplica al acceso de Key Vault desde Azure Portal. Aunque los usuarios pueden ir a un almacén de claves desde Azure Portal, es posible que no pueda enumerar las claves, los secretos o los certificados si su equipo cliente no está en la lista de dispositivos permitidos.
El servicio Azure Private Link permite acceder a Azure Key Vault y a los servicios de asociados o clientes hospedados de Azure mediante un punto de conexión privado de la red virtual. Un punto de conexión privado de Azure es una interfaz de red que le conecta de forma privada y segura a un servicio con la tecnología de Azure Private Link. El punto de conexión privado usa una dirección IP privada de la red virtual para incorporar el servicio de manera eficaz a su red virtual. Todo el tráfico dirigido al servicio se puede enrutar mediante el punto de conexión privado, por lo que no se necesita ninguna puerta de enlace, dispositivos de traducción de direcciones de red (NAT), conexiones de ExpressRoute o VPN ni direcciones IP públicas. El tráfico entre la red virtual y el servicio atraviesa la red troncal de Microsoft, eliminando la exposición a la red pública de Internet. Puede conectarse a una instancia de un recurso de Azure, lo que le otorga el nivel más alto de granularidad en el control de acceso.
Seguridad de la capa de transporte (TLS) y Protocolo de transferencia de hipertexto con cifrado de Capa de sockets seguros (HTTPS)
El front-end de Key Vault (plano de datos) es un servidor de varios inquilinos. Esto significa que los almacenes de claves de distintos clientes pueden compartir la misma dirección IP pública. Con el fin de lograr el aislamiento, cada solicitud HTTP se autentica y autoriza con independencia de otras solicitudes.
El protocolo HTTPS permite al cliente participar en la negociación de TLS. Los clientes pueden aplicar la versión de TLS y, cada vez que un cliente lo hace, toda la conexión usará la protección de nivel correspondiente. Key Vault admite versiones de protocolo TLS 1.2 y 1.3.
Opciones de autenticación de Key Vault
Cuando se crea un almacén de claves en una suscripción de Azure, se asocia automáticamente con el inquilino de Microsoft Entra de la suscripción. En ambos planos, todos los llamadores deben registrarse en este inquilino y autenticarse para acceder al almacén de claves. En ambos casos, las aplicaciones pueden acceder a Key Vault de tres maneras:
- Solo la aplicación: La aplicación representa una entidad de servicio o una identidad administrada. Esta identidad es el escenario más común para aplicaciones que necesitan acceder periódicamente a certificados, claves o secretos del almacén de claves. Para que este escenario funcione, el elemento objectId de la aplicación debe especificarse en la directiva de acceso y el elemento applicationId no debe especificarse o debe ser nulo.
- Solo el usuario: el usuario accede al almacén de claves desde cualquier aplicación registrada en el inquilino. Los ejemplos de este tipo de acceso incluyen Azure PowerShell y Azure Portal. Para que este escenario funcione, el elemento objectId del usuario debe especificarse en la directiva de acceso y el elemento applicationId no debe especificarse o debe ser nulo.
- Aplicación y usuario (a veces se conoce como identidad compuesta): El usuario tiene que acceder al almacén de claves desde una aplicación específica y la aplicación debe usar el flujo de autenticación delegada (OBO) para suplantar al usuario. Para que este escenario funcione, se debe especificar applicationId y objectId en la directiva de acceso. El elemento applicationId identifica la aplicación necesaria y el elemento objectId identifica el usuario. Actualmente, esta opción no está disponible para Azure RBAC en el plano de datos.
En todos los tipos de acceso, la aplicación se autentica con Microsoft Entra ID. La aplicación utiliza cualquiera método de autenticación compatible según el tipo de aplicación. La aplicación adquiere un token para un recurso del plano para conceder acceso. El recurso es un punto de conexión en el plano de administración o de datos, según el entorno de Azure. La aplicación usa el token y envía la solicitud de una API de REST a Key Vault.
El modelo de un único mecanismo de autenticación para ambos planos tiene varias ventajas:
- Las organizaciones pueden controlar el acceso de forma centralizada a todos los almacenes de claves de su organización.
- Si un usuario abandona la organización, al instante pierde el acceso a todos los almacenes de claves de la organización.
- Las organizaciones pueden personalizar la autenticación mediante las opciones de Microsoft Entra ID, como habilitar la autenticación multifactor para mayor seguridad.
Introducción al modelo de acceso
El acceso a un almacén de claves se controla mediante dos interfaces: el plano de administración y el plano de datos. El plano de administración es donde puede administrar el propio almacén de claves. Las operaciones en este plano incluyen crear y eliminar los almacenes de claves, recuperar las propiedades de un almacén de claves y actualizar las directivas de acceso. El plano de datos es donde se trabaja con los datos almacenados en un almacén de claves. Puede agregar, eliminar y modificar claves, secretos y certificados.
Ambos planos usan Microsoft Entra ID para la autenticación. Para realizar la autorización, el plano de administración usa el control de acceso basado en roles de Azure (RBAC de Azure) y el plano de datos utiliza una directiva de acceso de Key Vault y RBAC de Azure para las operaciones del plano de datos de Key Vault.
Para obtener acceso a un almacén de claves en cualquier plano, todos los llamadores (usuarios o aplicaciones) deben tener una autorización y autenticación correctas. La autenticación establece la identidad del llamador. La autorización determina las operaciones que puede ejecutar el llamador. La autenticación con Key Vault funciona junto con Microsoft Entra ID, que es responsable de autenticar la identidad de cualquier entidad de seguridad determinada.
Una entidad de seguridad es un objeto que representa un usuario, un grupo o una entidad de servicio que solicita acceso a recursos de Azure. Azure asigna un identificador de objeto único a cada entidad de seguridad.
- Una entidad de seguridad de usuario identifica un individuo que tiene un perfil en Microsoft Entra ID.
- Una entidad de seguridad de grupo identifica un conjunto de usuarios creados en Microsoft Entra ID. Los roles o permisos asignados al grupo se conceden a todos los usuarios dentro del grupo.
- Una entidad de servicio es un tipo de entidad de seguridad que identifica una aplicación o un servicio, es decir, un fragmento de código en lugar de un usuario o grupo. El identificador de objeto de una entidad de servicio se conoce como su Id. de cliente y actúa como su nombre de usuario. El secreto de cliente de la entidad de servicio o el certificado actúa como contraseña. Muchos servicios de Azure admiten la asignación de identidades administradas con la administración automatizada del id. de cliente y el certificado. La identidad administrada es la opción más segura y recomendada para realizar la autenticación en Azure.
Acceso condicional
Key Vault proporciona compatibilidad con las directivas de acceso condicional de Microsoft Entra. Mediante el uso de directivas de acceso condicional puede aplicar los controles de acceso correctos a Key Vault cuando sea necesario para mantener la organización segura y no interferir con los usuarios cuando no se necesita.
Acceso con privilegios
La autorización determina las operaciones que puede realizar quien envía la llamada. La autorización de Key Vault usa el control de acceso basado en roles de Azure (RBAC de Azure) en el plano de administración y las directivas de acceso de RBAC de Azure o Azure Key Vault en el plano de datos.
El acceso a los almacenes se realiza a través de dos interfaces o planos. Estos son el plano de administración y el plano de datos.
- El plano de administración es donde se administra Key Vault y es la interfaz utilizada para crear y eliminar almacenes. También puede leer las propiedades del almacén de claves y administrar las directivas de acceso.
- El plano de datos es donde se trabaja con los datos almacenados en un almacén de claves. Puede agregar, eliminar y modificar claves, secretos y certificados.
Las aplicaciones acceden a los planos a través de puntos de conexión. Los controles de acceso para los dos planos funcionan de forma independiente. Para conceder acceso a una aplicación para que use las claves de un almacén de claves, debe conceder acceso al plano de datos mediante una directiva de acceso de Key Vault o RBAC de Azure. Para conceder a un usuario acceso de lectura a las propiedades y etiquetas de Key Vault, pero sin que este pueda acceder a los datos (claves, secretos o certificados), debe conceder acceso al plano de administración con Azure RBAC.
| Plano de acceso | Puntos de conexión de acceso | Operaciones | Mecanismo de control de acceso |
|---|---|---|---|
| Plano de administración | Global: management.azure.com:443 Microsoft Azure operado por 21Vianet: management.chinacloudapi.cn:443 Azure US Gov: management.usgovcloudapi.net:443 Azure Alemania: management.microsoftazure.de:443 |
Crear, leer, actualizar y eliminar almacenes de claves Establecer directivas de acceso de Key Vault Establecer etiquetas de Key Vault |
Azure RBAC |
| Plano de datos | Global: <vault-name>.vault.azure.net:443 Microsoft Azure operado por 21Vianet: <vault-name>.vault.azure.cn:443 Azure US Gov: <vault-name>.vault.usgovcloudapi.net:443 Azure Alemania: <vault-name>.vault.microsoftazure.de:443 |
Claves: encrypt, decrypt, wrapKey, unwrapKey, sign, verify, get, list, create, update, import, delete, recover, back up, restore, purge, rotate (versión preliminar), getrotationpolicy (versión preliminar), setrotationpolicy (versión preliminar), release (versión preliminar) Certificados: manage contacts, getissuers, list issuers, set issuers, delete issuers, manage issuers, get, list, create, import, update, delete, recover, back up, restore, purge Secretos: get, list, set, delete, recover, backup, restore y purge |
Directiva de acceso de Key Vault o Azure RBAC |
Administración del acceso administrativo a Key Vault
Cuando crea un almacén de claves en un grupo de recursos, administra el acceso mediante Microsoft Entra ID. Puede conceder a usuarios o grupos la capacidad de administrar los almacenes de claves en un grupo de recursos. Puede conceder acceso a un nivel de ámbito específico si asigna los roles de Azure apropiados. Para conceder acceso a un usuario para administrar los almacenes de claves, debe asignar el rol predefinido Colaborador de almacén de claves a este usuario en un ámbito específico. Los siguientes niveles de ámbitos se pueden asignar a un rol de Azure:
- Suscripción: Un rol de Azure asignado al nivel de suscripción se aplica a todos los recursos y grupos de recursos de esa suscripción.
- Grupo de recursos: Un rol de Azure asignado al nivel de grupo de recursos se aplica a todos los recursos de dicho grupo de recursos.
- Recurso específico: un rol de Azure asignado a un recurso concreto se aplica a dicho recurso. En este caso, el recurso es un almacén de claves específico.
Cuando se usa un modelo de permisos de directivas de acceso, si un usuario tiene permisos de Contributor en un plano de administración de Key Vault, se puede conceder a sí mismo acceso al plano de datos estableciendo una directiva de acceso de Key Vault. Debe controlar de forma estricta quién tiene acceso con el rol de Contributor a los almacenes de claves con el modelo de permisos de directivas de acceso, con el fin de garantizar que las personas autorizadas sean las únicas que puedan acceder a los almacenes de claves, las claves, los secretos y los certificados, y administrarlos. Se recomienda usar el nuevo modelo de permiso de control de acceso basado en roles (RBAC) para evitar este problema. Con el modelo de permiso de RBAC, la administración de permisos se limita a los roles "Propietario" y "Administrador de acceso de usuario", lo que permite la separación de tareas entre roles para las operaciones de seguridad y las operaciones administrativas generales.
Control del acceso a datos de Key Vault
Puede controlar el acceso a claves, certificados y secretos de Key Vault mediante RBAC de Azure o directivas de acceso de Key Vault.
Registro y supervisión
Los registros de Key Vault guardan información acerca de las actividades realizadas en el almacén.
Puede integrar Key Vault con Event Grid para recibir notificaciones cuando el estado de una clave, un certificado o un secreto almacenados en Key Vault haya cambiado.
También es importante supervisar el estado del almacén de claves para comprobar que el servicio funciona según lo previsto.
Copia de seguridad y recuperación
La protección frente a la eliminación temporal y la purga de Azure Key Vault permite recuperar almacenes y objetos de almacén eliminados.
También, debe hacer copias de seguridad del almacén periódicamente, cuando actualice, elimine o cree objetos dentro de él.