Dela via

Säkerhetskontroll: Loggning och hotidentifiering

Loggning och hotidentifiering omfattar kontroller för att identifiera hot i molnet och aktivera, samla in och lagra granskningsloggar för molntjänster, inklusive aktivering av identifierings-, undersöknings- och reparationsprocesser med kontroller för att generera högkvalitativa aviseringar med inbyggd hotidentifiering i molntjänster. Det omfattar även insamling av loggar med en molnövervakningstjänst, centralisering av säkerhetsanalys med siem, tidssynkronisering och loggkvarhållning.

LT-1: Aktivera funktioner för hotidentifiering

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

Säkerhetsprincip: Övervaka alla kända resurstyper för kända och förväntade hot och avvikelser för att stödja scenarier för hotidentifiering. Konfigurera dina aviseringsfiltrerings- och analysregler för att extrahera högkvalitativa aviseringar från loggdata, agenter eller andra datakällor för att minska falska positiva identifieringar.

Azure-vägledning: Använd funktionen för hotidentifiering i Microsoft Defender för molnet för respektive Azure-tjänster.

Information om hotidentifiering som inte ingår i Microsoft Defender-tjänster finns i Microsoft Cloud Security Benchmark-tjänstbaslinjer för respektive tjänster för att aktivera funktionerna för hotidentifiering eller säkerhetsaviseringar i tjänsten. Mata in aviseringar och loggdata från Microsoft Defender för molnet, Microsoft 365 Defender och logga data från andra resurser i dina Azure Monitor- eller Microsoft Sentinel-instanser för att skapa analysregler som identifierar hot och skapar aviseringar som matchar specifika kriterier i din miljö.

För OT-miljöer (Operational Technology) som omfattar datorer som styr eller övervakar ICS-resurser (Industrial Control System) eller SCADA-resurser (Övervakningskontroll och dataförvärv) använder du Microsoft Defender för IoT för att inventera tillgångar och identifiera hot och sårbarheter.

För tjänster som inte har en inbyggd hotidentifieringsfunktion bör du överväga att samla in dataplansloggarna och analysera hoten via Microsoft Sentinel.

Azure-implementering och ytterligare kontext:

AWS-vägledning: Använd Amazon GuardDuty för hotidentifiering som analyserar och bearbetar följande datakällor: VPC-flödesloggar, händelseloggar för AWS CloudTrail-hantering, CloudTrail S3-datahändelseloggar, EKS-granskningsloggar och DNS-loggar. GuardDuty kan rapportera om säkerhetsproblem som eskalering av privilegier, exponerad användning av autentiseringsuppgifter eller kommunikation med skadliga IP-adresser eller domäner.

Konfigurera AWS Config för att kontrollera regler i SecurityHub för efterlevnadsövervakning, till exempel konfigurationsavvikelse, och skapa resultat när det behövs.

För hotidentifiering som inte ingår i GuardDuty och SecurityHub aktiverar du funktioner för hotidentifiering eller säkerhetsaviseringar i de AWS-tjänster som stöds. Extrahera aviseringarna till CloudTrail, CloudWatch eller Microsoft Sentinel för att skapa analysregler som jagar hot som matchar specifika kriterier i din miljö.

Du kan också använda Microsoft Defender för molnet för att övervaka vissa tjänster i AWS, till exempel EC2-instanser.

För OT-miljöer (Operational Technology) som omfattar datorer som styr eller övervakar ICS-resurser (Industrial Control System) eller SCADA-resurser (Övervakningskontroll och dataförvärv) använder du Microsoft Defender för IoT för att inventera tillgångar och identifiera hot och sårbarheter.

AWS-implementering och ytterligare kontext:

GCP-vägledning: Använd Händelsehotidentifiering i Google Cloud Security Command Center för hotidentifiering med hjälp av loggdata som administratörsaktivitet, GKE-dataåtkomst, VPC-flödesloggar, Moln-DNS och brandväggsloggar.

Använd dessutom Security Operations-sviten för modern SOC med Chronicle SIEM och SOAR. Chronicle SIEM och SOAR ger funktioner för hotidentifiering, undersökning och jakt

Du kan också använda Microsoft Defender för molnet för att övervaka vissa tjänster i GCP, till exempel beräknings-VM-instanser.

För OT-miljöer (Operational Technology) som omfattar datorer som styr eller övervakar ICS-resurser (Industrial Control System) eller SCADA-resurser (Övervakningskontroll och dataförvärv) använder du Microsoft Defender för IoT för att inventera tillgångar och identifiera hot och sårbarheter.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):

LT-2: Aktivera hotidentifiering för identitets- och åtkomsthantering

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

Säkerhetsprincip: Identifiera hot för identiteter och åtkomsthantering genom att övervaka användar- och programinloggnings- och åtkomstavvikelser. Beteendemönster som överdrivet många misslyckade inloggningsförsök och inaktuella konton i prenumerationen bör aviseras.

Azure-vägledning: Azure AD tillhandahåller följande loggar som kan visas i Azure AD-rapportering eller integreras med Azure Monitor, Microsoft Sentinel eller andra SIEM/övervakningsverktyg för mer avancerade användningsfall för övervakning och analys:

  • Inloggningar: Inloggningsrapporten innehåller information om användningen av hanterade program och användarinloggningsaktiviteter.
  • Granskningsloggar: Ger spårningsbarhet via loggar för alla ändringar som görs av olika funktioner i Azure AD. Exempel på granskningsloggar är ändringar som gjorts i alla resurser i Azure AD som att lägga till eller ta bort användare, appar, grupper, roller och principer.
  • Riskfyllda inloggningar: En riskfylld inloggning är en indikator för ett inloggningsförsök som kan ha utförts av någon som inte är legitim ägare till ett användarkonto.
  • Användare som har flaggats för risk: En riskfylld användare är en indikator för ett användarkonto som kan ha komprometterats.

Azure AD tillhandahåller också en Identity Protection-modul för att identifiera och åtgärda risker relaterade till användarkonton och inloggningsbeteenden. Exempel på risker är läckta autentiseringsuppgifter, inloggning från anonyma eller skadliga IP-adresser, lösenordsspray. Med principerna i Azure AD Identity Protection kan du tillämpa riskbaserad MFA-autentisering tillsammans med villkorsstyrd åtkomst i Azure på användarkonton.

Dessutom kan Microsoft Defender för molnet konfigureras för att avisera om inaktuella konton i prenumerationen och misstänkta aktiviteter, till exempel ett överdrivet antal misslyckade autentiseringsförsök. Förutom den grundläggande säkerhetshygienövervakningen kan Microsoft Defender för molnets hotskyddsmodul också samla in mer djupgående säkerhetsaviseringar från enskilda Azure-beräkningsresurser (till exempel virtuella datorer, containrar, apptjänst), dataresurser (till exempel SQL DB och lagring) och Azure-tjänstlager. Med den här funktionen kan du se kontoavvikelser i de enskilda resurserna.

Obs! Om du ansluter din lokala Active Directory för synkronisering använder du Microsoft Defender för identitetslösningen för att använda dina lokala Active Directory-signaler för att identifiera, identifiera och undersöka avancerade hot, komprometterade identiteter och skadliga insideråtgärder riktade mot din organisation.

Azure-implementering och ytterligare kontext:

AWS-vägledning: AWS IAM tillhandahåller följande rapportering av loggar och rapporter för konsolanvändaraktiviteter via IAM Access Advisor- och IAM-autentiseringsuppgifter:

  • Alla lyckade inloggningsförsök och misslyckade inloggningsförsök.
  • Multifaktorautentiseringsstatus (MFA) för varje användare.
  • Vilande IAM-användare

