Cloud API

• 1: Overview
• 2: Architecture
• 3: Installation
• 3.1: Prerequisites
• 3.2: Pre-Configuration
• 3.3: Protect Service Installation
• 3.4: Policy Agent Installation
• 3.5: Audit Log Forwarder Installation
• 3.6:
• 3.7:
• 3.8:
• 4: REST API
• 4.1: Export an OpenAPI Spec
• 4.2: Payload Encoding
• 4.3: v1 Specification
• 4.4: Legacy Specification
• 4.5: SSL Certificates
• 5: Performance
• 5.1: Function App Performance
• 5.2: Log Forwarder Performance
• 6: Audit Logging
• 7: No Access Behavior
• 8: Upgrading To The Latest Version
• 9: Known Limitations
• 10: Appendices
• 10.1: Integrating Cloud Protect with PPC (Protegrity Provisioned Cluster)
• 10.2: Configuring Regular Expression to Extract Policy Username
• 10.3: Getting JWT for Service Account in Azure Active Directory
• 10.4: Protection Methods
• 10.5: ARM Template Installation - Required Permissions
• 10.6: Associating ESA Data Store With Cloud Protect Agent

1 - Overview

Solution Overview

Cloud API Protector on Azure is a cloud-native, serverless product for fine-grained data protection. This enables the invocation of Protegrity data protection cryptographic methods in cloud-native serverless technology. The benefits of serverless include rapid auto-scaling, performance, low administrative overhead, and reduced infrastructure costs compared to a server-based solution.

This product provides a data protection API end-point for clients. The product is designed to scale elastically and yield reliable query performance under extremely high concurrent loads. During idle use, the serverless product will scale completely down, providing significant savings in Cloud compute fees.

Protegrity utilizes a data security policy maintained by an Enterprise Security Administrator (ESA), similar to other Protegrity products. Using a simple REST API interface, authorized users can perform both de-identification (protect) and re-identification (unprotect) operations on data. A user’s individual capabilities are subject to privileges and policies defined by the Enterprise Security Administrator.

Analytics on Protected Data

Protegrity’s format and length preserving tokenization scheme make it possible to perform analytics directly on protected data. Tokens are join-preserving so protected data can be joined across datasets. Often statistical analytics and machine learning training can be performed without the need to re-identify protected data. However, a user or service account with authorized security policy privileges may re-identify subsets of data using the Cloud API Protector on Azure service.

Features

Cloud API Protector on Azure incorporates Protegrity’s patent-pending vaultless tokenization capabilities into cloud-native serverless technology. Combined with an ESA security policy, the protector provides the following features:

• Role-based access control (RBAC) to protect and unprotect (re-identify) data depending on the user privileges.
• Policy enforcement features of other Protegrity application protectors.

For more information about the available protection options, such as, data types, Tokenization or Encryption types, or length preserving and non-preserving tokens, refer to Protection Methods Reference.

2 - Architecture

Deployment Architecture

Protegrity’s Cloud API on Azure should be deployed in the Customer’s Cloud account. The product incorporates Protegrity’s vaultless tokenization engine within an Azure Function App. The encrypted data security policy from an ESA is deployed periodically as a static resource through an Azure Blob Storage container. The policy is decrypted in memory at runtime within the Function App. This architecture allows Protegrity Serverless to be highly available and scale very quickly without direct dependency on any other Protegrity services.

The product exposes a remote data protection service. Each REST request includes a micro-batch of data to process and parameters such as operation and data element. The function applies the data security policy including user authorization and returns a corresponding response. Security operations on sensitive data performed by protector can be audited. The product can be configured to send audit logs to ESA via optional component called Log Forwarder.

The security policy is synchronized via another serverless component called the Protegrity Policy Agent. The agent operates on a configurable schedule, fetches policy from ESA, performs envelope encryption using Azure Key Vault, and deploys the policy into the Azure Blob Storage container which is accessed by Protector Function App. This solution can be configured to automatically provision the static policy or the final step can be performed on-demand by an administrator.

The following diagram shows the high-level architecture described above.

The following diagram shows a reference architecture for synchronizing the security policy from ESA.

The ESA is a soft appliance that must be pre-installed on a separate server. It is used to create and manage security policies.

For more information about installing the ESA, and creating and managing policies, refer to the Policy Management Section

Audit Log Forwarding Architecture

Audit logs are by default sent to Azure Blob Storage and Application Insights. The Cloud Protect product can also be configured to send audit logs to ESA. Such configuration requires deploying audit Log Forwarder component which is available as part of Cloud Protect deployment bundle. The diagram below shows additional resources deployed with Log Forwarder component.

The audit log forwarding solution includes Azure Event Hubs data-streaming service and an Azure Function App deployment called Log Forwarder. Protect function delivers audit logs to Azure Event Hub instance, Event Hub instance batches audit logs and delivers them to Log Forwarder function. Log Forwarder function then delivers audit logs to ESA. Audit log aggregation occurs on both Protect and Log Forwarder functions. Aggregation rules are described in the Understanding the log aggregation section. If Log Forwarder cannot deliver audit logs to ESA due to temporary ESA connection loss, it will send undelivered audit logs to a dead-letter queue Event Hub. Audit logs in dead-letter queue Event Hub can be re-delivered to ESA using another instance of Log Forwarder, which can be configured to run either manually or on schedule.

The security of audit logs is ensured by using HTTPS connection on each link of the communication between protector function and ESA. Integrity and authenticity of audit logs is additionally checked on Log Forwarder function which verifies individual logs signature. The signature verification is done upon arrival from Azure Event Hub before applying aggregation. If signature cannot be verified, the log is forwarded as is to ESA where additional signature verification can be configured. Log Forwarder function uses client certificate to authenticate calls to ESA.

To learn more about individual audit log entry structure and purpose of audit logs, refer to Audit Logging section. Installation instruction can be found in the Audit Log Forwarder Installation.

Forwarding of audit logs requires network access from the cloud to the ESA.

Access Control

The Cloud API utilizes access controls provided by the Azure Function service. The following mechanisms are available for controlling and restricting access to the Cloud API data protection endpoint:

• Azure role-based access control (Azure RBAC).
• Function access keys. Requests must include an API access key in the request.
• OpenID Connect. OpenID is a simple identity layer on top of the OAuth 2.0 protocol. Authorization is performed in the Protegrity Function App code.

For more information on Azure Function security concepts, refer to Azure documentation:

• Azure Functions Security Concepts

• REST API Authentication and Authorization

• REST API Policy Authorization

REST API Authentication and Authorization

The Rest API supports built-in authentication and authorization provided by Azure Function app. More information is available in the following Azure documentation:

App Service Authentication/Authorization Overview

REST API Policy Authorization

Once the request is authenticated and authorized by the Azure Function App, the Protegrity Cloud API performs the requested security operation based on the policy data element from the payload and the authenticated user.

3 - Installation

3.1 - Prerequisites

Azure Services

The following table describes the Azure services that may be part of your Protegrity installation.

All permissions in the table must be granted with the Resource group scope.

ESA Version Requirements

The Protector and Log Forwarder functions require a security policy from a compatible ESA version.

The table below shows compatibility between different Protector and ESA versions.

Prerequisites

Required Skills and Abilities

3.2 - Pre-Configuration

Resource Group

Identify or create a new Azure Resource Group where the Protegrity solution will be installed. It is recommended that a new Resource group is created. This can provide greater security controls and help avoid conflicts with other applications that might impact regional account limits. An individual with the Cloud Administrator role will be required for some of the subsequent installation steps.

Azure Subscription ID (AzureSubscriptionID): ____________________

Azure Resource Group ID (ApiResourceGroupID): ___________________

Azure Region (ApiRegion): ___________________

Key Vault

Key Vault is required to store secrets and encrypt policy deployment package. Identify existing Key Vault or create new.

To create Key Vault:

1. From the Azure Console select Create a resource.

2. Navigate to Key Vault > Create.

3. Select a Resource group.

4. Enter a Key vault name.

5. Select a Region. For the best performance, use the same region for all resources.

6. Set the Pricing tier to Standard.

7. Under Access configuration, select Vault access policy as the Permission model.

8. Under Networking, ensure that Enable public access is selected.

9. Under Review + create, click Create.

10. Record Key Vault Name:

    Key Vault Name (PolicyKeyValue): ___________________

Function App Storage

Create Storage Account

Create a storage account to host Protegrity deployment packages provided in installation artifact bundle. Note that turning on the firewall or restricting access to selected virtual networks or IP address ranges will require additional configuration and is beyond the scope of this document.

To create Function App storage:

1. From the Azure Console select Create a resource.

2. Navigate to Storage account > Create.

3. Select the Resource group where the Protegrity solution will be deployed.

4. Enter a Storage account name.

5. Select the Region where the Protegrity solution will be deployed.

6. Set the Preferred storage type to Azure Blob Storage or Azure Data Lake Storage

7. Set the Primary workload to Cloud native

8. Setting for Performance should be set to Standard.

9. Setting for Redundancy should be set to Geo-redundant storage (GRS).

10. Continue to Advanced setup and verify Enable hierarchical namespace is unchecked

    Warning

    If Enable hierarchical namespace is checked, Policy Agent component will not be able to properly set the policy blob url, resulting in Protector error Policy is not available

11. Adjust the Networking and Data protection configurations according to your security requirements or use the default values.

12. Under Review + create, click Create.

13. Record the storage account name

    Storage Account Name (StorageAccountName): ____________________

14. Record the storage blob service URL. Navigate to created Storage Account, select Settings, Endpoints, record the value of Blob Service

    Storage Account Blob Service Url (StorageAccountBlobServiceUrl): ____________________

Upload Files

Create a deployment container using the Azure Blob Service.

1. Go Storage Account created in the previous step.

2. Under Data storage section, select Containers and click + Container .

3. Type in container name and click Create .

4. Upload the following installation artifacts to the container:

• protegrity-protect-azure-<version>.zip
• protegrity-agent-azure-<version>.zip

5. Record Protect function blob URL:

   Protect Function Blob URL (ProtectFuncURL): ____________________

6. Record Forward function blob URL. Both Protect and Forward functions use the same protegrity-protect-azure-<version>.zip distribution:

   Forward Function Blob URL (ForwardFuncURL): ____________________

7. Record Agent function blob URL:

   Agent Function Blob URL (AgentFuncURL): ____________________

Create Protect Function Policy Blob

Create a blob container for encrypted Protegrity security policy using Azure Blob Service. Agent will store encrypted policy in this container. Both Protect and Log Forwarder functions will load policy from this container.

1. Go Storage Account created in the previous step.

2. Under Data storage section, select Containers and click + Container .

3. Type in container name and click Create .

4. Right-click the container name, and select Container properties to obtain URL.

   Append the name of the policy file to the container URL, e.g, https://<your-storage-account>.blob.core.windows.net/<your-policy-container>/<your-policy-file-name>.zip. Record the blob url.

   Protect Function Policy Blob URL (ProtectFuncPolicyBlobUrl): ____________________

Create Agent Policy Blob Container

The Agent function uploads an encrypted policy zip package to a blob container which is used as a staging storage. Create the policy staging container

To prepare the policy blob container:

1. Under Storage account created in previous step, select Data storage > Containers and click + Container .

2. Type in a container name and click Create .

   Agent Policy Blob Container Name (AgentPolicyBlobContainer): ___________________

3.3 - Protect Service Installation

Preparation

1. Ensure that all the steps in Pre-Configuration are performed.

2. Login to the Azure account console where Protegrity will be installed.

3. Ensure the Azure Resource Manager templates provided by Protegrity are available on your local computer.

Register an Entra ID App

A Microsoft Entra ID App provides the mechanism for Client to authenticate with the Function App instance. Creating an Entra ID app requires appropriate permissions to the Azure Subscription and is typically performed by the Azure Account Administrator.

To register an Entra ID App:

1. In the Azure portal navigate to Microsoft Entra ID.

2. Click + Add and select App registration.

3. Enter a Name and select Accounts in any organizational directory.

4. Leave the Redirect URI empty and select Register.

5. After registration is complete record the application name and application id displayed in the overview window.

   Entra ID Application Name (EntraIDApplicationName): ___________________

   Entra ID Application ID (EntraIDApplicationID): ___________________

Protect Function User-Assigned Managed Identity

User-assigned Azure managed identities are optional. If a user-assigned identity is not provided, a system-assigned managed identity will be enabled the function. User-assigned managed identities offer less frequent updates to Azure resources and allow for configuration of permissions ahead of function creation.

1. In the search box, enter Managed Identities. Under Services, select Managed Identities

2. Select Create

3. For Subscription provide recorded value of AzureSubscriptionID

4. For Resource Group provide recorded value of ApiResourceGroup

5. For Region provide recorded value of ApiRegion

6. For Name provide a name of the new identity

