Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen
I mange organisationer går trafikken ikke længere gennem en firewall i serverrummet. Brugerne forbinder via en agent til en cloudtjeneste, der fungerer som webproxy, firewall og adgangsgateway (SASE og SSE), og interne programmer nås via ZTNA i stedet for VPN. For en undersøgelse betyder det, at de netværkslogs, der tidligere lå på egen hardware, nu ligger i leverandørens platform med leverandørens opbevaringstid, felter og eksportmuligheder. Loggene er ofte bedre end de gamle, fordi de kobler trafik til en bruger og en enhed, men de skal hentes, før de udløber, og deres felter skal forstås.
De klassiske kilder er beskrevet i Proxy- og webfilterlogs og VPN-logs. Her er det de cloudbaserede varianter.
Hvad loggene typisk indeholder
Navne og felter varierer mellem leverandører, men de fleste platforme har de samme logtyper:
- Webtrafik: tidspunkt, bruger, enhed, destination (domæne eller URL), kategori, handling (tilladt, blokeret, advaret), datamængde op og ned, og om trafikken blev TLS-inspiceret.
- Adgang til interne programmer (ZTNA): bruger, enhed, program, connector eller gateway, resultat af politikvurdering og sessionens start og slut.
- Firewall og DNS: forbindelser og opslag, der går gennem tjenesten.
- DLP og CASB: upload af filer, brug af cloudtjenester og hændelser, der har udløst en regel; se DLP-hændelser.
- Administration: ændringer af politikker og indstillinger, og hvem der lavede dem.
- Klient og enhed: agentens status, enhedens overholdelse af krav og forbindelsestidspunkter.
Fordi brugeren er logget ind i agenten via organisationens identitetsudbyder, er brugernavnet i loggen som regel en reel identitet, ikke en IP-adresse, der skal oversættes. Koblingen til loginloggen hos identitetsudbyderen er beskrevet i Identitetsudbydere og SSO.
IP-adresser i en SASE-verden
En af de største faldgruber er IP-adresser. Når trafikken går gennem leverandørens net, ser destinationen leverandørens udgående adresse, ikke brugerens. Det har konsekvenser i begge retninger:
- En IP-adresse i fx Microsoft 365’s loginlog kan være leverandørens adresse og dermed dele den med mange andre kunder, hvis leverandøren ikke tildeler dedikerede adresser.
- Brugerens egen offentlige adresse, fx hjemmeforbindelsen, fremgår kun af SASE-loggen som klientens kildeadresse, hvis platformen registrerer den.
Kortlæg derfor tidligt, om organisationen har dedikerede udgående adresser, og hvilke adresser der hører til leverandøren. Ellers kan en IP-baseret korrelation give fejlagtige resultater. Se IP-adresser som bevis.
ZTNA i stedet for VPN
Med VPN fik brugeren adgang til et helt netsegment, og VPN-loggen viste en tildelt adresse og en session. Med ZTNA vurderes hver adgang til et program for sig ud fra identitet, enhed og kontekst, i tråd med principperne i NIST’s zero trust-arkitektur. Loggen bliver derfor mere fintmasket: Den viser, hvilke programmer brugeren forsøgte at nå, og om politikken tillod det. Til gengæld ser ZTNA-platformen ikke, hvad der skete inde i programmet. Det skal findes i programmets egen log. En connector eller gateway i det interne net kan have sine egne logs, som også skal sikres.
Opbevaring og eksport
Opbevaringen i leverandørens konsol er typisk kort og bestemt af licensen. Organisationer, der har brug for længere historik, streamer normalt loggene til egen SIEM eller lagerkonto via leverandørens eksportfunktion. Undersøgelsen skal derfor fastslå:
- hvor lang tid loggene opbevares i platformen,
- om de streames til en SIEM eller et arkiv, og fra hvornår,
- om streamingen omfatter alle logtyper, eller kun nogle,
- om der er huller, fx perioder hvor eksporten var fejlet.
Eksport fra konsollen er ofte begrænset i antal rækker pr. udtræk, så store perioder må deles op eller hentes via API. Eksportens egne kontrolfiler eller sammentællinger bør gemmes, så fuldstændigheden kan vises. Når loggene ligger i en SIEM, gælder de samme krav til integritet og eksport som for andre SIEM-data; se SIEM-data som bevis.
TLS-inspektion og hvad den ændrer
Hvis tjenesten inspicerer TLS, kan loggen indeholde fulde URL’er, filnavne og indholdskategorier. Uden inspektion ser tjenesten ofte kun domænenavnet. Det afgør, hvor detaljeret en konklusion om fx upload til en privat cloudtjeneste kan blive. Mange organisationer undtager bestemte kategorier fra inspektion, fx bank og sundhed, og nogle programmer bruger certifikatfastlåsning, så trafikken ikke kan inspiceres. Undtagelserne skal dokumenteres, fordi de forklarer, hvorfor bestemte destinationer kun fremstår med domænenavn.
Trafik uden om tjenesten
En SASE-løsning ser kun den trafik, der sendes gennem den. Trafik kan gå udenom, fx når agenten er slået fra eller afinstalleret, når enheden er på et netværk med undtagelse, eller når der bruges en privat enhed. Agentens lokale logs og platformens status for enheden kan vise, hvornår agenten var aktiv. Fravær af trafik i loggen betyder derfor ikke nødvendigvis, at der ikke var trafik.
Sikring
- Afklar platform, licens og opbevaringstid, og hvem der har administratoradgang.
- Eksportér de relevante logtyper for perioden direkte fra platformen eller fra SIEM’en, og gem rå data i leverandørens format.
- Eksportér administrationsloggen, så ændringer i politikker og undtagelser i perioden kan dokumenteres.
- Gem en beskrivelse af politikker, undtagelser for TLS-inspektion og udgående IP-adresser på sikringstidspunktet.
- Sikr agentens lokale logs på de relevante enheder, hvis de er kopieret forensisk.
- Hash eksporterne, og notér forespørgsler, filtre og antal rækker.
Bed om leverandørens dokumentation for felterne i den version, der var i brug. Feltnavne og betydninger ændres med opdateringer.
Fejlkilder
- Delte udgående adresser: En IP-adresse kan høre til leverandøren og mange kunder.
- Tidsstempler: Nogle platforme logger i UTC, andre i administratorens tidszone ved eksport fra konsollen.
- Sessioner og forbindelser: En brugers aktivitet på én side kan give mange logrækker. Datamængder skal summeres korrekt.
- Blokeret er ikke forsøgt: En blokering kan skyldes baggrundstrafik fra et program, ikke en bevidst handling.
- Politikændringer: En ændret politik midt i perioden ændrer, hvad der blev logget.
Dokumentation
Rapporten skal beskrive platformens arkitektur i det omfang, det er nødvendigt for at forstå loggene: hvilke enheder og brugere var omfattet, hvilke undtagelser fandtes, og hvilke udgående adresser blev brugt. Feltbeskrivelser fra leverandøren vedlægges eller henvises til med version. Ved konklusioner om datamængder angives, hvordan summeringen er foretaget, og om der er sorteret baggrundstrafik fra. Huller i eksporten eller streamingen skal stå tydeligt.
Hvad loggene kan og ikke kan bevise
Loggene kan vise, at en bestemt bruger fra en bestemt enhed forbandt sig til en destination eller et internt program på et bestemt tidspunkt, og hvor meget data der blev overført. Med TLS-inspektion kan de vise mere detaljeret, hvad der blev hentet eller sendt. De kan ikke vise indholdet af krypteret trafik uden inspektion, trafik uden om tjenesten eller hvem der fysisk brugte enheden. Upload til privat cloud er gennemgået i Upload til privat cloud.
Kilder og versioner
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-92: Guide to Computer Security Log Management
- CISA: Zero Trust Maturity Model, version 2.0
Senest gennemgået: oktober 2026.
Næste skridt
- DHCP, Wi-Fi og NAC: hvilken enhed havde IP-adressen?
- Webserverlogs (IIS, Apache, Nginx): felter, tidszoner, proxy og CDN
- Logkorrelation: sådan kobles hændelser på tværs af systemer
Del af: Netværk og logs
Læs også: TeamViewer- og AnyDesk-logs: fjernadgang i sporene · VoIP og omstillingsanlæg: CDR, SIP-logs og optagelser
→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
