Data access control method, apparatus, device, medium, and program product

Abstract

The application provides a data access control method and device, equipment, medium and program product, which can be applied to the technical field of big data. The method comprises the following steps: in response to an access request for a target service, determining a target service calling sequence corresponding to the target service according to service thread association information, the service thread association information comprising a plurality of historical services and a historical service calling sequence corresponding to each historical service; in response to the target service calling an nth service, if the nth service is different from an nth service in the target service calling sequence, blocking the calling of the nth service, the target service calling sequence comprising N services, n belongs to N, and N is an integer greater than or equal to 1.

Description

Technical Field

[0001] This application relates to the field of big data, specifically to a data access control method, apparatus, device, medium, and program product. Background Technology

[0002] In the field of computer system security, access control of underlying service calls initiated by business processes is a key technical means to ensure system security. With the continuous increase in microservice architecture, containerized deployment, and business logic complexity, how to effectively identify and block abnormal service calls in business behavior has become an urgent problem to be solved in this field. Summary of the Invention

[0003] In view of the above problems, embodiments of this application provide a data access control method, apparatus, device, medium, and program product.

[0004] According to a first aspect of this application, a data access control method is provided, the method comprising: in response to an access request for a target service, determining a target service call sequence corresponding to the target service based on service thread association information, the service thread association information including multiple historical services and historical service call sequences corresponding to each historical service; in response to the target service calling the nth service, if the nth service is not the same as the nth service in the target service call sequence, blocking the call to the nth service, the target service call sequence including N services, where n belongs to N and N is an integer greater than or equal to 1.

[0005] According to an embodiment of this application, the business thread association information is obtained through the following operations: obtaining the historical service call sequences of multiple historical services, wherein the historical service call sequences are the service calls allowed to be initiated by the historical services and the order of the calls; and generating a mapping table of the historical service call sequences corresponding to each historical service based on the historical service call sequences of multiple historical services, thereby obtaining the business thread association information.

[0006] According to an embodiment of this application, obtaining historical service call sequences of multiple historical services includes: collecting initial service call sequences of multiple historical services; if an anomaly is detected in the initial service call sequence, adjusting the initial service call sequence to obtain a historical service call sequence.

[0007] According to an embodiment of this application, the method further includes: obtaining first attribute information for each historical service, wherein the first attribute information represents additional constraints that must be met when a historical service calls a service; and adding the first attribute information to the historical service call sequence of each historical service.

[0008] According to an embodiment of this application, the method further includes: in response to a target service calling the nth service, obtaining second attribute information of the target service; if the second attribute information does not match the first attribute information of the target service call sequence, blocking the call to the nth service.

[0009] According to embodiments of this application, the attribute information includes call time, operation type, subject type, and region type.

[0010] According to an embodiment of this application, the method further includes: generating a prompt message if the nth service called by the target service is different from the nth service in the target service call sequence.

[0011] According to an embodiment of this application, determining the target service call sequence corresponding to the target service based on the business thread association information includes: obtaining the target identification information of the target service, wherein the identification information represents the business type of the service; traversing the historical identification information of multiple historical services in the business thread association information, and if the target identification information is the same as the first historical identification information, taking the historical service call sequence corresponding to the first historical identification information as the target service call sequence.

[0012] According to a second aspect of this application, a data access control device is provided, comprising: a determining module, configured to, in response to an access request for a target service, determine a target service call sequence corresponding to the target service based on service thread association information, wherein the service thread association information includes multiple historical services and historical service call sequences corresponding to each historical service; and a blocking module, configured to, in response to a target service calling the nth service, block the call to the nth service if the nth service is not the same as the nth service in the target service call sequence, wherein the target service call sequence includes N services, where n belongs to N and N is an integer greater than or equal to 1.

[0013] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0014] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0015] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0016] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 The illustrations depict application scenarios of data access control methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0018] Figure 2 A flowchart illustrating a data access control method according to an embodiment of this application is shown schematically.

[0019] Figure 3 This illustration schematically shows a flowchart of obtaining business thread association information according to an embodiment of this application;

[0020] Figure 4 A flowchart illustrating the process of obtaining a historical service call sequence according to an embodiment of this application is shown schematically;

[0021] Figure 5 This schematic diagram illustrates a structural block diagram of a data access control device according to an embodiment of the present application;

[0022] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a data access control method according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0024] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0025] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0026] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0027] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0028] Before introducing the technical solutions provided in the embodiments of this disclosure, the relevant technologies involved in this disclosure will be explained first.

[0029] In the field of computer system security, access control of underlying service calls initiated by business processes is a key technical means to ensure system security. With the continuous increase in microservice architecture, containerized deployment, and business logic complexity, how to effectively identify and block abnormal service calls in business behavior has become an urgent problem to be solved in this field.

[0030] Currently, the following technical solutions are typically adopted to address the aforementioned technical problems:

[0031] (1) User or process-based access control methods. These methods provide basic protection for system resources by assigning predefined operation permissions (such as read, write, execute, etc.) to different users or processes. However, these methods can only distinguish who is initiating the call and cannot perceive the business context of the current call. When the same process processes different business requests, its legitimate service call sequence may differ significantly. Traditional access control models cannot finely distinguish call behavior based on business type, resulting in coarse-grained all-allow or all-deny policies that may block normal business and are difficult to effectively identify forged or unauthorized calls.

[0032] (2) Application-layer verification-based access control methods. These methods embed permission judgment logic in the business code, such as verifying whether a user is qualified to perform a certain operation. However, when the business process is compromised or maliciously controlled by an attacker, the application-layer verification logic can be bypassed or tampered with, allowing the attacker to initiate illegal underlying service calls without triggering application-layer alerts. Therefore, relying solely on application-layer access control has obvious security vulnerabilities.

[0033] In recent years, although some studies have attempted to use kernel probe technology (such as eBPF) to intercept system calls, most of the related solutions focus on blacklist and whitelist filtering of single calls, lacking the overall perception of service call order, business context and call constraints.

[0034] Figure 1 The diagram illustrates an application scenario of data access control according to an embodiment of this application.

[0035] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0036] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal devices. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal devices, and can also be in the form of web pages.

[0037] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be the backend server of the aforementioned target application, used to provide backend services to the clients of the target application.

[0038] It should be noted that the data access control method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-103. Accordingly, the data access control device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-103.

[0039] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0040] Figure 2 A flowchart illustrating a data access control method according to an embodiment of this application is shown schematically.

[0041] like Figure 2 As shown, the data access control method 200 according to an embodiment of this application may include steps S210 to S220.

[0042] In step S210, in response to an access request for the target service, the target service call sequence corresponding to the target service is determined based on the service thread association information. The service thread association information includes multiple historical services and the historical service call sequence corresponding to each historical service.

[0043] In step S220, in response to the target service calling the nth service, if the nth service is not the same as the nth service in the target service call sequence, the call to the nth service is blocked. The target service call sequence includes N services, where n belongs to N and N is an integer greater than or equal to 1.

[0044] For example, the target business can be a specific business operation initiated at this time. For instance, the target business could be querying an order, logging in as a user, etc. An access request can be a business operation request initiated for the target business. For example, when a user clicks the "Query Balance" option on a financial platform, the front-end sends an HTTP request to the back-end server; this request is an "access request for the target business (Query Balance)".

[0045] The business thread association information can be a pre-generated data structure that records the historical service call sequences corresponding to multiple historical business processes. Historical business processes can be various business identifiers that the system has normally processed in the past, such as "balance query," "user login," and "payment settlement." The historical service call sequence can be a collection of underlying service calls (such as database read, cache query, log write, network communication, etc.) initiated sequentially in chronological order during the execution of a historical business process.

[0046] For example, after receiving an access request, the system uses the target service as an index to perform a matching search in the service thread association information. This retrieves the service call sequence that the target service should normally execute, and uses it as the baseline sequence for subsequent comparisons, i.e., the target service call sequence. For instance, if user A initiates an order query service, the system searches the service thread association information for the historical service call sequence corresponding to the order query service: Service 1: Read user session cache; Service 2: Query order database; Service 3: Record access log. This historical service call sequence is then used as the target service call sequence.

[0047] During the execution of the target business, the system continuously monitors each service call it initiates. When the business is about to call the nth service (i.e., the nth call in chronological order), this event triggers the verification logic for this step. Here, n represents the current call order, incrementing from 1. For example, after the order query business above begins execution, the system detects that its first service call is: reading the user session cache, at which point n=1; then it detects the second call: querying the order database, at which point n=2; and then it detects the third call: recording the access log, at which point n=3.

