Separation of duties, ensuring your adminstrators administrate
By Simon Thorpe on Nov 25, 2008
A recent debate internally was discussing how to find a solution to prevent administrators accessing sensitive documents stored in a system, yet at the same time retain their ability to perform administration. This requirement is often referred to as the need for the separation of duties.
The discussion was about Universal Content Management (UCM) using the database to store content and that database and UCM administrators could use their administrative access to get copies of sensitive documents in the system. The problem also extended beyond the database to backups and other locations the sensitive content may reside. For instance, with the browser being the main delivery mechanism for applications, it means any sensitive content is passed through a web server, possibly a web cache/proxy and finally onto the browser where it resides in the local cache. If this content is not sent via a secure channel (HTTPS) then there is the potential for a network/systems administrator to intercept this content. You could solve this problem using a multitude of technologies and techniques.
- Ensure all communication from application/content repository is via a secure network
- Configure the ECM environment in a way that limits the ECM administrator from getting access to the content
- Use database features like Database Vault to ensure DBA's cannot query certain database data. (Blogged by Oracle's Roxana Bradescu)
- Secure the backups
- Secure/encrypt the hard disks of the client users
All the above methods are perfectly valid for protecting data whilst it resides within the confines of the system but it poses some challenges.
- How do you ensure all these systems reflect a single policy? You have to manage each system separately and this exposes risk.
- Some systems just do not provide straight forward methods for separation of duties.
- Deploying enterprise management and IdM to centralize the control over these environments can be expensive, complex and lengthy.
Oracle IRM is an excellent technology to help deliver a strong level of separation of duties in a simple and quick fashion. All the best security professionals i've spoke with iterate good security should be simple. At its most simplistic, deploying IRM with very few classifications between the IT group and the business gives one set of simple, very visible policies that ensures a business segment, such as HR, legal or finance, can be assured only authorized users have access to their sensitive content.
Administrators can then happily administrate. DBA's can maintain and ensure database performance, UCM admins can setup new metadata, add new roles to the system, database backups can be handled as usual. IRM will ensure that sensitive content, no matter where it ends up, can only be accessed by those with rights on the IRM server.
Even the IRM server itself has powerful separation of duty in it's administrative model. Here in Oracle our global IT group has the rights to create new classifications for the business upon request. Yet when these classifications are handed over to the business, GIT do not remain administrators and therefore have no ability to get access to the content secured against those classifications, unless of course they are given rights by that business owner.
IRM doesn't replace those technologies mentioned above, it simply provides a complimentary solution which can be rapidly deployed and easily audited.