Recommandations pour la protection des secrets d’application

  • Article

S’applique à cette recommandation de liste de contrôle de sécurité Azure Well-Architected Framework :

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

Ce guide décrit les recommandations relatives à la sécurisation des informations sensibles dans les applications. Une gestion correcte des secrets est essentielle pour maintenir la sécurité et l’intégrité de votre application, de votre charge de travail et des données associées. Une gestion incorrecte 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 OAuth (Open Authorization) et les clés SSH (Secure Shell) sont des secrets. Certaines informations d’identification, telles que les jetons OAuth côté client, peuvent être créées dynamiquement au moment de l’exécution. Les secrets dynamiques doivent encore être protégés malgré leur nature temporaire. Les informations non confidentielles, telles que les certificats et les clés de signature numérique, peuvent également être sensibles. Les exigences de conformité peuvent entraîner le traitement des paramètres de configuration qui ne sont généralement pas considérés comme des secrets d’application.

Définitions 

Terme Définition
Certificats Fichiers numériques qui contiennent les clés publiques pour le chiffrement ou le déchiffrement.
Titre de compétences 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 aux privilèges minimum Un Confiance nulle principe qui vise à réduire au minimum un ensemble d’autorisations pour effectuer une fonction de travail.
Identité managée Identité affectée aux ressources et gérée par Azure.
Non-secrétaire Informations qui ne compromettent pas la posture de sécurité de la charge de travail si elles sont divulguées.
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 charge de travail. En cas de fuite, les secrets peuvent entraîner une violation.
X.509 Norme qui définit le format des certificats de clé publique.

Important

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

Les paramètres de configuration d’application, tels que les URL des API utilisées par l’application, sont un exemple de non-sécurités. Ces informations ne doivent pas être stockées avec le code d’application ou les secrets d’application. Envisagez d’utiliser un système de gestion de la configuration dédié tel que Azure App Configuration pour gérer ces paramètres. Pour plus d’informations, consultez Qu’est-ce que Azure App Configuration ?.

Stratégies de conception

Votre stratégie de gestion des secrets doit réduire autant que possible les secrets et les intégrer à l’environnement en tirant parti des fonctionnalités de la plateforme. Par exemple, si vous utilisez une identité managée pour votre application, les informations d’accès ne sont pas incorporées dans les chaînes de connexion et il est sûr de stocker les informations dans un fichier de configuration. Tenez compte des domaines de préoccupation suivants avant de stocker et de gérer les 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 conserver une piste d’audit pour inspecter et valider l’accès aux secrets.

Créez une stratégie autour de ces points pour empêcher le vol d’identité, éviter la répudiation et réduire l’exposition inutile à des informations.

Pratiques sécurisées pour la gestion des secrets

Si possible, évitez de créer des secrets. Trouvez des moyens de déléguer la responsabilité à la plateforme. Par exemple, utilisez les identités managées intégrées de la plateforme pour gérer les informations d’identification. Moins de secrets entraînent une réduction de la surface d’exposition et moins de temps consacré à la gestion des secrets.

Nous recommandons que les clés aient trois rôles distincts : utilisateur, administrateur et auditeur. La distinction de rôle permet de s’assurer que seules les identités approuvées ont accès aux secrets avec le niveau d’autorisation approprié. Informez les développeurs, les administrateurs et les autres membres du personnel compétent sur l’importance des meilleures pratiques en matière de gestion des secrets et 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 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 étendues de consommateur peuvent changer au fil du temps, et vous ne pouvez pas mettre à jour les autorisations ou 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.

Cette aide s’applique à 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épartage, veillez à créer plusieurs clés pour prendre en charge plusieurs clients.

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

Stockage secret

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

Les certificats doivent être stockés uniquement dans Key Vault ou dans le magasin de certificats du système d’exploitation. Par exemple, le stockage d’un certificat X.509 dans un fichier PFX ou sur un disque n’est pas recommandé. Si vous avez besoin d’un niveau de sécurité plus élevé, choisissez des systèmes qui ont des fonctionnalités de module de sécurité matériel (HSM) au lieu de magasins de secrets basés sur des logiciels.

Compromis : les solutions HSM sont proposées à un coût plus élevé. Vous pouvez également voir un effet sur les performances de l’application en raison de couches de sécurité supplémentaires.

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 limité via des autorisations. Appliquez toujours l’approche des privilèges minimum 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 étendue de ressource. Créez des limites d’isolation afin qu’un composant puisse uniquement utiliser les secrets dont il a besoin. Si un composant isolé est compromis, il ne peut pas prendre le contrôle d’autres secrets et potentiellement de la charge de travail entière. Une façon d’isoler les secrets consiste à utiliser plusieurs coffres de clés. La création de coffres de clés supplémentaires n’entraîne aucun coût supplémentaire.

