Data request access control method

Abstract

The invention relates to an access control method for a data request, and aims to construct a comprehensive security access control system. The method comprises the following steps: receiving a data request of an access client, wherein the data request comprises access identification information and a user identification; and evaluating a risk level based on the request information, and implementing a special control strategy on the high-risk request. The strategy comprises checking a preset access white list and a black list: the request in the white list is directly released, the request in the black list only initiates access authentication to an authorized user, the access is allowed if the authentication is passed, and otherwise, the access is rejected; in addition, access authentication is also carried out on requests which are not listed in a white list or a black list so as to enhance security. According to the method, a multi-level protection mechanism is formed by combining risk assessment, black and white list management and user identity authentication, malicious requests are effectively defended, different users and request characteristics are flexibly adapted, the user experience is guaranteed while the intranet data security is improved, and good expandability and adaptability are achieved.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to an access control method for data requests. Background Art

[0002] With the advent of the big data era, data has become an important asset for enterprises, and data security is also one of the major challenges faced by enterprises. Enterprise data platforms are usually deployed in an intranet environment, allowing only intranet users to access through intranet clients, while external networks cannot access them, thereby ensuring the security of intranet data. However, in some cases, there is a need for external network access, and data access channels need to be opened to external network clients, but this also leads to higher data risks, which can easily lead to data leakage or illegal operations on data. In other cases, access requests from intranet clients also need to be handled differently to reduce data risks, data leakage or illegal operations on data.

[0003] In the prior art, although there are access control methods based on IP blacklists and whitelists, these methods can often only simply block or allow operations on specific IP addresses, and lack flexible processing of data requests, resulting in the leakage of internal sensitive data or legitimate users may be unable to access intranet resources due to IP address problems. Summary of the invention

[0004] Based on this, the purpose of this application is to propose an access control method for data requests, which implements more secure and flexible access control based on the risk level of data requests to ensure the security and availability of intranet resources.

[0005] A data request access control method described in an embodiment of the present application is applied to an intranet server, and the method comprises the following steps: Obtaining a data request sent by an access client; the data request includes access identification information and a user identification; Determining the risk level of the data request; If the risk level of the data request is a preset first risk level, determining whether the access identification information of the data request exists in a preset access whitelist and an access blacklist; If the access identification information of the data request exists in the access whitelist, executing the data request; If the access identification information of the data request does not exist in the access whitelist and the access blacklist, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; If the access identification information of the data request exists in the access blacklist, determine whether the user identity corresponding to the user identification is an authorized user; if the user identity corresponding to the user identification is an authorized user, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; if the user identity corresponding to the user identification is not an authorized user, do not execute the data request.

[0006] The access control method for data requests described in the embodiment of the present application first receives data requests from access clients, which include key access identification information (such as IP address, request type, etc.) and user identification (such as user name, account number, etc.). Next, the risk level of the data request is determined, and for data requests with high risk levels, the preset access whitelist and access blacklist are further checked. Requests in the whitelist are considered safe and credible. If the access identification information of the request appears in the whitelist, the execution of the request is directly allowed. On the contrary, if the access identification information of the request appears in the blacklist, different measures are taken according to the different user identities-for authorized users, the real identity and authority of the user are verified by initiating access authentication. If the authentication passes, the request is allowed to execute; if the authentication fails or the user identity is not an authorized user, the execution of the request is directly rejected. In addition, if the access identification information of the data request is neither in the whitelist nor in the blacklist, the access authentication process will also be initiated to ensure the authenticity and legitimacy of the request. This step is a general processing method for all requests that are not explicitly classified as safe or dangerous, and is intended to enhance the security of the system through additional verification steps. In summary, the technical solution of this application builds a comprehensive and sophisticated access control system by introducing multiple links such as risk assessment, whitelist and blacklist checks, and access authentication based on user identity. This system can not only effectively resist attacks from malicious requests and protect the security of intranet resources, but also flexibly adjust access rights according to user identity and request characteristics to improve user experience. At the same time, the technical solution also has good scalability and adaptability, and can easily cope with access control requirements in different scenarios.

[0007] For better understanding and implementation, the present application is described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A flowchart of a method for controlling access to data requests according to an embodiment of the present application; Figure 2 A schematic diagram of the steps of processing different security modes in the embodiments of the present application; Figure 3 A schematic diagram of the steps for determining the source client type of a data request in an embodiment of the present application; Figure 4 A schematic diagram of the steps for determining the risk level of a data request in an embodiment of the present application; Figure 5 This is a schematic diagram of the steps for setting an access interface whitelist and an access interface blacklist by managing a client in an embodiment of the present application. DETAILED DESCRIPTION

