Jeton secret aws

par Sreedar Radhakrishnan, Akshay Aggarwal et Zachary Milleron dans Advanced (300), AWS Identity and Access Management (IAM), AWS Secrets Manager, Best Practices, Security, Identity, & Compliance, Technical How-toPermalink Comments Share

AWS Secrets Manager vous aide à gérer, récupérer et faire pivoter les informations d’identification de base de données, les clés API et d’autres secrets tout au long de leur cycle de vie. Vous utilisez peut-être déjà Secrets Manager pour stocker et gérer des secrets dans vos applications basées sur Amazon Web Services (AWS), mais qu’en est-il des secrets pour les applications hébergées dans votre centre de données sur site ou hébergées par un autre fournisseur de services cloud ? Vous pouvez même être en train de déplacer des applications hors de votre centre de données dans le cadre d’une migration par phases, où l’application est partiellement dans AWS, mais d’autres composants restent Restez dans votre centre de données jusqu’à ce que la migration soit terminée. Dans cet article de blog, nous décrirons les avantages potentiels de l’utilisation de Secrets Manager pour les charges de travail en dehors d’AWS, décrirons certaines pratiques recommandées pour l’utilisation de Secrets Manager pour les charges de travail hybrides et fournirons un exemple d’application de base pour mettre en évidence comment authentifier et récupérer en toute sécurité des secrets à partir de Secrets Manager dans une charge de travail multicloud.

Pour effectuer un appel d’API afin de récupérer des secrets à partir du Gestionnaire de secrets, vous avez besoin d’informations d’identification IAM. Bien qu’il soit possible d’utiliser un utilisateur AWS Identity and Access Management (IAM), AWS recommande d’utiliser des informations d’identification temporaires ou de courte durée dans la mesure du possible afin de réduire l’impact d’une identification exposée. Cela signifie que nous permettrons à notre application hybride d’assumer un rôle IAM dans cet exemple. Nous utiliserons IAM Roles Anywhere pour fournir un mécanisme permettant à nos applications en dehors d’AWS d’assumer un rôle IAM basé sur une approbation configurée auprès de notre autorité de certification (CA).

IAM Roles Anywhere offre une solution permettant aux applications sur site ou multicloud d’acquérir des informations d’identification AWS temporaires, ce qui permet d’éliminer la nécessité de créer et de gérer des informations d’identification AWS à long terme. Cette suppression des informations d’identification à long terme renforce la sécurité et rationalise le processus opérationnel en réduisant la charge de la gestion et de la rotation des informations d’identification.

Dans cet article, nous supposons que vous avez une compréhension de base de l’IAM. Pour plus d’informations sur les rôles IAM, consultez la documentation IAM. Nous commencerons par examiner certains cas d’utilisation potentiels à un niveau élevé, puis nous mettrons en évidence les pratiques recommandées pour récupérer en toute sécurité les secrets du Gestionnaire de secrets à partir de votre charge de travail locale ou hybride. Enfin, nous vous guiderons à travers un exemple d’application simple pour montrer comment rassembler ces recommandations dans une charge de travail.

Cas d’utilisation sélectionnés pour l’accès secrets extérieurs à AWS

Voici quelques exemples de scénarios dans lesquels il peut être nécessaire de récupérer ou de gérer en toute sécurité des secrets provenant d’applications externes à AWS, par exemple à partir d’applications hébergées dans votre centre de données ou un autre fournisseur de cloud.

Centralisez la gestion des secrets pour les applications dans votre datacenter et dans AWS

Il est avantageux d’offrir à vos équipes d’application un environnement unique et centralisé pour la gestion des secrets. Cela peut simplifier la gestion des secrets, car les équipes d’application ne sont tenues de comprendre et d’utiliser qu’un seul ensemble d’API pour créer, récupérer et faire pivoter les secrets. Il offre également une visibilité cohérente sur les secrets utilisés dans votre organisation, car Secrets Manager est intégré à AWS CloudTrail pour enregistrer les appels d’API au service, y compris les appels pour récupérer ou modifier une valeur de secret.

