Connexion à AWS Transfer pour SFTP
J'ai du mal à me connecter à AWS Transfer for SFTP . J'ai réussi à configurer un serveur et j'ai essayé de me connecter à l'aide de WinSCP.
J'ai configuré un rôle IAM avec des relations de confiance comme suit:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
J'ai associé cela à une politique de réduction de la portée comme décrite dans la documentation en utilisant un répertoire personnel homebucket et un répertoire personnel homedir
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListHomeDir",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": "arn:aws:s3:::${transfer:HomeBucket}"
},
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:PutObject",
"s3:GetObjectAcl",
"s3:GetObject",
"s3:GetObjectVersionAcl",
"s3:GetObjectTagging",
"s3:PutObjectTagging",
"s3:PutObjectAcl",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}*"
}
]
}
J'ai pu m'authentifier à l'aide d'une clé ssh, mais en ce qui concerne la lecture/l'écriture de fichiers, je n'arrêtais pas d'obtenir des erreurs opaques comme "Erreur lors de la recherche de homedir" et j'ai échoué "readdir". Tout cela ressemble beaucoup à des problèmes avec ma politique IAM mais je n'ai pas pu le comprendre.
Nous avons rencontré des problèmes similaires pour que la stratégie de réduction de la portée fonctionne avec nos utilisateurs sur AWS Transfer. La solution qui a fonctionné pour nous consistait à créer deux types de politiques différents.
- Stratégie à attacher au rôle qui a des droits généraux sur l'ensemble du bucket.
- Stratégie de portée limitée à appliquer à l'utilisateur qui utilise les variables du service de transfert comme
{transfer:UserName}.
Nous avons conclu que peut-être seule la politique supplémentaire jointe est capable de résoudre les variables du service de transfert . Nous ne savons pas si cela est correct et si c'est la meilleure solution, car cela ouvre le risque possible lorsque vous pardonnez d'attacher la stratégie d'étendue vers le bas pour créer une sorte d'utilisateur "admin". Je serais donc heureux d'obtenir des informations pour verrouiller davantage cela un peu.
Voici à quoi cela ressemble dans ma console en regardant les détails de l'utilisateur de transfert: 
Voici nos deux politiques que nous utilisons:
Politique générale à attacher au rôle IAM
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::my-s3-bucket"
]
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3::: my-s3-bucket/*"
}
]
}
Limiter la politique à appliquer pour transférer l'utilisateur
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::${transfer:HomeBucket}"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:UserName}/*",
"${transfer:UserName}"
]
}
}
},
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}*"
}
]
}
J'ai eu un problème similaire mais avec un comportement d'erreur différent. J'ai réussi à me connecter avec succès, mais la connexion a été presque immédiatement fermée. J'ai fait les choses suivantes:
- Assurez-vous que le rôle IAM qui autorise l'accès au compartiment contient également l'accès KMS si votre compartiment est chiffré.
- Assurez-vous que la relation de confiance fait également partie de ce rôle.
- Assurez-vous que le serveur lui-même a également un rôle Cloudwatch avec une relation de confiance avec transfer.amazonaws.com! C'était la solution pour moi. Je ne comprends pas pourquoi cela est nécessaire, mais sans la relation de confiance dans le rôle Cloudwatch, ma connexion est fermée.
J'espère que ça aide. Modifier: Ajout d'une image pour les paramètres du rôle CloudWatch: 
La stratégie de compartiment pour le rôle d'utilisateur IAM peut ressembler à ceci:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<your bucket>"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::<your bucket>/*"
]
}
]
}
Enfin, ajoutez également une relation d'approbation comme indiqué ci-dessus pour le rôle IAM de l'utilisateur.
Si vous pouvez vous connecter à votre sftp mais obtenez une erreur readdir lorsque vous essayez de lister le contenu, par exemple avec la commande "ls", c'est un signe que vous n'avez aucune autorisation de compartiment. Si votre connexion est fermée immédiatement, cela semble être un problème de relation de confiance ou un problème KMS.
Selon la documentation quelque peu cryptée, @limfinity était correcte. Pour limiter l'accès, vous avez besoin d'une combinaison générale de rôle/stratégie accordant l'accès pour voir le compartiment. Ce rôle est appliqué à l'utilisateur SFTP que vous créez. De plus, vous avez besoin d'une stratégie personnalisée qui accorde des droits CRUD uniquement au compartiment de l'utilisateur. La stratégie personnalisée est également appliquée à l'utilisateur SFTP.
À partir de la page 24 de ce document ... https://docs.aws.Amazon.com/transfer/latest/userguide/sftp.ug.pdf#page=28&zoom=100,0,776
Pour créer une stratégie d'étendue réduite, utilisez les variables de stratégie suivantes dans votre stratégie IAM:
Guide de l'utilisateur d'AWS Transfer for SFTP Création d'une stratégie d'étendue
• ${transfer:HomeBucket}
• ${transfer:HomeDirectory}
• ${transfer:HomeFolder}
• ${transfer:UserName}
Remarque Vous ne pouvez pas utiliser les variables répertoriées ci-dessus en tant que variables de stratégie dans une définition de rôle IAM. Vous créez ces variables dans une stratégie IAM et les fournissez directement lors de la configuration de votre utilisateur. De plus, vous ne pouvez pas utiliser la variable $ {aws: Username} dans cette stratégie de limitation de portée. Cette variable fait référence à un nom d'utilisateur IAM et non au nom d'utilisateur requis par AWS SFTP.
Je ne peux pas commenter, désolé si je poste incorrectement.
Attention à la politique par défaut d'AWS!
Cette solution a fonctionné pour moi dans la mesure où j'ai pu utiliser les stratégies de réduction de portée pour les utilisateurs SFTP comme prévu. Cependant, il y a un hic:
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
Cette section de la stratégie permettra aux utilisateurs SFTP utilisant cette stratégie de changer de répertoire en racine et de répertorier tous les compartiments de votre compte. Ils n'auront pas accès à la lecture ou à l'écriture, mais ils peuvent découvrir des choses qui sont probablement inutiles. Je peux confirmer que changer ce qui précède en:
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "${transfer:HomeBucket}"
},
... semble empêcher les utilisateurs SFTP de répertorier les compartiments. Cependant, ils peuvent toujours cd vers des répertoires s'ils connaissent des compartiments qui existent - encore une fois, ils n'ont pas de lecture/écriture, mais cela reste un accès inutile. Il me manque probablement quelque chose pour empêcher cela dans ma politique.
Le bon jailing semble être un sujet de backlog: https://forums.aws.Amazon.com/thread.jspa?threadID=297509&tstart=