Serverlogs en privacyUw host stopte met loggen. Uw server niet.

U bent nu de partij aan wie iemand schrijft

Wie wil weten wie uw site heeft bezocht, begint niet bij uw host. Die begint bij u, want u bent de enige partij in de keten met een direct belang bij het bewaren van het record, een juridisch adres waaraan geschreven kan worden, en geen transparantierapport om achteraf te publiceren.

Dat is een ongemakkelijke zin voor een hostingbedrijf om te schrijven, dus hier is de rekensom erachter. De hier gepubliceerde inventaris zegt dat HTTP access logs na vierentwintig uur automatisch worden vernietigd en dat er daarna nergens een adresgeschiedenis bestaat. Een standaard webserver op een machine die u van ons huurt, bewaart zijn eigen access log ongeveer veertien dagen, in een nachtelijke back-up een jaar lang, en niemand heeft een van beide getallen bewust ingesteld. De zorgvuldig gekozen host wordt tenietgedaan door een standaardinstelling die niemand heeft gelezen.

Wat één regel van een access log werkelijk bevat

Het standaardformaat op beide gangbare webservers is al vijfentwintig jaar stabiel, en bijna niemand leest het als een record van een persoon. Het is de moeite waard om het één keer zo te lezen, want elk veld hieronder is een aparte onthulling, en ze stapelen zich op.

Zeven velden, één regel, geschreven voor elk verzoek dat een browser doet — wat voor één paginaweergave meestal ergens tussen de twintig en tachtig regels betekent. Niets daarvan was een beslissing. Alles ervan is een record.

Negen plekken waar uw eigen stack een bezoeker vastlegt

Bijna elke discussie over logging gaat over de eerste rij. Het is de enige waarvan mensen weten dat hij bestaat, en hij is lang niet het onthullendste ding op de machine.

De laatste rij is degene die de meeste goede voornemens ondermijnt. Een logrotatie verkorten van veertien dagen naar één verandert wat er op de schijf staat, en verandert helemaal niets aan de kopie die om drie uur 's nachts is gemaakt en een jaar lang bewaard zal blijven. Een record verwijderen dat u al hebt gerepliceerd, is een verandering van locatie, geen verwijdering.

De twee velden die meer weggeven dan het adres

Een adres is het veld waar iedereen over discussieert, en het is het veld met de kortste nuttige levensduur: het verandert, het wordt gedeeld, en op een mobiel netwerk hoort het bij een provider in plaats van bij een persoon. De twee ernaast zijn in alle stilte erger.

Het verwijzende adres beschrijft de lezer, niet het verzoek

Het beantwoordt een vraag die u nooit hebt gesteld: waar was deze persoon een seconde geleden. Dat is een doorgestuurde link naar een privédocument, een intern ticketsysteem, een voorvertoning van een mailclient, of een pagina op een site die deze persoon niet graag aan de uwe gekoppeld zou zien. Browsers korten het pad nu in wanneer de bestemming een andere origin is, wat helpt — en helemaal niets doet voor de links binnen uw eigen site, waar het volledige pad nog steeds wordt verstuurd en vastgelegd.

De user agent is de kiem van een vingerafdruk

Op zichzelf is het een menigte. Gecombineerd met een adres, een taalheader, een volgorde van verzoeken en een set geaccepteerde formaten, is het vaak wekenlang dezelfde ene bezoeker — zonder cookie, zonder toestemming, en zonder dat iemand heeft besloten om iets te volgen. Dit is het mechanisme dat van “wij bewaren alleen serverlogs” een zwakkere zin maakt dan degene die het zegt gelooft.

Geheimen komen in het log terecht omdat ze in de URL stonden

Dit is de fout waarvoor het de moeite waard is deze pagina te lezen, want ze komt vaak voor, ze verloopt onopgemerkt en ze ligt volledig binnen uw eigen controle. Alles na het vraagteken maakt deel uit van de request line, en de request line is wat wordt weggeschreven.

• Links om een wachtwoord opnieuw in te stellen. Een eenmalig token in een query string wordt in platte tekst vastgelegd in het access log, in de back-up van het access log, en bij elke proxy tussen de lezer en u.
• Uitnodigings- en afmeldlinks. Dezelfde vorm, langer levend, en over het algemeen met helemaal geen vervaldatum.
• Sessie-ID's die in de URL worden meegegeven. Zeldzaam in nieuwe code, nog altijd aanwezig in oude code, en een complete account-overname voor wie het bestand in handen heeft.
• API-keys die aan een browser worden meegegeven. Een key in een query string is een key in een log, een key in een referrer die naar een derde partij wordt gestuurd, en een key in de geschiedenis van de lezer.
• Het zoekvak. Een sitezoekfunctie die via GET werkt, legt elke zoekopdracht die ooit in uw site is getypt vast, samen met het adres van wie de opdracht typte.

