Chat now with support
Chat with Support

Security Management Platform Global Settings Current - Security Guide

Privacy and Protection of Customer Data

Customer data is differentiated using a unique organization identifier. This organization identifier is generated securely during customer sign-up. This organization identifier is passed to the user interface via a tamper proof (signed) token (JSON Web Token). This is passed with all requests made and is used to provide the organization context for all back-end services. The signed token (JSON Web Token) has a ‘Time to Live’ of 10 minutes and must be refreshed and re-authorized at this time. Failure to do so results in access being lost to Security Management Platform Core.

Security Management Platform Core relies on MSAL (Microsoft Authentication Library) cache to silently refresh access tokens. This cache is encrypted at rest and accessible only by service account.

Quest Software employees and Microsoft employees do not have access to and cannot see the keys used for encryption and decryption. The process of encryption and decryption is transparent to Security Management Platform and takes place between the Azure Key Vault Service and Azure Storage Tables. The keys are stored in a Hardware Service Module within the Azure Key Vault which is FIPS-2 level validated by Microsoft Azure. These keys are rotated hourly. For more information, see: https://azure.microsoft.com/en-us/services/key-vault/.

Customer data passed within a notification to the Notification Service is stored but cannot be retrieved.

Separation of Customer Data

For Azure Data Explorer, each organization is contained within a separate database ensuring no mixture of data.

For Azure Storage, a combination of techniques is employed. In Azure Blob Storage the primary technique employed is to keep each organization in a separate container. For other Azure Storage services and when Azure Blob Storage data cannot be separated using containers, the architecture will employ careful use of the organization identifier to ensure data is kept separate.

For Azure Cosmos DB, the architecture will employ careful use of the organization identifier to ensure data is kept separate.

Network Communications

FIPS 140-2 Compliance

Security Management Platform Core cryptographic usage is based on Azure and AWS FIPS 140-2 compliant cryptographic functions.

More information on approved crypto functions is available at NIST FIPS 140-2 https://csrc.nist.gov/publications/detail/fips/140/2/final

 

 

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating