DataWorks:Security risks

Built-in risk check items

DataWorks provides built-in risk check items for common scenarios. You can also create custom risk check items based on your data security needs. The following table describes some of the built-in risk check items.

The actual list of built-in items may vary and is subject to what is shown in the console. DataWorks continues to add new built-in risk check items in subsequent releases.

Custom risk check items

This feature allows you to create fine-grained risk identification rules by combining different dimensions, such as monitored targets, operation type, data volume, frequency, operator, and time. The system analyzes data operation logs based on the enabled identification rules and generates corresponding risk events.

1. On the Security Risk page, click the Risk Detection Item tab.

2. Click New Test Item to configure a custom check item. The following tables describe the parameters.

   • Basic information: Defines the basic properties and metadata of the check item.

     Parameter	Required	Description
     Policy name	Yes	The name of the check item, which should clearly reflect its monitoring purpose. Example: "Detection for bulk export of core customer information".
     Type of Risk	Yes	Categorizes the risk for subsequent analysis and management. Behavioral risk: An operation performed by a user or system account that may pose a security risk. Turnover Risk: A risk that may arise when data is transmitted across different systems, applications, or network boundaries.
     Risk Level	Yes	Defines the severity of the risk that this check item detects. The system uses this level to aggregate risks and trigger alerts. High-risk: An activity that could lead to a serious data breach, business interruption, or major compliance issue. Med: An activity that may pose a potential security threat and requires attention and auditing from security personnel. Low-risk: A non-standard operation, typically used for auditing or statistical purposes.
     Note Information	No	A detailed description of the check item, such as its rationale, the specific business scenario it monitors, or contact information for the relevant owner.

   • Operational Objectives: Defines the scope of the rule by specifying which data assets to monitor.

     Parameter	Required	Description
     Detection range	Yes	Defines the scope of data assets to monitor. You can select and combine one or more dimensions based on your data management policy. By Location: Filters assets by their physical or logical storage location, such as a database instance, project, or Catalog/Schema. Supported engine types include MaxCompute, Hologres, EMR Hive, DLF, DLF Legacy, and StarRocks. The hierarchy varies by engine. For example, MaxCompute is organized as Project > Table, while Hologres is organized as Database > Table. The actual selectable scope depends on the data assets that have been identified in the tenant. By Classification: Filters assets by data category. By Grading: Filters assets by data sensitivity level, such as S1, S2, or S3. When you select multiple dimensions, they are combined with an AND logic, meaning only assets that meet all selected criteria are monitored.

   • Operation rule definition: This is the core of the rule, which defines the specific behavior patterns that are considered risky.

     Parameter	Required	Description
     Data manipulation	No	Defines the SQL operation types to monitor. If not specified, all operation types are monitored. Behavioral risk: Supported operations include Select, Update, Insert, Delete, Alter, Drop, and Truncate. Turnover Risk: Supported operations include TunnelUpload and TunnelDownload. The subset of supported operations varies by engine. When the selected engine and operation are not compatible, the console displays a gray hint, and no risk events are generated for that combination. Supported operations by engine: MaxCompute: Behavior (anomalous behavior) supports Select / Update / Insert / Delete / Alter / Drop / Truncate. Circulation (anomalous circulation) supports TunnelUpload / TunnelDownload. Hologres: Behavior supports Truncate / Drop. Anomalous circulation is not supported. EMR Hive: Behavior supports Select / Insert / Drop. Anomalous circulation is not supported. DLF / DLF Legacy: Behavior supports Select / Insert / Drop. Anomalous circulation is not supported. StarRocks: Behavior supports Insert / Drop. Anomalous circulation is not supported.
     Operational Data Volume	No	Sets a threshold for the volume of data involved in an operation. If disabled, no limit is applied. Choose one of the two matching modes: Single operation data volume: Triggers the rule when the number of rows affected by a single operation is greater than or equal to the set value. Cumulative Over Time: Triggers the rule when the cumulative number of rows affected by operations within the specified time window (unit: minute/hour/day) is greater than or equal to the set value. Important When you select Cumulative Over Time, the Operating frequency and Operation time sections below are hidden and their values are cleared, because the cumulative mode already includes a time-window capability. To use frequency or time window together with data volume, switch back to Single operation data volume.
     Operating frequency	No	Sets a threshold for data operation frequency. If disabled, no limit is applied. Example: Execute 5 DELETE operations within 1 minute. An alert is generated on the fifth match within the minute.
     Operator	No	Specifies the users or user groups that the rule applies to. This field contains two independent switches, which can be enabled separately or together: User Scope: When enabled, the rule applies only to the selected User. When disabled or left empty, the rule applies to all users. Note that applying the rule to all users may generate a large number of risk events. User Whitelist: When enabled, select users or user groups. Operations by users on the whitelist are not identified as risk events. Use this switch to exclude known compliant runtime identities such as ETL accounts or inspection accounts. This switch is independent of User Scope and can be enabled at the same time.
     Source IP	No	Displayed only when Type of Risk is set to Turnover Risk. Filters events by the client IP address from which the operation was initiated. Contains two independent switches: Source IP Blacklist: When enabled, operations from IP addresses in the blacklist are identified as risks. Source IP Whitelist: When enabled, operations from IP addresses in the whitelist are not identified as risks. Each list supports three input formats: a single IP (for example, 192.0.2.1), an IP range (for example, 192.0.2.1-192.0.2.99), or CIDR (for example, 10.0.0.0/24). Two preset libraries — Risk IP address library and Overseas IP address library — are also available. Note The two preset IP libraries currently appear as placeholders in the UI and cannot be selected. Their availability will be announced later.
     Operation time	No	Defines the time window during which the rule is active. If disabled, the rule is active 24/7. You can select one or more time periods by day of the week and hour (0-23). For example, you can monitor bulk data export activities only during non-working hours, such as from 18:00 to 09:00 the following day.

