

# Segurança
<a name="a-security"></a>

O pilar Segurança refere-se à capacidade de proteger dados, sistemas e ativos para utilizar as tecnologias de nuvem para melhorar sua segurança. Você pode encontrar orientações prescritivas sobre implementação no [whitepaper Pilar de segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp). 

**Topics**
+ [Fundamentos de segurança](a-sec-security.md)
+ [Gerenciamento de identidade e acesso](a-identity-and-access-management.md)
+ [Detecção](a-detective-controls.md)
+ [Proteção de infraestrutura](a-infrastructure-protection.md)
+ [Proteção de dados](a-data-protection.md)
+ [Resposta a incidentes](a-incident-response.md)
+ [Segurança de aplicações](a-appsec.md)

# Fundamentos de segurança
<a name="a-sec-security"></a>

**Topics**
+ [SEGURANÇA 1. Como operar com segurança sua workload?](sec-01.md)

# SEGURANÇA 1. Como operar com segurança sua workload?
<a name="sec-01"></a>

 Para operar sua workload com segurança, você deve aplicar as práticas recomendadas gerais a todas as áreas de segurança. Use os requisitos e os processos que você definiu em excelência operacional em nível de carga de trabalho e também organizacional e aplique-os a todas as áreas. Manter-se atualizado com as recomendações da AWS e do setor e a inteligência de ameaças ajuda você a desenvolver seu modelo de ameaças e objetivos de controle. A automação de processos, testes e validação de segurança permite que você escale suas operações de segurança. 

**Topics**
+ [SEC01-BP01 Separar as workloads usando contas](sec_securely_operate_multi_accounts.md)
+ [SEC01-BP02 Proteger as propriedades e o usuário raiz das contas](sec_securely_operate_aws_account.md)
+ [SEC01-BP03 Identificar e validar objetivos de controle](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 Manter-se atualizado sobre as ameaças à segurança](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 Manter-se atualizado com as recomendações de segurança](sec_securely_operate_updated_recommendations.md)
+ [SEC01-BP06 Automatizar testes e validação de controles de segurança em pipelines](sec_securely_operate_test_validate_pipeline.md)
+ [SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça](sec_securely_operate_threat_model.md)
+ [SEC01-BP08 Avaliar e implementar regularmente novos serviços e recursos de segurança](sec_securely_operate_implement_services_features.md)

# SEC01-BP01 Separar as workloads usando contas
<a name="sec_securely_operate_multi_accounts"></a>

 Estabeleça barreiras de proteção e isolamento entre workloads e ambientes (como de produção, desenvolvimento e teste) por meio de uma estratégia de várias contas. A separação em nível de conta é altamente recomendável, pois ela oferece um limite de isolamento robusto para segurança, faturamento e acesso. 

**Resultado desejado:** uma estrutura de conta que isola operações na nuvem, workloads não relacionadas e ambientes em contas separadas, aumentando a segurança em toda a infraestrutura de nuvem.

**Antipadrões comuns:**
+  Colocação de várias workloads não relacionadas com diferentes níveis de confidencialidade na mesma conta.
+  Estrutura de unidade organizacional (UO) definida de forma inadequada.

**Benefícios do estabelecimento desta prática recomendada:**
+  Redução do escopo de impacto se uma workload for acessada acidentalmente.
+  Governança central de acesso a serviços, recursos e regiões da AWS.
+  Manutenção da segurança da infraestrutura de nuvem com políticas e administração centralizada de serviços de segurança.
+  Criação de contas automatizada e processo de manutenção.
+  Auditoria centralizada da infraestrutura de conformidade e requisitos regulatórios.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 As Contas da AWS oferecem um limite de isolamento de segurança entre workloads ou recursos que operam em diferentes níveis de confidencialidade. Para utilizar esse limite de isolamento, a AWS oferece ferramentas para gerenciar em grande escala suas workloads de nuvem por meio de uma estratégia de várias contas. Para ter orientações sobre os conceitos, os padrões e a implementação de uma estratégia de várias contas na AWS, consulte [Organizar seu ambiente da AWS com o uso de várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). 

 Quando você tem várias Contas da AWS no gerenciamento central, elas devem ser organizadas em uma hierarquia definida por camadas de unidades organizacionais (UOs). Desse modo, os controles de segurança podem ser organizados e aplicados às UOs e às contas membros, estabelecendo controles preventivos consistentes nas contas membros da organização. Os controles de segurança são herdados, permitindo que você filtre as permissões disponíveis para as contas membros localizadas em níveis inferiores de uma hierarquia de UOs. Um bom design aproveita essa herança para reduzir o número e a complexidade das políticas de segurança necessárias para obter os controles de segurança desejados para cada conta membro. 

 O [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) e o [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) são dois serviços que você pode utilizar para implementar e gerenciar essa estrutura de várias contas em seu ambiente da AWS. O AWS Organizations possibilita organizar as contas em uma hierarquia definida por uma ou mais camadas de UOs, em que cada UO contém uma série de contas membros. As [políticas de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) permitem que o administrador da organização estabeleça controles preventivos detalhados nas contas membros, e o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) pode ser utilizado para estabelecer controles proativos e de detecção nessas contas. Muitos serviços da AWS [integram-se ao AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) para oferecer controles administrativos delegados e realizar tarefas específicas do serviço em todas as contas membros da organização. 

 Estruturado sobre o AWS Organizations, o [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) oferece práticas recomendadas de um clique para um ambiente da AWS de várias contas com uma [zona de pouso](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html). A zona de pouso é o ponto de entrada para o ambiente de várias contas estabelecido pelo Control Tower. O Control Tower oferece vários [benefícios](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/) em comparação com o AWS Organizations. Três benefícios que oferecem governança aprimorada de contas são: 
+  Barreiras de proteção de segurança obrigatórias e integradas que são aplicadas automaticamente às contas admitidas na organização. 
+  Barreiras de proteção opcionais que podem ser ativadas ou desativadas em determinado conjunto de UOs. 
+  O [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) oferece implantação automatizada de contas que contêm linhas de base aprovadas e opções de configuração em sua organização. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  **Projetar uma estrutura de unidade organizacional:** uma estrutura de unidade organizacional projetada adequadamente reduz o trabalho de gerenciamento necessário para criar e manter políticas de controle de serviços e outros controles de segurança. Sua estrutura de unidade organizacional deve estar [alinhada com as necessidades, a confidencialidade dos dados e a estrutura de workload de sua empresa](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/). 

1.  **Criar uma zona de pouso para seu ambiente de várias contas:** uma zona de pouso oferece uma base consistente de infraestrutura e segurança na qual sua organização pode desenvolver, executar e implantar workloads com rapidez. É possível usar uma [zona de pouso personalizada ou o AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html) para orquestrar seu ambiente. 

1.  **Estabelecer barreiras de proteção:** implemente barreiras de proteção consistentes para seu ambiente por meio da zona de pouso. O AWS Control Tower oferece uma lista de controles [obrigatórios](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html) e [opcionais](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html) que podem ser implantados. Os controles obrigatórios são implantados automaticamente na implementação do Control Tower. Leia a lista de controles opcionais e altamente recomendados e implemente controles adequados às suas necessidades. 

1.  **Restringir o acesso a regiões adicionadas recentemente**: para novas Regiões da AWS, recursos do IAM, como usuários e perfis, serão propagados somente para as regiões especificadas. Essa ação pode ser realizada por meio do [console ao usar o Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) ou ajustando as políticas de permissões do [IAM no AWS Organizations](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/). 

1.  **Considerar o AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)**: o StackSets ajuda você a implantar recursos, como grupos, políticas e perfis do IAM em diferentes regiões e Contas da AWS por meio de um modelo aprovado. 

## Recursos
<a name="resources"></a>

**Práticas recomendadas relacionadas:** 
+ [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md)

