Password vaults implementation
Import
·
Dec 22, 2022
·
article
This article present multiple alternatives to implement password vaults with ServiceNow. The main Use Case is for Discovery, but it can be also used for integrations.
Warning : This article is not an official documentation, and it might be non exhaustive.
ServiceNow instance can store credentials used by Discovery and Service Mapping in an external credential repository rather than directly in a ServiceNow credentials record.
Note : It requires the activation of the "External Credential Storage" plugin.
| Keep passwords inside the customer Network | Passwords are not stored in the ServiceNow platform, they don’t have to transit on Internet |
|---|---|
| Password Rotation | Allow password to rotate with having to manage it manually |
| Managed by Security teams | It is possible to keep the password management by security teams, and not ServiceNow Adinistrators teams |
| Log | It is possible to Trace, Log and have a better security parameters |
| Independent security zones | It is possible to connect different vault instances and configure different security zones |
Vault typical architectures (outside of ServiceNow)
- Vaults can be used in 2 different "modes". It is important to discuss this aspect to avoid misunderstandings
- Bastion/Proxy Mode
- The user connects to the bastion and select a server. The Bastion will act as a proxy to share the screen/console to the server
- The user/password is not communicated
- The user connects to the bastion and select a server. The Bastion will act as a proxy to share the screen/console to the server
- Vault Mode
- The vault gives the username and password of the serve to connect
- Bastion/Proxy Mode
- Important : It is possible to discover only using Vault mode
Use of multiple and local accounts
- It is necessary to configure ServiceNow to find the right credential account to use
- Simple mapping depends on credential ID
- As for credentials stored in the platform, every credential will be tested until connection success
- If a credential is successful, the credential ID is recorded for later
- Simple mapping depends on credential ID
- The vault can be requested with the target IP to discover (if the connector is compatible)
- Allow management of local accounts
- More secured, but it will be necessary to maintain the IPs in the vault
- It is challenging, except if it is possible to automate the process
- Allow management of local accounts
Example with HashiCorp :
- In this example, we used a combination of simple Active Directory account, and local unique accounts, based on an IP. Please note this implementation used a custom connector.
Discovery Process (example using CyberArk)
- The instance maintains a unique identifier for each credential, the credential type (such as SSH, SNMP, or Windows), and any credential affinities. The MID Server obtains the credential identifier from the instance, and then uses a customer-provided JAR file to resolve the identifier from the repository into a usable credential.
| Phase | Description |
|---|---|
| 1 | ServiceNow asks for a server discovery (managed in a queue) |
| 2 | MID Server detects the OS if it is the first discovery. |
| 3 | The MID Server will check if a credential identifier is already associated to the server, or if there are possible credentials to test, depending of protocol type and IP range. |
| 4 | MID Server request to a specific API the credentials depending of the Credential identifier. The API will use CyberArk AIM Agent to request CyberArk infrastructure and get the password. |
| 5 | MID Server will use the password to connect to the target OS |
List of common vault and implementation
How to deploy, test, or develop custom connectors?
I separated the content in dedicated articles :
Possible challenges during deployment
- Some tools can have licensing impacts
- Architecture principles to check
- Some customers refuses to allow connection from the MID servers to the vault directly, depending on network and security zones
- How to management the accounts in the vault
- Bastion mode vs vault mode : Security teams won’t allow to use their existing accounts, so it could be necessary to create ServiceNow specific accounts
- Who will manage/deploy/maintain ServiceNow accounts inside the vault?
- Bastion mode vs vault mode : Security teams won’t allow to use their existing accounts, so it could be necessary to create ServiceNow specific accounts
- Management of multiple accounts
- How to manage if multiple accounts are necessary? How to map with each perimeter?
- Volume of requests to the vault
- ServiceNow doesn’t store any credential, and will request it multiple times for every server
- Usage of cache is recommended
- Performance impact on the vault to check
- ServiceNow doesn’t store any credential, and will request it multiple times for every server
- Availability of SMEs
Other ressources :
Labels:
View original source
https://www.servicenow.com/community/itom-articles/password-vaults-implementation/ta-p/2424263
