Privacy Rights

Latest Dynatrace

Permissions

The following table describes the required permissions.

Permission

Description

storage:logs:read

Enables the app to query logs

storage:logs:write

Enables the app to write privacy audit logs

storage:buckets:read

Enables the app to list Grail buckets

state:app-states:read

Enables the app to read request data

state:app-states:write

Enables the app to store request data

state:app-states:delete

Enables the app to delete request policies

state:user-app-states:read

Enables the app to read user configuration

state:user-app-states:write

Enables the app to store user configuration

iam:service-users:use

Enables the app to process requests using a service user

email:emails:send

Enables the app to send status updates for requests

Installation

Make sure the app is installed in your environment.

Before you begin

Some one-time setup is necessary to make sure Privacy Rights Privacy Rights functions correctly. We recommend you create a Privacy Rights request assignees group to assign all Privacy Rights users to, and a Privacy Rights request reviewers group with additional permissions for reviewers.

You can grant these permissions by assigning the groups the following IAM policies. Each policy should be bound to its group as an environment policy. Replace the placeholder value for iam:service-user-email with the email of your privacy-rights service user.

Privacy rights request assignees

The following policy should be bound to the group as an environment policy. The group should also include the view logs permission for the environment. We recommend restricting app engine and app state permissions to the app ID, unless the user also needs access to other apps.

ALLOW app-engine:apps:run WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW state:app-states:read, state:app-states:write, state:app-states:delete WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW email:emails:send;
ALLOW storage:buckets:read;
ALLOW storage:logs:read;
ALLOW storage:fieldsets:read;
ALLOW state:user-app-states:read, state:user-app-states:write, state:user-app-states:delete WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW app-engine:functions:run;
ALLOW storage:logs:write;

Privacy Rights request reviewers

The following group should be assigned to both the assignee policy above, and a reviewer-specific policy:

ALLOW storage:records:delete;
ALLOW iam:service-users:use WHERE iam:service-user-email = "YOUR-SERVICE-USER-EMAIL-HERE";
ALLOW automation:workflows:read;
ALLOW automation:workflows:write;

Create service user

To configure the service user for Privacy Rights Privacy Rights, see Create service users. Make sure to name the user privacy-rights. The name must match exactly.

See Create policies based on a service user, to learn how to create a policy that will be assigned to the service user.
Make sure you provide the following policy statement in the Policy statement field:

ALLOW app-engine:apps:run WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW storage:records:delete;
ALLOW storage:fieldsets:read;
ALLOW storage:system:read;
ALLOW storage:logs:read;
ALLOW storage:events:read;
ALLOW storage:bizevents:read;
ALLOW storage:spans:read;
ALLOW storage:buckets:read;
ALLOW state:app-states:read;
ALLOW state:app-states:write;
ALLOW email:emails:send;
ALLOW storage:logs:write;

Service user email

To find the email of your service user:

In Dynatrace, go to Account Management.
Select Identity & access management > Service users.

You will see an overview table with all of your service users.
In the Actions column, select > View Service User.
The email is listed as Service user email in the Details section.

Restrict access

To prevent users from accessing Privacy Rights Privacy Rights, you can create a group with the following policy and add all users who shouldn't be able to export, delete, or access the sensitive data in the app to the group.

ALLOW app-engine:apps:run WHERE shared:app-id != 'dynatrace.privacy.rights';
ALLOW state:app-states:read, state:app-states:write, state:app-states:delete WHERE shared:app-id != 'dynatrace.privacy.rights';
DENY app-engine:apps:run WHERE shared:app-id = 'dynatrace.privacy.rights';
DENY state:app-states:read, state:app-states:write, state:app-states:delete WHERE shared:app-id = 'dynatrace.privacy.rights';
DENY iam:service-users:use WHERE iam:service-user-email = "YOUR-SERVICE-USER-EMAIL-HERE";

IAM policies are additive, so make sure that no other policies including the ALLOW app-engine:apps:run or ALLOW state:app-states:{read, write, delete} permissions are active for these users. They should also not have read access to audit logs in the default_logs or privacy_audit buckets (depending on your chosen audit logging configuration) or be granted state-management:app-states:delete, which would allow them to delete requests.

Privacy Rights Privacy Rights empowers you to address and manage customer requests related to data subject rights under applicable data protection laws (for example, GDPR and CCPA/CPRA).

Privacy Rights Privacy Rights helps you to:

Export personal data: about a specific end-user.
Delete personal data: review and delete personal data about a specific end-user.
Cleanup data: cleanup any mistakenly ingested data for a specific timeframe.

The built-in workflows provide a straightforward method to search for data associated with end users. You can then review the retrieved data and make informed decisions about exporting or deleting it. The system also allows you to track and follow up on these requests through the request dashboard. Each step is documented with an audit trail to ensure compliance with your obligations.

Privacy Rights Privacy Rights only supports export, deletion, and cleanup of logs from Grail.

