Security Policy Recommendation enables you to intelligently configure masking policies and row filtering rules through natural language descriptions. Buddy automatically analyzes sensitive field characteristics, recommends masking methods and filtering policies, and waits for your confirmation at key points before applying them.
Overview
Data security policies are a critical part of ensuring compliant use of sensitive data. The traditional approach requires manually configuring masking rules table by table and field by field, which is inefficient and prone to omissions. Security Policy Recommendation covers the following scenarios:
Masking Policy Recommendation: Automatically recommends appropriate masking methods (hashing, masking, setting to NULL, and so on) based on identified sensitive tags and field types.
Masking Policy Creation and Binding: Creating and binding a masking policy involves two steps. AI first generates the masking policy configuration in the security module, and the policy is created after user confirmation. The policy is then bound to the corresponding fields on the table details page, with support for differentiated settings by user group.
Batch Policy Creation: Supports batch creation of security policies for multiple tables and fields at once, with no limit on the number of policies.
Row Filtering Rule Generation: Recommends and generates row-level filtering rules based on the business attributes of tables (such as region fields and department fields), achieving multi-tenant data isolation.
Policy Compliance Check: Checks whether all sensitive fields in the current Schema are associated with masking policies and outputs a compliance coverage report. It supports built-in compliance frameworks such as PII, GDPR, and PIPL, and also allows users to create custom sensitive tags to extend the scope of compliance checks.
Prerequisites
Buddy has been enabled for the workspace.
The current account has Buddy development mode permissions.
You have view permissions on the Catalogs / Schemas that require security policy configuration.
You have permissions to create and bind policies in the data security module.
Information You Must Provide
Before recommending security policies, Buddy will ask you to provide the following minimum information set, while the rest is automatically recommended by AI:
|
Target scope | Table name, Schema, or specific field for which a policy needs to be configured |
Policy requirements | Masking recommendation / Create policy / Bind policy / Row filtering / Compliance check (can be implicitly expressed through natural language) |
If your input is incomplete, Buddy will ask for the missing information through an "Ask User card" before continuing.
Configurations That AI Can Intelligently Generate
|
Masking Method | Recommend based on the sensitivity type of the field (phone number → masking, ID card → hashing, name → masking, and so on) |
User group differentiation policy | Recommend differentiated masking based on user group roles (administrator plaintext / developer masking / analyst hashing) |
Row filtering condition | Analyze dimension fields such as region and department in the table, and generate row-level filtering SQL expressions. |
Compliance Coverage Report | Scan sensitive fields and associated policies, and output a list of uncovered fields and recommendations. |
Operation Steps
Step 1: Expressing Security Policy Requirements
Describe your requirements in natural language in the Buddy input box, and Buddy will automatically identify the policy type and target scope.
Example Input:
What masking policy should be used for the phone number and ID number in the user_info table?
Help me create a masking policy: administrators see plaintext, developers see masked data, and analysts see hashed data.
Set row filtering for the analyst group so that they can only see data from the East China region.
Check which sensitive fields under ods_catalog have not been configured with masking.
We have a custom sensitive label "Internal Employee ID". Please help me check its coverage.
Step 2: Completing Missing Information
If the input is incomplete, Buddy will ask you for the missing information through an Ask User card:
If no target table or field is specified, list the identified sensitive fields in the current Schema for selection.
If the user group setting in the masking policy is unclear, list the available user groups for selection.
After you answer, Buddy will continue the execution.
Step 3: Reviewing AI-Recommended Policies
Buddy displays the recommended security policies in structured cards:
Masking Policy Recommendations:
Field name, sensitive type, and recommended masking method.
Differentiated masking settings for each user group.
Recommendation reason.
Row Filter Rule:
Filter dimension (such as region or department)
Filter SQL expression.
Applicable user groups.
Compliance Coverage Check:
Number and list of covered sensitive fields.
Uncovered sensitive fields and recommended policies.
Compliance coverage rate.
Note:
You can modify any policy configuration on the card before confirming, and Buddy will apply the modified policy.
Step 4: Creating a Data Masking Policy
After the policy configuration is confirmed, Buddy creates a masking policy in the security module:
Display the policy name, masking method, and applicable user groups.
After successful creation, the policy ID is returned.
During batch creation, successful and failed items are displayed.
There is no limit on the number of policies that can be created in a batch.
Step 5: Binding a Policy to a Field
After the masking policy is created, Buddy binds it to the corresponding fields on the table details page:
Example Input:
Bind the newly created masking policy to the phone number field in the user_info table.
Buddy will:
Display the mapping between the fields to be bound and the policies.
After confirmation, perform the binding operation.
Display the binding result (success or failure).
Note
Creating and binding a masking policy involves two steps: first create the policy in the security module, and then bind it to fields in the table details.
Step 6: Configuring Row Filtering Rules (Optional)
If row-level data isolation is required, Buddy generates row filtering rules:
Display the SQL expression for the filter condition.
Confirm the applicable user groups.
Create and bind a row filtering rule.
Key Milestone Confirmation
|
Target scope | Before policy recommendation | Confirm the table / field for which a policy needs to be configured. |
Masking policy | Before creation | Review masking methods and user group differentiation settings. |
Policy binding | Before binding | Confirm the mapping between fields and policies. |
Row filtering rule | Before creation | Review filter conditions and applicable user groups. |
Batch Operations | Before batch creation | Confirm the impact scope. |
FAQs
Q: Why Are Data Masking Policy Creation and Binding Separated into Two Steps?
Creating and binding a masking policy are two independent operations in the security module. Policy creation defines masking rules in the security module, such as masking methods and differentiated user group settings. Policy binding associates a created policy with specific fields on the table details page. Performing these two steps enables policy reuse, as the same policy can be bound to similar fields in multiple tables.
Q: What Is the Difference Between Security Policies Created by Buddy and Those Manually Created in the Security Module?
A: There is no difference at all. Policies created by Buddy and policies created manually are in the same management system, and you can view and manage them centrally in Data Security Overview. Q: Are Custom Sensitive Tags Supported?
A: Yes. In addition to built-in compliance framework tags such as PII / GDPR / PIPL, you can create custom sensitive tags (such as "Internal Employee ID" and "Business Confidentiality Level"). Buddy can perform compliance checks and policy recommendations based on custom tags.
Q: What Compliance Frameworks Are Covered by Compliance Checks?
A: It supports built-in compliance frameworks such as PII / GDPR / PIPL, and also supports compliance checks based on custom sensitive tags created by users to meet business-specific compliance requirements.
References