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á.
# Gerenciando usuários para endpoints de servidor
Nas seções a seguir, você encontrará informações sobre como adicionar usuários usando AWS Transfer Family AWS Directory Service for Microsoft Active Directory ou um provedor de identidade personalizado.
Como parte das propriedades de cada usuário, você também pode armazenar a chave pública Secure Shell (SSH) desse usuário. Isso é necessário para a autenticação baseada em chaves. A chave privada será armazenada localmente no computador do seu usuário. Quando o usuário envia uma solicitação de autenticação ao seu servidor usando um cliente, o servidor confirma que o usuário tem acesso à chave privada SSH associada. Em seguida, o servidor autentica o usuário com êxito.
**nota**
Para implantação e gerenciamento automatizados de usuários com várias chaves SSH, consulte[Módulos Transfer Family Terraform](terraform.md).
Além disso, especifique um diretório da página inicial do usuário, ou o diretório inicial, e atribua um perfil (IAM) do AWS Identity and Access Management para o usuário. Opcionalmente, é possível fornecer uma política de sessão para limitar o acesso do usuário somente ao diretório do seu bucket do Amazon S3.
**Importante**
AWS Transfer Family bloqueia a autenticação de nomes de usuário com 1 ou 2 caracteres nos servidores SFTP. Além disso, também bloqueamos o nome de usuário `root`.
A razão por trás disso é devido ao grande volume de tentativas mal-intencionadas de login por scanners de senha.
## Amazon EFS versus Amazon S3
Características de cada opção de armazenamento:
+ Para limitar o acesso: o Amazon S3 oferece suporte a políticas de sessão; o Amazon EFS oferece suporte a usuários, grupos e grupos secundários POSIX IDs
+ Ambas as public/private teclas de suporte
+ Ambos dão suporte a diretórios iniciais
+ Ambos dão suporte a diretórios lógicos
**nota**
Para o Amazon S3, a maior parte do suporte para diretórios lógicos é por meio da API/CLI. É possível usar a caixa de seleção **Restrito** no console para bloquear um usuário em seu diretório inicial, mas não pode especificar uma estrutura de diretório virtual.
## Diretórios lógicos
Se você estiver especificando valores de diretório lógico para seu usuário, o parâmetro usado dependerá do tipo de usuário.
+ Para usuários gerenciados por serviços, forneça valores de diretório lógico em `HomeDirectoryMappings`.
+ Para usuários de provedores de identidade personalizados, forneça valores de diretório lógico em`HomeDirectoryDetails`.
AWS Transfer Family suporta a especificação de um HomeDirectory valor ao usar o LOGICAL HomeDirectoryType. Isso se aplica aos usuários do Service Managed, ao acesso ao Active Directory e às implementações do Provedor de Identidade Personalizado, onde HomeDirectoryDetails são fornecidos na resposta.
**Importante**
Ao especificar um HomeDirectory com LOGICAL HomeDirectoryType, o valor deve ser mapeado para um de seus mapeamentos lógicos de diretório. O serviço valida isso durante a criação e as atualizações do usuário para evitar configurações que não funcionariam.
### Comportamento padrão do
Por padrão, se não for especificado, o HomeDirectory é definido como “/” para o modo LÓGICO. Esse comportamento permanece inalterado e permanece compatível com as definições de usuário existentes.
+ Certifique-se de mapear sua entrada HomeDirectory para uma *entrada* e não para um *alvo*. Consulte mais detalhes em [Regras para usar diretórios lógicos](logical-dir-mappings.md#logical-dir-rules).
+ Para obter detalhes sobre como um diretório virtual é estruturado, consulte[Estrutura do diretório virtual](implement-log-dirs.md#virtual-dirs).
### Considerações sobre provedores de identidade personalizados
Ao usar um provedor de identidade personalizado, agora você pode especificar um HomeDirectory na resposta ao usar o LOGICAL HomeDirectoryType. A chamada da TestIdentityProvider API produzirá resultados corretos quando o IDP personalizado especificar um HomeDirectory no modo LÓGICO.
Exemplo de resposta personalizada do IDP com HomeDirectory e LOGICAL HomeDirectoryType:
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-user-role",
"HomeDirectoryType": "LOGICAL",
"HomeDirectory": "/marketing",
"HomeDirectoryDetails": "[{\"Entry\":\"/\",\"Target\":\"/bucket/home\"},{\"Entry\":\"/marketing\",\"Target\":\"/marketing-bucket/campaigns\"}]"
}
```
## Cotas de grupo do Active Directory
AWS Transfer Family tem um limite padrão de 100 grupos do Active Directory por servidor. Se seu caso de uso exigir mais de 100 grupos, considere usar uma solução de provedor de identidade personalizada, conforme descrito em [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
Esse limite se aplica aos servidores que usam os seguintes provedores de identidade:
+ AWS Directory Service para Microsoft Active Directory
+ AWS Directory Service para serviços de domínio Entra ID
Se você precisar solicitar um aumento do limite de serviço, consulte as [AWS service (Serviço da AWS) cotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) no *Referência geral da AWS*. Se seu caso de uso exigir mais de 100 grupos, considere usar uma solução de provedor de identidade personalizada, conforme descrito em [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
Para obter informações sobre solução de problemas relacionadas aos limites de grupos do Active Directory, consulte[Limites de grupos do Active Directory excedidos](auth-issues.md#managed-ad-group-limits).
**Topics**
+ [Amazon EFS versus Amazon S3](#efs-vs-s3-users)
+ [Diretórios lógicos](#logical-dir-users)
+ [Cotas de grupo do Active Directory](#ad-group-quotas)
+ [Trabalhar com usuários gerenciados por serviços](service-managed-users.md)
+ [Trabalhar com provedores de identidade personalizados](custom-idp-intro.md)
+ [Usando o AWS Directory Service para o Microsoft Active Directory](directory-services-users.md)
+ [Usando o AWS Directory Service para serviços de domínio Entra ID](azure-sftp.md)
# Trabalhar com usuários gerenciados por serviços
É possível adicionar usuários gerenciados por serviços do Amazon S3 ou do Amazon EFS ao seu servidor, dependendo da configuração de **domínio** do servidor. Para obter mais informações, consulte [Configurando um endpoint de servidor SFTP, FTPS ou FTP](tf-server-endpoint.md).
Se você usar um tipo de identidade gerenciada por serviço, adicione usuários ao seu servidor habilitado para SFTP. Ao fazer isso, cada nome de usuário deve ser único no servidor.
Para adicionar programaticamente um usuário gerenciado pelo serviço, veja o [exemplo](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_Examples) da API. [CreateUser](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html)
**nota**
Para usuários gerenciados por serviços, há um limite de 2.000 entradas de diretório lógico. Para obter informações sobre o uso de diretórios lógicos, consulte[Como usar diretórios lógicos para simplificar suas estruturas de diretórios do Transfer Family](logical-dir-mappings.md).
**Topics**
+ [Adicionar usuários gerenciados por serviços do Amazon S3](#add-s3-user)
+ [Adicionar usuários gerenciados por serviços do Amazon EFS](#add-efs-user)
+ [Gerenciar usuários gerenciados por serviços](#managing-service-managed-users)
## Adicionar usuários gerenciados por serviços do Amazon S3
**nota**
Se você quiser configurar um bucket Amazon S3 com várias contas, siga as etapas mencionadas neste artigo do Knowledge Center: [Como configuro meu AWS Transfer Family servidor para usar um bucket do Amazon Simple Storage Service que está em outra AWS](https://aws.amazon.com/premiumsupport/knowledge-center/sftp-cross-account-s3-bucket/) conta? .
**Para adicionar um usuário gerenciado por serviços do Amazon S3 ao seu servidor**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)e selecione **Servidores** no painel de navegação.
1. Na página **Servidores**, escolha a caixa de seleção ao lado do servidor para o qual você deseja adicionar um usuário.
1. Escolha **Adicionar usuário**.
1. Na seção **Configuração do usuário**, em **Nome de usuário**, insira o nome de usuário. Esse nome de usuário deve ter, no mínimo, 3 e, no máximo 100 caracteres. Você pode usar os seguintes caracteres no nome de usuário: a—z, A-Z, 0—9, sublinhado '\$1', hífen '-', ponto '.' e sinal de arroba '@'. O nome de usuário não pode começar com um hífen '-', ponto '.' ou com o sinal '@'.
1. Para For **Acesso**, selecione o perfil do IAM que você criou anteriormente e que fornece acesso ao seu bucket do Amazon S3.
Você criou esse perfil do IAM usando o procedimento em [Criar uma política e um perfil do IAM](requirements-roles.md). Esso perfil do IAM inclui uma política do IAM que fornece acesso ao seu bucket do Amazon S3. Também inclui uma relação de confiança com o AWS Transfer Family serviço, definida em outra política do IAM. Se você precisar de um controle de acesso refinado para seus usuários, consulte a postagem do blog [Enhance data access with an Amazon AWS Transfer Family S3](https://aws.amazon.com/blogs/storage/enhance-data-access-control-with-aws-transfer-family-and-amazon-s3-access-points/).
1. (Opcional) Para **Política**, selecione uma das seguintes ações:
+ **Nenhum**
+ **Política existente**
+ **Selecione uma política do IAM**: permite que você escolha uma política de sessão existente. Escolha **Exibir** para ver um objeto JSON contendo os detalhes da política.
+ **Política de geração automática com base na pasta inicial**: gera uma política de sessão para você. Escolha **Exibir** para ver um objeto JSON contendo os detalhes da política.
**nota**
Se você escolher **Gerar política automaticamente com base na pasta inicial**, não selecione **Restrito** para esse usuário.
Para saber mais sobre as políticas de sessão[Criar uma política e um perfil do IAM](requirements-roles.md), consulte[Criar uma política de sessão de um bucket do Amazon S3](users-policies-session.md), ou[Abordagens dinâmicas de gerenciamento de permissões](dynamic-permission-management.md).
1. Para o **diretório inicial**, escolha o bucket do Amazon S3 para armazenar os dados a serem transferidos usando. AWS Transfer Family Insira o caminho no diretório `home` que o usuário acessa quando faz login usando seu cliente.
Se você deixar esse parâmetro em branco, o diretório `root` do seu bucket do Amazon S3 será usado. Nesse caso, certifique-se de que seu perfil do IAM fornece acesso a esse `root` diretório.
**nota**
Recomendamos que você escolha um caminho de diretório que contenha o nome do usuário, o que permite que você efetivamente use uma política de sessão. A política de sessão limita o acesso do usuário no bucket do Amazon S3 para o diretório `home` do usuário.
1. (Opcional) Em **Restrito**, marque a caixa de seleção para que seus usuários não possam acessar nada fora dessa pasta e não possam ver o bucket ou o nome da pasta do Amazon S3.
**nota**
Atribuir ao usuário um diretório inicial e restringir o usuário a esse diretório inicial deve ser suficiente para bloquear o acesso do usuário à pasta designada. Se você precisar aplicar mais controles, use uma política de sessão.
Se você selecionar **Restrito** para esse usuário, não poderá selecionar a **Política gerada automaticamente com base na pasta inicial**, pois a pasta inicial não é um valor definido para usuários restritos.
1. Para **chave pública SSH**, insira a parte da chave pública SSH do par de chaves SSH.
Sua chave é validada pelo serviço antes que você possa adicionar o novo usuário.
**nota**
Para obter instruções sobre como gerar um par de chaves SSH, consulte [Gere chaves SSH para usuários gerenciados por serviços](sshkeygen.md).
1. (Opcional) Em **Chave** e **Valor**, insira uma ou mais tags como pares de chave/valor e escolha **Adicionar tag**.
1. Escolha **Adicionar** para adicionar o novo usuário ao servidor que você escolheu.
O novo usuário será exibido na seção **Usuários** da página **Detalhes do servidor**.
**Próximas etapas** - Para a próxima etapa, continue em [Transferindo arquivos em um endpoint de servidor usando um cliente](transfer-file.md).
## Adicionar usuários gerenciados por serviços do Amazon EFS
O Amazon EFS usa o modelo de permissão de arquivo da Portable Operating System Interface (POSIX) para representar a propriedade do arquivo.
+ Para obter mais detalhes sobre a propriedade de arquivos do Amazon EFS, consulte [Propriedade do arquivo do Amazon EFS](configure-storage.md#efs-file-ownership).
+ Para obter mais detalhes sobre a configuração de diretórios para seus usuários do EFS, consulte [Configurar usuários do Amazon EFS para Transfer Family](configure-storage.md#configure-efs-users-permissions).
**Para adicionar um usuário gerenciado por serviços do Amazon EFS ao seu servidor**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)e selecione **Servidores** no painel de navegação.
1. Na página **Servidores**, selecione o servidor do Amazon EFS ao qual você deseja adicionar um usuário.
1. Escolha **Adicionar usuário** para exibir a página **Adicionar usuário**.
1. Na seção **Configuração de usuários**, use as seguintes configurações.
1. Esse **Nome de usuário** deve ter, no mínimo, 3 e, no máximo 100 caracteres. É possível usar os seguintes caracteres no nome de usuário: a-z, A-Z, 0-9, sublinhado, '\$1', hífen '-', ponto final '.' e o sinal de arroba "@". O nome de usuário não pode começar com hífen '-', ponto final '.' ou o sinal de arroba "@".
1. Para **ID de usuário** e **ID de grupo**, observe o seguinte:
+ Para o primeiro usuário que você criar, recomendamos que você insira um valor de ID **0** de **ID de grupo** e **ID de usuário**. Isso concede ao usuário privilégios de administrador para o Amazon EFS.
+ Para usuários adicionais, insira o ID de usuário POSIX e o ID do grupo do usuário. Eles IDs são usados para todas as operações do Amazon Elastic File System realizadas pelo usuário.
+ Para **ID de usuário** e **ID de grupo**, não use nenhum zero à esquerda. Por exemplo, **12345** é aceitável, mas **012345** não é.
1. (Opcional) Em **Grupo secundário IDs**, insira um ou mais grupos POSIX adicionais IDs para cada usuário, separados por vírgulas.
1. Para **Acesso**, escolha o perfil do IAM que:
+ Concede ao usuário acesso apenas aos recursos do Amazon EFS (sistemas de arquivos) que você deseja que ele acesse.
+ Define quais operações do sistema de arquivos o usuário pode ou não realizar.
Recomendamos que você use a função do IAM para a seleção do sistema de arquivos do Amazon EFS com acesso e read/write permissões de montagem. Por exemplo, a combinação das duas políticas AWS gerenciadas a seguir, embora bastante permissiva, concede as permissões necessárias para seu usuário:
+ AmazonElasticFileSystemClientFullAccess
+ AWSTransferConsoleFullAccess
Para obter mais informações, consulte a publicação do blog: [Suporte do AWS Transfer Family para Amazon Elastic File System](https://aws.amazon.com/blogs/aws/new-aws-transfer-family-support-for-amazon-elastic-file-system/).
1. Para o **Diretório inicial**, faça o seguinte:
+ Escolha o sistema de arquivos do Amazon EFS que você deseja usar para armazenar os dados a serem transferidos usando AWS Transfer Family.
+ Decida se deseja definir o diretório inicial como **Restrito**. Definir o diretório inicial como **Restrito** tem os seguintes efeitos:
+ Os usuários do Amazon EFS não podem acessar nenhum arquivo ou diretório fora dessa pasta.
+ Os usuários do Amazon EFS não conseguem ver o nome do sistema de arquivos do Amazon EFS (**fs-xxxxxxx**).
**nota**
Quando você seleciona a opção **Restrito**, os links simbólicos não são resolvidos para os usuários do Amazon EFS.
+ (Opcional) Insira o caminho para o diretório inicial no qual você deseja que os usuários estejam quando fizerem login usando o cliente.
Se você não especificar um diretório inicial, o diretório raiz do seu sistema de arquivos Amazon EFS será usado. Nesse caso, certifique-se de que seu perfil do IAM fornece acesso a esse diretório .
1. Para **chave pública SSH**, insira a parte da chave pública SSH do par de chaves SSH.
Sua chave é validada pelo serviço antes que você possa adicionar o novo usuário.
**nota**
Para obter instruções sobre como gerar um par de chaves SSH, consulte [Gere chaves SSH para usuários gerenciados por serviços](sshkeygen.md).
1. (Opcional) Insira qualquer tag para o usuário. Para **Chave** and **Valor**, insira uma ou mais tags como pares de chave/valor e escolha **Adicionar tag**.
1. Escolha **Adicionar** para adicionar o novo usuário ao servidor que você escolheu.
O novo usuário será exibido na seção **Usuários** da página **Detalhes do servidor**.
Problemas possíveis de encontrar ao usar o SFTP pela primeira vez no servidor do Transfer Family:
+ Se você executar o comando `sftp` e o prompt não aparecer, é possível encontrar a seguinte mensagem:
`Couldn't canonicalize: Permission denied`
`Need cwd`
Nesse caso, aumente as permissões da política para a função do seu usuário. Você pode adicionar uma política AWS gerenciada, como`AmazonElasticFileSystemClientFullAccess`.
+ Se você entrar `pwd` no `sftp` prompt para visualizar o diretório inicial do usuário, poderá ver a seguinte mensagem, onde *USER-HOME-DIRECTORY* está o diretório inicial do usuário SFTP:
`remote readdir("/USER-HOME-DIRECTORY"): No such file or directory`
Nesse caso, você deve conseguir navegar até o diretório pai (`cd ..`) e criar o diretório inicial do usuário (`mkdir username`).
**Próximas etapas** - Para a próxima etapa, continue em [Transferindo arquivos em um endpoint de servidor usando um cliente](transfer-file.md).
## Gerenciar usuários gerenciados por serviços
Nesta seção, é possível encontrar informações sobre como visualizar uma lista de usuários, como editar detalhes do usuário e como adicionar uma chave pública SSH.
+ [Exibir uma lista de usuários](#list-users)
+ [Exibir ou editar detalhes do usuário](#view-user-details)
+ [Exclusão de um usuário](#delete-user)
+ [Adicionar chave pública SSH](#add-user-ssh-key)
+ [Excluir chave pública SSH](#delete-user-ssh-key)
**Para encontrar uma lista de seus usuários**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Selecione **Servidores** no painel de navegação para exibir a página **Servidores**.
1. Escolha o identificador na coluna **ID do servidor** para ver a página **Detalhes do servidor**.
1. Em **Usuários**, veja uma lista de usuários.
**Para visualizar ou editar detalhes do usuário**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Selecione **Servidores** no painel de navegação para exibir a página **Servidores**.
1. Escolha o identificador na coluna **ID do servidor** para ver a página **Configuração do servidor**.
1. Em **Usuários**, escolha um nome de usuário para ver a página de **Detalhes do usuário**.
É possível alterar as propriedades do usuário nessa página escolhendo **Editar**.
1. Na página **Detalhes do usuário**, escolha **Editar** ao lado de **Configuração do usuário**.
![\[Imagem mostrando a tela para edição da configuração de um usuário\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/edit-user-details-page-user-config.png)
1. Na página **Editar configuração**, para **Acesso**, escolha o perfil do IAM que você criou antes e que fornece acesso ao seu bucket do Amazon S3.
Você criou esse perfil do IAM usando o procedimento em [Criar uma política e um perfil do IAM](requirements-roles.md). Esso perfil do IAM inclui uma política do IAM que fornece acesso ao seu bucket do Amazon S3. Também inclui uma relação de confiança com o AWS Transfer Family serviço, definida em outra política do IAM.
1. (Opcional) Para **Política**, escolha uma das seguintes opções:
+ **Nenhum**
+ **Política existente**
+ **Selecionar uma política do IAM**: permite que você escolha uma política de sessão existente. Escolha **Exibir** para ver um objeto JSON contendo os detalhes da política.
Para saber mais sobre as políticas de sessão, consulte [Criar uma política e um perfil do IAM](requirements-roles.md). Para saber mais sobre como criar uma política de sessão, consulte [Criar uma política de sessão de um bucket do Amazon S3](users-policies-session.md).
1. Para o **diretório inicial**, escolha o bucket do Amazon S3 para armazenar os dados a serem transferidos usando. AWS Transfer Family Insira o caminho no diretório `home` que o usuário acessa quando faz login usando seu cliente.
Se você deixar esse parâmetro em branco, o diretório `root` do seu bucket do Amazon S3 será usado. Nesse caso, certifique-se de que seu perfil do IAM fornece acesso a esse `root` diretório.
**nota**
Recomendamos que você escolha um caminho de diretório que contenha o nome do usuário, o que permite que você efetivamente use uma política de sessão. A política de sessão limita o acesso do usuário no bucket do Amazon S3 para o diretório `home` do usuário.
1. (Opcional) Em **Restrito**, marque a caixa de seleção para que seus usuários não possam acessar nada fora dessa pasta e não possam ver o bucket ou o nome da pasta do Amazon S3.
**nota**
Ao designar ao usuário um diretório inicial e restringir o usuário a esse diretório inicial, isso deve ser suficiente para bloquear o acesso do usuário à pasta designada. Se você precisar aplicar mais controles, use uma política de sessão.
1. Escolha **Salvar** para salvar as alterações.
**Para excluir um usuário**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Selecione **Servidores** no painel de navegação para exibir a página **Servidores**.
1. Escolha o identificador na coluna **ID do servidor** para ver a página **Configuração do servidor**.
1. Em **Usuários**, escolha um nome de usuário para ver a página de **Detalhes do usuário**.
1. Na página **Detalhes do usuário**, escolha **Excluir** à direita do nome de usuário.
1. Na caixa de diálogo de confirmação exibida, insira a palavra **delete** e escolha **Excluir** para confirmar que deseja excluir o usuário.
O usuário é excluído e removido da lista de **usuários** .
**Para adicionar uma chave pública SSH para um usuário**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. No painel de navegação, selecione **Servidores**.
1. Escolha o identificador na coluna **ID do servidor** para ver a página **Configuração do servidor**.
1. Em **Usuários**, escolha um nome de usuário para ver a página de **Detalhes do usuário**.
1. Escolha **Add SSH public key (Adicionar chave pública SSH)** para adicionar uma nova chave pública SSH a um usuário.
**nota**
As chaves SSH são usadas somente por servidores habilitados para File Transfer Protocol (SFTP) da Secure Shell (SSH). Para obter informações sobre como gerar um par de chaves SSH, consulte [Gere chaves SSH para usuários gerenciados por serviços](sshkeygen.md).
1. Em **chave pública SSH**, insira a parte da chave pública SSH do par de chaves SSH.
Sua chave é validada pelo serviço antes que você possa adicionar o novo usuário. O formato da chave SSH é `ssh-rsa string`. Para gerar um par de chaves SSH, consulte [Gere chaves SSH para usuários gerenciados por serviços](sshkeygen.md).
1. Escolha **Adicionar chave**.
**Para excluir uma chave pública SSH para um usuário**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. No painel de navegação, selecione **Servidores**.
1. Escolha o identificador na coluna **ID do servidor** para ver a página **Configuração do servidor**.
1. Em **Usuários**, escolha um nome de usuário para ver a página de **Detalhes do usuário**.
1. Para excluir uma chave pública, marque a caixa de seleção da chave SSH e escolha **Excluir**.
# Trabalhar com provedores de identidade personalizados
AWS Transfer Family oferece várias opções para provedores de identidade personalizados autenticarem e autorizarem usuários para transferências seguras de arquivos. Aqui estão as principais abordagens:
+ [Solução personalizada de provedor de identidade](custom-idp-toolkit.md)—Este tópico descreve a solução de provedor de identidade personalizada da Transfer Family, usando um kit de ferramentas hospedado em. GitHub
**nota**
Para a maioria dos casos de uso, essa é a opção recomendada. Especificamente, se você precisar oferecer suporte a mais de 100 grupos do Active Directory, a solução personalizada do provedor de identidade oferece uma alternativa escalável sem limitações de grupo. Essa solução é descrita na postagem do blog [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
+ [Usando para integrar seu provedor de identidade](authentication-api-gateway.md)—Este tópico descreve como usar uma AWS Lambda função para apoiar um método do Amazon API Gateway.
Você pode fornecer uma RESTful interface com um único método do Amazon API Gateway. O Transfer Family chama esse método para se conectar ao seu provedor de identidade, que autentica e autoriza seus usuários a acessar o Amazon S3 ou o Amazon EFS. Use essa opção se precisar de uma RESTful API para integrar seu provedor de identidade ou se quiser usá-la para aproveitar seus recursos AWS WAF para solicitações de bloqueio geográfico ou limitação de taxa. Para obter detalhes, consulte [Usando para integrar seu provedor de identidade](authentication-api-gateway.md).
+ [Abordagens dinâmicas de gerenciamento de permissões](dynamic-permission-management.md)—Este tópico descreve abordagens para gerenciar dinamicamente as permissões do usuário usando políticas de sessão.
Para autenticar seus usuários, é possível usar seu provedor de identidade existente com AWS Transfer Family. Você integra seu provedor de identidade usando uma função AWS Lambda ,que autentica e autoriza seus usuários a acessarem o Amazon S3 ou o Amazon Elastic File System (Amazon EFS). Para obter detalhes, consulte [Usando AWS Lambda para integrar seu provedor de identidade](custom-lambda-idp.md). Você também pode acessar CloudWatch gráficos de métricas como o número de arquivos e bytes transferidos no AWS Transfer Family Management Console, oferecendo um único painel para monitorar as transferências de arquivos usando um painel centralizado.
+ O Transfer Family fornece uma postagem no blog e um workshop que orientam você na criação de uma solução de transferência de arquivos. Essa solução usa AWS Transfer Family SFTP/FTPS endpoints gerenciados e Amazon Cognito e DynamoDB para gerenciamento de usuários.
A postagem do blog está disponível em [Usando o Amazon Cognito como provedor de identidade com AWS Transfer Family o Amazon S3](https://aws.amazon.com/blogs/storage/using-amazon-cognito-as-an-identity-provider-with-aws-transfer-family-and-amazon-s3/). Você pode ver os detalhes do workshop [aqui](https://catalog.workshops.aws/transfer-family-sftp/en-US).
**nota**
Para provedores de identidade personalizados, o nome de usuário deve ter no mínimo 3 e no máximo 100 caracteres. Você pode usar os seguintes caracteres no nome de usuário: a—z, A-Z, 0—9, sublinhado '\$1', hífen '-', ponto '.' e sinal de arroba '@'. O nome de usuário não pode começar com um hífen '-', ponto '.' ou com o sinal '@'.
Ao implementar um provedor de identidade personalizado, considere as seguintes práticas recomendadas:
+ Implante a solução na mesma Conta da AWS região dos seus servidores Transfer Family.
+ Implemente o princípio do menor privilégio ao configurar as funções e políticas do IAM.
+ Use recursos como lista de permissões de IP e registro padronizado para aumentar a segurança.
+ Teste minuciosamente seu provedor de identidade personalizado em um ambiente que não seja de produção antes da implantação.
**Topics**
+ [Solução personalizada de provedor de identidade](custom-idp-toolkit.md)
+ [Usando AWS Lambda para integrar seu provedor de identidade](custom-lambda-idp.md)
+ [Usando para integrar seu provedor de identidade](authentication-api-gateway.md)
+ [Usando vários métodos de autenticação](custom-idp-mfa.md)
+ [IPv6 suporte para provedores de identidade personalizados](custom-idp-ipv6.md)
# Solução personalizada de provedor de identidade
A solução de provedor de identidade AWS Transfer Family personalizada é uma solução modular de provedor de identidade personalizada que resolve muitos casos de uso comuns de autenticação e autorização que as empresas têm ao implementar o serviço. Essa solução fornece uma base reutilizável para a implementação de provedores de identidade personalizados com configuração granular por sessão por usuário e separa a lógica de autenticação e autorização, oferecendo uma easy-to-maintain base flexível para vários casos de uso.
Com a solução AWS Transfer Family personalizada de provedor de identidade, você pode abordar casos de uso comuns de autenticação e autorização corporativa. Essa solução modular oferece:
+ Uma base reutilizável para implementar provedores de identidade personalizados
+ Configuração granular de sessão por usuário
+ Lógica separada de autenticação e autorização
## Detalhes de implementação do kit de ferramentas de identidade personalizado
A solução fornece uma base flexível e sustentável para vários casos de uso. Para começar, revise o kit de ferramentas em [https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family) e siga as instruções de implantação na seção [Introdução](https://github.com/aws-samples/toolkit-for-aws-transfer-family/tree/main/solutions/custom-idp#getting-started).
![\[Diagrama de arquitetura para o kit de ferramentas do provedor de identidade personalizado disponível em GitHub.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/custom-idp-solution-high-level-architecture.png)
**nota**
Se você já usou modelos e exemplos de provedores de identidade personalizados, considere adotar essa solução. No futuro, os módulos específicos do fornecedor padronizarão essa solução. A manutenção contínua e os aprimoramentos de recursos serão aplicados a essa solução.
Essa solução contém padrões padrão para implementar um provedor personalizado que considera os detalhes, incluindo o registro e onde armazenar os metadados adicionais da sessão necessários AWS Transfer Family, como o `HomeDirectoryDetails` parâmetro. Essa solução fornece uma base reutilizável para a implementação de provedores de identidade personalizados com configuração granular por sessão por usuário e separa a lógica de autenticação do provedor de identidade da lógica reutilizável que cria uma configuração que é retornada à Transfer Family para concluir a autenticação e estabelecer configurações para a sessão.
O código e os recursos de suporte para essa solução estão disponíveis em [https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family).
O kit de ferramentas contém os seguintes recursos:
+ Um [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam)modelo que provisiona os recursos necessários. Opcionalmente, implante e configure o Amazon API Gateway para incorporar AWS WAF, conforme descrito na postagem do blog [Protegendo AWS Transfer Family com o AWS Web Application Firewall e o Amazon API](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/) Gateway.
+ Um esquema do [Amazon DynamoDB](https://aws.amazon.com/dynamodb) para armazenar metadados de configuração sobre provedores de identidade, incluindo configurações de sessão do usuário, como, e. `HomeDirectoryDetails` `Role` `Policy`
+ Uma abordagem modular que permite adicionar novos provedores de identidade à solução no futuro, como módulos.
+ Recuperação de atributos: opcionalmente, recupere a função do IAM e os atributos do perfil POSIX (UID e GID) de provedores de identidade compatíveis, incluindo AD, LDAP e Okta.
+ Suporte para vários provedores de identidade conectados a um único servidor Transfer Family e vários servidores Transfer Family usando a mesma implantação da solução.
+ Verificação integrada da lista de permissões de IP, como listas de permissões de IP que podem ser configuradas opcionalmente por usuário ou por provedor de identidade.
+ Registro detalhado com nível de registro configurável e suporte de rastreamento para auxiliar na solução de problemas.
Antes de começar a implantar a solução de provedor de identidade personalizada, você precisa ter os seguintes AWS recursos.
+ Uma Amazon Virtual Private Cloud (VPC) com sub-redes privadas, com conectividade com a Internet por meio de um gateway NAT ou de um endpoint de gateway do DynamoDB.
+ Permissões apropriadas do IAM para realizar as seguintes tarefas:
+ Implante o `custom-idp.yaml` CloudFormation modelo,
+ Crie AWS CodePipeline projetos
+ Crie AWS CodeBuild projetos
+ Crie funções e políticas do IAM
**Importante**
Você deve implantar a solução na mesma Conta da AWS e Região da AWS que contenha seus servidores Transfer Family de destino.
## Provedores de identidade compatíveis
A lista a seguir contém detalhes dos provedores de identidade compatíveis com a solução de provedor de identidade personalizada.
| Fornecedor | Fluxos de senhas | Fluxos de chave pública | Multifatorial | Recuperação de atributos | Detalhes |
| --- | --- | --- | --- | --- | --- |
| Active Directory e LDAP | Sim | Sim | Não | Sim | A verificação do usuário pode ser realizada como parte do fluxo de autenticação de chave pública. |
| Argon2 (hash local) | Sim | Não | Não | Não | Os hashes Argon2 são armazenados no registro do usuário para casos de uso de autenticação “local” baseada em senha. |
| Amazon Cognito | Sim | Não | Sim\$1 | Não | Somente autenticação multifatorial baseada em senha de uso único (TOTP) baseada em tempo. \$1O MFA baseado em SMS não é suportado. |
| Insira o ID (antigo Azure AD) | Sim | Não | Não | Não | |
| Okta | Sim | Sim | Yes (Sim) | Sim | Somente MFA baseado em TOTP. |
| Chave pública | Não | Sim | Não | Não | As chaves públicas são armazenadas no registro do usuário no DynamoDB. |
| Secrets Manager | Sim | Sim | Não | Não | |
# Usando AWS Lambda para integrar seu provedor de identidade
Este tópico descreve como criar uma AWS Lambda função que se conecta ao seu provedor de identidade personalizado. Você pode usar qualquer provedor de identidade personalizado, como Okta, Secrets Manager ou um armazenamento de dados personalizado que inclua lógica de autorização e autenticação. OneLogin
Para a maioria dos casos de uso, a forma recomendada de configurar um provedor de identidade personalizado é usar [Solução personalizada de provedor de identidade](custom-idp-toolkit.md) o.
**nota**
Antes de criar um servidor Transfer Family que usa o Lambda como provedor de identidade, você deve criar a função. Para obter um exemplo de função do Lambda, consulte [Exemplo de funções do Lambda](#lambda-auth-examples). Ou você pode implantar uma CloudFormation pilha que usa um dos[Modelos de função do Lambda](#lambda-idp-templates). Além disso, certifique-se de que sua função do Lambda use uma política baseada em recursos que confie no Transfer Family. Para visualizar um exemplo de política, consulte [Exemplo de política baseada em recursos do Lambda](#lambda-resource-policy).
1. Abra o [console do AWS Transfer Family](https://console.aws.amazon.com/transfer/).
1. Escolha **Criar servidor** para abrir a página **Criar servidor**. Em **Escolher um provedor de identidade**, escolha **Provedor de identidade personalizado**, conforme mostrado na captura de tela a seguir.
![\[A seção do console Escolher um provedor de identidade com Provedor de identidade personalizada selecionado. Também tem o valor padrão selecionado, que é que os usuários podem se autenticar usando sua senha ou chave.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/custom-lambda-console.png)
**nota**
A escolha dos métodos de autenticação só estará disponível se você habilitar o SFTP como um dos protocolos do seu servidor Transfer Family.
1. Certifique-se de que o valor padrão, **Usar AWS Lambda para conectar seu provedor de identidade**, esteja selecionado.
1. Para a **AWS Lambda Função**, insira o nome da sua função do Lambda.
1. Preencha as caixas restantes e escolha **Criar servidor**. Para obter detalhes sobre as etapas restantes para criar um servidor, consulte [Configurando um endpoint de servidor SFTP, FTPS ou FTP](tf-server-endpoint.md).
## Exemplo de política baseada em recursos do Lambda
Você deve ter uma política que faça referência ao servidor Transfer Family e ao ARNs Lambda. Por exemplo, é possível usar a política a seguir com sua função do Lambda que se conecta ao seu provedor de identidade. A política tem um JSON de escape como uma string.
****
```
"Policy":
"{\"Version\":\"2012-10-17\",
\"Id\":\"default\",
\"Statement\":[
{\"Sid\":\"AllowTransferInvocation\",
\"Effect\":\"Allow\",
\"Principal\":{\"Service\":\"transfer.amazonaws.com\"},
\"Action\":\"lambda:InvokeFunction\",
\"Resource\":\"arn:aws:lambda:region:123456789012:function:my-lambda-auth-function\",
\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:transfer:region:123456789012:server/server-id\"}}}
]}"
```
**nota**
No exemplo de política acima, substitua cada uma *user input placeholder* por suas próprias informações.
## Estrutura de mensagens de evento
A estrutura da mensagem de evento do servidor SFTP enviada para a função do Lambda do autorizador para um IDP personalizado é a seguinte.
```
{
"username": "value",
"password": "value",
"protocol": "SFTP",
"serverId": "s-abcd123456",
"sourceIp": "192.168.0.100"
}
```
Onde `username` e `password` são os valores das credenciais de login enviadas ao servidor.
Por exemplo, insira o seguinte comando para se conectar:
```
sftp bobusa@server_hostname
```
A senha será solicitada:
```
Enter password:
mysecretpassword
```
É possível verificar isso na sua função do Lambda imprimindo o evento passado de dentro da função do Lambda. A aparência deve ser semelhante ao exemplo a seguir.
```
{
"username": "bobusa",
"password": "mysecretpassword",
"protocol": "SFTP",
"serverId": "s-abcd123456",
"sourceIp": "192.168.0.100"
}
```
A estrutura do evento é semelhante para FTP e FTPS: a única diferença é que esses valores são usados para o parâmetro `protocol`, em vez de SFTP.
## Funções do Lambda para autenticação
Para implementar diferentes estratégias de autenticação, edite a função do Lambda. Para ajudá-lo a atender às necessidades do seu aplicativo, você pode implantar uma CloudFormation pilha. Para obter mais informações sobre o Lambda, consulte [Guia do desenvolvedor do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ou [Como criar funções do Lambda com Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html).
**Topics**
+ [Valores do Lambda válidos](#lambda-valid-values)
+ [Exemplo de funções do Lambda](#lambda-auth-examples)
+ [Testar a configuração](#authentication-test-configuration)
+ [Modelos de função do Lambda](#lambda-idp-templates)
### Valores do Lambda válidos
A tabela a seguir descreve os detalhes dos valores que o Transfer Family aceita para funções Lambda que são usadas para provedores de identidade personalizados.
| Valor | Description | Obrigatório |
| --- | --- | --- |
| `Role` | Especifica o nome do recurso da Amazon (ARN) do perfil do IAM que controla o acesso dos seus usuários ao bucket do Amazon S3 ou ao sistema de arquivos do Amazon EFS. As políticas anexadas a essa função determinam o nível de acesso que você deseja fornecer aos usuários durante a transferência de arquivos para dentro e para fora de seu sistema de arquivos do Amazon S3 ou Amazon EFS. O perfil do IAM também deve conter uma relação de confiança que permite o servidor acesse os recursos quando estiver servindo as solicitações de transferência dos usuários. Para obter informações sobre como estabelecer um relacionamento de confiança, consulte [Estabelecer um relacionamento de confiança](requirements-roles.md#establish-trust-transfer). | Obrigatório |
| `PosixProfile` | A identidade POSIX completa, incluindo ID de usuário (`Uid`), ID de grupo (`Gid`) e qualquer grupo secundário IDs (`SecondaryGids`), que controla o acesso dos usuários aos sistemas de arquivos do Amazon EFS. As permissões POSIX definidas em arquivos e diretórios em seu sistema de arquivos determinam o nível de acesso que os usuários obtêm ao transferir arquivos para dentro e para fora de seus sistemas de arquivos do Amazon EFS. | Necessário para armazenamento secundário do Amazon EFS |
| `PublicKeys` | Uma lista de valores de chave pública SSH que são válidos para esse usuário. Uma lista vazia indica que esse não é um login válido. Não deve ser devolvido durante a autenticação por senha. | Opcional |
| `Policy` | Uma política de sessão para seu usuário, para que você possa usar o mesmo perfil do IAM do entre vários usuários. Esta política delimita o acesso do usuário a partes do bucket do Amazon S3. Para obter mais informações sobre o uso de políticas de sessão com provedores de identidade personalizados, consulte os exemplos de políticas de sessão neste tópico. | Opcional |
| `HomeDirectoryType` | O tipo de diretório (pasta) inicial que você deseja que o diretório inicial dos usuários seja quando eles fizerem login no servidor. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/custom-lambda-idp.html) | Opcional |
| `HomeDirectoryDetails` | Mapeamentos de diretórios lógicos que especificam quais caminhos e chaves do Amazon S3 devem estar visíveis para o usuário e como você deseja torná-los visíveis. Você precisa especificar o par `Entry` e `Target`, onde `Entry` mostra como o caminho se tornou visível e `Target` é o caminho real do Amazon S3 ou Amazon EFS. | Obrigatório se `HomeDirectoryType` tiver um valor de `LOGICAL` |
| `HomeDirectory` | O diretório inicial de um usuário quando ele faz login no servidor usando o cliente. O formato depende do seu back-end de armazenamento: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/custom-lambda-idp.html) O nome do bucket ou o ID do sistema de arquivos do Amazon EFS devem ser incluídos no caminho. A omissão dessas informações resultará em erros de “Arquivo não encontrado” durante as transferências de arquivos. | Opcional |
**nota**
`HomeDirectoryDetails` O é uma representação em string de um mapa JSON. Isso contrasta com `PosixProfile`, que é um objeto de mapa JSON real e `PublicKeys` que é uma matriz JSON de strings. Veja os exemplos de código para obter detalhes específicos do idioma.
**HomeDirectory Requisitos de formato**
Ao usar o `HomeDirectory` parâmetro, certifique-se de incluir o formato completo do caminho:
**Para armazenamento no Amazon S3:** sempre inclua o nome do bucket no formato `/bucket-name/path`
**Para armazenamento no Amazon EFS:** sempre inclua o ID do sistema de arquivos no formato `/fs-12345/path`
Uma causa comum dos erros de “Arquivo não encontrado” é omitir o nome do bucket ou o ID do sistema de arquivos EFS do `HomeDirectory` caminho. `HomeDirectory`Definir como apenas `/` sem o identificador de armazenamento fará com que a autenticação seja bem-sucedida, mas as operações de arquivo falhem.
### Exemplo de funções do Lambda
Esta seção apresenta alguns exemplos de funções do Lambda, tanto em NodeJS quanto em Python.
**nota**
Nesses exemplos, o usuário, a função, o perfil POSIX, a senha e os detalhes do diretório inicial são todos exemplos e devem ser substituídos pelos valores reais.
------
#### [ Logical home directory, NodeJS ]
A função de exemplo do NodeJS a seguir fornece os detalhes de um usuário que tem um [diretório inicial lógico](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html).
```
// GetUserConfig Lambda
exports.handler = (event, context, callback) => {
console.log("Username:", event.username, "ServerId: ", event.serverId);
var response;
// Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
if (event.serverId !== "" && event.username == 'example-user') {
var homeDirectoryDetails = [
{
Entry: "/",
Target: "/fs-faa1a123"
}
];
response = {
Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank
PosixProfile: {"Gid": 65534, "Uid": 65534}, // Required for EFS access, but not needed for S3
HomeDirectoryDetails: JSON.stringify(homeDirectoryDetails),
HomeDirectoryType: "LOGICAL",
};
// Check if password is provided
if (!event.password) {
// If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ];
// Check if password is correct
} else if (event.password !== 'Password1234') {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
} else {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
callback(null, response);
};
```
------
#### [ Path-based home directory, NodeJS ]
A função de exemplo do NodeJS a seguir fornece os detalhes de um usuário que tem um diretório inicial baseado no caminho.
```
// GetUserConfig Lambda
exports.handler = (event, context, callback) => {
console.log("Username:", event.username, "ServerId: ", event.serverId);
var response;
// Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
// There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins.
if (event.serverId !== "" && event.username == 'example-user') {
response = {
Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank
Policy: '', // Optional, JSON stringified blob to further restrict this user's permissions
// HomeDirectory format depends on your storage backend:
// For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john')
// For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john')
HomeDirectory: '/my-transfer-bucket/users/example-user' // S3 example - replace with your bucket name
// HomeDirectory: '/fs-faa1a123/users/example-user' // EFS example - uncomment for EFS
};
// Check if password is provided
if (!event.password) {
// If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ];
// Check if password is correct
} else if (event.password !== 'Password1234') {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
} else {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
callback(null, response);
};
```
------
#### [ Logical home directory, Python ]
A função de exemplo do Python a seguir fornece os detalhes de um usuário que tem um [diretório inicial lógico](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html).
```
# GetUserConfig Python Lambda with LOGICAL HomeDirectoryDetails
import json
def lambda_handler(event, context):
print("Username: {}, ServerId: {}".format(event['username'], event['serverId']))
response = {}
# Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
if event['serverId'] != '' and event['username'] == 'example-user':
homeDirectoryDetails = [
{
'Entry': '/',
'Target': '/fs-faa1a123'
}
]
response = {
'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank
'PosixProfile': {"Gid": 65534, "Uid": 65534}, # Required for EFS access, but not needed for S3
'HomeDirectoryDetails': json.dumps(homeDirectoryDetails),
'HomeDirectoryType': "LOGICAL"
}
# Check if password is provided
if event.get('password', '') == '':
# If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]
# Check if password is correct
elif event['password'] != 'Password1234':
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
else:
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
return response
```
------
#### [ Path-based home directory, Python ]
A função de exemplo do Python a seguir fornece os detalhes de um usuário que tem um diretório inicial baseado no caminho.
```
# GetUserConfig Python Lambda with PATH HomeDirectory
def lambda_handler(event, context):
print("Username: {}, ServerId: {}".format(event['username'], event['serverId']))
response = {}
# Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
# There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins.
if event['serverId'] != '' and event['username'] == 'example-user':
response = {
'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank
'Policy': '', # Optional, JSON stringified blob to further restrict this user's permissions
# HomeDirectory format depends on your storage backend:
# For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john')
# For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john')
'HomeDirectory': '/my-transfer-bucket/users/example-user', # S3 example - replace with your bucket name
# 'HomeDirectory': '/fs-faa1a123/users/example-user', # EFS example - uncomment for EFS
'HomeDirectoryType': "PATH" # Not strictly required, defaults to PATH
}
# Check if password is provided
if event.get('password', '') == '':
# If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]
# Check if password is correct
elif event['password'] != 'Password1234':
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
else:
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
return response
```
------
### Testar a configuração
Depois de criar seu provedor de identidade personalizado, você deve testar sua configuração.
------
#### [ Console ]
**Para testar sua configuração usando o AWS Transfer Family console**
1. Abra o [console do AWS Transfer Family](https://console.aws.amazon.com/transfer/).
1. Na página **Servidores**, escolha seu novo servidor, escolha **Ações** e escolha **Testar**.
1. Insira o texto para **Nome de usuário** e **Senha** que você definiu ao implantar a CloudFormation pilha. Se você manteve as opções padrão, o nome de usuário é `myuser` e a senha é `MySuperSecretPassword`.
1. Escolha o **protocolo do servidor** e insira o endereço IP para o **IP de origem**, se você os definiu ao implantar a CloudFormation pilha.
------
#### [ CLI ]
**Para testar sua configuração usando a AWS CLI**
1. Execute o comando [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html). Substitua cada `user input placeholder` por suas próprias informações, conforme descrito nas etapas subsequentes.
```
aws transfer test-identity-provider --server-id s-1234abcd5678efgh --user-name myuser --user-password MySuperSecretPassword --server-protocol FTP --source-ip 127.0.0.1
```
1. Insira o ID do servidor.
1. Insira o nome de usuário e a senha que você definiu ao implantar a CloudFormation pilha. Se você manteve as opções padrão, o nome de usuário é `myuser` e a senha é `MySuperSecretPassword`.
1. Insira o protocolo do servidor e o endereço IP de origem, se você os tiver definido ao implantar a CloudFormation pilha.
------
Se a autenticação do usuário for bem-sucedida, o teste retornará uma resposta de HTTP `StatusCode: 200`, uma string vazia `Message: ""` (que, caso contrário, conteria um motivo para a falha) e um campo `Response`.
**nota**
No exemplo de resposta abaixo, o campo `Response` é um objeto JSON que foi “stringificado” (convertido em uma string JSON simples que pode ser usada dentro de um programa) e contém os detalhes das funções e permissões do usuário.
```
{
"Response":"{\"Policy\":\"{\\\"Version\\\":\\\"2012-10-17\\\",\\\"Statement\\\":[{\\\"Sid\\\":\\\"ReadAndListAllBuckets\\\",\\\"Effect\\\":\\\"Allow\\\",\\\"Action\\\":[\\\"s3:ListAllMybuckets\\\",\\\"s3:GetBucketLocation\\\",\\\"s3:ListBucket\\\",\\\"s3:GetObjectVersion\\\",\\\"s3:GetObjectVersion\\\"],\\\"Resource\\\":\\\"*\\\"}]}\",\"Role\":\"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\":\"/\"}",
"StatusCode": 200,
"Message": ""
}
```
### Modelos de função do Lambda
Você pode implantar uma CloudFormation pilha que usa uma função Lambda para autenticação. Fornecemos vários modelos que autenticam e autorizam seus usuários usando credenciais de login. Você pode modificar esses modelos ou AWS Lambda códigos para personalizar ainda mais o acesso do usuário.
**nota**
Você pode criar um AWS Transfer Family servidor habilitado para FIPS CloudFormation especificando uma política de segurança habilitada para FIPS em seu modelo. As políticas de segurança disponíveis estão descritas em [Políticas de segurança para AWS Transfer Family servidores](security-policies.md)
**Para criar uma CloudFormation pilha para usar na autenticação**
1. Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. *Siga as instruções para implantar uma CloudFormation pilha a partir de um modelo existente em [Seleção de um modelo de pilha no Guia](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) do AWS CloudFormation usuário.*
1. Use um dos modelos a seguir para criar uma função do Lambda para usar na autenticação no Transfer Family.
+ [Modelo de pilha clássico (Amazon Cognito)](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml)
Um modelo básico para criar um AWS Lambda para uso como provedor de identidade personalizado em AWS Transfer Family. Ele se autentica no Amazon Cognito para autenticação baseada em senha, e as chaves públicas são retornadas de um bucket do Amazon S3 se a autenticação baseada em chave pública for usada. Após a implantação, é possível modificar o código da função do Lambda para fazer algo diferente.
+ [AWS Secrets Manager modelo de pilha](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml)
Um modelo básico usado AWS Lambda com um AWS Transfer Family servidor para integrar o Secrets Manager como um provedor de identidade. Ele se autentica com base em uma entrada AWS Secrets Manager do formato`aws/transfer/server-id/username`. Além disso, o segredo deve conter os pares de valores-chave de todas as propriedades do usuário retornadas ao Transfer Family. Após a implantação, é possível modificar o código da função do Lambda para fazer algo diferente.
+ [Modelo de pilha Okta](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml): um modelo básico usado AWS Lambda com um AWS Transfer Family servidor para integrar o Okta como um provedor de identidade personalizado.
+ Modelo de [pilha Okta-MFA: um modelo](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml) básico usado AWS Lambda com um AWS Transfer Family servidor para integrar o Okta, com a autenticação multifator, como um provedor de identidade personalizado.
+ [Modelo do Azure Active Directory](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml): os detalhes dessa pilha estão descritos na postagem do blog [Autenticando AWS Transfer Family com o Azure Active Directory e. AWS Lambda](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/)
Depois que a pilha for implantada, você poderá ver detalhes sobre ela na guia **Saídas** no console. CloudFormation
A implantação de uma dessas pilhas é a maneira mais fácil de integrar um provedor de identidade personalizado ao fluxo de trabalho do Transfer Family.
# Usando para integrar seu provedor de identidade
Este tópico descreve como usar uma AWS Lambda função para apoiar um método do API Gateway. Use essa opção se precisar de uma RESTful API para integrar seu provedor de identidade ou se quiser usá-la para aproveitar seus recursos AWS WAF para solicitações de bloqueio geográfico ou limitação de taxa.
Para a maioria dos casos de uso, a forma recomendada de configurar um provedor de identidade personalizado é usar [Solução personalizada de provedor de identidade](custom-idp-toolkit.md) o.
**Limitações ao usar um API Gateway para integrar seu provedor de identidade**
+ Essa configuração não aceita domínios personalizados.
+ Essa configuração não é compatível com um URL privado do API Gateway.
Se precisar de um desses, é possível usar o Lambda como provedor de identidade, sem o API Gateway. Para obter detalhes, consulte [Usando AWS Lambda para integrar seu provedor de identidade](custom-lambda-idp.md).
## Autenticação usando um método do API Gateway
É possível criar um método API Gateway para ser usado como provedor de identidade para o Transfer Family. Essa abordagem fornece uma maneira altamente segura de criar e fornecer APIs. Com o API Gateway, você pode criar um endpoint HTTPS para que todas as operações de entrada da API sejam transmitidas com maior segurança. Para obter mais detalhes sobre o serviço do API Gateway, consulte o [Guia do desenvolvedor do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html).
O API Gateway oferece um método de autorização chamado`AWS_IAM`, que fornece a mesma autenticação baseada em AWS Identity and Access Management (IAM) AWS usada internamente. Se você ativar a autenticação com `AWS_IAM`, somente chamadores com permissões explícitas para chamar uma API poderão acessar o método API Gateway dessa API.
Para usar o método do API Gateway como provedor de identidade personalizado para o Transfer Family, ative o IAM para o método do API Gateway. Como parte desse processo, você fornece um perfil do IAM com permissões para o Transfer Family usar seu gateway.
**nota**
Para melhorar a segurança, é possível configurar um firewall para aplicações Web. O AWS WAF é um firewall para aplicações Web que permite monitorar as solicitações HTTP e HTTPS que são encaminhadas ao Amazon API Gateway. Para obter detalhes, consulte [Adicione um firewall da aplicação web](web-application-firewall.md).
**Não habilite o armazenamento em cache do API Gateway**
Não habilite o armazenamento em cache para seu método API Gateway ao usá-lo como um provedor de identidade personalizado para Transfer Family. O armazenamento em cache é impróprio e inválido para solicitações de autenticação porque:
Cada solicitação de autenticação é exclusiva e requer uma resposta ativa, não uma resposta em cache
O armazenamento em cache não oferece benefícios, pois o Transfer Family nunca envia solicitações duplicadas ou repetidas para o API Gateway.
A ativação do armazenamento em cache fará com que o API Gateway responda com dados incompatíveis, resultando em respostas inválidas às solicitações de autenticação
**Para usar seu método API Gateway para autenticação personalizada com o Transfer Family**
1. Crie uma CloudFormation pilha. Para fazer isso:
**nota**
Os modelos de pilha foram atualizados para usar senhas BASE64 codificadas: para obter detalhes, consulte. [Melhorias nos CloudFormation modelos](#base64-templates)
1. Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. *Siga as instruções para implantar uma CloudFormation pilha a partir de um modelo existente em [Seleção de um modelo de pilha no Guia](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) do AWS CloudFormation usuário.*
1. Use um dos modelos básicos a seguir para criar um método API Gateway suportado por AWS Lambda para uso como provedor de identidade personalizado no Transfer Family.
+ [Modelo básico de pilha](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-apig.template.yml)
Por padrão, seu método API Gateway é usado como um provedor de identidade personalizado para autenticar um único usuário em um único servidor usando uma chave ou senha SSH (Secure Shell) codificada. Após a implantação, é possível modificar o código da função do Lambda para fazer algo diferente.
+ [AWS Secrets Manager modelo de pilha](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml)
Por padrão, seu método API Gateway é autenticado em uma entrada no Secrets Manager do formato `aws/transfer/server-id/username`. Além disso, o segredo deve conter os pares de valores-chave de todas as propriedades do usuário retornadas ao Transfer Family. Após a implantação, é possível modificar o código da função do Lambda para fazer algo diferente. Para obter mais informações, consulte a postagem do blog [Habilitar a autenticação por senha para AWS Transfer Family uso AWS Secrets Manager](https://aws.amazon.com/blogs/storage/enable-password-authentication-for-aws-transfer-family-using-aws-secrets-manager-updated/).
+ [Modelo de pilha Okta](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-apig.template.yml)
Seu método API Gateway se integra ao Okta como um provedor de identidade personalizado no Transfer Family. Para obter mais informações, consulte a postagem de blog [Usar o Okta como provedor de identidade com AWS Transfer Family](https://aws.amazon.com/blogs/storage/using-okta-as-an-identity-provider-with-aws-transfer-for-sftp/).
A implantação de uma dessas pilhas é a maneira mais fácil de integrar um provedor de identidade personalizado ao fluxo de trabalho do Transfer Family. Cada pilha usa a função do Lambda para oferecer suporte ao seu método de API com base no API Gateway. Em seguida, é possível usar seu método de API como um provedor de identidade personalizado no Transfer Family. Por padrão, a função do Lambda autentica um único usuário chamado `myuser` com uma senha de `MySuperSecretPassword`. Após a implantação, é possível editar essas credenciais ou atualizar o código da função do Lambda para fazer algo diferente.
**Importante**
Recomendamos que você edite as credenciais padrão de usuário e senha.
Depois que a pilha for implantada, você poderá ver detalhes sobre ela na guia **Saídas** no console. CloudFormation Esses detalhes incluem o nome do recurso da Amazon (ARN) da pilha, o ARN do perfil do IAM que a pilha criou e o URL do seu novo gateway.
**nota**
Se você estiver usando a opção de provedor de identidade personalizado para habilitar a autenticação baseada em senha para seus usuários e ativar o registro de solicitações e respostas fornecido pelo API Gateway, o API Gateway registrará as senhas dos seus usuários no Amazon Logs. CloudWatch Não recomendamos usar esse log em seu ambiente de produção. Para obter mais informações, consulte [Configurar o registro de CloudWatch API no API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html) no *Guia do desenvolvedor do API Gateway*.
1. Verifique a configuração do método API Gateway para seu servidor. Para fazer isso:
1. Abra o console do API Gateway em [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/).
1. Escolha a **API de modelo básico do Transfer Custom Identity Provider** que o CloudFormation modelo gerou. Talvez seja necessário selecionar sua região para ver seus gateways.
1. No painel **Recursos**, escolha **OBTER**. A captura de tela a seguir mostra a configuração correta do método.
![\[Detalhes da configuração da API, mostrando os parâmetros de configuração do método para os caminhos de solicitação e para a string de consulta de URL.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/apig-config-method-fields.png)
Neste ponto, seu API gateway está pronto para ser implantado.
1. Escolha **Ações** e **Implantar API**. Para o **Estágio de implantação**, escolha **prod** e **Implantar**.
Depois que o método API Gateway for implantado com sucesso, veja seu desempenho em **Estágios** > **Detalhes do estágio**, conforme mostrado na captura de tela a seguir.
**nota**
Copie o endereço do **URL de invocação** que aparece na parte superior da tela. Talvez você precise dele para a próxima etapa.
![\[Detalhes do estágio com o URL Invoke destacado.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/apig-config-method-invoke.png)
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Uma Transfer Family deveria ter sido criada para você quando você criou a pilha. Caso contrário, configure seu servidor usando essas etapas.
1. Escolha **Criar servidor** para abrir a página **Criar servidor**. Em **Escolher um provedor de identidade**, escolha **Personalizado** e, em seguida, selecione **Usar Amazon API Gateway para se conectar ao seu provedor de identidade**, conforme mostrado na captura de tela a seguir.
![\[A tela do provedor de identidade com o provedor de identidade personalizado selecionado e com o API Gateway escolhido para se conectar ao seu provedor de identidade.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/create-server-choose-idp-custom.png)
1. Na caixa de texto **Fornecer um URL do Amazon API Gateway**, cole o endereço do **URL de invocação** do endpoint do API Gateway que você criou na etapa 3 deste procedimento.
1. Em **Role**, escolha a função do IAM que foi criada pelo CloudFormation modelo. Essa função permite que o Transfer Family invoque seu método de gateway de API.
A função de invocação contém o nome da CloudFormation pilha que você selecionou para a pilha que você criou na etapa 1. Tem o seguinte formato: `CloudFormation-stack-name-TransferIdentityProviderRole-ABC123DEF456GHI`.
1. Preencha as caixas restantes e escolha **Criar servidor**. Para obter detalhes sobre as etapas restantes para criar um servidor, consulte [Configurando um endpoint de servidor SFTP, FTPS ou FTP](tf-server-endpoint.md).
## Implementar seu método do API Gateway
Para criar um provedor de identidade personalizado para o Transfer Family, seu método API Gateway deve implementar um único método que tenha um caminho de recurso de `/servers/serverId/users/username/config`. Os `username` valores `serverId` e vêm do caminho RESTful dos recursos. Além disso, adicione `sourceIp` e `protocol` como **Parâmetros de sequência de caracteres de consulta do URL** na **solicitação de método**, conforme mostrado na imagem a seguir.
![\[A tela de recursos do API Gateway mostrando os detalhes do GET método.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/apig-config-method-request.png)
**nota**
O nome de usuário deve ter no mínimo 3 e no máximo 100 caracteres. Você pode usar os seguintes caracteres no nome de usuário: a—z, A-Z, 0—9, sublinhado '\$1', hífen '-', ponto '.' e sinal de arroba '@'. O nome de usuário não pode começar com um hífen '-', ponto '.' ou com o sinal '@'.
Se o Transfer Family tentar uma autenticação de senha para o usuário, o serviço fornecerá um campo de cabeçalho `Password:`. Na ausência de um cabeçalho `Password:`, o Transfer Family tenta a autenticação por chave pública para autenticar seu usuário.
Ao usar um provedor de identidade para autenticar e autorizar usuários finais, além de validar suas credenciais, é possível permitir ou negar solicitações de acesso com base nos endereços IP dos clientes usados por seus usuários finais. É possível usar esse atributo para garantir que os dados armazenados em seus buckets do S3 ou em seu sistema de arquivos Amazon EFS possam ser acessados por meio dos protocolos suportados somente a partir de endereços IP que você especificou como confiáveis. Para ativar esse atributo, você deve incluir `sourceIp` na sequência de caracteres de consulta.
Se você tiver vários protocolos habilitados para seu servidor, e quiser fornecer acesso usando o mesmo nome de usuário em vários protocolos, poderá fazer isso desde que as credenciais específicas para cada protocolo tenham sido configuradas no seu provedor de identidade. Para habilitar esse recurso, você deve incluir o `protocol` valor no caminho do RESTful recurso.
Seu método do API Gateway deve sempre retornar o código de status HTTP `200`. Qualquer outro código de status HTTP indica um erro ao acessar a API.
**Resposta de exemplo do Amazon S3**
O corpo de resposta do exemplo é um documento JSON do seguinte formato para o Amazon S3.
```
{
"Role": "IAM role with configured S3 permissions",
"PublicKeys": [
"ssh-rsa public-key1",
"ssh-rsa public-key2"
],
"Policy": "STS Assume role session policy",
"HomeDirectory": "/amzn-s3-demo-bucket/path/to/home/directory"
}
```
**nota**
A política tem um JSON de escape como uma string. Por exemplo:
****
```
"Policy":
"{
\"Version\": \"2012-10-17\",
\"Statement\":
[
{\"Condition\":
{\"StringLike\":
{\"s3:prefix\":
[\"user/*\", \"user/\"]}},
\"Resource\": \"arn:aws:s3:::amzn-s3-demo-bucket\",
\"Action\": \"s3:ListBucket\",
\"Effect\": \"Allow\",
\"Sid\": \"ListHomeDir\"},
{\"Resource\": \"arn:aws:s3:::*\",
\"Action\": [\"s3:PutObject\",
\"s3:GetObject\",
\"s3:DeleteObjectVersion\",
\"s3:DeleteObject\",
\"s3:GetObjectVersion\",
\"s3:GetObjectACL\",
\"s3:PutObjectACL\"],
\"Effect\": \"Allow\",
\"Sid\": \"HomeDirObjectAccess\"}]
}"
```
O exemplo de resposta a seguir mostra que um usuário tem um tipo de diretório inicial lógico.
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-access-role-s3",
"HomeDirectoryType":"LOGICAL",
"HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/amzn-s3-demo-bucket1\"}]",
"PublicKeys":[""]
}
```
**Exemplo de resposta do Amazon EFS**
O corpo de resposta do exemplo é um documento JSON do seguinte formato para o Amazon EFS.
```
{
"Role": "IAM role with configured EFS permissions",
"PublicKeys": [
"ssh-rsa public-key1",
"ssh-rsa public-key2"
],
"PosixProfile": {
"Uid": "POSIX user ID",
"Gid": "POSIX group ID",
"SecondaryGids": [Optional list of secondary Group IDs],
},
"HomeDirectory": "/fs-id/path/to/home/directory"
}
```
O campo `Role` indica que ocorreu uma autenticação bem-sucedida. Ao fazer a autenticação por senha (quando você fornece um cabeçalho `Password:`), você não precisa fornecer chaves públicas SSH. Se um usuário não puder ser autenticado, por exemplo, se a senha estiver incorreta, seu método deverá retornar uma resposta sem um `Role` definido. Um exemplo dessa resposta é um objeto JSON vazio.
O exemplo de resposta a seguir mostra um usuário que tem um tipo de diretório inicial lógico.
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-access-role-efs",
"HomeDirectoryType": "LOGICAL",
"HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/faa1a123\"}]",
"PublicKeys":[""],
"PosixProfile":{"Uid":65534,"Gid":65534}
}
```
É possível incluir políticas de usuário na função do Lambda no formato JSON. Para obter mais informações sobre a configuração de políticas de usuário no Transfer Family, consulte [Gerenciar controles de acesso](users-policies.md).
## Função do Lambda padrão
Para implementar diferentes estratégias de autenticação, edite a função do Lambda que seu gateway usa. Para ajudá-lo a atender às necessidades do seu aplicativo, é possível usar os seguintes exemplos de funções do Lambda em Node.js. Para obter mais informações sobre o Lambda, consulte [Guia do desenvolvedor do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ou [Como criar funções do Lambda com Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html).
O exemplo a seguir da função do Lambda usa seu nome de usuário, senha (se você estiver executando a autenticação por senha), ID do servidor, protocolo e endereço IP do cliente. É possível usar uma combinação dessas entradas para pesquisar seu provedor de identidade e determinar se o login deve ser aceito.
**nota**
Se você tiver vários protocolos habilitados para seu servidor e quiser fornecer acesso usando o mesmo nome de usuário em vários protocolos, poderá fazer isso desde que as credenciais específicas do protocolo tenham sido configuradas no seu provedor de identidade.
Para File Transfer Protocol (FTP), recomendamos manter credenciais separadas do Secure Shell (SFTP) e File Transfer Protocol (SFTP) e File Transfer Protocol (FTP). Recomendamos manter credenciais separadas para o FTP porque, diferentemente do SFTP e do FTPS, o FTP transmite as credenciais em texto não criptografado. Ao isolar as credenciais de FTP do SFTP ou FTPS, se as credenciais de FTP forem compartilhadas ou expostas, suas cargas de trabalho usando SFTP ou FTPS permanecerão seguras.
Essa função de exemplo retorna a função e os detalhes do diretório inicial lógico, junto com as chaves públicas (se ela realizar a autenticação por chave pública).
Ao criar usuários gerenciados por serviços, você define o diretório inicial, lógico ou físico. Da mesma forma, precisamos dos resultados da função do Lambda para transmitir a estrutura de diretórios física ou lógica desejada pelo usuário. Os parâmetros definidos dependem do valor do campo [https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType).
+ `HomeDirectoryType` definido como `PATH` — o `HomeDirectory` campo deve então ser um prefixo absoluto do bucket do Amazon S3 ou um caminho absoluto do Amazon EFS que seja visível para seus usuários.
+ `HomeDirectoryType` definido como `LOGICAL` — *Não* defina um campo `HomeDirectory`. Em vez disso, definimos um `HomeDirectoryDetails` campo que fornece os Entry/Target mapeamentos desejados, semelhantes aos valores descritos no [https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings)parâmetro para usuários gerenciados por serviços.
As funções de exemplo estão listadas em [Exemplo de funções do Lambda](custom-lambda-idp.md#lambda-auth-examples).
## Função Lambda para uso com AWS Secrets Manager
Para usar AWS Secrets Manager como seu provedor de identidade, você pode trabalhar com a função Lambda no modelo de amostra CloudFormation . A função do Lambda consulta o serviço Secrets Manager com suas credenciais e, se for bem-sucedida, retorna um segredo designado. Para ter mais informações sobre o Secrets Manager, consulte o [Guia do usuário do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Para baixar um CloudFormation modelo de amostra que usa essa função Lambda, acesse o bucket do [Amazon S3 fornecido](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml) pela. AWS Transfer Family
## Melhorias nos CloudFormation modelos
Melhorias na interface do API Gateway foram feitas nos CloudFormation modelos publicados. Os modelos agora usam senhas BASE64 codificadas com o API Gateway. Suas implantações existentes continuam funcionando sem esse aprimoramento, mas não permitem senhas com caracteres fora do conjunto básico de caracteres US-ASCII.
As alterações no modelo que habilitam esse recurso são as seguintes:
+ O `GetUserConfigRequest AWS::ApiGateway::Method` recurso precisa ter esse `RequestTemplates` código (a linha em itálico é a linha atualizada)
```
RequestTemplates:
application/json: |
{
"username": "$util.urlDecode($input.params('username'))",
"password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
"protocol": "$input.params('protocol')",
"serverId": "$input.params('serverId')",
"sourceIp": "$input.params('sourceIp')"
}
```
+ O `RequestParameters` formulário do `GetUserConfig` recurso deve ser alterado para usar o `PasswordBase64` cabeçalho (a linha em itálico é a linha atualizada):
```
RequestParameters:
method.request.header.PasswordBase64: false
method.request.querystring.protocol: false
method.request.querystring.sourceIp: false
```
**Para verificar se o modelo da sua pilha é o mais recente**
1. Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Na lista de pilhas, escolha sua pilha.
1. No painel de detalhes, escolha a guia **Modelo**.
1. Procure o seguinte:
+ Pesquise `RequestTemplates` e verifique se você tem esta linha:
```
"password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
```
+ Pesquise `RequestParameters` e verifique se você tem esta linha:
```
method.request.header.PasswordBase64: false
```
Se você não vê as linhas atualizadas, edite sua pilha. Para obter detalhes sobre como atualizar sua CloudFormation pilha, consulte [Modificar um modelo de pilha](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-get-template.html) no *AWS CloudFormation;* Guia do usuário.
# Usando vários métodos de autenticação
O servidor Transfer Family controla a lógica AND quando você usa vários métodos de autenticação. A Transfer Family trata isso como duas solicitações separadas para seu provedor de identidade personalizado: no entanto, seus efeitos são combinados.
Ambas as solicitações devem retornar com êxito com a resposta correta para permitir que a autenticação seja concluída. O Transfer Family exige que as duas respostas sejam completas, o que significa que elas contêm todos os elementos necessários (função, diretório inicial, política e perfil POSIX se você estiver usando o Amazon EFS para armazenamento). O Transfer Family também exige que a resposta da senha não inclua chaves públicas.
A solicitação de chave pública deve ter uma resposta separada do provedor de identidade. Esse comportamento permanece inalterado ao usar **Senha OU Chave ou** **Senha E Chave**.
O protocolo SSH/SFTP desafia o cliente de software primeiro com uma autenticação de chave pública e, em seguida, solicita uma autenticação por senha. Essa operação exige que ambas sejam bem-sucedidas antes que o usuário possa concluir a autenticação.
Para opções personalizadas de provedor de identidade, você pode especificar qualquer uma das opções a seguir sobre como autenticar.
+ **Senha OU chave** — os usuários podem se autenticar com sua senha ou chave. Este é o valor padrão.
+ **SOMENTE senha** — os usuários devem fornecer sua senha para se conectar.
+ **SOMENTE CHAVE** — os usuários devem fornecer sua chave privada para se conectar.
+ **Senha e chave** — os usuários devem fornecer a chave privada e a senha para se conectar. O servidor verifica a chave em primeiro lugar e, em seguida, se a chave for válida, o sistema solicitará uma senha. Se a chave privada fornecida não for correspondente à chave pública armazenada, a autenticação falhará.
# IPv6 suporte para provedores de identidade personalizados
AWS Transfer Family provedores de identidade personalizados oferecem suporte total às IPv6 conexões. Ao implementar um provedor de identidade personalizado, sua função Lambda pode receber e processar solicitações de autenticação de ambos IPv4 e de IPv6 clientes sem nenhuma configuração adicional. A função Lambda recebe o endereço IP do cliente no `sourceIp` campo da solicitação, que pode ser um IPv4 endereço (por exemplo,`203.0.113.42`) ou um IPv6 endereço (por exemplo,`2001:db8:85a3:8d3:1319:8a2e:370:7348`). A implementação do seu provedor de identidade personalizado deve lidar com os dois formatos de endereço de forma adequada.
**Importante**
Se seu provedor de identidade personalizado realizar validação ou registro com base em IP, certifique-se de que sua implementação manipule adequadamente os formatos IPv6 de endereço. IPv6 os endereços são maiores que IPv4 os endereços e usam um formato de notação diferente.
**nota**
Ao lidar com IPv6 endereços em seu provedor de identidade personalizado, certifique-se de usar funções de análise de IPv6 endereço adequadas em vez de simples comparações de strings. IPv6os endereços podem ser representados em vários formatos canônicos (por exemplo, `fd00:b600::ec2` ou`fd00:b600:0:0:0:0:0:ec2`). Use bibliotecas IPv6 de endereços ou funções apropriadas em sua linguagem de implementação para validar e comparar IPv6 endereços corretamente.
**Example Tratamento de ambos IPv4 e IPv6 endereços em um provedor de identidade personalizado**
```
def lambda_handler(event, context):
# Extract the source IP address from the request
source_ip = event.get('sourceIp', '')
# Log the client IP address (works for both IPv4 and IPv6)
print(f"Authentication request from: {source_ip}")
# Example of IP-based validation that works with both IPv4 and IPv6
if is_ip_allowed(source_ip):
# Continue with authentication
# ...
else:
# Reject the authentication request
return {
"Role": "",
"HomeDirectory": "",
"Status": "DENIED"
}
```
Para obter mais informações sobre a implementação de provedores de identidade personalizados, consulte[Usando AWS Lambda para integrar seu provedor de identidade](custom-lambda-idp.md).
# Usando o AWS Directory Service para o Microsoft Active Directory
Você pode usar AWS Transfer Family para autenticar seus usuários finais de transferência de arquivos usando AWS Directory Service for Microsoft Active Directory. Ele permite a migração perfeita de fluxos de trabalho de transferência de arquivos que dependem da autenticação do Active Directory sem alterar as credenciais dos usuários finais ou precisar de um autorizador personalizado.
Com AWS Managed Microsoft AD, você pode fornecer acesso seguro a Directory Service usuários e grupos via SFTP, FTPS e FTP para dados armazenados no Amazon Simple Storage Service (Amazon S3) ou no Amazon Elastic File System (Amazon EFS). Se você usa o Active Directory para armazenar as credenciais de seus usuários, agora tem uma maneira mais fácil de habilitar transferências de arquivos para esses usuários.
Você pode fornecer acesso aos grupos do Active Directory AWS Managed Microsoft AD em seu ambiente local ou na AWS nuvem usando conectores do Active Directory. Você pode dar aos usuários que já estão configurados em seu ambiente Microsoft Windows, na AWS nuvem ou em sua rede local, acesso a um AWS Transfer Family servidor que usa AWS Managed Microsoft AD como identidade. O blog AWS de armazenamento contém uma postagem que detalha uma solução para usar o Active Directory com o Transfer Family: [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
**nota**
AWS Transfer Family não é compatível com Simple AD.
O Transfer Family não é compatível com as configurações entre regiões do Active Directory: oferecemos suporte apenas às integrações do Active Directory que estejam na mesma região do servidor Transfer Family.
O Transfer Family não suporta o uso de nenhum deles AWS Managed Microsoft AD nem do AD Connector para habilitar a autenticação multifator (MFA) para sua infraestrutura de MFA existente baseada em RADIUS.
AWS Transfer Family não oferece suporte a regiões replicadas do Managed Active Directory.
Para usar AWS Managed Microsoft AD, você deve executar as seguintes etapas:
1. Crie um ou mais AWS Managed Microsoft AD diretórios usando o Directory Service console.
1. Use o console Transfer Family para criar um servidor que use AWS Managed Microsoft AD como provedor de identidade.
1. Configure o AWS Directory usando um conector do Active Directory.
1. Adicione acesso de um ou mais dos seus Directory Service grupos.
1. Embora não seja obrigatório, recomendamos que você teste e verifique o acesso do usuário.
**Topics**
+ [Antes de começar a usar AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)
+ [Trabalhando com realms do Active Directory](#managed-ad-realms)
+ [Escolhendo AWS Managed Microsoft AD como seu provedor de identidade](#managed-ad-identity-provider)
+ [Conectando-se ao Microsoft Active Directory local](#on-prem-ad)
+ [Como conceder acesso a grupos](#directory-services-grant-access)
+ [Testando usuários](#directory-services-test-user)
+ [Como excluir o acesso ao servidor para um grupo](#directory-services-misc)
+ [Como se conectar ao servidor usando SSH (Secure Shell)](#directory-services-ssh-procedure)
+ [Conectando-se AWS Transfer Family a um Active Directory autogerenciado usando florestas e relações de confiança](#directory-services-ad-trust)
## Antes de começar a usar AWS Directory Service for Microsoft Active Directory
**nota**
AWS Transfer Family tem um limite padrão de 100 grupos do Active Directory por servidor. Se seu caso de uso exigir mais de 100 grupos, considere usar uma solução de provedor de identidade personalizada, conforme descrito em [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
### Forneça um identificador exclusivo para seus grupos do AD
Antes de poder usar AWS Managed Microsoft AD, você deve fornecer um identificador exclusivo para cada grupo em seu diretório do Microsoft AD. É possível usar o identificador de segurança (SID) de cada grupo para fazer isso. Os usuários do grupo que você associa têm acesso aos seus recursos do Amazon S3 ou do Amazon EFS por meio dos protocolos habilitados usando o AWS Transfer Family.
Use o seguinte PowerShell comando do Windows para recuperar o SID de um grupo, *YourGroupName* substituindo-o pelo nome do grupo.
```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```
**nota**
Se você estiver usando AWS Directory Service como seu provedor de identidade `userPrincipalName` e `SamAccountName` tiver valores diferentes, AWS Transfer Family aceite o valor em`SamAccountName`. O Transfer Family não aceita o valor especificado em `userPrincipalName`.
### Adicione Directory Service permissões à sua função
Você também precisa de permissões de Directory Service API para usar AWS Directory Service como seu provedor de identidade. As seguintes permissões são necessárias ou sugeridas:
+ `ds:DescribeDirectories` é necessária para que o Transfer Family procure o diretório
+ `ds:AuthorizeApplication` é necessária para adicionar autorização para o Transfer Family
+ `ds:UnauthorizeApplication` é sugerida para remover todos os recursos criados provisoriamente, caso algo dê errado durante o processo de criação do servidor
Adicione essas permissões à função que você está usando para criar seus servidores do Transfer Family. Para obter detalhes sobre essas permissões, consulte [Permissões da API do Directory Service : referência de ações, recursos e condições](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/UsingWithDS_IAM_ResourcePermissions.html).
## Trabalhando com realms do Active Directory
Ao considerar como fazer com que seus usuários do Active Directory acessem os servidores AWS Transfer Family , tenha em mente o realm do usuário e o realm do grupo. Idealmente, o realm do usuário e o realm do grupo devem corresponder. Ou seja, tanto o usuário quanto o grupo estão no realm padrão, ou ambos estão no realm confiável. Se esse não for o caso, o usuário não poderá ser autenticado pelo Transfer Family.
É possível testar o usuário para garantir que a configuração esteja correta. Para obter detalhes, consulte [Testando usuários](#directory-services-test-user). Se houver um problema com o user/group território, você receberá o erro Nenhum acesso associado encontrado para grupos de usuários.
## Escolhendo AWS Managed Microsoft AD como seu provedor de identidade
Esta seção descreve como usar AWS Directory Service for Microsoft Active Directory com um servidor.
**Para usar AWS Managed Microsoft AD com Transfer Family**
1. Faça login no Console de gerenciamento da AWS e abra o Directory Service console em [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).
Use o Directory Service console para configurar um ou mais diretórios gerenciados. Para obter mais informações, consulte [AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), no *Guia do administrador do Directory Service *.
![\[O console do Directory Service mostrando uma lista de diretórios e seus detalhes.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/directory-services-AD-list.png)
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)e escolha **Criar servidor**.
1. Na página **Escolher protocolos**, escolha um ou mais protocolos na lista.
**nota**
Se você selecionar **FTPS**, deverá fornecer o certificado AWS Certificate Manager .
1. Em **Escolher um provedor de identidade**, escolha **Directory Service AWS **.
![\[Captura de tela do console mostrando a seção Escolha provedor de identidade com o Directory Service selecionado.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/create-server-choose-idp-directory-services.png)
1. A lista **Diretórios** contém todos os diretórios gerenciados que você configurou. Escolha um diretório da lista e escolha **Próximo**.
**nota**
Não há suporte para diretórios entre contas e compartilhados. AWS Managed Microsoft AD
Para configurar um servidor com o Directory Service como seu provedor de identidade, você precisa adicionar algumas Directory Service permissões. Para obter detalhes, consulte [Antes de começar a usar AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Para concluir a criação do servidor, use um dos procedimentos a seguir:
+ [Criar um servidor habilitado para SFTP](create-server-sftp.md)
+ [Criar um servidor habilitado para FTPS](create-server-ftps.md)
+ [Criar um servidor habilitado para FTP](create-server-ftp.md)
Nesses procedimentos, continue com a etapa a seguir, escolhendo um provedor de identidade.
**Importante**
Você não pode excluir um diretório do Microsoft AD Directory Service se o tiver usado em um servidor Transfer Family. Primeiro, você deve excluir o servidor e, em seguida, excluir o diretório.
## Conectando-se ao Microsoft Active Directory local
Esta seção descreve como configurar um AWS diretório usando um AD Connector
**Para configurar seu AWS diretório usando o AD Connector**
1. Abra o console do [Directory Service](https://console.aws.amazon.com/directoryservicev2/) e selecione **Diretórios**.
1. Selecione **Configurar diretório**.
1. Em tipo de diretório, escolha **AD Connector**.
1. Selecione um tamanho de diretório, selecione **Avançar** e, em seguida, selecione sua VPC e sub-redes.
1. Selecione **Avançar** e preencha os campos da seguinte forma:
+ Nome **DNS do diretório**: insira o nome de domínio que você está usando para o Microsoft Active Directory.
+ **Endereços IP DNS: insira seus endereços** IP do Microsoft Active Directory.
+ **Nome de usuário e **senha** da conta do servidor**: insira os detalhes da conta de serviço a ser usada.
1. Preencha as telas para criar o serviço de diretório.
A próxima etapa é criar um servidor Transfer Family com o protocolo SFTP e o tipo de provedor de identidade do **AWS Directory Service**. Na lista suspensa **Diretório**, selecione o diretório que você adicionou no procedimento anterior.
## Como conceder acesso a grupos
Depois de criar o servidor, você deve escolher quais grupos no diretório devem ter acesso para carregar e baixar arquivos usando os protocolos habilitados AWS Transfer Family. Você faz isso criando um *acesso*.
**nota**
AWS Transfer Family tem um limite padrão de 100 grupos do Active Directory por servidor. Se seu caso de uso exigir mais de 100 grupos, considere usar uma solução de provedor de identidade personalizada, conforme descrito em [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
**nota**
Os usuários devem pertencer *diretamente* ao grupo ao qual você está concedendo acesso. Por exemplo, suponha que Bob seja um usuário e pertença ao Grupo A, e que o próprio Grupo A esteja incluído no Grupo B.
Se você conceder acesso ao Grupo A, Bob terá acesso.
Se você conceder acesso ao Grupo B (e não ao Grupo A), Bob não terá acesso.
**Para conceder acesso a um grupo**
1. Abra o AWS Transfer Family console em [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Navegue até a página de detalhes do seu servidor.
1. Na seção **Acessos**, escolha **Adicionar acesso**.
1. Insira o SID do AWS Managed Microsoft AD diretório ao qual você deseja ter acesso ao servidor.
**nota**
Para obter informações sobre como encontrar o SID do seu grupo, consulte [Antes de começar a usar AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Para **Access**, escolha uma função AWS Identity and Access Management (IAM) para o grupo.
1. Na seção **Política**, escolha uma política. A configuração padrão é **Nenhum**.
1. Para o **diretório inicial**, escolha um bucket do Amazon S3 que corresponda ao diretório inicial do grupo.
**nota**
É possível limitar as partes do bucket que os usuários veem criando uma política de sessão. Por exemplo, para limitar os usuários à sua própria pasta no diretório `/filetest`, insira o texto a seguir na caixa.
```
/filetest/${transfer:UserName}
```
Para saber mais sobre como criar uma política de sessão, consulte [Criar uma política de sessão de um bucket do Amazon S3](users-policies-session.md).
1. Escolha **Adicionar** para criar a associação.
1. Escolha seu servidor.
1. Escolha **Adicionar acesso**.
1. Insira o SID do grupo.
**nota**
Para obter informações sobre como encontrar o SID, consulte [Antes de começar a usar AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Escolha **Adicionar acesso**.
Na seção **Acessos**, os acessos para o servidor estão listados.
![\[Console mostrando a seção Acessos com os acessos do servidor listados.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/accesses-list.png)
## Testando usuários
Você pode testar se um usuário tem acesso ao AWS Managed Microsoft AD diretório do seu servidor.
**nota**
Um usuário deve estar em exatamente um grupo (uma ID externa) listado na seção **Acesso** da página de **Configuração do Endpoint**. Se o usuário não estiver em nenhum grupo ou estiver em mais de um único grupo, esse usuário não receberá acesso.
**Para testar se um usuário específico tem acesso**
1. Na página de detalhes do servidor, escolha **Ações** e, em seguida, escolha **Teste**.
1. Para **testar o provedor de identidade**, insira as credenciais de login de um usuário que está em um dos grupos que tem acesso.
1. Escolha **Testar**.
Você vê um teste bem-sucedido do provedor de identidade, mostrando que o usuário selecionado recebeu acesso ao servidor.
![\[Captura de tela do console da resposta bem-sucedida do teste do provedor de identidade.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/identity-provider-test-success.png)
Se o usuário pertencer a mais de um grupo que tenha acesso, você receberá a seguinte resposta.
```
"Response":"",
"StatusCode":200,
"Message":"More than one associated access found for user's groups."
```
## Como excluir o acesso ao servidor para um grupo
**Para excluir o acesso ao servidor para um grupo**
1. Na página de detalhes do servidor, escolha **Ações** e, em seguida, escolha **Excluir acesso**.
1. Na caixa de diálogo, confirme que deseja remover o acesso para este grupo.
Ao retornar à página de detalhes do servidor, você verá que o acesso para o grupo não está mais listado.
## Como se conectar ao servidor usando SSH (Secure Shell)
Depois de configurar o servidor e os usuários, é possível se conectar ao servidor usando SSH e usar o nome de usuário totalmente qualificado para um usuário que tenha acesso.
```
sftp user@active-directory-domain@vpc-endpoint
```
Por exemplo: `transferuserexample@mycompany.com@vpce-0123456abcdef-789xyz.vpc-svc-987654zyxabc.us-east-1.vpce.amazonaws.com`.
Este formato tem como destino a pesquisa da federação, limitando a pesquisa de um Active Directory potencialmente grande.
**nota**
É possível especificar o nome de usuário simples. No entanto, neste caso, o código do Active Directory precisa pesquisar todos os diretórios na federação. Isso pode limitar a pesquisa e a autenticação pode falhar mesmo que o usuário tenha acesso.
Após a autenticação, o usuário fica localizado no diretório inicial que você especificou quando configurou o usuário.
## Conectando-se AWS Transfer Family a um Active Directory autogerenciado usando florestas e relações de confiança
Directory Service tem as seguintes opções disponíveis para se conectar a um Active Directory autogerenciado:
+ A confiança unidirecional na floresta (de saída AWS Managed Microsoft AD e entrada para o Active Directory local) funciona somente para o domínio raiz.
+ Para domínios secundários, é possível usar um dos seguintes:
+ Use a confiança bidirecional entre o Active Directory local AWS Managed Microsoft AD e o Active Directory
+ Use confiança externa unidirecional para cada domínio secundário.
Ao se conectar ao servidor usando um domínio confiável, o usuário precisa especificar o domínio confiável, por exemplo, `transferuserexample@mycompany.com`.
# Usando o AWS Directory Service para serviços de domínio Entra ID
Para clientes que precisam apenas de transferência por SFTP e não desejam gerenciar um domínio, existe o Simple Active Directory. Como alternativa, os clientes que desejam os benefícios do Active Directory e a alta disponibilidade em um serviço totalmente gerenciado podem usar o Microsoft AD gerenciado da AWS . Por fim, para clientes que desejam aproveitar a floresta existente do Active Directory para a transferência por SFTP, existe o Active Directory Connector.
Observe o seguinte:
+ Para aproveitar sua floresta existente do Active Directory para atender às suas necessidades de transferência por SFTP, é possível usar o [Active Directory Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html).
+ Se deseja os benefícios do Active Directory e a alta disponibilidade em um serviço totalmente gerenciado, é possível usar o AWS Directory Service for Microsoft Active Directory. Para obter detalhes, consulte [Usando o AWS Directory Service para o Microsoft Active Directory](directory-services-users.md).
Este tópico descreve como usar um conector do Active Directory e os [serviços de domínio Entra ID (anteriormente Azure AD)](https://azure.microsoft.com/en-us/services/active-directory-ds/) para autenticar usuários do SFTP Transfer com o Entra ID.
**Topics**
+ [Antes de começar a usar o AWS Directory Service para o Entra ID Domain Services](#azure-prereq)
+ [Etapa 1: Adicionar serviços de domínio Entra ID](#azure-add-adds)
+ [Etapa 2: Criar uma conta de serviço](#azure-create-service-acct)
+ [Etapa 3: Configurando o AWS diretório usando o AD Connector](#azure-setup-directory)
+ [Etapa 4: Configurar o AWS Transfer Family servidor](#azure-setup-transfer-server)
+ [Etapa 5: Conceder acesso a grupos](#azure-grant-access)
+ [Etapa 6: Testar usuários](#azure-test)
## Antes de começar a usar o AWS Directory Service para o Entra ID Domain Services
**nota**
AWS Transfer Family tem um limite padrão de 100 grupos do Active Directory por servidor. Se seu caso de uso exigir mais de 100 grupos, considere usar uma solução de provedor de identidade personalizada, conforme descrito em [Simplifique a autenticação do Active Directory com um provedor de identidade personalizado para AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
Para AWS isso, você precisa do seguinte:
+ Uma nuvem privada virtual (VPC) em uma AWS região em que você está usando seus servidores Transfer Family
+ Pelo menos duas sub-redes privadas na VPC
+ A VPC deve ter conectividade com a Internet
+ Um gateway de cliente e um gateway privado virtual para conexão site-to-site VPN com o Microsoft Entra
Para o Microsoft Entra, você precisa do seguinte:
+ Um serviço de domínio Entra ID e Active Directory
+ Um grupo de recursos da Entra
+ Uma rede virtual Entra
+ Conectividade VPN entre sua Amazon VPC e seu grupo de recursos Entra
**nota**
Isso pode ser feito por meio de túneis IPSEC nativos ou usando dispositivos VPN. Neste tópico, usamos túneis IPSEC entre um gateway de rede virtual Entra e um gateway de rede local. Os túneis devem ser configurados para permitir o tráfego entre seus endpoints do Entra Domain Service e as sub-redes que abrigam sua VPC. AWS
+ Um gateway de cliente e um gateway privado virtual para conexão site-to-site VPN com o Microsoft Entra
O diagrama a seguir mostra a configuração necessária antes de começar.
![\[Entra/Azure AD e diagrama de AWS Transfer Family arquitetura. Uma AWS VPC se conectando a uma rede virtual da Entra pela Internet, usando um conector do AWS Directory Service para o Entra Domain Service.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-architecture.png)
## Etapa 1: Adicionar serviços de domínio Entra ID
O Entra ID não oferece suporte a instâncias de ingresso de domínio por padrão. Para realizar ações como o Domain Join e usar ferramentas como a Política de Grupo, os administradores devem habilitar os Serviços de Domínio Entra ID. Se você ainda não adicionou o Entra DS, ou sua implementação existente não está associada ao domínio que você deseja que seu servidor de transferência SFTP use, você deve adicionar uma nova instância.
Para obter informações sobre como habilitar os Serviços de Domínio Entra ID, consulte [Tutorial: Criar e configurar um domínio gerenciado do Microsoft Entra Domain Services](https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started).
**nota**
Ao habilitar o Entra DS, verifique se ele está configurado para o grupo de recursos e o domínio Entra ao qual você está conectando seu servidor de transferência SFTP.
![\[Entre na tela de serviços de domínio mostrando o grupo de recursos bob.us em execução.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-ad-add-instance.png)
## Etapa 2: Criar uma conta de serviço
O Entra deve ter uma conta de serviço que faça parte de um grupo de administradores no Entra DS. Essa conta é usada com o conector do AWS Active Directory. Certifique-se de que essa conta esteja sincronizada com o Entra DS.
![\[Entre na tela mostrando o perfil de um usuário.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-service-acct.png)
**dica**
A autenticação multifator para o Entra ID não é suportada pelos servidores Transfer Family que usam o protocolo SFTP. O servidor do Transfer Family não pode fornecer o token MFA depois que um usuário se autentica no SFTP. Certifique-se de desativar o MFA antes de tentar se conectar.
![\[Insira os detalhes da autenticação multifatorial, mostrando o status da MFA como desativada para dois usuários.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-ad-mfa-disable.png)
## Etapa 3: Configurando o AWS diretório usando o AD Connector
Depois de configurar o Entra DS e criar uma conta de serviço com túneis VPN IPSEC entre sua AWS VPC e a rede virtual Entra, você pode testar a conectividade fazendo ping no endereço IP DNS do Entra DS de qualquer instância do EC2. AWS
Depois de verificar se a conexão está ativa, continue abaixo.
**Para configurar seu AWS diretório usando o AD Connector**
1. Abra o console do [Directory Service](https://console.aws.amazon.com/directoryservicev2/) e selecione **Diretórios**.
1. Selecione **Configurar diretório**.
1. Em tipo de diretório, escolha **AD Connector**.
1. Selecione um tamanho de diretório, selecione **Avançar** e, em seguida, selecione sua VPC e sub-redes.
1. Selecione **Avançar** e preencha os campos da seguinte forma:
+ Nome **DNS do diretório**: insira o nome de domínio que você está usando para o Entra DS.
+ **Endereços IP DNS: insira seus endereços** IP do Entra DS.
+ **Nome de usuário da conta do servidor** e **senha**: insira os detalhes da conta de serviço que você criou na *Etapa 2: Crie uma conta de serviço*.
1. Preencha as telas para criar o serviço de diretório.
Agora, o status do diretório deve estar **Ativo** e está pronto para ser usado com um servidor de transferência SFTP.
![\[A tela Serviços de Diretório mostrando um diretório com status Ativo, conforme necessário.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-connector-ready.png)
## Etapa 4: Configurar o AWS Transfer Family servidor
Crie um servidor Transfer Family com o protocolo SFTP e o tipo de provedor de identidade do **AWS Directory Service**. Na lista suspensa **Diretórios**, selecione o diretório que você adicionou na *Etapa 3: Configurar o AWS Directory usando o AD Connector*.
**nota**
Você não pode excluir um diretório do Microsoft AD no AWS Directory Service se o tiver usado em um servidor Transfer Family. Primeiro, você deve excluir o servidor e, em seguida, excluir o diretório.
## Etapa 5: Conceder acesso a grupos
Depois de criar o servidor, você deve escolher quais grupos no diretório devem ter acesso para carregar e baixar arquivos usando os protocolos habilitados AWS Transfer Family. Você faz isso criando um *acesso*.
**nota**
Os usuários devem pertencer *diretamente* ao grupo ao qual você está concedendo acesso. Por exemplo, suponha que Bob seja um usuário e pertença ao Grupo A, e que o próprio Grupo A esteja incluído no Grupo B.
Se você conceder acesso ao Grupo A, Bob terá acesso.
Se você conceder acesso ao Grupo B (e não ao Grupo A), Bob não terá acesso.
Para conceder acesso, você precisa recuperar o SID do grupo.
Use o seguinte PowerShell comando do Windows para recuperar o SID de um grupo, *YourGroupName* substituindo-o pelo nome do grupo.
```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```
![\[Windows PowerShell mostrando um SID de objeto sendo recuperado.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-grant-access.png)
**Conceder acesso a grupos**
1. Abra o [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Navegue até a página de detalhes do servidor e, na seção **Acessos**, escolha **Adicionar acesso**.
1. Insira o SID que você recebeu da saída do procedimento anterior.
1. Para **Access**, escolha uma AWS Identity and Access Management função para o grupo.
1. Na seção **Política**, escolha uma política. O valor padrão é **Nenhum**.
1. Para o **diretório inicial**, escolha um bucket do Amazon S3 que corresponda ao diretório inicial do grupo.
1. Escolha **Adicionar** para criar a associação.
Os detalhes do servidor de transferência devem ser semelhantes aos seguintes:
![\[Uma parte da tela de detalhes do servidor Transfer Family, mostrando um exemplo de ID de diretório para o provedor de identidade.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-assoc-1.png)
![\[Uma parte da tela de detalhes do servidor Transfer Family, mostrando a ID externa do Active Directory na parte Accessos da tela.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/azure-assoc-2.png)
## Etapa 6: Testar usuários
É possível testar ([Testando usuários](directory-services-users.md#directory-services-test-user)) se um usuário tem acesso ao diretório AWS Managed Microsoft AD do seu servidor. Um usuário deve estar em exatamente um grupo (uma ID externa) listado na seção **Acesso** da página de **Configuração do Endpoint**. Se o usuário não estiver em nenhum grupo ou estiver em mais de um único grupo, esse usuário não receberá acesso.