SEC02-BP03 Stocker et utiliser des secrets en toute sécurité - Pilier Sécurité
Directives d'implémentationRessources

SEC02-BP03 Stocker et utiliser des secrets en toute sécurité

Une charge de travail nécessite une capacité automatisée pour prouver son identité aux bases de données, aux ressources et aux services tiers. Cela se fait à l'aide d'identifiants d'accès secrets, tels que des clés d'accès à l'API, des mots de passe et des jetons OAuth. L'utilisation d'un service spécialement conçu pour stocker, gérer et faire tourner ces informations d'identification permet de réduire les risques de compromission de ces informations d'identification.

Résultat souhaité : implémentation d'un mécanisme de gestion sécurisée des informations d'identification des applications qui atteint les objectifs suivants :

  • Identification des secrets nécessaires pour la charge de travail.

  • Réduction du nombre d'informations d'identification à long terme requis en les remplaçant par des informations d'identification à court terme, dans la mesure du possible.

  • Établissement d'un stockage sécurisé et d'une rotation automatisée des informations d'identification à long terme restantes.

  • Audit de l'accès aux secrets qui existent dans la charge de travail.

  • Surveillance continue pour vérifier qu'aucun secret n'est intégré dans le code source pendant le processus de développement.

  • Réduction des risques de divulgation des informations d'identification par inadvertance.

Anti-modèles courants :

  • Aucune rotation des informations d'identification.

  • Stockage des informations d'identification à long terme dans le code source ou les fichiers de configuration.

  • Stockage des informations d'identification au repos non chiffrées.

Avantages liés à l'instauration de cette bonne pratique :

  • Les secrets sont chiffrés au repos et en transit.

  • L'accès aux informations d'identification est sécurisé par une API (il s'agit plus ou moins d'un distributeur d'informations d'identification).

  • L'accès à une information d'identification (en lecture et en écriture) est audité et consigné.

  • Séparation des préoccupations : la rotation des informations d'identification est effectuée par un composant distinct, qui peut être séparé du reste de l'architecture.

  • Les secrets sont distribués automatiquement à la demande aux composants logiciels et la rotation se produit dans un emplacement central.

  • L'accès aux informations d'identification peut être contrôlé de façon précise.

Niveau de risque exposé si cette bonne pratique n'est pas instaurée : élevé

Directives d'implémentation

Dans le passé, les informations d'identification utilisées pour s'authentifier auprès des bases de données, des API tierces, des jetons et d'autres secrets pouvaient être intégrées dans du code source ou des fichiers d'environnement. AWS fournit plusieurs mécanismes pour stocker ces informations d'identification en toute sécurité, en effectuer la rotation automatiquement et vérifier leur utilisation.

Pour gérer les secrets de façon optimale, la meilleure solution consiste à suivre les directives de suppression, de remplacement et de rotation. Les informations d'identification les plus sûres sont celles que vous n'avez pas à stocker, gérer ou manipuler. Certaines informations d'identification qui ne sont plus nécessaires au fonctionnement de la charge de travail peuvent être supprimées en toute sécurité.

Pour les informations d'identification qui restent nécessaires au bon fonctionnement de la charge de travail, il peut être possible d'opter pour une solution temporaire ou à court terme au lieu d'utiliser des informations à long terme. Par exemple, au lieu de coder en dur une clé d'accès secrète AWS, envisagez de remplacer les informations d'identification à long terme par des informations d'identification temporaires à l'aide de rôles IAM.

Certains secrets de longue durée ne peuvent pas être supprimés ni remplacés. Ces secrets peuvent être stockés dans un service tel qu'AWS Secrets Manager, où ils peuvent être stockés, gérés et mis en rotation de façon centralisée.

Un audit du code source de la charge de travail et des fichiers de configuration peut révéler de nombreux types d'informations d'identification. Le tableau suivant résume les stratégies de traitement des types courants d'informations d'identification :

