Partager via

Recommandations pour la protection des secrets d’application

  • Article

S’applique à cette recommandation de liste de contrôle Sécurité Power Platform Well-Architected :

SE:07 Protégez les secrets d’application en renforçant leur stockage, en limitant l’accès et la manipulation et en auditant ces actions. Exécutez un processus de rotation fiable et régulier qui permet d’improviser des rotations en cas d’urgence.

Ce guide décrit les recommandations pour sécuriser les informations sensibles dans les charges de travail. Une bonne gestion des secrets est cruciale pour maintenir la sécurité et l’intégrité de votre application, de la charge de travail et des données associées. Une mauvaise gestion des secrets peut entraîner des violations de données, des interruptions de service, des violations réglementaires et d’autres problèmes.

Les informations d’identification, telles que les clés API, les jetons Open Authorization (OAuth) et les clés Secure Shell (SSH), sont des secrets. Les exigences de conformité peuvent entraîner le traitement comme des secrets d’application des paramètres de configuration qui ne sont pas normalement considérés comme des secrets.

Définitions

Terme Définition
Certificats Fichiers numériques contenant les clés publiques pour le chiffrement et le déchiffrement.
Informations d’identification Informations utilisées pour vérifier l’identité de l’éditeur ou du consommateur dans un canal de communication.
Analyse des informations d’identification Processus de validation du code source pour s’assurer que les secrets ne sont pas inclus.
Chiffrement Processus par lequel les données sont rendues illisibles et verrouillées avec un code secret.
Clé Code secret utilisé pour verrouiller ou déverrouiller des données chiffrées.
Accès avec privilège minimal Principe de confiance zéro qui vise à réduire un ensemble d’autorisations pour accomplir une fonction.
Identité managée Identité attribuée aux ressources et gérée par Azure.
Non secret Information qui ne met pas en péril la sécurité de la charge de travail en cas de divulgation.
Rotation Processus de mise à jour régulière des secrets afin que, s’ils sont compromis, ils ne soient disponibles que pour une durée limitée.
Secret Composant confidentiel du système qui facilite la communication entre les composants de la charge de travail. En cas de divulgation, les secrets peuvent provoquer une violation.
X.509 Norme qui définit le format des certificats de clé publique.

Important

Ne traitez pas les non secrets comme des secrets. Les secrets nécessitent une rigueur opérationnelle qui n’est pas nécessaire pour les non secrets et qui peut entraîner des coûts supplémentaires.

Les paramètres de l’application qui ne sont pas des secrets, tels que les URL des API dont l’application a besoin, doivent être maintenus séparés du code ou des secrets de l’application. Pour stocker la configuration de l’application, envisagez d’utiliser un connecteur personnalisé ou des variables d’environnement. Une autre option consiste à utiliser une table Dataverse pour stocker les métadonnées sur la configuration de l’application. Cependant, vous devrez trouver une manière de remplir ces données dans un nouvel environnement, par exemple en transférant les données de configuration du développement au test ou à la production. Vous pouvez utiliser des flux de données pour y parvenir.

Stratégies de conception clés

Tenez compte des domaines de préoccupation suivants avant de stocker et de gérer des secrets :

  • Les secrets créés doivent être conservés dans un stockage sécurisé avec des contrôles d’accès stricts.
  • La rotation des secrets est une opération proactive, tandis que la révocation est réactive.
  • Seules les identités approuvées doivent avoir accès aux secrets.
  • Vous devez maintenir une piste d’audit pour inspecter et valider l’accès aux secrets.

Élaborez une stratégie autour de ces points pour aider à prévenir l’usurpation d’identité, à éviter la répudiation et à réduire l’exposition inutile aux informations.

Pratiques sûres pour la gestion des secrets

Nous recommandons que les clés disposent de trois rôles distincts : utilisateur, administrateur et auditeur. La distinction des rôles permet de garantir que seules les identités approuvées ont accès aux secrets avec le niveau d’autorisation approprié. Sensibilisez les développeurs, les administrateurs et tout autre personnel pertinent sur l’importance de la gestion des secrets et les pratiques recommandées en matière de sécurité.

Clés prépartagées

