Recommandations pour la protection des secrets d’application

  • Article

S’applique à cette recommandation de liste de contrôle azure Well-Architected Framework Security :

SE :09 Protégez les secrets d’application en renforcéssant 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. La gestion appropriée 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 toujours être protégés malgré leur nature temporaire. Les informations non référentielles, 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.
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 vous 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èges minimum Un principe Confiance Zéro qui vise à minimiser un ensemble d’autorisations pour terminer une fonction de travail.
Identité managée Identité affectée aux ressources et gérée par Azure.
Non-secret Informations qui ne mettent pas en péril la posture de sécurité de la charge de travail en cas de fuite.
Rotation Le processus de mise à jour régulière des secrets afin que, s’ils soient compromis, ils sont disponibles uniquement pendant 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 provoquer une violation.
X.509 Norme qui définit le format des certificats de clé publique.

Important

Ne traitez pas les non-secrétaires comme les secrets. Les secrets nécessitent une rigueur opérationnelle qui n’est pas nécessaire pour les non-secrets et qui peuvent 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-secrets. 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 configuration dédié tel qu’Azure App Configuration pour gérer ces paramètres. Pour plus d’informations, consultez Qu’est-ce qu’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 dans 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 des chaîne de connexion et il est sûr de stocker les informations dans un fichier de configuration. Tenez compte des domaines 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 aux informations.

Gérer les secrets de charge de travail

Si possible, évitez de créer des secrets. Trouver 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 : l’utilisateur, l’administrateur et l’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 d’autres employés pertinents sur l’importance de la gestion des secrets et des meilleures pratiques de sécurité.

Clés prépartage

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 des consommateurs peuvent changer au fil du temps, et vous ne pouvez pas mettre à jour indépendamment 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 d’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, veuillez consulter la section 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 des secrets dans un environnement renforcé, chiffrer au repos et en transit, et auditer l’accès et les modifications aux secrets. Si vous devez stocker des secrets d’application, conservez-les en dehors du code source pour faciliter la rotation.

Les certificats doivent uniquement être stockés 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é ajoutées.

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. Seules les identités et services 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 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 des secrets dont il a besoin. Si un composant isolé est compromis, il ne peut pas contrôler d’autres secrets et potentiellement la charge de travail entière. Une façon d’isoler les secrets consiste à utiliser plusieurs coffres de clés. Il n’existe aucun coût supplémentaire pour la création de coffres de clés supplémentaires.

Implémentez l’audit et la surveillance pour l’accès secret. Journaliser les personnes qui accèdent 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

Avoir un processus en place 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 supprimés et remplacés par de nouveaux secrets aussi fréquemment que possible.

Gérez soigneusement les jetons d’accès OAuth, en tenant compte de leur temps de vie. Déterminez si la fenêtre d’exposition doit être ajustée à 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 Secure OAuth 2.0 On-Behalf-Of refresh tokens.

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 l’état 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.

Pour plus d’informations sur la façon dont Stockage Azure gère la rotation, consultez Gérer les clés d’accès de 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 les concepts de rotation en mode natif peut simplifier cette tâche opérationnelle.

Utiliser les secrets de charge de travail en toute sécurité

En tant qu’opérateur ou géné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 au sein de l’organisation et en externe avec des partenaires. En l’absence d’un outil, disposez d’un processus permettant de remettre 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 secrète. Avoir 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 des secrets :

Empêcher le codage en dur

Ne codez pas les secrets en dur en tant que texte statique dans les artefacts de code, tels que le code d’application, 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 à tout le monde disposant d’un accès en lecture.

Vous pouvez éviter cette situation en utilisant des identités managées pour éliminer la nécessité de stocker les 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 hors production avec de faux secrets pendant le développement pour empêcher 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éent des artefacts. Vous pouvez ajouter ces outils en tant que crochets de précommit Git qui analysent les informations d’identification avant le déploiement du code source. Passez en revue et désinfectez 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 par le biais de révisions d’homologues.

Remarque

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

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 une interruption minimale pour les utilisateurs. Lorsqu’un secret est pivoté, il peut y avoir une fenêtre lorsque 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 uns 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 dans votre pipeline de déploiement automatisé. La récupération des secrets permet de s’assurer 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 d’application ou la configuration au moment de l’exécution, ce qui empêche les secrets d’être exposés accidentellement aux journaux ou au contrôle de version.

Facilitation 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é. Microsoft Entra ID et 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 la gestion de la rotation des clés, pour les anomalies, etc.

Utilisez le contrôle d’accès en fonction du rôle Azure (RBAC) pour attribuer des autorisations aux utilisateurs, groupes et 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 d’exposition secrète. Intégrez des processus dans votre charge de travail qui détectent les activités suspectes et vérifient régulièrement les clés exposées dans votre code d’application. Certaines options incluent :

Ne stockez pas de clés et de secrets pour n’importe quel type d’environnement dans les fichiers de configuration d’application ou les pipelines d’intégration continue et de livraison continue (CI/CD). Les développeurs doivent utiliser les services connectés Visual Studio ou les 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é