Data Security¶

In the cloud computing era, data security is of paramount importance. Comprehensive data protection capabilities enhance visibility and insight, automatically alert on security risks, and thereby improve overall defense, ensuring data availability as well as security and compliance.

When using Guance, its built-in tools perform risk assessment and processing on the received data.

How to Reduce Data Risks?¶

Guance collects monitoring information from your infrastructure and services and manages it centrally, allowing you to analyze and process it at any time. During this process, servers transmit multiple types of data. Servers using Guance normally send various types of data content. Most data collected through normal use of Guance products does not contain personal privacy information. For non-essential personal data that may be included, we provide detailed explanations and recommendations to prevent confusion. Guance provides multiple ways to help you reduce data risks.

Data Security Considerations on the DataKit Side¶

HTTPS Data Upload¶

All DataKit data is uploaded via the HTTPS protocol, ensuring the security of data communication.

Limited Delivery Mechanism¶

The center cannot deliver instructions to DataKit for execution; all requests are initiated by DataKit itself. DataKit can only periodically pull relevant configurations (such as Pipeline and blacklist configurations) from the center. The center cannot deliver commands to DataKit for execution.

Field Value Masking During Tracing Collection¶

During the Tracing collection process, the execution process of some SQL statements may be collected. The field values in these SQL statements are all masked, for example:

SELECT name from class where name = 'zhangsan'

will be masked to

SELECT name from class where name = ?

Pipeline and Blacklist Mechanisms¶

If some sensitive data in the collected data cannot be removed during collection, you can use specific Pipeline functions (such as the cover() function, which replaces parts of a string with *) to mask sensitive data (such as phone numbers).

Additionally, configuring blacklist rules can also prevent the upload of sensitive data.

Sensitive Data Scanning¶

The Sensitive Data Scanning feature is used to identify, flag, and edit risk-bearing data such as personal privacy information. As a security defense, it effectively prevents sensitive data from leaking out.

For more details, see Sensitive Data Scanning.

Logs¶

The use of Guance products and services generates numerous log records. Due to the strong correlation of log data itself, specific rules must be applied during the collection-analysis process to achieve filtering of massive volumes of log data.

By configuring sensitive fields for log data, members with the corresponding permissions can only see masked log data.

Data access permission control is another key method for reducing log data security risks. By configuring corresponding log data access query scopes for different roles, data is isolated, achieving comprehensive management and filtering of sensitive data.

For more details, see Multi-role Data Access Permission Control.

Snapshots¶

The snapshot service of Guance acts as an immediate data replica, containing anomaly data filtering conditions and data records. When there is a need to share monitoring data, setting data masking rules or deciding the sharing method when sharing a snapshot can generate an access link with specified viewing permissions, automatically forming a data protection shield.

For more details, see Snapshots.

RUM¶

When collecting data related to user visits, the RUM (Real User Monitoring) SDK performs custom modification and interception on the data to prevent sensitive data from flowing out.

For more details, see SDK Data Interception and Data Modification.

Web RUM SDK¶

The following describes the RUM SDK's use of Cookies and alternative mechanisms (compliance disclosure).

Under default configuration, the Guance RUM SDK writes two types of Cookies into the monitored application to implement session identification and user identification:

1. Cookies with the _gc_s_ prefix: Used to store information related to the current visit session, enabling the correlation and statistics of user behavior within a single visit cycle.

2. Cookies with the _gc_usr_ prefix: Used to store user identification information, allowing the continuous identification of the same end user across different visit sessions.

The above Cookies do not contain users' real identity information; they are only used for session management and anonymous user identification in monitoring data.

If writing Cookies is not allowed in specific business scenarios (such as privacy compliance requirements, users refusing Cookies, browser restrictions, etc.), the RUM SDK supports initialization configuration:

sessionPersistence: "local-storage"

This stores the above session information and user identification in LocalStorage, thereby continuing to provide session and user association capabilities without writing any Cookies.

Session Replay Privacy Settings¶

Session Replay provides privacy controls to ensure that no company exposes sensitive or personal data. Data is also stored encrypted. The default privacy options of Session Replay are designed to protect end-user privacy and prevent sensitive organizational information from being collected.

Global Configuration¶

By enabling Session Replay, sensitive elements are automatically masked so that they are not recorded by the RUM SDK.

