Approches dynamiques de gestion des autorisations

Comprendre l'architecture des autorisations Transfer Family

AWS Transfer Family prend en charge la gestion dynamique des autorisations par le biais de politiques de session, qui vous permettent de restreindre les autorisations effectives des rôles IAM lors de l'exécution. Cette approche fonctionne à la fois pour les utilisateurs gérés par des services et pour les utilisateurs de fournisseurs d'identité personnalisés, mais elle n'est prise en charge que lors du transfert de fichiers vers ou depuis Amazon S3 (et non Amazon EFS).

Chaque AWS Transfer Family utilisateur fonctionne avec un modèle d'autorisation qui comprend :

1. Rôle IAM de base : définit les autorisations de base pour l'utilisateur

2. Politique de session facultative : restreint (étend vers le bas) les autorisations de base lors de l'exécution

Les autorisations effectives se situent à l'intersection des autorisations relatives au rôle de base et des autorisations liées à la politique de session. Les politiques de session ne peuvent que restreindre les autorisations ; elles ne peuvent pas accorder d'autorisations supplémentaires au-delà de ce que permet le rôle de base.

Cette architecture s'applique aux deux types d'utilisateurs :

• Utilisateurs gérés par le service : les politiques de session peuvent être configurées directement dans les paramètres utilisateur

• Utilisateurs du fournisseur d'identité personnalisé : les politiques de session peuvent être renvoyées dans le cadre de la réponse d'authentification ou stockées dans AWS Secrets Manager

Deux approches de gestion des autorisations

Lorsque vous concevez des autorisations pour les utilisateurs de Transfer Family qui ont besoin de modèles d'accès uniques, vous pouvez choisir entre deux approches principales :

Un rôle par utilisateur

Créez un rôle IAM distinct pour chaque utilisateur de Transfer Family avec des autorisations spécifiques adaptées aux besoins de cet utilisateur. Utilisez cette approche lorsque :

• Chaque utilisateur a besoin d'autorisations très différentes

• L'administration des autorisations est gérée par différentes personnes au sein de votre organisation

• Vous avez besoin d'un contrôle précis de l'accès des utilisateurs individuels

Rôle partagé avec politiques de session

Utilisez un rôle IAM unique avec des autorisations étendues (telles que l'accès à un compartiment Amazon S3 complet contenant plusieurs répertoires personnels d'utilisateurs) et appliquez des politiques de session pour restreindre chaque utilisateur à sa zone spécifique. Cette approche réduit considérablement les frais administratifs par rapport à la gestion de rôles distincts pour chaque utilisateur. Utilisez cette approche lorsque :

• Les utilisateurs ont besoin de types d'accès similaires mais à des ressources différentes (par exemple, tous les utilisateurs doivent read/write avoir accès, mais chacun uniquement à son propre dossier)

• Vous souhaitez simplifier la gestion des rôles et éviter de créer des dizaines ou des centaines de rôles individuels

• Les utilisateurs ne doivent accéder qu'à leurs répertoires de base désignés dans un compartiment partagé

• L'administration des autorisations est centralisée au sein de votre organisation

Par exemple, au lieu de créer des rôles distincts pour les utilisateurs « alice », « bob » et « charlie », vous pouvez créer un rôle avec accès à l'ensemble du s3://company-transfers/ bucket, puis utiliser des politiques de session pour restreindre alice à s3://company-transfers/alice/s3://company-transfers/bob/, bob à, etc.

Mise en œuvre des politiques de session

Les politiques de session fonctionnent en limitant les autorisations effectives du rôle IAM de base attribué à un utilisateur. Les autorisations finales se situent à l'intersection des autorisations du rôle et des autorisations de la politique de session.

Vous pouvez implémenter des politiques de session dynamiques de deux manières :

Substitution de variables

Utilisez les variables de politique Transfer Family telles que ${transfer:Username}${transfer:HomeDirectory}, et ${transfer:HomeBucket} dans les politiques de votre session. Ces variables sont automatiquement remplacées par les valeurs réelles lors de l'exécution. Pour plus d'informations sur ces variables, consultezCréation d'une politique de session pour un compartiment Amazon S3.

Génération dynamique

Pour les fournisseurs d'identité personnalisés, générez des politiques de session dans le on-the-fly cadre de la réponse d'authentification à partir de votre fonction Lambda ou de votre méthode API Gateway. Cette approche vous permet de créer des politiques hautement personnalisées basées sur les attributs des utilisateurs, les appartenances à des groupes ou les sources de données externes au moment de l'authentification.

