A cloud WAF unified pre-authorization method under a virtualization environment

Abstract

This invention relates to the field of network security technology, and in particular to a unified pre-authorization method for cloud WAFs in a virtualized environment. By deploying a unified authorization management agent on a cloud platform and having it work collaboratively with a pre-authorization certificate generation server within a network security vendor, batch pre-authorization management is achieved. Specifically, the method includes: the agent generating a unique identifier for its server and applying for a pre-authorization certificate; the certificate server verifying the certificate and issuing a pre-authorization certificate containing the total resource amount; after verifying and storing the certificate, the agent can respond to requests from the cloud platform, authorizing eligible WAF nodes and recording the authorization in a local database; simultaneously, the agent establishes periodic heartbeat checks with all authorized WAF nodes to verify the authorization status in real time, preventing bypassing authorization through virtual machine cloning, rollback, or other methods. This invention improves the efficiency of batch authorization in cloud WAFs, ensures the reliability and auditability of the authorization process, and provides a reliable billing basis for cooperation between the parties.

Description

Technical Field

[0001] This invention relates to the field of network security technology, specifically to a unified pre-authorization method for cloud WAF in a virtualized environment. Background Technology

[0002] Web Application Firewall (WAF) is a core protection component in the network security system targeting Layer 7 (Application Layer) of the OSI seven-layer model. It can accurately intercept web attacks such as SQL injection and XSS, filling the gap in application layer protection of traditional firewalls. It is a key barrier to ensure web application security, data compliance and business continuity.

[0003] Currently, many applications are migrating to the cloud, and the demand for cloud WAFs is gradually increasing. One characteristic of cloud WAFs is their large number, making it impossible to authorize them one by one like traditional hardware WAF devices. As a WAF vendor, our WAF virtual machines need to provide a unified authorization mechanism to be integrated with cloud vendors, enabling cloud vendors to uniformly authorize cloud WAFs in batches. At the same time, it also needs to ensure the credibility of the authorization service, serving as strong evidence for later billing, and preventing the abuse and bypassing of authorization, etc.

[0004] Currently, many security vendors integrate cloud WAFs by deploying and installing the cloud WAF in the cloud environment, then exporting the authorization fingerprint file from the WAF application and authorizing each user individually.

[0005] Due to the large number of WAFs in the cloud environment, manually importing certificates to authorize them one by one would be a very labor-intensive task. Furthermore, because network security vendors and cloud vendors are different companies in the actual production environment in order to adapt to more cloud platforms, the process of authorizing WAF nodes will be very long.

[0006] Cybersecurity vendors are developing specific authorization interfaces for cloud providers. Because WAF nodes are merely authorized nodes, cybersecurity vendors cannot accurately know the total number of authorized WAF nodes on a current virtualization platform; only the cloud provider knows the total number of authorized nodes. This information imbalance undermines the equality of cooperation and is detrimental to long-term collaboration between the two parties. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the present invention aims to provide a unified pre-authorization method for cloud WAF in a virtualized environment.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a unified pre-authorization method for cloud WAF in a virtualized environment, the method comprising the following steps: S1. Deploy and run a unified authorization management agent in the virtualization environment provided by the cloud vendor. The unified authorization management agent generates a unique identifier for the server based on the hardware and software information of the server it is located on, and sends the unique identifier to the pre-authorization certificate generation server running inside the network security vendor. S2. The pre-authorized certificate generation server receives the unique identifier, generates a pre-authorized certificate based on the unique identifier, the total amount of pre-authorized resources and the certificate generation time, and sends the pre-authorized certificate to the unified authorization management agent. S3. The unified authorization management agent receives and verifies the pre-authorized certificate, and stores the certificate information in the local database after successful verification. S4. When the cloud provider needs to authorize the target WAF node, it sends an authorization request to the unified authorization management agent. The unified authorization management agent queries the remaining authorization resources in the local database according to the authorization request, and when the resources are sufficient and the target WAF node meets the authorization conditions, it generates authorization information for the target WAF node and sends the authorization information to the target WAF node. S5. The unified authorization management agent establishes a periodic heartbeat detection mechanism with each authorized WAF node, and verifies the authorization status of each WAF node in real time through the heartbeat detection mechanism.

[0009] In some embodiments, step S1, specifically generating the unique identifier of the server, includes: Collect the MAC address, IP address, processor ID, operating system UUID, and UUID generated by the WAF installation program of the service network card in the server; The collected information is concatenated into a first string according to a predetermined order; Perform a byte-by-byte XOR operation on the first string to obtain the second string; The second string is hashed to obtain a hash value that serves as the unique identifier of the server.

[0010] In some embodiments, step S2, generating the pre-authorization certificate specifically includes: The received unique identifier is decoded and decrypted to obtain the original unique identifier data; After the pre-authorized total resource information is formatted and processed, it is appended sequentially to the original unique identifier data along with the certificate generation time and the certificate UUID generated for the current certificate to form a third string; The third string is encrypted to obtain the fourth string; Perform a hash operation on the fourth string to obtain the fifth string; The fourth string and the fifth string are concatenated and encoded to generate the final pre-authorization certificate.

