Data security risk assessment method and system

Abstract

The invention provides a data security risk assessment method and system. According to the method, a data access request is acquired, a target tracking identifier corresponding to the data access request is generated or received for the data access request based on a target entry service, and inter-service calling related to the data access request is tracked according to the target tracking identifier to acquire calling link data corresponding to the data access request. On the basis of pre-established sensitive field metadata, labeling a field access behavior of target business data involved in calling link data as a corresponding sensitive data access event, constructing a data stream sample graph according to an association relationship between the sensitive data access event and a target tracking identifier, performing risk analysis on the data stream sample graph, and obtaining a sensitive data stream; therefore, the data security risk assessment result corresponding to the single data access request can be output at the request level, and the full-link assessment of the data security risk under the micro-service architecture is realized.

Description

Technical Field

[0001] This application relates to data security technology, and in particular to a method and system for assessing data security risks. Background Technology

[0002] In the data security management scenario of the existing microservice architecture, for a single data access request, only partial access records can usually be seen in the interface logs or database audit logs.

[0003] For example, if a user calls a certain interface or service at a certain time to perform read and write operations on a certain table, it is usually difficult to fully reconstruct the entire chain of call relationships and data read and write behaviors of this data access request across gateway services, business services, service mesh sidecar proxies, message queue components, and various data storage systems within the microservice architecture at the system level.

[0004] In other words, existing technologies can often only assess access behavior at a certain level in isolation, and cannot conduct a full-chain assessment of data security risks in a microservice architecture. Summary of the Invention

[0005] This application provides a data security risk assessment method and system, which outputs data security risk assessment results corresponding to a single data access request at the request level, thereby realizing full-link assessment of data security risks under a microservice architecture.

[0006] Firstly, this application provides a data security risk assessment method, including: Obtain a data access request, wherein the data access request includes at least the target user identifier that made the data access request, the target entry service corresponding to the data access request, and the target operation type for the target business data; Based on the target entry service, generate or receive a target tracking identifier corresponding to the data access request; In each service node of the microservice architecture, the inter-service calls related to the data access request are traced based on the target tracking identifier to obtain the call chain data corresponding to the data access request; Based on pre-established sensitive field metadata, the field access behavior of the target business data involved in the call chain data is marked as the corresponding sensitive data access event; Based on the association between the sensitive data access event and the target tracking identifier, a data flow sample graph corresponding to the data access request is constructed; A risk analysis is performed on the data flow sample graph to determine the data security risk assessment result corresponding to the data access request.

[0007] Secondly, this application provides a data security risk assessment system, including: The acquisition module is used to acquire data access requests, wherein the data access request includes at least the target user identifier that made the data access request, the target entry service corresponding to the data access request, and the target operation type for the target business data; The generation module is used to generate or receive a target tracking identifier corresponding to the data access request based on the target entry service. The tracing module is used to trace the inter-service calls related to the data access request in each service node of the microservice architecture based on the target tracing identifier, so as to obtain the call chain data corresponding to the data access request; The annotation module is used to annotate the field access behavior of the target business data involved in the call chain data as the corresponding sensitive data access event based on the pre-established sensitive field metadata. The construction module is used to construct a data flow sample graph corresponding to the data access request based on the association between the sensitive data access event and the target tracking identifier; The assessment module is used to perform risk analysis on the data flow sample graph to determine the data security risk assessment result corresponding to the data access request.

[0008] Thirdly, this application provides an electronic device, comprising: Processor; and, Memory for storing the executable instructions of the processor; The processor is configured to perform any of the possible methods described in the first aspect by executing the executable instructions.

[0009] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the possible methods described in the first aspect.

[0010] The data security risk assessment method and system provided in this application acquire data access requests and, based on the target entry service, generate or receive target tracking identifiers corresponding to the data access requests. Then, in each service node of the microservice architecture, the inter-service calls related to the data access requests are traced according to the target tracking identifiers to obtain call chain data corresponding to the data access requests. Next, based on pre-established sensitive field metadata, the field access behaviors of the target business data involved in the call chain data are marked as corresponding sensitive data access events. Then, based on the association between sensitive data access events and target tracking identifiers, a data flow sample graph corresponding to the data access requests is constructed. Finally, based on pre-established data flow risk analysis rules, risk analysis is performed on the data flow sample graph to determine the data security risk assessment results corresponding to the data access requests. This allows for the output of data security risk assessment results corresponding to a single data access request at the request level, achieving full-chain assessment of data security risks under a microservice architecture. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] Figure 1 This is a schematic flowchart illustrating a data security risk assessment method according to an example embodiment of this application; Figure 2 This is a schematic diagram illustrating the specific implementation process of S120 according to an example embodiment of this application; Figure 3 This is a schematic diagram illustrating the specific implementation process of S140 according to an example embodiment of this application; Figure 4 This is a schematic diagram illustrating the specific implementation process of S150 according to an example embodiment of this application; Figure 5 This is a schematic diagram illustrating the specific implementation process of S160 according to an example embodiment of this application; Figure 6 This is a schematic diagram of the structure of a data security risk assessment system according to an example embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application.

