As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Gerenciar controles de acesso
Você pode controlar o acesso de um usuário aos AWS Transfer Family recursos usando uma política AWS Identity and Access Management (IAM). Uma política do IAM é uma instrução, normalmente no formato JSON, que permite determinado nível de acesso a um recurso. Use uma política do IAM para definir quais operações de arquivo você deseja permitir ou não que os seus usuários executem. Você também pode usar uma política do IAM para definir o bucket ou buckets do Amazon S3 aos quais você deseja conceder acesso aos seus usuários. Para especificar essas políticas para os usuários, você cria uma função do IAM AWS Transfer Family que tenha a política do IAM e a relação de confiança associada a ela.
Cada usuário SFTP é atribuído um perfil do IAM. O tipo de função do IAM que AWS Transfer Family usa é chamado de *função de serviço*. Quando um usuário faz login no seu servidor, AWS Transfer Family assume a função do IAM mapeada para o usuário. Para saber mais sobre a criação de uma função do IAM que fornece ao usuário acesso a um bucket do Amazon S3, consulte [Criação de uma função para delegar permissões a um AWS serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no Guia do usuário do *IAM*.
Você pode conceder acesso somente de gravação aos objetos do Amazon S3 usando determinadas permissões dentro de uma política do IAM. Para obter detalhes, consulte [Conceder a capacidade de somente gravar e listar arquivos](configure-storage.md#headobject-access-denied).
O blog AWS de armazenamento contém uma postagem detalhando como configurar o acesso com privilégios mínimos. Para obter detalhes, consulte [Implementação do acesso com privilégios mínimos em um AWS Transfer Family fluxo de trabalho](https://aws.amazon.com/blogs//storage/implementing-least-privilege-access-in-an-aws-transfer-family-workflow/).
**nota**
Se seu bucket do Amazon S3 for criptografado usando AWS Key Management Service (AWS KMS), você deverá especificar permissões adicionais em sua política. Para obter detalhes, consulte [Proteção e criptografia de dados](encryption-at-rest.md). Além disso, é possível ver mais informações sobre [políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session.html) no *Guia do usuário do IAM*.
**Topics**
+ [Permitir acesso de leitura e gravação a um bucket do Amazon S3](users-policies-all-access.md)
+ [Criar uma política de sessão de um bucket do Amazon S3](users-policies-session.md)
+ [Abordagens dinâmicas de gerenciamento de permissões](dynamic-permission-management.md)
# Permitir acesso de leitura e gravação a um bucket do Amazon S3
Esta seção descreve como criar uma política do IAM que permite acesso de leitura e gravação a um bucket específico do Amazon S3. A atribuição de uma função do IAM que tenha essa política do IAM ao seu usuário dá a esse usuário read/write acesso ao bucket do Amazon S3 especificado.
A política a seguir fornece acesso de leitura e gravação programático a um bucket do Amazon S3. As declarações de `GetObjectACL` e `PutObjectACL` só são necessárias se você precisar habilitar o acesso entre contas. Ou seja, seu servidor Transfer Family precisa acessar um bucket em uma conta diferente.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid":"ReadWriteS3",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObjectVersion",
"s3:GetObjectVersionTagging",
"s3:GetObjectACL",
"s3:PutObjectACL"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"]
}
]
}
```
A ação `ListBucket` requer permissão para o bucket propriamente dito. As ações `PUT`, `GET` e `DELETE` exigem permissões de objeto. Como esses são recursos diferentes, eles são especificados usando diferentes nomes de recursos da Amazon (ARNs).
Para restringir ainda mais o acesso dos usuários somente ao prefixo `home` do bucket do Amazon S3 especificado, consulte [Criar uma política de sessão de um bucket do Amazon S3](users-policies-session.md).
# Criar uma política de sessão de um bucket do Amazon S3
Uma *política de sessão* é uma política AWS Identity and Access Management (IAM) que restringe os usuários a determinadas partes de um bucket do Amazon S3. Ela faz isso avaliando o acesso em tempo real.
**nota**
As políticas de sessão são usadas somente com o Amazon S3. Para o Amazon EFS, você usa permissões de arquivo POSIX para limitar o acesso.
Use uma política de sessão quando você precisar fornecer o mesmo acesso a determinada parte do seu bucket do Amazon S3 a um grupo de usuários. Por exemplo, um grupo de usuários pode precisar acessar somente o diretório `home`. Esse grupo de usuários compartilha o mesmo perfil do IAM.
**nota**
O tamanho máximo de uma política de sessão é 2.048 caracteres. Para obter mais detalhes, consulte o [parâmetro de solicitação de política](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_RequestSyntax) para a `CreateUser` ação na *referência da API*.
Para criar uma política de sessão, use as seguintes variáveis de política na sua política do IAM:
+ `${transfer:HomeBucket}`
+ `${transfer:HomeDirectory}`
+ `${transfer:HomeFolder}`
+ `${transfer:UserName}`
**Importante**
Você não pode usar as variáveis anteriores em políticas gerenciadas. Você também não pode usá-las como variáveis de política em uma definição de perfil do IAM. Crie essas variáveis em uma política do IAM e as forneça diretamente ao configurar o seu usuário. Além disso, você não pode usar a variável `${aws:Username}` nesta política de sessão. Essa variável refere-se a um nome de usuário do IAM, e não ao nome de usuário exigido pelo AWS Transfer Family.
## Exemplo de política de sessão
O código a seguir mostra um exemplo de política de sessão.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::${transfer:HomeBucket}"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:HomeFolder}/*",
"${transfer:HomeFolder}"
]
}
}
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion",
"s3:GetObjectACL",
"s3:PutObjectACL"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}/*"
}
]
}
```
**nota**
O exemplo de política anterior pressupõe que os usuários tenham seus diretórios pessoais configurados para incluir uma barra final, para indicar que é um diretório. Se, por outro lado, você definir um `HomeDirectory` de usuário sem a barra final, então deve incluí-lo como parte de sua política.
No exemplo anterior da política, observe o uso dos parâmetros de política `transfer:HomeFolder`, `transfer:HomeBucket`, e `transfer:HomeDirectory`. Esses parâmetros são definidos para o `HomeDirectory` que está configurado para o usuário, conforme descrito em [HomeDirectory](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectory)[Implementar seu método do API Gateway](authentication-api-gateway.md#authentication-api-method)e. Esses parâmetros têm as seguintes definições:
+ O parâmetro `transfer:HomeBucket` é substituído pelo primeiro componente do `HomeDirectory`.
+ O parâmetro `transfer:HomeFolder` é substituído pelas partes restantes do parâmetro `HomeDirectory`.
+ O parâmetro `transfer:HomeDirectory` tem a barra inicial (`/`) removida para que possa ser usado como parte do nome do recurso da Amazon (ARN) do S3 em uma instrução `Resource`.
**nota**
Se você estiver usando diretórios lógicos, ou seja, o `homeDirectoryType` do usuário é `LOGICAL`, esses parâmetros de política (`HomeBucket`,`HomeDirectory`, e `HomeFolder`) não serão compatíveis.
Por exemplo, suponha que o parâmetro `HomeDirectory` configurado para o usuário do Transfer Family seja `/home/bob/amazon/stuff/`.
+ `transfer:HomeBucket` está definido como `/home`.
+ `transfer:HomeFolder` está definido como `/bob/amazon/stuff/`.
+ `transfer:HomeDirectory` se torna `home/bob/amazon/stuff/`.
O primeiro `"Sid"` permite que o usuário liste todos os diretórios a partir de `/home/bob/amazon/stuff/`.
O segundo `"Sid"` limita o acesso `put` e `get` do usuário ao mesmo caminho,`/home/bob/amazon/stuff/`.
Com a política anterior vigente, ao fazer login, o usuário poderá acessar somente objetos em seu diretório inicial. No momento da conexão, AWS Transfer Family substitui essas variáveis pelos valores apropriados para o usuário. Isso facilita a aplicação das mesmas políticas para vários usuários. Essa abordagem reduz a sobrecarga de gerenciamento de perfil e política do IAM para gerenciar o acesso dos usuários ao seu bucket do Amazon S3.
Você também pode usar uma política de sessão para personalizar o acesso de cada um dos usuários com base em suas necessidades comerciais. Para obter mais informações, consulte [Permissões para AssumeRole, AssumeRoleWith SAML e AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_assumerole.html) no *Guia do usuário do IAM*.
**nota**
AWS Transfer Family armazena o JSON da política, em vez do Amazon Resource Name (ARN) da política. Portanto, ao alterar a política no console do IAM, você precisa retornar ao AWS Transfer Family console e atualizar seus usuários com o conteúdo mais recente da política. É possível atualizar o usuário na guia **Informações da política** na seção de **Configuração do usuário**.
Se você estiver usando o AWS CLI, você pode usar o comando a seguir para atualizar a política.
```
aws transfer update-user --server-id server --user-name user --policy \
"$(aws iam get-policy-version --policy-arn policy --version-id version --output json)"
```
## Substituições aninhadas para políticas de sessão
As substituições aninhadas não são realizadas nas políticas de sessão do Transfer Family. As políticas de sessão podem usar variáveis aninhadas, como`${transfer:HomeDirectory}`. Quando a política é processada, a variável externa (por exemplo,`${transfer:HomeDirectory}`) pode ser substituída por um valor que contém outra variável (por exemplo, \$1`amzn-s3-demo-bucket:/$(transfer:UserName}`). No entanto, a variável aninhada não é posteriormente substituída pelo nome de usuário real (por exemplo, **johndoe**).
Isso significa que, ao criar políticas de sessão para o Transfer Family, você precisa considerar esse comportamento e garantir que a estrutura da política e o uso de variáveis sejam projetados adequadamente. As variáveis aninhadas podem não ser resolvidas conforme o esperado e a política pode não conceder as permissões pretendidas. É importante testar e validar minuciosamente as políticas da sessão para garantir que funcionem conforme o esperado. Esse comportamento é uma consideração importante ao implementar controle de acesso e permissões para seu ambiente Transfer Family.
Uma solução para esse problema é usar o nome real do bucket Amazon S3 em sua política de sessão. Então, por exemplo, em vez de especificar `${transfer:HomeDirectory}` em sua política de sessão, use o seguinte, onde amzn-s3-demo-bucket é seu bucket real:. `${amzn-s3-demo-bucket/transfer:UserName}`
# Abordagens dinâmicas de gerenciamento de permissões
## Entendendo a arquitetura de permissão do Transfer Family
AWS Transfer Family oferece suporte ao gerenciamento dinâmico de permissões por meio de políticas de sessão, que permitem restringir as permissões efetivas das funções do IAM em tempo de execução. Essa abordagem funciona tanto para usuários gerenciados por serviços quanto para usuários de provedores de identidade personalizados, mas só é suportada na transferência de arquivos de ou para o Amazon S3 (não para o Amazon EFS).
Cada AWS Transfer Family usuário opera com um modelo de permissão que consiste em:
1. *Função básica do IAM* - Define as permissões básicas para o usuário
1. *Política de sessão opcional* - restringe (reduz o escopo) as permissões básicas em tempo de execução
As permissões efetivas são a interseção das permissões da função básica e das permissões da política de sessão. As políticas de sessão só podem restringir as permissões; elas não podem conceder permissões adicionais além do permitido pela função básica.
Essa arquitetura se aplica aos dois tipos de usuário:
+ *Usuários gerenciados por serviços* - as políticas de sessão podem ser configuradas diretamente nas configurações do usuário
+ *Usuários de provedores de identidade personalizados* - as políticas de sessão podem ser retornadas como parte da resposta de autenticação ou armazenadas em AWS Secrets Manager
## Duas abordagens para o gerenciamento de permissões
Ao criar permissões para usuários do Transfer Family que precisam de padrões de acesso exclusivos, você pode escolher entre duas abordagens principais:
Uma função por usuário
Crie uma função do IAM separada para cada usuário do Transfer Family com permissões específicas adaptadas às necessidades desse usuário. Use essa abordagem quando:
+ Cada usuário requer permissões muito diferentes
+ A administração de permissões é feita por diferentes pessoas em sua organização
+ Você precisa de um controle refinado sobre o acesso individual do usuário
Função compartilhada com políticas de sessão
Use uma única função do IAM com amplas permissões (como acesso a um bucket inteiro do Amazon S3 contendo vários diretórios iniciais de usuários) e aplique políticas de sessão para restringir cada usuário à sua área específica. Essa abordagem reduz significativamente a sobrecarga administrativa em comparação com o gerenciamento de funções separadas para cada usuário. Use essa abordagem quando:
+ Os usuários precisam de tipos de acesso semelhantes, mas a recursos diferentes (por exemplo, todos os usuários precisam read/write acessar, mas cada um somente à sua própria pasta)
+ Você quer simplificar o gerenciamento de funções e evitar a criação de dezenas ou centenas de funções individuais
+ Os usuários só devem acessar seus diretórios iniciais designados em um bucket compartilhado
+ A administração de permissões é centralizada em sua organização
Por exemplo, em vez de criar funções separadas para os usuários “alice”, “bob” e “charlie”, você pode criar uma função com acesso a todo o `s3://company-transfers/` bucket e, em seguida, usar políticas de sessão para restringir alice a`s3://company-transfers/alice/`, bob to `s3://company-transfers/bob/` e assim por diante.
## Implementando políticas de sessão
As políticas de sessão funcionam restringindo as permissões efetivas da função básica do IAM atribuída a um usuário. As permissões finais são a interseção das permissões da função e das permissões da política de sessão.
Você pode implementar políticas de sessão dinâmicas de duas maneiras:
Substituição de variáveis
Use variáveis de política do Transfer Family`${transfer:Username}`, como`${transfer:HomeDirectory}`,, e `${transfer:HomeBucket}` em suas políticas de sessão. Essas variáveis são substituídas automaticamente pelos valores reais em tempo de execução. Para obter mais informações sobre essas variáveis, consulte[Criar uma política de sessão de um bucket do Amazon S3](users-policies-session.md).
Geração dinâmica
Para provedores de identidade personalizados, gere políticas de sessão on-the-fly como parte da resposta de autenticação da sua função Lambda ou método do API Gateway. Essa abordagem permite criar políticas altamente personalizadas com base em atributos do usuário, associações a grupos ou fontes de dados externas no momento da autenticação.
Você também pode armazenar políticas de sessão AWS Secrets Manager pré-geradas incluindo uma chave nomeada `Policy` com o JSON da política de sessão como valor. Isso permite que você use a mesma função ampla do IAM em vários usuários, mantendo os controles de acesso específicos do usuário.
**nota**
As políticas de sessão são suportadas somente para transferências de arquivos de e para o Amazon S3. Eles não se aplicam aos sistemas de arquivos do Amazon EFS. Para o Amazon EFS, as permissões são governadas UID/GID e os bits de permissão aplicados dentro do próprio sistema de arquivos.
## Implementação por tipo de usuário
Usuário gerenciados por serviços
Para usuários gerenciados por serviços, você pode especificar políticas de sessão diretamente na configuração do usuário por meio do AWS Transfer Family console, da API ou da CLI. Para obter mais informações, consulte [Trabalhar com usuários gerenciados por serviços](service-managed-users.md).
Usuários de provedores de identidade personalizados
Para usuários de provedores de identidade personalizados, você pode fornecer políticas de sessão de duas maneiras:
+ AWS Secrets Manager Incluindo uma chave nomeada `Policy` com a política de sessão como valor
+ Diretamente na resposta da função Lambda ou na resposta do API Gateway como parte do resultado da autenticação
Para obter mais informações, consulte [Solução personalizada de provedor de identidade](custom-idp-toolkit.md).
## Exemplo: simplificação do gerenciamento de funções com políticas de sessão
Este exemplo demonstra como o gerenciamento dinâmico de permissões pode reduzir significativamente a sobrecarga administrativa e, ao mesmo tempo, manter a segurança.
### Cenário
Sua organização tem 50 usuários que precisam de acesso SFTP para transferir arquivos. Cada usuário só deve acessar sua própria pasta dentro de um bucket compartilhado do Amazon S3 chamado. `company-transfers` Sem as políticas de sessão, você precisaria criar 50 funções diferentes do IAM.
Abordagem tradicional (sem políticas de sessão)
+ Crie 50 funções do IAM:`TransferRole-Alice`,`TransferRole-Bob`,`TransferRole-Charlie`, etc.
+ Cada função tem permissões específicas somente para a pasta desse usuário
+ O gerenciamento de permissões requer a atualização de funções individuais
+ Adicionar novos usuários requer a criação de novas funções
Abordagem dinâmica (com políticas de sessão)
+ Crie 1 função do IAM: `TransferRole-Shared` com amplas permissões para todo o bucket
+ Use políticas de sessão para restringir cada usuário à sua pasta específica em tempo de execução
+ O gerenciamento de permissões requer a atualização de uma função ou modelo de política de sessão
+ Adicionar novos usuários não requer novas funções, apenas configuração do usuário
### Implementação
Veja como você implementaria a abordagem dinâmica (usando o `company-transfers` bucket como exemplo para ser substituído pelo seu bucket real do Amazon S3):
**Para implementar o gerenciamento dinâmico de permissões**
1. Crie uma função compartilhada do IAM com amplas permissões do Amazon S3:
****
```
{
"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"
}
]
}
```
1. Crie um modelo de política de sessão que restrinja o acesso à pasta do usuário:
****
```
{
"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}*"
}
}
}
]
}
```
1. Configure cada usuário com:
+ A função compartilhada do IAM
+ A política de sessão foi aplicada da seguinte forma:
+ *Usuários gerenciados por serviços*: use a API ou a CLI para aplicar o JSON por meio do parâmetro Policy ao criar ou modificar usuários (o console oferece apenas opções de política predefinidas)
+ *Usuários de provedores de identidade personalizados*: retorne-a como parte da resposta da função Lambda durante a autenticação ou armazene-a AWS Secrets Manager como uma chave chamada “Política” junto com as credenciais do usuário
+ Diretório inicial: `/company-transfers/${transfer:Username}/`