See the supported connectors for Application Integration.

Mask sensitive data in logs

Preview — Mask sensitive data in logs

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This document describes masking sensitive data in integration execution logs.

About data masking

Application Integration generates log messages for each integration execution. These logs can contain information that is used to determine the status of each integration step, or to troubleshoot failed integrations, tasks, or events. However, if you have enabled local logging or Cloud Logging, all data variables and fields are included in the log output of the execution log or Cloud Logging respectively. These logs can also include sensitive or personally identifiable information (PII) that you don't want to be visible in the log output. With Application Integration, you can mask sensitive data in the log output so that this information is not visible when you review the logs.

Benefits

Masking sensitive data in logs provides the following benefits:

• Improve customer security and privacy
• Comply with data privacy regulations

Supported data types

You can mask variables for all supported data types in Application Integration.

Mask sensitive data in logs

To mask sensitive data in logs for a project, you must enable masking for all of the following resources:

• Project by enabling masking for all regions in that project
• Integration
• Variables

Project-level masking control signifies the highest tier of the masking hierarchy, subsequently followed by integration and variables. Authorization for project-level masking is established by using a flag at the region level. To enable project-level masking, enable masking for all regions within your projects. In your project, if you have enabled masking for the integration and the variable, but disabled masking for the region that contains the integration, then the masking functionality doesn't work. Similarly, if integration masking is disabled, variable masking for that integration doesn't work even if you have enabled masking at the region level.

Suppose, you have a project that contains a region with multiple integrations. You want to disable masking for specific integration. In such a case, you can enable masking for the region and disable it for the specific integration that doesn't require masking. Based on your business needs, for your project, you can enable masking at the region, integration, and the variable level. On the other hand, if a project has multiple regions and you have enabled masking for only one region, then end-to-end masking will work only for that region and all integrations built within that region.

Masking format

Variables are masked in the fixed masking format. For example, the following format shows a masked variable of type string and length 12: Masked String of length 12

You can search for masked variables with the /Masked.*\./ regular expression. You can use the following regular expressions to filter specific types of masked variables:

• String: Masked String.*\.
• Integer: Masked Int.*\.
• Boolean: Masked Bool.*\.

The fixed masking format is efficient for large strings. Both Cloud Logging and integration execution logs mask variables in the same format.

Example use case

Suppose, your customers' sales data contains sensitive information such as, contact information, order history, pricing agreements, customer payments, etc. By enabling masking at different hierarchical levels, you can protect your data log visibility:

• To protect customer sales in the production environment, enable masking for your project for all regions associated with that project.
• To protect specific sections such as customer's payment details, enable masking for the intgeration that contains the payment flow.
• To protect specific details such as customer's account number, enable masking for the variable that contains the account number.

For data protection, you must mask all sensitive information. If any level is left unmasked, it could lead to a potential point of unauthorized access.

Pricing

There's no additional cost for masking variables. For information about pricing, see Application Integration pricing.

Limitation

• Application Integration doesn't support masking data in nested fields.