Separation of Customer Data
Separation of Customer Data
A common concern related to cloud-based services is the prevention of commingling of data that belongs to different customers. On Demand Audit has architected its solution to specifically prevent such data commingling by logically separating customer data stores.
Customer data are differentiated using a Customer Organization Identifier. The Customer Organization Identifier is a unique identifier obtained from Quest On Demand Core that is created when the customer signs up with the application.
This identifier is used throughout the solution to ensure strict data separation of customers' data. The technique used to separate custom data varies depending on the type service and storage.
- 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 Power BI, each organization is contained within a separate workspace.
- For Azure Cosmos DB, the architecture will employ careful use of the organization identifier to ensure data is kept separate.
Network Communications
All external communication is secured with HTTPS to the On Demand Core User Interface.
The external HTTPS certificate used on AWS S3 Content Delivery Network is a Level 2 domain certificate created and managed by Quest DevOps.
There are no unsecured external HTTP calls within On Demand Audit.
All internal network communication within Azure among On Demand services and components is secured with HTTPS and is not visible to the external public internet.
Integration with On Premises Change Auditor Installations:
All communication with on premises Change Auditor uses secure TLS 1.2 connections over Web Sockets.
Authentication of Users
The customer logs in to the application by providing On Demand user account credentials.
The process of registering an Azure AD tenant into On Demand Audit is handled through the well-established Azure Admin Consent workflow. For more information about the Azure Active Directory Admin Consent workflow, please refer the Quest On Demand Core technical documents.
The initial configuration of the connection of Change Auditor to On Demand is done by the Change Auditor administrator using On Demand login credentials previously established in the On Demand web portal. For further details, see the On Demand Core security guide.
Role Based Access Control
Role Based Access Control
Quest On Demand provides permission-based roles to determine what permission level a user has and what tasks the user can perform.
For more details, see Adding users to an organization in the On Demand Global Settings User Guide.
List of permissions that can be assigned to On Demand Audit users:
- Can Configure Audit and Manage Searches
- Can View Dashboard
- Can Manage Azure AD Tenant Configurations for Audit
- Can Manage Change Auditor Installation Configuration
- Can View Event Retention Settings
- Can View Shared Searches
- Can Run Shared Searches
- Can Run Search Visualization
- Can Run Private Searches
- Can Manage Private Searches
- Can Manage Shared Searches
- View Event Details
- Can Run Quick Search Searches
- Can Export Search Results
- Can Manage Shared Alerts and Shared Alert Plans
- Can Manage Private Alerts and Private Alert Plans
- Can Export Data
On Demand Audit also makes use of one special role called Manage Audit Organization Private Alerts and Private Alert Plans. This built-in role is the only way that users can be delegated the rights to manage organization private alerts and private alert plans regardless of the user in the organization that owns the alert or alert plan. Users must be assigned to this role to receive the assigned rights because they cannot be granted this capability via a permission in the standard way. This role is not assigned by default to any user, nor is the right implicitly held by members of On Demand Administrator or Audit Administrator roles the way that other permissions are held.