Vous pouvez contrôler l’accès en créant des clés distinctes pour chaque consommateur. Par exemple, un client, tel qu’une application ou un flux, communique avec une API tierce à l’aide d’une clé prépartagée. Si un autre client doit accéder à la même API, il doit utiliser une autre clé. Ne partagez pas de clés même si deux consommateurs ont les mêmes modèles d’accès ou rôles. Les portées des consommateurs peuvent changer au fil du temps et vous ne pouvez pas mettre à jour de manière indépendante les autorisations ni distinguer les modèles d’utilisation une fois qu’une clé est partagée. L’accès distinct facilite également la révocation. Si la clé d’un consommateur est compromise, il est plus facile de révoquer ou de faire pivoter cette clé sans affecter les autres consommateurs.

Ces conseils s’appliquent à différents environnements. La même clé ne doit pas être utilisée pour les environnements de préproduction et de production. Si vous êtes responsable de la création de clés prépartagées, assurez-vous de créer plusieurs clés pour prendre en charge plusieurs clients.

Pour plus d’informations, voir Recommandations pour la gestion des identités et des accès.

Stockage des secrets

Utilisez un système de gestion des secrets, comme Azure Key Vault, pour stocker les secrets dans un environnement renforcé, chiffrer les secrets au repos et en transit et auditer l’accès et les modifications des secrets. Si vous devez stocker des secrets d’application, conservez-les en dehors du code source pour faciliter la rotation.

Un système de gestion des secrets dédié facilite le stockage, la distribution et le contrôle de l’accès aux secrets d’application. Seuls les services et identités autorisés doivent avoir accès aux magasins de secrets. L’accès au système peut être restreint via des autorisations. Appliquez toujours l’approche du moindre privilège lors de l’attribution d’autorisations.

Vous devez également contrôler l’accès au niveau du secret. Chaque secret ne doit avoir accès qu’à une seule portée de ressource. Créez des limites d’isolement afin qu’un composant puisse uniquement utiliser les secrets dont il a besoin. Si un composant isolé est compromis, il ne peut pas obtenir le contrôle des autres secrets et potentiellement de toute la charge de travail. Une façon d’isoler les secrets consiste à utiliser plusieurs coffres de clés. Il n’y a aucun coût supplémentaire pour la création de coffres de clés supplémentaires.

Implémentez l’audit et la surveillance de l’accès aux secrets. Enregistrez qui accède aux secrets et quand pour identifier une activité non autorisée ou suspecte. Pour plus d’informations sur l’enregistrement du point de vue de la sécurité, voir Recommandations pour la surveillance et la détection des menaces.

Rotation des secrets

Mettez en place un processus qui maintient l’hygiène des secrets. La longévité d’un secret influence la gestion de ce secret. Pour réduire les vecteurs d’attaque, les secrets doivent être retirés et remplacés par de nouveaux secrets aussi souvent que possible.

Gérez les jetons d’accès OAuth avec précaution, en tenant compte de leur durée de vie. Déterminez si la fenêtre d’exposition doit être ajustée sur une période plus courte. Les jetons d’actualisation doivent être stockés en toute sécurité avec une exposition limitée à l’application. Les certificats renouvelés doivent également utiliser une nouvelle clé. Pour plus d’informations sur les jetons d’actualisation, voir Sécuriser les jetons d’actualisation OAuth 2.0 On-Behalf-Of.

Remplacez les secrets une fois qu’ils ont atteint leur fin de vie, qu’ils ne sont plus utilisés par la charge de travail ou qu’ils ont été compromis. À l’inverse, ne retirez pas les secrets actifs, sauf en cas d’urgence. Vous pouvez déterminer le statut d’un secret en affichant les journaux d’accès. Les processus de rotation des secrets ne doivent pas affecter la fiabilité ou les performances de la charge de travail. Utilisez des stratégies qui créent une redondance dans les secrets, les consommateurs et les méthodes d’accès pour une rotation fluide.

Pratiques sûres pour l’utilisation des secrets

En tant que générateur ou opérateur de secrets, vous devriez être en mesure de distribuer des secrets de manière sécurisée. De nombreuses organisations utilisent des outils pour partager des secrets en toute sécurité, tant au sein de l’organisation qu’en externe avec les partenaires. En l’absence d’outil, mettez en place un processus pour transmettre correctement les informations d’identification aux destinataires autorisés. Vos plans de récupération d’urgence doivent inclure des procédures de récupération des secrets. Mettez en place un processus pour les situations où une clé est compromise ou divulguée et doit être régénérée à la demande. Tenez compte des pratiques recommandées suivantes pour la sécurité lorsque vous utilisez des secrets :

Empêcher le codage en dur