Dans les scénarios où votre application est déployée sur site ou dans un multicloud et que votre base de données réside dans Amazon Relational Database Service (Amazon RDS), vous avez la possibilité d’utiliser à la fois IAM Roles Anywhere et Secrets Manager pour stocker et récupérer des secrets à l’aide d’informations d’identification à court terme. Cette approche permet aux équipes de sécurité centrales d’avoir confiance dans la gestion des informations d’identification et aux équipes de création d’avoir un modèle bien défini pour la gestion des informations d’identification. Notez que vous pouvez également choisir de configurer l’authentification de base de données IAM avec RDS, au lieu de stocker les informations d’identification de base de données dans Secrets Manager, si cela est pris en charge par votre environnement de base de données.

Chez

AWS, nous constatons généralement que les clients bénéficient de la meilleure expérience, des meilleures performances et des meilleurs tarifs lorsqu’ils choisissent un fournisseur de cloud principal. Cependant, pour diverses raisons, certains clients se retrouvent dans une situation où ils exécutent des opérations informatiques dans un environnement multicloud. Dans ces scénarios, vous pouvez avoir des applications hybrides qui s’exécutent dans plusieurs environnements cloud, ou vous pouvez avoir des données stockées dans AWS qui doivent être accessibles à partir d’une autre application ou charge de travail exécutée dans un autre fournisseur de cloud. Vous pouvez utiliser IAM Roles Anywhere pour accéder en toute sécurité aux secrets ou les gérer dans Secrets Manager pour ces cas d’utilisation.

Migrations d’applications par phases vers AWS

Imaginons que vous migriez une application monolithique vers AWS à partir de votre centre de données, mais que la migration soit planifiée pour se dérouler par phases sur plusieurs mois. Il se peut que vous migriez votre calcul vers AWS bien avant vos bases de données, ou vice versa. Dans ce scénario, vous pouvez utiliser Secrets Manager pour stocker vos secrets d’application et y accéder à partir d’un site et d’AWS. Étant donné que vos secrets sont accessibles à la fois sur site et via AWS via les mêmes API, vous n’aurez pas besoin de refactoriser votre application pour récupérer ces secrets en tant que La migration se poursuit.

Pratiques recommandées pour la récupération des secrets pour les charges de travail hybrides et multicloud

Dans cette section, nous allons décrire certaines pratiques recommandées qui vous aideront à fournir un accès au moindre privilège à vos secrets d’application, quelle que soit l’origine de l’accès.

La mise en cache côté client

des secrets stockés dans Secrets Manager peut vous aider à améliorer les performances et à réduire les coûts en réduisant le nombre de requêtes d’API adressées à Secrets Manager. Après avoir récupéré un secret à partir de Secrets Manager, votre application peut obtenir la valeur secrète à partir de son cache en mémoire sans effectuer d’autres appels d’API. La valeur du secret mis en cache est automatiquement actualisée après un intervalle de temps configurable, appelé durée du cache, afin de garantir que l’application utilise toujours la dernière valeur de secret. AWS fournit des bibliothèques de mise en cache côté client pour .NET, Java, JDBC, Python et Go pour activer la mise en cache côté client. Vous trouverez des informations plus détaillées sur la mise en cache côté client spécifique aux bibliothèques Python dans cet article de blog.

Prenons l’exemple d’une application hybride avec un serveur d’applications local, qui doit récupérer les informations d’identification de la base de données stockées dans le Gestionnaire de secrets afin d’interroger les informations client à partir d’une base de données. Étant donné que les appels d’API pour récupérer le secret proviennent de l’extérieur d’AWS, ils peuvent entraîner une latence accrue simplement en fonction de la distance physique par rapport au centre de données AWS le plus proche. Dans ce scénario, les gains de performances de la mise en cache côté client deviennent encore plus percutants.

Appliquer l’accès au moindre privilège aux secrets par le biais de stratégies IAM

