Chat now with support
Chat mit Support

On Demand Global Settings Current - Security Guide

User Authentication

All users must sign up and be approved by their internal On Demand administrator user before they can use On Demand. Sign in is via the Quest Identity Broker (QIB) which provides a tamper proof token for all user operations in the user interface. This token has a limited lifetime (5 minutes), after which it must be refreshed with the QIB. Failure to refresh causes all interactions with On Demand to fail. If a user’s access is revoked by the QIB, they continue to have access until their valid token expires, which is a maximum of 5 minutes. If a user’s access is revoked within On Demand by an On Demand administrator, their access and actions fail once the token expires.

The QIB provides authentication services linking identities and applications. Identities are sourced from several services:

•
Quest accounts (username and hashed passwords stored in a Quest database)
•
Azure Active Directory (business)
•
Microsoft Live (personal) account credentials

On Demand is among many Quest applications that rely on the QIB for authentication services. The QIB uses industry-standard Open ID Connect and SAML protocols, as well as secure direct connections to the Quest account database. All traffic in transit is encrypted using HTTPS and all data stored in the QIB database is encrypted at rest. No credentials are stored in the QIB database.

The QIB does not provide Multi-Factor Authentication (MFA) at this time. End users wishing to use Azure Active Directory for authentication can take advantage of MFA as provided by AAD, which is honored by the QIB.

The QIB is based on the open source Keycloak project sponsored by Red Hat. Quest regularly updates our customizations to match the most recent released version of Keycloak.

Figure 4. User authentication with QIB (Quest Identity Broker).
 

A valid Azure Active Directory JWT token is required to make notification requests and a valid On Demand JWT token is required to make additions or modifications to the Notification Service settings.

FIPS 140-2 compliance

On Demand Core cryptographic usage is based on Azure and AWS FIPS 140-2 compliant cryptographic functions.

•
On Demand Core leverages the Azure Key Vault and AWS KMS data-in-transit and data-at-rest built-in mechanisms.
•
Quest Identity Broker uses AWS KMS to encrypt data-at-rest stored in RDS.
•
More information on Azure Key Vault is available at https://azure.microsoft.com/en-us/services/key-vault/
•
More information on AWS KMS is available at https://aws.amazon.com/kms/
•
More information on approved crypto functions is available at NIST FIPS 140-2 https://csrc.nist.gov/publications/detail/fips/140/2/final
•
The Notification Service uses AES-256 server-side encryption with Amazon S3 managed keys.

Auditing

On Demand Core provides an activity trail log for the following actions:

•
Adding an Office 365 tenant
•
Removing an Office 365 tenant
•
Granting of Admin Consent for the tenant
•
On Demand administrator authorizing a user to be an On Demand administrator
•
On Demand administrator de-authorizing a user, so they are no longer an On Demand administrator
•
Notification settings modification
•
Privileged actions on system objects for On Demand modules

Audit data is stored in Azure SQL database and is available via JWT authenticated access to On Demand administrators only.

The Quest Identity Broker provides an audit trail log for all interactions, including login, logout, and account creation. Access is limited to the QIB administrators only.

SDLC and SDL

The On Demand team follows a strict Quality Assurance cycle.

•
Access to source control and build systems is protected by domain security, meaning that only employees on the Quest corporate network have access to these systems. Therefore, should an On Demand developer leave the company, this individual can no longer access On Demand systems.
•
All code is versioned in source control.
•
All product code is reviewed by another developer before check in.

In addition, the On Demand Development team follows a managed Security Development Lifecycle (SDL) which includes:

•
MS-SDL best practices
•
Threat modeling.
•
OWASP guidelines.
•
Regularly scheduled static code analysis is performed on regular basis.
•
Regularly scheduled vulnerability scanning is performed on regular basis.
•
Segregated Development, Pre-Production, and Production environments. Customer data is not used in Development and Pre-Production environments.

On Demand developers go through the same set of hiring processes and background checks as other Quest employees.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen