SEC03-BP02 Accorder un accès selon le principe du moindre privilège - AWS Framework Well-Architected
Directives d’implémentationRessources

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

SEC03-BP02 Accorder un accès selon le principe du moindre privilège

Accordez uniquement l’accès dont les utilisateurs ont besoin pour effectuer des actions spécifiques sur des ressources spécifiques dans des conditions spécifiques. Faites appel à des groupes et des attributs d’identité pour définir de façon dynamique des autorisations à grande échelle, plutôt que pour des utilisateurs individuels. Par exemple, vous pouvez autoriser un groupe de développeurs à gérer uniquement les ressources de leur projet. Ainsi, si un développeur quitte le projet, son accès est automatiquement révoqué sans que les stratégies d’accès sous-jacentes soient modifiées.

Résultat escompté : les utilisateurs ne disposent que des autorisations minimales requises pour leurs fonctions professionnelles spécifiques. Vous utilisez des Comptes AWS séparés pour isoler les développeurs des environnements de production. Lorsque les développeurs ont besoin d’accéder à des environnements de production pour des tâches spécifiques, un accès limité et contrôlé leur est accordé seulement pour la durée de ces tâches. Leur accès en production est immédiatement révoqué une fois qu’ils ont terminé les travaux nécessaires. Vous révisez régulièrement les autorisations et vous les révoquez rapidement lorsqu’elles ne sont plus nécessaires, par exemple lorsqu’un utilisateur change de rôle ou quitte l’organisation. Vous limitez les privilèges d’administrateur à un petit groupe de confiance afin de réduire l’exposition aux risques. Vous accordez aux comptes de machines ou de systèmes uniquement les autorisations minimales requises pour effectuer les tâches prévues.

Anti-modèles courants :

  • Par défaut, vous accordez des autorisations d’administrateur aux utilisateurs.

  • Vous utilisez le compte d’utilisateur racine pour les activités quotidiennes.

  • Vous créez des politiques trop permissives sans les délimiter correctement.

  • Vos révisions d’autorisations sont peu fréquentes, ce qui entraîne des dérives.

  • Vous vous appuyez uniquement sur un contrôle d’accès basé sur les attributs pour l’isolation de l’environnement ou la gestion des autorisations.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé

Directives d’implémentation

Le principe du moindre privilège stipule que les identités ne devraient être autorisées à effectuer que le plus petit ensemble d’actions nécessaires pour accomplir une tâche spécifique. Il permet d’atteindre un équilibre entre la convivialité, l’efficacité et la sécurité. Le respect de ce principe permet de limiter l’accès non intentionnel et de déterminer qui a accès aux ressources. Par défaut, les utilisateurs et les rôles IAM ne disposent d’aucune autorisation. L’utilisateur racine dispose d’un accès complet par défaut et doit être étroitement contrôlé, surveillé et utilisé uniquement pour les tâches nécessitant un accès racine.

Les politiques IAM sont utilisées pour octroyer explicitement des autorisations aux rôles IAM ou à des ressources spécifiques. Par exemple, les politiques basées sur l’identité peuvent être attachées à des groupes IAM, tandis que les compartiments S3 peuvent être contrôlés par des politiques basées sur les ressources.

Lorsque vous créez une politique IAM, vous pouvez spécifier les actions de service, les ressources et les conditions qui doivent être remplies pour qu’AWS autorise ou refuse l’accès. AWS prend en charge diverses conditions pour vous aider à limiter l’accès. Par exemple, en utilisant la clé de condition PrincipalOrgID, vous pouvez refuser des actions si le demandeur ne fait pas partie de votre organisation AWS.

Vous pouvez également contrôler les demandes que les services AWS effectuent en votre nom, comme AWS CloudFormation qui crée une fonction AWS Lambda, à l’aide de la clé de condition CalledVia. Vous pouvez superposer différents types de politiques pour établir une défense en profondeur et limiter les autorisations globales de vos utilisateurs. Vous pouvez également limiter les autorisations qui peuvent être accordées et sous quelles conditions. Par exemple, vous pouvez autoriser vos équipes responsables de la charge de travail à créer leurs propres politiques IAM pour les systèmes qu’elles créent, mais seulement si elles appliquent une limite des autorisations afin de limiter le nombre maximal d’autorisations qu’elles peuvent accorder.