Vous pouvez utiliser une combinaison de types de stratégies IAM pour restreindre de manière granulaire l’accès aux secrets d’application lorsque vous utilisez IAM Roles Anywhere et Secrets Manager. Vous pouvez utiliser des conditions dans les stratégies d’approbation pour contrôler Les systèmes peuvent assumer ce rôle. Dans notre exemple, cela est basé sur le certificat du système, ce qui signifie que vous devez contrôler de manière appropriée l’accès à ces certificats. Dans notre exemple, nous utilisons une condition de stratégie pour spécifier une adresse IP, mais vous pouvez également utiliser une plage d’adresses IP. D’autres exemples seraient des conditions qui spécifient une plage horaire pour l’accès aux ressources, des conditions qui autorisent ou refusent la création de ressources dans certaines régions AWS, etc. Vous trouverez des exemples de stratégies dans la documentation IAM.

Vous devez utiliser des stratégies d’identité pour fournir à Secrets Manager des autorisations sur le rôle IAM assumé, conformément au principe du moindre privilège. Vous trouverez des exemples de stratégies IAM pour les cas d’utilisation de Secrets Manager dans la documentation de Secrets Manager.

En combinant différents types de stratégies, telles que les stratégies d’identité et les stratégies d’approbation, vous pouvez limiter l’étendue des systèmes qui peuvent assumer un rôle et contrôler ce que ces systèmes peuvent faire après avoir assumé un rôle. Par exemple, dans la stratégie d’approbation pour le rôle IAM avec accès au secret dans le Gestionnaire de secrets, vous pouvez autoriser ou refuser l’accès en fonction du nom commun du certificat utilisé pour authentifier et récupérer des informations d’identification temporaires afin d’assumer un rôle à l’aide de IAM Roles Anywhere. Vous pouvez ensuite attacher au rôle assumé une stratégie d’identité qui fournit uniquement les actions d’API nécessaires à votre application, telles que la possibilité de récupérer une valeur de secret, mais pas de supprimer un secret. Consultez ce billet de blog pour plus d’informations sur l’utilisation des différents types de stratégies.

Transformez les secrets à long terme en secrets à court terme

Vous vous demandez peut-être déjà : « Pourquoi devrais-je utiliser des informations d’identification à court terme pour accéder à un secret à long terme ? » La rotation fréquente de vos secrets d’application dans le Gestionnaire de secrets réduira le rayon d’impact d’un secret compromis. Imaginez que vous Faites pivoter votre secret d’application tous les jours. Si ce secret est d’une manière ou d’une autre exposé publiquement, il ne sera utilisable qu’une seule journée (ou moins). Cela peut réduire considérablement le risque que des informations d’identification compromises soient utilisées pour accéder à des informations sensibles. Vous trouverez plus d’informations sur l’intérêt d’utiliser des informations d’identification de courte durée dans cette bonne pratique AWS Well-Architected.

Au lieu d’utiliser des informations d’identification de base de données statiques qui sont rarement (ou jamais) pivotées, vous pouvez utiliser le Gestionnaire de secrets pour effectuer automatiquement la rotation des secrets jusqu’à toutes les quatre heures. Cette méthode aligne mieux la durée de vie de votre clé secrète de base de données avec la durée de vie des informations d’identification à courte durée de vie utilisées pour assumer le rôle IAM à l’aide de IAM Roles Anywhere.

Exemple de charge de travail : comment récupérer un secret pour interroger une base de données Amazon RDS à partir d’une charge de travail exécutée dans un autre fournisseur de cloud.

Nous allons maintenant vous montrer des exemples des pratiques recommandées décrites précédemment, telles que l’étendue des autorisations avec des stratégies IAM. Nous présenterons également un exemple d’application qui utilise une machine virtuelle hébergée chez un autre fournisseur de cloud pour accéder à un secret dans Secrets Manager.

L’architecture de référence de la figure 1 montre l’exemple d’application de base.

