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á. # 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).