[0048] The target service call sequence contains N services, where N is an integer greater than or equal to 1, meaning there is at least one service. n represents the current call order, ranging from 1 to N. As n iterates through N, all expected service calls for the entire business are verified. For example, in an order query business, N=3, meaning there are 3 services in the sequence. The system will verify calls for n=1, 2, and 3 sequentially. A thread first initiates a call to a service (i.e., the n=1st call). The system's monitoring interceptor detects this call and initiates a comparison process. If the call passes verification, the business continues execution. When the n=2nd call is initiated, the comparison process is triggered again, and so on. If the actual number of calls during business execution exceeds N (e.g., the 4th call is initiated), the system can also handle it according to a preset strategy (e.g., blocking or issuing an alarm).

[0049] The system compares the currently invoked nth service with the predefined nth service in the target service call sequence. If they match, the current call is expected and execution is allowed to continue. If they differ, the call deviates from the normal pattern, potentially indicating business logic errors, malicious calls after intrusion, or configuration errors. In this case, the call is immediately blocked, and the service is not allowed to execute. For example, in an order query business, the second service in the target service call sequence should be "query the order database." If the system detects that the actual second call is "delete order table data" (rather than a query), and the two are different, the system immediately blocks the deletion operation to prevent damage to the database.

[0050] The nth service currently called by the target service is different from the nth service in the target service call sequence. This can be due to: comparing the service pointed to by the nth call actually issued by the business with the expected service at the nth position in the target service call sequence, and the two service representations are inconsistent, i.e., the wrong service is called; the call order is disordered, i.e., the service that should have been called in the n+1th step is called in the nth step; or an unexpected service outside the target service call sequence is called.

[0051] Understandably, by pre-establishing business thread association information and comparing the current service with the expected service item by item in the order of call during the actual business execution, abnormal behavior can be identified the moment a service call occurs, thus avoiding subsequent illegal operations or data leaks. At the same time, it does not rely on application layer code logic and has strong anti-bypass capabilities, significantly improving the accuracy and security of access control during business operation.

[0052] Figure 3 A flowchart illustrating the process of obtaining business thread association information according to an embodiment of this application is shown.

[0053] like Figure 3As shown, the business thread association information 300 obtained according to the embodiments of this application can be obtained through steps S310 to S320.

[0054] In step S310, the historical service call sequence of multiple historical services is obtained. The historical service call sequence is the service calls and call order that are allowed to be initiated by historical services.

[0055] In step S320, a mapping table is generated based on the historical service call sequences of multiple historical services to obtain the service thread association information.

[0056] For example, historical business operations can be various business operations that have been verified to cover all business scenarios in the test environment. For instance, historical business operations can be order inquiries, user logins, payment settlements, balance inquiries, etc. Each historical business operation is independent of the others and corresponds to different underlying service call requirements.

[0057] A historical service call sequence can be an ordered set of underlying service calls generated sequentially during the normal execution of a historical service, recording all service calls allowed for that historical service and their order. The historical service call sequence can be obtained in a test environment by using a hook program deployed at the kernel level to capture the underlying service calls sequentially during the execution of each historical service, categorizing the captured results by service identifier to form a historical service call sequence corresponding to each historical service.

[0058] A mapping table can be a data structure consisting of the identification information of historical services as keys and the corresponding historical service call sequences as values. Each record describes the mapping relationship between a type of historical service and the service call sequence that is allowed to be executed. The business thread association information is composed of this mapping table.

[0059] In one example, taking three historical business types—order inquiry, user login, and payment settlement—as examples, after the system completed full-scenario verification of the above businesses in the test environment, the following historical service call sequences were collected and recorded respectively: The historical service call sequence for the order inquiry business includes: Service 1: Read user session cache; Service 2: Query order database; Service 3: Record access log; The historical service call sequence for the user login business includes: Service 1: Query user account information; Service 2: Verify login credentials; Service 3: Write login session; The historical service call sequence for the payment settlement business includes: Service 1: Read account balance; Service 2: Deduct account amount; Service 3: Write transaction record; Service 4: Record settlement log. The system collects historical service call sequences for three types of historical business: order inquiry, user login, and payment settlement. These sequences are then aggregated and integrated using each business identifier as a key, generating the following mapping table: The historical service call sequence corresponding to the business identifier "Order Inquiry" is: Service 1: Read user session cache; Service 2: Query order database; Service 3: Record access log. The historical service call sequence corresponding to the business identifier "User Login" is: Service 1: Query user account information; Service 2: Verify login credentials; Service 3: Write login session. The historical service call sequence corresponding to the business identifier "Payment Settlement" is: Service 1: Read account balance; Service 2: Deduct account amount; Service 3: Write transaction details; Service 4: Record settlement log. This mapping table represents the business thread association information.

[0060] Based on the above mapping table, when user A initiates an order query in the production environment, the system uses the order query as an index to retrieve the corresponding historical service call sequence in the associated information of the business thread: the first service: read the user session cache, the second service: query the order database, and the third service: record the access log. This sequence is used as the target service call sequence to compare and verify each subsequent service call initiated by the business. If the verification shows that the second actual call is "delete order table data" instead of the expected "query order database", the call is immediately blocked.

[0061] Understandably, by collecting service call sequences from multiple historical services during the testing phase and constructing a unified mapping table based on each service identifier as business thread association information, the system can establish an independent service call benchmark for each type of service. This allows for accurate location of the service call chain that should be executed for different types of business requests in the production environment, avoiding the decrease in control precision caused by covering all business scenarios with a coarse-grained general strategy. This significantly improves the accuracy of business thread association information coverage of different business scenarios and the granularity of access control policies.

[0062] Figure 4 A flowchart illustrating the process of obtaining a historical service call sequence according to an embodiment of this application is shown.

[0063] like Figure 4 As shown, obtaining the historical service call sequence 400 of multiple historical services according to the embodiments of this application may include steps S410 to S420.

[0064] In step S410, the initial service call sequence of multiple historical services is collected.

[0065] In step S420, if the initial service call sequence is found to be abnormal, the initial service call sequence is adjusted to obtain the historical service call sequence.

[0066] For example, the initial service call sequence can be the original call sequence captured and recorded directly in the actual order in which the service calls occur, by monitoring the execution process of historical business processes through hook programs deployed in the kernel layer in a test environment. The initial service call sequence reflects all underlying service calls triggered by historical business processes in the test scenario, including service calls driven normally by business logic, as well as additional calls introduced by test environment configuration, debugging options, or other non-business factors, which have not yet been verified and filtered.

[0067] Detecting anomalies in the initial service call sequence can be achieved by comparing each service call in the sequence with the business function scope of the historical business, determining whether it is a necessary underlying call for the normal execution of the business. Anomalies in the initial service call sequence can include service calls that are inconsistent with the business function scope. For example, a business with data reading as its core function might have disk write service calls in the initial sequence; or there might be additional calls introduced by debugging configurations in the test environment rather than triggered by the business logic itself; or there might be missing necessary calls or incorrect service call order.

[0068] Adjusting the initial service call sequence can involve removing service calls identified as abnormal, supplementing necessary service calls missed during data collection, or reordering service calls with incorrect order. The sequence obtained after these processes is the historical service call sequence. If no abnormalities are found in the initial service call sequence, it is directly used as the historical service call sequence for the corresponding historical business without any adjustments.

[0069] In one example, taking the order query service as an example, during the execution of this service in the test environment, the kernel-level hook program captured the following initial service call sequence in the actual triggering order: Service 1: Read user session cache; Service 2: Query order database; Service 3: Write temporary debug file; Service 4: Record access log. This sequence is the original call record of the order query service obtained by the system during the acquisition phase, containing a total of 4 service calls.

[0070] When checking the initial service call sequence of the order query business, the system detected an anomaly in the third service, "Write Temporary Debug File": this service call was a disk write operation, which is inconsistent with the core function of the order query business, which is to read data. Furthermore, investigation confirmed that it was automatically triggered by the debugging module after debugging logs were enabled in the test environment, and was not driven by the order query business logic itself. Therefore, the system removed this abnormal service call from the initial service call sequence and re-sorted the order of the remaining calls, ultimately obtaining the historical service call sequence of the order query business: 1st service: Read user session cache; 2nd service: Query order database; 3rd service: Record access log. This historical service call sequence was then used as input data for the mapping table construction, and was aggregated with the historical service call sequences of other historical businesses such as user login and payment settlement to generate complete business thread association information. In the production environment, when user A initiates an order query business, the system verifies each actual service call according to the above sequence in the business thread association information. If it detects that the second actual call is "Delete order table data" instead of the expected "Query order database," the call is immediately blocked.

