January 31, 2012

The audit log with reversible operations

Though audit is eventually going to befall the enterprise, rarely do we see any of them take proactive action on the most precious of data: the identity store. It is a sad realization, if a matter-of-factly one, especially when you know there some neat features in the UnboundID product line squarely aimed at making auditing easier but a valuable risk hedging practice to deploy across the board. Here is the first step you can take to wrap your head around it:
  a) enable an audit log publisher, just so you can see what goes in the log
dsconfig create-log-publisher --publisher-name "File Based Audit Log" --type file-based-audit --set enabled:true --set suppress-internal-operations:true --set log-file:logs/audit --set "rotation-policy:24 Hours Time Limit Rotation Policy" --set "retention-policy:File Count Retention Policy" --set include-requester-ip-address:true --set use-reversible-form:true
  You can obviously also go do this on the web console or the dsconfig interactive cli. This just makes it an easy copy/paste.


   b) fire some operations
  we'll simply create an object here and delete it immediately afterwards, just so we get something in the new log...

# bin/ldapmodify -a -c


Arguments from tool properties file:  --hostname localhost --port 9389
--bindDN o=i --bindPasswordFile config/i.pwd


dn: cn=test.0,o=demo
objectclass: person
cn: test.0
sn: demo


# Processing ADD request for cn=test.0,o=demo
# ADD operation successful for DN cn=test.0,o=demo


# bin/ldapdelete cn=test.0,o=demo




Arguments from tool properties file:  --hostname localhost --port 9389


--bindDN o=i --bindPasswordFile config/i.pwd

Processing DELETE request for cn=test.0,o=demo
DELETE operation successful for DN cn=test.0,o=demo

  c) check out the audit log
# 21/Jan/2012:15:46:15.617 -0600; conn=10; op=1; clientIP=127.0.0.1
dn: cn=test.0,o=demo
changetype: add
objectClass: person
objectClass: top
cn: test.0
sn: demo
ds-entry-unique-id:: IAa+rBsFTZi3P6lpUaFG3Q==
ds-update-time:: AAABNQI76kc=
ds-create-time:: AAABNQI76kc=
creatorsName: cn=Directory Manager,cn=Root DNs,cn=config
modifiersName: cn=Directory Manager,cn=Root DNs,cn=config


# 21/Jan/2012:15:48:03.092 -0600; conn=13; op=1; clientIP=127.0.0.1
# Deleted entry attributes
# dn: cn=test.0,o=demo
# objectClass: top
# objectClass: person
# cn: test.0
# sn: demo
# ds-entry-unique-id:: IAa+rBsFTZi3P6lpUaFG3Q==
# ds-update-time:: AAABNQI76kc=
# ds-create-time:: AAABNQI76kc=
# creatorsName: cn=Directory Manager,cn=Root DNs,cn=config
# modifiersName: cn=Directory Manager,cn=Root DNs,cn=config
# subschemaSubentry: cn=schema
# entryUUID: 2006beac-1b05-4d98-b73f-a96951a146dd
# createTimestamp: 20120121214615.495Z
# modifyTimestamp: 20120121214615.495Z
# ds-entry-checksum: 3969919676
dn: cn=test.0,o=demo
changetype: delete

OK so what do we have here? Both operations are reported with enough information to review at a later time. Note too that the delete operation doesn't merely contain the delete instruction but also the contents of the object being deleted, in the event that this was an operator or application error, you would have a simple way to revert the change and restore the original entry without fear of losing precious information.


I invite you to get more familiar with this type of logger, as it can be tweaked to do a lot more. For example you may restrict the logger to only log traffic satisfying certain criteria on the connection (IP, security and such), the type of request and/or the results being fetched(a certain type of sensitive data, entry, ...).
It's a very powerful framework, give it a whirl some time.

No comments:

Post a Comment