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.

En este artículo se proporciona información general sobre las características de seguridad y los procedimientos recomendados en Azure Key Vault.

Nota:

Para obtener una lista completa de las recomendaciones de seguridad de Azure Key Vault, consulte la línea de base de seguridad de Azure Key Vault.

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. Para conocer los detalles completos, consulte Puntos de conexión de servicio de red virtual en Azure Key Vault.

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. Para conocer los pasos de implementación, consulte Configuración de firewalls y redes virtuales de Azure Key Vault.

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 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. Para conocer los pasos de implementación, consulte Integración de Key Vault con Azure Private Link.

TLS y 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.

Nota:

Puede supervisar la versión de TLS que usan los clientes mediante la supervisión de los registros de Key Vault con una consulta de Kusto de ejemplo aquí.

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 applicationIdno debe especificarse o debe ser null.
• 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 applicationIdno debe especificarse o debe ser null.
• Aplicación y usuario (a veces denominado identidad compuesta): 4el 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 en nombre de (OBO) para suplantar al usuario. Para que este escenario funcione, se deben especificar ambos objetos applicationId y objectId en la directiva de acceso. El elemento applicationId identifica la aplicación necesaria y el elemento objectId identifica al 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. Para más información, revise todo el flujo de autenticación.

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.

Para obtener más información, consulte Aspectos básicos de la autenticación de Key Vault.

Introducción al modelo 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.

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.

Para obtener más información sobre la autenticación en Key Vault, consulte Autenticación en Azure Key Vault.

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.

Para más información, consulte la información general sobre el acceso condicional.

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.

En la siguiente tabla se muestran los puntos de conexión para los planos de administración y datos.

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, backup, restore, purge, rotate (versión preliminar), getrotationpolicy (versión preliminar), setrotationpolicy (versión preliminar), release(versión preliminar) Certificados: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, recover, backup, restore y 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 almacén de claves, debe asignar un rol key vault Contributor predefinido al 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.

Existen varios roles predefinidos. Si un rol predefinido no se ajusta a sus necesidades, puede definir uno propio. Para más información, consulte RBAC de Azure: Roles integrados en Azure.

Importante

Cuando se usa un modelo de permisos de directivas de acceso, si un usuario tiene Contributor, Key Vault Contributor u otro rol con permisos de Microsoft.KeyVault/vaults/write 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.

Para obtener más información, vea

• RBAC de Azure para operaciones del plano de datos de Key Vault.
• Directiva 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. Para obtener información completa, vea Registro de Key Vault.

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. Para más información, consulte Supervisión de Key Vault con Azure Event Grid.

También es importante supervisar el estado del almacén de claves para comprobar que el servicio funciona según lo previsto. Para saber cómo hacerlo, consulte Supervisión y alertas de Azure Key Vault.

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. Para conocer los detalles completos, consulte Introducción a la eliminación temporal en Azure Key Vault.

También, debe hacer copias de seguridad del almacén periódicamente, cuando actualice, elimine o cree objetos dentro de él.

Pasos siguientes

• Línea de base de seguridad de Azure Key Vault
• Procedimientos recomendados de Azure Key Vault
• Puntos de conexión de servicio de red virtual para Azure Key Vault
• RBAC de Azure: roles integrados