# Gerenciamento de identidade e acesso
Para usar os serviços da AWS, é necessário conceder aos usuários e aplicações acesso a recursos em suas contas da AWS. À medida que executa mais workloads na AWS, você precisa de gerenciamento de identidade robusto e de permissões implementadas para garantir que as pessoas certas tenham acesso aos recursos certos nas condições certas. A AWS oferece uma grande variedade de recursos para ajudar a gerenciar identidades humanas e de máquinas e suas permissões. As práticas recomendadas para esses recursos se encaixam em duas áreas principais.
**Topics**
+ [Gerenciamento de identidades](identity-management.md)
+ [Gerenciamento de permissões](permissions-management.md)
# Gerenciamento de identidades
Há dois tipos de identidades que você precisa gerenciar ao abordar a operação de workloads seguros da AWS.
+ **Identidades humanas:** as identidades humanas que exigem acesso aos ambientes e aplicações da AWS podem ser categorizadas em três grupos: força de trabalho, terceiros e usuários.
O grupo *força de trabalho* inclui administradores, desenvolvedores e operadores que são membros da sua organização. Eles precisam de acesso para gerenciar, criar e operar os recursos da AWS.
*Terceiros* são colaboradores externos, como prestadores de serviços, fornecedores ou parceiros. Eles interagem com os recursos da AWS como parte do engajamento com a organização.
Os *usuários* são os consumidores das aplicações. Eles acessam os recursos da AWS por meio de um navegador da web, aplicações-cliente, aplicativos móveis ou ferramentas interativas de linha de comandos.
+ **Identidades de máquina:** suas aplicações de workload, ferramentas operacionais e componentes precisam de uma identidade para solicitar serviços da AWS, como ler dados. Essas identidades também incluem máquinas em execução no ambiente da AWS, como instâncias do Amazon EC2 ou funções do AWS Lambda. Você também pode gerenciar identidades de máquina para partes externas, ou máquinas fora da AWS, que exigem acesso ao seu ambiente da AWS.
**Topics**
+ [SEC02-BP01 Usar mecanismos de início de sessão fortes](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md)
+ [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md)
+ [SEC02-BP04 Confiar em um provedor de identidades centralizado](sec_identities_identity_provider.md)
+ [SEC02-BP05 Auditar e fazer a rotação das credenciais periodicamente](sec_identities_audit.md)
+ [SEC02-BP06 Utilizar grupos de usuários e atributos](sec_identities_groups_attributes.md)
# SEC02-BP01 Usar mecanismos de início de sessão fortes
Os inícios de sessão (autenticação com credenciais de login) podem apresentar riscos quando não são usados mecanismos, como autenticação multifator (MFA), especialmente em situações em que as credenciais de login foram divulgadas acidentalmente ou podem ser deduzidas com facilidade. Utilize mecanismos de início de sessão fortes para reduzir essas riscos exigindo MFA e políticas de senhas fortes.
**Resultado desejado:** reduzir os riscos de acesso não intencional às credenciais na AWS usando mecanismos de login robustos para usuários do [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), o [usuário-raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), o [Centro de Identidade do AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) e provedores de identidade terceirizados. Isso significa exigir MFA, impor políticas de senhas fortes e detectar comportamento de login anômalo.
**Práticas comuns que devem ser evitadas:**
+ Não impor uma política de senhas fortes para suas identidades incluindo senhas complexas e MFA.
+ Compartilhar as mesmas credenciais entre usuários diferentes.
+ Não utilizar controles de detecção para logins suspeitos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Há muitas maneiras pelas quais identidades humanas podem iniciar sessão na AWS. É prática recomendada da AWS confiar em um provedor de identidades centralizado utilizando federação (federação direta SAML 2.0 entre o AWS IAM e o IdP centralizado, ou usando o Centro de Identidade do AWS IAM) ao realizar a autenticação na AWS. Nesse caso, estabeleça um processo de início de sessão seguro com o provedor de identidades ou o Microsoft Active Directory.
Ao abrir pela primeira vez uma Conta da AWS, você começa com um usuário-raiz da Conta da AWS. Você só deve usar o usuário-raiz da conta para configurar o acesso para seus usuários (e para [tarefas que exijam o usuário-raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)). É importante ativar a autenticação multifator (MFA) para o usuário-raiz da conta imediatamente após abrir sua Conta da AWS e proteger o usuário-raiz usando o guia de [práticas recomendadas da AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html).
O Centro de Identidade do AWS IAM foi projetado para usuários da força de trabalho, e você pode criar e gerenciar identidades de usuários dentro do serviço e proteger o processo de login com MFA. O AWS Cognito, por outro lado, foi projetado para gerenciamento de identidade e acesso de clientes (CIAM), que fornece grupos de usuários e provedores de identidades para usuários externos nas aplicações.
Se você criar usuários no Centro de Identidade do AWS IAM, proteja o processo de início de sessão nesse serviço e [ative a MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html). Para identidades de usuários externos, é possível usar [grupos de usuários do Amazon Cognito](https://docs.aws.amazon.com/cognito/index.html) e proteger o processo de início de sessão nesse serviço ou usar um dos provedores de identidades compatíveis com os grupos de usuários do Amazon Cognito.
Além disso, para usuários do Centro de Identidade do AWS IAM, você pode usar o [Acesso Verificado pela AWS](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) para fornecer uma camada adicional de segurança, verificando a identidade do usuário e a postura do dispositivo antes que tenha acesso aos recursos da AWS.
Se você estiver utilizando usuários do [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), proteja o processo de início de sessão usando o IAM.
Você pode usar o Centro de Identidade do AWS IAM e a federação direta do IAM simultaneamente para gerenciar o acesso à AWS. É possível usar a federação do IAM para gerenciar o acesso ao Console de gerenciamento da AWS e aos serviços e o Centro de Identidade do IAM para gerenciar o acesso a aplicações empresariais, como o Quick ou o Amazon Q Business.
Seja qual for o método de início de sessão, é essencial impor uma política de login forte.
### Etapas de implementação
Veja a seguir as recomendações gerais de início de sessão forte. As configurações reais que você configurar deverão ser definidas pela política da sua empresa ou usar um padrão como o [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html).
+ Solicite a MFA. É [prática recomendada do IAM exigir MFA para](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) identidades humanas e workloads. A ativação da MFA oferece uma camada adicional de segurança que exige que os usuários forneçam credenciais de início de sessão e uma senha de uso único (OTP) ou uma string gerada e verificada criptograficamente por um dispositivo de hardware.
+ Imponha um comprimento mínimo de senha, que é um fator essencial da força da senha.
+ Imponha complexidade para tornar as senhas mais difíceis de deduzir.
+ Permitir que os usuários troquem suas próprias senhas.
+ Crie identidades individuais em vez de credenciais compartilhadas. Com a criação de identidades individuais, é possível fornecer a cada usuário um conjunto exclusivo de credenciais de segurança. Os usuários individuais oferecem a capacidade de auditar a atividade de cada usuário.
Recomendações do Centro de Identidade do IAM:
+ O Centro de Identidade do IAM fornece uma [política de senha](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) predefinida ao usar o diretório padrão que estabelece o tamanho, a complexidade e os requisitos de reutilização da senha.
+ [Ative o MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) e defina a configuração contextual ou sempre ativa do MFA quando a fonte de identidade for o diretório padrão, o AWS Managed Microsoft AD ou o AD Connector.
+ Permita que os usuários [registrem seus próprios dispositivos de MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html).
Recomendações do diretório de grupos de usuários do Amazon Cognito:
+ Configure as opções de [força da senha](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html).
+ [Exija MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) para os usuários.
+ Use as [configurações de segurança avançadas](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) dos grupos de usuários do Amazon Cognito para recursos como a [autenticação adaptativa](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html), a qual pode bloquear logins suspeitos.
Recomendações para usuários do IAM:
+ Em teoria, você está utilizando Centro de Identidade do IAM ou federação direta. No entanto, talvez você precise de usuários do IAM. Nesse caso, [defina uma política de senhas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) para usuários do IAM. A política de senhas pode ser usada para definir requisitos como extensão mínima ou a obrigatoriedade de uso de caracteres não alfabéticos.
+ Crie uma política do IAM para [impor o início de sessão com MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) para que os usuários possam gerenciar suas próprias senhas e dispositivos de MFA.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP03 Armazenar e usar segredos com segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 Confiar em um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Compartilhar recursos com segurança em sua organização](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documentos relacionados:**
+ [Política de senhas do Centro de Identidade do AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [Política de senhas de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Definir da senha do usuário-raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Política de senhas do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [Credenciais da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [Práticas recomendadas de segurança do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
**Vídeos relacionados:**
+ [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E)
+ [Como dominar a identidade em cada camada do bolo](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP02 Usar credenciais temporárias
Ao realizar qualquer tipo de autenticação, é melhor utilizar credenciais temporárias em vez de credenciais de longo prazo a fim de reduzir ou eliminar riscos como credenciais que são divulgadas acidentalmente, compartilhadas ou roubadas.
**Resultado desejado:** para reduzir o risco de credenciais de longo prazo, use credenciais temporárias sempre que possível para identidades humanas e de máquinas. Credenciais de longo prazo criam muitos riscos, como exposição por meio de uploads para repositórios públicos. Ao utilizar credenciais temporárias, você reduz significativamente as chances de comprometimento das credenciais.
**Práticas comuns que devem ser evitadas:**
+ Desenvolvedores que usam chaves de acesso de longo prazo de usuários do IAM em vez de obter credenciais temporárias da CLI usando federação.
+ Desenvolvedores que incorporam chaves de acesso de longo prazo no código e fazem upload desse código para repositórios públicos do Git.
+ Desenvolvedores que incorporam chaves de acesso de longo prazo em aplicações móveis que, depois, são disponibilizadas em lojas de aplicações.
+ Usuários que compartilham chaves de acesso de longo prazo com outros usuários ou funcionários que deixam a empresa e não devolvem as chaves de acesso de longo prazo.
+ Utilizar chaves de acesso de longo prazo para identidades de máquina quando é possível usar credenciais temporárias.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Utilize credenciais de segurança temporárias em vez de credenciais de longo prazo para todas as solicitações à AWS API e CLI. As solicitações de API e CLI para serviços da AWS devem, em quase todos os casos, ser assinadas usando [chaves de acesso da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). Essas solicitações podem ser assinadas com credenciais temporárias ou de longo prazo. A única vez em que você deve usar credenciais de longo prazo, também conhecidas como chaves de acesso de longo prazo, é se estiver usando um [usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) ou o [usuário-raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html). Quando você se federa à AWS ou assume um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) por meio de outros métodos, credenciais temporárias são geradas. Mesmo quando você acessa o Console de gerenciamento da AWS utilizando credenciais de login, credenciais temporárias são geradas para você fazer chamadas para serviços da AWS. Há poucas situações nas quais você precisa de credenciais de longo prazo, e é possível realizar quase todas as tarefas usando credenciais temporárias.
Evitar o uso de credenciais de longo prazo em favor de credenciais temporárias deve andar lado a lado com uma estratégia de reduzir o uso de usuários do IAM em favor da federação e de perfis do IAM. Embora usuários do IAM tenham sido usados para identidades humanas e de máquina no passado, agora recomendamos não utilizá-los para evitar os riscos de utilizar chaves de acesso de longo prazo.
### Etapas de implementação
#### Identidades humanas
Para identidades da força de trabalho, como funcionários, administradores, desenvolvedores e operadores:
+ Recomenda-se [confiar em um provedor de identidade centralizado](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) e [exigir que os usuários humanos usem federação com um provedor de identidades para acessar a AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp). A federação para os usuários pode ser feita com [federação direta para cada Conta da AWS](https://aws.amazon.com/identity/federation/) ou usando o [Centro de Identidade do AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) e um provedor de identidades escolhido por você. A federação oferece uma série de vantagens em comparação com a utilização de usuários do IAM que vão além de eliminar credenciais de longo prazo. Seus usuários também podem solicitar credenciais temporárias na linha de comando para [federação direta](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) ou usando o [Centro de Identidade do IAM](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Isso significa que há poucos casos de uso que exigem usuários do IAM ou credenciais de longo prazo para seus usuários.
Para identidades de terceiros:
+ Ao conceder a terceiros, como provedores de software como serviço (SaaS), acesso aos recursos em sua Conta da AWS, você pode [usar funções entre contas](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) e [políticas baseadas em recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). Além disso, você pode usar o fluxo de credenciais de [concessão do Amazon Cognito OAuth 2.0](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html) para clientes ou parceiros de SaaS B2B.
Identidades de usuários que acessam os recursos da AWS por meio de um navegador da web, aplicações-cliente, aplicativos móveis ou ferramentas interativas de linha de comandos:
+ Se precisar conceder às aplicações para consumidores ou clientes acesso aos seus recursos da AWS, você pode usar [bancos de identidades do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) ou [grupos de usuários do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) para fornecer credenciais temporárias. As permissões para as credenciais são configuradas por meio dos perfis do IAM. Você também pode definir uma função do IAM separada com permissões limitadas para usuários convidados que não são autenticados.
#### Identidades de máquina
Para identidades de máquina, talvez seja necessário utilizar credenciais de longo prazo. Nesses casos, [exija que as workloads usem credenciais temporárias com perfis do IAM para acessar a AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles).
+ Para o [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), é possível usar [perfis para o Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).
+ O [AWS Lambda](https://aws.amazon.com/lambda/) permite configurar um [perfil de execução do Lambda para conceder ao serviço permissões](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) para realizar ações AWS usando credenciais temporárias. Há muitos outros modelos semelhantes para os serviços da AWS concederem credenciais temporárias utilizando perfis do IAM.
+ Para dispositivos de IoT, você pode usar o [provedor de credenciais do AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) para solicitar credenciais temporárias.
+ Para sistemas on-premises ou sistemas que funcionam fora da AWS e que precisam de acesso a recursos da AWS, é possível usar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html).
Há cenários em que credenciais temporárias não são compatíveis, o que exige o uso de credenciais de longo prazo. Nessas situações, [audite e alterne essas credenciais periodicamente](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) e [alterne as chaves de acesso regularmente](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials). Para chaves de acesso de usuário do IAM altamente restritas, considere as seguintes medidas de segurança adicionais:
+ Conceda permissões altamente restritas:
+ Siga o princípio do privilégio mínimo (seja específico sobre ações, recursos e condições).
+ Considere conceder ao usuário do IAM somente a operação AssumeRole para uma função específica. Dependendo da arquitetura on-premises, essa abordagem ajuda a isolar e proteger as credenciais de longo prazo do IAM.
+ Limite as fontes de rede e os endereços IP permitidos na política de confiança do perfil do IAM.
+ Monitore o uso e configure alertas para permissões não utilizadas ou uso indevido (usando filtros métricos e alarmes do AWS CloudWatch Logs).
+ Imponha [limites de permissão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) (políticas de controle de serviço (SCPs) e limites de permissão se complementam — os SCPs são granulares, enquanto os limites de permissão são refinados).
+ Implemente um processo para provisionar e armazenar com segurança (em um cofre on-premises) as credenciais.
Algumas outras opções para cenários que exigem credenciais de longo prazo incluem:
+ Crie sua própria API de venda de tokens (usando o Amazon API Gateway).
+ Para cenários em que você precisa usar credenciais de longo prazo, ou para credenciais que não sejam chaves de acesso da AWS (como logins de bancos de dados), é possível usar um serviço projetado para lidar com o gerenciamento de segredos, como o [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/). O Secrets Manager simplifica o gerenciamento, a rotação e o armazenamento seguro de segredos criptografados. Muitos serviços da AWS oferecem suporte à [integração direta](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html) com o Secrets Manager.
+ Para integrações multinuvem, você pode usar a federação de identidades com base nas credenciais do provedor de serviços de credenciais (CSP) de origem (consulte [AWS STS AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)).
Para obter mais informações sobre a mudança de credenciais de longo prazo, consulte a mudança de [chaves de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP03 Armazenar e usar segredos com segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 Confiar em um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Compartilhar recursos com segurança em sua organização](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documentos relacionados:**
+ [Credenciais de segurança temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS Credenciais da](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [Práticas recomendadas de segurança do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
+ [Centro de Identidade do IAM](https://aws.amazon.com/iam/identity-center/)
+ [Provedores de identidade e federação](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Fazer a rotação das chave de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)
+ [Soluções para parceiros de segurança: acesso e controle](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [O usuário-raiz da conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Acesse AWS usando uma identidade de workload nativa do Google Cloud Platform](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/)
+ [How to access AWS resources from Microsoft Entra ID tenants using AWS Security Token Service](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/)
**Vídeos relacionados:**
+ [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E)
+ [Como dominar a identidade em cada camada do bolo](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP03 Armazenar e usar segredos com segurança
Uma workload exige um recurso automatizado para comprovar a identidade dela em bancos de dados, recursos e serviços de terceiros. Isso é feito com o uso de credenciais de acesso secretas, como chaves de acesso de API, senhas e tokens do OAuth. Utilizar um serviço com propósito específico para armazenar, gerenciar e fazer a rotação de credenciais ajuda a reduzir a probabilidade de comprometimento dessas credenciais.
**Resultado desejado:** implementar um mecanismo para gerenciar com segurança credenciais da aplicação que atinja as seguintes metas:
+ Identificar quais segredos são necessários para a workload.
+ Reduzir o número de credenciais de longo prazo necessárias substituindo-as por credenciais de curto prazo quando possível.
+ Estabelecer um armazenamento seguro e uma rotação automatizada das credenciais de longo prazo restantes.
+ Auditar o acesso aos segredos existentes na workload.
+ Monitorar continuamente para confirmar que nenhum segredo seja incorporado ao código-fonte durante o processo de desenvolvimento.
+ Reduzir a probabilidade de divulgação acidental de credenciais.
**Práticas comuns que devem ser evitadas:**
+ Ausência de rotação de credenciais.
+ Armazenar credenciais de longo prazo em código-fonte ou arquivos de configuração.
+ Armazenar credenciais em repouso não criptografadas.
**Benefícios de implementar esta prática recomendada:**
+ Os segredos são armazenados com criptografia em repouso e em trânsito.
+ O acesso às credenciais é controlado por meio de uma API (pense nisso como uma *máquina de venda automática de credenciais*).
+ O acesso a uma credencial (de leitura e gravação) é auditado e registrado.
+ Separação de preocupações: a rotação de credenciais é realizada por um componente separado que pode ser segregado do restante da arquitetura.
+ Os segredos são automaticamente distribuídos sob demanda em componentes de software e a rotação ocorre em um local central.
+ O acesso às credenciais pode ser controlado de forma detalhada.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
No passado, as credenciais usadas para realizar a autenticação em bancos de dados, APIs de terceiros, tokens e outros segredos podiam ser incorporadas em código-fonte ou em arquivos do ambiente. A AWS oferece vários mecanismos para armazenar essas credenciais com segurança, alterná-las automaticamente e auditar o uso delas.
A melhor forma de abordar o gerenciamento de segredos é seguir as orientações de remover, substituir e fazer a rotação. A credencial mais segura é a que você não precisa armazenar, gerenciar nem processar. Pode haver credenciais que não sejam mais necessárias ao funcionamento da workload que podem ser removidas com segurança.
Para credenciais que ainda são necessárias ao funcionamento adequado da workload, pode haver uma oportunidade de substituir uma credencial de longo prazo por uma credencial temporária ou de curto prazo. Por exemplo, em vez de codificar uma chave de acesso secreta da AWS, considere substituir essa credencial de longo prazo por uma temporária utilizando perfis do IAM.
Em algumas situações, talvez alguns segredos de longa duração não possam removidos ou substituídos. Esses segredos podem ser armazenados em um serviço, como o [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), onde podem ser armazenados, gerenciados e ter a rotação feita centralmente de tempos em tempos.
Uma auditoria do código-fonte da workload e os arquivos de configuração podem revelar muitos tipos de credencial. A seguinte tabela resume as estratégias para lidar com tipos comuns de credenciais:
| Tipo de credencial | Descrição | Estratégia sugerida |
| --- | --- | --- |
| Chaves de acesso ao IAM | Chaves secretas e de acesso do AWS IAM usadas para assumir perfis do IAM dentro de uma workload | Substitua: em vez disso, use [perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html) atribuídos às instâncias de computação (como [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) ou [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)). Para interoperabilidade com terceiros que precisam de acesso a recursos em sua Conta da AWS, pergunte se eles oferecem suporte ao [acesso entre contas da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html). Para aplicações móveis, considere usar credenciais temporárias nos [bancos de identidades do Amazon Cognito (identidades federadas](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)). Para workloads executadas fora da AWS, considere o usar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) ou o [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). Para contêineres, consulte [Perfil do IAM para tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) ou [Perfil do IAM em nós do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html). |
| Chaves SSH | Chaves privadas do Secure Shell usadas para fazer login em instâncias do EC2 Linux, manualmente ou como parte de um processo automatizado | Substitua: use o [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) ou o [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) para fornecer acesso programático e humano às instâncias do EC2 usando perfis do IAM. |
| Credenciais de aplicações e bancos de dados | Senhas: sequência de texto simples | Rotação: armazene as credenciais no [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) e estabeleça a rotação automática, se possível. |
| Credenciais do Amazon RDS e do Aurora Admin Database | Senhas: sequência de texto simples | Substitua: use a [integração do Secrets Manager com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) ou o [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html). Além disso, alguns tipos de banco de dados do RDS podem usar perfis do IAM em vez de senhas para alguns casos de uso (para obter mais detalhes, consulte [Autenticação de banco de dados do IAM](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)). |
| Tokens OAuth | Tokens secretos: sequência de texto simples | Rotação: armazene tokens no [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) e configure a rotação automática. |
| Chaves e tokens de API | Tokens secretos: sequência de texto simples | Rotação: armazene no [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) e estabeleça a rotação automática, se possível. |
Um prática não recomendada comum é incorporar chaves de acesso do IAM a código-fonte, arquivos de configuração ou aplicações móveis. Quando uma chave de acesso do IAM for necessária para se comunicar com um serviço da AWS, use [credenciais de segurança temporárias (de curto prazo)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html). Essas credenciais de curto prazo podem ser fornecidas por meio de [perfis do IAM para instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), [funções de execução](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) para funções Lambda, [perfis do IAM do Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) para acesso de usuários móveis e [políticas do IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) para dispositivos de IoT. Ao interagir com terceiros, prefira [delegar acesso a um perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) com o acesso necessário aos recursos da sua conta em vez de configurar um usuário do IAM e enviar para terceiros a chave de acesso secreta desse usuário.
Há muitos casos em que a workload exige o armazenamento dos segredos necessários para interoperar com outros serviços e recursos. O [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) foi criado especificamente para gerenciar com segurança essas credenciais, bem como o armazenamento, o uso e a rotação de tokens de API, senhas e outras credenciais.
O AWS Secrets Manager oferece cinco recursos principais para garantir o armazenamento e o manuseio seguros de credenciais confidenciais: [criptografia em repouso](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [criptografia em trânsito](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [auditoria abrangente](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [controle de acesso refinado](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) e [rotação extensível de credenciais](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). Outros serviços de gerenciamento de segredos de parceiros da AWS ou soluções desenvolvidas localmente que oferecem recursos e garantias semelhantes também são aceitáveis.
Ao recuperar um segredo, é possível usar os componentes de cache do lado do cliente do Secrets Manager a fim de armazená-lo em cache para uso futuro. Recuperar um segredo armazenado em cache é mais rápido do que recuperá-lo do Secrets Manager. Além disso, como há um custo para chamar APIs do Secrets Manager, usar um cache pode reduzir os custos. Para ver todas as formas pelas quais você pode recuperar segredos, consulte [Obter segredos](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html).
**nota**
Algumas linguagens podem exigir que você implemente sua própria criptografia na memória para o armazenamento em cache do lado do cliente.
### Etapas de implementação
1. Identifique caminhos de código contendo credenciais codificadas usando ferramentas automatizadas, como o [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/).
1. Utilize o Amazon CodeGuru para verificar seus repositórios de código. Quando a revisão estiver concluída, filtre Type=Secrets no CodeGuru para encontrar linhas de código problemáticas.
1. Identifique credenciais que possam ser removidas ou substituídas.
1. Identifique credenciais não mais necessárias e marque-as para remoção.
1. Para chaves secretas da AWS incorporadas ao código-fonte, substitua-as por perfis do IAM associados aos recursos necessários. Se parte da sua workload for externa à AWS, mas exigir credenciais do IAM para acessar os recursos da AWS, considere usar o [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) ou o [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).
1. Para outros segredos duradouros de terceiros que exijam o uso da estratégia de rotação, integre o Secrets Manager ao seu código para recuperar segredos de terceiros em tempo de execução.
1. O console do CodeGuru pode criar [automaticamente um segredo no Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) usando as credenciais descobertas.
1. Integre a recuperação de segredos do Secrets Manager ao código da sua aplicação.
1. As funções do Lambda sem servidor podem usar uma [extensão do Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) independente de linguagem.
1. Para instâncias ou contêineres do EC2, a AWS fornece exemplos de [código do lado do cliente para recuperar segredos do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) em várias linguagens de programação populares.
1. Revise periodicamente sua base de código e verifique novamente para confirmar se não há novos segredos adicionados ao código.
1. Considere usar uma ferramenta como [git-secrets](https://github.com/awslabs/git-secrets) para evitar a confirmação de novos segredos em seu repositório de código-fonte.
1. [Monitore a atividade do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) em busca de indicações de uso inesperado, acesso inadequado a segredos ou tentativas de exclusão de segredos.
1. Reduza a exposição humana às credenciais. Restrinja o acesso a credenciais de leitura, gravação e modificação a um perfil do IAM dedicado a esse fim, e apenas forneça acesso para assumir o perfil a um pequeno subconjunto de usuários operacionais.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP02 Usar credenciais temporárias](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP05 Auditar e fazer a rotação das credenciais periodicamente](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)
**Documentos relacionados:**
+ [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Provedores de identidade e federação](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Amazon CodeGuru apresenta o detector de segredos](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)
+ [Como o AWS Secrets Manager usa o AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html).
+ [Criptografia e descriptografia de segredos no Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ [Entradas de blog do Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/)
+ [Amazon RDS anuncia integração com AWS Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/)
**Vídeos relacionados:**
+ [Práticas recomendadas para gerenciar, recuperar e fazer a rotação de segredos em escala](https://youtu.be/qoxxRlwJKZ4)
+ [Encontrar segredos codificados com o detector de segredos do Amazon CodeGuru](https://www.youtube.com/watch?v=ryK3PN--oJs)
+ [Proteger segredos para workloads híbridas usando o AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8)
**Workshops relacionados:**
+ [Armazenar, recuperar e gerenciar credenciais confidenciais no AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US)
+ [AWSAtivações híbridas do Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html)
# SEC02-BP04 Confiar em um provedor de identidades centralizado
Para identidades da força de trabalho (funcionários e prestadores de serviços), confie em um provedor de identidade que permita gerenciar identidades em um local centralizado. Isso facilita o gerenciamento do acesso em várias aplicações e sistemas, pois você está criando, atribuindo, gerenciando, revogando e auditando o acesso de um único local.
**Resultado desejado:** você tem um provedor de identidade centralizado no qual gerencia centralmente os usuários da força de trabalho, as políticas de autenticação (como a exigência de autenticação multifator (MFA)) e a autorização para sistemas e aplicações (como atribuir acesso com base na associação ou nos atributos do grupo de um usuário). Os usuários da sua força de trabalho fazem login no provedor de identidade central e se federam (autenticação única) a aplicações internas e externas, eliminando a necessidade de os usuários se lembrarem de várias credenciais. Seu provedor de identidade é integrado aos seus sistemas de recursos humanos (RH) para que as mudanças de pessoal sejam automaticamente sincronizadas com seu provedor de identidade. Por exemplo, se alguém deixar sua organização, você poderá revogar automaticamente o acesso a aplicações e sistemas federados (inclusive a AWS). Você habilitou o registro em log detalhado de auditoria em seu provedor de identidade e está monitorando esses logs em busca de comportamentos incomuns do usuário.
**Práticas comuns que devem ser evitadas:**
+ Você não usa federação e autenticação única. Os usuários da sua força de trabalho criam contas de usuário e credenciais separadas em várias aplicações e sistemas.
+ Você não automatizou o ciclo de vida das identidades dos usuários da força de trabalho, por exemplo, integrando seu provedor de identidade aos seus sistemas de RH. Quando um usuário deixa sua organização ou muda de função, você segue um processo manual para excluir ou atualizar seus registros em várias aplicações e sistemas.
**Benefícios de implementar esta prática recomendada:** ao usar um provedor de identidades centralizado, você tem um único local para gerenciar as identidades e políticas dos usuários da força de trabalho, a capacidade de atribuir acesso às aplicações a usuários e grupos e a capacidade de monitorar a atividade de login do usuário. Ao se integrar aos seus sistemas de recursos humanos (RH), quando um usuário muda de função, essas alterações são sincronizadas com o provedor de identidade e atualizam automaticamente as aplicações e permissões atribuídas. Quando um usuário sai da sua organização, sua identidade é automaticamente desativada no provedor de identidade, revogando seu acesso a aplicações e sistemas federados.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
**Orientação para usuários da força de trabalho que acessam a AWS:** os usuários da força de trabalho na organização, como funcionários e prestadores de serviços, podem precisar acessar a AWS usando o Console de gerenciamento da AWS ou a AWS Command Line Interface (AWS CLI) para desempenhar suas funções de trabalho. Você pode conceder acesso à AWS aos usuários da sua força de trabalho federando a partir de seu provedor de identidade centralizado para a AWS em dois níveis: federação direta para cada Conta da AWS ou federação para várias contas em sua [organização da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html).
Para federar os usuários da sua força de trabalho diretamente com cada Conta da AWS, é possível usar um provedor de identidade centralizado para federar o [AWS Identity and Access Management](https://aws.amazon.com/iam/) na conta em questão. A flexibilidade do IAM permite que você habilite um [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) ou um provedor de identidade [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) separado para cada Conta da AWS e atributos de usuário federados para controle de acesso. Os usuários da sua força de trabalho usarão o navegador da Web para fazer login no provedor de identidade fornecendo suas respectivas credenciais (como senhas e códigos de token MFA). O provedor de identidade emite uma declaração SAML para o navegador, que é enviada ao URL de login do Console de gerenciamento da AWS para permitir que o usuário faça autenticação única no [Console de gerenciamento da AWS assumindo um perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Seus usuários também podem obter credenciais da API da AWS temporárias para uso no [AWS CLI](https://aws.amazon.com/cli/) ou [AWS SDKs](https://aws.amazon.com/developer/tools/) do [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) [assumindo o perfil do IAM usando uma declaração SAML do provedor de identidade](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html).
Para federar os usuários da sua força de trabalho com várias contas em sua organização da AWS, é possível usar o [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) para gerenciar centralmente o acesso dos usuários a Contas da AWS e aplicações. Você ativa o Identity Center para sua organização e configura sua fonte de identidade. O IAM Identity Center fornece um diretório de origem de identidade padrão que você pode usar para gerenciar seus usuários e grupos. Como alternativa, você pode escolher uma fonte de identidade externa [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) usando SAML 2.0 e [provisionando automaticamente](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) usuários e grupos usando o SCIM ou conectando-se [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) usando o [Directory Service](https://aws.amazon.com/directoryservice/). Depois que uma fonte de identidade é configurada, você pode atribuir acesso a usuários e grupos a Contas da AWS definindo políticas de privilégios mínimos em seus [conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Os usuários da sua força de trabalho podem se autenticar por meio de seu provedor de identidade central para entrar no [portal de acesso da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) e fazer login único nas aplicações em nuvem atribuídas a Contas da AWS eles. Este tópico descreve como configurar a [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) para autenticar o usuário com o Centro de Identidade e obter credenciais para executar comandos da AWS CLI. O Centro de Identidade também permite acesso com login único a aplicações da AWS, como o [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) e os [portais do AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html).
Depois de seguir as orientações anteriores, os usuários da sua força de trabalho não precisarão mais utilizar usuários e grupos do IAM para operações normais ao gerenciar workloads na AWS. Em vez disso, seus usuários e grupos serão gerenciados fora da AWS e os usuários poderão acessar recursos da AWS como *identidade federada*. As identidades federadas usam os grupos definidos pelo seu provedor de identidade centralizado. Você deve identificar e remover grupos do IAM, usuários do IAM e credenciais de usuário de longa duração (senhas e chaves de acesso) que não são mais necessárias nas suas Contas da AWS. Você pode [encontrar credenciais não utilizadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) usando [relatórios de credenciais do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [excluir os usuários do IAM correspondentes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) e [excluir grupos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html). Você pode aplicar uma [Política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) à sua organização que ajuda a impedir a criação de novos usuários e grupos do IAM, impondo esse acesso à AWS por meio de identidades federadas.
**nota**
Você é responsável por lidar com a rotação dos tokens de acesso do SCIM, conforme descrito na documentação de [provisionamento automático](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html). Além disso, você é responsável pela rotação dos certificados que oferecem suporte à federação de identidades.
**Orientação para os usuários das aplicações:** você pode gerenciar as identidades dos usuários das aplicações, como um aplicativo móvel, usando o [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) como provedor de identidades centralizado. O Amazon Cognito habilita a autenticação, autorização e gerenciamento de usuários para suas aplicações Web e móveis. O Amazon Cognito fornece um armazenamento de identidades que pode ser escalado para milhões de usuários, oferece suporte à federação de identidades sociais e corporativas e oferece recursos avançados de segurança para ajudar a proteger seus usuários e negócios. É possível integrar sua aplicação Web ou móvel personalizada ao Amazon Cognito para adicionar autenticação de usuário e controle de acesso a suas aplicações em minutos. Desenvolvido com base em padrões de identidade abertos, como SAML e Open ID Connect (OIDC), o Amazon Cognito oferece suporte a vários regulamentos de conformidade e se integra aos recursos de desenvolvimento de frontend e backend.
### Etapas de implementação
**Etapas para usuários da força de trabalho acessarem a AWS**
+ Federe os usuários da sua força de trabalho à AWS usando um provedor de identidade centralizado de acordo com uma das seguintes abordagens:
+ Use o Centro de Identidade do IAM para habilitar a autenticação única para várias Contas da AWS em sua organização da AWS via federação com seu provedor de identidade.
+ Use o IAM para conectar seu provedor de identidade diretamente a cada Conta da AWS, permitindo acesso federado refinado.
+ Identifique e remova usuários e grupos do IAM que são substituídos por identidades federadas.
**Etapas para usuários das suas aplicações**
+ Use o Amazon Cognito como um provedor de identidades centralizado para suas aplicações.
+ Integre suas aplicações personalizadas com o Amazon Cognito usando o OpenID Connect e o OAuth. Você pode desenvolver suas aplicações personalizadas usando as bibliotecas do Amplify que fornecem interfaces simples para integração com uma variedade de serviços da AWS, como o Amazon Cognito para autenticação.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP06 Utilizar grupos de usuários e atributos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html)
+ [SEC03-BP02 Conceder acesso de privilégio mínimo](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
**Documentos relacionados:**
+ [Federação de identidades na AWS](https://aws.amazon.com/identity/federation/)
+ [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Práticas recomendadas do AWS Identity and Access Management](https://aws.amazon.com/iam/resources/best-practices/)
+ [Conceitos básicos da administração delegada no Centro de Identidade do IAM](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/)
+ [Como usar políticas gerenciadas pelo cliente no Centro de Identidade do IAM para casos de uso avançados](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/)
+ [AWS CLI v2: fornecedor de credenciais do Centro de Identidade do IAM](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html)
**Vídeos relacionados:**
+ [AWS re:Inforce 2022: Mergulho profundo no AWS Identity and Access Management (IAM)](https://youtu.be/YMj33ToS8cI)
+ [AWS re:Invent 2022: Simplificar o acesso da sua força de trabalho com o Centro de Identidade do IAM](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Invent 2018: Dominar a identidade em todos os aspectos](https://youtu.be/vbjFjMNVEpc)
**Exemplos relacionados:**
+ [Workshop: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US)
**Ferramentas relacionadas:**
+ [Parceiros de competência Segurança da AWS: gerenciamento de identidade e acesso](https://aws.amazon.com/security/partner-solutions/)
+ [saml2aws](https://github.com/Versent/saml2aws)
# SEC02-BP05 Auditar e fazer a rotação das credenciais periodicamente
Audite e faça a rotação das credenciais periodicamente para limitar o período durante o qual as credenciais podem ser usadas para acessar seus recursos. Credenciais de longo prazo criam muitos riscos, e estes podem ser reduzidos por meio da rotação periódica das credenciais de longo prazo.
**Resultado desejado:** implemente a rotação de credenciais para ajudar a reduzir os riscos associados ao uso de credenciais a longo prazo. Audite e corrija regularmente a não conformidade com políticas de rotação de credenciais.
**Práticas comuns que devem ser evitadas:**
+ Não auditar o uso de credenciais.
+ Utilizar credenciais de longo prazo desnecessariamente.
+ Utilizar credenciais de longo prazo e não fazer sua rotação regularmente.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Quando você não puder contar com credenciais temporárias e exigir credenciais de longo prazo, faça uma auditoria das credenciais para garantir que os controles definidos, por exemplo, [autenticação multifator (MFA)](https://aws.amazon.com/iam/features/mfa/), sejam aplicados, sofram rotação periódica e tenham o nível de acesso apropriado.
A validação periódica, preferencialmente por meio de uma ferramenta automatizada, é necessária para verificar se os controles corretos são aplicados. Para identidades humanas, exija que os usuários alterem suas senhas periodicamente e substituam chaves de acesso por credenciais temporárias. Ao migrar de usuários do AWS Identity and Access Management (IAM) para identidades centralizadas, você pode [gerar um relatório de credenciais](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) para auditar seus usuários.
Também recomendamos implementar e monitorar a MFA no provedor de identidades. É possível configurar o [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) ou usar [padrões de segurança do AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) para monitorar se os usuários configuraram a MFA. Considere utilizar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para fornecer credenciais temporárias para identidades de máquina. Em situações em que o uso de perfis do IAM e credenciais temporárias não é possível, é necessário realizar auditoria frequente e fazer a rotação das chaves de acesso.
### Etapas de implementação
+ **Audite as credenciais periodicamente:** a auditoria das identidades configuradas em seu provedor de identidades e no IAM ajuda a garantir que somente identidades autorizadas tenham acesso à sua workload. Essas identidades podem incluir, entre outros, usuários do IAM, usuários do Centro de Identidade do AWS IAM, usuários do Active Directory ou usuários em um provedor de identidades upstream diferente. Por exemplo, remova as pessoas que saem da organização os perfis entre contas que não são mais necessários. Estabeleça um processo para auditar periodicamente as permissões para os serviços acessados por uma entidade do IAM. Isso ajuda a identificar as políticas que você precisa modificar a fim de remover todas as permissões não utilizadas. Use relatórios de credenciais e o [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para auditar credenciais e permissões do IAM. Você pode usar o [Amazon CloudWatch para configurar alarmes para chamadas de API específicas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) chamadas dentro do seu ambiente. AWS [O Amazon GuardDuty também pode alertar você sobre atividades inesperadas](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), o que pode indicar acesso excessivamente permissivo ou acesso não intencional às credenciais do IAM.
+ **Faça a rotação das credenciais regularmente:** quando não conseguir usar credenciais temporárias, faça a rotação das chaves de acesso do IAM de longo prazo regularmente (máximo a cada 90 dias). Se uma chave de acesso for divulgada acidentalmente sem seu conhecimento, isso limitará o período de uso das credenciais para acessar seus recursos. Para obter mais informações sobre a rotação de chaves de acesso para usuários do IAM, consulte [Fazer a rotação das chave de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
+ **Revise suas permissões do IAM:** para melhorar a segurança da sua conta da Conta da AWS, você deve revisar e monitorar regularmente cada uma de suas políticas do IAM. Verifique se as políticas seguem o princípio de privilégio mínimo.
+ **Considere automatizar a criação e as atualizações de recursos do IAM:** o [Centro de Identidade do IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) automatiza muitas tarefas do IAM, como gerenciamento de perfis e políticas. Como alternativa, o AWS CloudFormation pode ser usado para automatizar a implantação de recursos do IAM, como perfis e políticas, para reduzir a chance de erros humanos, pois os modelos podem ser verificados e ter controle de versão.
+ **Use o IAM Roles Anywhere para substituir usuários do IAM por identidades de máquina:** o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) permite que você use perfis em áreas que tradicionalmente não poderia, como servidores on-premises. O IAM Roles Anywhere utiliza um [certificado X.509](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification) confiável para realizar a autenticação na AWS e receber credenciais temporárias. O uso do IAM Roles Anywhere evita a necessidade de fazer a rotação dessas credenciais, pois credenciais de longo prazo não são mais armazenadas em seu ambiente on-premises. Você precisará monitorar e fazer a rotação do certificado X.509 à medida que ele se aproxima da validade.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP02 Usar credenciais temporárias ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP03 Armazenar e usar segredos com segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
**Documentos relacionados:**
+ [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Práticas recomendadas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Provedores de identidade e federação](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Soluções para parceiros de segurança: acesso e controle](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [Credenciais de segurança temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Obter relatórios de credenciais da sua Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Vídeos relacionados:**
+ [Práticas recomendadas para gerenciar, recuperar e fazer a rotação de segredos em escala](https://youtu.be/qoxxRlwJKZ4)
+ [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E)
+ [Como dominar a identidade em cada camada do bolo](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 Utilizar grupos de usuários e atributos
A definição de permissões de acordo com grupos de usuários e atributos ajuda a reduzir o número e a complexidade das políticas, simplificando o cumprimento do princípio do privilégio mínimo. Você pode usar grupos de usuários para gerenciar permissões para várias pessoas em um só lugar com base na função que elas desempenham em sua organização. Os atributos, como departamento, projeto ou localização, podem ampliar o escopo de permissão quando as pessoas realizam uma função que, embora semelhante, envolve diferentes subconjuntos de recursos.
**Resultado desejado:** é possível aplicar alterações nas permissões com base na função a todos os usuários que executam essa função. A associação a grupos e os atributos governam as permissões de usuário, reduzindo a necessidade de gerenciar permissões para cada usuário. Os grupos e atributos que você define em seu provedor de identidades (IdP) são propagados automaticamente para seus ambientes da AWS.
**Práticas comuns que devem ser evitadas:**
+ Gerenciar permissões para usuários individuais e duplicá-las entre vários usuários.
+ Definir grupos em um nível muito alto, concedendo permissões excessivamente amplas.
+ Definir grupos em um nível muito detalhado, criando duplicação e confusão em termos de associação.
+ Usar grupos com permissões duplicadas em subconjuntos de recursos quando, em vez disso, é possível usar atributos.
+ Não gerenciar grupos, atributos e associações por meio de um provedor de identidades padronizado integrado aos seus ambientes da AWS.
+ Usar o encadeamento de perfis ao utilizar sessões do Centro de Identidade do AWS IAM
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
As permissões da AWS são definidas em documentos chamados de *políticas*, os quais são associados a uma entidade principal, como usuário, grupo, perfil ou recurso. Você pode escalar o gerenciamento de permissões organizando as atribuições de permissões (grupo, permissões, conta) com base na função do trabalho, na workload e no ambiente SDLC. Para sua força de trabalho, isso permite definir grupos com base na função desempenhada pelos usuários dentro da organização, e não nos recursos que estão sendo acessados. Por exemplo, um grupo WebAppDeveloper pode ter uma política anexada para configurar serviços como o Amazon CloudFront em uma conta de desenvolvimento. Um grupo `AutomationDeveloper` pode apresentar sobreposição de algumas permissões com o grupo `WebAppDeveloper`. Essas permissões comuns podem ser capturadas em uma política separada e associadas aos dois grupos, em vez de fazer com que os usuários de ambas as funções pertençam a um grupo `CloudFrontAccess`.
Além dos grupos, você pode usar *atributos* para controlar melhor o escopo do acesso. Por exemplo, você pode ter um atributo Projeto para os usuários do seu grupo `WebAppDeveloper` para definir o escopo do acesso a recursos específicos do projeto. O uso dessa técnica elimina a necessidade de ter grupos diferentes para desenvolvedores de aplicações que estão trabalhando em diferentes projetos se, em outras circunstâncias, as permissões deles forem as mesmas. A forma como você se refere aos atributos nas políticas de permissão baseia-se na respectiva origem, sejam eles definidos como parte do seu protocolo de federação (por ex., SAML, OIDC ou SCIM) ou como declarações SAML personalizadas, ou definidos dentro do Centro de Identidade do IAM.
### Etapas de implementação
1. Estabeleça onde você definirá grupos e atributos:
1. Seguindo as orientações em [SEC02-BP04 Confiar em um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), é possível determinar se há necessidade de definir grupos e atributos no seu provedor de identidades, no Centro de Identidade do IAM ou com grupos de usuários do IAM em uma conta específica.
1. Defina grupos:
1. Determine seus grupos com base na função e no escopo de acesso necessário. Considere usar uma estrutura hierárquica ou convenções de nomenclatura para organizar grupos de forma eficaz.
1. Se estiver definindo no Centro de Identidade do IAM, crie grupos e associe o nível de acesso desejado usando conjuntos de permissões.
1. Se estiver definindo em um provedor de identidades externo, determine se o provedor atende ao protocolo SCIM e considere habilitar o provisionamento automático no Centro de Identidade do IAM. Esse recurso sincroniza a criação, associação e exclusão de grupos entre seu provedor e o Centro de Identidade do IAM.
1. Defina atributos:
1. Se usar um provedor de identidades externo, os protocolos SCIM e SAML 2.0 fornecem determinados atributos por padrão. Atributos adicionais podem ser definidos e transmitidos por meio de declarações SAML usando o nome do atributo `https://aws.amazon.com/SAML/Attributes/PrincipalTag`. Consulte a documentação do provedor de identidades para obter orientação sobre a definição e configuração de atributos personalizados.
1. Se você definir perfis no Centro de Identidade do IAM, habilite o recurso de controle de acesso por atributo (ABAC) e defina os atributos conforme desejado. Considere os atributos que se alinham à estrutura da sua organização ou à estratégia de marcação de recursos.
Se você precisar do encadeamento de perfis do IAM assumidos por meio do Centro de Identidade do IAM, valores como `source-identity` e `principal-tags` não serão propagados. Para mais detalhes, consulte [Habilite e configure atributos para controle de acesso](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html).
1. Defina o escopo das permissões com base em grupos e atributos:
1. Considere incluir condições em suas políticas de permissão que comparem os atributos da entidade principal aos atributos dos recursos que estão sendo acessados. Por exemplo, é possível definir uma condição para permitir o acesso a um recurso somente se o valor de uma chave de condição `PrincipalTag` corresponder ao valor de uma chave `ResourceTag` com o mesmo nome.
1. Ao definir as políticas de ABAC, siga as orientações nas práticas recomendadas e exemplos de [autorização por ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html).
1. Revise e atualize regularmente sua estrutura de grupos e atributos à medida que as necessidades de sua organização evoluem para garantir o gerenciamento ideal de permissões.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP04 Confiar em um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP02 Conceder acesso de privilégio mínimo](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [COST02-BP04 Implementar grupos e perfis](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html)
**Documentos relacionados:**
+ [Práticas recomendadas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Gerenciar identidades no Centro de Identidade do IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [O que é ABAC para AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [ABAC no Centro de Identidade do IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)
+ [Exemplos de política de ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html)
**Vídeos relacionados:**
+ [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E)
+ [Como dominar a identidade em cada camada do bolo](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# Gerenciamento de permissões
Gerencie permissões para controlar o acesso a identidades de humanos e máquinas que precisam de acesso à AWS e à suas workloads. Com as permissões, você controla quem pode acessar o quê e em quais condições. Ao definir permissões para identidades humanas e de máquina específicas, você concede a elas acesso a ações de serviço específicas em recursos específicos. Além disso, você pode especificar condições que precisem ser verdadeiras para que o acesso seja concedido.
Há várias maneiras de conceder acesso a diferentes tipos de recursos. Uma maneira é usar diferentes tipos de política.
As [políticas baseadas em identidade](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no IAM são *gerenciadas* ou *em linha* e anexadas às identidades do IAM, incluindo usuários, grupos ou perfis. Essas políticas permitem que você especifique o que cada identidade pode fazer (suas respectivas permissões). As políticas baseadas em identidade podem ser subdivididas em outras categorias.
**Políticas gerenciadas**: políticas autônomas baseadas em identidade que você pode anexar a vários usuários, grupos e funções em sua conta da AWS. Existem dois tipos de políticas gerenciadas:
+ **Políticas gerenciadas pela AWS**: políticas gerenciadas que são criadas e gerenciadas pela AWS.
+ **Políticas gerenciadas pelo cliente**: políticas gerenciadas que você cria e gerencia em sua conta da AWS. As políticas gerenciadas pelo cliente fornecem controle mais preciso sobre suas políticas do que as políticas gerenciadas pela AWS.
As políticas gerenciadas são o método preferencial para aplicar permissões. No entanto, também é possível usar políticas em linha adicionadas diretamente a um único usuário, grupo ou perfil. As políticas em linha mantêm um relacionamento estrito de um para um entre uma política e uma identidade. As políticas em linha são excluídas quando a identidade é excluída.
Na maioria dos casos, é necessário criar suas próprias políticas gerenciadas pelo cliente seguindo o princípio do privilégio [mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
[Políticas baseadas em recurso](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) são anexadas a um recurso. Por exemplo, uma política de bucket do S3 é uma política baseada em recursos. Essas políticas concedem permissão a uma entidade principal que pode estar na mesma conta que o recurso ou em outra conta. Para obter uma lista de serviços que oferecem suporte a permissões baseadas em recursos, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
Os [limites de permissões](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) usam uma política gerenciada para determinar as permissões máximas que um administrador pode definir. Isso permite que você delegue a capacidade de criar e gerenciar permissões para desenvolvedores, como a criação de um perfil do IAM, mas limita as permissões que eles podem conceder para que não possam escalar as próprias permissões usando o que eles criaram.
O [Controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) na AWS permite que você conceda permissões com base em atributos chamados de tags. As tags podem ser anexadas a entidades principais (usuários ou perfis) do IAM e a recursos da AWS. Os administradores podem criar políticas do IAM reutilizáveis que aplicam permissões com base nos atributos da entidade principal do IAM. Por exemplo, como administrador, você pode usar uma única política do IAM que concede aos desenvolvedores em sua organização acesso a recursos da AWS que correspondem às tags de projeto dos desenvolvedores. À medida que a equipe de desenvolvedores adiciona recursos aos projetos, as permissões são aplicadas automaticamente com base em atributos, eliminando a necessidade de atualizações de políticas para cada novo recurso.
As [políticas de controle de serviços (SCP) de organizações](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_scp) definem o máximo de permissões para os membros da conta de uma organização ou unidade organizacional (UO). As SCPs *limitam* as permissões que as políticas baseadas em identidade ou políticas baseadas em recurso concedem a entidades (usuários ou funções) dentro da conta, mas *não concedem permissões*.
As [políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) assumem uma função ou um usuário federado. Passe as políticas de sessão ao usar as políticas de sessão da AWS CLI ou AWS API para limitar as permissões que as políticas baseadas em identidade do usuário ou da função concedem à sessão. As políticas de sessão *limitam* as permissões para uma sessão criada, mas *não concedem* permissões. Para obter mais informações, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session).
**Topics**
+ [SEC03-BP01 Definir requisitos de acesso](sec_permissions_define.md)
+ [SEC03-BP02 Conceder acesso de privilégio mínimo](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Estabelecer processo de acesso de emergência](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Reduzir as permissões continuamente](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Definir barreiras de proteção de permissões para sua organização](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Compartilhar recursos com segurança em sua organização](sec_permissions_share_securely.md)
+ [SEC03-BP09 Compartilhar recursos com terceiros de forma segura](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 Definir requisitos de acesso
Cada componente ou recurso de seu workload precisa ser acessado por administradores, usuários finais ou outros componentes. Tenha uma definição clara de quem ou o que deve ter acesso a cada componente, escolha o tipo de identidade e o método de autenticação e autorização apropriados.
**Práticas comuns que devem ser evitadas:**
+ Codificação rígida ou armazenamento de segredos em sua aplicação.
+ Concessão de permissões personalizadas a cada usuário.
+ Uso de credenciais de longa duração.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Cada componente ou recurso de seu workload precisa ser acessado por administradores, usuários finais ou outros componentes. Tenha uma definição clara de quem ou o que deve ter acesso a cada componente, escolha o tipo de identidade e o método de autenticação e autorização apropriados.
O acesso regular a Contas da AWS dentro da organização deve ser fornecido usando [acesso federado](https://aws.amazon.com/identity/federation/) ou um provedor de identidade centralizado. Você também deve centralizar o gerenciamento de identidade e garantir que haja uma prática estabelecida para integrar o acesso à AWS ao ciclo de vida de acesso dos funcionários. Por exemplo, quando um funcionário muda para um cargo com um nível de acesso diferente, sua associação ao grupo também deve mudar para refletir os novos requisitos de acesso.
Ao definir os requisitos de acesso para identidades não humanas, determine quais aplicações e componentes precisam de acesso e como as permissões são concedidas. O uso de perfis do IAM criados com o modelo de acesso de privilégio mínimo é uma abordagem recomendada. [AWS As políticas gerenciadas](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) fornecem políticas do IAM predefinidas que abordam a maioria dos casos de uso comuns.
Serviços da AWS, como o [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) e o [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html), podem ajudar a desacoplar os segredos da aplicação ou workload com segurança. No Secrets Manager, é possível estabelecer uma rotação automática das suas credenciais. É possível usar o Systems Manager para referenciar parâmetros em seus scripts, comandos, documentos do SSM, configurações e fluxos de trabalho de automação usando o nome exclusivo que você especificou ao criar o parâmetro.
É possível usar o [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para obter [credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) para workloads executadas fora da AWS. Suas workloads podem usar as mesmas [políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) e [perfis do IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)que você usa com aplicações da AWS para acessar recursos da AWS.
Quando possível, prefira credenciais temporárias de curta duração em vez de credenciais estáticas de longa duração. Para cenários em que você precisa de usuários do com acesso programático e credenciais de longo prazo, use as [informações de última utilização da chave de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) para fazer a rotação e remover chaves de acesso.
Os usuários precisam de acesso programático se quiserem interagir com a AWS de fora do Console de gerenciamento da AWS. A forma de conceder acesso programático depende do tipo de usuário que está acessando a AWS.
Para conceder acesso programático aos usuários, selecione uma das seguintes opções:
****
| Qual usuário precisa de acesso programático? | Para | Por |
| --- | --- | --- |
| IAM | (Recomendado) Use credenciais do console como credenciais temporárias para assinar solicitações programáticas para a AWS CLI, os AWS SDKs ou as APIs da AWS. | Siga as instruções da interface que deseja utilizar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| Identidade da força de trabalho (Usuários gerenciados no Centro de Identidade do IAM) | Use credenciais temporárias para assinar solicitações programáticas para a AWS CLI, os SDKs da AWS ou as APIs da AWS. | Siga as instruções da interface que deseja utilizar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| IAM | Use credenciais temporárias para assinar solicitações programáticas para a AWS CLI, os SDKs da AWS ou as APIs da AWS. | Siga as instruções em [Usar credenciais temporárias com recursos da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) no Guia do usuário do IAM. |
| IAM | (Não recomendado)Use credenciais de longo prazo para assinar solicitações programáticas para a AWS CLI, os SDKs da AWS ou as APIs da AWS. | Siga as instruções da interface que deseja utilizar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
## Recursos
**Documentos relacionados:**
+ [Controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Centro de Identidade do AWS IAM](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [AWS Políticas gerenciadas pela para o IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS Condições de política do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [Casos de uso do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [Remover credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [Como trabalhar com políticas do](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [Como controlar o acesso a recursos da AWS com base em Conta da AWS, UO ou organização](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identificar, organizar e gerenciar segredos facilmente usando a pesquisa avançada no AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**Vídeos relacionados:**
+ [Torne-se um mestre e políticas do IAM em no máximo 60 minutos](https://youtu.be/YQsK4MtsELU)
+ [Separação de deveres, privilégio mínimo, delegação e CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Simplificação do gerenciamento de identidade e acesso para inovação](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 Conceder acesso de privilégio mínimo
Conceda somente o acesso de que os usuários precisam para realizar ações em recursos específicos e sob condições específicas. Use grupos e atributos de identidade para definir permissões dinamicamente em escala, em vez de definir permissões para usuários individuais. Por exemplo, é possível permitir o acesso de um grupo de desenvolvedores para gerenciar apenas recursos de seu próprio projeto. Dessa forma, se um desenvolvedor sair do projeto, seu acesso será automaticamente revogado sem que seja necessário alterar as políticas de acesso adjacentes.
**Resultado desejado:** os usuários têm apenas as permissões mínimas necessárias para suas funções de trabalho específicas. Use Contas da AWS separadas para isolar os desenvolvedores dos ambientes de produção. Quando os desenvolvedores precisam acessar ambientes de produção para tarefas específicas, eles recebem acesso limitado e controlado somente durante a duração dessas tarefas. O acesso à produção é imediatamente revogado após a conclusão do trabalho necessário. Você realiza revisões regulares das permissões e as revoga imediatamente quando não são mais necessárias, como quando um usuário muda de função ou sai da organização. Você restringe os privilégios de administrador a um grupo pequeno e confiável para reduzir a exposição ao risco. Você concede às contas de máquinas ou de agente apenas as permissões mínimas necessárias para executar as tarefas pretendidas.
**Práticas comuns que devem ser evitadas:**
+ Por padrão, você concede permissões de administrador aos usuários.
+ Você usa a conta de usuário-raiz para atividades diárias.
+ Você cria políticas excessivamente permissivas sem um escopo adequado.
+ Suas revisões de permissões não são frequentes, o que leva ao aumento de permissões.
+ Você depende exclusivamente do controle de acesso baseado em atributos para isolamento do ambiente ou gerenciamento de permissões.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
O princípio do [privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) afirma que as identidades só devem ter permissão para realizar o menor conjunto de ações necessárias para cumprir uma tarefa específica. Isso equilibra a usabilidade, eficiência e segurança. Operar sobre esse princípio ajuda a limitar acesso não intencional e a rastrear quem tem acesso a quais recursos. Usuários e perfis do IAM não têm permissões por padrão. O usuário-raiz tem acesso total por padrão e deve ser rigorosamente controlado, monitorado e usado somente para [tarefas que exijam acesso de usuário-raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html).
Políticas do IAM são usadas para conceder explicitamente permissões aos perfis do IAM ou recursos específicos. Por exemplo, políticas com base em identidade podem ser anexadas a grupos do IAM, enquanto buckets do S3 podem ser controlados por políticas baseadas em recursos.
Ao criar uma política do IAM, você pode especificar as ações de serviço, os recursos e as condições que devem ser verdadeiras para que a AWS permita ou negue o acesso. A AWS oferece suporte a uma variedade de condições para ajudar você a reduzir o acesso. Por exemplo, usando a [chave de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID, você poderá negar ações se o solicitante não fizer parte da sua organização da AWS.
Você também pode controlar as solicitações feitas pelos serviços da AWS em seu nome, como o AWS CloudFormation criando uma função do AWS Lambda usando a chave de condição CalledVia. Você pode aplicar camadas de tipos diferentes de políticas para estabelecer a defesa em profundidade e limitar as permissões gerais dos usuários. É possível restringir as permissões que podem ser concedidas e sob quais condições. Por exemplo, você pode permitir que as equipes de workloads criem as próprias políticas do IAM para os sistemas que elas desenvolvem, mas somente se aplicarem um [limite de permissão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) para limitar o máximo de permissões que o sistema pode receber.
### Etapas de implementação
+ **Implementar políticas de privilégio mínimo**: atribua políticas de acesso com privilégio mínimo a grupos e perfis do IAM para refletir a função do usuário ou a função que você definiu.
+ **Isolar ambientes de desenvolvimento e produção por meio de Contas da AWS separadas**: use Contas da AWS separadas para ambientes de desenvolvimento e produção e controle o acesso entre eles usando [políticas de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), políticas de recursos e políticas de identidade.
+ **Baseie as políticas no uso da API**: uma forma de determinar as permissões necessárias é revisar os logs da AWS CloudTrail. Você pode usar essa revisão para criar permissões personalizadas para as ações que o usuário realiza na AWS. O [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) pode [gerar automaticamente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) uma política do IAM com base na atividade de acesso. É possível usar o IAM Access Advisor em nível de organização ou conta para [rastrear as últimas informações acessadas para uma política específica](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).
+ **Considere usar [políticas gerenciadas pela AWS para cargos comuns](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)**: ao começar a criar políticas de permissões refinadas, pode ser útil usar políticas gerenciadas pela AWS para cargos comuns, como faturamento, administradores de banco de dados e cientistas de dados. Essas políticas podem ajudar a diminuir o acesso dos usuários enquanto você determina como implementar as políticas de privilégio mínimo.
+ **Remova permissões desnecessárias:** detecte e remova entidades, credenciais e permissões do IAM não utilizadas para alcançar o princípio do privilégio mínimo. Você pode usar o [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) para identificar o acesso externo e não utilizado, e a [geração de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) pode ajudar a ajustar as políticas de permissões.
+ **Garanta que os usuários tenham acesso limitado aos ambientes de produção:** os usuários só devem ter acesso aos ambientes de produção com um caso de uso válido. Depois de o usuário realizar as tarefas específicas para as quais o acesso à produção foi necessário, o acesso deve ser revogado. Limitar o acesso a ambientes de produção ajuda a prevenir eventos não intencionais e que causam impacto à produção, além de diminuir o escopo do impacto do acesso não intencional.
+ **Considere usar limites de permissões:** um [limite de permissões](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) é um recurso avançado para usar uma política gerenciada que define o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. O limite de permissões de uma entidade permite que a entidade execute somente as ações permitidas por ambas as políticas baseadas em identidade e seus limites de permissões.
+ **Refine o acesso usando controle de acesso por atributo e etiquetas de recursos:** é possível usar o [controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) com etiquetas de recursos para refinar as permissões quando há suporte. Você pode usar um modelo ABAC que compara as tags da entidade principal às tags de recursos para refinar o acesso com base nas dimensões personalizadas que você define. Essa abordagem pode simplificar e reduzir o número de políticas de permissão em sua organização.
+ É recomendável que o ABAC seja usado apenas para controle de acesso quando as entidades principais e os recursos forem de propriedade da sua organização da AWS. Partes externas podem usar os mesmos nomes e valores de tag de sua organização para suas próprias entidades principais e recursos. Se você depende exclusivamente desses pares de nome/valor para conceder acesso a entidades principais ou recursos externos, você pode fornecer permissões não intencionais.
+ **Use políticas de controle de serviço para o AWS Organizations:** as [políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) controlam centralmente o máximo de permissões disponíveis para contas-membro na organização. É importante notar que você pode usar as políticas de controle de serviço para restringir as permissões do usuário-raiz nas contas-membro. Considere também usar o AWS Control Tower, que fornece controles gerenciados prescritivos que enriquecem o AWS Organizations. Também é possível definir os seus próprios controles no Control Tower.
+ **Estabeleça uma política de ciclo de vida do usuário para sua organização:** as políticas de ciclo de vida do usuário definem tarefas a serem executadas quando os usuários são integrados à AWS, mudam de função ou escopo de trabalho ou não precisam mais de acesso à AWS. Realize revisões das permissões durante todas as etapas do ciclo de vida do usuário para verificar se as permissões estão adequadamente restritivas e para evitar desvios nas permissões.
+ **Estabeleça um cronograma regular para revisar as permissões e remover todas as permissões desnecessárias:** revise regularmente o acesso dos usuários para verificar se os usuários não têm acesso excessivamente permissivo. O [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) e o IAM Access Analyzer podem ajudar durante as auditorias de permissões dos usuários.
+ **Estabeleça uma matriz de funções de trabalho:** uma matriz de funções de trabalho visualiza as várias funções e níveis de acesso necessários em sua presença da AWS. Com uma matriz de cargos, você pode definir e separar as permissões com base nas responsabilidades do usuário dentro da sua organização. Use grupos em vez de aplicar permissões diretamente a usuários ou funções individuais.
## Recursos
**Documentos relacionados:**
+ [Conceder privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Limites de permissões para entidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Técnicas para criar políticas do IAM de privilégio mínimo](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [O IAM Access Analyzer facilita a implementação de permissões de privilégio mínimo ao gerar políticas do IAM com base na atividade de acesso](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [Delegar o gerenciamento de permissões aos desenvolvedores usando os limites de permissões do IAM](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [Refinar permissões usando as informações de último acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Tipos de política do IAM e quando usá-las](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [Testar as políticas do IAM com o simulador de políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [Barreiras de proteção no AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Arquiteturas de confiança zero: uma perspectiva da AWS](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [Como implementar o princípio de privilégio mínimo com o CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [Controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Reduzir o escopo da política pela visualização das atividades do usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Visualizar acesso do perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [Usar a marcação com tags para organizar seu ambiente e impulsionar a responsabilidade](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [Estratégias de marcação com tags da AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [Marcando recursos do AWS](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**Vídeos relacionados:**
+ [Gerenciamento de permissões de última geração](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Confiança zero: uma perspectiva da AWS](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 Estabelecer processo de acesso de emergência
Crie um processo que permita acesso emergencial às suas workloads no caso improvável de um problema com seu provedor de identidades centralizado.
Crie processos para diferentes modos de falha que poderiam resultar em um evento de emergência. Por exemplo, em circunstâncias normais, os usuários da sua força de trabalho são federados na nuvem usando um provedor de identidades centralizado ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) para gerenciar suas workloads. No entanto, se o provedor de identidades centralizado falhar ou a configuração da federação na nuvem for modificada, talvez os usuários de sua força de trabalho não consigam se federar na nuvem. Um processo de acesso de emergência permite que administradores autorizados acessem seus recursos de nuvem por meios alternativos (como uma forma alternativa de federação ou acesso direto do usuário) para corrigir problemas com sua configuração de federação ou workloads. O processo de acesso de emergência é usado até o mecanismo normal de federação ser restaurado.
**Resultado desejado:**
+ Você definiu e documentou os modos de falha que são considerados uma emergência: considere suas circunstâncias normais e os sistemas dos quais seus usuários dependem para gerenciar suas workloads. Pense em como cada uma dessas dependências pode falhar e causar uma situação de emergência. Talvez você considere as perguntas e as práticas recomendadas do [pilar Confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) úteis para identificar modos de falha e arquitetar sistemas mais resilientes para minimizar a probabilidade de falhas.
+ Você documentou as etapas que devem ser seguidas para confirmar uma falha como emergência. Por exemplo, é possível exigir que os administradores de identidade confiram o status de seus provedores de identidade primário e de reserva e, se nenhum dos dois estiver disponível, declarar um evento de emergência por falha do provedor de identidades.
+ Você definiu um processo de acesso de emergência específico de cada tipo de modo de emergência ou falha. Ser específico pode reduzir a tentação de seus usuários de abusar de um processo geral para todos os tipos de emergência. Seus processos de acesso de emergência descrevem as circunstâncias em que cada processo deve ser usado e, inversamente, as situações em que o processo não deve ser usado e apontam para processos alternativos que podem ser aplicados.
+ Seus processos são bem documentados com instruções detalhadas e playbooks que podem ser seguidos com rapidez e eficiência. Lembre-se de que um evento de emergência pode ser um momento estressante para os usuários e eles podem estar sob extrema pressão de tempo. Portanto, desenvolva o processo para ser o mais simples possível.
**Práticas comuns que devem ser evitadas:**
+ Você não tem processos de acesso de emergência bem documentados e bem testados. Os usuários não estão preparados para uma emergência e seguem processos improvisados quando um evento de emergência ocorre.
+ Seus processos de acesso de emergência dependem dos mesmos sistemas (como um provedor de identidades centralizado) que seus mecanismos de acesso normais. Isso significa que uma falha desse sistema pode afetar os mecanismos de acesso normal e de emergência e prejudicar sua capacidade de se recuperar da falha.
+ Seus processos de acesso de emergência são usados em situações não emergenciais. Por exemplo, os usuários muitas vezes utilizam de forma indevida os processos de acesso de emergência, pois acham mais fácil fazer alterações diretamente do que enviá-las por meio de um pipeline.
+ Seus processos de acesso de emergência não geram logs suficientes para auditar os processos, ou os logs não são monitorados para alertar sobre o possível uso indevido dos processos.
**Benefícios de implementar esta prática recomendada:**
+ Com processos de acesso de emergência bem documentados e testados, é possível reduzir o tempo gasto pelos usuários para responder e resolver um evento de emergência. Isso pode resultar em menos tempo de inatividade e maior disponibilidade dos serviços fornecidos aos seus clientes.
+ É possível rastrear cada solicitação de acesso de emergência e detectar e alertar sobre tentativas não autorizadas de uso indevido do processo para eventos não emergenciais.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Esta seção fornece orientação para criar processos de acesso de emergência para vários modos de falha relacionados às workloads implantadas na AWS, começando com uma orientação comum que se aplica a todos os modos de falha e seguida por uma orientação específica com base no tipo de modo de falha.
**Orientação comum para todos os modos de falha**
Pense no seguinte ao projetar um processo de acesso de emergência para um modo de falha:
+ Documente as pré-condições e as suposições do processo: quando o processo deve ou não ser usado. Isso ajuda a detalhar o modo de falha e documentar suposições, como o estado de outros sistemas relacionados. Por exemplo, o processo do Modo de falha 2 pressupõe que o provedor de identidades está disponível, mas a configuração na AWS foi modificada ou expirou.
+ Pré-crie os recursos necessários para o processo de acesso de emergência ([SEC10-BP05)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html). Por exemplo, crie previamente a Conta da AWS de acesso de emergência com usuários e perfis do IAM e os perfis do IAM entre contas em todas as contas da workload. Isso verifica se esses recursos estão prontos e disponíveis quando um evento de emergência ocorre. Ao pré-criar recursos, você não depende das APIs do [ambiente de gerenciamento](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) da AWS (usadas para criar e modificar recursos da AWS) que podem estar indisponíveis em caso de emergência. Além disso, ao pré-criar recursos do IAM, não é necessário considerar [possíveis atrasos devido a consistência eventual](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency).
+ Inclua processos de acesso de emergência como parte dos planos de gerenciamento de incidentes ([SEC1-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Documente como os eventos de emergência são acompanhados e comunicados a outras pessoas na organização, como equipes de colegas, sua liderança e, quando aplicável, externamente a seus clientes e parceiros de negócios.
+ Defina o processo de solicitação de acesso de emergência no sistema de fluxo de trabalho de solicitação de serviço existente, caso haja um. Normalmente, esses sistemas de fluxo de trabalho permitem criar formulários de admissão para coletar informações sobre a solicitação, rastrear a solicitação em cada estágio do fluxo de trabalho e adicionar etapas de aprovação automatizadas e manuais. Relacione cada solicitação a um evento de emergência correspondente acompanhado no sistema de gerenciamento de incidentes. Ter um sistema uniforme para acessos de emergência permite que você acompanhe essas solicitações em um único sistema, analise as tendências de uso e melhore os processos.
+ Verifique se os processos de acesso de emergência só podem ser iniciados por usuários autorizados e exigem aprovações dos colegas ou da gerência do usuário, conforme apropriado. O processo de aprovação deve operar de forma eficaz dentro e fora do horário comercial. Defina como as solicitações de aprovação permitirão aprovadores secundários se os aprovadores primários não estiverem disponíveis e forem encaminhadas para a cadeia de gerenciamento até serem aprovadas.
+ Implemente mecanismos robustos de registro em log, monitoramento e alerta para o processo e os mecanismos de acesso de emergência. Gere logs de auditoria detalhados para todas as tentativas bem-sucedidas e fracassadas de obter acesso de emergência. Correlacione a atividade com eventos de emergência contínuos do sistema de gerenciamento de incidentes e inicie alertas quando as ações ocorrerem fora dos períodos esperados ou quando a conta de acesso de emergência for usada durante as operações normais. A conta de acesso de emergência só deve ser acessada durante emergências, pois os procedimentos de quebra de vidro podem ser considerados uma backdoor. Integre-se à sua ferramenta de gerenciamento de eventos e informações de segurança (SIEM) ou [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)para relatar e auditar todas as atividades durante o período de acesso de emergência. Ao retornar às operações normais, alterne automaticamente as credenciais de acesso de emergência e notifique as equipes relevantes.
+ Teste os processos de acesso de emergência periodicamente para verificar se as etapas estão claras e garantir o nível correto de acesso com rapidez e eficiência. Seus processos de acesso de emergência devem ser testados como parte das simulações de resposta a incidentes ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) e dos testes de recuperação de desastres ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)).
**Modo de falha 1: o provedor de identidades usado para federação na AWS não está disponível**
Conforme descrito em [SEC02-BP-04 Confiar em um provedor de identidade federado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), recomendamos confiar em um provedor de identidades centralizado para federar os usuários de sua força de trabalho e conceder acesso a Contas da AWS. Você pode federar em várias Contas da AWS na organização da AWS usando o Centro de Identidade do IAM ou federar em Contas da AWS individuais usando o IAM. Nos dois casos, os usuários da força de trabalho se autenticam com seu provedor de identidades centralizado antes de serem redirecionados a um endpoint de login da AWS para SSO.
No caso improvável do provedor de identidades centralizado não estar disponível, os usuários da sua força de trabalho não poderão se federar nas Contas da AWS nem gerenciar as workloads. Nesse evento de emergência, é possível fornecer um processo de acesso de emergência para um pequeno grupo de administradores acessar as Contas da AWS a fim de realizar tarefas essenciais que não podem esperar até que seus provedores de identidades centralizados estejam online novamente. Por exemplo, seu provedor de identidades fica indisponível por quatro horas e, durante esse período, você precisa modificar os limites superiores de um grupo do Amazon EC2 Auto Scaling em uma conta de produção para lidar com um aumento inesperado no tráfego de clientes. Seus administradores de emergência devem seguir o processo de acesso de emergência a fim de obter acesso à Conta da AWS de produção específica e fazer as alterações necessárias.
O processo de acesso de emergência depende de uma Conta da AWS de acesso de emergência pré-criada usada exclusivamente para acesso de emergência e tem recursos da AWS (como perfis e usuários do IAM) para apoiar o processo de acesso de emergência. Durante as operações normais, ninguém deve acessar a conta de acesso de emergência, e você deve monitorar e alertar sobre o uso indevido dessa conta (para receber mais detalhes, consulte a seção Orientação comum anterior).
A conta de acesso de emergência tem perfis do IAM de acesso de emergência com permissões para assumir perfis entre contas nas Contas da AWS que exigem acesso de emergência. Esses perfis do IAM são pré-criados e configurados com políticas de confiança que confiam nos perfis do IAM da conta de emergência.
O processo de acesso de emergência pode usar uma das seguintes abordagens:
+ É possível pré-criar um conjunto de [usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) para seus administradores de emergência na conta de acesso de emergência com senhas fortes e tokens de MFA associados. Esses usuários do IAM têm permissões para assumir os perfis do IAM que permitem o acesso entre contas à Conta da AWS onde o acesso de emergência é necessário. Recomendamos criar o menor número possível de usuários e atribuir cada um a um único administrador de emergência. Durante uma emergência, um usuário administrador de emergência entra na conta de acesso de emergência usando sua senha e código de token MFA, muda para o perfil do IAM de acesso de emergência na conta de emergência e, por fim, para o perfil do IAM de acesso de emergência na conta da workload para realizar a ação de alteração de emergência. A vantagem dessa abordagem é que cada usuário do IAM é atribuído a um administrador de emergência, e é possível saber qual usuário fez login analisando os eventos do CloudTrail. A desvantagem é que você precisa manter vários usuários do IAM com as respectivas senhas de longa duração e tokens de MFA associados.
+ É possível usar o [usuário-raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) de emergência para entrar na conta de acesso de emergência, assumir o perfil do IAM para acesso de emergência e assumir o perfil entre contas na conta da workload. Recomendamos definir uma senha forte e vários tokens de MFA para o usuário-raiz. Também recomendamos armazenar a senha e os tokens de MFA em um cofre de credenciais corporativo seguro que imponha autenticação e autorização fortes. Você deve proteger a senha e os fatores de redefinição de tokens de MFA: defina o endereço de e-mail da conta como uma lista de distribuição de e-mail monitorada pelos administradores de segurança na nuvem e o número de telefone da conta como um número de telefone compartilhado que também seja monitorado pelos administradores de segurança. A vantagem dessa abordagem é que há um conjunto de credenciais de usuário-raiz para gerenciar. A desvantagem é que, como se trata de um usuário compartilhado, vários administradores podem fazer login como usuário-raiz. Você deve fazer auditoria dos eventos de log do cofre corporativo para identificar qual administrador fez check-out da senha do usuário-raiz.
**Modo de falha 2: a configuração do provedor de identidades na AWS foi modificada ou expirou**
Para permitir que os usuários de sua força de trabalho sejam federados nas Contas da AWS, é possível configurar o Centro de Identidade do IAM com um provedor de identidades externo ou criar um provedor de identidades do IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). Normalmente, você os configura importando um documento XML de metadados SAML fornecido pelo provedor de identidades. O documento XML de metadados inclui um certificado X.509 correspondente a uma chave privada que o provedor de identidades usa para assinar as declarações SAML.
Essas configurações no lado da AWS podem ser modificadas ou excluídas por engano por um administrador. Em outro cenário, o certificado X.509 importado para a AWS pode expirar, e um novo XML de metadados com um novo certificado ainda não foi importado para a AWS. Os dois cenários podem interromper a federação na AWS para os usuários de sua força de trabalho, ocasionando uma emergência.
Nesse evento de emergência, você pode fornecer aos seus administradores de identidade acesso à AWS para resolver os problemas de federação. Por exemplo, seu administrador de identidade usa o processo de acesso de emergência para fazer login na Conta da AWS de acesso de emergência, muda para um perfil na conta de administrador do Centro de Identidade e atualiza a configuração do provedor de identidades externo importando o documento XML de metadados SAML mais recente do provedor de identidades para reativar a federação. Após a federação ser corrigida, os usuários da sua força de trabalho continuarão usando o processo operacional normal para federar em suas contas da workload.
Você pode seguir as abordagens detalhadas no Modo de falha 1 anterior para criar um processo de acesso de emergência. É possível conceder permissões de privilégio mínimo aos seus administradores de identidade a fim de acessar somente a conta de administrador do Centro de Identidade e realizar ações no Centro de Identidade nessa conta.
**Modo de falha 3: interrupção do Centro de Identidade**
No caso improvável de uma interrupção do Centro de Identidade do IAM ou da Região da AWS, recomendamos definir uma configuração que possa ser usada para conceder acesso temporário ao Console de gerenciamento da AWS.
O processo de acesso de emergência usa a federação direta do provedor de identidades no IAM em uma conta de emergência. Para obter detalhes sobre o processo e as considerações de design, consulte [Configurar o acesso de emergência ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html).
### Etapas de implementação
**Etapas comuns para todos os modos de falha**
+ Crie uma Conta da AWS dedicada aos processos de acesso de emergência. Crie previamente os recursos do IAM necessários na conta, como perfis ou usuários do IAM e, opcionalmente, provedores de identidades do IAM. Além disso, crie previamente perfis do IAM entre contas nas Contas da AWS da workload com relacionamentos de confiança com os perfis do IAM correspondentes na conta de acesso de emergência. É possível usar o [CloudFormation StackSets com AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) para criar esses recursos nas contas-membro da sua organização.
+ Crie [políticas de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) do AWS Organizations para negar a exclusão e a modificação dos perfis do IAM entre contas nas Contas da AWS-membro.
+ Ative o CloudTrail para a Conta da AWS de acesso de emergência e envie os eventos da trilha a um bucket central do S3 em sua Conta da AWS de coleção de logs. Se você estiver usando o AWS Control Tower para configurar e controlar seu ambiente de várias contas da AWS, todas as contas que você criar usando o AWS Control Tower ou inscrever no AWS Control Tower terão o CloudTrail ativado por padrão e serão enviadas a um bucket do S3 em uma Conta da AWS de arquivo de log dedicado.
+ Monitore a atividade da conta de acesso de emergência criando regras do EventBridge que correspondam ao login do console e à atividade da API pelos perfis do IAM de emergência. Envie notificações ao seu centro de operações de segurança quando ocorrerem atividades fora de um evento de emergência contínuo acompanhado no sistema de gerenciamento de incidentes.
**Etapas adicionais para o Modo de falha 1: o provedor de identidades usado para federar na AWS não está disponível; Modo de falha 2: a configuração do provedor de identidades na AWS foi modificada ou expirou**
+ Crie previamente recursos de acordo com o mecanismo escolhido para acesso de emergência:
+ **Utilizar usuários do IAM:** crie previamente os usuários do IAM com senhas fortes e dispositivos MFA associados.
+ **Utilizar o usuário-raiz da conta de emergência:** configure o usuário-raiz com uma senha forte e armazene a senha no seu cofre de credenciais corporativo. Associe vários dispositivos físicos de MFA ao usuário-raiz e armazene os dispositivos em locais que possam ser acessados rapidamente pelos membros de sua equipe de administradores de emergência.
**Etapas adicionais para o Modo de falha 3: interrupção do Centro de Identidade**
+ Conforme detalhado em [Configurar o acesso de emergência ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), na Conta da AWS de acesso de emergência, crie um provedor de identidades do IAM para ativar a federação direta de SAML a partir do provedor de identidades.
+ Crie grupos de operações de emergência no IdP sem membros.
+ Crie perfis do IAM correspondentes aos grupos de operações de emergência na conta de acesso de emergência.
## Recursos
**Práticas recomendadas do Well-Architected relacionadas:**
+ [SEC02-BP04 Confiar em um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 Conceder acesso de privilégio mínimo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 Desenvolver planos de gerenciamento de incidentes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 Promover game days](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**Documentos relacionados:**
+ [Configurar o acesso de emergência ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [Habilitar o acesso de usuários federados SAML 2.0 ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Acesso de emergência](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2022: Simplificar o acesso da sua força de trabalho com o Centro de Identidade do IAM](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022: Mergulho profundo no AWS Identity and Access Management (IAM)](https://youtu.be/YMj33ToS8cI)
**Exemplos relacionados:**
+ [AWS Perfil de acesso de emergência da](https://github.com/awslabs/aws-break-glass-role)
+ [AWS Framework do playbook do cliente da](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Exemplos de playbook de resposta a incidentes da](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 Reduzir as permissões continuamente
À medida que suas equipes determinarem o acesso de que precisam, remova as permissões desnecessárias e estabeleça processos de análise para obter permissões de privilégio mínimo. Monitore e remova continuamente identidades e permissões não utilizadas para acesso humano e de máquina.
**Resultado desejado:** as políticas de permissão devem seguir o princípio de privilégio mínimo. À medida que os cargos e os perfis se tornem mais bem definidos, suas políticas de permissões precisam ser analisadas para remover permissões desnecessárias. Essa abordagem reduz o escopo do impacto caso as credenciais sejam expostas de forma acidental ou sejam acessadas sem autorização.
**Práticas comuns que devem ser evitadas:**
+ Usar como padrão a concessão de permissões de administrador aos usuários.
+ Criar políticas permissivas demais, mas sem privilégios completos de administrador.
+ Manter as políticas de permissão quando não são mais necessárias.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Enquanto as equipes e os projetos estiverem apenas começando, políticas de permissão permissivas podem ser usadas para inspirar inovação e agilidade. Por exemplo, em um ambiente de desenvolvimento ou teste, os desenvolvedores podem receber acesso a uma ampla gama de serviços da AWS. Recomendamos avaliar o acesso de forma contínua e restringir o acesso somente àqueles serviços e ações de serviço necessários para concluir o trabalho atual. Recomendamos essa avaliação para identidades humanas e de máquina. Identidades de máquina, às vezes, denominadas contas de sistema ou serviço, são identidades que fornecem acesso da AWS a aplicações ou servidores. Esse acesso é especialmente importante em um ambiente de produção, em que as permissões excessivamente permissivas podem causar um grande impacto e expor dados dos clientes.
A AWS oferece vários métodos para ajudar a identificar usuários, perfis, permissões e credenciais não utilizados. A AWS também pode ajudar a analisar a atividade de acesso dos usuários e dos perfis do IAM, como chaves de acesso associadas, e o acesso aos recursos da AWS, como objetos em buckets do Amazon S3. A geração de políticas do AWS Identity and Access Management Access Analyzer pode auxiliar você a criar políticas de permissão restritivas com base nos serviços e nas ações reais com os quais uma entidade principal interage. O [controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) pode ajudar a simplificar o gerenciamento de permissões, pois você pode fornecer permissões aos usuários usando seus atributos em vez de anexar políticas de permissões diretamente a cada usuário.
### Etapas de implementação
+ **Use o [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** o IAM Access Analyzer ajuda a identificar os recursos em sua organização e suas contas, como buckets do Amazon Simple Storage Service (Amazon S3) ou perfis do IAM que são [compartilhados com uma entidade externa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Use a [geração de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html):** a geração de políticas do IAM Access Analyzer ajuda você a [criar políticas de permissão refinadas com base na atividade de acesso de um usuário ou perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks).
+ **Teste as permissões em ambientes inferiores antes da produção:** comece usando os [ambientes menos críticos de sandbox e desenvolvimento](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html) para testar as permissões necessárias para várias funções de trabalho usando o IAM Access Analyzer. Em seguida, restrinja e valide progressivamente essas permissões nos ambientes de teste, garantia de qualidade e preparação antes de aplicá-las à produção. Inicialmente, os ambientes inferiores podem ter permissões mais relaxadas, pois as políticas de controle de serviços (SCPs) impõem barreiras de proteção ao limitar o máximo de permissões concedidas.
+ **Determine um prazo e uma política de uso aceitáveis para usuários e funções do IAM:** use o [carimbo de data/hora do último acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) para [identificar usuários e perfis não utilizados e removê-los](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/). Revise as informações de serviço e ação acessadas mais recentemente para identificar e [definir o escopo das permissões para usuários e perfis específicos.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) Por exemplo, você pode usar as informações acessadas mais recentemente para identificar as ações específicas do Amazon S3 exigidas pelo perfil da aplicação e restringir o acesso do perfil apenas a essas ações. Recursos de informações acessadas mais recentemente estão disponíveis no Console de gerenciamento da AWS e de maneira programática para permitir que você As incorpore aos fluxos de trabalho de infraestrutura e ferramentas automatizadas.
+ **Considere [registrar em log eventos de dados no AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** por padrão, o CloudTrail não registra eventos de dados em log, como atividades em nível de objeto do Amazon S3 (por exemplo, `GetObject` e `DeleteObject`) ou atividades de tabela do Amazon DynamoDB (por exemplo, `PutItem` e `DeleteItem`). Considere ativar o registro em log desses eventos para determinar quais usuários e perfis precisam acessar objetos do Amazon S3 ou itens de tabelas do DynamoDB específicos.
## Recursos
**Documentos relacionados:**
+ [Conceder privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Remover credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [ O que é o AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Como trabalhar com políticas do](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ Registrar em log e monitorar no DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Usar o registro em log de eventos do CloudTrail para buckets e objetos do Amazon S ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ Obter relatórios de credenciais da sua Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Vídeos relacionados:**
+ [Torne-se um mestre e políticas do IAM em no máximo 60 minutos](https://youtu.be/YQsK4MtsELU)
+ [Separação de deveres, privilégio mínimo, delegação e CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022: Mergulho profundo no AWS Identity and Access Management (IAM) ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 Definir barreiras de proteção de permissões para sua organização
Use barreiras de proteção de permissões para reduzir o escopo das permissões disponíveis que podem ser concedidas a entidades principais. A cadeia de avaliação da política de permissões inclui suas grades de proteção para determinar as *permissões efetivas* de uma entidade principal ao tomar decisões de autorização. Você pode definir barreiras de proteção usando uma abordagem baseada em camadas. Aplique algumas barreiras de proteção de maneira abrangente em toda a organização e outras de forma detalhada às sessões de acesso temporário.
**Resultado desejado:** você obtém um isolamento claro dos ambientes usando Contas da AWS sparapdpas. As políticas de controle de serviços (SCPs) são usadas para definir barreiras de proteção de permissões em toda a organização. As barreiras de proteção mais amplas são definidas nos níveis hierárquicos mais próximos da raiz da sua organização e as barreiras de proteção mais rígidas são definidas mais perto do nível das contas individuais.
Quando aceitas, as políticas de recursos definem as condições que uma entidade principal deve satisfazer para obter acesso a um recurso. As políticas de recursos também abrangem o conjunto de ações permitidas, quando apropriado. Os limites de permissão são impostos às entidades principais que gerenciam as permissões da workload, delegando o gerenciamento de permissões aos proprietários de workload individuais.
**Práticas comuns que devem ser evitadas:**
+ Criar Contas da AWS-membro dentro de uma [organização da AWS](https://aws.amazon.com/organizations/), mas não usar SCPs para restringir o uso e as permissões disponíveis para suas credenciais de raiz.
+ Atribuir permissões com base em privilégio mínimo, mas não colocar barreiras de proteção no conjunto máximo de permissões que podem ser concedidas.
+ *Confiar na base de *negação implícita* do AWS IAM para restringir as permissões, confiando que as políticas não concederão uma permissão explícita* indesejada.
+ Executar vários ambientes de workload na mesma Conta da AWS e confiar em mecanismos como VPCs, tags ou políticas de recursos para impor limites de permissão.
**Benefícios de implementar esta prática recomendada:** as barreiras de proteção de permissões ajudam a criar confiança de que permissões indesejadas não podem ser concedidas, mesmo quando uma política de permissão tenta fazer isso. Isso pode simplificar a definição e o gerenciamento de permissões, reduzindo o escopo máximo das permissões que precisam ser consideradas.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Recomendamos usar uma abordagem baseada em camadas para definir barreiras de proteção de permissões para sua organização. Essa abordagem reduz sistematicamente o conjunto máximo de permissões possíveis à medida que camadas adicionais são aplicadas. Isso ajuda você a conceder acesso com base no princípio de privilégio mínimo, reduzindo o risco de acesso indesejado devido à configuração incorreta de alguma política.
A primeira etapa para estabelecer barreiras de proteção de permissões é isolar workloads e ambientes em Contas da AWS separadas. As entidades principais de uma conta não podem acessar recursos em outra conta sem permissão explícita para fazer isso, mesmo quando as duas contas estão na mesma organização da AWS ou na mesma [unidade organizacional (UO)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html). Você pode usar UOs para agrupar contas que deseja administrar como uma única unidade.
A próxima etapa é reduzir o conjunto máximo de permissões que você pode conceder às entidades principais nas contas-membro da sua organização. Você pode usar [políticas de controle de serviço (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) para essa finalidade, as quais podem ser aplicadas a uma UO ou a uma conta. As SCPs podem impor controles de acesso comuns, como restringir o acesso a determinadas Regiões da AWS, ajudar a impedir a exclusão de recursos ou desabilitar ações de serviço possivelmente arriscadas. As SCPs que você aplica à raiz da sua organização afetam apenas as contas-membro, mas não a conta de gerenciamento. As SCPs regem apenas as entidades principais da sua organização. As SCPs não regem entidades principais externas à sua organização que estão acessando seus recursos.
Se você estiver usando o [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html), poderá aproveitar os [controles](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) e as [zonas de pouso](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) como base para as barreiras de proteção de permissões e ambiente de várias contas. As zonas de pouso fornecem um ambiente básico seguro e pré-configurado com contas separadas para diferentes workloads e aplicações. As barreiras de proteção impõem controles obrigatórios sobre segurança, operações e conformidade por meio de uma combinação de políticas de controle de serviços (SCPs), regras do AWS Config e outras configurações. No entanto, ao usar barreiras de proteção e zonas de pouso do Control Tower com as SCPs personalizadas da organização, é crucial seguir as práticas recomendadas descritas na documentação da AWS para evitar conflitos e garantir a governança adequada. Consulte a [orientação do AWS Control Tower para o AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html) a fim de obter recomendações detalhadas sobre o gerenciamento de SCPs, contas e unidades organizacionais (OUs) em um ambiente do Control Tower.
Ao aderir a essas diretrizes, você pode aproveitar com eficácia as barreiras de proteção e zonas de pouso do Control Tower e as SCPs personalizadas, ao mesmo tempo em que mitiga possíveis conflitos e garante a governança e o controle adequados sobre seu ambiente de várias contas da AWS.
Outra etapa é usar [políticas de recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) para definir o escopo das ações disponíveis que você pode realizar nos recursos por elas governados, juntamente com quaisquer condições que o diretor interino deva atender. Isso pode ser tão amplo quanto permitir todas as ações, desde que a entidade principal faça parte da sua organização (usando a [chave de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID), ou tão granular quanto permitir apenas ações específicas de um perfil do IAM específico. É possível adotar uma abordagem semelhante com as condições das políticas de confiança de perfis do IAM. Se uma política de confiança de recursos ou perfis nomear explicitamente uma entidade principal na mesma conta que o perfil ou o recurso por ela governado, essa entidade principal não precisará de uma política do IAM anexada que conceda as mesmas permissões. Se a entidade principal estiver em uma conta diferente da conta do recurso, ela precisará de uma política do IAM anexada que conceda essas permissões.
Muitas vezes, uma equipe de workload quer gerenciar as permissões exigidas pela workload em questão. Isso, por sua vez, pode exigir que a equipe crie políticas de permissão e perfis do IAM. É possível capturar o escopo máximo de permissões que a equipe pode conceder em um [limite de permissão do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) e associar esse documento a um perfil do IAM que a equipe pode usar para gerenciar seus perfis do IAM e permissões. Essa abordagem pode proporcionar à equipe a flexibilidade para concluir o trabalho e, ao mesmo tempo, reduzir os riscos de acesso administrativo ao IAM.
Uma etapa mais granular é implementar técnicas de *gerenciamento de acesso privilegiado* (PAM) e *gerenciamento de acesso elevado temporário* (TEAM). Um exemplo de PAM é exigir que as entidades principais realizem a autenticação multifator antes de executar ações privilegiadas. Para obter mais informações, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html). O TEAM exige uma solução que gerencie a aprovação e o período durante o qual uma entidade principal pode ter acesso elevado. Uma abordagem é adicionar temporariamente a entidade principal à política de confiança de perfis referente a um perfil do IAM que tenha acesso elevado. Outra abordagem é, em operação normal, reduzir o escopo das permissões concedidas a uma entidade principal por um perfil do IAM usando uma [política de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) e, em seguida, suspender temporariamente essa restrição durante o período aprovado. Para saber mais sobre as soluções validadas pela AWS e por parceiros selecionados, consulte [Acesso elevado temporário](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html).
### Etapas de implementação
1. Isole workloads e ambientes em Contas da AWS separadas.
1. Use SCPs para reduzir o conjunto máximo de permissões que podem ser concedidas às entidades principais nas contas dos membros da sua organização.
1. Ao definir SCPs para reduzir o conjunto máximo de permissões que podem ser concedidas às entidades principais nas contas dos membros da sua organização, você pode escolher entre uma abordagem de *lista de permissões ou listas* de *negação*. A estratégia da lista de permissões especifica explicitamente o acesso permitido e bloqueia implicitamente todos os outros acessos. A estratégia da lista de negação especifica explicitamente o acesso não permitido e permite todos os outros acessos por padrão. Ambas as estratégias têm suas vantagens e desvantagens, e a escolha apropriada depende dos requisitos específicos e do modelo de risco de sua organização. Para obter mais detalhes, consulte [Estratégia para usar SCPs.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html)
1. Além disso, analise os [exemplos de políticas de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) para entender como construir SCPs de forma eficaz.
1. Use políticas de recursos do IAM para reduzir o escopo e especificar as condições das ações permitidas nos recursos. Use condições nas políticas de confiança de perfis do IAM para criar restrições aos perfis assumidos.
1. Atribua limites de permissão do IAM a perfis do IAM que as equipes de workload podem usar para gerenciar perfis e permissões do IAM de suas próprias workloads.
1. Avalie as soluções de PAM e TEAM com base em suas necessidades.
## Recursos
**Documentos relacionados:**
+ [Perímetro de dados na AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [Estabelecer barreiras de proteção para permissões usando perímetros de dados](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [Lógica da avaliação de política](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**Exemplos relacionados:**
+ [Exemplos de políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**Ferramentas relacionadas:**
+ [AWS Solução da : gerenciamento de acesso elevado temporário](https://aws-samples.github.io/iam-identity-center-team/)
+ [Soluções validadas de parceiros de segurança para TEAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 Gerenciar o acesso com base no ciclo de vida
Monitore e ajuste as permissões concedidas às entidades principais (usuários, funções e grupos) durante todo o ciclo de vida em sua organização. Ajuste as associações de grupo à medida que os usuários mudarem de função e remova o acesso quando um usuário sair da organização.
**Resultado desejado:** você monitora e ajusta as permissões em todo o ciclo de vida dos diretores da organização, reduzindo o risco de privilégios desnecessários. Você concede acesso apropriado ao criar um usuário. Você modifica o acesso à medida que as responsabilidades do usuário mudam e remove o acesso quando o usuário não está mais ativo ou sai da organização. Você gerencia centralmente as alterações em seus usuários, perfis e grupos. Você usa a automação para propagar alterações em seus ambientes da AWS.
**Práticas comuns que devem ser evitadas:**
+ Conceder privilégios de acesso excessivos ou amplos às identidades com antecedência, para além daqueles exigidos inicialmente.
+ Não revisar nem ajustar os privilégios de acesso à medida que as funções e responsabilidades das identidades mudam ao longo do tempo.
+ Manter identidades inativas ou encerradas com privilégios de acesso ativos. Isso aumenta o risco de acesso não autorizado.
+ Não aproveitar a automação para gerenciar o ciclo de vida das identidades.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Gerencie e ajuste cuidadosamente os privilégios de acesso concedidos às identidades (como usuários, funções, grupos) durante todo o ciclo de vida. Esse ciclo de vida inclui a fase inicial de integração, mudanças contínuas em perfis e responsabilidades e eventual desligamento ou rescisão. Gerencie proativamente o acesso com base no estágio do ciclo de vida para manter o nível de acesso adequado. Siga o princípio de privilégio mínimo para reduzir o risco de privilégios de acesso excessivos ou desnecessários.
Você pode gerenciar o ciclo de vida dos usuários do IAM diretamente na Conta da AWS ou por meio de federação no provedor de identidades de seu quadro de funcionários para o [Centro de Identidade do IAM da AWS](https://aws.amazon.com/iam/identity-center/). Para usuários do IAM, é possível criar, modificar e excluir usuários e as respectivas permissões associadas na Conta da AWS. No caso de usuários federados, você pode usar o Centro de Identidade do IAM para gerenciar o respectivo ciclo de vida sincronizando as informações de usuários e grupos do provedor de identidades da sua organização por meio do protocolo [System for Cross-Domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) (SCIM).
O SCIM é um protocolo de padrão aberto para provisionamento e desprovisionamento automatizados de identidades de usuários em diferentes sistemas. Ao integrar seu provedor de identidades ao Centro de Identidade do IAM usando o SCIM, você pode sincronizar automaticamente as informações do usuário e do grupo para ajudar a validar que os privilégios de acesso sejam concedidos, modificados ou revogados com base nas alterações na fonte de identidade autorizada da sua organização.
À medida que as funções e responsabilidades dos funcionários mudam em sua organização, ajuste os respectivos privilégios de acesso de maneira correspondente. Você pode usar os conjuntos de permissões do Centro de Identidade do IAM para definir diferentes funções ou responsabilidades de trabalho e associá-las a políticas e permissões apropriadas do IAM. Quando a função de um funcionário muda, você pode atualizar o conjunto de permissões atribuído para refletir as novas responsabilidades. Verifique se ele tem o acesso necessário e segue o princípio de privilégio mínimo.
### Etapas de implementação
1. Defina e documente um processo de ciclo de vida do gerenciamento de acesso, incluindo procedimentos para concessão de acesso inicial, revisões periódicas e desligamento.
1. Implemente [perfis, grupos e limites de permissões do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) para gerenciar o acesso coletivamente e impor os níveis máximos de acesso permitidos.
1. Integre-se a um [provedor de identidades federado](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (como Microsoft Active Directory, Okta, Ping Identity) como fonte confiável para uso de informações de usuários e grupos usando o Centro de Identidade do IAM.
1. Use o protocolo [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) para sincronizar informações de usuários e grupos do provedor de identidades com o repositório de identidades do Centro de Identidade do IAM.
1. Crie [conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) no Centro de Identidade do IAM que representem diferentes cargos ou responsabilidades em sua organização. Defina as políticas e permissões apropriadas do IAM para cada conjunto de permissões.
1. Implemente análises regulares de acesso, revogação imediata do acesso e melhoria contínua do processo do ciclo de vida do gerenciamento de acesso.
1. Ofereça treinamento e conhecimento aos funcionários sobre as práticas recomendadas de gerenciamento de acesso.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP04 Confiar em um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**Documentos relacionados:**
+ [Gerenciar sua fonte de identidade](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [Gerenciar identidades no Centro de Identidade do IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [Como usar o AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [Geração de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**Vídeos relacionados:**
+ [AWS re:Inforce 2023: Gerenciar o acesso elevado temporário com o AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022: Simplificar o acesso da sua força de trabalho com o Centro de Identidade do IAM](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022: Aproveitar o poder das políticas do IAM e controlar permissões com o Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 Analisar o acesso público e entre contas
Monitore continuamente as descobertas que destacam o acesso público e entre contas. Limite o acesso público e o acesso entre contas somente aos recursos específicos que exigem esse tipo de acesso.
**Resultado desejado:** saiba quais de seus recursos da AWS são compartilhados e com quem. Monitore e audite continuamente seus recursos compartilhados para verificar se eles são compartilhados apenas com entidades principais autorizadas.
**Práticas comuns que devem ser evitadas:**
+ Não manter um inventário dos recursos compartilhados.
+ Não seguir um processo de aprovação do acesso público ou entre contas aos recursos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo
## Orientação para implementação
Se a sua conta estiver no AWS Organizations, você poderá conceder acesso aos recursos à toda a organização, a unidades organizacionais específicas ou a contas individuais. Se sua conta não for membro de uma organização, você poderá compartilhar recursos com contas individuais. Você pode conceder acesso direto entre contas usando políticas baseadas em recursos — por exemplo, políticas de [bucket do Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) — ou permitindo que um principal em outra conta assuma uma função do IAM em sua conta. Ao utilizar políticas de recursos, verifique se o acesso é concedido apenas a entidades principais autorizadas. Defina um processo para aprovar todos os recursos que devem ser acessíveis publicamente.
O [AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) [segurança comprovada](https://aws.amazon.com/security/provable-security/) para identificar todos os caminhos de acesso a um recurso de fora de sua conta. Ele revisa as políticas de recursos continuamente e relata descobertas de acesso público e entre contas para facilitar a análise de acesso potencialmente amplo. Considere a configuração do IAM Access Analyzer com o AWS Organizations para verificar se você tem visibilidade em todas as suas contas. O IAM Access Analyzer também permite que você [visualize as descobertas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) antes de implantar permissões de recursos. Isso permite validar que as alterações de política concedam apenas o acesso público e entre contas pretendido aos seus recursos. Ao designar para acesso a várias contas, você pode usar [políticas de confiança](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) para controlar em quais casos um perfil pode ser assumido. Por exemplo, você pode usar a [chave de condição `PrincipalOrgId` para negar uma tentativa de assumir uma função fora da sua AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/).
O [AWS Config pode relatar recursos](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) que estão configurados incorretamente e, por meio de verificações de políticas do AWS Config, pode detectar recursos com acesso público configurado. Serviços como o [AWS Control Tower](https://aws.amazon.com/controltower/) e o [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) simplificam as barreiras de proteção e as verificações de implantação em um AWS Organizations para identificar e corrigir recursos publicamente expostos. Por exemplo, AWS Control Tower tem uma barreira de proteção gerenciada que pode detectar se algum [snapshot do Amazon EBS pode ser restaurado por Contas da AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).
### Etapas de implementação
+ **Considere usar o [AWS Config para AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** o AWS Config permite agregar descobertas de várias contas em um AWS Organizations na conta de um administrador delegado. Isso fornece uma visão abrangente e permite que você [implante Regras do AWS Config em várias contas para detectar recursos acessíveis ao público](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html).
+ **Configure o AWS Identity and Access Management Access Analyzer:** O IAM Access Analyzer ajuda você a identificar os recursos em sua organização e suas contas, como buckets do Amazon S3 ou perfis do IAM, que são [compartilhados com uma entidade externa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Use a remediação automática no AWS Config para responder a mudanças na configuração de acesso público dos buckets do Amazon S3:** [você pode ativar automaticamente as configurações de bloqueio de acesso público para buckets do Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
+ **Implemente monitoramento e alertas para identificar se os buckets do Amazon S3 se tornaram públicos:** você deve ter [monitoramento e alertas](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) em vigor para identificar quando o Bloqueio de Acesso Público do Amazon S3 está desativado e se os buckets do Amazon S3 se tornam públicos. Além disso, se você estiver usando o AWS Organizations, poderá criar uma [política de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) que impeça alterações nas políticas de acesso público do Amazon S3. O [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) procura buckets do Amazon S3 que têm permissões de acesso livre. As permissões de bucket que concedem acesso de upload ou exclusão a todos criam possíveis problemas de segurança, pois permitem que qualquer pessoa adicione, modifique ou remova itens em um bucket. A verificação do Trusted Advisor examina as permissões de bucket explícitas e as políticas de bucket associadas que podem substituir as permissões de bucket. Você também pode utilizar o AWS Config para monitorar seus buckets do Amazon S3 para acesso público. Para obter mais informações, consulte [Como usar o AWS Config para monitorar e responder a buckets do Amazon S3 que permitem acesso público](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
Ao analisar os controles de acesso dos buckets do Amazon S3, é importante considerar a natureza dos dados armazenados neles. O [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) é um serviço desenvolvido para ajudar você a descobrir e proteger dados confidenciais, como informações de identificação pessoal (PII), informações de saúde protegidas (PHI) e credenciais, como chaves privadas ou chaves de acesso da AWS.
## Recursos
**Documentos relacionados:**
+ [Usar o AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [Biblioteca de controles do AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [Padrão de práticas recomendas de segurança básica da AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config Regras gerenciadas do](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [Referência de verificação do AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [Monitorar resultados da verificação do AWS Trusted Advisor com o Amazon EventBridge](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [Habilitar regras do AWS Config em todas as contas na sua organização](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config e AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [Disponibilizar publicamente sua AMI para uso no Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**Vídeos relacionados:**
+ [Práticas recomendadas para proteger seu ambiente de várias contas](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Mergulho profundo no IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 Compartilhar recursos com segurança em sua organização
À medida que o número de workloads aumenta, talvez você precise compartilhar o acesso aos recursos nessas workloads ou fornecer os recursos várias vezes nas contas. É possível usar constructos para compartimentalizar seu ambiente, por exemplo, para ter ambientes de desenvolvimento, teste e produção. No entanto, ter constructos de separação não impede que você compartilhe com segurança. Ao compartilhar componentes que se sobrepõem, você pode reduzir a sobrecarga operacional e possibilitar uma experiência consistente sem precisar adivinhar o que ignorou ao criar o mesmo recurso várias vezes.
**Resultado desejado:** minimize o acesso não intencional usando métodos seguros para compartilhar recursos em sua organização e ajudar na sua iniciativa de prevenção de perda de dados. Reduza sua sobrecarga operacional em comparação com o gerenciamento de componentes individuais, reduza os erros gerados pela criação manual do mesmo componente várias vezes e aumente a escalabilidade das suas workloads. É possível se beneficiar da redução de tempo para a resolução em cenários de falhas em vários pontos e aumentar sua confiança na determinação de quando um componente não é mais necessário. Para obter recomendações sobre a análise de recursos compartilhados externamente, consulte [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md).
**Práticas comuns que devem ser evitadas:**
+ Ausência de um processo para monitorar de forma contínua e alertar automaticamente sobre o compartilhamento externo inesperado.
+ Ausência de referência sobre o que deve ou não ser compartilhado.
+ Adotar como padrão uma política amplamente aberta em vez de compartilhar explicitamente quando necessário.
+ Criar manualmente recursos básicos que se sobrepõem quando necessário.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Projete seus controles e padrões de acesso para reger o consumo de recursos compartilhados com segurança e somente com entidades confiáveis. Monitore recursos compartilhados e revise o acesso a eles de forma contínua e seja alertado sobre o compartilhamento inadequado ou inesperado. Revise [Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) para saber como estabelecer uma governança para limitar o acesso externo somente aos recursos que o exijam e estabelecer um processo para monitorar continuamente e enviar alertas de forma automática.
O compartilhamento entre contas no AWS Organizations é aceito [por vários serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), como [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) e [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Esses serviços possibilitam compartilhar os dados em uma conta central, acessá-los ou gerenciar recursos e dados dessa conta. Por exemplo, o AWS Security Hub CSPM pode transferir as descobertas de contas individuais para uma conta central onde é possível visualizar todas elas. O AWS Backup pode fazer um backup de um recurso e compartilhá-lo entre contas. É possível usar o [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) para compartilhar outros recursos comuns, como [sub-redes de VPC e anexos do gateway de trânsito](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) ou [pipelines do Amazon SageMaker AI](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker).
Para restringir sua conta para compartilhar apenas recursos dentro de sua organização, use [políticas de controle de serviços (SCPs)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) para impedir o acesso a entidades externas. Ao compartilhar recursos, combine controles baseados em identidade e controles de rede para [criar um perímetro de dados para sua organização](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) e ajudar a se proteger contra acesso não intencional. Um perímetro de dados é um conjunto de barreiras de proteção preventivas que ajudam a garantir que apenas suas identidades confiáveis acessem recursos confiáveis das redes esperadas. Esses controles impõem limites apropriados sobre quais recursos podem ser compartilhados e impedir o compartilhamento ou a exposição de recursos que não devem ser permitidos. Por exemplo, como parte do seu perímetro de dados, você pode usar as políticas de endpoint da VPC e a condição `AWS:PrincipalOrgId` para garantir que as identidades que acessam seus buckets do Amazon S3 pertençam à sua organização. É importante observar que as [SCPs não se aplicam a perfis vinculados a serviços ou entidades principais de serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
Ao usar o Amazon S3, [desative as ACLs do seu bucket do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) e use as políticas do IAM para definir o controle de acesso. Para [restringir o acesso a uma origem do Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) do [Amazon CloudFront](https://aws.amazon.com/cloudfront/), migre da identidade do acesso de origem (OAI) para um controle de acesso de origem (OAC) compatível com recursos adicionais, incluindo criptografia do lado do servidor com o [AWS Key Management Service](https://aws.amazon.com/kms/).
Em alguns casos, convém permitir o compartilhamento de recursos fora de sua organização ou conceder a terceiros acesso aos seus recursos. Para obter recomendações sobre o gerenciamento de permissões para compartilhar recursos externamente, consulte [Gerenciamento de permissões](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html).
### Etapas de implementação
1. **Use o AWS Organizations:** O AWS Organizations é um serviço de gerenciamento de contas que permite consolidar várias Contas da AWS em uma organização criada e gerencia centralmente por você. É possível agrupar suas contas em unidades organizacionais (UOs) e anexar políticas diferentes a cada UO a fim de ajudar a atender às suas necessidades orçamentárias, de segurança e conformidade. Também é possível controlar como serviços de inteligência artificial (IA) e machine learning (ML) da AWS podem coletar e armazenar dados e usar o gerenciamento de várias contas dos serviços da AWS integrados ao Organizations.
1. **Integre o AWS Organizations com serviços da AWS:** quando você usa um serviço da AWS para executar tarefas em seu nome nas contas-membro da organização, o AWS Organizations cria um perfil vinculado ao serviço (SLR) do IAM para esse serviço em cada conta-membro. Você deve gerenciar o acesso confiável usando o Console de gerenciamento da AWS, as APIs da AWS ou a AWS CLI. Para obter recomendações sobre como ativar o acesso confiável, consulte [Usar o AWS Organizations com outros serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) e [Serviços da AWS que você pode usar com o Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. **Estabeleça um perímetro de dados:** um perímetro de dados fornece um limite claro de confiança e propriedade. Na AWS, costuma ser representado como sua organização na AWS gerenciada pelo AWS Organizations, com quaisquer redes ou sistemas on-premises que acessam os recursos da AWS. O objetivo do perímetro de dados é garantir que o acesso seja permitido se a identidade e o recurso forem confiáveis e a rede for esperada. No entanto, estabelecer um perímetro de dados não é uma abordagem única. Avalie e adote os objetivos de controle descritos no [whitepaper sobre como criar um perímetro na AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html) com base em modelos e requisitos de risco de segurança específicos. Você deve considerar cuidadosamente sua postura de risco exclusiva e implementar os controles de perímetro que se alinhem às suas necessidades de segurança.
1. **Use o compartilhamento de recursos nos serviços da AWS e restrinja adequadamente:** muitos serviços da AWS permitem compartilhar recursos com outra conta ou apontar para um recurso em outra conta, como [imagens de máquina da Amazon (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) e [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Restrinja a API `ModifyImageAttribute` para especificar as contas confiáveis com as quais a AMI será compartilhada. Especifique a condição `ram:RequestedAllowsExternalPrincipals` ao usar o AWS RAM para restringir o compartilhamento somente à sua organização, ajudando assim a impedir o acesso de identidades não confiáveis. Para orientações e recomendações, consulte [Compartilhamento de recursos e destinos externos](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html).
1. **Use AWS RAM para compartilhar com segurança em uma conta ou com outras Contas da AWS:** O [AWS RAM](https://aws.amazon.com/ram/) ajuda você a compartilhar com segurança os recursos criados com perfis e usuários em sua conta e em outras Contas da AWS. Em um ambiente de várias contas, o AWS RAM permite criar um recurso uma vez e compartilhá-lo com outras contas. Essa abordagem ajuda a reduzir sua sobrecarga operacional enquanto oferece consistência, visibilidade e capacidade de auditoria por meio de integrações com o Amazon CloudWatch e o AWS CloudTrail, o que você não recebe ao utilizar o acesso entre contas.
Se você tiver recursos que compartilhou anteriormente usando uma política baseada em recursos, poderá usar a [API `PromoteResourceShareCreatedFromPolicy`](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) ou equivalente para promover o compartilhamento de recursos em um compartilhamento de recursos do AWS RAM completo.
Em alguns casos, convém realizar etapas adicionais para compartilhar recursos. Por exemplo, para compartilhar um snapshot criptografado, é necessário [compartilhar uma chave do AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key).
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 Compartilhar recursos com terceiros de forma segura](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 Criar camadas de rede](sec_network_protection_create_layers.md)
**Documentos relacionados:**
+ [O proprietário do bucket concede permissão entre contas para objetos que não possui](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Como usar políticas de confiança com o IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Como criar um perímetro de dados na AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Como usar um ID externo ao conceder acesso aos seus recursos da AWS para terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Serviços da AWS que você pode usar com o AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Estabelecer um perímetro de dados na AWS: permitir que somente identidades confiáveis acessem os dados da empresa ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**Vídeos relacionados:**
+ [Acesso granular com o AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Como proteger seu perímetro de dados com endpoints da VPC](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Estabelecer um perímetro de dados na AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**Ferramentas relacionadas:**
+ [Exemplos de políticas de perímetro de dados ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 Compartilhar recursos com terceiros de forma segura
A segurança de seu ambiente de nuvem não para na sua organização. Sua organização pode contar com terceiros para gerenciar uma parte de seus dados. O gerenciamento de permissões para o sistema gerenciado por terceiros deve seguir a prática de acesso just-in-time utilizando o princípio de privilégio mínimo com credenciais temporárias. Ao trabalhar em parceria com terceiros, é possível reduzir o escopo do impacto e o risco de acesso acidental.
**Resultado desejado:** você evita usar credenciais de longo prazo do AWS Identity and Access Management (IAM), como chaves de acesso e chaves secretas, pois elas representam um risco de segurança se usadas indevidamente. Em vez disso, você usa perfis do IAM e credenciais temporárias para melhorar sua postura de segurança e minimizar a sobrecarga operacional do gerenciamento de credenciais de longo prazo. Ao conceder acesso a terceiros, use um identificador universalmente exclusivo (UUID) como ID externo na política de confiança do IAM e mantenha as políticas do IAM anexadas ao perfil sob seu controle para garantir privilégio mínimo de acesso. Para conferir recomendações sobre a análise de recursos compartilhados externamente, consulte [SEC03-BP07 Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html).
**Práticas comuns que devem ser evitadas:**
+ Utilizar a política de confiança padrão do IAM sem nenhuma condição.
+ Utilizar credenciais e chaves de acesso de longo prazo do IAM.
+ Reutilizar IDs externos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Talvez você deseje permitir o compartilhamento de recursos fora do AWS Organizations ou conceder a terceiros acesso à sua conta. Por exemplo, um parceiro (terceiro) pode oferecer uma solução de monitoramento que precise acessar recursos em sua conta. Nesses casos, crie um perfil entre contas do IAM somente com os privilégios necessários para o parceiro. Além disso, defina uma política de confiança usando a [condição de ID externo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). Ao utilizar um ID externo, você ou o parceiro pode gerar um ID exclusivo para cada cliente, terceiro ou locação. O ID exclusivo não deve ser controlado por ninguém, exceto por você, depois de criado. O parceiro deve implementar um processo para relacionar o ID externo ao cliente de forma segura, auditável e reproduzível.
Também é possível usar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para gerenciar perfis do IAM para aplicações fora da AWS que usam APIs da AWS.
Se o parceiro não precisar mais de acesso ao seu ambiente, remova o perfil. Evite fornecer credenciais de longo prazo para terceiros. Conheça outros serviços da AWS que oferecem suporte ao compartilhamento, como a permissão do AWS Well-Architected Tool ao [compartilhamento de uma workload](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) com outras Contas da AWS e o [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html), que ajuda a compartilhar com segurança um recurso da AWS que você possui com outras contas.
### Etapas de implementação
1. **Use perfis entre contas para fornecer acesso a contas externas.** Os [perfis entre contas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) reduzem a quantidade de informações confidenciais armazenadas por contas externas e por terceiros para atender os clientes. Os perfis entre contas possibilitam que você conceda acesso aos recursos da AWS em sua conta de maneira segura a terceiros, como parceiros da AWS ou outras contas em sua organização, ao mesmo tempo que mantém a capacidade de gerenciar e auditar esse acesso. O parceiro pode oferecer serviço a você a partir de uma infraestrutura híbrida ou, como alternativa, extrair dados de um local externo. O [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) ajuda você a permitir que workloads de terceiros interajam com segurança com suas workloads da AWS e a reduzir ainda mais a necessidade de credenciais de longo prazo.
Você não deve usar credenciais ou chaves de acesso de longo prazo associadas a usuários para conceder acesso a contas externas. Em vez disso, utilize perfis entre contas para conceder acesso entre contas.
1. **Realize a devida diligência e garanta o acesso seguro para provedores de SaaS de terceiros.** Ao compartilhar recursos com provedores de SaaS de terceiros, realize a devida diligência para garantir que eles tenham uma abordagem segura e responsável para acessar os recursos da AWS. Avalie seu modelo de responsabilidade compartilhada para entender quais medidas de segurança eles fornecem e o que está sob sua responsabilidade. Garanta que o provedor de SaaS tenha um processo seguro e auditável para acessar seus recursos, incluindo o uso de [IDs externos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) e princípios de acesso com privilégios mínimos. O uso de IDs externos ajuda a resolver o [problema de representante confuso](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/).
Implemente controles de segurança para garantir acesso seguro e aderir ao princípio de privilégio mínimo ao conceder acesso a provedores de SaaS de terceiros. Isso pode incluir o uso de IDs externos, identificadores universalmente exclusivos (UUIDs) e políticas de confiança do IAM que limitam o acesso somente ao estritamente necessário. Trabalhe em estreita colaboração com o provedor de SaaS para estabelecer mecanismos de acesso seguro, revisar regularmente o acesso deles aos recursos da AWS e realizar auditorias para garantir a conformidade com os requisitos de segurança.
1. **Deprecie as credenciais de longo prazo fornecidas pelo cliente.** Deprecie o uso de credenciais de longo prazo e use perfis entre clientes ou o IAM Roles Anywhere. Se você precisar utilizar credenciais de longo prazo, estabeleça um plano para migrar para um acesso baseado em perfil. Para obter detalhes sobre o gerenciamento de chaves, consulte [Gerenciamento de identidades](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html). Trabalhe também com a equipe da sua Conta da AWS e o parceiro para estabelecer um runbook de mitigação de riscos. Para conferir recomendações sobre como responder e mitigar o impacto potencial de um incidente de segurança, consulte [Resposta a incidentes](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html).
1. **Verifique se a configuração possui recomendações ou é automatizada.** O ID externo não é tratado como segredo, mas ele não pode ser um valor facilmente dedutível, como um número de telefone, um nome ou o ID da conta. Torne o ID externo um campo somente leitura de forma que o ID externo não possa ser alterado com o fim de representar a configuração.
Você ou o parceiro podem gerar o ID externo. Defina um processo para determinar quem é responsável pela geração do ID. Seja qual for a entidade que crie o ID externo, o parceiro impõe a exclusividade e os formatos de forma consistente entre os clientes.
A política criada para acesso entre contas em suas contas deve seguir o [princípio de privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). O terceiro deve fornecer um documento de política de perfil ou um mecanismo de configuração automatizada que utilize um modelo do AWS CloudFormation ou um equivalente para você. Isso reduz a chance de erros associados à criação manual de políticas e oferece uma trilha auditável. Para obter mais informações sobre como usar um modelo do AWS CloudFormation para criar funções entre contas, consulte [Funções entre contas](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/).
O terceiro deve fornecer um mecanismo de configuração automatizado e auditável. No entanto, ao utilizar o documento de política de perfis que descreve o acesso necessário, você deve automatizar a configuração do perfil. Com um modelo do AWS CloudFormation ou equivalente, monitore alterações com detecção de desvios como parte da prática de auditoria.
1. **Considere as alterações.** Sua estrutura de contas, sua necessidade de terceiros ou a oferta de serviço pode sofrer alterações. Você deve antecipar alterações e falhas e planejar adequadamente com as pessoas, o processo e a tecnologia corretos. Audite o nível de acesso que você concede periodicamente e implemente métodos de detecção para ser alertado sobre alterações inesperadas. Monitore e audite o uso do perfil e o datastore dos IDs externos. Você deve estar preparado para revogar o acesso de terceiros, seja de forma temporária ou permanente, como resultado de alterações ou padrões de acesso inesperados. Além disso, meça o impacto de sua operação de revogação, inclusive o tempo para realizá-la, as pessoas envolvidas, o custo e o impacto de outros recursos.
Para obter recomendações sobre métodos de detecção, consulte as [práticas recomendadas de detecção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html).
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC02-BP02 Usar credenciais temporárias](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 Definir barreiras de proteção de permissões para sua organização](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 Detecção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documentos relacionados:**
+ [O proprietário do bucket concede permissão entre contas para objetos que não possui](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Como usar políticas de confiança com perfis do IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Delegar acesso entre Contas da AWS usando perfis do IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [Como faço para acessar recursos em outra Conta da AWS usando o IAM?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Lógica de avaliação de política entre contas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [Como usar um ID externo ao conceder acesso aos seus recursos da AWS para terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Coletar informações de recursos da AWS CloudFormation criados em contas externas com recursos personalizados](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Usar IDs externos com segurança para acessar contas da AWS pertencentes a terceiros](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Estender os perfis do IAM para workloads fora do IAM com o IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**Vídeos relacionados:**
+ [Como faço para permitir que usuários ou perfis em uma Conta da AWS separada tenham acesso à minha Conta da AWS?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [Centro de Conhecimentos da AWS Live: Práticas recomendadas e decisões de design do IAM](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**Exemplos relacionados:**
+ [Configurar o acesso entre contas ao Amazon DynamoDB](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [Ferramenta de consulta de rede do AWS STS](https://github.com/aws-samples/aws-sts-network-query-tool)