Data service and security obligation integrated semantic audit log generation method

Abstract

The application discloses a kind of data service and security obligation integration semantic audit log generation method.Record triadic semantic context (subject class · resource class · purpose class) when access control decision;After security obligation execution is completed, write unified audit log entry containing service operation information and obligation execution information in the same database transaction with atomic operation, if write fails, the entire service request is rolled back;Each log entry contains SM3 hash link field, so that historical records cannot be tampered with;Synchronous automatic completion of multi-framework compliance clause reference annotation is completed when log is generated;Based on the compliance proof report that hash chain log can be independently verified by third party is generated at any time after SM2 signature is added.The application also supports: data processing pipeline components and data service gateway use unified log format, SM3 hash chain is continuous across components;Audit log generated by delayed obligation compensation execution is appended to the end of existing hash chain.The application makes compliance proof become real-time byproduct of system operation.

Description

Technical Field

[0001] This invention relates to the field of data security compliance and auditing technology, specifically to a method and system for atomically generating service operation logs and security obligation execution logs during data service execution, ensuring immutability through an SM3 hash chain, and simultaneously annotating compliance clauses during generation. Background Technology

[0002] Existing data security audit systems have three fundamental problems: First, the service log and obligation log systems are separate; second, compliance proof is a post-event process that is time-consuming and lacks cryptographic non-repudiation; and third, logs can be tampered with, and the credibility of compliance proof depends on human integrity rather than technical mechanisms. Summary of the Invention

[0003] This invention provides a method for generating semantic audit logs that integrates data services and security obligations. A ternary semantic context records the subject, resource, and purpose semantic classes. Service logs and obligation logs are generated atomically within the same transaction. An SM3 hash chain ensures immutability, and compliance clauses are synchronously annotated during log generation. SM2 signature compliance reports are available at any time. This invention also extends hash chain coverage from the service state to the pipeline state and supports appending audit logs for delayed obligation compensation. Attached Figure Description

[0004] Figure 1 The overall flowchart for the semantic audit log generation method. Figure 1 This invention demonstrates its five-step overall process. Step 1: Three-element semantic context construction: Based on the P1 inference engine, the subject, resource, and purpose of the service request are mapped to corresponding semantic class identifiers, recording the complete inference path (including trigger rule identifiers and inference chains). Step 2: Obligation execution + atomic log writing: After the obligation is executed, a unified log entry containing service operation information and obligation execution information is written atomically within the same database transaction. If the write fails, the entire service request is rolled back. Step 3: SM3 hash chain maintenance: The SM3 hash value of the current entry is calculated, and the hash values ​​of previous entries are stored in the `sm_prev` field, forming an immutable hash chain. Step 4: Compliance clause synchronous annotation: Multi-framework compliance clause reference annotation is automatically completed during log generation, without relying on post-processing; the knowledge base maintains the mapping relationship. Step 5: SM2 signature compliance proof generation: A compliance proof report containing obligation coverage statistics, violation summaries, and clause satisfaction status is generated, with an attached SM2 digital signature, which can be independently verified by third parties.

[0005] Figure 2 This is a schematic diagram of the audit log field structure and SM3 hash chain. Figure 2The complete field structure of the audit log is displayed, divided into five groups: Basic Identifier Group (log_id, timestamp including trusted timestamp, request_id, component_type distinguishing P2 / DSOP / SDK); Subject Semantic Group (subject_class, subject_org, trust_score, purpose_class, all from the P1 inference engine); Resource Semantic Group (resource_class, security_level, data_hash); Obligation Execution Group (obligation_types, execution_params, execution_status); Linked Compliance Group (compliance_tags including multi-framework clause references, sm_prev including previous hash value, hash including current SM3 hash value). The sm_prev field is the key to the hash chain, connecting log entries from different components across component boundaries, enabling the hash chain to cover the entire lifecycle from pipeline state to service state.

[0006] Figure 3 This is a diagram illustrating the parallel annotation of multiple frameworks for compliance clauses. Figure 3 This demonstrates a mechanism for automatically labeling the same obligation execution event with multiple compliance framework clauses. The left side shows the triggering obligation execution events: Subject ExternalResearcher accessing DiagnosisRecord (L3), Purpose ResearchAccess, Decision ConditionalAllow, Execution MaskingObligation, and kAnonymityObligation (k≥5). The middle section shows automatic labeling in the knowledge base. The right side displays three frameworks side-by-side: Personal Information Protection Law (Article 28 Sensitive Personal Information Processing, Article 13 Research Exception, Article 51 Obligations of Personal Information Processors); Data Security Law (Article 27 Data Security Protection Obligations, Article 21 Data Classification and Grading Protection); and Industry Standard (GB / T 35273-2023, National Health Commission Data Security Management Measures). When the compliance framework is updated, only the mapping relationships in the knowledge base need to be updated; the audit log system does not require modification.

[0007] Figure 4 This is a diagram of a continuous architecture for cross-component hash chains. Figure 4This demonstrates an architecture where audit logs from multiple components form a continuous hash chain across components via the `sm_prev` field. Each of the three components (DSOP pipeline component, P2 semantic gateway, and SDK obligation proxy) generates its own audit log entries, with the `component_type` field distinguishing the source. DSOP pipeline component log (log_1): Contains three integrity proof fields: `input_data_hash`, `output_data_hash`, and `obligation_sequence_hash`, with `sm_prev=null` (chain start point) and `hash=H_DSOP`. P2 semantic gateway log (log_2): `sm_prev=H_DSOP`, `hash=H_P2`. SDK obligation proxy log (log_3): `sm_prev=H_P2`, `hash=H_SDK`. Note: The three logs form a continuous hash chain via the `sm_prev` field; any tampering with the logs from any component will cause subsequent hash chain verification to fail. Delayed obligation compensation logs are appended to the end of the chain, with `compensation_flag=true` indicating the difference between the original processing and the compensation processing. Detailed Implementation

[0008] Example 1: Audit Log of Patient Data Query Interface The ternary semantic context is: subject_class=ExternalResearcher, resource_class=DiagnosisRecord, purpose_class=ResearchAccess. The inference engine returns ConditionalAllow, with an obligation set {MaskingObligation(diagnosis), kAnonymityObligation(k≥5)}. After the obligation is executed, it is atomically written to the audit log, synchronously annotating Articles 28 and 13 of the Individual Income Tax Protection Law and Article 27 of the Data Security Law.

[0009] Example 2: Cross-component hash chain DSOP pipeline log: log_id=DSOP_001, component_type=DSOP, input_data_hash=H1, output_data_hash=H2, obligation_sequence_hash=H3, hash=H_DSOP; P2 gateway log: sm_prev=H_DSOP, hash=H_P2. The two logs form a cross-component hash chain through the sm_prev field.

[0010] Example 3: Adding to the Audit Log of Delay Obligation Compensation Compensation audit log: compensation_flag=true, original_timestamp=data entry time, compensation_timestamp=compensation execution time, sm_prev references the hash value of the preceding entry at the end of the chain. This allows for differentiation between original processing and compensation processing during compliance audits.

Claims

1. A method for generating semantic audit logs that integrate data services and security obligations, characterized in that, Includes the following steps: (1) When executing access control decisions at the data service interface, record the three-element semantic context, including: the semantic class identifier of the requesting subject, the semantic class identifier of the requested resource, and the semantic class identifier of the purpose of this access; (2) After the security obligation is completed, write the audit log entry in an atomic manner within the same database transaction. The audit log entry contains all the contents of service operation information and obligation execution information, ensuring that the two types of information are inseparable in the same record. (3) Each audit log entry contains a hash link field, which stores the hash value of the previous log entry. The hash value of the current entry is obtained by performing a national cryptographic SM3 hash calculation on all fields of the entry, so that the historical audit records form an immutable hash chain. (4) While writing audit log entries, simultaneously mark the references to compliance framework clauses related to this access control decision and obligation execution. The marking does not depend on post-event processing and is automatically completed by the system when the log is generated. (5) Based on the audit logs generated in steps (3) and (4), generate a compliance certification report. The report includes statistics on the coverage of obligations, a summary of violations, and the compliance status within a specified time period. After attaching an SM2 digital signature, it can be independently verified by a third party.

2. The method according to claim 1, characterized in that, In step (1), the construction of the ternary semantic context is based on the reasoning engine of the security semantic knowledge base. The reasoning engine maps the specific identity identifier, resource identifier and access purpose in the request to the corresponding semantic class, and records the complete reasoning path during the reasoning process. The reasoning path includes the triggered rule identifier and the derivation chain.

3. The method according to claim 1, characterized in that, In step (2), the writing operation of the audit log entry is completed in the same database transaction as the data service operation. If the audit log writing fails, the entire service request is rolled back to ensure the strict atomicity of the data service operation and the audit record.

4. The method according to claim 1, characterized in that, In step (4), the reference to compliance framework clauses supports the parallel annotation of multiple frameworks, and the same audit log entry can simultaneously annotate relevant clauses in multiple compliance frameworks; The annotation is automatically completed by the mapping relationship between obligation types and compliance clauses stored in the security semantic knowledge base. When the compliance framework is updated, only the mapping relationship in the knowledge base needs to be updated, and the existing audit log system does not need to be modified.

5. The method according to claim 1, characterized in that, The audit log entry also includes a data content hash field, the hash value of which is calculated based on the SM3 of the data service response content. By comparing the response content hash with the hash value in the audit record, it can be verified whether the data service response content is consistent with the processing result described in the audit record.

6. The method according to claim 1, characterized in that, The obligation execution audit logs generated by the data processing pipeline components and the semantic audit logs generated by the data service access gateway adopt a unified field specification. Log entries of different component types are distinguished by the component_type field. The same hash chain can contain log entries from different components, so that the continuity of the hash chain crosses the component boundary. The complete obligation execution record of any dataset from pipeline processing to service access forms an unbreakable cross-component hash chain.

7. The method according to claim 6, characterized in that, Each obligation execution audit log entry generated by the data processing pipeline component also includes integrity proof fields: input_data_hash (SM3 hash value of the pipeline node's input dataset), output_data_hash (SM3 hash value of the pipeline node's output dataset), and obligation_sequence_hash (SM3 hash value of the sequence of obligation operations executed by this node). These three hash values ​​together constitute the integrity proof of the node's obligation execution process. Any tampering with the obligation execution process or input / output data will result in inconsistent hash values.

8. The method according to claim 6, characterized in that, When performing delayed obligation compensation processing on historical data, the audit log entries generated by the compensation execution are appended to the end of the existing hash chain of the dataset. The compensation log entries contain a special identifier field compensation_flag=true, the original dataset processing timestamp original_timestamp, and the compensation execution timestamp compensation_timestamp, making the temporal relationship between the compensation records and the original records clearly identifiable in the hash chain.

9. A semantic audit log generation system integrating data services and security obligations, characterized in that, include: The semantic context building module is configured to map the subject, resource, and destination of service requests to semantic class identifiers and record the reasoning path; The atomic log writing module is configured to atomically write service operation information and obligation execution information within the same database transaction. The SM3 hash chain module is configured to calculate the hash value of each log entry, maintain the hash chain association between log entries, and support continuity across components; The compliance clause annotation module is configured to automatically annotate the references to compliance framework clauses when logs are generated. The compliance proof report generation module is configured to generate compliance proof reports with additional SM2 signatures based on hash chain logs.

Images