Workloads OU — Conta de aplicativo

Influencie o futuro da Arquitetura de Referência de AWS Segurança (AWSSRA) respondendo a uma breve pesquisa.

O diagrama a seguir ilustra os serviços de segurança da AWS que estão configurados na conta do aplicativo (junto com o próprio aplicativo).

A conta do aplicativo hospeda a infraestrutura e os serviços principais para executar e manter um aplicativo corporativo. A conta do aplicativo e a UO de cargas de trabalho atendem a alguns objetivos principais de segurança. Primeiro, você cria uma conta separada para cada aplicativo para fornecer limites e controles entre cargas de trabalho para evitar problemas de combinação de funções, permissões, dados e chaves de criptografia. Você deseja fornecer um contêiner de conta separado, no qual a equipe de aplicativos possa ter amplos direitos para gerenciar sua própria infraestrutura sem afetar outras pessoas. Em seguida, você adiciona uma camada de proteção fornecendo um mecanismo para a equipe de operações de segurança monitorar e coletar dados de segurança. Use uma trilha organizacional e implantações locais de serviços de segurança de contas (Amazon GuardDuty, AWS Config, AWS Security Hub EventBridge, Amazon, AWS IAM Access Analyzer), que são configurados e monitorados pela equipe de segurança. Por fim, você permite que sua empresa defina os controles de forma centralizada. Você alinha a conta do aplicativo à estrutura de segurança mais ampla, tornando-a membro da OU de cargas de trabalho, por meio da qual ela herda as permissões, restrições e proteções de serviço apropriadas.

Consideração do design

• Em sua organização, é provável que você tenha mais de um aplicativo de negócios. A OU de cargas de trabalho foi projetada para abrigar a maioria das cargas de trabalho específicas de sua empresa, incluindo ambientes de produção e não produção. Essas cargas de trabalho podem ser uma combinação de aplicativos comerciais off-the-shelf (COTS) e seus próprios aplicativos e serviços de dados personalizados desenvolvidos internamente. Existem poucos padrões para organizar diferentes aplicativos de negócios junto com seus ambientes de desenvolvimento. Um padrão é ter várias OUs secundárias com base em seu ambiente de desenvolvimento, como produção, preparação, teste e desenvolvimento, e usar contas secundárias separadas da AWS nas OUs que pertencem a aplicativos diferentes. Outro padrão comum é ter OUs secundárias separadas por aplicativo e, em seguida, usar contas secundárias separadas da AWS para ambientes de desenvolvimento individuais. A estrutura exata da OU e da conta depende do design do aplicativo e das equipes que gerenciam esses aplicativos. Considere os controles de segurança que você deseja aplicar, sejam eles específicos do ambiente ou do aplicativo, porque é mais fácil implementar esses controles como SCPs em OUs. Para mais considerações sobre a organização de OUs orientadas à carga de trabalho, consulte a seção Organização de OUs orientadas à carga de trabalho do whitepaper da AWS Organizando seu ambiente da AWS usando várias contas.

Aplicação VPC

A nuvem privada virtual (VPC) na conta do aplicativo precisa tanto de acesso de entrada (para os serviços web simples que você está modelando) quanto de saída (para necessidades de aplicativos ou necessidades de serviços da AWS). Por padrão, os recursos dentro de uma VPC são roteáveis entre si. Há duas sub-redes privadas: uma para hospedar as instâncias do EC2 (camada de aplicativo) e outra para o Amazon Aurora (camada de banco de dados). A segmentação da rede entre diferentes camadas, como a camada do aplicativo e a camada do banco de dados, é realizada por meio de grupos de segurança da VPC, que restringem o tráfego no nível da instância. Para maior resiliência, a carga de trabalho abrange duas ou mais zonas de disponibilidade e utiliza duas sub-redes por zona.

Consideração do design

• Você pode usar o espelhamento de tráfego para copiar o tráfego de rede de uma interface de rede elástica de instâncias do EC2. Em seguida, você pode enviar o tráfego para dispositivos out-of-band de segurança e monitoramento para inspeção de conteúdo, monitoramento de ameaças ou solução de problemas. Por exemplo, talvez você queira monitorar o tráfego que está saindo da sua VPC ou o tráfego cuja origem está fora da sua VPC. Nesse caso, você espelhará todo o tráfego, exceto o tráfego que passa pela sua VPC, e o enviará para um único dispositivo de monitoramento. Os logs de fluxo do Amazon VPC não capturam tráfego espelhado; eles geralmente capturam informações somente dos cabeçalhos dos pacotes. O espelhamento de tráfego fornece uma visão mais profunda do tráfego da rede, permitindo que você analise o conteúdo real do tráfego, incluindo a carga útil. Ative o espelhamento de tráfego somente para a interface de rede elástica de instâncias do EC2 que podem estar operando como parte de cargas de trabalho confidenciais ou para as quais você espera precisar de diagnósticos detalhados no caso de um problema.