[0013] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0015] Figure 1 This is a flowchart illustrating a data security risk assessment method according to an example embodiment of this application. Figure 1 As shown, the method provided in this embodiment includes: S110, Obtain data access request.

[0016] In this step, the data access request includes at least the target user identifier that made the data access request, the target entry service corresponding to the data access request, and the target operation type for the target business data.

[0017] Specifically, the gateway service receives network access requests from terminal devices and / or upstream systems. These requests include at least a request path, a request method, and request header and / or request body fields. Within the gateway service, the user account identifier that initiated the network access request is parsed from the request header and / or request body fields, and this user account identifier is used as the target user identifier for the data access request. Based on the preset routing and forwarding configuration, the entry microservice identifier corresponding to the network access request is matched against the request path and request method, and this entry microservice identifier is used as the target entry service for the data access request.

[0018] In the gateway service, the pre-configured interface metadata is queried based on the request path and request method to obtain the business operation type corresponding to the request path and request method from the interface metadata, and the business operation type is used as the target operation type for the target business data, so that the data access request includes at least the target user identifier, the target entry service, and the target operation type.

[0019] S120. Based on the target entry service, generate or receive the target tracking identifier corresponding to the data access request.

[0020] Figure 2 This is a schematic diagram illustrating the specific implementation flow of S120 according to an example embodiment of this application. For example... Figure 2 As shown, the above-mentioned S120 includes: S121. In the target entry service, detect whether the data access request contains the first tracking identifier carried by the upstream system.

[0021] Specifically, the network message for data access request is received in the target entry service. Within the network message for data access request, predefined tracing identifier header fields and / or message header fields are parsed. The predefined tracing identifier header fields include at least the field name used to carry a tracing identifier conforming to the distributed tracing standard protocol format.

[0022] When an identifier value conforming to the distributed tracing standard protocol format is parsed in the tracing identifier header field and / or message header field, it is determined that the data access request contains a first tracing identifier carried by the upstream system.

[0023] If no identifier value conforming to the distributed tracing standard protocol format is parsed in the tracing identifier header field and / or message header field, it is determined that the data access request does not contain the first tracing identifier.

[0024] S122. When a data access request containing a first tracking identifier is detected, the first tracking identifier is used as the target tracking identifier.

[0025] Specifically, in the target entry service, the identifier value of the first tracking identifier is read from the tracking identifier header field and / or message header field of the data access request; the identifier value is validated for format validity and / or length to confirm that the identifier value conforms to the identifier structure specified in the distributed tracing standard protocol.

[0026] When the verification passes, the identifier value is written to the request context object corresponding to the data access request, and the written identifier value is set as the target tracing identifier corresponding to the data access request, so that the target tracing identifier can be passed through and associated in subsequent microservice calls.

[0027] S123. When it is detected that the data access request does not contain the first tracking identifier, a new second tracking identifier is generated for the data access request according to the distributed tracking identifier generation rules, and the second tracking identifier is used as the target tracking identifier.

[0028] Optionally, the distributed tracing identifier generation rules adopt an identifier format that conforms to the distributed tracing standard protocol, which is at least the W3C Trace Context protocol and / or the OpenTelemetry protocol.

[0029] Specifically, the tracking identifier generation component is invoked in the target entry service to obtain the current system timestamp, instance identifier, and / or high-entropy random number. The timestamp, instance identifier, and / or high-entropy random number are encoded and concatenated according to the distributed tracking identifier generation rules to generate a second tracking identifier that conforms to the distributed tracking standard protocol format.

[0030] Write the second tracking identifier into the request context object corresponding to the data access request, and append the second tracking identifier to the tracking identifier header field of the response message of the data access request and / or the subsequent forwarded request message, so that the second tracking identifier can be identified and used as the target tracking identifier corresponding to the data access request in subsequent service nodes.

[0031] S130. In each service node of the microservice architecture, the inter-service calls related to the data access request are traced based on the target tracing identifier to obtain the call chain data corresponding to the data access request.

[0032] Specifically, in gateway services, business services, service mesh sidecar proxies, and / or message queue producers and consumers, the target tracing identifier is transparently transmitted, enabling the source service to write the target tracing identifier into the protocol header and / or message header when initiating synchronous calls or asynchronous messages to the target service. During the logging process of each service node, the target tracing identifier is written as a fixed field into the call log and / or access audit log, so that the call chain data includes log records corresponding to the target tracing identifier.

