Data Access¶

Data such as logs, RUM, APM, and metrics may contain sensitive information. Therefore, for security reasons, even within the same business organization, it is necessary to finely delineate data access permissions.

The data access functionality is implemented in the following ways:

1. Based on indexes from different sources, set data access scopes at the member role level for visitors.

2. Utilize tools such as regular expressions and masking fields to perform necessary processing on data while restricting access, 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 there are historical access rules on the current page, click the icon under the Options column of that rule to clone an existing rule and then create a new one.

Configure¶

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 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 for data under the current rule.

7. Add one or multiple fields that need to be masked.

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

9. Select one 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 select Any (OR) or All (AND).

• All (AND) is selected by default, 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: (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.

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, you can use Masking Fields or Regular Expressions to further process the data to enhance data protection.

On the configuration page, besides directly adding individual masking fields, if you need to further mask specific parts of the log message, such as hiding token or IP information, you can add regular expressions to meet this requirement.

• 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 enabled regular expressions.
• Supports directly editing or deleting a specific regular expression here.
• Supports moving regular expressions by dragging. When data matches this masking rule, regular expressions are applied in order from top to bottom for masking.
• 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¶

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

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

Multi-Role Permission Coverage¶

If a member holds multiple roles and the query permission scopes of these roles vary (as shown in the figure below), the member's final data query permission will be the union of the data access view 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 from different sources and with different attributes to accommodate varying data access needs.

• Relationship between multiple filters within one rule: Multiple values for the same key have an OR relationship; relationships between different keys are AND.
• Relationships between multiple rules are OR.

Therefore, if:

Rule 1: host = [host1,host2] AND service = [service1,service2] Rule 2: host = [host3,host4] AND source = [source1,source2]

The same role simultaneously possesses the above two permission rules, 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 Rule 1 among them has masking rules configured, 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 within the current workspace.
5. Click Save. If needed, click Preview at the bottom left 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 where host:cn-hangzhou.172.**.** and service:kodo, and within such data, all token information will be invisible.

Use Cases¶

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

Manage¶

• You can 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, restrictions are 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.

More Reading¶