Partilhar via

Controle de segurança: registro e deteção de ameaças

O Registo e Deteção de Ameaças abrange controlos para detetar ameaças na nuvem e ativar, recolher e armazenar registos de auditoria para serviços na nuvem, incluindo a ativação de processos de deteção, investigação e correção com controlos para gerar alertas de alta qualidade com deteção de ameaças nativas em serviços na nuvem; também inclui a coleta de logs com um serviço de monitoramento em nuvem, centralização da análise de segurança com um SIEM, sincronização de tempo e retenção de logs.

LT-1: Habilite os recursos de deteção de ameaças

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8.11 AU-3, AU-6, AU-12, SI-4 10.6, 10.8, A3.5

Princípio de segurança: Para dar suporte a cenários de deteção de ameaças, monitore todos os tipos de recursos conhecidos em busca de ameaças e anomalias conhecidas e esperadas. Configure suas regras de filtragem e análise de alertas para extrair alertas de alta qualidade de dados de log, agentes ou outras fontes de dados para reduzir falsos positivos.

Orientação do Azure: use o recurso de deteção de ameaças do Microsoft Defender for Cloud para os respetivos serviços do Azure.

Para deteção de ameaças não incluídas nos serviços do Microsoft Defender, consulte as linhas de base do serviço Microsoft Cloud Security Benchmark para os respetivos serviços para habilitar os recursos de deteção de ameaças ou alerta de segurança dentro do serviço. Ingerir alertas e dados de log do Microsoft Defender for Cloud, Microsoft 365 Defender e registrar dados de outros recursos em suas instâncias do Azure Monitor ou do Microsoft Sentinel para criar regras de análise, que detetam ameaças e criam alertas que correspondem a critérios específicos em seu ambiente.

Para ambientes de Tecnologia Operacional (OT) que incluem computadores que controlam ou monitoram recursos do Sistema de Controle Industrial (ICS) ou do Controle de Supervisão e Aquisição de Dados (SCADA), use o Microsoft Defender for IoT para inventariar ativos e detetar ameaças e vulnerabilidades.

Para serviços que não têm um recurso nativo de deteção de ameaças, considere coletar os logs do plano de dados e analisar as ameaças por meio do Microsoft Sentinel.

Implementação do Azure e contexto adicional:

Orientação da AWS: use o Amazon GuardDuty para deteção de ameaças, que analisa e processa as seguintes fontes de dados: VPC Flow Logs, logs de eventos de gerenciamento do AWS CloudTrail, logs de eventos de dados do CloudTrail S3, logs de auditoria EKS e logs DNS. O GuardDuty é capaz de relatar problemas de segurança, como escalonamento de privilégios, uso de credenciais expostas ou comunicação com endereços IP ou domínios mal-intencionados.

Configure o AWS Config para verificar regras no SecurityHub para monitoramento de conformidade, como desvio de configuração, e crie descobertas quando necessário.

Para deteção de ameaças não incluídas no GuardDuty e no SecurityHub, habilite os recursos de deteção de ameaças ou alerta de segurança nos serviços compatíveis da AWS. Extraia os alertas para o CloudTrail, CloudWatch ou Microsoft Sentinel para criar regras de análise, que caçam ameaças que correspondem a critérios específicos em todo o seu ambiente.

Você também pode usar o Microsoft Defender for Cloud para monitorar determinados serviços na AWS, como instâncias do EC2.

Para ambientes de Tecnologia Operacional (OT) que incluem computadores que controlam ou monitoram recursos do Sistema de Controle Industrial (ICS) ou do Controle de Supervisão e Aquisição de Dados (SCADA), use o Microsoft Defender for IoT para inventariar ativos e detetar ameaças e vulnerabilidades.

Implementação da AWS e contexto adicional:

Orientação do GCP: Use Detecção de Ameaças de Eventos no Centro de Comando de Segurança na Google Cloud para a deteção de ameaças utilizando dados de registo, como Atividade do Administrador, Acesso a Dados GKE, Registos de Fluxo da VPC, DNS na Nuvem e Registos de Firewall.

Além disso, use o pacote de operações de segurança para o SOC moderno com Chronicle, SIEM e SOAR. O Chronicle SIEM e o SOAR fornecem recursos de deteção, investigação e caça de ameaças

