Подключение к передаче AWS для SFTP

У меня проблемы с подключением к AWS Transfer для SFTP. Я успешно настроил сервер и попытался подключиться с помощью WinSCP.

Я настроил роль IAM с помощью доверительных отношений следующим образом:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "transfer.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Я связал это с политикой уменьшения объема, как описано в документации, используя домашний каталог homebucket и домашний каталог 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}*"
        }
    ]
}

Мне удалось пройти проверку подлинности с помощью ключа ssh, но когда дело дошло до чтения/записи файлов, я просто получал непрозрачные ошибки, такие как "Ошибка при поиске homedir" и ошибка "readdir". Все это очень пахнет как проблемы с моей политикой IAM, но я не смог понять это.

Ответы

Ответ 1

У нас были похожие проблемы с получением политики по ограничению возможностей для работы с нашими пользователями в AWS Transfer. Решение, которое работало для нас, заключалось в создании двух разных типов политик.

Политику для прикрепления к роли, которая имеет общие права на все ведро.
Определите политику, применяемую к пользователю, который использует переменные службы передачи, такие как {transfer:UserName}.

Мы пришли к выводу, что, возможно, только дополнительная прикрепленная политика способна разрешить переменные службы передачи. Мы не уверены, правильно ли это, и является ли это лучшим решением, потому что это открывает возможный риск, когда вы отказываетесь от присоединения политики к области действия для создания своего рода "администратора". Так что я был бы рад получить информацию для дальнейшей блокировки немного.

Вот как это выглядит в моей консоли при просмотре данных пользователя передачи:

Вот две наши политики, которые мы используем:
Общая политика для присоединения к роли 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/*"
        }
    ]
}

Определите политику, применяемую для передачи пользователя

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

Ответ 2

У меня была похожая проблема, но с другим поведением ошибки. Мне удалось успешно войти в систему, но затем соединение было почти сразу закрыто. Я сделал следующие вещи:

Убедитесь, что роль IAM, которая разрешает доступ к сегменту, также содержит доступ к KMS, если ваш сегмент зашифрован.
Убедитесь, что доверительные отношения также являются частью этой роли.
Убедитесь, что у самого сервера есть роль Cloudwatch, а также доверительные отношения с Transfer.amazonaws.com! Это было решением для меня. Я не понимаю, зачем это нужно, но без доверительных отношений в роли Cloudwatch мое соединение закрывается.

Надеюсь, это поможет. Редактировать: Добавлена картинка для настроек роли CloudWatch:

Политика сегмента для роли пользователя IAM может выглядеть следующим образом:

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

}

Наконец, также добавьте доверительные отношения, как показано выше для роли IAM пользователя.

Если вы можете подключиться к своему sftp, но затем получить ошибку readdir при попытке вывести список содержимого, например, с помощью команды "ls", то это признак того, что у вас нет разрешения на ведро. Если ваше соединение сразу закрывается, это может быть проблемой доверительных отношений или проблемой KMS.

Ответ 3

Согласно довольно загадочной документации, @limfinity была верна. Чтобы ограничить доступ, вам нужна общая комбинация ролей и политик, предоставляющая доступ для просмотра корзины. Эта роль применяется к создаваемому вами пользователю SFTP. Кроме того, вам нужна настраиваемая политика, которая предоставляет права CRUD только группе пользователей. Пользовательская политика также применяется к пользователю SFTP.

Со страницы 24 этого документа... https://docs.aws.amazon.com/transfer/latest/userguide/sftp.ug.pdf#page=28&zoom=100,0,776

Чтобы создать политику уменьшения объема, используйте следующие переменные политики в своей политике IAM:

Руководство пользователя AWS Transfer for SFTP Создание политики ограничения объема

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

Примечание. Переменные, перечисленные выше, нельзя использовать в качестве переменных политики в определении роли IAM. Вы создаете эти переменные в политике IAM и предоставляете их непосредственно при настройке вашего пользователя. Кроме того, вы не можете использовать переменную $ {aws: Username} в этой политике сокращения области действия. Эта переменная ссылается на имя пользователя IAM, а не на имя пользователя, требуемое AWS SFTP.

Ответ 4

Не могу комментировать, извините, если я пишу неправильно.

Осторожнее с политикой по умолчанию AWS!

Это решение сработало для меня в том смысле, что я смог использовать политики уменьшения объема для пользователей SFTP, как и ожидалось. Однако тут есть одна загвоздка:

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

Этот раздел политики позволит пользователям SFTP, использующим эту политику, изменить каталог на корневой и перечислить все сегменты вашей учетной записи. У них не будет доступа для чтения или записи, но они могут обнаружить вещи, которые, вероятно, не нужны. Я могу подтвердить, что изменив вышеизложенное на:

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

... появляется, чтобы запретить пользователям SFTP перечислять сегменты. Тем не менее, они по-прежнему могут cd в каталоги, если они знают, что существуют сегменты - опять же, у них нет "чтения/записи", но это все еще ненужный доступ. Я, вероятно, что-то упускаю, чтобы предотвратить это в моей политике

Надлежащее jailing кажется, является темой отставания: https://forums.aws.amazon.com/thread.jspa?threadID=297509&tstart=0