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 finely divide data access permissions.

The data access feature is implemented through the following methods:

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

On the Management > Data Access page, you can start creating new rules in the following two ways:

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 of the rule to clone an existing rule and then create.

Configure¶

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 to which the current rule applies;

5. For the data type you selected, choose the corresponding Index, service, application, and Metrics;

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

7. Add one or more fields that need to be desensitized;

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 can be applied, including default roles and custom roles in the system;

10. Save.

Configuration Notes¶

Data Access Scope Definition¶

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

The logical relationship between different fields can be customized to select Any (OR) or All (AND);

• By default, All (AND) is selected, and you can switch to Any (OR):

• Examples of logical relationships are as follows:

  • Example 1: (Default AND)

    • host=[host1,host2] AND service = [service1,service2];

  • Example 2: (Switch to Any OR)

    • host=[host1,host2] OR service = [service1,service2].

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

Regular Expression Desensitization¶

When setting access rules, although the data scope has been defined, additional measures are still needed to prevent the leakage of sensitive or unnecessary information. At this time, you can use Desensitization Fields or Regular Expressions to further process the data to enhance data protection.

On the configuration page, in addition to directly adding individual desensitization fields, if you need to further desensitize part of the content in the log message, such as not displaying token or IP information, you can add regular expressions to meet this requirement.

• Supports configuring multiple regular expressions, with a maximum of 10 expressions under one access rule;
• Supports disabling or enabling a regular expression, and subsequent applications and previews will only adapt desensitization based on the enabled regular expressions;
• Supports directly editing or deleting a regular expression here;
• Supports dragging to move the position of regular expressions. When data matches this desensitization rule, the regular expressions are applied in order from top to bottom for desensitization processing;
• Supports directly creating a new regular expression here:

In the pop-up window, enter the required information.

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

Role Scenarios and Query Permissions¶

Simple Scenario¶

Assume that a member only holds one role, such as read-only. After selecting this role, the system will only perform desensitization for this configured role.

Among them, if the "All" role is selected, all roles except Owner will be affected by desensitization.

Multi-Role Permission Coverage¶

If a member holds multiple roles, and the query permission coverage of these roles is different (as shown in the figure below), the member's final data query permission will be the sum of the data access view scopes of all roles.

Multi-Rule Permission Control¶

In scenarios where business data is complex and hierarchical, for data with different sources and attributes, sometimes it is necessary to set multiple access rules to adapt to different data access needs.

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

Therefore, 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 the above permission rules, the actual data will display Rule1 OR Rule2 to achieve the union effect.

The actual data range that can be seen is:

（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 has a desensitization rule configured, then all data returned under all permission rules will be affected by the desensitization rule.

Configuration Example¶

1. Select the index rp70 of this workspace;
2. Set the data range to host:cn-hangzhou.172.**.** and service:kodo;
3. Do not set desensitization fields here, directly write the regular expression tkn_[\da-z]*, that is, encrypt the token information;
4. Finally, directly assign the current access rule to all Read-only members in the current workspace.
5. Click Save. If needed, click Preview in the lower left corner to view the desensitization effect.

The above access rule is for all Read-only members in the current workspace, who can only access data under the log index rp70 with host:cn-hangzhou.172.**.** and service:kodo, and in such data, all token information is invisible.

Use Cases¶

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

Management List¶

• You can view information such as the index associated with the rule, query conditions, whether desensitization is applied, the number of associated roles, and the number of members.
• Only display rules related to me: By default, it is "Off", displaying all rules; when enabled, only rules related to the current role are displayed.
• Enable/Disable Rule: Modify the rule status. When disabled, role access is unrestricted; when enabled, it is restored.
• Edit: You can modify the rule's name, description, bound index, filter conditions, and authorized roles.
• Clone: Quickly copy the current rule.
• Operation Audit: Record operations related to the rule.
• Delete: Delete the current rule.
• Batch operations: Supports batch enabling, disabling, and deleting multiple rules.

Further Reading¶