Recomendaciones para proteger los secretos de aplicación

  • Artículo

Se aplica a esta recomendación de lista de comprobación de seguridad de Azure Well-Architected Framework:

SE:09 Proteja los secretos de aplicación protegiendo su almacenamiento y restringiendo el acceso y la manipulación y auditando esas acciones. Ejecute un proceso de rotación confiable y regular que pueda improvisar rotaciones para emergencias.

En esta guía se describen las recomendaciones para proteger la información confidencial en las aplicaciones. La administración adecuada de secretos es fundamental para mantener la seguridad y la integridad de la aplicación, la carga de trabajo y los datos asociados. El control incorrecto de los secretos puede provocar infracciones de datos, interrupciones del servicio, infracciones normativas y otros problemas.

Las credenciales, como las claves de API, los tokens de Open Authorization (OAuth) y las claves de Secure Shell (SSH) son secretos. Algunas credenciales, como los tokens de OAuth del lado cliente, se pueden crear dinámicamente en tiempo de ejecución. Los secretos dinámicos todavía deben protegerse a pesar de su naturaleza temporal. La información no inicial, como los certificados y las claves de firma digital, también puede ser confidencial. Los requisitos de cumplimiento pueden provocar que los valores de configuración que no se consideran secretos normalmente se traten como secretos de aplicación.

Definiciones 

Término Definición
Certificados Archivos digitales que contienen las claves públicas para el cifrado o descifrado.
Credencial Información que se usa para comprobar la identidad del publicador o consumidor en un canal de comunicación.
Exploración de credenciales Proceso de validación del código fuente para asegurarse de que no se incluyen los secretos.
Cifrado Proceso por el que los datos se convierten en ilegibles y bloqueados con un código secreto.
Clave Código secreto que se usa para bloquear o desbloquear datos cifrados.
Acceso con privilegios mínimos Principio de Confianza cero que pretende minimizar un conjunto de permisos para completar una función de trabajo.
Identidad administrada Una identidad asignada a los recursos y administrada por Azure.
Nonsecret Información que no pone en peligro la posición de seguridad de la carga de trabajo si se filtra.
Rotación El proceso de actualización periódica de secretos para que, si están en peligro, solo están disponibles durante un tiempo limitado.
Secreto Componente confidencial del sistema que facilita la comunicación entre componentes de carga de trabajo. Si se filtran, los secretos pueden provocar una infracción.
X.509 Estándar que define el formato de los certificados de clave pública.

Importante

No trate los nosecretos como secretos. Los secretos requieren rigor operativo que no es necesario para los nosecretos y que pueden dar lugar a costos adicionales.

Las opciones de configuración de la aplicación, como las direcciones URL de las API que usa la aplicación, son un ejemplo de nosecretos. Esta información no se debe almacenar con el código de aplicación ni los secretos de aplicación. Considere la posibilidad de usar un sistema de administración de configuración dedicado, como Azure App Configuration, para administrar esta configuración. Para obtener más información, vea ¿Qué es Azure App Configuration?.

Estrategias de diseño principales

La estrategia de administración de secretos debe minimizar los secretos tanto como sea posible e integrarlos en el entorno aprovechando las características de la plataforma. Por ejemplo, si usa una identidad administrada para la aplicación, la información de acceso no se inserta en cadenas de conexión y es seguro almacenar la información en un archivo de configuración. Tenga en cuenta las siguientes áreas de interés antes de almacenar y administrar secretos:

  • Los secretos creados deben mantenerse en un almacenamiento seguro con controles de acceso estrictos.

  • La rotación de secretos es una operación proactiva, mientras que la revocación es reactiva.

  • Solo las identidades de confianza deben tener acceso a secretos.

  • Debe mantener una pista de auditoría para inspeccionar y validar el acceso a los secretos.

Cree una estrategia en torno a estos puntos para ayudar a evitar el robo de identidad, evitar el rechazo y minimizar la exposición innecesaria a la información.

Procedimientos seguros para la administración de secretos

Si es posible, evite crear secretos. Busque formas de delegar la responsabilidad en la plataforma. Por ejemplo, use las identidades administradas integradas de la plataforma para controlar las credenciales. Menos secretos dan como resultado un área expuesta reducida y menos tiempo invertido en la administración de secretos.

Se recomienda que las claves tengan tres roles distintos: usuario, administrador y auditor. La distinción de roles ayuda a garantizar que solo las identidades de confianza tengan acceso a secretos con el nivel de permiso adecuado. Instruir a los desarrolladores, administradores y a otro personal relevante sobre la importancia de la administración de secretos y los procedimientos recomendados de seguridad.