För åtkomstövervakning på API-nivå och hotidentifiering använder du Amazon GuadDuty för att identifiera resultaten relaterade till IAM. Exempel på dessa resultat är:

  • Ett API som används för att få åtkomst till en AWS-miljö och anropades på ett avvikande sätt, eller användes för att undvika defensiva åtgärder
  • Ett API som används för att:
    • identifiera resurser anropades på ett avvikande sätt
    • samla in data från en AWS-miljö anropades på ett ovanligt sätt.
    • Manipulering av data eller processer i en AWS-miljö utfördes på ett avvikande sätt.
    • få obehörig åtkomst till en AWS-miljö anropades på ett avvikande sätt.
    • upprätthålla obehörig åtkomst till en AWS-miljö anropades på ett avvikande sätt.
    • Att få åtkomst på hög nivå till en AWS-miljö initierades på ett avvikande sätt.
    • anropas från en känd skadlig IP-adress.
    • anropas med rotautentiseringsuppgifter.
  • AWS CloudTrail-loggning har inaktiverats.
  • Kontots lösenordsprincip har försvagats.
  • Flera världsomspännande lyckade konsolinloggningar observerades.
  • Autentiseringsuppgifter som har skapats exklusivt för en EC2-instans via en instansstartsroll används från ett annat konto i AWS.
  • Autentiseringsuppgifter som har skapats exklusivt för en EC2-instans via en instansstartsroll används från en extern IP-adress.
  • Ett API anropades från en känd skadlig IP-adress.
  • Ett API anropades från en IP-adress i en anpassad hotlista.
  • Ett API anropades från en IP-adress för tor-avslutsnoden.

AWS-implementering och ytterligare kontext:

GCP-vägledning: Använd Händelsehotidentifiering i Google Cloud Security Command Center för viss typ av IAM-relaterad hotidentifiering, till exempel identifiering av händelser där ett vilande användarhanterat tjänstkonto har beviljats en eller flera känsliga IAM-roller.

Tänk på att Google Identity-loggar och Google Cloud IAM-loggar både skapar administratörsaktivitetsloggar men för olika omfång. Google Identity-loggar är endast för åtgärder som motsvarar Identity Platform medan IAM-loggar är för åtgärder som motsvarar IAM för Google Cloud. IAM-loggar innehåller loggposter för API-anrop eller andra åtgärder som ändrar konfigurationen eller metadata för resurser. Dessa loggar registrerar till exempel när användare skapar VM-instanser eller ändrar behörigheter för identitets- och åtkomsthantering.

Använd molnidentitets- och IAM-rapporter för aviseringar om vissa misstänkta aktivitetsmönster. Du kan också använda Policy Intelligence för att analysera tjänstkontons aktiviteter och identifiera om tjänstkonton i ditt projekt inte har använts under de senaste 90 dagarna.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):

LT-3: Aktivera loggning för säkerhetsundersökning

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

Säkerhetsprincip: Aktivera loggning för dina molnresurser för att uppfylla kraven för säkerhetsincidentutredningar och säkerhetssvar och efterlevnadsändamål.

Azure-vägledning: Aktivera loggningskapacitet för resurser på olika nivåer, till exempel loggar för Azure-resurser, operativsystem och program i dina virtuella datorer och andra loggtyper.

Tänk på olika typer av loggar för säkerhet, granskning och andra driftloggar på hanterings-/kontrollplanets och dataplanets nivåer. Det finns tre typer av loggar som är tillgängliga på Azure-plattformen:

  • Azure-resurslogg: Loggning av åtgärder som utförs i en Azure-resurs (dataplanet). Du kan till exempel hämta en hemlighet från ett nyckelvalv eller göra en begäran till en databas. Innehållet i resursloggarna varierar beroende på Azure-tjänst och resurstyp.
  • Azure-aktivitetslogg: Loggning av åtgärder på varje Azure-resurs på prenumerationsnivå, utifrån (hanteringsplanet). Du kan använda aktivitetsloggen för att avgöra vad, vem och när för skrivåtgärder (PUT, POST, DELETE) som tagits på resurserna i din prenumeration. Det finns en enda aktivitetslogg för varje Azure-prenumeration.
  • Azure Active Directory-loggar: Loggar över inloggningsaktivitetens historik och spårningsloggen för ändringar som gjorts i Azure Active Directory för en viss klientorganisation.

Du kan också använda Microsoft Defender för molnet och Azure Policy för att aktivera resursloggar och loggdata som samlas in på Azure-resurser.

Azure-implementering och ytterligare kontext:

AWS-vägledning: Använd AWS CloudTrail-loggning för hanteringshändelser (kontrollplansåtgärder) och datahändelser (dataplansåtgärder) och övervaka dessa spår med CloudWatch för automatiserade åtgärder.