Dans l’exemple d’application, un secret d’application (par exemple, un nom d’utilisateur et un mot de passe de base de données) est utilisé pour accéder à une base de données Amazon RDS à partir d’un serveur d’applications hébergé chez un autre fournisseur de cloud. Le processus suivant est utilisé pour se connecter au Gestionnaire de secrets afin de récupérer et d’utiliser le secret :

1. Le serveur d’applications effectue une demande de récupération d’informations d’identification temporaires à l’aide de IAM Roles Anywhere.
2. IAM valide la demande par rapport à la les stratégies IAM pertinentes et vérifie que le certificat a été émis par une autorité de certification configurée en tant qu’ancre de confiance.
3. Si la demande est valide, AWS Security Token Service (AWS STS) fournit des informations d’identification temporaires que l’application peut utiliser pour assumer un rôle IAM.
4. IAM Roles Anywhere renvoie des informations d’identification temporaires à l’application.
5. L’application assume un rôle IAM avec des autorisations Secrets Manager et effectue un appel d’API GetSecretValue à Secrets Manager.
6. L’application utilise les informations d’identification de base de données renvoyées par le Gestionnaire de secrets pour interroger la base de données RDS et récupérer les données qu’elle doit traiter.

Avant

de configurer les rôles IAM n’importe où, il est essentiel de créer un rôle IAM avec l’autorisation requise pour Amazon RDS et Secrets Manager. Si vous suivez ces instructions par vous-même, reportez-vous à ce billet de blog et le Guide de l’utilisateur d’IAM Roles Anywhere pour connaître les étapes de configuration d’IAM Roles Anywhere dans votre environnement.

Obtenir des informations d’identification de sécurité temporaires

Vous disposez de plusieurs options pour obtenir des informations d’identification de sécurité temporaires à l’aide d’IAM Roles Anywhere :

• l’assistant d’informations d’identification IAM Roles Anywhere est un outil qui gère le processus de signature de l’API CreateSession avec la clé privée associée à un certificat d’entité finale X.509 et appelle le point de terminaison pour obtenir des informations d’identification AWS temporaires. Il renvoie les informations d’identification au processus appelant dans un format JSON standard. Cette approche est documentée dans le Guide de l’utilisateur d’IAM Roles Anywhere.
• Utilisation des kits SDK AWS Utilisez des

contrôles de stratégie pour définir correctement l’étendue de l’accès aux secrets

Dans cette section, nous montrons le processus de restreindre l’accès aux informations d’identification temporaires en utilisant des instructions de condition basées sur des attributs extraits du certificat X.509. Cette étape supplémentaire vous donne un contrôle granulaire de la politique d’approbation, afin que vous puissiez gérer efficacement les ressources qui peuvent obtenir des informations d’identification à partir d’IAM Roles Anywhere. Pour plus d’informations sur l’établissement d’un périmètre de données robuste sur AWS, consultez cet article de blog.

Conditions préalables

• Rôles IAM n’importe où à l’aide de l’autorité de certification privée AWS ou de votre propre PKI comme ancre de confiance
• Profil IAM Roles Anywhere
• Un rôle IAM avec des autorisations Secrets Manager

Restreindre l’accès aux informations d’identification temporaires

Vous pouvez restreindre l’accès aux informations d’identification temporaires à l’aide de conditions PKI spécifiques dans la politique d’approbation de votre rôle, comme suit :

• Les sessions émises par IAM Roles Anywhere ont l’identité source défini sur le nom commun (CN) de l’objet que vous utilisez dans l’authentification du certificat d’entité finale auprès du rôle cible.
• IAM Roles Anywhere extrait les valeurs des champs Subject, Issuer et Subject Alternative Name (SAN) du certificat d’authentification et les met à disposition pour l’évaluation des stratégies via les balises sourceIdentity et principal.
• Pour examiner le contenu d’un certificat, utilisez la commande suivante :

  openssl x509 -text -noout -in certificate.pem

• Pour établir une relation d’approbation pour IAM Roles Anywhere, procédez comme suit :
  1. Dans le volet de navigation de la console IAM, choisissez Roles .
  2. La console affiche les rôles de votre compte. Choisissez le nom du rôle que vous souhaitez modifier, puis choisissez l’onglet Relations d’approbation sur la page de détails.
  3. choisir Modifier la relation de confiance .

