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á.
Praticas recomendadas de segurança para grupos de usuários do Amazon Cognito
Esta página descreve as práticas recomendadas de segurança que você pode implementar para proteção contra ameaças comuns. A configuração escolhida dependerá do caso de uso de cada aplicação. Recomendamos que, pelo menos, sejam aplicados privilégios mínimos às operações administrativas e sejam tomadas medidas para proteger os segredos da aplicação e do usuário. Outra etapa avançada, mas eficaz, que você pode realizar é configurar e aplicar ACLs a AWS WAF web aos grupos de usuários.
Proteja seu grupo de usuários no nível da rede
AWS WAF A web ACLs pode proteger o desempenho e o custo dos mecanismos de autenticação que você cria com o Amazon Cognito. Com a web ACLs, você pode implementar grades de proteção na frente da API e das solicitações de login gerenciadas. ACLs Crie filtros de camada de rede e de aplicativos na Web que podem reduzir o tráfego ou exigir um CAPTCHA com base nas regras que você cria. As solicitações não são transmitidas para seus recursos do Amazon Cognito até que atendam às qualificações nas regras da Web ACL. Para obter mais informações, consulte AWS WAF web ACLs.
Proteger contra o abuso de mensagens SMS
Ao permitir a inscrição pública em seu grupo de usuários, você pode configurar a verificação da conta com códigos que o Amazon Cognito envia em mensagens de texto SMS. As mensagens SMS podem ser associadas a atividades indesejadas e aumentar sua AWS fatura. Configure sua infraestrutura para ser resiliente contra o envio de mensagens SMS em situações de fraude. Para obter mais informações, revise as seguintes postagens de AWS Blogs.
Entender a autenticação pública
Os grupos de usuários do Amazon Cognito têm recursos de gerenciamento de identidade e acesso do cliente (CIAM) que oferecem suporte a casos de uso em que membros do público podem cadastrar uma conta de usuário e acessar suas aplicações. Quando um grupo de usuários permite a inscrição por autoatendimento, ele está aberto a solicitações de contas de usuário da internet pública. As solicitações de autoatendimento vêm de operações de API, como SignUpe InitiateAuth, e da interação do usuário com o login gerenciado. Você pode configurar grupos de usuários para mitigar abusos decorrentes de solicitações públicas ou desabilitar totalmente as operações de autenticação pública.
As configurações a seguir são algumas das maneiras pelas quais você pode gerenciar solicitações de autenticação pública e interna em seus grupos de usuários e clientes de aplicações.
| Configuração | Opções disponíveis | Configurado em | Efeito na autenticação pública | Configuração do console | Operação e parâmetro da API |
|---|---|---|---|---|---|
| Cadastro por autoatendimento | Permita que os usuários se inscrevam em uma conta ou criem contas de usuário como administrador. | Grupo de usuários | Impedir cadastro público | Cadastrar-se – Cadastro por autoatendimento |
CreateUserPool, UpdateUserPool
|
| Confirmação do administrador | Envie códigos de confirmação para novos usuários ou exija que os administradores os confirmem. | Grupo de usuários | Impedir a confirmação de cadastro sem ação do administrador | Cadastrar-se – Verificação e confirmação assistidas pelo Cognito |
CreateUserPool, UpdateUserPool
|
| Divulgação de usuário | Entregue mensagens de “usuário não encontrado” no login e na redefinição de senha ou evite a divulgação. | Cliente da aplicação | Proteger contra adivinhação do nome de login, endereço de e-mail ou números de telefone | Clientes da aplicação – Impedir erros de existência de usuário |
CreateUserPoolClient, UpdateUserPoolClient
|
| Segredo do cliente | Exigir ou não um hash secreto no cadastro, login e redefinição de senha | Cliente da aplicação | Proteger contra solicitações de autenticação de fontes não autorizadas | Clientes de aplicações — Segredo do cliente |
|
| Web ACLs | Habilitar ou não um firewall de rede para solicitações de autenticação | Grupo de usuários | Limitar ou impedir o acesso com base nas características de solicitação definidas pelo administrador e nas regras de endereço IP | AWS WAF – Configurações WAF |
|
| IdP externo | Permitir o login de usuários de terceiros IdPs, no diretório do grupo de usuários ou em ambos | Cliente da aplicação | Exclua usuários locais ou usuários federados do cadastro e login. | Clientes da aplicação — Provedores de identidade |
CreateUserPoolClient, UpdateUserPoolClient
|
| Servidor de autorização | Hospedar ou não páginas da web públicas para autenticação | Grupo de usuários | Desativar páginas da web públicas e permitir somente a autenticação baseada em SDK | Domínio |
A criação de qualquer domínio de grupo de usuários disponibiliza páginas da web públicas. |
| Proteção contra ameaças | Habilitar ou desabilitar o monitoramento de sinais de atividade maliciosa ou senhas inseguras | Grupo de usuários ou cliente da aplicação | Poder bloquear automaticamente o login ou exigir MFA quando os usuários mostram indicadores de comprometimento | Proteção contra ameaças — Configurações de proteção |
Os parâmetros de |
Proteger clientes confidenciais com segredos do cliente
O segredo do cliente é uma string opcional associada a um cliente de aplicação. Todas as solicitações de autenticação para clientes de aplicações com segredos de cliente devem incluir um hash secreto gerado com base no nome de usuário, ID do cliente e segredo do cliente. Aqueles que não conhecem o segredo do cliente são excluídos da sua aplicação desde o início.
No entanto, os segredos do cliente têm limitações. Se você incorporar um segredo de cliente a um software-cliente público, o segredo do cliente estará aberto à inspeção. Assim, abre-se a capacidade de criar usuários, enviar solicitações de redefinição de senha e realizar outras operações no cliente da sua aplicação. Os segredos do cliente devem ser implementados somente quando uma aplicação é a única entidade que tem acesso ao segredo. Normalmente, isso é possível em aplicações clientes confidenciais do lado do servidor. Isso também se aplica às aplicações M2M, nas quais é necessário um segredo do cliente. Armazene o segredo do cliente em um armazenamento local criptografado ou AWS Secrets Manager. Nunca deixe o segredo de seu cliente ser visível na internet pública.
Proteger outros segredos
Seu sistema de autenticação com grupos de usuários do Amazon Cognito pode lidar com dados, senhas e credenciais da AWS . Estas são algumas das práticas recomendadas para lidar com segredos que sua aplicação pode acessar.
- Senhas
-
Os usuários podem inserir senhas ao entrarem na sua aplicação. O Amazon Cognito tem tokens de atualização que sua aplicação pode empregar para continuar as sessões de usuário expiradas sem uma nova solicitação de senha. Não coloque nenhuma senha ou hash de senha no armazenamento local. Projete sua aplicação para tratar as senhas como não visíveis e transmiti-las somente para seu grupo de usuários.
Como prática recomendada, implemente a autenticação sem senha com WebAuthn chaves de acesso. Se você precisar implementar senhas, use o fluxo de autenticação Secure Remote Password (SRP) e a autenticação multifator (MFA).
- AWS credenciais
-
A autenticação administrativa e as operações administrativas do grupo de usuários exigem autenticação com AWS credenciais. Para implementar essas operações em um aplicativo, conceda acesso seguro às AWS credenciais temporárias. Conceda acesso às credenciais somente às aplicações executadas em um componente do servidor que você controla. Não coloque aplicativos que tenham AWS credenciais em sistemas públicos de controle de versão, como o. GitHub Não codifique AWS credenciais em aplicativos públicos do lado do cliente.
- Verificador de código PKCE
-
O Proof Key for Code Exchange, ou PKCE, é para concessões de código de autorização do OpenID Connect (OIDC) com seu servidor de autorização de grupo de usuários. As aplicações compartilham segredos do verificador de código com seu grupo de usuários quando solicitam códigos de autorização. Para trocar códigos de autorização por tokens, os clientes devem reafirmar que conhecem o verificador do código. Essa prática evita a emissão de tokens com códigos de autorização interceptados.
Os clientes devem gerar um novo verificador de código aleatório com cada solicitação de autorização. O uso de um verificador de código estático ou previsível significa que o invasor só precisa interceptar o verificador codificado e o código de autorização. Projete sua aplicação para que ela não exponha os valores do verificador de código aos usuários.
Privilégio mínimo de administração do grupo de usuários
As políticas do IAM podem definir o nível de acesso das entidades principais à administração do grupo de usuários e às operações de autenticação administrativa do Amazon Cognito. Por exemplo:
-
Para um servidor web, conceda permissões para autenticação com operações administrativas de API.
-
Para um AWS IAM Identity Center usuário que gerencia um grupo de usuários no seu Conta da AWS, conceda permissões para manutenção e geração de relatórios do grupo de usuários.
O nível de granularidade dos recursos no Amazon Cognito é limitado a dois tipos de recursos para fins de política do IAM: grupo de usuários e banco de identidades. Observe que não é possível aplicar permissões para gerenciar clientes de aplicação individuais. Configure grupos de usuários com o conhecimento de que as permissões que você concede são efetivas em todos os clientes da aplicação. Quando sua organização tem vários locatários de aplicação e seu modelo de segurança exige a separação das responsabilidades administrativas entre os locatários, implemente a multilocação com um locatário por grupo de usuários.
Embora seja possível criar políticas do IAM com permissões para operações de autenticação do usuário como InitiateAuth, essas permissões não têm efeito. As operações de API públicas e autorizadas por tokens não estão sujeitas às permissões do IAM. Das operações de autenticação de grupos de usuários disponíveis, você só pode conceder permissões para operações administrativas do servidor, como AdminInitiateAuth.
Você pode limitar os níveis de administração do grupo de usuários com listas de privilégios mínimos Action. O exemplo de política a seguir é para um administrador que pode gerenciar servidores de recursos IdPs, clientes de aplicativos e o domínio do grupo de usuários, mas não usuários ou o grupo de usuários.
O exemplo de política a seguir concede gerenciamento e autenticação de usuários e grupos a uma aplicação do lado do servidor.
Proteger e verificar os tokens
Os tokens podem conter referências internas à associação ao grupo e aos atributos do usuário que talvez você não queira divulgar ao usuário final. Não armazene tokens de ID e acesso no armazenamento local. Os tokens de atualização são criptografados com uma chave que somente seu grupo de usuários pode acessar e não são visíveis para usuários e aplicações. Revogue os tokens de atualização quando os usuários saírem ou quando você determinar que a persistência da sessão de um usuário é indesejada por motivos de segurança.
Use tokens de acesso para autorizar o acesso somente a sistemas que verifiquem de modo independente se o token é válido e não está expirado. Para obter recursos de verificação, consulte Verificar um token web JSON.
Determinar os provedores de identidades de confiança
Ao configurar seu grupo de usuários com provedores de identidade SAML ou OIDC (IdPs), você IdPs pode criar novos usuários, definir atributos de usuário e acessar os recursos do aplicativo. Os provedores de SAML e OIDC são normalmente usados em cenários business-to-business (B2B) ou corporativos em que você ou seu cliente imediato controlam a associação e a configuração do provedor.
Os provedores sociais oferecem contas de usuário para qualquer pessoa na internet e estão menos sob seu controle do que os provedores corporativos. Ative as redes sociais IdPs em seu cliente de aplicativo somente quando estiver pronto para permitir que clientes públicos façam login e acessem recursos em seu aplicativo.
Entender o efeito dos escopos no acesso aos perfis de usuário
Você pode solicitar escopos de controle de acesso em suas solicitações de autenticação para o servidor de autorização do grupo de usuários. Esses escopos podem conceder aos usuários acesso a recursos externos e acesso para ver e modificar os próprios perfis dos usuários. Configure seus clientes de aplicação para oferecer suporte aos escopos mínimos necessários para a operação da aplicação.
O aws.cognito.signin.user.admin escopo está presente em todos os tokens de acesso emitidos pela autenticação do SDK com operações como InitiateAuth. Ele é designado para operações de autoatendimento de perfil de usuário em sua aplicação. Também é possível solicitar esse escopo no servidor de autorização. Esse escopo é necessário para operações autorizadas por tokens, como e. UpdateUserAttributesGetUser O efeito dessas operações é limitado pelas permissões de leitura e gravação do seu cliente da aplicação.
Os escopos openid, profile, email e phone autorizam solicitações para o endpoint userinfo em seu servidor de autorização do grupo de usuários. Eles definem os atributos que o endpoint pode retornar. O escopo openid, quando solicitado sem outros escopos, retorna todos os atributos disponíveis, mas quando você solicita mais escopos na solicitação, a resposta é reduzida aos atributos representados pelos escopos adicionais. O escopo openid também indica uma solicitação de um token de ID; quando você omite esse escopo da sua solicitação para o seu Autorizar endpoint, o Amazon Cognito emite somente um token de acesso e, quando aplicável, um token de atualização. Para obter mais informações, consulte Escopos do OpenID Connect em Termos do cliente da aplicação.
Limpar as entradas para os atributos do usuário
Os atributos do usuário que podem acabar como métodos de entrega e nomes de usuário, por exemplo email, têm restrições de formato. Outros atributos podem ter tipos de dados de string, booleanos ou numéricos. Os valores dos atributos de cadeia de caracteres são compatíveis com uma variedade de entradas. Configure sua aplicação para se proteger contra tentativas de gravar dados indesejados em seu diretório de usuários ou nas mensagens que o Amazon Cognito entrega aos usuários. Realize a validação do lado do cliente dos valores de atributos de string enviados pelo usuário em sua aplicação antes de enviá-los para o Amazon Cognito.
Os grupos de usuários mapeiam atributos do IdPs seu grupo de usuários com base em um mapeamento de atributos que você especifica. Mapeie somente atributos de IdP seguros e previsíveis para atributos de string do grupo de usuários.