[0009] In order to make the purpose, technical solution and advantages of the present application clearer, the embodiments of the present application will be further described in detail below in conjunction with the accompanying drawings. Wherein, when the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0010] It should be clear that the implementation methods described in the embodiments described below do not represent all implementation methods consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims. Based on the embodiments of the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present application.

[0011] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application are also intended to include plural forms, unless the context clearly indicates other meanings. In addition, in the description of this application, unless otherwise specified, "multiple" refers to two or more. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more associated listed items, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone; the character " / " generally indicates that the objects associated before and after are in an "or" relationship.

[0012] It should be understood that, although the terms first, second, third, etc. may be used in the present application to describe various information, such information should not be limited to these terms, and these terms are only used to distinguish similar objects, and do not have to be used to describe a specific order or sequence, nor can they be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to the specific circumstances. Depending on the context, the words "if" / "if" used in the present application can be interpreted as "at the time of" or "when" or "in response to determination".

[0013] The present application relates to the field of network communication technology, and specifically to data security management. With the advent of the big data era, data has become an important asset for enterprises, and data security issues are also one of the important problems faced by enterprises. Enterprise data platforms are usually deployed in an intranet environment, and only allow intranet users to access through the intranet client, while the external network cannot access, thereby ensuring the data security of the intranet. However, in some cases there is a need for external network access, and the data access channel needs to be opened to the external network client, but this also leads to higher data risks, which can easily cause data leakage or illegal operation of data. In other cases, the access requests of the intranet client also need to be processed differently to reduce data risks, cause data leakage or illegal operation of data.

[0014] In the prior art, although there are access control methods based on IP blacklists and whitelists, these methods can only simply block or allow operations on specific IP addresses, lacking flexible processing of data requests, resulting in internal sensitive data leakage or legitimate users being unable to access intranet resources due to IP address issues. In response to this, the present application provides an access control method for data requests, which can achieve more secure and flexible access control.

[0015] Please refer to Figure 1 The present application discloses a method for access control of data requests, which is applied to an intranet server. The method comprises the following steps: S101: Acquire a data request sent by an access client; the data request includes access identification information and a user identification; S102: Determine the risk level of the data request; S103: If the risk level of the data request is the preset first risk level, determine whether the access identification information of the data request exists in the preset access whitelist and access blacklist; S104: If the access identification information of the data request exists in the access whitelist, execute the data request; S105: If the access identification information of the data request does not exist in the access whitelist and the access blacklist, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; S106: If the access identification information of the data request exists in the access blacklist, determine whether the user identity corresponding to the user identification is an authorized user; if the user identity corresponding to the user identification is an authorized user, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; if the user identity corresponding to the user identification is not an authorized user, do not execute the data request.

[0016] The access control method for data requests described in the embodiment of the present application first receives data requests from access clients, which include key access identification information (such as IP address, request type, etc.) and user identification (such as user name, account number, etc.). Next, the risk level of the data request is determined, and for data requests with high risk levels, the preset access whitelist and access blacklist are further checked. Requests in the whitelist are considered safe and credible. If the access identification information of the request appears in the whitelist, the execution of the request is directly allowed. On the contrary, if the access identification information of the request appears in the blacklist, different measures are taken according to the different user identities-for authorized users, the real identity and authority of the user are verified by initiating access authentication. If the authentication passes, the request is allowed to execute; if the authentication fails or the user identity is not an authorized user, the execution of the request is directly rejected. In addition, if the access identification information of the data request is neither in the whitelist nor in the blacklist, the access authentication process will also be initiated to ensure the authenticity and legitimacy of the request. This step is a general processing method for all requests that are not explicitly classified as safe or dangerous, and is intended to enhance the security of the system through additional verification steps. In summary, the technical solution of this application builds a comprehensive and sophisticated access control system by introducing multiple links such as risk assessment, whitelist and blacklist checks, and access authentication based on user identity. This system can not only effectively resist attacks from malicious requests and protect the security of intranet resources, but also flexibly adjust access rights according to user identity and request characteristics to improve user experience. At the same time, the technical solution also has good scalability and adaptability, and can easily cope with access control requirements in different scenarios.

[0017] The access control method for data request described in the embodiment of the present application is executed by an intranet server, which is a computer device. Each step is described in detail below.

[0018] For step S101, a data request sent by an access client is obtained; the data request includes access identification information and a user identification.

[0019] The access client refers to a client that initiates the data request, and may specifically include an intranet client and / or an extranet client.