Claves previamente compartidas

Puede controlar el acceso mediante la creación de claves distintas para cada consumidor. Por ejemplo, un cliente se comunica con una API de terceros mediante una clave precompartida. Si otro cliente necesita acceder a la misma API, debe usar otra clave. No comparta claves aunque dos consumidores tengan los mismos patrones de acceso o roles. Los ámbitos de consumidor pueden cambiar con el tiempo y no se pueden actualizar los permisos de forma independiente ni distinguir patrones de uso después de compartir una clave. El acceso distinto también facilita la revocación. Si la clave de un consumidor está en peligro, es más fácil revocar o rotar esa clave sin afectar a otros consumidores.

Esta guía se aplica a diferentes entornos. No se debe usar la misma clave para entornos de preproducción y producción. Si es responsable de crear claves previamente compartidas, asegúrese de crear varias claves para admitir varios clientes.

Para obtener más información, consulte Recomendaciones para la administración de identidades y acceso.

Almacenamiento de secretos

Use un sistema de administración de secretos, como Azure Key Vault, para almacenar secretos en un entorno protegido, cifrar en reposo y en tránsito, y auditar el acceso y los cambios en los secretos. Si necesita almacenar secretos de aplicación, manténgalos fuera del código fuente para facilitar la rotación.

Los certificados solo se deben almacenar en Key Vault o en el almacén de certificados del sistema operativo. Por ejemplo, no se recomienda almacenar un certificado X.509 en un archivo PFX o en un disco. Si necesita un mayor nivel de seguridad, elija sistemas que tengan funcionalidades del módulo de seguridad de hardware (HSM) en lugar de almacenes secretos basados en software.

Compensación: las soluciones HSM se ofrecen a un costo mayor. También puede ver un efecto en el rendimiento de la aplicación debido a capas de seguridad agregadas.

Un sistema de administración de secretos dedicado facilita el almacenamiento, distribución y control del acceso a los secretos de aplicación. Solo las identidades y servicios autorizados deben tener acceso a almacenes secretos. El acceso al sistema se puede restringir a través de permisos. Aplique siempre el enfoque con privilegios mínimos al asignar permisos.

También debe controlar el acceso en el nivel de secreto. Cada secreto solo debe tener acceso a un único ámbito de recurso. Cree límites de aislamiento para que un componente solo pueda usar secretos que necesita. Si un componente aislado está en peligro, no puede obtener el control de otros secretos y potencialmente toda la carga de trabajo. Una manera de aislar secretos es usar varios almacenes de claves. No hay ningún costo adicional para crear almacenes de claves adicionales.

Implemente la auditoría y la supervisión del acceso secreto. Registre quién accede a los secretos y cuándo identificar actividades no autorizadas o sospechosas. Para obtener información sobre el registro desde una perspectiva de seguridad, consulte Recomendaciones sobre la supervisión de la seguridad y la detección de amenazas.

Rotación de secretos

Tener un proceso en su lugar que mantenga la higiene secreta. La durabilidad de un secreto influye en la gestión de ese secreto. Para reducir los vectores de ataque, los secretos se deben retirar y reemplazar por nuevos secretos con la mayor frecuencia posible.

Controle cuidadosamente los tokens de acceso de OAuth, teniendo en cuenta su período de vida. Considere si la ventana de exposición debe ajustarse a un período más corto. Los tokens de actualización se deben almacenar de forma segura con una exposición limitada a la aplicación. Los certificados renovados también deben usar una clave nueva. Para obtener información sobre los tokens de actualización, consulte Protección de tokens de actualización de OAuth 2.0 en nombre de .

Reemplace los secretos después de que lleguen a su fin de vida, ya no los use la carga de trabajo o si se han puesto en peligro. Por el contrario, no retire secretos activos a menos que sea una emergencia. Para determinar el estado de un secreto, consulte los registros de acceso. Los procesos de rotación de secretos no deben afectar a la confiabilidad ni al rendimiento de la carga de trabajo. Use estrategias que generen redundancia en secretos, consumidores y métodos de acceso para una rotación fluida.

Para más información sobre cómo Azure Storage controla la rotación, consulte Administración de claves de acceso de la cuenta.

Los procesos de rotación deben automatizarse e implementarse sin ninguna interacción humana. El almacenamiento de secretos en un almacén de administración de secretos que admite de forma nativa los conceptos de rotación puede simplificar esta tarea operativa.

