Consideraciones sobre la administración de claves y secretos en Azure

El cifrado es una herramienta esencial para la seguridad ya que restringe el acceso. Sin embargo, es igualmente importante proteger los secretos (claves, certificados) que proporcionan acceso a los datos.

Puntos clave

• Use el control de acceso basado en la identidad en lugar de claves criptográficas.
• Use algoritmos de cifrado estándar y recomendados.
• Almacene las claves y los secretos en un servicio de almacén de claves administrado. Controle los permisos con un modelo de acceso.
• Rote las claves y otros secretos con frecuencia. Reemplace los secretos expirados o en peligro.

Control de acceso basado en la identidad

Las organizaciones no deben desarrollar y mantener sus propios algoritmos de cifrado. Hay muchas formas de proporcionar el control de acceso mediante recursos de almacenamiento, como los siguientes:

• Claves compartidas
• Firmas compartidas
• Acceso anónimo
• Métodos basados en proveedores de identidades

Los estándares seguros ya existen en el mercado y deberían preferirse. AES debe usarse como cifrado de bloque simétrico, AES-128, AES-192 y AES-256 son aceptables. Las API de criptografía integradas en sistemas operativos deben usarse siempre que sea posible, en lugar de bibliotecas de criptografía que no sean de plataforma. Para .NET, asegúrese de seguir el modelo de criptografía de .NET.

¿Da prioridad la autenticación por medio de servicios de identidad antes que las claves criptográficas para una carga de trabajo?

La protección de las claves criptográficas con frecuencia se puede pasar por alto o poner en práctica de manera deficiente. La administración de las claves de forma segura con código de aplicación es especialmente difícil y puede provocar errores como la publicación accidental de claves de acceso confidenciales en repositorios de código públicos.

Se recomienda usar las opciones basadas en la identidad para el control de acceso al almacenamiento. Esta opción usa controles de acceso basado en roles (RBAC) en los recursos de almacenamiento. Puede usar RBAC para asignar permisos a los usuarios, los grupos y las aplicaciones en un ámbito determinado. Los sistemas de identidad como Azure Active Directory (Azure AD) ofrecen una experiencia segura que se puede usar para el control de acceso, con mecanismos integrados para controlar la rotación de claves, la supervisión de anomalías y mucho más.

Supongamos que necesita almacenar datos confidenciales en Azure Blob Storage. Puede usar Azure AD y RBAC para autenticar una entidad de servicio que tenga los permisos necesarios para acceder al almacenamiento. Para más información sobre la característica, consulte Autorización del acceso a blobs y colas con Azure Active Directory.

Almacenamiento de claves

Para evitar pérdidas de seguridad, almacene las siguientes claves y secretos en un almacén seguro:

• claves de API
• Cadenas de conexión de base de datos
• Claves de cifrado de datos
• Contraseñas

La información confidencial no debe almacenarse en el código ni en la configuración de la aplicación. Un atacante que obtenga acceso de lectura al código fuente no debe conocer los secretos específicos de la aplicación y el entorno.

Almacene todos los secretos y las claves de la aplicación en un servicio de almacén de claves administrado, como Azure Key Vault o HashiCorp Vault. El almacenamiento de claves de cifrado en un almacén administrado limita aún más el acceso. La carga de trabajo puede acceder a los secretos mediante la autenticación en Key Vault con identidades administradas. Ese acceso se puede restringir con RBAC de Azure.

Asegúrese de que no se almacenen claves ni secretos de ningún tipo de entorno (desarrollo, pruebas o producción) en archivos de configuración de la aplicación o canalizaciones de CI/CD. Los desarrolladores pueden usar Servicios conectados de Visual Studio o archivos solo locales para acceder a las credenciales.

Establezca procesos que detecten periódicamente las claves que puedan haberse visto expuestas en el código de la aplicación. Una opción es la tarea Credential Scanner. Para obtener información sobre la tarea de configuración, consulte Tarea de Credential Scanner.

¿Dispone de un modelo de acceso a los almacenes de claves para conceder acceso a las claves y los secretos?

Para proteger el acceso a los almacenes de claves, controle los permisos de claves y secretos mediante un modelo de acceso. Para más información, consulte Introducción al modelo de acceso.

Acciones sugeridas

Considere la posibilidad de usar Azure Key Vault para los secretos y las claves.

Consideraciones acerca de las operaciones

¿Quién tiene la responsabilidad de administrar las claves y los secretos en el contexto de la aplicación?

La rotación de claves y certificados suele ser la causa de las interrupciones en la aplicación. Incluso Azure ha experimentado la expiración de certificados. Es fundamental que la rotación de claves y certificados esté programada y totalmente operativa. El proceso de rotación debe automatizarse y probarse para garantizar la eficacia. Azure Key Vault admite la auditoría y la rotación de claves.

El equipo central de SecOps ofrece orientación sobre cómo se administran las claves y los secretos (gobernanza). El equipo de DevOps de aplicación es responsable de administrar las claves y los secretos relacionados con las aplicaciones.

¿Qué tipos de claves y secretos se usan y cómo se generan?

Entre los enfoques siguientes se incluyen:

• Claves administradas por Microsoft
• Claves administradas por el cliente
• Bring Your Own Key

A menudo, la decisión se basa en los requisitos de seguridad, cumplimiento y clasificación de datos específicos. Para determinar el tipo de claves más adecuado, conviene adquirir un conocimiento claro de estos requisitos.

¿Las claves y los secretos se rotan con frecuencia?

Para reducir los vectores de ataque, los secretos requieren rotación y son propensos a expirar. El proceso debe automatizarse y ejecutarse sin ninguna interacción humana. Si se almacenan en un almacén administrado se simplifican esas tareas operativas mediante el control de la rotación de claves.

Reemplace los secretos una vez que hayan alcanzado el final de su vida útil o si se han visto comprometidos. Los certificados renovados también deben usar una clave nueva. Debe desarrollar un proceso para situaciones en las que las claves se vean comprometidas (filtradas) y tengan que volver a generarse a petición. Por ejemplo, la rotación de secretos en SQL Database.

Para más información, consulte Rotación de claves en Key Vault.

Puede usar identidades administradas para eliminar la sobrecarga operativa y almacenar los secretos o certificados de las entidades de servicio.

¿Se supervisan las fechas de expiración de los certificados SSL/TLS y existen procesos para renovarlas?

Una causa común de interrupción de la aplicación son los certificados SSL/TLS expirados.

Evite interrupciones mediante el seguimiento de las fechas de expiración de los certificados SSL/TLS y su renovación puntual. Lo ideal es automatizar el proceso, aunque a menudo depende de la entidad de certificación (CA) usada. Si no se automatiza, use alertas para asegurarse de que las fechas de expiración no pasen desapercibidas.

Acciones sugeridas

Implemente un proceso para la administración de certificados SSL y el proceso de renovación automatizada con Azure Key Vault.

Más información

Tutorial: Configuración de la rotación automática de certificados en Key Vault

Contenido relacionado

Los servicios de administración de identidades y acceso se autentican y conceden permiso a los siguientes grupos:

• Usuarios
• Asociados
• Clientes
• APLICACIONES
• Servicios
• Otras entidades

Para conocer las consideraciones de seguridad, consulte Consideraciones sobre la administración de identidades y acceso de Azure.

Vuelva al artículo principal: Protección de datos

Pasos siguientes

Proteja los datos en reposo y en tránsito mediante el cifrado. Asegúrese de usar algoritmos de cifrado estándar.