[0071] Understandably, by introducing an anomaly detection and adjustment step after collecting the initial service call sequence, it is possible to effectively identify and eliminate interfering calls introduced by test environment factors or non-business logic factors. This ensures that the historical service call sequence used to build the mapping table accurately reflects the underlying call content and order that should be initiated during the normal execution of historical business processes. It also avoids the mistaken interception of legitimate business requests in the production environment due to the inclusion of additional calls driven by non-business logic in the policy benchmark, significantly improving the accuracy of the service call sequence in the business thread association information and the reliability of the policy benchmark.

[0072] As described above, the data access control method according to the embodiments of this application may further include the steps of: obtaining first attribute information of each historical service, wherein the first attribute information represents the additional constraints that need to be met when the historical service is allowed to call the service; and adding the first attribute information to the historical service call sequence of each historical service.

[0073] For example, the first attribute information can be a set of restrictive descriptions attached to each service call in the historical business, used to limit the conditions under which the business is allowed to initiate a call. The historical service call sequence itself records which services a certain historical business is allowed to call and in what order, while the first attribute information further limits the boundaries of each service call item on this basis. For example, a specific service call of a certain historical business is only allowed to be triggered within a specified time range, or a service call is only allowed to perform read operations on data but not write operations. The above conditions can constitute the content of the first attribute information corresponding to the service call.

[0074] The methods for obtaining the first attribute information can be varied. For example, it can be manually configured by the security administrator according to the actual business security policy, or it can be automatically generated by the system after analyzing and summarizing the historical business operation records during the testing phase. Alternatively, a combination of these two methods can be used. After obtaining the first attribute information for each historical business, it is associated with each service item in the corresponding historical service call sequence, written into and stored in the business thread association information. This ensures that the historical service call sequence, in addition to the original service type and call order records, also carries additional constraints for each service call.

[0075] In one example, we will continue with the order query business example described above. In the aforementioned embodiment, the business thread association information has recorded the historical service call sequence corresponding to the order query business. This sequence includes three services: the first service is reading the user session cache, the second service is querying the order database, and the third service is recording access logs. Based on this, the corresponding first attribute information is obtained for each of the three service items in the sequence: the first attribute information for the first service (reading the user session cache) is that calls can only be initiated between 08:00 and 22:00 daily, and are not allowed to be triggered during platform maintenance windows; the first attribute information for the second service (querying the order database) is that only read-type database operations are allowed, and write-type, delete-type, or structure change-type operations are not allowed; the first attribute information for the third service (recording access logs) is that the write target is limited to the access log storage directory pre-specified by the system, and writes to any other arbitrary path are not allowed.

[0076] The first attribute information corresponding to each of the above service items is injected into the historical service call sequence of the order query business. After injection, the historical service call sequence of the order query business in the business thread association information is recorded as follows: The first service is reading the user session cache, with the additional constraint that it can only be called between 08:00 and 22:00 daily; the second service is querying the order database, with the additional constraint that the operation type is limited to read; the third service is recording access logs, with the additional constraint that the write path is limited to a predefined log directory. For other historical businesses recorded in the business thread association information, such as user login business and payment settlement business, the acquisition and injection of their respective first attribute information are completed.

[0077] Understandably, by acquiring and injecting the first attribute information of each historical business, the control requirements for service calls in the actual business operation scenario can be solidified in a structured way into the business thread association information. Based on the existing service call order comparison mechanism, the control dimensions are further refined, avoiding the situation where abnormal operation behavior is allowed even after the call order matching is passed due to insufficient control granularity. At the same time, the additional constraints and service call sequences are uniformly carried in the business thread association information, which facilitates the policy query and use of each link of subsequent access control, and significantly improves the completeness of access control baseline data and the granularity of business security policies.

[0078] As described above, the data access control method according to the embodiments of this application may further include the steps of: in response to a target service calling the nth service, obtaining the second attribute information of the target service; if the second attribute information does not match the first attribute information of the target service call sequence, blocking the call to the nth service.

