A privacy-computing-oriented scalable data fine-grained access control system

Abstract

The application realizes a privacy computing oriented scalable data fine-grained access control system through a method in the field of network security. A complete functional system is formed by setting three parts of a management center service, a high-availability agent and a data agent service. The management center service is managed by an administrator, sets a management authentication user, manages a security protection strategy, and issues a rule strategy to the data agent service and the high-availability agent. The high-availability agent is forwarded to the database agent service through an agent port. The data agent service is serially arranged between a business system and a database to control access of the business system to the database. The system provided by the application realizes horizontal expansion of data access control capability under high-concurrency database requests through a mode of dynamically increasing the database agent service. The system realizes more fine access control of the database by a business system or a database administrator through deep analysis of SQL.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a scalable, fine-grained data access control system for privacy computing. Background Technology

[0002] Before processing data, privacy computing platforms often need to cache the data in a local database. However, during operation and maintenance, this sensitive data may be accessed by database administrators or third-party database maintenance personnel. This system intersects between the privacy computing platform and the database, implementing access control for database requests to protect sensitive data. Furthermore, privacy computing platforms are often deployed on open networks, exchanging data and performing computations with remote privacy nodes, making them vulnerable to attacks and intrusions from the internet, posing significant data security risks. This system can also address these issues through access control and abnormal behavior analysis.

[0003] Current database access control technologies primarily employ a single-machine or master-slave setup, interleaved between the business system and the database, to perform authorization checks on each database request. This approach requires manually adding new control nodes as the load increases, hindering rapid scaling. This system, however, supports cloud deployment and can dynamically scale to support access control for a large number of database requests. Furthermore, existing access control policies mainly focus on destination IP address, database name, table, and field, lacking more granular access control such as source IP address and time window. Finally, this system supports deep parsing of various database protocols, including traditional and large databases, and possesses attack script detection capabilities to prevent security incidents such as non-compliant data usage and malicious theft.

[0004] Current database security protection technologies have the following shortcomings:

[0005] 1) When the database request access load suddenly increases, it is often impossible to expand the capacity in time to support a large number of access requests.

[0006] 2) It is difficult to implement fine-grained access control for user database connection requests, such as control over database fields, source IP addresses, and time dimensions. This makes it impossible to meet flexible and ever-changing access control requirements.

[0007] 3) Currently, such systems support relatively few database protocols and lack deep protocol parsing and abnormal behavior analysis capabilities. This system, however, supports many mainstream relational database and non-relational database protocols, as well as big data platform protocols. Furthermore, through deep protocol parsing, it can reconstruct content and, based on built-in abnormal behavior detection scripts, can issue alerts for non-compliant operations and attack behaviors. Summary of the Invention

[0008] To this end, the present invention first proposes a scalable fine-grained data access control system for privacy computing, which consists of three parts: a management center service, a high-availability agent, and a data agent service, forming a complete functional system. The management center service is managed by the administrator and includes three functional modules: setting up management authentication users, managing security protection policies, and distributing policy rules to the data agent service and the high-availability agent.

[0009] The high-availability proxy component uses a horizontally scalable technical deployment scheme. Database administrators and business systems send and receive data packets for accessing the database, which are then forwarded to the database proxy service through the proxy port.

[0010] The data proxy service is configured with a proxy layer and a control layer structure. It runs between the business system and the database, receives request messages from the business system to access database assets, analyzes the message content, and controls the business system's access to the database in conjunction with the security access policy.

[0011] The specific architecture of the high-availability proxy service is as follows: it adopts a horizontally scalable deployment scheme to handle high-concurrency data requests, and realizes policy parsing and data request forwarding. The specific process of policy parsing is as follows: it parses the port mapping policy rules issued by the management center service, and starts the port mapping proxy process according to the content of the policy rules. The specific process of data request forwarding is as follows: according to the proxy port mapping rules, it forwards the received data requests to the port of the destination host, thus completing the data request forwarding.

