Microsoft Azure

Set up Microsoft Azure for automated tests with TrustCloud!

TrustCloud’s API-based integrations map seamlessly to your frameworks and controls to power automated evidence collection, continuous monitoring, and predictive risk analysis. Let’s explore how you can set up Microsoft Azure for automated tests.

By granting TrustCloud limited access to metadata through a service principal account, you can ensure that your systems remain compliant with your adopted controls. TrustCloud’s focus on trust, security, and simplifying compliance makes it a valuable asset in the GRC landscape.

Explore 100+ evidence collection integrations to power evidence collection and real-time risk analysis.

Purpose

Once you set up your compliance program, TrustOps works to ensure that your systems remain compliant with your adopted controls. To do so, TrustCloud runs automated tests against systems in your product and business stack and verifies that they are properly configured.

This document outlines the steps you can take to grant TrustCloud access to only read metadata about the configuration settings for your Microsoft Azure resources so that TrustOps can validate and generate evidence for your compliance program.

Explore our GRC launchpad to gain expertise on numerous compliance standards and topics.

Instructions to grant TrustCloud limited access to Azure metadata

By granting TrustCloud limited access to metadata through a service principal account, you can ensure that your systems remain compliant with your adopted controls. TrustCloud’s focus on trust, security, and simplifying compliance makes it a valuable asset in the GRC landscape.

Follow the steps below to create a new service principal account and grant that account read-only access to your Azure subscription. A service principal account is an account strictly created for applications and/or services. From Microsoft’s Documentation.

*Automated tools that use Azure services should always have restricted permissions. Instead of having applications sign in as a fully privileged user, it offers service principals.

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access it’s resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at what level. For security reasons, it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.*

If Azure Active Directory is used, you also need to grant the new service account several read-only scopes within Azure AD to allow the inspection of user and role settings.

Creating a service principal with certificate authentication

1. For certificate authentication, you will need to create the account using the Azure CLI. Execute the following command to create a “TrustCloudAzureService” account with a Reader role, replacing {subscriptionId} with your subscription ID. You can additionally change the validity of the certificate by updating the –years parameter<

   az ad sp create-for-rbac -n "TrustCloudAzureService" --role Reader --create-cert --scopes /subscriptions/{subscriptionId} --years 2
   

   Note: This step is to be followed if you’re only going to “connect one subscription with TrustCloud”. If you want to connect multiple subscriptions, please follow Step 2.

2. For certificate authentication, you need to create a service principal via the Azure CLI.
   Execute the following command by replacing the {subscriptionId} with your applicable subscription IDs. You can additionally change the validity of the certificate by updating the –years parameter & adding more subscriptions to the –scopes parameter, separated by a space. Refer the code beneath for more details:

   az ad sp create-for-rbac -n "TrustCloudAzureService" --role Reader --create-cert --scopes /subscriptions/{subscriptionId_1} /subscriptions/{subscriptionId_2} --years 2

   Note:

   1. If you have already used the TrustCloudAzureService service principal for an existing connection, you can re-create it with the above command. Once created, you will need to update the newly created Private key content for the existing connections.
   2. If you are creating a connection for the first time, you can create create a single service principal for multiple subscriptions with the command above & then create multiple connections in TrustCloud with the same private Key for each subscription.
3. Save the output to a file.
4. The output also contains a path to the certificate .pem file. Note this file’s location.
5. To set up the connection in TrustOps, you will need the output from the Azure CLI, the contents of the PEM file, and your Azure Subscription ID.

Granting necessary scopes for Azure Active Directory automated tests

To support running TrustOps’s automated tests against Azure Active Directory, the created service principal must be granted several scopes:

1. AuditLog: AuditLog.Read.All
2. DeviceManagementConfiguration: DeviceManagementConfiguration.Read.All
3. DeviceManagementManagedDevices: DeviceManagementManagedDevices.Read.All
4. DeviceManagementServiceConfig: DeviceManagementServiceConfig.Read.All
5. Group: Group.Read.All
6. Organization: Organization.Read.All
7. Reports: Reports.Read.All
8. Policy: Policy.Read.All
9. RoleManagement: Role.Read.All
10. User: User.Read.All
11. Application: Application.Read.All

To grant the required scopes:

1. Navigate to the Azure Active Directory administration console.
   
2. Click on the ‘App Registrations menu from the left navigation bar.
3. Click on the ‘All Applications’ tab.
4. Find the name of the service principal you created previously (e.g., “TrustCloudAzureService”), and click on it.
5. Go to the ‘API Permissions’ menu in the left navigation panel.
6. Click on the “Add a Permission” button.
   
7. Click on “Microsoft Graph” from the ‘Request API Permission’ section.
   
8. Click on the ‘Application Permissions tab.
9. Expand and select the following scopes:
   1. AuditLog: AuditLog.Read.All
   2. Group: Group.Read.All
   3. Organization: Organization.Read.All
   4. Policy: Policy.Read.All
   5. RoleManagement: Role.Read.All
   6. User: User.Read.All
   7. DeviceManagementConfiguration: DeviceManagementConfiguration.Read.All
   8. DeviceManagementManagedDevices: DeviceManagementManagedDevices.Read.All
   9. DeviceManagementServiceConfig: DeviceManagementServiceConfig.Read.All
   10. Application: Application.Read.All
10. Click on “Grant admin consent for [your organization name]” and click on “Yes”.