[0033] The aforementioned call chain data includes: The first call event data that represents the synchronous call relationship between services.

[0034] The second call event data represents the asynchronous call relationship through the message queue; Third-party call event data characterizes the read / write relationship between business services and data storage systems, which include at least relational databases, NoSQL databases, and / or object storage systems.

[0035] Specifically, for the first call event data, the source service's call client component intercepts remote procedure call requests initiated to the target service. Before initiating the call, it records the source service logical identifier, target service logical identifier, call interface identifier, request method, request parameter summary, and current timestamp, generating a call start log. In the target service's call server component, it intercepts received remote procedure call requests, recording the target service logical identifier, called interface identifier, request method, request parameter summary, current timestamp, and the identifier value corresponding to the target tracing identifier, generating a call receive log. In the source service's call client component, upon receiving a call response from the target service, it records the call result status code, error code, response time, and current timestamp, generating a call end log. In the call chain acquisition component, based on the target tracing identifier and / or the unique call identifier, it correlates and aggregates the call start log, call receive log, and call end log to form the first call event data representing a single synchronous call relationship between services.

[0036] For the second call event data, in the message sending component on the message queue producer side, when writing a message to the message queue, the sending request can be intercepted, and the producer service logic identifier, target topic and / or target queue name, message key value, message size, current timestamp, and identifier value corresponding to the target tracking identifier can be recorded to generate a message sending event log, and the target tracking identifier can be written to the message header field. In the message queue broker and / or service mesh sidecar broker, when a message write request is received from the producer side, the partition information, offset information, and current timestamp of the message are recorded to generate a message enqueue event log; in the message consumption component on the message queue consumer side, when pulling and / or receiving messages from the message queue, the target tracking identifier in the message header field is parsed, and the consumer service logic identifier, consumption topic and / or queue name, message key value, message offset, current timestamp, and consumption result status are recorded to generate a message consumption event log. In the call chain acquisition component, message sending event logs, message enqueueing event logs, and message consumption event logs are correlated and aggregated based on message key values, offset information, and / or target tracking identifiers to form second call event data that represents the asynchronous call relationship through message queues.

[0037] For third-party call event data, database access interception components and / or object-relational mapping component plugins can be integrated into business services. When business services initiate data read, write, and / or update operations to relational databases, NoSQL databases, and / or object storage systems, the corresponding database access interface calls are intercepted. Upon interception of a database access interface call, the target data storage system type, data source identifier and / or connection string identifier, accessed database name, table name and / or collection name, object storage bucket name, access operation type, access condition summary and / or primary key summary, and current timestamp are parsed, and the target tracking identifier corresponding to the data access request is obtained. After completing the data read, write, and / or update operations, the number of rows affected, the size of the written data, the size of the query result set, and / or error code information are further recorded to generate a database access event log. In the call chain collection component, the database access event log is associated with the target tracking identifier and stored in a structured manner at the granularity of a single database access operation to form third-party call event data representing the read-write relationship between the business service and the data storage system.

[0038] Furthermore, in the practical application of existing microservice architectures, service mesh components, such as those deployed using sidecars, are widely used to implement service discovery, traffic governance, and observability. Inter-service calls are typically forwarded and managed uniformly via sidecar proxies, which can transparently intercept and process inbound and outbound requests. To conduct data security risk assessments, it is necessary to reconstruct the call path of a data access request across multiple service nodes across the entire chain, and further analyze it in conjunction with sensitive data access behaviors. However, in existing service mesh deployments, sidecar proxies primarily focus on traffic control and performance monitoring, often limiting the processing of tracing identifiers to simple pass-through, lacking a unified parsing, injection, and logging mechanism. This makes it difficult to comprehensively accumulate call chain data suitable for security risk assessment at the service mesh level.

[0039] To address this, the target tracing identifier can be obtained by parsing the tracing identifier header field in the inbound request within the service mesh component's sidecar proxy. In the service mesh component's outbound requests, the target tracing identifier is injected into the corresponding tracing identifier header field. Finally, the target tracing identifier, source service logic identifier, and target service logic identifier are written to a unified format call log in the service mesh component's sidecar proxy log.

[0040] Specifically, in the inbound direction, the sidecar proxy uses Layer 7 protocol parsing capabilities, such as parsing HTTP / 1.1 headers, HTTP / 2 metadata, and gRPC metadata. According to the pre-configured list of tracing identifier header fields and protocol format rules, it parses the tracing identifier header fields in the inbound request message, and prioritizes identifying identifier values ​​that conform to the W3C TraceContext and / or OpenTelemetry protocol formats, and caches them as target tracing identifiers in the current session context.