[0011] In some embodiments, step S3, specifically verifying the pre-authorized certificate, includes: The received pre-authorization certificate is decoded and divided into encrypted data and verification data. Calculate the hash value of the encrypted data portion and compare it with the verification data portion to verify data integrity; If the data is complete, the encrypted data portion is decrypted to obtain plaintext data containing the server's unique identifier, total resources, and certificate UUID. The decrypted server unique identifier is compared with the locally generated server unique identifier to verify the certificate's compatibility with the current server. The local database was queried to confirm that the certificate UUID had not been imported repeatedly.

[0012] In some embodiments, in step S4, after receiving the authorization request, the unified authorization management agent performs the following judgment process: Query the local database to calculate the number of remaining authorized resources; Check if the target WAF node already has an authorization record and if the authorization is still valid; Detect network connectivity with the target WAF node; The authorization operation is performed when there are sufficient remaining authorized resources, the target WAF node is not authorized or its authorization has expired, and the network connectivity is normal.

[0013] In some embodiments, the heartbeat detection mechanism in step S5 is specifically as follows: Authorized WAF nodes periodically send heartbeat requests to the unified authorization management agent. The heartbeat request contains at least the unique sequence number and IP address of the WAF node. The unified authorization management agent queries the corresponding authorization record in the local database based on the received heartbeat request, and returns response information including authorization status and authorization expiration time to the WAF node; The WAF node determines whether its authorization status is valid based on the received response information.

[0014] In some embodiments, a heartbeat detection anomaly is determined when any of the following conditions occur, and the WAF node enters an unauthorized state: The unified authorization management agent cannot connect; The response information returned by the unified authorization management agent indicates that the authorization status is invalid; The authorization expiration time returned by the unified authorization management agent is inconsistent with the local record of the WAF node or has expired.

[0015] In some embodiments, the method further includes an authorization revocation step: The unified authorization management agent receives authorization revocation requests for the target WAF node; Based on the revocation request, delete or update the authorization record of the corresponding target WAF node in the local database, and release the corresponding authorization resources.

[0016] In some embodiments, the unified authorization management agent receives the authorization request and authorization revocation request through a predefined API interface, which includes at least the / api / authorization interface for node authorization and the / api / Unauthorization interface for node authorization revocation.

[0017] In some embodiments, the unified authorization management agent stores pre-authorized certificate information, WAF node authorization records, and authorization operation logs in a local database for resource statistics, billing calculation, and operation auditing.

[0018] Compared with the prior art, the beneficial effects of the present invention are: 1. Significantly improves the efficiency and automation level of authorization management. By introducing a unified authorization management agent running on the cloud platform, centralized and automated authorization management of massive cloud WAF nodes has been achieved. Cloud vendors can perform batch authorization and revocation through standard API interfaces, completely changing the inefficient traditional manual authorization import mode, greatly shortening the authorization process, and adapting to the dynamic and elastic scaling business needs of the cloud environment.

[0019] 2. Effectively prevents the authorization mechanism from being maliciously bypassed, ensuring security. The solution employs a real-time status verification mechanism based on periodic heartbeats. The authorization management agent maintains active communication with each WAF node to verify its authorization status. This mechanism effectively identifies and blocks attempts to illegally extend or replicate authorization status through methods such as cloning virtual machines, rolling back system snapshots, and tampering with IP addresses. This ensures that authorization is bound to a specific, real running instance, significantly improving the security and reliability of the authorization system.

[0020] 3. Establish a transparent and credible basis for billing and auditing. All authorization operations (pre-authorization certificates, node authorization / revocation records, heartbeat logs) are persistently stored in the local database of the authorization management agent, forming a complete and tamper-proof operation log. This provides objective and reliable data for settlement between network security vendors and cloud vendors, solves the problem of information asymmetry in authorization under the traditional model, and promotes the fairness and long-term stability of cooperation.

[0021] 4. Achieve refined management and flexible control of resources. The solution supports setting the total amount of pre-authorized resources and allocating node-level quotas based on dimensions such as the number of protected instances and time periods. Combined with real-time resource queries and heartbeat monitoring, the usage of authorized resources is clearly controllable, supports billing based on actual usage, and allows cloud vendors to flexibly adjust and reclaim authorized resources according to business needs, thereby achieving optimized resource utilization.