[0012] Meanwhile, under high concurrency load, by monitoring the load of the keepalived nodes of the proxy service, the keepalived nodes and proxy nodes are dynamically added, and a large number of new database connection requests are forwarded to the newly added data proxy service nodes, so as to enable the data proxy service to support high concurrency database requests.

[0013] By analyzing the messages of business systems accessing the database through data proxy services, more granular data access control can be achieved. Combined with fine-grained access control policies, more precise control can be achieved down to the table field level and time dimension.

[0014] After receiving connection request messages from business systems, the database proxy service parses the message content and extracts the SQL script and user information. It then parses the SQL script to obtain database operation instructions, target database, table, and field information, and combines this information with security access control policies issued by the management center to control database access.

[0015] The specific method for dynamically adding keepalived nodes and proxy nodes, and forwarding a large number of new database connection requests to the newly added data proxy service nodes, is as follows: First, the data proxy service is encapsulated into a Docker container: the keepalived service is encapsulated in a container for rapid deployment when adding keepalived nodes; then, the Docker container is published: the container is published to the cloud platform for use in the next step of dynamically adding proxy service nodes; next, keepalived load metrics are set: a load value is set for the keepalived nodes. When the load data of a node approaches this metric value, it indicates that the current node is under high pressure and no longer accepts new connection requests; then, the keepalived load is checked cyclically: the high-availability proxy service checks the load of the keepalived nodes cyclically to determine whether the load requirement has been met. When each node reaches the specified load value, a new keepalived node needs to be added to share the connection request pressure; then, proxy service nodes are added: the Docker container is downloaded from the cloud service, started, and deployed as a new keepalived node; finally, forwarding rules are set: the new database connection requests are distributed to the new keepalived nodes to share the connection pressure of the proxy service. Regularly check the load of keepalived nodes to ensure the agent service is working stably.

[0016] The specific method for controlling database access using the security access control policies issued by the management center service is as follows: After receiving the request message from the business system, it is implemented through twelve steps. Step one is that the proxy service first receives the connection data request message from the business system and reads the entire content of the message. Step two is parsing the message content: after obtaining the entire message content, it parses the message content to obtain the database request content. Step three is extracting operation database information: through analysis of the requested database content, it extracts the SQL script and operation user from the message, parses the SQL script, and obtains the operation database instructions, target database, table, and field information from the script. Step four is traversing security access policies: it iterates through the security protection policies issued by the central server, matching the policies with the content in the database request information. Step five is filtering policies by username: matching policies based on the username in the request information; if a match is found, proceed to the next step. Step six is ​​filtering policies by database name: filtering by database name based on the database name in the request information. The process involves several steps: Step 7: Filtering strategies by table name in the request information. If a match is found, proceed to the next step. Step 8: Filtering strategies by field name in the request information. If a match is found, proceed to the next step. Step 9: Verifying strategy matching. Validating the strategies matched by filtering in steps 5 through 8. If a match is found, proceed to the next step. Step 10: Verifying time matching. Verifying the time required by the strategy based on the current time. If a match is found, the current strategy is successful, and the pass / block result specified in the current strategy is returned to the proxy layer for processing. Step 11: Generating a blocking message. If the strategy blocks the current request, a blocking message is generated and returned to the business system. Step 12: Sending the original message to the database. If the strategy allows the current request, the original message is sent to the database to complete the business request.

[0017] The data proxy service, acting as a database proxy service, runs between the business system and the database. Internally, it comprises two modules: a proxy layer and a control layer. The proxy layer parses request messages, provides the information within to the control layer, and, upon receiving the control result, generates blocking messages and reassembles de-identified messages according to protection requirements. These messages are then fed back to the business system and the database system, completing the access control process. The control layer analyzes user database operations. Based on security policies, it first authenticates the legitimacy of the logged-in user's actions. If the user is legitimate, it performs security verification on the user's actions. After successful security verification, it performs de-identification detection and finally checks the operation script for high-risk scripts to verify whether the script contains any violations.

