IAMressources - AWS Conseils prescriptifs

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.

IAMressources

Influencez le futur de l'architecture de référence de AWS sécurité (AWS SRA) en répondant à une courte enquête.

Bien qu'AWSIdentity and Access Management (IAM) ne soit pas un service inclus dans un schéma d'architecture traditionnel, il touche tous les aspects de l'AWSorganisation, AWS des comptes et AWS des services. Vous ne pouvez déployer aucun AWS service sans créer d'IAMentités et accorder d'abord des autorisations. Une explication complète IAM n'entre pas dans le cadre de ce document, mais cette section fournit des résumés importants des recommandations relatives aux meilleures pratiques et des indications vers des ressources supplémentaires.

 

Cas d'utilisation ou politique

Effet

Géré par

Objectif

Se rapporte à

Affecte

Déployé dans

Politiques de contrôle des services (SCPs)

Restrict

Équipe centrale, telle que l'équipe chargée de la plateforme ou de la sécurité [1]

Garde-corps, gouvernance

Organisation, unité d'organisation, compte

Tous les principes de l'organisation, de l'unité d'organisation et des comptes

Compte de gestion de l'organisation [2]

Politiques d'automatisation des comptes de base (les IAM rôles utilisés par la plateforme pour gérer un compte)

Accorder et restreindre

Équipe centrale, telle que plateforme, sécurité ou IAM équipe [1]

Autorisations pour les rôles d'automatisation (de base) autres que la charge de travail [3]

Compte unique [4]

Principes utilisés par l'automatisation au sein d'un compte membre

Comptes membres

Politiques humaines de base (les IAM rôles qui accordent aux utilisateurs l'autorisation d'effectuer leur travail)

Accorder et restreindre

Équipe centrale, telle que plateforme, sécurité ou IAM équipe [1]

Autorisations pour les rôles humains [5]

Compte unique [4]

Principaux fédérés [5] et IAM utilisateurs [6]

Comptes membres

Limites d'autorisations (autorisations maximales qu'un développeur habilité peut attribuer à un autre directeur)

Restrict

Équipe centrale, telle que plateforme, sécurité ou IAM équipe [1]

Garde-fous pour les rôles d'application (doivent être appliqués)

Compte unique [4]

Rôles individuels pour une application ou une charge de travail dans ce compte [7]

Comptes membres

Politiques relatives aux rôles des machines pour les applications (rôle attaché à l'infrastructure déployée par les développeurs)

Accorder et restreindre

Délégué aux développeurs [8]

Autorisation pour l'application ou la charge de travail [9]

Compte unique

Un principal sur ce compte

Comptes membres

Politiques basées sur une ressource

Accorder et restreindre

Délégué aux développeurs [8,10]

Autorisations d'accès aux ressources

Compte unique

Un principal dans un compte [11]

Comptes membres

  

Remarques tirées du tableau :

  1. Les entreprises disposent de nombreuses équipes centralisées (telles que les équipes chargées des plateformes cloud, des opérations de sécurité ou des équipes de gestion des identités et des accès) qui se répartissent les responsabilités liées à ces contrôles indépendants et évaluent les politiques des uns et des autres. Les exemples présentés dans le tableau sont des espaces réservés. Vous devrez déterminer la séparation des tâches la plus efficace pour votre entreprise.

  2. Pour les utiliserSCPs, vous devez activer toutes les fonctionnalités dans AWS Organizations.

  3. Des rôles et des politiques de base communs sont généralement nécessaires pour permettre l'automatisation, tels que les autorisations pour le pipeline, les outils de déploiement, les outils de surveillance (par exemple, les règles AWS Lambda et AWS Config) et d'autres autorisations. Cette configuration est généralement fournie lors du provisionnement du compte.

  4. Bien qu'elles concernent une ressource (telle qu'un rôle ou une politique) dans un seul compte, elles peuvent être répliquées ou déployées sur plusieurs comptes à l'aide de. AWS CloudFormation StackSets

  5. Définissez un ensemble de règles et de rôles humains de base qui sont déployés sur tous les comptes des membres par une équipe centrale (souvent lors du provisionnement des comptes). Les développeurs de l'équipe de la plateforme, de l'équipe et des IAM équipes d'audit de sécurité en sont des exemples.

  6. Utilisez la fédération d'identité (au lieu des IAM utilisateurs locaux) dans la mesure du possible.

  7. Les limites des autorisations sont utilisées par les administrateurs délégués. Cette IAM politique définit les autorisations maximales et remplace les autres politiques (y compris les “*:*” politiques qui autorisent toutes les actions sur les ressources). Les limites d'autorisations devraient être requises dans les politiques humaines de base comme condition pour créer des rôles (tels que les rôles de performance de la charge de travail) et pour associer des politiques. Des configurations supplémentaires telles SCPs que l'imposition de la limite des autorisations.

  8. Cela suppose que des barrières de sécurité suffisantes (par exemple, SCPs et des limites d'autorisations) ont été déployées.

  9. Ces politiques facultatives peuvent être mises en œuvre lors de la création du compte ou dans le cadre du processus de développement de l'application. L'autorisation de créer et d'associer ces politiques sera régie par les autorisations du développeur de l'application.

  10. Outre les autorisations des comptes locaux, une équipe centralisée (telle que l'équipe de la plateforme cloud ou l'équipe des opérations de sécurité) gère souvent certaines politiques basées sur les ressources afin de permettre l'accès entre comptes pour gérer les comptes (par exemple, pour fournir un accès aux compartiments S3 à des fins de journalisation).

  11. Une IAM politique basée sur les ressources peut faire référence à n'importe quel principal de n'importe quel compte pour autoriser ou refuser l'accès à ses ressources. Il peut même faire référence à des principes anonymes pour permettre l'accès public.

 Il est essentiel de s'assurer que les IAM identités ne disposent que des autorisations nécessaires pour un ensemble bien défini de tâches afin de réduire le risque d'abus d'autorisations malveillant ou involontaire. L'établissement et le maintien d'un modèle de moindre privilège nécessitent un plan délibéré pour continuellement mettre à jour, évaluer et atténuer les privilèges excessifs. Voici quelques recommandations supplémentaires pour ce plan :

  • Utilisez le modèle de gouvernance de votre organisation et sa propension au risque établie pour établir des garde-fous et des limites d'autorisations spécifiques.

  • Mettez en œuvre le principe du moindre privilège par le biais d'un processus itératif continu. Il ne s'agit pas d'un exercice ponctuel.

  • SCPsÀ utiliser pour réduire les risques exploitables. Il s'agit de barrières de sécurité larges, et non de contrôles étroitement ciblés.

  • Utilisez les limites d'autorisations pour déléguer IAM l'administration de manière plus sûre.

    • Assurez-vous que les administrateurs délégués appliquent la politique de IAM limites appropriée aux rôles et aux utilisateurs qu'ils créent.

  • En tant qu' defense-in-depthapproche (en conjonction avec des politiques basées sur l'identité), utilisez des IAM politiques basées sur les ressources pour refuser un large accès aux ressources.

  • Utilisez le conseiller IAM d'accès AWS CloudTrail, AWS IAM l'analyseur d'accès et les outils associés pour analyser régulièrement l'historique de l'utilisation et les autorisations accordées. Corrigez immédiatement les autorisations excessives évidentes.

  • Délimitez les actions générales à des ressources spécifiques, le cas échéant, au lieu d'utiliser un astérisque comme caractère générique pour indiquer toutes les ressources.

  • Mettez en œuvre un mécanisme permettant d'identifier, d'examiner et d'approuver rapidement les exceptions aux IAM politiques en fonction des demandes.