A method and device for tracking database access behavior

Abstract

This specification discloses a method and device for tracing database access behavior, relating to the field of database technology, and is used to solve the problem of difficulty in obtaining the complete call chain under the constraints of PostgreSQL application scenarios. The method includes: obtaining the pending request of the current database access behavior; generating multiple behavior-related fingerprints of the current database access behavior based on the pending request; combining the multiple behavior-related fingerprints to generate a tracking token, and embedding the tracking token into the pending request to obtain a rewritten pending request; collecting each execution event during the execution of the rewritten pending request to obtain an event stream; and reconstructing the call chain of the current database access behavior based on the fields of the event stream.

Description

Technical Field

[0001] This specification relates to the field of database technology, and in particular to a method and device for tracking database access behavior. Background Technology

[0002] Database access refers to the process by which an application or user interacts with a database to read, write, or delete data. Current mainstream database access auditing solutions include database log auditing, forwarding proxy auditing, and network traffic mirroring auditing. However, these solutions are typically deployed on the database server or network side. While they can obtain the execution results of Structured Query Language (SQL), they struggle to reliably obtain client context information before the driver layer execution and to obtain the complete call chain for the same request.

[0003] Furthermore, in PostgreSQL application scenarios, database access auditing must not modify the database kernel or increase the burden on database plugins; it must not record plaintext parameters, yet still ensure that homogeneous statements can be merged; it must maintain the reproducibility of the same request chain under connection pool reuse and retry mechanisms; and it must support high-concurrency real-time analysis with the added constraint of controllable latency. These constraints are precisely what server-side and network-side solutions find difficult to satisfy simultaneously.

[0004] Therefore, there is a need for a method to obtain a complete call chain and trace database access behavior under the constraints of PostgreSQL application scenarios. Summary of the Invention

[0005] To address the aforementioned problems, one or more embodiments of this specification provide a method and apparatus for tracking database access behavior.

[0006] One or more embodiments of this specification employ the following technical solutions: This specification provides one or more embodiments of a method for tracking database access behavior, the method comprising: Retrieve pending requests for current database access behavior; Based on the request to be executed, generate multiple behavior-related fingerprints for the current database access behavior; wherein, the multiple behavior-related fingerprints include at least: query fingerprint, source fingerprint, and session fingerprint; By combining the multiple behavior-related fingerprints, a tracking token is generated, and the tracking token is embedded into the request to be executed to obtain the rewritten request to be executed. During the execution of the rewritten request to be executed, an event stream is obtained by collecting each execution event; Based on the fields of the event stream, the call chain of the current database access behavior can be reconstructed.

[0007] Optionally, in one or more embodiments of this specification, multiple behavior-related fingerprints of the current database access behavior are generated based on the request to be executed, specifically including: The request to be executed is intercepted based on the JDBC driver, the request to be executed is parsed to obtain the current syntax tree, and the current syntax tree is processed through structure normalization to obtain the syntax tree to be extracted. The computable structural features of the syntax tree to be extracted are extracted, and sensitive structural markers are obtained by performing sensitive identification on the syntax tree to be extracted. The computable structural features and the sensitive structural markers are then concatenated to obtain a query fingerprint. Based on the source of the request to be executed, the context features of the request to be executed are collected, and a source fingerprint is generated based on the context features; The session parameters of the request to be executed are determined by combining the pre-set lease generation counter, and a session fingerprint is generated based on the session parameters; The query fingerprint, the source fingerprint, and the session fingerprint are used as multiple behavior-related fingerprints for the current database access behavior.

[0008] Optionally, in one or more embodiments of this specification, the computable structural features of the syntax tree to be extracted are extracted, and sensitive structural markers are obtained by performing sensitive identification on the syntax tree to be extracted, so as to concatenate the computable structural features and the sensitive structural markers to obtain a query fingerprint, specifically including: The syntax tree to be extracted is traversed to obtain multi-dimensional structural information, and the multi-dimensional structural information is arranged and spliced ​​according to a preset format to generate computable structural features; By scanning the syntax tree to be extracted, the field names to be identified in the request to be executed are obtained, and sensitive structure markers are identified based on the matching results of the field names to be identified with the preset sensitive rule base; wherein, the sensitive structure markers include: the bitmap position of the sensitive type and the parsing version number; By concatenating the computable structural features with the sensitive structural markers, a query string is obtained. The hash value of the query string is then calculated based on the first key to obtain the query fingerprint.