7. Assign following roles to this identity:

   • Storage Blob Data Owner
   • Monitoring Metrics Publisher
   • Azure Event Hubs Data Sender: required only if function is sending logs to ESA

8. Record Protect function user-assigned identity

   Protect Function User-Assigned Identity (ProtectFuncUserAssignedIdentity): ____________________

Install Protect Function via Azure Resource Manager

Resources created with the ARM template include API Management service, Function App, App Service Plan and Application Insights service.

To install protect function via Azure Resource Manager:

1. From Azure Console, select Create a resource, search for template then select Template deployment (deploy using custom templates) > Create.

2. Select Build your own template in the editor.

3. Click Load File and upload pty_protect_arm_v2.json, then click Save.

4. Select a Resource group.

5. Enter a Name for the resources. All resources will be prefixed with Protegrity-Protect except for log container which will be prefixed with ptylogs. For more information on naming rules see: Azure resource name rules.

6. For Location input specify Azure region name or leave default to deploy in the same region as resource group.

7. For Storage Account Blob Service Url Optionally use the value recorded in Create Storage Account. If value is not given, it will be automatically derived from Protect Function Blob Url.

8. For Protect Function Blob Url use the value from Upload Files.

9. For Function App Managed Identity Optionally use the value from Protect Function User-Assigned Managed Identity. If value is not given, a system-assigned managed identity will be enabled.

10. For Function Sku either EP1 or EP3 are recommended. Note that this will affect the running cost.

11. For Create Api Management Service select Do not create. API Management Service is required only for integration with Snowflake. This service is not required otherwise.

12. For Api Management Service Sku Applicable only when API Management Service is created. Skip this if API Management Service is not created. Either Consumption (if available) or Premium are recommended. Note that this will affect the running cost.

13. For Username Regex you can optionally specify regex to extract policy username from the request. See Configuring Regular Expression to Extract Policy Username for more details.

14. For Entra ID Application ID enter the value recorded in Register an Entra ID App.

15. For Forward Logs To ESA select whether audit logs are to be sent to ESA or not. If you are not planning on sending audit logs to ESA you can skip Event Hub Nameand Event Hub Namespace properties below. For details on creating and configuring Event Hubs see Audit Log Forwarder Installation

16. For Event Hub Name provide the name of Event Hub which will be used to send audit logs to ESA.

17. For Event Hub Namespace provide the name of Event Hub Namespace which is hosting Event Hub selected in previous step.

18. Under Review + create, click Create. Wait for all resources to deploy. If the deployment fails for any resources of type Microsoft.Web/sites/host/functionKeys then click Redeploy and try deploying again.

19. After deployment is complete, go to Outputs and record protectFunctionName, azureTenantId and apiGatewayUrl.

    Protect Function Name (ProtectFuncName): __________________

    Azure Tenant ID (AzureTenantID): __________________

    API Gateway URL (ApiGatewayURL): __________________

Function System-Assigned Managed Identity

System-assigned Azure managed identity is enabled if user-assigned managed identity is not used. User-assigned managed identities offer less frequent updates to Azure resources and allow for configuration of permissions ahead of function creation.

If you have not created a user-assigned managed identity at Protect Function User-Assigned Managed Identity, setup following role assignments for system-assigned managed identity:

1. Navigate to the function

2. Select Settings, Identity.

3. Confirm Status of system-assigned identity is already On on System Assigned tab

4. Click on Azure role assignments button.

5. Assign following roles to this identity:

   • Storage Blob Data Owner
   • Monitoring Metrics Publisher
   • Azure Event Hubs Data Sender: required only if function is sending logs to ESA

6. From Azure console, navigate to Function App and select protect function deployed in previous section.

7. Select Overview and click Restart button. Wait until function restart completes.

Update Key Vault Access Policies

The Key vault must be updated to allow the Function App to decrypt the policy files. Azure assigns a unique identifier to each Function App instance that can be used to grant permissions to that instance. Update the Key vault access policies with the Protect function. To update the key vault access policies:

Obtain Function App identifier

1. Navigate to the Function App service in the Azure portal.

2. Select the newly created Protect Function App instance.

3. Select the Identity option under Settings.

4. Ensure that setting System assigned is set to Status On.

5. Record the Object ID:

   Protect Function Object ID: ___________________

Update the Key vault access policies with the Protect function’s Object ID

1. From Azure console navigate to Key Vaults, select the Key Vault created in Key Vault.
2. Select Access policies.
3. Click Create.
4. Select the following permissions in Permissions tab: a. Get under Key Management Operations. b. Unwrap Key under Cryptographic Operations. c. Get under Secret Permissions.
5. Proceed Next to Principal.
6. Enter the Protect Function Object ID recorded in this section into the search field.
7. Select the Function App instance.
8. Proceed Next to Application and Next again to Review + Create.
9. Review permissions and Create.

Upload the Sample Policy

The Protegrity installation bundle contains a sample policy which can be used to test the protect service installation without an ESA. Upload the sample policy artifact to the policy Blob storage container:

1. Go to Azure console and select Storage Account Name (StorageAccountName) recorded in step Create Storage Account.

2. Under Data storage select Blob Containers and select container created in Protect Function Policy Blob Container

3. Click Upload and select protegrity-sample-policy-<version>.zip file from your local computer.

4. Click Upload and wait for the file to complete uploading.

5. Record the sample policy blob url:

   Sample Policy Blob Url (SamplePolicyBlobUrl): ___________________

Test the Protect Function Installation

Before continuing with next steps, you may verify the protect service is installed correctly. This step is optional and can be skipped.

1. From Azure console, navigate to Function App and select protect function app.

2. Select Overview and record URL value as <Protect Function URL>.

3. Navigate to Settings > Environment variables and click OPENID_ENABLED.

4. Change value to false and click Apply.

5. Select or create variable AZURE_POLICY_BLOB_URL.

6. Set value of AZURE_POLICY_BLOB_URL to value recorded for SamplePolicyBlobUrl and click Apply.

7. Select Apply and Confirm to finalize setting changes.

8. Go to Functions > App keys and record the value of default key under Host Keys (All functions) as <Protect Function app key>.

9. Run the following CURL command to test Function deployment.

   curl -X POST "<Protect Function URL>/api/v1/unprotect" -k \
   -H 'x-functions-key: <Protect Function app key>' \
   -H 'Content-Type: application/json' \
   -d '{
     "data": ["UtfVk UHgcD!"],
     "user": "MARIA",
     "data_element": "alpha"
   }'
   

   Note

   When you copy-paste the curl command, make sure each header is in a separate line.

10. Replace <Protect Function URL> and <Protect Function app key> with the values recorded in step 2 And 5.

11. Run curl command. Verify the following output.

    {"data":["hello world!"], "success": true, "encoding": "utf8"}
    

12. Go back to Function app. Select Settings > Environment variables and click OPENID_ENABLED,

13. Change value to true and click Apply. Select Apply and Confirm to finalize.

Troubleshooting

To review live requests, navigate to Application Insights service and select item with the same name as the protect function. Under Investigate, select Live Metrics. Wait for the dashboard to load, then go to Sample Telemetry pane on the right and look for the requests in question.

To review the full history of requests from Application Insights under Monitoring select Logs:

1. Select the Tables tab.
2. Hover over one of the table names under Application Insights header, for example exceptions.
3. Click on See preview data.
4. Click Use in editor.

You can also run the query directly in the query editor. For instance to select the 10 latest exceptions run the following query.

exceptions 
| where timestamp > ago(24h)
| order by timestamp
| limit 10

Protect Function App Configuration

Protect Function app can be customized using environment variables. From Azure console, navigate to Function App service and select protect function app. Navigate to Settings > Environment variables. Add or Edit environment variables based on the following information.

3.4 - Policy Agent Installation

Policy Agent Function installation is done via Azure Resource Manager template provided by Protegrity. Before running the template, some resources must be created manually.

ESA Server

Policy Agent function requires ESA server running and accessible from Agent Function App on TCP port 8443. Make sure inbound connections on TCP:8443 are allowed for the network where ESA is hosted. You can find the list of Agent Function Outbound IP addresses after you deploy the function in Agent Function Outbound IP address

Note down ESA IP to be accessed form Agent Function:

ESA IP Address (EsaIpAddress): ___________________

Certificates on ESA

By default, ESA is configured with self-signed certificates, which can only be validated using self-signed CA certificate supplied in policy agent Cloud Function Environment variables configuration.

In case ESA is configured with publicly signed certificates, this section can be skipped since the agent function will use public CA to validate ESA certificates.

To obtain self-signed CA certificate from ESA:

1. Log in to ESA Web UI.

2. Select Settings > Network > Manage Certificates.

3. Hover over Server Certificate and click on download icon to download the CA certificate.

4. After certificate is downloaded, open the PEM file in text editor and replace all new lines with escaped new line: \n.

   To escape new lines from command line, use one of the following commands depending on your operating system:

   Linux Bash:

   awk 'NF {printf "%s\\n",$0;}' ProtegrityCA.pem > output.txt
   

   Windows PowerShell:

   (Get-Content '.\ProtegrityCA.pem') -join '\n' | Set-Content 'output.txt'
   

5. Record the certificate content with new lines escaped.

   ESA CA Server Certificate (EsaCaCert): ___________________

   This value will be used to set PTY_ESA_CA_SERVER_CERT variable in the Policy Agent Function Configuration section Configure Function

For more information about ESA certificate management refer to Certificate Management Guide in ESA documentation.

Create Policy Encryption Key

Create a policy encryption key.

To create policy encryption key:

1. From Azure console, navigate to Key Vaults and select Key Vault created in Key Vault.

2. Under Objects, select Keys.

3. Click Generate/Import.

4. Specify the following:

   a. Key name for the Name field.

   b. RSA for Key type.

   c. 2048 for RSA key size.

   d. Set Enabled toggle to Yes.

5. Select Create.

6. Click on the key name after creation is complete, then click on the key identifier row under CURRENT VERSION.

7. Copy the full URL value of Key Identifier. Record it for later use:

   Policy Encryption Key ID (PolicyEncryptionKey): _________________

Agent Function User-Assigned Managed Identity

User-assigned Azure managed identities are optional. If a user-assigned identity is not provided, a system-assigned managed identity will be enabled the function. User-assigned managed identities offer less frequent updates to Azure resources and allow for configuration of permissions ahead of function creation.

1. In the search box, enter Managed Identities. Under Services, select Managed Identities

2. Select Create

3. For Subscription provide recorded value of AzureSubscriptionID

4. For Resource Group provide recorded value of ApiResourceGroup

5. For Region provide recorded value of ApiRegion

6. For Name provide a name of the new identity

7. Assign following roles to this identity:

   • Storage Blob Data Owner with scope Storage account
   • Monitoring Metrics Publisher with scope Resource Group
   • Website Contributor with scope Resource Group

8. Record Agent function user-assigned identity

   Agent Function User-Assigned Identity (AgentFuncUserAssignedIdentity): ____________________

Install Agent via ARM template

Resources created with ARM template include Function App, Premium V3 App Service Plan (optional) and Application Insights service. Run Azure Resource Manager deployment.

To install Agent via ARM template:

1. From Azure Console, select Create a resource, search for template and then select Template deployment > Create.

2. Select Build your own template in editor.

3. Select Load File and upload pty_agent_arm_v2.json. Click Save.

4. Select Resource Group.

5. Specify Name for the resources (All resources will be prefixed with Protegrity-Agent).

6. For Location input specify Azure region name or leave default to deploy in the same region as resource group

7. For Agent Function Blob Url use the value from Upload Files

8. For Function App Managed Identity Optionally use the value from Agent Function User-Assigned Managed Identity. If value is not given, a system-assigned managed identity will be enabled.

9. If you set Use Existing App Service Plan to True, you must specify existing Linux App Service Plan name in the next parameter.

10. For Storage Account Blob Service Url Optionally use the value recorded in Create Storage Account. If value is not given, it will be automatically derived from Agent Function Blob Url.

11. Select Review + create then Create. Wait for all resources to deploy

12. After deployment is complete, go to Outputs and record agentFunctionName:

    Agent Function Name: __________________

Function System-Assigned Managed Identity

System-assigned Azure managed identity is enabled if user-assigned managed identity is not used. User-assigned managed identities offer less frequent updates to Azure resources and allow for configuration of permissions ahead of function creation.

If you have not created a user-assigned managed identity at Agent Function User-Assigned Managed Identity, setup following role assignments for system-assigned managed identity:

1. Navigate to the function

2. Select Settings, Identity.

3. Confirm Status of system-assigned identity is already On on System Assigned tab

4. Click on Azure role assignments button.

5. Assign following roles to this identity:

   • Storage Blob Data Owner with scope Storage account
   • Monitoring Metrics Publisher with scope Resource Group
   • Website Contributor with scope Resource Group

Creating ESA Credentials

Policy Agent Function requires ESA credentials to be provided as one of the two options:

• ESA credentials stored as secrets in Azure Key Vault
• ESA credentials provided by a custom Azure Function App )

