Controle de Segurança: Registro em log e detecção de ameaças

  • Artigo

O Registro em Log e a Detecção de Ameaças abrangem controles para detectar ameaças na nuvem e habilitar, coletar e armazenar logs de auditoria para serviços de nuvem, incluindo a habilitação de processos de detecção, investigação e correção com controles para gerar alertas de alta qualidade com detecção de ameaças nativas nos serviços de nuvem; também inclui a coleta de logs com um serviço de monitoramento de nuvem, centralização da análise de segurança com um SIEM, sincronização de horas e retenção de logs.

LT-1: habilitar funcionalidades de detecção de ameaças

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS 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 detecção de ameaças, monitore todos os tipos de recursos conhecidos para ameaças e anomalias conhecidas e esperadas. Configure sua filtragem de alerta e regras de análise para extrair alertas de alta qualidade de dados de log, agentes ou outras fontes de dados para reduzir falsos positivos.

Diretrizes do Azure: use a capacidade de detecção de ameaças de Microsoft Defender para Nuvem para os respectivos serviços do Azure.

Para detecção de ameaças não incluída nos serviços de Microsoft Defender, consulte linhas de base do serviço Microsoft Cloud Security Benchmark para os respectivos serviços para habilitar a detecção de ameaças ou os recursos de alerta de segurança dentro do serviço. Ingerir alertas e dados de log de Microsoft Defender para Nuvem, 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 detectam ameaças e criam alertas que correspondem a critérios específicos em seu ambiente.

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

Para serviços que não têm uma funcionalidade nativa de detecçã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:

Diretrizes da AWS: use o Amazon GuardDuty para detecção de ameaças que analisa e processa as seguintes fontes de dados: Logs de Fluxo do VPC, logs de eventos de gerenciamento do AWS CloudTrail, logs de eventos de dados do CloudTrail S3, logs de auditoria do EKS e logs de 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 mal-intencionados ou domínios.

Configure a Configuração do AWS para marcar regras no SecurityHub para monitoramento de conformidade, como descompasso de configuração, e crie descobertas quando necessário.

Para detecção de ameaças não incluída no GuardDuty e no SecurityHub, habilite a detecção de ameaças ou os recursos de alerta de segurança nos serviços AWS com suporte. 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 seu ambiente.

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

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

Implementação do AWS e contexto adicional:

Diretrizes do GCP: use a Detecção de Ameaças de Eventos no Google Cloud Security Command Center para detecção de ameaças usando dados de log, como atividade de Administração, acesso a dados GKE, logs de fluxo de VPC, DNS na nuvem e logs de firewall.

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

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

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

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

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

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

Princípio de segurança: detecte ameaças para identidades e gerenciamento de acesso monitorando as anomalias de entrada e acesso do usuário e do aplicativo. Os padrões comportamentais, como número excessivo de tentativas de logon com falha e contas preteridas na assinatura, devem ser alertados.

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

  • Entradas: o relatório de entradas fornece informações sobre o uso de aplicativos gerenciados e as atividades de entrada do usuário.
  • Logs de auditoria: Possibilitam o rastreio por logs de todas as alterações feitas por vários recursos 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 suspeitas: uma entrada suspeita é o indicador de uma tentativa de entrada que pode ter sido realizada por alguém que não é o proprietário legítimo de uma conta de usuário.
  • Usuários sinalizados como suspeitos: um usuário suspeito é o indicador de uma conta de usuário que pode ter sido comprometida.

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

Além disso, o Microsoft Defender para Nuvem pode ser configurado para alertar sobre contas preteridas na assinatura e atividades suspeitas, como 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 para Nuvem 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 BD SQL e armazenamento) e camadas de serviço do Azure. Essa funcionalidade permite ver as anomalias nas contas nos recursos individuais.

