Database auditing:  wat doe je met je auditing data?

Database auditing:  wat doe je met je auditing data? Database auditing is iets dat steeds vaker bewust geactiveerd wordt. Immers een actief security beleid gaat niet alleen over het beperken van mogelijk misbruik maar ook over het kunnen detecteren daarvan. Zodra de database aan auditing doet moet er ook beheer worden gevoerd over over de audit trail. Dit is iets waarvan we in de praktijk zien dat dit niet (netjes) is ingeregeld. Dit kan er toe leiden dat bijvoorbeeld de system tablespace van een Oracle database volloopt.

In dit geval zijn er verschillende scenario’s te onderscheiden:

  • Databases waarbij auditing expliciet geregeld is door de beheerder.
    Dit zijn de gevallen waarbij er vooraf nagedacht is over het gebruik van auditing. Hierbij mag je er vanuit gaan dat er ook nagedacht is over zaken zoals bewaartermijnen en archivering van de audit-data.  Als gevolg hiervan hoop je dat er ook een archiveer en opschoon procedure actief is.
  • Oudere databases met traditionele auditing en de init.ora parameter audit_trail=DB. 
    Dit kan bijvoorbeeld gebeuren als de database met DBCA gecreëerd is.  In dit geval loop de sys.aud$ table vanzelf vol om dat bijvoorbeeld bij iedere logon gevuld wordt.
  • Nieuwere databases waarbij mixed mode auditing (de default) of unified auditing wordt gebruikt.
    Zodra de nieuwe auditing actief is en er enkele policies ijn enabled wordt er automatisch ge audit. Hiervoor is geen init.ora parameter noodzakelijk.  Als je je database met DBCA aanmaakt zijn er automatisch diverse standaard policies enabled.

Om te zien of Oracle auditing wegschrijft  kan je  een eenvoudige check doen:

select count(*) from sys.aud$;
select count(*) from unified_audit_trail;

Als een van beide queries een andere waarde dan 0 geeft dan wordt er audit informatie weggeschreven. Afhankelijk van waar die informatie staat kan je een aantal acties nemen.

  • Sys.aud$.
    Het commando
    truncate table sys.aud$
    kan gebruikt worden om de audit_trail leeg te gooien.  Om de auditing generatie echt te stoppen moeten of alle audit regels ongedaan worden gemaakt of moet de init.ora parameter audit_trail op none gezet worden
  • unified_audit_trail
    Deze nieuwe audit destination kan alleen met behulp van het dbms_audit_mgmt package beheerd worden. Hierdoor is het n iet meer mogelijk direct delete acties op onderliggende tabellen uit te voeren. Alle auditing zat met ingang van Oracle 23 volgens de unified auditing manier gaan.
    Het metalink artikel How To Purge The UNIFIED AUDIT TRAIL  geeft een aanzet hoe de unified_audit_trail op te schonen. Eventueel kan ook de AUDIT_TRAIL_ALL optie gebruikt worden maar die geeft de gebruikte ruimte minder goed vrij.
    Met het noaudit policy <naam>  commando  kunnen specifieke audit acties uitgezet worden

Het is belangrijk om te beseffen dat het rücksichtslos opschonen van audit informatie misschien niet de beste reactie is.  Auditing is meer en meer een essentieel deel van de database configuratie. Hierbij komen vragen aan de orde zoals:

  • Wat wil of moet ik auditen?
  • Hoe lang wil/moet ik de audit informatie bewaren.
  • Moet de audit informatie in de database blijven of is er een voorkeur deze ergens anders op te slaan.

Al met al blijkt dat auditing niet meer het obscure onderdeel is van de database dat het jaren geweest is. Auditing verdient serieuze aandacht.

We hopen dat we je met dit artikel ‘Database auditing:  wat doe je met je auditing data? ‘ op weg hebben geholpen. Mocht je hulp nodig hebben of je hebt vragen n.a.v. dit artikel, laat het ons dan weten.

Oracle Security en patching

Scroll to Top