ESA Credentials In Azure Key Vault

Policy Agent Function uses Key Vault as secure store for sensitive information like ESA username and password.

Create ESA credentials secrets:

1. Navigate to Key Vault.

2. Under Objects, select Secrets > Generate/import.

3. Select Manual, then type in valid json as shown in the example for Secret value.

   {"username": "<policy_export_user>", "password": "<password>"}
   

4. Select Create.

5. Navigate to the secret details in Key Vault by selecting the newly created secret.

6. Inspect the current secret version properties by selecting the current version.

7. Copy the Secret Identifier value. For example https://<myvault>.vault.azure.net/secrets/<mysecret>/abcdefgxyz8edef595adaehij0d99123.

8. Record the Secret Identifier for later use.

ESA Credentials From Custom Azure Function App

Policy Agent Function requests ESA username and password from a custom Azure Function App, further referred to as ESA Credentials function. This method may be used to get the username and password from external vaults.

There are four options for configuring Policy Agent authorization with ESA Credentials function: Option 1, Option 2, Option 3 and Option 4. Only one option is expected to be configured at a time.

Create ESA credentials function:

1. Create Azure HTTP triggered ESA Credentials function using any supported runtime.

   a. There is no input needed.

   b. The function must accept an HTTP POST request.

   c. The function must return the following response schema

   ```
   response: 
   type: json object
     properties: 
       username: string 
       password: string  
   ```
   
   For example,
   
   ```
   {"username": "admin", "password": "Password1234"} 
   ```
   

2. Configure Policy Agent to use ESA Credentials function app.

   a. Navigate to HTTP triggered function to open ‘Code + Test’ page.

   b. Under ‘Code + Test’ tab on ‘Code + Test’ page select ‘Resource JSON’.

   c. In ‘Resource JSON’ blade record the value of ‘invoke_url_template’ property.

   **'invoke_url_template'** property is located towards the bottom of resource json.
   
   URL must be in the form of 'https://[function-app-name].azurewebsites.[net|us]/api/[http-trigger-name]'.
   
   **ESA Credentials function URL (EsaCredentialsFnUrl):__________**
   

   d. Navigate to Policy Agent function app.

   e. Expand Settings menu item.

   f. Select Environment Variables menu item.

   g. Click Add button.

   h. For Name use PTY_ESA_CREDENTIALS_FUNCTION.

   i. For Value use ESA Credentials function URL (EsaCredentialsFnUrl) recorded in previous steps.

   j. Hit Apply in Add/Edit application setting blade.

   k. Hit Apply in App Settings tab.

3. Configure Authorization Option 1: Function Key Option 2: Key Vault Option 3: System-assigned Identity Option 4: User-assigned Identity

Authorization Option 1: Configure Policy Agent to access ESA Credentials function using ESA Credentials function key from environment variables.

1. Configure HTTP trigger of ESA Credentials function with authentication level FUNCTION.

   Review Azure documentation on how to accomplish this.

2. Navigate to ESA Credentials function app.

3. Expand Functions menu item.

4. Select App Keys.

5. Record default key value.

   ESA Credentials function key (EsaCredentialsFnKey):_______________

6. Navigate to Policy Agent function app.

7. Expand Settings menu item.

8. Select Environment Variables menu item.

9. Click Add button.

10. For Name use PTY_ESA_CREDENTIALS_FUNCTION_KEY.

11. For Value use ESA Credentials function key (EsaCredentialsFnKey) recorded in previous steps.

12. Hit Apply in Add/Edit application setting blade.

13. Hit Apply in App Settings tab.

Authorization Option 2: Configure Policy Agent to access ESA Credentials function using ESA Credentials function key from Azure Key Vault.

1. Configure HTTP trigger of ESA Credentials function with authentication level FUNCTION.

   Review Azure documentation on how to accomplish this.

2. Navigate to ESA Credentials function app.

3. Expand Functions menu item.

4. Select App Keys.

5. Record default key value.

   ESA Credentials function key (EsaCredentialsFnKey):_______________

6. Navigate to Key Vault.

7. Under Objects, select Secrets > Generate/import.

8. Select Manual, type in secret name and use ESA Credentials function key value recorded in previous steps (EsaCredentialsFnKey) for Secret value.

9. Select Create.

10. Record Key Vault secret name.

    ESA Credentials function key secret name (EsaCredentialsFnKeySecretName):_______________

11. Navigate to Policy Agent function app.

12. Expand Settings menu item.

13. Select Environment Variables menu item.

14. Click Add button.

15. For Name use PTY_ESA_CREDENTIALS_FUNCTION_KEY_SECRET.

16. For Value use ESA Credentials function key secret name (EsaCredentialsFnKeySecretName) recorded in previous steps.

17. Hit Apply in Add/Edit application setting blade.

18. Hit Apply in App Settings tab.

Authorization Option 3: Configure ESA Credentials authentication provider to authorize Policy Agent system-assigned identity.

1. Navigate to Policy Agent function app

2. Expand Settings menu item

3. Select Identity

4. Select System assigned tab

5. Status should already be On

   Other Status indicates Policy Agent was installed without system-assigned identity. Before proceeding any further you need to either install Policy Agent with system-assigned identity or follow Option 4 which describes configuration steps for Policy Agent installed with user-assigned managed identity.

6. Copy Object (principal) ID

7. Navigate to ESA Credentials function app

8. Expand Settings menu item

9. Select Authentication

10. Select Add identity provider

    Review related Microsoft documentation

11. Select Microsoft in identity provider dropdown

12. For App registration type provide details of your choice

13. For Issuer URL accept the default value

14. For Client application requirement select Allow requests from any application

    Access will be limited to only the Policy Agent identity in the next step

15. For Identity requirement select Allow requests from specific identities

16. For Allowed identities add Object (principal) ID copied in previous step

17. For Restrict access select Require authentication

18. For Unauthenticated requests select HTTP 401 Unauthorized: recommended for APIs

19. Check Token store

20. Select Add

21. Click OK to apply constraint

22. Click Save

23. Navigate to Application of Microsoft identity provider

    A link to identity providers application is available under Authentication menu item of ESA Credentials function

24. Expand Manage menu item

25. Select Expose an API

26. Copy Application ID URI or select Add if it does not exist and Save to accept the default value

27. Record Application ID URI of identity provider

    ESA Credentials function Application ID URI (EsaCredentialsFnAppIdUri):_______________

28. Navigate to Policy Agent function app.

29. Expand Settings menu item.

30. Select Environment Variables menu item.

31. Click Add button.

32. For Name use PTY_ESA_CREDENTIALS_FUNCTION_SCOPE.

33. For Value use ESA Credentials function Application ID URI (EsaCredentialsFnAppIdUri) recorded in previous steps appended with /.default

    Review Microsoft identity platform default scope

34. Hit Apply in Add/Edit application setting blade.

35. Hit Apply in App Settings tab.

Authorization Option 4: Configure ESA Credentials authentication provider to authorize Policy Agent user-assigned identity.

1. Navigate to Policy Agent function app

2. Expand Settings menu item

3. Select Identity

4. Select User assigned tab

   User-assigned identity should already be provided. Missing user-assigned identity indicates Policy Agent was installed without user-assigned identity. Before proceeding any further you need to either install Policy Agent with user-assigned identity or follow Option 3 which describes configuration steps for Policy Agent installed with system-assigned managed identity.

5. Copy Client ID

6. Copy Object (principal) ID

7. Navigate to ESA Credentials function app

8. Expand Settings menu item

9. Select Authentication

10. Select Add identity provider

    Review related Microsoft documentation

11. Select Microsoft in identity provider dropdown

12. For App registration type provide details of your choice

13. For Issuer URL accept the default value

14. For Client application requirement select Allow requests from specific client applications

15. For Allowed client applications add Client ID copied in previous step

16. Click OK to apply constraint

17. For Identity requirement select Allow requests from specific identities

18. For Allowed identities add Object (principal) ID copied in previous step

19. Click OK to apply constraint

20. Click Save

21. Navigate to Application of Microsoft identity provider

    A link to identity providers application is available under Authentication menu item of ESA Credentials function

22. Expand Manage menu item

23. Select Expose an API

24. Copy Application ID URI or select Add if it does not exist and Save to accept the default value

25. Record Application ID URI of identity provider

    ESA Credentials function Application ID URI (EsaCredentialsFnAppIdUri):_______________

26. Navigate to Policy Agent function app.

27. Expand Settings menu item.

28. Select Environment Variables menu item.

29. Click Add button.

30. For Name use PTY_ESA_CREDENTIALS_FUNCTION_SCOPE.

31. For Value use ESA Credentials function Application ID URI (EsaCredentialsFnAppIdUri) recorded in previous steps appended with /.default

    Review Microsoft identity platform default scope

32. Hit Apply in Add/Edit application setting blade.

33. Hit Apply in App Settings tab.

Agent Function Key Vault Access Policies

Agent Function requires access to Key Vault created in Key Vault to encrypt policy and to access configuration secrets.

1. From Azure console navigate to Key Vaults, select the Key Vault created in Key Vault.
2. Select Access policies.
3. Click Create.
4. Select the following permissions in Permissions tab: a. Get under Key Management Operations. b. Wrap Key under Cryptographic Operations. c. Get under Secret Permissions.
5. For Principal provide function identity a. For functions with user-assigned identity enter identity recorded in step Agent Function User-Assigned Managed Identity b. For functions with system-assigned identity enter function name recorded in step Install Agent via ARM template
6. Proceed Next to Application and Next again to Review + Create.
7. Review permissions and Create.

Agent Function Outbound IP address

Agent Function App IP addresses may be useful for configuring ESA policy store and allowing traffic between Agent and ESA.

To obtain the list of Outbound IP addresses:

1. From Azure console navigate to Function App, select the Agent Function App.
2. Select Settings > Networking.
3. Under Outbound traffic configuration, select Show More next to Outbound addresses

Configure Function

Agent Function must be configured with parameters recorded in steps above.

To configure Function:

1. Open Function App service from the Azure console. Select the Function App created for policy agent in previous steps.

2. Navigate to Settings > Environment variables .

3. On the App Settings pane, click on Show values to reveal all configuration values

4. To modify multiple parameters, click the pencil icon Advanced edit at the top. Alternatively you may click on the environment variable name to edit single values.

5. Modify parameters according to the table below. If configuration has a default value you don’t have to change it

Protegrity-Protect-func1,Protegrity-Protect-func2

6. Click Apply at the bottom of the screen and then Confirm to save the changes.

Test Agent Function Installation

After configuration is complete you can test the function.

To test Agent function installation:

1. Navigate to Overview.

2. Select the function agent from the Functions tab.

3. Click Code + Test > Test/Run and then Run to execute the function.

4. You should see a 202 Accepted response.

5. Expand Logs output at the bottom of the page. Click Maximize to enlarge log output.

   Note

   It may take 1-2 minutes for the logs to begin populating in the console. Logging in the console is best effort and it is possible for the logs to be cut off. Navigate to Application Insights for full logs.