[0041] In the outbound direction, when the sidecar agent initiates a forwarding request to the downstream service, it reads the target tracking identifier from the current session context and injects it into the preset tracking identifier header field to achieve unified tracking identifier injection and pass-through for downstream requests.

[0042] Regarding logging, the sidecar agent, based on configurable access log templates, writes the source service logical identifier obtained from the service registration or configuration center, the target service logical identifier parsed during the routing decision process, and the target tracing identifier of the current session as fixed fields into the access log entries, and outputs them in a unified structured format, such as JSON fields "trace_id", "source_service", "target_service", etc.

[0043] The backend log collection and analysis component, based on the aforementioned unified field, centrally aggregates and indexes the logs output by different sidecar instances. This enables traceability and correlation of cross-service call chains at the service mesh level without relying on business code modifications, providing underlying data support for data security risk assessment.

[0044] This enables the automatic acquisition and stable transmission of target tracing identifiers corresponding to data access requests. Even if some business services do not implement or only partially implement tracing points, the service mesh layer can still guarantee the continuity and consistency of tracing identifiers across service calls. Furthermore, by uniformly outputting standardized call logs carrying target tracing identifiers and source / target service logical identifiers at the sidecar proxy layer, the call chain data achieves a unified format, complete fields, and reliable correlation at the service mesh level. This improves the accuracy and coverage of link reconstruction when constructing data flow sample graphs based on target tracing identifiers, solving the technical problem of difficulty in completely and accurately collecting call relationships for data security risk assessment after the introduction of the service mesh.

[0045] S140. Based on pre-established sensitive field metadata, mark the field access behavior of the target business data involved in the call link data as the corresponding sensitive data access event.

[0046] In this step, based on the pre-established sensitive field metadata, the field access behavior of the target business data involved in the call chain data is marked as the corresponding sensitive data access event. The sensitive field metadata represents the sensitivity level and / or field type of each business data field.

[0047] Optionally, the aforementioned sensitive field metadata is established in the following way: Extract field information from the table structure and / or service interface definition of the business database; For the extracted field information, collect information on the meaning, purpose, and compliance requirements of the fields; Based on the preset sensitivity classification rules and sensitivity level division rules, assign sensitivity types and sensitivity levels to each field; Establish a mapping between field identifiers and sensitive field tags in the metadata management service to serve as sensitive field metadata.

[0048] Figure 3 This is a schematic diagram illustrating the specific implementation flow of S140 according to an example embodiment of this application. For example... Figure 3 As shown, the above-mentioned S140 includes: S141. Configure sensitive field tags for each field in the business data model. Sensitive field tags are used to indicate the sensitivity type and / or sensitivity level of the corresponding field.

[0049] Specifically, the metadata management service assigns globally unique field identifiers to each field in the business data model. Based on the domain model of the business system, a mapping relationship is established between the field identifiers and the corresponding table names, field names, and / or interface field names. The metadata management service maintains a sensitive field tag field for each field identifier. This sensitive field tag field stores the sensitivity type, sensitivity level, and / or de-identification strategy identifier corresponding to the field identifier, enabling the business service to retrieve and cache the corresponding sensitive field tag information from the metadata management service when loading the business data model.

[0050] S142. Set field access interception logic in the serialization component, deserialization component, object-relational mapping component, and / or message encoding / decoding component.

[0051] Specifically, in the serialization and / or deserialization components, read and write operations between object fields and serialized data structures are uniformly encapsulated based on reflection mechanisms and / or pre-generated field access description information. In the object-relational mapping component, a unified field read and write access interface is invoked when performing data mapping between entity objects and database records. In the message encoding and decoding component, when performing message body encoding and / or decoding processing, read and write operations of message fields are centralized to preset field access processing functions. Field access interception logic is injected into the aforementioned field read and write access interfaces and / or field access processing functions to perform access monitoring and event logging based on the sensitive field marking information of the corresponding fields before and after a field is read and / or written.

[0052] S143. When a target field marked with a sensitive field is detected to be read and / or written at the field access interception logic, a sensitive data access event record is generated.

[0053] When a target field marked with a sensitive field is detected to be read and / or written at the field access interception logic, a sensitive data access event record is generated. The sensitive data access event record includes at least the corresponding target tracking identifier, service identifier, operation type, sensitive field type, and timestamp.

[0054] S150. Based on the correlation between sensitive data access events and target tracking identifiers, construct a data flow sample diagram corresponding to the data access request.

[0055] Figure 4 This is a schematic diagram illustrating the specific implementation flow of S150 according to an example embodiment of this application. For example... Figure 4 As shown, the above-mentioned S150 includes: S151, Aggregate call chain data and sensitive data access events collected under the same target tracking identifier.

[0056] Specifically, in the data security risk assessment system, a session-level aggregation context is maintained for each target tracking identifier. When call chain data carrying the target tracking identifier is received, the call chain data is written into the call event set in the corresponding session-level aggregation context based on the target tracking identifier.