Privacy Rights Privacy Rights uses a multi-party access control model to protect your data. This requires setup of policies, groups, and a service user before first use of the app. See Prerequisites to learn more.
We recommend that you restrict access to the app, app state, service user, and audit logs to a small group of trusted users. The service user has extensive permissions and could be mistakenly or deliberately abused, for example, to delete a large volume of data. Users with access to the app state may be able to modify requests even if they don't have access to the app UI. To learn how to restrict access, see Restrict access and Audit Logs.

Create a request to review and export personal data about a specific end-user. The overview includes details of all requests, including the relevant user identifier, assignees and reviewers, the current status of each request, as well as the defined due date. Audit logs and request policies can be accessed and managed from this page.

In the export request form, you specify the user details such as user type, a user identifier to search for matching data in Grail, and the scope of the search in Grail (the timeframe and log buckets).

The data matching the executed query are returned and can be viewed by number of log records, volume, data residency, as well as number of systems. The reviewer can then approve or reject export of this data.

1 of 3Create a request to review and export personal data about a specific end-user. The overview includes details of all requests, including the relevant user identifier, assignees and reviewers, the current status of each request, as well as the defined due date. Audit logs and request policies can be accessed and managed from this page.

Privacy Rights Privacy Rights writes audit logs by ingesting logs into your Dynatrace tenant. This allows you to audit and download historical actions, such as request creation, request approval, and policy creation.

By default, audit logs go to the default_logs bucket. To change this, you can assign your logs to a privacy_audit bucket. This is a custom bucket that needs to be created manually, and the name is not configurable. You can customize the retention period to suit your needs and restrict access to the bucket using IAM policies. You also need to manually set up a rule assigning logs containing Privacy Rights App Audit to the privacy_audit bucket. To do this, go to Settings > Log Monitoring > Bucket assignment. Ensure that the rule has higher priority than any other rules that might assign the app’s logs to a different bucket, such as Audit logs.

If no audit logs are visible and the privacy_audit bucket does not exist, there may be a bucket assignment rule that assigns the app’s audit logs to a different bucket than default_logs. In such cases, add an assignment rule that assigns the audit logs to default_logs and sets its priority higher than other rules.

With Privacy Rights Privacy Rights, you can also create and manage request policies to enrich or filter request results, for example, to prevent the deletion of audit logs and compliance records.

When creating a policy, you can define its conditions using DQL. We suggest the following:

Use the parse command to extract personal data fields from your logs, such as a profile ID or IP address.
Use the filter command to exclude data that should not be included, such as audit logs or compliance records.

To limit the scope of requests:

Use the shortest possible timeframe and select relevant buckets only.
Make sure you aren't exporting personal data of other individuals or confidential data.
Use policies to help ensure that your organization’s policies regarding sensitive data are followed.

Policies map policy requirements to DQL that can be applied to refine the request query. For example, if you have a financial_logs bucket and your organizational policy is that this should never be included in personal data exports, you can create an export policy | filter dt.system.bucket != “financial_logs” and apply this to all export requests by default.
Minimize the number of logs you export/delete so it is easier to review the data.

If you see a banner informing you that permissions are misconfigured, confirm that:

Permissions are configured correctly for the service user, to learn more see Privacy Rights.
The simple workflow used by the app has not been mistakenly deleted or switched off. Users with the automation:workflows:admin permission can view and edit the workflow in Workflows after enabling admin mode. The workflow should be enabled on a schedule and include the app’s Process deletion requests workflow action.

If you notice that deletion and cleanup requests in the Approved state don't transition into the Processing state, confirm that:

Permissions are configured correctly for the service user, to learn more see Privacy Rights.
The simple workflow used by the app has not been mistakenly deleted or switched off. Users with the automation:workflows:admin permission can view and edit the workflow in Workflows after enabling admin mode. The workflow should be enabled on a schedule and include the app’s Process deletion requests workflow action.

If any deletion error occurs, then your request transitions into the Failed state. In the request details, further information will be provided for each failed task. Deletion and cleanup requests are processed in one or more tasks that cover specific timeframes. You can assume that deletion has succeeded for any timeframe not listed in the failed tasks. There are four reasons why a deletion task may fail:

Invalid request: the request was not accepted because either it uses DQL that is unsupported for deletion or it matches too many records. No data has been deleted. You can resolve this by creating a new request with a modified query and attempting deletion again for the failed timeframe(s).
Trigger timeout: due to a temporary outage, it was not possible to start deletion and the task timed out. No data has been deleted. We recommend you wait 12 hours or longer, then create a new request for the failed timeframe(s) to attempt deletion again.
Processing timeout: due to a temporary outage during deletion, the task has timed out. Data may have been partially deleted. We recommend you wait 12 hours or longer, then create a new request for the failed timeframe(s) to attempt deletion again.
Internal error: an internal error occurred during deletion. In this unlikely case, data may have been partially deleted for the timeframe. Please contact Support so we can assist you in resolving the issue.

Learning modules

01Export personal data

How-to guide
Export personal data with Privacy Rights

02Delete personal data

How-to guide
Delete personal data with Privacy Rights

03Cleanup data

How-to guide
Cleanup data with Privacy Rights