VPC endpoints

Os endpoints de VPC fornecem outra camada de controle de segurança, além de escalabilidade e confiabilidade. Use-os para conectar seu aplicativo VPC a outros serviços da AWS. (Na conta do aplicativo, o AWS SRA emprega endpoints VPC para AWS KMS, AWS Systems Manager e Amazon S3.) Endpoints são dispositivos virtuais. Eles são componentes de VPC escalados horizontalmente, redundantes e altamente disponíveis. Permitem a comunicação entre instâncias em sua VPC e serviços, sem impor riscos de disponibilidade ou restrições de largura de banda ao tráfego de rede. Você pode usar um VPC endpoint para conectar de forma privada sua VPC a serviços compatíveis da AWS e serviços de endpoint de VPC fornecidos pela AWS PrivateLink sem precisar de um gateway de internet, dispositivo NAT, conexão VPN ou conexão do AWS Direct Connect. As instâncias em sua VPC não exigem endereços IP públicos para se comunicar com outros serviços da AWS. O tráfego entre sua VPC e o outro serviço da AWS não sai da rede Amazon. 

Outro benefício do uso de VPC endpoints é permitir a configuração de políticas de endpoint. Uma política de VPC endpoint é uma política de recursos do IAM que você anexa a um endpoint quando cria ou modifica o endpoint. Se você não anexar uma política do IAM ao criar um endpoint, a AWS anexará uma política padrão do IAM para você que permite acesso total ao serviço. Uma política de endpoint não substitui nem substitui políticas do IAM ou políticas específicas de serviços (como políticas de bucket do S3). É uma política do IAM separada para controlar o acesso do endpoint ao serviço especificado. Dessa forma, ele adiciona outra camada de controle sobre a qual os diretores da AWS podem se comunicar com recursos ou serviços.

Amazon EC2

As instâncias do Amazon EC2 que compõem nosso aplicativo usam a versão 2 do Instance Metadata Service (IMDSv2). O IMDSv2 adiciona proteções para quatro tipos de vulnerabilidades que podem ser usadas para tentar acessar o IMDS: firewalls de aplicativos de sites, proxies reversos abertos, vulnerabilidades de falsificação de solicitações do lado do servidor (SSRF), firewalls abertos de camada 3 e NATs. Para obter mais informações, consulte a postagem do blog Adicione uma defesa aprofundada contra firewalls abertos, proxies reversos e vulnerabilidades de SSRF com aprimoramentos no EC2 Instance Metadata Service.

Use VPCs separadas (como subconjunto dos limites da conta) para isolar a infraestrutura por segmentos de carga de trabalho. Use sub-redes para isolar as camadas de sua aplicação (por exemplo, Web, aplicação e banco de dados) em uma única VPC. Use sub-redes privadas para as instâncias que não devem ser acessadas diretamente pela Internet. Para chamar a API do Amazon EC2 de sua sub-rede privada sem usar um gateway de internet, use a AWS. PrivateLink Restrinja o acesso às suas instâncias usando grupos de segurança. Use Logs de fluxo da VPC para monitorar o tráfego recebido nas instâncias. Use o Session Manager, um recurso do AWS Systems Manager, para acessar suas instâncias remotamente em vez de abrir portas SSH de entrada e gerenciar chaves SSH. Use volumes separados do Amazon Elastic Block Store (Amazon EBS) para o sistema operacional e seus dados. Você pode configurar sua conta da AWS para aplicar a criptografia dos novos volumes do EBS e das cópias de snapshot que você criar. 

Exemplo de implementação

A biblioteca de códigos AWS SRA fornece um exemplo de implementação da criptografia padrão do Amazon EBS no Amazon EC2. Ele demonstra como você pode habilitar a criptografia padrão do Amazon EBS em nível de conta em cada conta da AWS e região da AWS na organização da AWS.

Application Load Balancers

Os Application Load Balancers distribuem o tráfego de entrada do aplicativo em vários destinos, como instâncias do EC2, em várias zonas de disponibilidade. No AWS SRA, o grupo-alvo do balanceador de carga são as instâncias EC2 do aplicativo. O AWS SRA usa ouvintes HTTPS para garantir que o canal de comunicação seja criptografado. O Application Load Balancer usa um certificado de servidor para encerrar a conexão front-end e, em seguida, descriptografar as solicitações dos clientes antes de enviá-las aos destinos.

O AWS Certificate Manager (ACM) se integra nativamente aos Application Load Balancers, e o AWS SRA usa o ACM para gerar e gerenciar os certificados públicos X.509 (servidor TLS) necessários. Você pode aplicar o TLS 1.2 e cifras fortes para conexões front-end por meio da política de segurança do Application Load Balancer. Para mais informações, consulte a documentação do Elastic Load Balancing. 

Considerações sobre design

• Para cenários comuns, como aplicativos estritamente internos que exigem um certificado TLS privado no Application Load Balancer, você pode usar o ACM nessa conta para gerar um certificado privado a partir de. CA privada da AWS No AWS SRA, a CA privada raiz do ACM é hospedada na conta do Security Tooling e pode ser compartilhada com toda a organização da AWS ou com contas específicas da AWS para emitir certificados de entidade final, conforme descrito anteriormente na seção de contas do Security Tooling. 

• Para certificados públicos, você pode usar o ACM para gerar esses certificados e gerenciá-los, incluindo a rotação automática. Como alternativa, você pode gerar seus próprios certificados usando ferramentas SSL/TLS para criar uma solicitação de assinatura de certificado (CSR), fazer com que a CSR seja assinada por uma autoridade de certificação (CA) para produzir um certificado e, em seguida, importar o certificado para o ACM ou fazer upload do certificado no IAM para uso com o Application Load Balancer. Se você importar um certificado para o ACM, deverá monitorar a data de expiração do certificado e renová-lo antes que ele expire. 

• Para obter camadas adicionais de defesa, você pode implantar políticas do AWS WAF para proteger o Application Load Balancer. Ter políticas periféricas, políticas de aplicativos e até mesmo camadas de aplicação de políticas privadas ou internas aumenta a visibilidade das solicitações de comunicação e fornece uma aplicação unificada de políticas. Para obter mais informações, consulte a postagem do blog Implantando defesa em profundidade usando o AWS Managed Rules for AWS WAF.

CA privada da AWS

AWS Private Certificate Authority(CA privada da AWS) é usado na conta do aplicativo para gerar certificados privados para serem usados com um Application Load Balancer. É um cenário comum que os Application Load Balancers forneçam conteúdo seguro via TLS. Isso exige que os certificados TLS sejam instalados no Application Load Balancer. Para aplicativos estritamente internos, os certificados TLS privados podem fornecer o canal seguro.

No AWS SRA, CA privada da AWS está hospedado na conta do Security Tooling e é compartilhado com a conta do aplicativo usando a AWS RAM. Isso permite que os desenvolvedores em uma conta de aplicativo solicitem um certificado de uma CA privada compartilhada. Compartilhar CAs em toda a sua organização ou entre contas da AWS ajuda a reduzir o custo e a complexidade da criação e do gerenciamento de CAs duplicadas em todas as suas contas da AWS. Quando você usa o ACM para emitir certificados privados de uma CA compartilhada, o certificado é gerado localmente na conta solicitante, e o ACM fornece gerenciamento e renovação completos do ciclo de vida.

Amazon Inspector

O AWS SRA usa o Amazon Inspector para descobrir e escanear automaticamente instâncias do EC2 e imagens de contêineres que residem no Amazon Elastic Container Registry (Amazon ECR) em busca de vulnerabilidades de software e exposição não intencional na rede.

O Amazon Inspector é colocado na conta do aplicativo porque fornece serviços de gerenciamento de vulnerabilidades para instâncias do EC2 nessa conta. Além disso, o Amazon Inspector relata caminhos de rede indesejados de e para instâncias do EC2.

O Amazon Inspector nas contas dos membros é gerenciado centralmente pela conta do administrador delegado. No AWS SRA, a conta do Security Tooling é a conta delegada do administrador. A conta de administrador delegado pode gerenciar descobertas, dados e determinadas configurações para membros da organização. Isso inclui a visualização de detalhes agregados das descobertas de todas as contas dos membros, a ativação ou desativação das verificações das contas dos membros e a análise dos recursos escaneados dentro da organização da AWS. 

Consideração do design

• Você pode usar o Patch Manager, um recurso do AWS Systems Manager, para acionar a aplicação de patches sob demanda para remediar vulnerabilidades de segurança de dia zero ou outras vulnerabilidades críticas de segurança do Amazon Inspector. O Patch Manager ajuda você a corrigir essas vulnerabilidades sem ter que esperar pelo cronograma normal de patches. A remediação é realizada usando o runbook do Systems Manager Automation. Para obter mais informações, consulte a série de blogs em duas partes Automatize o gerenciamento e a remediação de vulnerabilidades na AWS usando o Amazon Inspector e o AWS Systems Manager.

Amazon Systems Manager

O AWS Systems Manager é um serviço da AWS que você pode usar para visualizar dados operacionais de vários serviços da AWS e automatizar tarefas operacionais em seus recursos da AWS. Com fluxos de trabalho e runbooks de aprovação automatizados, você pode trabalhar para reduzir o erro humano e simplificar as tarefas de manutenção e implantação nos recursos da AWS.

Além desses recursos gerais de automação, o Systems Manager oferece suporte a vários recursos de segurança preventivos, de detecção e responsivos. O AWS Systems Manager Agent (SSM Agent) é um software da Amazon que pode ser instalado e configurado em uma instância do EC2, em um servidor local ou em uma máquina virtual (VM). O SSM Agent permite que o Systems Manager atualize, gerencie e configure esses recursos. O Systems Manager ajuda você a manter a segurança e a conformidade examinando essas instâncias gerenciadas e relatando (ou tomando medidas corretivas) sobre quaisquer violações detectadas em seu patch, configuração e políticas personalizadas. 

O AWS SRA usa o Session Manager, um recurso do Systems Manager, para fornecer uma experiência interativa de shell e CLI baseada em navegador. Isso fornece gerenciamento de instâncias seguro e auditável sem a necessidade de abrir portas de entrada, manter bastion hosts ou gerenciar chaves SSH. O AWS SRA usa o Patch Manager, um recurso do Systems Manager, para aplicar patches às instâncias do EC2 para sistemas operacionais e aplicativos. 

O AWS SRA também usa a automação, um recurso do Systems Manager, para simplificar tarefas comuns de manutenção e implantação de instâncias do Amazon EC2 e outros recursos da AWS. A automação pode simplificar tarefas comuns de TI como alterar o estado de um ou mais nós gerenciados (usando uma automação de aprovação) e gerenciar estados dos nós gerenciados de acordo com sua própria programação. O Systems Manager inclui recursos que ajudam você a direcionar grandes grupos de instâncias usando etiquetas e controles de velocidade que ajudam a implementar alterações de acordo com os limites que você define. A automação oferece automações com um clique para simplificar tarefas complexas, como criar imagens de máquina incríveis da Amazon (AMIs) e recuperar instâncias EC2 inacessíveis. Além disso, você pode aprimorar a segurança operacional dando às funções do IAM acesso a runbooks específicos para realizar determinadas funções, sem conceder permissões diretamente a essas funções. Por exemplo, se você quiser que uma função do IAM tenha permissões para reiniciar instâncias específicas do EC2 após atualizações de patches, mas não quiser conceder a permissão diretamente a essa função, crie um runbook de automação e conceda à função permissões para executar somente o runbook.

Considerações sobre design

• O agente do Systems Manager depende dos metadados da instância do EC2 para funcionar corretamente. O Systems Manager pode acessar os metadados da instância usando a versão 1 ou a versão 2 do Instance Metadata Service (IMDSv1 e IMDSv2). 

• O SSM Agent precisa se comunicar com diferentes serviços e recursos da AWS, como mensagens do Amazon EC2, Systems Manager e Amazon S3. Para que essa comunicação ocorra, a sub-rede exige conectividade de saída com a Internet ou provisionamento de VPC endpoints apropriados. O AWS SRA usa VPC endpoints para que o SSM Agent estabeleça caminhos de rede privados para vários serviços da AWS. 

• Usando o Automation, você pode compartilhar as práticas recomendadas com o restante da sua organização. Você pode criar as melhores práticas para gerenciamento de recursos em runbooks e compartilhar os runbooks entre regiões e grupos da AWS. Você também pode restringir os valores permitidos para os parâmetros do runbook. Para esses casos de uso, talvez seja necessário criar runbooks de automação em uma conta central, como ferramentas de segurança ou serviços compartilhados, e compartilhá-los com o resto da organização da AWS. Os casos de uso comuns incluem a capacidade de implementar centralmente atualizações de patches e segurança, corrigir desvios nas configurações de VPC ou nas políticas de bucket do S3 e gerenciar instâncias do EC2 em grande escala. Para obter detalhes sobre a implementação, consulte a documentação do Systems Manager.

Amazon Aurora

No AWS SRA, o Amazon Aurora e o Amazon S3 compõem a camada lógica de dados. O Aurora é um mecanismo de banco de dados relacional gerenciado compatível com o MySQL e o PostgreSQL. Um aplicativo que está sendo executado nas instâncias do EC2 se comunica com o Aurora e o Amazon S3 conforme necessário. O Aurora é configurado com um cluster de banco de dados dentro de um grupo de sub-redes de banco de dados. 

Consideração do design

• Como em muitos serviços de banco de dados, a segurança do Aurora é gerenciada em três níveis. Para controlar quem pode realizar ações de gerenciamento do Amazon Relational Database Service (Amazon RDS) em clusters e instâncias de banco de dados Aurora, você usa o IAM. Para controlar quais dispositivos e instâncias do EC2 podem abrir conexões com o endpoint do cluster e a porta da instância de banco de dados para clusters de banco de dados Aurora em uma VPC, você usa um grupo de segurança da VPC. Para autenticar logins e permissões para um cluster de banco de dados Aurora, você pode adotar a mesma abordagem de uma instância de banco de dados independente do MySQL ou do PostgreSQL, ou pode usar a autenticação do banco de dados do IAM para a edição compatível com o Aurora MySQL. Com essa última abordagem, você se autentica em seu cluster de banco de dados compatível com o Aurora MySQL usando uma função do IAM e um token de autenticação.

Amazon S3

O Amazon S3 é um serviço de armazenamento de objetos que oferece escalabilidade, disponibilidade de dados, segurança e desempenho líderes do setor. É a espinha dorsal de dados de muitos aplicativos criados na AWS, e as permissões e os controles de segurança apropriados são essenciais para proteger dados confidenciais. Para obter as melhores práticas de segurança recomendadas para o Amazon S3, consulte a documentação, palestras técnicas on-line e análises mais detalhadas nas postagens do blog. A melhor prática mais importante é bloquear o acesso excessivamente permissivo (especialmente o acesso público) aos buckets do S3.

AWS KMS

O AWS SRA ilustra o modelo de distribuição recomendado para o gerenciamento de chaves, em que a chave KMS reside na mesma conta da AWS que o recurso a ser criptografado. Por esse motivo, o AWS KMS é usado na conta do aplicativo, além de ser incluído na conta do Security Tooling. Na conta do aplicativo, o AWS KMS é usado para gerenciar chaves específicas para os recursos do aplicativo. Você pode implementar uma separação de tarefas usando políticas de chaves para conceder permissões de uso de chaves às funções locais do aplicativo e restringir as permissões de gerenciamento e monitoramento aos seus principais guardiões. 

Consideração do design

• Em um modelo distribuído, a responsabilidade pelo gerenciamento de chaves do AWS KMS é da equipe de aplicação. No entanto, sua equipe central de segurança pode ser responsável pela governança e pelo monitoramento de eventos criptográficos importantes, como os seguintes:

  • O material da chave importada em uma chave do KMS está próximo da data de validade.

  • O material de chave em uma chave do KMS foi alternado automaticamente.

  • Uma chave do KMS foi excluída.

  • Há uma alta taxa de falha na decodificação.

AWS CloudHSM

O AWS CloudHSM fornece módulos gerenciados de segurança de hardware (HSMs) na nuvem da AWS. Ele permite que você gere e use suas próprias chaves de criptografia na AWS usando HSMs validados pelo FIPS 140-2 de nível 3 aos quais você controla o acesso. Você pode usar o CloudHSM para descarregar o processamento SSL/TLS para seus servidores web. Isso reduz a carga sobre o servidor web e fornece segurança extra ao armazenar a chave privada do servidor web no CloudHSM. Da mesma forma, você pode implantar um HSM do CloudHSM na VPC de entrada na conta de rede para armazenar suas chaves privadas e assinar solicitações de certificado se precisar atuar como autoridade de certificação emissora. 

Consideração do design

• Se você tem um requisito rígido para o FIPS 140-2 nível 3, você também pode optar por configurar o AWS KMS para usar o cluster CloudHSM como um armazenamento de chaves personalizado em vez de usar o armazenamento de chaves KMS nativo. Ao fazer isso, você se beneficia da integração entre o AWS KMS e os serviços da AWS que criptografam seus dados, além de ser responsável pelos HSMs que protegem suas chaves do KMS. Isso combina HSMs de inquilino único sob seu controle com a facilidade de uso e integração do AWS KMS. Para gerenciar sua infraestrutura do CloudHSM, você precisa empregar uma infraestrutura de chave pública (PKI) e ter uma equipe com experiência no gerenciamento de HSMs.

AWS Secrets Manager

O AWS Secrets Manager ajuda você a proteger as credenciais (segredos) de que você precisa para acessar seus aplicativos, serviços e recursos de TI. O serviço permite que você alterne, gerencie e recupere com eficiência as credenciais do banco de dados, as chaves de API e outros segredos durante todo o ciclo de vida. Você pode substituir as credenciais codificadas em seu código por uma chamada de API para o Secrets Manager para recuperar o segredo programaticamente. Isso ajuda a garantir que o segredo não possa ser comprometido por alguém que esteja examinando seu código, porque o segredo não existe mais no código. Além disso, o Secrets Manager ajuda você a mover seus aplicativos entre ambientes (desenvolvimento, pré-produção, produção). Em vez de alterar o código, você pode garantir que um segredo devidamente nomeado e referenciado esteja disponível no ambiente. Isso promove a consistência e a reutilização do código do aplicativo em diferentes ambientes, ao mesmo tempo em que exige menos alterações e interações humanas após o teste do código. 

Com o Secrets Manager, você pode gerenciar o acesso aos segredos usando políticas de IAM refinadas e políticas baseadas em recursos. Você pode ajudar a proteger segredos criptografando-os com chaves de criptografia que você gerencia usando o AWS KMS. O Secrets Manager também se integra aos serviços de registro e monitoramento da AWS para auditoria centralizada. 

O Secrets Manager usa criptografia de envelope com chaves de dados e chaves de dados do AWS KMS para proteger cada valor secreto. Ao criar um segredo, você pode escolher qualquer chave simétrica gerenciada pelo cliente na conta e na região da AWS, ou você pode usar a chave gerenciada da AWS para o Secrets Manager. 

Como prática recomendada, você pode monitorar seus segredos para registrar quaisquer alterações neles. Isso ajuda a garantir que qualquer uso ou alteração inesperada possa ser investigada. Alterações indesejadas podem ser revertidas. Atualmente, o Secrets Manager oferece suporte a dois serviços da AWS que permitem monitorar sua organização e atividade: AWS CloudTrail e AWS Config. CloudTrail captura todas as chamadas de API para o Secrets Manager como eventos, incluindo chamadas do console do Secrets Manager e de chamadas de código para as APIs do Secrets Manager. Além disso, CloudTrail captura outros eventos relacionados (não relacionados à API) que podem ter um impacto na segurança ou na conformidade em sua conta da AWS ou podem ajudá-lo a solucionar problemas operacionais. Isso inclui certos eventos de rotação de segredos e exclusão de versões secretas. O AWS Config pode fornecer controles de detetive rastreando e monitorando alterações nos segredos no Secrets Manager. Essas mudanças incluem a descrição do segredo, a configuração de rotação, as tags e o relacionamento com outras fontes da AWS, como a chave de criptografia do KMS ou as funções do AWS Lambda usadas para rotação secreta. Você também pode configurar a Amazon EventBridge, que recebe notificações de alteração de configuração e conformidade do AWS Config, para rotear eventos secretos específicos para ações de notificação ou remediação. 

No AWS SRA, o Secrets Manager está localizado na conta do aplicativo para oferecer suporte a casos de uso de aplicativos locais e gerenciar segredos próximos ao seu uso. Aqui, um perfil de instância é anexado às instâncias do EC2 na conta do aplicativo. Segredos separados podem então ser configurados no Secrets Manager para permitir que esse perfil de instância recupere segredos — por exemplo, para ingressar no domínio apropriado do Active Directory ou LDAP e acessar o banco de dados Aurora. O Secrets Manager se integra ao Amazon RDS para gerenciar as credenciais do usuário quando você cria, modifica ou restaura uma instância de banco de dados Amazon RDS ou um cluster de banco de dados Multi-AZ. Isso ajuda você a gerenciar a criação e a rotação de chaves e substitui as credenciais codificadas em seu código por chamadas programáticas de API para o Secrets Manager.

Consideração do design

• Em geral, configure e gerencie o Secrets Manager na conta mais próxima de onde os segredos serão usados. Essa abordagem aproveita o conhecimento local do caso de uso e fornece velocidade e flexibilidade às equipes de desenvolvimento de aplicativos. Para informações rigorosamente controladas, nas quais uma camada adicional de controle pode ser apropriada, os segredos podem ser gerenciados centralmente pelo Secrets Manager na conta do Security Tooling.

Amazon Cognito

O Amazon Cognito permite que você adicione cadastro, login e controle de acesso de usuários aos seus aplicativos web e móveis de forma rápida e eficiente. O Amazon Cognito é escalável para milhões de usuários e oferece suporte ao login com provedores de identidade social, como Apple, Facebook, Google e Amazon, e provedores de identidade corporativa por meio do SAML 2.0 e do OpenID Connect. Os dois principais componentes do Amazon Cognito são grupos de usuários e grupos de identidades. Os grupos de usuários são diretórios de usuários que fornecem opções de inscrição e login para os usuários do seu aplicativo. Os grupos de identidade permitem que você conceda aos usuários acesso a outros serviços da AWS. Você pode usar grupos de identidades e grupos de usuários separadamente ou em conjunto. Para cenários de uso comuns, consulte a documentação do Amazon Cognito.

O Amazon Cognito fornece uma interface de usuário integrada e personalizável para cadastro e login de usuários. Você pode usar Android, iOS e JavaScript SDKs para o Amazon Cognito para adicionar páginas de cadastro e login de usuários aos seus aplicativos. O Amazon Cognito Sync é um serviço e uma biblioteca de clientes da AWS que permite a sincronização entre dispositivos de dados de usuários relacionados a aplicativos.  

O Amazon Cognito oferece suporte à autenticação multifatorial e à criptografia de dados em repouso e dados em trânsito. Os grupos de usuários do Amazon Cognito fornecem recursos de segurança avançados para ajudar a proteger o acesso às contas em seu aplicativo. Esses recursos avançados de segurança fornecem autenticação adaptativa baseada em risco e proteção contra o uso de credenciais comprometidas.  

Considerações sobre design

• Você pode criar uma função do AWS Lambda e, em seguida, acionar essa função durante as operações do grupo de usuários, como cadastro, confirmação e login (autenticação) do usuário com um gatilho do AWS Lambda. Você pode adicionar desafios de autenticação, migrar usuários e personalizar mensagens de verificação. Para operações comuns e fluxo de usuários, consulte a documentação do Amazon Cognito. O Amazon Cognito chama as funções do Lambda de forma síncrona. 

• Você pode usar grupos de usuários do Amazon Cognito para proteger aplicativos pequenos e multilocatários. Um caso de uso comum do design multilocatário é executar cargas de trabalho para dar suporte ao teste de várias versões de um aplicativo. O projeto de vários locatários também é útil para testar uma única aplicação com diferentes conjuntos de dados, o que permite o uso completo dos seus recursos de cluster. No entanto, certifique-se de que o número de inquilinos e o volume esperado estejam alinhados com as cotas de serviço relacionadas do Amazon Cognito. Essas cotas são compartilhadas entre todos os locatários da aplicação.

Amazon Verified Permissions

O Amazon Verified Permissions é um serviço de gerenciamento de permissões escalável e de autorização refinado para os aplicativos que você cria. Desenvolvedores e administradores podem usar o Cedar, uma linguagem de políticas de código aberto criada especificamente e que prioriza a segurança, com funções e atributos para definir controles de acesso mais granulares, contextuais e baseados em políticas. Os desenvolvedores podem criar aplicativos mais seguros com mais rapidez externalizando a autorização e centralizando o gerenciamento e a administração de políticas. As permissões verificadas incluem definições de esquema, gramática de declarações de política e raciocínio automatizado que abrangem milhões de permissões, para que você possa aplicar os princípios de negação padrão e privilégio mínimo. O serviço também inclui uma ferramenta de simulador de avaliação para ajudá-lo a testar suas decisões de autorização e políticas de autores. Esses recursos facilitam a implantação de um modelo de autorização detalhado e refinado para apoiar seus objetivos de confiança zero. As Permissões Verificadas centralizam as permissões em um repositório de políticas e ajudam os desenvolvedores a usar essas permissões para autorizar ações do usuário em seus aplicativos.

Você pode conectar seu aplicativo ao serviço por meio da API para autorizar as solicitações de acesso do usuário. Para cada solicitação de autorização, o serviço recupera as políticas relevantes e avalia essas políticas para determinar se um usuário tem permissão para realizar uma ação em um recurso, com base nas entradas de contexto, como usuários, funções, associação ao grupo e atributos. Você pode configurar e conectar Permissões verificadas para enviar seus registros de autorização e gerenciamento de políticas para a AWS CloudTrail. Se você usa o Amazon Cognito como seu repositório de identidade, você pode se integrar às Permissões Verificadas e usar o ID e os tokens de acesso que o Amazon Cognito retorna nas decisões de autorização em seus aplicativos. Você fornece tokens do Amazon Cognito para Permissões Verificadas, que usam os atributos que os tokens contêm para representar o principal e identificar os direitos do principal. Para obter mais informações sobre essa integração, consulte a postagem do blog da AWS Simplificando a autorização refinada com as Permissões Verificadas da Amazon e o Amazon Cognito.

As permissões verificadas ajudam você a definir o controle de acesso baseado em políticas (PBAC). O PBAC é um modelo de controle de acesso que usa permissões expressas como políticas para determinar quem pode acessar quais recursos em um aplicativo. O PBAC reúne controle de acesso baseado em função (RBAC) e controle de acesso baseado em atributos (ABAC), resultando em um modelo de controle de acesso mais poderoso e flexível. Para saber mais sobre o PBAC e como você pode criar um modelo de autorização usando permissões verificadas, consulte a postagem do blog da AWS Controle de acesso baseado em políticas no desenvolvimento de aplicativos com Amazon Verified Permissions.

No AWS SRA, as permissões verificadas estão localizadas na conta do aplicativo para oferecer suporte ao gerenciamento de permissões para aplicativos por meio de sua integração com o Amazon Cognito.

Defesa em camadas

A conta do aplicativo oferece uma oportunidade de ilustrar os princípios de defesa em camadas que a AWS possibilita. Considere a segurança das instâncias do EC2 que compõem o núcleo de um aplicativo de exemplo simples representado no AWS SRA e você poderá ver como os serviços da AWS funcionam juntos em uma defesa em camadas. Essa abordagem se alinha à visão estrutural dos serviços de segurança da AWS, conforme descrito na seção Aplicar serviços de segurança em toda a sua organização da AWS, anteriormente neste guia.

• A camada mais interna são as instâncias do EC2. Conforme mencionado anteriormente, as instâncias do EC2 incluem muitos recursos de segurança nativos por padrão ou como opções. Os exemplos incluem o IMDSv2, o sistema Nitro e a criptografia de armazenamento Amazon EBS.

• A segunda camada de proteção se concentra no sistema operacional e no software em execução nas instâncias do EC2. Serviços como o Amazon Inspector e o AWS Systems Manager permitem que você monitore, relate e tome medidas corretivas nessas configurações. O Inspector monitora vulnerabilidades em seu software e o Systems Manager ajuda você a trabalhar para manter a segurança e a conformidade examinando as instâncias gerenciadas quanto ao status de patch e configuração e, em seguida, relatando e tomando as ações corretivas que você especificar.

• As instâncias e o software executado nessas instâncias fazem parte da sua infraestrutura de rede da AWS. Além de usar os recursos de segurança da Amazon VPC, a AWS SRA também usa endpoints de VPC para fornecer conectividade privada entre a VPC e os serviços compatíveis da AWS, além de fornecer um mecanismo para colocar políticas de acesso no limite da rede.

• A atividade e a configuração das instâncias do EC2, do software, da rede e das funções e recursos do IAM são monitoradas ainda mais pelos serviços focados na conta da AWS, como AWS Security Hub, Amazon, GuardDuty AWS, AWS CloudTrail Config, AWS IAM Access Analyzer e Amazon Macie.

• Por fim, além da conta do aplicativo, a AWS RAM ajuda a controlar quais recursos são compartilhados com outras contas, e as políticas de controle de serviços do IAM ajudam você a aplicar permissões consistentes em toda a organização da AWS.