De oplossing is geen loginstelling. Verplaats de waarde naar een header of een request body, waar geen enkel standaardformaat het vastlegt, en roteer alles wat al is weggeschreven. Een logfilter dat tokens verwijdert, is een tweede ding om te onderhouden, en het klopt niet meer zodra iemand een parameter toevoegt.

Wat er van u kan worden geëist, en door wie

De andere gidsen hier gaan over instrumenten die een hostingbedrijf bereiken in een jurisdictie die daarvoor is gekozen. Het instrument dat uw eigen logs bereikt, is eenvoudiger: het wordt aan u betekend, waar u zich bevindt, en de locatie van de machine maakt geen deel uit van de vraag.

• Een civiele vordering in uw eigen land. Iemand die een rechtszaak aanspant over een reactie, een lek of een aankoop, vraagt de beheerder van de site om wat de beheerder heeft. Dat bent u, en veertien dagen aan access logs is iets wat gemakkelijk kan worden bevolen om over te leggen.
• Een verzoek van een lezer. Onder de Europese wetgeving inzake gegevensbescherming mag iemand vragen wat u over hem of haar bewaart, en een adres kan persoonsgegevens zijn: het Hof van Justitie oordeelde dat al in 2016 in Case C-582/14, waar een dynamisch adres dat een website-exploitant bewaarde persoonsgegevens was, omdat er een rechtmatige weg naar de abonnee bestond. Ook de bewaartermijn moet gerechtvaardigd zijn — Article 5(1)(e) stelt dat het niet langer mag duren dan noodzakelijk, en “zo werd het pakket nu eenmaal verzonden” is geen doel.
• Wie de machine ook compromitteert. De meest waarschijnlijke lezer van uw access log is helemaal geen rechtbank. Logs zijn zelden versleuteld, zelden gemonitord en bijna nooit opgenomen in een dreigingsmodel, en ze staan op een voorspelbaar pad op elke server die op de gebruikelijke manier is ingericht.
• Iedereen die uw back-ups bereiken. Een externe kopie is een kopie bij een ander bedrijf, onder een andere jurisdictie, verantwoording verschuldigd aan instrumenten die u niet hebt gelezen.

Niets daarvan is juridisch advies, en deze onderneming is uw advocaat niet. Het is dezelfde inventarislogica, toegepast op uw kant van de lijn: wat u niet kunt overleggen, kan ook niet van u worden geëist, en al het overige is een kwestie van wiens rechtbank er vraagt. Hoe dat uitpakt aan de kant van de hosting, staat beschreven in wat er werkelijk gebeurt als de politie een host om informatie vraagt.

Minder bewaren zonder blind te worden

De reflex na het lezen tot hier is om logging helemaal uit te zetten, en dat is de verkeerde zet: een server zonder logs kan niet worden gedebugd, kan niet verstandig rate-limited worden, en kan u niet vertellen dat er op dit moment wordt ingebroken. Het doel is niet nul. Het doel is het bewaren van het deel dat een operationele vraag beantwoordt, en het weggooien van het deel dat alleen een vraag over een persoon beantwoordt.

Twee van die zes kosten helemaal niets en maken het grootste deel van de blootstelling op deze pagina ongedaan. De laatste is degene waar niemand aan denkt, en dat is de reden waarom de andere vijf tekortschieten.

De derde partijen die uw lezers voor u loggen

Alles hierboven gaat over bestanden op een machine die u zelf beheert. Een browser die uw pagina laadt, opent ook een verbinding met elke andere origin die de pagina noemt, en elk daarvan ontvangt het adres, de user agent en een referrer die aangeeft welke van uw pagina's werd gelezen — nog voordat er ook maar een toestemmingsbanner is beantwoord, want het verzoek is dan al vertrokken.

• Een font dat door iemand anders wordt geserveerd. Eén regel in een stylesheet, en elke lezer van elke pagina wordt onthuld aan een derde partij, voor een bestand dat u net zo goed in dezelfde map als de rest van de site had kunnen hosten.
• Een ingesloten video of kaart. Wordt geladen zodra hij in beeld komt, op elke pagina waarop hij verschijnt, of iemand nu op play drukt of niet.
• Een chatwidget of een tag manager. Standaard aanwezig op elke pagina, en in staat om verdere code te laden die u niet hebt gecontroleerd.
• Een error tracker. De nuttigste van allemaal, en de meest onthullende: hij bestaat om u de status van de sessie van iemand anders te sturen.
• Een CDN voor de hele site. Geen pleidooi tegen het gebruik ervan — het is een redelijke ruil — maar het is een bedrijf dat elk verzoek ziet voordat u dat doet, zijn eigen logs bijhoudt, en verantwoording aflegt aan zijn eigen jurisdictie.