[0009] Optionally, in one or more embodiments of this specification, based on the source of the request to be executed, the contextual features of the request to be executed are collected to generate a source fingerprint based on the contextual features, specifically including: Determine the source of the request to be executed and collect the contextual features of the source of the request to be executed; The source fingerprint is obtained by calculating the hash value of the context features based on the second key.

[0010] Optionally, in one or more embodiments of this specification, the session parameters of the request to be executed are determined in conjunction with a pre-set lease generation counter, and a session fingerprint is generated based on the session parameters, specifically including: Based on the physical connection corresponding to the request to be executed, determine the connection pool corresponding to the physical connection and the authorized user hash value bound to the physical connection; Construct a pre-set lease generation counter for each physical connection in the corresponding connection pool; wherein the pre-set lease generation counter is set to 1 when the corresponding physical connection is first retrieved from the connection pool, and increments by 1 each time it is retrieved; When the current database access behavior obtains a physical connection from the corresponding connection pool, the physical identifier corresponding to the physical connection is obtained; The physical identifier, the value of the preset lease generation counter, and the authorized user hash value are used as session parameters for the request to be executed. The session parameters are concatenated sequentially to obtain a session parameter string, and the hash value of the session parameter string is calculated based on the third key to obtain the session fingerprint.

[0011] Optionally, in one or more embodiments of this specification, the plurality of behavior-related fingerprints are combined to generate a tracking token, and the tracking token is embedded in the request to be executed to obtain a rewritten request to be executed, specifically including: The root-level tracking identifier is obtained by concatenating the multiple behavior-related fingerprints with a preset time interval and calculating the hash value based on the fourth key; wherein, the preset time interval is obtained by rounding down the timestamp of the request to be executed. The root-level tracking identifier, the query fingerprint, and the statement information of the request to be executed are concatenated, and a hash value is calculated based on the fifth key to obtain the span tracking identifier; the statement information includes: statement sequence number and retry sequence number; The tracking token is obtained by concatenating the preceding positioning byte of the root-level tracking identifier with the preceding positioning byte of the span tracking identifier; Based on a pre-set annotation template, the tracking token is embedded into the request to be executed to obtain a rewritten request to be executed.

[0012] Optionally, in one or more embodiments of this specification, each execution event in the event stream includes at least: a root-level trace identifier, a statement sequence number, and a timestamp.

[0013] Optionally, in one or more embodiments of this specification, the call chain for obtaining the current database access behavior is reconstructed based on the fields of the event stream, specifically including: Based on the root-level tracing identifier of each execution event in the event stream, the event stream is clustered to obtain a candidate link set; the root-level tracing identifier is obtained by parsing the tracing token, and the same candidate link set belongs to the same level of request; Based on the statement sequence number, each execution event in the candidate link set is grouped and arranged, and the sorted execution events are connected according to the partial order rules of the preset application events to reconstruct the call link of the current database access behavior.

[0014] Optionally, in one or more embodiments of this specification, the method further includes: After obtaining the call chain that restores the current database access behavior, risk tags are generated by matching the sensitive structure markers with a preset risk rule base. Output the call chain obtained from the restoration and the risk label.

[0015] This specification provides one or more embodiments of a database access behavior tracking device, the device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described above.

[0016] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: Multiple behavior-related fingerprints are generated from the pending request and combined into a tracking token, which is then embedded into the pending request. This establishes a direct binding relationship between the pending request and its corresponding tracking information, ensuring non-intrusive tracking. Furthermore, during subsequent execution event collection, the tracking token can be extracted from the rewritten request without relying on external storage or out-of-band transmission, reducing coupling between systems. By collecting each execution event during request execution to obtain an event stream, and reconstructing the complete call chain based on the fields in the event stream, the scattered execution events are associated with a continuous call chain, solving the problem of visible statements but discontinuous call chains in traditional solutions. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a database access behavior tracking method provided in an embodiment of this specification; Figure 2 This specification provides a flowchart of a fingerprint generation process for an application scenario. Figure 3 This specification provides a timing diagram for rewriting and execution in an application scenario, as illustrated in an embodiment of the present invention. Figure 4 This is a schematic diagram of a link restoration process provided in an embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a database access behavior tracking device provided in an embodiment of this specification. Detailed Implementation