[0018] The proxy layer functions specifically as follows: parsing data request messages and generating blocking messages. The data request message parsing function receives request messages from the business system, parses the structure of the request message according to each database communication message protocol, and reads the operation information within the message. This information is then provided to the control layer for processing. The blocking message generation function, after receiving the blocking result from the control layer, generates an error message based on the result content and following the database communication protocol, simulating the database side. The new message information is then returned to the business system by the proxy layer, blocking the business system's request message to the database.

[0019] The control layer functions specifically include: user authentication, access control, high-risk script detection, and access log generation. The user authentication function authenticates logged-in users independently of the database service, without referencing database user information, and verifies the user entirely according to the security policies set by the administrator. The specific process is as follows: After receiving a request message from the business system to access the database, the database proxy service parses the message, extracts information about database operations, iterates through local policies, and matches local security access policies using the user, target database, table, and field information as filtering conditions. If a policy is found, it verifies whether the current time matches the policy. If a match is found, the processing result required by the policy is sent to the proxy for processing the request. If no matching policy is found, the system's default policy rules are applied. Next, high-risk script detection checks the security of database request scripts, detecting dangerous operations such as SQL injection, database breaches, and credential stuffing attacks, and sends the detection results to the proxy layer to block the request message, protecting database data security. Finally, access log generation generates database access logs, which are then cached locally as structured data.

[0020] The technical effects to be achieved by this invention are as follows:

[0021] This technical solution employs highly available load balancing technology, combined with port forwarding technology, and achieves horizontal scaling of data access control capabilities under high-concurrency database requests by dynamically adding database proxy services.

[0022] This invention performs deep analysis of SQL to obtain information such as databases, tables, and fields, enabling control over user operations on databases, tables, and fields. It also proposes access control based on more dimensions such as source IP address and time, allowing for access control at different points in time. This enables more refined access control for business systems or database administrators.

[0023] This system supports deep parsing of various database message protocols, including relational databases, non-relational databases, industrial time-series databases, emerging big data databases, and blockchain communication protocols. The system also includes built-in high-risk detection scripts to block and alert on attack attempts. Attached Figure Description

[0024] Figure 1 The specific process of the system constituted by the control methods;

[0025] Figure 2 High-availability proxy architecture (see attached diagram);

[0026] Figure 3 Methods for dynamically adding keepalived nodes and proxy nodes;

[0027] Figure 4 Database access control methods based on security access control policies issued by the management center service Detailed Implementation

[0028] The following are preferred embodiments of the present invention, which are described in conjunction with the accompanying drawings. However, the present invention is not limited to these embodiments.

[0029] This invention proposes a scalable, fine-grained data access control system for privacy-preserving computing.

[0030] This method consists of three parts: management center service, high availability agent, and data agent service, forming a complete functional system.

[0031] The management center service settings module for managing and authenticating users is responsible for maintaining users who access the database, managing security protection policies, and distributing policy rules to the data proxy service and the high availability proxy.

[0032] High-availability proxy: It uses a horizontally scalable technology deployment solution to solve the problem of high data concurrency, receives data packets that access the database, and forwards them to the database proxy service through the proxy port;

[0033] Data Proxy Service: As a database proxy service, it runs between the business system and the database. High-concurrency requests can be handled by adding proxy service nodes. The data proxy service is responsible for receiving request messages from business systems to access database assets, analyzing the message content, and controlling business system access to the database based on security access policies.

[0034] First, the administrator configures security access policies on the management center service. These policies are then distributed to the high-availability proxy and data proxy services. The database proxy service parses database requests and provides the parsed content to the control layer to check the business system's access permissions to the database. Based on the detection results, it decides whether to forward the packet to the database or block the request. The data proxy service also collects database access logs during the control process and sends them to the auditing service via a message queue. The specific process is as follows: Figure 1 As shown.

