Requires Free Membership to View
Unfortunately, I have to conditionally agree with your DBAs, if they want to define and create accounts and permissions. Account management is a function, not a role. The role of a DBA is administration of services, and indeed many organization's user account administration is going to be part of a DBA's role.
With that said, DBAs should manage accounts and define and set permissions based on security policies and standards. While DBAs can -- and usually do -- do the work, the security group should be telling them how to do it. Security should also have the right to audit and monitor their activities.
Be aware that there is one instance in which, within this scenario, the security group should manage user accounts and set permissions. This is when a DBA needs an account. For separation of duties (SoD) best practices, DBAs should not be able to set up accounts or privileges for themselves; this is the most common method for "backdoor" unauthorized access to come about, which can lead to information exposure or malicious activity. If you're willing to give them the administrative function for account management, they should be willing to allow you to manage their access.
As a final note, on many new applications and operating systems, you can have account management privileges without full administrative rights. In this case, where possible, the DBAs should only be granted this limited access to do account management unless their role requires them to do other administrative tasks on the application or server.
For more information:
- Read more about conducting a user access review with a small information security staff.
- Get more advice on choosing management for Active Directory provisioning.
This was first published in March 2010
Security Management Strategies for the CIO
Join the conversationComment
Share
Comments
Results
Contribute to the conversation