Med Amazon CloudWatch Logs-tjänsten kan du samla in och lagra loggar från dina resurser, program och tjänster nästan i realtid. Det finns tre huvudkategorier av loggar:

  • Varuautomater: Loggar som publicerats internt av AWS-tjänster för din räkning. För närvarande är Amazon VPC Flow-loggar och Amazon Route 53-loggar de två typer som stöds. Dessa två loggar är aktiverade som standard.
  • Loggar publicerade av AWS-tjänster: Loggar från mer än 30 AWS-tjänster publicerar till CloudWatch. De inkluderar Amazon API Gateway, AWS Lambda, AWS CloudTrail och många andra. Dessa loggar kan aktiveras direkt i tjänsterna och CloudWatch.
  • Anpassade loggar: Loggar från ditt eget program och lokala resurser. Du kan behöva samla in dessa loggar genom att installera CloudWatch Agent i dina operativsystem och vidarebefordra dem till CloudWatch.

Även om många tjänster endast publicerar loggar till CloudWatch-loggar kan vissa AWS-tjänster publicera loggar direkt till AmazonS3 eller Amazon Kinesis Data Firehose där du kan använda olika principer för lagring och kvarhållning av loggning.

AWS-implementering och ytterligare kontext:

GCP-vägledning: Aktivera loggningsfunktioner för resurser på olika nivåer, till exempel loggar för Azure-resurser, operativsystem och program i dina virtuella datorer och andra loggtyper.

Tänk på olika typer av loggar för säkerhet, granskning och andra driftloggar på hanterings-/kontrollplanets och dataplanets nivåer. Operations Suite Cloud Logging Service samlar in och aggregerar alla typer av logghändelser från resursnivåer. Fyra kategorier av loggar stöds i Cloud Logging:

  • Plattformsloggar – loggar skrivna av dina Google Cloud-tjänster.
  • Komponentloggar – liknar plattformsloggar, men de är loggar som genereras av Programvarukomponenter från Google som körs på dina system.
  • Säkerhetsloggar – främst granskningsloggar som registrerar administrativa aktiviteter och åtkomster inom dina resurser.
  • Användarskriven – loggar skrivna av anpassade program och tjänster
  • Loggar för flera moln och hybridmolnloggar – loggar från andra molnleverantörer som Microsoft Azure och loggar från lokal infrastruktur.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):

LT-4: Aktivera nätverksloggning för säkerhetsundersökning

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

Säkerhetsprincip: Aktivera loggning för dina nätverkstjänster för att stödja nätverksrelaterade incidentundersökningar, hotjakt och generering av säkerhetsaviseringar. Nätverksloggarna kan innehålla loggar från nätverkstjänster som IP-filtrering, nätverks- och programbrandvägg, DNS, flödesövervakning och så vidare.

Azure-vägledning: Aktivera och samla in nätverkssäkerhetsgruppsloggar (NSG), NSG-flödesloggar, Azure Firewall-loggar och WAF-loggar (Web Application Firewall) och loggar från virtuella datorer via datainsamlingsagenten för nätverkstrafik för säkerhetsanalys för att stödja incidentundersökningar och generering av säkerhetsaviseringar. Du kan skicka flödesloggarna till en Azure Monitor Log Analytics-arbetsyta och sedan använda Traffic Analytics för att ge insikter.

Samla in DNS-frågeloggar för att korrelera andra nätverksdata.

Azure-implementering och ytterligare kontext:

AWS-vägledning: Aktivera och samla in nätverksloggar som VPC-flödesloggar, WAF-loggar och Route53 Resolver-frågeloggar för säkerhetsanalys för att stödja incidentundersökningar och generering av säkerhetsaviseringar. Loggarna kan exporteras till CloudWatch för övervakning eller en S3-lagringshink för inmatning till Microsoft Sentinel-lösningen för centraliserad analys.

AWS-implementering och ytterligare kontext:

GCP-vägledning: De flesta nätverksaktivitetsloggar är tillgängliga via VPC-flödesloggarna som registrerar ett exempel på nätverksflöden som skickas från och tas emot av resurser, inklusive instanser som används som virtuella Google Compute-datorer, Kubernetes Engine-noder. Dessa loggar kan användas för nätverksövervakning, kriminalteknik, säkerhetsanalys i realtid och kostnadsoptimering.

Du kan visa flödesloggar i Molnloggning och exportera loggar till målet som Cloud Logging-export stöder. Flödesloggar aggregeras efter anslutning från den virtuella datorn Compute Engine och exporteras i realtid. Genom att prenumerera på Pub/Sub kan du analysera flödesloggar med hjälp av API:er för direktuppspelning i realtid.