[0079] For example, the second attribute information can be a description of the current call context collected in real time by the system during a service call in the actual operation of the target service. Unlike the first attribute information pre-configured in the historical service call sequence, which records the conditions required for the call to occur, the second attribute information reflects the objective situation when the call actually occurs. The actual situation collected at runtime is checked against the pre-set constraint benchmarks item by item, and if the actual situation does not meet the preset constraints, the call is immediately blocked.

[0080] In one example, the aforementioned order query service example will be used for illustration. In the aforementioned embodiment, the target service call sequence of the order query service already carries the first attribute information of each service item: the first attribute information of the first service (reading user session cache) is that calls can only be initiated between 08:00 and 22:00 daily; the first attribute information of the second service (querying the order database) is that only read-type database operations are allowed, and write-type, delete-type, or structure change-type operations are not allowed; the first attribute information of the third service (recording access logs) is that the write path is limited to a predefined log directory.

[0081] Scenario 1: Normal Business Execution. A user initiates an order query request at 10:30 AM. When the business execution reaches the second service call, the second attribute information of this call is collected in real time: the call occurred at 10:30 AM, and the intended operation type is database read. This second attribute information is compared with the first attribute information of the second service in the target service call sequence: the call time of 10:30 AM falls within the allowed time range of 8:00 AM to 10:00 PM daily, and the operation type is read, which matches the constraint of "only read-type operations are allowed." The comparison passes, and the system allows the database query operation to continue.

[0082] Scenario 2: Abnormal Call Interception. At 23:15 on the same day, an attacker attempted to modify the operation type of the second service call by constructing a request and using the order query business interface to change it to a database deletion operation. When the system detected that the business was about to initiate a second service call, it collected the second attribute information of this call: the call occurred at 23:15, and the intended operation type was database deletion. Comparing this second attribute information with the first attribute information of the second service: the call time of 23:15 is not within the allowed time range of 08:00 to 22:00 daily, the operation type is deletion, and it also does not comply with the constraint of "only read-type operations are allowed." Both comparisons failed, and the system immediately blocked this call, preventing the deletion operation from being executed.

[0083] Understandably, by collecting the second attribute information in real time during each service call and comparing it with the first attribute information pre-injected in the target service call sequence, compliance checks of the call conditions can be superimposed on the original call sequence compliance checks. This expands the judgment benchmark of access control from a single call sequence dimension to a dual dimension of call sequence and call conditions. This makes it difficult for abnormal calls to bypass the constraint review at the attribute level, even if they pass the service type sequence comparison. This further compresses the operational space that attackers can exploit and significantly improves the protection depth and anti-bypass capability of the overall access control mechanism.

[0084] As mentioned above, the attribute information includes call time, operation type, subject type, and region type.

[0085] For example, the call time can be a constraint set on the time range within which a service call is allowed to be initiated, limiting when the service call can be triggered. The strictness of the call time constraint can vary depending on the nature of different service calls. For instance, some service calls are only allowed to be triggered within specific time periods, while others are allowed to be triggered at any time of day. For example, a data read service might have a call time constraint from 08:00 to 22:00 daily; calls initiated outside this period are outside the allowed range. Conversely, a log write service might have an unlimited call time constraint throughout the day, indicating that the service call is not subject to time constraints.

[0086] Operation type can be a constraint set on the specific types of operations allowed to be executed in a service call. It limits the scope of operations that a business can access at the execution level regarding the underlying service resources, preventing the business from performing operations beyond its authorized scope on the resources managed by a service, even if it is already permitted to call that service. Operation types can include various categories such as read, write, modify, delete, and structure change, with different operation type constraints imposing varying degrees of restriction on these categories. For example, if the operation type constraint for a database service call is set to allow only read operations, then the call can only perform query operations on the database resources and is not allowed to perform write, modify, delete, or structure change operations.

[0087] Subject type can be a constraint set on the identity category of the requesting subject allowed to initiate a service call, used to limit which type of subject has the right to trigger the call. The identity category of the requesting subject can include various categories such as ordinary users, administrator users, internal system service accounts, and third-party access applications. Different categories of subjects have different permission ranges in the business system. Subject type constraints ensure that specific service calls can only be initiated by subjects within the authorized category, and similar call requests initiated by subjects outside the authorized category should be blocked. For example, the subject type constraint for a database service call may be that only authenticated ordinary users or internal system service accounts are allowed to initiate it. If an administrator subject needs to access the same database resource, it should do so through a dedicated management interface and should not be allowed to trigger it through the regular business call chain.

