Admin Consent and Service Principals
Security Guardian requires Admin Consent for Entra ID collections and access to the customer’s Microsoft Entra and Microsoft 365 tenants for auditing. The customer grants that access using the Microsoft Admin Consent process, which will create a Service Principal in the customer's Microsoft Entra ID with minimum consents required by On Demand (Groups, Users, Contacts).
The Service Principal is created using Microsoft's OAuth certificate-based client credentials grant flow https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow.
Customers can revoke Admin Consent at any time. For more information, see: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/delete-application-portal?pivots=portal and https://docs.microsoft.com/en-us/skype-sdk/trusted-application-api/docs/tenantadminconsent.
The following base consent is required by On Demand:
In addition to the base consents, the following consents are required for auditing:
Audit currently uses the Microsoft 365 Management Activity API, Microsoft Graph API, and Microsoft Entra Graph API for reading events from Microsoft 365 and Microsoft Entra ID using a “limited permissions model” which does not require global administrator permissions. After the consent has been granted using the global administrator account, thereafter all auditing operations will be driven by the token generated using the Application Service Principal.
The Admin Consent process will create a Service Principal in the customer's Microsoft Entra tenant with the following permissions.
- Permissions required to read audit log activities and activity data from Microsoft Entra ID and Microsoft 365.
- Permissions required to read the identity risk event information.
- Permissions required to read service health information.
- Permissions required to read user profile data and directory data such as users, groups, and applications.
Location of Customer Data
When a customer signs up for On Demand, they select the region in which to run their On Demand organization. All computation is performed, and all data is stored in the selected region. The currently supported regions can be found here https://regions.quest-on-demand.com
Azure Storage, including the Blobs, Tables, and Queues storage structures, are replicated three times in the same datacenter for resiliency against hardware failure. The data is replicated across different fault domains to increase availability. All replication datacenters reside within the geographic boundaries of the selected region. See this Microsoft reference for more details: https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy
Audit customer data is stored in the selected On Demand region, entirely within Azure Services provided by Microsoft. For more information, see Achieving Compliant Data Residency and Security with Azure.
For US Organizations:
- All Audit data is stored and processed within the United States, using a single Azure Datacenter. Azure “West US 2” is used for all processed data within Audit. For disaster recovery duplicate copies of all data are stored in Azure “East US 2” and Azure “Central US”.
For Europe Organizations:
- All Audit data is stored and processed within the European Union, using a single Azure Datacenter. Azure “Northern Europe” is used for all processed data within Audit. For disaster recovery duplicate copies of all data are stored in Azure “Western Europe”.
For UK Organizations:
- All Audit data is stored and processed within the UK, using a single Azure Datacenter. Azure “UK South” is used for all processed data within Audit. For disaster recovery duplicate copies of all data are stored in Azure “UK West”.
For Canada Organizations:
- All Audit data is stored and processed within Canada, using a single Azure Datacenter. Azure “Canada Central” is used for all processed data within Audit. For disaster recovery duplicate copies of all data are stored in Azure “Canada East”.
For Australia Organizations:
- All Audit data is stored and processed within Australia, using a single Azure Datacenter. Azure “Australia East” is used for all processed data within Audit. For disaster recovery duplicate copies of all data are stored in Azure “Australia Southeast”.
All on premises data from Change Auditor is transmitted to and retained in the selected On Demand organization and region.
Audit makes use of Amazon SES (Simple Email Service) to provide email alerting capabilities via the On Demand Notification Service. These services require Amazon data centers outside of Azure data centers. All data is stored and processed within the matching region selected in On Demand.
Privacy and Protection of Customer Data
A common concern related to cloud-based services is the prevention of commingling of data that belongs to different customers. Security Guardian has designed its solution to specifically prevent such data commingling by logically separating customer data stores. Information such as Active Directory and Entra ID objects are all stored in Azure Data Explorer with each customer having their own database. However, items such as Assessments and Assessment results are stored within the same Azure Storage Account and partitioned by the Customer Organization ID and the Azure Tenant ID.
Customer data is differentiated using a Customer Organization Identifier. The Customer Organization Identifier is a unique identifier obtained from the Quest On Demand Platform 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 in the Azure Data Explorer database and during processing.
The most sensitive customer data collected and stored by Audit is the event data from activity occurring in the Microsoft Entra ID and Microsoft 365 environment and event data from all connected Change Auditor installations. All data is segregated based on the organizational identifier. Whenever event data is stored or retrieved within the system the organizational identifier ensures data remains separate.
All event data is protected by service-level encryption present in Microsoft Azure Services.
For information on privacy and protection of customer data within On Demand and email alerting provided by Amazon SES, please refer to the Quest On Demand Global Settings Security Guide.
Network Communications
Internal network communication within Azure includes inter-service communication between Security Guardian components and the On Demand Platform.
Inter-service communication uses OAuth authentication using a Quest Entra ID service account with the rights to access the services. No backend services of Security Guardian can be used by end users.
On Demand Services accepts access to Security Guardian from the On Demand web user interface.
All external communication is secured with HTTPS TLS 1.2 and with HTTPS to the On Demand Core User Interface.
The Security Guardian user interface uses OAuth authentication with a JWT token, issued to a logged in user.
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 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.