To enable your privacy settings, set defaultPrivacyLevel to mask-user-input, mask, or allow in your SDK configuration.

import { datafluxRum } from '@cloudcare/browser-rum'

datafluxRum.init({
  applicationId: '<DATAFLUX_APPLICATION_ID>',
  datakitOrigin: '<DATAKIT ORIGIN>',
  service: 'browser',
  env: 'production',
  version: '1.0.0',
  sessionSampleRate: 100,
  sessionReplaySampleRate: 100,
  trackInteractions: true,
  defaultPrivacyLevel: 'mask-user-input',
})

datafluxRum.startSessionReplayRecording()

After updating the configuration, you can use the following privacy options to override elements in the HTML document:

Mask user input mode: Masks most form fields, such as inputs, text areas, and checkbox values, while recording all other text as-is. Inputs are replaced with three asterisks (***), and text areas are obfuscated with space-preserving x characters.

Mask mode: Masks all HTML text, user input, images, and links. Text on the application is replaced with X, rendering the page as a wireframe.

Allow mode: Records all data.

Some limitations:

For data security considerations, the following elements are always masked regardless of the defaultPrivacyLevel mode you configure:

• Input elements of type password, email, and tel;
• Elements with an autocomplete attribute, such as credit card numbers, expiration dates, and security codes.

Custom Configuration¶

Session Replay supports masking of sensitive elements. You can flexibly configure the content to be masked based on business needs, such as sensitive information like phone numbers. The following are the specific methods:

Masking via Element Attributes¶

You can add the data-gc-privacy attribute to elements that need to be masked. The following four attribute values are supported:

• allow: Allows data collection, no masking. • mask: Masks the content, displaying it in masked form. • mask-user-input: Masks user input, preventing sensitive input data from being recorded. • hidden: Completely hides the content.

Example code:

<!-- Allows data collection -->
<div class="mobile" data-gc-privacy="allow">13523xxxxx</div>

<!-- Masks the content -->
<div class="mobile" data-gc-privacy="mask">13523xxxxx</div>

<!-- Masks user input -->
<input class="mobile" data-gc-privacy="mask-user-input" value="13523xxxxx" />

<!-- Hides the content -->
<div class="mobile" data-gc-privacy="hidden">13523xxxxx</div>

Masking via Element Class Names¶

Masking can also be achieved by adding specific class names to elements. The following class names are currently supported:

• gc-privacy-allow: Allows data collection. • gc-privacy-mask: Masks the content. • gc-privacy-mask-user-input: Masks user input. • gc-privacy-hidden: Completely hides the content.

Example code:

<!-- Allows data collection -->
<div class="mobile gc-privacy-allow">13523xxxxx</div>

<!-- Masks the content -->
<div class="mobile gc-privacy-mask">13523xxxxx</div>

<!-- Masks user input -->
<input class="mobile gc-privacy-mask-user-input" value="13523xxxxx" />

<!-- Hides the content -->
<div class="mobile gc-privacy-hidden">13523xxxxx</div>

Using shouldMaskNode to Implement Custom Node Masking Policies¶

In certain special scenarios, customized masking may be required for specific DOM nodes. For example, in applications with higher security requirements, you may want to uniformly mask all text content containing numeric values on the page. This requirement can be achieved by configuring the shouldMaskNode callback function for more flexible privacy control policies.

import { datafluxRum } from '@cloudcare/browser-rum'

datafluxRum.init({
  applicationId: '<DATAFLUX_APPLICATION_ID>',
  datakitOrigin: '<DATAKIT ORIGIN>',
  service: 'browser',
  env: 'production',
  version: '1.0.0',
  sessionSampleRate: 100,
  sessionReplaySampleRate: 100,
  trackInteractions: true,
  defaultPrivacyLevel: 'mask-user-input',
  shouldMaskNode: (node, privacyLevel) => {
    if (node.nodeType === Node.TEXT_NODE) {
      // If it is a text node, check whether the content contains numbers
      const textContent = node.textContent || ''
      return /\d+/.test(textContent)
    }
    return false
  },
})

datafluxRum.startSessionReplayRecording()

In the above example, the shouldMaskNode function checks all text nodes. If the content contains numbers (such as amounts, phone numbers, etc.), masking is applied automatically, thereby enhancing the privacy protection of user data.

With the above methods, you can flexibly configure masking rules for sensitive elements, improving data security and meeting business compliance requirements.