As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Conta de segurança OU — Log Archive
| 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 Log Archive.
A conta Log Archive é dedicada à ingestão e arquivamento de todos os registros e backups relacionados à segurança. Com registros centralizados, você pode monitorar, auditar e alertar sobre o acesso a objetos do Amazon S3, atividades não autorizadas por identidades, mudanças na política do IAM e outras atividades críticas realizadas em recursos confidenciais. Os objetivos de segurança são simples: esse armazenamento deve ser imutável, acessado somente por mecanismos controlados, automatizados e monitorados, e criado para oferecer durabilidade (por exemplo, usando os processos apropriados de replicação e arquivamento). Os controles podem ser implementados em profundidade para proteger a integridade e a disponibilidade dos registros e do processo de gerenciamento de registros. Além dos controles preventivos, como atribuir funções de menor privilégio a serem usadas para acessar e criptografar registros com uma chave controlada do AWS KMS, use controles de detetive, como o AWS Config, para monitorar (alertar e corrigir) essa coleção de permissões em caso de alterações inesperadas.
Consideração do design
-
Os dados de registro operacional usados por suas equipes de infraestrutura, operações e carga de trabalho geralmente se sobrepõem aos dados de registro usados pelas equipes de segurança, auditoria e conformidade. Recomendamos que você consolide seus dados operacionais de registro na conta do Log Archive. Com base em seus requisitos específicos de segurança e governança, talvez seja necessário filtrar os dados de registro operacionais salvos nessa conta. Talvez você também precise especificar quem tem acesso aos dados de registro operacionais na conta do Log Archive.
Tipos de registros
Os principais registros mostrados no AWS SRA incluem CloudTrail (trilha da organização), registros de fluxo do Amazon VPC, registros de acesso da CloudFront Amazon e do AWS WAF e registros de DNS do Amazon Route 53. Esses registros fornecem uma auditoria das ações tomadas (ou tentadas) por um usuário, função, serviço da AWS ou entidade de rede (identificadas, por exemplo, por um endereço IP). Outros tipos de registro (por exemplo, registros de aplicativos ou registros de banco de dados) também podem ser capturados e arquivados. Para obter mais informações sobre fontes de log e melhores práticas de registro, consulte a documentação de segurança de cada serviço.
Amazon S3 como armazenamento central de registros
Muitos serviços da AWS registram informações no Amazon S3, seja por padrão ou exclusivamente. AWS CloudTrail, Amazon VPC Flow Logs, AWS Config e Elastic Load Balancing são alguns exemplos de serviços que registram informações no Amazon S3. Isso significa que a integridade do log é obtida por meio da integridade do objeto do S3; a confidencialidade do log é obtida por meio dos controles de acesso a objetos do S3; e a disponibilidade do log é obtida por meio do S3 Object Lock, das versões do objeto do S3 e das regras do ciclo de vida do S3. Ao registrar as informações em um bucket S3 dedicado e centralizado que reside em uma conta dedicada, você pode gerenciar esses registros em apenas alguns buckets e aplicar controles rígidos de segurança, acesso e separação de tarefas.
No AWS SRA, os registros primários armazenados no Amazon S3 CloudTrail vêm de, portanto, esta seção descreve como proteger esses objetos. Essa orientação também se aplica a qualquer outro objeto do S3 criado por seus próprios aplicativos ou por outros serviços da AWS. Aplique esses padrões sempre que tiver dados no Amazon S3 que precisem de alta integridade, forte controle de acesso e retenção ou destruição automatizada.
Todos os novos objetos (incluindo CloudTrail registros) que são enviados para buckets do S3 são criptografados por padrão usando a criptografia do lado do servidor da Amazon com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3). Isso ajuda a proteger os dados em repouso, mas o controle de acesso é controlado exclusivamente pelas políticas do IAM. Para fornecer uma camada adicional de segurança gerenciada, você pode usar a criptografia do lado do servidor com as chaves do AWS KMS que você gerencia (SSE-KMS) em todos os buckets de segurança do S3. Isso adiciona um segundo nível de controle de acesso. Para ler arquivos de log, o usuário deve ter as permissões de leitura do Amazon S3 para o objeto do S3 e uma política ou função do IAM aplicada que permita a decodificação de acordo com a política de chave associada.
Duas opções ajudam você a proteger ou verificar a integridade dos objetos de CloudTrail log armazenados no Amazon S3. CloudTrail fornece validação da integridade do arquivo de log para determinar se um arquivo de log foi modificado ou excluído após a CloudTrail entrega. A outra opção é o S3 Object Lock.
Além de proteger o próprio bucket do S3, você pode seguir o princípio do privilégio mínimo para os serviços de registro (por exemplo, CloudTrail) e a conta do Log Archive. Por exemplo, usuários com permissões concedidas pela política de IAM gerenciada pela AWS AWSCloudTrail_FullAccess podem desativar ou reconfigurar as funções de auditoria mais confidenciais e importantes em suas contas da AWS. Limite a aplicação dessa política do IAM ao menor número possível de pessoas.
Use controles de detetive, como os fornecidos pelo AWS Config e pelo AWS IAM Access Analyzer, para monitorar (e alertar e remediar) esse coletivo mais amplo de controles preventivos para mudanças inesperadas.
Para uma discussão mais aprofundada sobre as melhores práticas de segurança para buckets do S3, consulte a documentação do Amazon S3, as palestras técnicas on-line
Exemplo de implementação
A biblioteca de códigos do AWS SRA
Amazon Security Lake
A AWS SRA recomenda que você use a conta Log Archive como a conta de administrador delegado para o Amazon Security Lake. Quando você faz isso, o Security Lake coleta registros compatíveis em buckets S3 dedicados na mesma conta que outros registros de segurança recomendados pela SRA.
Para proteger a disponibilidade dos registros e do processo de gerenciamento de registros, os buckets S3 do Security Lake devem ser acessados somente pelo serviço Security Lake ou pelas funções do IAM gerenciadas pelo Security Lake para fontes ou assinantes. Além de usar controles preventivos, como atribuir funções de menor privilégio para acesso e criptografar registros com uma chave controlada do AWS Key Management Services (AWS KMS), use controles de detetive, como o AWS Config, para monitorar (alertar e corrigir) essa coleção de permissões em caso de alterações inesperadas.
O administrador do Security Lake pode habilitar a coleta de registros em toda a sua organização da AWS. Esses registros são armazenados em buckets regionais do S3 na conta do Log Archive. Além disso, para centralizar os registros e facilitar o armazenamento e a análise, o administrador do Security Lake pode escolher uma ou mais regiões cumulativas nas quais os registros de todos os buckets regionais do S3 são consolidados e armazenados. Os registros dos serviços compatíveis da AWS são automaticamente convertidos em um esquema padronizado de código aberto chamado Open Cybersecurity Schema Framework (OCSF) e salvos no formato Apache Parquet nos buckets do Security Lake S3. Com o suporte do OCSF, o Security Lake normaliza e consolida com eficiência os dados de segurança da AWS e de outras fontes de segurança corporativa para criar um repositório unificado e confiável de informações relacionadas à segurança.
O Security Lake pode coletar registros associados a eventos de CloudTrail gerenciamento e CloudTrail dados da AWS para o Amazon S3 e o AWS Lambda. Para coletar eventos CloudTrail de gerenciamento no Security Lake, você deve ter pelo menos uma trilha CloudTrail organizacional multirregional que colete eventos de CloudTrail gerenciamento de leitura e gravação. O registro deve estar ativado para a trilha. Uma trilha multirregional entrega arquivos de log de várias regiões para um único bucket S3 para uma única conta da AWS. Se as regiões estiverem em países diferentes, considere os requisitos de exportação de dados para determinar se as trilhas multirregionais podem ser habilitadas.
O AWS Security Hub é uma fonte de dados nativa compatível com o Security Lake, e você deve adicionar as descobertas do Security Hub ao Security Lake. O Security Hub gera descobertas de vários serviços diferentes da AWS e integrações de terceiros. Essas descobertas ajudam você a ter uma visão geral da sua postura de conformidade e se você está seguindo as recomendações de segurança da AWS e das soluções de parceiros da AWS.
Para obter visibilidade e insights acionáveis de registros e eventos, você pode consultar os dados usando ferramentas como Amazon Athena, Amazon Service, OpenSearch Amazon Quicksight e soluções de terceiros. Os usuários que precisam acessar os dados de log do Security Lake não devem acessar diretamente a conta do Log Archive. Eles devem acessar os dados somente da conta do Security Tooling. Ou eles podem usar outras contas da AWS ou locais locais que fornecem ferramentas de análise, como OpenSearch Serviço, ou ferramentas de terceiros QuickSight, como ferramentas de gerenciamento de eventos e informações de segurança (SIEM). Para fornecer acesso aos dados, o administrador deve configurar os assinantes do Security Lake na conta do Log Archive e configurar a conta que precisa acessar os dados como assinante de acesso a consultas. Para obter mais informações, consulte Amazon Security Lake na seção Security OU — Security Tooling account deste guia.
O Security Lake fornece uma política gerenciada pela AWS para ajudar você a gerenciar o acesso do administrador ao serviço. Para obter mais informações, consulte o Guia do usuário do Security Lake. Como prática recomendada, recomendamos que você restrinja a configuração do Security Lake por meio de pipelines de desenvolvimento e evite alterações na configuração por meio dos consoles da AWS ou da AWS Command Line Interface (AWS CLI). Além disso, você deve configurar políticas rígidas de IAM e políticas de controle de serviço (SCPs) para fornecer somente as permissões necessárias para gerenciar o Security Lake. Você pode configurar notificações para detectar qualquer acesso direto a esses buckets do S3.