[0018] This specification provides a method and device for tracking database access behavior.

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] like Figure 1 As shown, this specification provides a flowchart illustrating a method for tracking database access behavior. Figure 1 As can be seen, in one or more embodiments of this specification, a method for tracking database access behavior specifically includes the following steps: S101: Obtain the pending requests for the current database access behavior.

[0021] The request to be executed is a textual representation of a raw SQL statement sent by the application to the database for execution via the Java Database Connectivity (JDBC) driver. That is, Figure 2As shown in the embodiment of this specification, interception is performed at the JDBC driver layer. Before the Structured Query Language (SQL) statement of the current database access behavior is actually sent to the PostgreSQL database, the original text form of the SQL statement is obtained as a request to be executed.

[0022] S102: Based on the request to be executed, generate multiple behavior-related fingerprints of the current database access behavior; wherein, the multiple behavior-related fingerprints include at least: query fingerprint, source fingerprint and session fingerprint.

[0023] After obtaining the request to be executed in step S101, in order to provide a basic identifier for subsequent generation of tracking tokens and link tracing, this embodiment of the specification generates multiple behavior-related fingerprints based on the request to be executed. These multiple behavior-related fingerprints include at least: a query fingerprint, a source fingerprint, and a session fingerprint. The query fingerprint is used to identify the structural features of the SQL statement, enabling SQL statements with the same semantics but different writing styles to be grouped into the same fingerprint. Furthermore, in this embodiment of the specification, the query fingerprint supports structured identification of sensitive fields. The source fingerprint is used to identify the source environment of the current database access request, such as the source application and source account. The session fingerprint is used to solve the crosstalk problem when the same physical connection is used sequentially by multiple requests in a connection pool reuse scenario; its generation depends on a lease generation mechanism.

[0024] Specifically, in one or more embodiments of this specification, multiple behavior-related fingerprints of the current database access behavior are generated based on the request to be executed, including: When the application submits a request to be executed to the PostgreSQL database via the JDBC driver, the JDBC driver intercepts this request. Since this interception occurs before the request is sent to the database, it obtains the raw form of the request. Therefore, as... Figure 2 The embodiment shown in this specification calls the SQL parser of the PostgreSQL dialect to perform lexical and syntactic analysis on the intercepted requests to be executed, constructing the corresponding current syntax tree. This current syntax tree represents the syntactic composition of the requests to be executed in a tree structure, with each node representing a syntactic unit. The current syntax tree is processed through structure normalization to eliminate differences that only affect the written form of the requests to be executed but do not change the semantics. This allows different requests to be executed with the same semantics to be normalized into a unified structural representation, thereby obtaining the syntax tree to be extracted.

[0025] After obtaining the syntax tree to be extracted, its computable structural features are extracted, and sensitive structure markers are obtained through sensitive identification. The computable structural features and the sensitive structure markers are then concatenated to obtain a query fingerprint. Next, based on the source of the request to be executed, the contextual features of the request are collected to generate a source fingerprint. The session parameters of the request to be executed are determined by combining a pre-set lease generation counter, and a session fingerprint is generated based on these parameters. The obtained query fingerprint, source fingerprint, and session fingerprint are then used as multiple behavior-related fingerprints for the current database access behavior.

[0026] In this embodiment, structural normalization mapping maps semantically identical but differently written requests to the same query fingerprint, eliminating interference from writing differences in subsequent analysis and reducing data storage and analysis costs. Sensitive identification is performed solely based on the extracted syntax tree, avoiding the risk of sensitive data leakage and providing a reliable basis for subsequent analysis. Source fingerprints are generated from the contextual features of the request to be executed, ensuring stable acquisition of source information before execution. By introducing a lease generation counter to assign an incrementing generation number to each loan of the same physical connection, the session parameters of the request to be executed are determined. When multiple requests have used the same physical connection sequentially, the session fingerprints of different requests are different, helping to solve the link crosstalk problem under connection pool reuse. Multiple behavior-related fingerprints are obtained through multi-fingerprint aggregation, providing a complete identification foundation for subsequent processes such as tracking token generation and link reconstruction.