Credential type Description Suggested strategy
IAM access keys AWS IAM access and secret keys used to assume IAM roles inside of a workload Replace: Use Rôles IAM assigned to the compute instances (such as Amazon EC2 or AWS Lambda) instead. For interoperability with third parties that require access to resources in your Compte AWS, ask if they support Accès intercompte AWS. For mobile apps, consider using temporary credentials through Groupes d'identités Amazon Cognito (identités fédérées). For workloads running outside of AWS, consider IAM Roles Anywhere or AWS Systems Manager Hybrid Activations.
SSH keys Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process Replace: Use AWS Systems Manager or EC2 Instance Connect to provide programmatic and human access to EC2 instances using IAM roles.
Application and database credentials Passwords – plain text string Rotate: Store credentials in AWS Secrets Manager and establish automated rotation if possible.
Amazon RDS and Aurora Admin Database credentials Passwords – plain text string Replace: Use the Intégration d'Secrets Manager à Amazon RDS or Amazon Aurora. In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see Authentification de base de données IAM).
OAuth tokens Secret tokens – plain text string Rotate: Store tokens in AWS Secrets Manager and configure automated rotation.
API tokens and keys Secret tokens – plain text string Rotate: Store in AWS Secrets Manager and establish automated rotation if possible.

Parmi les anti-modèles courants, citons l'intégration des clés d'accès IAM dans le code source, les fichiers de configuration ou les applications mobiles. Lorsqu'une clé d'accès IAM est requise pour communiquer avec un service AWS, utilisez des informations d'identification de sécurité temporaires (à court terme). Ces informations d'identification à court terme peuvent être fournies via des rôles IAM pour les instances EC2, des rôles d'exécution pour les fonctions Lambda, des rôles IAM Cognito pour l'accès des utilisateurs mobiles et des politiques IoT Core pour les appareils IoT. Lorsque vous interagissez avec des tiers, privilégiez la délégation des accès à un rôle IAM avec l'accès nécessaire aux ressources de votre compte au lieu de configurer un utilisateur IAM et d'envoyer au tiers la clé d'accès secrète pour cet utilisateur.

Dans de nombreux cas, la charge de travail exige le stockage de secrets nécessaires pour interagir avec d'autres services et ressources. AWS Secrets Manager est conçu pour gérer en toute sécurité ces informations d'identification, ainsi que le stockage, l'utilisation et la rotation des jetons d'API, mots de passe et autres informations d'identification.

AWS Secrets Manager fournit cinq capacités clés pour assurer le stockage et la manipulation sécurisés des informations d'identification sensibles : chiffrement au repos, chiffrement en transit, audit complet, contrôle d'accès détaillé et rotation extensible des informations d'identification. D'autres services de gestion des secrets créés par des partenaires AWS ou des solutions développées localement qui offrent des capacités et des assurances similaires sont également acceptables.

Étapes d'implémentation

  1. Identifiez les chemins de code contenant des informations d'identification codées en dur à l'aide d'outils automatisés tels que Amazon CodeGuru.

    • Utilisez Amazon CodeGuru pour analyser vos référentiels de code. Une fois la vérification terminée, filtrez sur Type=Secrets dans CodeGuru afin de trouver les lignes de code qui posent problème.

  2. Identifiez les informations d'identification qui peuvent être supprimées ou remplacées.

    1. Identifiez les informations d'identification qui ne sont plus nécessaires et marquez-les en vue de leur suppression.

    2. Pour les clés secrètes AWS qui sont intégrées au code source, remplacez-les par des rôles IAM associés aux ressources nécessaires. Si une partie de votre charge de travail se trouve en dehors d'AWS mais requiert des informations d'identification IAM pour accéder aux ressources AWS, envisagez l'utilisation d'IAM Roles Anywhere ou d'AWS Systems Manager Hybrid Activations.

  3. Pour les autres secrets tiers de longue durée qui nécessitent l'utilisation de la stratégie de rotation, intégrez Secrets Manager dans votre code afin d'extraire les secrets tiers au moment de l'exécution.

    1. La console CodeGuru peut créer automatiquement un secret dans Secrets Manager à l'aide des informations d'identification découvertes.

    2. Intégrez l'extraction des secrets d'Secrets Manager dans votre code d'application.

  4. Examinez régulièrement votre base de code et effectuez une nouvelle analyse afin de vérifier qu'aucun nouveau secret n'a été ajouté au code.

    • Envisagez d'utiliser un outil tel que git-secrets pour éviter d'intégrer de nouveaux secrets dans votre référentiel de code source.

  5. Surveillez l'activité d'Secrets Manager afin de détecter toute utilisation inattendue, tout accès aux secrets inapproprié ou toute tentative de suppression de secrets.

  6. Réduisez l'exposition humaine aux informations d'identification. Limitez l'accès à la lecture, à l'écriture et à la modification des informations d'identification à un rôle IAM dédié à cette fin et fournissez un accès uniquement pour assumer le rôle à un petit sous-ensemble d'utilisateurs opérationnels.

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Ateliers connexes :