[0020] The access identification information is used to uniquely identify the source or type of the data request, and can be an IP address, MAC address or request type, etc., or it can be a specific identifier attached by the proxy server when forwarding the external network client request. Of course, the specific identifier can be the IP address, MAC address or request type of the proxy server itself.

[0021] The user identifier is used to identify the specific user who initiates the request, and may be a user name or account ID, etc.

[0022] In this step, the intranet server receives data requests from the access client through its network interface. These data requests usually contain necessary access information such as access identification information and user identification, so that the server can perform subsequent processing.

[0023] In one embodiment, the access client includes an intranet client and an extranet client; the data request includes a data request sent by the intranet client through the intranet and a data request sent by the proxy server through the intranet; wherein the data request sent by the proxy server is obtained by the proxy server receiving the data request sent by the extranet client through the extranet; Please refer to Figure 2 After the step of obtaining the data request sent by the access client in step S101, the following steps are included: Step S1011, obtaining the current security mode; Step S1012: if the current security mode is the full network protection mode, for any data request from an intranet client or an extranet server, determine the risk level of the data request; Step S1013, if the current security mode is the external network protection mode, for a data request from an external network client, determine the risk level of the data request; for a data request from an internal network client, execute the data request.

[0024] Among them, in step S1011, the security mode is set according to the current security requirements and environmental conditions, and is used to guide the subsequent data request processing process. In this embodiment, the intranet server supports at least two security modes: full network protection mode and external network protection mode. The setting of the security mode can be completed by the administrator on the management interface, and can also be dynamically adjusted according to the system's automatic detection mechanism.

[0025] In step S1012, in the full network protection mode, the intranet server performs strict access control on all data requests from the intranet client and the external network (through the proxy server). Specifically, the intranet server uses a preset risk assessment algorithm or rule library to determine the risk level of each data request, and executes subsequent steps according to the risk level, namely, steps S103 to S106. For details, refer to the description of other embodiments of this application.

[0026] In step S1013, compared with the full network protection mode, the external network protection mode focuses more on the access control of the external network client, while the access to the internal network client is relatively loose. Therefore, in this mode, only the risk level of the data request from the external network client (through the proxy server) is determined, and the subsequent steps, i.e., steps S103 to S106, are executed according to the risk level. For the data request from the internal network client, it is directly executed without additional risk assessment or control. This processing method not only ensures the access efficiency of the internal network client, but also effectively prevents security threats from the external network.

[0027] In summary, this embodiment achieves flexible and efficient access control by introducing security modes and differentiated processing strategies for different types of clients and data request sources. In the full network protection mode, all data requests are subject to strict risk assessment and control to ensure the overall security of the system; in the extranet protection mode, the access of the internal and external network clients is reasonably differentiated and processed according to actual needs, which not only ensures the access efficiency of the internal network clients, but also effectively prevents security threats from the extranet. This flexible configuration method enables the system to better adapt to different business scenarios and security requirements, and improves the availability and security of the system.

[0028] Please refer to Figure 3 In one embodiment, the data request sent by the intranet client includes the first access identification information of the intranet client, and the data request sent by the proxy server includes the second access identification information of the proxy server; After the step of obtaining the data request sent by the access client in step S101, the following steps are included: Step S1014, parsing the access identification information of the data request; Step S1015: if the access identification information is the first access identification information, determining that the data request is a data request from an intranet client; Step S1016: If the access identification information is the second access identification information, it is determined that the data request is a data request from an external network client.

[0029] In step S1014, after receiving the data request, the access identification information carried in the request is first parsed.

[0030] Step S1015 is a step of further judging the access identification information after parsing it. If the access identification information is the first access identification information (i.e., the specific identification of the intranet client), it can be determined that the data request comes from the intranet client. Once it is confirmed that the data request comes from the intranet client, the request is processed accordingly according to the preset access control policy.

[0031] Corresponding to step S1015, step S1016 processes the case where the access identification information is the second access identification information (i.e., the specific identification of the proxy server). When the access identification information is parsed to be the second access identification information, it is determined that the data request comes from the external network client. Once it is confirmed that the data request comes from the external network client, the request is further processed according to the current security mode and risk assessment strategy.

[0032] In summary, this embodiment achieves accurate distinction of the source of data requests by introducing access identification information and corresponding parsing and judgment steps. Whether it is a direct request from an intranet client or an extranet client request forwarded by a proxy server, its source can be accurately determined by parsing the access identification information in the request.

[0033] In step S102, the risk level of the data request is determined. After receiving the data request, the intranet server determines the risk level of the data request, which can be done by using a preset risk assessment algorithm or rule to conduct a risk assessment on the data request, which specifically involves analyzing the content of the request, verifying the source of the request, monitoring the frequency of the request, and other aspects. Through comprehensive evaluation, the server assigns a risk level to each data request, which reflects the degree of security risk that the request may bring. Of course, the intranet server can also confirm the risk based on a preset list of data request risk levels, specifically recording the different risk levels of each data request in the list in advance according to the characteristics of different data requests, so that the risk level of the data request can be confirmed based on the preset list.

[0034] Please refer to Figure 4 In one embodiment, the data request includes access interface information; the access interface information includes data request path information and data operation information; The step of determining the risk level of the data request in step S102 includes: Step S1021: If the data request path information of the data request matches the data path information of any access interface information recorded in the preset access interface blacklist, and the data operation information of the data request matches the data operation parameters of the corresponding access interface information, then the risk level of the data request is determined to be the first risk level; the access interface blacklist records a plurality of access interface information, each access interface information including data request path information and data operation parameters; Step S1022: If the data request path information of the data request matches the data path information of any access interface information recorded in the preset access interface whitelist, and the data operation information of the data request matches the data operation parameters of the corresponding access interface information, then the risk level of the data request is determined to be the second risk level; the access interface whitelist records several access interface information, and each access interface information includes data request path information and data operation parameters.

[0035] In this embodiment, the access interface information in the data request is first parsed, and the access interface information includes data request path information (such as URL path) and data operation information (such as HTTP methods such as GET, POST and the parameters they carry). Subsequently, the access interface information is compared with the preset access interface blacklist and access interface whitelist. Specifically, when performing blacklist comparison, each record in the blacklist is traversed to check whether the path information of the data request matches the path information of a record in the blacklist, and whether the data operation information (including the method and its parameters) meets the data operation parameters defined in the record. If both match, it means that the interface or operation that the data request attempts to access is explicitly prohibited and there is a high risk, so its risk level is determined to be the first risk level (representing high risk or requiring special attention). When performing whitelist comparison, similarly, the data request is compared with the records in the whitelist. If the path information and operation information of the data request fully meet the requirements of a record in the whitelist, indicating that the data request meets the predefined and explicitly permitted operation scope, then the data request is considered safe or permitted, and its risk level is determined as the second risk level (representing low risk or safety).

[0036] In summary, this embodiment achieves an accurate assessment of the risk level of data requests. By maintaining the access interface blacklist and whitelist, potential high-risk access requests (such as attempts to access sensitive data or perform dangerous operations) can be quickly identified, while also ensuring that legitimate and safe access requests are quickly processed. This mechanism not only improves the security of the system and reduces potential losses caused by malicious access or misoperation, but also optimizes resource allocation, allowing the intranet server to process legitimate data requests more efficiently. In addition, by flexibly configuring blacklists and whitelists, system administrators can adjust security policies according to actual needs, enhancing the flexibility and scalability of the system.

[0037] In one embodiment, after the step of determining the risk level of the data request in step S102, the following steps are further included: Step S1024: if the risk level of the data request is a preset second risk level, execute the data request; wherein the operational risk corresponding to the second risk level is smaller than the operational risk corresponding to the first risk level.

[0038] In this embodiment, the second risk level is a low risk level. Specifically, the risk assessment value of the data request can be compared with the preset second risk level threshold. If the risk level is equal to or lower than the threshold, the data request is considered to be at the second risk level; or, based on a preset list, the risk level of the data request can be confirmed to determine whether its characteristics meet the second risk level. When the risk level of the data request is determined to be the second risk level, the request can be executed quickly without the need for a complex approval process or additional security reinforcement measures like processing high-risk requests (requests at the first risk level), so that low-risk data requests can be responded to and processed more quickly.

[0039] Regarding step S103, if the risk level of the data request is the preset first risk level, it is determined whether the preset access whitelist or access blacklist contains the access identification information of the data request.

[0040] In this embodiment, special attention is first paid to the preset first risk level, which represents a high risk level and requires special treatment. For data requests assessed as the first risk level, the intranet server first checks the preset access whitelist and access blacklist. These two lists store access identification information that is considered safe or dangerous, respectively. The intranet server determines whether the request should be directly allowed or rejected by comparing the access identification information of the data request with the entries in the two lists.

[0041] For step S104, if the access identification information of the data request exists in the access whitelist, the data request is executed.

[0042] In this step, if access identification information matching the data request is found in the access whitelist, it means that the data request comes from a trusted source and the access is a trusted and secure access. Therefore, the intranet server will directly execute the data request without further verification or authentication.

[0043] For step S105, if the access identification information of the data request does not exist in the access whitelist and the access blacklist, access authentication is initiated; if the access authentication is passed, the data request is executed, otherwise, the data request is not executed.

[0044] In this step, if the access identification information of the data request is neither in the whitelist nor in the blacklist, the intranet server will initiate an access authentication process. This process may include multiple steps such as verifying the user's identity and checking the user's permissions. If the authentication is successful, that is, the user's identity is confirmed and has the permission to execute the request, the server will execute the data request; if the authentication fails, the request will be rejected.

[0045] In one embodiment, in step S105, if the access identification information of the data request does not exist in the access whitelist and the access blacklist, the step of initiating access authentication includes: Step S1051, if the access identification information of the data request does not exist in the access whitelist and the access blacklist, send verification information to the user client corresponding to the user identification; if the verification information sent by the access client is received, determine that the access authentication is passed; otherwise, determine that the access authentication is not passed; Alternatively, in step S1052, if the access identification information of the data request does not exist in the access whitelist and the access blacklist, access audit information is sent to the management client; if the management client returns audit approval information, it is determined that the access authentication is successful; otherwise, it is determined that the access authentication is unsuccessful.

[0046] Among them, in step S1051, when the access identification information of the data request is neither in the access whitelist nor in the access blacklist, whether the access authentication is passed will be determined based on the user's direct verification method. Specifically, it can be a method of sending verification information. First, a verification message will be sent to the user client corresponding to the user identifier (which may just be the access client or another client). This verification information can be a verification code, a one-time password (OTP), a biometric request (such as fingerprint, facial recognition) or other forms of identity authentication request. After the user client receives the verification information, it will prompt the user to perform the corresponding verification operation. At this time, the user needs to complete the verification on the access client that initiates the data request, and send the verification information (or verification result) to the intranet server through the access client. The intranet server checks whether the verification information (or the result of the verification) from the access client is successfully received. If it is successfully received, it is determined that the access authentication is passed and the data request is allowed to continue processing; if it is not received or the verification fails, it is determined that the access authentication is not passed and the data request is rejected.

[0047] In step S1052, when the access identification information of the data request is neither in the white list nor in the black list, another access authentication method will be adopted, that is, sending access audit information to the management client to perform more stringent access control. Specifically, the intranet server generates an access audit information and sends it to the management client. This information usually contains basic information of the data request, the user identification of the requester, and the details of the resources requested for access. After the management client receives the access audit information, the administrator or the automatic audit system will audit the request. The audit process may include checking the authority of the requester, the rationality of the request, the security of the resources, and other aspects. After the audit is completed, the management client will send the audit result (pass or fail) back to the intranet server. The intranet server determines whether the access authentication is passed based on the received audit result. If the audit is passed, the data request is allowed to continue processing; if the audit is not passed, the data request is rejected.

[0048] In summary, this embodiment provides two flexible access authentication methods when neither the access whitelist nor the blacklist can directly determine the risk level of the data request (or in other words, the data request may be at other risk levels between the first risk level and the second risk level). The first method implements fast and relatively simple identity authentication by directly sending verification information to the user, which is suitable for most conventional access scenarios. The second method provides a more stringent and controllable audit mechanism for high-risk or special access requests by introducing the audit process of the management client, ensuring the security of system resources and the compliance of access. These two methods complement each other and together constitute a comprehensive and flexible access control system, which effectively improves the security of the system and user experience.

[0049] For step S106, if the access identification information of the data request exists in the access blacklist, determine whether the user identity corresponding to the user identification is an authorized user; if the user identity corresponding to the user identification is an authorized user, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; if the user identity corresponding to the user identification is not an authorized user, do not execute the data request.

[0050] In this step, if the access identification information of the data request appears in the access blacklist, it means that the data request comes from an unsafe source. However, in order to balance flexibility and user experience, the intranet server will further check whether the user identity corresponding to the user identification is an authorized user. If it is an authorized user, the intranet server will give a certain degree of tolerance and further verify the user's true identity and authority by initiating access authentication. If the authentication is successful, the request is executed; if the authentication fails or the user identity is not an authorized user, the request is rejected. This step reflects that the technical solution not only ensures security, but also takes into account the actual needs of legitimate users.

[0051] In one embodiment, before the step of obtaining the data request sent by the access client in step S101, the following steps are also included: Step S201, obtaining user authorization information sent by the management client; the user authorization information includes a user identifier of the authorized user; Step S202, adding the user identification of the authorized user into a preset authorized user list; The step of determining whether the user identity corresponding to the user identifier is an authorized user in step S106 includes: Step S1061, determine whether the user identifier exists in the authorized user list; if so, determine that the user identity corresponding to the user identifier is an authorized user; if not, determine that the user identity corresponding to the user identifier is not an authorized user.