6. Below is an example log output from successful agent run.

   
   INFO:AZURE_SUBSCRIPTION_ID: [xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]
   INFO:AZURE_KEY_VAULT_NAME: [vault-name]
   INFO:AZURE_ENCRYPTION_KEY_ID: [https://vault-name.vault.azure.net/keys/key-name/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
   INFO:AZURE_RESOURCE_GROUP_NAME: [resource-group-name]
   INFO:AZURE_POLICY_BLOB_URL: [https://resource-group-name.blob.core.windows.net/policy/protegrity-policy-name.zip]
   INFO:AZURE_RETAIN_POLICY_BLOB: [3]
   INFO:PROTEGRITY_PROTECT_FUNCTION: [Protegrity-Protect-xxxx]
   INFO:DISABLE_DEPLOY: [0]
   INFO:PTY_ESA_IP: [xxx.xxx.xxx.xxx]
   INFO:PTY_SYNC_DATASTORE: []
   INFO:POLICY_PULL_TIMEOUT: [40]
   INFO:LOG_LEVEL: [info]
   INFO:PTY_CORE_EMPTYSTRING: [empty]
   INFO:PTY_CORE_CASESENSITIVE: [no]
   INFO:PTY_ADDIPADDRESSHEADER: [yes]
   INFO:Starting policy agent [4.0.3] ...
   INFO:ESA_CONNECTION_TIMEOUT: [60]
   INFO:Using ESA CA certificate from PTY_ESA_CA_SERVER_CERT environment variable.
   INFO:ResilientPackageClient initialized.
   INFO:Retrieving ESA rps version
   INFO:Resilient package correlation_id=[xxxxxxxxxxxxxxxxxxxxxxxxx] datastore=[]
   INFO:RPS Version: 1.9.2, Build: 1.9.2+1.g4bfba.1.9
   INFO:Checking ESA rps export availability
   INFO:Resilient package correlation_id=[xxxxxxxxxxxxxxxxxxxxxxxxx] datastore=[QA_DATA_STORE]
   INFO:Export available, Last-Modified: [Thu, 01 Jan 2026 00:00:00 GMT]
   INFO:Getting current policy metadata [https://resource-group-name.blob.core.windows.net/policy/protegrity-policy-name.zip] ...
   INFO:Last modified: [Thu, 01 Jan 2026 00:00:00 GMT], Last deployed: [Thu, 01 Jan 2026 00:00:00 GMT]
   WARNING:Current policy deployment has no checksum_mapping metadata:
   INFO:No changes in the policy since last download. Skipping policy deployment.
   INFO:Checking container for the last deployed policy [https://resource-group-name.blob.core.windows.net/policy]...
   INFO:[Protegrity-Protect-xxxx] current policy blob url: [https://resource-group-name.blob.core.windows.net/policy/2026-02-01_18-00-00/protegrity-policy-name.zip]
   INFO:Policy blob in sync for function [Protegrity-Protect-xxxx]
   INFO:[0] blobs are outside of the retention period [3]
   

7. If the log output in this window pauses or is difficult to read, you may navigate back to the Agent Function App overview and select Monitoring > Logs from the menu on the left. Run the query traces in the query editor to view logs.

Troubleshooting

To review the most recent invocation traces, navigate to the function app instance. Select Monitoring > Logs from the menu on the left. Run the query traces in the query editor to retrieve the full history of executions with detailed traces.

3.5 - Audit Log Forwarder Installation

The following sections provide installation steps for the Log Forwarder component in Azure. The Log Forwarder deployment allows for the audit logs generated by Protect Service to be delivered to ESA for auditing and governance purposes. Log Forwarder component is optional and is not required for the Protect Service to work properly. See Audit Log Forwarder Architecture for more information. Some of the installation steps are not required for the operation of the software but recommended for establishing a secure environment. Contact Protegrity for further guidance on configuration alternatives in the cloud.

ESA Audit Store Configuration

ESA server is required as the recipient of audit logs. Verify the information below to ensure ESA is accessible and configured properly.

1. ESA server running and accessible on TCP port 9200 (Audit Store) or 24284 (td-agent).

2. Audit Store service is configured and running on ESA. Applies when audit logs are output to Audit Store directly or through td-agent. For information related to ESA Audit Store configuration, refer to Audit Store Guide.

3. (Optional) td-agent is configured for external input. For more information related to td-agent configuration, refer to ESA guide Sending logs to an external security information and event management (SIEM).

Certificates on ESA

By default, ESA is configured with self-signed certificates, which can only be validated using self-signed CA certificate supplied in Log Forwarder configuration.

In case ESA is configured with publicly signed certificates, this section can be skipped since the Log Forwarder will use public CA to validate ESA certificates.

To obtain self-signed CA certificate from ESA:

1. Download ESA CA certificate from the /etc/ksa/certificates/plug directory of the ESA

2. After certificate is downloaded, open the PEM file in text editor and replace all new lines with escaped new line: \n.

   To escape new lines from command line, use one of the following commands depending on your operating system:

   Linux Bash:

   awk 'NF {printf "%s\\n",$0;}' CA.pem > output.txt
   

   Windows PowerShell:

   (Get-Content '.\CA.pem') -join '\n' | Set-Content 'output.txt'
   

3. Record the certificate content with new lines escaped.

   ESA CA Server Certificate (EsaCaCert): ___________________

   This value will be used to set PTY_ESA_CA_SERVER_CERT Log Forwarder variable in section Install Log Forwarder via ARM template

For more information about ESA certificate management refer to Certificate Management Guide in ESA documentation.

ESA Authentication

Audit Log Forwarder must authenticate with ESA using certificate-based authentication with client certificate and certificate key. Download the following certificates from the /etc/ksa/certificates/plug directory of the ESA:

• client.key
• client.pem

Both certificate and certificate key must be converted to single-line values using code similar to the following examples.

Client certificate (client.pem):

• Powershell
• Bash

$folder = 'C:\Temp'
cd $folder
(Get-Content "$folder\client.pem") -join '\n' | Set-Content "$folder\one-liner-client.pem"
cat "$folder\one-liner-client.pem"

folder="/tmp"
cd "$folder"
awk 'NF {printf "%s\\n",$0}' "client.pem" > "one-liner-client.pem"
cat "one-liner-client.pem"

Client certificate key (client.key):

• Powershell
• Bash

$folder = 'C:\Temp'
cd $folder
(Get-Content "$folder\client.key") -join '\n' | Set-Content "$folder\one-liner-client.key"
cat "$folder\one-liner-client.key"

folder="/tmp"
cd "$folder"
awk 'NF {printf "%s\\n",$0}' "client.key" > "one-liner-client.key"
cat "one-liner-client.key"

There are two options to configure Log Forwarder for certificate authentication:

• While installing using ARM template
  1. Provide single-line client certificate for Esa Client Cert
  2. Provide Azure Key Vault secret name for Esa Client Cert Key Secret Name which stores single-line certificate key file.
• When re-configuring after installation using environment variables
  1. Provide single-line client certificate for ESA_CLIENT_CERT
  2. Provide Azure Key Vault secret name for ESA_CLIENT_CERT_KEY_SECRET_NAME which stores single-line certificate key file.

Create Key Vault Secrets

Log Forwarder uses Key Vault as a secure store for certificate key file.

Create secret in Key Vault for certificate key file:

1. Navigate to Key Vault.

2. Under Objects, select Secrets > Generate/import.

3. Select Manual, type in secret name and specify single-line certificate key file value for Secret value.

4. Select Create.

5. Record secret name:

   ESA Client Cert Key Secret Name (EsaClientCertKeySecretName): ___________________

Function User-Assigned Managed Identity

User-assigned Azure managed identities are optional. If a user-assigned identity is not provided, a system-assigned managed identity will be enabled the function. User-assigned managed identities offer less frequent updates to Azure resources and allow for configuration of permissions ahead of function creation.

1. In the search box, enter Managed Identities. Under Services, select Managed Identities

2. Select Create

3. For Subscription provide recorded value of AzureSubscriptionID

4. For Resource Group provide recorded value of ApiResourceGroup

5. For Region provide recorded value of ApiRegion

6. For Name provide a name of the new identity

7. Assign following roles to this identity:

   • Storage Blob Data Owner
   • Monitoring Metrics Publisher
   • Azure Event Hubs Data Receiver

8. Record Forward function user-assigned identity

   Forward Function User-Assigned Identity (ForwardFuncUserAssignedIdentity): ____________________

Install Log Forwarder via ARM template

Resources created with ARM template include Function App, App Service Plan and Application Insights service. Optionally, a new Event Hub namespace and Event Hub instance can be created.

To install Log Forwarder via ARM template:

1. From Azure Console, select Create a resource, search for template and then select Template deployment > Create.

2. Select Build your own template in editor.

3. Select Load File and upload pty_forward_arm_v2.json. Click Save.

4. Select Resource Group.

5. Specify Name for the resources (All resources will be prefixed with Protegrity-Forward).

6. For Location input specify Azure region name or leave default to deploy in the same region as resource group

7. For Storage Account Blob Service Url Optionally use the value recorded in Create Storage Account. If value is not given, it will be automatically derived from Forward Function Blob Url.

8. For Forward Function Blob Url use the value from Upload Files.

9. For Function Sku either EP1 or EP3 are recommended. Note that this will affect the running cost.

10. For Function Sku Count Minimum number of workers to keep active.

11. For WorkSpace Sku Azure Monitor log analytics pricing plan. See Azure Monitor Pricing tiers documentation for details: Azure Monitor Pricing

12. For Log Retention In Days The workSpace data retention in days. Allowed values are per pricing plan. See Azure Monitor Pricing tiers documentation for details: Azure Monitor Pricing

13. For Forward Logs to ESA select whether to collect audit logs from a new or an existing Event Hub. A new Event Hub namespace and new Event Hub instance will be created for ‘From new Event Hub’ option.

14. For Audit Log Output select whether to send logs directly to Audit Store or td-agent on ESA

15. For Event Hub Namespace enter Event Hub namespace name. Depending on previous option, a new namespace with this name will be created or an existing namespace with this name will be used.

16. For New Event Hub Namespace Sku Name select Event Hub namespace SKU name. Applicable only when ‘From new Event Hub’ is selected.

17. For New Event Hub Namespace Sku Tier select Event Hub namespace SKU Tier used for new Event Hub namespace. Applicable only when ‘From new Event Hub’ is selected.

18. For New Event Hub Namespace Sku Capacity enter a value of Event Hub throughput units for Basic or Standard tiers, where value should be 0 to 20 throughput units. The Event Hubs premium units for Premium tier, where value should be 0 to 10 premium units. Applicable only when ‘From new Event Hub’ is selected.

19. For Event Hub Name enter Event Hub instance name. A new Event Hub instance with this name will be created or an existing Event Hub instance with this name will be used.

20. For Event Hub Name DLQ enter Event Hub name for the dead-letter queue, where messages will be delivered to in case connection to ESA is lost. A new Event Hub instance with this name will be created or an existing Event Hub with this name will be used.

21. For New Event Hub Partition Count enter number of partitions to create in a new Event Hub. Allowed values are from 1 to 32 partitions. Applicable only when ‘From new Event Hub’ is selected.

22. For New Event Hub Audit Log Retention In Days enter number of days audit logs will be available in Event Hub. Applies to both primary Event Hub and dead-letter queue Event Hub. Applicable only when ‘From new Event Hub’ is selected.

23. For Log Destination Esa Ip enter ESA IP address.

24. For Esa Client Cert enter single-line ESA client certificate. See section Certificate Authentication for details.

25. For Esa Client Cert Key Secret Name enter secret name which stores ESA client certificate single-line private key. See section Certificate Authentication for details.

26. For Key Vault Uri enter URI of the Key Vault that stores ESA username/password secrets.

27. For Esa Tls Disable Cert Verify Set to ‘0’ to enable ESA certificate validation. Set to ‘1’ to disable ESA certificate verification. Disable only for initial setup and development purposes, do not disable in production environments.

28. If ESA is configured with self-signed certificate, set Pty Esa Ca Server Cert. Use the ESA CA Server Certificate escaped content recorded in Certificates on ESA.

    Note that for development and troubleshooting purposes, ESA certificate validation can be disabled by either redeploying this function with this ARM template where Esa Tls Disable Cert Verify option is set to ‘1’ or by directly setting PTY_ESA_DISABLE_TLS_CERT_VERIFY environment variable to ‘1’.

29. For Esa Connect Timeout set time in seconds to wait for the ESA connection response. Minimum value: 1. Default: 5.

30. For Esa Virtual Host provide ESA virtual hostname. This configuration is optional. It can be used when proxy server is present and supports TLS SNI extension.

31. For Min Log Level select minimum log level. Accepted values: off, severe, warning, info, config, all

32. Select Review + create then Create. Wait for all resources to deploy

After deployment is complete:

1. Go to Outputs and record:

   Forward Function Name (ForwardFuncName):__________________

2. Record:

   Event Hub Name (EventHubName):__________________

   Event Hub Namespace (EventHubNamespace):__________________

Function System-Assigned Managed Identity

System-assigned Azure managed identity is enabled if user-assigned managed identity is not used. User-assigned managed identities offer less frequent updates to Azure resources and allow for configuration of permissions ahead of function creation.

If you have not created a user-assigned managed identity at Function User-Assigned Managed Identity, setup following role assignments for system-assigned managed identity:

1. Navigate to the function

2. Select Settings, Identity.

3. Confirm Status of system-assigned identity is already On on System Assigned tab

4. Click on Azure role assignments button.

5. Assign following roles to this identity:

   • Storage Blob Data Owner
   • Monitoring Metrics Publisher
   • Azure Event Hubs Data Receiver

6. From Azure console, navigate to Function App and select audit log forwarder function deployed in previous section.

7. Select Overview and click Restart button. Wait until function restart completes.

Update Function Key Vault Access Policies

The Key vault must be updated to allow the Function App to decrypt the policy files. The Forwarder is using policy to confirm the authenticity of audit logs it receives from Event Hub and to digitally sign the aggregated logs that it sends to ESA. Update the Key vault access policies with function identity. To update the key vault access policies:

1. From Azure console navigate to Key Vaults, select the Key Vault created in Key Vault.
2. Select Access policies.
3. Click Create.
4. Select the following permissions in Permissions tab: a. Get under Key Management Operations. b. Unwrap Key under Cryptographic Operations. c. Get under Secret Permissions.
5. Proceed Next to Principal.
6. For Principal provide function identity a. For functions with user-assigned identity enter identity recorded in step Function User-Assigned Managed Identity b. For functions with system-assigned identity enter function name recorded in step Install Log Forwarder via ARM template
7. Proceed Next to Application and Next again to Review + Create.
8. Review permissions and Create.

Test Log Forwarder Installation

Follow the steps to validate Log Forwarder installation. Successful Log Forwarder installation will aggregate logs, connect to ESA and send audit log events.

Testing in this section validates the connectivity between Log Forwarder and ESA. The sample policy included with the initial installation and test event below are not based on your ESA policy. Any logs forwarded to ESA which are not signed with a policy generated by your ESA will not be added to the audit store.

Install Log Forwarder and configure according to previous sections. Log Forwarder configuration MinLogLevel must be at least info level.

1. In the following command, replace ‘forwarder-function-name’ with your function name

2. In the following command, replace ‘forwarder-function-key’ with your function key

3. Run the command in PowerShell:

   
   $forwarderFunctionName='forwarder-function-name'
   $forwarderFunctionKey='forwarder-function-key'
   
   Invoke-WebRequest -UseBasicParsing -Uri "https://$forwarderFunctionName.azurewebsites.net/admin/functions/auditlogforwarder" `
   -Method POST `
   -Headers @{
     "x-functions-key" = $forwarderFunctionKey
   } `
   -ContentType "application/json" `
   -Body "{`"input`":`"{\`"additional_info\`":{\`"description\`":\`"Data unprotect operation was successful.\`",\`"request_id\`":\`"f0ffbbf8-ab5b-42b7-90f4-51db7443af77\`"},\`"cnt\`": 1,\`"correlationid\`": \`"clfwrqgme0021nj329mijk52w\`",\`"logtype\`": \`"Protection\`",\`"level\`": \`"SUCCESS\`",\`"origin\`": {  \`"hostname\`": \`"169.254.197.189\`",  \`"ip\`": \`"169.254.197.189\`", \`"time_utc\`": 1722941687},\`"protection\`": {\`"dataelement\`": \`"alpha\`", \`"operation\`": \`"Unprotect\`",\`"audit_code\`": 8,\`"policy_user\`": \`"test_user\`",\`"datastore\`": \`"SAMPLE_POLICY\`"},\`"process\`": {  \`"name\`": \`"N/A\`",  \`"id\`": \`"15\`",\`"thread_id\`": \`"2243954624\`",\`"user\`": \`"sbx_user1051\`", \`"platform\`": \`"Linux_x32\`"},\`"client\`": {\`"username\`":\`"sbx_user1051\`",\`"ip\`":\`"169.254.197.189\`"},\`"protector\`": {\`"family\`": \`"IAP Lambda\`",\`"version\`": \`"3.1.0\`",\`"vendor\`": \`"Cloud Protect\`",\`"pcc_version\`": \`"3.5.0.1\`", \`"core_version\`": \`"2.0.1\`"},\`"signature\`": { \`"key_id\`":\`"5f143892-bbe4-4794-b1f4-ed28ca2a077e\`", \`"checksum\`": \`"90BC9BF39354869BD4BC5381820D201797DF4AF53B5A7F5F3AE01EC607C41A6E\`"}}`"}"
   

   Note

   For Cloud API on Azure Government Cloud use the following URL: https://$forwarderFunctionName.azurewebsites.us/admin/functions/auditlogforwarder

   Note

   The Body content is a sample audit log. See Audit Logging for detail on audit log contents.

4. Run following query to see your function logs, allow for a few minutes for Azure to deliver the logs

   
   traces
   | project timestamp, message
   | where timestamp > ago(5m)
   

5. Test is successful if the logs contain the following entry:

   opensearch.0: All logs successfully send to destination
   

   If the log entry is not present, please consult the Troubleshooting section for common errors and solutions.

Update Protect Service With Event Hub details

In this section, Event Hub details will be provided to the Protect Service installation.

1. Navigate to the Protect function environment variables.

2. Set EVENTHUB_NAME to the output value recorded in Install Log Forwarder via ARM template.

3. Set EventHub__fullyQualifiedNamespace to the output value recorded in Install Log Forwarder via ARM template.

4. Apply and Confirm to apply the changes.

Update Policy Agent With Log Forwarder Function Target

Log Forwarder requires a Protegrity policy which is in sync with the Protector Service. This section will describe the steps to update the Policy Agent to include updating the Log Forwarder.

1. Navigate to the Policy Agent function created in Install Agent via ARM template

2. Select Settings > Environment variables > PROTEGRITY_PROTECT_FUNCTION

3. Edit the value for environment variable PROTEGRITY_PROTECT_FUNCTION to include the Log Forwarder function’s name in the comma separated list of function names.

4. Select Apply > Apply > Confirm to save the changes

5. Test Policy Agent installation as described in Test Agent Function Installation

Test Full Log Forwarder Installation

1. Install and configure Protegrity Agent, Protect Service and Log Forwarder components.
2. Set EVENT_LEVEL environment variable on Protect Service function to Informational.
3. Set PTY_LOG_LEVEL environment variable on both Protect Service function and Log Forwarder function to config.

Test Installation

1. Make a protect operation using a data element or user which will result in audit log generation

2. Navigate to the Logs for the Protect Service function

3. Execute ’traces’ query

4. Expect to see a log similar to the below:

   
   Completed publishing events for Event Hub: audit-logs (Partition Id/Key: '0'), Operation Id: 'e17bacd6-91e6-4fb5-8281-2929788bef09'. Service Retry Count: 0; Duration: '0.02' seconds
   

5. Navigate to the Logs for the Log Forwarder function

6. Execute ’traces’ query

7. Expect to see a log similar to the below:

   
   opensearch.0: All logs successfully send to destination
   

Troubleshooting

Configure additional logging for functions:

1. Set EVENT_LEVEL environment variable on Protect function to Informational.
2. Set PTY_LOG_LEVEL environment variable on both Protect function and Log Forwarder function to config.

Unhandled exception. System.Exception: Failed to initialize 
function type,expecting environment variable 
'AzureWebJobs.AuditLogForwarder.Disabled' 
to be set to either 'true' or 'false'

[2024/08/08 10:00:00] [error] [tls] error: unexpected EOF

Failed to aggregate audit logs, 1 audit logs dropped, error: 
The user, group or application 'appid=;oid=;iss=' does not have 
secrets get permission on key vault ';location='...
Status: 403 (Forbidden)
ErrorCode: Forbidden

TCP connection timed out: 001.001.001.001:9200

fail: Protect.Aggregate[0] Failed to aggregate audit logs, 
1 audit logs dropped, error: Invalid URI: The format of the URI 
could not be determined. 
info: iap[0] Shared memory segment POLICY does not exist: The 
system cannot find the file specified.

[Error] Azure-Messaging-EventHubs: An exception occurred while 
publishing a batch of events for buffered producer instance with 
identifier 'x' to Event Hub: audit-logs, Partition Id: '0', 
Operation Id: 'x'. Error Message: 'Unauthorized access.

3.6 -

Prerequisites

3.7 -

Required Skills and Abilities

3.8 -

4 - REST API

REST API

The following sections describe key concepts for understanding the REST API.

Base URL:

https://{ProtectFuncName}.azurewebsites.net/api

Substitute the Protect function name recorded during the Protect function installation.

https://{ProtectFuncName}.azurewebsites.us/api

4.1 - Export an OpenAPI Spec

Export an OpenAPI Spec

Once the Cloud API on Azure is installed, you can export the OpenAPI documentation file from:

https://{ProtectFuncName}.azurewebsites.net/api/v1/openapi

Authentication and functions key are required to get the URL.

https://{ProtectFuncName}.azurewebsites.us/api/v1/openapi

For testing the REST API, we recommend using a client tool, such as Postman.

4.2 - Payload Encoding

Payload Encoding

The following encoding formats are supported in the REST API.

For every encoding, the resultant protected data is returned in the same encoding. For example, if request is hex-encoded, the response is also hex-encoded.

For more information about the encoding formats, refer to the Protection Methods Reference.

4.3 - v1 Specification

Request

AWS Lambda service limits maximum size of payload to 6 MB. Client applications of Protegrity Cloud API must ensure their payload size is within this limit. This applies to all types of requests described below.

Performs a policy operation such as protect, unprotect, or reprotect.

• URI

  /v1/protect or /v1/unprotect or /v1/reprotect

• Method

  POST

• Parameters

  data: Input data to the policy operation.

  data_element: Data element to use for the policy operation.

  encoding: Optional, encoding of the data. One of: base64, base64_mime, base64_pem, base64_url, hex, or utf8. Defaults to hex for binary data elements, otherwise defaults to utf8.

  external_iv: Optional, external initialization vector.

  old_data_element: (reprotect) Data element for unprotecting the input.

  old_external_iv: (reprotect) Optional, external initialization vector for the input.

  query_id: Optional, identifier for the request.

  user: User performing the operation.

• Result

  Returns the output of the policy operation.

Example 1 - without external IV

{
  "encoding": "utf8",
  "query_id": "1",
  "user": "user1",
  "data_element": "Alphanum",
  "data":[<data1>,<data2>]
}

Example 2 - with external IV

{
  "encoding": "utf8",
  "query_id": "1",
  "user": "user1",
  "data_element": "Alphanum",
  "external_iv": "abc123",
  "data":[<data1>,<data2>]
}

Example 3 - reprotect

{
  "encoding": "utf8",
  "query_id": "1",
  "user": "user1",
  "data_element": "deName",
  "old_data_element": "Alphanum",
  "data":[<data1>,<data2>]
}

Performs policy operations using different data elements for each data set.

• URI

  /v1/protect or /v1/unprotect or /v1/reprotect

• Method

  POST

• Parameters

  encoding: Optional, encoding of the data. One of: base64, base64_mime, base64_pem, base64_url, hex, or utf8. Defaults to hex for binary data elements, otherwise defaults to utf8.

  query_id: Optional, prefix for the request identifier.

  user: User performing the operation.

  arguments[].data: Input data to the policy operation.

  arguments[].data_element: Data element to use for the policy operation.

  arguments[].external_iv: Optional, external initialization vector.

  arguments[].id: Optional, request identifier.

  arguments[].old_data_element: (reprotect) Data element for unprotecting the input.

  arguments[].old_external_iv: (reprotect) Optional, external initialization vector for the input.

Example 4 - multiple data elements support payload

{
  "encoding": "utf8",
  "query_id": "query1234", 
  "user": <policy_user>, 
  "arguments": [
    {
      "id": "1", 
      "external_iv": "<external iv>", 
      "data_element": "<data element name>", 
      "data":["<data1>","<data2>"]
    }, 
    {
      "data_element": <data element name>, 
      "data":["<data1>","<data2>"]
    }
  ]
}

• External IV

  The External IV feature provides an additional level of security by allowing different tokenized results across protectors for the same input data and token element, depending on the External IV set on each protector. External IVs must adhere to certain guardrails and not all data elements support External IV. To read more about the Tokenization model with External IV, refer to the External Initialization Vector (IV) chapter in the Protection Methods Reference.

Response

responsePayloadV1:
type: object
  properties:
    success:
      type: bool
    error_msg:
      type: string
      description: When success is false, error_msg is included
    results:
      type: array
      items:
        type: string

Example success:

{
  "encoding": "utf8", 
  "results":["str1","str2"], 
  "success": true
}

If the request was successful, the success flag will always be true.

Example failure:

{
  "error_msg": "token expired", 
  "success": false
}

If the request fails, the success flag will always be false.

Multi Data Elements Support Payload

responsePayloadV2:
type: object
  properties:
    success:
      type: boolean
    results:
      type: array
        items:
          type: object
          properties:
            success:
              type: bool
            error_msg:
              type: string
              description: When success is false, error_msg is included
            id:
              type: string
              description: When id is sent in the request payload, id is included in the response
            results:
              type: array
              items:
                type: string

Example success:

{
  "encoding": "utf8", 
  "results":[
    {
      "encoding": "utf8", 
      "results":["str1","str2"], 
      "success": true
    }, 
    {
      "encoding": "utf8", 
      "results":["str1","str2"], 
      "success": true
    }
  ], 
  "success": true
}

If the all the subrequests were successful, the success flag will be true.

Example failure:

{
  "results": [
    {
      "error_msg": 
      "Protect failed. Data element not found. Refer to audit log for details", 
      "success": false
    }, 
    {
      "encoding": "utf8", 
      "results":["str1","str2"], 
      "success": true
    }
  ], 
  "success": false
}

It is possible to have a mix of successful and unsuccessful results. In this case, the global success flag will be false.

4.4 - Legacy Specification

Protegrity has multiple products with REST API capabilities, such as Protection Server (out of support), DSG, and the latest product - IAP REST. Each one has its use case. To help you move to cloud-native implementation, Cloud Product REST API supports legacy payload.

• Request
• Response

Request

Performs a policy operation such as protect, unprotect, or reprotect.

• Method

  POST

• Parameters

  dataelementname: (protect/unprotect) Data element to use for the policy operation.

  externaliv: (protect/unprotect) Optional, external initialization vector.

  newdataelementname: (reprotect) Data element to use for the output.

  newexternaliv: (reprotect) Optional, external initialization vector for the output.

  olddataelementname: (reprotect) Data element to use for the input.

  oldexternaliv: (reprotect) Optional, external initialization vector for the input.

  policyusername: User performing the operation.

  bulk.id: Optional, identifier for the request.

  bulk.data[].content: Input data to the policy operation.

• Result

  Returns the output of the policy operation.

Example 1 - protect without external IV

{
  "protect": {
    "policyusername": "user1",
    "dataelementname": "Alphanum",
    "bulk": {
      "id": "1",
      "data": [
        {
          "content": <Data encoded in base64>
        }
      ]
    }
  }
}

Example 2 - protect with external IV

{
  "protect": {
    "policyusername": "user1",
    "dataelementname": "Alphanum",
    "externaliv": "abc123",
    "bulk": {
      "id": "1",
      "data": [
        {
          "content": <Data encoded in base64>
        }
      ]
    }
  }
}

Example 3 - unprotect

{
  "unprotect": {
    "policyusername": "user1",
    "dataelementname": "Alphanum",
    "bulk": {
      "id": "1",
      "data": [
        {
          "content": <Data encoded in base64>
        }
      ]
    }
  }
}

Example 4 - reprotect

{
  "reprotect": {
    "policyusername": "user1",
    "newdataelementname": "deName",
    "olddataelementname": "Alphanum",
    "bulk": {
      "id": "1",
      "data": [
        {
          "content": <Data encoded in base64>
        }
      ]
    }
  }
}

Response

Example:

{"protect":{"bulk":{"returntype":"success","data":[{"returntype":"success","message":"Data
 protection was successful.","content":"RGZBUFR4ODAzejFwNjQ5TWg0TEFpcFNqbA=="},{"returntype":"success",
"message":"Data protection was successful.","content":"aHNnVVB5QWFDYw=="}]}}}

4.5 - SSL Certificates

SSL Certificates

By default, the Azure function app function support HTTPS.

To setup SSL Certificates in the Protect Function App please go to the following Azure documentation link:

App Service, Configure SSL Certificate

5 - Performance

5.1 - Function App Performance

Function App Performance

Overview

Azure Function apps offer different hosting plans that directly impact the performance, scalability, and cost of Cloud Protect deployments. Understanding these plans and their characteristics is essential for optimizing your data protection operations.

Azure Function App Service Plans

Azure Functions provides several hosting options, each with different characteristics:

Consumption Plan

The Consumption plan provides automatic scaling and charges only for compute resources used during function execution. While cost-effective for sporadic workloads, this plan has limitations:

• Cold start latency: Functions may experience delays when starting after periods of inactivity
• Limited execution time: Maximum execution duration of 10 minutes per function invocation
• Shared infrastructure: Resources are shared across tenants, which can lead to variable performance
• Memory constraints: Limited to 1.5 GB of memory per instance

Premium Plan (Recommended)

The Premium plan is the recommended option for Cloud Protect on Azure. It provides enhanced performance and enterprise-grade features:

• Pre-warmed instances: Always-ready instances eliminate cold start delays, ensuring consistent performance
• Enhanced compute resources: Flexible compute sizing, see App Service Premium version 3 plan
• VNET integration: Secure connectivity to on-premises resources and Azure private networks
• Unlimited execution duration: No time limits for long-running protection operations
• Predictable performance: Dedicated infrastructure ensures consistent throughput
• Better scaling control: Minimum and maximum instance count configuration

Elastic Premium Plan (Recommended)

The Elastic Premium plan extends the Premium plan with additional elasticity and performance optimization:

• Rapid scale-out: Faster scaling response to demand spikes
• Greater instance limits: Support for larger-scale deployments
• Optimized cold start: Even faster initialization compared to standard Premium
• Event-driven scaling: More granular scaling based on event sources
• All Premium features: Includes VNET integration, pre-warmed instances, and unlimited execution time

Cloud Protect Recommendations

Cloud Protect on Azure recommends using either Premium or Elastic Premium plans for production deployments. These plans provide:

1. Consistent Performance: Pre-warmed instances ensure data protection operations execute immediately without cold start delays
2. Sufficient Resources: Memory and CPU resources adequate for cryptographic operations and high-volume data processing
3. Reliability: Dedicated infrastructure for predictable performance and SLA compliance
4. Security: VNET integration enables secure communication with ESA (Enterprise Security Administrator) and other protected resources
5. Scalability: Automatic scaling handles variable workloads while maintaining performance standards

Performance Considerations

When deploying Cloud Protect on Azure Functions, consider the following factors:

Instance Sizing

Select appropriate instance sizes based on your workload:

• EP1 (Elastic Premium 1): 1 vCPU, 3.5 GB RAM - suitable for moderate workloads
• EP2 (Elastic Premium 2): 2 vCPU, 7 GB RAM - recommended for standard production deployments
• EP3 (Elastic Premium 3): 4 vCPU, 14 GB RAM - for high-volume or resource-intensive operations

Scaling Configuration

Configure scaling parameters to match your protection requirements:

• Minimum instances: Set to at least 1-2 pre-warmed instances to eliminate cold starts
• Maximum instances: Configure based on peak load expectations and budget constraints
• Scale-out rules: Define appropriate triggers based on CPU, memory, or queue depth metrics

Network Considerations

• Use VNET integration to reduce latency when communicating with ESA servers
• Enable private endpoints for secure, high-performance connectivity to Azure services (Storage, Key Vault)
• Consider proximity placement to co-locate Function apps with dependent resources

Monitoring and Optimization

• Monitor execution duration metrics to identify bottlenecks
• Track instance count and scaling patterns to optimize configuration
• Review memory and CPU utilization to right-size your plan
• Set up Application Insights for detailed performance telemetry and diagnostics

Cost vs. Performance Trade-offs

While Premium and Elastic Premium plans have higher baseline costs compared to Consumption, they provide:

• Predictable performance and cost structure
• Reduced total cost for steady-state workloads (no per-execution charges)
• Better resource utilization through persistent instances
• Lower operational overhead from consistent behavior

For Cloud Protect deployments handling sensitive data with compliance requirements, the Premium/Elastic Premium investment ensures reliable, performant data protection operations.

5.2 - Log Forwarder Performance

Log Forwarder Performance

Log forwarder architecture is optimized to minimize the amount of connections and reduce the overall network bandwidth required to send audit logs to ESA. This is achieved with batching and aggregation taking place on two levels.

The first level is in protect function instances, where audit logs from consecutive requests to an instance are batched and aggregated. The second level of batching takes place in Azure Event Hub instance where log records from different protect function instances are additionally batched and sent to log forwarder function where they are aggregated.

These sections show how to configure the deployment to accommodate different patterns of anticipated audit log stream. It also shows how to monitor deployment resources to detect problems so that audit records are not lost.

Protect Service Function Environment Variables

• PTY_CORE_FLUSHINTERVAL: Defines for how long audit logs are aggregated before they are sent to Azure Event Hub. Default value is ten seconds. Audit logs are always aggregated into one minute buckets, therefore a value greater than sixty seconds will affect mostly the batching interval.

• MAX_WAIT_TIME: Defines for how long aggregated audit logs are batched before they are sent to Azure Event Hub. Default value is ten seconds.

  Increasing MAX_WAIT_TIME may result in:

  1. Increased latency or lag of audit logs arriving to Event Hub and therefore ESA

  2. Increased throughput rates due to fewer network requests overall

  3. Increased aggregation rates for values up to one minute Lowering MAX_WAIT_TIME may result in:

  4. Reduced latency or lag for audit logs to arrive to Event Hub and therefore ESA

  5. Reduced throughput rates due to higher number of network requests overall

  6. Reduced aggregation rates for values up to one minute It is not recommended to set MAX_WAIT_TIME lower in production workloads as it may overload the Event Hubs service. Lowering MAX_WAIT_TIME may be beneficial for speeding up log delivery to ESA in dev/test environments.

Log Forwarder ARM Template Parameters

• New Event Hub Namespace Sku Name and New Event Hub Namespace Sku Tier directly affect the quotas applied to new Event Hub instances. Review Azure Event Hub Quotas related to selected tier in Azure documentation: Azure Event Hub Quotas
• New Event Hub Namespace Sku Capacity: Event Hubs throughput units for Basic or Standard tiers, where value should be 0 to 20 throughput units. The Event Hubs premium units for Premium tier, where value should be 0 to 10 premium units. Capacity directly controls the purchased throughput of Event Hub instance. Review details in Azure documentation: Event Hub Instance Throughput
• New Event Hub Partition Count: The number of partitions represents the level of parallel log streams in the Event Hub. It is proportional to throughput capacity of the Event Hub instance. If the number of partitions is too low and the volume of audit logs is too high, a throughput ceiling may be reached on Event Hub and some audit records sent from protect function may be lost. Review details in Azure documentation: Event Hub Scalability
• New Event Hub Audit Log Retention In Days: Number of days audit logs are to be available in Event Hub. Applies to both primary Event Hub instance and dead-letter queue Event Hub instance. While audit logs are processed by Log Forwarder in near-realtime, it may be beneficial to keep audit logs available in Event Hub for extended period in case Log Forwarder or ESA require maintenance.
• Event Hub Name DLQ: Dead-letter Queue Event Hub name. This Event Hub will be used by Log Forwarder in case ESA is temporarily unavailable. Messages from DLQ Event Hub can be re-processed by another instance of Log Forwarder either manually or on schedule once ESA connectivity is restored.

Monitoring Log Forwarder Performance

• Azure Event Hub Metrics: Any positive value in ‘Throttled Requests’ metric indicates that audit logs rate from protect function is too high. The recommended actions may include:

  • Increase aggregation and batching intervals of Protect function by increasing values of PTY_CORE_FLUSHINTERVAL and MAX_WAIT_TIME
  • Increase number of partitions for Event Hub
  • Purchase additional capacity units for Event Hub
  • Use a higher Event Hub namespace tier

• Azure Event Hub Metrics for DLQ Event Hub: Any positive value in ‘Incoming Messages’ metric indicates that not all audit logs are being delivered to ESA. Review whether connection to ESA is set up in Audit Log Forwarder Installation

• Protect Function Logs: If protect function is unable to send logs to Event Hub, it will log the following message:

  Failed to forward {n} events to Event Hub
  

• Count number of protect operations: Query logs in Log Analytics workspace of Protect Service or Log Forwarder functions:

  traces
  | where timestamp >= ago(20h)
  | where message has 'additional_info'
  | parse message with * "cnt\":" Count: long *  ",\"correlation" *
  | summarize count_sum = sum(Count)
  

• View number of function instances on a graph: Query logs in Log Analytics workspace of Protect Service or Log Forwarder functions:

  requests
  | summarize InstanceCount = dcount(cloud_RoleInstance) by bin(timestamp, 1s)
  | where timestamp >= ago(2h)
  | order by timestamp desc
  | render timechart
  

6 - Audit Logging

Audit Logging

Audit records and application logs stream to Azure Storage Account. Cloud Protect uses a JSON format for audit records that is described in the following sections.

You can analyze and alert on audit records using Protegrity ESA or Azure Application Insights. For more information about forwarding your audit records to ESA, contact Protegrity. Azure Application Insights contains only a sample of the audit records. The complete audit records are written to Azure Storage Account. For more information about Azure Application Insights,, refer to the Azure Application Insights overview.

For more information about audit records, refer to the Protegrity Analytics Guide.

Audit record fields

The audit record format has been altered in version 3.1 of the protector to provide more information.

Example Audit Records

The following are sample audit messages:

Protect Success:

{
      "additional_info": {
        "deployment_id": "Protegrity-Protect-function-deployment-id",
        "description": "Data protect operation was successful.",
        "query_id": "sf-query-id:01978dbc-0582-d7e4-0000-002a3603a20d",
        "request_id": "8476a536-e9f4-11e8-9739-2dfe598c3fcd"
      },
      "cnt": 4000,
      "correlationid": "sf-query-id:01978dbc-0582-d7e4-0000-002a3603a20d",
      "logtype": "Protection",
      "level": "SUCESS",
      "origin": {
        "hostname": "localhost",
        "ip": "127.0.0.1",
        "time_utc": 1635363966
      },
      "protection": {
        "dataelement": "deAddress",
        "operation": "Protect",
        "audit_code": 6,
        "datastore": "SAMPLE_POLICY",
        "policy_user": "test_user"
      },
      process":{
        "name":"protect",
        "id":"13",
        "module":"coreprovider",
        "thread_id":"573580544",
        "user":"sbx_user1051",
        "platform":"\"Linux_x64\"",
        "version":"UNKNOWN"
      },
      "client": {
        "ip":"169.254.62.117"
      },
      "protector": {
        "family": "cp",
        "version": "4.0.0.102",
        "vendor": "aws.snowflake",
        "datastore":"SAMPLE_POLICY",
        "pcc_version": "4.0.0.9",
        "core_version": "2.1.4+0.g93016.2.1",
        "lambda_version":"4.0.1"
      },
      "signature": {
        "key_id": "95f5a194-b0a4-4351-a",
        "checksum": "B324AF7C56944D91C47847A77C0367C594C0B948E7E75654B889571BD4F60A71"
      }
    }

User permission denied:

{
      "additional_info": {
        "deployment_id": "Protegrity-Protect-function-deployment-id",
        "description": "The user does not have the appropriate permissions to perform the requested operation.",
        "query_id": "sf-query-id:01978dbc-0582-d7e4-0000-002a3603a20d",
        "request_id": "8476a536-e9f4-11e8-9739-2dfe598c3fcd"
      },
      "cnt": 4000,
      "correlationid": "sf-query-id:01978dbc-0582-d7e4-0000-002a3603a20d",
      "logtype": "Protection",
      "level": "ERROR",
      "origin": {
        "hostname": "localhost",
        "ip": "127.0.0.1",
        "time_utc": 1635363966
      },
      "protection": {
        "dataelement": "deAddress",
        "operation": "Protect",
        "audit_code": 3,
        "datastore": "SAMPLE_POLICY",
        "policy_user": "test_user"
      },
      process":{
        "name":"protect",
        "id":"13",
        "module":"coreprovider",
        "thread_id":"573580544",
        "user":"sbx_user1051",
        "platform":"\"Linux_x64\"",
        "version":"UNKNOWN"
      },
      "client": {
        "ip":"169.254.62.117"
      },
      "protector": {
        "family": "cp",
        "version": "4.0.0.102",
        "vendor": "aws.snowflake",
        "datastore":"SAMPLE_POLICY",
        "pcc_version": "4.0.0.9",
        "core_version": "2.1.4+0.g93016.2.1",
        "lambda_version":"4.0.1"
      },
      "signature": {
        "key_id": "95f5a194-b0a4-4351-a",
        "checksum": "A216797C56944D91C47847A77C0367C594C0B948E7E75654B889571BD4F60A71"
      }
    }

Data element not found:

{
      "additional_info": {
        "deployment_id": "Protegrity-Protect-function-deployment-id",
        "description": "The data element could not be found in the policy.",
        "query_id": "sf-query-id:01978dbc-0582-d7e4-0000-002a3603a20d",
        "request_id": "8476a536-e9f4-11e8-9739-2dfe598c3fcd"
      },
      "cnt": 4000,
      "correlationid": "sf-query-id:01978dbc-0582-d7e4-0000-002a3603a20d",
      "logtype": "Protection",
      "level": "ERROR",
      "origin": {
        "hostname": "localhost",
        "ip": "127.0.0.1",
        "time_utc": 1635363966
      },
      "protection": {
        "dataelement": "deAddress",
        "operation": "Protect",
        "audit_code": 2,
        "datastore": "SAMPLE_POLICY",
        "policy_user": "test_user"
      },
      process":{
        "name":"protect",
        "id":"13",
        "module":"coreprovider",
        "thread_id":"573580544",
        "user":"sbx_user1051",
        "platform":"\"Linux_x64\"",
        "version":"UNKNOWN"
      },
      "client": {
        "ip":"169.254.62.117"
      },
      "protector": {
        "family": "cp",
        "version": "4.0.0.102",
        "vendor": "aws.snowflake",
        "datastore":"SAMPLE_POLICY",
        "pcc_version": "4.0.0.9",
        "core_version": "2.1.4+0.g93016.2.1",
        "lambda_version":"4.0.1"
      },
      "signature": {
        "key_id": "95f5a194-b0a4-4351-a",
        "checksum": "AF09217C56944D91C47847A77C0367C594C0B948E7E75654B889571BD4F60A71"
      }
    }

7 - No Access Behavior

No Access Behavior

The security policy maintains a No Access Operation, configured in an ESA, which determines the response for unauthorized unprotect requests.

The following table describes the result returned in the response for the various no access unprotect permissions.

8 - Upgrading To The Latest Version

Upload Deployment Artifacts

You can download the latest version of the deployment package from https://my.protegrity.com. Navigate to Data Protection > Cloud Protect to download the latest version.

After downloading the deployment package from the Protegrity Portal, go to Azure console. Navigate to the storage account that was previously created to upload deployment artifacts (see: Agent Policy Blob Container).

Upload the following artifacts to the Azure storage container:

• protegrity-protect-<version>.zip
• protegrity-agent-<version>.zip

After upload is complete, note the blob url for each file. Blob URL may be found in the blob properties.

Record Blob URL values below

New Protect Function Blob URL: ___________________

New Log Forwarder Function Blob URL: ___________________

New Agent Function Blob URL: ___________________

Perform the following steps to upgrade the Policy Agent, Protect, and Log Forwarder Functions separately.

Disable Protegrity Agent Function Timer Trigger

App Function Timer Trigger is used to periodically run Protegrity Agent Function to synchronize policy from ESA. The trigger must be disabled temporarily for the time of the upgrade process.

Follow the steps below to disable the Agent Function Timer Trigger.

1. From Azure Console, go to Function App service and select Protegrity Agent Function.

2. Navigate to Overview.

3. The functions list should contain agent function with Trigger type Timer and status Enabled.

4. Click on the three dots in the same row as the agent function. Then select Disable.

Upgrading Policy Agent Function

Upgrade Policy Agent Runtime Package

1. From Azure console, navigate to Function App service and select agent function app. Navigate to Settings > Environment variables.

2. Click on WEBSITE_RUN_FROM_PACKAGE configuration entry.

3. Save existing URL. You may need it to rollback upgrade.

   WEBSITE_RUN_FROM_PACKAGE: _______________

4. Replace URL with New Agent Function Blob URL.

5. Click Apply then select Apply and Confirm to finalize.

6. Using menu on the left, navigate to Overview. Stop the function using Stop button at the top. Then start it again.

7. In the next section the Agent function will be tested to make sure it works as expected.

8. (Optional) If you need to rollback to older version of Agent Function, replace WEBSITE_RUN_FROM_PACKAGE with URL recorded in previous steps.

Disable Agent Policy Deployment and Test Policy Agent Function

Policy agent generates a backup of pulled policy when triggered. The policy will then be deployed to Protect and Log Forwarder functions. Deployment of policies to functions should be disabled during the upgrade process.

Follow the steps below to disable policy deployment:

1. From Azure Console, navigate to Policy Agent Function App

2. Navigate to Settings > Environment variables.

3. set DISABLE_DEPLOY to 1 if it is not already set.

   Note

   This will prevent Agent from overwriting production policy files or their references in deployed functions.

4. Stop/Start the Agent function. It may take a few minutes for the function to start.

Test/Run Policy Agent Function to Generate Latest Policy

Follow the steps below to run the upgraded policy agent to refresh latest backup policy. Record the latest backup policy URL for later upgrade steps.

1. From Azure Console, navigate to the Policy Agent Function App

2. Navigate to the agent Test/Run feature as described in Test Agent Function Installation.

3. Run the policy agent. Verify the agent executed successfully by carefully inspecting the logs.

4. Use the following Azure Blob url from your Policy Agent Function Settings > Environment variables

   AZURE_POLICY_BLOB_URL
   

   Note

   If resources are deployed in gov cloud, use blob.core.usgovcloudapi.net domain

   upgraded_agent_policy_blob_url: _______________________

Upgrading Protect Function

Diagram below illustrates upgrade steps.

• Create Staging Deployment Slot Creating new deployment slot allows updating the function without interruptions to the existing traffic.

• Load Production Policy and Test New Protect Function In Staging

• Finalize Protector upgrade Upgraded Protect Function can now be swapped in to production deployment slot to serve production traffic.

Create Staging Deployment Slot (Protector)

Creating new deployment slot allows updating the function without interruptions to the existing traffic.

1. From Azure console, navigate to Function App service and select the Protect Function App to upgrade. Navigate to Deployments > Deployment Slots.

2. Click Add slot. Specify slot name.

3. Click Add. Wait for the slot to be created.

4. After the slot is added, select Close to close the dialog box.

5. There should be a new slot available in the list of deployment slots. You will use this deployment slot as staging for the upgraded function. After upgrade is done and tested, you will swap staging slot with production slot.

6. Click on the new deployment slot. This will open the newly created replica of Cloud Protect Function.

7. Copy the function URL from the overview window.

   Staging Protect Function URL: ________________

8. Navigate to Identity section under Settings.

9. If your installation utilizes System Assigned Identity:

   1. Select System Assigned tab and switch Status On. Click Save.

   2. This will generate the Object ID for the newly deployed function in the deployment slot.

   3. Add Role Assignments to the identity as described in section Function System-Assigned Managed Identity

      Tip

      Reference production function slot for current permissions.

   4. Use the Object ID to update Key Vault policy to allow function in the deployment slot to use policy encryption key. See Protect Function Key Vault Access Policies for instructions how to update Key Vault policy.

10. If your installation utilizes User Assigned Identity:

    1. Select User Assigned tab

    2. Select Add. Choose the identity in use on the production function, then complete by selecting Add again.

11. Navigate to App Keys section from the menu on the left. Record default key value under Host Keys section.

    Staging Protect Function Default Host Key: ________________

12. Navigate to the staging Function App Settings > Environment variables

13. Click on WEBSITE_RUN_FROM_PACKAGE configuration entry.

14. Replace value with New Protect Function Blob URL.

15. Set EVENTHUB_NAME to the output value recorded in Install Log Forwarder via ARM template for the newly deployed log forwarder.

16. Set EventHub__fullyQualifiedNamespace to the output value recorded in Install Log Forwarder via ARM template.

17. Click Apply, then Apply to finalize.

Load Production Policy and Test New Protect Function In Staging

1. Navigate to the new staging Protect function Settings > Environment variables

2. Set AZURE_POLICY_BLOB_URL environment variable to the upgraded_agent_policy_blob_url value recorded in previous steps.

3. Start/Stop the protect function.

4. Test New Protect Function in staging. You can use curl command below, replacing Staging Protect Function URL and Staging Protect Function Default Host Key with values recorded in previous section.

• Snowflake
• Cloud API

curl -X POST "<Staging Protect Function URL>/api/Protect" -k \
-H 'sf-custom-X-Protegrity-HCoP-Rules: {"jsonpaths":[{"op_type":"unprotect","data_element":"alpha"}]}' \
-H 'sf-context-current-user: test' \
-H 'sf-external-function-current-query-id: test-id' \
-H 'x-functions-key: <Staging Protect Function Default Host Key>' \
-H 'Content-Type: application/json' \
-d '{
  "data": [
    ["0", "UtfVk UHgcD!"]
  ]
}'

curl -X POST "<Protect Function URL>/api/v1/protect" -k \
-H 'x-functions-key: <Protect Function app key>' \
-H 'Content-Type: application/json' \
-d '{
  "data": ["test"],
  "user": "test",
  "data_element": "test"
}'

