Data access control method and system and storage medium

Abstract

The invention discloses a data access control method and system and a computer readable storage medium. The data access control method is applied to a gateway, the gateway is in communication connection with a client and a server, and the control method comprises the steps that the gateway receives an access request of the client; the gateway judges whether the resource locator of the access request conforms to a preset rule set or not; if yes, data access is controlled according to the access permission corresponding to the rule set; and if the data does not accord with the rule set, executing a preset bottom-taking rule, and controlling data access according to the bottom-taking rule. According to the technical scheme, a protection mechanism can be effectively formed, sensitive data leakage is reduced, and data safety and operation stability are guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, in particular to a data access control method, system and computer readable storage medium. BACKGROUND

[0002] In the existing data access and related network interaction scenarios, the communication process between the client and the server lacks a perfect security protection mechanism. For various access requests initiated by the client, it is often assumed that they have legitimacy and credibility. In this case, whether it is an authorized normal request or an illegal request without access permission, it may be directly passed to the backend server, and the system cannot effectively distinguish whether the request source is legal and the initiator has the corresponding permission.

[0003] At the same time, due to the lack of a unified identity authentication system and request content verification logic, malicious users can easily construct false requests or use the trust mechanism to attempt to access resources beyond their own permission range, or even directly perform illegal operations on the backend service. Once such unauthorized requests successfully bypass the basic protection, sensitive data may be leaked, service functions may be misused, and other risks may occur, which seriously affect the security and stable operation of the data. SUMMARY

[0004] In view of the defects in the prior art, the present application provides a data access control method that can effectively form a protection mechanism, reduce the leakage of sensitive data, and ensure data security and stable operation.

[0005] The data access control method provided by the present application is applied to a gateway, which is in communication connection with a client and a server respectively. The control method comprises:

[0006] The gateway receives an access request from the client;

[0007] The gateway determines whether the resource locator of the access request meets a preset rule set;

[0008] If the rule set is met, the data access is controlled according to the access permission corresponding to the rule set;

[0009] If the rule set is not met, a preset bottom rule is executed, and the data access is controlled according to the bottom rule.

[0010] In one aspect, before the step of determining whether the resource locator of the access request meets the preset rule set, the method comprises:

[0011] Different data accesses are configured with corresponding resource locators;

[0012] A rule set of the resource locator meeting the control requirements is established.

[0013] In one aspect, before the gateway receives the client's access request, it also includes:

[0014] Replace the server address with the gateway address and hide the server address so that the client accesses the gateway address.

[0015] In one aspect, if the steps conforming to the set of rules are followed, the process further includes:

[0016] Determine if the data access matches the cache mapping;

[0017] If a match is found, the access rules corresponding to the cache mapping will be automatically reused;

[0018] If there is no match, the data access is forwarded to the server, which processes the data access according to a preset security policy.

[0019] In one aspect, the security policy includes at least one of establishing a whitelist of allowed access, access traffic rate limiting, and alarm notification.

[0020] In one aspect, the fallback rule includes at least one of re-triggered verification, mandatory two-factor authentication, and encrypted forwarding to the server.

[0021] In one aspect, the control method further includes:

[0022] The content of the access request is scanned and identified according to a pre-set pattern, suspicious content is marked and reported to the server.

[0023] In one aspect, before the gateway determines whether the resource locator of the access request matches a preset set of rules, it includes:

[0024] The gateway determines whether data access includes gateway information.

[0025] If gateway information is included, continue access;

[0026] If the gateway information is not included, the user will be redirected to the login page for authentication. If authentication is successful, the user will be redirected to the customer's business interface and will be able to log in without further assistance for a preset period of time.

[0027] Furthermore, to address the aforementioned issues, this application also provides a data access control system applied to a gateway, which is communicatively connected to both a client and a server. The control system includes:

[0028] The receiving module is used by the gateway to receive access requests from clients;

[0029] The judgment module is used by the gateway to determine whether the resource locator of the access request conforms to a preset set of rules;

[0030] The control module is used to control data access according to the access permissions corresponding to the rule set if the data meets the rule set; otherwise, it executes a preset fallback rule and controls data access according to the fallback rule.

[0031] In addition, to address the aforementioned problems, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned control method.