[0052] This embodiment involves obtaining user authorization information from a management client to ensure that only users explicitly authorized by the management level can access intranet resources. Specifically, in step 201, the intranet server receives and parses the user authorization information sent by the management client through interaction with the management client. This information usually includes the user ID of the authorized user, which is an important basis for the intranet server to identify the user and determine whether it has access rights. Usually, after receiving the user authorization information, it will be verified and parsed to ensure the integrity and accuracy of the information. The verification process may include checking the source, format, signature, etc. of the information to prevent the information from being tampered with or forged. Next, step 202 adds the user ID of the verified authorized user to a preset authorized user list. The authorized user list is used to store all user IDs authorized by the management level. This list is an important basis for the system to determine whether the user identity is an authorized user.

[0053] Based on this, step S1061 is a specific implementation step for determining whether the user identity is an authorized user, which depends on the authorized user list maintained in step 202. When the intranet server receives a data request and needs to determine whether the user identity of the request is an authorized user, it will first query the authorized user list. By comparing the user identifier in the data request with the user identifier in the authorized user list, it is determined whether the user has been authorized. If the user identifier exists in the list, it is determined that the user identity is an authorized user; if not, it is determined that the user identity is not an authorized user.

[0054] In summary, this embodiment constructs a user identity authentication mechanism based on management client authorization, allowing the management layer to dynamically add or delete authorized users through the management client without complex configuration or modification of the system. By querying the preset authorized user list, the intranet server can quickly determine the user identity, thereby achieving effective access control of data requests. This mechanism not only simplifies the access control process, but also improves the system response speed and user experience.

[0055] In one embodiment, if the user identity corresponding to the user identifier is an authorized user, the step of initiating access authentication in step S106 includes: Step S1062, if the user identity corresponding to the user identifier is an authorized user, send access audit information to the management client; if the management client returns audit pass information, it is determined that the access authentication is passed, otherwise, it is determined that the access authentication is not passed.

[0056] In this embodiment, when step S106 identifies that the user identity corresponding to the user identifier is an authorized user, access is not directly allowed, but a more cautious access authentication method is adopted, that is, the legitimacy of the access is further confirmed through the audit process of the management client. That is to say, in the embodiment of the present application, the authorized user only means the user in the access blacklist, who has the qualification for further authentication. As for whether the user can actually access, it also depends on whether the access authentication can be passed. This is to avoid unilaterally rejecting all users in the access blacklist and support necessary access in some special cases. Specifically, if the user identity is confirmed as an authorized user, the intranet server sends an access audit message to the management client. The access audit information usually contains key information such as the user's basic information, the details of the resource requested for access, and the access time, so that the management client can make a comprehensive assessment. After receiving the access audit information, the management client will start the corresponding audit process. This process can be a manual audit by the administrator, or it can be executed by a preset automatic audit rule. During the audit process, the administrator or the automatic audit system will comprehensively consider multiple factors, such as the user's access history, the rationality of the request, the sensitivity of the resource, etc., to decide whether to approve the access request. After the audit is completed, the management client will promptly return the audit result (pass or fail) to the intranet server. The intranet server determines whether the access authentication is passed based on the received audit result. If the audit is passed, the user is allowed to continue to access the requested resources; if the audit is not passed, the access request is rejected, and the corresponding rejection reason can be fed back to the user.

[0057] In this embodiment, when authorizing users to access resources, an access authorization channel is opened for blacklisted users, and an audit mechanism is also set up. This not only improves the flexibility and controllability of responding to access requests, but also prevents potential security risks and abuse of authority. It can dynamically adjust access rights according to management decisions to ensure that resource access always complies with the organization's security policies and business needs.

[0058] Please refer to Figure 5 In one embodiment, before the step of obtaining the data request sent by the access client in step S101, the following steps are also included: Step S301, obtaining configuration information sent by a management client, wherein the configuration information includes at least one access interface information and a risk level corresponding to each access interface information; Step S302: if the risk level of the access interface information is the first risk level, add the access interface information to a preset access interface whitelist; Step S303: If the risk level of the access interface information is the second risk level, the access interface information is added to a preset access interface blacklist.

[0059] This embodiment involves obtaining configuration information from a management client. This configuration information is crucial for the subsequent access control of the intranet server. Specifically, the intranet server establishes a communication connection with the management client and receives the configuration information sent by the management client. This configuration information contains important information about the data access interface, such as the interface name, interface address, interface function description, etc., as well as the risk level corresponding to each interface. Among them, the risk level of the interface is derived from a comprehensive assessment of factors such as the function, sensitivity, and historical access of the interface. It reflects the degree of security risk that may be brought about when the interface is accessed.