Finalize Protector upgrade

Upgraded Protect Function can now be swapped in to production deployment slot to serve production traffic.

1. Go to your main Protect Function.

2. Select deployment slots.

3. Select Swap.

4. Select staging Protect Function slot as source and production Function as target.

5. Click swap and wait until the functions are swapped.

6. If you need to rollback swap the application slots again.

Upgrading Log Forwarder Function

Disable Log Forwarder Event Hub Trigger

Disabling the Event Hub trigger will prevent audit log delivery during the upgrade process. This reduces the chance for any duplicate or lost audit logs. Later steps will indicate when this trigger may be re-enabled.

Follow the steps below to disable the Event Hub trigger:

1. From Azure Console, go to Function App service and select Protegrity Log Forwarder Function.

2. Navigate to Overview.

3. The functions list should contain AuditLogForwarder function with Trigger type Event Hub and Status Enabled.

4. Click on the three dots in the same row as the AuditLogForwarder function. Then select Disable.

Create Staging Deployment Slot (Log Forwarder)

Creating new deployment slot allows updating the function such that it may easily be rolled back. Log Forwarder Function will be disabled during the upgrade process. Logs generated during this time will be processed once Log Forwarder is re-enabled

1. From Azure console, navigate to Function App service and select the Log Forwarder Function App to upgrade. Navigate to Deployments > Deployment Slots.