Você também pode usar o Microsoft Defender for Cloud para monitorar determinados serviços no GCP, como instâncias de VM de computação.

Para ambientes de Tecnologia Operacional (OT) que incluem computadores que controlam ou monitoram recursos do Sistema de Controle Industrial (ICS) ou do Controle de Supervisão e Aquisição de Dados (SCADA), use o Microsoft Defender for IoT para inventariar ativos e detetar ameaças e vulnerabilidades.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

LT-2: Habilite a deteção de ameaças para gerenciamento de identidade e acesso

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8.11 AU-3, AU-6, AU-12, SI-4 10.6, 10.8, A3.5

Princípio de segurança: Detete ameaças para identidades e gerenciamento de acesso monitorando as anomalias de entrada e acesso do usuário e do aplicativo. Padrões comportamentais, como número excessivo de tentativas de login com falha e contas obsoletas na assinatura, devem ser sinalizados.

Orientação do Azure: o Azure AD fornece os seguintes logs que podem ser exibidos nos relatórios do Azure AD ou integrados ao Azure Monitor, Microsoft Sentinel ou outras ferramentas de SIEM/monitoramento para casos de uso de monitoramento e análise mais sofisticados:

  • Entradas: o relatório de entradas fornece informações sobre o uso de aplicativos gerenciados e atividades de entrada do usuário.
  • Logs de auditoria: fornece rastreabilidade por intermédio de registos para todas as alterações feitas por diferentes funcionalidades no Azure AD. Exemplos de logs de auditoria incluem alterações feitas em quaisquer recursos no Azure AD, como adicionar ou remover usuários, aplicativos, grupos, funções e políticas.
  • Entradas arriscadas: um início de sessão arriscado é um indicador de uma tentativa de início de sessão que pode ter sido realizada por alguém que não é o proprietário legítimo de uma conta de utilizador.
  • Usuários sinalizados para risco: um usuário arriscado é um indicador para uma conta de usuário que pode ter sido comprometida.

O Azure AD também fornece um módulo de Proteção de Identidade para detetar e corrigir riscos relacionados a contas de usuário e comportamentos de entrada. Exemplos de riscos incluem credenciais vazadas, login de endereços IP anônimos ou vinculados a malware, pulverização de senha. As políticas no Azure AD Identity Protection permitem que você imponha a autenticação MFA baseada em risco em conjunto com o Acesso Condicional do Azure em contas de usuário.

Além disso, o Microsoft Defender for Cloud pode ser configurado para alertar sobre contas preteridas na assinatura e atividades suspeitas, como um número excessivo de tentativas de autenticação com falha. Além do monitoramento básico de higiene de segurança, o módulo de Proteção contra Ameaças do Microsoft Defender for Cloud também pode coletar alertas de segurança mais detalhados de recursos de computação individuais do Azure (como máquinas virtuais, contêineres, serviço de aplicativo), recursos de dados (como Banco de Dados SQL e armazenamento) e camadas de serviço do Azure. Esse recurso permite que você veja anomalias de conta dentro dos recursos individuais.

Observação: Se estiveres a ligar o teu Active Directory local para sincronização, utiliza a solução "Microsoft Defender for Identity" para consumir os teus sinais do Active Directory local para identificar, detectar e investigar ameaças avançadas, identidades comprometidas e ações internas maliciosas direcionadas à tua organização.

Implementação do Azure e contexto adicional:

Orientação da AWS: O AWS IAM fornece os seguintes relatórios de logs e relatórios de atividades do usuário do console por meio do IAM Access Advisor e do relatório de credenciais do IAM:

  • Todas as tentativas de início de sessão bem-sucedidas e tentativas de início de sessão malsucedidas.
  • Status de autenticação multifator (MFA) para cada usuário.
  • Utilizador adormecido do IAM

