Proteja e isole suas workloads altamente confidenciais com um enclave seguro
Esta orientação mostra como você pode criar uma arquitetura de nuvem abrangente para workloads confidenciais em segurança nacional, defesa e aplicação da lei nacional. Ao usar uma arquitetura de várias contas na AWS, você pode entregar suas missões e, ao mesmo tempo, manter dados confidenciais e workloads seguros. Esta orientação foi criada para ajudar você a atender a requisitos de segurança e conformidade rigorosos e exclusivos, abordando gerenciamento central de identidade e acesso, governança, segurança de dados, registro em log abrangente e design e segmentação de rede em alinhamento com várias estruturas de segurança dos EUA.
Observação: [Isenção de responsabilidade]
Diagrama de arquitetura
-
Visão geral
-
Conta de gerenciamento da organização
-
Contas de segurança
-
Contas de infraestrutura
-
Contas de aplicações, comunidades, equipes ou grupos (confidenciais)
-
Visão geral
-
Este diagrama de arquitetura apresenta uma visão geral sobre como configurar workloads abrangentes e de várias contas com requisitos exclusivos de segurança e conformidade. Para saber mais sobre como implantar essa orientação, abra as outras guias.
Clique para aumentar
Etapa 1
Uma organização no AWS Organizations com várias contas, orientada por service control policies (SCPs – políticas de controle de serviços): a organização agrupa várias contas da AWS que são controladas por uma única entidade cliente. As contas separadas da AWS isolam bem o plano de controle e o plano de dados entre workloads ou ambientes, como se fossem de propriedade de diferentes clientes da AWS.Etapa 2
A conta de gerenciamento é usada para criar a organização. Na conta de gerenciamento da organização, você pode:- Criar contas na organização e gerenciar políticas para todas as unidades organizacionais (UOs).
- Entrar nas seguintes UOs da organização:
- UO de segurança
- UO de infraestrutura
- UO de aplicações confidenciais
Cada UO terá uma ou mais contas de membros ou UO aninhadas, de acordo com o projeto.
Etapa 3
A UO de aplicações terá várias UOs aninhadas dedicadas à entrega de aplicações e ao gerenciamento do ciclo de vida, além de incluir o seguinte:- UO de desenvolvimento
- UO de teste
- UO de produção
- UO compartilhada
Além disso, é possível provisionar UOs de sandbox como workloads não confidenciais.
Etapa 1
Uma organização no AWS Organizations com várias contas, orientada por service control policies (SCPs – políticas de controle de serviços): a organização agrupa várias contas da AWS que são controladas por uma única entidade cliente. As contas separadas da AWS isolam bem o plano de controle e o plano de dados entre workloads ou ambientes, como se fossem de propriedade de diferentes clientes da AWS.Etapa 2
A conta de gerenciamento é usada para criar a organização. Na conta de gerenciamento da organização, você pode:- Criar contas na organização e gerenciar políticas para todas as unidades organizacionais (UOs).
- Entrar nas seguintes UOs da organização:
- UO de segurança
- UO de infraestrutura
- UO de aplicações confidenciais
Cada UO terá uma ou mais contas de membros ou UO aninhadas, de acordo com o projeto.
Etapa 3
A UO de aplicações terá várias UOs aninhadas dedicadas à entrega de aplicações e ao gerenciamento do ciclo de vida, além de incluir o seguinte:- UO de desenvolvimento
- UO de teste
- UO de produção
- UO compartilhada
Além disso, é possível provisionar UOs de sandbox como workloads não confidenciais.
-
Conta de gerenciamento da organização
-
Este diagrama de arquitetura mostra como uma organização pode agrupar várias contas, todas controladas por uma única entidade cliente. Siga as etapas para implantar a conta de gerenciamento da organização, parte desta orientação.
Clique para aumentar
Etapa 1
Uma organização com várias contas: a organização agrupa várias contas separadas da AWS, que são controladas por uma única entidade cliente. Isso consolida o faturamento, agrupa contas que usam UOs e facilita a implantação de controles preventivos de uma organização usando SCPs.Etapa 2
Controles preventivos de segurança: esses controles, implementados pelos SCPs, protegem a arquitetura, evitam a desativação da barreira de proteção e bloqueiam o comportamento indesejável do usuário. Os SCPs fornecem um mecanismo de barreira de proteção usado principalmente para negar categorias específicas ou inteiras de operações de API em nível de conta, UO ou organização da AWS. É possível usá-los para garantir que as workloads sejam implantadas somente nas regiões da AWS recomendadas ou para negar o acesso a serviços específicos da AWS.
Etapa 3
Automação: a automação garante que as barreiras de proteção sejam aplicadas de forma consistente quando a organização adiciona novas contas da AWS à medida que novas equipes e workloads são incorporadas. Ela corrige os desvios de conformidade e fornece barreiras de proteção na conta raiz da organização.
Etapa 4
Criptografia: o AWS Key Management Service (AWS KMS) com chaves gerenciadas pelo cliente criptografa dados armazenados em repouso usando criptografia validada pelo FIPS 140-2, seja em buckets do Amazon Simple Storage Service (Amazon S3), volumes do Amazon Elastic Block Store (Amazon EBS), bancos de dados do Amazon Relational Database Service (Amazon RDS) ou outros serviços de armazenamento da AWS. Ela protege os dados em trânsito usando o TLS 1.2 ou superior.Etapa 5
Login único: um recurso do AWS Identity and Access Management (IAM), o IAM Identity Center é usado para fornecer a concessão centralizada de perfis do IAM em contas da AWS em toda a organização para entidades principais autorizadas. As identidades existentes de uma organização podem ser obtidas do repositório de identidades do Active Directory (AD) existente do cliente ou de outro provedor de identidades (IdP) de terceiros.A AWS facilita a aplicação da autenticação multifatorial usando aplicativos autenticadores, chaves de segurança e autenticadores integrados, oferecendo suporte à autenticação e aos dispositivos WebAuthn, FIDO2 e Universal 2nd Factor (U2F).
Etapa 1
Uma organização com várias contas: a organização agrupa várias contas separadas da AWS, que são controladas por uma única entidade cliente. Isso consolida o faturamento, agrupa contas que usam UOs e facilita a implantação de controles preventivos de uma organização usando SCPs.Etapa 2
Controles preventivos de segurança: esses controles, implementados pelos SCPs, protegem a arquitetura, evitam a desativação da barreira de proteção e bloqueiam o comportamento indesejável do usuário. Os SCPs fornecem um mecanismo de barreira de proteção usado principalmente para negar categorias específicas ou inteiras de operações de API em nível de conta, UO ou organização da AWS. É possível usá-los para garantir que as workloads sejam implantadas somente nas regiões da AWS recomendadas ou para negar o acesso a serviços específicos da AWS.
Etapa 3
Automação: a automação garante que as barreiras de proteção sejam aplicadas de forma consistente quando a organização adiciona novas contas da AWS à medida que novas equipes e workloads são incorporadas. Ela corrige os desvios de conformidade e fornece barreiras de proteção na conta raiz da organização.
Etapa 4
Criptografia: o AWS Key Management Service (AWS KMS) com chaves gerenciadas pelo cliente criptografa dados armazenados em repouso usando criptografia validada pelo FIPS 140-2, seja em buckets do Amazon Simple Storage Service (Amazon S3), volumes do Amazon Elastic Block Store (Amazon EBS), bancos de dados do Amazon Relational Database Service (Amazon RDS) ou outros serviços de armazenamento da AWS. Ela protege os dados em trânsito usando o TLS 1.2 ou superior.Etapa 5
Login único: um recurso do AWS Identity and Access Management (IAM), o IAM Identity Center é usado para fornecer a concessão centralizada de perfis do IAM em contas da AWS em toda a organização para entidades principais autorizadas. As identidades existentes de uma organização podem ser obtidas do repositório de identidades do Active Directory (AD) existente do cliente ou de outro provedor de identidades (IdP) de terceiros.A AWS facilita a aplicação da autenticação multifatorial usando aplicativos autenticadores, chaves de segurança e autenticadores integrados, oferecendo suporte à autenticação e aos dispositivos WebAuthn, FIDO2 e Universal 2nd Factor (U2F).
-
Contas de segurança
-
Este diagrama de arquitetura mostra como configurar centralmente uma coleção abrangente de logs entre serviços e contas da AWS. Siga as etapas neste diagrama de arquitetura para implantar a parte de Contas de segurança desta orientação.
Clique para aumentar
Etapa 1
Registro centralizado: essa arquitetura recomenda a coleta e a centralização abrangentes de logs em todos os serviços e contas da AWS. Os logs do AWS CloudTrail funcionam em toda a organização para fornecer auditabilidade completa do plano de controle em todo o ambiente de nuvem.O Amazon CloudWatch Logs, um serviço de registro em log da AWS nativo da nuvem, é usado para capturar uma grande variedade de logs, incluindo logs do sistema operacional e da aplicação, logs de fluxo da VPC e logs do sistema de nomes de domínio, que são então centralizados e disponibilizados somente para a equipe de segurança definida.
Etapa 2
Monitoramento centralizado de segurança: desvios de conformidade e ameaças à segurança surgem em toda a organização AWS do cliente por meio da implantação automática de vários tipos diferentes de controles de segurança de detetives. Isso inclui ativar os diversos serviços de segurança da AWS em todas as contas da organização.Esses serviços de segurança incluem Amazon GuardDuty, AWS Security Hub, AWS Config, AWS Firewall Manager, Amazon Macie, IAM Access Analyzer e alarmes do CloudWatch. O controle e a visibilidade devem ser delegados em todo o ambiente de várias contas a uma única conta central de ferramentas de segurança, para facilitar a visibilidade em toda a organização de todas as descobertas de segurança e alterações na conformidade.
Etapa 3
Acesso somente para visualização e capacidade de pesquisa: a conta de segurança tem acesso somente para visualização em toda a organização (incluindo acesso ao console do CloudWatch de cada conta) para facilitar a investigação durante um incidente.O acesso somente para visualização é diferente do acesso somente para leitura, pois não fornece acesso a nenhum dado. Um complemento opcional está disponível para usar o conjunto abrangente de logs centralizados e torná-los pesquisáveis, fornecendo correlação e painéis básicos.
Etapa 1
Registro centralizado: essa arquitetura recomenda a coleta e a centralização abrangentes de logs em todos os serviços e contas da AWS. Os logs do AWS CloudTrail funcionam em toda a organização para fornecer auditabilidade completa do plano de controle em todo o ambiente de nuvem.O Amazon CloudWatch Logs, um serviço de registro em log da AWS nativo da nuvem, é usado para capturar uma grande variedade de logs, incluindo logs do sistema operacional e da aplicação, logs de fluxo da VPC e logs do sistema de nomes de domínio, que são então centralizados e disponibilizados somente para a equipe de segurança definida.
Etapa 2
Monitoramento centralizado de segurança: desvios de conformidade e ameaças à segurança surgem em toda a organização AWS do cliente por meio da implantação automática de vários tipos diferentes de controles de segurança de detetives. Isso inclui ativar os diversos serviços de segurança da AWS em todas as contas da organização.Esses serviços de segurança incluem Amazon GuardDuty, AWS Security Hub, AWS Config, AWS Firewall Manager, Amazon Macie, IAM Access Analyzer e alarmes do CloudWatch. O controle e a visibilidade devem ser delegados em todo o ambiente de várias contas a uma única conta central de ferramentas de segurança, para facilitar a visibilidade em toda a organização de todas as descobertas de segurança e alterações na conformidade.
Etapa 3
Acesso somente para visualização e capacidade de pesquisa: a conta de segurança tem acesso somente para visualização em toda a organização (incluindo acesso ao console do CloudWatch de cada conta) para facilitar a investigação durante um incidente.
O acesso somente para visualização é diferente do acesso somente para leitura, pois não fornece acesso a nenhum dado. Um complemento opcional está disponível para usar o conjunto abrangente de logs centralizados e torná-los pesquisáveis, fornecendo correlação e painéis básicos.
-
Contas de infraestrutura
-
Este diagrama de arquitetura mostra como um ambiente de rede centralizado e isolado é construído com nuvens privadas virtuais (VPCs). Siga as etapas neste diagrama de arquitetura para implantar a parte de contas de infraestrutura desta orientação.
Clique para aumentar
Etapa 1
Rede centralizada e isolada: as VPCs criadas por meio do Amazon Virtual Private Cloud (Amazon VPC) são usadas para criar isolamento de plano de dados entre workloads, centralizadas em uma conta de rede compartilhada. A centralização facilita a forte segmentação de funções e a otimização de custos.Etapa 2
Conectividade mediada: a conectividade com ambientes on-premises, a saída da Internet, os recursos compartilhados e as APIs da AWS são mediadas em um ponto central de entrada e saída por meio do uso do AWS Transit Gateway, do AWS Site-to-Site VPN, dos firewalls de próxima geração e do AWS Direct Connect (quando aplicável).Etapa 3
Opções alternativas: a arquitetura VPC centralizada não é para todos os clientes. Para clientes menos preocupados com a otimização de custos, existe uma opção para VPCs baseadas em contas locais interconectadas por meio do Transit Gateway na conta central da rede compartilhada.
Nas duas opções, a arquitetura prescreve a transferência de endpoints da API pública da AWS para o espaço do endereço da VPC privada do cliente, usando endpoints centralizados para obter eficiência de custos.
Etapa 4
Inspeção centralizada de infraestrutura como serviço (IaaS) de entrada e saída: é comum ver requisitos centralizados de entrada e saída para workloads baseadas em IaaS. A arquitetura fornece essa funcionalidade para que os clientes possam decidir se os serviços nativos de inspeção de firewall de entrada e saída da AWS (como o AWS Network Firewall, o AWS WAF ou o Application Load Balancer por meio do Elastic Load Balancing (ELB)) atendem aos seus requisitos.Caso contrário, os clientes podem aumentar esses recursos com dispositivos de firewall de terceiros. A arquitetura permite começar com um firewall da AWS e migrar para um firewall de terceiros ou usar uma combinação de tecnologias de firewall de entrada e saída.
Etapa 1
Rede centralizada e isolada: as VPCs criadas por meio do Amazon Virtual Private Cloud (Amazon VPC) são usadas para criar isolamento de plano de dados entre workloads, centralizadas em uma conta de rede compartilhada. A centralização facilita a forte segmentação de funções e a otimização de custos.Etapa 2
Conectividade mediada: a conectividade com ambientes on-premises, a saída da Internet, os recursos compartilhados e as APIs da AWS são mediadas em um ponto central de entrada e saída por meio do uso do AWS Transit Gateway, do AWS Site-to-Site VPN, dos firewalls de próxima geração e do AWS Direct Connect (quando aplicável).Etapa 3
Opções alternativas: a arquitetura VPC centralizada não é para todos os clientes. Para clientes menos preocupados com a otimização de custos, existe uma opção para VPCs baseadas em contas locais interconectadas por meio do Transit Gateway na conta central da rede compartilhada.
Nas duas opções, a arquitetura prescreve a transferência de endpoints da API pública da AWS para o espaço do endereço da VPC privada do cliente, usando endpoints centralizados para obter eficiência de custos.
Etapa 4
Inspeção centralizada de infraestrutura como serviço (IaaS) de entrada e saída: é comum ver requisitos centralizados de entrada e saída para workloads baseadas em IaaS. A arquitetura fornece essa funcionalidade para que os clientes possam decidir se os serviços nativos de inspeção de firewall de entrada e saída da AWS (como o AWS Network Firewall, o AWS WAF ou o Application Load Balancer por meio do Elastic Load Balancing (ELB)) atendem aos seus requisitos.Caso contrário, os clientes podem aumentar esses recursos com dispositivos de firewall de terceiros. A arquitetura permite começar com um firewall da AWS e migrar para um firewall de terceiros ou usar uma combinação de tecnologias de firewall de entrada e saída.
-
Contas de aplicações, comunidades, equipes ou grupos (confidenciais)
-
Esse diagrama de arquitetura mostra como configurar a segmentação e a separação entre workloads pertencentes a diferentes estágios do ciclo de vida de desenvolvimento de software ou entre diferentes funções administrativas de TI. Siga as etapas neste diagrama de arquitetura para implantar as contas de aplicações, comunidades, equipes ou grupos que fazem parte desta orientação.
Clique para aumentar
Etapa 1
Segmentação e separação: a arquitetura não fornece apenas uma forte segmentação e separação entre workloads pertencentes a diferentes estágios do ciclo de vida de desenvolvimento de software ou entre diferentes funções administrativas de TI (como entre redes, firewalls de entrada e saída e workloads).Também oferece uma forte arquitetura de zoneamento de rede, microssegmentando o ambiente ao envolver cada instância ou componente em um firewall de estado que é aplicado no hardware do AWS Nitro System, junto com serviços como ELB e AWS WAF.
Etapa 2
Todos os fluxos de rede são rigorosamente aplicados, com o movimento lateral evitado entre aplicações, camadas dentro de uma aplicação e nós em uma camada de uma aplicação, a menos que seja explicitamente permitido. Além disso, o roteamento é evitado entre Dev, Test e Prod com recomendações sobre uma arquitetura de CI/CD para permitir a agilidade do desenvolvedor e facilitar a promoção de código entre ambientes com as aprovações apropriadas.
Etapa 1
Segmentação e separação: a arquitetura não fornece apenas uma forte segmentação e separação entre workloads pertencentes a diferentes estágios do ciclo de vida de desenvolvimento de software ou entre diferentes funções administrativas de TI (como entre redes, firewalls de entrada e saída e workloads).Também oferece uma forte arquitetura de zoneamento de rede, microssegmentando o ambiente ao envolver cada instância ou componente em um firewall de estado que é aplicado no hardware do AWS Nitro System, junto com serviços como ELB e AWS WAF.
Etapa 2
Todos os fluxos de rede são rigorosamente aplicados, com o movimento lateral evitado entre aplicações, camadas dentro de uma aplicação e nós em uma camada de uma aplicação, a menos que seja explicitamente permitido. Além disso, o roteamento é evitado entre Dev, Test e Prod com recomendações sobre uma arquitetura de CI/CD para permitir a agilidade do desenvolvedor e facilitar a promoção de código entre ambientes com as aprovações apropriadas.
Pilares do Well-Architected
O AWS Well-Architected Framework ajuda a entender as vantagens e as desvantagens das decisões tomadas durante a criação de sistemas na nuvem. Os seis pilares do Framework permitem que você aprenda as melhores práticas de arquitetura, a fim de projetar e operar sistemas confiáveis, seguros, eficientes, econômicos e sustentáveis. Com a Ferramenta AWS Well-Architected, disponível gratuitamente no Console de Gerenciamento da AWS, você pode avaliar suas workloads em relação às práticas recomendadas ao responder a uma série de questões para cada pilar.
O diagrama de arquitetura acima exemplifica a criação de uma solução pautada nas melhores práticas do Well-Architected. Para ser totalmente Well-Architected, é preciso respeitar a maior quantidade possível das melhores práticas desse framework.
-
Excelência operacionalLeia o whitepaper sobre excelência operacional
Esta orientação usa o Organizations com pilhas e configurações do AWS CloudFormation para criar uma base segura para seu ambiente da AWS. Isso fornece uma solução de infraestrutura como código (IaC) que acelera a implementação de controles técnicos de segurança. As regras do Config corrigem quaisquer deltas de configuração que tenham sido determinados como impactando negativamente a arquitetura prescrita. Você pode usar a infraestrutura comercial global da AWS para workloads confidenciais e automatizar sistemas seguros para entregar missões com mais rapidez e, ao mesmo tempo, melhorar continuamente seus processos e procedimentos.
-
SegurançaLeia o whitepaper sobre segurança
Esta orientação usa o Organizations para facilitar a implantação de barreiras de proteção organizacionais, como o registro em log de APIs com o CloudTrail. Esta orientação também fornece controles preventivos usando SCPs prescritivos da AWS como um mecanismo de barreira de proteção, usado principalmente para negar categorias específicas ou inteiras de APIs em seu ambiente (para garantir que as workloads sejam implantadas somente nas regiões recomendadas) ou negar acesso a serviços específicos da AWS. Os logs do CloudTrail e do CloudWatch oferecem suporte a coleta e centralização abrangentes de logs recomendados em serviços e contas da AWS. Os recursos de segurança da AWS e a variedade de serviços relevantes para a segurança são configurados em um padrão definido que ajuda você a atender a alguns dos requisitos de segurança mais rígidos do mundo.
-
ConfiabilidadeLeia o whitepaper sobre confiabilidade
Esta orientação usa várias zonas de disponibilidade (AZs), portanto, a perda de uma AZ não afeta a disponibilidade da aplicação. Você pode usar o CloudFormation para automatizar o provisionamento e a atualização da infraestrutura de forma segura e controlada. Esta orientação também fornece regras pré-criadas para avaliar as configurações de recursos da AWS e as mudanças de configuração em seu ambiente, ou você pode criar regras personalizadas no AWS Lambda para definir as práticas recomendadas e as diretrizes. Você pode automatizar a capacidade de escalar seu ambiente para atender à demanda e mitigar interrupções, como configurações incorretas ou problemas transitórios de rede.
-
Eficiência de performanceLeia o whitepaper sobre eficiência da performance
Essa orientação simplifica o gerenciamento da infraestrutura em nuvem usando o Transit Gateway, que serve como um hub central que conecta várias VPCs por meio de um único gateway, facilitando a escalabilidade e a manutenção da arquitetura de rede. Isso simplifica sua arquitetura de rede e facilita o roteamento eficiente de tráfego entre diferentes contas da AWS em sua organização.
-
Otimização de custosLeia o whitepaper sobre otimização de custos
Essa orientação fornece a capacidade de evitar ou remover custos desnecessários ou o uso de recursos abaixo do ideal. O Organizations oferece centralização e faturamento consolidado, facilitando a forte separação entre o uso de recursos e a otimização de custos. Essa orientação prescreve a transferência de endpoints de API públicos da AWS para seu espaço de endereço da VPC privada, usando endpoints centralizados para eficiência de custos. Além disso, você pode usar os relatórios de custo e uso da AWS (AWS CUR) para rastrear seu uso da AWS e estimar cobranças.
-
SustentabilidadeLeia o whitepaper sobre sustentabilidade
Essa orientação ajuda você a reduzir a pegada de carbono associada ao gerenciamento de workloads em seus próprios datacenters. A infraestrutura global da AWS oferece infraestrutura de suporte (como energia, resfriamento e rede), uma taxa de utilização mais alta e atualizações tecnológicas mais rápidas do que os data centers tradicionais. Além disso, a segmentação e a separação das workloads ajudam a reduzir a movimentação desnecessária de dados, e o Amazon S3 oferece níveis de armazenamento e a capacidade de mover dados automaticamente para níveis de armazenamento eficientes.
Recursos de implementação
O código de amostra é um ponto de partida. Ele é validado para o setor, é prescritivo, mas não definitivo, e mostra o que há por trás de tudo para ajudar você a começar.
Conteúdo relacionado
Configuração de amostra TSE-SE (com mecanismo de automação LZA)
Trusted Secure Enclaves - Sensitive Edition
Aviso de isenção de responsabilidade
O código de exemplo, as bibliotecas de software, as ferramentas de linha de comando, as provas de conceito, os modelos ou outra tecnologia relacionada (incluindo qualquer uma das anteriores fornecidas por nossa equipe) são fornecidos a você como Conteúdo da AWS nos termos do Contrato de Cliente da AWS ou o contrato por escrito pertinente entre você e a AWS (o que for aplicável). Você não deve usar esse Conteúdo da AWS em suas contas de produção, na produção ou em outros dados essenciais. Você é responsável por testar, proteger e otimizar o Conteúdo da AWS, como código de exemplo, conforme apropriado para uso em nível de produção com base em suas práticas e padrões específicos de controle de qualidade. A implantação de Conteúdo da AWS pode gerar cobranças da AWS para criar ou usar recursos cobráveis, como executar instâncias do Amazon EC2 ou usar armazenamento do Amazon S3.
As referências a serviços ou organizações terceirizadas nesta orientação não implicam em endosso, patrocínio ou afiliação entre a Amazon ou a AWS e terceiros. A orientação da AWS é um ponto de partida técnico, e você pode personalizar sua integração com serviços de terceiros ao implantar a arquitetura.