Observação: se você estiver conectando sua Active Directory local para sincronização, use a solução Microsoft Defender para Identidade para consumir os sinais locais do Active Directory para identificar, detectar e investigar ameaças avançadas, identidades comprometidas e ações internas mal-intencionadas direcionadas à sua organização.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: o AWS IAM fornece os seguintes relatórios e logs para atividades do usuário do console por meio do Assistente de Acesso do IAM e do relatório de credenciais do IAM:

  • Todas as tentativas de logon bem-sucedidas e de logon malsucedidas.
  • A MFA (autenticação multifator) status para cada usuário.
  • Usuário do IAM inativo

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

  • Uma API usada para obter acesso a um ambiente da AWS e foi invocada de maneira anômala ou usada para evitar medidas defensivas
  • Uma API usada para:
    • descobrir recursos foi invocado de forma anômala
    • Coletar dados de um ambiente da AWS foi invocado de forma anômala.
    • A violação de dados ou processos em um ambiente da AWS foi invocada de maneira anômala.
    • obter acesso não autorizado a um ambiente da AWS foi invocado de maneira anômala.
    • manter o acesso não autorizado a um ambiente da AWS foi invocado de maneira anômala.
    • obter permissões de alto nível para um ambiente AWS foi invocado de maneira anômala.
    • ser invocado de um endereço IP mal-intencionado conhecido.
    • ser invocado usando credenciais raiz.
  • O log do AWS CloudTrail foi desabilitado.
  • A política de senha da conta foi enfraquecida.
  • Vários logons de console com êxito mundial foram observados.
  • As credenciais que foram criadas exclusivamente para uma instância do EC2 por meio de uma função de inicialização de instância estão sendo usadas de outra conta dentro da AWS.
  • As credenciais que foram criadas exclusivamente para uma instância do EC2 por meio de uma função de inicialização de instância estão sendo usadas de um endereço IP externo.
  • Uma API foi invocada de um endereço IP mal-intencionado conhecido.
  • Uma API foi invocada de um endereço IP em uma lista de ameaças personalizada.
  • Uma API foi invocada de um endereço IP do nó de saída do Tor.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: use a Detecção de Ameaças de Eventos no Google Cloud Security Command Center para determinado tipo de detecção de ameaças relacionada ao IAM, como detecção de eventos em que uma conta de serviço gerenciada pelo usuário inativa recebeu uma ou mais funções de IAM confidenciais.

Lembre-se de que os logs do Google Identity e os logs do IAM do Google Cloud produzem logs de atividade de administrador, mas para o escopo diferente. Os logs do Google Identity são apenas para operações correspondentes à 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 à 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 os relatórios de Identidade de Nuvem e IAM para alertar sobre determinados padrões de atividades suspeitas. Você também pode usar o Policy Intelligence para analisar as atividades de 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:

Stakeholders de segurança do cliente (Saiba mais):

LT-3: habilitar registro em log para investigação de segurança

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS 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 conformidade e resposta de segurança.

Diretrizes do Azure: habilite a funcionalidade de registro em log para recursos nas diferentes camadas, como logs para recursos do Azure, sistemas operacionais e aplicativos dentro de suas VMs e outros tipos de log.

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

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

Também é possível usar o Microsoft Defender para Nuvem e o Azure Policy para habilitar logs de recursos e coleta de dados de log nos recursos do Azure.

Implementação do Azure e contexto adicional:

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

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

  • Logs de vingança: logs publicados nativamente pelos serviços da AWS em seu nome. Atualmente, os logs do Amazon VPC Flow e os logs do Amazon Route 53 são os dois tipos com suporte. Esses dois logs são habilitados por padrão.
  • Logs publicados pelos serviços da AWS: logs de mais de 30 serviços da AWS são publicados no CloudWatch. Eles incluem o Gateway de API da Amazon, o Lambda da AWS, o AWS CloudTrail e muitos outros. Esses logs podem ser habilitados 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 encaminhando-os para o CloudWatch.

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

Implementação do AWS e contexto adicional:

Diretrizes do GCP: habilite a funcionalidade de registro em log para recursos nas diferentes camadas, como logs para recursos do Azure, sistemas operacionais e aplicativos dentro de suas VMs e outros tipos de log.

Lembre-se de diferentes tipos de logs para segurança, auditoria e outros logs operacionais nas camadas do plano de gerenciamento/controle e 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. Há suporte para quatro categorias de logs no Log de Nuvem:

  • Logs de plataforma – logs gravados pelos 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 gravados 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 da infraestrutura local.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

LT-4: habilitar o registro de rede para investigação de segurança

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS 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 relacionadas à rede, busca de 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 aplicativo, DNS, monitoramento de fluxo e assim por diante.

Diretrizes do Azure: habilite e colete logs de recursos do NSG (grupo de segurança de rede), logs de fluxo do NSG, logs de Firewall do Azure e logs de Firewall de Aplicativo Web (WAF) e logs de máquinas virtuais por meio do agente de coleta de dados de tráfego de rede para 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 workspace do Log Analytics do Azure Monitor e, em seguida, usar a Análise de Tráfego para fornecer insights.

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

Implementação do Azure e contexto adicional:

Diretrizes da AWS: habilite e colete logs de rede, como logs de fluxo de VPC, logs de WAF e logs de consulta do Resolvedor de Rota53 para análise de segurança para dar 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 S3 para ingestão na solução do Microsoft Sentinel para análise centralizada.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: a maioria dos logs de atividades de rede estão disponíveis por meio dos Logs de Fluxo de VPC que registra uma amostra de fluxos de rede enviados e recebidos por recursos, incluindo instâncias usadas como VMs de Computação do Google, nós do Mecanismo do Kubernetes. Esses logs podem ser usados para monitoramento de rede, análise forense, análise de segurança em tempo real e otimização de despesas.