Para monitoramento de acesso em nível de API e deteção de ameaças, use o Amazon GuadDuty para identificar as descobertas relacionadas ao IAM. Exemplos dessas constatações incluem:

  • Uma API usada para obter acesso a um ambiente da AWS e foi invocada de forma anômala ou foi usada para evitar medidas defensivas
  • Uma API usada para:
    • A Discover Resources foi invocada de forma anómala
    • A coleta de dados de um ambiente da AWS foi invocada de forma anómala.
    • a adulteração de dados ou processos em um ambiente AWS foi invocada de forma anómala.
    • obter acesso não autorizado a um ambiente da AWS foi invocado de forma anômala.
    • manter o acesso não autorizado a um ambiente da AWS foi invocado de forma anômala.
    • A obtenção de permissões de alto nível para um ambiente da AWS foi invocada de forma anómala.
    • ser invocado a partir de um endereço IP malicioso conhecido.
    • ser invocado usando credenciais de root.
  • O registro em log do AWS CloudTrail foi desativado.
  • A política de senha da conta foi enfraquecida.
  • Vários logins de console bem-sucedidos em todo o mundo foram observados.
  • As credenciais que foram criadas exclusivamente para uma instância do EC2 por meio de uma função de execução de instância estão sendo usadas de outra conta na AWS.
  • As credenciais que foram criadas exclusivamente para uma instância do EC2 por meio de uma função de execução de instância estão sendo usadas a partir de um endereço IP externo.
  • Uma API foi invocada a partir de um endereço IP mal-intencionado conhecido.
  • Uma API foi invocada a partir de um endereço IP em uma lista de ameaças personalizada.
  • A partir de um endereço IP de nó de saída Tor, uma API foi invocada.

Implementação da AWS e contexto adicional:

Orientação do GCP: Utilize a Deteção de Ameaças de Eventos no Centro de Comando de Segurança do Google Cloud para determinados tipos de detecção de ameaças relacionadas ao IAM, como a deteção de eventos em que uma conta de serviço gerida pelo utilizador, que estava inativa, recebeu uma ou mais funções sensíveis do IAM.

Esteja ciente de que os registos de identidade do Google e os registos IAM do Google Cloud produzem ambos logs de actividades do administrador, mas para escopos diferentes. Os logs de identidade do Google são apenas para operações que correspondem ao Identity Platform, enquanto os logs do IAM são para operações que correspondem ao IAM para Google Cloud. Os logs do IAM contêm entradas de log de chamadas de API ou outras ações que modificam a configuração ou os metadados dos recursos. Por exemplo, esses logs registram quando os usuários criam instâncias de VM ou alteram as permissões de Gerenciamento de Identidade e Acesso.

Use o Cloud Identity e os relatórios do IAM para alertar sobre determinados padrões de atividade suspeitos. Você também pode usar o Policy Intelligence para analisar as atividades das contas de serviço para identificar atividades como contas de serviço em seu projeto que não foram usadas nos últimos 90 dias.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

LT-3: Ativar o registo para investigação de segurança

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.12 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3

Princípio de segurança: habilite o registro em log para seus recursos de nuvem para atender aos requisitos para investigações de incidentes de segurança e fins de resposta e conformidade de segurança.

Orientação do Azure: ative a capacidade de registo para recursos nos diferentes níveis, tais como registos para recursos do Azure, sistemas operativos e aplicações nas suas VMs e outros tipos de registo.

Esteja atento aos diferentes tipos de logs para segurança, auditoria e outros logs operacionais no plano de gerenciamento/controle e nas camadas do plano de dados. Há três tipos de logs disponíveis na plataforma Azure:

  • Log de recursos do Azure: log de operações executadas em um recurso do Azure (o plano de dados). Por exemplo, obter um segredo de um cofre de chaves ou fazer uma solicitação a um banco de dados. O conteúdo dos logs de recursos varia de acordo com o serviço do Azure e o tipo de recurso.
  • Log de atividades do Azure: registro em log de operações em cada recurso do Azure na camada de assinatura, do lado de fora (o plano de gerenciamento). Você pode usar o Registro de atividades para determinar o quê, quem e quando para quaisquer operações de gravação (PUT, POST, DELETE) realizadas nos recursos da sua assinatura. Há um único log de atividades para cada assinatura do Azure.
  • Logs do Azure Active Directory: registos do histórico de atividades de início de sessão e trilha de auditoria das alterações feitas no Azure Active Directory para um inquilino específico.

Você também pode usar o Microsoft Defender for Cloud e o Azure Policy para habilitar logs de recursos e coleta de dados de log em recursos do Azure.

Implementação do Azure e contexto adicional:

Orientação da AWS: use o registro em log do AWS CloudTrail para eventos de gerenciamento (operações de plano de controle) e eventos de dados (operações de plano de dados) e monitore essas trilhas com o CloudWatch para ações automatizadas.

O serviço Amazon CloudWatch Logs permite coletar e armazenar logs de seus recursos, aplicativos e serviços quase em tempo real. Existem três categorias principais de logs:

  • Vended logs: logs publicados nativamente pelos serviços da AWS em seu nome. Atualmente, os logs de fluxo da Amazon VPC e os logs do Amazon Route 53 são os dois tipos suportados. Esses dois logs são habilitados por padrão.
  • Logs publicados pelos serviços da AWS: os logs de mais de 30 serviços da AWS são publicados no CloudWatch. Eles incluem Amazon API Gateway, AWS Lambda, AWS CloudTrail e muitos outros. Esses logs podem ser ativados diretamente nos serviços e no CloudWatch.
  • Logs personalizados: logs de seu próprio aplicativo e recursos locais. Talvez seja necessário coletar esses logs instalando o CloudWatch Agent em seus sistemas operacionais e encaminhá-los para o CloudWatch.

Embora muitos serviços publiquem logs apenas no CloudWatch Logs, alguns serviços da AWS podem publicar logs diretamente no AmazonS3 ou no Amazon Kinesis Data Firehose, onde você pode usar diferentes políticas de armazenamento e retenção de logs.

Implementação da AWS e contexto adicional:

Orientação do GCP: Ative a capacidade de registo para recursos nas diferentes camadas, como registos para recursos do Azure, sistemas operativos e aplicações dentro das suas VMs e outros tipos de registo.

Esteja atento aos diferentes tipos de logs para segurança, auditoria e outros logs operacionais no plano de gerenciamento/controle e nas camadas do plano de dados. O serviço Operations Suite Cloud Logging coleta e agrega todos os tipos de eventos de log de camadas de recursos. Quatro categorias de logs são suportadas no Cloud Logging:

  • Logs da plataforma - logs gravados pelos seus serviços do Google Cloud.
  • Logs de componentes - semelhantes aos logs de plataforma, mas são logs gerados por componentes de software fornecidos pelo Google que são executados em seus sistemas.
  • Logs de segurança - principalmente logs de auditoria que registram atividades administrativas e acessos em seus recursos.
  • Escrito pelo usuário - logs escritos por aplicativos e serviços personalizados
  • Logs de várias nuvens e logs de nuvem híbrida - logs de outros provedores de nuvem, como o Microsoft Azure, e logs de infraestrutura local.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

LT-4: Habilitar o log de rede para investigação de segurança

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.6, 8.7, 13.6 AU-3, AU-6, AU-12, SI-4 10.8

Princípio de segurança: habilite o registro em log para seus serviços de rede para dar suporte a investigações de incidentes relacionados à rede, caça a ameaças e geração de alertas de segurança. Os logs de rede podem incluir logs de serviços de rede, como filtragem de IP, firewall de rede e de aplicações, DNS, monitorização de fluxo e assim por diante.

Orientação do Azure: habilite e colete logs de recursos do grupo de segurança de rede (NSG), logs de fluxo NSG, logs do Firewall do Azure e logs do firewall de aplicações web (WAF). Recorra ao agente de coleta de dados de tráfego de rede para a coleta de logs de máquinas virtuais, com vista à análise de segurança para dar suporte a investigações de incidentes e à geração de alertas de segurança. Você pode enviar os logs de fluxo para um espaço de trabalho do Azure Monitor Log Analytics e, em seguida, usar a Análise de Tráfego para fornecer informações.

Colete logs de consulta DNS para ajudar a correlacionar outros dados da rede.

Implementação do Azure e contexto adicional:

Orientação da AWS: habilite e colete logs de rede, como VPC Flow Logs, WAF Logs, e logs de consulta do Route53 Resolver, para análise de segurança que dê suporte a investigações de incidentes e geração de alertas de segurança. Os logs podem ser exportados para o CloudWatch para monitoramento ou um bucket de armazenamento do S3 para ingestão na solução Microsoft Sentinel para análise centralizada.

Implementação da AWS e contexto adicional:

Orientação do GCP: A maioria dos logs de atividades de rede está disponível por meio dos Logs de Fluxo da VPC, que registram uma amostra dos fluxos de rede enviados e recebidos pelos recursos, incluindo instâncias usadas como VMs do Google Compute e nós do Google Kubernetes Engine. Esses logs podem ser usados para monitoramento de rede, perícia, análise de segurança em tempo real e otimização de despesas.

