# Appendix 1 - Azure configuration notes ## Required Permissions During Deployment The permissions a user requires in Azure to enable CDR for Azure (during deployment). **To grant Vectra access to your Azure tenant (Consent Workflow):** * `Global Administrator` - Enterprise app is created that requires lower permissions for ongoing use. * See permissions required post deployment below for the ongoing permissions required by the **Vectra AI - CDR for Azure** enterprise app. **To setup logging and grant Vectra access to the logs (Log Enablement Workflow):** These permissions are required during [automated deployment](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/automated-deployment) and includes both [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment) and [remediating policies](https://app.gitbook.com/o/JzmsJ8tnfjhhOVPvs0G8/s/HJ1ltuWFvsArFWtevnRn/~/edit/~/changes/75/deployment/cdr-for-azure/deployment/automated-deployment#id-5.-remediate-policies) flows. * `Global Administrator` * `Resource Policy Contributor` at management group level * `User Access Administrator` at management group level * This can be a temporary privilege elevation used only during the creation of Vectra resources. ## Permissions Required Post Deployment These are the ongoing permissions required post deployment for CDR for Azure. **Enterprise App / Service Principal** Role permissions defined at the Vectra specific resource group level: * `Microsoft.Storage/storageAccounts/read` * `Microsoft.Storage/storageAccounts/blobServices/containers/read` * `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` * `Microsoft.Resources/subscriptions/resources/read` * At the management group level used for deployment. **User-Assigned Managed Identity** For resource remediation that sets logging and retention policies at the management group level: * `Monitoring Contributor Role` and `Storage Account Contributor Role` * This is only required for the [Automated Deployment ](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/automated-deployment)method. Manual deployment details are at the discretion of the customer. ## What Vectra Creates in Azure and Why This applies fully to the Automated Deployment method and partially to the Manual Deployment method (only the **Vectra AI - CDR for Azure** enterprise app is shared with the manual deployment process)
ItemNameHow to Find
(from Azure portal)
Resource Grouprg-vectra-cdrResource groups > Click into “rg-vectra-cdr”
Enterprise Application / Service PrincipalVectra AI – CDR for AzureMicrosoft Entra ID > Enterprise applications > search for “Vectra AI” or “CDR”
Enterprise Application / Service Principal RoleVectra Azure CDR Connector Role
Vectra Azure CDR Audit Role		Resource groups > Click into “rg-vectra-cdr” > Access control (IAM) > Roles > Search for “cdr”
User-Assigned Managed Identityid-vectraResource groups > Click into “rg-vectra-cdr”
Storage AccountsVectra[unique_identifier] - These have 4-day retention set.Resource groups > Click into “rg-vectra-cdr”
Policy Initiatives and PoliciesVectra Initiative Manage Resource Group
Vectra Initiative Collect Location Logs
Vectra Initiative Collect Subscription Activity Logs Vectra Storage Account Retention
Vectra Policy Collect Activity Logs
Vectra Policy Collect Key Vault Logs
Vectra Policy Collect Automation Account Logs
Vectra Policy Collect Storage Account Blob Logs
Vectra Policy Collect Storage Account File Logs		Policy > Definitions > Search for “Vectra”
Policy AssignmentsVectra Initiative Manage Resource Group Assignment Vectra Initiative Collect Subscription Activity Logs Assignment Vectra Initiative Collect Location Logs for [location| AssignmentPolicy > Assignments > Search for “Vectra”
### Enterprise Application - SP and Associated Role Enterprise Applications and Service Principals are essentially the same thing. Typically, the term Enterprise Application is used to describe an application integration while the Service Principal is the security principal for the application that is used to grant permissions or consent to resources. Vectra uses Microsoft’s App Registration process to instantiate a copy of `Vectra AI – CDR for Azure` in your directory. The Application ID of this Enterprise Application / Service Principal refers to Vectra’s App Registration which resides in Vectra’s directory. The Service Principal Object ID refers to the instantiated instance in your directory and is what Vectra refers to as the `enterpriseAppPrincipalID` during deployment. [This article](https://marileeturscak.medium.com/the-difference-between-app-registrations-enterprise-applications-and-service-principals-in-azure-4f70b9a80fe5) gives details on differences between App Registrations, Enterprise Applications, and Service Principals. **Enterprise Application Name** - `Vectra AI – CDR for Azure` **How is it created** – This is created during [1. Grant Vectra Access](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#id-1.-grant-vectra-access) to your Azure tenant. **Associated roles** – Assigned during [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment) using ARM templates. * `Vectra Azure CDR Connector Role` is assigned to the `Vectra AI – CDR for Azure` Service Principal * The scope of the role assignment is the `rg-vectra-cdr` resource group. * The permissions of the role are: * `Microsoft.Storage/storageAccounts/read` * `Microsoft.Storage/storageAccounts/blobServices/containers/read` * `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` * `Vectra Azure CDR Audit Role` is assigned to the `Vectra AI – CDR for Azure` Service Principal * The scope of the role assignment is the management group used for deployment. * The permission of the role is `Microsoft.Resources/subscriptions/resources/read` **What does the Enterprise Application / Service Principal do?** * When Vectra’s LogFlow ingestion process collects log data from your Azure tenant, it assumes the Service Principal which has the role assignment/permissions mentioned in the prior bullet. The Service Principal is only permitted to read the log data that exists in the storage accounts that were created in the `rg-vectra-cdr` resource group. It can also collect counts of resources for billing. ### Resource Group - Storage Accounts - Managed Identity Vectra creates a resource group, storage accounts, and a user-assigned managed identity. **Resource Group** - Name: `rg-vectra-cdr` **How it is created?** * It is automatically created during [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment) using ARM templates. **What does it contain?** * A storage account for each location specified during the deployment and a storage account used to store subscription activity logs. These are set to have a 4-day retention period. * Name format: `vectra[unique_identifier]` * User-Assigned Managed Identity * Name: `id-vectra` **Why does Vectra create a storage account for each location we deployed CDR for Azure to?** * Azure requires that the diagnostic setting that writes resource logs to a storage account write to a storage account that is located in the same location as the resource. **Can the storage accounts be configured for private access?** * Yes, after the main deployment runs, the storage accounts can have restrictions put in place to only allow access to them from specific IP addresses used by Vectra in the region your Vectra tenant is deployed in. * Please see [Configuring Private Access for Azure Storage Accounts](#configuring-private-access-for-azure-storage-accounts) for details if this is required. **What is the purpose of the** `id-vectra` **managed identity?** * The policy remediation tasks are run by the managed identity. **What are the scope and permissions of the** `id-vectra` **managed identity?** * The scope is the management group that was selected for deployment. * The permissions are given by built-in Azure roles: * `Monitoring Contributor Role` * `Storage Account Contributor Role` {% hint style="info" %} **Please Note:** * The `id-vectra` managed identity can only execute actions that are part of the policy definitions and assignments discussed in the next section. * It does not partake in any part of the log ingestion process. * The policy details can easily be viewed by the customer. {% endhint %} ### Policy Definitions, Assignments, and Remediation Tasks Vectra uses Azure policy definitions at both the initiative and policy level along with policy assignments to enable a diagnostic setting on the supported resources. The diagnostic setting directs logs to be stored in the storage accounts so that Vectra can retrieve the logs for analysis. Initiatives are a collection of Azure policy definitions that are grouped together towards a specific goal or purpose. Policies enforce and control the properties of a resource. Assignments are a policy definition or initiative that has been assigned to a specific scope. More information about Azure policy is available [here](https://learn.microsoft.com/en-us/azure/governance/policy/overview). The Azure policy definitions and assignments are created during [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment). Vectra creates 2 initiative definitions: * **Vectra Initiative Collection Subscription Activity Logs** * Contains 1 policy definition that enables a diagnostic setting to send subscription activity logs to a storage account in the `rg-vectra-cdr` resource group. * All subscriptions in the management group chosen for deployment log these subscription activity logs to the same storage account in the resource group. * Policy name – **Vectra Policy Collect Activity Logs** * **Vectra Initiative Collect Location Logs** * Contains 2 policy definitions, one for each currently supported resource type, that enable a diagnostic setting to send resource logs to storage accounts in the `rg-vectra-cdr` resource group. * The resource logs are stored in specific individual storage accounts for each location that was configured during [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment). * Policy names: **Vectra Policy Collect Automation Account Logs**, **Vectra Policy Collect Key Vault Logs**, **Vectra Policy Collect Storage Account Blob Logs**, **Vectra Policy Collect Storage Account File Logs**. Vectra creates the following Policy Assignments: * **Vectra Initiative Collect Subscription Activity Logs Assignment** * **Vectra Initiative Collect Location Logs for \[location] Assignment** * Vectra creates a policy assignment that is specific for each location that was configured. During [5. Remediate Policies](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#id-5.-remediate-policies), Vectra creates remediation tasks to remediate any existing resources in your environment that need to be made compliant with the policies for logging that Vectra created when [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment). These remediation tasks can be viewed in your Azure portal at *Policy > Remedation > Remediation tasks* (be sure to check that the scope matches the management group you used for deployment). Any Vectra supported resources that are deployed after you have fully completed your Vectra CDR for Azure deployment will automatically be made compliant by Azure with the polices that Vectra put in place. As Vectra continues development, additional log types may be supported. Running the ARM template deployment process is an idempotent process. The same steps can be run again in the future, and nothing will change with resources that Vectra has already deployed. If you add any new Azure regions/locations to your deployment or if Vectra adds additional supported resource types, simply redo the main deployment and remediation steps as outlined in the [automated deployment](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/automated-deployment). ## Configuring Private Access for Azure Storage Accounts If it is required to setup private access for the storage accounts used by CDR for Azure, please follow these instructions. This must be completed after the storage accounts have been created. Performing this step will add IP level restrictions to the storage accounts so that only Vectra IPs in the same region as your Vectra tenant will be able to access the storage accounts. When using the Automated Deployment this can be after [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment) has completed. When using Manual Deployment this would be after [3. Deploy to Azure](https://app.gitbook.com/o/JzmsJ8tnfjhhOVPvs0G8/s/HJ1ltuWFvsArFWtevnRn/~/edit/~/changes/75/deployment/cdr-for-azure/deployment/manual-deployment#id-3.-deploy-to-azure) has been completed. If you add additional locations or resources to your deployment, any new storage accounts created during that process would also need to again be configured as per these instructions below. To configure private access for your Azure storage accounts used by CDR for Azure: * Navigate to the resource group containing your storage accounts used for CDR for Azure. * If using the automated deployment, it will be named `rg-vectra-cdr` and in the region you specified during deployment. * Click on one of the storage accounts. * Open the **Security + networking** menu on the left and click on **Networking**. * Select the **Enabled from selected virtual networks and IP addresses** option. * Under the **Firewall** section, add the IPs corresponding to the region of your Vectra tenant from the list of IPs available here: * * For example, if your Vectra URL is like this: `https://[unique_identifier].uw2.portal.vectra.ai/` then you would use the `us-west-2` entries from the above list. * `uw2` = `us-west-2` * `ew1` = `eu-west-1` * `cc1` = `ca-central-1` * `ec2` = `eu-central-2` * `as2` = `ap-southeast-2` * Click **Save**. * Repeat these steps for any additional storage accounts in your CDR for Azure deployment. An example is shown below: ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-0ec84d58356d2bb062c10016aaf0193cc9df05d8%2Fcdr-for-azure-deployment-guide-35.png?alt=media) ## Checking and Resolving Permissions Issues As discussed in [required permissions during deployment](#required-permissions-during-deployment), performing the deployment in Azure requires specific permissions: * **Global Administrator** in Microsoft Entra ID (Azure AD). * **Resource Policy Contributor** at management group level. * **User Access Administrator** at management group level. * This can be a temporary privilege elevation used only during the creation of Vectra resources. This section will discuss how to check if you have the required permissions, how to gain the permissions, and how to remove the permissions after deployment. {% hint style="danger" %} This guidance should NOT be used in place of, or bypass any of your organization’s internal processes or rules that apply to managing permissions within your Azure environment. {% endhint %} {% hint style="info" %} Prior to performing any permission elevation, you should check the access you currently have. You may already have the required RBAC permissions and may not need to elevate permissions or you may not have sufficient permissions to perform the elevation flow. If you cannot validate or add the permissions that are required, please work with someone in your organization who can perform the deployment or provide you with the necessary permissions. {% endhint %} ### Check for Global Administrator Role in Microsoft Entra ID * In the Azure portal, navigate to *Microsoft Entra ID.* * Click on **Users** in the menu to the left. * Search for the user who will be performing the install and click on their name. * From the user page, click **Assigned Roles** in the menu to the left and verify that you see **Global Administrator** in the list of roles. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-53c9bd3403fabca9dc7e1221bb9f9cd2173c3859%2Fcdr-for-azure-deployment-guide-36.png?alt=media) * If the user who will be performing the deployment does not have this role, please work with your IT team and internal process to be assigned this role. * Alternatively, you can also navigate to *Microsoft Entra ID → Roles and administrators →* search for **Global Administrator** and click on it. * The **Active Assignments** column will contain a list of users who have this role and could potentially perform the deployment. ### Check for User Access Administrator and Resource Policy Contributor Role The [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) role enables the user to grant themselves and other users access to Azure resources. This role will be required throughout the installation process. The [Resource Policy Contributo](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#resource-policy-contributor)r role gives users the rights to create and modify resource policy. This will be required to deploy the initial template and during the policy remediation stage of the deployment. * In the Azure Portal, navigate to *Management Groups*. * Select the management group you wish to deploy Vectra CDR for Azure in. * If you cannot select the Management Group and instead see a message stating, **You are not authorized to view this Management Group**, then you do not have any roles assigned to you within that Management Group. * In this case, work with a colleague, or if you are a Global Administrator, you should be able to Elevate Permissions as Global Administrator. * After elevating permissions, you should be able to Assign Resource Policy Contributor Role. * After elevating permissions and assigning the Resource Policy Contributor role, you can come back here and perform the check as described below. * If you do not use management groups, please get in touch with your account team to discuss options. * Click into *Access Control (IAM)* in the left menu. * Click on the **View my access** button if you will be doing the installation or the **Check access** button to then search for the user who will be doing the installation. * On the assignments screen, check for both the **Resource Policy Contributor** and **User Access Administrator** roles. * They should both have a scope of **This resource** which refers to the management group that you chose earlier. * If you have this role at the **Root** scope, this will suffice as well. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-94b5244d0b2c39410afc2fad3be10b191cdc2891%2Fcdr-for-azure-deployment-guide-37.png?alt=media) * If you are missing either of these roles, you will need to either add these roles (following your organization’s internal process) or use the instructions below. The User Access Administrator role can be a temporary elevation that is used only for the deployment, or it can be a role assignment. * If you determine that it is necessary to add the User Access Administrator role, we will assume this to be a temporary elevation use case in our below instructions. ### Elevate Permissions as Global Administrator Performing this step will add the User Access Administrator role at the root level in Azure. This is a highly privileged role that allows for a wide range of actions related to user permissions across all subscriptions and management groups. It is a best practice to assign this temporarily and then remove the role assignment after you have performed the deployment. Please see [this Microsoft article](https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal) for additional details. * In the Azure portal, navigate to *Microsoft Entra ID.* * Click **Properties** in the menu to the left. * Toggle the **Access management for Azure resources** setting to **Yes** and **Save**. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-9b88db96034af467fb2676575723b1f56fe4d1f0%2Fcdr-for-azure-deployment-guide-38.png?alt=media) * A success notification will appear in the corner once complete. * There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials. * Once elevated per the above instructions, you should be able to assign the Resource Policy Contributor role. ### Assign Resource Policy Contributor Role * In the Azure Portal, navigate to *Management Groups*. * Select the management group you wish to deploy Vectra CDR for Azure in. * Click into *Access Control (IAM)* in the menu to the left. * Click **+ Add** and the click **Add role assignment**. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-39b22d5180f66ccde0b97f8da7effa4ccbc777b6%2Fcdr-for-azure-deployment-guide-39.png?alt=media) * In the search bar, type **Resource Policy Contributor**, click on its line, and then click **Next**. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-57d6696921632bdb0cca7fd208d0533670efc08f%2Fcdr-for-azure-deployment-guide-40.png?alt=media) * In the **Members** tab, ensure **User, group, or service principal** is selected, click **+ Select members** and then search for the name/email address of the user who will perform the installation. Select the user from the list that appears and click the **Select** button. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-99c48b9edfffb261754c26e6101212c93d014773%2Fcdr-for-azure-deployment-guide-41.png?alt=media) * Click **Next twice** to move to the **Review + assign** screen, confirm the details are correct, and then click the **Review + assign** button. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-68be7d9262e56a862e6980de272ba1657d3e468a%2Fcdr-for-azure-deployment-guide-42.png?alt=media) * A success notification will appear in the corner once complete. * There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials. * After adding the Resource Policy Contributor role, it is recommended to check your permissions per the earlier instructions before continuing with the deployment. ### Recommended Order of Operations for Permissions Cleanup If it was required to elevate permissions or add roles as part of the deployment, it is recommended to remove these permissions when they are no longer required. Vectra’s recommended sequencing is: 1. The user performing the deployment should perform De-Elevating Permissions as Global Administrator after Executing the main deployment (Deploy to Azure). This will ensure the deployment user will not have unnecessary permissions during the wait for the automated Azure policy compliance scan to complete. 2. After 24 hours, the user should perform the remediation as per Ensure pre-existing resources are remediated to log correctly (Remediate Policies). 3. After successful remediation, the user should again Elevate Permissions as Global Administrator so that they can Remove the Resource Policy Contributor Role that was required to be in place for the remediation step. 4. Remove the Resource Policy Contributor Role. 5. Finally, the user should perform De-Elevating Permissions as Global Administrator as shown below. ### De-Elevating Permissions as Global Administrator This will remove the User Access Administrator role that was temporarily added. Keep in mind that to be able to Remove the Resource Policy Contributor Role, you must have the User Access Administrator role that doing this step removes. It is recommended to follow the Recommended Order of Operations for Permissions Cleanup. * In the Azure portal, navigate to *Microsoft Entra ID.* * Click **Properties** in the menu to the left. * Toggle the **Access management for Azure resources** setting to **No**, and click **Save**. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-d3a74d84bbe34209d80b97f6635385d59024ca8e%2Fcdr-for-azure-deployment-guide-43.png?alt=media) * A success notification will appear in the corner once complete. * There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials. ### Remove the Resource Policy Contributor Role To remove the Resource Policy Contributor role, the user needs to have the User Access Administrator role that was granted earlier through permission elevation. * In the Azure Portal, navigate to *Management Groups*. * Select the management group you deployed Vectra CDR for Azure into. * Click into *Access Control (IAM)* in the left menu. * Click the **Role Assignments** tab and then click on the **Role** filter button and select the **Resource Policy Contributor** role. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-138d6708ea18c5fb3a5f34c4adafea6f5ef2f363%2Fcdr-for-azure-deployment-guide-44.png?alt=media) * Select the checkbox next to the user you wish to remove the role from, click **X Remove** and then click **Yes** in the modal that appears. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-dbff3c6941de4deb7b63b806a72bea3d048817e7%2Fcdr-for-azure-deployment-guide-45.png?alt=media) * There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials. ## Unsupported Azure Locations **Location** or **Region** terminology is often used interchangeably in Azure documentation. One example is that when using the Azure CLI command of `az account list-locations`, the output is technically a list of regions. In this documentation, **Location** or **Region** is also used interchangeably. Due to differences in capabilities that Azure offers in each Location/Region, Vectra CDR for Azure will not be able to ingest logs in some Locations. Additionally, some Locations cannot serve as the default Region for the deployment during [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment). Please see the below table for details: * The column on the left, **Unsupported Locations/Regions**, are locations that storage accounts currently cannot be created in. * If your Azure deployment is using any of these locations, Vectra CDR for Azure will not be able to collect logs from these locations. There will not be any errors generated during deployment because of this. * The column on the right, **Locations/Regions Unsupported as Primary**, if one of these Regions is selected when choosing the **Region** for the ARM template deployment, an error will occur during deployment. An example of such an error is included below: ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-db207803bf76db33c7bd3754f29c8b613122cef4%2Fcdr-for-azure-deployment-guide-46.png?alt=media) | **Unsupported Locations/Regions** | **Locations/Regions Unsupported as Primary** | | --------------------------------- | -------------------------------------------- | | australiacentral2 | australiacentral | | brazilsoutheast | israelcentral | | francesouth | westindia | | germanynorth | | | norwaywest | | | southafricawest | | | switzerlandwest | | | uaecentral | |