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’informations d’identification 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 escompté : mise en œuvre d’un mécanisme de gestion sécurisée des informations d’identification des applications permettant d’atteindre 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 au respect de cette bonne pratique :

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

  • L’accès aux informations d’identification est bloqué par le biais d’une API (considérez-la comme un distributeur automatique 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 d’exposition au risque si cette bonne pratique n’est pas respecté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 d’identification à long terme. Par exemple, au lieu du codage en dur une AWS clé d’accès secrète , 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 que AWS Secrets Manager, où ils peuvent être stockés, gérés et subir une rotation de manière centralisée et régulière.

Un audit du code source et des fichiers de configuration de la charge de travail 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 :

Type d’informations d’identification Description Stratégie suggérée
Clés d’accès IAM AWS Accès IAM et clés secrètes utilisés pour assumer des rôles IAM au sein d’une charge de travail Remplacer : utilisez plutôt les rôles IAM attribués aux instances de calcul (telles que Amazon EC2 ou AWS Lambda). Pour l’interopérabilité avec des tiers qui ont besoin d’accéder aux ressources de votre compteCompte AWS, demandez-leur s’ils proposent AWS l’accès intercompte. Pour les applications mobiles, pensez à utiliser des informations d’identification temporaires via les groupes d’identités Amazon Cognito (identités fédérées). Pour les charges de travail exécutées en dehors de AWS, pensez à Rôles Anywhere IAM ou à AWS Systems Manager Hybrid Activations. Pour les conteneurs, consultez le rôle IAM de la tâche Amazon ECS ou le rôle IAM du nœud Amazon EKS.
Clés SSH Clés privées Secure shell utilisées pour se connecter aux instances Linux EC2, manuellement ou dans le cadre d’un processus automatisé Remplacer : utilisez AWS Systems Manager ou EC2 Instance Connect pour fournir un accès programmatique et humain aux instances EC2 à l’aide de rôles IAM.
Informations d’identification d’application et base de données Mots de passe — chaîne de texte brut Rotation : stockez les informations d’identification dans AWS Secrets Manager et établissez une rotation automatique si possible.
Informations d’identification d’administration Amazon RDS et Amazon Aurora Mots de passe — chaîne de texte brut Remplacer : utilisez l’intégration de Secrets Manager avec Amazon RDS ou Amazon Aurora. En outre, certains types de bases de données RDS peuvent utiliser des rôles IAM au lieu de mots de passe dans certains cas d’utilisation (pour plus de détails, voir Authentification de base de données IAM).
Jetons OAuth Jetons secrets — chaîne de texte brut Rotation : stockez les jetons dans AWS Secrets Manager et configurez la rotation automatique.
Jetons et clés API Jetons secrets — chaîne de texte brut Rotation : stockez dans AWS Secrets Manager et établissez une rotation automatique si 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 AWS service, 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, préférez la délégation de l’accès à un rôle IAM disposant de l’accès requis aux ressources de votre compte à la configuration d’un utilisateur IAM et à l’envoi au tiers de la clé d’accès secrète de cet utilisateur.

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

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

Lorsque vous récupérez un secret, vous pouvez utiliser les composants de mise en cache côté client de Secrets Manager pour le mettre en cache en vue d’une utilisation future. Il est plus rapide de récupérer un secret mis en cache que de le récupérer à partir de Secrets Manager. De plus, étant donné que l’appel des API Secrets Manager implique des coûts, l’utilisation d’un cache peut réduire vos coûts. Pour connaître toutes les manières dont vous pouvez récupérer des secrets, consultez Obtenir des secrets.

Note

Certains langages peuvent vous obliger à implémenter votre propre chiffrement en mémoire pour la mise en cache côté client.

É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 qu’Amazon CodeGuru.

    1. Utilisez Amazon CodeGuru pour analyser vos référentiels de code. Une fois l’examen terminé, filtrez sur Type=Secrets dans CodeGuru pour trouver les lignes de code problématiques.

  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 est externe à AWS mais nécessite des informations d’identification IAM pour accéder aux ressources AWS, envisagez d’utiliser Rôles Anywhere IAM ou des activations hybrides AWS Systems Manager.

  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 à partir de Secrets Manager dans votre code d’application.

      1. Les fonctions Lambda sans serveur peuvent utiliser une extension Lambda indépendante du langage.

      2. Pour les instances ou les conteneurs EC2, AWS fournit un exemple de code côté client permettant de récupérer des secrets à partir de Secrets Manager dans plusieurs langages de programmation courants.

  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.

    1. Envisagez l’utilisation d’un outil tel que git-secrets pour éviter l’ajout de nouveaux secrets à votre dépôt de code source.

  5. Surveillez l’activité de Secrets Manager pour détecter tout signe d’utilisation inattendue, d’accès secret inapproprié ou de 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 :