The issue of privileged accounts is certainly not a new one. Operating Systems have always had the concept of a root or administrator account, for example. These super accounts are not the kind of accounts that people should be using on a business as usual basis (though I suspect this "rule" is a case of Do As I Say, Not As I Do). Sometimes, though, there is just no way of getting around the need to access a system or application with a privileged account.
Rogue insider employees are on the increase, if press reports are to be believed. Indeed, it is probably a fair comment given that staff turnover has increased dramatically in recent years! So it makes a lot of sense to ensure that employees don't have permanent access to credentials that can cause damage to your IT infrastructure. And so... Privileged Identity Management has finally come of age.
Or has it?
IBM, earlier this year, announced an initiative based on the integration of Tivoli Access Manager for Enterprise Single Sign On and Tivoli Identity Manager to address the needs of privileged access and details of their solution can be found in their Redguide publication: "Centrally Managing and Auditing Privileged User Identities by Using the IBM Integration Services for Privileged Identity Management".
It works on the basis of being able to elevate your privileges upon request and having TAM ESSO check-out the elevated privileges from an ITIM vault and inject the credentials into the target platform/application login sequence without the end user ever having to know the privileged account's password. Sounds like genius, right? Maybe. It certainly a neat way of taking the best bits of two fairly solid applications to cater for a gap in both products. And in the main it ought to work... at least for those applications that TAM ESSO can integrate with.
Most software applications that claim to provide a solution to the privileged access rights problem only seem to do so for either the Windows administrator accounts or the Unix administrator accounts and almost forget about those other special accounts that reside inside of applications. TAM ESSO can therefore help resolve that. However, this is only true for accessing a system with elevated privileges. What about changing passwords on a frequent basis and changing passwords after account use?
One of the reasons why privileged accounts have been causing so much pain is because organisations are scared to change the passwords for these accounts for fear that their systems will break! That's certainly a fair comment, in my opinion. We all know that applications shouldn't bind to a Directory Server with the cn=root account, but I bet they do. And when that account's password is changed, what will happen? Where within the application is the password for cn=root stored? In a properties file? In a database? How should the password be updated? Do we have to stop the application first? What if there are multiple applications using that account? Do we need a major outage of our systems? Maybe we should do it at a weekend, what do you think?
So the solution described in the Redguide publication goes a long way to plug a gap. The supposed industry leading solutions for Privileged Identity Management also go a long way to help alleviate the problem. But it seems to me that there are still issues needing addressing!
Ultimately, the right answer for delivering a solution will be dependent on:
- the customer's appetite for solving the problem completely
- the customer's appetite for risk
- the customer's financial muscle when it comes to licensing software solutions
No comments:
Post a Comment