Exemple : Restreindre l’accès à un rôle en fonction du nom commun du certificat L’exemple

suivant montre une politique d’approbation qui ajoute une condition basée sur le nom commun de l’objet (CN) du certificat.

Si vous essayez d’accéder aux informations d’identification temporaires à l’aide d’un autre certificat qui a un CN différent, vous recevrez l’erreur « Erreur lors de la récupération des informations d’identification à partir du processus personnalisé : 2023/07/0X 23:46:43 AccessDeniedException : Impossible d’assumer le rôle pour arn :aws :iam ::64687XXX207 :role/RDS_SM_Role ».

Exemple : Restreindre l’accès à un rôle en fonction du nom commun de l’émetteur L’exemple

suivant montre une stratégie d’approbation qui ajoute une condition basée sur le CN de l’émetteur du certificat.

Exemple : Restreindre l’accès à un rôle en fonction de l’objet nom alternatif (SAN)

L’exemple suivant illustre une stratégie d’approbation qui ajoute une condition basée sur les champs SAN du certificat.

Définissez des

stratégies de session pour réduire davantage la portée des sessions fournies par IAM Roles Anywhere. Ici, à des fins de démonstration, nous avons ajouté une politique en ligne pour n’autoriser que les demandes provenant de l’adresse IP spécifiée en utilisant les étapes suivantes.

1. Accédez à la console Roles Anywhere.
2. Sous Profils , choisissez Créer un profil .
3. Sur la page Créer un profil, entrez un nom pour le profil.
4. Pour Rôles , sélectionnez le rôle que vous avez créé à l’étape précédente, puis sélectionnez la stratégie En ligne.

L’exemple suivant montre comment autoriser uniquement les requêtes provenant d’une adresse IP spécifique. Vous devrez remplacer <X.X.X.X/32> dans l’exemple de stratégie par votre propre adresse IP.

Récupérer des secrets en toute sécurité à partir d’une charge de travail exécutée dans un autre environnement cloud

Dans cette section, nous allons montrer le processus de connexion de machines virtuelles (VM) exécutées dans un autre fournisseur de cloud à une base de données MySQL Amazon RDS, où les informations d’identification de la base de données sont stockées en toute sécurité dans Secrets Manager.

Créer une base de données et gérer les informations d’identification de la base de données principale Amazon RDS dans Secrets Manager

Dans cette section, vous allez créer une instance de base de données et utiliser Secrets Manager pour gérer les informations d’identification de la base de données maître.

Pour créer une base de données Amazon RDS et gérer les informations d’identification de la base de données maître dans Secrets Manager

1. Ouvrez la console Amazon RDS et choisissez Create database .
2. Sélectionnez votre méthode de création de base de données préférée. Pour cet article, nous avons choisi la création standard .
3. Sous Options du moteur , pour Type de moteur , choisissez le moteur de base de données de votre choix. Dans cet article, nous utilisons MySQL.
4. Sous Paramètres , pour Paramètres d’informations d’identification , sélectionnez Gérer les informations d’identification principales dans AWS Secrets Manager .

   Figure 2 : gestion des informations d’identification principales dans Secrets Manager

5. Vous avez la possibilité de chiffrer les informations d’identification de la base de données maître gérée. Dans cet exemple, nous allons utiliser la clé AWS KMS par défaut.
6. (Facultatif) Choisissez d’autres paramètres pour répondre à vos besoins. Pour plus d’informations, consultez Paramètres des instances de base de données.
7. Choisissez Créer une base de données et attendez quelques minutes que l’icône base de données à créer.

Récupérer et utiliser des informations d’identification temporaires pour accéder à un secret dans Secrets Manager