3. Action buttons:

   • Effective immediately: Saves the current configuration and immediately activates the check item. The system begins risk analysis based on this rule from the next detection cycle (T+1).

   • Save Only: Saves the current configuration but does not activate it. The check item is saved in a "Disabled" state and is not used for risk analysis. You can enable it manually later.

   • Cancel: Discards all configurations in the current session and returns to the list page.

Enable or disable risk check items

After you create a check item, you can enable or disable it on the Risk Check Items tab.

• Enabled: DataWorks identifies events that match the rule and flags them as risk events.

• Not enabled: DataWorks retains previously flagged risk events but stops identifying new events.

  You can Enable or disable an individual risk check item. You can also select multiple items to Batch open or Batch Close them.

Edit or delete risk check items

After creating a check item, you can edit or delete it on the Risk Check Items tab.

• Edit: Reconfigures the risk check item. All settings except for the Policy name can be changed.

• Delete: Deletes a configured risk check item. After deletion, no new risk events are generated based on it.

  When you Edit or Delete risk check items, you can either Edit or Delete them individually in the Actions column, or select multiple risk check items and click Batch Delete.

View risk events

When an enabled risk check item is triggered, the system generates a corresponding risk event. You can view a detailed list of all events on the Risk Event tab.

Process risk events

On the Risk Event tab of the Security Risk page, you can view and process risk events. In the Operation column, click Immediate processing to update its status.

Use cases

Manually inspecting risk events is inefficient and delays responses. You may need to automatically distribute alerts to different teams based on the severity or type of risk.

• Scenario 1: Respond to critical risks in real time

  When the system detects a High-risk security event, it immediately notifies the security owner via SMS and an IM tool such as DingTalk for an emergency response.

• Scenario 2: Monitor specific behaviors

  The data security team wants to monitor all bulk export of sensitive data events and automatically send email notifications to all team members for auditing.

• Scenario 3: Categorize alerts by function

  Alerts related to Data Behavior Risks are sent to the data governance team, while alerts related to Data Flow Risk are sent to the architect team.

Benefits

The core purpose of an alert policy is to enable automated and differentiated notifications for security risks, sending the right information to the right people at the right time.

• Custom alert rules: You can flexibly define trigger conditions based on Risk Level, Type of Risk, or specific Risk Event.

• Multi-channel real-time delivery: Alerts can be sent through various channels, including Email Notification, Text Message Notification, Email and SMS notifications, DingTalk Group Robot, Feishu Group Robot, and Enterprise WeChat Robot, to ensure timely delivery.

• Improved response efficiency: The process shifts from passive risk discovery to proactive identification, shortening the response and resolution time.

Procedure

1. Go to the alert policy page

   In the Security risk module, select the Alert Policy tab and click Create New Alert Policy.

2. Enter basic information

   • Policy name: Enter a name for your policy, such as "High-risk event SMS alert".

   • Strategy Description (Optional): Briefly describe the purpose of the policy.

3. Define trigger conditions: This is the core of the policy and determines when an alert is triggered.

   • Select a Trigger Condition Type:

     • Security Risk Level: The broadest rule type. Select High-risk, Med, or Low-risk. All risk events of the selected level will trigger this alert.

     • Types of Security Risks: A category-based rule type. Select Data Behavior Risks or Data Flow Risk. All events in the selected category will trigger the alert.

     • Security Risk Events: The most fine-grained rule type. You can select one or more specific events, such as bulk query of sensitive data or frequent updates to sensitive data.

4. ConfigurationAlert Notification

   Click the Add notification method drop-down list, select a notification channel, and specify the corresponding Notification Recipients for each channel. Two rows — Email and SMS — are added by default. You can add more channels. A single policy supports multiple channels.

   Notification channel	Recipient type	Notes
   Email Notification	RAM user / RAM role	Added using the user/role selector. Multiple selections are supported.
   Text Message Notification	RAM user / RAM role	Added using the user/role selector. Multiple selections are supported.
   Email and SMS notifications	RAM user / RAM role	A single entry that sends both email and SMS at the same time. This is a standalone combined channel, not the same as separately selecting Email and SMS.
   DingTalk Group Robot	Group robot webhook URL	The URL must start with https://oapi.dingtalk.com/robot/send.
   Feishu Group Robot	Group robot webhook URL	The URL must start with https://open.feishu.cn/open-apis/bot/v2/hook.
   Enterprise WeChat Robot	Group robot webhook URL	The URL must start with https://qyapi.weixin.qq.com/cgi-bin/webhook/send.

   Note

   The webhook URL for robot channels is validated against the required prefix. If the URL does not match, the system reports "Invalid URL format" and the policy cannot be saved.

5. Save and manage

   • Click New Policy to save the policy.

   • After the policy is saved, it appears in the list, where you can View, Modification, or Remove it.