Vous pouvez également stocker des politiques de session prégénérées AWS Secrets Manager en incluant une clé nommée Policy avec la politique de session JSON comme valeur. Cela vous permet d'utiliser le même rôle IAM étendu pour plusieurs utilisateurs tout en conservant des contrôles d'accès spécifiques à l'utilisateur.

Note

Les politiques de session ne sont prises en charge que pour les transferts de fichiers vers et depuis Amazon S3. Ils ne s'appliquent pas aux systèmes de fichiers Amazon EFS. Pour Amazon EFS, les autorisations sont régies par le système de fichiers lui-même UID/GID et les bits d'autorisation sont appliqués dans celui-ci.

Implémentation par type d'utilisateur

Utilisateurs gérés par le service

Pour les utilisateurs gérés par des services, vous pouvez spécifier des politiques de session directement dans la configuration utilisateur via la AWS Transfer Family console, l'API ou la CLI. Pour de plus amples informations, veuillez consulter Travailler avec des utilisateurs gérés par des services.

Utilisateurs du fournisseur d'identité personnalisé

Pour les utilisateurs de fournisseurs d'identité personnalisés, vous pouvez fournir des politiques de session de deux manières :

• AWS Secrets Manager En incluant une clé nommée Policy avec la politique de session comme valeur

• Directement dans la réponse de la fonction Lambda ou dans la réponse API Gateway dans le cadre du résultat de l'authentification

Pour de plus amples informations, veuillez consulter Solution de fournisseur d'identité personnalisée.

Exemple : simplification de la gestion des rôles avec des politiques de session

Cet exemple montre comment la gestion dynamique des autorisations peut réduire considérablement les frais administratifs tout en préservant la sécurité.

Scénario

Votre organisation compte 50 utilisateurs qui ont besoin d'un accès SFTP pour transférer des fichiers. Chaque utilisateur ne doit accéder qu'à son propre dossier dans un compartiment Amazon S3 partagé appelécompany-transfers. Sans politiques de session, vous devriez créer 50 rôles IAM distincts.

Approche traditionnelle (sans politiques de session)

• Créez 50 rôles IAM :TransferRole-Alice,TransferRole-Bob,TransferRole-Charlie, etc.

• Chaque rôle dispose d'autorisations spécifiques uniquement pour le dossier de cet utilisateur

• La gestion des autorisations nécessite la mise à jour des rôles individuels

• L'ajout de nouveaux utilisateurs nécessite la création de nouveaux rôles

Approche dynamique (avec politiques de session)

• Création d'un rôle IAM : TransferRole-Shared avec des autorisations étendues pour l'ensemble du bucket

• Utilisez les politiques de session pour limiter chaque utilisateur à son dossier spécifique au moment de l'exécution

• La gestion des autorisations nécessite la mise à jour d'un modèle de politique de rôle ou de session

• L'ajout de nouveaux utilisateurs ne nécessite aucun nouveau rôle, juste une configuration utilisateur

Mise en œuvre

Voici comment implémenter l'approche dynamique (en utilisant le company-transfers bucket comme exemple à remplacer par votre bucket Amazon S3 actuel) :

Pour implémenter la gestion dynamique des autorisations

1. Créez un rôle IAM partagé avec des autorisations Amazon S3 étendues :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject"
         ],
         "Resource": "arn:aws:s3:::company-transfers/*"
       },
       {
         "Effect": "Allow",
         "Action": "s3:ListBucket",
         "Resource": "arn:aws:s3:::company-transfers"
       }
     ]
   }

2. Créez un modèle de politique de session qui restreint l'accès au dossier de l'utilisateur :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject"
         ],
         "Resource": "arn:aws:s3:::company-transfers/${transfer:Username}/*"
       },
       {
         "Effect": "Allow",
         "Action": "s3:ListBucket",
         "Resource": "arn:aws:s3:::company-transfers",
         "Condition": {
           "StringLike": {
             "s3:prefix": "${transfer:Username}*"
           }
         }
       }
     ]
   }

3. Configurez chaque utilisateur avec :

   • Le rôle IAM partagé

   • La politique de session s'appliquait comme suit :

     • Utilisateurs gérés par le service : utilisez l'API ou la CLI pour appliquer le JSON via le paramètre Policy lors de la création ou de la modification d'utilisateurs (la console propose uniquement des options de stratégie prédéfinies)

     • Utilisateurs du fournisseur d'identité personnalisé : renvoyez-le dans le cadre de la réponse de la fonction Lambda lors de l'authentification ou stockez-le AWS Secrets Manager sous forme de clé nommée « Policy » à côté des informations d'identification de l'utilisateur

   • Répertoire personnel : /company-transfers/${transfer:Username}/