47.用例：在 Grail 中配置日志记录权限

Use Case: Configuring Log Record Permissions in Grail
Grail and IAM Policies make it possible to configure fine-grained permissions, down to the individual log record level.
In many cases, log files may contain sensitive customer or business information, which must be restricted to specific users or groups.
In our use-case example, there are three teams of users:
A, which requires general log access;
B, which requires access to logs defined as “Sensitive”; and C, which requires access to both “Sensitive” and “Critical” log files.
To accomplish this requirement, we will follow the Grail best practices:
First, we will create a new, separate Grail bucket for the new log file types, with an extended retention timeframe (from 35 days to one year).
Next, we will review our existing log ingestion rules, via OneAgent auto-discovery, custom log source, and the Generic Log Ingest API, to confirm how the “Sensitive” and “Critical” log files are ingested.
We need to ensure that there are appropriate identifying fields defined at the log record level: if not, we need to set their dt security context either at the data source or in the log processing rule.
Next, we will configure the DQL matchers for the new bucket, and once the matchers are in place, we will create and set the IAM policy permissions at the bucket and log record levels, to ensure these logs can only be accessed by Teams B and C.
First, we must create the new bucket in Grail.
Note that to create and view Grail buckets, you will need read/write IAM policy permissions for storage bucket definitions.
Since the policy is not defined out-of-the-box, you will need to create your own, custom IAM policy for those permissions, and then assign that policy to administrative users before you begin.
For a step-by-step walkthrough of creating new buckets in Grail, please reference our online documentation, or other videos in this series.
In brief, new Grail buckets can either be created through the Storage Management app, or through the Dynatrace API.
Once created, the new Log buckets will propagate throughout the environment, and become available for use.
Next, we need to ensure that the log records contain the necessary fields to be filtered into the new bucket.
Dynatrace allows you to tweak your ingested log data by adding a dt security context attribute to specific log records, to set permissions for individual records.
Once you identify the log records you wish to add a security attribute to, copy the processing function for the logs, and add a new Log Security Context rule.
You can learn how to create a new Log Security Context rule through our online documentation; for the purposes of our example, we have defined two log security context rules.
Each rule has appropriate matchers defined, and the Critical DT Host Logs rule has a value of “dt-critical”, and Sensitive DT Host Logs has a value of “dt-sensitive”.
Now that we have ensured that our records can be identified, we will configure the DQL matchers for the new bucket.
From the Settings app, expand Log Monitoring and select Log Buckets.
Select the icon to add a new rule.
Since there will be two different types of logs going into a single bucket, we will add two separate rules.
We will provide an appropriate name for the rule, select our new bucket from the drop-down menu, and use the matchers we defined previously for our log security context rules in step two.
We will repeat the process for the second rule, using the “critical” matcher information.
Finally, we will configure the new policies and groups through the Account Management portal.
Team A requires general log access but should not have access to any “Sensitive” or “Critical” logs.
Out of the box, Dynatrace provides a default group called “Log Viewer” - however, this group has access to all logs from all buckets, including the sensitive and critical logs from our example!
This group is therefore not appropriate for Team A - we will need to create a new group for them.
Likewise, a default policy called “Storage Logs Read” permits read access to all logs and all buckets.
This policy is also not appropriate for Team A - we will need to create a new policy for them.
For step-by-step instructions to create a new IAM policy, create and manage groups, and assign Grail permissions, please reference our online documentation.
For the users on Team A, we will create a new policy which allows them to read stored logs, and further specifies that they can only read logs stored in buckets whose name begins with “default underscore”.
Next, we will create a new group which does not provide any additional Account, Environment, or Management Zone permissions, but provides associated users with access to our new “Default Logs Read” policy.
Individual users on Team A can then be added to the new group through the Users tab.
Next, Team B needs access to logs defined as “Sensitive” but should not have access to “Critical” log files.
For the users on Team B, we will create a new policy which only allows them to read stored logs where the security context is “dt sensitive” and the log bucket is named “sensitive critical logs”.
Users associated with this policy can only view logs that meet both of these criteria.
Next, we will create a new group which provides associated users with access to this new “Sensitive Logs Read” policy.
Once users from Team B are added, they will have access to Sensitive - but not Critical - logs.
And finally, we will configure Team C with access to both “Sensitive” and “Critical” log files.
Their new policy allows users to read all stored logs in the “sensitive critical logs” bucket.
Unlike the Team B policy, it does not limit the user to any specific security context - users assigned to this policy can view all logs in that bucket.
Then, as before, we will create a new group that will allow users access to the “Critical Logs Read” policy, and then add specific users as appropriate.