[0060] Among them, in step S302, the first risk level indicates that the risk of the interface is relatively low, therefore, the access interface information with the risk level of the first risk level is added to the preset access interface whitelist. This means that when a data request attempts to access these interfaces in the future, access will be allowed directly without the need for complex authentication or review processes. Corresponding to step S302, step S303 processes interfaces with a risk level of the second risk level. The second risk level indicates that the risk of the interface is relatively high, therefore, the access interface information with the risk level of the second risk level is added to the preset access interface blacklist. In this way, when a data request attempts to access these interfaces, access will be directly denied to prevent potential security risks.

[0061] In summary, this embodiment implements an access interface management mechanism based on risk level. By adding interfaces with lower risks to the whitelist, the access control process for these interfaces can be simplified and access efficiency can be improved; and by adding interfaces with higher risks to the blacklist, unauthorized access to these interfaces can be effectively prevented to protect the security of intranet data. This mechanism allows the management client to flexibly configure access control policies according to the risk level of the interface, thereby improving the security and flexibility of accessing intranet data.

[0062] In one embodiment, before the step of obtaining the configuration information sent by the management client in step S301, the following steps are also included: Step S300, in response to the risk configuration instruction sent by the management client, obtain configuration page data and send it to the management client, so that the operation interface of the management client displays the configuration page; the configuration page data includes an access interface information adding component, a risk level setting component and a confirmation component; the management client receives the access interface information filled in by the user through the access interface information adding component, receives the risk level set by the user through the risk level setting component, and when the confirmation component receives the user's confirmation operation, obtains the configuration information according to the access interface information and the risk level, and sends the configuration information to the intranet server.

[0063] This embodiment defines an important step before obtaining the configuration information sent by the management client, which involves interaction with the management client so that the management client can conveniently configure the access interface information and risk level. First, the intranet server needs to respond to the risk configuration instruction from the management client. This instruction may be triggered by the administrator on the management client to start the process of configuring the access interface information and risk level. After receiving the risk configuration instruction, the intranet server obtains the configuration page data and sends the data to the management client. The configuration page data includes various components used to build the configuration page, such as the access interface information adding component, the risk level setting component and the confirmation component. These components together constitute the interface for the user to perform configuration operations on the management client. After the management client receives the configuration page data, it will parse the data and display the configuration page on its operation interface. The user can fill in the access interface information, set the risk level, and finally confirm the configuration through the components on this page. After the user fills in the access interface information through the access interface information adding component and sets the risk level through the risk level setting component, if the confirmation component receives the user's confirmation operation, the management client will generate configuration information based on these input information. The management client then sends this configuration information back to the intranet server for use in subsequent steps.

[0064] In summary, this embodiment provides an intuitive and convenient way to configure interface information and risk levels for the management client. This method not only reduces the difficulty of operation for administrators, improves configuration efficiency, but also enhances the flexibility and accuracy of configuration. Administrators can configure the access interface of the intranet server at any time through the management client according to actual needs, including adding new interfaces, modifying the risk level of the interface, etc. This dynamic configuration capability enables the system to better adapt to the ever-changing business environment and security requirements, thereby improving the overall security and reliability of the system. At the same time, since the configuration process is completed on the management client, it also reduces the need for direct operation of the intranet server, reducing the possibility of security risks caused by misoperation.

[0065] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of the present application, and the present application is also intended to include such modifications and modifications.

Claims

1. A method for controlling access to data requests, characterized in that: Applied to an intranet server, the method comprises the following steps: Obtaining a data request sent by an access client; the data request includes access identification information and a user identification; Determine the risk level of the data request; If the risk level of the data request is a preset first risk level, determining whether the access identification information of the data request exists in a preset access whitelist and an access blacklist; If the access identification information of the data request exists in the access whitelist, executing the data request; If the access identification information of the data request does not exist in the access whitelist and the access blacklist, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; If the access identification information of the data request exists in the access blacklist, determine whether the user identity corresponding to the user identification is an authorized user; if the user identity corresponding to the user identification is an authorized user, initiate access authentication; if the access authentication passes, execute the data request, otherwise, do not execute the data request; if the user identity corresponding to the user identification is not an authorized user, do not execute the data request.

2. The data request access control method according to claim 1, characterized in that: After the step of determining the risk level of the data request, the step further includes: If the risk level of the data request is a preset second risk level, the data request is executed; wherein the operational risk corresponding to the second risk level is less than the operational risk corresponding to the first risk level.

