Compartir a través de

Recomendaciones para proteger 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 al proteger su almacenamiento y restringir 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 e integridad de la aplicación, la carga de trabajo y los datos asociados. El control incorrecto de secretos puede provocar infracciones de datos, interrupciones del servicio, infracciones normativas y otros problemas.

Las credenciales, como las claves de API, los tokens de autorización abierta (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 certificados y claves de firma digital, también puede ser confidencial. Los requisitos de cumplimiento pueden provocar que las opciones de configuración que normalmente no se consideren secretas 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.
Credenciales 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 Proceso de actualización periódica de secretos para que, si están en peligro, solo estarán disponibles durante un tiempo limitado.
Secreto Componente confidencial del sistema que facilita la comunicación entre los componentes de la 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 secretos como secretos. Los secretos requieren rigor operativo que no es necesario para los nocretos 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 nocretos. 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 App de Azure Configuración, para administrar estas opciones. Para obtener más información, consulte ¿Qué es App de Azure configuración?.

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 está incrustada en cadena de conexión s y es segura almacenar la información en un archivo de configuración. Tenga en cuenta las siguientes áreas de preocupación 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.

Administración de secretos de carga de trabajo

Si es posible, evite crear secretos. Encuentre 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 lugar a una reducción del área expuesta 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. Eduque 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 previamente compartida. 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 de forma independiente los permisos 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 distintos 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 deben almacenarse 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 de 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, la distribución y el 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 recursos. 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 costos adicionales para crear almacenes de claves adicionales.

Implemente la auditoría y la supervisión del acceso secreto. Registre quién accede a 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 longevidad 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 tiempo de vida. Tenga en cuenta si la ventana de exposición debe ajustarse a un período más corto. Los tokens de actualización deben almacenarse 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, vea 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 la rotación sin problemas.

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

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

Uso de secretos de carga de trabajo de forma segura

Como generador o operador 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 se ve comprometida 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 dura

No almacene secretos de código duro 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 las 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 examinan las credenciales antes de que se implementen las confirmaciones de código fuente. Revise y sane los registros de aplicaciones periódicamente 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 comprometido. Debe revocarse.

Respuesta 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 intenta llegar la aplicación no reconoce las solicitudes. Puede minimizar estos problemas mediante la compilación de 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 las 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 inyecció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, Azure Managed HSM 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. El identificador y las identidades administradas de Microsoft Entra ayudan a minimizar la necesidad de secretos. Microsoft Entra ID ofrece una experiencia altamente 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 los almacenes de claves, los permisos y los 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 las 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