[0035] Data Proxy Service: As a database proxy service, it runs between the business system and the database. Its functions include: policy parsing, data request message parsing, generating blocking messages, user authentication, access control, high-risk script detection, generating access logs, and log distribution. First, the database proxy service's policy parsing function parses and loads the security access policies issued by the central service, providing them to the control layer to control database requests received by the access layer. 1) Proxy Layer: Responsible for parsing request messages, providing the information in the messages to the control layer, generating blocking messages according to protection requirements, reassembling de-identified messages, and feeding them back to the business system and database system to complete the access control. 2) Control Layer: Responsible for analyzing user database operation behavior, first authenticating the legitimacy of logged-in user operations according to security policies. If the user is legitimate, then performing security verification on the user's operation behavior. After passing security verification, performing de-identification detection, and finally performing high-risk script detection on the operation script to verify whether the script contains illegal operations. After the above detection process, the detection results are obtained and fed back to the proxy layer, which then performs operations such as sending, blocking, and modifying request messages.

[0036] Proxy Layer Functions: Data request message parsing and blocking message generation. 1) Data Request Message Parsing: Receives request messages from the business system, parses the message structure according to the database communication protocol, and reads the operation information such as username, database name, request SQL, and database operation type (currently supported databases include: MySQL, MariaDB, OceanBase, Gauss, MongoDB, Oracle, PostgreSQL, DM, SQL Server, DB2, Hive, Impala, and HDFS). This information is provided to the control layer for processing. 2) Blocking Message Generation: Upon receiving the blocking result from the control layer, the proxy layer generates an error message based on the result content and following the database communication protocol, simulating the database side. The new message information is then returned to the business system, blocking the business system's database request message.

[0037] The control layer functions include: user authentication, access control, high-risk script detection, and access log generation; 1) User authentication: Authenticating logged-in users and verifying the validity of their identities. This authentication is independent of user authentication on the database service, does not refer to database user content, and is verified entirely according to the security policies set by the administrator. The specific process is as follows: After receiving the connection data request message from the business system, the database proxy service parses the message content, extracts the user information and database information from the connection message, and then uses the security protection policy issued by the central server to authenticate the user's validity. If the user is valid, the login request message is forwarded to the database; otherwise, an invalid user authentication message is generated and returned to the business system, blocking the connection; Access control: Verifying user operations on the database, verifying user behavior according to the security policy, and detecting the legality of their database operations through fine-grained security rules. The process is as follows: After receiving the database request message from the business system, the database proxy service parses the message and extracts the information about database operations. The content includes: accessing user, target database, operation script, target database table, and fields. It iterates through local policies, using the accessing user, target database, table, and field information as filtering conditions to match local security access policies. Once a policy is found, it verifies whether the current time matches the policy. If a match is found, the processing result required by the policy is sent to the proxy to process the request; if no matching policy is found, it is processed according to the system's default policy rules. 3) High-risk script detection: Detects the security of database request scripts, identifying dangerous operations such as SQL injection, database breaches, and credential stuffing attacks, and sends the detection results to the proxy layer to block request packets, protecting database data security. 4) Generate access logs: Generates database access logs, including access time, operating user, access IP, proxy port, database type, database server IP, database port, request script, and security protection results. This content is structured and cached locally.

[0038] To meet the high-concurrency access requirements of privacy computing services on the blockchain to government databases, a high-availability proxy service is added before the data proxy service to forward access requests from business systems to different data proxy services. The specific architecture is as follows: Figure 2 As shown.

[0039] High-Availability Proxy: Meets high concurrency requirements, employing a horizontally scalable deployment scheme to handle high-concurrency data requests. Functions include policy parsing and data request forwarding. 1) Policy Parsing: Parses the port mapping policy rules issued by the management center service and starts the port mapping proxy process according to the policy rules; 2) Data Request Forwarding: Forwards received data requests to the destination host's port according to the proxy port mapping rules, completing the data request forwarding.