Obs! Du kan också använda Paketspegling för att klona trafiken för angivna instanser i ditt Virtual Private Cloud (VPC)-nätverk och vidarebefordra den för undersökning. Paketspegling samlar in all trafik och alla paketdata, inklusive nyttolaster och rubriker.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):

LT-5: Centralisera hantering och analys av säkerhetsloggar

CIS Controls v8 ID(er) NIST SP 800-53 r4 ID(er) PCI-DSS ID:er v3.2.1
8.9, 8.11, 13.1 AU-3, AU-6, AU-12, SI-4 Inte tillgänglig

Säkerhetsprincip: Centralisera loggningslagring och analys för att möjliggöra korrelation mellan loggdata. För varje loggkälla kontrollerar du att du har tilldelat en dataägare, åtkomstvägledning, lagringsplats, vilka verktyg som används för att bearbeta och komma åt data samt krav på datakvarhållning.

Använd molnbaserat SIEM om du inte har någon befintlig SIEM-lösning för CSP:er. eller aggregera loggar/aviseringar i din befintliga SIEM.

Azure-vägledning: Se till att du integrerar Azure-aktivitetsloggar i en centraliserad Log Analytics-arbetsyta. Använd Azure Monitor för att köra frågor mot och utföra analyser och skapa aviseringsregler med hjälp av loggar som sammanställts från Azure-tjänster, slutpunktsenheter, nätverksresurser och andra säkerhetssystem.

Dessutom aktiverar och registrerar du data till Microsoft Sentinel som tillhandahåller siem-funktioner (security information event management) och soar-funktioner (security orchestration automated response).

Azure-implementering och ytterligare kontext:

AWS-vägledning: Se till att du integrerar dina AWS-loggar i en centraliserad resurs för lagring och analys. Använd CloudWatch för att fråga och utföra analyser och för att skapa aviseringsregler med hjälp av loggar som sammanställts från AWS-tjänster, tjänster, slutpunktsenheter, nätverksresurser och andra säkerhetssystem.

Dessutom kan du aggregera loggarna i en S3-lagringshink och registrera loggdata till Microsoft Sentinel som tillhandahåller siem-funktioner (security information event management) och soar-funktioner (security orchestration automated response).

AWS-implementering och ytterligare kontext:

GCP-vägledning: Se till att du integrerar dina GCP-loggar i en centraliserad resurs (till exempel Operations Suite Cloud Logging Bucket) för lagring och analys. Molnloggning stöder de flesta av Google Clouds interna tjänstloggning samt program från tredje part och lokala program. Du kan använda Cloud Logging för att fråga och utföra analyser och skapa aviseringsregler med hjälp av loggarna aggregerade från GCP-tjänster, tjänster, slutpunktsenheter, nätverksresurser och andra säkerhetssystem.

Använd molnbaserat SIEM om du inte har någon befintlig SIEM-lösning för CSP:er eller aggregerar loggar/aviseringar i din befintliga SIEM.

Obs! Google tillhandahåller två log query-klientdelar, Logs Explorer och Log Analytics för frågor, visa och analysera loggar. För felsökning och utforskning av loggdata rekommenderar vi att du använder Logs Explorer. För att generera insikter och trender rekommenderar vi att du använder Log Analytics.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):

LT-6: Konfigurera kvarhållning av logglagring

CIS Controls v8 ID(er) NIST SP 800-53 r4 ID(er) PCI-DSS ID:er v3.2.1
8.3, 8.10 AU-11 10.5, 10.7

Säkerhetsprincip: Planera din kvarhållningsstrategi för loggar enligt dina efterlevnads-, reglerings- och affärskrav. Konfigurera loggkvarhållningsprincipen för de enskilda loggningstjänsterna för att säkerställa att loggarna arkiveras korrekt.

Azure-vägledning: Loggar som Azure-aktivitetsloggar behålls i 90 dagar och tas sedan bort. Du bör skapa en diagnostikinställning och dirigera loggarna till en annan plats (till exempel Azure Monitor Log Analytics-arbetsyta, Event Hubs eller Azure Storage) baserat på dina behov. Den här strategin gäller även för andra resursloggar och resurser som hanteras av dig själv, till exempel loggar i operativsystemen och programmen på virtuella datorer.