Procedimientos seguros para usar secretos

Como generador o operador de secretos, debe poder distribuir secretos de forma segura. Muchas organizaciones usan herramientas para compartir secretos de forma segura tanto dentro de la organización como externamente a los asociados. En ausencia de una herramienta, tiene un proceso para entregar correctamente las credenciales a los destinatarios autorizados. Los planes de recuperación ante desastres deben incluir procedimientos de recuperación secreta. Tener un proceso para situaciones en las que una clave está en peligro o filtrada y debe volver a generarse a petición. Tenga en cuenta los siguientes procedimientos recomendados para la seguridad al usar secretos:

Evitar la codificación de forma hardcoding

No bloquee los secretos de código como texto estático en artefactos de código, como código de aplicación, archivos de configuración y canalizaciones de implementación de compilación. Esta práctica de alto riesgo hace que el código sea vulnerable porque los secretos se exponen a todos los usuarios con acceso de lectura.

Puede evitar esta situación mediante el uso de identidades administradas para eliminar la necesidad de almacenar credenciales. La aplicación usa su identidad asignada para autenticarse en otros recursos a través del proveedor de identidades (IdP). Pruebe en entornos que no son de producción con secretos falsos durante el desarrollo para evitar la exposición accidental de secretos reales.

Use herramientas que detecten periódicamente secretos expuestos en el código de la aplicación y compilen artefactos. Puede agregar estas herramientas como enlaces de confirmación previa de Git que buscan credenciales antes de que se implementen las confirmaciones del código fuente. Revise y sane los registros de aplicaciones con regularidad para ayudar a garantizar que no se registren accidentalmente secretos. También puede reforzar la detección a través de revisiones del mismo nivel.

Nota

Si las herramientas de examen detectan un secreto, ese secreto debe considerarse en peligro. Debe revocarse.

Responder a la rotación de secretos

Como propietario de la carga de trabajo, debe comprender el plan de rotación de secretos y las directivas para poder incorporar nuevos secretos con una interrupción mínima a los usuarios. Cuando se gira un secreto, puede haber una ventana cuando el secreto anterior no es válido, pero no se ha colocado el nuevo secreto. Durante esa ventana, el componente al que la aplicación intenta acceder no reconoce las solicitudes. Para minimizar estos problemas, cree lógica de reintento en el código. También puede usar patrones de acceso simultáneos que le permitan tener varias credenciales que se pueden cambiar de forma segura sin afectarse entre sí.

Trabaje con el equipo de operaciones y forme parte del proceso de administración de cambios. Debe informar a los propietarios de credenciales cuando retire una parte de la aplicación que usa credenciales que ya no son necesarias.

Integre la recuperación y configuración de secretos en la canalización de implementación automatizada. La recuperación de secretos ayuda a garantizar que los secretos se capturan automáticamente durante la implementación. También puede usar patrones de inserción de secretos para insertar secretos en el código de aplicación o la configuración en tiempo de ejecución, lo que impide que los secretos se expongan accidentalmente a registros o control de versiones.

Facilitación de Azure

Almacene secretos mediante Key Vault. Almacene secretos en el sistema de administración de secretos de Azure, Key Vault, HSM administrado de Azure y otras ubicaciones. Para obtener más información, consulte Cómo elegir la solución de administración de claves adecuada.

Integre el control de acceso basado en identidades. Microsoft Entra identificador e identidades administradas ayudan a minimizar la necesidad de secretos. Microsoft Entra id. ofrece una experiencia muy segura y utilizable para el control de acceso con mecanismos integrados para controlar la rotación de claves, para anomalías y mucho más.

Use el control de acceso basado en rol (RBAC) de Azure para asignar permisos a usuarios, grupos y aplicaciones en un ámbito determinado.

Use un modelo de acceso para controlar almacenes de claves, permisos y secretos. Para más información, consulte Introducción al modelo de acceso.

Implemente la detección de exposición secreta. Integre los procesos de la carga de trabajo que detecten actividad sospechosa y compruebe periódicamente las claves expuestas en el código de la aplicación. Entre estas opciones se incluyen:

No almacene claves y secretos para ningún tipo de entorno en los archivos de configuración de la aplicación ni en canalizaciones de integración continua y entrega continua (CI/CD). Los desarrolladores deben usar servicios conectados de Visual Studio o archivos solo locales para acceder a las credenciales.

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de seguridad