Implémentez l’audit et la surveillance pour l’accès aux secrets. Journaliser qui accède aux secrets et quand identifier les activités non autorisées ou suspectes. Pour plus d’informations sur la journalisation du point de vue de la sécurité, consultez Recommandations sur la surveillance de la sécurité et la détection des menaces.

Rotation des secrets

Mettez en place un processus qui maintient l’hygiène secrète. 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 soin, 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, consultez Jetons d’actualisation secure OAuth 2.0 On-Behalf-Of.

Remplacez les secrets après leur fin de vie, ne sont plus utilisés par la charge de travail ou s’ils ont été compromis. À l’inverse, ne retirez pas les secrets actifs, sauf s’il s’agit d’une urgence. Vous pouvez déterminer la status d’un secret en consultant 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.

Pour plus d’informations sur la façon dont stockage Azure gère la rotation, consultez Gérer les clés d’accès au compte.

Les processus de rotation doivent être automatisés et déployés sans aucune interaction humaine. Le stockage des secrets dans un magasin de gestion des secrets qui prend en charge en mode natif les concepts de rotation peut simplifier cette tâche opérationnelle.

Pratiques sécurisées pour l’utilisation des secrets

En tant que générateur ou opérateur de secrets, vous devez être en mesure de distribuer des secrets de manière sécurisée. De nombreuses organisations utilisent des outils pour partager en toute sécurité des secrets à la fois au sein du organization et en externe avec des partenaires. En l’absence d’un outil, disposez d’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. Ayez 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 meilleures pratiques suivantes pour la sécurité lors de l’utilisation de secrets :

Empêcher le codage en dur

Ne codez pas en dur les secrets en tant que texte statique dans les artefacts de code tels que le code d’application, les fichiers de configuration et les pipelines de build-déploiement. Cette pratique à haut risque rend le code vulnérable, car les secrets sont exposés à tous les utilisateurs disposant d’un accès en lecture.

Vous pouvez éviter cette situation en utilisant des identités managées pour éviter d’avoir à stocker des informations d’identification. Votre application utilise son identité affectée pour s’authentifier auprès d’autres ressources via le fournisseur d’identité (IdP). Testez dans des environnements de non-production avec de faux secrets pendant le développement pour éviter l’exposition accidentelle de secrets réels.

Utilisez des outils qui détectent régulièrement les secrets exposés dans votre code d’application et créez des artefacts. Vous pouvez ajouter ces outils en tant que hooks de précommit Git qui recherchent les informations d’identification avant le déploiement des validations de code source. Passez en revue et nettoyez régulièrement les journaux des applications pour vous assurer qu’aucun secret n’est enregistré par inadvertance. Vous pouvez également renforcer la détection via des révisions par les pairs.

Notes

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 charge de travail, vous devez comprendre le plan et les stratégies de rotation des secrets afin de pouvoir incorporer de nouveaux secrets avec une interruption minimale pour les utilisateurs. Lorsqu’un secret est pivoté, il peut y avoir une fenêtre où l’ancien secret n’est pas valide, mais que le nouveau secret n’a pas été placé. Pendant cette fenêtre, le composant que l’application tente d’atteindre ne reconnaît 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 d’avoir plusieurs informations d’identification qui peuvent être modifiées en toute sécurité sans affecter les autres.

Collaborez avec l’équipe des opérations et faites partie du processus de gestion des modifications. Vous devez informer les propriétaires d’informations d’identification lorsque vous désactivez une partie de l’application qui utilise des informations d’identification qui ne sont plus nécessaires.

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

Animation Azure

Stockez les secrets à l’aide de Key Vault. Stockez les secrets dans le système de gestion des secrets Azure, Key Vault, Azure Managed HSM et d’autres emplacements. Pour plus d’informations, consultez Comment choisir la solution de gestion des clés appropriée.

Intégrer le contrôle d’accès basé sur l’identité. l’ID Microsoft Entra et les identités managées permettent de réduire le besoin de secrets. Microsoft Entra ID offre une expérience hautement sécurisée et utilisable pour le contrôle d’accès avec des mécanismes intégrés pour gérer la rotation des clés, pour les anomalies, etc.

Utilisez le contrôle d’accès en fonction du rôle (RBAC) Azure pour attribuer des autorisations aux utilisateurs, aux groupes et aux applications dans une certaine étendue.

Utilisez un modèle d’accès pour contrôler les coffres de clés, les autorisations et les secrets. Pour plus d’informations, consultez Vue d’ensemble du modèle d’accès.

Implémentez la détection de l’exposition aux secrets. Intégrez des processus à votre charge de travail qui détectent les activités suspectes et case activée régulièrement pour les clés exposées dans le code de votre application. Certaines options incluent :

Ne stockez pas de clés et de secrets pour un type d’environnement dans des fichiers de configuration d’application ou des pipelines d’intégration continue et de livraison continue (CI/CD). Les développeurs doivent utiliser Visual Studio Connected Services ou des fichiers locaux uniquement pour accéder aux informations d’identification.

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de sécurité