Data Access¶

LOGs, RUM, APM, and Metrics may contain sensitive information. Therefore, for security reasons, even within the same business organization, it is necessary to carefully divide data access permissions.

The data access feature is implemented in the following ways:

• Based on indexes from different sources, set member roles level data access scopes for visitors.
• To protect data security, use regular expressions and desensitization fields as tools to process data under restricted access, ensuring that sensitive information is properly protected without reducing the value of the data.

On the Management > Data Access page, new rules can be created using the following two methods:

Click the Create button in the upper left corner of the page to start creating;

If there are historical access rules on the current page, click the icon under the operations on the right side of the rule to clone an existing rule and then create.

Start Configuration¶

1. Select the data type;
2. Define the name of the current rule;
3. Enter the description of the current rule;
4. Select the workspace site where the current rule will be applied;

5. For the selected data type, choose the corresponding index, services, applications, and metrics;

6. Define the access scope of the data under the current rule;

7. Add one or more fields that need desensitization;

8. Use regular expressions to desensitize sensitive information in the field content;

9. Select one or more member roles to which the current access rule applies, including default system roles and custom roles;

10. Save.

Configuration Notes¶

Definition of Data Access Scope¶

Data Scope: Members within the access rule can only view data that matches the filter conditions.

Logical relationships between different fields can be customized to select either any (OR) or all (AND);

• By default, all (AND) is selected, but it can be switched to any (OR):

• Examples of logical relationships are as follows:

  • Example 1: (Default AND)

    • HOST=[HOST1,H lid2] AND service = [service1,service2];

  • Example 2: (Switched to any OR)

    • HOST=[HOST1,H lid2] OR service = [service1,service2].

• Supports filtering values through labels/attributes, including positive filtering, negative filtering, fuzzy matching, reverse fuzzy matching, Exist and Not exist multiple filtering methods.

Regular Expression Desensitization¶

When setting up access rules, despite having defined the data scope, additional measures are still needed to prevent leakage of sensitive or unnecessary information. At this point, desensitization fields or regular expressions can be used to further process the data to enhance data protection.

In the configuration page, besides directly adding single desensitization fields, if you need to further desensitize certain parts of the log message, such as not displaying token or IP information, this can be achieved by adding a regular expression.

• Supports configuring multiple regular expressions, with up to 10 expressions configurable under one access rule;
• Supports disabling or enabling a particular regular expression, subsequent application and preview will only adapt desensitization based on enabled regular expressions;
• Supports directly editing or deleting a particular regular expression here;
• Supports dragging to move the position of the regular expression, data matching this desensitization rule will apply the regular expression for desensitization in top-down order;
• Supports directly creating a new regular expression here:

In the popup window, input the required information.

If you check Apply to Rule, this rule will be directly added below the regular expression.

Role Scenarios and Query Permissions¶

Simple Case¶

Assume a member only holds one role, such as read-only, then selecting this role will cause the system to only perform desensitization for viewing according to the configured role.

Among them, if you select "All" this role, all roles except Owner will be affected by desensitization.

Multiple Role Permission Overlap¶

If a member has multiple roles, and these roles have different query permission coverage ranges (as shown in the figure below), then the final data query permissions for this member will be the sum of the data access viewing ranges of all roles.

Multi-Rule Permission Control¶

In cases where business data is complex and has many levels, for data with different sources and attributes, sometimes multiple access rules need to be set to meet different data access needs.

• Relationship between multiple filters in one rule: The relationship between multiple values of the same key is OR, the relationship between different keys is AND;
• The relationship between multiple rules is OR.

So, if:

Rule 1: HOST = [HOST1,HOST2] AND service = [service1,service2]
Rule 2: HOST = [HOST3,HOST4] AND source = [source1,source2]

If the same role has both of these permission rules at the same time, then the actual data will display Rule 1 OR Rule 2 to achieve a union effect.

The actual visible data range will be:

(HOST = [HOST1,HOST2] AND service = [service1,service2]) OR (HOST = [HOST3,HOST4] AND source = [source1,source2])

If the same role has multiple permission rules, and Rule 1 contains desensitization rules, then all data returned under all permission rules will be affected by the desensitization rules.

Configuration Example¶

1. Select the index rp70 for this workspace;
2. Set the data scope to HOST:cn-hangzhou.172.**.** and service:kodo;
3. Do not set desensitization fields here, directly write the regular expression tkn_[\da-z]*, i.e., encrypt token information;
4. Finally, assign the current access rule to all Read-only members within the current workspace.
5. Click save. If necessary, you can click Preview in the lower left corner to view the desensitization effect.

This access rule is aimed at all Read-only members in the current workspace, allowing access only to data under the log index rp70, HOST:cn-hangzhou.172.**.** and service:kodo. In this kind of data, all token information cannot be viewed.

Use Cases¶

Based on already effective data access rules, snapshot data received by members hit by the rules will automatically be filtered according to their permission rules. Even if the snapshot contains data beyond the member's access permissions, the system will first filter it out, and ultimately the member can only view data that complies with their access rules.

Management List¶

• You can view information related to the rules such as associated indexes, query conditions, whether desensitization is applied, number of associated roles and members.
• Show only rules related to me: Default is "Off", showing all rules; when enabled, only rules related to the current role are displayed.
• Enable/Disable Rules: Modify rule status, disable after which role access is unrestricted, enable to restore.
• Edit: Modify the name, description, bound index, filter conditions, and authorized roles of the rule.
• Clone: Quickly copy the current rule.
• Operation Audit: Record operations related to the rule.
• Delete: Delete the current rule.
• Batch Operations: Support batch enabling, disabling, and deleting multiple rules.

More Reading¶