[0027] Furthermore, in one or more embodiments of this specification, the above-mentioned extraction of computable structural features of the syntax tree to be extracted, and the sensitive identification of the syntax tree to be extracted to obtain sensitive structural markers, so as to concatenate the computable structural features and the sensitive structural markers to obtain a query fingerprint, specifically includes: like Figure 2 The process involves traversing the syntax tree to obtain multi-dimensional structural information, and then arranging and concatenating this information using a preset format to generate computable structural features. For example, the process of extracting multi-dimensional structural information in a certain scenario is: "Vq=<opType,tableSet,projectionSet,predicateShape,joinGraph,groupSet,orderSet,limitFlag> " In this scenario, the process involves extracting multi-dimensional structural information (Vq) from the syntax tree to be extracted. This Vq includes eight dimensions: operation type (opType), table set (tableSet), projection set (projectionSet), predicate shape (predicateShape), JOIN graph structure (joinGraph), group set (groupSet), sorting set (orderSet), and LIMIT flag (limitFlag). After obtaining this multi-dimensional structural information, it is arranged and concatenated according to a preset format to generate computable structural features. The preset format here is a fixed-order sequence of key-value pairs, with each dimension separated by a delimiter.

[0028] By scanning the syntax tree to be extracted, the field names to be identified in the request to be executed are obtained. Sensitive structure markers are then identified based on the matching results between these field names and a pre-defined sensitive rule base. These sensitive structure markers include the bitmap position of the sensitive type and the parsing version number. Specifically, the projection field nodes and predicate field nodes in the syntax tree to be extracted are traversed, and field names are extracted from each node. These field names are the field names to be identified. Each extracted field name is matched against a pre-defined sensitive rule base. This sensitive rule base is a pre-configured set of rules, each containing a sensitive type name, a matching pattern, the position number of the sensitive type in the bitmap, and the corresponding risk level. This matching process is based solely on the field name and does not read the specific parameter values ​​of the field. For example, in a certain scenario, the field names in `projectionSet` and `predicateShape` are matched against the sensitive rule base to generate a `sensitiveMask` bitmap and a `riskLevel`.

[0029] After obtaining the computable structural features and sensitive structural markers, these two elements, along with the parser version number, are concatenated to obtain the query string. Then, the hash value of the query string is calculated based on the first key to obtain the query fingerprint. The concatenation format can be to connect the computable structural features and sensitive structural markers in a fixed order using a delimiter. For example, "Vq||sensitiveMask||parserVersion". Then, based on the first key kq, the query string queryFP=HMAC_SHA256(kq, Vq||sensitiveMask||parserVersion) is obtained. The output length of the HMAC_SHA256 algorithm is 256 bits. In this embodiment, for ease of storage and comparison, the first 128 bits are truncated from the hash result as the final query fingerprint. Furthermore, it should be noted that the first key is typically generated using a cryptographically secure random number generator, possessing randomness and unpredictability. This database access behavior tracking method owns the key and is securely distributed to various application instances in a distributed deployment.

[0030] Furthermore, in one or more embodiments of this specification, the above-mentioned collection of contextual features of the request to be executed from its source, in order to generate a source fingerprint based on the contextual features, specifically includes the following steps: Determine the source of the request to be executed. The source is the client environment that initiated the current database access request, including the physical or virtual node running the application, the database connection pool, and the application itself.

[0031] After determining the source of the request to be executed, the context features of the source are collected. These context features include at least: account hash, application identifier, client network segment, driver version, node identifier, and connection pool name. Each context feature is obtained based on the database connection object, runtime environment, and connection pool corresponding to the source of each request. The collected context features are then normalized to obtain a normalized context string. The hash value of the context features is calculated based on the second key to obtain the source fingerprint. For example... Figure 2 In the scenario shown, the source fingerprint is: contextFP = HMAC_SHA256(kc, normalizedContext), where kc is the second key and normalizedContext is the normalized context string of the context features. That is, the second key is used to calculate the HMAC_SHA256 hash value of the normalized context string. The output length of the HMAC_SHA256 algorithm is 256 bits, but this scheme truncates 96 to 128 bits from the hash result as the final source fingerprint for easier storage and comparison.