[0032] The beneficial effects of this invention are reflected in the following: The gateway, acting as an intermediary node between the client and the server, uniformly receives access requests and matches the resource locators of the requests against a preset set of rules. For requests that conform to the rules, access is controlled according to the corresponding access permissions; for requests that do not conform to the rules, a preset fallback rule is executed. This changes the situation in traditional methods where there is a lack of unified verification and lax control over access requests. In other words, an effective access barrier is formed at the gateway layer, preventing unauthorized or non-compliant requests from directly affecting the server, reducing security risks such as malicious proxy bypass, improving the security and controllability of data access, ensuring that access to server resources is under orderly management, reducing sensitive data leakage, and guaranteeing data security and operational stability. Attached Figure Description

[0033] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0034] Figure 1 This is a schematic diagram of the flow steps of the data access control method of this application;

[0035] Figure 2 A schematic diagram illustrating the process steps of pre-configuring resource locators, setting rule sets, and hiding server addresses in the data access control method of this application;

[0036] Figure 3 This is a functional structure diagram of the control system for data access in this application. Detailed Implementation

[0037] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are merely illustrative of the technical solution of the present invention and are therefore intended to limit the scope of protection of the present invention.

[0038] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0039] like Figure 1 As shown, this application provides a data access control method applied to a gateway, primarily used in Web reverse proxies. The gateway communicates with both clients and servers. Clients include user browsers and enterprise applications; access requests include, for example, accessing an enterprise human resources system or financial statements. The control method includes:

[0040] Step S10: The gateway receives the client's access request. In a web proxy scenario, the gateway acts as an intermediary node between the client and the server. Any data access request initiated by the client will first be sent to the gateway, rather than directly to the server. This process is the foundation of all subsequent security controls, ensuring that all communication between the client and the server is relayed through the gateway, preventing requests from bypassing the proxy and directly reaching the server. For example, when a user enters the corporate portal URL into their browser, the request will first be received by the gateway, processed by the gateway, and then forwarded to the corresponding server.

[0041] In step S20, the gateway determines whether the resource locator in the access request conforms to a preset rule set. A resource locator, such as a URL path, is core information identifying data resources. The gateway matches the resource locator in the request with the pre-configured rule set. The rule set is set based on enterprise business needs and includes legitimate access paths for various business systems. For example, preset rules might include " / hr / " (corresponding to the HR system) and " / finance / " (corresponding to the finance system), used to limit which resource locators are compliant. For instance, if the URL requested by the client is " / hr / employee / list", the gateway checks whether the URL matches the preset rule " / hr / *". If it matches, it is determined to conform to the rule set; if the requested URL is " / unknown / path" and there is no corresponding configuration in the rule set, it is determined to be non-compliant.

[0042] Step S30: If the request matches the rule set, control data access according to the access permissions corresponding to the rule set. When the requested resource locator matches a preset rule, the gateway will invoke the access permission policy bound to that rule to achieve differentiated control based on permissions. The access permission policy is set based on dimensions such as user identity and application type. For example, ordinary employees can only access their own personnel information, while administrators can access all employee information. The gateway will verify the identity of the request initiator and allow or restrict access according to permissions. For example, when an ordinary employee requests access to all employee information, the gateway will reject the request according to the access permission policy to ensure that data access complies with the principle of least privilege.

[0043] Step S40: If the request does not conform to the rule set, a preset fallback rule is executed to control data access. When the requested resource locator does not match any preset rule, the gateway will trigger a predefined fallback rule to avoid incomplete rule coverage. The fallback rule aims to provide security for unconventional requests, such as re-triggering identity verification, forcing two-factor authentication, or encrypting and forwarding the request to the backend for special verification. For example, if a client requests a URL without configured rules, the gateway will execute the fallback rule: first, require the user to complete dynamic token verification; only after successful verification will the request be encrypted and forwarded to the backend, while recording the access behavior; if verification fails, the request will be directly intercepted to prevent malicious users from bypassing the proxy and accessing sensitive backend data using paths without configured rules.

[0044] In this embodiment, the gateway acts as an intermediary node between the client and the server. It uniformly receives access requests and matches the resource locators of the requests against a preset set of rules. Requests that conform to the rules are controlled according to the corresponding access permissions, while requests that do not conform to the rules are executed according to preset fallback rules. This changes the situation in traditional methods where there is a lack of unified verification and lax control over access requests. In other words, an effective access barrier is formed at the gateway layer, preventing unauthorized or non-compliant requests from directly affecting the server, reducing security risks such as malicious proxy bypass, improving the security and controllability of data access, ensuring that access to server resources is under orderly management, reducing sensitive data leakage, and guaranteeing data security and operational stability.

