About Shared Configurations

Feature Overview

Function Definition

The Shared Configurations module is mainly used for cross-domain reusing of security rules. It supports creating shared rule sets of custom rules, rate limiting, whitelist, custom Bot, and WAF/APP exceptions. Once created, these rule sets can be referenced by multiple domains, enabling “one-time configuration for multiple deployments”.

Access Entry

Log in to the console → Select Security Settings from the left navigation bar → Click on Shared Configurations to access the Shared Configuration Management page.

The page includes the following core tabs:

• Custom Rules: Identify specific requests and execute actions such as block or delay response.
• Rate Limiting: Restrict the request frequency of a single IP or session.
• Whitelist: Bypass requests from specific IPs, UAs, or Regions.
• Custom Bot: Identify and control specific Bot behaviors.
• WAF Rule Exception: Exempt specific requests from WAF detection.
• APP/API Exception: Exempt specific API requests from detection.
• Actions:Manage reusable response actions.

Core Value

The core value of shared configurations is to address the issue of reusing security rules across multiple sites/domains, eliminating repeated configurations and improving the consistency of security policies and also the efficiency of security policy management.

Rationale

Sharing Mechanism

Decoupling Shared Configurations from Specific Business Domains:

• When creating a shared rule, no specific domain is bound, and a unique configuration ID is generated.
• By utilizing the “Referenced Domain” field, shared rules can be associated with one or more business domains, enabling one-to-many reuse.
• A single domain can reference multiple shared rules simultaneously, and the rules are applied in order of priority.

Activation Logic

1. After a request reaches the edge node, it first matches the domain-specific configuration rules.
2. Then match the Shared Multi-Domain Configuration rule.
3. If there is a conflict between the shared rule and the single domain rule, the final action will be executed based on the configured priority (which can be customized).
4. After a configuration change, the edge nodes will synchronize and update in real time or near real time to ensure quick enforcement of the policy.

Data Flow

Client Request → Edge Node → Match Domain-Specific Rule → Match Shared Multi-Domain Configuration Rule → Execute Action (Block / Bypass / Delayed Response, etc.) → Return Response

Product Capabilities

Core Capabilities

Customer Challenges Addressed

• Pain Point 1: Low Efficiency Due to Redundant Configuration Across Multiple Sites
  When customers have dozens of business domains, there is no need to repeatedly create the same rules (such as blocking Russian IPs or Google site verification whitelists) for each domain. Create them once and reuse across all domains, significantly reducing operational workload.
• Pain Point 2: Inconsistent Security Policies Leading to Protection Vulnerabilities
  Prevents differences in security policies across domains (for example, some domains not having rate limiting configured) by providing unified global policies through shared configurations, thus improving overall defense consistency.
• Pain Point 3: Challenges In Team Collaboration and Policy Synchronization
  Security rules created by the security team can be quickly synchronized to all business domains, eliminating the need for separate notifications and updates, thus reducing collaboration costs and human errors.
• Pain Point 4: Lengthy Launch Cycles for New Business
  When a new domain goes live, mature shared security policies can be directly referenced without configuration from scratch, shortening the go-live timeline and enabling rapid security protection.
• Pain Point 5: Challenges in Compliance Audit and Traceability
  The creator, change logs, and referenced domains of a shared rule can all be traced, meeting Network Security Level Protection, PCI DSS, and other compliance requirements, which facilitates security incident tracing.

Typical Use Cases

Scenario 1: Blocking IPs From Specific Regions

If a customer needs to block all access from Russian IP addresses, a shared custom rule named block russia can be created to match Russian region IPs, set the action to “block,” and reference it to all service domains for unified site-wide blocking.

Scenario 2: Unified Site Verification Whitelist

The customer needs to configure a Google site verification whitelist for all domains. A shared rule named google-site-verification can be created to match Google verification request paths/UA, set the action to “bypass,” and apply it to all domains to avoid redundant configuration.

Scenario 3: Rate Limiting for API Interfaces

To ensure API service stability, the customer configures a unified rate limiting rule for all API domains (for example, a maximum of 100 requests per minute per IP). After creating a shared rate limiting rule, the customer applies it in bulk to all API domains.

Notes

• Domain-specific configurations have a higher priority than shared configurations applied across multiple Domains. Please plan priorities ahead in case of conflicts.
• Before deleting a shared rule, make sure that no production Domains are referencing it to avoid disrupting normal business operations.
• After changes are made to a shared rule, the update will be synchronized across all Domains referencing this rule. Please proceed with caution and evaluate the potential impact in advance.

Access Entry

• Create Shared Rule: Click “Add Rule,” select the rule type, configure the matching conditions and action handling, and submit to make the rule available for referencing.
• Reference Shared Rule: Click the rule name, choose “Associate Domain,” select the target shared rule, and save.
• Manage Shared Rules: On the Shared Configuration page, you can edit, copy, and delete rules, as well as view referenced Domains and the change history.