[0032] Furthermore, in one or more embodiments of this specification, the above-mentioned determination of the session parameters of the request to be executed in conjunction with a pre-set lease generation counter to generate a session fingerprint based on the session parameters specifically includes the following steps: Based on the physical connection corresponding to the request to be executed, the connection pool corresponding to the physical connection and the authorized user hash value bound to the physical connection are determined. Specifically, in the JDBC driver layer, each database connection corresponds to a physical connection at the underlying level, which is created and managed by the connection pool. The connection pool instance managing the connection is looked up in reverse through the physical connection object. For example, each connection object contains a reference to the connection pool. This reference is obtained through reflection or callback mechanisms to determine the connection pool to which the physical connection belongs. Furthermore, the database authorization account used when establishing the connection is obtained from the physical connection object, and an irreversible hash transformation is performed on this account to obtain the authorized user hash value bound to the physical connection.

[0033] Then, a pre-set lease generation counter is constructed for each physical connection in the corresponding connection pool. The pre-set lease generation counter starts at 1 when the corresponding physical connection is first retrieved from the connection pool, and increments by 1 with each retrieval. That is, when a physical connection is first borrowed, leaseEpoch = 1; each time it is returned and then borrowed again, leaseEpoch = leaseEpoch + 1. The transaction critical boundary is recorded as txnEpoch. This process ensures that the same physical connection can have different lease generation counter values ​​when used by different pending requests at different times, thus distinguishing these pending requests.

[0034] When a physical connection is obtained from the corresponding connection pool for the current database access behavior, the physical identifier corresponding to that physical connection is retrieved. The physical identifier, the value of the pre-set lease generation counter, and the authorized user hash value are used as session parameters for the request to be executed. Then, the session parameters are concatenated sequentially to obtain a session parameter string, for example: "physicalConnId||leaseEpoch||authUserHash", where physicalConnId is the physical identifier, leaseEpoch is the value of the pre-set lease generation counter, and authUserHash is the authorized user hash value. The hash value of the session parameter string is calculated based on a third key to obtain the session fingerprint. For example... Figure 2 As shown: In a certain scenario, the session fingerprint sessionFP = HMAC_SHA256(ks, physicalConnId||leaseEpoch||authUserHash), where ks is the third key. The output length of the above session parameter string after HMAC_SHA256 is 256 bits. However, in order to facilitate storage and comparison, the first 128 bits are truncated as the final session fingerprint in this scheme.

[0035] S103: Combine the multiple behavior-related fingerprints to generate a tracking token, and embed the tracking token into the request to be executed to obtain the rewritten request to be executed.

[0036] After obtaining multiple behavior-related fingerprints based on step S102 above, this embodiment combines the multiple behavior-related fingerprints to generate a tracking token, and embeds the tracking token into the request to be executed to obtain a rewritten request to be executed. By combining multiple behavior-related fingerprints, the multiple dimensions of information that were originally stored or transmitted separately are integrated into a single representation, reducing the complexity and error probability of transmitting multiple fingerprints separately and providing a reliable association key for link reconstruction. By embedding the tracking token into the request to be executed, a direct binding relationship is established between the request to be executed and its corresponding tracking information. Moreover, embedding only the tracking token does not change the execution logic and result of the request to be executed, and is completely transparent to the application layer and database layer, ensuring the non-intrusiveness of the tracking mechanism.

