It’s a problem that I see organizations struggling with every day. An audit finding has come down requiring the monitoring of privileged users in databases containing sensitive or regulated data.
From the outside, this seems simple. Get a list of privileged users and log whatever they are doing. However, as folks dig into this, the first question they have to ask is who are the privileged users? And that’s where the trouble starts.
What exactly is a privileged database user? It’s probably not anyone and everyone with access to the system. Maybe it’s only the database administrators, but what exactly does that mean? Membership in a DBA or SysAdmin role?
That can be very misleading, since DBA level privileges can be granted directly to a user without any role membership, or new roles with names like Not-A-DBA can be created with DBA equivalent privileges.
Maybe a privileged user is anyone with write access to the database? But that tends to include everyone, since it’s been pointed out by database security researchers many times in the past that creating a read-only database user is essentially impossible, due to all the write privileges that are typically (and often irrevocably) granted to PUBLIC (that’s everyone in the database).
Even with a firm definition of what makes a user a privileged user, the problems don’t go away. Just because a user is not privileged today, does not mean they won’t be privileged tomorrow.
Actually creating and maintaining an accurate list of privileged users in an enterprise full of databases can be an impossible task.
There is another way forward though. One that is simple to define, implement, and maintain. One that meets the letter of regulations and audit findings, and one that ensures that no matter how or when a user obtained their privileges, that their activities in the database are tracked.
The answer is to pay attention to the activity first, and who did it second.
From the outside, this seems simple. Get a list of privileged users and log whatever they are doing. However, as folks dig into this, the first question they have to ask is who are the privileged users? And that’s where the trouble starts.
What exactly is a privileged database user? It’s probably not anyone and everyone with access to the system. Maybe it’s only the database administrators, but what exactly does that mean? Membership in a DBA or SysAdmin role?
That can be very misleading, since DBA level privileges can be granted directly to a user without any role membership, or new roles with names like Not-A-DBA can be created with DBA equivalent privileges.
Maybe a privileged user is anyone with write access to the database? But that tends to include everyone, since it’s been pointed out by database security researchers many times in the past that creating a read-only database user is essentially impossible, due to all the write privileges that are typically (and often irrevocably) granted to PUBLIC (that’s everyone in the database).
Actually creating and maintaining an accurate list of privileged users in an enterprise full of databases can be an impossible task.
There is another way forward though. One that is simple to define, implement, and maintain. One that meets the letter of regulations and audit findings, and one that ensures that no matter how or when a user obtained their privileges, that their activities in the database are tracked.
The answer is to pay attention to the activity first, and who did it second.
Have you read these related articles?
Newsletter:
