Latest Dynatrace
Privacy Rights empowers you to address and manage customer requests related to their data subject rights under applicable data protection laws (for example, GDPR and CCPA/CPRA).
The built-in workflows provide a straightforward method to search for data associated with end users. You can then review the retrieved personal data and make informed decisions about exporting 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 only supports the export of logs. With deleteion/cleanup workflows you can make informed decisions about deletion or export.
Privacy Rights only supports export, deletion, and cleanup of logs from Grail.
To install Privacy Rights, find Privacy Rights in Dynatrace Hub and select Install.
To obtain a personal data export, you need to fill in a request export form.
In the request, specify:
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 personal data exports are followed.
Policies map policy requirements to DQL that can be applied to refine the export 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.
Policies map policy requirements to DQL that can be applied to refine the export 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.
Consider the number of logs you export/delete. The higher the number, the more difficult it is to review the data.
Privacy Rights ingests log entries as audit logs. 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 bucket assignment rule. 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, 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:
parse
command to extract personal data fields from your logs, such as a profile ID or IP addressfilter
command to exclude data that should not be deleted, such as audit logs or compliance records.Privacy Rights uses a service user to process approved deletion and cleanup requests in the background when the app is not being used. Before you create a service user, you need to create a policy that will be assigned to the service user.
To create a policy to assign to the service user
In Dynatrace, go to Account Management.
Select Identity & access management > Policy Management.
Select Policy.
Provide a policy name in the Policy name field.
optional In Policy description, provide a description to help other users understand how this policy is used.
In Policy statement, provide the following policy statement:
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:buckets:read;ALLOW state:app-states:read;ALLOW state:app-states:write;ALLOW email:emails:send;ALLOW storage:logs:write;
Select Save.
You then need to create the service user.
In Dynatrace, go to Account Management.
Select Identity & access management > Service users.
Select Add service user.
In Name, name the user privacy-rights
. The name must match exactly.
optional In Description, explain how the service user is used.
Select Save.
You will see an overview table with all your service users.
In the Actions column, select the > View Service User.
Select Permission.
In the Permission name list, select the policy you created for the service user. If you have multiple environments and only use Privacy Rights in a single environment, restrict the service user to this environment by selecting it in the Scope section.
To use Privacy Rights, you need certain IAM permissions to make sure it functions correctly. You can grant these permissions by assigning them to a group with the following IAM policy: To use Privacy Rights, you need certain IAM permissions to make sure it 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 them to a group with the following IAM policy:
Privacy rights request assignees
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;
This 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. Privacy Rights request reviewers
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;
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.
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.
We recommend that you restrict access to the app, app state, and service user 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 prevent users from accessing 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 (such as the default AppEngine - User policy) are active for these users.
They should also not be granted state-management:app-states:delete
, which would allow them to delete requests or have read access to audit logs in the default_logs
or privacy_audit
buckets (depending on your chosen audit logging configuration).
If you noticed that deletion and cleanup requests in the Approved state don't transition into the Processing state, confirm that:
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 support you in resolving the issue.