Você pode exibir logs de fluxo no Log de Nuvem e exportar logs para o destino compatível com a exportação de Log de Nuvem. Os logs de fluxo são agregados pela conexão das VMs do Mecanismo de Computação e exportados em tempo real. Ao assinar o Pub/Sub, você pode analisar logs de fluxo usando APIs de streaming em tempo real.

Observação: você também pode usar o Espelhamento de Pacotes clona o tráfego de instâncias especificadas em sua rede VPC (Nuvem Virtual Privada) e encaminha-o para exame. O Espelhamento de Pacotes captura todos os dados de tráfego e pacotes, incluindo cargas e cabeçalhos.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

LT-5: centralizar o gerenciamento e a análise do log de segurança

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

Princípio de segurança: centralize o armazenamento e a análise de log para habilitar a correlação entre os dados de log. Para cada origem de log, verifique se você atribuiu um proprietário de dados, orientação de acesso, local de armazenamento, quais ferramentas são usadas para processar e acessar os dados e os requisitos de retenção de dados.

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

Diretrizes do Azure: verifique se você está integrando os logs de atividades do Azure em um workspace centralizado do Log Analytics. Use o Azure Monitor para consultar e executar análises e criar regras de alerta usando os logs agregados de 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 SIEM (gerenciamento de eventos de informações de segurança) e SOAR (resposta automatizada de orquestração de segurança).

Implementação do Azure e contexto adicional:

Diretrizes da AWS: verifique se você está integrando seus logs da AWS em um recurso centralizado para armazenamento e análise. Use o CloudWatch para consultar e executar análises e para criar regras de alerta usando os logs agregados de serviços, serviços, dispositivos de ponto de extremidade, recursos de rede e outros sistemas de segurança.

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

Implementação do AWS e contexto adicional:

Diretrizes do GCP: verifique se você está integrando seus logs do GCP em um recurso centralizado (como o bucket log de nuvem do Operations Suite) para armazenamento e análise. O Log de Nuvem dá suporte à maior parte do log de serviços nativos do Google Cloud, bem como aos aplicativos de terceiros e aplicativos locais. Você pode usar o Log de Nuvem 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 de extremidade, 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 CSP ou agregar logs/alertas em seu SIEM existente.

Observação: o Google fornece dois front-end de consulta de log, Logs Explorer e Log Analytics para consultar, exibir e analisar logs. Para solução de problemas e exploração de dados de log, é recomendável usar logs Explorer. Para gerar insights e tendências, é recomendável usar o Log Analytics.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

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

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS 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 log de acordo com seus requisitos de conformidade, regulamentação e negócios. Configure a política de retenção de log nos serviços de registro em log individuais para garantir que os logs sejam arquivados adequadamente.

Diretrizes do Azure: os logs, como os Logs de Atividades do Azure, são mantidos por 90 dias e excluídos. Você deve criar uma configuração de diagnóstico e rotear os logs para outro local (como workspace do Log Analytics do Azure Monitor, 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 conta própria, como logs nos sistemas operacionais e aplicativos dentro de VMs.

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

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

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

Implementação do Azure e contexto adicional:

Diretrizes 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, manter a retenção indefinida ou escolher um período de retenção entre 10 anos e um dia.

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

Implementação do AWS e contexto adicional:

Diretrizes do GCP: por padrão, o Log de Nuvem do Operations Suite mantém os logs por 30 dias, a menos que você configure a retenção personalizada para o bucket log de nuvem. Administração logs de auditoria de atividade, logs de auditoria de eventos do sistema e logs de Transparência de Acesso são mantidos por padrão 400 dias. Você pode configurar o Log de Nuvem para reter logs entre 1 dia e 3650 dias.

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

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

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

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
8.4 AU-8 10.4

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

Diretrizes do Azure: a Microsoft mantém fontes de tempo para a maioria dos serviços de PaaS e SaaS do Azure. Para os sistemas operacionais de recursos de computação, use um servidor NTP padrão da Microsoft para sincronização de data/hora, a menos que você tenha um requisito específico. Se você precisar montar seu próprio servidor NTP (protocolo de tempo de rede), proteja 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:

Diretrizes da AWS: a AWS mantém fontes de tempo para a maioria dos serviços da AWS. Para recursos ou serviços em que a configuração de hora do sistema operacional está configurada, use o Serviço de Sincronização de Tempo padrão do Amazon Time da AWS para sincronização de tempo, a menos que você tenha um requisito específico. Se você precisar montar seu próprio servidor NTP (protocolo de tempo de rede), proteja a porta de serviço UDP 123.

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

Implementação do AWS e contexto adicional:

Diretrizes do GCP: o Google Cloud mantém fontes de tempo para a maioria dos serviços de PaaS e SaaS do Google Cloud. 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 levantar seu próprio servidor NTP (protocolo de tempo de rede), 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 Mecanismo de Computação, mas use o servidor NTP interno fornecido pelo Google.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):