[0022] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. The embodiments of this application will provide a detailed description and understanding of the application. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the architecture of a unified pre-authorization system for cloud WAF in a virtualized environment provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the authorization server unique identifier (device fingerprint) generation mechanism in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the composition of the pre-authorization certificate content in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the business logic of the unified authorization management agent authorizing WAF nodes in this embodiment of the invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] The core architecture of the system described in this invention involves two main roles and two types of nodes, whose relationships are as follows: Figure 1(This diagram illustrates the logical relationships and core interaction processes between the Anquan pre-authorization certificate generation server running within a network security vendor's premises, the Anquan unified authorization management agent deployed in a cloud vendor's environment, and multiple WAF nodes, including certificate issuance, node authorization, and heartbeat detection.) Anquan Pre-authorization Certificate Generation Server: Running within a secure and controlled environment of a network security vendor (such as Anquan Company), it holds the private key for the RSA asymmetric encryption algorithm. It is responsible for generating pre-authorization master certificates for specific "Unified Authorization Management Agents".

[0026] Anquan Unified Authorization Management Agent: Runs in a virtualized environment (such as a specific Linux virtual machine) provided by a cloud vendor or end customer, and holds an RSA public key certificate paired with the aforementioned private key. It is the core execution unit for authorization management, responsible for managing the total pre-authorized resources, and for authorizing, revoking, and monitoring the status of its subordinate WAF nodes.

[0027] WAF nodes: WAF protection virtual machine instances running in a cloud environment are objects that require authorization. They communicate with the unified authorization management agent to obtain authorization and maintain a heartbeat.

[0028] The specific implementation of this solution is described in detail below through several embodiments.

[0029] Example 1: Basic Method Flow This embodiment illustrates the overall process of the unified pre-authorization method.

[0030] See Figure 4 (This diagram details the complete decision-making and execution steps from receiving the authorization request, through resource verification, node status checks, certificate generation and import, to the final database update.) The method includes the following steps: S1. Deployment and Unique Identifier Generation: The cloud vendor prepares a server (virtual machine) in its virtualization platform, deploys and runs the "Unified Authorization Management Agent" program provided by this invention. After the agent starts, it automatically collects the hardware and software information of the server it resides in (see Example 2 for specific collection elements), and generates a globally unique identifier strongly bound to the server environment through a specific algorithm, called license_uuid (i.e., device fingerprint). Then, the agent encrypts and encodes this license_uuid and sends it to the "pre-authorization certificate generation server" running within the security vendor. The sending method can be through secure channels (such as email, secure transmission tools) or through a dedicated API (such as the GET / getDevFinger interface described in Document 1).

[0031] S2. Pre-authorization Certificate Generation and Distribution: After receiving fingerprint information from a specific agent, the security vendor's "pre-authorization certificate generation server" binds the total authorized resources, certificate generation time, and other information to the license_uuid according to the commercial contract (e.g., pre-ordering 100 protection instances * 12 months) to generate a master "pre-authorization certificate." This certificate is digitally signed and encrypted using the security vendor's private key to ensure its authenticity and immutability. After generation, this certificate file (e.g., core_license.lic) is distributed to the cloud vendor's administrator, who then imports it into the corresponding unified authorization management agent.

[0032] S3. Pre-authorized Certificate Verification and Storage: After receiving the pre-authorized certificate file, the unified authorization management agent executes a strict verification process (see Example 3 for details), including integrity verification, decryption, identity matching verification (ensuring the certificate was issued to "itself"), and anti-duplicate import verification. Once all verifications pass, the agent persistently stores the core certificate information (such as certificate UUID, total authorized resource quantity, and effective time) in a local database (e.g., the table `license_file_info`). At this point, the agent obtains a pool of available authorized resources.

[0033] S4. WAF Node Authorization: When a cloud provider needs to activate a new WAF virtual machine, its management platform (or administrator) sends an authorization request to the local unified authorization management agent. The request includes information such as the target WAF node's IP address, the number of protected sites, and bandwidth. After receiving the request, the agent executes decision logic (see Example 4 for details): checking whether its remaining authorization resources are sufficient, whether the target node is already authorized, and whether the target node is online. If all conditions are met, a specific authorization instruction or certificate for the WAF node is generated and sent to the target WAF node. At the same time, this authorization information is recorded in the local database (such as the table license_node_info), and the remaining resource count is updated.

[0034] S5. Heartbeat Status Maintenance: All authorized WAF nodes must maintain periodic heartbeat communication with the unified authorization management agent (see Example 5 for details). WAF nodes periodically (e.g., every 60 seconds) report their status (serial number, IP address) to the agent. The agent queries the database to verify the validity of the authorization and returns the authorization status and expiration time. The WAF node determines whether its authorization remains valid based on the response. This mechanism is used to detect and block authorization bypass attempts through cloning, rollback, etc., in real time.

[0035] Example 2: Server Unique Identifier Generation Mechanism This embodiment details how to generate a strongly bound server unique identifier in step S1.