Étapes d’implémentation

  • Implémentez des politiques de moindre privilège : attribuez des stratégies d’accès avec le moindre privilège aux groupes et rôles IAM pour rester cohérent avec le rôle ou la fonction de l’utilisateur que vous avez défini.

  • Isolez les environnements de développement et de production via des Comptes AWS séparés : utilisez des Comptes AWS séparés pour les environnements de développement et de production, et contrôlez l’accès entre eux à l’aide de politiques de contrôle des services, de politiques de ressources et de politiques d’identité.

  • Politiques de base relatives à l’utilisation des API : l’un des moyens de déterminer les autorisations nécessaires consiste à consulter les journaux AWS CloudTrail. Vous pouvez utiliser cette révision pour créer des autorisations adaptées aux actions effectivement réalisées par l’utilisateur dans AWS. IAM Access Analyzer peut générer automatiquement une politique IAM basée sur l’activité d’accès. Vous pouvez utiliser IAM Access Advisor au niveau de l’organisation ou du compte pour suivre les dernières informations consultées pour une stratégie donnée.

  • Envisagez d’utiliser des politiques gérées par AWS pour les fonctions professionnelles : lorsque vous commencez à créer des politiques d’autorisations détaillées, il peut être utile d’utiliser des politiques gérées par AWS pour les rôles professionnels courants, tels que la facturation, les administrateurs de base de données et les scientifiques des données. Ces politiques peuvent permettre de restreindre l’accès des utilisateurs en déterminant comment mettre en œuvre les politiques de moindre privilège.

  • Supprimez les autorisations inutiles : détectez et supprimez les entités, les informations d’identification et les autorisations IAM inutilisées afin d’appliquer le principe du moindre privilège. Vous pouvez utiliser l’Analyseur d’accès IAM pour identifier les accès externes et non utilisés, et la génération de politiques de l’Analyseur d’accès IAM peut aider à optimiser les politiques d’autorisation.

  • S’assurer que les utilisateurs ont un accès limité aux environnements de production : les utilisateurs ne doivent avoir accès qu’aux environnements de production présentant un cas d’utilisation valide. Une fois que l’utilisateur a effectué les tâches précises qui nécessitent un accès en production, cet accès doit être révoqué. Le fait de limiter l’accès aux environnements de production permet de prévenir les événements imprévus ayant une incidence sur la production et réduit la portée des répercussions de l’accès involontaire.

  • Envisagez les limites des autorisations : une limite des autorisations est une fonctionnalité permettant d’utiliser une politique gérée qui définit les autorisations maximales qu’une politique basée sur l’identité peut accorder à une entité IAM. La limite des autorisations d’une entité lui permet d’effectuer uniquement les actions autorisées à la fois par ses politiques basées sur l’identité et ses limites des autorisations.

  • Affinez l’accès à l’aide du contrôle d’accès basé sur les attributs et des balises de ressources : un contrôle d’accès basé sur les attributs (ABAC) utilisant des balises de ressources peut être utilisé pour affiner les autorisations lorsqu’il est pris en charge. Vous pouvez utiliser un modèle ABAC qui compare les balises principales aux balises de ressources pour affiner l’accès en fonction des dimensions personnalisées que vous définissez. Cette approche permet de simplifier et de réduire le nombre de politiques d’autorisation au sein de votre organisation.

    • Il est recommandé d’utiliser uniquement ABAC pour le contrôle d’accès lorsque les principaux et les ressources appartiennent à votre organisation AWS. Les parties externes peuvent utiliser les mêmes noms de balises et les mêmes valeurs que votre organisation pour leurs propres principaux et ressources. Si vous vous appuyez uniquement sur ces paires nom-valeur pour accorder l’accès à des principaux ou à des ressources externes, vous pouvez fournir des autorisations involontaires.

  • Utilisez des politiques de contrôle des services pour AWS Organizations : les politiques de contrôle des services contrôlent de façon centralisée les autorisations disponibles maximales pour les comptes membres de votre organisation. Il est important de noter que vous pouvez utiliser les politiques de contrôle des services pour limiter les autorisations des utilisateurs racine dans les comptes membres. Envisagez également d’utiliser AWS Control Tower, qui fournit des contrôles gérés normatifs permettant d’enrichir AWS Organizations. Vous pouvez également définir vos propres contrôles dans Control Tower.

  • Établissez une politique de cycle de vie des utilisateurs pour votre organisation : les politiques de cycle de vie des utilisateurs définissent les tâches à effectuer lorsque les utilisateurs sont intégrés à AWS, changent de rôle ou de champ d’activité, ou n’ont plus besoin d’accéder à AWS. Examinez les autorisations à chaque étape du cycle de vie d’un utilisateur pour vous assurer qu’elles sont suffisamment restrictives et éviter les dérives.

  • Établissez un calendrier régulier pour vérifier les autorisations et supprimer les autorisations inutiles : vous devez régulièrement vérifier l’accès des utilisateurs pour vérifier qu’il n’est pas trop permissif. AWS Config et l’Analyseur d’accès IAM peuvent aider lors des audits des autorisations des utilisateurs.

  • Établissez une matrice des rôles de tâches : une matrice des rôles de tâches permet de visualiser les différents rôles et niveaux d’accès requis au sein de votre couverture AWS. À l’aide d’une matrice des fonctions professionnelles, vous pouvez définir et séparer les autorisations en fonction des responsabilités des utilisateurs au sein de votre organisation. Utilisez des groupes au lieu d’appliquer des autorisations directement à des utilisateurs ou à des rôles individuels.

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :