Cross-domain data security governance and audit tracing system

Abstract

The invention discloses a cross-domain data security governance and auditing traceability system, relates to the field of auditing traceability, solves the problem of hysteresis of auditing traceability, and comprises a user calibration module, an auditing access module, an exception recognition module and a log analysis module, the user calibration module is used for calibrating the user identity category of each user; the audit access user executes service operation on the cross-domain files through an audit access module, and records corresponding user single-day event streams based on operation results to obtain file audit logs of different cross-domain files; the exception identification module is used for analyzing the user access condition according to the user single-day event flow to obtain an exception cross-domain file; the log analysis module is used for carrying out audit analysis on the file audit log of the abnormal cross-domain file, no operation is carried out based on an audit result or a corresponding user is pulled into an abnormal list, and timely and complete audit tracing is achieved through identification and analysis of the abnormal cross-domain file.

Description

Technical Field

[0001] This invention belongs to the field of audit traceability technology, specifically a cross-domain data security governance and audit traceability system. Background Technology

[0002] Audit traceability refers to the technical means used in auditing to track and verify the data change process. By recording, tracking, and verifying all critical operations and data changes in a system or business process, it aims to ensure the integrity, compliance, and traceability of data. Cross-domain security governance refers to establishing unified security policies, controls, and collaboration mechanisms between different security domains to ensure the security, compliance, and trustworthiness of data, resources, and operations during cross-domain interactions. Its core objective is to address the security risks arising from inter-domain differences and achieve secure cross-boundary collaboration. Audit traceability focuses on the security control of data operation behaviors. However, at present, when performing audit tracing, the administrator of cross-domain data often needs to confirm the existence of abnormal cross-domain files before audit tracing can be carried out. Instead, the audit tracing is based on the analysis of cross-domain file access events and business events, which leads to the lag and incompleteness of audit tracing. To address this, the present invention proposes a cross-domain data security governance and audit traceability system. Summary of the Invention

[0003] The purpose of this invention is to propose a cross-domain data security governance and audit traceability system to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A cross-domain data security governance and audit traceability system includes a user identification module, an audit access module, an anomaly identification module, and a log analysis module. The user identification module is used to identify the user identity category of each user and record the corresponding user as an audit access user to grant audit access permissions or force logout. The audit access module is used by audit access users. Audit access users perform business operations on cross-domain files through the audit access module. Based on the operation results, the corresponding user's daily event stream is recorded and sent to the anomaly identification module. The file audit logs of different cross-domain files are then sent to the log analysis module. The anomaly identification module is used to analyze the user's access status based on the user's daily event flow, and send the abnormal cross-domain files to the log analysis module; the log analysis module is used to perform audit analysis on the file audit logs of the abnormal cross-domain files, and based on the audit results, take no action or add the corresponding user to the anomaly list.

[0005] Furthermore, the calibration process of the user calibration module is as follows: After a user logs in, their identification identifier is collected. The identification identifier is matched with multiple violation identifiers corresponding to the abnormal list in the pre-existing database. If the identification identifier is the same as any violation identifier, the corresponding user will be forcibly logged out. If the identification identifier is different from all the violation identifiers in the exception list, the identification identifier will be matched with the audit identifier of the audit access user stored in the database. If the identification identifier is the same as any audit identifier, the corresponding user will be recorded as an audit access user and granted the corresponding audit access permissions. If the identification identifier is different from all audit identifiers, the user will not be granted access permissions.

[0006] Furthermore, the specific working process of the audit access module is as follows: Obtain the audit access permissions corresponding to the audit access user. If the audit access user does not have audit access permissions, force the corresponding audit access user to log out. If the user has audit access privileges, no action will be taken. When an audit access user accesses any cross-domain file, the current time is read and recorded as the start time of the access, and the physical address of the corresponding cross-domain file is identified; the operation of accessing the cross-domain file is recorded as the access event of the corresponding audit access user.

[0007] Furthermore, the operation of the audit access module also includes: If an audit access user performs any type of business operation on a cross-domain file, the current time is read and recorded as the start time of the business operation, and a snapshot of the cross-domain file's state at the start time of the business operation is saved; until the audit access user submits the result of the business operation, the submission time is recorded as the end time of the business operation, and then a snapshot of the cross-domain file's state at the end time of the business operation is recorded. Read the physical address of the cross-domain file being manipulated; construct the corresponding audit access user's business event; All access events and business events of the same audit access user on the same day are summarized into the user's daily event stream for the corresponding audit access user; all access events and business events corresponding to the same cross-domain file on the same day are summarized into the file audit log for the corresponding cross-domain file.

[0008] Furthermore, the specific working process of the anomaly detection module is as follows: Obtain the daily event stream of all audit access users and count the daily file access count of each audit access user; read the audit identifier of each audit access user; identify the historical file access count of the corresponding audit access user based on the audit identifier; The historical access counts of the same audit access user are summed and averaged to obtain the historical access mean; then the standard deviation of the historical file access count is calculated based on the historical access mean and the historical file access count. The first comparison threshold is obtained by subtracting the standard deviation of K times the number of historical file visits from the historical average access value; the second comparison threshold is obtained by adding K times the standard deviation of the number of historical file visits to the historical average access value; where K is a constant used to adjust the actual values ​​of the first comparison threshold and the second comparison threshold.

[0009] Furthermore, the operation of the anomaly detection module also includes: The daily file access count of the audited user is compared with the first comparison threshold and the second comparison threshold respectively; if the daily file access count is greater than or equal to the first comparison threshold and less than or equal to the second comparison threshold, no operation is performed. If the number of daily file accesses is less than the first comparison threshold or greater than the second comparison threshold, then all cross-domain files accessed by the audited user on that day will be recorded as abnormal cross-domain files.

[0010] Furthermore, the analysis process of the log analysis module is as follows: Retrieve all abnormal cross-domain files, identify the physical address of the abnormal cross-domain files, and read the file audit log of the corresponding cross-domain file based on the physical address; For any abnormal cross-domain file's file audit log, identify the corresponding business event in the file audit log; obtain the audit identifier of the business event operator based on the business event; and search for the access event of the corresponding audit access user in the file audit log using the audit identifier.

[0011] Furthermore, the analysis process of the log analysis module also includes: If there is no access event for the corresponding audit user or the access event for the corresponding audit user occurs after the business event, the corresponding audit user will be added to the exception list. If there is an access event for a corresponding audited user, and the access event occurred before the corresponding business event, then Identify the state snapshot corresponding to each event in the file audit log, arrange the state snapshots in chronological order, number each state snapshot, and obtain the file state chain corresponding to the abnormal cross-domain file.

[0012] Furthermore, the analysis process of the log analysis module also includes: Identify all even-numbered state snapshots in the entire file state chain and compare them with the next state snapshot; if the even-numbered state snapshot is exactly the same as the next state snapshot, do not perform any operation. If the state snapshot with an even number is different from the next state snapshot, then the number of the next state snapshot is recorded as the exception number. The position of the abnormal event in the file audit log is obtained by adding one to the value of the abnormal number and dividing by two. The audit identifier of the audit access user corresponding to the abnormal event is read from the file audit log. The audit access user is then identified based on the audit identifier and added to the abnormal list.

[0013] Furthermore, the process of comparing the state snapshots is as follows: Get any state snapshot, identify the metadata, access path and version number corresponding to the state snapshot; convert the metadata, access path and version number into string representations, and then calculate the source data hash value, access path hash value and version number hash value in sequence using a preset hash algorithm; Similarly, extract the metadata, access path, and version number from another state snapshot to be compared, calculate the corresponding hash value, and compare them; if the hash values ​​of all corresponding attributes are exactly the same, then the two state snapshots are considered to be exactly the same; if the hash values ​​of any attribute are inconsistent, then the two state snapshots are considered to be different.

[0014] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention first identifies the user identity category of each user through a user identification module, and records the corresponding user as an audit access user, granting audit access permissions or forcibly logging out; then, the audit access user performs business operations on cross-domain files through the audit access module, and records the corresponding user's daily event stream based on the operation results and sends it to the anomaly identification module, obtaining file audit logs for different cross-domain files and sending them to the log analysis module; this invention records the operation relationship between all audit access users and cross-domain files.

[0015] 2. This invention utilizes an anomaly identification module to analyze user access patterns based on daily event flows, identifying abnormal cross-domain files and sending them to a log analysis module. The log analysis module then performs audit analysis on the audit logs of these abnormal cross-domain files, taking no action based on the audit results or adding the corresponding user to an anomaly list. This invention achieves timely and complete audit traceability through the identification and analysis of abnormal cross-domain files. Attached Figure Description

[0016] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0017] Figure 1 This is an overall system block diagram of the present invention; Figure 2 This is a schematic diagram of a user's daily event flow in this invention; Figure 3 This is a schematic diagram of the file audit log in this invention; Figure 4 This invention relates to a method flowchart. Detailed Implementation

[0018] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: Please refer to Figures 1-3 As shown, the technical solution provided by the present invention is: a cross-domain data security governance and audit traceability system, which involves a management platform, including a user identification module, a database, an audit access module, an anomaly identification module, a log analysis module, and an alarm module; In this invention, files in cross-domain data are defined as cross-domain files; The user identification module is used to identify the user identity category of each user in the management platform. The identification process is as follows: After a user logs in, the system collects the identification identifier of each user on the access management platform. The identification identifier is a core field that can accurately identify the user's identity in the system, and it is usually a combination of letters and numbers. The identification identifier is matched with multiple violation identifiers corresponding to the abnormal list in the pre-existing database. If the identification identifier is the same as any violation identifier, the corresponding user will be forcibly logged out. If the identification identifier is different from all the violation identifiers in the exception list, the identification identifier will be matched with the audit identifier of the audit access user stored in the database. If the identification identifier is the same as any audit identifier, the corresponding user will be recorded as the audit access user and the audit access user will be granted the corresponding audit access permissions. It should be noted that users with audit access permissions can perform business operations on cross-domain files in the system; specifically, business operations include: adding cross-domain files, deleting cross-domain files, modifying cross-domain files, and searching for cross-domain files. If the identification identifier is different from all audit identifiers, the user is not granted access rights.

[0020] In this invention, the audit access module is used by audit access users. Audit access users perform business operations on cross-domain files through the audit access module. The working process is as follows: Obtain the audit access permissions corresponding to the audit access user. If the audit access user does not have audit access permissions, force the corresponding audit access user to log out; this indicates that the corresponding audit access user is a fake user without permissions. Specifically, the system reads the data fields related to audit access permissions of the audit access user and matches them with the permission database. If the match is successful (the corresponding data field exists in the permission database), it means that the user has audit access permissions. If the match fails, it means that the corresponding audit access user does not have permission to access. If the user has audit access privileges, no action will be taken. When an audited user accesses any cross-domain file, the current time is read and recorded as the start time of the access, and the physical address of the corresponding cross-domain file is identified; the operation of accessing the cross-domain file is recorded as the access event of the corresponding audited user. The format of the access event is: audit identifier of the user who is auditing the access - access start time - physical address of the cross-domain file; If an audit access user performs any type of business operation on a cross-domain file, the current time is read and recorded as the start time of the business operation, and a snapshot of the cross-domain file's state at the start time of the business operation is saved; until the audit access user submits the result of the business operation, the submission time is recorded as the end time of the business operation, and then a snapshot of the cross-domain file's state at the end time of the business operation is recorded. The status snapshot includes a status snapshot identifier (such as snapshot ID), file access path, version number, business operation type, and metadata; Read the physical address of the cross-domain file being manipulated; construct the corresponding audit access user's business event; The format of the business event is as follows: business operation type - business start time - state snapshot at business start time - business end time - state snapshot at business end time - physical address of the cross-domain file; All access events and business events of the same audit access user on the same day are summarized into the user's daily event stream for the corresponding audit access user; all access events and business events corresponding to the same cross-domain file on the same day are summarized into the file audit log for the corresponding cross-domain file; Specifically, the daily event flow for user A, who was audited, is as follows: Access event (access cross-domain file A) - Modify event (modify the content in cross-domain file A) - Access event (access cross-domain file A) - Access event (access cross-domain file C) - Delete event (delete the content in cross-domain file C). The file audit log for cross-domain file A is as follows: Access event (audited access user A accesses) - Modification event (audited access user A modifies the content of a cross-domain file) - Access event (audited access user B accesses) - Delete event (audited access user B deletes the content of a cross-domain file).

[0021] The audit access module sends the daily event stream of all audit access users to the anomaly identification module, and sends the file audit logs of all cross-domain files to the log analysis module.

[0022] In this invention, the anomaly identification module is used to analyze the user access behavior of audited users. The analysis process is as follows: Obtain the daily event stream of all audit access users and count the daily file access count of each audit access user; read the audit identifier of each audit access user; identify the historical file access count of the corresponding audit access user based on the audit identifier; Specifically, the historical file access count is the daily file access count of the audited user in the corresponding period; The historical access counts of the same audit access user are summed and averaged to obtain the historical access mean; then the standard deviation of the historical file access count is calculated based on the historical access mean and the historical file access count. The first comparison threshold is obtained by subtracting the standard deviation of K times the number of historical file visits from the historical average access value; the second comparison threshold is obtained by adding K times the standard deviation of the number of historical file visits to the historical average access value; where K is a constant, specifically used to adjust the actual values ​​of the first comparison threshold and the second comparison threshold, preferably K=3; The daily file access count of the audited user is compared with the first comparison threshold and the second comparison threshold respectively; if the daily file access count is greater than or equal to the first comparison threshold and less than or equal to the second comparison threshold, no operation is performed. If the number of daily file accesses is less than the first comparison threshold or greater than the second comparison threshold, then all cross-domain files accessed by the audited user on that day will be recorded as abnormal cross-domain files. The anomaly analysis module sends the abnormal cross-domain file to the log analysis module.

[0023] In this invention, the log analysis module is used to analyze the audit logs after receiving an anomaly identification signal. The specific analysis process is as follows: Retrieve all abnormal cross-domain files, identify the physical address of the abnormal cross-domain files, and read the file audit log of the corresponding cross-domain file based on the physical address; For any abnormal cross-domain file's file audit log, identify the corresponding business event in the file audit log; obtain the audit identifier of the business event operator based on the business event; and search for the access event of the corresponding audit access user in the file audit log using the audit identifier. If there is no access event for the corresponding audit user or the access event for the corresponding audit user occurs after the business event, a warning signal will be generated and the corresponding audit user will be added to the abnormal list. It should be noted that since access events and business events in the file audit log are arranged in chronological order, if there is no access event corresponding to the audit user, it means that the corresponding audit user did not access the corresponding cross-domain file but performed operations on the cross-domain file. If there is an access event for a corresponding audited user, and the access event occurred before the corresponding business event, then Identify the state snapshot corresponding to each event in the file audit log, arrange the state snapshots in chronological order, number each state snapshot with n, and obtain the file state chain of the corresponding abnormal cross-domain file; Identify all even-numbered state snapshots in the entire file state chain and compare them with the next state snapshot; if the even-numbered state snapshot is exactly the same as the next state snapshot, do not perform any operation. In this invention, the process of comparing two state snapshots is as follows: Get any state snapshot, identify the metadata, access path and version number corresponding to the state snapshot; convert the metadata, access path and version number into string representations, and then calculate the source data hash value, access path hash value and version number hash value in sequence using a preset hash algorithm; Optionally, the hash algorithm can be SHA-256, SHA-3, or BLAKE2. Similarly, extract the above attributes from another state snapshot to be compared, calculate the corresponding hash values ​​and compare them; if all corresponding attributes have the same hash value, then the two state snapshots are considered to be identical; if any attribute has a different hash value, then the two state snapshots are considered to be different. If a state snapshot with an even number differs from the next state snapshot, the number of the next state snapshot is recorded as the exception number; specifically, state snapshot number 2 is compared with state snapshot number 3; state snapshot number 4 is compared with state snapshot number 5. The position of the abnormal event in the file audit log is obtained by adding one to the value of the abnormal number and dividing by two. The audit identifier of the audit access user corresponding to the abnormal event is read from the file audit log. The audit access user is identified based on the audit identifier and added to the abnormal list. Then, a warning signal is generated. For example, if the exception number is 5, then (5+1) / 2=3, so the third event in the file audit log is an exception event; The log analysis module stores the audit identifiers corresponding to the audited access users who are added to the abnormal list in the database and sends warning signals to the alarm module. In this invention, the alarm module is used to issue a warning to the administrator of the cross-domain file after receiving a warning signal. The administrator of the cross-domain file can locate the abnormal cross-domain file based on the warning signal and take corresponding measures.

[0024] Example 2: As Figure 4 As shown, based on another concept of the same invention, a cross-domain data security governance and audit traceability method is proposed, including the following steps: Step S101: Collect the identification identifier of each user, determine the identity category of the corresponding user based on the identification identifier, and grant the corresponding user audit access or add the corresponding user to the abnormal list. Step S102: The user performs business operations on cross-domain files with audit access permissions, and records the user's daily event stream and the file audit logs of different cross-domain files. Step S103: Analyze the user's access status based on the user's daily event stream to obtain abnormal cross-domain files; Step S104: Perform audit analysis on the file audit logs of the abnormal cross-domain files, and take no action based on the audit results or add the corresponding user to the abnormal list.

[0025] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A cross-domain data security governance and audit traceability system, characterized in that, It includes a user identification module, an audit access module, an anomaly identification module, and a log analysis module. The user identification module is used to identify the user identity category of each user and record the corresponding user as an audit access user to grant audit access permissions or force logout. The audit access module is used by audit access users. Audit access users perform business operations on cross-domain files through the audit access module. Based on the operation results, the corresponding user's daily event stream is recorded and sent to the anomaly identification module. The file audit logs of different cross-domain files are then sent to the log analysis module. The anomaly identification module is used to analyze the user's access status based on the user's daily event flow, and send the abnormal cross-domain files to the log analysis module; the log analysis module is used to perform audit analysis on the file audit logs of the abnormal cross-domain files, and based on the audit results, take no action or add the corresponding user to the anomaly list.

2. The cross-domain data security governance and audit traceability system according to claim 1, characterized in that, The calibration process of the user calibration module is as follows: After a user logs in, their identification identifier is collected. The identification identifier is matched with multiple violation identifiers corresponding to the abnormal list in the pre-existing database. If the identification identifier is the same as any violation identifier, the corresponding user will be forcibly logged out. If the identification identifier is different from all the violation identifiers in the exception list, the identification identifier will be matched with the audit identifier of the audit access user stored in the database. If the identification identifier is the same as any audit identifier, the corresponding user will be recorded as an audit access user and granted the corresponding audit access permissions. If the identification identifier is different from all audit identifiers, the user will not be granted access permissions.

3. The cross-domain data security governance and audit traceability system according to claim 1, characterized in that, The specific working process of the audit access module is as follows: Obtain the audit access permissions corresponding to the audit access user. If the audit access user does not have audit access permissions, force the corresponding audit access user to log out. If the user has audit access privileges, no action will be taken. When an audit access user accesses any cross-domain file, the current time is read and recorded as the start time of the access, and the physical address of the corresponding cross-domain file is identified; the operation of accessing the cross-domain file is recorded as the access event of the corresponding audit access user.