[0057] When a sensitive data access event carrying a target tracking identifier is received, the sensitive data access event is written into the sensitive event set in the corresponding session-level aggregation context based on the target tracking identifier.

[0058] When the preset aggregation timeout is reached and / or the corresponding session end marker is detected, the set of call events and the set of sensitive events in the session-level aggregation context are uniformly organized to generate the original dataset to be constructed corresponding to the target tracking identifier, which serves as the input data for constructing the data flow sample graph.

[0059] S152. Treat service nodes, data storage nodes, and / or external system nodes as graph nodes, and treat the calling relationships and data read / write relationships between nodes as graph edges.

[0060] Specifically, in the data security risk assessment system, the source node identifier and target node identifier are extracted for each call chain data record, and the corresponding node is marked as a service node, data storage node and / or external system node according to the system type to which the source node identifier and / or target node identifier belong.

[0061] According to the preset node deduplication rules, the node identifiers that appear repeatedly under the same target tracking identifier are deduplicated, generating a node set corresponding to the target tracking identifier, and assigning a unique graph node number to each node set member in the graph data structure accordingly.

[0062] Based on the source node identifier, target node identifier, and operation type in the call chain data record, a directed graph edge is constructed pointing from the source node number to the target node number. The call relationship and data read / write relationship are marked as the corresponding edge types to form an initial graph structure corresponding to the target tracking identifier.

[0063] Furthermore, it's worth noting that for data access behavior in a microservice architecture, it's typically only possible to record what happened during a specific call at the log level. It's difficult to accurately represent the call relationships between service nodes, as well as the data read / write relationships between services and data storage, and between services and external systems, using a graph structure. Specifically, existing solutions often simply record textual information such as the source service name, target service name, database operation SQL statement, or external interface call address. This makes it impossible to accurately distinguish different types of edges in a structured data flow graph, such as service call edges, data access edges, and external outflow edges. This deficiency is particularly pronounced when performing path-level analysis of sensitive data flows (e.g., checking whether sensitive data flows out to external systems via certain services), easily leading to incomplete path identification, edge type confusion, and the inability to automatically deduce multi-hop transmission links. This, in turn, affects the accuracy and interpretability of the overall data security risk assessment.

[0064] In another possible implementation, synchronous calls and / or asynchronous message sending from the source service node to the target service node are marked as service call edges. Read, write, and / or update operations from the service node to the database node are marked as data access edges. Calls and / or data transfer operations from the service node to external system nodes are marked as external outflow edges.

[0065] Specifically, in the event collection and preprocessing stage, the raw records from gateway services, business services, service mesh sidecar proxies, message queues, database audit logs, and external interface call logs are standardized and parsed. Key fields such as source node identifier, target node identifier, operation type, protocol type, and resource type are uniformly extracted from them. The nodes are then classified based on resource type to construct a node set of service nodes, database nodes, and external system nodes.

[0066] Secondly, during the edge construction phase, rule matching is performed based on the combination of operation type and resource type: when the original record represents a synchronous HTTP / gRPC call between services within the same trust boundary or an asynchronous message sending via a message queue, it is abstracted into a service call edge pointing from the source service node to the target service node.

[0067] When the original record represents a service's query, insert, update, or delete operation on a relational database, NoSQL database, or object storage system, it is abstracted as a read / write / update data access edge from the service node to the database node, and the operation direction is recorded in the edge attribute. When the original record represents a service's API call to an external system, cross-organizational data transfer, or traffic forwarding via an egress gateway, it is abstracted as an external outflow edge from the service node to the external system node.

[0068] Finally, by storing the aforementioned edges and their type labels into a graph data structure, a directed graph with dual semantics of node type and edge type is formed. This naturally supports path traversal, pattern matching, and constraint search based on edge type at the graph algorithm level, providing a directly usable structured data flow sample graph for upper-layer data security risk assessment.

[0069] S153. Use the sensitive field type and operation type corresponding to the sensitive data access event as attributes of graph nodes and / or graph edges to construct a data flow sample graph.

[0070] Specifically, when processing sensitive data access events, based on the service identifier, data storage identifier, and / or external system identifier in the sensitive data access event record, the corresponding graph node is searched from the node set of the data flow sample graph, and attribute values ​​related to the sensitive field type and sensitivity level are added or updated in the attribute set of the graph node.

[0071] At the same time, based on the operation type in the sensitive data access event record and the associated source node identifier and target node identifier, the corresponding graph edge is found from the graph edge set of the data flow sample graph, and attribute values ​​related to sensitive field type, operation type and access direction are added or updated in the attribute set of the graph edge.

