As your software-defined data center (SDDC) grows, so does the quantity of privileged accounts. This was the discussion on the Virtualization Security Podcast of February 13, 2014, where we were joined by Thycotic Software. Privileged accounts are used by administrators and others to fix issues, set up new users, add new workloads, move workloads around your SDDC, harden those workloads, and perhaps even log in to just pull down logs for further use. The list of reasons to use privileged accounts is as endless as your system administrator’s stack of work. Yet today, almost always, access to these accounts is made by those who know the password.
Within the fully realized secure hybrid cloud and SDDC, one of the lowest hanging fruits of administrative security is to use a different password for each account, whether administrative, privileged, or other. However, being humans, we tend to use a set of passwords instead. This set is usually something we can remember or have written down somewhere. In some cases, we use personal password tools such as 1Password. But these tools do not meet the requirements of the SDDC. Mostly defined as a borderless data center with massive amounts of automation, the SDDC includes not only IaaS (infrastructure cloud service providers), but also the myriad of SaaS applications in use (Salesforce, Box, Twitter, Facebook, etc.). All these services use privileged accounts to control, maintain, troubleshoot, etc.
By placing a privileged account manager into the mix, we gain the ability to have good password hygiene (password resets, complexity, etc.), one distinct password and perhaps even account name per service, and other best practices, as well as the ability to use those complex and not-memorized passwords via scripts in a secure fashion. The key to using privileged account managers such as Xceedium and Thycotic Secret Server within the SDDC is that they must be accessible via an API, so that they can be used within the scripts that control, orchestrate, and otherwise maintain the SDDC.
The list of requirements for privileged account management for the SDDC includes the following. We are close for many of these, but some are missing still.
- Maintain good password hygiene and related password policies
- Work across the myriad of SaaS, IaaS, PaaS, and storage clouds
- Have an API, so that scripts and other automation tools can get access as needed to privileged accounts
- Be hosted anywhere, perhaps even within a cloud
- Have access to use a cloud or network HSMs
- Provide launchers to launch privileged access, so passwords are never shown
- Maintain an approval workflow for gaining access to extremely privileged accounts such as those used within hypervisors, social media, and other highly important accounts
- Log data to other tools for behavioral and traditional security analysis
- Use multiple factors of identification to even access the system
- Have a backup system or plan in case the primary account manager has issues or is not accessible (absolutely should be part of any DR plan).
Within our secure hybrid cloud or secure software-defined data center architecture (seen in figure 1), privileged account access sits firmly within the transition between traditional data centers and clouds as a a part of identity.
As we have discussed before, identity within the secure hybrid cloud (SDDC) requires many factors of authentication to prove who is the user. For privileged account management tools, this proof becomes paramount, as the tool is the holder of all privileged accounts. The security around this one part of your SDDC needs to be increased to not only include IP restrictions but also such things as the device in use, geo-location, accelerometer changes within devices, traditional two-factor authentication mechanisms, and perhaps ultimately a set of personalized questions used to prove the identity of the unknown at the other end of the device.
Have a listen: what tools do you use today to manage your privileged accounts? Hopefully, nothing is on a post-it note underneath the keyboard.
Share this Article: