SEC03-BP02 Accorder un accès selon le principe du moindre privilège - Pilier Sécurité
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 ne doivent disposer que des autorisations nécessaires pour effectuer 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 racine 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 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 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 vos équipes chargées des applications à créer leurs propres politiques IAM pour les systèmes qu’elles créent, mais vous devez également appliquer une limite des autorisations afin de limiter le nombre maximum d’autorisations que le système peut recevoir.

Étapes d’implémentation

  • Implémenter des politiques du 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.

  • Envisagez d’utiliser des politiques gérées 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.

  • Supprimer les autorisations inutiles : supprimez les autorisations inutiles et réduisez les politiques trop permissives. La génération de politiques d’IAM Access Analyzer peut aider à affiner 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.

  • Envisager des limites des autorisations : une limite des autorisations est une fonctionnalité avancée permettant d’utiliser une stratégie gérée qui définit 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’effectuer uniquement les actions autorisées à la fois par ses politiques basées sur l’identité et ses limites des autorisations.  

  • Envisagez les balises de ressources pour les autorisations : un modèle de contrôle d’accès basé sur les 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 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 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 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. 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 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’ils ne sont pas trop permissifs. AWS Config et IAM Access Analyzer peuvent vous aider lors de l’audit 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, 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 :