[0045] like Figure 2 As shown, before the gateway determines whether the resource locator of the access request matches the preset rule set, it includes:

[0046] Step S01 involves configuring corresponding resource locators for different data access scenarios. Resource locators identify the paths to data resources and need to be configured individually for each scenario. For example, in a company's HR system, different data access operations such as querying employee basic information, viewing salary details, and exporting attendance records require resource locators like " / hr / info", " / hr / salary", and " / hr / attendance", respectively. Similarly, operations in the finance system such as expense reimbursement applications and invoice queries correspond to resource locators like " / finance / reimburse" and " / finance / invoice". By configuring dedicated resource locators for each data access scenario, the data access paths for different business operations can be clearly distinguished, providing accurate identification for subsequent rule matching and access control, and avoiding management loopholes caused by path confusion.

[0047] Step S02: Establish a rule set for resource locators that meet control requirements. After configuring resource locators for different data accesses, these resource locators need to be integrated into a rule set based on the enterprise's security policies, permission systems, and other control requirements. The rule set can be defined through URL prefix matching, parameter format validation, etc. For example, the " / hr / " series of resource locators related to the HR system can be grouped into "HR Access Rules," stipulating that only HR employees can access them; the " / finance / " series of resource locators related to the finance system can be grouped into "Finance Access Rules," restricting access to finance personnel and management. Simultaneously, the rule set must clearly define the compliant format of the resource locators (e.g., prohibiting special characters, limiting parameter ranges, etc.). This enables the gateway to determine whether access requests are compliant based on clear standards, providing an executable basis for subsequent access control and resolving the management chaos caused by scattered rules and inconsistent standards.

[0048] like Figure 2 As shown, before the gateway receives the client's access request, it also includes:

[0049] Step S03 involves replacing the server address with the gateway address to hide the server's address, ensuring that the client accesses the gateway address. This step uses an address replacement mechanism to hide the backend server's real address, ensuring that the client only interacts with the gateway address and cannot directly obtain the backend server's real IP address or domain name.

[0050] For example, the real address of the enterprise's backend HR system server is "192.168.1.100:8080", and the real address of the finance system server is "192.168.1.101:8080". The gateway will uniformly replace these real addresses with the gateway's public address, such as "https: / / gateway.company.com". When a client needs to access the HR system, it enters the address "https: / / gateway.company.com / hr" instead of directly accessing "192.168.1.100:8080"; when accessing the finance system, it enters "https: / / gateway.company.com / finance", and the corresponding backend real address is hidden by the gateway in the internal processing flow.

[0051] This approach fundamentally prevents clients from directly identifying the backend server location through the access address, thus preventing malicious users from bypassing the gateway proxy and directly initiating access requests to the backend server. For example, it prevents the use of leaked real addresses to circumvent the gateway's authentication and permission verification mechanisms. This solves the security risk of backend access being easily compromised due to leaked redirect links, while ensuring that all data access is controlled through the gateway as the sole entry point, thereby strengthening the security protection of the proxy layer.

[0052] In one embodiment of this application, after the steps that satisfy the rule set, the method further includes:

[0053] Step S310: Determine if the data access matches the cache mapping. Cache mapping refers to the association relationship stored by the gateway after binding a user session with a previously matched access rule, such as the corresponding record of a user session identifier and a specific resource locator rule. After the data access matches the preset rule set, the gateway will query the cache to see if there is a rule binding record corresponding to the user session, thereby determining whether the current data access matches the cache mapping. For example, if a user previously accessed " / hr / info" and matched the "HR system access rule", the gateway will bind the user's session ID with the rule and store it in the cache; when the user initiates data access again, the gateway will check whether the current session ID has a corresponding rule record in the cache, thereby determining whether the cache mapping matches.

[0054] Step S311: If a match is found, the access rule corresponding to the cache mapping is automatically reused. When data access matches the cache mapping, the gateway does not need to re-match the resource locator with rules; it directly reuses the access rule bound in the cache to process the current request. For example, if a user first accesses " / hr / info" within the same session (matching the "HR system access rule" and caching the mapping), and subsequently accesses " / hr / salary," because the session ID matches the cache mapping of the "HR system access rule," the gateway will automatically reuse this rule for permission verification and access control, without needing to parse the rule set again. This mechanism reduces redundant rule matching calculations, improves data access efficiency, and ensures that access within the same session always follows a consistent security policy by binding sessions and rules, avoiding security risks caused by missed rule checks.

[0055] In step S312, if there is a mismatch, the data access is forwarded to the server, which processes the data access according to a preset security policy. When data access does not match the cache mapping, the gateway forwards the request to the backend server, which further processes it according to the preset security policy. The security policy includes establishing a whitelist of allowed access, access traffic rate limiting, and alarm notifications, such as allowing only specific IPs or users to access, limiting the number of requests per unit time to prevent malicious attacks, and sending alarms to the administrator when abnormal access occurs. For example, if a user's first access matches the rule set but there is no cache mapping, after the gateway forwards the request to the financial server, the server will verify whether the user is in the whitelist. If not, access is denied, and an alarm is triggered to notify the administrator. This achieves secondary security control for compliant requests without cache mapping, compensating for security protection in scenarios not covered by the caching mechanism.

[0056] In one embodiment, the security policy includes at least one of the following: establishing a whitelist of allowed access, access traffic rate limiting, and alarm notification. Requests forwarded to the server undergo secondary security control. For the whitelist mechanism, for example, only internal enterprise IP addresses or specific user accounts are allowed to access sensitive business systems; requests not on the whitelist are directly rejected by the server, restricting unauthorized access at the source. For traffic rate limiting, for high-frequency request scenarios, a maximum number of requests per IP or user per minute is set, such as a limit of 60 requests / minute, to prevent malicious users from exhausting server resources through batch requests and ensuring service stability. For alarm notification, when the server detects abnormal access, such as attempts by IPs outside the whitelist or request frequencies exceeding the threshold, it immediately sends alarm information to the administrator, such as email or system notification, facilitating timely intervention and handling of potential risks.

[0057] In one embodiment, the fallback rule includes at least one of re-triggering verification, mandatory secondary authentication, and encrypted forwarding to the server. The fallback rule handles requests that do not match the preset rule set, forming a security safety net. For re-triggering verification, when the resource locator of the request does not match a rule, the gateway re-verifies the legitimacy of the request, such as checking the format of request parameters and the validity of user identification. For example, it directly intercepts parameters with abnormal formats to prevent invalid requests from entering the backend. For mandatory secondary authentication, for unmatched requests related to sensitive operations, such as accessing an internal document library without configured rules, the gateway forces the user to confirm their identity through additional verification methods, and only continues processing after successful verification, improving access security. For encrypted forwarding to the server, for unmatched requests requiring further backend processing, the gateway encrypts the request content before forwarding it to the server to prevent data from being stolen or tampered with during transmission. For example, parameters and user information are transmitted using SSL / TLS encryption to ensure data confidentiality.

[0058] In one embodiment, the control method further includes:

[0059] Step S50: Scan and identify the content of the access request according to a pre-defined pattern, mark suspicious content, and report it to the server. During the gateway's processing of access requests, deep security inspection of the request content is introduced. A comprehensive scan of various information in the request, including resource locators, request parameters, request headers, and request bodies, is performed using a pre-defined pattern, such as a regular expression rule base, to identify potential security risks.

[0060] For example, the default pattern includes detection rules for external link identifiers such as "http: / / " or "https: / / ". When content like "http: / / backend-server / secret" is embedded in the request parameters or path, it will be judged as suspicious content. This may be malicious users trying to bypass the gateway and directly access the real address of the backend server. For another example, if the request contains special character combinations that do not conform to business logic (such as the SQL injection signature "'or'1'='1"), it will also be marked as suspicious.

[0061] After marking suspicious content, the gateway will report the detailed information of the request (including the request source, time, and specific location of the suspicious content) to the server, so that the administrator can view it in the background visualization interface. At the same time, the system can provide rule adjustment suggestions based on built-in policies, such as adding rules to block such links, forming a closed loop of "detection-reporting-optimization", further strengthening the control over the Web proxy to prevent escape and making up for the security blind spot of traditional proxies that only rely on path matching.

[0062] In one embodiment of this application, before the gateway determines whether the resource locator of the access request matches a preset set of rules, the following steps are included:

[0063] In step S210, the gateway determines whether the data access carries gateway information. Gateway information refers to credentials generated by the gateway to identify whether a user has been authenticated by the gateway, such as authentication cookies and session identifiers. This information serves as the basis for the gateway to verify the legitimacy of the user's identity. Before determining whether the resource locator of the access request conforms to a preset rule set, the gateway first checks whether the current data access request carries such gateway information. For example, if a user previously logged in through the gateway, the gateway would generate a cookie containing the user's identity and session information and return it to the client. The client must automatically include this cookie in subsequent requests. The gateway determines whether the data access carries gateway information by checking whether the cookie exists in the request header.