Ne codez pas en dur les secrets sous forme de texte statique dans les artefacts de code tels que les flux de cloud et les applications canevas, les fichiers de configuration et les pipelines de déploiement de build. Cette pratique à haut risque rend le code vulnérable car les secrets sont exposés à toute personne disposant d’un accès en lecture.

Utilisez des outils qui détectent régulièrement les secrets exposés dans le code de votre application et créez des artefacts. Vous pouvez ajouter ces outils dans le cadre de vos pipelines de déploiement pour rechercher les informations d’identification avant que le code source valide le déploiement. Examinez et nettoyez régulièrement les journaux d’application pour vous assurer qu’aucun secret n’est enregistré par inadvertance. Vous pouvez également renforcer la détection via des révisions par des pairs.

Note

Si les outils d’analyse découvrent un secret, ce secret doit être considéré comme compromis. Il doit être révoqué.

Répondre à la rotation des secrets

En tant que propriétaire de la charge de travail, vous devez comprendre le plan et les stratégies de rotation des secrets afin de pouvoir incorporer de nouveaux secrets avec le minimum de perturbations pour les utilisateurs. Lors de la rotation d’un secret, il peut y avoir être un intervalle de temps pendant lequel l’ancien secret n’est pas valide, mais que le nouveau secret n’a pas été inséré. Pendant cet intervalle de temps, le composant que la charge de travail tente d’atteindre n’accepte pas les demandes. Vous pouvez réduire ces problèmes en créant une logique de nouvelle tentative dans le code. Vous pouvez également utiliser des modèles d’accès simultanés qui vous permettent de disposer de plusieurs informations d’identification pouvant être modifiées en toute sécurité sans s’affecter mutuellement.

Travaillez avec l’équipe des opérations et participez au processus de gestion des changements. Vous devez informer les propriétaires des informations d’identification lorsque vous désactivez une partie de la charge de travail qui utilise des informations d’identification qui ne sont plus nécessaires.

Intégrez la récupération et la configuration des secrets dans votre pipeline de déploiement automatisé. La récupération des secrets aide à garantir que les secrets sont automatiquement récupérés pendant le déploiement. Vous pouvez également utiliser des modèles d’injection de secrets pour insérer des secrets dans le code ou la configuration de l’application au moment de l’exécution, ce qui empêche les secrets d’être accidentellement exposés aux journaux ou au contrôle de version.

Facilitation de Power Platform

Les sections suivantes décrivent les fonctionnalités et capacités de Power Platform que vous pouvez utiliser pour gérer les secrets d’application.

Utiliser les clés secrètes Azure Key Vault

Les variables d’environnement permettent de référencer les clés secrètes stockées dans Azure Key Vault. Ces clés secrètes sont ensuite mises à disposition pour être utilisées avec les composants , tels que les flux Power Automate et les connecteurs personnalisés. Notez que les secrets ne peuvent pas être utilisés dans d’autres personnalisations ou généralement via l’API.

Les clés secrètes sont uniquement stockées dans Azure Key Vault et la variable d’environnement font simplement référence à l’emplacement de la clé secrète du coffre-fort de clés. L’utilisation de clés secrètes Azure Key Vault avec des variables d’environnement nécessite que vous configuriez Azure Key Vault afin que Power Platform puisse lire les clés secrètes spécifiques que vous souhaitez référencer. Pour plus d’informations, voir Utiliser des variables d’environnement dans les solutions et Utiliser des variables d’environnement dans les connecteurs personnalisés de la solution.

Utiliser le vérificateur de solutions

Avec la fonctionnalité de vérificateur de solution, vous pouvez exécuter une vérification d’analyse statique enrichie de vos solutions par rapport à un ensemble de règles de meilleures pratiques et identifier rapidement ces schémas problématiques. Une fois la vérification terminée, vous recevez un rapport détaillé qui répertorie les problèmes identifiés, les composants et le code affectés, et des liens vers la documentation qui explique comment résoudre chaque problème. Examinez les règles du vérificateur de solutions disponibles dans la catégorie Sécurité. Pour plus d’informations, voir Utiliser le vérificateur de solutions pour valider vos solutions.

Utiliser les actions CyberArk

CyberArk offre une plateforme de sécurité d’identité qui sécurise les identités humaines et machine de bout en bout. Les flux de bureau Power Automate vous permettent de récupérer les informations d’identification de CyberArk. Pour plus d’informations, voir Actions CyberArk.

Voir aussi

Liste de contrôle de sécurité

Référez-vous à l’ensemble complet des recommandations.

Liste de contrôle de sécurité