[0036] The process by which the unified authorization management agent generates its unique server identifier (license_uuid) is a process of fusing multi-source environmental information and performing cryptographic processing, aiming to ensure the uniqueness, stability, and tamper-proof nature of the identifier. The specific steps are as follows (see below). Figure 2 (This diagram visually illustrates how to concatenate and perform calculations on five elements—the business network card MAC address, IP address, processor ID, operating system UUID, and program installation UUID—to ultimately generate a unique identifier, license_uuid.) S201. Information Collection: When the agent program starts, it collects the following five key elements from the host server: Element 1: MAC address of the service network card (6 bytes). It is read from system paths such as / sys / class / net / eth0 / address or / sys / class / net / enp2s0 / address by default, for example, d8:43:ae:3e:6e:fe. The MAC address is the hardware identifier of the network device.

[0037] Element 2: IP address (32-bit) of the service network interface card. Obtain the IPv4 address configured for the aforementioned network interface card.

[0038] Element 3: Processor ID (8 bytes). A unique identifier read from the CPU, such as 71 06 0B 00 FF FBEB BF.

[0039] Element 4: Operating System UUID (128-bit). Read from system files such as / sys / devices / virtual / dmi / id / product_uuid, provided by the virtualization platform or hardware vendor, for example, a9b9bfbc-6ae8-6916-ad05-d843ae3e6efe.

[0040] Element 5: WAF License Installation Package UUID (128-bit). This is a random GUID generated by the installer at a specified path (e.g., / anquanwaf / license / serial) during the installation of the unified license management agent software. For example, it might be 107fbc59-db6a-4333-bb06-e868649bd72a. This file is write-protected once generated to prevent unauthorized modification.

[0041] S202. Information Concatenation: The raw byte data of the above five elements (or after converting them to a unified hexadecimal representation) are concatenated in a fixed order to generate the first string string_1. The concatenation order is: [MAC address (6 bytes)][IP address (4 bytes)][Processor ID (8 bytes)][Operating system UUID (16 bytes)][Installation package UUID (16 bytes)], totaling 50 bytes. The fixed order ensures the determinism of the generation process.

[0042] S203. Obfuscation Operation: To increase the complexity of the original information and prevent the inference of environmental information through simple fingerprint analysis, string_1 is obfuscated byte by byte. In a preferred solution, an XOR operation is used to XOR each byte of string_1 with a fixed value 0xFE to obtain the second string string_2. The technical disclosure document 2 mentions using 0x10, which is an equivalent alternative. The core idea is to perform reversible byte transformation.

[0043] S204. Hash and Final Identifier Generation: Perform a cryptographic hash operation on the obfuscated string_2 to generate a fixed-length, irreversible unique identifier. The SHA-256 algorithm is preferred; calculate the SHA-256 hash value of string_2 to obtain a 64-byte (512-bit) hash value. This hash value is the unique identifier of the current authorization server, license_uuid.

[0044] S205. Encryption and Transmission Preparation: To protect the license_uuid during transmission, it is encrypted using a pre-configured RSA public key. The encrypted binary data is then Base64 encoded and converted to plain text format for secure transmission to the "pre-authorized certificate generation server" via HTTP interface or file. For example, by calling the GET / getDevFinger interface, the response content is the Base64 encoded encrypted fingerprint data.

[0045] Example 3: Generation, Verification, and Storage of Pre-authorization Certificates This embodiment details the generation of the pre-authorization certificate and the verification and storage process on the agent side in steps S2 and S3.

[0046] Part 1: Pre-authorization certificate generation (executed by the pre-authorization certificate generation server) See Figure 3 (This diagram illustrates the data structure of a pre-authorized certificate, which is composed of fields such as the authorization server fingerprint UUID, the number of authorized resources, the authorization time, and the certificate UUID, concatenated sequentially.) The generation process is as follows: S301. Decoding and Decryption: After receiving Base64 encoded data from the agent, the server first performs Base64 decoding to obtain encrypted binary data. Then, it uses the RSA private key, which is kept securely by the security vendor, to decrypt the data and restore the agent server's original license_uuid (i.e., the 64-byte SHA256 hash value).

[0047] S302. Constructing the certificate data body: The server prepares to generate the payload data for the certificate.

[0048] The total pre-authorized resources agreed upon in the business agreement (e.g., 100 instances per month) are converted into a 4-byte integer. This integer is then converted to network byte order (big-endian), and then XORed byte-by-byte with 0xFE to obtain the processed 4-byte resource amount data.

[0049] Get the current system time and generate an 8-byte time_t timestamp to represent the certificate generation time.

[0050] Generate a new, random 128-bit UUID as the unique identifier for this pre-authorized certificate, cert_uuid.

[0051] The three parts of data mentioned above—[4 bytes of processed resource size], [8 bytes of timestamp], and [16 bytes of cert_uuid]—are appended sequentially to the decrypted license_uuid (64 bytes) to form the plaintext data body of the certificate, called the third string string_3. The total length of string_3 is 64 + 4 + 8 + 16 = 92 bytes.