Pode visualizar logs de fluxo no Cloud Logging e exportá-los para os destinos que a exportação do Cloud Logging suporta. Os logs de fluxo são agregados por conexão de VMs do Compute Engine e exportados em tempo real. Ao assinar o Pub/Sub, você pode analisar logs de fluxo usando APIs de streaming em tempo real.

Nota: Você também pode usar o Packet Mirroring para clonar o tráfego de instâncias especificadas na sua rede Virtual Private Cloud (VPC) e encaminhá-lo para examinação. O Packet Mirroring captura todo o tráfego e dados de pacotes, incluindo cargas úteis e cabeçalhos.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

LT-5: Centralize o gerenciamento e a análise de logs de segurança

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8.9, 8.11, 13.1 AU-3, AU-6, AU-12, SI-4 N/A

Princípio de segurança: centralize o armazenamento e a análise de logs para permitir a correlação entre os dados de log. Para cada fonte de log, certifique-se de ter atribuído um proprietário de dados, orientação de acesso, local de armazenamento, quais ferramentas são usadas para processar e acessar os dados e requisitos de retenção de dados.

Use o SIEM nativo da nuvem se você não tiver uma solução SIEM existente para CSPs. ou agregar logs/alertas em seu SIEM existente.

Orientação do Azure: certifique-se de que está a integrar os registos de atividade do Azure num espaço de trabalho centralizado do Log Analytics. Use o Azure Monitor para consultar e executar análises e criar regras de alerta usando os logs agregados dos serviços do Azure, dispositivos de ponto de extremidade, recursos de rede e outros sistemas de segurança.

Além disso, habilite e integre dados ao Microsoft Sentinel, que fornece recursos de gerenciamento de eventos de informações de segurança (SIEM) e de resposta automatizada de orquestração de segurança (SOAR).

Implementação do Azure e contexto adicional:

Orientação da AWS: certifique-se de integrar seus logs da AWS em um recurso centralizado para armazenamento e análise. Use o CloudWatch para consultar e executar análises e criar regras de alerta usando os logs agregados de serviços, serviços, dispositivos de endpoint, recursos de rede e outros sistemas de segurança da AWS.

Além disso, você pode agregar os logs em um bucket de armazenamento do S3 e integrar os dados de log ao Microsoft Sentinel, que fornece recursos de gerenciamento de eventos de informações de segurança (SIEM) e resposta automatizada de orquestração de segurança (SOAR).

Implementação da AWS e contexto adicional:

Orientação do GCP: certifique-se de que você está integrando seus logs do GCP em um recurso centralizado (como o bucket do Operations Suite Cloud Logging) para armazenamento e análise. O Cloud Logging suporta a maior parte do registo do serviço nativo do Google Cloud, bem como as aplicações de terceiros e as aplicações locais. Você pode usar o Cloud Logging para consultar e executar análises e para criar regras de alerta usando os logs agregados de serviços GCP, serviços, dispositivos de ponto final, recursos de rede e outros sistemas de segurança.

Use o SIEM nativo da nuvem se você não tiver uma solução SIEM existente para CSPs ou agregue logs/alertas em seu SIEM existente.

Nota: o Google fornece dois frontends de consulta de logs, o Explorador de logs e o Log Analytics para interrogar, visualizar e analisar logs. Para solucionar problemas e explorar dados de log, é recomendável usar o Explorador de Logs. Para gerar insights e tendências, recomenda-se o uso do Log Analytics.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

LT-6: Configurar a retenção de armazenamento de log

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8.3, 8.10 AU-11 10.5, 10.7

Princípio de segurança: planeje sua estratégia de retenção de logs de acordo com seus requisitos de conformidade, regulamentação e negócios. Configure a política de retenção de logs nos serviços de log individuais para garantir que os logs sejam arquivados adequadamente.

Orientação do Azure: Logs como Log de Atividade do Azure são retidos por 90 dias e, em seguida, eliminados. Você deve criar uma configuração de diagnóstico e rotear os logs para outro local (como o espaço de trabalho do Azure Monitor Log Analytics, Hubs de Eventos ou Armazenamento do Azure) com base em suas necessidades. Essa estratégia também se aplica a outros logs de recursos e recursos gerenciados por você mesmo, como logs nos sistemas operacionais e aplicativos dentro de VMs.