[0072] After the node and edge attributes are updated, the graph nodes and edges are persistently stored according to a preset graph data format (including but not limited to adjacency list format and / or graph database storage format) so that the data flow sample graph explicitly represents the correspondence between sensitive field types and specific data flow paths under the target tracking identifier.

[0073] S160. Perform risk analysis on the data flow sample graph to determine the data security risk assessment results corresponding to the data access request.

[0074] In this step, risk analysis is performed on the data flow sample graph based on pre-established data flow risk analysis rules to determine the data security risk assessment results corresponding to the data access requests. Figure 5 This is a schematic diagram illustrating the specific implementation flow of S160 according to an example embodiment of this application. For example... Figure 5 As shown, the above-mentioned S160 includes: S161. Based on the sensitive field types, sensitivity levels, node types, and edge types in the data flow sample graph, calculate the sensitive data exposure range for data access requests.

[0075] Specifically, the data flow sample graph corresponding to the data access request is traversed, and the types of sensitive fields appearing on all graph nodes and edges, along with their corresponding sensitivity levels, are counted. Based on preset node type classification rules, service nodes, data storage nodes, and external system nodes are categorized separately. For each type of node, the set of sensitive field types associated with that type of node in the data flow sample graph and the highest sensitivity level are calculated.

[0076] Based on the preset exposure range quantification rules, the number of various nodes, the number of sensitive field types associated with the nodes, and the highest sensitivity level are weighted and summarized to generate a sensitive data exposure range indicator corresponding to the data access request. The sensitive data exposure range indicator includes at least the number of sensitive nodes, the coverage of sensitive fields, and the overall sensitivity exposure level.

[0077] S162. Based on whether there are paths in the data flow sample diagram that allow sensitive data to flow to unauthorized nodes and / or to unintended storage systems, determine whether there is a risk of unauthorized access and / or risk of data being illegally stored.

[0078] Specifically, based on a pre-established whitelist of authorized nodes and / or a whitelist of expected storage systems, each node in the data flow sample graph is marked with an authorization status to identify it as an authorized node, an unauthorized node, and / or an unexpected storage system node.

[0079] In the data flow sample graph, starting from the source node containing sensitive field types, a directed path search is performed according to the edge type constraints to find all sensitive data flow paths that reach unauthorized nodes and / or unexpected storage system nodes via service call edges, data access edges, and / or external outflow edges.

[0080] When at least one sensitive data flow path that meets the conditions is detected, the data access request is marked as having the risk of unauthorized access and / or data violation landing, and the corresponding starting node, target node, key intermediate nodes and edge types are recorded.

[0081] When no sensitive data flow path that meets the conditions is detected, the data access request is marked as having no risk of unauthorized access and / or risk of data being illegally disposed of.

[0082] S163. Identify high-risk aggregation nodes based on the degree of aggregation of characteristic data at specific nodes in the data flow sample graph.

[0083] Specifically, based on preset high-sensitivity data determination rules, sensitive field types that reach a preset threshold or higher sensitivity level are marked as high-sensitivity data.

[0084] In the data flow sample graph, statistics are performed on each node to calculate the number of highly sensitive data access events associated with each node across all incoming and / or outgoing edges. Based on the statistical results, a highly sensitive data aggregation index is calculated for each node. This index includes at least the total number of highly sensitive access events, the number of highly sensitive field types, and the number of highly sensitive source nodes. Nodes with a highly sensitive data aggregation index exceeding a preset aggregation threshold are marked as high-risk aggregation nodes. The corresponding node identifier, the set of highly sensitive field types, and their access relationships are written into the risk node list for subsequent data security governance and access control policy optimization.

[0085] S164. Output the corresponding data security risk score and / or risk level for the data access request.

[0086] Specifically, obtain the sensitive data exposure range indicators, unauthorized access risk detection results, data violation landing risk detection results, and high-risk aggregation node identification results corresponding to the data access request. The sensitive data exposure range indicators include at least the number of sensitive nodes, the coverage of sensitive fields, and the overall sensitivity exposure level.

[0087] According to the preset feature mapping rules, the number of sensitive nodes, the coverage of sensitive fields, the comprehensive sensitivity exposure level, the detection results of unauthorized access risk, the detection results of data violation landing risk, and the number of high-risk aggregation nodes are respectively mapped to corresponding numerical risk feature components.

[0088] Based on a preset weight configuration table, weight coefficients are assigned to each risk feature component, and the first risk score corresponding to the data access request is calculated by linear weighted summation. The first risk score is used to reflect the basic risk level calculated based on structured rules.

[0089] The first risk score is compared with a preset basic risk score threshold range. Based on the comparison result, the data access request is divided into at least one risk level among low risk, medium risk, and high risk to obtain the first risk level corresponding to the data access request.

