Säkerhetskontroll: Loggning och hotidentifiering

  • Artikel

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 aviseringar av hög kvalitet 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-kontroller v8 ID:n NIST SP 800-53 r4 ID:n 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 hotidentifieringsscenarier. Konfigurera dina aviseringsfiltrerings- och analysregler för att extrahera aviseringar av hög kvalitet 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 inkluderar 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, AWS CloudTrail-hanteringshändelseloggar, CloudTrail S3-datahändelseloggar, EKS-granskningsloggar och DNS-loggar. GuardDuty kan rapportera säkerhetsproblem som behörighetseskalering, exponerad användning av autentiseringsuppgifter eller kommunikation med skadliga IP-adresser eller domäner.

Konfigurera AWS-konfiguration 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 inkluderar 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 Admin aktivitet, GKE-dataåtkomst, VPC-flödesloggar, Cloud DNS och brandväggsloggar.

Använd även Security Operations-sviten för moderna 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 inkluderar 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-kontroller v8 ID:n NIST SP 800-53 r4 ID:n 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 avvikelser vid inloggning och åtkomst för användare och program. Beteendemönster, till exempel överdrivet antal misslyckade inloggningsförsök och inaktuella konton i prenumerationen, bör aviseras.

Azure-vägledning: Azure AD innehå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årbarhet via loggar för alla ändringar som görs av olika funktioner i Azure AD. Exempel på granskningsloggar är de resursändringar som görs 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 framtvinga riskbaserad MFA-autentisering tillsammans med villkorsstyrd åtkomst i Azure på användarkonton.

Dessutom kan Microsoft Defender för molnet konfigureras för aviseringar om inaktuella konton i prenumerationen och misstänkta aktiviteter, till exempel ett överdrivet antal misslyckade autentiseringsförsök. Förutom den grundläggande övervakningen av säkerhetshygien kan Microsoft Defender för molnets hotskyddsmodul även 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 lokal Active Directory för synkronisering använder du den Microsoft Defender for Identity lösningen för att använda din lokal Active Directory signaler för att identifiera, identifiera och undersöka avancerade hot, komprometterade identiteter och skadliga insideråtgärder som riktas 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-autentiseringsrapporten:

  • Varje lyckad inloggning 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 avvikande sätt.
    • manipulering av data eller processer i en AWS-miljö anropades 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.
    • få behörigheter på hög nivå till en AWS-miljö anropades 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 försvagades.
  • 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 TOR-avslutsnods IP-adress.

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 cloud Identity- och IAM-rapporterna för att få aviseringar om vissa misstänkta aktivitetsmönster. Du kan också använda Principinformation för att analysera aktiviteter för tjänstkonton för att identifiera aktiviteter som tjänstkonton i projektet som 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-kontroller v8 ID:n NIST SP 800-53 r4 ID:n 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 undersökningar av säkerhetsincidenter och säkerhetsåtgärds- och efterlevnadsändamål.

Azure-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 driftsloggar på nivåerna hantering/kontrollplan och dataplan. 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å tjänst- och resurstyp i Azure.
  • 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:

  • Varuautomatloggar: 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 publiceras 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 lagrings- och kvarhållningsprinciper för 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 driftsloggar på nivåerna hantering/kontrollplan och dataplan. Tjänsten Operations Suite Cloud Logging samlar in och aggregerar alla typer av logghändelser från resursnivåer. Fyra kategorier av loggar stöds i Molnloggning:

  • 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-kontroller v8 ID:n NIST SP 800-53 r4 ID:n 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 resursloggar för nätverkssäkerhetsgrupper (NSG), NSG-flödesloggar, Azure Firewall loggar och Web Application Firewall-loggar (WAF) 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 Trafikanalys 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-lagringsbucket 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 urval av 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, datateknik, säkerhetsanalys i realtid och kostnadsoptimering.

Du kan visa flödesloggar i Cloud Logging och exportera loggar till målet som cloud logging export stöder. Flödesloggar aggregeras efter anslutning från beräkningsmotorns virtuella datorer 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 som klonar trafiken för angivna instanser i ditt VPC-nätverk (Virtual Private Cloud) och vidarebefordrar 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: Central hantering och analys av säkerhetsloggar

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n PCI-DSS ID(er) v3.2.1
8.9, 8.11, 13.1 AU-3, AU-6, AU-12, SI-4 Ej tillämpligt

Säkerhetsprincip: Centralisera loggning av lagring 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 MOLNLÖSNINGsleverantörer. 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 (hantering av säkerhetsinformationshändelser) 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 central resurs för lagring och analys. Använd CloudWatch för att köra frågor mot och utföra analyser och för att skapa aviseringsregler med hjälp av loggarna aggregerade från AWS-tjänster, tjänster, slutpunktsenheter, nätverksresurser och andra säkerhetssystem.

Dessutom kan du aggregera loggarna i en S3-lagringsbucket och registrera loggdata till Microsoft Sentinel som tillhandahåller funktioner för hantering av säkerhetsinformationshändelser (SIEM) 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 central resurs (till exempel Operations Suite Cloud Logging-bucket) för lagring och analys. Molnloggning stöder merparten av den interna Tjänstloggningen i Google Cloud samt program från tredje part och lokala program. Du kan använda Molnloggning 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 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 aggregera loggar/aviseringar i din befintliga SIEM.

Obs! Google tillhandahåller två loggfrågasklientdelar, Logs Explorer och Log Analytics för frågor, visning och analys av loggar. För felsökning och utforskning av loggdata rekommenderar vi att du använder Logs Explorer. Om du vill 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 loggar

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n 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-, regel- 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 operativsystem och program på virtuella datorer.

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

  • Använd Azure Monitor Log Analytics-arbetsytan för en kvarhållningsperiod för loggar på upp till 1 år eller enligt dina krav från 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. Admin aktivitetsgranskningsloggar, systemhändelsegranskningsloggar och åtkomsttransparensloggar behålls som standard 400 dagar. Du kan konfigurera Molnloggning för att behålla loggar mellan 1 dag och 3650 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-kontroller v8 ID:n NIST SP 800-53 r4 ID:n 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. Använd microsofts standardoperativsystem för beräkningsresurser för tidssynkronisering om du inte har ett specifikt krav. Om du behöver skapa en egen NTP-server (Network Time Protocol) kontrollerar du att du skyddar UDP-tjänstporten 123.

Alla loggar som genereras av resurser i Azure tillhandahåller 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 har konfigurerats använder du AWS standardtjänst för amazontidssynkronisering för tidssynkronisering om du inte har ett specifikt krav. Om du behöver skapa en egen NTP-server (Network Time Protocol) kontrollerar 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 operativsystemen 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 skapa en egen NTP-server (Network Time Protocol) ser du till att skydda 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):