L’étape suivante consiste à utiliser le service AWS Roles Anywhere pour obtenir des informations d’identification temporaires pour un rôle IAM. Ces informations d’identification temporaires sont essentielles pour accéder aux ressources AWS en toute sécurité. Nous avons décrit précédemment les options qui s’offrent à vous pour récupérer des informations d’identification temporaires à l’aide de IAM Roles Anywhere. Dans cette section, nous allons supposer que vous utilisez l’assistant d’informations d’identification pour récupérer des informations d’identification temporaires et effectuer un appel d’API au Gestionnaire de secrets.

Une fois que vous avez récupéré des informations d’identification temporaires et assumé un rôle IAM avec des autorisations d’accès au secret dans le Gestionnaire de secrets, vous pouvez exécuter un script simple sur la machine virtuelle pour obtenir le nom d’utilisateur et le mot de passe de la base de données à partir du Gestionnaire de secrets et mettre à jour la base de données. Les étapes sont résumées ici :

• Utiliser l’assistant d’informations d’identification pour assumer votre rôle IAM avec les autorisations d’accès au secret dans le Gestionnaire de secrets. Vous trouverez des instructions pour obtenir des informations d’identification temporaires dans le Guide de l’utilisateur d’IAM Roles Anywhere.
• Récupérez des secrets à partir du Gestionnaire de secrets. À l’aide des informations d’identification temporaires obtenues, vous pouvez créer un objet de session boto3 et initialiser un secrets_client à partir de boto3.client('secretsmanager'). Le secrets_client est responsable de l’interaction avec le service Secrets Manager. Vous allez récupérer la valeur de secret à partir du Gestionnaire de secrets, qui contient les informations d’identification nécessaires (par exemple, le nom d’utilisateur et le mot de passe de la base de données) pour accéder à une base de données RDS.
• Établissez une connexion à la base de données RDS. La valeur secrète récupérée est analysée et les informations de connexion à la base de données sont extraites. Vous pouvez ensuite établir une connexion à la base de données RDS à l’aide des détails extraits, tels que le nom d’utilisateur et le mot de passe.
• Effectuer des opérations de base de données. Une fois que la base de données La connexion est établie, le script effectue l’opération de mise à jour d’un enregistrement dans la base de données.

Voici un exemple de script Python permettant de récupérer des informations d’identification à partir du Gestionnaire de secrets et de se connecter au RDS pour les opérations de base de données.

Et c’est tout ! Vous avez récupéré des informations d’identification temporaires à l’aide d’IAM Roles Anywhere, assumé un rôle avec des autorisations permettant d’accéder au nom d’utilisateur et au mot de passe de la base de données dans Secrets Manager, puis récupéré et utilisé les informations d’identification de base de données pour mettre à jour une base de données à partir de votre application exécutée sur un autre fournisseur de cloud. Il s’agit d’un exemple d’application simple pour les besoins de l’article de blog, mais les mêmes concepts s’appliqueront dans des cas d’utilisation réels.

Conclusion

Dans cet article, nous avons montré comment vous pouvez stocker, récupérer et gérer en toute sécurité les secrets d’application et les informations d’identification de base de données pour vos charges de travail hybrides et multicloud à l’aide de Secrets Manager. Nous a également décrit certaines pratiques recommandées pour l’accès au moindre privilège à vos secrets lors de l’accès à Secrets Manager depuis l’extérieur d’AWS à l’aide de rôles IAM Anywhere. Enfin, nous avons présenté un exemple simple d’utilisation d’IAM Roles Anywhere pour assumer un rôle, puis récupérer et utiliser les informations d’identification de base de données de Secrets Manager dans une charge de travail multicloud. Pour commencer à gérer les secrets, ouvrez la console du Gestionnaire de secrets. Pour en savoir plus sur Secrets Manager, reportez-vous à la documentation de Secrets Manager.

 
Si vous avez des commentaires sur cet article, soumettez-les dans la section Commentaires ci-dessous. Si vous avez des questions sur cet article, contactez AWS Support.

Vous souhaitez en savoir plus sur la sécurité AWS ? Suivez-nous sur Twitter.

MOTS clés : AWS Secrets Manager, Rôles IAM n’importe où, Blog sur la sécurité