[0052] S303. Encryption and Integrity Protection: To ensure the confidentiality and integrity of the certificate, the following steps shall be taken: Encrypt string_3 using the RSA private key to obtain the encrypted data block string_4.

[0053] Calculate the SHA-256 hash value of string_4 to obtain the 64-byte integrity check code string_5.

[0054] Concatenate string_4 and string_5 together to form string_6 (string_4 + string_5).

[0055] S304, Final Encoding: Base64 encoding the string_6 to generate the final, text-based pre-licensed certificate file content. This content can be written to a file such as core_license.lic.

[0056] Part Two: Pre-authorized Certificate Verification and Storage (Executed by the Unified Authorization Management Agent) S311. Decoding and Segmentation: After receiving the core_license.lic file, the agent first performs Base64 decoding to obtain string_6. According to the convention, the first 256 bytes of string_6 (corresponding to the typical output length of RSA 2048-bit private key encryption) are the encrypted data string_7, and the remaining 64 bytes are the checksum string_8.

[0057] S312, Integrity Verification: Calculate the SHA-256 hash value of string_7 and compare the result byte-by-byte with the received string_8. If they are not equal, it is determined that the certificate has been tampered with during transmission or storage, the import process is immediately terminated, and a "data tampered with" error is returned.

[0058] S313. Decryption and Parsing: After integrity verification, the RSA public key stored locally by the agent is used to decrypt string_7, resulting in string_9 (i.e., 92 bytes of plaintext data). string_9 is then parsed according to a predefined format. The first 64 bytes: license_uuid_remote (the target server identifier claimed by the certificate).

[0059] The following 4 bytes: the total amount of resources after processing.

[0060] The following 8 bytes: Certificate generation timestamp.

[0061] The last 16 bytes: cert_uuid (unique certificate number).

[0062] S314. Identity Matching Verification: The agent calculates its current environment's license_uuid (using the same method as in Example 2) and compares it with the decrypted license_uuid_remote. If they do not match, it means that the certificate was not issued to the current agent server, and the import fails. This prevents the certificate from being copied and used on other machines.

[0063] S315. Anti-duplicate import verification: The agent queries the license_file_info table in the local database to check if the cert_uuid already exists. If it exists, it means that the certificate has been successfully imported, and duplicate imports are prohibited to avoid redundant resource calculations.

[0064] S316. Data Storage: After all verifications are successful, the agent stores the certificate's valid information in the `license_file_info` table of the local MySQL database. The table structure is shown in Document 1, and key fields include: `dev_key` (stores its own `license_uuid` or the `license_uuid_remote` from the certificate), `license_uuid` (stores the `cert_uuid`), `create_time` (certificate generation time), and `limit` (total authorized resources). Simultaneously, the agent initializes the "remaining authorized resources" in memory, whose value is equal to the value of the `limit` field (obtained by XORing 4 bytes of resource data with 0xFE and converting to host byte order).

[0065] Example 4: WAF Node Authorization Decision Logic This embodiment combines Figure 4 This section details the internal decision-making process of the unified authorization management agent when handling authorization requests from WAF nodes.

[0066] When an agent receives an authorization request via an API interface (such as POST / api / authorization), the request body contains information such as the target WAF node's IP address, port, authorization cycle (in months), number of protected instances (protects), and number of sites (sites). The agent judges and processes the request according to the following logic: S401. Total and Remaining Resource Query: The agent queries the license_file_info table to obtain the total number of authorized resources (total_lic_resource). Then, it queries the license_node_info table, sums up the resources consumed by all unexpired license records (expire_date > current time) (e.g., protects * cycle), and subtracts the consumed resources from the total number of resources to calculate the current remaining number of authorized resources (rest_lic_resource).

[0067] S402. Check the existing authorization status of the target node: Using the IP address and other conditions in the request, the agent queries the `license_node_info` table to check if the target WAF node already has an authorization record. If a record exists, and its authorization expiration time (`expire_date`) is more than one month from the current time (or other set thresholds), the node is determined to be "already authorized and has a long remaining time," and there is no need to re-authorize it. At this time, the message "The current WAF node is already authorized, and re-authorization is not possible" is returned, and the process ends. This check prevents unnecessary duplicate authorization of the same node.

[0068] S403. Check target node network connectivity: The agent attempts to establish a network connection (such as a TCP handshake) with the IP address and port of the target WAF node specified in the request. If the connection fails, it indicates that the target node may not be running or the network is unreachable, and authorization cannot be delivered in this case. The system returns the message: "The target WAF node is currently offline and authorization cannot be performed at this time," and the process ends.

[0069] S404. Check if remaining resources are sufficient: Calculate the amount of resources required for this authorization request, for example, required resources = protects * cycle. Compare the required resources with the rest_lic_resource calculated in step S401. If the required resources > rest_lic_resource, it indicates that the resource pool is insufficient, and the following message is returned: "Insufficient remaining authorization resources, authorization failed," and the process ends.

