Recomendaciones para proteger los secretos de aplicación
Se aplica a esta recomendación de lista de verificación de seguridad bien diseñada: Power Platform
SE:07 | Proteja los secretos de las aplicaciones reforzando su almacenamiento y restringiendo el acceso y la manipulación, así como auditando dichas acciones. Lleve a cabo un proceso de rotación fiable y regular que pueda improvisar rotaciones para emergencias. |
---|
Esta guía describe las recomendaciones para proteger la información confidencial en cargas de trabajo. Una administración adecuada de los secretos es crucial para mantener la seguridad y la integridad de su aplicación, la carga de trabajo y los datos asociados. La gestión inadecuada de los secretos puede dar lugar a infracciones de datos, interrupciones del servicio, violaciones de la normativa y otros problemas.
Las credenciales, como claves API, tokens de autorización abierta (OAuth) y claves Secure Shell (SSH) son secretos. Los requisitos de cumplimiento pueden hacer que las opciones de configuración que normalmente no se consideran secretas se traten como secretos de aplicación.
Definiciones
Término | Definición |
---|---|
Certificados | Archivos digitales que contienen las claves públicas de cifrado o descifrado. |
Credenciales | Información que se usa para verificar la identidad del editor o del consumidor en un canal de comunicación. |
Escaneado de credenciales | El proceso de validación del código fuente para asegurarse de que no se incluyen secretos. |
Cifrado | Proceso por el que los datos se hacen ilegibles y se bloquean con un código secreto. |
Llave | Un código secreto que se usa para bloquear o desbloquear datos cifrados. |
Acceso de privilegio mínimo | Un principio de confianza cero cuyo objetivo es reducir al mínimo un conjunto de permisos para completar una función de trabajo. |
Identidad administrada | Una identidad asignada a recursos y administrada por Azure. |
No secreto | Información que no pone en peligro la seguridad de la carga de trabajo si se filtra. |
Giro | El proceso de actualizar periódicamente los secretos para que, si se ven comprometidos, solo estén disponibles durante un tiempo limitado. |
Secret | Un 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 brecha. |
X.509 | Norma que define el formato de los certificados de clave pública. |
Importante
No trate los no secretos como secretos. Los secretos requieren un rigor operativo que es innecesario para los no secretos y que podría acarrear costes adicionales.
Las opciones de la aplicación que no son secretos, como las URL de las API que necesita la aplicación, deben mantenerse separadas del código de la aplicación o de los secretos de la aplicación. Para almacenar la configuración de la aplicación, considere la posibilidad de usar un conector personalizado o variables de entorno. Otra opción es usar una tabla de Dataverse para almacenar metadatos sobre la configuración de la aplicación. Sin embargo, tendrá que encontrar la forma de rellenar estos datos en un nuevo entorno, como transferir los datos de configuración de desarrollo a pruebas o producción. Puede usar flujos de datos para lograrlo.
Estrategias clave de diseño
Tenga en cuenta los siguientes aspectos antes de almacenar y administrar secretos:
- Los secretos creados deben guardarse en un lugar seguro con estrictos controles de acceso.
- 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 los secretos.
- Debe mantener un registro de auditoría para inspeccionar y validar el acceso a los secretos.
Cree una estrategia en torno a estos puntos para ayudar a prevenir el robo de identidad, evitar el repudio y minimizar la exposición innecesaria de información.
Prácticas seguras para la administración de secretos
Recomendamos 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 los secretos con el nivel de permiso adecuado. Eduque a los desarrolladores, administradores y demás personal pertinente sobre la importancia de la administración secreta y los procedimientos recomendados en materia de seguridad.
Claves previamente compartidas
Puede controlar el acceso creando claves distintas para cada consumidor. Por ejemplo, un cliente, como una aplicación o un flujo, se comunica con una API de terceros usando una clave precompartida. Si otro cliente necesita acceder a la misma API, deberá usar otra clave. No comparta claves aunque dos consumidores tengan los mismos patrones de acceso o roles. Los ámbitos de consumo pueden cambiar con el tiempo y no se pueden actualizar los permisos de forma independiente ni distinguir los patrones de uso después de compartir una clave. El acceso diferenciado también facilita la revocación. Si la clave de un consumidor se ve comprometida, es más fácil revocarla o rotarla sin afectar a otros consumidores.
Esta indicación se aplica a distintos entornos. No se debe usar la misma clave tanto para entornos de preproducción como de producción. Si es responsable de crear claves precompartidas, asegúrese de crear varias claves para dar soporte a varios clientes.
Para obtener más información, consulte Recomendaciones para la administración de identidad y acceso.
Almacenamiento de secretos
Utilice un sistema de administración de secretos, como Azure Key Vault, para almacenar secretos en un ambiente reforzado, cifrarlos en reposo y en tránsito, y auditar el acceso y los cambios a los secretos. Si necesita almacenar secretos de aplicación, manténgalos fuera del código fuente para facilitar su rotación.
Un sistema dedicado de administración de secretos facilita el almacenamiento, la distribución y el control del acceso a los secretos de aplicación. Solo las identidades y los servicios autorizados deben tener acceso a los almacenes de secretos. El acceso al sistema puede restringirse mediante permisos. Aplique siempre el enfoque del menor privilegio a la hora de asignar permisos.
También debe controlar el acceso en el nivel de secretos. Cada secreto solo debe tener acceso a un único ámbito de recursos. Cree límites de aislamiento para que un componente solo pueda usar los secretos que necesite. Si un componente aislado se ve comprometido, no puede obtener el control de otros secretos y potencialmente de toda la carga de trabajo. Una forma de aislar los secretos es usar varios almacenes de claves. No hay costes añadidos por crear almacenes de claves adicionales.
Implemente auditorías y supervise el acceso a los secretos. Registre quién accede a los secretos y cuándo para identificar actividades no autorizadas o sospechosas. Para obtener información sobre el registro desde el punto de vista de la seguridad, consulte Recomendaciones para supervisar y detectar amenazas.
Rotación de secretos
Disponga de un proceso que mantenga los secretos en buen estado. La longevidad de un secreto influye en su administración. Para reducir los vectores de ataque, los secretos deben retirarse y reemplazarse por otros nuevos con la mayor frecuencia posible.
Maneje los tokens de acceso con cuidado, teniendo en cuenta su tiempo de vida. OAuth Considere si es necesario ajustar el intervalo de exposición a un periodo 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 nueva clave. Para obtener información sobre los tokens de actualización, consulte Tokens de actualización en nombre de Secure OAuth 2.0.
Reemplace los secretos cuando lleguen al final de su vida útil, cuando ya no los use la carga de trabajo o si se han visto comprometidos. A la inversa, no retire los secretos activos a menos que se trate de una emergencia. Puede determinar el estado de un secreto si consulta los registros de acceso. Los procesos de rotación secreta no deberían afectar a la fiabilidad ni al rendimiento de la carga de trabajo. Use estrategias que creen redundancia en los secretos, los consumidores y los métodos de acceso para conseguir una rotación fluida.
Prácticas seguras para usar secretos
Como generador u operador de secretos, debe ser capaz de distribuirlos de forma segura. Muchas organizaciones usan herramientas para compartir secretos de forma segura tanto dentro de la organización como externamente a los partners. En ausencia de una herramienta, disponga de un proceso para entregar correctamente las credenciales a los destinatarios autorizados. Sus planes de recuperación ante desastres deben incluir procedimientos de recuperación de secretos. Disponga de un proceso para situaciones en las que una clave se vea comprometida o se filtre y sea necesario regenerarla a petición. Tenga en cuenta los siguientes procedimientos recomendados para su seguridad al usar secretos:
Evitar la codificación rígida
No codifique secretos como texto estático en artefactos de código como flujos de nube y aplicaciones de lienzo, archivos de configuración y canalizaciones de compilación e implementación. Esta práctica de alto riesgo hace que el código sea vulnerable porque los secretos están expuestos a todo el que tenga acceso de lectura.
Utilice herramientas que detecten periódicamente secretos expuestos en el código de su aplicación y creen artefactos. Puede agregar estas herramientas como parte de sus canalizaciones de implementación para buscar credenciales antes de implementar las confirmaciones de código fuente. Revise y sanee los registros de las aplicaciones con regularidad para asegurarse de que no se registra ningún secreto de forma inadvertida. También puede reforzar la detección mediante revisiones entre pares.
Nota
Si las herramientas de exploración descubren un secreto, ese secreto debe considerarse comprometido. Se debe revocar.
Responder a la rotación de secretos
Como propietario de la carga de trabajo, debe comprender el plan y las directivas de rotación de secretos para poder incorporar nuevos secretos con el mínimo trastorno para los usuarios. Cuando se rota un secreto, puede haber una ventana en la que el antiguo secreto no sea válido, pero el nuevo secreto no se haya colocado. Durante ese intervalo, el componente al que intenta llegar la carga de trabajo no acepta las solicitudes. Puede minimizar estos problemas si incorpora una lógica de reintento en el código. También puede usar patrones de acceso simultáneo que le permitan tener varias credenciales que puedan cambiarse 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 las credenciales cuando dé de baja una parte de la carga de trabajo que usa credenciales que ya no son necesarias.
Integre la recuperación de secretos y la configuración en su canalización de implementación automatizada. La recuperación de secretos ayuda a garantizar que los secretos se recuperen automáticamente durante la implementación. También puede usar patrones de inyección de secretos para insertar secretos en el código o la configuración de la aplicación en tiempo de ejecución, lo que evita que los secretos queden expuestos accidentalmente a los registros o al control de versiones.
Facilitación de Power Platform
Las siguientes secciones describen características y capacidades de Power Platform que puede usar para administrar secretos de aplicación.
Usar secretos de Azure Key Vault
Las variables de entorno permiten hacer referencia a secretos almacenados en Azure Key Vault. Estos secretos se ponen a disposición para su uso dentro de flujos y conectores personalizados de Power Automate. Tenga en cuenta que los secretos no están disponibles para usarlos en otras personalizaciones o, en general, a través de la API.
Los secretos reales solo se almacenan en Azure Key Vault y la variable de entorno simplemente hace referencia a la ubicación de los secretos del almacén de claves. El uso de secretos de Azure Key Vault con variables de entorno requiere que configure Azure Key Vault para que Power Platform pueda leer los secretos específicos a los que desea hacer referencia. Para obtener más información, consulte Usar variables de entorno en soluciones y Usar variables de entorno en conectores personalizados de solución.
Usar el comprobador de soluciones
Con la característica del comprobador de soluciones puede realizar una completa verificación de análisis estático de sus soluciones con un conjunto de reglas de prácticas recomendadas e identificar rápidamente estos patrones problemáticos. Cuando la comprobación se completa, usted recibe un informe detallado que lista los problemas identificados, los componentes y el código afectados y vínculos a la documentación que describe cómo solucionar cada problema. Revise las reglas del comprobador de soluciones disponibles en la categoría Seguridad. Para obtener más información, consulte Usar el comprobador de soluciones para validar sus soluciones.
Usar acciones de CyberArk
CyberArk ofrece una plataforma de seguridad de identidades que protege las identidades de personas y de máquinas de un extremo a otro. Los flujos de escritorio de Power Automate le permiten recuperar credenciales de CyberArk. Para obtener más información, consulte Acciones de CyberArk.
Información relacionada
- Utilice las variables ambiente en las soluciones
- Utilice las variables ambiente en los conectores personalizados de la solución
- Utilice el verificador de soluciones para validar sus soluciones
- CyberArk comportamiento
- Azure DevOps Escáner de credenciales tarea
- Configurar la extensión de seguridad DevOps Microsoft Azure DevOps
- Configurar la seguridad avanzada de GitHub para Azure DevOps
- Recomendaciones para el monitoreo y detección de amenazas
- Recomendaciones para la gestión de identidad y acceso
Lista de verificación de seguridad
Consulte el conjunto completo de recomendaciones.