2. Click Add slot. Specify slot name.

3. Click Add. Wait for the slot to be created.

4. After the slot is added, select Close to close the dialog box.

5. There should be a new slot available in the list of deployment slots. You will use this deployment slot as staging for the upgraded function. After upgrade is done, you will swap staging slot with production slot.

6. Click on the new deployment slot. This will open the newly created replica of Log Forwarder Function.

7. Navigate to the staging Function App environment variable settings Settings > Environment variables

8. Click on WEBSITE_RUN_FROM_PACKAGE configuration entry.

9. Replace value with New Log Forwarder Function Blob URL. Click Apply.

10. Click on AZURE_POLICY_BLOB_URL configuration entry.

11. Replace value with upgraded_agent_policy_blob_url. Click Apply.

12. Click Apply and Confirm to push the configuration changes.

Finalize Log Forwarder Upgrade

Upgraded Log Forwarder Function will be swapped into production deployment slot to serve production traffic and re-enabled,

• Swap Upgraded Function Slot to Production

• Re-Enable Log Forwarder Function Trigger

Swap Upgraded Function Slot to Production

1. Go to your main Log Forwarder Function.

2. Select deployment slots.

3. Select Swap.

4. Select staging Log Forwarder Function slot as source and current Function as target.

5. Click Start Swap and wait until the functions are swapped.