Du har alternativet för loggkvarhållning enligt nedan:

  • Använd Azure Monitor Log Analytics-arbetsytan under en kvarhållningsperiod på upp till ett år eller enligt dina krav för svarsteamet.
  • Använd Azure Storage, Data Explorer eller Data Lake för långsiktig lagring och arkivering i mer än ett år och för att uppfylla dina krav på säkerhetsefterlevnad.
  • Använd Azure Event Hubs för att vidarebefordra loggar till en extern resurs utanför Azure.

Obs! Microsoft Sentinel använder Log Analytics-arbetsytan som serverdel för logglagring. Du bör överväga en långsiktig lagringsstrategi om du planerar att behålla SIEM-loggar under längre tid.

Azure-implementering och ytterligare kontext:

AWS-vägledning: Som standard sparas loggarna på obestämd tid och upphör aldrig att gälla i CloudWatch. Du kan justera kvarhållningsprincipen för varje logggrupp, behålla den obegränsade kvarhållningen eller välja en kvarhållningsperiod mellan 10 år och en dag.

Använd Amazon S3 för loggarkivering från CloudWatch och tillämpa objektlivscykelhantering och arkiveringsprincip på bucketen. Du kan använda Azure Storage för central loggarkivering genom att överföra filerna från Amazon S3 till Azure Storage.

AWS-implementering och ytterligare kontext:

GCP-vägledning: Som standard behåller Operations Suite Cloud Logging loggarna i 30 dagar, såvida du inte konfigurerar anpassad kvarhållning för bucketen Molnloggning. Granskningsloggar för administratörsaktivitet, systemhändelsegranskningsloggar och åtkomsttransparensloggar behålls som standard 400 dagar. Du kan konfigurera Molnloggning för att behålla loggar mellan 1 dag och 3 650 dagar.

Använd Cloud Storage för loggarkivering från Molnloggning och tillämpa livscykelhantering och arkiveringsprincip för objekt på bucketen. Du kan använda Azure Storage för central loggarkivering genom att överföra filerna från Google Cloud Storage till Azure Storage.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):

LT-7: Använd godkända tidssynkroniseringskällor

CIS Controls v8 ID(er) NIST SP 800-53 r4 ID(er) PCI-DSS ID:er v3.2.1
8,4 AU-8 10.4

Säkerhetsprincip: Använd godkända tidssynkroniseringskällor för din loggningstidsstämpel som innehåller information om datum, tid och tidszon.

Azure-vägledning: Microsoft underhåller tidskällor för de flesta Azure PaaS- och SaaS-tjänster. För operativsystemen för beräkningsresurser använder du en Microsoft-standard-NTP-server för tidssynkronisering om du inte har ett specifikt krav. Om du behöver sätta upp en egen NTP-server, säkerställer du att du skyddar UDP-tjänstporten 123.

Alla loggar som genereras av resurser i Azure ger tidsstämplar med den tidszon som anges som standard.

Azure-implementering och ytterligare kontext:

AWS-vägledning: AWS underhåller tidskällor för de flesta AWS-tjänster. För resurser eller tjänster där operativsystemets tidsinställning är konfigurerad använder du AWS-standardtjänsten amazon time sync för tidssynkronisering om du inte har ett specifikt krav. Om du behöver sätta upp en egen NTP-server, säkerställer du att du skyddar UDP-tjänstporten 123.

Alla loggar som genereras av resurser i AWS ger tidsstämplar med den tidszon som anges som standard.

AWS-implementering och ytterligare kontext:

GCP-vägledning: Google Cloud underhåller tidskällor för de flesta Google Cloud PaaS- och SaaS-tjänster. För operativsystemet för beräkningsresurser använder du en NTP-standardserver för Google Cloud för tidssynkronisering om du inte har ett specifikt krav. Om du behöver installera din egen nätverkstidprotokoll-server (NTP-server) bör du säkerställa säkerheten för UDP-tjänstporten 123.

Obs! Vi rekommenderar att du inte använder externa NTP-källor med virtuella Datorer i Compute Engine, utan använder den interna NTP-servern som tillhandahålls av Google.

GCP-implementering och ytterligare kontext:

Intressenter för kundsäkerhet (Läs mer):