none
Audit DATABASE_OBJECT_CHANGE_GROUP includes ACCESS to ASYMMETRIC KEYs RRS feed

  • Question

  • Hi,

    We are in the process of rolling out the audit feature of SQL 2008. While testing we found that if we include the DATABASE_OBJECT_CHANGE_GROUP in the (server) audit specification, we get an audit record created every time an asymmetric key is accessed. This is a bit confusing and I would have thought this action should be part of DATABASE_OBJECT_ACCESS_GROUP.

    Can anyone explain why the audit groups are set up in this way?

    Thanks,

    Ben

    Tuesday, March 15, 2011 10:57 AM

Answers

  • Yes its just annoying for me because we have a very high volume of calls to a column-encrypted value which are all getting recorded in our audit.

    I raised it on Connect, but i was told it was "by design" because access to the key requires CONTROL permissions, which comes under the category of DATABASE_OBJECT_CHANGE_GROUP.

    However I don't know how accessing a key can really be described as CONTROLling it.

    Probably its because they just didn't implement a more granular permission level for ACCESS on these types of object (analagous to SELECT on a schema object) so the next level up is CONTROL.

    Regards,

    Ben

    Wednesday, March 16, 2011 10:21 AM

All replies

  • Hi Ben,


    I have seen this before when I was implementing database_object_change_group audit specification for one of the server and the behaviour that you see is the same for symmetric key,cerfiticate, asymmetric key , full text catalog and master keys - access or open activity gets logged in this audit group and this can be verified from sys.dm_audit_actions. But I did't bother much about it as we din't have any such keys used apparently.


    Thanks, Leks
    Wednesday, March 16, 2011 12:13 AM
  • Yes its just annoying for me because we have a very high volume of calls to a column-encrypted value which are all getting recorded in our audit.

    I raised it on Connect, but i was told it was "by design" because access to the key requires CONTROL permissions, which comes under the category of DATABASE_OBJECT_CHANGE_GROUP.

    However I don't know how accessing a key can really be described as CONTROLling it.

    Probably its because they just didn't implement a more granular permission level for ACCESS on these types of object (analagous to SELECT on a schema object) so the next level up is CONTROL.

    Regards,

    Ben

    Wednesday, March 16, 2011 10:21 AM