**Documentos relacionados:** 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [Diretrizes de auditoria de segurança da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Usar o CloudFormation StackSets para fornecer recursos entre várias regiões e Contas da AWS](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/) 
+  [Perguntas frequentes sobre o Organizations](https://aws.amazon.com/organizations/faqs/) 
+  [Terminologia e conceitos do AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) 
+  [Práticas recomendadas para políticas de controle de serviços do AWS Organizations em um ambiente de várias contas](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) 
+  [Guia de referência de gerenciamento de contas da AWS](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) 
+  [Organização do ambiente usando várias contas da AWS](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 

**Vídeos relacionados:** 
+  [Habilitar a adoção da AWS em grande escala com automação e governança](https://youtu.be/GUMSgdB-l6s) 
+  [Práticas recomendadas de segurança de acordo com o Well-Architected](https://youtu.be/u6BCVkXkPnM) 
+  [Criar e administrar várias contas com o uso do AWS Control Tower](https://www.youtube.com/watch?v=agpyuvRv5oo) 
+  [Habilitar o Control Tower para organizações existentes](https://www.youtube.com/watch?v=CwRy0t8nfgM) 

**Workshops relacionados:** 
+  [Dia de imersão no Control Tower](https://controltower.aws-management.tools/immersionday/) 

# SEC01-BP02 Proteger as propriedades e o usuário raiz das contas
<a name="sec_securely_operate_aws_account"></a>

 O usuário raiz é o mais privilegiado de uma Conta da AWS, com acesso administrativo integral a todos os recursos da conta, e em alguns casos não pode ser restringido por políticas de segurança. Desabilitar o acesso programático ao usuário raiz, estabelecer controles apropriados para ele e evitar o uso rotineiro desse usuário ajuda a reduzir o risco de exposição acidental das credenciais raiz e o subsequente comprometimento do ambiente de nuvem. 

**Resultado desejado: **proteger o usuário raiz ajuda a reduzir a chance de danos acidentais ou intencionais decorrentes do mau uso das respectivas credenciais. Estabelecer controles de detecção também pode alertar o pessoal apropriado quando se realizam ações utilizando o usuário raiz.

**Antipadrões comuns:**
+  Utilizar o usuário raiz para outras tarefas que não sejam aquelas que exigem credenciais do usuário raiz.  
+  Negligenciar os testes dos planos de contingência regularmente a fim de verificar a funcionalidade da infraestrutura, dos processos e dos funcionários essenciais durante uma emergência. 
+  Considerar apenas o fluxo típico de login de contas e não considerar nem testar métodos de recuperação de contas alternativos. 
+  Não lidar com DNS, servidores de e-mail e operadoras de telefonia como parte do perímetro de segurança essencial, pois eles são usados no fluxo de recuperação de contas. 

 **Benefícios do estabelecimento desta prática recomendada:** proteger o acesso ao usuário raiz cria a confiança de que as ações em sua conta estão controladas e auditadas. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 A AWS oferece muitas ferramentas para ajudar a proteger sua conta. No entanto, como algumas dessas medidas não estão habilitadas por padrão, é necessário implementá-las diretamente. Leve em consideração essas recomendações como etapas fundamentais para proteger sua Conta da AWS. Ao implementar essas etapas, é importante criar um processo para avaliar e monitorar os controles de segurança de forma contínua. 

 Ao criar uma Conta da AWS pela primeira vez, você começa com uma identidade que tem acesso completo a todos os recursos e serviços da AWS na conta. Essa identidade é chamada de usuário raiz da Conta da AWS. É possível fazer login como usuário raiz usando o endereço de e-mail e a senha utilizados para criar a conta. Devido ao acesso elevado concedido ao usuário raiz da AWS, é necessário limitar o uso do usuário raiz da AWS à realização de tarefas que [o exijam especificamente](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). As credenciais de login do usuário raiz devem ser bem protegidas, e a autenticação multifator (MFA) sempre deve ser habilitada para o usuário raiz da Conta da AWS. 

 Além do fluxo de autenticação normal para fazer login com seu usuário raiz usando um nome de usuário, senha e o dispositivo de autenticação multifator (MFA), há fluxos de recuperação de contas para fazer login com seu usuário raiz da Conta da AWS com o endereço de e-mail e o número de telefone associados à sua conta. Dessa forma, é igualmente importante proteger a conta de e-mail do usuário raiz para a qual o e-mail de recuperação é enviado e o número de telefone associado à conta. Além disso, considere possíveis dependências circulares em que o endereço de e-mail associado ao usuário raiz é hospedado em servidores de e-mail ou recursos de serviço de nome de domínio (DNS) da mesma Conta da AWS. 

 Ao usar o AWS Organizations, há várias Contas da AWS, e cada uma tem um usuário raiz. Uma conta é designada como a conta de gerenciamento e várias camadas de contas membros podem ser adicionadas à conta de gerenciamento. Priorize a proteção do usuário raiz de sua conta de gerenciamento e, depois, os usuários raiz das contas membros. A estratégia para proteger o usuário raiz de sua conta de gerenciamento pode diferir da utilizada nos usuários raiz de suas contas membros, e é possível implementar controles de segurança preventivos nos usuários raiz dessas contas. 

### Etapas da implementação
<a name="implementation-steps"></a>

 As etapas de implementação a seguir são recomendadas para estabelecer controles para o usuário raiz. Quando aplicável, as recomendações têm referências cruzadas com o [Benchmark do CIS AWS Foundations versão 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html). Além dessas etapas, consulte as [Diretrizes de práticas recomendadas da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) para proteger os recursos e a Conta da AWS. 

 **Controles preventivos** 

1.  Configure [informações de contato](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) precisos para a conta. 

   1.  Essas informações são usadas para o fluxo de recuperação de senha perdida, o fluxo de recuperação de conta de dispositivo MFA perdida e para comunicações com sua equipe sobre segurança crítica. 

   1.  Utilize um endereço de e-mail hospedado por seu domínio corporativo, preferencialmente uma lista de distribuição, como o endereço de e-mail do usuário raiz. O uso de uma lista de distribuição em vez da conta de e-mail de um indivíduo oferece redundância e continuidade adicionais para o acesso à conta raiz por longos períodos. 

   1.  O número de telefone listado nas informações de contato deve ser um telefone dedicado e seguro para esse fim. O número de telefone não deve ser listado nem compartilhado com ninguém. 

1.  Não crie chaves de acesso para o usuário raiz. Se houver chaves de acesso, remova-as (CIS 1.4). 

   1.  Elimine todas as credenciais programáticas de longa duração (chaves de acesso e secretas) para o usuário raiz. 

   1.  Se já houver chaves de acesso do usuário raiz, será necessário fazer a transição dos processos que utilizam essas chaves para utilizar chaves de acesso temporárias de um perfil do AWS Identity and Access Management (IAM), depois [excluir as chaves de acesso do usuário raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key). 

1.  Determine se você precisa armazenar credenciais para o usuário raiz. 

   1.  Ao usar o AWS Organizations para criar contas membros, a senha inicial do usuário raiz em novas contas membros é definida como um valor aleatório que não é exposto a você. Se necessário, considere utilizar o fluxo de redefinição de senha de sua conta de gerenciamento do AWS Organizations para [obter acesso à conta membro](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root). 

   1.  Para Contas da AWS autônomas ou a conta de gerenciamento do AWS Organizations, considere criar e armazenar de forma segura as credenciais do usuário raiz. Ativar a MFA para o usuário raiz 

1.  Ative os controles preventivos para os usuários raiz das contas membros em ambientes de várias contas da AWS. 

   1.  Considere habilitar a barreira de proteção preventiva [Desautorizar criação de chaves de acesso raiz para o usuário raiz](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys) para contas membros. 

   1.  Considere habilitar a barreira de proteção preventiva [Desautorizar criação como um usuário raiz](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions) para contas membros. 

1.  Se você precisar de credenciais para o usuário raiz: 

   1.  Use uma senha complexa. 

   1.  Ative a autenticação multifator (MFA) para o usuário raiz, especialmente para contas (pagantes) de gerenciamento do AWS Organizations (CIS 1.5). 

   1.  Considere o uso de dispositivos de MFA de hardware para ter resiliência e segurança, pois os dispositivos de uso único reduzem as chances de os dispositivos que contêm seus códigos de MFA serem reutilizados para outros fins. Garanta que os dispositivos de MFA de hardware alimentados por bateria sejam substituídos regularmente. (CIS 1.6) 
      +  Para configurar a MFA para o usuário raiz, siga as instruções para habilitar uma [MFA virtual](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) ou um [dispositivo de MFA de hardware](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root). 

   1.  Considere registrar vários dispositivos de MFA para backup. [Até oito dispositivos de MFA são permitidos por conta](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/). 
      +  Registrar mais de um dispositivo de MFA para o usuário raiz desabilita automaticamente o [fluxo para recuperar sua conta se o dispositivo de MFA for perdido](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/). 

   1.  Armazene a senha com segurança e considere as dependências circulares se for armazenar a senha eletronicamente. Não armazene a senha de uma forma que exija o acesso à mesma Conta da AWS para obtê-la. 

1.  Opcional: considere estabelecer um cronograma de alternância de senha periódica para o usuário raiz. 
   +  As práticas recomendadas de gerenciamento de credenciais dependem de seus requisitos regulatórios e de política. Os usuários raiz protegidos por MFA não dependem da senha como um único fator de autenticação. 
   +  [A alteração periódica da senha de usuário raiz](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_passwords_change-root.html) reduz o risco de mau uso de uma senha exposta acidentalmente. 

### Controles de detecção
<a name="detective-controls"></a>
+  Crie alarmes para detectar o uso das credenciais raiz (CIS 1.7). [Quando habilitado, o Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) monitora e alerta o uso de credenciais da API do usuário raiz por meio da descoberta [RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage). 
+  Avalie e implemente os controles de detecção incluídos no [pacote de conformidade do Pilar de segurança do AWS Well-Architected para AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) ou, se usar o AWS Control Tower, os [controles altamente recomendados](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html) disponíveis no Control Tower. 

### Orientação operacional
<a name="operational-guidance"></a>
+  Determine quem na organização deve ter acesso às credenciais do usuário raiz. 
  +  Use uma regra de duas pessoas de forma que um indivíduo tenha acesso a todas as credenciais necessárias e MFA para obter acesso de usuário raiz. 
  +  Verifique se é a organização, e não um único indivíduo, que mantém controle sobre o número de telefone e alias de e-mail associados à conta (que são utilizados para redefinição de senha e fluxo de redefinição de MFA). 
+  Utilize o usuário raiz apenas como uma exceção (CIS 1.7). 
  +  O usuário raiz da AWS não deve ser usado para tarefas diárias, mesmo que sejam tarefas administrativas. Somente faça login como usuário raiz para realizar [tarefas da AWS que o exijam especificamente](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Todas as outras ações devem ser realizadas por outros usuários que assumem perfis apropriados. 
+  Confira periodicamente se o acesso ao usuário raiz está funcionando de forma que os procedimentos sejam testados antes de uma situação de emergência que exija o uso das credenciais do usuário raiz. 
+  Confira periodicamente se o endereço de e-mail associado à conta e os listados em [Contatos alternativos](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html) funcionam. Monitore as caixas de entrada de e-mail das quais você recebe notificações de segurança abuse@amazon.com. Além disso, garanta que todos os números de telefone associados à conta estejam funcionando. 
+  Prepare um procedimento de resposta a incidentes para responder ao mau uso da conta raiz. Consulte o [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) e as práticas recomendadas na [seção “Resposta a incidentes” do whitepaper Pilar Segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) para ter mais informações sobre como criar uma estratégia de resposta a incidentes para sua Conta da AWS. 

## Recursos
<a name="resources"></a>

**Práticas recomendadas relacionadas:** 
+ [SEC01-BP01 Separar as workloads usando contas](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 Usar mecanismos de login fortes](sec_identities_enforce_mechanisms.md)
+ [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Estabelecer processo de acesso de emergência](sec_permissions_emergency_process.md)
+ [SEC10-BP05 Acesso pré-provisionado](sec_incident_response_pre_provision_access.md)

**Documentos relacionados:** 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [Diretrizes de auditoria de segurança da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Amazon GuardDuty: alerta de uso de credenciais raiz](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) 
+  [Orientações passo a passo sobre como monitorar o uso de credenciais raiz por meio do CloudTrail](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html#securityhub-cis1.4-controls-1.7) 
+  [Tokens de MFA aprovados para uso com a AWS](https://aws.amazon.com/iam/features/mfa/) 
+  Implementar [o acesso de quebra de vidro](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) na AWS 
+  [Os dez principais itens de segurança para aprimorar sua Conta da AWS](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/) 
+  [O que fazer se eu notar atividade não autorizada em minha Conta da AWS?](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/) 

**Vídeos relacionados:** 
+  [Habilitar a adoção da AWS em grande escala com automação e governança](https://youtu.be/GUMSgdB-l6s) 
+  [Práticas recomendadas de segurança de acordo com o Well-Architected](https://youtu.be/u6BCVkXkPnM) 
+  [Limitar o uso de credenciais raiz da AWS](https://youtu.be/SMjvtxXOXdU?t=979) do AWS re:inforce 2022: Práticas recomendadas de segurança com o AWS IAM

**Exemplos e laboratórios relacionados:** 
+  [Laboratório: Conta da AWS e usuário raiz](https://www.wellarchitectedlabs.com/security/100_labs/100_aws_account_and_root_user/) 

# SEC01-BP03 Identificar e validar objetivos de controle
<a name="sec_securely_operate_control_objectives"></a>

 Com base em seus requisitos de conformidade e riscos identificados no modelo de ameaça, derive e valide os objetivos de controle e os controles que você precisa aplicar à carga de trabalho. A validação contínua de objetivos de controle e controles ajuda a medir a eficácia da mitigação de riscos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Identificar requisitos de conformidade: descubra os requisitos organizacionais, legais e de conformidade que a sua workload precisa cumprir. 
+  Identificar recursos de conformidade da AWS: identifique os recursos da AWS disponíveis para ajudar você com a conformidade. 
  +  [https://aws.amazon.com/compliance/ ](https://aws.amazon.com/compliance/)
  + [ https://aws.amazon.com/artifact/](https://aws.amazon.com/artifact/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Security Audit Guidelines (Diretrizes de auditoria de segurança da AWS)](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+ [ Boletins de segurança](https://aws.amazon.com/security/security-bulletins/) 

 **Vídeos relacionados:** 
+  [AWS Security Hub CSPM: Manage Security Alerts and Automate Compliance (AWS Security Hub: gerenciamento de alertas de segurança e automatização da governança)](https://youtu.be/HsWtPG_rTak) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP04 Manter-se atualizado sobre as ameaças à segurança
<a name="sec_securely_operate_updated_threats"></a>

 Para ajudar a definir e implementar os controles apropriados, reconheça vetores de ataque mantendo-se a par das ameaças de segurança mais recentes. Consuma o AWS Managed Services para facilitar o recebimento de notificações de comportamentos inesperados ou incomuns em suas contas da AWS. Investigue usando ferramentas de parceiros da AWS ou feeds de informações sobre ameaças de terceiros como parte de seu fluxo de informações de segurança. A [lista de vulnerabilidades e exposições comuns (CVEs) ](https://cve.mitre.org/) contém vulnerabilidades de segurança cibernética divulgadas publicamente que você pode usar para se manter atualizado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Inscreva-se em fontes de inteligência de ameaças: analise regularmente as informações de inteligência de ameaças de várias fontes relevantes sobre as tecnologias usadas na sua workload. 
  +  [Lista de vulnerabilidades e exposições comuns ](https://cve.mitre.org/)
+  Considerar [AWS Shield Advanced](https://aws.amazon.com/shield/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) : oferece visibilidade quase em tempo real das fontes de inteligência, se sua workload for acessível pela Internet. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Security Audit Guidelines (Diretrizes de auditoria de segurança da AWS)](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [AWS Shield](https://aws.amazon.com/shield/) 
+ [ Boletins de segurança](https://aws.amazon.com/security/security-bulletins/) 

 **Vídeos relacionados:** 
+ [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP05 Manter-se atualizado com as recomendações de segurança
<a name="sec_securely_operate_updated_recommendations"></a>

 Mantenha-se atualizado com as recomendações de segurança da AWS e do setor para evoluir a postura de segurança de sua workload. [Boletins de segurança da AWS](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc&awsf.bulletins-year=year%232009) contêm informações importantes sobre notificações de segurança e privacidade. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Siga as atualizações da AWS: inscreva-se ou verifique regularmente novas recomendações e dicas. 
  +  [Laboratórios do AWS Well-Architected](https://wellarchitectedlabs.com/?ref=wellarchitected) 
  +  [Blog de segurança da AWS](https://aws.amazon.com/blogs/security/?ref=wellarchitected) 
  +  [Documentação do serviço da AWS](https://aws.amazon.com/documentation/?ref=wellarchitected) 
+  Inscreva-se para receber as novidades do setor: consulte regularmente os feeds de notícias de várias fontes relevantes às tecnologias usadas na sua workload. 
  +  [Exemplo: lista de vulnerabilidade e exposições comuns](https://cve.mitre.org/cve/?ref=wellarchitected) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Boletins de segurança](https://aws.amazon.com/security/security-bulletins/) 

 **Vídeos relacionados:** 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP06 Automatizar testes e validação de controles de segurança em pipelines
<a name="sec_securely_operate_test_validate_pipeline"></a>

 Estabeleça linhas de base e modelos seguros para mecanismos de segurança que são testados e validados como parte de sua compilação, pipelines e processos. Use ferramentas e automação para testar e validar todos os controles de segurança continuamente. Por exemplo, verifique itens, como imagens de máquina e modelos de infraestrutura como código, para detectar vulnerabilidades de segurança, irregularidades e desvios da uma linha de base estabelecida em cada estágio. O AWS CloudFormation Guard pode ajudar você a verificar se os modelos do CloudFormation são seguros, economizar tempo e reduzir o risco de erro de configuração. 

É fundamental reduzir o número de configurações incorretas de segurança introduzidas em um ambiente de produção. Portanto, quanto mais você puder controlar a qualidade e reduzir os defeitos no processo de construção, melhor. Projete pipelines de integração e implantação contínua (CI/CD) para testar problemas de segurança sempre que possível. Os pipelines de CI/CD oferecem a oportunidade de aumentar a segurança em cada estágio de criação e entrega. As ferramentas de segurança de CI/CD também devem estar sempre atualizadas para mitigar as ameaças em constante evolução.

Acompanhe as alterações na configuração de workload para ajudar na auditoria de conformidade, gerenciamento de alterações e investigações que possam ser aplicáveis. Você pode usar o AWS Config para registrar e avaliar seus recursos da AWS e de terceiros. Ele permite auditar e avaliar continuamente a conformidade geral com regras e pacotes de conformidade, que são coleções de regras com ações de correção.

O rastreamento de alterações deve incluir alterações planejadas, que fazem parte do processo de controle de alterações da sua organização [às vezes chamado de MACD, de Move, Add, Change, Delete (Mover, Adicionar, Alterar, Excluir)], alterações não planejadas e alterações inesperadas, como incidentes. Podem ocorrer alterações na infraestrutura, mas também podem estar relacionadas a outras categorias, como alterações em repositórios de código, imagens de máquina e alterações de inventário de aplicações, alterações de processos e políticas ou alterações de documentação.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Automatize o gerenciamento de configuração: aplique e valide configurações seguras automaticamente usando uma ferramenta ou um serviço de gerenciamento de configuração. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
  +  [Configurar um pipeline CI/CD na AWS](https://aws.amazon.com/getting-started/projects/set-up-ci-cd-pipeline/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Como usar políticas de controle de serviço para definir barreiras de proteção de permissão entre contas no AWS Organization](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) 

 **Vídeos relacionados:** 
+  [Como gerenciar ambientes da AWS de várias contas usando o AWS Organizations](https://youtu.be/fxo67UeeN1A) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça
<a name="sec_securely_operate_threat_model"></a>

 Realize a modelagem de ameaças para identificar e manter um registro atualizado de possíveis ameaças e mitigações associadas para sua workload. Priorize suas ameaças e adapte as mitigações de controles de segurança para prevenir, detectar e responder. Revise e mantenha isso no contexto de sua workload e no cenário de segurança em evolução. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 **O que é modelagem de ameaças?** 

 “A modelagem de ameaças serve para identificar, comunicar e compreender as ameaças e as mitigações no contexto de proteção de algo de valor.” [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling) 

 **Por que você deve ter um modelo de ameaças?** 

 Os sistemas são complexos e se tornam cada vez mais intrincados e qualificados com o passar do tempo, oferecendo maior valor empresarial e maior satisfação e engajamento do cliente. Isso significa que as decisões de design de TI precisam considerar um número cada vez maior de casos de uso. Essa complexidade e o número de permutações de caso de uso geralmente tornam as abordagens não estruturadas ineficazes para encontrar e mitigar ameaças. Em vez disso, você precisa de uma abordagem sistemática para enumerar as possíveis ameaças ao sistema, elaborar mitigações e priorizá-las a fim de garantir que os recursos limitados de sua organização tenham impacto máximo na melhoria do procedimento geral de segurança do sistema. 

 A modelagem de ameaças foi projetada para oferecer essa abordagem sistemática, com o objetivo de encontrar e resolver problemas na fase inicial do processo de design, quando as mitigações têm custo e esforço relativamente baixos em comparação com a fase posterior do ciclo de vida. Essa abordagem está alinhada ao princípio de [segurança *shift left*](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview) (mover para a esquerda) do setor. Por fim, a modelagem de ameaças é integrada ao processo de gerenciamento de riscos de uma organização e ajuda a impulsionar as decisões sobre quais controles implementar usando uma abordagem orientada a ameaças. 

 **Quando a modelagem de ameaças deve ser realizada?** 

 Inicie a modelagem de ameaças o quanto antes no ciclo de vida de sua workload. Isso oferece a você maior flexibilidade sobre o que fazer com as ameaças identificadas. Muito semelhante aos bugs de software, quanto mais cedo você identificar ameaças, mais econômico será resolvê-las. Um modelo de ameaças é um documento ativo e deve continuar a evoluir à medida que suas workloads mudam. Revise seus modelos de ameaça no decorrer do tempo, inclusive quando há uma alteração importante ou uma alteração no cenário de ameaças ou ao adotar um novo recurso ou serviço. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Como podemos realizar a modelagem de ameaças?** 

 Há muitas formas diferentes de realizar a modelagem de ameaças. Muito semelhante às linguagens de programação, há vantagens e desvantagens em cada uma, e é necessário escolher a forma mais adequada para você. Uma abordagem é começar com o [Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame) (Estrutura de quatro perguntas do Shostack para modelagem de ameaças), que apresenta perguntas abertas a fim de oferecer estrutura ao seu exercício de modelagem de ameaças: 

1.  **Em que você está trabalhando?** 

    A finalidade dessa pergunta é ajudar você a entender e chegar a um acordo sobre o sistema que você está construindo e os detalhes sobre ele que são relevantes para a segurança. A criação de um modelo ou um diagrama é a forma mais comum de responder a essa pergunta, pois ele ajuda você a visualizar o que você está construindo; por exemplo, usando um [fluxograma de dados](https://en.wikipedia.org/wiki/Data-flow_diagram). Escrever as suposições e os detalhes importantes sobre seu sistema também ajuda a definir o que está no escopo. Isso permite que todos que estão contribuindo para o modelo de ameaças se concentrem na mesma coisa e evitem desvios demorados para tópicos fora do escopo (inclusive versões desatualizadas do sistema). Por exemplo, se você estiver criando uma aplicação web, provavelmente não vale a pena criar uma modelagem de ameaças da sequência de inicialização confiável do sistema operacional para clientes de navegador, pois não há nenhuma possibilidade de seu design ter influência nisso. 

1.  **O que pode dar errado?** 

    É nessa fase que você identifica ameaças ao seu sistema. Ameaças são ações ou eventos acidentais ou intencionais que têm impactos indesejados que podem afetar a segurança de seu sistema. Sem um claro entendimento do que pode dar errado, não há o que fazer sobre isso. 

    Não há uma lista canônica do que pode dar errado. A criação dessa lista exige etapas de brainstorming e colaboração entre todas as pessoas de sua equipe e as [pessoas relevantes envolvidas](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips) no exercício de modelagem de ameaças. Você pode auxiliar suas etapas de brainstorming utilizando um modelo para identificar ameaças, como o [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)), que sugere categorias diferentes para avaliar: Spoofing (Falsificação), Tampering (Violação), Repudiation (Repúdio), Information disclosure (Divulgação de informações), Denial of service (Negação de serviço) e Elevation of privilege (Elevação de privilégio). Além disso, talvez você queira auxiliar as etapas de brainstorming revisando as listas existentes e a pesquisa para inspiração, como o [OWASP Top 10](https://owasp.org/www-project-top-ten/), o [HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/) e o catálogo de ameaças de sua própria organização. 

1.  **O que estamos fazendo a respeito?** 

    Como no caso da primeira pergunta, não há uma lista canônica de todas as mitigações possíveis. A entradas nessa etapa são as ameaças identificadas, as pessoas e as áreas de melhoria da etapa anterior. 

    Segurança e conformidade são [responsabilidades compartilhadas entre você e a AWS](https://aws.amazon.com/compliance/shared-responsibility-model/). É importante entender que ao perguntar “O que vamos fazer a respeito?” você também pergunte “Quem é responsável por fazer algo a respeito?”. Entender o equilíbrio entre suas responsabilidades e as da AWS ajuda a definir o escopo de seu exercício de modelagem de ameaças para as mitigações que estão sob seu controle, que, geralmente, são uma combinação de opções de configuração de serviços da AWS e suas mitigações específicas ao sistema. 

    No que se refere à responsabilidade compartilhada da AWS, você descobrirá que os [serviços da AWS estão no escopo de muitos programas de conformidade](https://aws.amazon.com/compliance/services-in-scope/). Esses programas ajudam você a entender os controles sólidos implementados na AWS para manter a segurança e a conformidade da nuvem. Os relatórios de auditoria desses programas estão disponíveis para download para clientes da AWS do [AWS Artifact](https://aws.amazon.com/artifact/). 

    Seja quais forem os serviços da AWS que você esteja utilizando, sempre há um elemento de responsabilidade do cliente, e as mitigações alinhadas a essas responsabilidades devem ser incluídas em seu modelo de ameaças. Para mitigações de controle de segurança dos próprios serviços da AWS, convém considerar a implementação de controles de segurança em todos os domínios; por exemplo, domínios como gerenciamento de identidade e acesso (autenticação e autorização), proteção de dados (em repouso e em trânsito), segurança de infraestrutura, registro em log e monitoramento. A documentação de cada serviço da AWS tem um [capítulo dedicado à segurança](https://docs.aws.amazon.com/security/) que oferece orientações sobre os controles de segurança a serem considerados como mitigações. É importante considerar o código que você está escrevendo e suas dependências e pensar nos controles que você poderia implementar para resolver essas ameaças. Esses controles podem ser fatores como [validação de entrada](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [processamento de sessões](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling) e [processamento de limites](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow). Com frequência, a maioria das vulnerabilidades é introduzida em código personalizado, então concentre-se nessa área. 

1.  **Fizemos um bom trabalho?** 

    O objetivo é a sua equipe e a organização aprimorarem a qualidade dos modelos de ameaças e a velocidade na qual você está realizando a modelagem de ameaças no decorrer do tempo. Essas melhorias vêm de uma combinação de prática, aprendizado, instrução e revisão. Para se aprofundar e trabalhar, é recomendável que você e sua equipe concluam o [curso de treinamento Threat modeling the right way for builders](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) (Modelagem de ameças da maneira certa para desenvolvedores) ou o respectivo [workshop](https://catalog.workshops.aws/threatmodel/en-US). Além disso, se você estiver procurando orientações sobre como integrar a modelagem de ameaças ao ciclo de vida do desenvolvimento de aplicações da organização, consulte a publicação [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) no Blog de segurança da AWS. 

 **Threat Composer** 

 Para ajudar e fornecer orientações ao criar a modelagem de ameaças, considere usar a ferramenta [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer), que visa reduzir o tempo de maturação na modelagem de ameaças. Essa ferramenta ajuda a fazer o seguinte: 
+  Escrever declarações úteis sobre ameaças alinhadas à [gramática de ameaças](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar) que funcionem em um fluxo de trabalho natural e não linear. 
+  Gerar um modelo de ameaça legível por humanos. 
+  Gerar um modelo de ameaça legível por máquina para permitir tratar os modelos de ameaças como código. 
+  Ajudar a identificar rapidamente as áreas de melhoria da qualidade e de cobertura usando o painel do Insights. 

 Para obter mais referências, acesse o Threat Composer e alterne para o **Example Workspace** definido pelo sistema. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC01-BP03 Identificar e validar objetivos de controle](sec_securely_operate_control_objectives.md) 
+  [SEC01-BP04 Manter-se atualizado sobre as ameaças à segurança](sec_securely_operate_updated_threats.md) 
+  [SEC01-BP05 Manter-se atualizado com as recomendações de segurança](sec_securely_operate_updated_recommendations.md) 
+  [SEC01-BP08 Avaliar e implementar regularmente novos serviços e recursos de segurança](sec_securely_operate_implement_services_features.md) 

 **Documentos relacionados:** 
+  [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (Blog de segurança da AWS) 
+ [NIST: Guia para modelagem de ameaças de sistemas centrados em dados](https://csrc.nist.gov/publications/detail/sp/800-154/draft)

 **Vídeos relacionados:** 
+ [AWS Summit ANZ 2021: Como abordar a modelagem de ameaças ](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022: Escalar a segurança: otimizar para ter uma entrega rápida e segura ](https://www.youtube.com/watch?v=DjNPihdWHeA)

 **Treinamento relacionado:** 
+ [ Threat modeling the right way for builders (Modelagem de ameaças da maneira certa para desenvolvedores): treinamento autoguiado virtual do AWS Skill Builder ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [ Threat modeling the right way for builders – AWS Workshop ](https://catalog.workshops.aws/threatmodel) (Modelagem de ameaças da maneira certa para desenvolvedores)

 **Ferramentas relacionadas:** 
+  [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 

# SEC01-BP08 Avaliar e implementar regularmente novos serviços e recursos de segurança
<a name="sec_securely_operate_implement_services_features"></a>

 Avalie e implemente serviços e recursos de segurança da AWS e parceiros da AWS que permitem que você desenvolva a postura de segurança da sua workload. O blog de segurança da AWS destaca novos serviços e recursos, guias de implementação e orientações gerais de segurança da AWS. [Quais as novidades da AWS?](https://aws.amazon.com/new) é uma ótima forma de se manter atualizado com todos os novos recursos, serviços e anúncios da AWS. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Planeje revisões regulares: crie um calendário de atividades de análise que inclua os requisitos de conformidade, avaliar novos recursos e serviços de segurança da AWS e manter-se atualizado sobre as novidades do setor. 
+  Descubra os serviços e recursos da AWS: descubra os recursos de segurança disponíveis para os serviços que você está usando e analise os novos recursos à medida que são lançados. 
  + [ Blog de segurança da AWS](https://aws.amazon.com/blogs/security/) 
  + [ Boletins de segurança da AWS](https://aws.amazon.com/security/security-bulletins/)
  +  [Documentação do serviço da AWS](https://aws.amazon.com/documentation/)
+  Definir processo de integração de serviços da AWS: defina processos para integração de novos serviços da AWS. Inclua como você avalia os novos serviços da AWS em termos de funcionalidade e os requisitos de conformidade para sua workload. 
+  Teste novos serviços e recursos: teste novos serviços e recursos à medida que são lançados em um ambiente que não seja de produção que replica bem o ambiente de produção. 
+  Implemente outros mecanismos de defesa: implemente mecanismos automatizados para defender sua workload e explore as opções disponíveis. 
  +  [Como corrigir recursos não compatíveis da AWS pelo Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)

## Recursos
<a name="resources"></a>

 **Vídeos relacionados:** 
+  [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM)

# Gerenciamento de identidade e acesso
<a name="a-identity-and-access-management"></a>

**Topics**
+ [SEGURANÇA 2. Como gerenciar a autenticação de pessoas e máquinas?](sec-02.md)
+ [SEGURANÇA 3. Como gerenciar permissões para pessoas e máquinas?](sec-03.md)

# SEGURANÇA 2. Como gerenciar a autenticação de pessoas e máquinas?
<a name="sec-02"></a>

 Há dois tipos de identidade que você precisa gerenciar para operar workloads seguras da AWS. Entender o tipo de identidade de que você precisa para gerenciar e conceder acesso ajuda a garantir que as identidades corretas tenham acesso aos recursos certos nas condições certas. 

Identidades humanas: seus administradores, desenvolvedores, operadores e usuários finais precisam de uma identidade para acessar ambientes e aplicações na AWS. Eles são membros de sua organização ou usuários externos com quem você colabora e que interagem com seus recursos da AWS por meio de um navegador da web, de uma aplicação cliente ou de ferramentas interativas de linha de comando. 

Identidades de máquina: aplicações de serviço, ferramentas operacionais e workloads precisam de uma identidade para fazer solicitações a serviços da AWS, como para ler dados. Essas identidades incluem máquinas em execução em seu ambiente da AWS, como instâncias do Amazon EC2 ou funções do AWS Lambda. Você também pode gerenciar identidades de máquina para partes externas que precisam de acesso. Além disso, você pode ter máquinas fora da AWS que precisam de acesso ao seu ambiente da AWS. 

**Topics**
+ [SEC02-BP01 Usar mecanismos de login fortes](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md)
+ [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md)
+ [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md)
+ [SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais](sec_identities_audit.md)
+ [SEC02-BP06 Utilizar grupos e atributos de usuários](sec_identities_groups_attributes.md)

# SEC02-BP01 Usar mecanismos de login fortes
<a name="sec_identities_enforce_mechanisms"></a>

Os logins (autenticação com credenciais de login) podem apresentar riscos quando não são usados mecanismos, como autenticação multifator (MFA), especialmente em situações em que as credenciais de login foram divulgadas acidentalmente ou podem ser deduzidas com facilidade. Utilize mecanismos de login fortes para reduzir essas riscos exigindo MFA e políticas de senhas fortes. 

 **Resultado desejado:** reduzir os riscos de acesso acidental a credenciais na AWS usando mecanismos de login fortes para usuários do [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), o [usuário raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), o [Centro de Identidade do AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) (sucessor do AWS Single Sign-On), e provedores de identidades de terceiros. Isso significa exigir MFA, impor políticas de senhas fortes e detectar comportamento de login anômalo. 

 **Antipadrões comuns:** 
+  Não impor uma política de senhas fortes para suas identidades incluindo senhas complexas e MFA. 
+  Compartilhar as mesmas credenciais entre usuários diferentes. 
+  Não utilizar controles de detecção para logins suspeitos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Há muitas formas de identidades humanas fazerem login na AWS. É prática recomendada da AWS depender de um provedor de identidades centralizado utilizando federação (federação direta ou usando Centro de Identidade do AWS IAM) ao realizar a autenticação na AWS. Nesse caso, você deve estabelecer um processo de login seguro com seu provedor de identidades ou o Microsoft Active Directory. 

 Ao abrir pela primeira vez uma Conta da AWS, você começa com um usuário raiz da Conta da AWS. Você só deve usar o usuário raiz da conta para configurar o acesso para seus usuários (e para [tarefas que exijam o usuário raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). É importante ativar a MFA para o usuário raiz da conta logo após abrir sua Conta da AWS e para proteger o usuário raiz usando o [Guia de práticas recomendadas da AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html). 

 Se você criar usuários no Centro de Identidade do AWS IAM, proteja o processo de login nesse serviço. Para identidades dos consumidores, é possível usar o [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/index.html) e proteger o processo de login nesse serviço ou usar os provedores de identidades compatíveis com o Amazon Cognito user pools. 

 Se estiver usando usuários do [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), você protegerá o processo de login com o IAM. 

 Seja qual for o método de login, é essencial impor uma política de login forte. 

 **Etapas da implementação** 

 Veja a seguir as recomendações gerais de login forte. As configurações reais devem ser definidas pela política de sua empresa ou usando um padrão como [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html). 
+  Exija MFA. É [prática recomendada IAM exigir MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) para identidades humanas e workloads. A ativação da MFA oferece uma camada adicional de segurança que exige que os usuários forneçam credenciais de login e uma senha de uso único (OTP) ou uma string gerada e verificada criptograficamente por um dispositivo de hardware. 
+  Imponha um comprimento mínimo de senha, que é um fator essencial da força da senha. 
+  Imponha complexidade para tornar as senhas mais difíceis de deduzir. 
+  Permita que os usuários alterem suas próprias senhas. 
+  Crie identidades individuais em vez de credenciais compartilhadas. Com a criação de identidades individuais, é possível fornecer a cada usuário um conjunto exclusivo de credenciais de segurança. Os usuários individuais oferecem a capacidade de auditar a atividade de cada usuário. 

 Recomendações do IAM Identity Center: 
+  O IAM Identity Center oferece uma [política de senha](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) predefinida ao usar o diretório padrão que estabelece o comprimento da senha, a complexidade e requisitos de reutilização. 
+  [Ative a MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) e defina a configuração de reconhecimento de contexto ou sempre ativo da MFA quando a origem da identidade for o diretório padrão, o AWS Managed Microsoft AD ou o AD Connector. 
+  Permita que os usuários [registrem seus próprios dispositivos de MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html). 

 Recomendações de diretório do Amazon Cognito user pools: 
+  Defina as configurações de [força da senha](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html). 
+  [Exija MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) dos usuários. 
+  Use as [configurações de segurança avançadas](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) do Amazon Cognito user pools para recursos como [autenticação adaptável](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html) que podem bloquear logins suspeitos. 

 Recomendações para usuários do IAM: 
+  Em teoria, você está utilizando IAM Identity Center ou federação direta. No entanto, talvez você precise de usuários do IAM. Nesse caso, [defina uma política de senha](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) para usuários do IAM. A política de senhas pode ser usada para definir requisitos como extensão mínima ou a obrigatoriedade de uso de caracteres não alfabéticos. 
+  Crie uma política do IAM com o objetivo de [impor login de MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) para que os usuários possam gerenciar suas próprias senhas e dispositivos de MFA. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md) 
+  [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md) 
+  [SEC03-BP08 Compartilhar recursos com segurança em sua organização](sec_permissions_share_securely.md) 

 **Documentos relacionados:** 
+ [ Política de senha do Centro de Identidade do AWS IAM (sucessor do AWS Single Sign-On)](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [ Política de senha do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [ Definir a senha do usuário raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [ Política de senha do Amazon Cognito ](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [ Credenciais da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [ Práticas recomendadas de segurança no IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)

 **Vídeos relacionados:** 
+  [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E) 
+  [Dominar a identidade em todos os aspectos](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP02 Usar credenciais temporárias
<a name="sec_identities_unique"></a>

 Ao realizar qualquer tipo de autenticação, é melhor utilizar credenciais temporárias em vez de credenciais de longo prazo a fim de reduzir ou eliminar riscos, como credenciais que são divulgadas acidentalmente, compartilhadas ou roubadas. 

**Resultado desejado:** para reduzir o risco de credenciais de longo prazo, use credenciais temporárias sempre que possível para identidades humanas e de máquina. Credenciais de longo prazo criam muitos riscos, por exemplo, é possível fazer upload delas em código para repositórios públicos do GitHub. Ao utilizar credenciais temporárias, você reduz significativamente as chances de comprometimento das credenciais. 

**Antipadrões comuns:**
+  Desenvolvedores que usam chaves de acesso de longo prazo de IAM users em vez de obter credenciais temporárias da CLI usando federação. 
+  Desenvolvedores que incorporam chaves de acesso de longo prazo no código e fazem upload desse código para repositórios públicos do Git. 
+  Desenvolvedores que incorporam chaves de acesso de longo prazo em aplicações móveis que, depois, são disponibilizadas em lojas de aplicações. 
+  Usuários que compartilham chaves de acesso de longo prazo com outros usuários ou funcionários que deixam a empresa e não devolvem as chaves de acesso de longo prazo. 
+  Utilizar chaves de acesso de longo prazo para identidades de máquina quando é possível usar credenciais temporárias. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Utilize credenciais de segurança temporárias em vez de credenciais de longo prazo para todas as solicitações da AWS CLI e API. As solicitações de API e CLI para serviços da AWS devem, em quase todos os casos, ser assinadas com [chaves de acesso da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html). Essas solicitações podem ser assinadas com credenciais temporárias ou de longo prazo. A única vez que você deve usar credenciais de longo prazo, também conhecidas como chaves de acesso de longo prazo, é se você estiver utilizando um [usuário do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_users.html) ou o [usuário raiz da Conta da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html). Quando você usa federação na AWS ou assume um [perfil do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) por outros métodos, são geradas credenciais temporárias. Mesmo quando você acessa o Console de gerenciamento da AWS utilizando credenciais de login, credenciais temporárias são geradas para você fazer chamadas para serviços da AWS. Há poucas situações nas quais você precisa de credenciais de longo prazo, e é possível realizar quase todas as tarefas usando credenciais temporárias. 

 Evitar o uso de credenciais de longo prazo em favor de credenciais temporárias deve andar lado a lado com uma estratégia de reduzir o uso de usuários do IAM em favor da federação e de perfis do IAM. Embora usuários do IAM tenham sido usados para identidades humanas e de máquina no passado, agora recomendamos não utilizá-los para evitar os riscos de utilizar chaves de acesso de longo prazo. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Para identidades humanas, como funcionários, administradores, desenvolvedores, operadores e clientes: 
+  Você deve [contar com um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) e [exigir que usuários humanos usem federação com um provedor de identidades para acessar a AWS utilizando credenciais temporárias](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-users-federation-idp). A federação para seus usuários pode ser realizada com [federação direta para cada Conta da AWS](https://aws.amazon.com/identity/federation/) ou usando o [AWS IAM Identity Center (sucessor do Centro de Identidade do AWS IAM)](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) e o provedor de identidades de sua escolha. A federação oferece uma série de vantagens em comparação com a utilização de usuários do IAM além de eliminar credenciais de longo prazo. Seus usuários também podem solicitar credenciais temporárias da linha de comando para [federação direta](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) ou utilizando o [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Isso significa que há poucos casos de uso que exigem usuários do IAM ou credenciais de longo prazo para seus usuários.  
+  Ao conceder acesso a recursos em sua Conta da AWS a terceiros, como provedores de software como serviço (SaaS), você pode utilizar [perfis entre contas](https://docs.aws.amazon.com//latest/UserGuide/tutorial_cross-account-with-roles.html) e [políticas baseadas em recursos](https://docs.aws.amazon.com//latest/UserGuide/access_policies_identity-vs-resource.html). 
+  Se você precisar conceder a aplicações de consumidores ou clientes acesso aos seus recursos da AWS, você pode utilizar [grupos de identidade do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) ou [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) para fornecer credenciais temporárias. As permissões para as credenciais são configuradas por meio de perfis do IAM. Você também pode definir um perfil do IAM separado com permissões limitadas para usuários convidados que não são autenticados. 

 Para identidades de máquina, talvez seja necessário utilizar credenciais de longo prazo. Nesses casos, você deve [exigir que as workloads utilizem credenciais temporárias com perfis da IAM para acessar a AWS](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-workloads-use-roles). 
+  Para [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), é possível usar [perfis do Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html). 
+  O [AWS Lambda](https://aws.amazon.com/lambda/) permite configurar um [perfil de execução do Lambda para conceder permissões de serviço](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) a fim de executar ações da AWS usando credenciais temporárias. Há muitos outros modelos semelhantes para os serviços da AWS concederem credenciais temporárias utilizando perfis do IAM. 
+  Para serviços de IoT, é possível usar o [provedor de credenciais de AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) para solicitar credenciais temporárias. 
+  Para sistemas on-premises ou sistemas executados fora da AWS que precisem acessar os recursos da AWS, é possível utilizar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html). 

 Há cenários em que credenciais temporárias não são uma opção e talvez seja necessário usar credenciais de longo prazo. Nessas situações, [faça auditoria e alterne as credenciais periodicamente](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) e [alterne as chaves de acesso regularmente para casos de uso que exijam credenciais de longo prazo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#rotate-credentials). Alguns exemplos que podem exigir credenciais de longo prazo incluem plug-ins do WordPress e clientes da AWS de terceiros. Em situações em que você precisa utilizar credenciais de longo prazo ou para credenciais que não sejam chaves de acesso da AWS, como logins de banco de dados, é possível usar um serviço projetado para lidar com o gerenciamento de segredos, como [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/). O Secrets Manager torna simples gerenciar, alternar e armazenar com segurança segredos criptografados utilizando [serviços compatíveis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html). Para ter mais informações sobre a alternância de credenciais de longo prazo, consulte [Alternar chave de acesso](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md) 
+ [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md) 
+ [SEC03-BP08 Compartilhar recursos com segurança em sua organização](sec_permissions_share_securely.md) 

 **Documentos relacionados:** 
+  [Credenciais de segurança temporárias](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+  [Credenciais da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) 
+  [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Perfis do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) 
+  [IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [Provedores de identidades e federação](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Alternar chaves de acesso](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 
+  [Soluções de parceiros de segurança: acesso e controle de acesso](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [Usuário raiz da Conta da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html) 

 **Vídeos relacionados:** 
+  [Gerenciar permissões de acesso em grande escala com o AWS IAM Identity Center (sucessor do Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E) 
+  [Dominar a identidade em todos os aspectos](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP03 Armazenar e usar segredos com segurança
<a name="sec_identities_secrets"></a>

 Uma workload exige um recurso automatizado para comprovar a identidade dela em bancos de dados, recursos e serviços de terceiros. Isso é realizado com o uso de credenciais de acesso secretas, como chaves de acesso de API, senhas e tokens do OAuth. Utilizar um serviço com propósito específico para armazenar, gerenciar e alternar essas credenciais ajuda a reduzir a probabilidade de comprometimento dessas credenciais. 

**Resultado desejado:** implementar um mecanismo para gerenciar com segurança credenciais de aplicações que concretize os seguintes objetivos: 
+  Identificar quais segredos são necessários para a workload. 
+  Reduzir o número de credenciais de longo prazo necessárias substituindo-as por credenciais de curto prazo quando possível. 
+  Estabelecer um armazenamento seguro e uma alternância automatizada das credenciais de longo prazo restantes. 
+  Auditar o acesso aos segredos existentes na workload. 
+  Monitorar continuamente para confirmar que nenhum segredo seja incorporado a código-fonte durante o processo de desenvolvimento. 
+  Reduzir a probabilidade de divulgação acidental de credenciais. 

**Antipadrões comuns:**
+  Ausência de alternância de credenciais. 
+  Armazenar credenciais de longo prazo em código-fonte ou arquivos de configuração. 
+  Armazenar credenciais em repouso não criptografadas. 

 **Benefícios do estabelecimento desta prática recomendada:**
+  Os segredos são armazenados com criptografia em repouso e em trânsito. 
+  O acesso às credenciais é fechado por meio de uma API (pense nisso como uma *máquina automática de venda de credenciais*). 
+  O acesso a uma credencial (de leitura e gravação) é auditado e registrado. 
+  Separação de preocupações: a alternância de credenciais é realizada por um componente separado, que pode ser segregado do restante da arquitetura. 
+  Os segredos são automaticamente distribuídos sob demanda em componentes de software e a alternância ocorre em um local central. 
+  O acesso às credenciais pode ser controlado de forma detalhada. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Antes, as credenciais usadas para realizar a autenticação em bancos de dados, APIs de terceiros, tokens e outros segredos podiam ser incorporadas em código-fonte ou em arquivos do ambiente. A AWS oferece vários mecanismos para armazenar essas credenciais com segurança, alterná-las automaticamente e auditar o uso delas. 

 A melhor forma de abordar o gerenciamento de segredos é seguir as orientações de remover, substituir e alternar. A credencial mais segura é a que você não precisa armazenar, gerenciar nem processar. Pode haver credenciais que não sejam mais necessárias ao funcionamento da workload que podem ser removidas com segurança. 

 Para credenciais que ainda são necessárias ao funcionamento adequado da workload, pode haver uma oportunidade de substituir uma credencial de longo prazo por uma credencial temporária ou de curto prazo. Por exemplo, em vez de codificar uma chave de acesso secreta da AWS, pense em substituir essa credencial de longo prazo por uma temporária utilizando perfis do IAM. 

 Alguns segredos duradouros podem não ser removidos ou substituídos. Esses segredos podem ser armazenados em um serviço, como o [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), no qual eles podem ser armazenados centralmente, gerenciados e alternados regularmente. 

 Uma auditoria do código-fonte da workload e os arquivos de configuração podem revelar muitos tipos de credencial. A seguinte tabela resume as estratégias para lidar com tipos comuns de credenciais: 


|  Credential type  |  Description  |  Suggested strategy  | 
| --- | --- | --- | 
|  IAM access keys  |  AWS IAM access and secret keys used to assume IAM roles inside of a workload  |  Replace: Use [Perfis do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios.html) assigned to the compute instances (such as [Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html) or [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)) instead. For interoperability with third parties that require access to resources in your Conta da AWS, ask if they support [Acesso entre contas da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html). For mobile apps, consider using temporary credentials through [Grupos de identidades (identidades federadas) do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). For workloads running outside of AWS, consider [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) or [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).  | 
|  SSH keys  |  Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process  |  Replace: Use [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) or [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) to provide programmatic and human access to EC2 instances using IAM roles.  | 
|  Application and database credentials  |  Passwords – plain text string  |  Rotate: Store credentials in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 
|  Amazon RDS and Aurora Admin Database credentials  |  Passwords – plain text string  |  Replace: Use the [Integração do Secrets Manager ao Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) or [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html). In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see [Autenticação de banco de dados do IAM](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.DBAuth.html)).  | 
|  OAuth tokens  |  Secret tokens – plain text string  |  Rotate: Store tokens in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and configure automated rotation.  | 
|  API tokens and keys  |  Secret tokens – plain text string  |  Rotate: Store in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 

 Um antipadrão comum é incorporar chaves de acesso do IAM ao código-fonte, a arquivos de configuração ou aplicativos móveis. Quando uma chave de acesso do IAM é necessária para comunicação com um serviço da AWS, utilize [credenciais de segurança temporárias (de curto prazo)](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html). Essas credenciais de curto prazo podem ser fornecidas por meio de [perfis do IAM para instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), [perfis de execução](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) para funções do Lambda, [perfis do Cognito IAM](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) para acesso de usuários móveis e [políticas do IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) para dispositivos IoT. Ao fazer interface com terceiros, prefira [delegar o acesso a um perfil do IAM ](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html) com o acesso necessário aos recursos de sua conta em vez de configurar um usuário do IAM e enviar a terceiros a chave de acesso secreta desse usuário. 

 Há muitos casos em que a workload exige o armazenamento de segredos necessários para interoperar com outros serviços e recursos. O [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) foi concebido especificamente para gerenciar com segurança essas credenciais, bem como o armazenamento, o uso e a alternância de tokens de API, senhas e outras credenciais. 

 O AWS Secrets Manager oferece cinco recursos principais para proteger o armazenamento e o processamento de credenciais sigilosas: [criptografia em repouso](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [criptografia em trânsito](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [auditoria abrangente](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [controle de acesso detalhado](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) e [alternância de credenciais extensíveis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). Outros serviços de gerenciamento de segredos de parceiros da AWS ou soluções desenvolvidas localmente que oferecem recursos e garantias semelhantes também são aceitáveis. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique caminhos de código que contenham credenciais codificadas usando ferramentas automatizadas, como o [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/). 
   +  Utilize o Amazon CodeGuru para verificar seus repositórios de código. Depois de concluir a revisão, filtre `Type=Secrets` no CodeGuru para encontrar linhas de código problemáticas. 

1.  Identifique credenciais que possam ser removidas ou substituídas. 

   1.  Identifique credenciais não mais necessárias e marque-as para remoção. 

   1.  Para chaves secretas da AWS incorporadas ao código-fonte, substitua-as por perfis do IAM associados aos recursos necessários. Se parte de sua workload estiver fora do AWS, mas exigir credenciais do IAM para acessar recursos da AWS, considere o [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) ou o [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). 

1.  Para outros terceiros, segredos duradouros que exijam o uso da estratégia de alternância, integre o Secrets Manager ao seu código para recuperar segredos de terceiros no tempo de execução. 

   1.  O console do CodeGuru pode [criar um segredo automaticamente no Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) utilizando as credenciais descobertas. 

   1.  Integre a recuperação de segredos do Secrets Manager ao código de sua aplicação. 
      +  Funções do Lambda Sem Servidor podem usar uma [extensão do Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) independente de linguagem. 
      +  Para instâncias ou contêineres do EC2, a AWS oferece [código do lado do cliente de exemplo para recuperar segredos do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) em várias linguagens de programação conhecidas. 

1.  Revise periodicamente sua base de código e verifique novamente para confirmar se não há novos segredos adicionados ao código. 
   +  Considere usar uma ferramenta como o [git-secrets](https://github.com/awslabs/git-secrets) para impedir a confirmação de novos segredos em seu repositório de código-fonte. 

1.  [Monitore a atividade do Secrets Manager ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) quanto a indicações de uso inesperado, acesso inadequado a segredos ou tentativas de excluir segredos. 

1.  Reduza a exposição humana às credenciais. Restrinja o acesso a credenciais de leitura, gravação e modificação a um perfil do IAM dedicado a esse fim, e apenas forneça acesso para assumir o perfil a um pequeno subconjunto de usuários operacionais. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md)
+ [SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais](sec_identities_audit.md)

 **Documentos relacionados:** 
+  [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Provedores de identidades e federação](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Amazon CodeGuru apresenta o Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) 
+  [Como o AWS Secrets Manager usa o AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html) 
+  [Criptografia e descriptografia de segredos no Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) 
+  [Entradas do blog do Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/) 
+  [Amazon RDS anuncia integração com o AWS Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/) 

 **Vídeos relacionados:** 
+  [Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala](https://youtu.be/qoxxRlwJKZ4) 
+  [Encontre segredos codificados com o Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs) 
+  [Proteger segredos para workloads híbridas usando o AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8) 

 **Workshops relacionados:** 
+  [Armazenar, recuperar e gerenciar credenciais sigilosas no AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/497b4908-169f-4e6f-b80d-ef10be3038d3/en-US) 
+  [ Ativações híbridas do AWS Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html) 

# SEC02-BP04 Contar com um provedor de identidades centralizado
<a name="sec_identities_identity_provider"></a>

 Para identidades da força de trabalho (funcionários e prestadores de serviços), confie em um provedor de identidade que permita gerenciar identidades em um local centralizado. Isso facilita o gerenciamento do acesso em várias aplicações e sistemas, pois você está criando, atribuindo, gerenciando, revogando e auditando o acesso de um único local. 

 **Resultado desejado:** Você tem um provedor de identidade centralizado no qual gerencia centralmente os usuários da força de trabalho, as políticas de autenticação (como a exigência de autenticação multifator (MFA)) e a autorização para sistemas e aplicações (como atribuir acesso com base na associação ou nos atributos do grupo de um usuário). Os usuários da sua força de trabalho fazem login no provedor de identidade central e se federam (autenticação única) a aplicações internas e externas, eliminando a necessidade de os usuários se lembrarem de várias credenciais. Seu provedor de identidade é integrado aos seus sistemas de recursos humanos (RH) para que as mudanças de pessoal sejam automaticamente sincronizadas com seu provedor de identidade. Por exemplo, se alguém deixar sua organização, você poderá revogar automaticamente o acesso a aplicações e sistemas federados (inclusive a AWS). Você habilitou o registro em log detalhado de auditoria em seu provedor de identidade e está monitorando esses logs em busca de comportamentos incomuns do usuário. 

 **Antipadrões comuns:** 
+  Você não usa federação e autenticação única. Os usuários da sua força de trabalho criam contas de usuário e credenciais separadas em várias aplicações e sistemas. 
+  Você não automatizou o ciclo de vida das identidades dos usuários da força de trabalho, por exemplo, integrando seu provedor de identidade aos seus sistemas de RH. Quando um usuário deixa sua organização ou muda de função, você segue um processo manual para excluir ou atualizar seus registros em várias aplicações e sistemas. 

 **Benefícios de estabelecer esta prática recomendada:** Ao usar um provedor de identidade centralizado, você tem um único local para gerenciar as identidades e políticas dos usuários da força de trabalho, a capacidade de atribuir acesso às aplicações a usuários e grupos e a capacidade de monitorar a atividade de login do usuário. Ao se integrar aos seus sistemas de recursos humanos (RH), quando um usuário muda de função, essas alterações são sincronizadas com o provedor de identidade e atualizam automaticamente as aplicações e permissões atribuídas. Quando um usuário sai da sua organização, sua identidade é automaticamente desativada no provedor de identidade, revogando seu acesso a aplicações e sistemas federados. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida**: alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 **Orientação para usuários da força de trabalho que acessam a AWS** 

 Usuários da força de trabalho em sua organização, como funcionários e prestadores de serviços, podem precisar acessar a AWS usando o Console de gerenciamento da AWS ou a AWS Command Line Interface (AWS CLI) para realizar suas funções de trabalho. Você pode conceder acesso à AWS aos usuários da sua força de trabalho federando a partir de seu provedor de identidade centralizado para a AWS em dois níveis: federação direta para cada Conta da AWS ou federação para várias contas na [organização da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html). 
+  Para federar os usuários da sua força de trabalho diretamente com cada Conta da AWS, você pode usar um provedor de identidade centralizado para federar o [AWS Identity and Access Management](https://aws.amazon.com/iam/) nessa conta. A flexibilidade do IAM permite que você habilite um [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) ou um [provedor de identidade Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) para cada Conta da AWS e use atributos de usuário federados para controle de acesso. Os usuários da sua força de trabalho usarão o navegador da web para fazer login no provedor de identidade fornecendo suas respectivas credenciais (como senhas e códigos de token MFA). O provedor de identidade emite uma declaração SAML para o navegador, que é enviada ao URL de login do Console de gerenciamento da AWS para permitir que o usuário faça autenticação única no [Console de gerenciamento da AWS assumindo uma função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Seus usuários também podem obter credenciais temporárias de API da AWS para uso na [AWS CLI](https://aws.amazon.com/cli/) ou [em AWS SDKs](https://aws.amazon.com/developer/tools/) pelo [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) assumindo [a função do IAM usando uma declaração SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) do provedor de identidade. 
+  Para federar seus usuários da força de trabalho com várias contas em sua organização da AWS, você pode usar o [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) para gerenciar centralmente o acesso dos usuários de sua força de trabalho a Contas da AWS e aplicações. Você ativa o Centro de Identidade para sua organização e configura sua fonte de identidade. O IAM Identity Center fornece um diretório de origem de identidade padrão que você pode usar para gerenciar seus usuários e grupos. Como alternativa, você pode escolher uma fonte de identidade externa [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) usando SAML 2.0 e [provisionando automaticamente](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) usuários e grupos usando o SCIM ou [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) com o uso do [Directory Service](https://aws.amazon.com/directoryservice/). Depois que uma fonte de identidade é configurada, você pode atribuir acesso a usuários e grupos a Contas da AWS definindo políticas de privilégios mínimos em seus [conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Os usuários da sua força de trabalho podem se autenticar por meio de seu provedor de identidade central para entrar no [portal de acesso da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) e autenticação única em Contas da AWS e aplicações em nuvem atribuídas a eles. Seus usuários podem configurar a [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) para se autenticar com o Centro de Identidade e obter credenciais para executar comandos da AWS CLI. O Centro de Identidade também permite acesso com autenticação única a aplicações da AWS, como o [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) e [portais do AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html). 

 Depois de seguir as orientações anteriores, os usuários da sua força de trabalho não precisarão mais usar IAM users e grupos para operações normais ao gerenciar workloads na AWS. Em vez disso, seus usuários e grupos são gerenciados fora da AWS e os usuários podem acessar os recursos da AWS como uma *identidade federada*. As identidades federadas usam os grupos definidos pelo seu provedor de identidade centralizado. Você deve identificar e remover grupos do IAM, IAM users e credenciais de usuário de longa duração (senhas e chaves de acesso) que não são mais necessárias nas suas Contas da AWS. Você pode [encontrar credenciais não utilizadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) com o uso do [relatórios de credenciais do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [excluindo IAM users correspondentes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) e [excluindo grupos do IAM.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) Você pode aplicar uma [política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) na sua organização, o que ajudará a impedir a criação de novos grupos e IAM users, forçando que esse acesso ocorra por meio de identidades federadas da AWS. 

 **Orientação para usuários de suas aplicações** 

 Você pode gerenciar as identidades dos usuários de suas aplicações, como um aplicativo móvel, usando o [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) como seu provedor de identidade centralizado. O Amazon Cognito permite autenticação, autorização e gerenciamento de usuários de seus aplicativos móveis e da web. O Amazon Cognito fornece um repositório de identidades que pode ser expandido para milhões de usuários, oferece suporte à federação de identidades sociais e corporativas e oferece recursos avançados de segurança para ajudar a proteger seus usuários e sua empresa. Você pode integrar seu aplicativo web ou móvel personalizado ao Amazon Cognito para adicionar autenticação de usuário e controle de acesso aos seus aplicativos em minutos. Desenvolvido com base em padrões de identidade abertos, como SAML e Open ID Connect (OIDC), o Amazon Cognito oferece suporte a vários regulamentos de conformidade e se integra aos recursos de desenvolvimento de front-end e back-end. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Etapas para usuários da força de trabalho acessarem a AWS** 
+  Federe os usuários da sua força de trabalho à AWS usando um provedor de identidade centralizado de acordo com uma das seguintes abordagens: 
  +  Use o IAM Identity Center para habilitar a autenticação única para várias Contas da AWS em sua organização da AWS, federando com seu provedor de identidade. 
  +  Use o IAM para conectar seu provedor de identidade diretamente a cada Conta da AWS, permitindo acesso federado refinado. 
+  Identifique e remova IAM users e grupos que são substituídos por identidades federadas. 

 **Etapas para usuários de suas aplicações** 
+  Use o Amazon Cognito como um provedor de identidade centralizado para suas aplicações. 
+  Integre suas aplicações personalizadas com o Amazon Cognito usando o OpenID Connect e o OAuth. Você pode desenvolver suas aplicações personalizadas usando as bibliotecas do Amplify que fornecem interfaces simples para integração com uma variedade de serviços da AWS, como o Amazon Cognito para autenticação. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC02-BP06 Utilizar grupos e atributos de usuários](sec_identities_groups_attributes.md) 
+  [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md) 
+  [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](sec_permissions_lifecycle.md) 

 **Documentos relacionados:** 
+  [Federação de identidades na AWS](https://aws.amazon.com/identity/federation/) 
+  [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Práticas recomendadas do AWS Identity and Access Management](https://aws.amazon.com/iam/resources/best-practices/) 
+  [Introdução à administração delegada do IAM Identity Center](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/) 
+  [Como usar políticas gerenciadas pelo cliente no IAM Identity Center para casos de uso avançados](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/) 
+  [AWS CLI v2: provedor de credenciais do IAM Identity Center](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html) 

 **Vídeos relacionados:** 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive (AWS re:Inforce 2022: aprofundamento no AWS Identity and Access Management (IAM))](https://youtu.be/YMj33ToS8cI) 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center (AWS re:Invent 2022: simplifique o acesso existente de sua força de trabalho com o IAM Identity Center)](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake (AWS re:Invent 2018: dominar a identidade em todos os aspectos)](https://youtu.be/vbjFjMNVEpc) 

 **Exemplos relacionados:** 
+  [Workshop: Using Centro de Identidade do AWS IAM to achieve strong identity management (Uso do Centro de Identidade do AWS IAM para conseguir um forte gerenciamento de identidade)](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US) 
+  [Workshop: Serverless identity (Identidade sem servidor)](https://identity-round-robin.awssecworkshops.com/serverless/) 

 **Ferramentas relacionadas:** 
+  [Parceiros de competência em segurança da AWS: gerenciamento de identidade e acesso](https://aws.amazon.com/security/partner-solutions/) 
+  [saml2aws](https://github.com/Versent/saml2aws) 

# SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais
<a name="sec_identities_audit"></a>

Audite e alterne as credenciais periodicamente para limitar o período durante o qual as credenciais podem ser usadas para acessar seus recursos. Credenciais de longo prazo criam muitos riscos, e estes podem ser reduzidos alternando credenciais de longo prazo regularmente.

 **Resultado desejado:** implementar a alternância de credenciais para ajudar a reduzir os riscos associados ao uso de credenciais de longo prazo. Auditar e corrigir regularmente a não conformidade com políticas de alternância de credenciais. 

 **Antipadrões comuns:** 
+  Não auditar o uso de credenciais. 
+  Utilizar credenciais de longo prazo desnecessariamente. 
+  Utilizar credenciais de longo prazo e não alterná-las regularmente. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Quando você não puder contar com credenciais temporárias e exigir credenciais de longo prazo, faça uma auditoria das credenciais para garantir que os controles definidos, por exemplo, autenticação multifator (MFA), sejam aplicados, alternados regularmente e que tenham o nível de acesso apropriado. 

 A validação periódica, preferencialmente por meio de uma ferramenta automatizada, é necessária para verificar se os controles corretos são aplicados. Para identidades humanas, você deve exigir que os usuários alterem suas senhas periodicamente e substituam chaves de acesso por credenciais temporárias. Ao migrar de usuários do AWS Identity and Access Management (IAM) para identidades centralizadas, é possível [gerar um relatório de credenciais](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) para fazer auditoria de seus usuários. 

 Também recomendamos implementar e monitorar a MFA no provedor de identidades. É possível configurar o [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) ou usar [Padrões de segurança AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) para monitorar se os usuários têm a MFA ativada. Considere utilizar o IAM Roles Anywhere para fornecer credenciais temporárias para identidades de máquina. Em situações em que o uso de perfis do IAM e credenciais temporárias não é possível, é necessário realizar auditoria frequente e alternar as chaves de acesso. 

 **Etapas da implementação** 
+  **Fazer auditoria nas credenciais regularmente:** a auditoria das identidades configuradas em seu provedor de identidades e no IAM ajuda a garantir que somente identidades autorizadas tenham acesso à sua workload. Essas identidades podem incluir, entre outros, usuários do IAM, do Centro de Identidade do AWS IAM, do Active Directory ou usuários em um provedor de identidades upstream diferente. Por exemplo, remova as pessoas que saem da organização e as funções entre contas que não são mais necessárias. Estabeleça um processo para auditar periodicamente as permissões para os serviços acessados por uma entidade do IAM. Isso ajuda a identificar as políticas que você precisa modificar a fim de remover todas as permissões não utilizadas. Use relatórios de credenciais e o [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para auditar credenciais e permissões do IAM. É possível utilizar o [Amazon CloudWatch para configurar alarmes para chamadas de API específicas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) chamadas em seu ambiente da AWS. [O Amazon GuardDuty também pode alertar você sobre atividade inesperada](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), que pode indicar acesso excessivamente permissivo ou acesso acidental às credenciais do IAM. 
+  **Alternar credenciais regularmente:** quando você não pode utilizar credenciais temporárias, alterne as chaves de acesso do IAM de longo prazo regularmente (no máximo, a cada 90 dias). Se uma chave de acesso for divulgada acidentalmente sem seu conhecimento, isso limitará o período de uso das credenciais para acessar seus recursos. Para ter informações sobre a alternância de chaves de acesso para usuários do IAM, consulte [Alternar chaves de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey). 
+  **Revisar as permissões do IAM**: para melhorar a segurança de sua Conta da AWS, revise e monitore regularmente cada uma das políticas do IAM. Verifique se as políticas seguem o princípio de privilégio mínimo. 
+  **Considerar automatizar a criação e as atualizações dos recursos do IAM:**o IAM Identity Center automatiza muitas tarefas do IAM, como o gerenciamento de perfis e políticas. Como alternativa, o AWS CloudFormation pode ser usado para automatizar a implantação de recursos do IAM, como perfis e políticas, para reduzir a chance de erros humanos, pois os modelos podem ser verificados e ter controle de versão. 
+  **Utilizar o IAM Roles Anywhere para substituir os usuários do IAM para identidades de máquina:** o IAM Roles Anywhere possibilita usar perfis em áreas onde não seria possível tradicionalmente, como em servidores on-premises. O IAM Roles Anywhere utiliza um certificado X.509 confiável para realizar a autenticação na AWS e receber credenciais temporárias. O uso do IAM Roles Anywhere evita a necessidade de alternar essas credenciais, pois credenciais de longo prazo não são mais armazenadas em seu ambiente on-premises. Você precisará monitorar e alternar o certificado X.509 ao aproximar-se da validade. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md) 
+  [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md) 

 **Documentos relacionados:** 
+  [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Provedores de identidades e federação](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Soluções de parceiros de segurança: acesso e controle de acesso](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [Credenciais de segurança temporárias](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+ [ Obter relatórios de credenciais da sua Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)

 **Vídeos relacionados:** 
+  [Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala](https://youtu.be/qoxxRlwJKZ4) 
+  [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E) 
+  [Dominar a identidade em todos os aspectos](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Exemplos relacionados:** 
+ [ Well-Architected Lab: Limpeza automatizada de usuários do IAM ](https://wellarchitectedlabs.com/security/200_labs/200_automated_iam_user_cleanup/)
+ [ Well-Architected Lab: Implantação automatizada de grupos e perfis do IAM ](https://wellarchitectedlabs.com/security/200_labs/200_automated_deployment_of_iam_groups_and_roles/)

# SEC02-BP06 Utilizar grupos e atributos de usuários
<a name="sec_identities_groups_attributes"></a>

 À medida que o número de usuários gerenciados cresce, você precisará determinar maneiras de organizá-los para que você possa gerenciá-los em grande escala. Coloque usuários com requisitos de segurança comuns em grupos definidos pelo provedor de identidade e implemente mecanismos para garantir que os atributos de usuário que podem ser usados para controle de acesso (por exemplo, departamento ou localização) estejam corretos e atualizados. Use esses grupos e atributos para controlar o acesso em vez de usuários individuais. Isso permite que você gerencie o acesso centralmente, alterando a associação ao grupo ou os atributos de um usuário uma vez com um [conjunto de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html), em vez de atualizar várias políticas individuais quando as necessidades de acesso de um usuário mudarem. Você pode usar o Centro de Identidade do AWS IAM (IAM Identity Center) para gerenciar grupos e atributos de usuários. O IAM Identity Center oferece suporte aos atributos mais usados, quer eles sejam inseridos manualmente durante a criação do usuário ou provisionados automaticamente usando um mecanismo de sincronização, como definido na especificação System for Cross-Domain Identity Management (SCIM). 

Coloque usuários com requisitos de segurança comuns em grupos definidos pelo provedor de identidade e implemente mecanismos para garantir que os atributos de usuário que podem ser usados para controle de acesso (por exemplo, departamento ou localização) estejam corretos e atualizados. Use esses grupos e atributos, em vez de usuários individuais, para controlar o acesso. Com isso, você pode gerenciar o acesso centralmente. Basta alterar uma vez a associação ou os atributos do grupo de um usuário. Ou seja, não será preciso atualizar muitas políticas individuais quando as necessidades de acesso de um usuário mudarem.

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Se estiver usando o Centro de Identidade do AWS IAM (IAM Identity Center), configure grupos: o IAM Identity Center permite configurar grupos de usuários e atribuir aos grupos o nível desejado de permissão. 
  +  [AWS Single Sign-On: gerenciar identidades](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  Saiba mais sobre o controle de acesso por atributo (ABAC): o ABAC é uma estratégia de autorização que define permissões com base em atributos. 
  +  [O que é ABAC para a AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
  +  [Laboratório: Controle de acesso baseado em tags do IAM para o EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Provedores de identidade e federação](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [O usuário raiz da conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **Vídeos relacionados:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with Centro de Identidade do AWS IAM (Gerenciar permissões de usuário em grande escala com o AWS SSO)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Exemplos relacionados:** 
+  [Laboratório: Controle de acesso baseado em tags do IAM para o EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

# SEGURANÇA 3. Como gerenciar permissões para pessoas e máquinas?
<a name="sec-03"></a>

 Gerencie permissões para controlar o acesso a identidades de pessoas e máquinas que precisam de acesso à AWS e à sua workload. As permissões controlam quem pode acessar o quê e em quais condições. 

**Topics**
+ [SEC03-BP01 Definir requisitos de acesso](sec_permissions_define.md)
+ [SEC03-BP02 Conceder acesso com 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 segurança com terceiros](sec_permissions_share_securely_third_party.md)

# SEC03-BP01 Definir requisitos de acesso
<a name="sec_permissions_define"></a>

Cada componente ou recurso de sua workload precisa ser acessado por administradores, usuários finais ou outros componentes. É necessário ter uma definição clara de quem ou do que deve ter acesso a cada componente, escolher o tipo de identidade apropriado e o método de autenticação e autorização.

 **Antipadrões comuns:** 
+ Codificação rígida ou armazenamento de segredos em sua aplicação. 
+ Conceder permissões personalizadas a cada usuário. 
+ Uso de credenciais de longa duração. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Cada componente ou recurso de sua workload precisa ser acessado por administradores, usuários finais ou outros componentes. É necessário ter uma definição clara de quem ou do que deve ter acesso a cada componente, escolher o tipo de identidade apropriado e o método de autenticação e autorização.

O acesso regular a Contas da AWS na 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 identidades 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. [As políticas gerenciadas pela AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) fornecem políticas predefinidas do IAM que abordam a maioria dos casos de uso comuns.

Os 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 segredos da aplicação ou workload com segurança em casos em que não é possível usar perfis do IAM. No Secrets Manager, você pode estabelecer uma alternância automática de 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.

Você pode usar o AWS Identity and Access Management Roles Anywhere 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. As 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 as aplicações da AWS para acessar os 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 da IAM com acesso programático e credenciais de longa duração, use [as últimas informações usadas da chave de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) para alternar e remover chaves de acesso. 

## Recursos
<a name="resources"></a>

 **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 Managed policies for IAM Identity Center (Políticas gerenciadas pela AWS para o IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 
+  [AWS IAM policy conditions (Condições de políticas do AWS IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 
+  [IAM use cases (Casos de uso do IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html) 
+  [Remova credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Trabalhando com políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+  [How to control access to AWS resources based on Conta da AWS, OU, or organization (Como controlar o acesso aos recursos da AWS baseados 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/) 
+  [Identify, arrange, and manage secrets easily using enhanced search in AWS Secrets Manager (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:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Torne-se um mestre em políticas do IAM em 60 minutos ou menos)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separação de tarefas, privilégio mínimo, delegação e CI/CD)](https://youtu.be/3H0i7VyTu70) 
+  [Streamlining identity and access management for innovation (Simplificação do gerenciamento de identidade e acesso para inovação)](https://www.youtube.com/watch?v=3qK0b1UkaE8) 

# SEC03-BP02 Conceder acesso com privilégio mínimo
<a name="sec_permissions_least_privileges"></a>

 É prática recomendada conceder somente o acesso de que as identidades 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, você pode 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, o acesso dele é automaticamente revogado sem alterar as políticas de acesso adjacentes. 

**Resultado desejado:** os usuário somente têm permissões necessárias para fazerem seus respectivos trabalhos. Os usuários devem ter acesso apenas a ambientes de produção para realizar uma tarefa específica dentro de um período limitado e o acesso deve ser revogado quando a tarefa for concluída. As permissões devem ser revogadas quando não forem mais necessárias, incluindo quando um usuário for para um projeto diferente ou mudar de cargo. Privilégios de administrador devem ser concedidos apenas a um grupo pequeno de administradores confiáveis. As permissões devem ser revistas regularmente para evitar desvios de permissão. Contas de máquina ou sistema devem ter apenas o mínimo de permissões necessárias para concluir as tarefas. 

**Antipadrões comuns:**
+  Usar como padrão a concessão de permissões de administrador aos usuários. 
+  Usar o usuário raiz para atividades diárias. 
+  Criar políticas permissivas demais, mas sem privilégios completos de administrador. 
+  Não revisar as permissões para entender se elas permitem o acesso de privilégio mínimo. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O princípio de estados [privilégio mínimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#grant-least-privilege) para as identidades deve ser apenas permitido para realizar o mínimo 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 e deve ser controlado e monitorado rigidamente, além de usado apenas para [tarefas que necessitam acesso 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 e associar 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, ao usar `PrincipalOrgID` como [chave de condição](https://docs.aws.amazon.com//latest/UserGuide/reference_policies_condition-keys.html), você pode negar ações se o solicitante não for 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 a criação, pelo AWS CloudFormation, de uma função do AWS Lambda, usando a chave de condição `CalledVia`. Tipos diferentes de política devem estar em camadas para estabelecer a defesa em profundidade e limitar as permissões gerais de seus usuários. Você pode restringir as permissões que podem ser concedidas e sob quais condições. Por exemplo, você pode permitir que suas equipes de aplicação criem suas próprias políticas do IAM para os sistemas que criam, mas deve também aplicar uma [Fronteira de permissão](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) para limitar o máximo de permissões que o sistema pode receber. 

 **Etapas da 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 ou o perfil do usuário que você definiu. 
  +  **Basear as políticas no uso da API**: uma maneira de determinar as permissões necessárias é analisar os logs do AWS CloudTrail. Essa análise permite que você crie permissões personalizadas para as ações do usuário dentro da AWS. O [IAM Access Analyzer pode gerar automaticamente uma IAM política com base](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) [na atividade](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). Você pode usar o IAM Access Advisor no nível da organização ou da conta para [rastrear](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) [as últimas informações acessadas para determinada política](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html). 
+  **Considerar o uso de [políticas gerenciadas da AWS para cargos](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html).** Pode ser difícil saber por onde começar ao criar políticas de permissões mais estritas. A AWS gerencia políticas 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 ao determinar como implementar as políticas de privilégio mínimo. 
+  **Remover permissões desnecessárias:** remova permissões que não são necessárias e ajuste políticas muito permissivas. A [geração de política pelo IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-policy-generation.html) pode ajudar a ajustar as políticas de permissão. 
+  **Garantir que os usuários tenham acesso limitado a ambientes de produção:** os usuários devem ter acesso a ambientes de produção apenas com um caso de uso válido. Depois de o usuário realizar as tarefas específicas para as quais foi necessário o acesso à produção, o acesso deve ser revogado. Limitar o acesso a ambientes de produção evita eventos não intencionais e que causam impacto à produção, além de diminuir o escopo do impacto do acesso não intencional. 
+ **Considerar os limites de permissões:** um limite de permissões é um recurso 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 ela execute apenas as ações aceitas por suas políticas baseadas em identidade e seus limites de permissões.  
+  **Considerar [tags de recursos](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) para permissões:** um modelo de controle de acesso baseado em atributo que usa tags de recursos permite conceder acesso com base no propósito do recurso, proprietário, ambiente ou outros critérios. Por exemplo, você pode usar tags de recurso para diferenciar entre ambientes de desenvolvimento e produção. Ao usar essas tags, é possível restringir os desenvolvedores ao ambiente de desenvolvimento. Ao combinar as tags e as políticas de permissões, você consegue alcançar um acesso restrito ao recurso sem precisar definir políticas complicadas e personalizadas para cada cargo. 
+  **Use [políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) para AWS Organizations.** As políticas de controle de serviço controlam centralmente o máximo de permissões disponíveis para contas de membros em sua organização. É importante notar que as políticas de controle de serviço permitem que você restrinja as permissões do usuário raiz nas contas de membros. Considere também o uso do 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. 
+  **Estabelecer uma política de ciclo de vida para sua organização:** as políticas de ciclo de vida do usuário definem tarefas a serem realizadas quando os usuários entram na AWS, mudam de cargo ou escopo de trabalho ou não precisam mais de acesso à AWS. As análises de permissão devem ser feitas durante todas as etapas do ciclo de vida do usuário para verificar se as permissões estão adequadamente restritas e para evitar desvios nas permissões. 
+  **Estabelecer uma programação regular para rever as permissões e remover as permissões desnecessárias:** frequentemente, você deve verificar o acesso do usuário para garantir que ele não tenha acesso muito permissivo. O [AWS Config](https://aws.amazon.com/config/) e o IAM Access Analyzer podem ajudar ao auditar as permissões do usuário. 
+ **Estabelecer uma matriz de cargos:** uma matriz de cargos exibe os diversos cargos e níveis de acesso necessários dentro de sua área 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 cargos individuais.**  **

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceder privilégio mínimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html?ref=wellarchitected#grant-least-privilege) 
+  [Permissions boundaries for IAM entities](https://docs.aws.amazon.com//latest/UserGuide/access_policies_boundaries.html) (Limites de permissões para entidades do IAM) 
+  [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) (Técnicas para escrever políticas do IAM de privilégio mínimo) 
+  [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM](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/) [policies based on access activity](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/) (IAM Access Analyzer facilita a implementação de permissões de privilégio mínimo gerando políticas do IAM baseadas na atividade de acesso) 
+  [Delegate permission management to developers by using IAM permissions boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) (Delegar gerenciamento de permissões para desenvolvedores usando os limites de permissões do IAM) 
+  [Refining Permissions using last accessed information (Refinar permissões usando as últimas informações acessadas)](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) 
+  [IAM policy types and when to use them](https://docs.aws.amazon.com//latest/UserGuide/access_policies.html) (Tipos de política do IAM e quando usá-las) 
+  [Testing IAM policies with the IAM policy simulator](https://docs.aws.amazon.com//latest/UserGuide/access_policies_testing-policies.html) (Testar políticas do IAM com o simulador de política do IAM) 
+  [Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) (Barreiras de proteção no AWS Control Tower) 
+  [Zero Trust architectures: An AWS perspective](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) (Arquiteturas de confiança zero: uma perspectiva da AWS) 
+  [How to implement the principle of least privilege with CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) (Como implementar o princípio de privilégio mínimo com o CloudFormation StackSets) 
+  [Controle de acesso baseado em atributos (ABAC)](https://docs.aws.amazon.com//latest/UserGuide/introduction_attribute-based-access-control.html?ref=wellarchitected) 
+ [Redução do escopo da política ao exibir a atividade do usuário](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html?ref=wellarchitected) 
+  [Visualizar acesso do cargo](https://docs.aws.amazon.com//latest/UserGuide/id_roles_manage_delete.html?ref=wellarchitected#roles-delete_prerequisites) 
+  [Use a marcação para organizar seu ambiente e gerar responsabilidade](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html?ref=wellarchitected) 
+  [Estratégias de marcação da AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/?ref=wellarchitected) 
+  [Marcação de recursos da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/quicksight-iam-identity-center/) 

 **Vídeos relacionados:** 
+  [Next-generation permissions management (Gerenciamento de permissões de última geração)](https://www.youtube.com/watch?v=8vsD_aTtuTo) 
+  [Zero Trust: An AWS perspective](https://www.youtube.com/watch?v=1p5G1-4s1r0) (Confiança zero: uma perspectiva da AWS) 
+  [How can I use permissions boundaries to limit users and roles to prevent privilege escalation?](https://www.youtube.com/watch?v=omwq3r7poek) (Como posso usar limites de permissões para limitar usuários e funções e evitar escalação do privilégio?) 

 **Exemplos relacionados:** 
+  [Lab: IAM permissions boundaries delegating role creation](https://wellarchitectedlabs.com/Security/300__Permission_Boundaries_Delegating_Role_Creation/README.html) (Laboratório: limites de permissões do IAM que delegam a criação de perfis) 
+  [Lab: IAM tag based access control for EC2](https://wellarchitectedlabs.com/Security/300__Tag_Based_Access_Control_for_EC2/README.html?ref=wellarchitected) (Laboratório: controle de acesso baseado em tags do IAM para EC2) 

# SEC03-BP03 Estabelecer processo de acesso de emergência
<a name="sec_permissions_emergency_process"></a>

 Crie um processo que permita acesso emergencial às suas workloads no caso improvável de um problema com seu provedor de identidades centralizado. 

 Você deve criar processos para diferentes modos de falha que possam 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 as respectivas 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é que o mecanismo normal de federação seja 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. Você pode encontrar as perguntas e as práticas recomendadas no [Pilar Confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) útil para identificar modos de falha e arquitetar sistemas mais resilientes com o objetivo de 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 manuais 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, projete o processo para ser o mais simples possível. 

 **Antipadrões comuns:** 
+  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 surge um evento de emergência. 
+  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 a 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 frequentemente usam 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 estabelecer 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. 
+  Você pode 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
<a name="implementation-guidance"></a>

 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 IAM users e perfis e os perfis entre contas do IAM em todas as contas da workload. Isso verifica se esses recursos estão prontos e disponíveis quando ocorre um evento de emergência. Ao pré-criar recursos, você não depende das APIs do ambiente de gerenciamento da AWS [(usadas para criar e modificar recursos](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) da AWS) que podem ficar indisponíveis em caso de emergência. Além disso, ao pré-criar recursos do IAM, você não precisa contabilizar [possíveis atrasos devido à eventual consistência.](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 ([SEC10-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, acompanhar 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. 
+  Verifique se o processo gera logs e eventos de auditoria detalhados para tentativas bem-sucedidas e fracassadas de obter acesso de emergência. Monitore o processo de solicitação e o mecanismo de acesso de emergência para detectar uso indevido ou acessos não autorizados. Correlacione a atividade com eventos de emergência contínuos do sistema de gerenciamento de incidentes e alerte quando as ações ocorrerem fora dos períodos esperados. Por exemplo, você deve monitorar e alertar sobre atividades na Conta da AWS de acesso de emergência, pois ela nunca deve ser usada em operações normais. 
+  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. Os 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 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 federar na AWS não está disponível** 

 Conforme descrito em [SEC02-BP04 Contar com um provedor de identidades centralizado](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 IAM Identity Center 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 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 do IAM e IAM users) 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: 
+  Você pode pré-criar um conjunto de [IAM users](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 IAM users 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 a função do IAM de acesso de emergência na conta de emergência e, por fim, muda para a função 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 IAM user é atribuído a um administrador de emergência, e você pode saber qual usuário fez login analisando os eventos do CloudTrail. A desvantagem é que você precisa manter vários IAM users com as respectivas senhas de longa duração e tokens de MFA associados. 
+  Você pode usar o [usuário raiz da Conta da AWS de acesso de emergência](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 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, você pode configurar o IAM Identity Center 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. Depois que a federação for 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 IAM Identity Center 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 receber detalhes sobre as considerações sobre o processo e o 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 da implementação
<a name="implementation-steps"></a>

 **Etapas comuns para todos os modos de falha** 
+  Crie uma Conta da AWS dedicado aos processos de acesso de emergência. Pré-crie os recursos do IAM necessários na conta, como perfis do IAM ou IAM users 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. Você pode 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 de membros de sua organização. 
+  Crie políticas de controle de serviço do AWS Organizations [(SCPS)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) para negar a exclusão e a modificação dos perfis do IAM entre contas nas Contas da AWS de membros. 
+  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 de emergência do IAM. 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, e o Modo de falha 2: a configuração do provedor de identidades na AWS foi modificada ou expirou** 
+  Pré-crie recursos de acordo com o mecanismo escolhido para acesso de emergência: 
  +  **Usar IAM users:** pré-crie-os IAM users com senhas fortes e dispositivos de MFA associados. 
  +  **Usar 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
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC02-BP04 Contar com um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html) 
+  [SEC03-BP02 Conceder acesso com 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 dias de jogo](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) 
+  [Permitir que usuários federados do SAML 2.0 acessem o 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 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI) 

 **Exemplos relacionados:** 
+  [Perfil de acesso de emergência da AWS](https://github.com/awslabs/aws-break-glass-role) 
+  [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework) 
+  [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks) 

# SEC03-BP04 Reduzir as permissões continuamente
<a name="sec_permissions_continuous_reduction"></a>

À 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. 

 **Antipadrões comuns:** 
+  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 é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Enquanto as equipes e os projetos estiverem 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 baseado em 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 conceder permissões aos usuários utilizando os atributos deles em vez de anexar políticas de permissões diretamente a cada usuário. 

 **Etapas da implementação** 
+  **Utilizar 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 na organização e nas 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). 
+  **Utilizar 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 detalhadas com base em um usuário do IAM ou na atividade de acesso de um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks). 
+  **Determinar um cronograma e uma política de uso aceitáveis para usuários e perfis do IAM:** utilize o [carimbo de data e hora de ú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](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) e removê-los. 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. Os 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ê os incorpore aos fluxos de trabalho de infraestrutura e ferramentas automatizadas. 
+  **Considerar [o registro em log dos 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, como atividade em nível de objeto do Amazon S3 (por exemplo, `GetObject` e `DeleteObject`) ou atividades de tabelas 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
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceder privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [Remova 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)
+  [Trabalhando com políticas](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)
+ [ Habilitar o log de eventos do CloudTrail para buckets e objetos do Amazon S3 ](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 em políticas do IAM em 60 minutos ou menos](https://youtu.be/YQsK4MtsELU) 
+  [Separação de tarefas, privilégio mínimo, delegação e CI/CD](https://youtu.be/3H0i7VyTu70) 
+ [AWS re:Inforce 2022: Aprofundamento 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
<a name="sec_permissions_define_guardrails"></a>

 Estabeleça controles comuns que restrinjam o acesso a todas as identidades na organização. Por exemplo, é possível restringir o acesso a Regiões da AWS específicas ou impedir que os operadores excluam recursos comuns, como um perfil do IAM usado pela equipe de segurança central. 

 **Antipadrões comuns:** 
+ Execução de workloads em sua conta de administrador organizacional. 
+ Execução de workloads de produção e não produção na mesma conta. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Com a expansão e o gerenciamento de workloads adicionais na AWS, você deve separá-las usando contas e gerenciá-las usando o AWS Organizations. Recomendamos que você estabeleça barreiras de proteção de permissões comuns que restrinjam o acesso a todas as identidades na sua organização. Por exemplo, você pode restringir o acesso a Regiões da AWS específicas ou impedir que a equipe exclua recursos comuns, como um perfil do IAM usado pela equipe de segurança central. 

 Você pode começar implementando exemplos de políticas de controle de serviço, como impedir que os usuários desabilitem os principais serviços. As SCPs usam a linguagem de políticas do IAM e permitem que você estabeleça controles aos quais todas as entidades principais (usuários e perfis) do IAM aderem. Você pode restringir o acesso a ações de serviço, recursos específicos e com base em condições específicas para atender às necessidades de controle de acesso de sua organização. Se necessário, você pode definir exceções para suas barreiras de proteção. Por exemplo, você pode restringir ações de serviço para todas as entidades do IAM na conta, exceto para um perfil de administrador específico. 

 Recomendamos evitar a execução de workloads em sua conta de gerenciamento. A conta de gerenciamento deve ser usada para gerir e implantar barreiras de proteção de segurança que afetarão as contas-membro. Alguns serviços da AWS permitem o uso de uma conta de administrador delegada. Quando disponível, você deve usar essa conta delegada em vez da conta de gerenciamento. Você deve limitar estritamente o acesso à conta de administrador organizacional. 

O uso de uma estratégia de várias contas permite ter maior flexibilidade na aplicação de barreiras de proteção às suas workloads. O AWS Security Reference Architecture dá orientações prescritivas sobre como projetar a estrutura da conta. Os serviços da AWS, como o AWS Control Tower, fornece recursos para gerenciar centralmente os controles de prevenção e detecção em sua organização. Defina um objetivo claro para cada conta ou UO em sua organização e limite os controles de acordo com esse objetivo. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Organizations](https://aws.amazon.com/organizations/) 
+ [Service control policies (SCPs) (Políticas de controle de serviços (SCPs))](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 
+ [Get more out of service control policies in a multi-account environment (Aproveite ao máximo as políticas de controle de serviços em um ambiente de várias contas)](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) 
+ [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) 

 **Vídeos relacionados:** 
+ [Enforce Preventive Guardrails using Service Control Policies (Aplique barreiras de proteção preventivas usando políticas de controle de serviços)](https://www.youtube.com/watch?v=mEO05mmbSms) 
+  [Building governance at scale with AWS Control Tower (Criação de governança em escala com o AWS Control Tower)](https://www.youtube.com/watch?v=Zxrs6YXMidk) 
+  [AWS Identity and Access Management deep dive (Análise aprofundada do AWS Identity and Access Management)](https://www.youtube.com/watch?v=YMj33ToS8cI) 

# SEC03-BP06 Gerenciar o acesso com base no ciclo de vida
<a name="sec_permissions_lifecycle"></a>

 Integre controles de acesso ao ciclo de vida do operador e da aplicação e ao seu provedor de federação centralizado. Por exemplo, remova o acesso do usuário que sair da organização ou mudar de funções. 

À medida que você gerencia cargas de trabalho usando contas separadas, haverá casos em que você precisará compartilhar recursos entre essas contas. Recomendamos que você compartilhe recursos usando o [AWS Resource Access Manager (AWS RAM)](http://aws.amazon.com/ram/). Esse serviço permite que você compartilhe, com facilidade e segurança, os recursos da AWS dentro da AWS Organizations e das unidades organizacionais. Usando o AWS RAM, o acesso a recursos compartilhados é concedido ou revogado automaticamente à medida que as contas são movidas para dentro e para fora da organização ou da unidade organizacional com a qual são compartilhadas. Isso ajuda a garantir que os recursos sejam compartilhados apenas com as contas que você determinar.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Ciclo de vida de acesso de usuário: implemente uma política de ciclo de vida de acesso para novos usuários, alterações de função de trabalho e usuários que saem, para que apenas os usuários atuais tenham acesso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AttributeControle de acesso baseado em atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 
+  [Remova credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Trabalhando com políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 

 **Vídeos relacionados:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Torne-se um mestre em políticas do IAM em 60 minutos ou menos)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separação de tarefas, privilégio mínimo, delegação e CI/CD)](https://youtu.be/3H0i7VyTu70) 

# SEC03-BP07 Analisar o acesso público e entre contas
<a name="sec_permissions_analyze_cross_account"></a>

Monitore continuamente as descobertas que destacam o acesso público e entre contas. Reduza o acesso público e o acesso entre contas somente aos recursos específicos que exigem esse acesso.

 **Resultado desejado:** saber quais de seus recursos da AWS são compartilhados e com quem. Monitorar e auditar continuamente seus recursos compartilhados para verificar se eles são compartilhados com apenas entidades principais autorizadas. 

 **Antipadrões comuns:** 
+  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 exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

 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 buckets do Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) ou permitindo que uma identidade principal em outra conta assuma um perfil 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/) utiliza [segurança demonstrável](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 configurar o IAM Access Analyzer com o AWS Organizations para verificar se você tem visibilidade a todas as suas contas. O IAM Access Analyzer também possibilita que você [visualize 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 projetar o acesso a várias contas, é possível utilizar [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 um perfil de fora de seu 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) configurados incorretamente, e por meio de verificações de politica do AWS Config, pode detectar recursos que tenham acesso público configurado. Serviços, como [AWS Control Tower](https://aws.amazon.com/controltower/) e [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) simplificam a implantação de controles de detecção e barreiras de proteção nos AWS Organizations para identificar e corrigir recursos publicamente expostos. Por exemplo, o AWS Control Tower tem uma barreira de proteção gerenciada que pode detectar se algum [snapshot do Amazon EBS é restaurado por Contas da AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html). 

 **Etapas da implementação** 
+  **Pensar em ativar o [AWS Config para AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** o AWS Config permite que você agregue as descobertas de várias contas em um AWS Organizations em uma conta de administrador delegada. Isso oferece uma visão abrangente e permite que você [implante o Regras do AWS Config nas contas para detectar recursos acessíveis ao público](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html). 
+  **Configurar o AWS Identity and Access Management Access Analyzer** o IAM Access Analyzer ajuda a identificar os recursos na organização e nas 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). 
+  **Usar autocorreção no AWS Config para responder a alterações na configuração do acesso público de buckets do Amazon S3:** [é possível reativar automaticamente as configurações de acesso público de bloco 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/). 
+  **Implementar o monitoramento e os alertas para identificar se os buckets do Amazon S3 se tornaram públicos:** é necessário ter o [monitoramento e os alertas](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) implementados para identificar quando o acesso público de blocos do Amazon S3 foi desativado e se os buckets do Amazon S3 se tornaram 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 confere se há buckets do Amazon S3 com permissões de acesso abertas. As permissões de bucket que concedem, upload ou excluem acesso 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 ter mais informações, consulte [Como usar o AWS Config para monitorar e responder a buckets do Amazon S3 que possibilitam 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 revisar o acesso, é importante considerar quais tipos de dados estão contidos em buckets do Amazon S3. O [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) ajuda a descobrir e proteger dados sigilosos, como PII, PHI e credenciais, como chaves privadas ou da AWS. 

## Recursos
<a name="resources"></a>

 **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)
+  [Norma de práticas de segurança básicas da AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+  [Regras gerenciadas do AWS Config](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)
+ [ Gerenciar regras do AWS Config em todas as contas de 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)

 **Vídeos relacionados:** 
+ [Práticas recomendadas para proteger seu ambiente de várias contas](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Análise aprofundada do IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)

# SEC03-BP08 Compartilhar recursos com segurança em sua organização
<a name="sec_permissions_share_securely"></a>

À 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. Você pode ter estruturas para fragmentar seu ambiente, como ter ambientes de desenvolvimento, teste e produção. No entanto, ter estruturas de separação não limita o compartilhamento seguro. 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:** minimizar o acesso acidental utilizando métodos seguros para compartilhar recursos com sua organização e ajudar com 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 de 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 ter orientações prescritivas sobre como analisar recursos compartilhados externamente, consulte [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md). 

 **Antipadrões comuns:** 
+  Falta de um processo para monitorar de forma contínua e alertar automaticamente sobre o compartilhamento externo inesperado. 
+  Falta de referência sobre o que deve ou não ser compartilhado. 
+  Ter 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 é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 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. Leia [Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) para ajudar você a estabelecer a governança a fim de reduzir o acesso externo apenas aos recursos que precisem dele e estabelecer um processo para monitorar de forma contínua e alertar automaticamente. 

 O compartilhamento entre contas no AWS Organizations é compatível com [uma série de serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), como o [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 o [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 realizar um backup de um recurso e compartilhá-lo entre contas. É possível utilizar 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 Transit Gateway](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 [Amazon SageMaker AI](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker). 

 Para restringir sua conta para somente compartilhar recursos em sua organização, utilize [políticas de controle de serviços (SCPs)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) para impedir o acesso a entidades principais 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) a fim de ajudar a proteger contra o acesso acidental. 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 de um perímetro de dados, é possível usar políticas de endpoint de 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ço (LSR) nem a 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 utilizar o Amazon S3, [desative as ACLs de seu bucket do Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) e utilize 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) a partir do [Amazon CloudFront](https://aws.amazon.com/cloudfront/), migre da identidade do acesso de origem (OAI) para um controle de acesso de origem (OAC), que é compatível com recursos adicionais, por exemplo, a 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 ter orientações prescritivas 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 da implementação** 

1.  **Utilize 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 que você cria e gerencia centralmente. É 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 aos serviços da AWS.** 

    Ao ativar um serviço da AWS para realizar tarefas em seu nome nas contas membros de sua organização, o AWS Organizations cria um perfil vinculado a serviço 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 ter orientações prescritivas 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 podem ser usados com o Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html). 

1.  **Estabeleça um perímetro de dados.** 

    O perímetro da AWS, geralmente, é representado como uma organização gerenciada pelo AWS Organizations. Junto com redes e sistemas on-premises, o acesso a recursos da AWS é o que muitos consideram o perímetro de My AWS. O objetivo do perímetro é garantir que o acesso seja permitido se a identidade e o recurso forem confiáveis e a rede for esperada. 

   1.  Defina e implante os perímetros. 

       Siga as etapas descritas em [Implementação do perímetro](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) do whitepaper Criar um perímetro na AWS para cada condição de autorização. Para ter orientações prescritivas sobre como proteger a camada de rede, consulte [Proteção de redes](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html). 

   1.  Monitore e alerte de forma contínua. 

       O [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) ajuda a identificar os recursos na organização e nas contas que são compartilhados com entidades externas. É possível integrar o [IAM Access Analyzer ao AWS Security Hub CSPM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-securityhub-integration.html) para enviar e agregar as descobertas para um recurso do IAM Access Analyzer para o Security Hub CSPM a fim de ajudar a analisar o procedimento de segurança de seu ambiente. Para ativar a integração, ative o IAM Access Analyzer e o Security Hub CSPM em cada região em cada conta. Também é possível utilizar o Regras do AWS Config para fazer auditoria da configuração e alertar a parte adequada utilizando o [Amazon Q Developer in chat applications com o AWS Security Hub CSPM](https://aws.amazon.com/blogs/security/enabling-aws-security-hub-integration-with-aws-chatbot/). Depois, você pode utilizar [Documentos de automação do AWS Systems Manager](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) para corrigir os recursos sem conformidade. 

   1.  Para ter orientações prescritivas sobre como monitorar e alertar de forma contínua sobre recursos compartilhados externamente, consulte [Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html). 

1.  **Utilize o compartilhamento de recursos em serviços da AWS e restrinja-o adequadamente.** 

    Muitos serviços da AWS possibilitam compartilhar recursos com outra conta ou almejar 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 compartilhar a AMI. Especifique a condição `ram:RequestedAllowsExternalPrincipals` ao utilizar o AWS RAM para restringir o compartilhamento somente à sua organização, a fim de ajudar a impedir o acesso de identidades não confiáveis. Para ter orientações prescritivas e consideraçõ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.  **Utilize o 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 com outras Contas da AWS. Em um ambiente de várias contas, o AWS RAM possibilita criar um recurso uma vez e compartilhá-lo com outras contas. Essa abordagem ajuda a reduzir sua sobrecarga operacional ao oferecer 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 compartilhados anteriormente com o uso de uma política baseada em recurso, é possível utilizar a API [https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) ou equivalente a fim de promover o compartilhamento de recursos para um compartilhamento completo de recursos do AWS RAM. 

    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
<a name="resources"></a>

 **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 segurança com terceiros](sec_permissions_share_securely_third_party.md) 
+  [SEC05-BP01 Criar camadas de rede](sec_network_protection_create_layers.md) 

 **Documentos relacionados:** 
+ [Proprietário do bucket concede permissão entre contas a 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/)
+ [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 podem ser usados 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 apenas que 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ítica de perímetro de dados ](https://github.com/aws-samples/data-perimeter-policy-examples)

# SEC03-BP09 Compartilhar recursos com segurança com terceiros
<a name="sec_permissions_share_securely_third_party"></a>

 A segurança de seu ambiente de nuvem não é interrompida em 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. A trabalhar em parceria com terceiros, é possível reduzir o escopo do impacto e o risco de acesso acidental. 

 **Resultado desejado:** credenciais do AWS Identity and Access Management (IAM) de longo prazo, chaves de acesso do IAM e chaves secretas associadas a um usuário podem ser usadas por qualquer pessoa desde que as credenciais sejam válidas e ativas. O uso de um perfil do IAM e credenciais temporárias ajuda você a melhorar seu procedimento de segurança geral reduzindo o esforço para manter credenciais de longo prazo, inclusive o gerenciamento e a sobrecarga operacional dessas informações sigilosas. Ao utilizar um identificador universalmente exclusivo (UUID) para o ID externo na política de confiança do IAM e manter as políticas do IAM anexadas ao perfil do IAM sob seu controle, é possível fazer auditoria e garantir que o acesso concedido a terceiros não seja permissivo demais. Para ter orientações prescritivas sobre como analisar recursos compartilhados externamente, consulte [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md). 

 **Antipadrões comuns:** 
+  Utilizar a política de confiança do IAM padrão sem condições. 
+  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 é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Talvez você deseje permitir o compartilhamento de recursos fora do AWS Organizations ou conceder a terceiros acesso à sua conta. Por exemplo, um parceiro (terceiros) 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 segurança com o uso da [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, terceiros 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 do AWS que utilizam 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. Esteja ciente de outros serviços da AWS compatíveis com o compartilhamento. Por exemplo, o AWS Well-Architected Tool possibilita o [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) ajuda você a compartilhar com segurança um recurso da AWS que você possua com outras contas. 

 **Etapas da implementação** 

1.  **Utilize 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 sigilosas armazenadas por contas externas e terceiros para atender aos clientes. Os perfis entre contas possibilitam a você conceder acesso a recursos da AWS em sua conta de forma segura a terceiros, como AWS Partners ou outras contas em sua organização e, ao mesmo tempo, manter 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 possibilitar que workloads de terceiros interajam com segurança com suas workloads da AWS e 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.  **Utilize um ID externo com terceiros.** 

    O uso de um [ID externo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) possibilita designar quem pode assumir um perfil em uma política de confiança do IAM. A política de confiança pode exigir que o usuário que assume o perfil imponha a condição e o destino no qual ele está operando. Ele também fornece uma maneira para que o proprietário da conta permita que a função seja assumida somente em circunstâncias específicas. A função principal do ID externo é resolver e evitar o problema de [substituto confuso](https://docs.aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/). 

    Utilize um ID externo se você for proprietário de uma Conta da AWS e tiver configurado um perfil para terceiros que acesse outras Contas da AWS além da sua, ou quando você pode assumir perfis em nome de clientes diferentes. Trabalhe com terceiros ou a AWS Partner para estabelecer uma condição de ID externo a ser incluída na política de confiança do IAM. 

1.  **Utilize IDs externos universalmente exclusivos.** 

    Implemente um processo que gere um valor exclusivo aleatório para um ID externo, como um identificador universalmente exclusivo (UUID). Um parceiro que reutilize IDs externos entre diferentes clientes não resolve o problema de substituto confuso porque o cliente A pode ser capaz de visualizar dados do cliente B utilizando o ARN do perfil do cliente B junto com o ID externo duplicado. Em um ambiente de vários locatários, em que um parceiro atende a vários clientes com diferentes Contas da AWS, o parceiro deve usar um ID exclusivo diferente como o ID externo de cada Conta da AWS. O parceiro é responsável por detectar IDs externos duplicados e mapear de forma segura cada cliente ao seu respectivo ID externo. O parceiro deve testar para verificar se ele pode assumir o perfil somente ao especificar o ID externo. O parceiro deve evitar armazenar o ARN do perfil do cliente e o ID externo até que este seja necessário. 

    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. 

1.  **Deprecie 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 como gerenciar chaves, consulte [Gerenciamento de identidades](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html). Trabalhe também com a equipe de sua Conta da AWS e o parceiro para estabelecer um runbook de mitigação de riscos. Para ter orientações prescritivas sobre como responder e mitigar o impacto em potencial do 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 tem orientações prescritivas ou é automatizada.** 

    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 parceiro 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 ter mais informações sobre como usar um modelo do CloudFormation para criar perfis entre contas, consulte [Perfis entre contas](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/). 

    O parceiro 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 CloudFormation ou equivalente, você deve monitorar alterações com detecção de desvios como parte da prática de auditoria. 

1.  **Considere alterações.** 

    Sua estrutura de contas, sua necessidade de terceiros ou a oferta de serviço pode ser alterada. 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 alertar você de 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 ter orientações prescritivas 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
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.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) 
+ [ SEC04 Detecção ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)

 **Documentos relacionados:** 
+ [ Proprietário do bucket concede permissão entre contas a 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 os perfis do IAM ](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [ Delegar acesso entre Contas da AWS usando funções do IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [ Como acesso 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 a seus recursos da AWS a terceiros ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [ Coletar informações de recursos do 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 ID externo com segurança para acessar contas da AWS pertencentes a outros ](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Estender perfis do IAM fora do IAM com 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 permito que usuários ou perfis em uma Conta da AWS separada acessem minha Conta da AWS? ](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Torne-se um mestre em políticas do IAM em 60 minutos ou menos ](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWSPráticas recomendadas do IAM e decisões de design ](https://www.youtube.com/watch?v=xzDFPIQy4Ks)

 **Exemplos relacionados:** 
+ [ Well-Architected Lab: Assumir perfil do IAM entre contas do Lambda (Nível 300)](https://www.wellarchitectedlabs.com/security/300_labs/300_lambda_cross_account_iam_role_assumption/)
+ [ 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)
+ [AWS STS Network Query Tool ](https://github.com/aws-samples/aws-sts-network-query-tool)

# Detecção
<a name="a-detective-controls"></a>

**Topics**
+ [SEGURANÇA 4. Como detectar e investigar eventos de segurança?](sec-04.md)

# SEGURANÇA 4. Como detectar e investigar eventos de segurança?
<a name="sec-04"></a>

Capture e analise eventos de logs e métricas para gerar visibilidade. Tome medidas em eventos de segurança e potenciais ameaças para ajudar a proteger sua carga de trabalho.

**Topics**
+ [SEC04-BP01 Configurar registro em log de serviço e aplicação](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada](sec_detect_investigate_events_analyze_all.md)
+ [SEC04-BP03 Automatizar a resposta a eventos](sec_detect_investigate_events_auto_response.md)
+ [SEC04-BP04 Implementar eventos de segurança acionáveis](sec_detect_investigate_events_actionable_events.md)

# SEC04-BP01 Configurar registro em log de serviço e aplicação
<a name="sec_detect_investigate_events_app_service_logging"></a>

Retenha logs de eventos de segurança de serviços e aplicações. Esse é um princípio fundamental de segurança para auditoria, investigações e casos de uso operacionais e um requisito de segurança comum orientado por padrões, políticas e procedimentos de governança, risco e conformidade (GRC).

 **Resultado desejado:** uma organização deve ser capaz de recuperar de forma confiável e consistente logs de ventos de segurança de serviços e aplicações da AWS de modo pontual quando necessário a fim de cumprir um processo ou obrigação interna, como resposta a incidentes de segurança. Considere centralizar os logs para ter melhores resultados operacionais. 

 **Antipadrões comuns:** 
+  Os logs são armazenados de forma perpétua ou excluídos muito precocemente. 
+  Todos podem acessar os logs. 
+  Contar inteiramente com processos manuais para uso e governança de logs. 
+  Armazenar todos os tipos de log em caso de necessidade. 
+  Conferir a integridade dos logs apenas quando necessário. 

 **Benefícios do estabelecimento desta prática recomendada:** implementar um mecanismo de análise da causa raiz (RCA) para incidentes de segurança e uma fonte de evidências para suas obrigações de governança, risco e conformidade. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Durante uma investigação de segurança ou outros casos de uso com base em seus requisitos, você precisa ser capaz de analisar os logs relevantes a fim de registrar e entender o escopo total e a linha do tempo do incidente. Os logs também são necessários para geração de alertas indicando que ocorreram determinadas ações de interesse. É essencial selecionar, ativar, armazenar e configurar mecanismos de consulta, recuperação e alertas. 

 **Etapas da implementação** 
+  **Selecione e ative fontes de logs.** Antes de uma investigação de segurança, você precisa capturar logs relevantes para reconstruir, de forma retroativa a atividade em uma Conta da AWS. Selecione e ative fontes de logs relevantes para suas workloads. 

   Os critérios de seleção de fonte de logs devem se basear nos casos de uso necessários à sua empresa. Estabeleça uma trilha para cada Conta da AWS utilizando o AWS CloudTrail ou uma trilha de AWS Organizations e configure um bucket do Amazon S3 para ela. 

   O AWS CloudTrail é um serviço de registro em log que rastreia chamadas de API feitas em uma Conta da AWS capturando a atividade do serviço da AWS. É ativado por padrão com uma retenção de 90 dias de eventos de gerenciamento que podem ser [recuperados por meio do histórico de eventos do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) utilizando o Console de gerenciamento da AWS, a AWS CLI ou um AWS SDK. Para ter uma retenção maior e visibilidade dos eventos de dados, [crie uma trilha do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) e associe-a a um bucket do Amazon S3 e opcionalmente com um grupo de logs do Amazon CloudWatch. Como alternativa, você pode criar um [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), que retém logs do CloudTrail por até sete anos e oferece um recursos e consultas baseado em SQL 

   A AWS recomenda que os clientes que utilizam uma VPC ativem o tráfego de rede e os logs de DNS por meio dos [Logs de fluxo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) e dos[logs de consultas doAmazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html), respectivamente, transmitindo-os a um bucket do Amazon S3 ou a um grupo de logs do CloudWatch. É possível criar um log de fluxo de VPC, uma sub-rede ou uma interface de rede. Para logs de fluxo de VPC, é possível ser seletivo em relação a como e onde usar os logs de fluxo para reduzir o custo. 

   Logs do AWS CloudTrail, Logs de fluxo de VPC e logs de consulta do Route 53 Resolver são as fontes básicas de registro em log para oferecer compatibilidade com investigações de segurança na AWS. Também é possível usar o [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) para coletar, normalizar e armazenar esses dados de logs no formato do Apache Parquet e no Open Cybersecurity Schema Framework (OCSF), que estão prontos para consulta. O Security Lake também é compatível com outros logs da AWS e logs de fontes de terceiros. 

   Os serviços da AWS podem gerar logs não capturados pelas fontes de log básicas, como logs do Elastic Load Balancing, logs do AWS WAF, logs de gravador do AWS Config, descobertas do Amazon GuardDuty, logs de auditoria do Amazon Elastic Kubernetes Service (Amazon EKS) e logs de aplicações e do sistema de instâncias do Amazon EC2. Para ter uma lista completa de opções de registro em log e monitoramento, consulte [Apêndice A: Definições de recursos de nuvem: registro em log e eventos](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/logging-and-events.html) do [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html). 
+  **Recursos de registro em log de pesquisa para cada serviço e aplicação da AWS:** cada serviço e aplicação da AWS oferecem opções armazenamento de logs, sendo cada um com seus próprios recursos de retenção e ciclo de vida. Os dois serviços de armazenamento de logs mais comuns são Amazon Simple Storage Service (Amazon S3) e Amazon CloudWatch. Para períodos de retenção longos, é recomendável utilizar o Amazon S3 para seus recursos de economia e ciclo de vida flexíveis. Se a opção de registro em log principal for logs do Amazon CloudWatch, como opção, você deve considerar o arquivamento de logs menos acessados no Amazon S3. 
+  **Selecione o armazenamento de logs:** a escolha do armazenamento de logs, geralmente, é relacionada a qual ferramenta de consultas você utiliza, recursos de retenção, familiaridade e custo. As principais opções para armazenamento de logs são um bucket do Amazon S3 ou um grupo de logs do CloudWatch. 

   Um bucket do Amazon S3 oferece armazenamento econômico e durável com uma política de ciclo de vida opcional. Os logs armazenados em buckets do Amazon S3 podem ser consultados com serviços como o Amazon Athena. 

   Um grupo de logs do CloudWatch oferece armazenamento durável e um recurso de consultas incorporado por meio do CloudWatch Logs Insights. 
+  **Identifique a retenção de logs apropriada:** quando você utiliza um bucket do Amazon S3 ou o grupo de logs do CloudWatch para armazenar logs, é necessário estabelecer ciclos de vida adequados para cada fonte de logs a fim de otimizar os custos de armazenamento e recuperação. Os clientes geralmente têm entre três meses a um ano de logs prontamente disponíveis para consultas, com retenção de até sete anos. A escolha de disponibilidade e retenção deve se alinhar aos seus requisitos de segurança e um composto de atribuições regulatórias, estatutárias e de negócios. 
+  **Ative o registro em log para cada serviço e aplicação da AWS com políticas adequadas de retenção e ciclo de vida:** para cada serviço ou aplicação da AWS em sua organização, procure as orientações específicas de configuração de registro em log: 
  + [ Configurar a trilha do AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
  + [ Configurar logs de fluxo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
  + [ Configurar as exportações de descobertas do Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html)
  + [ Configurar os registros do AWS Config](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-config.html)
  + [ Configurar o tráfego de ACL da web do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)
  + [ Configurar os logs de tráfego de rede do AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html)
  + [ Configurar logs de acesso do Elastic Load Balancing ](https://docs.aws.amazon.com/)
  + [ Configurar logs de consulta do Amazon Route 53 resolver ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)
  + [ Configurar logs do Amazon RDS ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html)
  + [ Configurar logs do ambiente de gerenciamento Amazon EKS ](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
  + [ Configurar o agente do Amazon CloudWatch para instâncias do Amazon EC2 e servidores on-premises ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+  **Selecione e implemente os mecanismos de consulta para logs:** para consultas de log, você pode usar o [CloudWatch Logs Insight](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)s para dados armazenados em grupos de logs do CloudWatch, e o [Amazon Athena](https://aws.amazon.com/athena/) e o [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) para dados armazenados no Amazon S3. Também é possível usar ferramentas de consulta de terceiros, como um serviço de gerenciamento de eventos e informações de segurança (SIEM). 

   O processo para selecionar uma ferramenta de consulta de log deve considerar as pessoas, o processo e os aspectos de tecnologia de suas operações de segurança. Selecione uma ferramenta que atenda aos requisitos operacionais, de negócios e segurança, esteja acessível e possa receber manutenção no longo prazo. Lembre-se de que as ferramentas de consulta de logs funcionam da forma ideal quando o número de logs a serem verificados é mantido dentro dos limites da ferramenta. Não é incomum ter várias ferramentas de consulta devido a restrições financeiras ou técnicas. 

   Por exemplo, você pode usar uma ferramenta de gerenciamento de eventos e informações de segurança (SIEM) de terceiros para realizar consultas para os últimos 90 dias de dados, mas usar o Athena para realizar consultas além de 90 dias devido ao custo de ingestão de logs de um SIEM. Seja qual for a implementação, garanta que sua abordagem minimize o número de ferramentas necessárias para maximizar a eficiência operacional, especialmente durante a investigação de um evento de segurança. 
+  **Use logs para alertas:** a AWS oferece alertas por meio de vários serviços de segurança: 
  +  O [AWS Config](https://aws.amazon.com/config/) monitora e registra as configurações de recursos da AWS e permite automatizar as tarefas de avaliação e correção em relação às configurações desejadas. 
  +  O [Amazon GuardDuty](https://aws.amazon.com/guardduty/) é um serviço de detecção de ameaças que monitora de forma contínua a existência de atividade mal-intencionada e comportamento não autorizado para proteger suas Contas da AWS e workloads. O GuardDuty ingere, agrega e analisa informações de fontes, como eventos de dados e gerenciamento do AWS CloudTrail, logs de DNS, logs de fluxo de VPC e logs do Amazon EKS Audit. O GuardDuty extrai fluxos de dados independentes diretamente do CloudTrail, de logs de fluxo de VPC, logs de consulta ao DNS e do Amazon EKS. Não é necessário gerenciar políticas de bucket do Amazon S3 nem modificar a forma de coletar e armazenar logs. Ainda é recomendável reter esses logs para sua própria investigação e fins de conformidade. 
  +  O [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) fornece um único local que agrega, organiza e prioriza alertas de segurança ou descobertas de vários serviços da AWS e produtos opcionais de terceiros para oferecer uma visão abrangente dos alertas de segurança e do status de conformidade. 

   Você também pode utilizar mecanismos de geração de alertas personalizados para alertas de segurança não cobertos por esses serviços ou para alertas específicos relevantes para o seu ambiente. Para ter informações sobre a criação desses alertas e detecções, consulte [Detecção no Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada](sec_detect_investigate_events_analyze_all.md) 
+  [SEC07-BP04 Definir o gerenciamento do ciclo de vida de dados](sec_data_classification_lifecycle_management.md) 
+  [SEC10-BP06 Pré-implantação de ferramentas](sec_incident_response_pre_deploy_tools.md) 

 **Documentos relacionados:** 
+ [ Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [ Conceitos básicos do Amazon Security Lake ](https://aws.amazon.com/security-lake/getting-started/)
+ [ Conceitos básicos: Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022: Introdução ao Amazon Security Lake ](https://www.youtube.com/watch?v=V7XwbPPjXSY)

 **Exemplos relacionados:** 
+ [ Assisted Log Enabler for AWS](https://github.com/awslabs/assisted-log-enabler-for-aws/)
+ [ Exportação histórica de descobertas do AWS Security Hub CSPM](https://github.com/aws-samples/aws-security-hub-findings-historical-export)

 **Ferramentas relacionadas:** 
+ [ Snowflake for Cybersecurity ](https://www.snowflake.com/en/data-cloud/workloads/cybersecurity/)

# SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada
<a name="sec_detect_investigate_events_analyze_all"></a>

 as equipes de operações de segurança confiam na coleta de logs e no uso de ferramentas de pesquisa para descobrir possíveis eventos de interesse, que podem indicar atividade não autorizada ou alteração não intencional. No entanto, a simples análise de dados coletados e o processamento manual de informações são insuficientes para acompanhar o volume de informações provenientes de arquiteturas complexas. Somente a análise e os relatórios não facilitam a atribuição dos recursos certos para trabalhar um evento em tempo hábil. 

Uma prática recomendada para montar uma equipe madura de operações de segurança é integrar profundamente o fluxo de eventos e descobertas de segurança em um sistema de notificação e fluxo de trabalho, como um sistema de emissão de tíquetes, um sistema de erros ou problemas, ou outro sistema de gerenciamento de informações e eventos de segurança (SIEM). Isso remove o fluxo de trabalho de e-mails e relatórios estáticos, o que permite rotear, escalar e gerenciar eventos ou descobertas. Muitas organizações também estão integrando alertas de segurança em suas plataformas de bate-papo ou colaboração e de produtividade do desenvolvedor. Para organizações que estão iniciando com automações, um sistema de emissão de tíquetes orientado por APIs e de baixa latência oferece flexibilidade considerável para o planejamento de o que automatizar primeiro.

Essa prática recomendada aplica-se não só a eventos de segurança gerados a partir de mensagens de log que representam atividades do usuário ou eventos de rede, como também a alterações detectadas na própria infraestrutura. A capacidade de detectar alterações, determinar se uma alteração foi apropriada e, em seguida, rotear essas informações para o fluxo de trabalho de correção correto é essencial para manter e validar uma arquitetura segura, no contexto de alterações em que a natureza de sua indesejabilidade é suficientemente sutil para que sua execução não possa ser impedida com uma combinação de configuração do AWS Identity and Access Management(IAM) e do AWS Organizations.

O Amazon GuardDuty e o AWS Security Hub CSPM fornecem mecanismos de agregação, desduplicação e análise para registros de log que também são disponibilizados a você por meio de outros serviços da AWS. O GuardDuty ingere, agrega e analisa informações de fontes como gerenciamento e eventos de dados do AWS CloudTrail, logs de DNS de VPC e logs de fluxo de VPC. O Security Hub CSPM pode ingerir, agregar e analisar a saída do GuardDuty AWS Config, do Amazon Inspector, Amazon Macie, do AWS Firewall Manager e de um número significativo de produtos de segurança de terceiros disponíveis no AWS Marketplace e, se criado adequadamente, no seu próprio código. Tanto o GuardDuty quanto o Security Hub CSPM têm um modelo de membro administrador que pode agregar descobertas e insights em várias contas. O Security Hub CSPM geralmente é usado por clientes que têm um SIEM on-premises como um log do lado da AWS e um pré-processador e agregador de logs e alertas nos quais eles podem consumir o Amazon EventBridge por meio de um processador e encaminhador com base no AWS Lambda.

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Avaliar os recursos de processamento de log: avalie as opções disponíveis para o processamento de logs. 
  +  [Use Amazon OpenSearch Service to log and monitor (almost) everything (Usar o Amazon OpenSearch Service para registrar e monitorar (quase) tudo) ](https://d1.awsstatic.com/whitepapers/whitepaper-use-amazon-elasticsearch-to-log-and-monitor-almost-everything.pdf)
  +  [Encontre um parceiro especializado em soluções de registro e monitoramento ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring)
+  Para começar a analisar logs do CloudTrail, experimente o Amazon Athena. 
  + [ Como configurar o Athena para analisar logs do CloudTrail ](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html)
+  Implementar o login centralizado na AWS: consulte a solução de exemplo da AWS a seguir para centralizar o log de várias fontes. 
  +  [Centralizar a solução de registro em log ](https://aws.amazon.com/solutions/centralized-logging/https://aws.amazon.com/solutions/centralized-logging/)
+  Implementar o registro em log centralizado com o parceiro: os parceiros da APN têm soluções para ajudar você a analisar os logs de forma centralizada. 
  + [ Registro em log e monitoramento ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Answers: registro em log centralizado ](https://aws.amazon.com/answers/logging/centralized-logging/)
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+ [ Conceitos básicos: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Vídeos relacionados:** 
+ [ Centrally Monitoring Resource Configuration and Compliance (Monitoramento centralizado de configuração e conformidade de recursos) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correção do Amazon GuardDuty e descobertas do AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gerenciamento de ameaças na nuvem: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

# SEC04-BP03 Automatizar a resposta a eventos
<a name="sec_detect_investigate_events_auto_response"></a>

 O uso de automação para investigar e corrigir eventos reduz o esforço humano e erros e permite escalar recursos de investigação. Análises regulares ajudarão você a ajustar ferramentas de automação e iterar continuamente. 

Na AWS, a investigação de eventos de interesse e informações sobre alterações potencialmente inesperadas em um fluxo de trabalho automatizado pode ser obtida com o Amazon EventBridge. Esse serviço fornece um mecanismo de regras escalável, projetado para processar formatos de eventos da AWS nativos (como eventos do AWS CloudTrail) e personalizados, que você pode gerar com base em sua aplicação. O Amazon GuardDuty também permite rotear eventos em um sistema de fluxo de trabalho para usuários que criam sistemas de resposta a incidentes (AWS Step Functions), uma conta de segurança central ou um bucket para análise posterior.

A detecção de alterações e o roteamento dessas informações para o fluxo de trabalho correto podem ser realizados com o uso do Regras do AWS Config e [de pacotes de conformidade](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html). O AWS Config detecta alterações nos serviços em escopo (embora com maior latência do que o EventBridge) e gera eventos que podem ser analisados usando o Regras do AWS Config para reversão, aplicação da política de conformidade e encaminhamento de informações aos sistemas, como plataformas de gerenciamento de alterações e sistemas operacionais de emissão de tíquetes. Além de escrever suas próprias funções do Lambda para responder a eventos do AWS Config, você também pode aproveitar o [kit de desenvolvimento do Regras do AWS Config](https://github.com/awslabs/aws-config-rdk)e uma [biblioteca de código aberto](https://github.com/awslabs/aws-config-rules) do Regras do AWS Config. Os pacotes de conformidade são uma coleção de ações de correção e do Regras do AWS Config que você implanta como uma única entidade criada como um modelo YAML. O [modelo de pacote de conformidade de amostra](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) está disponível no pilar Segurança do Well-Architected.

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Implementar alertas automatizados com o GuardDuty: o GuardDuty é um serviço de detecção de ameaças que monitora continuamente atividades mal-intencionadas e comportamentos não autorizados para proteger suas workloads e Contas da AWS. Habilite o GuardDuty e configure alertas automatizados. 
+  Automatizar o processo de investigação: desenvolva processos automatizados que investigam um evento e relatam informações a um administrador para economizar tempo. 
  + [ Laboratório: Amazon GuardDuty na prática ](https://hands-on-guardduty.awssecworkshops.com/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Answers: registro em log centralizado ](https://aws.amazon.com/answers/logging/centralized-logging/)
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+ [ Conceitos básicos: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 
+ [ Como configurar o Amazon GuardDuty ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)

 **Vídeos relacionados:** 
+ [ Centrally Monitoring Resource Configuration and Compliance (Monitoramento centralizado de configuração e conformidade de recursos) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correção do Amazon GuardDuty e descobertas do AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gerenciamento de ameaças na nuvem: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada de controles de detecção ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html)

# SEC04-BP04 Implementar eventos de segurança acionáveis
<a name="sec_detect_investigate_events_actionable_events"></a>

 Crie alertas para serem enviados à sua equipe para ação. Certifique-se de que os alertas incluam informações relevantes para a equipe agir. Para cada mecanismo de detecção existente, você também deve ter um processo, na forma de um [runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) ou [playbook](https://wa.aws.amazon.com/wat.concept.playbook.en.html), para investigar. Por exemplo, quando você habilita o [Amazon GuardDuty](http://aws.amazon.com/guardduty), ele gera diferentes [descobertas](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html). Você deve ter uma entrada de runbook para cada tipo de descoberta, por exemplo, se um [cavalo de Troia](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_trojan.html) for descoberto, seu runbook terá instruções simples que instruem alguém a investigar e corrigir o problema. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Descubra as métricas disponíveis para serviços da AWS: descubra as métricas disponíveis por meio do Amazon CloudWatch para os serviços que você está usando. 
  +  [Documentação do serviço da AWS](https://aws.amazon.com/documentation/) 
  +  [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  Configure os alarmes do Amazon CloudWatch. 
  +  [Como usar os alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Vídeos relacionados:** 
+ [ Centrally Monitoring Resource Configuration and Compliance (Monitoramento centralizado de configuração e conformidade de recursos) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correção do Amazon GuardDuty e descobertas do AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gerenciamento de ameaças na nuvem: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

# Proteção de infraestrutura
<a name="a-infrastructure-protection"></a>

**Topics**
+ [SEGURANÇA 5. Como proteger seus recursos de rede?](sec-05.md)
+ [SEGURANÇA 6. Como proteger seus recursos de computação?](sec-06.md)

# SEGURANÇA 5. Como proteger seus recursos de rede?
<a name="sec-05"></a>

Qualquer carga de trabalho que tenha alguma forma de conectividade de rede, seja a Internet ou uma rede privada, exige várias camadas de defesa para ajudar a proteger contra ameaças externas e internas baseadas em rede.

**Topics**
+ [SEC05-BP01 Criar camadas de rede](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Controlar tráfego de todas as camadas](sec_network_protection_layered.md)
+ [SEC05-BP03 Automatizar a proteção da rede:](sec_network_protection_auto_protect.md)
+ [SEC05-BP04 Implementar inspeção e proteção](sec_network_protection_inspection.md)

# SEC05-BP01 Criar camadas de rede
<a name="sec_network_protection_create_layers"></a>

Agrupe os componentes que compartilham requisitos de confidencialidade em camadas para minimizar o possível escopo do impacto do acesso não autorizado. Por exemplo, um cluster de banco de dados em uma nuvem privada virtual (VPC) sem necessidade de acesso à Internet deve ser colocado em sub-redes sem nenhuma rota para/ou proveniente da Internet. O tráfego só deve fluir do próximo recurso menos sigiloso adjacente. Considere uma aplicação da web atrás de um balanceador de carga. Seu banco de dados não deve ser acessível diretamente do balanceador de carga. Somente a lógica de negócios ou o servidor da web tem acesso direto ao seu banco de dados. 

 **Resultado desejado:** criar uma rede em camadas. Redes em camadas ajudam a agrupar logicamente componentes de rede semelhantes. Elas também reduzem o possível escopo de impacto do acesso não autorizado à rede. Uma rede configurada adequadamente em camadas dificulta que usuários não autorizados adaptem recursos adicionais em seu ambiente da AWS. Além de garantir caminhos de rede internos, você também deve proteger sua borda de rede, como aplicações da web e endpoints de API. 

 **Antipadrões comuns:** 
+  Criar todos os recursos em uma única VPC ou sub-rede. 
+  Utilizar grupos de segurança excessivamente permissivos. 
+  Não utilizar sub-redes. 
+  Permitir o acesso direto aos armazenamentos de dados, como bancos de dados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os componentes como instâncias do Amazon Elastic Compute Cloud (Amazon EC2), clusters de banco de dados do Amazon Relational Database Service (Amazon RDS) e funções do AWS Lambda que compartilham requisitos de acessibilidade podem ser segmentados em camadas formadas por sub-redes. Considere implantar workloads sem servidor, como funções do [Lambda](https://docs.aws.amazon.com/lambda/index.html), em uma VPC ou atrás de um [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html). As tarefas do [AWS Fargate](https://aws.amazon.com/fargate/getting-started/) que não têm necessidade de acesso à Internet devem ser colocadas em sub-redes sem rota para ou proveniente da Internet. Essa abordagem em camadas reduz o impacto da configuração incorreta de uma única camada, o que pode permitir o acesso não intencional. Para o AWS Lambda, você pode executar as funções em sua VPC para utilizar os controles baseados em VPC. 

 Para a conectividade de rede que pode incluir milhares de VPCs, Contas da AWS e redes on-premises, você deve utilizar o [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). O Transit Gateway age como um hub que controla como o tráfego é roteado entre todas as redes conectadas, que agem como raios. O tráfego entre o Amazon Virtual Private Cloud (Amazon VPC) e o Transit Gateway permanece na rede privada da AWS, o que reduz a exposição externa a usuários não autorizados e possíveis problemas de segurança. O emparelhamento entre regiões do Transit Gateway também criptografa o tráfego entre regiões sem nenhum ponto único de falha ou gargalo de largura de banda. 

 **Etapas da implementação** 
+  **Utilize o [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html) para analisar o caminho entre uma origem e um destino com base na configuração:** o Reachability Analyzer permite a você automatizar a verificação da conectividade para e proveniente de recursos conectados à VPC. Observe que essa análise é realizada analisando a configuração (nenhum pacote de rede é enviado na realização da análise). 
+  **Utilize o [Analisador de Acesso à Rede Amazon VPC](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) para identificar o acesso acidental à rede aos recursos:** o Analisador de Acesso à Rede Amazon VPC possibilita especificar seus requisitos de acesso à rede identificar possíveis caminhos de rede. 
+  **Considere se os recursos precisam estar em uma sub-rede pública:** não coloque os recursos em sub-redes públicas de sua VPC a menos que eles devam receber tráfego de rede de entrada de origens públicas. 
+  **Crie [sub-redes em suas VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html):** crie sub-redes para cada camada de rede (em grupos que incluam várias zonas de disponibilidade) para melhorar a microssegmentação. Verifique também se você associou as [tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) corretas com suas sub-redes para controlar o roteamento e a conectividade de rede. 
+  **Utilize o [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/security-group-policies.html) para gerenciar seus grupos de segurança de VPC:** o AWS Firewall Manager ajuda a reduzir o trabalho de usar vários grupos de segurança. 
+  **Utilize o [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) para proteger contra vulnerabilidades comuns da web:** o AWS WAF pode ajudar a melhorar a segurança de borda inspecionando o tráfego quanto a vulnerabilidades comuns da web, como injeção de SQL. Ele também permite restringir o tráfego de endereços IP originários de determinados países ou locais geográficos. 
+  **Utilize o [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) como uma rede de distribuição de conteúdo (CDN):** o Amazon CloudFront pode ajudar a acelerar sua aplicação da web armazenando dados mais perto de seus usuários. Ele também pode melhorar a segurança de borda aplicando HTTPS, restringindo o acesso a áreas geográficas e garantindo que o tráfego de rede possa acessar somente recursos roteados por meio do CloudFront. 
+  **Utilize o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) ao criar interfaces de programação de aplicações (APIs):** o Amazon API Gateway ajuda a publicar, monitorar e proteger APIs REST, HTTPS e de WebSocket. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) 
+ [ Amazon Inspector ](https://aws.amazon.com/inspector)
+  [Segurança na Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) 
+ [ Reachability Analyzer ](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [ Analisador de Acesso à Rede Amazon VPC ](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/getting-started.html#run-analysis)

 **Vídeos relacionados:** 
+  [Arquiteturas de referência do AWS Transit Gateway para várias VPCs ](https://youtu.be/9Nikqn_02Oc)
+  [Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield](https://youtu.be/0xlwLEccRe0) 
+ [AWS re:Inforce 2022: Validar controles de acesso à rede eficazes na AWS](https://www.youtube.com/watch?v=aN2P2zeQek0)
+ [AWS re:Inforce 2022: Proteções avançadas contra bots usando o AWS WAF](https://www.youtube.com/watch?v=pZ2eftlwZns)

 **Exemplos relacionados:** 
+  [Well-Architected Lab: Implantação automatizada de VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 
+ [ Workshop: Analisador de Acesso à Rede Amazon VPC ](https://catalog.us-east-1.prod.workshops.aws/workshops/cf2ecaa4-e4be-4f40-b93f-e9fe3b1c1f64)

# SEC05-BP02 Controlar tráfego de todas as camadas
<a name="sec_network_protection_layered"></a>

  ao projetar sua topologia de rede, você deve examinar os requisitos de conectividade de cada componente. Por exemplo, se um componente precisa de acesso à Internet (entrada e saída), conectividade com VPCs, serviços de borda e datacenters externos. 

 Uma VPC permite que você defina a topologia de rede que abrange uma Região da AWS com um intervalo de endereços IPv4 privados que você define ou um intervalo de endereços IPv6 que a AWS seleciona. Você deve aplicar vários controles com uma abordagem detalhada de defesa para tráfego de entrada e saída, incluindo o uso de grupos de segurança (firewall de inspeção com estado), Network ACLs, sub-redes e tabelas de rotas. Você pode criar sub-redes em uma zona de disponibilidade dentro de uma VPC. Cada sub-rede tem uma tabela de rotas associada que define regras de roteamento para gerenciar os caminhos do tráfego dentro da sub-rede. Você pode definir uma sub-rede roteável na Internet com uma rota que siga até um gateway da Internet ou gateway NAT associado à VPC ou que passe por outra VPC. 

 Quando uma instância, um banco de dados do Amazon Relational Database Service(Amazon RDS) ou outro serviço é executado em uma VPC, ela tem seu próprio grupo de segurança por interface de rede. Esse firewall está fora da camada do sistema operacional e pode ser usado para definir regras para o tráfego permitido de entrada e saída. Você também pode definir relacionamentos entre grupos de segurança. Por exemplo, as instâncias em um grupo de segurança no nível do banco de dados aceitam somente o tráfego de instâncias no nível do aplicativo, por referência aos grupos de segurança aplicados às instâncias envolvidas. A menos que você esteja usando protocolos não baseados em TCP, não deve ser necessário ter uma instância do Amazon Elastic Compute Cloud(Amazon EC2) diretamente acessível pela Internet (mesmo com portas restritas por grupos de segurança) sem um balanceador de carga ou o [CloudFront](https://aws.amazon.com/cloudfront). Isso ajuda a protegê-lo contra acesso não intencional surgido por um problema de sistema operacional ou aplicativo. Uma sub-rede também pode ter uma Network ACL anexada a ela, que atua como um firewall sem estado. Você deve configurar a Network ACL para restringir a abrangência do tráfego permitido entre camadas. Observe que é preciso definir regras de entrada e de saída. 

 Alguns serviços da AWS requerem componentes para acessar a Internet para fazer chamadas de API, onde [os endpoints de API da AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) estão localizados. Outros serviços da AWS usam [VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html) dentro das suas Amazon VPCs. Muitos serviços da AWS, incluindo o Amazon S3 e o Amazon DynamoDB, oferecem suporte a endpoints da VPC, e essa tecnologia foi generalizada no [AWS PrivateLink](https://aws.amazon.com/privatelink/). Recomendamos o uso dessa abordagem para acessar serviços da AWS, serviços de terceiros e seus próprios serviços hospedados em outras VPCs com segurança. Todo o tráfego de rede do AWS PrivateLink permanece no backbone global da AWS e nunca atravessa a Internet. A conectividade só pode ser iniciada pelo consumidor do serviço e não pelo provedor do serviço. O uso do AWS PrivateLink para acesso a serviços externos permite criar VPCs air-gapped sem acesso à Internet e ajuda a proteger suas VPCs de vetores de ameaças externas. Os serviços de terceiros podem usar o AWS PrivateLink para permitir que os clientes se conectem aos serviços de suas VPCs por meio de endereços IP privados. Para ativos da VPC que precisam estabelecer conexões de saída com a Internet, elas podem ser feitas somente de saída (unidirecional) por meio de um gateway NAT gerenciado pela AWS, de um gateway da Internet somente de saída ou de proxies de Web criados e gerenciados por você. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Controlar o tráfego de rede em uma VPC: implemente as práticas recomendadas de VPC para controlar o tráfego. 
  +  [Segurança da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) 
  +  [VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
  +  [Grupo de segurança da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 
  +  [ACLs de rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 
+  Controlar o tráfego na borda: implemente serviços de borda, como o Amazon CloudFront, para fornecer uma camada adicional de proteção e outros recursos. 
  +  [Casos de uso do Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/IntroductionUseCases.html) 
  +  [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
  +  [AWS Web Application Firewall (AWS WAF)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-section.html) 
  +  [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  [Roteamento de entrada da Amazon VPC](https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-vpc-ingress-routing-insert-virtual-appliances-forwarding-path-vpc-traffic/) 
+  Controlar o tráfego de rede privada: implemente serviços que protegem o tráfego privado da sua workload. 
  +  [Emparelhamento de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 
  +  [Serviços de endpoint da Amazon VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 
  +  [Amazon VPC Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
  +  [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 
  +  [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 
  +  [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/user-getting-started.html) 
  +  [Pontos de acesso do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-points.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+  [Conceitos básicos do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Vídeos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs (Arquiteturas de referência do AWS Transit Gateway para várias VPCs)](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield) ](https://youtu.be/0xlwLEccRe0)

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada da VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC05-BP03 Automatizar a proteção da rede:
<a name="sec_network_protection_auto_protect"></a>

 Automatize os mecanismos de proteção para fornecer uma rede de autodefesa com base em inteligência de ameaças e detecção de anomalias. Por exemplo, ferramentas de detecção e prevenção de intrusão que podem se adaptar às ameaças atuais e reduzir seu impacto. Um firewall de aplicação Web é um exemplo de onde você pode automatizar a proteção de rede; por exemplo, usando a solução AWS WAF Security Automations ([https://github.com/awslabs/aws-waf-security-automations](https://github.com/awslabs/aws-waf-security-automations)) para bloquear automaticamente solicitações originadas de endereços IP associados a agentes de ameaças conhecidos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Automatize a proteção para tráfego baseado na Web: a AWS oferece uma solução que usa o AWS CloudFormation para implantar automaticamente um conjunto de regras do AWS WAF projetadas para filtrar ataques comuns baseados na Web. Os usuários podem selecionar entre recursos de proteção pré-configurados que definem as regras incluídas em uma lista de controle de acesso da Web (ACL da Web) do AWS WAF. 
  +  [Automações de segurança do AWS WAF](https://aws.amazon.com/solutions/aws-waf-security-automations/) 
+  Considere as soluções de AWS Partner: os parceiros da AWS oferecem centenas de produtos líderes do setor que são equivalentes, idênticos ou se integram aos controles existentes nos seus ambientes on-premises. Esses produtos complementam os serviços da AWS já existentes para que os clientes possam implantar uma arquitetura de segurança abrangente e obter uma experiência mais uniforme na nuvem e no ambiente on-premises. 
  +  [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+ [Segurança da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html)
+  [Conceitos básicos do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Vídeos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs (Arquiteturas de referência do AWS Transit Gateway para várias VPCs)](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield) ](https://youtu.be/0xlwLEccRe0)

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada da VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC05-BP04 Implementar inspeção e proteção
<a name="sec_network_protection_inspection"></a>

 Inspecione e filtre o tráfego em cada camada. É possível inspecionar suas configurações de VPC quanto a possíveis acessos não intencionais usando o [VPC Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html). Especifique seus requisitos de acesso à rede e identifique possíveis caminhos de rede que não os atendem. Para componentes que fazem transações por meio de protocolos baseados em HTTP, um firewall de aplicativo Web pode ajudar a proteger contra ataques comuns. [AWS WAF](https://aws.amazon.com/waf) é um firewall para aplicativos web que permite monitorar e bloquear solicitações HTTP(s) que correspondem às regras configuráveis que são encaminhadas para uma API do Amazon API Gateway, o Amazon CloudFront ou um Application Load Balancer. Para começar a usar o AWS WAF, você pode usar o [AWS Managed Rules](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) em combinação com as suas próprias ou usar [integrações de parceiros existentes](https://aws.amazon.com/waf/partners/). 

 Para gerenciar o AWS WAF, proteções do AWS Shield Advanced e grupos de segurança do Amazon VPC no AWS Organizations, você pode usar o AWS Firewall Manager. Ele permite configurar e gerenciar centralmente regras de firewall entre contas e aplicativos, simplificando a imposição de regras comuns em escala. Ele também permite que você responda rapidamente a ataques, usando o [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-responding.html)ou [soluções](https://aws.amazon.com/solutions/aws-waf-security-automations/) capazes de bloquear automaticamente solicitações indesejadas para suas aplicações Web. O Firewall Manager também funciona com o [AWS Network Firewall](https://aws.amazon.com/network-firewall/). O AWS Network Firewall é um serviço gerenciado que usa um mecanismo de regras para fornecer controle refinado sobre o tráfego de rede com e sem estado. Ele oferece suporte às especificações do sistema de prevenção de intrusões (IPS) de código aberto [compatível com Suricata ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) para regras para ajudar a proteger sua workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Configure o Amazon GuardDuty: o GuardDuty é um serviço de detecção de ameaças que monitora continuamente atividades mal-intencionadas e comportamentos não autorizados para proteger suas workloads e Contas da AWS. Habilite o GuardDuty e configure alertas automatizados. 
  +  [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) 
  +  [Laboratório: Implantação automatizada de controles de detecção](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html) 
+  Configure os logs de fluxo da nuvem privada virtual (VPC): os logs de fluxo da VPC é um recurso que permite capturar informações sobre o tráfego de IP direcionado e proveniente de interfaces de rede na sua VPC. Os dados de log de fluxo podem ser publicados no Amazon CloudWatch Logs e no Amazon Simple Storage Service (Amazon S3). Depois de criar um log de fluxo, você pode recuperar e visualizar seus dados no destino escolhido. 
+  Considere o espelhamento de tráfego da VPC: o espelhamento de tráfego é um recurso da Amazon VPC que pode ser usado para copiar o tráfego de rede de uma interface de rede elástica de instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e enviá-lo para dispositivos de segurança e monitoramento fora de banda para inspeção de conteúdo, monitoramento de ameaças e solução de problemas. 
  +  [Espelhamento de tráfego de VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+  [Segurança da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) 
+  [Conceitos básicos do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Vídeos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs (Arquiteturas de referência do AWS Transit Gateway para várias VPCs)](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield)](https://youtu.be/0xlwLEccRe0) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada da VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEGURANÇA 6. Como proteger seus recursos de computação?
<a name="sec-06"></a>

Os recursos de computação exigem várias camadas de defesa para ajudar na proteção contra ameaças externas e internas. Recursos de computação incluem instâncias do EC2, contêineres, funções do AWS Lambda, serviços de banco de dados, dispositivos de IoT e muito mais.

**Topics**
+ [SEC06-BP01 Fazer o gerenciamento de vulnerabilidades](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Reduzir a superfície de ataque](sec_protect_compute_reduce_surface.md)
+ [SEC06-BP03 Implementar serviços gerenciados](sec_protect_compute_implement_managed_services.md)
+ [SEC06-BP04 Automatizar a proteção da computação](sec_protect_compute_auto_protection.md)
+ [SEC06-BP05 Permitir que as pessoas executem ações a uma distância](sec_protect_compute_actions_distance.md)
+ [SEC06-BP06 Validar a integridade do software](sec_protect_compute_validate_software_integrity.md)

# SEC06-BP01 Fazer o gerenciamento de vulnerabilidades
<a name="sec_protect_compute_vulnerability_management"></a>

Verifique e corrija com frequência vulnerabilidades no código, nas dependências e na infraestrutura para proteger-se contra novas ameaças.

 **Resultado desejado:** criar e manter um programa de gerenciamento de vulnerabilidade. Verificar regularmente e corrigir recursos, como instâncias do Amazon EC2, contêineres do Amazon Elastic Container Service (Amazon ECS) e workloads do Amazon Elastic Kubernetes Service (Amazon EKS). Configurar janelas de manutenção para recursos gerenciados da AWS, como bancos de dados Amazon Relational Database Service (Amazon RDS). Utilizar a verificação de código estático para inspecionar a existência de problemas comuns no código-fonte da aplicação. Considerar testes de penetração de aplicações da web se sua organização tiver as habilidades obrigatórias ou puder contratar assistência externa. 

 **Antipadrões comuns:** 
+  Não ter um programa de gerenciamento de vulnerabilidades. 
+  Realizar aplicação de patches do sistema sem considerar a gravidade ou como evitar riscos. 
+  Utilizar software que ultrapassou a data de fim de vida útil (EOL) indicada pelo fornecedor. 
+  Implantar código em produção antes de analisar a existência de problemas de segurança. 

 **Benefícios do estabelecimento desta prática recomendada:** 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Um programa de gerenciamento de vulnerabilidades inclui avaliação de segurança, identificação de problemas, priorização e realização de operações de patch como parte da solução dos problemas. A automação é a chave para verificar de forma contínua as workloads quanto a problemas e exposição acidental à rede e realização de remediação. Automatizar a criação e atualizar os recursos economiza tempo e reduz o risco de erros de configuração que criam mais problemas. Um programa de gerenciamento de vulnerabilidades bem projetado também deve considerar testes de vulnerabilidades durante o desenvolvimento e os estágios de implantação do ciclo de vida do software. Implementar o gerenciamento de vulnerabilidades durante o desenvolvimento e a implantação ajuda a reduzir a chance de uma vulnerabilidade atingir seu ambiente de produção. 

 Implementar um programa de gerenciamento de vulnerabilidades exige um bom entendimento do [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) e como ele se relaciona com suas workloads específicas. Segundo o modelo de responsabilidade compartilhada, a AWS é responsável por proteger a infraestrutura da Nuvem AWS. Essa infraestrutura abrange o hardware, o software, as redes e as instalações que executam os serviços da Nuvem AWS. Você é responsável pela segurança na nuvem, por exemplo, os dados reais, a configuração de segurança e as tarefas de gerenciamento de instâncias do Amazon EC2 e por garantir que seus objetos do Amazon S3 sejam classificados e configurados corretamente. Sua abordagem ao gerenciamento de vulnerabilidades também pode variar dependendo dos serviços consumidos. Por exemplo, a AWS gerencia a aplicação de patches para nosso serviço de banco de dados relacional gerenciado, o Amazon RDS, mas você seria responsável pela colocação de patches em bancos de dados auto-hospedados. 

 A AWS tem uma série de serviços para ajudar com seu programa de gerenciamento de vulnerabilidades. O [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) verifica de forma contínua as workloads da AWS quanto a problemas de software e acesso acidental à rede. [O AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) ajuda a gerenciar a aplicação de patches em suas instâncias do Amazon EC2. O Amazon Inspector e o Systems Manager podem ser visualizados no [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html), um serviço de gerenciamento de procedimentos de segurança na nuvem que ajuda a automatizar verificações de segurança da AWS e centralizar alertas de segurança. 

 O [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) pode ajudar a identificar possíveis problemas em aplicações Java e Python utilizando análise de código estático. 

 **Etapas da implementação** 
+  **Configurar o [Amazon Inspector](https://docs.aws.amazon.com/inspector/v1/userguide/inspector_introduction.html):** o Amazon Inspector detecta automaticamente instâncias do Amazon EC2 recém-executadas, funções do Lambda e imagens de contêiner elegíveis enviadas ao Amazon ECR e as verifica imediatamente quanto a problemas de software, possíveis defeitos e exposição acidental à rede. 
+  **Verificar o código-fonte:** verifique as bibliotecas e as dependências quanto a problemas e defeitos. O [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) pode verificar e fornecer recomendações para corrigir [problemas de segurança comuns](https://docs.aws.amazon.com/codeguru/detector-library/index.html) para aplicações Java e Python. [A OWASP Foundation](https://owasp.org/www-community/Source_Code_Analysis_Tools) publica uma lista de ferramentas de análise de código-fonte (também conhecidas como ferramentas SAST). 
+  **Implementar um mecanismo para verificar e aplicar patches ao seu ambiente existente, bem como verificação como parte de um processo de construção de pipeline de CI/CD:** implemente um mecanismo para verificar e aplicar patches quanto a problemas em suas dependências e sistemas operacionais a fim de ajudar a proteger-se contra novas ameaças. Execute esse mecanismo regularmente. O gerenciamento de vulnerabilidade de software é essencial ao entendimento de onde é necessário aplicar patches ou resolver problemas de software. Priorize a remediação de possíveis problemas de segurança incorporando avaliações de vulnerabilidade no início de seu pipeline de integração/entrega contínua (CI/CD). Sua abordagem pode variar com base nos serviços da AWS que você está consumindo. Para conferir a existência de possíveis problemas no software em execução em instâncias do Amazon EC2, adicione o [Amazon Inspector](https://aws.amazon.com/inspector/) ao seu pipeline para alertar e interromper o processo de compilação se forem detectados problemas ou possíveis defeitos. O Amazon Inspector monitora recursos de forma contínua. Você também pode utilizar produtos de código aberto, como [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), [Snyk](https://snyk.io/product/open-source-security-management/), [OpenVAS](https://www.openvas.org/), gerenciadores de pacotes e ferramentas de AWS Partner para gerenciamento de vulnerabilidades. 
+  **Utilize o [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html):** você é responsável pelo gerenciamento de patches para seus recursos do AWS, incluindo instâncias do Amazon Elastic Compute Cloud (Amazon EC2), imagens de máquina da Amazon (AMIs) e outros recursos de computação. O [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) automatiza o processo de aplicação de patches em instâncias gerenciadas com atualizações relacionadas à segurança e outros tipos de atualizações. O Patch Manager pode ser utilizado para aplicar patches em instâncias do Amazon EC2 para sistemas operacionais e aplicações, como aplicações da Microsoft, pacotes de serviços Windows e atualizações de versão secundária para instâncias baseadas em Linux. Além do Amazon EC2, o Patch Manager também pode ser utilizado para aplicar patches em servidores on-premises. 

   Para ter uma lista de sistemas operacionais compatíveis, consulte [Sistemas operacionais compatíveis](https://docs.aws.amazon.com/systems-manager/latest/userguide/prereqs-operating-systems.html) no Guia do usuário do Systems Manager. Você pode verificar instâncias para ver apenas um relatório de patches ausentes ou verificar e instalar automaticamente todos os patches ausentes. 
+  **Utilize do [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html):** o Security Hub CSPM oferece uma visão abrangente do estado de seu sistema na AWS. Ele coleta dados de segurança em [vários serviços da AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html) e oferece essas descobertas em um formato personalizado, possibilitando priorizar as descobertas de segurança em serviços da AWS. 
+  **Utilize o [AWS CloudFormation](https://aws.amazon.com/cloudformation/):** o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) é um serviço de infraestrutura como código (IaC) que pode ajudar com o gerenciamento de vulnerabilidades automatizando a implantação de recursos e padronizando a arquitetura de recursos em várias contas e ambientes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Visão geral de segurança do AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS--Security.pdf) 
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Gerenciamento aprimorado e automatizado de vulnerabilidades para workloads de nuvem com um novo Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automatizar o gerenciamento e a remediação de vulnerabilidades na AWS usando o Amazon Inspector e o AWS Systems Manager: Parte 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)

 **Vídeos relacionados:** 
+  [Proteção de serviços com tecnologia sem servidor e de contêiner](https://youtu.be/kmSdyN9qiXY) 
+  [Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2](https://youtu.be/2B5bhZzayjI) 

# SEC06-BP02 Reduzir a superfície de ataque
<a name="sec_protect_compute_reduce_surface"></a>

 Reduza a exposição ao acesso não intencional protegendo os sistemas operacionais e minimizando componentes, bibliotecas e serviços consumíveis externamente em uso. Primeiro, diminua o número de componentes não utilizados, sejam eles pacotes de sistema operacional ou aplicações para workloads baseadas no Amazon Elastic Compute Cloud (Amazon EC2), sejam eles módulos de software externos no código, para todas as workloads. Encontre muitos guias de configuração de proteção e segurança para sistemas operacionais comuns e software de servidor. Por exemplo, você pode começar com o [Center for Internet Security](https://www.cisecurity.org/) e iterar.

 No Amazon EC2, e possível criar as próprias imagens de máquina da Amazon (AMIs), corrigidas e reforçadas, para ajudar você a atender aos requisitos de segurança específicos da sua organização. Os patches e outros controles de segurança aplicados na AMI são efetivos no momento em que foram criados. Eles não são dinâmicos, a menos que você modifique após a inicialização, por exemplo, com o AWS Systems Manager. 

 É possível simplificar o processo de criação de AMIs seguras com o EC2 Image Builder. O EC2 Image Builder reduz significativamente o esforço necessário para criar e manter imagens douradas sem escrever e manter a automação. Quando as atualizações de software ficam disponíveis, o Image Builder produz automaticamente uma nova imagem sem exigir que os usuários iniciem manualmente as compilações de imagem. O EC2 Image Builder permite validar facilmente a funcionalidade e a segurança de suas imagens antes de usá-las na produção com testes fornecidos pela AWS e seus próprios testes. Também é possível aplicar as configurações de segurança fornecidas pela AWS para proteger ainda mais suas imagens para atender aos critérios de segurança internos. Por exemplo, você pode produzir imagens em conformidade com o padrão do Guia de implementação técnica de segurança (STIG) usando modelos fornecidos pela AWS. 

 Com ferramentas de análise de código estático de terceiros é possível identificar problemas de segurança comuns, como limites de entrada de função não verificados, bem como vulnerabilidades e exposições comuns (CVEs) aplicáveis. Você pode usar o [Amazon CodeGuru](https://aws.amazon.com/codeguru/) para os idiomas compatíveis. As ferramentas de verificação de dependência também podem ser usadas para determinar se as bibliotecas com as quais o código está vinculado são as versões mais recentes, estão livres de CVEs e têm condições de licenciamento que atendem aos requisitos da política de software. 

 Usando o Amazon Inspector, você pode executar avaliações de configuração de CVEs conhecidas em suas instâncias, avaliar parâmetros de segurança e automatizar a notificação de defeitos. O Amazon Inspector é executado em instâncias de produção ou em um pipeline de compilação e notifica desenvolvedores e engenheiros quando descobertas estão presentes. Você pode acessar as descobertas programaticamente e direcionar sua equipe para os registros em atraso e os sistemas de rastreamento de bugs. [EC2 Image Builder](https://aws.amazon.com/image-builder/) pode ser usado para manter imagens de servidor (AMIs) com aplicação automática de patches, aplicação de políticas de segurança fornecidas pela AWS e outras personalizações. Ao usar contêineres, implemente a [Verificação de imagens do ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) no pipeline de compilação e regularmente no repositório de imagens para procurar CVEs nos contêineres. 

 Embora o Amazon Inspector e outras ferramentas sejam eficazes na identificação de configurações e CVEs presentes, outros métodos são necessários para testar a carga de trabalho no nível do aplicativo. [Fuzzing](https://owasp.org/www-community/Fuzzing) é um método conhecido de encontrar erros usando automação para injetar dados malformados em campos de entrada e outras áreas do aplicativo. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Configure os sistemas operacionais: configure os sistemas operacionais para atender às práticas recomendadas. 
  +  [Securing Amazon Linux](https://www.cisecurity.org/benchmark/amazon_linux/) 
  +  [Securing Microsoft Windows Server](https://www.cisecurity.org/benchmark/microsoft_windows_server/) 
+  Configure recursos em contêiner para atender às práticas recomendadas de segurança. 
+  Implemente as práticas recomendadas do AWS Lambda. 
  +  [Práticas recomendadas do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um host traga a sua própria licença pelo Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada do firewall de aplicações Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP03 Implementar serviços gerenciados
<a name="sec_protect_compute_implement_managed_services"></a>

 Implemente serviços que gerenciam recursos, como o Amazon Relational Database Service (Amazon RDS), o AWS Lambda e o Amazon Elastic Container Service (Amazon ECS), para reduzir as tarefas de manutenção de segurança como parte do modelo de responsabilidade compartilhada. Por exemplo, o Amazon RDS ajuda você a configurar, operar e escalar um banco de dados relacional, automatiza tarefas de administração, como provisionamento de hardware, configuração de banco de dados, aplicação de patches e backups. Isso significa que você tem mais tempo livre para se concentrar na proteção da aplicação de outras maneiras descritas no AWS Well-Architected Framework. O Lambda permite executar código sem provisionar nem gerenciar servidores e, portanto, você só precisa se concentrar na conectividade, na invocação e na segurança em nível de código, e não na infraestrutura ou no sistema operacional. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Explorar os serviços disponíveis: explore, teste e implemente serviços que gerenciam recursos, como Amazon RDS, AWS Lambda e Amazon ECS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Site da AWS](https://aws.amazon.com/)
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um bastion host com o Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2)](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+ [Laboratório: AWS Certificate Manager Request Public Certificate ](https://wellarchitectedlabs.com/security/200_labs/200_certificate_manager_request_public_certificate/)

# SEC06-BP04 Automatizar a proteção da computação
<a name="sec_protect_compute_auto_protection"></a>

 Automatize seus mecanismos de computação de proteção, incluindo gerenciamento de vulnerabilidades, redução da superfície de ataque e gerenciamento de recursos. A automação ajudará você a investir tempo para proteger outros aspectos da carga de trabalho e reduzir o risco de erros humanos. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatizar o gerenciamento de configuração: aplique e valide configurações seguras automaticamente usando uma ferramenta ou um serviço de gerenciamento de configuração. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [Laboratório: Implantação automatizada da VPC](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 
  +  [Laboratório: Implantação automatizada da aplicação Web no EC2](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 
+  Automatizar a aplicação de patches para instâncias do Amazon Elastic Compute Cloud(Amazon EC2): o Patch Manager do AWS Systems Manager automatiza o processo de aplicação de patches em instâncias gerenciadas com atualizações relacionadas à segurança e com outros tipos de atualizações. Você pode usar o gerenciador de patches para aplicar patches a sistemas operacionais e aplicações. 
  +  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
  +  [Correção centralizada de várias contas e várias regiões com automação do AWS Systems Manager](https://https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  Implementar detecção e prevenção de intrusão: implemente uma ferramenta de detecção e prevenção de invasões para monitorar e interromper atividades maliciosas nas instâncias. 
+  Considerar as soluções de AWS Partner: os parceiros da AWS oferecem centenas de produtos líderes do setor que são equivalentes, idênticos ou se integram aos controles existentes nos seus ambientes on-premises. Esses produtos complementam os serviços da AWS já existentes para que os clientes possam implantar uma arquitetura de segurança abrangente e obter uma experiência mais uniforme na nuvem e no ambiente on-premises. 
  +  [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [Correção centralizada de várias contas e várias regiões com automação do AWS Systems Manager](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um bastion host com o Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2)](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada do firewall de aplicações Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 
+  [Laboratório: Implantação automatizada da aplicação Web no EC2](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 

# SEC06-BP05 Permitir que as pessoas executem ações a uma distância
<a name="sec_protect_compute_actions_distance"></a>

 A remoção da capacidade de acesso interativo reduz o risco de erro humano e o potencial de configuração ou gerenciamento manual. Por exemplo, use um fluxo de trabalho de gerenciamento de alterações para implantar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) usando infraestruturas como código e gerenciar instâncias do Amazon EC2 com ferramentas, como o AWS Systems Manager, em vez de permitir acesso direto, ou por meio de um host traga a sua própria licença. O AWS Systems Managerpode automatizar uma variedade de tarefas de manutenção e implantação, usando recursos que incluem fluxos de trabalho de [automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) [,](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), [documentos](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) (playbooks) e o [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html). O AWS CloudFormation empilha a compilação com base em pipelines e pode automatizar tarefas de implantação e gerenciamento de infraestrutura sem usar diretamente o Console de gerenciamento da AWS ou APIs. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Substitua o acesso ao controle: substitua o acesso ao console (SSH ou RDP) a instâncias com o Run Command do AWS Systems Manager para automatizar tarefas de gerenciamento. 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um host traga a sua própria licença pelo Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada do firewall de aplicações Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP06 Validar a integridade do software
<a name="sec_protect_compute_validate_software_integrity"></a>

 Implemente mecanismos (por exemplo, assinatura de código) para validar se o software, o código e as bibliotecas usados na workload são de fontes confiáveis e não foram adulterados. Por exemplo, você deve verificar o certificado de assinatura de código de binários e scripts para confirmar o autor e garantir que ele não tenha sido adulterado desde que foi criado pelo autor. [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) pode ajudar a garantir a confiança e a integridade do código gerenciando centralmente o ciclo de vida de assinatura de código, incluindo certificação de assinatura e chaves públicas e privadas. Você pode aprender a usar padrões avançados e práticas recomendadas para assinatura de código com o [AWS Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/). Além disso, uma soma de verificação do software que você faz download, em comparação com a soma de verificação do provedor, pode ajudar a garantir que ela não tenha sido adulterada. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Investigar os mecanismo: a assinatura de código é um mecanismo que pode ser usado para validar a integridade do software. 
  +  [NIST: Considerações de segurança para assinatura de código](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01262018.pdf) 

## Recursos
<a name="resources"></a>

**Documentos relacionados:** 
+ [AWS Signer](https://docs.aws.amazon.com/signer/index.html)
+ [New – Code Signing, a Trust and Integrity Control for AWS Lambda (Novo: assinatura de código, um controle de confiança e integridade para o AWS Lambda)](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 

# Proteção de dados
<a name="a-data-protection"></a>

**Topics**
+ [SEGURANÇA 7. Como classificar meus dados?](sec-07.md)
+ [SEGURANÇA 8. Como proteger seus dados em repouso?](sec-08.md)
+ [SEGURANÇA 9. Como proteger seus dados em trânsito?](sec-09.md)

# SEGURANÇA 7. Como classificar meus dados?
<a name="sec-07"></a>

A classificação serve para categorizar os dados com base em criticidade e confidencialidade para ajudá-lo a determinar os controles de proteção e retenção apropriados.

**Topics**
+ [SEC07-BP01 Identificar os dados em sua workload](sec_data_classification_identify_data.md)
+ [SEC07-BP02 Definir controles de proteção de dados](sec_data_classification_define_protection.md)
+ [SEC07-BP03 Automatizar a identificação e a classificação](sec_data_classification_auto_classification.md)
+ [SEC07-BP04 Definir o gerenciamento do ciclo de vida de dados](sec_data_classification_lifecycle_management.md)

# SEC07-BP01 Identificar os dados em sua workload
<a name="sec_data_classification_identify_data"></a>

É essencial compreender o tipo e a classificação de dados que sua workload está processando, os processos de negócios associados, onde os dados são armazenados e quem é o proprietário dos dados. Você também deve ter uma compreensão dos requisitos legais e de conformidade aplicáveis de sua workload e quais controles de dados precisam ser implementados. A identificação dos dados é a primeira etapa da jornada da classificação de dados. 

**Benefícios do estabelecimento desta prática recomendada:**

 A classificação dos dados possibilita que os proprietários da workload identifiquem os locais que armazenam dados sigilosos e determinem como esses dados devem ser acessados e compartilhados. 

 A classificação dos dados tem como objetivo responder às seguintes perguntas: 
+ **Qual tipo de dados você tem?**

  Podem ser dados como: 
  +  Propriedade intelectual (IP), como segredos comerciais, patentes ou contratos. 
  +  Informações de saúde protegidas (PHI), como registros médicos que contêm informações do histórico médico referente a um indivíduo. 
  +  Informações de identificação pessoal (PII), como nome, endereço, data de nascimento e ID nacional ou número de registro. 
  +  Dados do cartão de crédito, como o Número da conta principal (PAN), nome do titular do cartão, data de validade e número do código de serviço. 
  +  Onde os dados sigilosos são armazenados? 
  +  Quem pode acessar, modificar e excluir dados? 
  +  A compreensão das permissões do usuário é essencial na proteção contra o possível uso indevido de dados. 
+ **Quem pode realizar operações de criação, leitura, atualização e exclusão (CRUD)? **
  +  Considere a possível escalação de privilégios compreendendo quem pode gerenciar permissões aos dados. 
+ **Qual impacto nos negócios poderá ocorrer se os dados forem divulgados de forma acidental, alterados ou excluídos? **
  +  Entenda a consequência do risco se os dados forem modificados, excluídos ou divulgados acidentalmente. 

Ao responder a estas perguntas, você pode realizar as seguintes ações: 
+  Reduzir o escopo de dados sigilosos (como o número de locais de dados sigilosos) e limitar o acesso aos dados sigilosos somente para usuários aprovados. 
+  Obtenha um entendimento de diferentes tipos de dados para que você possa implementar técnicas e mecanismos de proteção de dados apropriados, como criptografia, prevenção da perda de dados e gerenciamento de identidade e acesso. 
+  Otimize os custos entregando os objetivos de controle certos para os dados. 
+  Responda às perguntas de modo confidencial de reguladores e auditores sobre os tipos e a quantidade de dados e como os dados de diferentes níveis de confidencialidade são isolados uns dos outros. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Classificação dos dados é o ato de identificar a confidencialidade dos dados. Ela pode envolver marcação para tornar os dados facilmente acessíveis e rastreáveis. A classificação de dados também reduz a duplicação de dados, o que pode ajudar a reduzir os custos de armazenamento e backup enquanto acelera o processo de pesquisa. 

 Utilize serviços, como o Amazon Macie para automatizar em grande escala a descoberta e a classificação de dados sigilosos. Outros serviços, como Amazon EventBridge e AWS Config, podem ser utilizados para automatizar a remediação de problemas de segurança de dados, como buckets do Amazon Simple Storage Service (Amazon S3) não criptografados e volumes do Amazon EC2 EBS ou recursos de dados não marcados. Para ter uma lista completa de integrações de serviços da AWS, consulte a [documentação do EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/event-types.html). 

 [A detecção de PII](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html) em dados não estruturados, como e-mails de clientes, tickets de suporte, análises de produtos e redes sociais, é possível [com o uso do Amazon Comprehend](https://aws.amazon.com/blogs/machine-learning/detecting-and-redacting-pii-using-amazon-comprehend/), que é um serviço de processamento de linguagem natural (PLN) que utiliza machine learning (ML) para encontrar insights e relacionamentos, como pessoas, locais, sentimentos e tópicos em texto não estruturado. Para ter uma lista de serviços da AWS que podem auxiliar na identificação dos dados, consulte [Técnicas comuns para detectar dados PHI e PII com o uso de serviços da AWS](https://aws.amazon.com/blogs/industries/common-techniques-to-detect-phi-and-pii-data-using-aws-services/). 

 Outro método compatível com a classificação e a proteção de dados é a [marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). A marcação possibilita atribuir metadados aos seus recursos da AWS que você pode utilizar para gerenciar, identificar, organizar, procurar e filtrar recursos. 

 Em alguns casos, você pode optar por marcar recursos inteiros (como um bucket do S3), especialmente quando uma workload ou um serviço específico deve armazenar processos ou transmissões de classificação de dados já conhecidos. 

 Quando apropriado, é possível marcar um bucket do S3 em vez de objetos individuais para facilidade de administração e manutenção de segurança. 

### Etapas da implementação
<a name="implementation-steps"></a>

**Detectar dados sigilosos no Amazon S3: **

1.  Antes de começar, você deve ter permissões apropriadas para acessar o console do Amazon Macie e as operações de API. Para ter detalhes adicionais, consulte [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html). 

1.  Utilize o Amazon Macie para realizar a descoberta de dados automatizada quando seus dados sigilosos residem no [Amazon S3](https://aws.amazon.com/s3/). 
   +  Utilize o guia [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) para configurar um repositório para os resultados da descoberta de dados sigilosos e criar um trabalho de descoberta de dados sigilosos. 
   +  [Como utilizar o Amazon Macie para visualizar dados sigilosos em buckets do S3.](https://aws.amazon.com/blogs/security/how-to-use-amazon-macie-to-preview-sensitive-data-in-s3-buckets/) 

      Por padrão, o Macie analisa objetos utilizando o conjunto de identificadores de dados gerenciados que recomendamos para a descoberta automatizada de dados sigilosos. É possível ajustar a análise configurando o Macie para utilizar identificadores de dados gerenciados específicos, identificadores de dados personalizados e listas de permissões quando ele realiza a descoberta automatizada de dados sigilosos para a sua conta ou organização. Você pode ajustar o escopo da análise excluindo buckets específicos (por exemplo, buckets do S3 que geralmente armazenam dados de registro em log da AWS). 

1.  Para configurar e utilizar a descoberta automatizada de dados sigilosos, consulte [Realizar a descoberta automatizada de dados sigilosos com o Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd-account-manage.html). 

1.  Você também pode considerar [Descoberta automatizada de dados para o Amazon Macie](https://aws.amazon.com/blogs/aws/automated-data-discovery-for-amazon-macie/). 

**Detectar dados sigilosos no Amazon RDS: **

 Para ter mais informações sobre a descoberta de dados em bancos de dados [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/), consulte [Habilitar a classificação de dados para o banco de dados Amazon RDS com o Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/). 

**Detectar dados sigilosos no DynamoDB: **
+  [Detectar dados sigilosos no DynamoDB com Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) explica como utilizar o Amazon Macie para detectar dados sigilosos em tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) exportando os dados para o Amazon S3 para verificação. 

** Soluções de parceiros da AWS: **
+  Considere utilizar nossa AWS Partner Network extensiva. Os parceiros da AWS têm ferramentas e frameworks de conformidade extensas que se integram diretamente aos serviços da AWS. Os parceiros podem oferecer uma solução de governança e conformidade personalizada para ajudar você a atender às suas necessidades organizacionais. 
+  Para saber sobre as soluções personalizadas em classificação de dados, consulte [Governança de dados na era dos requisitos de regulamento e conformidade](https://aws.amazon.com/big-data/featured-partner-solutions-data-governance-compliance/). 

 É possível aplicar automaticamente os padrões de marcação que sua organização adota criando e implantando políticas com o uso do AWS Organizations. As políticas de tag possibilitam especificar regras que definem nomes de chave válidas e quais valores são válidos para cada chave. É possível optar somente por monitorar, que oferece a você uma oportunidade de avaliar e limpar suas tags existentes. Depois que suas tags estiverem em conformidade com seus padrões escolhidos, você poderá ativar a aplicação nas políticas de tag a fim de impedir que tags sem conformidade sejam criadas. Para ter mais detalhes, consulte [Proteger tags de recursos utilizadas para autorização utilizando uma política de controle de serviço no AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) e o exemplo de política em [Impedir que as tags sejam modificadas, exceto por principais autorizados](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin). 
+  Para começar a utilizar políticas de tag no [AWS Organizations](https://aws.amazon.com/organizations/), é altamente recomendável que você siga o fluxo de trabalho em [Conceitos básicos de políticas de tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) antes de passar para políticas de tag mais avançadas. Compreender os efeitos de anexar uma política de tag simples a uma conta antes de expandir para uma unidade organizacional (UO) ou uma organização inteira permite ver os efeitos de uma política de tag antes de aplicar a conformidade com a política de tag. [Conceitos básicos de políticas de tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) oferece links para instruções de tarefas relacionadas a política mais avançadas. 
+  Considere a avaliação de outros [serviços e recursos do AWS](https://docs.aws.amazon.com/whitepapers/latest/data-classification/using-aws-cloud-to-support-data-classification.html#aws-services-and-features) compatíveis com a classificação de dados, que estão listados no whitepaper [Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 
+  [Descoberta automatizada de dados com o Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd.html) 
+  [Conceitos básicos de políticas de tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) 
+  [Detectar entidades de PII](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html) 

 **Blogs relacionados:** 
+  [Como utilizar o Amazon Macie para visualizar dados sigilosos em buckets do S3.](https://aws.amazon.com/blogs/security/how-to-use-amazon-macie-to-preview-sensitive-data-in-s3-buckets/) 
+  [Realizar a descoberta automatizada de dados sigilosos com o Amazon Macie](https://aws.amazon.com/blogs/aws/automated-data-discovery-for-amazon-macie/) 
+  [Técnicas comuns para detectar dados PHI e PII com o uso de serviços da AWS](https://aws.amazon.com/blogs/industries/common-techniques-to-detect-phi-and-pii-data-using-aws-services/) 
+  [Detectar e editar PII com o uso do Amazon Comprehend](https://aws.amazon.com/blogs/machine-learning/detecting-and-redacting-pii-using-amazon-comprehend/) 
+  [Proteger tags de recursos usadas para autorização utilizando uma política de controle de serviços no AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) 
+  [Habilitar a classificação do banco de dados Amazon RDS com o Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/) 
+  [Detectar dados sigilosos no DynamoDB com o Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) 

 **Vídeos relacionados:** 
+  [Segurança dos dados orientada a eventos com o uso do Amazon Macie](https://www.youtube.com/watch?v=onqA7MJssoU) 
+  [Amazon Macie para proteção e governança de dados](https://www.youtube.com/watch?v=SmMSt0n6a4k) 
+  [Ajustar descobertas de dados sigilosos com listas de permissão](https://www.youtube.com/watch?v=JmQ_Hybh2KI) 

# SEC07-BP02 Definir controles de proteção de dados
<a name="sec_data_classification_define_protection"></a>

 Proteja os dados de acordo com seu nível de classificação. Por exemplo, proteja dados classificados como públicos usando recomendações relevantes enquanto protege dados confidenciais com controles adicionais. 

Usando tags de recursos, separar contas da AWS por confidencialidade (e potencialmente também por advertência, enclave ou comunidade de interesse), políticas do IAM, SCPs do AWS Organizations, AWS Key Management Service (AWS KMS) e AWS CloudHSM, você pode definir e implementar as políticas de classificação e proteção de dados com criptografia. Por exemplo, se você tiver buckets do S3 que contêm dados altamente críticos ou instâncias do Amazon Elastic Compute Cloud (Amazon EC2) que processam dados confidenciais, eles poderão ser marcados com uma tag `Project=ABC` . Somente a equipe imediata sabe o que o código do projeto significa e fornece meios de usar o controle de acesso baseado em atributos. Você pode definir os níveis de acesso às chaves de criptografia do AWS KMS por meio de políticas de chave e concessões para garantir que somente os serviços apropriados tenham acesso ao conteúdo confidencial por meio de um mecanismo seguro. Se você estiver tomando decisões de autorização com base em tags, certifique-se de que as permissões nas tags sejam definidas adequadamente usando políticas de tags no AWS Organizations.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Defina o esquema de identificação e classificação de dados: a identificação e a classificação de seus dados são realizadas para avaliar o potencial impacto e o tipo de dados que você está armazenando e quem deve acessá-los. 
  +  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  Descubra os controles disponíveis da AWS: descubra os controles de segurança para os serviços da AWS que você usa ou planeja usar. Muitos serviços têm uma seção de segurança em sua documentação. 
  +  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  Identificar recursos de conformidade da AWS: identifique os recursos da AWS disponíveis para ajudar. 
  +  [https://aws.amazon.com/compliance/](https://aws.amazon.com/compliance/?ref=wellarchitected) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  [Whitepaper Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 
+  [Texto ausente](https://aws.amazon.com/compliance/) 

 **Vídeos relacionados:** 
+  [Introducing the New Amazon Macie (Apresentação do novo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEC07-BP03 Automatizar a identificação e a classificação
<a name="sec_data_classification_auto_classification"></a>

 automatizar a identificação e a classificação de dados pode ajudar a implementar os controles corretos. O uso de automação para isso, em vez de acesso direto de uma pessoa, reduz o risco de erros humanos e exposição. Você deve avaliar o uso de uma ferramenta, como o [Amazon Macie](https://aws.amazon.com/macie/), que usa machine learning para descobrir, classificar e proteger automaticamente dados confidenciais na AWS. O Amazon Macie reconhece dados confidenciais, como informações de identificação pessoal (PII) ou propriedade intelectual, e fornece painéis e alertas que dão visibilidade sobre como esses dados estão sendo acessados ou movidos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Use o Amazon Simple Storage Service (Amazon S3) Inventory: o Amazon S3 Inventory é uma das ferramentas que você pode usar para auditar e gerar relatórios sobre o status de replicação e criptografia de seus objetos. 
  +  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) 
+  Considere o Amazon Macie: O Amazon Macie usa o machine learning para descobrir e classificar automaticamente os dados armazenados no Amazon S3.
  +  [Amazon Macie](https://aws.amazon.com/macie/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon Macie](https://aws.amazon.com/macie/) 
+  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) 
+  [Whitepaper Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 

 **Vídeos relacionados:** 
+  [Introducing the New Amazon Macie (Apresentação do novo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEC07-BP04 Definir o gerenciamento do ciclo de vida de dados
<a name="sec_data_classification_lifecycle_management"></a>

 sua estratégia de ciclo de vida definida deve ser baseada no nível de confidencialidade, bem como nos requisitos legais e organizacionais. Aspectos como a duração pela qual você retém dados, processos de destruição de dados, gerenciamento de acesso a dados, transformação de dados e compartilhamento de dados devem ser considerados. Ao escolher uma metodologia de classificação de dados, equilibre usabilidade e acesso. Considere também os vários níveis de acesso e nuances para implementar uma abordagem segura, mas utilizável, para cada nível. Sempre use uma abordagem de defesa detalhada e reduza o acesso humano a dados e mecanismos para transformar, excluir ou copiar dados. Por exemplo, exija que os usuários se autentiquem fortemente em uma aplicação e conceda a ela, e não aos usuários, a permissão de acesso necessária para executar uma ação a distância. Além disso, garanta que os usuários venham de um caminho de rede confiável e exijam acesso às chaves de descriptografia. Use ferramentas como painéis ou relatórios automatizados para fornecer aos usuários informações extraídas dos dados e não acesso direto aos dados. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Identificar tipos de dados: identifique os tipos de dados que você está armazenando ou processando em sua workload. Esses dados podem ser texto, imagens, bancos de dados binários, entre outros. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Whitepaper Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 

 **Vídeos relacionados:** 
+  [Introducing the New Amazon Macie (Apresentação do novo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEGURANÇA 8. Como proteger seus dados em repouso?
<a name="sec-08"></a>

Proteja seus dados em repouso implementando vários controles para reduzir o risco de acesso não autorizado ou manuseio incorreto.

**Topics**
+ [SEC08-BP01 Implementar gerenciamento de chaves seguro](sec_protect_data_rest_key_mgmt.md)
+ [SEC08-BP02 Aplicar criptografia em repouso](sec_protect_data_rest_encrypt.md)
+ [SEC08-BP03 Automatizar a proteção de dados em repouso](sec_protect_data_rest_automate_protection.md)
+ [SEC08-BP04 Impor o controle de acesso](sec_protect_data_rest_access_control.md)
+ [SEC08-BP05 Usar mecanismos para evitar que as pessoas acessem os dados](sec_protect_data_rest_use_people_away.md)

# SEC08-BP01 Implementar gerenciamento de chaves seguro
<a name="sec_protect_data_rest_key_mgmt"></a>

 O gerenciamento seguro de chaves inclui o armazenamento, a rotação, o controle de acesso e o monitoramento do material essencial necessário para proteger os dados em repouso para sua workload. 

 **Resultado desejado:** um mecanismo de gerenciamento de chaves escalável, repetível e automatizado. O mecanismo deve fornecer a capacidade de impor o acesso de privilégio mínimo ao material essencial e fornecer o equilíbrio correto entre disponibilidade, confidencialidade e integridade das chaves. O acesso às chaves deve ser monitorado e o material da chave deve ser rotacionado por meio de um processo automatizado. O material de chave nunca deve estar acessível a identidades humanas. 

**Antipadrões comuns:** 
+  Acesso humano a material de chave não criptografado. 
+  Criação de algoritmos criptográficos personalizados. 
+  Permissões excessivamente amplas para acessar materiais importantes. 

 **Benefícios de estabelecer esta prática recomendada:** Ao estabelecer um mecanismo seguro de gerenciamento de chaves para sua workload, você pode ajudar a proteger seu conteúdo contra acesso não autorizado. Além disso, você pode estar sujeito aos requisitos regulamentares para criptografar seus dados. Uma solução eficaz de gerenciamento de chaves pode fornecer mecanismos técnicos alinhados a essas regulamentações para proteger o material chave. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Muitos requisitos regulatórios e práticas recomendadas incluem a criptografia de dados em repouso como um controle de segurança fundamental. Para cumprir esse controle, sua workload precisa de um mecanismo para armazenar e gerenciar com segurança o material chave usado para criptografar seus dados em repouso. 

 A AWS oferece o AWS Key Management Service (AWS KMS) para fornecer armazenamento durável, seguro e redundante para chaves do AWS KMS. [Muitos serviços da AWS se integram com o AWS KMS](https://aws.amazon.com/kms/features/#integration) para oferecer suporte à criptografia de seus dados. O AWS KMS usa módulos de segurança de hardware validados pelo FIPS 140-2 Nível 3 para proteger suas chaves. Não há mecanismo para exportar chaves do AWS KMS em texto simples. 

 Ao implantar workloads usando uma estratégia de várias contas, isso é considerado [prática recomendada](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/application.html#app-kms) para manter chaves do AWS KMS na mesma conta da workload que as usa. Nesse modelo distribuído, a responsabilidade pelo gerenciamento das chaves do AWS KMS é da equipe de aplicações. Em outros casos de uso, as organizações podem optar por armazenar as chaves do AWS KMS em uma conta centralizada. Essa estrutura centralizada requer políticas adicionais para permitir o acesso entre contas necessário para que a conta da workload acesse as chaves armazenadas na conta centralizada, mas pode ser mais aplicável em casos de uso em que uma única chave é compartilhada entre várias Contas da AWS. 

 Independentemente de onde o material da chave esteja armazenado, o acesso à chave deve ser rigorosamente controlado por meio do uso de [políticas de chave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) e políticas do IAM. Políticas de chave são a principal forma de controlar o acesso a uma chave do AWS KMS. Além disso, concessões à chave do AWS KMS podem fornecer acesso a serviços da AWS para criptografar e descriptografar dados em seu nome. Reserve um tempo para revisar as [práticas recomendadas para controle de acesso às chaves do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html). 

 É uma prática recomendada monitorar o uso de chaves de criptografia para detectar padrões de acesso incomuns. As operações realizadas usando chaves gerenciadas pela AWS e chaves gerenciadas pelo cliente armazenadas no AWS KMS podem ser registradas no AWS CloudTrail e devem ser revisadas periodicamente. Atenção especial deve ser dada ao monitoramento dos principais eventos de destruição. Para mitigar a destruição acidental ou maliciosa de material de chave, os eventos de destruição da chave não excluem o material da chave imediatamente. As tentativas de excluir as chaves no AWS KMS estão sujeitas a um [período de espera](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html#deleting-keys-how-it-works), cujo padrão é de 30 dias, dando aos administradores tempo para revisar essas ações e reverter a solicitação, se necessário. 

 A maioria dos serviços da AWS usam o AWS KMS de forma transparente para você. Seu único requisito é decidir se quer usar uma chave gerenciada pela AWS ou gerenciada pelo cliente. Se sua workload exigir o uso direto de AWS KMS para criptografar ou descriptografar dados, a prática recomendada é usar [criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) para proteger seus dados. O [SDK de criptografia da AWS](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) pode fornecer às suas aplicações primitivas de criptografia do lado do cliente para implementar a criptografia envelopada e integrar com o AWS KMS. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Determine as opções adequadas [de gerenciamento de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt) (gerenciado pela AWS ou gerenciado pelo cliente) para a chave. 
   +  Para facilitar o uso, a AWS oferece, para a maioria dos serviços, chaves de propriedade da AWS e gerenciadas por ela, que fornecem capacidade de criptografia em repouso sem a necessidade de gerenciar materiais ou políticas de chaves. 
   +  Ao usar chaves gerenciadas pelo cliente, considere o armazenamento de chaves padrão para fornecer o melhor equilíbrio entre agilidade, segurança, soberania de dados e disponibilidade. Outros casos de uso podem exigir o uso de armazenamentos de chaves personalizadas com [AWS CloudHSM](https://aws.amazon.com/cloudhsm/) ou o [armazenamento de chaves externo](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html). 

1.  Analise a lista de serviços que você está usando para sua workload para entender como o AWS KMS se integra ao serviço. Por exemplo, as instâncias do EC2 podem usar volumes criptografados do EBS, verificando se os snapshots do Amazon EBS criados a partir desses volumes também são criptografados usando uma chave gerenciada pelo cliente e mitigando a divulgação acidental de dados de snapshots não criptografados. 
   +  [Como os serviços da AWS são usados no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/service-integration.html) 
   +  Para obter informações detalhadas sobre as opções de criptografia que um serviço da AWS oferece, consulte o tópico Criptografia em repouso no guia do usuário ou no guia do desenvolvedor do serviço. 

1.  Implemente o AWS KMS: o AWS KMS simplifica a criação e o gerenciamento de chaves e o controle do uso da criptografia em uma ampla variedade de serviços da AWS e em suas aplicações. 
   +  [Conceitos básicos: AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) 
   +  Revise as [práticas recomendadas para controle de acesso às chaves do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html). 

1.  Considere o AWS Encryption SDK: use a integração do AWS Encryption SDK com o AWS KMS quando sua aplicação precisar criptografar dados no lado do cliente. 
   +  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

1.  Habilite o [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para revisar e notificar automaticamente se houver políticas de chave do AWS KMS excessivamente amplas. 

1.  Habilite o [Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html) para receber notificações se houver políticas de chaves configuradas incorretamente, chaves programadas para exclusão ou chaves sem a rotação automática ativada. 

1.  Determine o nível de registro em log apropriado para suas chaves do AWS KMS. Como as chamadas para o AWS KMS, incluindo eventos somente para leitura, são registradas em log, os logs do CloudTrail associados ao AWS KMS podem se tornar volumosos. 
   +  Algumas organizações preferem registrar a atividade de log do AWS KMS em uma trilha separada. Para obter mais detalhes, consulte a seção [Registro em log de chamadas de API do AWS KMS com CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html) do guia do desenvolvedor do AWS KMS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 
+  [Ferramentas e serviços criptográficos da AWS](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) 
+  [Como proteger dados do Amazon S3 com o uso de criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [Criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) 
+  [Promessa de soberania digital](https://aws.amazon.com/blogs/security/aws-digital-sovereignty-pledge-control-without-compromise/) 
+  [Desmistificação das operações de chave do AWS KMS, traga sua própria chave, armazenamento de chaves personalizado e portabilidade de texto cifrado](https://aws.amazon.com/blogs/security/demystifying-kms-keys-operations-bring-your-own-key-byok-custom-key-store-and-ciphertext-portability/) 
+  [Detalhes criptográficos do AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **Vídeos relacionados:** 
+  [How Encryption Works in AWS (Como funciona a criptografia na AWS)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Proteger seu armazenamento em bloco na AWS)](https://youtu.be/Y1hE1Nkcxs8) 
+  [AWS data protection: Using locks, keys, signatures, and certificates (Proteção de dados da AWS: uso de travas, chaves, assinaturas e certificados)](https://www.youtube.com/watch?v=lD34wbc7KNA) 

 **Exemplos relacionados:** 
+  [Implemente mecanismos avançados de controle de acesso usando o AWS KMS](https://catalog.workshops.aws/advkmsaccess/en-US/introduction) 

# SEC08-BP02 Aplicar criptografia em repouso
<a name="sec_protect_data_rest_encrypt"></a>

 É necessário implementar o uso de criptografia para dados em repouso. A criptografia mantém a confidencialidade dos dados sigilosos em caso de acesso não autorizado ou divulgação acidental. 

 **Resultado desejado:** os dados privados devem ser criptografados por padrão quando em repouso. A criptografia ajuda a manter a confidencialidade dos dados e oferece uma camada adicional de proteção contra a divulgação intencional ou acidental de dados ou exfiltração. Dados criptografados não podem ser lidos nem acessados sem primeiro descriptografá-los. Todos os dados armazenados não criptografados devem ser inventariados e controlados. 

 **Antipadrões comuns:** 
+  Não utilizar configurações de criptografia por padrão. 
+  Conceder acesso excessivamente permissivo para chaves de descriptografia. 
+  Não monitorar o uso de chaves de criptografia e descriptografia. 
+  Armazenar dados não criptografados. 
+  Utilizar a mesma chave de criptografia para todos os dados, seja qual for o uso, os tipos e a classificação de dados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Mapeie as chaves de criptografia às classificações de dados em suas workloads. Essa abordagem ajuda a proteger-se contra o acesso excessivamente permissivo ao utilizar uma chave única ou um número muito pequeno de chaves de criptografia para seus dados (consulte [SEC07-BP01 Identificar os dados em sua workload](sec_data_classification_identify_data.md)). 

 O AWS Key Management Service (AWS KMS) integra-se a muitos serviços da AWS para facilitar a criptografia de seus dados em repouso. Por exemplo, no Amazon Simple Storage Service (Amazon S3), você pode definir a [criptografia padrão](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html) em um bucket para que os novos objetos sejam criptografados automaticamente. Ao utilizar o AWS KMS, considere o nível de restrição necessário para os dados. Chaves do AWS KMS controladas por serviço e padrão são gerenciadas e utilizadas em seu nome pelo AWS. Para dados sigilosos que exijam acesso refinado à chave de criptografia subjacente, considere chaves gerenciadas pelo cliente (CMKs). Você tem total controle sobre as CMKs, como gerenciamento de alternância e acesso pelo uso de políticas de chave. 

 Além disso, o [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) e o [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) são compatíveis com a imposição de criptografia ao definir a criptografia padrão. Você pode usar o [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) para conferir automaticamente se está usando criptografia, por exemplo, [volumes do Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), instâncias do [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html) e [buckets do Amazon S3](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). 

 A AWS também oferece operações de criptografia do lado do cliente, possibilitando que você criptografe os dados antes de fazer upload deles para a nuvem. O AWS Encryption SDKoferece uma forma de criptografar seus dados utilizando a [criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping). Você fornece a chave de encerramento, e o AWS Encryption SDK gera uma chave de dados exclusiva para cada objeto de dados que ele criptografa. Considere utilizar o AWS CloudHSM se precisar de um módulo de segurança de hardware de um locatário (HSM) gerenciado. O AWS CloudHSM possibilita gerar, importar e gerenciar chaves criptográficas em um HSM validado de nível 3 FIPS 140-2. Alguns casos de uso do AWS CloudHSM incluem proteger chaves privadas para emitir uma autoridade de certificado (CA) e ativar a criptografia de dados transparente (TDE) para bancos de dados Oracle. O AWS CloudHSM Client SDK oferece software que possibilita criptografar dados do lado do cliente com chaves armazenadas no AWS CloudHSM antes de fazer upload de seus dados para AWS. O Amazon DynamoDB Encryption Client também possibilita criptografar e assinar itens antes de fazer upload para uma tabela do DynamoDB. 

 **Etapas da implementação** 
+  **Impor criptografia em repouso para o Amazon S3:** implemente a [criptografia padrão do bucket do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html). 

   **Configurar a [criptografia padrão para volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html):** especifique que você deseja que todos os volumes do Amazon EBS recém-criados sejam criados em formato criptografado, com a opção de usar a chave padrão fornecida pela AWS ou uma chave que você criar. 

   **Configurar imagens de máquina da Amazon (AMIs) criptografadas:** a cópia de uma AMI existente com criptografia habilitada criptografará automaticamente os volumes raiz e os snapshots. 

   **Configurar a [criptografia do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html):** configure a criptografia para seus clusters de banco de dados Amazon RDS e snapshots em repouso utilizando a opção de criptografia. 

   **Criar e configurar chaves do AWS KMS com políticas que limitem o acesso às entidades principais apropriadas para cada classificação de dados:** por exemplo, crie uma chave do AWS KMS para criptografar dados de produção e uma chave diferente para criptografar dados de desenvolvimento ou teste. Você também pode conceder acesso de chave a outras Contas da AWS. Considere ter contas diferentes para seus ambientes de desenvolvimento e produção. Se seu ambiente de produção precisar descriptografar artefatos na conta de desenvolvimento, você poderá editar a política de CMK utilizada para criptografar os artefatos de desenvolvimento a fim de conferir à conta de produção a capacidade de descriptografar esses artefatos. O ambiente de produção pode, então, ingerir os dados descriptografados para uso na produção. 

   **Configurar a criptografia em serviços da AWS adicionais:** para outros serviços da AWS utilizados, leia a [documentação de segurança](https://docs.aws.amazon.com/security/) do serviço em questão para determinar as opções de criptografia do serviço. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Ferramentas de criptografia da AWS](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 
+  [Whitepaper de detalhes criptográficos do AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 
+  [AWS Key Management Service](https://aws.amazon.com/kms) 
+  [Ferramentas e serviços criptográficos da AWS](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) 
+  [Criptografia do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Criptografia padrão de volumes do Amazon EBS](https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-volumes/) 
+  [Criptografar recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [Como ativo a criptografia padrão para um bucket do Amazon S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html) 
+  [Proteger dados do Amazon S3 com o uso de criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 

 **Vídeos relacionados:** 
+  [Como a criptografia funciona na AWS](https://youtu.be/plv7PQZICCM) 
+  [Proteger o armazenamento em bloco na AWS](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP03 Automatizar a proteção de dados em repouso
<a name="sec_protect_data_rest_automate_protection"></a>

 Use ferramentas automatizadas para validar e impor controles de dados em repouso continuamente, por exemplo, verificar se há apenas recursos de armazenamento criptografados. Você pode [automatizar a validação de que todos os volumes do EBS são criptografados](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html) com o uso do [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). [AWS Security Hub CSPM](http://aws.amazon.com/security-hub/) também pode verificar vários controles diferentes por meio de verificações automatizadas em relação a padrões de segurança. Além disso, o Regras do AWS Config pode [corrigir recursos não compatíveis automaticamente](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html#setup-autoremediation). 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation_guidance"></a>

 *Dados em repouso* representam todos os dados mantidos no armazenamento não volátil por qualquer período na carga de trabalho. Isso inclui armazenamento em bloco, armazenamento de objetos, bancos de dados, arquivos, dispositivos IoT e qualquer outro meio de armazenamento no qual os dados persistam. Proteger seus dados em repouso reduz o risco de acesso não autorizado quando a criptografia e os controles de acesso adequados são implementados. 

 Garantir a criptografia em repouso: garanta que a única maneira de armazenar dados seja usando a criptografia. O AWS KMS se integra perfeitamente a muitos serviços da AWS para facilitar a criptografia de todos os seus dados em repouso. Por exemplo, no Amazon Simple Storage Service (Amazon S3), você pode definir a [criptografia padrão](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) em um bucket para que todos os novos objetos sejam criptografados automaticamente. Além disso, o [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) e [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) oferecem suporte à imposição de criptografia ao definir a criptografia padrão. Você pode usar o [AWS Managed Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) para verificar automaticamente se você está usando criptografia, por exemplo, para [Volumes do EBS](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), [instâncias do Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)e aos [Amazon S3](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Ferramentas de criptografia da AWS](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [SDK de criptografia da AWS](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

 **Vídeos relacionados:** 
+  [How Encryption Works in AWS (Como a criptografia funciona na AWS)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Como proteger o armazenamento em bloco na AWS)](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP04 Impor o controle de acesso
<a name="sec_protect_data_rest_access_control"></a>

 Para ajudar a proteger seus dados em repouso, implemente o controle de acesso utilizando mecanismos, como isolamento e versionamento, e aplique o princípio de privilégio mínimo. Evite conceder acesso público aos seus dados. 

**Resultado desejado:** garantir que somente usuários autorizados possam acessar os dados conforme a necessidade. Proteger seus dados com backups regulares e versionamento a fim de impedir a modificação ou a exclusão de dados intencionais ou acidentais. Isolar dados críticos de outros dados a fim de proteger a confidencialidade e a integridade deles. 

**Antipadrões comuns:**
+  Armazenar dados com requisitos de confidencialidade ou classificações diferentes juntos. 
+  Utilizar permissões excessivamente permissivas em chaves de descriptografia. 
+  Classificar dados de modo inadequado. 
+  Não reter backups detalhados de dados importantes. 
+  Conceder acesso persistente a dados de produção. 
+  Não auditar o acesso aos dados nem rever as permissões regularmente 

**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Vários controles podem ajudar a proteger seus dados em repouso, por exemplo, acesso (utilizando privilégio mínimo), isolamento e versionamento. Deve ser feita a auditoria de acesso aos seus dados com os mecanismos de detecção, como AWS CloudTrail e os logs de nível de serviço, como os logs de acesso do Amazon Simple Storage Service (Amazon S3). Você deve inventariar quais dados são acessíveis publicamente e criar um plano para reduzir a quantidade de dados disponíveis ao longo do tempo. 

 O Amazon Glacier Vault Lock e o Amazon S3 Object Lock fornecem controle de acesso obrigatório para os objetos no Amazon S3. Assim que uma política de cofre é bloqueada com a opção de conformidade, nem mesmo o usuário raiz pode alterá-la até que o bloqueio expire. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Aplicar o controle de acesso**: aplique o controle de acesso com privilégios mínimos, incluindo acesso a chaves de criptografia. 
+  **Dados separados com base em diferentes níveis de classificação**: use diferentes Contas da AWS para níveis de classificação de dados e gerencie essas contas com o [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). 
+  **Analisar as políticas do AWS Key Management Service (AWS KMS)**: [analise o nível de acesso](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) concedido nas políticas do AWS KMS. 
+  **Revisar as permissões de objeto e de bucket do Amazon S3**: revise regularmente o nível de acesso concedido nas políticas de bucket do S3. Uma das práticas recomendadas é evitar buckets que possam ser lidos ou gravados publicamente. Considere o uso do [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) para detectar buckets que estão disponíveis publicamente e do Amazon CloudFront para fornecer conteúdo do Amazon S3. Garanta que os buckets que não devem permitir acesso público sejam configurados adequadamente para evitar o acesso público. Por padrão, todos os buckets do S3 são privados e só ser acessados por usuários que receberam explicitamente esse acesso. 
+  **Ativar o [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html):** o IAM Access Analyzer analisa os buckets do Amazon S3 e gera uma descoberta quando [uma política do S3 concede acesso a uma entidade externa.](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-resources.html#access-analyzer-s3) 
+  **Habilitar o [versionamento do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) e o [bloqueio de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)** quando apropriado. 
+  **Utilizar o [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html)**: o Amazon S3 Inventory pode ser usado para auditar e gerar relatórios sobre o status de replicação e criptografia de seus objetos do S3. 
+  **Revisar as permissões do [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) e do [compartilhamento de AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html)**: as permissões de compartilhamento podem permitir que imagens e volumes sejam compartilhados com Contas da AWS externas à sua workload. 
+  **Revise os compartilhamentos do [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) periodicamente para determinar se os recursos devem continuar a ser compartilhados.** O Resource Access Manager possibilita compartilhar recursos, como políticas do AWS Network Firewall, regras do Amazon Route 53 Resolver e sub-redes em suas Amazon VPCs. Faça auditoria em recursos compartilhados regularmente e interrompa o compartilhamento dos que não precisem mais ser compartilhados. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC03-BP01 Definir requisitos de acesso](sec_permissions_define.md) 
+  [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md) 

 **Documentos relacionados:** 
+  [Whitepaper de detalhes criptográficos do AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 
+  [Introdução ao gerenciamento de permissões de acesso aos seus recursos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/intro-managing-access-s3-resources.html) 
+  [Visão geral do gerenciamento de acesso dos recursos do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) 
+  [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) 
+  [Amazon S3 \$1 Amazon CloudFront: uma combinação perfeita na nuvem](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/) 
+  [Usar versionamento](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) 
+  [Bloquear objetos usando o Bloqueio de objetos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html) 
+  [Compartilhar um snapshot do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) 
+  [AMIs compartilhadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html) 
+  [Hospedar uma aplicação de uma página no Amazon S3](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) 

 **Vídeos relacionados:** 
+  [Proteger o armazenamento em bloco na AWS](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP05 Usar mecanismos para evitar que as pessoas acessem os dados
<a name="sec_protect_data_rest_use_people_away"></a>

 Impeça que os usuários acessem dados e sistemas confidenciais diretamente em circunstâncias operacionais normais. Por exemplo, use um fluxo de trabalho de gerenciamento de alterações para gerenciar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) usando ferramentas em vez de permitir acesso direto ou um host traga a sua própria licença. Isso pode ser obtido usando o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), que usa [documentos de automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) que contêm etapas que você usa para realizar tarefas. Esses documentos podem ser armazenados no controle de origem, analisados por pares antes da execução e testados detalhadamente para minimizar os riscos em comparação com o acesso ao shell. Os usuários empresariais podem ter um painel em vez de acesso direto a um armazenamento de dados para executar consultas. Quando os pipelines de CI/CD não forem usados, determine quais controles e processos são necessários para fornecer adequadamente um mecanismo de acesso break-glass normalmente desabilitado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Implemente mecanismos para manter as pessoas longe dos dados: os mecanismos incluem o uso de painéis, como o Quick, para exibir dados aos usuários em vez de consultar diretamente. 
  +  [Quick](https://aws.amazon.com/quicksight/) 
+  Automatize o gerenciamento de configuração: execute ações remotas, aplique e valide configurações seguras automaticamente usando uma ferramenta ou um serviço de gerenciamento de configuração. Evite usar hosts traga a sua própria licença ou acessar diretamente instâncias do EC2. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [Pipeline de CI/CD do AWS CloudFormation para modelos na AWS](https://aws.amazon.com/quickstart/architecture/cicd-taskcat/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Whitepaper de detalhes criptográficos do AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **Vídeos relacionados:** 
+  [How Encryption Works in AWS (Como a criptografia funciona no AWS Backup)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Como proteger o armazenamento em bloco na AWS)](https://youtu.be/Y1hE1Nkcxs8) 

# SEGURANÇA 9. Como proteger seus dados em trânsito?
<a name="sec-09"></a>

Proteja seus dados em trânsito implementando vários controles para reduzir o risco de acesso não autorizado ou perda.

**Topics**
+ [SEC09-BP01 Implementar o gerenciamento seguro de chaves e certificados](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Aplicar a criptografia em trânsito](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Automatizar a detecção de acesso não intencional a dados](sec_protect_data_transit_auto_unintended_access.md)
+ [SEC09-BP04 Autenticar as comunicações de rede](sec_protect_data_transit_authentication.md)

# SEC09-BP01 Implementar o gerenciamento seguro de chaves e certificados
<a name="sec_protect_data_transit_key_cert_mgmt"></a>

 Os certificados Transport Layer Security (TLS) são usados para proteger as comunicações de rede e estabelecer a identidade de sites, recursos e workloads na internet, bem como em redes privadas. 

 **Resultado desejado:** Um sistema seguro de gerenciamento de certificados que pode provisionar, implantar, armazenar e renovar certificados em uma infraestrutura de chave pública (PKI). Um mecanismo seguro de gerenciamento de chaves e certificados evita que o material da chave privada do certificado seja divulgado e renova automaticamente o certificado periodicamente. Ele também se integra a outros serviços para fornecer comunicações de rede seguras e identidade para os recursos da máquina na workload. O material de chave nunca deve estar acessível a identidades humanas. 

 **Antipadrões comuns:** 
+  Executar etapas manuais durante os processos de implantação ou renovação de certificado. 
+  Não prestar a devida atenção à hierarquia da autoridade de certificação (CA) ao criar uma CA privada. 
+  Usar certificados autoassinados para recursos públicos. 

 **Benefícios de estabelecer esta prática recomendada: **
+  Simplificar o gerenciamento de certificados por meio de implantação e renovação automatizadas. 
+  Incentivar a criptografia de dados em trânsito usando certificados TLS. 
+  Aumentar a segurança e a auditabilidade das ações de certificação realizadas pela autoridade de certificação. 
+  Organizar as tarefas de gerenciamento em diferentes camadas da hierarquia da CA. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto

## Orientação para implementação
<a name="implementation-guidance"></a>

 As workloads modernas fazem uso extensivo de comunicações de rede criptografadas usando protocolos de PKI, como TLS. O gerenciamento de certificados PKI pode ser complexo, mas o provisionamento, a implantação e a renovação automatizados de certificados podem reduzir o atrito associado ao gerenciamento deles. 

 A AWS oferece dois serviços para gerenciar certificados de PKI de uso geral: [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) e [Autoridade de Certificação Privada da AWS (CA Privada da AWS)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). O ACM é o principal serviço que os clientes usam para provisionar, gerenciar e implantar certificados para uso em workloads públicas e privadas da AWS. O ACM emite certificados usando o CA Privada da AWS e [integra-se](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) a muitos outros serviços gerenciados da AWS para fornecer certificados TLS seguros para workloads. 

 A CA Privada da AWS permite estabelecer a própria autoridade de certificação raiz ou subordinada e emitir certificados TLS por meio de uma API. É possível usar esses tipos de certificado em cenários em que você controla e gerencia a cadeia de confiança do lado do cliente da conexão TLS. Além dos casos de uso do TLS, a CA Privada da AWS pode ser usada para emitir certificados para pods do Kubernetes, atestados de produtos de dispositivos Matter, assinatura de código e outros casos de uso com um [modelo personalizado](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). Você também pode usar [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para fornecer credenciais do IAM temporárias para workloads on-premises que receberam certificados X.509 assinados pela CA privada. 

 Além do ACM e do CA Privada da AWS, o [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) oferece suporte especializado para provisionar, gerenciar e implantar certificados de PKI em dispositivos de IoT. O AWS IoT Core fornece mecanismos especializados para [integração de dispositivos de IoT](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) à infraestrutura de chave pública em grande escala. 

**Considerações para estabelecer uma hierarquia de CA privada **

 Quando precisar estabelecer uma CA privada, é importante tomar cuidado especial para projetar adequadamente a hierarquia da CA com antecedência. É uma prática recomendada implantar cada nível de sua hierarquia de CA em Contas da AWS separadas ao criar uma hierarquia de CA privada. Essa etapa intencional reduz a área de superfície de cada nível na hierarquia da CA, simplificando a descoberta de anomalias nos dados de log do CloudTrail e reduzindo o escopo de acesso ou impacto se houver acesso não autorizado a uma das contas. A CA raiz deve residir em uma própria conta separada e deve ser usada somente para emitir um ou mais certificados de CA intermediários. 

 Depois, crie uma ou mais CAs intermediárias em contas separadas da conta da CA raiz para emitir certificados para usuários finais, dispositivos ou outras workloads. Por fim, emita certificados da CA raiz para as CAs intermediárias, que, por sua vez, emitirão certificados para os usuários finais ou dispositivos. Para obter mais informações sobre como planejar a implantação de CA e projetar a hierarquia de CA, incluindo planejamento de resiliência, replicação entre regiões, compartilhamento de CAs na organização e muito mais, consulte [Planning your CA Privada da AWS deployment](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Determine os serviços da AWS relevantes e necessários para seu caso de uso: 
   +  Muitos casos de uso podem aproveitar a infraestrutura de chave pública da AWS existente usando o [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). O ACM pode ser usado para implantar certificados TLS para servidores web, balanceadores de carga ou outros usos para certificados publicamente confiáveis. 
   +  Considere [CA Privada da AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) quando precisar estabelecer a própria hierarquia de autoridade de certificação privada ou precisar acessar certificados exportáveis. O ACM pode então ser usado para emitir [muitos tipos de certificados de entidade final](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) usando a CA Privada da AWS. 
   +  Para casos de uso em que os certificados devem ser provisionados em grande escala para dispositivos incorporados de Internet das Coisas (IoT), pense no [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html). 

1.  Implemente a renovação automática do certificado sempre que possível: 
   +  Use [a renovação gerenciada pelo ACM](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) para certificados emitidos pelo ACM junto com serviços gerenciados da AWS integrados. 

1.  Estabeleça trilhas de auditoria e registro: 
   +  Habilite o [Logs do CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) para monitorar o acesso às contas que têm autoridades de certificação. Considere configurar a validação da integridade do arquivo de log no CloudTrail para verificar a autenticidade dos dados de log. 
   +  Gere e revise periodicamente [relatórios de auditoria](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) que listam os certificados que a CA privada emitiu ou revogou. Esses relatórios podem ser exportados para um bucket do S3. 
   +  Ao implantar uma CA privada, você também precisará estabelecer um bucket do S3 para armazenar a lista de revogação de certificados (CRL). Para obter orientação sobre como configurar esse bucket do S3 com base nos requisitos da workload, consulte [Planejar uma lista de revogação de certificados (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md) 
+ [SEC08-BP01 Implementar gerenciamento de chaves seguro](sec_protect_data_rest_key_mgmt.md)
+  [SEC09-BP04 Autenticar as comunicações de rede](sec_protect_data_transit_authentication.md) 

 **Documentos relacionados:** 
+  [How to host and manage an entire private certificate infrastructure in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/) 
+  [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/) 
+  [Práticas recomendadas de CA privada](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html) 
+  [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) 

 **Vídeos relacionados:** 
+  [Activating AWS Certificate Manager Private CA (workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE) 

 **Exemplos relacionados:** 
+  [Workshop de CA privada](https://catalog.workshops.aws/certificatemanager/en-US/introduction) 
+  [IOT Device Management Workshop](https://iot-device-management.workshop.aws/en/) (incluindo provisionamento de dispositivos) 

 **Ferramentas relacionadas:** 
+  [Plug-in para o gerenciador de certificados do Kubernetes para usar a CA Privada da AWS](https://github.com/cert-manager/aws-privateca-issuer) 

# SEC09-BP02 Aplicar a criptografia em trânsito
<a name="sec_protect_data_transit_encrypt"></a>

Aplique os requisitos de criptografia definidos com base em políticas, obrigações regulatórias e padrões da organização para cumprir os requisitos organizacionais, legais e de conformidade. Utilize somente protocolos com criptografia ao transmitir dados sigilosos para fora da sua nuvem privada virtual (VPC). A criptografia ajuda a manter a confidencialidade dos dados mesmo quando os dados passam por redes não confiáveis.

 **Resultado desejado:** todos os dados devem ser criptografados em trânsito com pacotes de criptografia e protocolos TLS seguros. O tráfego de rede entre seus recursos e a Internet deve ser criptografado para reduzir o acesso não autorizado aos dados. O tráfego de rede exclusivamente em seu ambiente interno da AWS deve ser criptografado com TLS sempre que possível. A rede interna da AWS é criptografada por padrão e o tráfego de rede em uma VPC não pode ser adulterado nem interceptado a menos que uma parte não autorizada tenha obtido acesso ao recurso que esteja gerando o tráfego (como instâncias do Amazon EC2 e contêineres do Amazon ECS). Considere proteger o tráfego de rede para rede com uma rede privada virtual (VPN) IPsec. 

 **Antipadrões comuns:** 
+  Utilizar versões obsoletas de SSL, TLS e componentes do pacote de criptografia (por exemplo, SSL v3.0, chaves RSA de 1024 bits e criptografia RC4). 
+  Permitir tráfego não criptografado (HTTP) para ou de recursos voltados para o público. 
+  Não monitorar e substituir certificados X.509 antes da validade. 
+  Utilizar certificados X.509 autoassinados para TLS. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os serviços da AWS fornecem endpoints HTTPS usando TLS para comunicação, fornecendo criptografia em trânsito quando se comunicam com as APIs da AWS. Protocolos não seguros, como HTTP, podem ser auditados e bloqueados em uma VPC por meio do uso de grupos de segurança. Solicitações HTTP também podem ser [redirecionadas automaticamente para HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) no Amazon CloudFront ou em um [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions). Você tem controle total sobre seus recursos de computação para implementar a criptografia em trânsito em seus serviços. Além disso, você pode usar a conectividade VPN em sua VPC a partir de uma rede externa ou [AWS Direct Connect](https://aws.amazon.com/directconnect/) para facilitar a criptografia do tráfego. Verifique se os seus clientes estão fazendo chamadas para APIs da AWS utilizando pelo menos TLS 1.2, pois a [AWS tornará obsoleto o uso de TLS 1.0 e 1.1 em junho de 2023](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Soluções de terceiros estão disponíveis no AWS Marketplace, caso você tenha requisitos especiais. 

 **Etapas da implementação** 
+  **Aplicar a criptografia em trânsito:** os requisitos de criptografia definidos devem se basear nos mais recentes padrões e práticas recomendadas e permitir apenas protocolos seguros. Por exemplo, configure apenas um grupo de segurança para permitir o protocolo HTTPS a um Application Load Balancer ou instância do Amazon EC2. 
+  **Configurar protocolos seguros em serviços de borda:** [configure o HTTPS com Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) e utilize um [perfil de segurança apropriado para seu procedimento de segurança e caso de uso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers). 
+  **Utilizar uma [VPN para conectividade externa](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html):** considere usar uma VPN IPsec para proteger conexões ponto a ponto ou rede a rede para fornecer privacidade e integridade dos dados. 
+  **Configurar protocolos seguros em balanceadores de carga:** selecione uma política de segurança que ofereça os pacotes de criptografia mais fortes compatíveis com os clientes que se conectarão ao receptor. [Criar um receptor de HTTPS para seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html). 
+  **Configurar protocolos seguros no Amazon Redshift:** configure o cluster para exigir uma [conexão Secure Socket Layer (SSL) ou Transport Layer Security (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html). 
+  **Configurar protocolos seguros:** leia a documentação do serviço da AWS para determinar os recursos de criptografia em trânsito. 
+  **Configurar o acesso seguro ao fazer upload para buckets do Amazon S3:** utilize controles de política de bucket do Amazon S3 para [implementar acesso seguro](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) aos dados. 
+  **Considerar o uso do [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** o ACM permite fornecer, gerenciar e implantar certificados TLS públicos para uso com serviços da AWS. 
+  **Considerar o uso do [Autoridade de Certificação Privada da AWS](https://aws.amazon.com/private-ca/) para necessidades de PKI privada:** o CA Privada da AWS permite criar hierarquias de autoridade de certificado privada (CA) para emitir certificados X.509 entidade final que podem ser usados para criar canais de TLS criptografados. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Documentação da AWS](https://docs.aws.amazon.com/index.html)
+ [ Utilizar HTTPS com o CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [ Conectar sua VPC a redes remotas usando a AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Criar um receptor de HTTPS para seu Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [ Tutorial: configurar o SSL/TLS no Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [Usar SSL/TLS para criptografar uma conexão com uma instância de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [ Configurar as opções de segurança para conexões ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)

# SEC09-BP03 Automatizar a detecção de acesso não intencional a dados
<a name="sec_protect_data_transit_auto_unintended_access"></a>

 Use ferramentas como o Amazon GuardDuty para detectar automaticamente atividades suspeitas ou tentativas de mover dados para fora dos limites definidos. Por exemplo, o GuardDuty pode detectar atividade de leitura do Amazon Simple Storage Service (Amazon S3) que é incomum com a descoberta [Exfiltration:S3/AnomalousBehavior](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#exfiltration-s3-objectreadunusual). Além do GuardDuty, [Logs de fluxo da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), que capturam informações de tráfego de rede, podem ser usados com o Amazon EventBridge para acionar a detecção de conexões anormais, bem-sucedidas e recusadas. [Amazon S3 Access Analyzer](http://aws.amazon.com/blogs/storage/protect-amazon-s3-buckets-using-access-analyzer-for-s3) pode ajudar a avaliar quais dados podem ser acessados por quem nos buckets do Amazon S3. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatizar a detecção de acesso não intencional a dados: use uma ferramenta ou um mecanismo de identificação para detectar automaticamente tentativas de mover dados fora dos limites definidos; por exemplo, para descobrir um sistema de banco de dados que esteja copiando dados para um host desconhecido. 
  + [ Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  Considerar o Amazon Macie: o Amazon Macie é um serviço de privacidade e segurança de dados totalmente gerenciado que usa machine learning e correspondência de padrões para descobrir e proteger seus dados sigilosos na AWS. 
  + [ Amazon Macie ](https://aws.amazon.com/macie/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+ [ Amazon Macie ](https://aws.amazon.com/macie/)

# SEC09-BP04 Autenticar as comunicações de rede
<a name="sec_protect_data_transit_authentication"></a>

 Verifique a identidade das comunicações usando protocolos que oferecem suporte à autenticação, como Transport Layer Security (TLS) ou IPsec. 

 Projete a workload para usar protocolos de rede seguros e autenticados sempre que for feita uma comunicação entre serviços, aplicações ou usuários. O uso de protocolos de rede compatíveis com a autenticação e a autorização fornece maior controle sobre os fluxos de rede e reduz o impacto do acesso não autorizado. 

 **Resultado desejado:** uma workload com fluxos de tráfego bem definidos do plano de dados e do ambiente de gerenciamento entre os serviços. Os fluxos de tráfego usam protocolos de rede autenticados e criptografados quando tecnicamente viáveis. 

 **Antipadrões comuns:** 
+  Fluxos de tráfego não criptografados ou não autenticados na workload. 
+  Reutilizar credenciais de autenticação entre vários usuários ou entidades. 
+  Confiar apenas nos controles de rede como um mecanismo de controle de acesso. 
+  Criar um mecanismo de autenticação personalizado em vez de depender de mecanismos de autenticação padrão do setor. 
+  Fluxos de tráfego excessivamente permissivos entre componentes de serviço ou outros recursos na VPC. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Limita o escopo do impacto do acesso não autorizado a uma parte da workload. 
+  Fornece um nível mais alto de garantia de que as ações são executadas somente por entidades autenticadas. 
+  Melhora o desacoplamento de serviços definindo e aplicando claramente as interfaces de transferência de dados pretendidas. 
+  Melhora o monitoramento, o log e a resposta a incidentes por meio da atribuição de solicitações e interfaces de comunicação bem definidas. 
+  Oferece defesa profunda para as workloads combinando controles de rede com controles de autenticação e de autorização. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os padrões de tráfego de rede da workload podem ser caracterizados em duas categorias: 
+  O *tráfego leste-oeste* representa fluxos de tráfego entre serviços que compõem uma workload. 
+  O *tráfego norte-sul* representa fluxos de tráfego entre a workload e os consumidores. 

 Embora seja uma prática comum criptografar o tráfego norte-sul, é menos comum proteger o tráfego leste-oeste usando protocolos autenticados. As práticas modernas de segurança recomendam que o design da rede por si só não conceda um relacionamento confiável entre duas entidades. Quando dois serviços puderem residir dentro de um limite de rede comum, criptografar, autenticar e autorizar as comunicações ainda são práticas recomendadas entre esses serviços. 

 Como exemplo, as APIs de serviços da AWS usam o protocolo de assinatura do [Signature Version 4 (SigV4) da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) para autenticar o chamador, independentemente da rede de origem da solicitação. Essa autenticação garante que as APIs da AWS possam verificar a identidade que solicitou a ação e que essa identidade possa ser combinada com políticas para tomar uma decisão de autorização a fim de determinar se a ação deve ser permitida ou não. 

 Serviços, como o [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) e o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) permitem usar o mesmo protocolo de assinatura SigV4 para adicionar autenticação e autorização ao tráfego leste-oeste em suas próprias workloads. Se os recursos fora do ambiente da AWS precisarem se comunicar com os serviços que exigem autenticação e autorização baseadas em SigV4, você poderá usar o [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) no recurso que não é da AWS para adquirir credenciais temporárias da AWS. Essas credenciais podem ser usadas para assinar solicitações para serviços que usam o SigV4 para autorizar o acesso. 

 Outro mecanismo comum para autenticar o tráfego leste-oeste é a autenticação mútua TLS (mTLS). Muitas aplicações da Internet das Coisas (IoT), aplicações business to business e microsserviços usam o mTLS para validar a identidade de ambos os lados de uma comunicação TLS por meio do uso de certificados X.509 do lado do cliente e do servidor. Esses certificados podem ser emitidos por Autoridade de Certificação Privada da AWS (CA Privada da AWS). É possível usar serviços como o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) e o [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) para fornecer autenticação mTLS para comunicação entre workloads ou dentro da workload. Embora o mTLS forneça informações de autenticação aos dois lados de uma comunicação TLS, ele não fornece um mecanismo de autorização. 

 Por fim, o OAuth 2.0 e o OpenID Connect (OIDC) são dois protocolos normalmente usados para controlar o acesso aos serviços pelos usuários, mas agora também estão se tornando populares para o tráfego entre serviços. O API Gateway fornece um [autorizador JSON Web Token (JWT)](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html), que permite que as workloads restrinjam o acesso às rotas de API usando JWTs emitidos por provedores de identidades OIDC ou OAuth 2.0. Os escopos do OAuth2 podem ser usados como uma fonte para decisões básicas de autorização, mas as verificações de autorização ainda precisam ser implementadas na camada da aplicação, e os escopos do OAuth2 por si sós não atendem a necessidades de autorização mais complexas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Definir e documentar os fluxos de rede da workload:** a primeira etapa na implementação de uma estratégia de defesa profunda é definir os fluxos de tráfego da workload. 
  +  Crie um diagrama de fluxo de dados que defina claramente como os dados são transmitidos entre os diferentes serviços que compõem a workload. Esse diagrama é a primeira etapa para aplicar esses fluxos por meio de canais de rede autenticados. 
  +  Instrumente a workload nas fases de desenvolvimento e testes para validar se o diagrama de fluxo de dados reflete com precisão o comportamento da workload em tempo de execução. 
  +  Um diagrama de fluxo de dados também pode ser útil ao realizar um exercício de modelagem de ameaças, conforme descrito em [SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html). 
+  **Estabeleça controles de rede:** considere os recursos da AWS para estabelecer controles de rede alinhados aos fluxos de dados. Embora os limites da rede não devam ser o único controle de segurança, eles fornecem uma camada na estratégia de defesa profunda para proteger a workload. 
  +  Use [grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html) para estabelecer, definir e restringir fluxos de dados entre recursos. 
  +  Considere usar o [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) para se comunicar com os serviços da AWS e de terceiros que são compatíveis com o AWS PrivateLink. Os dados enviados por meio de um endpoint da interface do AWS PrivateLink permanecem na estrutura da rede da AWS e não atravessam a internet pública. 
+  **Implementar autenticação e autorização entre os serviços na workload:** escolha o conjunto de serviços da AWS mais apropriado para fornecer fluxos de tráfego autenticados e criptografados na workload. 
  +  Considere o [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) para proteger a comunicação entre serviços. O VPC Lattice pode usar a [autenticação do SigV4 combinada com políticas de autenticação](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) para controlar o acesso entre serviços. 
  +  Para comunicação entre serviços usando mTLS, considere o [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) ou o [App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html). O [CA Privada da AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) pode ser usado para estabelecer uma hierarquia de CA privada capaz de emitir certificados para uso com o mTLS. 
  +  Ao fazer a integração com serviços que usam OAuth 2.0 ou OIDC, considere o [API Gateway usando o autorizador JWT](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html). 
  +  Para comunicação entre a workload e dispositivos de IoT, considere o [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html), que fornece várias opções para criptografia e autenticação de tráfego de rede. 
+  **Monitorar o acesso não autorizado:** monitore continuamente os canais de comunicação não intencionais, entidades principais não autorizadas que tentam acessar recursos protegidos e outros padrões de acesso inadequados. 
  +  Se estiver usando o VPC Lattice para gerenciar o acesso aos serviços, considere ativar e monitorar os [logs de acesso do VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html). Esses logs de acesso incluem informações sobre a entidade solicitante, informações de rede que incluem a VPC de origem e de destino e os metadados da solicitação. 
  +  Considere a ativação dos [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) para capturar metadados nos fluxos de rede e analisar se há anomalias periodicamente. 
  +  Consulte o [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) e a seção [Resposta a incidentes ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) do Pilar Segurança: AWS Well-Architected Framework para obter mais orientações sobre planejamento, simulação e resposta a incidentes de segurança. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [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)
+ [SEC02-BP02 Usar credenciais temporárias](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)

 **Documentos relacionados:** 
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ Configurar a autenticação TLS mútua para uma API REST ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [ Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)

 **Vídeos relacionados:** 
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)

 **Exemplos relacionados:** 
+ [ Workshop do Amazon VPC Lattice ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [Workshop Zero-Trust Episode 1 – The Phantom Service Perimeter](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)

# Resposta a incidentes
<a name="a-incident-response"></a>

**Topics**
+ [SEGURANÇA 10. Como prever, responder e se recuperar de incidentes?](sec-10.md)

# SEGURANÇA 10. Como prever, responder e se recuperar de incidentes?
<a name="sec-10"></a>

 Mesmo com controles preventivos e de detecção consolidados, sua organização deve implementar processos para responder e reduzir o impacto potencial de incidentes de segurança. Sua preparação afeta muito a capacidade das equipes operarem efetivamente durante um incidente, isolarem, conterem e analisarem problemas e restaurarem as operações para um estado adequado conhecido. Implementar as ferramentas e o acesso antes de um incidente de segurança e praticar rotineiramente dias de jogos para validar a resposta a incidentes ajuda a garantir que você possa se recuperar enquanto minimiza interrupções empresariais. 

**Topics**
+ [SEC10-BP01 Identify key personnel and external resources](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Desenvolver planos de gerenciamento de incidentes](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Prepare recursos forenses](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Desenvolva e teste manuais de resposta a incidentes de segurança](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Acesso pré-provisionado](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Pré-implantação de ferramentas](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Execute simulações](sec_incident_response_run_game_days.md)
+ [SEC10-BP08 Estabeleça uma estrutura para aprender com os incidentes](sec_incident_response_establish_incident_framework.md)

# SEC10-BP01 Identify key personnel and external resources
<a name="sec_incident_response_identify_personnel"></a>

 Identifique o pessoal, as obrigações legais e os recursos internos e externos que ajudariam sua organização a responder a um incidente. 

Para definir sua abordagem de resposta a incidentes na nuvem, com a participação de outras equipes (como consultoria jurídica, liderança, partes interessadas de negócios, serviços do AWS Support e outras), você deve identificar as principais partes interessadas, pessoal e contatos relevantes. Para reduzir a dependência e diminuir o tempo de resposta, certifique-se de que sua equipe, equipes de segurança especializadas e respondentes sejam instruídos sobre os serviços que você usa e tenham a oportunidade de praticar.

É recomendável identificar parceiros externos de segurança da AWS que possam fornecer experiência externa e uma perspectiva diferente para aumentar seus recursos de resposta. Os parceiros de segurança confiáveis podem ajudá-lo a identificar possíveis riscos ou ameaças com os quais você talvez não esteja familiarizado.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>
+  **Identificar o pessoal-chave da organização:** Mantenha uma lista de contatos da sua organização que você precisaria acionar para responder e recuperar-se de um incidente. 
+  **Identificar parceiros externos:** Entre em contato com parceiros externos, se necessário, que possam ajudá-lo a responder e se recuperar de um incidente. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Incident Response Guide (Guia de resposta a incidentes da AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **Vídeos relacionados:** 
+  [Prepare for and respond to security incidents in your AWS environment (Prepare-se e responda a incidentes de segurança no ambiente da AWS) ](https://youtu.be/8uiO0Z5meCs)

 **Exemplos relacionados:** 

# SEC10-BP02 Desenvolver planos de gerenciamento de incidentes
<a name="sec_incident_response_develop_management_plans"></a>

O primeiro documento a ser desenvolvido para resposta a incidentes é o plano de resposta a incidentes. O plano de resposta a incidentes foi projetado para ser a base de seu programa e estratégia de resposta a incidentes. 

 **Benefícios de estabelecer esta prática recomendada:** O desenvolvimento de processos de resposta a incidentes completos e claramente definidos é fundamental para um programa de resposta a incidentes bem-sucedido e escalável. Quando ocorre um evento de segurança, etapas e fluxos de trabalho claros poderão ajudar você a responder em tempo hábil. Talvez você já tenha processos de resposta a incidentes existentes. Independentemente do seu estado atual, é importante atualizar, repetir e testar seus processos de resposta a incidentes regularmente. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

Um plano de gerenciamento de incidentes é fundamental para responder, mitigar e se recuperar de possíveis impactos de incidentes de segurança. Um plano de gerenciamento de incidentes é um processo estruturado de identificação, correção e resposta em tempo hábil a incidentes de segurança.

 A nuvem tem muitos dos mesmos requisitos e perfis operacionais encontrados em um ambiente on-premises. Ao criar um plano de gerenciamento de incidentes, é importante definir estratégias de resposta e recuperação que se alinhem melhor aos seus resultados empresariais e requisitos de conformidade. Por exemplo, se você opera workloads na AWS em conformidade com o FedRAMP nos Estados Unidos, é útil aderir ao [Guia de tratamento de segurança de computadores NIST SP 800-61](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Da mesma forma, ao operar workloads com informações de identificação pessoal (PII) da Europa, considere cenários como a maneira como você deve se proteger e responder a incidentes relacionados à residência de dados, conforme exigido pela [Regulamentação Geral de Proteção de Dados (GDPR) da UE](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en). 

 Ao criar um plano de gerenciamento de incidentes para suas workloads na AWS, comece com o [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) , para elaborar uma abordagem de defesa profunda em relação à resposta a incidentes. Nesse modelo, a AWS gerencia a segurança da nuvem, e você é responsável pela segurança na nuvem. Isso significa que você mantém o controle e é responsável pelos controles de segurança que escolhe implementar. O [AWS Security Incident Response Guide (Guia de resposta a incidentes de segurança da AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) detalha os conceitos e as orientações básicas para criar um plano de gerenciamento de incidentes centrado na nuvem.

 Um plano de gerenciamento de incidentes eficaz deve ser continuamente iterado e permanecer atualizado com relação às suas metas de operações de nuvem. Considere o uso dos planos de implementação detalhados abaixo, à medida que cria e evolui seu plano de gerenciamento de incidentes. 

## Etapas da implementação
<a name="implementation-steps"></a>

 **Defina funções e responsabilidades** 

 Lidar com eventos de segurança exige disciplina interorganizacional e uma inclinação para a ação. Em sua estrutura organizacional, deve haver muitas pessoas responsáveis, atribuídas, consultadas ou mantidas informadas durante um incidente, como representantes de recursos humanos (RH), da equipe executiva e do setor jurídico. Considere essas funções e responsabilidades e se algum terceiro deve estar envolvido. Observe que muitas regiões têm leis locais que regem o que deve e o que não deve ser feito. Embora possa parecer burocrático criar um grafo de pessoas responsáveis, atribuídas, consultadas e informadas (RACI) para seus planos de resposta de segurança, isso facilita a comunicação rápida e direta e descreve claramente a liderança em diferentes estágios do evento. 

 Durante um incidente, incluir os proprietários e os desenvolvedores de aplicações e recursos afetados é fundamental porque eles são especialistas no assunto (PMEs) que podem fornecer informações e contexto para ajudar a medir o impacto. Pratique e construa relacionamentos com os desenvolvedores e os proprietários de aplicações antes de confiar na experiência deles para responder a incidentes. Proprietários de aplicações ou PMEs, como administradores ou engenheiros de nuvem, podem precisar agir em situações em que o ambiente não seja familiar ou tenha complexidade, ou em que os respondentes não tenham acesso. 

 Por fim, parceiros confiáveis podem estar envolvidos na investigação ou na resposta, pois podem oferecer experiência adicional e um controle valioso. Se você não tiver essas habilidades em sua própria equipe, contrate uma parte externa para obter assistência. 

 **Entender as equipes de resposta e o suporte da AWS** 
+  **AWS Support** 
  +  [O Suporte](https://aws.amazon.com/premiumsupport/) oferece uma variedade de planos que concedem acesso a ferramentas e conhecimentos que apoiam o êxito e a saúde operacional de suas soluções da AWS. Se precisar de suporte técnico e mais recursos para ajudar a planejar, implantar e otimizar seu ambiente da AWS, selecione um plano de suporte mais adequado ao seu caso de uso da AWS. 
  +  Considere o [Support Center](https://console.aws.amazon.com/support) entre Console de gerenciamento da AWS (é necessário fazer login) como ponto central de contato para obter suporte para problemas que afetam seus recursos da AWS. O acesso ao Suporte é controlado pelo AWS Identity and Access Management. Para ter mais informações sobre como obter acesso aos recursos da Suporte, consulte [Conceitos básicos do Suporte](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support). 
+  **Equipe de Resposta a Incidentes de Clientes (CIRT) da AWS** 
  +  A Equipe de Resposta a Incidentes de Clientes (CIRT) da AWS é uma equipe global da AWS especializada 24 horas por dia, 7 dias por semana, que presta assistência aos clientes durante eventos de segurança ativos do cliente do [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/). 
  +  Ao apoiar você, a AWS CIRT presta assistência na triagem e na recuperação de um evento de segurança ativo na AWS. Eles podem ajudar na análise da causa raiz por meio do uso de logs de serviço da AWS e fornecer recomendações para recuperação. Eles também podem fornecer recomendações de segurança e práticas recomendadas para ajudar você a evitar eventos de segurança no futuro. 
  +  Os clientes da AWS podem contratar a AWS CIRT por meio de um [caso do Suporte](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html). 
+  **Suporte de resposta a DDoS** 
  +  A AWS oferece o [AWS Shield](https://aws.amazon.com/shield/), que fornece um serviço gerenciado de proteção distribuída de negação de serviço (DDoS) que protege as aplicações web em execução na AWS. O Shield oferece detecção contínua e mitigações automáticas em linha que podem minimizar o tempo de inatividade e a latência da aplicação, portanto, não há necessidade de contratar o Suporte para se beneficiar da proteção contra DDoS. Existem dois níveis de Shield: AWS Shield Standard e AWS Shield Advanced. Para saber mais sobre as diferenças entre esses dois níveis, consulte a [documentação de recursos do Shield](https://aws.amazon.com/shield/features/). 
+  **AWS Managed Services (AMS)** 
  +  [O AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) oferece gerenciamento contínuo de sua infraestrutura da AWS para que você possa se concentrar em suas aplicações. Ao implementar as práticas recomendadas para manter sua infraestrutura, o AMS ajuda a reduzir sua sobrecarga operacional e os riscos. O AMS automatiza atividades comuns, como solicitações de mudança, monitoramento, gerenciamento de patches, serviços de segurança e backup, e fornece serviços de ciclo de vida completo para provisionar, executar e oferecer compatibilidade com sua infraestrutura. 
  +  O AMS assume a responsabilidade de implantar um pacote de controles de detecção de segurança e fornece uma primeira linha de resposta aos alertas 24 horas por dia, 7 dias por semana. Quando um alerta é iniciado, o AMS segue um conjunto padrão de guias e manuais automatizados para verificar uma resposta consistente. Esses guias são compartilhados com os clientes do AMS durante a integração para que eles possam desenvolver e coordenar uma resposta com o AMS. 

 **Desenvolva o plano de resposta a incidentes** 

 O plano de resposta a incidentes foi projetado para ser a base de seu programa e estratégia de resposta a incidentes. O plano de resposta a incidentes deve estar em um documento formal. Um plano de resposta a incidentes geralmente inclui as seguintes seções: 
+  **Uma visão geral da equipe de resposta a incidentes:** Descreve as metas e as funções da equipe de resposta a incidentes. 
+  **Funções e responsabilidades:** Lista as partes interessadas na resposta a incidentes e detalha suas funções quando ocorre um incidente. 
+  **Um plano de comunicação:** Detalha as informações de contato e como você se comunica durante um incidente. 
+  **Métodos de comunicação de backup:** É prática recomendada ter a comunicação fora de banda como backup para a comunicação de incidentes. Um exemplo de aplicação que fornece um canal seguro de comunicação fora de banda é AWS Wickr. 
+  **Fases da resposta a incidentes e ações a serem realizadas:** Enumera as fases da resposta a incidentes (por exemplo, detectar, analisar, erradicar, conter e recuperar), incluindo ações de alto nível a serem realizadas nessas fases. 
+  **Definições de severidade e priorização do incidente:** Detalha como classificar a severidade de um incidente, como priorizar o incidente e, depois, como as definições de severidade afetam os procedimentos de escalonamento. 

 Embora essas seções sejam comuns em empresas de diferentes tamanhos e setores, o plano de resposta a incidentes de cada organização é único. Você precisa criar um plano de resposta a incidentes que funcione melhor para a organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC04 (Como você detecta e investiga eventos de segurança?)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) 

 **Documentos relacionados:** 
+  [AWS Security Incident Response Guide (Guia de resposta a incidentes de segurança da AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: Guia de tratamento de incidentes de segurança de computadores ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

# SEC10-BP03 Prepare recursos forenses
<a name="sec_incident_response_prepare_forensic"></a>

Antes de um incidente de segurança, considere o desenvolvimento de recursos forenses para apoiar as investigações de eventos de segurança. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

 Os conceitos da análise forense on-premises tradicional se aplicam à AWS. Para obter informações importantes para começar a desenvolver recursos forenses na Nuvem AWS, consulte [Forensic investigation environment strategies in the Nuvem AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/). 

 Depois de configurar o ambiente e a estrutura da Conta da AWS para análise forense, defina as tecnologias necessárias para executar com eficácia metodologias forenses sólidas nas quatro fases: 
+  **Coleta:** Colete logs relevantes da AWS, como logs do AWS CloudTrail, do AWS Config, logs de fluxo da VPC e log em nível de host. Colete snapshots, backups e despejos de memória dos recursos afetados da AWS, quando disponíveis. 
+  **Exame:** Examine os dados coletados extraindo e avaliando as informações relevantes. 
+  **Análises:** Analise os dados coletados para entender o incidente e tirar conclusões dele. 
+  **Relatórios:** Apresente as informações resultantes da fase de análise. 

## Etapas da implementação
<a name="implementation-steps"></a>

 **Prepare o ambiente forense** 

 [AWS Organizations](https://aws.amazon.com/organizations/) ajuda a gerenciar e reger centralmente um ambiente da AWS à medida que você expande e escala os recursos da AWS. Uma organização da AWS consolida suas Contas da AWS para que você possa administrá-las como uma única unidade. Você pode usar unidades organizacionais (UOs) para agrupar contas e administrá-las como uma única unidade. 

 Para resposta a incidentes, é útil ter uma estrutura da Conta da AWS compatível com as funções de resposta a incidentes, que inclui uma *UO de segurança* e uma *UO forense*. Dentro da OU de segurança, você deve ter contas para: 
+  **Arquivamento de logs:** Agregue logs em uma Conta da AWS de arquivamento de logs com permissões limitadas. 
+  **Ferramentas de segurança:** Centralize os serviços de segurança em uma Conta da AWS de ferramenta de segurança. Essa conta opera como administrador delegado dos serviços de segurança. 

 Dentro da UO forense, você tem a opção de implementar uma única conta ou contas forenses para cada região em que opera, dependendo da que funciona melhor para sua empresa e modelo operacional. Se você criar uma conta forense por região, poderá bloquear a criação de recursos da AWS fora dessa região e reduzir o risco de os recursos serem copiados para uma região não pretendida. Por exemplo, se você opera apenas em US East (N. Virginia) Region (`us-east-1`) e US West (Oregon) (`us-west-2`), então você teria duas contas na UO forense: uma para `us-east-1` e uma para `us-west-2`. 

 Você pode criar uma Conta da AWS de análise forense para várias regiões. Você deve ter cuidado ao copiar recursos da AWS para essa conta para verificar se está de acordo com seus requisitos de soberania de dados. Como é preciso tempo para provisionar novas contas, é imperativo criar e instrumentar as contas forenses bem antes de um incidente, para que os respondentes possam estar preparados para usá-las de forma eficaz em suas respostas. 

 O diagrama a seguir exibe um exemplo de estrutura de contas, incluindo uma UO forense com contas forenses por região: 

![\[Diagrama de fluxo mostrando uma estrutura de contas por região para resposta a incidentes, bifurcada em uma UO forense e de segurança.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/region-account-structure.png)


 **Capture backups e snapshots** 

 Configurar backups dos principais sistemas e bancos de dados é essencial para a recuperação de um incidente de segurança e para fins forenses. Com os backups em vigor, você pode restaurar seus sistemas ao estado seguro anterior. Na AWS, você pode criar snapshots de vários recursos. Os snapshots fornecem backups pontuais desses recursos. Há muitos serviços da AWS que podem ajudar em backup e recuperação. Para obter detalhes sobre esses serviços e abordagens para backup e recuperação, consulte [Backup and Recovery Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) e [Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/). 

 Especialmente quando se trata de situações como ransomware, é fundamental que os backups estejam bem protegidos. Para obter orientações sobre como proteger os backups, consulte [Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Além de proteger os backups, você deve testar regularmente seus processos de backup e restauração para verificar se a tecnologia e os processos implementados funcionam conforme o esperado. 

 **Automatize a análise forense** 

 Durante um evento de segurança, sua equipe de resposta a incidentes deve ser capaz de coletar e analisar evidências rapidamente, mantendo a precisão durante o período em torno do evento (como capturar registros relacionados a um evento ou recurso específico ou coletar o despejo de memória de uma instância do Amazon EC2). É desafiador e demorado para a equipe de resposta a incidentes coletar manualmente as evidências relevantes, especialmente em um grande número de instâncias e contas. Além disso, a coleta manual pode estar sujeita a erros humanos. Por esses motivos, você deve desenvolver e implementar a automação para perícia o máximo possível. 

 A AWS oferece vários recursos de automação para análise forense, que estão listados na seção de recursos a seguir. Esses recursos são exemplos de padrões forenses que desenvolvemos e que os clientes implementaram. Embora possam ser uma arquitetura de referência útil para começar, considere modificá-las ou criar padrões de automação forense com base em seu ambiente, requisitos, ferramentas e processos forenses. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Security Incident Response Guide - Develop Forensics Capabilities ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS Security Incident Response Guide - Forensics Resources ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Forensic investigation environment strategies in the Nuvem AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+  [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 
+ [AWS Prescriptive Guidance - Automate incident response and forensics ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)

 **Vídeos relacionados:** 
+ [ Automatização de resposta a incidentes e forense ](https://www.youtube.com/watch?v=f_EcwmmXkXk)

 **Exemplos relacionados:** 
+ [ Automated Incident Response and Forensics Framework (Estrutura forense e de resposta automatizada a incidentes) ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Automated Forensics Orchestrator for Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)

# SEC10-BP04 Desenvolva e teste manuais de resposta a incidentes de segurança
<a name="sec_incident_response_playbooks"></a>

 Uma parte fundamental da preparação de seus processos de resposta a incidentes é desenvolver manuais. Os manuais de resposta a incidentes fornecem uma série de orientações prescritivas e etapas a serem seguidas quando ocorre um evento de segurança. Ter uma estrutura e etapas claras simplifica a resposta e reduz a probabilidade de erro humano. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os manuais devem ser criados para cenários de incidentes, como: 
+  **Incidentes esperados**: os manuais devem ser criados para os incidentes previstos. Isso inclui ameaças como negação de serviço (DoS), ransomware e comprometimento de credenciais. 
+  **Descobertas ou alertas de segurança conhecidos**: os manuais devem ser criados para descobertas e alertas de segurança conhecidos, como descobertas do GuardDuty. Você pode receber uma descoberta do GuardDuty e pensar: “E agora?” Para evitar que você trate incorretamente ou ignore uma descoberta do GuardDuty, crie um manual para cada possível descoberta do GuardDuty. Alguns detalhes e orientações sobre a correção podem ser encontrados na [documentação do GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). É importante notar que o GuardDuty não está habilitado por padrão e tem um custo. Para obter mais detalhes sobre o GuardDuty, consulte [Appendix A: Cloud capability definitions - Visibility and alerting](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/visibility-and-alerting.html). 

 Os manuais devem conter etapas técnicas a serem concluídas por um analista de segurança para investigar e responder adequadamente a um possível incidente de segurança. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Os itens a serem incluídos em um manual incluem: 
+  **Visão geral do manual**: qual cenário de risco ou incidente esse manual aborda? Qual é o objetivo do manual? 
+  **Pré-requisitos**: quais logs, mecanismos de detecção e ferramentas automatizadas são necessários para esse cenário de incidente? Qual é a notificação esperada? 
+  **Informações de comunicação e escalonamento**: quem está envolvido e quais são suas informações de contato? Quais são as responsabilidades de cada parte interessada? 
+  **Etapas de resposta**: em todas as fases da resposta a incidentes, quais etapas táticas devem ser seguidas? Quais consultas um analista deve executar? Qual código deve ser executado para alcançar o resultado desejado? 
  +  **Detectar**: como o incidente será detectado? 
  +  **Análise**: como o escopo do impacto será determinado? 
  +  **Contêm**: como o incidente será isolado para limitar o escopo? 
  +  **Erradicar**: como a ameaça será removida do ambiente? 
  +  **Recuperar**: como o sistema ou o recurso afetado voltará à produção? 
+  **Resultados esperados**: depois que as consultas e o código forem executados, qual é o resultado esperado do manual? 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC10-BP02 - Develop incident management plans (SEC10-BP02 – Desenvolver planos de gerenciamento de incidentes)](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) 

 **Documentos relacionados:** 
+  [Framework for Incident Response Playbooks (Estrutura para manuais de resposta a incidentes)](https://github.com/aws-samples/aws-customer-playbook-framework)  
+  [Develop your own Incident Response Playbooks (Desenvolva seus próprios manuais de resposta a incidentes)](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)  
+  [Incident Response Playbook Samples (Amostras do manual de resposta a incidentes)](https://github.com/aws-samples/aws-incident-response-playbooks)  
+  [Building an AWS incident response runbook using Jupyter playbooks and CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)  

 

# SEC10-BP05 Acesso pré-provisionado
<a name="sec_incident_response_pre_provision_access"></a>

Verifique se os respondentes a incidentes têm o acesso correto pré-provisionado na AWS para reduzir o tempo de investigação necessário até a recuperação.

 **Antipadrões comuns:** 
+  Uso da conta raiz para a resposta a incidentes. 
+  Alteração de contas de usuário existentes. 
+  Manipulação de permissões do IAM diretamente ao fornecer elevação de privilégios just-in-time. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

A AWS recomenda reduzir ou eliminar a dependência de credenciais de longa duração sempre que possível, dando preferência a credenciais temporárias e *a mecanismos de escalação de privilégios* just-in-time. As credenciais de longa duração são propensas a riscos de segurança e aumentam a sobrecarga operacional. Para a maioria das tarefas de gerenciamento, bem como tarefas de resposta a incidentes, recomendamos a implementação da [federação de identidades](https://docs.aws.amazon.com/identity/federation/) junto com a [escalação temporária para acesso administrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). Nesse modelo, um usuário solicita elevação a um nível superior de privilégio (como um perfil de resposta a incidentes) e, considerando que ele seja elegível para a elevação, a solicitação é enviada a um aprovador. Se a solicitação for aprovada, o usuário receberá um conjunto de credenciais [temporárias da AWS,](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) que podem ser usadas para concluir suas tarefas. Depois que essas credenciais expirarem, o usuário deve enviar uma nova solicitação de elevação.

 Recomendamos o uso da escalação de privilégio temporária para a maioria dos cenários de resposta a incidentes. A maneira correta de fazer isso é com o uso do [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [de políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) para definir o escopo de acesso. 

 Há cenários em que as identidades federadas não estão disponíveis, como: 
+  Interrupção relacionada a um provedor de identidades (IdP) comprometido. 
+  Erro de configuração ou erro humano causando uma falha no sistema de gerenciamento de acesso federado. 
+  Atividade mal-intencionada, como um evento de negação de serviço distribuído (DDoS) ou indisponibilidade de renderização do sistema. 

 Nos casos anteriores, deverá haver um acesso de emergência de *breaking-glass* configurado para permitir a investigação e a correção em tempo hábil dos incidentes. Recomendamos a utilização de um [usuário do IAM com as permissões apropriadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) para realizar tarefas e acessar os recursos da AWS. Use as credenciais raiz somente para [tarefas que exijam o acesso do usuário raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Para verificar se os respondentes de um incidente têm o nível de acesso correto à AWS e a outros sistemas relevantes, recomendamos o pré-provisionamento de contas de usuário dedicadas. As contas de usuário exigem acesso privilegiado e devem ser estritamente controladas e monitoradas. As contas devem ser criadas com os menores privilégios exigidos para realizar as tarefas necessárias, e o nível de acesso deve ser baseado nos manuais criados como parte do plano de gerenciamento de incidentes. 

 Utilize perfis e usuários dedicados e com propósito específico como uma prática recomendada. Escalar temporariamente o acesso de usuários ou perfis por meio da adição de políticas do IAM não deixa claro qual é o acesso que os usuários tinham durante o incidente, e há um risco de que os privilégios escalados não sejam revogados. 

 É importante remover o máximo de dependências possível para verificar se o acesso pode ser obtido com o maior número possível de cenários de falha. Para apoiar isso, crie um manual para verificar se os usuários de resposta a incidentes são criados como usuários do AWS Identity and Access Management em uma conta de segurança dedicada, e não são gerenciados por nenhuma solução de autenticação única (SSO) ou federação. Cada respondente individual deve ter sua própria conta nomeada. A configuração da conta deve aplicar uma [política de senha forte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) e a autenticação multifator (MFA). Se os manuais de resposta a incidentes só exigem acesso ao Console de gerenciamento da AWS, o usuário não deve ter chaves de acesso configuradas e deve ser proibido explicitamente de criar chaves de acesso. Isso pode ser configurado com políticas do IAM ou políticas de controle de serviços (SCPs), conforme mencionado nas Práticas recomendadas de segurança da AWS para [SCPs do AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Os usuários não devem ter privilégios além da capacidade de assumir perfis de resposta a incidentes em outras contas. 

 Durante um incidente, pode ser necessário conceder acesso a outros indivíduos internos ou externos para apoiar a investigação, a correção ou as atividades de recuperação. Nesse caso, use o mecanismo do manual mencionado anteriormente, e deve haver um processo para verificar se qualquer acesso adicional foi revogado imediatamente após a conclusão do incidente. 

 Para verificar se o uso de perfis de resposta a incidentes pode ser monitorado e auditado corretamente, é essencial que as contas de usuário do IAM criadas para esse fim não sejam compartilhadas entre indivíduos e que o usuário raiz da Conta da AWS não seja utilizado, a menos que isso seja [exigido para uma tarefa específica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Se o usuário raiz for exigido (por exemplo, quando o acesso do IAM a uma conta específica estiver indisponível), use um processo distinto com um manual disponível para verificar a disponibilidade da senha e do token de MFA do usuário raiz. 

 Para configurar as políticas do IAM para os perfis de resposta a incidentes, considere o uso do [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) para gerar políticas baseadas em logs do AWS CloudTrail. Para fazer isso, conceda acesso de administrador ao perfil de resposta a incidentes em uma conta de não produção e execute de acordo com os manuais. Depois da conclusão, pode ser criada uma política que permita somente as ações realizadas. Essa política pode ser então aplicada a todos os perfis de resposta a incidentes em todas as contas. Você pode criar uma política do IAM separada para cada manual a fim de facilitar o gerenciamento e a auditoria. Exemplos de manuais podem incluir planos de resposta para ransomware, violações de dados, perda de acesso da produção, dentre outros cenários. 

 Use as contas de usuário de resposta a incidentes para assumir funções do [IAM de resposta a incidentes em outras Contas da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Esses perfis também devem ser configurados para só poderem ser assumidos por usuários na conta de segurança, e o relacionamento de confiança deve exigir que a entidade principal que está fazendo a chamada seja autenticada com MFA. Os perfis devem usar políticas do IAM com escopo estritamente definido para controlar o acesso. Garanta que todas as solicitações `AssumeRole` para esses perfis estejam conectadas no CloudTrail e sejam alertadas, e que as ações realizadas usando esses perfis sejam registradas. 

 É altamente recomendável que as contas de usuário do IAM e os perfis do IAM sejam claramente nomeados para permitir que sejam encontrados com facilidade nos logs do CloudTrail. Um exemplo disso seria nomear as contas do IAM como `<USER_ID>-BREAK-GLASS` e os perfis do IAM como `BREAK-GLASS-ROLE`. 

 [O CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) é usado para registrar as atividades da API em suas contas da AWS e deve ser usado para [configurar alertas sobre o uso dos perfis de resposta a incidentes](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Consulte a publicação do blog sobre como configurar alertas quando as chaves raiz são usadas. As instruções podem ser modificadas para configurar a métrica do [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) filtro a filtro em eventos `AssumeRole` relacionados ao perfil do IAM de resposta a incidentes: 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 Como é provável que os perfis de resposta a incidentes tenham um alto nível de acesso, é importante que esses alertas sejam transmitidos a um grande grupo e que sejam tomadas atitudes rapidamente. 

 Durante um incidente, é possível que um respondente possa exigir acesso a sistemas que não são protegidos diretamente pelo IAM. Isso pode incluir instâncias do Amazon Elastic Compute Cloud, bancos de dados do Amazon Relational Database Service ou plataformas de software como serviço (SaaS). É altamente recomendável que, em vez de usar protocolos nativos, como SSH ou RDP, o [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) seja usado para todo acesso administrativo a instâncias do Amazon EC2. Esse acesso pode ser controlado usando o IAM, que é protegido e auditado. Também pode ser possível automatizar partes de seus manuais usando os documentos do [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), o que pode reduzir os erros do usuário e melhorar o tempo de recuperação. Para acesso aos bancos de dados e a ferramentas de terceiros, recomendamos armazenar as credenciais de acesso no AWS Secrets Manager e conceder acesso aos perfis de respondente a incidentes. 

 Por fim, o gerenciamento das contas de usuário do IAM de resposta a incidentes deve ser adicionado aos seus processos de [junção, migração e saída,](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) além de ser revisado e testado periodicamente visando confirmar se somente o acesso pretendido é permitido. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Managing temporary elevated access to your AWS environment (Gerenciamento de acesso elevado temporário ao seu ambiente da AWS)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS Security Incident Response Guide (Guia de resposta a incidentes de segurança da AWS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [Recuperação de desastres do AWS Elastic](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [Setting an account password policy for IAM users (Definição de uma política de senhas de contas para usuários do IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [Using multi-factor authentication (MFA) in AWS (Uso da autenticação multifator (MFA) na AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ Configuring Cross-Account Access with MFA (Configuração do acesso entre contas com MFA) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (Uso do IAM Access Analyzer para gerar políticas do IAM) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (Práticas recomendadas para políticas de controle de serviço do AWS Organizations em um ambiente de várias contas) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (Como receber notificações quando as chaves de acesso raiz da sua conta da AWS são usadas) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies (Criar permissões de sessão refinadas usando políticas gerenciadas pelo IAM) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **Vídeos relacionados:** 
+ [ Automating Incident Response and Forensics in AWS (Automação de resposta a incidentes e investigações forenses na AWS) ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [Guia DIY (faça você mesmo) para runbooks, relatórios de incidentes e resposta a incidentes](https://youtu.be/E1NaYN_fJUo) 
+ [ Prepare for and respond to security incidents in your AWS environment (Prepare-se e responda a incidentes de segurança no ambiente da AWS) ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **Exemplos relacionados:** 
+ [ Lab: AWS Account Setup and Root User (Laboratório: usuário raiz e configuração de conta da AWS) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Lab: Incident Response with AWS Console and CLI (Laboratório: resposta a incidentes com o console e a CLI da AWS) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 Pré-implantação de ferramentas
<a name="sec_incident_response_pre_deploy_tools"></a>

Verifique se o pessoal de segurança tem as ferramentas certas pré-implantadas para reduzir o tempo de investigação até a recuperação.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para automatizar as funções de resposta e operações de segurança, você pode usar um conjunto abrangente de APIs e ferramentas da AWS. Você pode automatizar totalmente os recursos de gerenciamento de identidade, segurança de rede, proteção de dados e monitoramento e disponibilizá-los com métodos populares de desenvolvimento de software já em vigor. Quando você cria a automação da segurança, seu sistema pode monitorar, analisar e iniciar uma resposta, em vez de fazer com que as pessoas monitorem a sua posição de segurança e reajam manualmente a eventos. 

 Se as equipes de resposta a incidentes continuarem a responder aos alertas da mesma forma, há o risco de se acostumarem aos alertas. Com o passar do tempo, a equipe pode se tornar dessensibilizada para alertas e cometer erros ao lidar com situações comuns ou perder alertas incomuns. A automação ajuda a evitar a exaustão de alertas usando funções que processam alertas repetitivos e comuns, permitindo que as pessoas lidem com incidentes confidenciais e exclusivos. A integração de sistemas de detecção de anomalias, como Amazon GuardDuty, AWS CloudTrail Insights e Amazon CloudWatch Anomaly Detection, pode reduzir a carga de alertas baseados em limites comuns. 

 Você pode melhorar os processos manuais com a automatização programática das etapas do processo. Depois de definir o padrão de correção para um evento, você pode decompor esse padrão em lógica acionável e desenvolver o código para executar essa lógica. Os respondentes podem executar esse código para corrigir o problema. Com o passar do tempo, você pode automatizar mais e mais etapas e, por fim, lidar automaticamente com classes inteiras de incidentes comuns. 

 Durante uma investigação de segurança, você precisa ser capaz de analisar os logs relevantes para registrar e compreender o escopo completo e o cronograma do incidente. Os logs também são necessários para geração de alertas indicando que ocorreram determinadas ações de interesse. É essencial selecionar, ativar, armazenar e configurar mecanismos de consulta, recuperação e definir alertas. Além disso, uma forma eficaz de fornecer ferramentas para pesquisar dados de log é o [Amazon Detective](https://aws.amazon.com/detective/). 

 A AWS oferece mais de 200 serviços em nuvem e milhares de recursos. Recomendamos que você analise os serviços que podem apoiar e simplificar sua estratégia de resposta a incidentes. 

 Além do registro em log, você deve desenvolver e implementar uma estratégia [consistente de marcação](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). A marcação pode ajudar a fornecer contexto sobre a finalidade de um recurso da AWS. A marcação também pode ser usada para automação. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Selecione e configure logs para análise e alertas** 

 Consulte a documentação a seguir sobre como configurar logs para resposta a incidentes: 
+ [ Logging strategies for security incident response (Estratégias de registro para resposta a incidentes de segurança) ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+  [SEC04-BP01 Configurar registro em log de serviço e aplicação](sec_detect_investigate_events_app_service_logging.md) 

 **Habilite serviços de segurança para oferecer suporte à detecção e resposta** 

 A AWS fornece recursos nativos de detecção, prevenção e resposta, e outros serviços podem ser usados para arquitetar soluções de segurança personalizadas. Para obter uma lista dos serviços mais relevantes para resposta a incidentes de segurança, consulte [Definições de capacidade de nuvem](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html). 

 **Desenvolva e implemente uma estratégia de marcação** 

 Obter informações contextuais sobre o caso de uso empresarial e as partes interessadas internas relevantes em torno de um recurso da AWS pode ser difícil. Uma forma de fazer isso é na forma de tags, que atribuem metadados aos recursos da AWS e consistem em uma chave e um valor definidos pelo usuário. Você pode criar tags para categorizar os recursos por finalidade, proprietário, ambiente, tipo de dados processados e outros critérios de sua escolha. 

 Ter uma estratégia de marcação consistente pode acelerar os tempos de resposta e minimizar o tempo gasto no contexto organizacional, permitindo identificar e discernir rapidamente as informações contextuais sobre um recurso da AWS. As tags também podem servir como um mecanismo para iniciar automações de resposta. Para obter mais detalhes sobre o que marcar, consulte [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Primeiro, você deve definir as tags que deseja implementar em toda a sua organização. Depois disso, você implementará e aplicará essa estratégia de marcação. Para obter mais detalhes sobre implementação e aplicação, consulte [Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC04-BP01 Configurar registro em log de serviço e aplicação](sec_detect_investigate_events_app_service_logging.md) 
+  [SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada](sec_detect_investigate_events_analyze_all.md) 

 **Documentos relacionados:** 
+ [ Logging strategies for security incident response (Estratégias de registro para resposta a incidentes de segurança) ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Incident response cloud capability definitions (Definições de recursos de nuvem de resposta a incidentes) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)

 **Exemplos relacionados:** 
+ [ Threat Detection and Response with Amazon GuardDuty and Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Security Hub Workshop (Workshop do Security Hub) ](https://catalog.workshops.aws/security-hub/en-US)
+ [ Vulnerability Management with Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)

# SEC10-BP07 Execute simulações
<a name="sec_incident_response_run_game_days"></a>

 À medida que as organizações crescem e evoluem com o tempo, o mesmo acontece com o cenário de ameaças, o que torna importante analisar continuamente seus recursos de resposta a incidentes. Executar simulações (também conhecidas como dias de teste) é um método que pode ser usado para realizar essa avaliação. As simulações usam cenários de eventos de segurança do mundo real projetados para imitar as táticas, as técnicas e os procedimentos (TTPs) de um agente de ameaças e permitir que uma organização exercite e avalie seus recursos de resposta a incidentes respondendo a esses eventos cibernéticos simulados da mesma forma que em uma situação real.

 **Benefícios do estabelecimento dessa prática recomendada:** as simulações têm vários benefícios: 
+  Validar a prontidão cibernética e desenvolver a confiança de seus socorristas. 
+  Testar a precisão e a eficiência de ferramentas e fluxos de trabalho. 
+  Refinar os métodos de comunicação e escalonamento alinhados com seu plano de resposta a incidentes. 
+  Proporcionar uma oportunidade de responder a vetores menos comuns. 

**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Existem três tipos principais de simulações: 
+  **Simulações teóricas:** a abordagem de simulações teóricas é uma sessão baseada em discussões que envolvem as várias partes interessadas na resposta a incidentes para exercer funções e responsabilidades e usar ferramentas de comunicação e manuais estabelecidos. A facilitação das simulações normalmente pode ser realizada em um dia inteiro em um local virtual, local físico ou uma combinação de ambos. Por ser baseada em discussões, a simulação teórica se concentra em processos, pessoas e colaboração. A tecnologia é parte integrante da discussão, mas o uso real de ferramentas ou scripts de resposta a incidentes geralmente não faz parte da simulação teórica. 
+  **Simulações da equipe roxa:** as simulações da equipe roxa aumentam o nível de colaboração entre os respondentes ao incidente (equipe azul) e os agentes de ameaças simuladas (equipe vermelha). A equipe azul é composta por membros do centro de operações de segurança (SOC), mas também pode incluir outras partes interessadas que estariam envolvidas durante um evento cibernético real. A equipe vermelha é composta por uma equipe de testes de penetração ou pelas principais partes interessadas treinadas em segurança ofensiva. A equipe vermelha trabalha em colaboração com os facilitadores da simulação ao projetar um cenário para que este seja preciso e viável. Durante as simulações da equipe roxa, o foco principal está nos mecanismos de detecção, nas ferramentas e nos procedimentos operacionais padrão (SOPs) que apoiam os esforços de resposta a incidentes. 
+  **Simulações da equipe vermelha:** durante uma simulação da equipe vermelha, o infrator (equipe vermelha) realiza uma simulação para atingir um determinado objetivo ou conjunto de objetivos a partir de um escopo predeterminado. Os defensores (equipe azul) não necessariamente terão conhecimento do escopo e da duração da simulação, o que oferece uma avaliação mais realista de como eles responderiam a um incidente real. Como as simulações da equipe vermelha podem ser testes invasivos, tenha cuidado e implemente controles para verificar se a simulação não causa danos reais ao ambiente. 

 Considere facilitar as simulações cibernéticas em intervalos regulares. Cada tipo de simulação pode oferecer benefícios exclusivos aos participantes e à organização como um todo. Portanto, você pode optar por começar com tipos de simulação menos complexos (como simulações teóricas) e avançar para tipos de simulação mais complexos (simulações da equipe vermelha). Você deve selecionar um tipo de simulação com base em sua maturidade de segurança, recursos e resultados desejados. Alguns clientes podem não optar por realizar simulações da equipe vermelha devido à complexidade e ao custo. 

## Etapas da implementação
<a name="implementation-steps"></a>

 Independentemente do tipo de simulação que você escolher, as simulações geralmente seguem estas etapas de implementação: 

1.  **Defina os principais elementos do exercício:** defina o cenário e os objetivos da simulação. Ambos devem ter aceitação da liderança. 

1.  **Identifique as principais partes interessadas:** no mínimo, um exercício precisa de facilitadores e participantes. Dependendo do cenário, outras partes interessadas, como departamento jurídico, de comunicação ou liderança executiva, podem estar envolvidos. 

1.  **Crie e teste o cenário:** talvez o cenário precise ser redefinido durante a criação se elementos específicos não forem viáveis. Espera-se um cenário finalizado como resultado dessa etapa. 

1.  **Facilite a simulação:** o tipo de simulação determina a facilitação usada (um cenário impresso em comparação a um cenário simulado altamente técnico). Os facilitadores devem alinhar suas táticas de facilitação aos objetos da simulação e envolver todos os participantes sempre que possível para proporcionar o máximo benefício. 

1.  **Desenvolva o relatório pós-ação (AAR):** identifique as áreas que funcionaram bem, aquelas que podem ser melhoradas e possíveis déficits. O AAR deve medir a eficácia da simulação, bem como a resposta da equipe ao evento simulado, para que o progresso possa ser monitorado ao longo do tempo com simulações futuras. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) (Guia de resposta a incidentes da AWS) 

 **Vídeos relacionados:** 
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs) (Dia de jogo da AWS: edição de segurança)

# SEC10-BP08 Estabeleça uma estrutura para aprender com os incidentes
<a name="sec_incident_response_establish_incident_framework"></a>

 A implementação de uma framework *de lições aprendidas* e da capacidade de análise da causa raiz não só ajudará a melhorar os recursos de resposta a incidentes, mas também ajudará a evitar que o incidente se repita. Ao aprender com cada incidente, você pode ajudar a evitar a repetição dos mesmos erros, exposições ou configurações incorretas, não apenas melhorando seu procedimento de segurança, mas também minimizando o tempo perdido em situações evitáveis. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 É importante implementar uma framework *de lições aprendidas* que estabeleça e alcance, em nível geral, os seguintes pontos: 
+  Quando as lições são aprendidas? 
+  O que está envolvido no processo de lições aprendidas? 
+  Como as lições aprendidas são colocadas em prática? 
+  Quem está envolvido no processo e como? 
+  Como as áreas de melhoria serão identificadas? 
+  Como você garantirá que as melhorias sejam monitoradas e implementadas de forma eficaz? 

 A estrutura não deve se concentrar em culpar os indivíduos, mas sim na melhoria de ferramentas e processos. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Além dos resultados de alto nível listados acima, é importante garantir que você faça as perguntas certas para obter o máximo valor (informações que levem a melhorias práticas) do processo. Considere estas perguntas para ajudar você a começar a promover discussões sobre as lições aprendidas: 
+  Qual foi o incidente? 
+  Quando o incidente foi identificado pela primeira vez? 
+  Como ele foi identificado? 
+  Quais sistemas alertaram sobre a atividade? 
+  Quais sistemas, serviços e dados estavam envolvidos? 
+  O que ocorreu especificamente? 
+  O que funcionou bem? 
+  O que não funcionou bem? 
+  Quais processos ou procedimentos falharam ou não tiveram a escala ajustada para responder ao incidente? 
+  O que pode ser melhorado nas seguintes áreas: 
  +  **Pessoas** 
    +  As pessoas que precisavam ser contatadas estavam realmente disponíveis e a lista de contatos estava atualizada? 
    +  As pessoas estavam perdendo treinamentos ou não tinham os recursos necessários para responder e investigar o incidente com eficácia? 
    +  Os recursos apropriados estavam prontos e disponíveis? 
  +  **Processo** 
    +  Os processos e procedimentos foram seguidos? 
    +  Os processos e procedimentos foram documentados e estavam disponíveis para esse (tipo de) incidente? 
    +  Estavam faltando processos e procedimentos necessários? 
    +  Os respondentes conseguiram obter acesso oportuno às informações necessárias para responder ao problema? 
  +  **Tecnologia** 
    +  Os sistemas de alerta existentes identificaram e alertaram efetivamente sobre a atividade? 
    +  Como poderíamos ter reduzido o tempo de detecção em 50%? 
    +  Os alertas existentes precisam ser aprimorados ou novos alertas precisam ser criados para esse (tipo de) incidente? 
    +  As ferramentas existentes permitiram uma investigação (pesquisa/análise) eficaz do incidente? 
    +  O que pode ser feito para ajudar a identificar esse (tipo de) incidente mais cedo? 
    +  O que pode ser feito para ajudar a evitar que esse (tipo de) incidente ocorra novamente? 
    +  Quem é o proprietário do plano de melhoria e como você testará se ele foi implementado? 
    +  Qual é o cronograma para que os controles e processos adicionais de monitoramento ou prevenção sejam implementados e testados? 

 Essa lista não inclui tudo, mas serve como ponto de partida para identificar quais são as necessidades da organização e da empresa e como você pode analisá-las para aprender com os incidentes de forma mais eficaz e melhorar constantemente seu procedimento de segurança. O mais importante é começar incorporando as lições aprendidas como parte padrão do processo de resposta a incidentes, da documentação e das expectativas das partes interessadas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Security Incident Response Guide - Establish a framework for learning from incidents](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html) 
+  [NCSC CAF guidance - Lessons learned (Orientações do NCSC CAF: lições aprendidas)](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned) 

# Segurança de aplicações
<a name="a-appsec"></a>

**Topics**
+ [SEGURANÇA 11. Como incorporar e validar as propriedades de segurança de aplicações durante o ciclo de vida de design, desenvolvimento e implantação?](sec-11.md)

# SEGURANÇA 11. Como incorporar e validar as propriedades de segurança de aplicações durante o ciclo de vida de design, desenvolvimento e implantação?
<a name="sec-11"></a>

Treinar a equipe, testar por meio da automação, entender as dependências e validar as propriedades de segurança de ferramentas e aplicações ajuda a diminuir a probabilidade de problemas de segurança em workloads de produção.

**Topics**
+ [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 Realizar teste de penetração regular](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 Análises manuais de código](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 Centralizar serviços para pacotes e dependências](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 Implantar software programaticamente](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 Avaliar regularmente as propriedades de segurança dos pipelines](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)

# SEC11-BP01 Treinar para segurança de aplicações
<a name="sec_appsec_train_for_application_security"></a>

 Forneça treinamento aos criadores em sua organização sobre práticas comuns para promover a segurança no desenvolvimento e na operação de aplicações. A adoção de práticas de desenvolvimento com foco na segurança ajuda a diminuir a probabilidade de problemas que são detectados somente no estágio de avaliação da segurança. 

**Resultado desejado:** o software deve ser projetado e criado com a segurança em mente. Quando os criadores em uma organização são treinados em práticas de desenvolvimento seguras que começam com um modelo de ameaças, isso melhora a qualidade e a segurança gerais do software produzido. Essa abordagem pode reduzir o tempo de entrega do software ou de recursos porque não é necessário tanto retrabalho após o estágio de avaliação da segurança. 

 Para as finalidades desta prática recomendada, *desenvolvimento seguro* refere-se ao software que está sendo criado e às ferramentas ou aos sistemas compatíveis com o ciclo de vida de desenvolvimento de software (SDLC). 

**Antipadrões comuns:**
+  Aguardar uma avaliação da segurança e, depois, considerar as propriedades de segurança de um sistema. 
+  Deixar todas as decisões de segurança para a equipe de segurança. 
+  Não comunicar como as decisões tomadas no SDLC se relacionam às expectativas ou as políticas de segurança gerais da organização. 
+  Iniciar o processo de avaliação da segurança muito tardiamente. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Melhor conhecimento dos requisitos organizacionais para a segurança na fase inicial do ciclo de desenvolvimento. 
+  Ser capaz de identificar e solucionar possíveis problemas de segurança com maior rapidez, promovendo uma entrega de recursos mais rápida. 
+  Maior qualidade do software e dos sistemas. 

**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Ofereça treinamento aos criadores em sua organização. Iniciar um curso sobre [modelagem de ameaças](https://catalog.workshops.aws/threatmodel/en-US) é uma boa base para ajudar a treinar para segurança. Preferencialmente, os criadores devem ser capazes de acessar de forma independente as informações relevantes às respectivas workloads. Esse acesso os ajuda a tomar decisões embasadas sobre as propriedades de segurança dos sistemas criados por eles sem a necessidade de solicitar outra equipe. O processo para envolver a equipe de segurança para avaliações deve ser claramente definido e simples de seguir. As etapas do processo de avaliação devem ser incluídas no treinamento de segurança. Quando houver padrões ou modelos de implementação disponíveis, eles deverão ser simples de encontrar e vincular aos requisitos de segurança gerais. Considere usar o [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) as [estruturas do AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), o [Service Catalog](https://aws.amazon.com/servicecatalog/) ou outras ferramentas de modelo para reduzir a necessidade de configuração personalizada. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Oferecer aos criadores um curso sobre [modelagem de ameaças](https://catalog.workshops.aws/threatmodel/en-US) para criar uma boa base e ajudar a treiná-los a pensar em segurança. 
+  Conceder acesso ao treinamento do [Treinamento da AWS and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult), do setor ou de parceiros da AWS. 
+  Fornecer treinamento sobre o processo de avaliação da segurança de sua organização, que esclarece a divisão de responsabilidades entre a equipe de segurança, as equipes de workload e outras partes interessadas. 
+  Publicar orientações de autoatendimento sobre como atender aos seus requisitos de segurança, inclusive códigos de exemplo e modelos, se disponíveis. 
+  Obter feedback regularmente de equipes de criadores sobre a experiência deles com o processo e o treinamento de processo de avaliação da segurança e usar esse feedback para promover melhorias. 
+  Utilizar dias de jogo ou campanhas de bug bash para ajudar a reduzir o número de problemas e aumentar as habilidades de seus criadores. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md) 

 **Documentos relacionados:** 
+  [Treinamento da AWS and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult) 
+  [Como pensar sobre governança de segurança na nuvem](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) 
+  [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 
+  [Como acelerar o treinamento: o AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html) 

 **Vídeos relacionados:** 
+  [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag) 

 **Exemplos relacionados:** 
+  [Workshop sobre modelagem de ameaças](https://catalog.workshops.aws/threatmodel) 
+  [Conscientização do setor para desenvolvedores](https://owasp.org/www-project-top-ten/) 

 **Serviços relacionados:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [Estruturas do AWS Cloud Development Kit (AWS CDK) (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) 
+  [Service Catalog](https://aws.amazon.com/servicecatalog/) 
+  [AWS BugBust](https://docs.aws.amazon.com/codeguru/latest/bugbust-ug/what-is-aws-bugbust.html) 

# SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento
<a name="sec_appsec_automate_testing_throughout_lifecycle"></a>

 Automatize o teste das propriedades de segurança durante o ciclo de vida de desenvolvimento e lançamento. Com a automação, é mais fácil identificar de forma consistente e repetível possíveis problemas no software antes do lançamento, o que reduz o risco de problemas de segurança no software que está sendo fornecido. 

**Resultado esperado: ** o objetivo do teste automatizado é oferecer uma forma programática de detectar possíveis problemas precocemente e com frequência ao longo do ciclo de vida de desenvolvimento. Ao automatizar o teste de regressão, você pode executar novamente testes funcionais e não funcionais para verificar se o software testado anteriormente ainda funciona da forma esperada após uma alteração. Ao definir testes de unidade de segurança para conferir configurações incorretas comuns, como uma autenticação ausente ou danificada, é possível identificar e resolver esses problemas logo no início do processo de desenvolvimento. 

 A automação de testes utiliza casos de teste para um propósito específico para validação de aplicações, com base nos requisitos e na funcionalidade desejada da aplicação. O resultado dos testes automatizados baseia-se na comparação da saída do teste gerado com a respectiva saída esperada, o que acelera o ciclo de vida dos testes em geral. As metodologias de teste, como teste de regressão e pacotes de teste de unidade, são mais adequadas para automação. A automação dos testes de propriedades de segurança possibilita aos criadores receber feedback automatizado sem precisar esperar por uma avaliação da segurança. Os testes automatizados em forma de análise de código estático ou dinâmico podem melhorar a qualidade do código e ajudar a detectar possíveis problemas de software no ciclo de vida de desenvolvimento. 

**Antipadrões comuns:**
+  Não comunicar os casos de teste e os resultados dos testes automatizados. 
+  Realizar os testes automatizados somente antes de um lançamento. 
+  Automatizar casos de teste com requisitos que mudam com frequência. 
+  Não fornecer orientações sobre como abordar os resultados dos testes de segurança. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Redução da dependência de pessoas que avaliam as propriedades de segurança dos sistemas. 
+  Descobertas consistentes em vários fluxos de trabalho que melhoram a consistência. 
+  Redução da probabilidade de introduzir problemas de segurança no software de produção. 
+  Redução do período de tempo entre a detecção e a correção devido à detecção mais antecipada de problemas de software. 
+  Maior visibilidade do problema sistêmico ou repetido entre os vários fluxos de trabalho, o que pode ser utilizado para promover melhorias em toda a organização. 

** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

Ao criar um software, adote vários mecanismos de teste para garantir que você esteja testando os requisitos funcionais da aplicação, com base na respectiva lógica de negócios e em requisitos não funcionais, os quais se concentram na confiabilidade, performance e segurança da aplicação. 

 O teste de segurança de aplicação estática (SAST) analisa padrões de segurança anômalos no código-fonte e fornece indicações de código propenso a defeitos. O SAST depende de entradas estáticas, como documentação (especificação de requisitos, documentação e especificações de design) e código-fonte da aplicação, para testar uma série de problemas de segurança conhecidos. Os analisadores de código estático podem ajudar a acelerar a análise de grandes volumes de código. O [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) oferece uma comparação de [analisadores de segurança de código-fonte](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), o que inclui ferramentas de código aberto para [leitores de código de byte](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) e [leitores de código binário](https://samate.nist.gov/index.php/Binary_Code_Scanners.html).

 Complemente seu teste estático com metodologias de teste de segurança de análise dinâmica (DAST), que realizam testes na aplicação em execução a fim de identificar comportamento possivelmente inesperado. O teste dinâmico pode ser utilizado para detectar possíveis problemas que não são detectáveis por meio de análise estática. Por meio dos testes nos estágios de repositório de código, compilação e pipeline, é possível impedir que diferentes tipos de problema em potencial ocorram no código. O [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) oferece recomendações de código, como verificação de segurança, no IDE do criador. O [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) pode identificar problemas críticos, problemas de segurança e bugs difíceis de detectar durante o desenvolvimento da aplicação e oferece recomendações para melhorar a qualidade do código. 

 O workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) utiliza ferramentas de desenvolvedor da AWS, como [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/) e [AWS CodePipeline](https://aws.amazon.com/codepipeline/), para automação de pipeline de lançamento que inclui as metodologias de teste SAST e DAST. 

 À medida que você avançar no SDLC, estabeleça um processo iterativo que inclua avaliações de aplicação periódicas com sua equipe de segurança. O feedback coletado dessas avaliações de segurança deve ser abordado e validado como parte de sua avaliação de prontidão do lançamento. Essas avaliações estabelecem um procedimento de segurança robusto de aplicações e fornecem aos criadores feedback útil para resolver possíveis problemas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Implementar um IDE consistente, análise de código e ferramentas de CI/CD que incluam teste de segurança. 
+  Considerar quando no SDLC é adequado bloquear pipelines em vez de apenas notificar os criadores de que problemas precisam ser corrigidos. 
+  O workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) fornece um exemplo de como integrar testes estáticos e dinâmicos a um pipeline de lançamento. 
+  Realizar testes ou análise de código com ferramentas automatizadas, como o [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrado a IDEs de desenvolvedores e o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para verificação do código na confirmação, ajuda os criadores a obter feedback no momento certo. 
+  Ao criar com o AWS Lambda, é possível usar o [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) para verificar o código de aplicação em suas funções. 
+  O workshop [CI/CD na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) fornece um ponto de partida para criar pipelines de CI/CD na AWS. 
+  Quando testes automatizados são incluídos em pipelines de CI/CD, você precisa usar um sistema de emissão de tíquetes para rastrear a notificação e a correção de problemas de software. 
+  Para testes de segurança que podem gerar descobertas, a vinculação com orientações para correção ajuda os criadores a melhorar a qualidade do código. 
+  Analise regularmente as descobertas das ferramentas automatizadas para priorizar a próxima automação, o treinamento de criadores ou a campanha de conscientização. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Entrega contínua e implantação contínua](https://aws.amazon.com/devops/continuous-delivery/) 
+  [Parceiros com competência em DevOps da AWS](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=partner-type%23technology&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-location=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&awsm.page-partner-solutions-cards=1) 
+  [Parceiros de competência em segurança da AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=use-case%23app-security&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) para segurança da aplicação 
+  [Como escolher uma abordagem de CI/CD do Well-Arquitected](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/) 
+  [Monitorar eventos do CodeCommit no Amazon EventBridge e no Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html) 
+  [Análise da detecção de segredos no Amazon CodeGuru Review](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection) 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Como a AWS aborda a automação de implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **Vídeos relacionados:**
+  [Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) 
+  [Como automatizar pipelines CI/CD entre contas](https://www.youtube.com/watch?v=AF-pSRSGNks) 

 **Exemplos relacionados:**
+  [Conscientização do setor para desenvolvedores](https://owasp.org/www-project-top-ten/) 
+  [Governança do AWS CodePipeline](https://github.com/awslabs/aws-codepipeline-governance) 
+  Workshop [Segurança para desenvolvedores](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US) 
+  [Workshop sobre CI/CD da AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) 

# SEC11-BP03 Realizar teste de penetração regular
<a name="sec_appsec_perform_regular_penetration_testing"></a>

Realize teste de penetração regular do software. Esse mecanismo ajuda a identificar possíveis problemas de software que não podem ser detectados pelo teste automatizado ou por uma análise manual do código. Ele também ajuda você a entender a eficácia dos controles de detecção. O teste de penetração deve tentar determinar se o software pode ser executado de formas inesperadas; por exemplo, expondo dados que devem ser protegidos ou concedendo permissões mais amplas que o esperado.

 

**Resultado desejado:** o teste de penetração é usado para detectar, corrigir e validar as propriedades de segurança da aplicação. O teste de penetração regular e programado deve ser realizado como parte do ciclo de vida de desenvolvimento de software (SDLC). As descobertas do teste de penetração devem ser abordadas antes do lançamento do software. Você precisa analisar as descobertas do teste de penetração para identificar se há problemas que podem ser encontrados usando a automação. Ter um processo de teste de penetração regular e repetível que inclua um mecanismo de feedback ativo ajuda a transmitir as orientações aos criadores e melhora a qualidade do software. 

**Antipadrões comuns:**
+  Realizar um teste de penetração somente para problemas de segurança conhecidos ou prevalentes. 
+  Realizar um teste de penetração em aplicações sem ferramentas e bibliotecas de terceiro dependentes. 
+  Realizar um teste de penetração em aplicações em busca de problemas de segurança de pacote e não avaliar a lógica de negócios implementada. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Maior confiança nas propriedades de segurança do software antes do lançamento. 
+  Oportunidade de identificar padrões de aplicação preferenciais, o que aumenta a qualidade do software. 
+  Um ciclo de feedback que identifica mais cedo no ciclo de desenvolvimento quando a automação ou treinamento adicional pode melhorar as propriedades de segurança do software. 

** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 O teste de penetração é um exercício de teste de segurança estruturado em que você executa cenários de violação de segurança planejados a fim de detectar, corrigir e validar controles de segurança. Os testes de penetração começam com o reconhecimento, durante o qual os dados são coletados com base no design atual da aplicação e nas respectivas dependências. Uma lista selecionada de cenários de teste específicos de segurança é criada e executada. A principal finalidade desses testes é revelar problemas de segurança em sua aplicação, que podem ser explorados para obter acesso não intencional ao seu ambiente ou acesso não autorizado aos dados. Você precisa realizar o teste de penetração ao lançar novos recursos ou sempre que sua aplicação passar por alterações importantes na implementação técnica ou de funções. 

 É necessário identificar o estágio mais apropriado do ciclo de vida de desenvolvimento para realizar o teste de penetração. Esse teste deve ocorrer em uma fase tardia o suficiente para que a funcionalidade do sistema esteja próxima ao estado de lançamento pretendido, mas com tempo suficiente para corrigir todos os problemas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Ter um processo estruturado sobre como definir o escopo do teste de penetração. Basear esse processo no [modelo de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) é uma boa forma de manter o contexto. 
+  Identificar o estágio apropriado do ciclo de vida de desenvolvimento para realizar o teste de penetração, que deve ser quando houver o mínimo de alterações esperadas na aplicação e houver tempo suficiente para realizar a correção. 
+  Treinar os criadores sobre o que esperar das descobertas do teste de penetração e como ter informações sobre correção. 
+  Utilizar ferramentas para acelerar o processo de testes de penetração automatizando testes comuns ou repetíveis. 
+  Analisar as descobertas do teste de penetração para identificar problemas de segurança sistêmicos e utilizar esses dados para embasar testes automatizados adicionais e a instrução contínua dos criadores. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md) 
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)

 **Documentos relacionados:** 
+  [O teste de penetração da AWS](https://aws.amazon.com/security/penetration-testing/) fornece orientações detalhadas para teste de penetração na AWS 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Parceiros de competência em segurança da AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) 
+  [Modernize sua arquitetura de teste de penetração no AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/) 
+  [AWS Fault injection Simulator](https://aws.amazon.com/fis/) 

 **Exemplos relacionados:** 
+  [Como automatizar testes de API com o AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (GitHub) 
+  [Assistente de segurança automatizado](https://github.com/aws-samples/automated-security-helper) (GitHub) 

# SEC11-BP04 Análises manuais de código
<a name="sec_appsec_manual_code_reviews"></a>

Realize uma análise manual do código do software que você produz. Esse processo ajuda a verificar se a pessoa que escreveu o código não é a única que está conferindo a qualidade dele.

**Resultado desejado:** a inclusão de uma etapa de análise de código manual durante o desenvolvimento melhora a qualidade do software que está sendo criado, ajuda a melhorar as habilidades de membros menos experientes da equipe e oferece uma oportunidade de identificar locais onde a automação pode ser usada. É possível oferecer compatibilidade com as análises de código manuais com ferramentas e testes automatizados. 

**Antipadrões comuns:**
+  Não realizar análises de código antes da implantação. 
+  Ter a mesma pessoa para escrever e analisar o código. 
+  Não utilizar a automação para auxiliar ou orquestrar as análises de código. 
+  Não treinar os criadores em segurança de aplicações antes de analisarem o código. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Código de melhor qualidade. 
+  Maior consistência do desenvolvimento do código por meio da reutilização de abordagens comuns. 
+  Redução no número de problemas descobertos durante o teste de penetração e em estágios posteriores. 
+  Maior transferência de conhecimentos na equipe. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A etapa de análise deve ser implementada como parte do fluxo de gerenciamento de código geral. Os detalhes dependem da abordagem utilizada para ramificação, solicitações de pull e mesclagem. Você pode utilizar o AWS CodeCommit ou soluções de terceiros, como GitHub, GitLab ou Bitbucket. Seja qual for o método utilizado, é importante verificar se seus processos precisam de análise de código antes da implantação em um ambiente de produção. O uso de ferramentas, como o [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html), pode facilitar a orquestração do processo de análise do código. 

### Etapas da implementação
<a name="implementation-steps-required-field"></a>
+  Implementar uma etapa de análise manual como parte do fluxo de gerenciamento de código e realizar essa análise antes de prosseguir. 
+  Considerar o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para gerenciar e auxiliar nas análises de código. 
+  Implementar um fluxo de aprovação que exija a realização de uma análise de código antes de avançá-lo para o próximo estágio. 
+  Verificar se há um processo para identificar problemas encontrados durante as análises de código manuais que possam ser detectados automaticamente. 
+  Integrar a etapa de análise de código manual de forma que se alinhe às suas práticas de desenvolvimento de código. 

## Recursos
<a name="resources-required-field"></a>

 **Práticas recomendadas relacionadas:**
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:**
+  [Trabalhar com solicitações de pull em repositórios do AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html) 
+  [Trabalhar com modelos de regra de aprovação no AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html) 
+  [Sobre solicitações de pull no GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) 
+  [Análises de código automatizadas com o Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/) 
+  [Automatizar a detecção de vulnerabilidades de segurança e bugs em pipelines de CI/CD com o uso da CLI do Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/) 

 **Vídeos relacionados:**
+  [Melhoria contínua da qualidade do código com o Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw) 

 **Exemplos relacionados:** 
+  Workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) 

# SEC11-BP05 Centralizar serviços para pacotes e dependências
<a name="sec_appsec_centralize_services_for_packages_and_dependencies"></a>

Forneça serviços centralizados a equipes de criadores para obter pacotes de software e outras dependências. Isso permite a validação de pacotes antes que eles sejam incluídos no software que você escreve e fornece uma fonte de dados para a análise do software que está sendo usado na sua organização.

**Resultado desejado:** o software é composto de um conjunto de outros pacotes de software além do código que está sendo escrito. Isso simplifica o consumo de implementações de funcionalidades que são utilizadas repetidamente, como um analisador JSON ou uma biblioteca de criptografia. A centralização lógica das fontes desses pacotes e dependências oferece um mecanismo para as equipes de segurança validarem as propriedades dos pacotes antes de eles serem utilizados. Essa abordagem também reduz o risco de um problema inesperado ser provocado por uma alteração em um pacote existente ou pela inclusão de pacotes arbitrários diretamente da Internet pelas equipes de criadores. Utilize essa abordagem em conjunto com os fluxos de testes manuais e automatizados para aumentar a confiança na qualidade do software que está sendo desenvolvido. 

**Antipadrões comuns:**
+  Extrair pacotes de repositórios arbitrários na Internet. 
+  Não testar novos pacotes antes de disponibilizá-los aos criadores. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Melhor entendimento de quais pacotes estão sendo utilizados no software que está sendo criado. 
+  Capacidade de notificar as equipes de workload quando um pacote precisa ser atualizado com base no entendimento de quem está usando o quê. 
+  Redução do risco de um pacote com problemas ser incluído em seu software. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Forneça serviços centralizados para pacotes e dependências de uma forma simples para os criadores consumirem. Serviços centralizados podem ser centralizados logicamente em vez de implementados como um sistema monolítico. Essa abordagem possibilita fornecer serviços de uma forma que atenda às necessidades dos criadores. Você precisa implementar uma forma eficiente de adicionar pacotes ao repositório quando ocorrem atualizações ou surgem novos requisitos. Serviços da AWS como o [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) ou soluções semelhantes de parceiros da AWS oferecem uma forma de entregar esse recurso. 

### Etapas da implementação:
<a name="implementation-steps"></a>
+ Implementar um serviço de repositório centralizado logicamente disponível em todos os ambientes onde o software é desenvolvido. 
+ Incluir acesso ao repositório como parte do processo de provisionamento de Conta da AWS.
+ Criar automação para testar pacotes antes de serem publicados em um repositório.
+ Manter métricas dos pacotes mais utilizados, das linguagens e das equipes com a maior quantidade de alterações.
+  Fornecer um mecanismo automatizado para as equipes de criadores solicitarem novos pacotes e fornecerem feedback. 
+  Verificar regularmente os pacotes em seu repositório para identificar o possível impacto de problemas recém-descobertos. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:** 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Aumentar a segurança de seu pacote com o kit de ferramentas CodeArtifact Package Origin Control](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/) 
+  [Detectar problemas de segurança no registro em log com o Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/) 
+  [Níveis de cadeia de suprimentos para artefatos de software (SLSA)](https://slsa.dev/) 

 **Vídeos relacionados:** 
+  [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag) 
+  [A filosofia de segurança da AWS (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U) 
+  [Quando a segurança, a proteção e a urgência importam: lidar com o Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg) 

 **Exemplos relacionados:** 
+  [Pipeline de publicação de pacotes de várias regiões](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (GitHub) 
+  [Publicar módulos Node.Js no AWS CodeArtifact usando o AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (GitHub) 
+  [Exemplo de pipeline do AWS CDK Java CodeArtifact](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (GitHub) 
+  [Distribuir pacotes privados do .NET NuGet com o AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (GitHub) 

# SEC11-BP06 Implantar software programaticamente
<a name="sec_appsec_deploy_software_programmatically"></a>

Faça implantações de software de forma programática quando possível. Essa abordagem diminui a probabilidade de falha em uma implantação ou da introdução de um problema inesperado devido a erro humano.

**Resultado desejado: **manter as pessoas longe dos dados é um princípio essencial da criação segura na Nuvem AWS. Esse princípio inclui como implantar seu software. 

 Os benefícios de não contar com pessoas para implantar software é a maior confiança de que o componente testado é o que será implantado e de que a implantação sempre é realizada de forma consistente. O software não deve precisar de alterações para funcionar em diferentes ambientes. O uso dos princípios de desenvolvimento de aplicações de 12 fatores, especificamente a externalização da configuração, possibilita implantar o mesmo código em vários ambientes sem a necessidade de alterações. Assinar de forma criptográfica os pacotes de software é uma boa maneira de garantir que nada tenha sido alterado entre os ambientes. O resultado geral dessa abordagem é reduzir o risco em seu processo de alterações e melhorar a consistência das versões do software. 

**Antipadrões comuns:**
+  Implantar software manualmente em produção. 
+  Realizar alterações manualmente no software para suprir diferentes ambientes. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Maior confiança no processo de lançamento de software. 
+  Redução do risco de uma alteração com falha afetar a funcionalidade dos negócios. 
+  Maior cadência de lançamentos devido ao menor risco de alterações. 
+  Recurso de reversão automática para eventos inesperados durante a implantação. 
+  Capacidade de comprovar de forma criptográfica que o software testado é o software implantado. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Crie a infraestrutura de sua Conta da AWS para remover o acesso humano persistente dos ambientes e use ferramentas de CI/CD para realizar implantações. Projete suas aplicações de forma que os dados da configuração específica do ambiente sejam obtidos de uma fonte externa, como o [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Assine pacotes depois de testados e valide essas assinaturas durante a implantação. Configure seus pipelines de CI/CD para enviar código da aplicação e usar canários para confirmar a implantação bem-sucedida. Utilize ferramentas como o [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ou o [AWS CDK](https://aws.amazon.com/cdk/) para definir sua infraestrutura; depois, use o [AWS CodeBuild](https://aws.amazon.com/codebuild/) e o [AWS CodePipeline](https://aws.amazon.com/codepipeline/) para realizar operações de CI/CD. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Criar pipelines de CI/CD bem definidos para simplificar o processo de implantação. 
+  O uso do [AWS CodeBuild](https://aws.amazon.com/codebuild/) e do [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) para oferecer recurso de CI/CD simplifica a integração de teste de segurança aos seus pipelines. 
+  Seguir as orientações sobre separação de ambientes no whitepaper [Organizar seu ambiente da AWS com o uso de várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). 
+  Garantir que não haja nenhum acesso humano persistente aos ambientes nos quais as workloads de produção estão em execução. 
+  Projetar as aplicações para oferecer compatibilidade com a externalização de dados de configuração. 
+  Considerar a implantação com o uso do modelo de implantação azul/verde. 
+  Implementar canários para validar a implantação bem-sucedida do software. 
+  Utilizar ferramentas criptográficas, como o [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) ou o [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/), para assinar e confirmar os pacotes de software que você está implantando. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:** 
+  [Workshop sobre CI/CD da AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 
+  [Assinatura de código com o uso de CA privada do AWS Certificate Manager e chaves assimétricas do AWS Key Management Service)](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) 
+  [Assinatura de código: um controle de integridade e confiança para o AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 

 **Vídeos relacionados:** 
+  [Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) 

 **Exemplos relacionados:** 
+  [Implantações azul/verde com o AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US) 

# SEC11-BP07 Avaliar regularmente as propriedades de segurança dos pipelines
<a name="sec_appsec_regularly_assess_security_properties_of_pipelines"></a>

 Aplique os princípios do pilar Segurança do Well-Architected aos seus pipelines, com atenção especial à separação das permissões. Avalie as propriedades de segurança de sua infraestrutura de pipelines. O gerenciamento eficaz da segurança *dos* pipelines permite que você forneça segurança ao software que passa *pelos* pipelines. 

**Resultado desejado: **os pipelines utilizados para criar e implantar o software devem seguir as mesmas práticas recomendadas que qualquer outra workload em seu ambiente. Os testes implementados nos pipelines não devem ser editáveis pelos criadores que os estão utilizando. Os pipelines só devem ter as permissões necessárias para as implantações que eles estão realizando e devem implementar proteções para evitar a implantação em ambientes errados. Os pipelines não devem contar com credenciais de longo prazo e devem ser configurados para emitir o estado de forma que a integridade dos ambientes de compilação possa ser validada. 

**Antipadrões comuns:**
+  Testes de segurança que podem ser ignorados pelos criadores. 
+  Permissões excessivamente amplas para pipelines de implantação. 
+  Pipelines não configurados para validar entradas. 
+  Ausência de análise regular das permissões associadas à infraestrutura de CI/CD. 
+  Uso de credenciais de longo prazo ou codificadas. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Maior confiança na integridade do software que está sendo criado e implantado pelos pipelines. 
+  Capacidade de interromper uma implantação quando há atividade suspeita. 

** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Iniciar com serviços de CI/CD gerenciados que ofereçam compatibilidade com perfis do IAM reduz o risco de vazamento de credenciais. Aplicar os princípios do pilar Segurança à sua infraestrutura de pipeline de CI/CD pode ajudar você a determinar onde é possível realizar melhorias de segurança. Seguir a [Arquitetura de referência de pipelines de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) é um bom ponto de partida para criar seus ambientes de CI/CD. Analisar regularmente a implementação de pipelines e analisar comportamentos inesperados nos logs pode ajudar você a entender os padrões de uso dos pipelines que estão sendo utilizados para implantar o software. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Iniciar com a [Arquitetura de referência de pipeline de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). 
+  Considerar o uso do [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) para gerar de forma programática as políticas de privilégio mínimo do IAM para os pipelines. 
+  Integrar seus pipelines ao monitoramento e aos alertas de forma que você seja notificado de atividade inesperada ou anormal. Para serviços gerenciados da AWS, o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) possibilita rotear dados para destinos, como o [AWS Lambda](https://aws.amazon.com/lambda/) ou o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Arquitetura de referência de pipeline de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) 
+  [Monitorar o AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) 
+  [Práticas recomendadas de segurança para o AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html) 

 **Exemplos relacionados:** 
+  [Painel de monitoramento de DevOps](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (GitHub) 

# SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload
<a name="sec_appsec_build_program_that_embeds_security_ownership_in_teams"></a>

Crie um programa ou mecanismo que capacite as equipes de criadores a tomar decisões de segurança sobre o software que elas estão criando. Ainda assim é necessário que sua equipe de segurança valide essas decisões durante uma avaliação, mas a incorporação da propriedade de segurança nas equipes de criadores aumenta a velocidade e segurança do processo de criação de workloads. Esse mecanismo também promove uma cultura de propriedade que afeta de forma positiva a operação dos sistemas que você cria.

 

**Resultado desejado: **para incorporar a propriedade de segurança e a tomada de decisão às equipes de criadores, você pode treinar os criadores a pensar sobre segurança ou incrementar o treinamento deles com pessoal de segurança incorporado ou associado às equipes de criadores. As duas abordagens são válidas e possibilitam à equipe tomar decisões de segurança de melhor qualidade logo no início do ciclo de desenvolvimento. Esse modelo de propriedade é baseado em treinamento para segurança de aplicações. Iniciar com o modelo de ameaças para a workload específica ajuda a direcionar o design thinking (pensamento de design) para o contexto apropriado. Outro benefício de ter uma comunidade de criadores concentrados em segurança ou um grupo de engenheiros de segurança que trabalhem com equipes de criadores é que você pode entender mais profundamente como o software é escrito. Esse entendimento ajuda você a determinar as próximas áreas de melhoria em seu recurso de automação. 

**Antipadrões comuns:**
+  Deixar todas as decisões de design de segurança para a equipe de segurança. 
+  Não abordar os requisitos de segurança cedo o suficiente no processo de desenvolvimento. 
+  Não obter feedback dos criadores e do pessoal de segurança sobre a operação do programa. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Redução do tempo para concluir as avaliações de segurança. 
+  Redução dos problemas de segurança que são detectados apenas no estágio de avaliação da segurança. 
+  Melhoria da qualidade geral do software que está sendo escrito. 
+  Oportunidade de identificar e entender problemas sistêmicos ou áreas de melhoria de alto valor. 
+  Redução da quantidade de revisão necessária devido às descobertas da avaliação da segurança. 
+  Melhoria da percepção da função de segurança. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Comece com as orientações em [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md). Depois, identifique o modelo operacional para o programa que você acredita ser o melhor para a sua organização. Os dois padrões principais são treinar os criadores ou incorporar o pessoal de segurança às equipes de criadores. Depois de decidir sobre a abordagem inicial, você precisa criar um piloto com uma equipe de workload ou um grupo pequeno de equipes de workload para comprovar que o modelo funciona para sua organização. O apoio de liderança dos criadores e da segurança da organização contribui para a entrega e o sucesso do programa. À medida que você criar esse programa, é importante selecionar as métricas que podem ser utilizadas para mostrar o valor dele. Saber como a AWS resolveu esse problema é uma boa experiência de aprendizado. A prática recomendada é muito concentrada na mudança e cultura organizacionais. As ferramentas que você utiliza devem ser compatíveis com a colaboração entre as comunidades de criadores e de segurança. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Começar com o treinamento dos criadores para segurança de aplicações. 
+  Criar uma comunidade e um programa de integração para instruir os criadores. 
+  Selecionar um nome para o programa. Guardiões, patrocinadores ou defensores são utilizados com frequência. 
+  Identificar o modelo a ser utilizado: treinar criadores, incorporar engenheiros de segurança e ter perfis de segurança de afinidade. 
+  Identificar patrocinadores do projeto em grupos de segurança e de criadores e possivelmente em outros grupos relevantes. 
+  Rastrear as métricas do número de pessoas envolvidas no programa, o tempo gasto em avaliações e o feedback dos criadores e do pessoal de segurança. Utilizar essas métricas para realizar melhorias. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md) 
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:** 
+  [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 
+  [Como pensar sobre governança de segurança na nuvem](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) 

 **Vídeos relacionados:** 
+  [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag) 