[0037] Specifically, in one or more embodiments of this specification, multiple behavior-related fingerprints are combined to generate a tracking token, and the tracking token is embedded into the request to be executed to obtain a rewritten request to be executed. This specifically includes the following steps: Multiple behavior-related fingerprints are concatenated with a preset time interval, and a hash value is calculated based on the fourth key to obtain the root-level tracking identifier. The preset time interval is obtained by rounding down the timestamp of the request to be executed. For example, the timestamp of the current request to be executed is obtained, and a rounding operation is performed according to a preset time bucket size, such as 60 seconds, so that all requests within the same minute will receive the same time bucket value. This operation avoids the fingerprint explosion problem caused by overly precise timestamps. The source fingerprint, session fingerprint, and time bucket are concatenated in a fixed order to form the root-level input string "contextFP |sessionFP||timeBucket". The root-level tracking identifier is obtained by calculating the root-level input string based on the fourth key: rootToken=HMAC_SHA256(kt1,contextFP||sessionFP||timeBucket), where kt1 is the fourth key. Then, the root-level tracking identifier, query fingerprint, and statement information of the request to be executed are concatenated to obtain the span tracking string "rootToken||queryFP||statementSeq||retrySeq". It should be noted that the statement information includes the statement sequence number `statementSeq` and the retry sequence number `retrySeq`. Then, the hash value is calculated based on the fifth key to calculate the span tracking string, obtaining the span tracking identifier `spanToken = HMAC_SHA256(kt2, rootToken||queryFP||statementSeq||retrySeq)`, where `kt2` is the fifth key. The tracking token is obtained by concatenating the preceding positioning bytes of the root-level tracking identifier and the preceding positioning bytes of the span tracking identifier, for example... Figure 2The first 10 bytes are taken from the hash result of the root tracking identifier and the first 10 bytes are taken from the hash result of the span tracking identifier. The two are concatenated into a 20-byte binary string. Then, the binary string is Base64Url encoded to obtain the tracking token: TrackingToken=Base64Url(rootToken[0:10]||spanToken[0:10]).

[0038] After obtaining the tracking token, since the tracking token itself is just an identifier, it needs to be associated with a specific execution instance of the pending request to be effective. If the tracking token is stored separately or transmitted out of band, it is impossible to determine which tracking token corresponds to the pending request during execution event collection. Therefore, after obtaining the tracking token, it is embedded in the pending request based on a pre-defined annotation template to obtain a rewritten pending request. This allows the tracking token to be transmitted to the execution layer along with the pending request, ensuring that the tracking information can be accurately associated with the specific execution instance of the pending request.

[0039] For intuitive understanding, such as Figure 3 The diagram illustrates a rewriting and execution process in an application scenario. In this process, the application thread sends an SQL request (also known as an execution request) to the JDBC execution layer, submitting the statement to be executed. Upon receiving the execution request, the JDBC execution layer sends a fingerprint request to the fingerprint control layer, requesting the generation of the query fingerprint, source fingerprint, and session fingerprint corresponding to the current execution request. The fingerprint control layer calculates these three fingerprints based on the execution request structure, the source context, and the connection pool lease generation information, and returns the fingerprint results to the JDBC execution layer. Then, the JDBC execution layer, after obtaining the three fingerprints, jointly derives a tracking token, which is then embedded as an annotation into the execution request to obtain the rewritten execution request. The JDBC execution layer then sends the rewritten execution request statement to the PostgreSQL database for execution. Subsequently, during execution, the JDBC execution layer simultaneously collects execution events to obtain an event stream and reports it to the analysis engine. Simultaneously, the PostgreSQL database returns the execution result to the JDBC execution layer, which then returns the execution result to the application thread. Based on the received event stream, the analysis engine reconstructs the complete call chain of the current database access behavior and can further combine sensitive structure markers to generate risk labels for analysis.

[0040] S104: During the execution of the rewritten request to be executed, collect each execution event to obtain an event stream.

[0041] Since the rewritten request to be executed already carries a tracking token, when the rewritten request text is submitted to the database for execution, the tracking token exists as a comment. The database automatically ignores the comment content when executing the request. Therefore, the rewritten request text has the same execution semantics and performance characteristics as the original request, and is transparent to the database. During the execution of the rewritten request text, key execution nodes in the JDBC driver layer collect execution events, thus obtaining an event stream through the collection of each execution time. It should be noted that each execution event in the event stream includes at least the following fields: root-level tracking identifier, statement sequence number, and timestamp.

[0042] S105: Based on the fields of the event stream, reconstruct the call chain of the current database access behavior.

[0043] To output the reconstructed call chain for tracing database accesses, enabling downstream applications to use the trace, the call chain for the current database access behavior is reconstructed based on the event stream fields after obtaining them.

