How many people in your IT organization have access to, say, the Administrator account’s password in Active Directory? How about to service account passwords? Unix servers? Other kinds of privileged accounts?
Now think about the individuals who have access to those various passwords. Even though they are trusted to do the right thing with those passwords, shouldn’t there be some level of governance over the use of them?
Take the example of Curt the contractor. He needs VPN access and is working on a database project that involves one of your SQL Servers. The normal path IT takes is to give him the access he needs to do his job. But, given the rise in insider threats over the past few years, your organization wants constraints put on Curt’s access. Now, you could just take away and re-grant access to the VPN, but then someone needs to be working whenever Curt is to facilitate that. And, speaking of when Curt’s working, when exactly is that? Is it ok for him to work on a Sunday night at 2am?
The challenge today with privileged passwords is there are so many accounts created for the purpose of logging, audit trails, segregation of duties, etc. that all have a lot of access to sensitive information, critical systems, and even security settings. And to make matters worse, there is no means by which to limit their use.
In essence, with most privileged accounts today, you can use them anywhere, anytime. Now, granted, not every account has full admin rights, but there are still few controls in place on the access to, and use of, these passwords, such as limiting:
- Day of the week
- Time of day
- System used to log in
- Access to a privileged session
- Use without manager approval
