Raise your hand if your company continues to distribute shared privileged account passwords to a “trusted” group of admins. Keep it up if you get the night sweats fretting over whether those root and administrator passwords fall into the wrong hands. There has to be a better way, right?
This is the first blog in a three-part series that explores key use-cases of the Centrify Privileged Service (CPS).
Centrify Server Suite (CSS) is the market’s leading privileged identity management solution. It should be your first port of call as a “least privilege” approach to securing your business by strictly controlling privileges and elevating them only when necessary.
This means logging in as yourself and then explicitly requesting elevated privileges for the tasks that really need them. This significantly reduces both the “threat surface” and the “mistake surface” – something I covered in compliance-focused SC Magazine webinar recently.
There are some situations, however, where logging in directly with a shared privileged account (such as “root”) is simply necessary and unavoidable. You may have emergency situations, legacy apps or network devices that don’t accommodate user accounts with adjustable roles for different functions/privileges. For these situations, Centrify has a new offering complimentary to CSS called the Centrify Privilege Service (CPS).
One key underlying premise of CPS is that if we have no choice but to keep all-powerful accounts such as “root” and “administrator” around and their passwords available, let’s not put control of such passwords in the hands of fallible custodians, i.e., carbon-based life forms…human administrators. Humans are prone to mistakes. They share passwords with colleagues. Social engineers and other nefarious attackers exploit them. They’re not good at routinely cycling passwords and maintaining strong password quality.
Turns out, CPS is a fantastic custodian (by design)! It keeps them in a bulletproof secure password store and manages them based strictly on a role-based access model tied to appropriate access policies. Now, while CPS can satisfy the vast majority of remote server access situations by simply logging the user in directly without revealing the password (see Part 2), one scenario requires handing that password over to the admin. This is known as an emergency “break glass” scenario.
It is where, for example, a Linux server is unavailable, off the network, and only accessible for troubleshooting via “init 1” (single user mode). Single user mode only allows “root” to login directly through the system console. Under these circumstances, an administrator with sufficient privileges can checkout the root password from CPS and use it to physically log into the server and attempt remediation.
Once the server is back on its feet and back on the network, CPS can regain full control once again by automatically changing the password so the administrator no longer knows it (nor anyone else).
In the video below, we demonstrate a break glass scenario. We then show how CPS is configured to achieve this, setting up joeadminguy – the demo CPS admin account – with a role and policy to grant him the ability to do this, along with permissions on the shared privileged account itself.
Once you’re done, please check out related blogs and accompanying video demos, where I walk through other CPS use-cases such as remote server login without password reveal and session recording for compliance.
You can learn much more about the Centrify Privilege Service here. Take it for a test drive (it typically takes a matter of hours to set you up!) and see how easy it can be achieve that balance of strong security with ease of use – and get some well-deserved REM sleep.