[0044] Specifically, in one or more embodiments of this specification, the call chain for the current database access behavior is reconstructed based on the fields of the event stream, which specifically includes the following steps: like Figure 4 As shown, based on the root-level tracing identifier of each execution event in the event stream, clustering is performed on the event stream to obtain a candidate link set. The root-level tracing identifier is obtained based on the parsing of the tracing token, and events within the same candidate link set belong to the same request level. That is, all events in the event stream are traversed, the root-level tracing identifier of each event is extracted, and events with the same root-level tracing identifier are grouped into the same candidate link set. Since the root-level tracing identifier uniquely identifies a database access request, all events within the same candidate link set belong to the same request level. This process, through clustering of the event stream, separates events that were originally mixed in the event stream belonging to different requests into their respective independent candidate link sets, providing a foundation for the independent reconstruction of each link.

[0045] Based on statement sequence numbers, the execution events in the candidate link set are grouped and arranged, with events having the same statement sequence number grouped together. At this point, all events within the same group belong to different execution stages of the same pending request. By arranging the groups in ascending order of statement sequence numbers, the execution order of each execution event is determined. For each group, according to pre-defined partial order rules for application events, such as start time being earlier than end time or exception time, the sorted execution events are connected to reconstruct the call chain of the current database access behavior. It should be noted that the above connection process does not solely rely on timestamps. Even if network transmission delays or cross-node clock asynchrony cause out-of-order event timestamps, the causal relationships between execution start, end, exception, and transaction boundary events can be correctly identified by combining event time progress with out-of-order windows to avoid incorrect connections. Figure 4 As shown, missing termination events can also be marked as missing termination events, which can then be used for link integrity marking and timeout alarms.

[0046] Furthermore, in one or more embodiments of this specification, the method further includes: After obtaining the call chain that reconstructs the current database access behavior, a risk label is generated by matching sensitive structure tags with a pre-configured risk rule base. This pre-configured risk rule base is a set of pre-configured rules, where each rule defines the matching conditions for sensitive structure tags and the corresponding risk label output. After obtaining the risk label, the reconstructed call chain and the risk label are output to provide a data foundation for downstream systems such as auditing systems, security alert systems, and performance analysis platforms.

[0047] To verify the effectiveness of this method, the data scale during the verification process included 10 million pending requests, such as execution events involving queries, updates, batch processing, and retries; the cluster topology consisted of 2 application nodes, 2 database nodes, and a reused connection pool; the control groups included a traditional log group, an annotation tracing identifier group, and the embodiment group described in this specification; the evaluation criteria included: merge accuracy to evaluate the proportion of correctly aggregated statements with the same semantic template, link integrity rate to evaluate the proportion of requests with recoverable complete start and end edges, storage usage to evaluate the storage volume of the audit repository per unit time, latency overhead to evaluate the increase in P95 response latency after enabling tracing relative to disabling tracing, and plaintext parameter disk persistence rate to evaluate the proportion of plaintext parameter values ​​recorded in the audit log. The verification results are shown in Table 1 below. Based on Table 1, it can be seen that this method achieved better results than the traditional method under multiple evaluation indicators.

[0048] Table 1. Comparative Experiment Record Table

[0049] like Figure 5 As shown in the diagram, this specification provides a schematic diagram of a database access behavior tracking device, the device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described above.

[0050] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0051] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0052] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for tracking database access behavior, characterized in that, The method includes: Retrieve pending requests for current database access behavior; Based on the request to be executed, generate multiple behavior-related fingerprints for the current database access behavior; wherein, the multiple behavior-related fingerprints include at least: query fingerprint, source fingerprint, and session fingerprint; By combining the multiple behavior-related fingerprints, a tracking token is generated, and the tracking token is embedded into the request to be executed to obtain the rewritten request to be executed. During the execution of the rewritten request to be executed, an event stream is obtained by collecting each execution event; Based on the fields of the event stream, the call chain of the current database access behavior is reconstructed; Based on the request to be executed, generate multiple behavior-related fingerprints for the current database access behavior, specifically including: The request to be executed is intercepted based on the JDBC driver, the request to be executed is parsed to obtain the current syntax tree, and the current syntax tree is processed through structure normalization to obtain the syntax tree to be extracted. The computable structural features of the syntax tree to be extracted are extracted, and sensitive structural markers are obtained by performing sensitive identification on the syntax tree to be extracted. The computable structural features and the sensitive structural markers are then concatenated to obtain a query fingerprint. Based on the source of the request to be executed, the context features of the request to be executed are collected, and a source fingerprint is generated based on the context features; The session parameters of the request to be executed are determined by combining the pre-set lease generation counter, and a session fingerprint is generated based on the session parameters; The query fingerprint, the source fingerprint, and the session fingerprint are used as multiple behavior-related fingerprints for the current database access behavior; Combining the multiple behavior-related fingerprints to generate a tracking token, and embedding the tracking token into the request to be executed to obtain a rewritten request to be executed, specifically including: The root-level tracking identifier is obtained by concatenating the multiple behavior-related fingerprints with a preset time interval and calculating the hash value based on the fourth key; wherein, the preset time interval is obtained by rounding down the timestamp of the request to be executed. The root-level tracking identifier, the query fingerprint, and the statement information of the request to be executed are concatenated, and a hash value is calculated based on the fifth key to obtain the span tracking identifier; the statement information includes: statement sequence number and retry sequence number; The tracking token is obtained by concatenating the preceding positioning byte of the root-level tracking identifier with the preceding positioning byte of the span tracking identifier; Based on a pre-set annotation template, the tracking token is embedded into the request to be executed to obtain a rewritten request to be executed.

