Connexion à AWS Transfer pour SFTP

Question

Je n'arrive pas à me connecter à AWS Transfer pour SFTP . J'ai réussi à configurer un serveur et j'ai essayé de me connecter en utilisant WinSCP.

J'ai mis en place 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 du champ d'application comme suit décrite dans la documentation utilisation d'un répertoire personnel homebucket et le 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 en utilisant une clé ssh, mais lorsqu'il s'est agi de lire/écrire des fichiers, je n'ai cessé d'obtenir des erreurs opaques telles que "Error looking up homedir" et l'échec de "readdir". Tout cela ressemble beaucoup à des problèmes avec ma politique IAM, mais je n'ai pas réussi à le comprendre.

Answer 1

Nous avons rencontré des problèmes similaires pour faire fonctionner la politique de réduction du champ d'application avec nos utilisateurs sur AWS Transfer. La solution qui a fonctionné pour nous a consisté à créer deux types de politiques différents.

• Politique à rattacher au rôle qui a des droits généraux sur l'ensemble du seau.
• Définir la politique à appliquer à l'utilisateur qui utilise les variables du service de transfert comme {transfer:UserName} .

Nous avons conclu que peut-être seule la politique de rattachement supplémentaire est en mesure de résoudre les variables du service de transfert . Nous ne sommes pas sûrs que cela soit correct et qu'il s'agisse de la meilleure solution, car cela ouvre un risque possible lorsqu'il s'agit d'attacher la politique de réduction du champ d'application pour créer une sorte d'utilisateur "administrateur". Je serais donc ravi d'avoir des commentaires pour verrouiller un peu plus ce point.

Voici ce que cela donne dans ma console lorsque je regarde les détails de l'utilisateur de transfert :

Voici les deux politiques que nous utilisons :
Politique générale à rattacher au rôle d'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/*"
        }
    ]
}

Étendue de la politique à appliquer à l'utilisateur transféré

{
    "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}*"
        }
    ]
}

Answer 2

J'ai eu un problème similaire mais avec un comportement d'erreur différent. J'ai réussi à me connecter, mais la connexion a été presque immédiatement fermée. J'ai procédé comme suit :

• Assurez-vous que le rôle IAM qui autorise l'accès au seau contient également l'accès KMS si votre seau est crypté.
• Veillez à ce que la relation de confiance fasse également partie de ce rôle.
• Assurez-vous que le serveur lui-même a un rôle Cloudwatch avec une relation de confiance avec transfer.amazonaws.com ! C'est la solution que j'ai trouvée. Je ne comprends pas pourquoi c'est nécessaire, mais sans la relation de confiance dans le rôle Cloudwatch, ma connexion est fermée.

J'espère que cela vous aidera. Edit : Ajout d'une image pour les paramètres du rôle CloudWatch :

La politique des seaux 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 de confiance, comme indiqué ci-dessus, pour le rôle IAM de l'utilisateur.

Si vous pouvez vous connecter à votre sftp mais que vous obtenez une erreur readdir lorsque vous essayez de lister le contenu, par exemple avec la commande "ls", c'est le signe que vous n'avez pas l'autorisation bucket. Si votre connexion est immédiatement fermée, il semble qu'il s'agisse d'un problème de relation de confiance ou d'un problème de KMS.

Answer 3

D'après la documentation quelque peu énigmatique, @limfinity avait raison. Pour réduire l'accès, vous avez besoin d'une combinaison générale de rôle et de politique autorisant l'accès à la base de données. Ce rôle est appliqué à l'utilisateur SFTP que vous créez. En outre, vous avez besoin d'une politique personnalisée qui accorde des droits CRUD uniquement au panier de l'utilisateur. Cette politique personnalisée est également appliquée à l'utilisateur SFTP.

Extrait 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 politique de réduction d'étendue, utilisez les variables de politique suivantes dans votre politique IAM :

Guide de l'utilisateur d'AWS Transfer pour SFTP Création d'une politique de réduction d'échelle

• ${transfer:HomeBucket}
• ${transfer:HomeDirectory}
• ${transfer:HomeFolder}
• ${transfer:UserName}

Note Vous ne pouvez pas utiliser les variables énumérées ci-dessus comme variables de stratégie dans une définition de rôle IAM. Vous créez ces variables dans une politique IAM et les fournissez directement lors de la configuration de votre utilisateur. Vous ne pouvez pas non plus utiliser la variable ${aws:Username} dans cette politique de réduction d'étendue. Cette variable fait référence à un nom d'utilisateur IAM et non au nom d'utilisateur requis par AWS SFTP.

Answer 4

Je ne peux pas faire de commentaire, désolé si je poste mal.

Attention à la politique par défaut d'AWS !

Cette solution a fonctionné pour moi en ce sens que j'ai pu utiliser des politiques de réduction d'étendue pour les utilisateurs SFTP comme prévu. Cependant, il y a un problème :

{
            "Sid": "AWSTransferRequirements",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },

Cette section de la politique permettra aux utilisateurs SFTP utilisant cette politique de changer le répertoire en Root et de lister tous les buckets de votre compte. Ils n'auront pas accès à la lecture ou à l'écriture, mais ils pourront découvrir des choses qui sont probablement inutiles. Je peux confirmer que la modification de ce qui précède en :

{
            "Sid": "AWSTransferRequirements",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "${transfer:HomeBucket}"
        },

... semble empêcher les utilisateurs de SFTP de lister les buckets. Cependant, ils peuvent toujours cd aux répertoires s'ils ont connaissance de l'existence de godets -- encore une fois, ils n'ont pas le droit de lecture/écriture, mais c'est toujours un accès inutile. Il me manque probablement quelque chose pour empêcher cela dans ma politique.

Correct jailing semble être un sujet en souffrance : https://forums.aws.amazon.com/thread.jspa?threadID=297509&tstart=0

Answer 5

Nous utilisions la version mise à jour de SFTP avec nom d'utilisateur et mot de passe et nous avons dû passer un certain temps à comprendre tous les détails. Pour la nouvelle version, la politique Scope down doit être spécifiée en tant que clé 'Policy' dans Secrets Manager. C'est très important pour que l'ensemble du flux fonctionne.

Nous avons documenté la configuration complète sur notre site ici - https://coderise.io/sftp-on-aws-with-username-and-password/

J'espère que cela vous aidera !