[0064] Step S211: If the request carries gateway information, the access continues. When a data access request carries valid gateway information, the gateway recognizes the previous authentication status of the request and allows the process to continue, i.e., proceeding to the next step of determining whether the resource locator matches the preset rule set. For example, if a user is already logged in and carries a session cookie generated by the gateway, and requests access to " / hr / info", the gateway detects that the cookie is valid and does not require repeated authentication, directly entering the rule matching stage. This ensures a smooth access process for authenticated users, achieving the convenience of one-time authentication and login-free access for multiple applications. At the same time, the validity verification of the gateway information prevents unauthorized users from forging requests.

[0065] In step S212, if the request does not carry gateway information, the user is redirected to the login page for authentication. If authentication is successful, the user is redirected to the customer's business page and can log in without needing to log in for a preset period. When a data access request does not carry gateway information, the gateway will redirect the request to the login page, requiring the user to complete identity authentication, such as entering a username, password, or verification code. During the authentication process, the gateway will interact with the backend user system to verify the user's identity. If the verification is successful, the gateway will generate new gateway information and return it to the client, while simultaneously redirecting the user to the business page they originally requested. For example, if the user originally wanted to access " / finance / reimburse", they will directly enter that page after authentication. In addition, the gateway will set a preset login-free period (e.g., 2 hours). During this period, when the user initiates other requests, as long as they carry valid gateway information, they do not need to log in again. This ensures the security interception of unauthenticated requests and improves the user experience through the login-free mechanism, avoiding the cumbersome operation caused by frequent authentication.

[0066] In addition, there are a few points that need to be clarified in this application:

[0067] First, regarding the formation of the rule set, machine learning models can analyze historical access logs and abnormal request characteristics in real time, such as URL mutation patterns and high-frequency abnormal paths, to automatically generate or update the rule set. For example, when multiple requests under the " / hr / " path are detected attempting to escape through " / hr / .. / finance / ", the machine learning model can automatically generate new rules to intercept the "path traversal feature" and synchronize them to the rule set without manual intervention. This upgrades from passively matching preset rules to actively learning and defending against new risks, solving the problem of incomplete coverage by static rules and significantly improving the ability to respond to unknown threats.

[0068] Second, for requests that do not comply with the rules, a fallback rule should be uniformly applied. A real-time risk scoring mechanism can be introduced, which combines multi-dimensional parameters such as user identity credibility, device security status, access time / location anomaly, and request content sensitivity level to score each request and dynamically adjust the control strategy: data access is divided into low-risk requests, medium-risk requests, and high-risk requests.

[0069] For low-risk requests, such as trusted users accessing public resources during normal hours, the verification process can be simplified, and caching rules can be reused to improve efficiency. For medium-risk requests, such as unfamiliar devices accessing sensitive resources, authentication can be strengthened, such as combining biometric and dynamic token authentication, and the scope of permissions can be temporarily tightened. For high-risk requests, such as abnormal IPs attempting to access core databases, they can be directly intercepted and source tracing analysis can be triggered, while the associated user sessions can be frozen. This breaks through the static, black-and-white control model, enabling dynamic matching of risk policies and a more refined management solution.

[0070] Third, continuous verification is performed on the data access process, meaning dynamic verification throughout the entire access flow: even if the request conforms to the rules and carries valid gateway information, the security status of the user's device is still verified in real time, such as whether malicious software is installed, whether system patches are updated, and the continuity of session behavior, such as whether operating habits have changed abruptly; if an anomaly is detected, such as the device suddenly accessing an insecure network or the operation frequency far exceeding the historical average, secondary authentication or temporary access freeze is immediately triggered until the risk is eliminated. This breaks through the traditional one-time authentication and trust model, extending security control to the entire access lifecycle, making the solution more stringent and adaptable to complex network environments.

[0071] like Figure 3 As shown, this application also provides a data access control system. The control system is applied to a gateway, which is communicatively connected to both a client and a server. The control system includes a receiving module 100, a judging module 200, and a control module 300.