2. The database access behavior tracking method according to claim 1, characterized in that, Extracting the computable structural features of the syntax tree to be extracted, and performing sensitive identification on the syntax tree to obtain sensitive structure markers, then concatenating the computable structural features and the sensitive structure markers to obtain a query fingerprint, specifically including: The syntax tree to be extracted is traversed to obtain multi-dimensional structural information, and the multi-dimensional structural information is arranged and spliced ​​according to a preset format to generate computable structural features; By scanning the syntax tree to be extracted, the field names to be identified in the request to be executed are obtained, and sensitive structure markers are identified based on the matching results of the field names to be identified with the preset sensitive rule base; wherein, the sensitive structure markers include: the bitmap position of the sensitive type and the parsing version number; By concatenating the computable structural features with the sensitive structural markers, a query string is obtained. The hash value of the query string is then calculated based on the first key to obtain the query fingerprint.

3. The database access behavior tracking method according to claim 1, characterized in that, Based on the source of the request to be executed, the contextual features of the request to be executed are collected to generate a source fingerprint based on the contextual features, specifically including: Determine the source of the request to be executed and collect the contextual features of the source of the request to be executed; The source fingerprint is obtained by calculating the hash value of the context features based on the second key.

4. The database access behavior tracking method according to claim 1, characterized in that, The session parameters of the request to be executed are determined by combining a pre-set lease generation counter, and a session fingerprint is generated based on the session parameters, specifically including: Based on the physical connection corresponding to the request to be executed, determine the connection pool corresponding to the physical connection and the authorized user hash value bound to the physical connection; Construct a pre-set lease generation counter for each physical connection in the corresponding connection pool; wherein the pre-set lease generation counter is set to 1 when the corresponding physical connection is first retrieved from the connection pool, and increments by 1 each time it is retrieved; When the current database access behavior obtains a physical connection from the corresponding connection pool, the physical identifier corresponding to the physical connection is obtained; The physical identifier, the value of the preset lease generation counter, and the authorized user hash value are used as session parameters for the request to be executed. The session parameters are concatenated sequentially to obtain a session parameter string, and the hash value of the session parameter string is calculated based on the third key to obtain the session fingerprint.

5. The method for tracking database access behavior according to claim 1, characterized in that, Each execution event in the event stream must include at least: root-level trace identifier, statement sequence number, and timestamp.

6. The database access behavior tracking method according to claim 5, characterized in that, Based on the fields of the event stream, the call chain of the current database access behavior is reconstructed, specifically including: Based on the root-level tracing identifier of each execution event in the event stream, the event stream is clustered to obtain a candidate link set; the root-level tracing identifier is obtained by parsing the tracing token, and the same candidate link set belongs to the same level of request; Based on the statement sequence number, each execution event in the candidate link set is grouped and arranged, and the sorted execution events are connected according to the partial order rules of the preset application events to reconstruct the call link of the current database access behavior.

7. The method for tracking database access behavior according to claim 2, characterized in that, The method further includes: After obtaining the call chain that restores the current database access behavior, risk tags are generated by matching the sensitive structure markers with a preset risk rule base. Output the call chain obtained from the restoration and the risk label.

8. A database access behavior tracking device, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in any one of claims 1-7.

Images