Skip to content

Data Access


Data such as logs, RUM, APM, and Metrics may contain sensitive information. Therefore, for security reasons, even within the same business organization, fine-grained division of data access permissions is necessary.

The data access functionality is implemented through the following methods:

  • Based on indices from different sources, set data access scopes at the member role level for visitors.
  • To protect data security, use tools like regular expressions and masking fields to perform necessary data processing on top of access restrictions, ensuring sensitive information is properly protected without diminishing data value.

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

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

If historical access rules exist on the current page, click the icon under the Options for that rule to clone an existing rule and then create.

Configuration

  1. Select the data type;
  2. Define the name of the current rule;
  3. Enter a description for the current rule;
  4. Select the workspace site where the current rule applies;
  5. For the data type you selected, choose the corresponding index, service, application, and Measurement;

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

  7. Add single or multiple fields that need masking;

  8. Use regular expressions to mask sensitive information within the field content;

  9. Select the single or multiple member roles to which the current access rule can be applied, including system default roles and custom roles;

  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 Any (OR) or All (AND);

  • All (AND) is selected by default, and supports switching to Any (OR):

  • Examples of logical relationships are as follows:

    • Example 1: (Default AND)

      • host=[host1,host2] AND service = [service1,service2];
    • Example 2: (Switched to Any OR)

      • host=[host1,host2] OR service = [service1,service2].
  • Supports filtering values via tags/attributes, including positive filtering, negative filtering, fuzzy matching, negative fuzzy matching, Exist and Not exist, among other filtering methods.

Regular Expression Masking

When setting access rules, even though the data scope is defined, additional measures are needed to prevent the leakage of sensitive or unnecessary information. At this point, masking fields or regular expressions can be used to further process the data to enhance data protection.

On the configuration page, besides directly adding individual masking fields, if further masking of certain content within the log message is needed, such as hiding token or IP information, this requirement can be met by adding regular expressions.

  • Supports configuring multiple regular expressions, with a maximum of 10 expressions per access rule;
  • Supports disabling or enabling a specific regular expression; subsequent application and preview will only adapt masking based on the enabled expressions;
  • Supports directly editing or deleting a specific regular expression here;
  • Supports moving the position of regular expressions via drag-and-drop; when data matches this masking rule, regular expressions are applied in order from top to bottom for masking processing;
  • Supports creating new regular expressions directly 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

Assuming a member holds only one role, such as read-only, after selecting this role, the system will only apply viewing masking configured for this role.

If the "All" role is selected, all roles except Owner will be affected by the masking.

Note
  • When no data access rules are configured for default roles, they have query permissions for all data;
  • Data access rules only take effect based on the foundation of user roles having data query permissions;
  • After roles are matched with rules, you can only add further filters within the scope configured by the rule. Queries beyond this scope will return empty data.

Multi-Role Permission Coverage

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

Multi-Rule Permission Control

In scenarios with complex business data and numerous hierarchies, it is sometimes necessary to set multiple access rules for data with different sources and attributes to accommodate varying data access needs.

  • Relationship between multiple filters within one rule: The relationship between multiple values for 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]

The same role has both of the above permission rules simultaneously, then the actual data will be displayed as Rule1 OR Rule2 to achieve a union effect.

The actual visible data scope 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 masking rules are configured within Rule 1, then all data returned under all permission rules will be affected by the masking 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 masking fields here; directly write the regular expression tkn_[\da-z]* to encrypt 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 masking effect.

The above access rule applies to all Read-only members in the current workspace. They can only access data under the log index rp70 with host:cn-hangzhou.172.**.** and service:kodo. Furthermore, within this data, all token information will be invisible.

Use Cases

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

Manage List

  • View information such as the index associated with the rule, query conditions, whether masking is applied, number of associated roles, and number of members.
  • Show only rules related to me: Default is "Off", showing all rules; when enabled, only shows rules related to the current role.
  • Enable/Disable rule: Modify the rule status. When disabled, role access is unrestricted; when enabled, it is restored.
  • Edit: Modify the rule's name, description, bound index, filter conditions, and authorized roles.
  • Clone: Quickly copy the current rule.
  • Operation Audit: Records operations related to the rule.
  • Delete: Delete the current rule.
  • Batch operations: Supports batch enabling, disabling, and deleting multiple rules.

Further Reading

Feedback

Is this page helpful? ×