[0072] The receiving module 100 is used by the gateway to receive access requests from clients. The receiving module 100 is responsible for receiving all data access requests initiated by clients. The receiving module 100 centrally connects client access requests to the gateway, ensuring that all communication between the client and the backend server is relayed through the gateway, preventing requests from directly bypassing the proxy and reaching the server. For example, when a user accesses an internal enterprise system, the entered URL points to the gateway address. The receiving module captures this request and passes it to the subsequent processing stages within the gateway, providing a foundation for subsequent rule judgments and access control, which is the first step in achieving centralized access management.

[0073] The judgment module 200 is used by the gateway to determine whether the resource locator of the access request conforms to a preset rule set. The judgment module 200 is a component of the gateway that performs access legitimacy verification; its function is to perform rule matching on the access requests received by the receiving module 100. The judgment module 200 extracts the resource locator from the request and compares it with the pre-configured rule set. For example, the preset rule set includes rules for legitimate paths in the human resources system and the financial system. The judgment module 200 checks whether the requested URL matches these rules. Through this process, the gateway can quickly identify whether the request is within the preset security control scope.

[0074] The control module 300 controls data access based on the access permissions corresponding to the rule set if the request matches the rule set; otherwise, it executes a preset fallback rule to control data access. The control module 300 is the execution component for implementing access control and exception handling. It adopts differentiated processing strategies based on the matching results from the judgment module: when a request matches the rule set, the control module 300 calls the access permission policy bound to that rule for fine-grained control of data access. The control module 300 verifies the identity of the request initiator, allowing only authorized users to access the data and rejecting unauthorized requests. When a request does not match the rule set, the control module 300 triggers a preset fallback rule to prevent security vulnerabilities caused by incomplete rule coverage. The control module 300 can force users to complete secondary authentication before processing, or directly block risky requests.

[0075] Through these two processing methods, the control module 300 can ensure that compliant requests are accessed normally according to their permissions, and also provide a security backup for abnormal requests, thereby achieving full-scenario control over data access and ultimately preventing unauthorized access and protecting backend resources.

[0076] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described control method.

[0077] The implementation of the computer-readable storage medium in this application refers to the control method described above, and will not be repeated here.

[0078] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A data access control method, characterized in that, The data access control method is applied to a gateway, which is communicatively connected to both a client and a server. The control method includes: The gateway receives access requests from clients; The gateway determines whether the resource locator of the access request conforms to a preset set of rules; If the data conforms to the set of rules, access to the data is controlled according to the access permissions corresponding to the set of rules. If the data does not conform to the set of rules, a preset fallback rule is executed, and data access is controlled according to the fallback rule.

2. The control method according to claim 1, characterized in that, Before the gateway determines whether the resource locator of the access request matches a preset set of rules, it includes: Configure appropriate resource locators for different data access methods; Establish a set of rules for resource locators that meet control requirements.

3. The control method according to claim 1, characterized in that, Before the gateway receives the client's access request, the following steps are also included: Replace the server address with the gateway address and hide the server address so that the client accesses the gateway address.

4. The control method according to claim 1, characterized in that, If the steps following the set of rules are met, the following further steps are also included: Determine if the data access matches the cache mapping; If a match is found, the access rules corresponding to the cache mapping will be automatically reused; If there is no match, the data access is forwarded to the server, which processes the data access according to a preset security policy.

5. The control method according to claim 4, characterized in that, The security policy includes at least one of the following: establishing a whitelist of allowed access, controlling access traffic rate, and issuing alarm notifications.

6. The control method according to claim 1, characterized in that, The fallback rules include at least one of the following: re-triggering verification, mandatory two-factor authentication, and encrypted forwarding to the server.

7. The control method according to claim 1, characterized in that, The control method further includes: The content of the access request is scanned and identified according to a pre-set pattern, suspicious content is marked and reported to the server.

8. The control method according to claim 1, characterized in that, Before the gateway determines whether the resource locator of the access request matches a preset set of rules, it includes: The gateway determines whether data access includes gateway information. If gateway information is included, continue access; If the gateway information is not included, the user will be redirected to the login page for authentication. If authentication is successful, the user will be redirected to the customer's business interface and will be able to log in without further assistance for a preset period of time.

9. A data access control system, characterized in that, The control system is applied to a gateway, which is communicatively connected to both a client and a server. The control system includes: The receiving module is used by the gateway to receive access requests from clients; The judgment module is used by the gateway to determine whether the resource locator of the access request conforms to a preset set of rules; The control module is used to control data access according to the access permissions corresponding to the rule set if the data meets the rule set; otherwise, it executes a preset fallback rule and controls data access according to the fallback rule.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the control method according to any one of claims 1 to 8.

Images