[0040] Simultaneously, under high concurrency load conditions, the keepalived nodes and proxy nodes are dynamically added by monitoring the load of the keepalived nodes of the proxy service. New, large numbers of database connection requests are then forwarded to the newly added data proxy service nodes, enabling the data proxy service to support high-concurrency database requests.

[0041] The specific process is as follows: Figure 3 As shown: By monitoring the load of the keepalived nodes in the proxy service and dynamically adding keepalived nodes, new database connection requests are forwarded to the newly added data proxy service nodes. This product uses this method to enable the data proxy service to support high-concurrency database requests. Specific process:

[0042] 1) Encapsulate the data proxy service into a Docker container: Encapsulate the keepalived service into a container for rapid deployment when adding keepalived nodes; 2) Publish the Docker container: Publish the container to the cloud platform for use in dynamically adding proxy service nodes; 3) Set keepalived load metrics: Set load values ​​for keepalived nodes. When the load data of a node approaches this metric value, it indicates that the current node is under high pressure and will no longer accept new connection requests; 4) Circularly check keepalived load: The high-availability proxy service circularly checks the load of keepalived nodes to determine whether the load requirement has been met. When each node reaches the specified load value, a new keepalived node needs to be added to share the connection request pressure; 5) Add proxy service nodes: Download the Docker container from the cloud service, start and deploy the new keepalived node; 6) Set forwarding rules: Distribute new database connection requests to the new keepalived node to share the connection pressure of the proxy service. Regularly circularly check the load of keepalived nodes to ensure the stable operation of the proxy service.

[0043] To achieve more granular data access control, it is necessary to analyze the messages of business systems accessing the database through data proxy services, and combine them with fine-grained access control policies to control the data more precisely at the table field level and time dimension.

[0044] After receiving connection request messages from the business system, the database proxy service parses the message content and extracts the SQL script and the user to be operated. It then parses the SQL script to obtain the database operation instructions, target database, table, and field information. Finally, it combines this information with the security access control policies issued by the management center service to control database access.

[0045] The protection process of database proxy services is as follows: Figure 4 As shown:

[0046] 1) Receiving Business System Request Messages: The proxy service first receives the business system connection data request message and reads the entire message content; 2) Parsing Message Content: After obtaining the entire message content, it parses the message content to obtain the database request content; 3) Extracting Operation Database Information: By analyzing the requested database content, it extracts the SQL script and operation user from the message, parses the SQL script, and obtains the database operation instructions, target database, table, and field information in the script; 4) Traversing Security Access Policies: It iterates through the security protection policies issued by the central server and matches the policies with the content in the database request information; 5) Filtering Policies by Username: It matches the policies with the username in the request information; if a match is found, it proceeds to the next step; 6) Filtering Policies by Database Name: It filters the current policies by the database name in the request information; if a match is found, it proceeds to the next step; 7) Filtering Policies by Table 8) Filtering strategy by name: Filter the current strategy by table name in the request information. If a match is found, proceed to the next step of filtering; 9) Filtering strategy by field name: Filter the strategy by field content in the request information to determine if a match is found. If a match is found, proceed to the next step of verification; 10) Verifying strategy match: Verify the strategies matched by the above filtering steps (5-8) to determine if a match is found. If a match is found, proceed to the next step of verification; 11) Verifying time match: Verify if the time required in the strategy matches the current time. If a match is found, the current strategy is successful. The pass or block result specified in the current strategy is returned to the proxy layer as the verification result for processing; 12) Generating blocking message: If the strategy blocks the current request, a blocking message is generated and returned to the business system; 13) Sending original message to database: If the strategy allows the current request, the original message is sent to the database to complete the business request;

[0047] During system operation:

[0048] First, local policies are traversed according to priority, and policies are matched using user, target database, table, and field information as filtering conditions. If a policy is matched, it is verified whether the current time is within the time defined in the policy. If there is no problem, the message is forwarded or blocked according to the policy's defined action. If no matching policy is found, the global default policy is used. If blocking is required, the business request message is intercepted, and an exception message is processed according to the database protocol for this type and sent to the business system. If forwarding is required, the business request message is not processed and is directly forwarded to the database.

[0049] The above process can enrich the in-depth analysis of database protocols and the detection of attack behaviors.

[0050] In terms of database message parsing, this system firstly supports the parsing of mainstream relational databases, such as MySQL, MariaDB, Oracle, DB2, SQL Server, PostgreSQL, DM, and Gauss. Secondly, it also supports the parsing of non-relational databases, such as MongoDB. It further supports the parsing of industrial time-series databases, such as IoTDB and InfluxDB. It also supports the parsing of emerging large-scale databases, such as Hive, HBase, HDFS, and Impala. Finally, it supports the parsing of blockchain communication protocols. In addition, the system includes built-in high-risk detection scripts, such as those for SQL injection, database breaches, and credential stuffing attacks, to prevent database attacks.

Claims

1. A scalable, fine-grained data access control system for privacy-preserving computing, characterized in that: A complete functional system is formed by setting up three parts: management center service, high availability proxy, and data proxy service. The management center service is managed by the administrator and has three functional modules: setting up and managing authentication users, managing security protection policies, and distributing policy rules to the data proxy service and high availability proxy. The high-availability proxy component uses a horizontally scalable technical deployment scheme. Database administrators and business systems send and receive data packets for accessing the database, which are then forwarded to the data proxy service through the proxy port. The data proxy service is configured with a proxy layer and a control layer structure. It runs between the business system and the database, receives request messages from the business system to access database assets, analyzes the message content, and controls the business system's access to the database in conjunction with the security access policy content. The specific architecture of the high-availability proxy service is as follows: it adopts a horizontally scalable deployment scheme to handle high-concurrency data requests, and realizes policy parsing and data request forwarding. The specific process of policy parsing is as follows: it parses the port mapping policy rules issued by the management center service, and starts the port mapping proxy process according to the content of the policy rules. The specific process of data request forwarding is as follows: according to the proxy port mapping rules, it forwards the received data requests to the port of the destination host, thus completing the data request forwarding. Meanwhile, under high concurrency load, by monitoring the load of the keepalived nodes of the proxy service, the keepalived nodes and proxy nodes are dynamically added, and a large number of new database connection requests are forwarded to the newly added data proxy service nodes, so as to enable the data proxy service to support high concurrency database requests. By analyzing the messages of business systems accessing the database through data proxy services, more granular data access control can be achieved. Combined with fine-grained access control policies, more precise control can be achieved down to the table field level and time dimension. After receiving the data connection request message from the business system, the data proxy service parses the message content and extracts the SQL script and operation user from the message; then it parses the SQL script to obtain the database operation instructions, target database, table and field information in the script, and controls database access in combination with the security access control policy issued by the management center service. The specific method for controlling database access using the security access control policies issued by the management center service is as follows: After receiving the request message from the business system, it is implemented through twelve steps. Step one is that the proxy service first receives the connection data request message from the business system and reads the entire content of the message. Step two is parsing the message content: after obtaining the entire message content, it parses the message content to obtain the database request content. Step three is extracting operation database information: through analysis of the requested database content, it extracts the SQL script and operation user from the message, parses the SQL script, and obtains the operation database instructions, target database, table, and field information from the script. Step four is traversing security access policies: it iterates through the security protection policies issued by the central server, matching the policies with the content in the database request information. Step five is filtering policies by username: matching policies based on the username in the request information; if a match is found, proceed to the next step. Step six is ​​filtering policies by database name: filtering by database name based on the database name in the request information. The process involves several steps: Step 7: Filtering strategies by table name in the request information. If a match is found, proceed to the next step. Step 8: Filtering strategies by field name in the request information. If a match is found, proceed to the next step. Step 9: Verifying strategy matching. Validating the strategies matched by filtering in steps 5 through 8. If a match is found, proceed to the next step. Step 10: Verifying time matching. Verifying the time required by the strategy based on the current time. If a match is found, the current strategy is successful, and the pass / block result specified in the current strategy is returned to the proxy layer for processing. Step 11: Generating a blocking message. If the strategy blocks the current request, a blocking message is generated and returned to the business system. Step 12: Sending the original message to the database. If the strategy allows the current request, the original message is sent to the database to complete the business request. The data proxy service, acting as a data proxy, runs between the business system and the database. Internally, it comprises two modules: a proxy layer and a control layer. The proxy layer parses request messages, provides the information within to the control layer, and, upon receiving the control result, generates blocking messages and reassembles de-identified messages according to protection requirements. These messages are then fed back to the business system and the database system, completing the access control process. The control layer analyzes user database operations. Based on security policies, it first authenticates the legitimacy of the logged-in user's actions. If the user is legitimate, it performs security verification on the user's actions. After successful security verification, it performs de-identification detection and finally checks the operation script for high-risk scripts to verify whether the script contains any violations.

2. The scalable fine-grained data access control system for privacy computing as described in claim 1, characterized in that: The specific method for dynamically adding keepalived nodes and proxy nodes, and forwarding a large number of new database connection requests to the newly added data proxy service nodes, is as follows: First, the data proxy service is encapsulated into a Docker container: the keepalived service is encapsulated in a container for rapid deployment when adding keepalived nodes; then, the Docker container is published: the container is published to the cloud platform for use in the next step of dynamically adding proxy service nodes; finally, keepalived load metrics are set: a load value is set for the keepalived nodes. When the node's load data approaches this metric value, it indicates that the current node is under high pressure and will no longer accept new connection requests. Next, the keepalived load is checked cyclically: the high-availability proxy service checks the load of keepalived nodes to determine if the load requirement has been met. When each node reaches the specified load value, a new keepalived node needs to be added to share the connection request pressure. Then, proxy service nodes are added: Docker containers are downloaded from the cloud service, started, and deployed to the new keepalived node. Finally, forwarding rules are set: new database connection requests are distributed to the new keepalived node to share the connection pressure of the proxy service. The load of keepalived nodes is checked periodically to ensure the stable operation of the proxy service.

3. A scalable fine-grained data access control system for privacy computing as described in claim 2, characterized in that: The specific functions of the proxy layer are: parsing data request messages and generating blocking messages; The data request message parsing function receives request messages from the business system, parses the structure of the business system request message according to the communication message protocol of each database, reads the operation information in the message, and provides this information to the control layer for processing. After receiving the blocking result from the control layer, the function generates a blocking message and, based on the result content and following the database communication protocol, simulates the database side to generate an error message. The new message information is then returned to the business system by the proxy layer, blocking the business system's request to the database.

4. A scalable fine-grained data access control system for privacy computing as described in claim 3, characterized in that: The control layer functions specifically include: user authentication, access control, high-risk script detection, and access log generation. The user authentication function authenticates logged-in users independently of the database service, without referencing database user information, and verifies the user entirely according to the security policies set by the administrator. The specific process is as follows: After receiving a request message from the business system to access the database, the data proxy service parses the message, extracts information about database operations, iterates through local policies, and matches the local security access policies using the user, target database, table, and field information as filtering conditions. If a policy is found, it verifies whether the current time matches the policy. If a match is found, the processing result required by the policy is sent to the proxy for processing of this request; if no matching policy is found, the system's default policy rules are applied. Next, high-risk script detection: Detects the security of database request scripts, identifies dangerous operations such as SQL injection, database breaches, and credential stuffing, and sends the detection results to the proxy layer to block request messages, protecting database data security; then, access logs are generated: Database access logs are generated, and this content is cached locally as structured data.

Images