3. The access control method for data request according to claim 1, characterized in that: The step of initiating access authentication if the access identification information of the data request does not exist in the access whitelist and the access blacklist includes: If the access identification information of the data request does not exist in the access whitelist and the access blacklist, send verification information to the user client corresponding to the user identification; if the verification information sent by the access client is received, determine that the access authentication is passed, otherwise, determine that the access authentication is not passed; Alternatively, if the access identification information of the data request does not exist in the access whitelist and the access blacklist, access audit information is sent to the management client; if the management client returns audit approval information, it is determined that the access authentication is successful; otherwise, it is determined that the access authentication is unsuccessful.

4. The method for controlling access to data requests according to claim 1, characterized in that: If the user identity corresponding to the user identifier is an authorized user, the step of initiating access authentication includes: If the user identity corresponding to the user identifier is an authorized user, access audit information is sent to the management client; if the management client returns audit pass information, it is determined that the access authentication is passed, otherwise, it is determined that the access authentication is not passed.

5. The data request access control method according to claim 1, characterized in that: The data request includes access interface information; the access interface information includes data request path information and data operation information; The step of determining the risk level of the data request comprises: If the data request path information of the data request matches the data path information of any access interface information recorded in the preset access interface blacklist, and the data operation information of the data request matches the data operation parameters of the corresponding access interface information, then the risk level of the data request is determined to be the first risk level; the access interface blacklist records a number of access interface information, each access interface information includes data request path information and data operation parameters; If the data request path information of the data request matches the data path information of any access interface information recorded in the preset access interface whitelist, and the data operation information of the data request matches the data operation parameters of the corresponding access interface information, then the risk level of the data request is determined to be the second risk level; the access interface whitelist records several pieces of access interface information, and each piece of access interface information includes data request path information and data operation parameters.

6. The method for controlling access to data requests according to claim 5, characterized in that: Before the step of obtaining the data request sent by the access client, the step further includes: Acquire configuration information sent by the management client, the configuration information including at least one access interface information and a risk level corresponding to each access interface information; If the risk level of the access interface information is the first risk level, adding the access interface information to a preset access interface whitelist; If the risk level of the access interface information is the second risk level, the access interface information is added to a preset access interface blacklist.

7. The data request access control method according to claim 6, characterized in that: Before the step of obtaining the configuration information sent by the management client, the step further includes: In response to the risk configuration instruction sent by the management client, configuration page data is obtained and sent to the management client, so that the operation interface of the management client displays the configuration page; the configuration page data includes an access interface information adding component, a risk level setting component and a confirmation component; the management client receives the access interface information filled in by the user through the access interface information adding component, receives the risk level set by the user through the risk level setting component, and when the confirmation component receives the user's confirmation operation, obtains the configuration information according to the access interface information and the risk level, and sends the configuration information to the intranet server.

8. The method for controlling access to data requests according to claim 1, characterized in that: Before the step of obtaining the data request sent by the access client, the following steps are also included: Obtaining user authorization information sent by the management client; the user authorization information includes a user identifier of the authorized user; Adding the user identification of the authorized user to a preset authorized user list; The step of determining whether the user identity corresponding to the user identifier is an authorized user includes: Determine whether the user identifier exists in the authorized user list; if so, determine that the user identity corresponding to the user identifier is an authorized user; if not, determine that the user identity corresponding to the user identifier is not an authorized user.

9. The data request access control method according to claim 1, characterized in that: The access client includes an intranet client and an extranet client; the data request includes a data request sent by the intranet client through the intranet and a data request sent by the proxy server through the intranet; wherein the data request sent by the proxy server is obtained by the proxy server receiving the data request sent by the extranet client through the extranet; After the step of obtaining the data request sent by the access client, the following steps are included: Get the current security mode; If the current security mode is the full network protection mode, for any data request from an intranet client or an extranet server, determine the risk level of the data request; If the current security mode is the extranet protection mode, for a data request from an extranet client, the risk level of the data request is determined; for a data request from an intranet client, the data request is executed.

10. The method for controlling access to data requests according to claim 9, characterized in that: The data request sent by the intranet client includes the first access identification information of the intranet client, and the data request sent by the proxy server includes the second access identification information of the proxy server; After the step of obtaining the data request sent by the access client, the following steps are included: Parsing the access identification information of the data request; If the access identification information is the first access identification information, determining that the data request is a data request from an intranet client; If the access identification information is the second access identification information, it is determined that the data request is a data request from an external network client.

Images