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

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

Une bonne pratique consiste à accorder uniquement l'accès dont les identités 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 souhaité : les utilisateurs doivent uniquement disposer des autorisations requises pour faire leur travail. Les utilisateurs ne doivent avoir accès qu'aux environnements de production pour effectuer une tâche précise dans un délai limité et cet accès doit être révoqué une fois la tâche terminée. Les autorisations doivent être révoquées lorsqu'elles ne sont plus nécessaires, y compris lorsqu'un utilisateur passe à un autre projet ou à une autre fonction. Les privilèges d'administrateur ne doivent être accordés qu'à un petit groupe d'administrateurs approuvés. Les autorisations doivent être examinées régulièrement pour éviter toute dérive. Les comptes des machines ou des systèmes doivent recevoir le plus petit ensemble d'autorisations nécessaires pour effectuer leurs tâches.

Anti-modèles courants :

  • Octroi par défaut des autorisations d'administrateur aux utilisateurs.

  • Utilisation de l'utilisateur root pour les activités quotidiennes.

  • Création de politiques trop permissives, mais sans tous les privilèges d'administrateur.

  • Absence de révision des autorisations pour comprendre si elles autorisent l'accès selon le principe du moindre privilège.

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

Directives d'implémentation

Le principe du moindre privilège établit que les identités ne doivent ê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. Les utilisateurs et les rôles IAM n'ont aucune autorisation par défaut. L'utilisateur root dispose d'une accès complet par défaut et doit être étroitement contrôle et surveillé. De plus, il doit être utilisé uniquement pour des tâches qui requièrent un accès root.

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 AWS Organization.

Vous pouvez également contrôler les demandes effectuées par les services AWS en votre nom, par exemple AWS CloudFormation qui crée une fonction AWS Lambda, en utilisant la clé de condition CalledVia. Vous devez 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 les équipes de votre application à créer leurs propres politiques IAM pour les systèmes qu'elles créent, mais vous devez également appliquer une limite d'autorisation afin de restreindre les autorisations maximum que le système peut recevoir.

Étapes d'implémentation

  • Implémentez des politiques du moindre privilège : attribuez des politiques d'accès avec le moins de privilèges possibles 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.

  • 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 difficile de savoir par où commencer. AWS dispose de politiques gérées pour les rôles professionnels courants, par exemple la facturation, les administrateurs de bases 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 reposant sur le principe du moindre privilège.

  • Supprimez les autorisations inutiles : supprimez les autorisations qui ne sont pas nécessaires et réduisez les politiques trop permissives. La génération de politique IAM Access Analyzer peut vous aider à affiner les politiques d'autorisations.

  • Assurez-vous que les utilisateurs ont un accès limité aux environnements de production : les utilisateurs ne doivent avoir accès aux environnements de production qu'avec 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 des limites d'autorisations : une limite des autorisations est une fonction qui permet d'utiliser une stratégie gérée définissant les autorisations maximales qu'une entité IAM peut recevoir d'une politique basée sur une identité. La limite des autorisations d'une entité lui permet d'exécuter uniquement les actions autorisées par ses stratégies basées sur l'identité et ses limites d'autorisations.  

  • Envisagez les balises de ressources pour les autorisations : un modèle de contrôle d'accès basé sur des attributs utilisant des balises de ressources vous permet d'accorder l'accès en fonction de l'objectif de la ressource, du propriétaire, de l'environnement ou d'autres critères. Par exemple, vous pouvez utiliser des balises de ressources pour différencier les environnements de développement et de production. En utilisant ces balises, vous pouvez limiter les développeurs à l'environnement de développement. En combinant les politiques de balisage et d'autorisations, vous pouvez obtenir un accès précis aux ressources sans avoir à définir des politiques compliquées et personnalisées pour chaque fonction professionnelle.

  • Utilisez les 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 maximum pour les comptes membres de votre organisation. Il est important de noter que les politiques de contrôle des services vous permettent de limiter les autorisations des utilisateurs root 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 de l'utilisateur pour votre organisation : les politiques du cycle de vie de l'utilisateur définissent les tâches à effectuer lorsque les utilisateurs sont intégrés à AWS, changent de rôle ou de fonctions, ou qu'ils n'ont plus besoin d'accéder à AWS. Les autorisations doivent être vérifiées à chaque étape du cycle de vie d'un utilisateur pour s'assurer qu'elles sont suffisamment restrictives et éviter les dérives.

  • Établissez un calendrier régulier pour passer en revue les autorisations et supprimer les autorisations inutiles : vous devez régulièrement passer en revue les accès utilisateur afin de vérifier que les utilisateurs ne disposent pas d'un accès trop permissif. AWS Config et IAM Access Analyzer peuvent être utiles pour auditer les autorisations utilisateur.

  • Établissez une matrice des fonctions : une matrice des fonctions permet de visualiser les différents rôles et les niveaux d'accès requis pour votre empreinte AWS. À l'aide d'une matrice des fonctions, 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 aux utilisateurs ou rôles individuels.  

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :