Please find the answers below:
What key is used to encrypt the secret? Algorithm AES 256 ? - Yes
Is it a “global” key or unique key per secret? - Customer data is encrypted using unique encryption keys.
Where is this key stored and managed? TBD Who can access it? - When hosted in the Saviynt Cloud, Saviynt provides encryption key management through the cloud provider's native tools. On AWS the Amazon Key Management Service (KMS) is used, and on Azure Saviynt utilizes the Azure Key Vault.
Both the customer and Saviynt will have designated staff who can view the key logs, but no one can see the keys.
How is key rotation managed? At what frequency? - The customer is provided with the ability to rotate their encryption key on a scheduled basis of their choice.
How can it be replaced if compromised? The key can be replaced manually if required? - The customer is provided with the ability to rotate their encryption key.
What controls can be put in place to ensure that this encryption key is not used out of context (e.g. key extraction for manual secret decryption...)? Perhaps need more context to answer properly - No one has access to the encryption keys, which are managed by AWS Key Management Service (KMS) or Azure Vault. Both STMicro and Saviynt will have designated staff who can view the key logs, but no one can see the keys.in a typical deployment, Saviynt uses AWS Managed Customer Master Keys. AWS KMS includes a web interface through the AWS Management Console, command-line interface, and RESTful API operations to request cryptographic operations of a distributed fleet of FIPS 140-2 validated hardware security modules (HSMs). The AWS KMS HSM is a multichip standalone hardware cryptographic appliance designed to provide dedicated cryptographic functions to meet the security and scalability requirements of AWS KMS. Saviynt can establish your own HSM-based cryptographic hierarchy under keys that we manage as AWS KMS keys. These keys are made available only on the HSMs and only in memory for the necessary time needed to process a cryptographic request. We can create multiple KMS keys, each represented by its key ID. Only under AWS IAM roles and accounts administered by Saviynt can customer KMS keys be created, deleted, or used to encrypt, decrypt, sign, or verify data. We can define access controls on who can manage and/or use KMS keys by creating a policy that is attached to the key. Such policies allow us to define application-specific uses for the keys for each operation.
Who can access the sensitive data contained in the DB? Perhaps need more context to answer properly - No Saviynt employee has access to the customer environment or data except for Technical Support issue resolution, and then only with the customer's explicit approval, through the customer's approval processes.
How can we ensure (control) that there is no unauthorized extraction of AzureAD connector credentials from this DB? - Saviynt, by default, stores IDs and passwords in the database config file. These credentials are hashed utilizing salted bCrypt.
Connector credentials, alternatively, can be vaulted in the native Hashicorp Vault or in any PAM vault you already use (Fortinex, CyberArk, etc.) through our Bring Your Own Vault (BYOV) tool. When the EIC application connector is invoked, EIC can check out the credentials from the vault and establish a connection with the target application—eliminating the need to store the service account credentials in EIC. Whether you use our native Hashicorp Vault or another already in use, Saviynt's BYOV feature secures target systems by periodically rotating the vaulted privileged account credentials and enables periodic password rotation based on the defined password policy.
How are AzureAD connector credentials rotated in this DB? At what frequency? Depending on the client Secret duration - Connector credentials can be vaulted in the native Hashicorp Vault or in any PAM vault you already use (Fortinex, CyberArk, etc.) through our Bring Your Own Vault (BYOV) tool. When the EIC application connector is invoked, EIC can check out the credentials from the vault and establish a connection with the target application—eliminating the need to store the service account credentials in EIC. Whether you use our native Hashicorp Vault or another already in use, Saviynt's BYOV feature secures target systems by periodically rotating the vaulted privileged account credentials and enables periodic password rotation based on the defined password policy.
What controls can be put in place to ensure that AzureAD Connector credentials are not used out of context (manual use, use from another source, etc.)? - This is an implementation question. There are several ways to protect connector credentials. The two most common are to use EIC's BYOV or CPAM capabilities. CPAM is the privileged access management suite that includes a PAM Vault in which connector credentials can be vaulted so that EIC checks them out for each use and the vault rotates the credentials after use. BYOV (Bring Your Own Vault) extends this capability to any PAM vault (Hashicorp, Fortinex, CyberArk, etc.) that a customer already has. When the EIC application connector is invoked, EIC can check out the credentials from the vault and establish a connection with the target application—eliminating the need to store the service account credentials in EIC. Whether you use our native CPAM Vault or another already in use, Saviynt's BYOV feature secures target systems by periodically rotating the vaulted privileged account credentials and enables periodic password rotation based on the defined password policy.
