# SEC 3. Como você gerencia as permissões para pessoas e máquinas?
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.
**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/framework/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/framework/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/framework/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)