[0088] Region type can be a constraint set on the network region or geographical range from which a request to initiate a service call is allowed, used to limit the range of request sources when the service call is triggered. The region category of the request source can be divided according to dimensions such as internal network regions versus external public network regions, domestic network regions versus overseas network regions, and different business logic partitions. Region type constraints block call requests from unauthorized network regions by limiting the range of request sources. For example, the region type constraint for a database service call might be set to only allow requests from the internal data access network region to trigger, while requests from external public network regions or overseas network regions are not allowed.

[0089] As described above, the data access control method according to the embodiments of this application may further include the step of: generating a prompt message if the nth service called by the target service is different from the nth service in the target service call sequence.

[0090] For example, the alert message can be a notification or sound generated when the actual service call of the target business deviates from the target service call sequence, describing the abnormal event. The generated alert message can be sent to the operation and maintenance alarm platform, security audit system, or other designated recipients to achieve timely notification of abnormal events.

[0091] In one example, continuing the scenario of the aforementioned order query service, after User A initiates an order query, it is detected that the n=2nd actual service call initiated by this service is to delete order table data, while the second expected service in the target service call sequence is "query order database." Since the two are different, the call is blocked, and a prompt message generation process is simultaneously triggered. The generated prompt message includes the following: the abnormal service name is "Order Query"; the call position where the abnormality occurred is the 2nd; the actual service called is to delete order table data; the second expected service in the target service call sequence is to query the order database; the abnormality trigger time is 3:12 AM on the same day; and the identifier of the service initiator is the account information corresponding to User A. The system sends the above prompt message to the operation and maintenance alarm platform. After receiving the notification, the operation and maintenance personnel can combine the call position recorded in the prompt message, the deviation between the actual service and the expected service, and the abnormality trigger time to determine whether this abnormality belongs to an external attack (e.g., an attacker constructing an unexpected kernel call path through an application vulnerability), and initiate the corresponding emergency response process accordingly.

[0092] Understandably, by synchronously generating prompt information when the actual service call of the target business is detected to be inconsistent with the expected service in the target service call sequence, the key context information of the abnormal event can be promptly transmitted to the relevant systems or personnel. This allows operation and maintenance or security management personnel to restore the abnormal business scene as soon as possible, avoiding the inability to respond to abnormal events in a timely manner due to lack of records. At the same time, it forms a complete detection, interception and notification closed loop in conjunction with the call blocking mechanism, which significantly improves the observability of the system for abnormal call behavior and the efficiency of source tracing and handling.

[0093] As described above, the above steps, which determine the target service call sequence corresponding to the target business based on the business thread association information, may further include the following steps in one possible implementation: obtaining the target identification information of the target business, where the identification information represents the business type of the business; traversing the historical identification information of multiple historical businesses in the business thread association information, and if the target identification information is the same as the first historical identification information, using the historical service call sequence corresponding to the first historical identification information as the target service call sequence.

[0094] For example, the target identification information may be identification content used to characterize the business type to which the target business belongs, such as business name, business code, request path, or business interface identifier.

[0095] Historical identification information can be the business type identifier of each historical business that is pre-recorded in the business thread association information. Each piece of historical identification information and its corresponding historical service call sequence are stored together in the business thread association information in an associated form, and the two correspond one-to-one.

[0096] In one example, continuing the previous scenario, user A initiates an access request to the system for an order query service. The target identifier information is extracted from this access request; the extracted target identifier information is "order query," indicating that the service type corresponding to this access request is an order query.

[0097] The system iterates through the business thread's associated information, which contains the following three historical business records: The first record identifies user login, with the corresponding service call sequence being: verifying user credentials and writing to the login log; the second record identifies order query, with the corresponding service call sequence being: reading the user session cache, querying the order database, and recording the access log; the third record identifies payment settlement, with the corresponding service call sequence being: verifying payment authorization, deducting the account balance, and writing the transaction record. Starting with the first record, the system compares the target identifier "order query" with the first record "user login." If they are different, the iteration continues. Then, it compares the target identifier "order query" with the second record "order query." If they match, the second record is considered the first record, and the iteration terminates. The historical service call sequence corresponding to this first record—reading the user session cache, querying the order database, and recording the access log—is determined as the target service call sequence. This sequence was then used as a baseline to compare and verify each service call actually initiated by user A's order query business. Finally, at the n=2 call, it was detected that the actual call to delete order table data was inconsistent with the expected call to query the order database, triggering call blocking and generating a prompt message.