Você tem a opção de retenção de log como abaixo:

  • Use o espaço de trabalho do Azure Monitor Log Analytics por um período de retenção de log de até 1 ano ou de acordo com os requisitos da sua equipe de resposta.
  • Use o Armazenamento do Azure, o Data Explorer ou o Data Lake para armazenamento de longo prazo e arquivamento por mais de 1 ano e para atender aos seus requisitos de conformidade de segurança.
  • Use os Hubs de Eventos do Azure para encaminhar logs para um recurso externo fora do Azure.

Observação: o Microsoft Sentinel usa o espaço de trabalho do Log Analytics como back-end para armazenamento de logs. Você deve considerar uma estratégia de armazenamento de longo prazo se planeja reter logs SIEM por mais tempo.

Implementação do Azure e contexto adicional:

Orientação da AWS: por padrão, os logs são mantidos indefinidamente e nunca expiram no CloudWatch. Você pode ajustar a política de retenção para cada grupo de logs, mantendo a retenção indefinida ou escolhendo um período de retenção entre 10 anos e um dia.

Use o Amazon S3 para arquivamento de logs do CloudWatch e aplique o gerenciamento do ciclo de vida do objeto e a política de arquivamento ao bucket. Você pode usar o Armazenamento do Azure para arquivamento central de logs transferindo os arquivos do Amazon S3 para o Armazenamento do Azure.

Implementação da AWS e contexto adicional:

Orientação do GCP: Por padrão, o Operations Suite Cloud Logging retém os logs por 30 dias, a menos que você configure a retenção personalizada para o bucket do Cloud Logging. Os logs de auditoria de atividade do administrador, os logs de auditoria de eventos do sistema e os logs de transparência de acesso são retidos por padrão por 400 dias. Você pode configurar o Cloud Logging para reter logs entre 1 dia e 3650 dias.

Use o Cloud Storage para arquivamento de logs do Cloud Logging e aplique o gerenciamento do ciclo de vida do objeto e a política de arquivamento ao bucket. Você pode usar o Armazenamento do Azure para arquivamento central de logs transferindo os arquivos do Armazenamento do Google Cloud para o Armazenamento do Azure.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

LT-7: Usar fontes de sincronização de tempo aprovadas

Controles CIS v8 ID(s) NIST SP 800-53 r4 Identificador(es) PCI-DSS ID(s) v3.2.1
8,4 AU-8 10,4

Princípio de segurança: Use fontes de sincronização de hora aprovadas para seu carimbo de data/hora de registro, que incluem informações de data, hora e fuso horário.

Orientação do Azure: a Microsoft mantém fontes de tempo de referência para a maioria dos serviços PaaS e SaaS do Azure. Para seus sistemas operacionais de recursos de computação, use um servidor NTP padrão da Microsoft para sincronização de tempo, a menos que você tenha um requisito específico. Se você precisar manter seu próprio servidor NTP (Network Time Protocol), certifique-se de proteger a porta de serviço UDP 123.

Todos os logs gerados por recursos no Azure fornecem carimbos de data/hora com o fuso horário especificado por padrão.

Implementação do Azure e contexto adicional:

Orientação da AWS: A AWS mantém fontes de tempo para a maioria dos seus serviços. Para recursos ou serviços em que a configuração de hora do sistema operacional está configurada, use o Amazon Time Sync Service padrão da AWS para sincronização de tempo, a menos que você tenha um requisito específico. Se você precisar manter seu próprio servidor NTP (Network Time Protocol), certifique-se de proteger a porta de serviço UDP 123.

Todos os logs gerados por recursos na AWS fornecem carimbos de data/hora com o fuso horário especificado por padrão.

Implementação da AWS e contexto adicional:

Orientações para o GCP: o Google Cloud mantém fontes de tempo para a maioria dos seus serviços PaaS e SaaS. Para seus sistemas operacionais de recursos de computação, use um servidor NTP padrão do Google Cloud para a sincronização de tempo, a menos que você tenha um requisito específico. Se você precisar manter seu próprio servidor NTP (Network Time Protocol), certifique-se de proteger a porta de serviço UDP 123.

Observação: é recomendável que você não use fontes NTP externas com máquinas virtuais do Compute Engine, mas use o servidor NTP interno fornecido pelo Google.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):