[0070] S405. Generate and issue WAF node certificates: The agent will begin the authorization operation if and only if all the above checks are passed (node ​​is not authorized / authorization is about to expire, node is online, resources are sufficient).

[0071] Generate Node Certificate: The agent generates an authorization credential for the WAF node. This credential may include: Authorized Node ID (which can be generated by the agent or use the WAF node's own serial number), Authorized IP, Number of Protected Instances, Number of Sites, Authorization Start Time (issue_date), and Authorization Expiration Time (expire_date, calculated from cycle), etc. This credential may be encrypted using a key agreed upon between the agent and the WAF node (such as an AES key).

[0072] Importing Node Certificates: The agent sends the generated node certificate to a specific interface of the target WAF node via a secure channel (such as HTTPS). Upon receiving the certificate, the WAF node decrypts and verifies it, then writes the authorization information locally. If the WAF node returns a successful import, the process continues; otherwise, the agent records "Authorization certificate import failed," and the entire authorization process is rolled back.

[0073] S406. Update Local Authorization Records: After the node certificate is successfully imported, the agent inserts a new record into the license_node_info table in the local database. The record fields include: id (WAF node serial number), ip, Instances (number of protected nodes), months (number of authorized months), issue_date, expire_date, etc. (as shown in the table structure in Document 1).

[0074] At the same time, update the value of rest_lic_resource in memory and / or persistent storage: rest_lic_resource = rest_lic_resource - required resources.

[0075] This concludes a complete WAF node authorization process. Cloud vendors' management platforms can use this interface to automate and batch authorize WAF nodes.

[0076] Example 5: Heartbeat Detection Mechanism This embodiment details the real-time heartbeat detection mechanism used to prevent bypass in step S5.

[0077] The heartbeat mechanism is key to preventing the abuse of authorization in this invention. Its protocol interaction format is described in Section 3.5 of Document 1.

[0078] S501. Heartbeat Request Initiation: Each authorized WAF node starts a scheduled task in the background to periodically (e.g., every 60 seconds) send a request to a specific heartbeat interface (such as GET / heartbeat?sn=... or POST / heartbeat) of the unified authorization management agent. The request must carry information that can uniquely identify itself, including at least: UUID or SN: The unique serial number of this WAF node, generated during WAF software installation or generated from hardware information.

[0079] IP: The management IP address currently used by this WAF node. This IP address should match the IP address recorded during authorization.

[0080] S502, Heartbeat Request Processing and Response: After the unified authorization management agent receives a heartbeat request: Extract the SN and IP address from the request.

[0081] Use the SN and IP address as query criteria to retrieve the license_node_info table from the local database.

[0082] If no matching, non-expired authorization record is found, a response is constructed with the status field set to false.

[0083] If a matching authorization record is found, a success response is constructed, in which the status field is true and includes information such as instances (number of protected nodes), issue_date (authorization time), and expire_date (authorization expiration time).

[0084] S503, WAF Node Authorization Status Determination: After receiving the agent's heartbeat response, the WAF node determines its own authorization status according to the following logic: Under normal circumstances: the response status is true, the expire_date in the response matches the expiration time stored locally on the node, and the current time has not exceeded expire_date. At this time, the node considers the authorization valid, updates the timestamp of the last successful heartbeat, and waits to initiate the request again in the next cycle.

[0085] Abnormal situations: If any of the following situations occur, the WAF node will immediately determine that the authorization heartbeat is abnormal, switch itself to "unauthorized state", stop providing protection services or enter degrade mode: a. Network error: Unable to connect to the unified authorization management agent (timeout or connection refused).

[0086] b. Invalid Authorization: The status field in the response returned by the agent is false. This indicates that the node has no valid authorization in the agent's authority record (it may have been revoked).

[0087] c. Inconsistent or expired information: The expire_date returned by the agent is inconsistent with the locally stored one (possibly due to the agent-side record being repaired or rolled back), or the current time has exceeded the returned expire_date.

[0088] S504, Anti-Bypass Principle: This heartbeat mechanism effectively handles various bypass scenarios: Virtual machine cloning: The cloned WAF virtual machine has the same SN, but it sends heartbeats to the agent. Since the authorization record is bound to the original IP, the heartbeat of the cloned machine will either fail due to the different IP (status: false) or expose an anomaly due to SN conflict.

[0089] Modifying IP address: If an authorized WAF node modifies its IP address, the IP field in its heartbeat request will not match the database record, resulting in status: false.

[0090] Authorization Agent Virtual Machine Rollback: If the cloud provider rolls back the virtual machine running the agent to an earlier snapshot (when there were more resources available), the issue_date and expire_date carried in the WAF node's heartbeat request may not match the records in the agent database after the rollback, resulting in authorization anomalies.

[0091] Authorization records have been tampered with: Any unauthorized modification to the agent's local database may be detected by the WAF node through inconsistencies in the heartbeat response.

[0092] This stateful, periodic, two-way verification ensures the real-time nature and authenticity of the authorization status.

[0093] Example 6: Authorization Revocation and API Interface This embodiment is used to illustrate the authorization revocation function and the standardized interfaces provided by the system.

[0094] S601. Authorization Revocation Process: When a cloud provider needs to release the authorization of a WAF node (e.g., due to virtual machine destruction or service shutdown), it calls the authorization revocation interface provided by the unified authorization management agent (e.g., POST / api / Unauthorization). The request body contains the identification information of the target WAF node, such as its IP address.

[0095] After the agent receives the revocation request: Based on information such as IP address, locate the corresponding authorization record in the license_node_info table.

[0096] Calculate the resources consumed by this record (e.g., the number of months elapsed from issue_date to the current time, used_months, multiplied by Instances). Alternatively, under a simpler billing model, mark the record as invalid without immediately releasing resources, and calculate the cost during monthly or periodic billing. In models requiring real-time resource release, add used_months * Instances back to rest_lic_resource.

[0097] To update this authorization record: you can change expire_date to the current time, or delete the record directly (logical deletion is recommended, and a status flag should be set to retain audit logs).

[0098] The operation returns a successful status. Afterward, when the WAF node sends a heartbeat again, it will receive a `status: false` response, thus entering an unauthorized state.

[0099] S602, System API Interface Overview: The unified authorization management agent, as an HTTP service, provides a series of RESTful APIs for cloud vendor management platforms to integrate and call, enabling automated management. Obtain device fingerprint: GET / getDevFinger. Used during initial deployment to provide the security vendor with the fingerprint needed to generate a pre-authorized certificate.

[0100] Import Pre-license Certificate: POST / uploadLicense. This command imports the master pre-license certificate file (core_license.lic) issued by the security vendor into the system. The request must be in multipart / form-data format, and the file field name must be core_license.

[0101] WAF Node Authorization: POST / api / authorization. The request format is JSON, containing fields such as IP, port, cycle, protecteds, sites, and customer, used to authorize a specified WAF node.

[0102] WAF Node Authorization Revocation: POST / api / Unauthorization. The request format is JSON, containing identifier fields such as IP address, used to revoke the authorization of the specified node.

[0103] WAF node heartbeat: GET / heartbeat?sn=... or POST / heartbeat. This interface is exclusively for WAF nodes to call for real-time authorization status verification and should not be exposed to cloud vendor management platforms.

[0104] These standardized interfaces enable cloud vendors to easily integrate this licensed solution into their automated operations and maintenance platforms.

[0105] Example 7: Data Storage, Auditing, and Billing Support This example illustrates the design of localized data storage and its key role in auditing and billing.

[0106] S701, Database Storage Design: The unified authorization management agent persistently stores all critical data in a local MySQL database, typically at / usr / local / ncaf / mysql / . Key data tables include: The license_file_info table stores metadata about the total pre-authorized certificates. Each record represents one imported certificate. Fields include the certificate's unique ID, the corresponding device fingerprint, the total resource limit, and the import time. This table is the authoritative source of the total resource limit.

[0107] The license node table (license_node_info) stores detailed information about all authorized WAF nodes. Each record represents a WAF node currently consuming resources. Fields include node ID, IP address, number of protected instances, authorization duration, issuance time, and expiration time. This table is the authoritative record of resource consumption.

[0108] Operation Log Table (not explicitly defined in the documentation, but essential for comprehensive auditing): Records all operations performed through the API interface, such as the request time, source IP, operation parameters, and execution results for authorization and revocation operations. This table is used for security auditing and troubleshooting.

[0109] S702. Resource Statistics and Billing Calculation: Based on the above database, accurate and indisputable resource statistics and cost calculation can be performed. From the security vendor's perspective: During the billing cycle, security vendors can request cloud vendors to provide data exported from the `license_file_info` and `license_node_info` tables (or access it through a security audit interface) to independently verify the total amount of authorized resources actually consumed by the cloud vendor (sum(Instances * months)) and compare it with the contract. This breaks down information asymmetry and ensures that billing is based on evidence.

[0110] On the cloud vendor side: Cloud vendors can also use this data to accurately bill their end customers. The customer field in the license_node_info table (if designed with extensions) can be directly associated with sub-customers, enabling multi-tenant billing.

[0111] S703, Operational Auditing and Trustworthiness: All authorization and revocation operations are meticulously recorded in the database and logged. These logs are immutable (under the system security assumption), providing electronic evidence of the trustworthiness of the authorization service. In the event of a dispute, the complete record of every resource allocation and release can be traced, clarifying responsibility.

[0112] In summary, this invention constructs a unified pre-authorization solution for WAF that is adaptable to cloud environments, efficient, fair, and resistant to bypass by introducing a unified authorization management agent, designing a strongly bound device fingerprint, a secure certificate chain, real-time status heartbeats, and complete localized audit logs. Those skilled in the art can modify or substitute the above embodiments without departing from the principles of this invention, and such modifications or substitutions should be considered to fall within the protection scope of this invention.

[0113] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

[0114] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A unified pre-authorization method for cloud WAF in a virtualized environment, characterized in that, The method includes the following steps: S1. Deploy and run a unified authorization management agent in the virtualization environment provided by the cloud vendor. The unified authorization management agent generates a unique identifier for the server based on the hardware and software information of the server it is located on, and sends the unique identifier to the pre-authorization certificate generation server running inside the network security vendor. S2. The pre-authorized certificate generation server receives the unique identifier, generates a pre-authorized certificate based on the unique identifier, the total amount of pre-authorized resources and the certificate generation time, and sends the pre-authorized certificate to the unified authorization management agent. S3. The unified authorization management agent receives and verifies the pre-authorized certificate, and stores the certificate information in the local database after successful verification. S4. When the cloud provider needs to authorize the target WAF node, it sends an authorization request to the unified authorization management agent. The unified authorization management agent queries the remaining authorization resources in the local database according to the authorization request, and when the resources are sufficient and the target WAF node meets the authorization conditions, it generates authorization information for the target WAF node and sends the authorization information to the target WAF node. S5. The unified authorization management agent establishes a periodic heartbeat detection mechanism with each authorized WAF node, and verifies the authorization status of each WAF node in real time through the heartbeat detection mechanism.

2. The method according to claim 1, characterized in that, In step S1, generating the unique identifier for the server specifically includes: Collect the MAC address, IP address, processor ID, operating system UUID, and UUID generated by the WAF installation program of the service network card in the server; The collected information is concatenated into a first string according to a predetermined order; Perform a byte-by-byte XOR operation on the first string to obtain the second string; The second string is hashed to obtain a hash value that serves as the unique identifier of the server.

3. The method according to claim 1 or 2, characterized in that, In step S2, generating the pre-authorization certificate specifically includes: The received unique identifier is decoded and decrypted to obtain the original unique identifier data; After the pre-authorized total resource information is formatted and processed, it is appended sequentially to the original unique identifier data along with the certificate generation time and the certificate UUID generated for the current certificate to form a third string; The third string is encrypted to obtain the fourth string; Perform a hash operation on the fourth string to obtain the fifth string; The fourth string and the fifth string are concatenated and encoded to generate the final pre-authorization certificate.

4. The method according to claim 1, characterized in that, In step S3, verifying the pre-authorized certificate specifically includes: The received pre-authorization certificate is decoded and divided into encrypted data and verification data. Calculate the hash value of the encrypted data portion and compare it with the verification data portion to verify data integrity; If the data is complete, the encrypted data portion is decrypted to obtain plaintext data containing the server's unique identifier, total resources, and certificate UUID. The decrypted server unique identifier is compared with the locally generated server unique identifier to verify the certificate's compatibility with the current server. The local database was queried to confirm that the certificate UUID had not been imported repeatedly.

5. The method according to claim 1, characterized in that, In step S4, after receiving the authorization request, the unified authorization management agent performs the following judgment process: Query the local database to calculate the number of remaining authorized resources; Check if the target WAF node already has an authorization record and if the authorization is still valid; Detect network connectivity with the target WAF node; The authorization operation is performed when there are sufficient remaining authorized resources, the target WAF node is not authorized or its authorization has expired, and the network connectivity is normal.

6. The method according to claim 1, characterized in that, In step S5, the heartbeat detection mechanism specifically includes: Authorized WAF nodes periodically send heartbeat requests to the unified authorization management agent. The heartbeat request contains at least the unique sequence number and IP address of the WAF node. The unified authorization management agent queries the corresponding authorization record in the local database based on the received heartbeat request, and returns response information including authorization status and authorization expiration time to the WAF node; The WAF node determines whether its authorization status is valid based on the received response information.

7. The method according to claim 6, characterized in that, The WAF node will enter an unauthorized state if any of the following conditions are met: The unified authorization management agent cannot connect; The response information returned by the unified authorization management agent indicates that the authorization status is invalid; The authorization expiration time returned by the unified authorization management agent is inconsistent with the local record of the WAF node or has expired.

8. The method according to claim 1, characterized in that, The method also includes an authorization revocation step: The unified authorization management agent receives authorization revocation requests for the target WAF node; Based on the revocation request, delete or update the authorization record of the corresponding target WAF node in the local database, and release the corresponding authorization resources.

9. The method according to claim 1, characterized in that, The unified authorization management agent receives the authorization request and authorization revocation request through a predefined API interface, which includes at least the / api / authorization interface for node authorization and the / api / Unauthorization interface for node authorization revocation.

10. The method according to claim 1, characterized in that, The unified authorization management agent stores pre-authorized certificate information, WAF node authorization records, and authorization operation logs in a local database for resource statistics, billing calculation, and operation auditing.

Images