Le Blog Amazon Web Services
Instructions pour protéger votre compte AWS lors de l’utilisation de l’accès par programme
La sécurité de vos ressources et le contrôle minutieux des personnes qui y ont accès est le fondement de l’utilisation maîtrisée des services AWS par nos clients. Cela est particulièrement vrai si l’un de vos utilisateurs AWS dispose d’un accès programmatique. L’accès programmatique vous permet d’appeler des actions sur vos ressources AWS via une application que vous écrivez ou un outil tiers. Vous utilisez une clé d’accès et une clé d’accès secrète pour signer vos demandes d’autorisation auprès d’AWS. L’accès par programme est très puissant. Il est donc important de mettre en œuvre les meilleures pratiques pour protéger les clés d’accès ainsi que les clés d’accès secrètes afin d’éviter toute activité accidentelle ou malveillante sur vos comptes.
Dans cet article, je soulignerai quelques règles générales pour vous aider à protéger votre compte de manière globale.
Protégez votre compte racine “Root Account”
Votre compte racine AWS (le compte créé lors de votre inscription initiale à AWS) dispose d’un accès illimité à toutes vos ressources AWS. Il n’y a aucun moyen de limiter les autorisations sur un compte racine. Pour cette raison, AWS vous recommande de ne pas générer de clés d’accès pour votre compte root. Cela donnerait à vos utilisateurs le pouvoir de fermer, par exemple, l’intégralité du compte – une capacité dont ils n’ont probablement pas besoin. Au lieu de cela, vous devez créer des utilisateurs individuels à l’aide de AWS Identity and Access Management (IAM), puis attribuer des autorisations à chaque utilisateur en fonction du principe de privilège minimal : Accordez-leur uniquement les autorisations requises pour effectuer les tâches qui leur sont assignées. Pour gérer plus facilement les autorisations de plusieurs utilisateurs IAM, vous devez affecter des utilisateurs disposant des mêmes autorisations à un groupe IAM.
Votre compte racine doit toujours être protégé par une authentification multi-facteurs (MFA). Cette couche de sécurité supplémentaire aide à protéger contre les connexions non autorisées à votre compte en exigeant deux facteurs: un élément que vous connaissez (un mot de passe) et un élément que vous possédez (par exemple, un périphérique MFA). AWS prend en charge les périphériques MFA virtuels et matériels et les clés de sécurité U2F.
Décidez comment accorder l’accès à votre compte AWS
Pour permettre aux utilisateurs d’accéder à AWS Management Console et au CLI AWS (AWS Command Line Interface), vous avez deux options.
La première consiste à créer des identités et à permettre aux utilisateurs de se connecter à l’aide d’un nom d’utilisateur et d’un mot de passe gérés par le service IAM. La deuxième approche consiste à utiliser la fédération pour permettre à vos utilisateurs d’utiliser leurs informations d’identification d’entreprise existantes pour se connecter à la console AWS et à la CLI.
Chaque approche a ses cas d’utilisation. La fédération est généralement préférable pour les entreprises qui possèdent un répertoire central existant ou prévoient d’avoir besoin de plus que la limite actuelle de 5 000 utilisateurs IAM.
Remarque: l’ accès à tous les comptes AWS est géré par AWS IAM. Quelle que soit l’approche choisie, veillez à vous familiariser et à suivre les meilleures pratiques IAM.
Décidez quand utiliser les clés d’accès
Les applications exécutées en dehors d’un environnement AWS auront besoin de clés d’accès pour accéder par programme aux ressources AWS. Par exemple, les outils de surveillance exécutés sur des outils d’automatisation locaux et tiers auront besoin de clés d’accès.
Toutefois, si les ressources nécessitant un accès programmatique s’exécutent dans AWS, la meilleure pratique consiste à utiliser des rôles IAM. Un rôle IAM est un ensemble défini d’autorisations. Il n’est pas associé à un utilisateur ou à un groupe spécifique. Au lieu de cela, n’importe quelle entité approuvée & reconnue peut se voir attribuer ce rôle afin d’effectuer une tâche métier ou technique spécifique.
En utilisant des rôles, vous pouvez accorder l’accès à une ressource sans coder en dur une clé d’accès et une clé d’accès secrète dans le fichier de configuration. Par exemple, vous pouvez accorder à une instance Amazon Elastic Compute Cloud (EC2) l’accès à un compartiment Amazon Simple Storage Service (Amazon S3) en attachant une stratégie à un rôle qui définit cet accès à l’instance EC2. Cette approche améliore votre sécurité, car IAM gérera de manière dynamique les informations d’identification pour vous avec des informations d’identification temporaires à rotation automatique.
Accorder le moins de privilège aux comptes de service
Si vous avez décidé de créer des comptes de service (c’est-à-dire des comptes utilisés pour un accès programmatique par des applications exécutées en dehors de l’environnement AWS) et de générer des clés d’accès pour ces comptes, vous devez créer un compte de service dédié pour chaque cas d’utilisation. Cela vous permettra de définir la stratégie associée aux seules autorisations requises pour un cas d’utilisation particulier, en limitant le rayon de détection si les informations d’identification sont compromises. Par exemple, si un outil de surveillance et un outil de gestion des versions nécessitent tous deux l’accès à votre environnement AWS, créez deux comptes de service distincts avec deux stratégies distinctes qui définissent l’ensemble minimal d’autorisations pour chaque outil.
En outre, il est également recommandé d’ajouter à la stratégie des conditions qui restreignent davantage l’accès, par exemple en limitant l’accès à la plage d’adresses IP source de vos clients.
Vous trouverez ci-dessous un exemple de politique qui représente le moins de privilèges. Il attribue les autorisations nécessaires (PutObject) à une ressource spécifique (un compartiment S3 nommé «exemplebucket») tout en ajoutant d’autres conditions (le client doit provenir de la plage d’adresses 203.0.113.0/24).
Utiliser des informations d’identification temporaires à partir d’AWS STS
AWS STS ( AWS Security Token Service ) est un service Web qui vous permet de demander des informations d’identification temporaires à utiliser dans votre code, votre interface de ligne de commande ou des outils tiers. Il vous permet d’assumer un rôle IAM avec lequel vous avez une relation de confiance, puis de générer des informations d’identification temporaires et limitées dans le temps en fonction des autorisations associées au rôle. Ces informations d’identification ne peuvent être utilisées que pendant la période de validité, ce qui réduit vos risques.
Il existe deux manières de générer des informations d’identification temporaires. Vous pouvez les générer à partir de l’AWS CLI, ce qui est utile lorsque vous avez besoin d’informations d’identification pour les tests à partir de votre ordinateur local ou d’un outil local ou tiers. Vous pouvez également les générer à partir de code à l’aide de l’un des kits de développement AWS. Cette approche est utile si vous avez besoin d’informations d’identification dans votre application ou si vous avez plusieurs types d’utilisateurs nécessitant des niveaux d’autorisation différents.
Créer des informations d’identification temporaires à l’aide du CLI
Si vous avez accès à l’AWS CLI, vous pouvez l’utiliser pour générer des informations d’identification temporaires avec des autorisations limitées à utiliser dans vos tests locaux ou avec des outils tiers. Pour pouvoir utiliser cette approche, voici ce dont vous avez besoin:
- Accès à l’AWS CLI via votre compte d’utilisateur principal ou via la fédération. Pour savoir comment configurer l’accès CLI à l’aide de vos informations d’identification IAM, suivez ce lien . Si vous utilisez la fédération, vous pouvez toujours utiliser la CLI en suivant les instructions fournies dans ce blog
- Un rôle IAM qui représente les autorisations nécessaires pour votre client de test. Dans l’exemple ci-dessous, j’utilise «s3-read». Ce rôle doit avoir une stratégie attachée qui accorde le moins de privilèges nécessaires pour le cas d’utilisation
- Une relation de confiance entre le rôle de service («s3-read») et votre compte d’utilisateur, afin de vous permettre d’assumer le rôle de service et de générer des informations d’identification temporaires. Visitez ce lien pour connaître les étapes à suivre pour créer cette relation de confiance.
L’exemple de commande ci-dessous générera un ID de clé d’accès temporaire et une clé d’accès secrète valides pendant 15 minutes, en fonction des autorisations associées au rôle nommé «s3-read». Vous pouvez remplacer les valeurs ci-dessous par votre propre numéro de compte, rôle de service et durée, puis utiliser la clé d’accès secrète et l’ID de clé d’accès de vos clients locaux.
aws sts assume-role --role-arn <arn:aws:iam::AWS-ACCOUNT-NUMBER:role/s3-read> --role-session-name <s3-access> --duration-seconds <900>
Voici le résultat de l’exécution de la commande :
Créer des informations d’identification temporaires à partir de votre code
Si une application utilise déjà le kit AWS SDK, vous pouvez utiliser AWS STS pour générer des informations d’identification temporaires directement à partir du code plutôt que des informations d’identification codées en dur dans vos configurations. Cette approche est recommandée si vous avez un code côté client qui requiert des informations d’identification ou si vous avez plusieurs types d’utilisateurs (par exemple, administrateurs, utilisateurs expérimentés et utilisateurs standard), car cela vous permet d’éviter de coder en dur plusieurs ensembles d’informations d’identification pour chaque utilisateur et/ou type d’utilisateur.
Pour plus d’informations sur l’utilisation des informations d’identification temporaires à partir du kit AWS SDK, visitez ce lien.
Utiliser Access Advisor
La console IAM fournit des informations sur le moment où un service AWS a été accédé pour la dernière fois par différents “principals”, ie asset authentifié. Cette information est appelée dernier service consulté.
À l’aide de cet outil, vous pouvez voir quand un utilisateur, groupe, rôle ou politique IAM a tenté d’accéder aux services pour lesquels il dispose d’autorisations. Sur la base de ces informations, vous pouvez décider si certaines autorisations doivent être révoquées ou davantage restreintes.
Intégrez cet outil à votre vérification de sécurité périodique. Utilisez-le pour évaluer les autorisations de toutes vos entités IAM et révoquer les autorisations non utilisées jusqu’à ce qu’elles soient nécessaires. Vous pouvez également automatiser le processus d’évaluation périodique des autorisations à l’aide des API Access Advisor. Si vous voulez savoir comment, ce billet de blog est un bon point de départ.
Autres outils de gestion des identifiants
Bien que l’accès minimal aux privilèges et les informations d’identification temporaires soient importants, il est tout aussi important que vos utilisateurs gèrent correctement leurs informations d’identification, de la rotation au stockage. Vous trouverez ci-dessous un ensemble de services et de fonctionnalités permettant d’enregistrer, de récupérer et de faire pivoter les informations d’identité en toute sécurité.
Magasin de paramètres AWS Systems Manager
AWS Systems Manager offre une fonctionnalité appelée Parameter Store qui fournit un stockage sécurisé et centralisé pour les paramètres de configuration et les secrets sur votre compte AWS. Vous pouvez stocker du texte brut ou des données chiffrées telles que des paramètres de configuration, des informations d’identification et des clés de licence. Une fois stocké, vous pouvez configurer un accès granulaire pour spécifier qui peut obtenir ces paramètres dans votre application, en ajoutant une autre couche de sécurité pour protéger vos données.
Le magasin de paramètres est un bon choix pour les cas d’utilisation dans lesquels vous avez besoin d’un stockage hiérarchique pour la gestion des données de configuration sur votre compte. Par exemple, vous pouvez stocker les informations d’identification d’accès à la base de données (nom d’utilisateur et mot de passe) dans le magasin de paramètres, les chiffrer avec une clé de chiffrement gérée par AWS Key Management Service et accorder aux instances EC2 exécutant les applications l’autorisation pour lire et déchiffrer ces informations d’identification.
Pour plus d’informations sur l’utilisation de AWS Systems Manager Parameter Store, visitez ce lien.
AWS Secrets Manager
AWS Secrets Manager est un service qui vous permet de gérer de manière centralisée le cycle de vie des secrets utilisés dans votre organisation, y compris la rotation, les audits et le contrôle d’accès. En vous permettant de faire pivoter automatiquement les secrets, Secrets Manager peut vous aider à répondre à vos exigences en matière de sécurité et de conformité. Secrets Manager propose également une intégration intégrée pour MySQL, PostgreSQL et Amazon Aurora sur Amazon RDS et peut être étendue à d’autres services.
Pour plus d’informations sur l’utilisation d’AWS Secrets Manager pour stocker et récupérer des secrets, visitez ce lien.
Amazon Cognito
Amazon Cognito vous permet d’ajouter des fonctionnalités d’enregistrement, de connexion et de gestion des utilisateurs à vos applications Web et mobiles.
Cognito peut être utilisé comme fournisseur d’identité (IdP), où il stocke et gère les utilisateurs et les informations d’identification de manière sécurisée pour vos applications, ou il peut être intégré à OpenID Connect, SAML et à d’autres fournisseurs d’identité Web populaires tels qu’Amazon.com.
Grâce à Amazon Cognito, vous pouvez générer des informations d’identification d’accès temporaires permettant à vos clients d’accéder aux services AWS, ce qui vous évite d’avoir à stocker des informations d’identification à long terme dans les applications client.
Pour en savoir plus sur l’utilisation d’Amazon Cognito en tant que fournisseur d’identité, consultez notre guide du développeur relatif aux groupes d’utilisateurs Amazon Cognito. Si vous souhaitez des informations sur l’utilisation d’Amazon Cognito avec un fournisseur d’identité tiers, consultez notre guide sur les pools d’identités Amazon Cognito (identités fédérées).
AWS Trusted Advisor
AWS Trusted Advisor est un service qui fournit une revue en temps réel de votre compte AWS et fournit des conseils sur la façon d’optimiser vos ressources pour réduire les coûts, augmenter les performances, augmenter la fiabilité et améliorer la sécurité.
La section «Sécurité» de AWS Trusted Advisor doit être examinée régulièrement pour évaluer la santé de votre compte AWS. Actuellement, plusieurs vérifications spécifiques à la sécurité sont effectuées, à partir de clés d’accès IAM qui n’ont pas été permutées pour devenir des groupes de sécurité non sécurisés. Trusted Advisor est un outil qui vous aide à effectuer plus facilement une révision quotidienne ou hebdomadaire de votre compte AWS.
git-secrets
git-secrets, disponible à partir du compte GitHub de AWS Labs, vous aide à éviter de saisir des mots de passe et d’autres informations d’identification sensibles dans un référentiel git. Il analyse les validations, les messages de validation et les fusions --no-ff pour empêcher vos utilisateurs d’ajouter par inadvertance des secrets à vos référentiels.
Conclusion
Dans ce billet de blog, j’ai présenté quelques options pour remplacer les informations d’identification à long terme dans vos applications par des informations d’identification d’accès temporaire pouvant être générées à l’aide de divers outils et services sur la plate-forme AWS. L’utilisation d’identifiants temporaires peut réduire le risque d’être victime d’une compromission et ainsi protéger davantage votre entreprise.
J’ai également abordé le concept de moindre privilège et fourni des services et des procédures utiles pour la maintenance et l’audit des autorisations accordées aux différentes identités de votre environnement.
Vous souhaitez plus d’informations sur le contenu, les actualités et les fonctionnalités d’AWS Security? Suivez-nous sur Twitter.
Auteurs :
- Mahmoud Matouk, Solution Architect dans les équipes Secteur Public, travaillant avec les organismes de formation, écoles et universités,
- Joe Chapman, Solution Architect dans l’équipe EdTech.
Traduit en français par Corneliu Croitoru, Solutions Architect. Corneliu est très impliqué dans la communauté Serverless chez AWS et il assiste les clients, principalement français, de toute taille (startups, PME, enterprise) et les aide à deployer leurs architectures cloud native sur AWS.