[0090] In the presence of a historical risk event sample library, target historical samples that are similar to the data access request in terms of sensitive field type combination, node type distribution, and risk feature component pattern are retrieved from the historical risk event sample library. Based on the actual handling results and final risk level recorded in the target historical sample, a preset statistical learning algorithm is used to calculate the second risk score and second risk level corresponding to the data access request.

[0091] Based on the preset risk fusion rules, the first risk score and the second risk score are normalized and then weighted and fused to obtain the target risk score corresponding to the data access request. Based on the preset target risk score segmentation rules, the target risk score is mapped to the target risk level corresponding to the data access request. The target risk level includes at least one of the following: security, concern, alarm, and critical alarm.

[0092] The target risk score and / or target risk level are associated with the target tracking identifier, target user identifier, and target entry service of the data access request and stored in the risk assessment result database. When the target risk level reaches the preset linkage threshold, the corresponding data security risk assessment result is pushed to the security management system and / or access control system through the interface for subsequent linkage processing.

[0093] In this embodiment, a data access request is acquired, and a target tracking identifier corresponding to the data access request is generated or received based on the target entry service. Then, in each service node of the microservice architecture, the inter-service calls related to the data access request are tracked according to the target tracking identifier to obtain the call chain data corresponding to the data access request. Next, based on pre-established sensitive field metadata, the field access behavior of the target business data involved in the call chain data is marked as the corresponding sensitive data access event. Then, based on the association between the sensitive data access event and the target tracking identifier, a data flow sample graph corresponding to the data access request is constructed. Finally, based on pre-established data flow risk analysis rules, risk analysis is performed on the data flow sample graph to determine the data security risk assessment result corresponding to the data access request. Thus, the data security risk assessment result corresponding to a single data access request can be output at the request level, realizing the full-link assessment of data security risks under the microservice architecture.

[0094] Figure 6 This is a schematic diagram of the structure of a data security risk assessment system according to an example embodiment of this application. Figure 6 As shown, the data security risk assessment system 300 provided in this embodiment includes: The acquisition module 310 is used to acquire a data access request, wherein the data access request includes at least the target user identifier that made the data access request, the target entry service corresponding to the data access request, and the target operation type for the target business data; The generation module 320 is used to generate or receive a target tracking identifier corresponding to the data access request based on the target entry service. The tracing module 330 is used to trace the inter-service calls related to the data access request in each service node of the microservice architecture based on the target tracing identifier, so as to obtain the call chain data corresponding to the data access request. The annotation module 340 is used to annotate the field access behavior of the target business data involved in the call chain data as the corresponding sensitive data access event based on the pre-established sensitive field metadata. The construction module 350 is used to construct a data flow sample diagram corresponding to the data access request based on the association between the sensitive data access event and the target tracking identifier; The assessment module 360 ​​is used to perform risk analysis on the data flow sample graph to determine the data security risk assessment result corresponding to the data access request.

[0095] Figure 7 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application. For example... Figure 7 As shown, the electronic device 400 provided in this embodiment includes: a processor 401 and a memory 402; wherein: Memory 402 is used to store computer programs, and the memory may also be flash memory.

[0096] Processor 401 is used to execute the execution instructions stored in the memory to implement the various steps in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0097] Alternatively, the memory 402 can be either standalone or integrated with the processor 401.

[0098] When the memory 402 is a device independent of the processor 401, the electronic device 400 may further include: Bus 403 is used to connect the memory 402 and the processor 401.

[0099] This embodiment also provides a readable storage medium storing a computer program, which, when executed by at least one processor of an electronic device, enables the electronic device to perform the methods provided in the various embodiments described above.

[0100] This embodiment also provides a program product including a computer program stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the electronic device to perform the methods provided in the various embodiments described above.

[0101] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0102] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data security risk assessment method, characterized in that, include: Obtain a data access request, wherein the data access request includes at least the target user identifier that made the data access request, the target entry service corresponding to the data access request, and the target operation type for the target business data; Based on the target entry service, generate or receive a target tracking identifier corresponding to the data access request; In each service node of the microservice architecture, the inter-service calls related to the data access request are traced based on the target tracking identifier to obtain the call chain data corresponding to the data access request; Based on pre-established sensitive field metadata, the field access behavior of the target business data involved in the call chain data is marked as the corresponding sensitive data access event; Based on the association between the sensitive data access event and the target tracking identifier, a data flow sample graph corresponding to the data access request is constructed; A risk analysis is performed on the data flow sample graph to determine the data security risk assessment result corresponding to the data access request.

