This blog is a continuation of my earlier blog “Plug and Play or Plug and Pain” on Privileged Access Management (PAM), posted on December 16, 2015. I will dive a bit deeper now into the problem of shared account password and key management and give pointers how SSH’s CryptoAuditor and Universal SSH Key Manager solutions address it.
Shared Account Password Management (SAPM) is a product category of Privileged Access Management (PAM) recognized by many analysts, vendors, and customers.
In simple terms, it means managing access to accounts that are in shared use by several persons. There are several types of shared accounts, starting from inbuilt operating system root or administrator accounts to shared accounts of particular applications, such as databases, or firecall accounts used in emergencies.
As the name implies, shared account password management is traditionally thought to mean managing passwords, and eliminating the manual process of sharing password lists in, for example Excel files. However, this implication has not been true for years. Especially with the SSH protocol, the use of cryptographic keys has been widespread since the beginning of the millennium. Managing the keys has also somewhat different needs and problems from managing passwords,
There are certain base requirements a SAPM solution is expected to meet:
- Encrypted password/key vault: The solution should store the passwords or keys of the shared accounts in a hardened location that is not accessible by the users.
- User mapping: The solution should be able to map the individual user accounts to shared accounts according to pre-configured rules. For example, “User X should be able to access only account Y on host Z.”
- Hiding target server credentials from the end users: The solution should insert the target server credential to the connection in a way that the user can never access it. Or at least, if the credential is “checked out” and disclosed to the user, it needs to be changed immediately on the target system so that the user cannot use the same credential to access the target system again.
- Integration with identity management (IdM) systems: The solution should be able to leverage an IdM system, for example Microsoft AD for authenticating the actual users and retrieving group information for them. The user’s groups can be used to define which accounts on which hosts the user is allowed to access.
- Workflow for requesting/granting access: The solution should provide a workflow for granting access to password or keys and set a timeframe when the access is allowed. For some use cases, this can be regular access, for example “from 9 to 5 on weekdays”. For other use cases, this can be temporary one-time access, for example “for two hours starting now”. This workflow can also be tied to an existing IT service management system.
Password or key rotation is also often mentioned as a requirement. However, let’s reconsider that briefly. If the password or key is “checked out” from the vault and disclosed to the user, rotation is clearly needed to prevent the same user from attempting (unauthorized?) access using the same password or key. Also, the theory goes that the longer the same password exists, the more time it gives to an attacker to attempt to break it, thus rotation is needed. This theory is valid if the network is not monitored and the potential brute-force attacks to break the password are not tracked.
On the other hand, if the password is truly random and long enough, it can be resistant even to brute force. Given both lower and uppercase alphabets, numbers and special characters, there are 95 printable characters in ASCII. The security equal to a 128-bit symmetric key, which is considered secure for the foreseeable future (according to [http://www.keylength.com/en/]), can be achieved by a random password of 20 characters (128*log2(2)/log2(95)= 19.48). If you want to learn more about this, check this page.
For SSH keys, the issue is slightly different. As pointed out by my colleague in his blog, controlling key-based access via SSH is really based on controlling the authorized keys, not the private keys. If the private key for accessing the target account is stored in the vault and is not available to the user and if the authorized keys are stored in a root-owned location on the target host, so that the users cannot add new authorizations, the need for key rotation is not really on the top of the list. If you have not taken the steps to control the authorized keys, rotating the keys may even lead you to a false sense of security.
Our CryptoAuditor solution has a network-based approach to SAPM. Unlike most other solutions, it does not require the users to change their tools or workflows, and it does not require any components to be installed on the target servers, reducing the setup time significantly. CryptoAuditor integrates with your Identity Management (IdM) systems, for example Microsoft Active Directory (AD), to authenticate the real person accessing the privileged account. It stores the target host Unix or Windows passwords and SSH keys in a secure vault, inaccessible to the privileged users. CryptoAuditor inserts the password or the key to the SSH or RDP connection transparently, so that the user never sees it. CryptoAuditor also offers a flexible set of user mapping rules, configurable either through API or GUI.
Combined with Universal SSH Key Manager, CryptoAuditor offers a full solution for SSH key management and monitoring. We will be adding more advanced functionalities in 2016, so stay tuned!
When looking for a solution for managing shared account credentials, be they passwords or keys, consider what kind of an impact is acceptable to your end users, then consider the effort needed in the implementation project. Also consider each of the base requirements and determine which are valid for your use case. Then pick the solution that suits you the best. You may not really need all the bells and whistles, if you can get a solution that is secure, easy, and works.