6. If you need to rollback, swap the application slots again.

Re-Enable Log Forwarder Function Trigger

1. Go to your main Log Forwarder Function.

2. Navigate to environment variable settings Settings > Environment variables

3. Click on AzureWebJobs.AuditLogForwarder.Disabled configuration entry.

4. Replace value with false. Click Apply then Apply and Confirm to finalize.

Re-enable Policy Agent Deployment Setting

Skip this step if changes were not made to the DISABLE_DEPLOY setting in previous upgrade steps

1. Navigate to Agent function Settings > Environment variables

2. Set DISABLE_DEPLOY to 0.

3. apply changes and restart the Agent Function App

Enable Protegrity Agent Function Timer Trigger

If the Agent Function Timer Trigger was disabled at the beginning of the upgrade process, you must re-enabled it. Follow the steps below to enable Policy Agent Timer Trigger.

1. Navigate back to Protegrity Agent Function.

2. Select Overview.

3. Click on the three dots in the same row as the agent function in the list of functions. Then select Enable.

9 - Known Limitations

• FPE is supported only for ASCII values.

10 - Appendices

10.1 - Integrating Cloud Protect with PPC (Protegrity Provisioned Cluster)

This guide describes how to configure the Protegrity Policy Agent and Log Forwarder to connect to a Protegrity Provisioned Cluster (PPC), highlighting the differences from connecting to ESA.

Key Differences: PPC vs ESA

Prerequisites

• Access to PPC and required credentials.
• Tools: curl, kubectl installed.

Policy Agent Setup with PPC

Follow these instructions as a guide for understanding specific inputs for Policy Agent integrating with PPC:

1. Obtain the Datastore Key Fingerprint

   To retrieve the fingerprint for your Policy Agent:

   1. Retrieve public key from the Cloud Provider Key Management service for the policy encryption key created in pre-configuration:

      • AWS
      • Azure
      • GCP
      1. Navigate to the Key Management Service in AWS console and open Customer Managed Keys
      2. Select the desired key
      3. Select the Public Key tab
      4. Select Download

      1. Navigate to the Key Vault in Azure console and open Objects>Keys
      2. Select the desired key
      3. Select the key indicated as CURRENT VERSION
      4. Select Download public key

      1. Navigate to Key Management in GCP console
      2. Select the desired key and open the Versions tab
      3. Select Get public key from the Actions column menu
      4. Select Download

   2. Escape the new line characters in the downloaded public key for use in the next step - for example:

      awk 'NF {printf "%s\\n",$0}' "<public_key_file>" > "new-line-escaped-public-key.pem"
      cat new-line-escaped-public-key.pem
      

   3. Export key fingerprint using the PPC API as indicated in the curl example below:

      curl -k -H "Authorization: Bearer ${TOKEN}" -X POST https://${HOST}/pty/v2/pim/datastores/1/export/keys  -H "Content-Type: application/json" --data '{
        "algorithm": "RSA-OAEP-256",
        "description": "example-key-from-key-management",
        "pem": "<value of new-line-escaped-public-key>"
      }'
      

      Sample Output:

      {"uid":"1","algorithm":"RSA-OAEP-256","fingerprint":"4c:46:d8:05:35:2e:eb:39:4d:39:8e:6f:28:c3:ab:d3:bc:9e:7a:cb:95:cb:b1:8e:b5:90:21:0f:d3:2c:0b:27","description":"example-key-from-kms"}
      

      Note

      Alternatively, set using the PPC CLI utility. See the export key example in Create Datastores Key

   4. Record the value for fingerprint and configure the Policy Agent:

      • AWS
      • Azure
      • GCP

      Set the environment variable PTY_DATASTORE_KEY in the Policy Agent Lambda function to the fingerprint value.

      Set the environment variable PTY_DATASTORE_KEY in the Policy Agent Function App to the fingerprint value.

      Set the variable in Policy Agent main.tf pty_datastore_key to the fingerprint value and apply the changes.

2. Retrieve the PPC CA Certificate

   To obtain the CA certificate from PPC:

   kubectl -n api-gateway get secret ingress-certificate-secret -o jsonpath='{.data.ca\.crt}' | base64 -d > CA.pem
   

   Use the ProtegrityCA.pem that was returned as described in Policy Agent Installation.

3. Configure the PPC Address

   Use the PPC address in place of the ESA IP address wherever required in your configuration.

   Note

   Use FQDN as described in the PPC Rest API documentation

Log Forwarder Setup with PPC

• The Log Forwarder will proceed without certificates and will print a warning if PTY_ESA_CA_SERVER_CERT is not provided.
• No additional certificate or CA configuration is needed for PPC.

10.2 - Configuring Regular Expression to Extract Policy Username

Configuring Regular Expression to Extract Policy Username

Cloud Protect Function exposes USERNAME_REGEX configuration to allow extraction of policy username from user in the request.

• USERNAME_REGEX Function Environment configuration

  The USERNAME_REGEX environment variable can be set to contain regular expression with one capturing group. This group is used to extract the username. Examples below show different regular expression values and the resulting policy user.

^(.*)[@/].*$

10.3 - Getting JWT for Service Account in Azure Active Directory

Getting JWT for Service Account in Azure Active Directory

Protect Function App can use Microsoft identity platform endpoint for identity-as-a-service, available in Azure Active Directory, to implement OpenID Connect and OAuth 2.0 authorization. This section describes how to get JWT using OAuth 2.0 client credentials grant flow in Azure Active Directory and authorize the Client ID in Protegrity Policy.

Suggested reading: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow

High-level design:

1. Active Directory Admin creates App registration for the service account.
2. Active Directory Admin gives consent for the Service Account App ID.
3. Daemon uses the Service Account App ID and the Service Account App ID Secret or Certificate, Protect Function App ID as the scope, and gets back the Access Token (JWT).
4. Daemon sends the request to the Protect Function App, including the access token in the Authorization Bearer header.

Configure the Protect Function App:

1. From the Azure console, navigate to Function App service and select protect function app.

2. Navigate to Settings > Environment variables and click OPENID_ENABLED. Make sure it is set to true.

3. Click on OPENID_AUDIENCES, make sure it is set to the App ID recorded in EntraIDApplicationID.

4. Click or Add the authorization environment variable. Make sure it is set to jwt.

5. Click or Add on jwt_user_claim environment variable, make sure it is set to [“azp”, “appid”]. For more information on claims on AAD access token, refer:

   https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens

To register a Service Account:

1. In the Azure portal navigate to Azure Active Directory.

2. Under Manage, select App registrations > New registration.

3. Enter a Name and select Accounts in any organizational directory.

4. Redirect URI is set to http://localhost.

5. Select Register.

   After registration is complete record Application ID and Directory (tenant) ID displayed in the overview window:

   Service Account App ID: ___________________

   Directory (tenant) ID: ___________________

6. In the Azure portal, in App registrations, select your application.

7. Select Certificates & secrets > New client secret.

8. Add a description for your client secret.

9. Select a duration.

10. Click Add.

11. Record the secret’s value for use in your client application code. This secret value is never displayed again after you leave this page.

    Service Account App Secret: ___________________

For more information on app registration, see Azure documentation Quickstart Registering App

Admin Consent the Service Account:

https://login.microsoftonline.com/{tenant}/adminconsent?
client_id={Service Account App ID}
&state=12345
&redirect_uri=http://localhost

Replace the tenant and the Service Account App ID with the values recorded in the previous step. At this point, Azure AD enforces that only a tenant administrator can sign into complete the request. The administrator will be asked to approve all the direct application permissions that were requested for the app in the app registration portal.

Get the access token

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id={Service Account App ID}&scope={EntraIDApplicationID }%2F.default&client_secret={Service Account App Secret}&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'

Replace Service Account App ID, EntraIDApplicationID, Service Account App Secret, and tenant with values recorded in previous steps.

Example for successful response:

{
  "token_type": "Bearer",
  "expires_in": 3599,
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBP..."
}

\

Record the access_token from the response. access_token: ___________________

Use the token

curl -X POST "https://<Protect hostname>/api/v1/protect" -k \
-H 'x-functions-key: <Protect Function app key>' \
-H 'Authorization: Bearer <access_token>' \
-H 'Content-Type: application/json' \
-d '{
  "data": ["hello world!"],
  "data_element": "alpha"
}'

Replace the {Protect hostname}, {Protect Function app key} and {access_token} with the.

Troubleshooting:

• Service Account App ID redirect URL matches the redirect URL in the request for admin consent.
• Active Directory administrator does admin consent.
• JWT aud claim is the same as OPENID_AUDIENCES.
• JWT iss claim is the same as OPENID_ISSUERS.
• Protect Function configuration authorization=JWT
• At least one of thejwt_user_claim exists in the JWT
• The user claim in the token has permissions to make protect request.
• The data element exists in the Protect Function App current policy.
• JWT is not expired

10.4 - Protection Methods

Protection Methods

For more information about the protection methods supported by Protegrity, refer to the Protection Methods Reference.

10.5 - ARM Template Installation - Required Permissions

ARM Template Installation - Required Permissions

Permissions below are required to install Protegrity service using ARM template.

All permissions in the table must be granted with the Resource group scope.

Microsoft.Insights/components/read

Microsoft.OperationalInsights/workspaces/read

Microsoft.Insights/components/write

Microsoft.OperationalInsights/workspaces/write

Microsoft.Web/serverFarms/write

Microsoft.Web/sites/write

Microsoft.Web/sites/host/listkeys/action

Microsoft.Web/serverFarms/join/action

Microsoft.Web/register/action

Microsoft.ManagedIdentity/userAssignedIdentities/assign/action

Microsoft.ManagedIdentity/userAssignedIdentities/read

Microsoft.Resources/deployments/validate/action

Microsoft.Resources/deployments/write

Microsoft.Resources/deployments/operationStatuses/read

Microsoft.Resources/deployments/read

Log Forwarder service ARM deployment requires additional permissions below:

Microsoft.EventHub/namespaces/write

Microsoft.EventHub/namespaces/eventhubs/write

Microsoft.EventHub/namespaces/networkrulesets/write

Microsoft.EventHub/namespaces/read

The additional permissions listed below are required when API management is part of the deployment.

Microsoft.ApiManagement/service/write

Microsoft.ApiManagement/service/apis/write

Microsoft.ApiManagement/service/diagnostics/write

Microsoft.ApiManagement/service/apis/operations/write

Microsoft.ApiManagement/service/apis/operations/policies/write

Microsoft.ApiManagement/service/backends/write

Microsoft.ApiManagement/service/loggers/write

Microsoft.ApiManagement/service/policies/write

Microsoft.ApiManagement/service/apis/diagnostics/write

Microsoft.ApiManagement/service/read

Microsoft.ApiManagement/service/operationResults/read

10.6 - Associating ESA Data Store With Cloud Protect Agent

Associating ESA Data Store With Cloud Protect Agent

ESA controls which policy is deployed to protector using concept of data store. A data store may contain a list of IP addresses identifying servers allowed to pull the policy associated with that specific data store. Data store may also be defined as default data store, which allows any server to pull the policy, provided it does not belong to any other data stores. Node registration occurs when the policy server (in this case the policy agent) makes a policy request to ESA, where the agent’s IP address is identified by ESA.

Policy agent function source IP address used for node registration on ESA depends on ESA hubcontroller configuration ASSIGN_DATASTORE_USING_NODE_IP and the PTY_ADDIPADDRESSHEADER configuration exposed by the agent function.

The function service uses multiple network interfaces, internal network interface with ephemeral IP range of 169.254.x.x and external network interface with IP range described in Function app outbound IP addresses section under function configuration. By default, when agent function is contacting ESA to register node for policy download, ESA uses agent function outbound IP address. This default behavior is caused by the default ESA hubcontroller configuration ASSIGN_DATASTORE_USING_NODE_IP=false and agent default configuration PTY_ADDIPADDRESSHEADER=yes.

In some cases, when there is a proxy server between the ESA and agent function, the desirable ESA configuration is ASSIGN_DATASTORE_USING_NODE_IP=true. and PTY_ADDIPADDRESSHEADER=no which will cause the ESA to use proxy server IP address.

The table below shows how the hubcontroller and agent settings will affect node IP registration on ESA.