4. The cross-domain data security governance and audit traceability system according to claim 3, characterized in that, The working process of the audit access module also includes: If an audit access user performs any type of business operation on a cross-domain file, the current time is read and recorded as the start time of the business operation, and a snapshot of the cross-domain file's state at the start time of the business operation is saved; until the audit access user submits the result of the business operation, the submission time is recorded as the end time of the business operation, and then a snapshot of the cross-domain file's state at the end time of the business operation is recorded. Read the physical address of the cross-domain file being manipulated; construct the corresponding audit access user's business event; All access events and business events of the same audit access user on the same day are summarized into the user's daily event stream for the corresponding audit access user; all access events and business events corresponding to the same cross-domain file on the same day are summarized into the file audit log for the corresponding cross-domain file.

5. The cross-domain data security governance and audit traceability system according to claim 1, characterized in that, The specific working process of the anomaly detection module is as follows: Obtain the daily event stream of all audit access users and count the daily file access count of each audit access user; read the audit identifier of each audit access user; identify the historical file access count of the corresponding audit access user based on the audit identifier; The historical access counts of the same audit access user are summed and averaged to obtain the historical access mean; then the standard deviation of the historical file access count is calculated based on the historical access mean and the historical file access count. The first comparison threshold is obtained by subtracting the standard deviation of K times the number of historical file visits from the historical average access value; the second comparison threshold is obtained by adding K times the standard deviation of the number of historical file visits to the historical average access value; where K is a constant used to adjust the actual values ​​of the first comparison threshold and the second comparison threshold.

6. The cross-domain data security governance and audit traceability system according to claim 5, characterized in that, The operation of the anomaly detection module also includes: The daily file access count of the audited user is compared with the first comparison threshold and the second comparison threshold respectively; if the daily file access count is greater than or equal to the first comparison threshold and less than or equal to the second comparison threshold, no operation is performed. If the number of daily file accesses is less than the first comparison threshold or greater than the second comparison threshold, then all cross-domain files accessed by the audited user on that day will be recorded as abnormal cross-domain files.

7. The cross-domain data security governance and audit traceability system according to claim 1, characterized in that, The analysis process of the log analysis module is as follows: Retrieve all abnormal cross-domain files, identify the physical address of the abnormal cross-domain files, and read the file audit log of the corresponding cross-domain file based on the physical address; For any abnormal cross-domain file's file audit log, identify the corresponding business event in the file audit log; obtain the audit identifier of the business event operator based on the business event; and search for the access event of the corresponding audit access user in the file audit log using the audit identifier.

8. The cross-domain data security governance and audit traceability system according to claim 7, characterized in that, The analysis process of the log analysis module also includes: If there is no access event for the corresponding audit user or the access event for the corresponding audit user occurs after the business event, the corresponding audit user will be added to the exception list. If there is an access event for a corresponding audited user, and the access event occurred before the corresponding business event, then Identify the state snapshot corresponding to each event in the file audit log, arrange the state snapshots in chronological order, number each state snapshot, and obtain the file state chain corresponding to the abnormal cross-domain file.

9. A cross-domain data security governance and audit traceability system according to claim 8, characterized in that, The analysis process of the log analysis module also includes: Identify all even-numbered state snapshots in the entire file state chain and compare them with the next state snapshot; if the even-numbered state snapshot is exactly the same as the next state snapshot, do not perform any operation. If the state snapshot with an even number is different from the next state snapshot, then the number of the next state snapshot is recorded as the exception number. The position of the abnormal event in the file audit log is obtained by adding one to the value of the abnormal number and dividing by two. The audit identifier of the audit access user corresponding to the abnormal event is read from the file audit log. The audit access user is then identified based on the audit identifier and added to the abnormal list.

10. A cross-domain data security governance and audit traceability system according to claim 9, characterized in that, The comparison process of the state snapshot is as follows: Get any state snapshot, identify the metadata, access path and version number corresponding to the state snapshot; convert the metadata, access path and version number into string representations, and then calculate the source data hash value, access path hash value and version number hash value in sequence using a preset hash algorithm; Similarly, extract the metadata, access path, and version number from another state snapshot to be compared, calculate the corresponding hash value, and compare them; if the hash values ​​of all corresponding attributes are exactly the same, then the two state snapshots are considered to be exactly the same; if the hash values ​​of any attribute are inconsistent, then the two state snapshots are considered to be different.

Images