[0098] Based on the above data access control method, embodiments of this application also provide a data access control device. The following will be combined with... Figure 5 The device is described in detail.

[0099] Figure 5 A schematic block diagram of a data access control device according to an embodiment of this application is shown.

[0100] like Figure 5 As shown, the data access control device 500 of this embodiment includes a determination module 510 and a blocking module 520.

[0101] The determining module 510 is used to respond to an access request for a target service by determining the target service call sequence corresponding to the target service based on service thread association information. The service thread association information includes multiple historical services and the historical service call sequences corresponding to each historical service. In one embodiment, the determining module 510 can be used to execute step S210 described above, which will not be repeated here.

[0102] The blocking module 520 is used to respond to a target service call to the nth service. If the nth service is not the same as the nth service in the target service call sequence, the call to the nth service is blocked. The target service call sequence includes N services, where n belongs to N and N is an integer greater than or equal to 1. In one embodiment, the blocking module 520 can be used to execute step S220 described above, which will not be repeated here.

[0103] According to embodiments of this application, any plurality of modules in the determining module 510 and the blocking module 520 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules can be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the determining module 510 and the blocking module 520 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array, a programmable logic array, a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit, or any other reasonable means of integrating or packaging the circuit, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the determining module 510 and the blocking module 520 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0104] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a data access control method according to an embodiment of this application.

[0105] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0106] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0107] According to embodiments of this application, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0108] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0109] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0110] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0111] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0112] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0113] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0115] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A data access control method, characterized in that, The method includes: In response to an access request for a target service, a target service call sequence corresponding to the target service is determined based on the service thread association information. The service thread association information includes multiple historical services and the historical service call sequence corresponding to each historical service. In response to the target service calling the nth service, if the nth service is not the same as the nth service in the target service call sequence, the call to the nth service is blocked. The target service call sequence includes N services, where n belongs to N and N is an integer greater than or equal to 1.

2. The method according to claim 1, characterized in that, The business thread association information is obtained through the following operations: Obtain the historical service call sequence of multiple historical services, wherein the historical service call sequence is the service calls and call order that are allowed to be initiated by the historical services; Based on the historical service call sequences of the multiple historical services, a mapping table corresponding to the historical service call sequences of each historical service is generated to obtain the service thread association information.

3. The method according to claim 2, characterized in that, Retrieve historical service call sequences for multiple historical business operations, including: Collect the initial service call sequences of multiple historical services; If the initial service call sequence is found to be abnormal, the initial service call sequence is adjusted to obtain the historical service call sequence.

4. The method according to claim 2, characterized in that, The method further includes: Obtain the first attribute information of each historical service, wherein the first attribute information represents the additional constraints that must be met to allow the historical service to call the service; Add the first attribute information to the historical service call sequence of each historical business.

5. The method according to claim 4, characterized in that, The method further includes: In response to the target service calling the nth service, obtain the second attribute information of the target service; If the second attribute information does not match the first attribute information of the target service call sequence, the call to the nth service is blocked.

6. The method according to claim 4 or 5, characterized in that, The attribute information includes call time, operation type, subject type, and region type.

7. The method according to claim 1, characterized in that, The method further includes: If the nth service called by the target service is different from the nth service in the target service call sequence, a prompt message is generated.

8. The method according to claim 1, characterized in that, Based on the business thread association information, determine the target service call sequence corresponding to the target business, including: Obtain target identification information for the target service, wherein the identification information represents the service type of the service; Traverse the historical identification information of multiple historical services in the business thread association information. If the target identification information is the same as the first historical identification information, take the historical service call sequence corresponding to the first historical identification information as the target service call sequence.

9. A data access control device, characterized in that, The device includes: The determination module is used to respond to an access request for a target business and determine the target service call sequence corresponding to the target business based on the business thread association information. The business thread association information includes multiple historical businesses and the historical service call sequence corresponding to each historical business. The blocking module is used to respond to the target service calling the nth service. If the nth service is not the same as the nth service in the target service call sequence, the module blocks the call to the nth service. The target service call sequence includes N services, where n belongs to N and N is an integer greater than or equal to 1.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images