Er is iets veranderd op uw website en niemand weet door wie. De prijzen op een pagina kloppen niet meer, een menu-item is verdwenen of een instelling staat anders dan vorige week. In een bedrijf met vier mensen die in het beheerscherm komen, is dat al een vervelend gesprek. Een WordPress inloggeschiedenis maakt van dat gesprek een feitelijke controle van dertig seconden.

Standaard houdt WordPress dit niet bij. U ziet wel wie een bericht het laatst heeft opgeslagen, maar niet wie er heeft ingelogd, vanaf welk adres, of wie een plugin heeft uitgeschakeld. In dit artikel leest u wat u wel en niet kunt vastleggen, hoe u het inricht en hoe u voorkomt dat het logboek een berg ruis wordt die niemand meer opent.

Waarvoor u het in de praktijk gebruikt

Drie situaties komen er steeds uit, en het is nuttig om ze uit elkaar te houden omdat ze verschillende instellingen vragen.

Terugzoeken wat er is gebeurd. De alledaagse variant. Iemand heeft een wijziging gedaan, u wilt weten wie en wanneer, zodat u het kunt terugdraaien of navragen. Hier gaat het om wijzigingen aan inhoud en instellingen.

Signaleren dat er iets niet klopt. Een inlog om drie uur ‘s nachts vanaf een adres in een land waar u niemand heeft zitten. Of een gebruiker die opeens beheerdersrechten kreeg. Hier gaat het om afwijkingen, en dus om meldingen in plaats van naslag.

Aantonen wat er is gebeurd na een incident. Bij een vermoeden van een datalek wilt u kunnen laten zien welke accounts actief waren en wat er is benaderd. Dat vraagt om een logboek dat maanden teruggaat en dat niet op dezelfde plek staat als de site zelf.

Wat u kunt vastleggen

Een goed activiteitenlogboek registreert meer dan alleen inlogmomenten. De onderdelen die er in de praktijk toe doen:

  • Geslaagde en mislukte inlogpogingen, met gebruikersnaam, tijdstip en IP-adres.
  • Uitlogmomenten en de duur van sessies.
  • Aangemaakte, gewijzigde en verwijderde gebruikers, en vooral wijzigingen in rollen.
  • Wachtwoordwijzigingen en aanvragen voor een nieuw wachtwoord.
  • Geïnstalleerde, bijgewerkte, geactiveerde en verwijderde plugins en thema’s.
  • Wijzigingen aan pagina’s, berichten en producten, inclusief wie ze publiceerde.
  • Aanpassingen aan de instellingen van WordPress zelf, zoals het adres van de site of de standaardrol voor nieuwe gebruikers.
  • Geüploade en verwijderde mediabestanden.

Wat u er niet uit haalt: wat iemand heeft gelézen. Een logboek registreert handelingen, geen blikken. Wilt u weten of iemand klantgegevens heeft ingezien, dan heeft u daar een aparte voorziening voor nodig, en bij de meeste kleine sites bestaat die niet.

Zo richt u het in

  1. Kies een plugin die alleen logt en verder niets doet. Er zijn er meerdere die dit goed doen, waaronder de logboekfunctie in de bekende beveiligingspakketten. Een aparte, lichte plugin is meestal overzichtelijker.
  2. Zet de bewaartermijn bewust. Dertig dagen is voor dagelijks gebruik genoeg, maar te kort voor onderzoek achteraf. Negentig dagen tot een jaar is een redelijke keuze, mits uw database dat aankan.
  3. Beperk wat u logt. Logt u elke opgeslagen conceptversie, dan heeft u binnen een maand honderdduizend regels en vindt u niets meer terug. Begin met inlogpogingen, gebruikerswijzigingen, plugin- en themawijzigingen en gepubliceerde inhoud.
  4. Zet meldingen aan voor precies vier gebeurtenissen: een nieuwe beheerder, een rolwijziging naar beheerder, een geslaagde inlog vanaf een onbekend land, en het uitschakelen van uw beveiligingsplugin. Meer meldingen betekent minder gelezen meldingen.
  5. Zorg dat het logboek buiten de site wordt bewaard, of stuur de belangrijkste gebeurtenissen door naar een mailbox. Een logboek dat alleen in de gehackte site staat, is precies het eerste wat een aanvaller wist.
  6. Controleer of de database niet te snel groeit. Kijk na een maand hoe groot de logtabel is en stel de bewaartermijn zo nodig bij; meer over dat opruimen staat bij het opschonen van een volgelopen database.

De AVG-kant, in gewone taal

Een inloggeschiedenis bevat persoonsgegevens: namen van medewerkers, tijdstippen en IP-adressen. Dat mag u vastleggen voor beveiliging en beheer, maar er horen wel drie dingen bij.

Vertel uw medewerkers dat het gebeurt en waarvoor. Dat is niet alleen netjes, het voorkomt ook dat het logboek als controlemiddel op productiviteit wordt gezien; daar is het niet voor bedoeld en daarvoor mag het ook niet zomaar worden gebruikt. Bewaar de gegevens niet langer dan nodig, en zet die termijn in uw eigen overzicht van verwerkingen. Meer over dat overzicht leest u bij de checklist voor privacy op uw website.

Wij zijn geen juristen. Verwerkt u gevoelige gegevens of heeft u een ondernemingsraad, laat de opzet dan even nakijken door iemand die dat wel is.

Wanneer u dit niet nodig heeft

Bent u de enige die ooit inlogt op uw website, dan voegt een uitgebreid activiteitenlogboek weinig toe. In dat geval is een simpele melding bij elke geslaagde inlog vanaf een onbekend apparaat waarschijnlijk genoeg, en scheelt u zich een plugin en een groeiende tabel.

Vanaf ongeveer drie mensen met toegang, of zodra er een extern bureau meekijkt, kantelt dat. Dan is de vraag “wie heeft dit gedaan” geen theorie meer maar iets wat een paar keer per jaar langskomt. En na een vertrekkende medewerker is het logboek het eerste waar u kijkt of het oude account nog is gebruikt.

Voor klanten met meerdere beheerders zetten wij dit standaard op als onderdeel van het afschermen en bewaken van beheerderstoegang, met een korte maandelijkse blik op de opvallende regels in plaats van een rapport dat niemand opent.

Concrete volgende stap: kijk in uw gebruikerslijst hoeveel accounts er beheerdersrechten hebben. Zijn dat er meer dan u kunt opnoemen, dan is dat de eerste opruiming en het logboek de tweede.