De eerste drie zelf hosten is meestal een middagje werk, en het neemt meer observatie door derden weg dan welke instelling op uw eigen server dan ook. Het is ook het deel van deze pagina dat verbetert wat uw lezers krijgen, in plaats van alleen wat u kan worden bevolen te overleggen, en dat is de reden om het eerst te doen. De equivalente lijst, gericht op uw eigen blootstelling in plaats van die van uw lezers, staat in de negen dingen die een site identificeren.

Wat deze onderneming daaraan kan doen, en wat niet

Die grens eerlijk trekken is meer waard dan een geruststelling, dus hier is hij, van onze kant.

• Onze eigen HTTP access logs worden na precies vierentwintig uur automatisch vernietigd, en er is geen adresgeschiedenis, geen record van inloglocaties en geen vingerafdruk die het overleeft. De volledige lijst van wat wel overleeft, is gepubliceerd als inventaris, en die loopt tot zeven records.
• Wat er via een juridische procedure binnenkomt, wordt bijgehouden in het transparantierapport, en wat een geldig bevel daadwerkelijk oplevert, staat vooraf vastgelegd in plaats van dat het op het moment zelf wordt beslist.
• Op een VPS of een dedicated server bevinden de logs die op deze pagina worden beschreven zich binnen uw eigen besturingssysteem. Wij lezen ze niet, wij versturen ze nergens naartoe, en wij kunnen ze ook niet voor u configureren — single tenancy werkt naar twee kanten, en dat is precies het punt ervan.
• Wat wij wel kunnen dragen, is de laag eronder: geen identiteitsregistratie bij aanmelding, afwikkeling uitsluitend on-chain, en een machine in een jurisdictie die u zelf hebt gekozen, in plaats van de jurisdictie waarin de uitgever van uw kaart gevestigd is.

En dan de zin waarvoor deze pagina bestaat: een host kiezen op basis van wat hij weigert te bewaren, en vervolgens veertien dagen van datzelfde zelf bewaren, is een privacybeslissing die door een configuratiebestand ongedaan wordt gemaakt. De twee helften zijn qua inspanning niet vergelijkbaar. De ene kostte een week lezen, de andere kost een middag, en maar één van de twee is afgerond.

Een audit van een uur voor uw eigen logs

Niets hieronder vereist een hulpmiddel dat u moet kopen, en elke stap vertelt u iets wat de vorige stap nog niet vertelde.

1. Print één regel van uw eigen access log uit en lees hem hardop, veld voor veld, zoals een vreemde dat zou doen.
2. Maak een lijst van elk bestand in uw logmap, en markeer welke u in het afgelopen jaar hebt geopend. De ongemarkeerde bestanden zijn pure aansprakelijkheid.
3. Lees de rotatieconfiguratie en schrijf op hoeveel dagen er werkelijk worden bewaard, in plaats van het getal waarvan u zich herinnert dat u ermee instemde.
4. Zet de back-up van vorige maand terug in een tijdelijke map, en zoek naar het log waarvan u dacht dat het veertien dagen geleden was verwijderd.
5. Doorzoek uw access log op de woorden token, reset, key, session en password. Alles wat u vindt, is een geheim dat al naar schijf is weggeschreven en moet worden geroteerd, niet alleen gerepareerd.
6. Laad uw eigen homepage met het netwerkpaneel van de browser open, en schrijf elk gecontacteerd domein op dat niet van uzelf is. Elk daarvan is een bedrijf dat uw lezers vasthoudt onder zijn eigen bewaartermijn.
7. Controleer welke header het echte adres achter uw proxy of CDN meedraagt, en ga na of de origin het vastlegt. Een CDN stopt de origin niet met loggen; het verplaatst alleen het veld.
8. Open de meest recente gebeurtenis in uw error tracker en tel hoeveel details van een echte lezer zich in de payload bevinden.
9. Bepaal bewust drie bewaartermijnen — beveiliging, analytics, back-ups — en schrijf ze op waar de volgende persoon die de server aanraakt ze zal vinden.
10. Schrijf de inventaris: wat bestaat er, waar, hoe lang, en wat u zou overleggen als er morgenvroeg een geldig bevel binnenkwam. Als dat document ongemakkelijk is om te schrijven, is dit het nuttigste uur van deze lijst.

Vragen die mensen echt stellen

Elke prijs binnen deze infrastructuur wordt volledig gepubliceerd, op één plek. Bekijk de volledige catalogus