Een securitylog helpt reconstrueren wie wat op welke resource heeft geprobeerd, wanneer dat gebeurde en met welk resultaat. Het is geen kopie van alle requests en ook geen dump van exceptions. Het doel is bruikbaar bewijs te leveren voor onderzoek naar verdachte toegang en acties, met zo weinig mogelijk gegevens en met maatregelen die voorkomen dat het log zelf een bron van blootstelling wordt.
Bij het ontwerpen van securitylogging in PHP is het verstandig eerst vast te stellen welke gebeurtenissen ertoe doen en waarvoor ze worden gebruikt: detectie, onderzoek, operationele audit of naleving van intern beleid. Stel vervolgens een gemeenschappelijk formaat vast, bepaal wie de logs mag raadplegen en test de volledige keten. Een log dat wel bestaat, maar waarin gebeurtenissen niet op volgorde kunnen worden gezet, het resultaat niet kan worden vastgesteld of pogingen niet van voltooide acties kunnen worden onderscheiden, voorziet niet in de onderzoeksbehoefte.
Technische logs, activiteit en securitygebeurtenissen scheiden
Technische logs beschrijven de werking van de applicatie: fouten, exceptions, latency, verbindingsstoringen of configuratieproblemen. Ze helpen bij het diagnosticeren van beschikbaarheid en gedrag. Een activiteitenlog documenteert bedrijfsacties die aan gebruikers kunnen worden toegeschreven, zoals het bewerken van een factuur of het wijzigen van accountgegevens. Securitygebeurtenissen richten zich daarentegen op feiten die relevant zijn voor de bescherming van identiteiten, rechten, resources en toegangsgrenzen.
Er zijn overlappingen, maar de categorieën zijn niet onderling uitwisselbaar. Een rolwijziging kan zowel een bedrijfsactiviteit als een securitygebeurtenis zijn; een database-exception is doorgaans technisch, hoewel een reeks fouten bij een gevoelige operatie aanleiding kan zijn voor een securitywaarschuwing. Door de doelen vast te leggen voorkomt u ongerichte duplicatie van informatie en kunt u passende bewaartermijnen, toegangsrechten en formaten toewijzen.
Gebruik het securitylog niet als onbeperkte auditopslag of als vervanging van metrics en traces. Ga er ook niet van uit dat het vastleggen van een gebeurtenis hetzelfde is als detectie: voor waarschuwingen zijn regels, drempelwaarden en verantwoordelijken voor de opvolging nodig. Documenteer welk systeem elke gegevensset produceert en welk team die gebruikt.
Acties en context kiezen die onderzoek mogelijk maken
Begin met een inventarisatie van acties en dreigingen die relevant zijn voor de applicatie. Gebeurtenissen die doorgaans in aanmerking komen, zijn mislukte aanmeldingen, accountblokkeringen, wijzigingen van inloggegevens, het toekennen of intrekken van rechten, configuratiewijzigingen, gevoelige exports en administratieve operaties. De lijst moet aansluiten op het product: elke paginaweergave vastleggen kan ruis opleveren, terwijl het weglaten van een wijziging van privileges het reconstrueren van ongeoorloofde toegang onmogelijk maakt.
Bepaal voor elke gebeurtenis welke vraag ermee beantwoord moet kunnen worden. Bij onderzoek naar een rechtenwijziging is het bijvoorbeeld van belang de actor, de getroffen gebruiker of resource, het oude en nieuwe recht, het resultaat en het tijdstip vast te stellen. Bij een mislukte authenticatie kan de genormaliseerde of gepseudonimiseerde accountidentificatie relevant zijn, afhankelijk van het beleid, naast het resultaat en de herkomst van de aanvraag als het verzamelen daarvan gerechtvaardigd is. Leid geen identiteit af uit een gedeeld IP-adres.
Maak onderscheid tussen poging, beslissing en resultaat. Een geweigerde aanvraag is geen voltooide wijziging; een geaccepteerd verzoek kan mislukken voordat de wijziging is opgeslagen. Leg het werkelijke resultaat vast en, wanneer dat nodig is voor onderzoek, ook de bereikte fase. Definieer eveneens wat elke waarde betekent, zoals denied, failed of succeeded, zodat verschillende componenten ze niet tegenstrijdig gebruiken.
Een consistent en correleerbaar schema gebruiken
Een gestructureerd formaat, meestal JSON, maakt het eenvoudiger gebeurtenissen te filteren en te correleren in operationele tools. Overweeg deze velden als basis:
- Gebeurtenis-ID: een stabiele, geversioneerde naam, bijvoorbeeld
authorization.permission_changed. - Tijdstip: datum en tijd in UTC, met passende precisie en gesynchroniseerde systeemklokken.
- Actor: interne identificatie of pseudoniem; geef processen en geautomatiseerde taken expliciet weer.
- Actie en resource: de uitgevoerde bewerking en het type en de identificatie van de getroffen resource, zonder de inhoud ervan op te nemen.
- Resultaat: geslaagd, geweigerd of mislukt, met een gecategoriseerde, niet-gevoelige reden.
- Correlatie: een request- of operatie-ID om gebeurtenissen aan elkaar te koppelen zonder het volledige request vast te leggen.
- Context van de herkomst: de service of component die de gebeurtenis heeft uitgegeven en, als dat gerechtvaardigd is, beperkte gegevens over de netwerkherkomst.
Veldnamen en typen moeten stabiel blijven. Een requestcorrelatie moet door de infrastructuur worden gegenereerd of gevalideerd; een willekeurige identificatie zonder controle accepteren kan botsingen of verwarring veroorzaken. Neem geen volledige headers, HTTP-bodies of parameters zonder onderscheid op. Context moet helpen de volgorde te reconstrueren, niet alle verwerkte gegevens kopiëren.
Geheimen uitsluiten en persoonsgegevens minimaliseren
Leg nooit wachtwoorden, access tokens, API-sleutels, sessiegeheimen, herstelcodes of waarden vast waarmee iemand zich kan authenticeren. Vermijd ook volledige persoonsgegevens wanneer een interne identificatie volstaat. Bepaal voor velden zoals e-mailadres, telefoonnummer of adres of opslag noodzakelijk is, of ze gemaskeerd kunnen worden en of een gepseudonimiseerde verwijzing geschikter is. De keuze hangt af van het doel, het risico en de toepasselijke verplichtingen.
Redigeer gegevens voordat de gebeurtenis het proces verlaat; vertrouw niet uitsluitend op een latere filter van de aggregator. Serialiseer in PHP geen requestobjecten, headers of exceptions rechtstreeks, omdat die gevoelige waarden kunnen bevatten. Maak een expliciet object of array met een allowlist van velden; een denyliststrategie is kwetsbaar zodra er nieuwe velden bijkomen. Valideer en begrens ook de lengte van door gebruikers beheersbare waarden om regelinjectie, ruis en overmatig verbruik te beperken.
Test gevallen waarin geheimen voorkomen in parameters of foutmeldingen en controleer of ze de logbestemming niet bereiken. Sanitization moet voldoende informatie voor onderzoek behouden, bijvoorbeeld een foutcategorie, zonder de volledige melding te bewaren als die inloggegevens kan bevatten.
Toegang, integriteit en levenscyclus beschermen
Logs bevatten zelf ook gevoelige informatie. Beperk wie mag schrijven, lezen, exporteren en het bewaarbeleid beheren; voor deze functies kunnen verschillende rechten nodig zijn. Bescherm transport en opslag met passende maatregelen voor de infrastructuur en voorkom dat een gecompromitteerd account van de applicatie de volledige geschiedenis spoorloos kan wissen of wijzigen. Gebruik, wanneer het risico dat rechtvaardigt, append-only-opslag of controleerbare integriteitsmaatregelen en documenteer de beperkingen ervan.
Stel per gebeurtenisklasse een expliciete bewaartermijn vast. Onbeperkt bewaren vergroot de blootstelling en de kosten; te vroeg verwijderen kan een onderzoek belemmeren. Het beleid moet rekening houden met back-ups, exports, testomgevingen en verwijderverzoeken die persoonsgegevens betreffen. Leg de toegang van operators tot de logs zelf vast en controleer die, vooral exports en beleidswijzigingen.
Logging kan uitvallen doordat de bestemming niet beschikbaar is, de opslaglimiet is bereikt of serialisatie mislukt. Bepaal voor elk geval wat er gebeurt op basis van de kritikaliteit. Laat een storing van het logsysteem er niet toe leiden dat een operatie met een hoog risico stilzwijgend wordt voltooid, maar voorkom ook dat een loggingexception inconsistente resultaten veroorzaakt of een transactie dupliceert. Voor kritieke operaties kan het nodig zijn de gebeurtenis samen met de wijziging op te slaan via een transactionele strategie, zoals het outbox pattern. Definieer bij gebruik van een queue de retries, deduplicatie en afhandeling van openstaande gebeurtenissen.
Testen of de gebeurtenis bestaat en veilig is
Tests moeten meer controleren dan alleen de aanroep van een loggingfunctie. Doorloop representatieve scenario’s: geweigerde toegang, toegekend privilege, ingetrokken privilege en een gevoelige wijziging die wel of niet wordt voltooid. Controleer of de gebeurtenis de actor, resource, het resultaat, tijdstip en de correlatie bevat; of het resultaat overeenkomt met wat er werkelijk is gebeurd; en of wachtwoorden, tokens of onnodige gegevens ontbreken.
Neem tests op voor storingen van de logbestemming en controleer of de hoofdoperatie in een consistente toestand blijft, of er een alternatieve melding wordt gegenereerd en of de fout zichtbaar wordt voor operations. Bevestig bij een gevoelige actie dat er geen succes wordt gemeld als de wijziging niet is opgeslagen. Test ook grenzen en gemanipuleerde invoer, zoals regeleinden in door gebruikers beheersbare waarden, en test leesrechten per rol: een bedrijfsgebruiker mag niet standaard toegang hebben tot de opslagplaats met gebeurtenissen.
Checklist voor het beoordelen van een implementatie
- Heeft elke gebeurtenis een vastgelegd doel, een verantwoordelijke en een bewaarbeleid?
- Worden pogingen, weigeringen, fouten en voltooide operaties van elkaar onderscheiden?
- Maakt het schema het mogelijk de actor, actie, resource, het resultaat en tijdstip vast te stellen?
- Is er correlatie met het request zonder de volledige inhoud ervan vast te leggen?
- Worden geheimen uitgesloten en persoonsgegevens geminimaliseerd voordat gegevens worden verzonden?
- Zijn toegang, transport, opslag en verwijdering gecontroleerd?
- Zijn een niet-beschikbare bestemming, de integriteit van de operatie en leesrechten getest?
Geef eerst prioriteit aan gebeurtenissen die accounts, privileges en operaties met de grootste impact beschermen. Standaardiseer daarna het schema, beperk de gegevens en automatiseer tests die mislukken zodra een geheim in de logs terechtkomt. Zo levert securitylogging in PHP bruikbaar bewijs op zonder een tweede database met gevoelige informatie te worden.