2. The data security risk assessment method according to claim 1, characterized in that, The step of generating or receiving a target tracking identifier corresponding to the data access request based on the target entry service includes: The target entry service detects whether the data access request contains a first tracking identifier carried by the upstream system. When the data access request is detected to contain the first tracking identifier, the first tracking identifier is used as the target tracking identifier; When it is detected that the data access request does not contain the first tracking identifier, a new second tracking identifier is generated for the data access request according to the distributed tracking identifier generation rules, and the second tracking identifier is used as the target tracking identifier.

3. The data security risk assessment method according to claim 2, characterized in that, The distributed tracing identifier generation rule adopts an identifier format that conforms to the distributed tracing standard protocol, which is at least the W3CTrace Context protocol and / or the OpenTelemetry protocol.

4. The data security risk assessment method according to claim 1, characterized in that, In each service node of the microservice architecture, the inter-service calls related to the data access request are traced based on the target tracing identifier to obtain the call chain data corresponding to the data access request, including: In each service node of the microservice architecture, the target tracking identifier is passed through, so that when the source service initiates a synchronous call or asynchronous message to the target service, the target tracking identifier is written into the protocol header and / or message header. During the logging process at each service node, the target tracing identifier is written as a fixed field into the call log and / or access audit log, so that the call chain data contains log records corresponding to the target tracing identifier.

5. The data security risk assessment method according to claim 4, characterized in that, Call link data, including: The first call event data representing the synchronous call relationship between services; The second call event data represents the asynchronous call relationship through the message queue; The third call event data represents the read / write relationship between the business service and the data storage system, wherein the data storage system includes at least a relational database, a NoSQL database, and / or an object storage system.

6. The data security risk assessment method according to claim 1, characterized in that, The method of marking field access behaviors of target business data involved in the call chain data as corresponding sensitive data access events based on pre-established sensitive field metadata includes: Configure sensitive field tags for each field in the business data model. The sensitive field tags are used to indicate the sensitivity type and / or sensitivity level of the corresponding field. Set field access interception logic in the serialization component, deserialization component, object-relational mapping component, and / or message encoding / decoding component; When a target field marked with the sensitive field is detected to be read and / or written at the field access interception logic, a sensitive data access event record is generated. The sensitive data access event record includes at least the corresponding target tracking identifier, service identifier, operation type, sensitive field type, and timestamp.

7. The data security risk assessment method according to claim 6, characterized in that, The sensitive field metadata is established in the following way: Extract field information from the table structure and / or service interface definition of the business database; For the extracted field information, collect information on the meaning, purpose, and compliance requirements of the fields; Based on the preset sensitivity classification rules and sensitivity level division rules, assign sensitivity types and sensitivity levels to each field; Establish a correspondence between field identifiers and sensitive field tags in the metadata management service to serve as the metadata for the sensitive fields.

8. The data security risk assessment method according to claim 1, characterized in that, The step of constructing a data flow sample graph corresponding to the data access request based on the association between the sensitive data access event and the target tracking identifier includes: The call chain data and sensitive data access events collected under the same target tracking identifier will be aggregated and processed. Service nodes, data storage nodes, and / or external system nodes are used as graph nodes, and the calling relationships and data read / write relationships between the nodes are used as graph edges. The sensitive field type and operation type corresponding to the sensitive data access event are used as attributes of the graph nodes and / or the graph edges to construct the data flow sample graph.

9. The data security risk assessment method according to claim 1, characterized in that, The step of performing risk analysis on the data flow sample graph based on pre-established data flow risk analysis rules to determine the data security risk assessment result corresponding to the data access request includes: Based on the sensitive field types, sensitivity levels, node types, and edge types in the data flow sample graph, calculate the sensitive data exposure range for the data access request; Based on whether there are paths in the data flow sample graph where sensitive data flows to unauthorized nodes and / or to unintended storage systems, determine whether there is a risk of unauthorized access and / or risk of data being illegally stored. Based on the degree of convergence of feature data at specific nodes in the data stream sample graph, high-risk convergence nodes are identified; Output the corresponding data security risk score and / or risk level for the data access request.

10. A data security risk assessment system, characterized in that, include: The acquisition module is used to acquire data access requests, wherein the data access request includes at least the target user identifier that made the data access request, the target entry service corresponding to the data access request, and the target operation type for the target business data; The generation module is used to generate or receive a target tracking identifier corresponding to the data access request based on the target entry service. The tracing module is used to trace the inter-service calls related to the data access request in each service node of the microservice architecture based on the target tracing identifier, so as to obtain the call chain data corresponding to the data access request. The annotation module is used to annotate the field access behavior of the target business data involved in the call chain data as the corresponding sensitive data access event based on the pre-established sensitive field metadata. The construction module is used to construct a data flow sample graph corresponding to the data access request based on the association between the sensitive data access event and the target tracking identifier; The assessment module is used to perform risk analysis on the data flow sample graph to determine the data security risk assessment result corresponding to the data access request.

Images