Electronic license whole-process supervision system

Abstract

According to the electronic license full-process supervision system provided by the invention, the processing process of the log data is shortened, the processing process of the log data is simplified into three steps of acquisition, processing and storage, and the processing efficiency of the log data is improved; the supervision SDK realizes an acquisition step: acquiring log data, performing compression operation on the log data, and reporting the log data to a supervision log processing service; according to the method, the processing steps of preprocessing, storage buffering and the like are completed on the basis of the supervision log processing service, and then the storage step is achieved through the supervision log storage service. Two processing flows of preprocessing and storing log data can be completed by monitoring data transmission between double-memory buffer queues arranged in the log processing service.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic certificate management, and in particular to a full-process supervision system for electronic certificates. Background Art

[0002] Electronic certificates refer to various legally binding certificates, certifications, approvals, appraisal reports, and other electronic documents issued by entities in accordance with the law. Examples include electronic ID cards, marriage certificates, bank payment statements, and business licenses. With advances in information technology, the coordinated use of electronic certificates alongside physical certificates has become the mainstream method of certificate application. However, the regulation of electronic certificate use faces numerous challenges, such as recording and monitoring the electronic certificate application process and promptly detecting and warning of tampering and forgery.

[0003] Existing technologies typically use logs to record and monitor the use of electronic certificates. For example, the ELK log analysis system integrates three open-source tools: Elasticsearch, Logstash, and Kibana, providing users with log query, sorting, and statistics services. However, the ELK system requires a separate logging system deployment and goes through a process involving log collection, local storage, log upload, log formatting, writing to a message queue, reading from a message queue, and writing to a database. This process involves multiple disk reads and writes, relies on multiple components, consumes significant system performance, and requires significant server resources. The log data process involves the following: Each time a user request is processed, a log data entry is generated and sent to a message queue (MQ) cluster for caching, where it is available to log analysis tools. MQ also needs to write the data to disk to prevent data loss. Furthermore, the original log data requires distributed storage and backup, and both backup and distributed storage must be implemented based on MQ. For example, during backup, assuming a single-backup strategy is used, MQ needs to read the locally cached log data and write a single copy to the backup disk. Log data also involves a consumption cluster, which is only responsible for data exchange in memory and does not involve disk storage. After consumption is completed, the data will be written to the database.

[0004] Consider a scenario where, in a regional system dedicated to handling electronic certificates, a specific electronic certificate application generates an average log of approximately 50KB when processing a single user request. Under normal circumstances, this application processes approximately 10,000 to 20,000 requests per second. During peak periods, this number can increase to three to five times the normal rate, creating a massive read and write demand. Furthermore, multiple types of electronic certificates exist within the same system. Furthermore, considering the message queue clusters required for log transmission and data backup requirements, the logging system must process massive amounts of data during peak periods, placing significant demands on the system's server resources. Given the large volume of electronic certificate data and its frequent updates, existing electronic certificate supervision systems struggle to meet the requirements for comprehensive, accurate, and real-time monitoring of electronic certificate information. Summary of the Invention

[0005] In order to solve the problem that the existing electronic certificate supervision system cannot meet the application requirements of high concurrency and large traffic, the present invention provides an electronic certificate full-process supervision system, which can record the logs of the electronic certificate application process in real time, meet the application requirements of high concurrency and large traffic, and realize real-time supervision and full life cycle management of electronic certificates.

[0006] The technical solution of the present invention is as follows: a full-process supervision system for electronic certificates, characterized in that it includes: a monitoring center, a supervision SDK, a supervision log processing service, and a supervision log storage service; The supervision SDK is embedded in the electronic certificate system and pre-sets the operation types that require supervision, which are recorded as "supervision operations." When any of the supervision operations occur in the electronic certificate system, the supervision SDK captures the detailed information of these supervision operations and generates a supervision log according to a preset log format. The log information of the supervision log includes: log number, log-related business number, log collection time, log index information, and log details. The log index information includes: log retrieval and query information extracted from the log details. The monitoring center mainly provides service registration and service management functions for the supervision SDK and the supervision log processing service, monitors the operation status of the supervision log processing service, and provides an interface for obtaining a list of supervision log processing services; After the supervision log processing service is started, it first registers with the monitoring center and uploads the service IP address and service port. The supervision log processing service sends a heartbeat every T1 second. The monitoring center continuously monitors the heartbeat information of the registered service. If no heartbeat information is received within T2 cycles, the supervision log processing service is considered abnormal and removed from the service list. The supervision SDK provides log collection, log compression and log reporting functions; after startup, the supervision SDK connects to the monitoring center and calls the supervision log processing service list interface to obtain the currently available supervision log processing service; at the same time, the supervision SDK connects to the supervision log processing service; After the supervision SDK collects the supervision log, it performs a log compression operation; the log compression operation includes: a primary compression operation and a secondary compression operation; the primary compression operation is to compress the log details using a high-ratio compression algorithm to obtain compressed log details; the secondary compression operation is to replace the original log details with the compressed log details and perform a secondary compression together with other log information to obtain secondary compressed log information; The supervision SDK reports the secondary compressed log information to the supervision log processing service in real time; Setting up dual memory buffer queues within the supervision log processing service, the memory buffer queues including: a pre-processing queue and a write queue; The pre-processing queue is used to receive the secondary compressed log information data reported by the supervision SDK in real time and pre-process the data. The write queue is used to buffer the pre-processed data and wait for batch storage; The supervisory log processing service first initializes a thread pool manager and a queue dispatcher, which are denoted as: a first thread pool manager and a first queue dispatcher; The first queue distributor pulls N2 pieces of the secondary compressed log information from the pre-processing queue at a time interval of N1 milliseconds, and submits the pulled data to the first thread pool manager; The first thread pool manager randomly selects an idle thread as a preprocessing thread to preprocess the original log data, and converts the preprocessing thread into a non-idle thread; The preprocessing includes: the preprocessing thread first decompresses the secondary compressed log information to obtain primary compressed log data; after the first decompression is completed, the preprocessing thread formats the primary compressed log data; the formatting operation includes parsing log fields, converting log formats, and verifying the integrity and accuracy of log data to ensure that subsequent analysis and storage operations can be performed based on a unified and standardized data format; After completing the pre-processing operation, the compressed log data is pushed into the write queue; The supervision log processing service initializes a thread pool manager and a queue distributor again, which are recorded as: a second thread pool manager and a second queue distributor; The second queue distributor periodically pulls N4 pieces of the compressed log data from the write queue at a time of N3 milliseconds, and submits the pulled data to the second thread pool manager; The second thread pool manager randomly selects an idle thread as a writing thread for storing logs to the database, and converts the writing thread into a non-idle thread; The writing thread calls the supervision log storage service to write log data in batches into the supervision log storage service, and the supervision log storage service stores the data into the log storage module.

[0007] It is further characterized by: The supervision log processing service also includes the following operations: The supervision log processing service creates a connection manager, and the connection manager monitors multiple supervision SDKs based on IO multiplexing technology; The supervision log processing service first registers the supervision SDK connection to be monitored with the connection manager and sets up an internal queue buffer for each supervision SDK connection to temporarily store the secondary compressed log information reported by the supervision SDK; The connection manager will enter a read loop, calling the internal queue buffer of the connection every M0 milliseconds to check whether there is data; When there is data in the internal queue buffer, the connection manager reads the data from the N0 connection's internal queue buffer and sends it to the memory buffer queue inside the supervision log processing service; The supervisory operations include: application, issuance, presentation, renewal and cancellation of electronic certificates; The types of regulatory logs include: application log, issuance log, presentation log, update log, cancellation request log and cancellation log; The application log includes: the application request number generated by the electronic certificate system when the user applies for an electronic certificate, the user's identity information and the type of certificate applied for; The issuance log includes: the certificate information and approval results generated by the certificate issuing agency; The presentation log includes: the time and object of the electronic certificate generated by the electronic certificate system when the electronic certificate user uses the electronic certificate; The update log includes: when the electronic certificate is updated, the update request number generated by the electronic certificate system, the user's identity information and the updated certificate information; The cancellation request log includes: the cancellation request number generated by the electronic certificate system when the electronic certificate is cancelled, the user's identity information and the cancelled certificate information; The cancellation log includes: the cancellation result and approval result generated by the issuing agency after the electronic certificate is cancelled; The supervision log is stored in the log storage module in the form of a log chain. Each encrypted and signed supervision log is linked in the form of log records according to chronological order or business logic to form a complete log chain. In addition to containing its own information, each log record also contains a hash value pointing to the previous record, forming a chain structure. When a user submits an application for an electronic certificate, a globally unique certificate number ZZBH is first generated for each user; The certificate number ZZBH is generated using a highly secure random number algorithm in combination with user parameters, including a timestamp and user identity information. Based on the certificate number ZZBH, a new log chain record is created, referred to as the basic log chain record. The basic log chain record includes the application time, applicant information, certificate type, and initial status. The basic log chain record is used as the starting block of the log chain. When any of the aforementioned regulatory operations occur in the electronic certificate system, a new regulatory log record is generated based on the regulatory SDK and associated with the unique certificate number ZZBH. The newly generated log record is encrypted and signed according to the preset encryption and signature process; The encryption and signing process includes: encrypting each record in the log chain using a national secret symmetric encryption algorithm, and simultaneously performing a national secret digital signature on the encrypted data, using a private key to generate the signature; The log chain is stored in a distributed database. When the history or current status of a certain electronic certificate needs to be verified, the signature and hash value of each record are verified one by one by tracing the log chain starting from the application block. The log storage module provides a RESTful API or other standard interface for the early warning service to access the data in the supervision log chain; The warning services include: real-time warning service for supervision logs and dynamic warning service for supervision logs; The supervision log real-time warning service performs real-time monitoring on a single type of data; After the real-time warning service of the supervision log is started, the preset warning configuration information is read first; the warning configuration information includes: warning type, warning rules and warning description; The real-time supervision log warning service performs real-time verification of relevant data in the business process based on the warning rules it reads. Different warning rules correspond to different verification methods. During the verification process, the system determines whether the current data meets the warning conditions. When the real-time supervision log warning service detects data that meets the warning conditions, it immediately generates a warning message. The warning message includes: warning time, warning type, triggering rules, and specific data values. The real-time warning service of the supervision log will push the brief information of the warning information to the relevant personnel through the preset communication method according to the warning contact person specified in the warning configuration; the warning contact person can access the detailed content of the warning message according to the brief information of the warning information; The real-time early warning service for monitoring logs is provided with a monitoring node, and the method for the monitoring node to capture new log records on the log chain in real time includes: utilizing the event monitoring mechanism provided by the log chain storage network in the log storage module to capture new log records on the log chain in real time, or calling an API interface to regularly query new log records on the log chain; When capturing log records, the monitoring node ensures that the captured data includes the completeness of the key information of the log record, including the complete content, signature, hash value, and timestamp; The monitoring node uses the public key to verify the signature of the captured log record; the verification content includes: hash value verification and link relationship verification; when anomalies or potential risks are detected, the alarm mechanism is immediately triggered; The hash value verification is as follows: the monitoring node calculates the hash value of the captured log record and compares it with the hash value stored in the log record; if the two do not match, it indicates that the log record has been tampered with and is marked as abnormal; The link relationship verification is as follows: the monitoring node checks whether the captured log record is correctly linked to the previous log record; if the link relationship is incorrect, it indicates that the log chain has been broken and it is marked as abnormal; The regulatory log dynamic warning service makes a comprehensive judgment on whether multiple types of data are compliant after being combined, or makes a comprehensive judgment on whether multiple pieces of data of a single type are compliant after being superimposed; The supervision log dynamic warning service performs dynamic inspections according to pre-established inspection strategies; The inspection strategy includes inspection frequency, inspection content, and inspection scope. The inspection content includes: log record integrity check, signature validity verification, signature value correctness verification, and certificate application assessment. The inspection scope includes: comprehensive inspection of the entire log or partial inspection of logs within a specific time period. After the supervision log dynamic warning service is started, it first reads the preset warning configuration information and performs real-time verification on the relevant data in the business process according to the warning rules in the warning configuration information; when data that meets the warning conditions is detected, the detailed content of the warning message will be immediately generated; After each round of inspection, the supervision log dynamic warning service generates an inspection result report; the inspection result report includes: findings during the inspection, anomaly detection and processing results; When the supervisory log dynamic warning service performs dynamic inspections, it traverses each log record in the log chain and performs verification tasks, including integrity verification, signature verification, and hash value verification. During the verification process, the verification results of each log record are recorded, including the number of successfully verified log records, the number of anomalies found, and the type of anomalies. The supervision log real-time warning service and the supervision log dynamic warning service both cache the detailed content of the generated warning message into memory for subsequent access.

[0008] The present application provides a full-process supervision system for electronic certificates, which shortens the processing flow of log data and simplifies the processing flow of log data into three steps of collection, processing and storage, thereby improving the processing efficiency of log data; the supervision SDK implements the collection step, collects log data, compresses the log data and reports it to the supervision log processing service; based on the supervision log processing service, preprocessing, storage buffer and other processing steps are completed, and then the storage step is implemented through the supervision log storage service. The present application sets up a dual memory buffer queue inside the supervision log processing service, and based on the memory application thread pool manager and queue distributor, the two processing flows of preprocessing and storage of log data can be completed by transferring data between the dual memory buffer queues set up inside the supervision log processing service; compared with the method of implementing the above operations based on a distributed system in the prior art, the processing and storage steps of the reported log data in this system are all completed based on memory operations, and there is no need to transfer data and synchronize information between distributed systems, which greatly simplifies the steps of the log processing process, saves data transfer time, and effectively improves data processing efficiency. It is particularly suitable for meeting high concurrency and large traffic application requirements. At the same time, in this application, the log index information is extracted from the log details and stored separately for retrieval and query purposes. The log details with larger data size are subsequently transmitted and stored in the form of compressed data based on a high-ratio compression algorithm, which effectively reduces the memory demand during log data processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 This is the flowchart for processing the electronic license supervision log in this application; Figure 2 This is the architecture diagram of the electronic license supervision service; Figure 3 This is a diagram of the concurrent queue consumption model; Figure 4 A flowchart for proactive supervision of electronic certificates; Figure 5 Schematic diagram of the compression process of regulatory logs. DETAILED DESCRIPTION

[0010] like Figure 1and Figure 2 As shown, this application includes a full-process supervision system for electronic certificates, which includes: a monitoring center, a supervision SDK, a supervision log processing service, a supervision log storage service, a supervision log real-time warning service, and a supervision log dynamic warning service. Based on the collaborative work of these components, effective supervision of the entire electronic certificate process is achieved.

[0011] The Supervision SDK is embedded in the electronic certificate system and pre-configured with the types of operations requiring supervision, referred to as "supervision operations." Whenever any supervision operation occurs in the electronic certificate system, the Supervision SDK captures detailed information about these operations and generates a supervision log in a pre-set format. In practice, the Supervision SDK is built as a standalone software module, tightly integrated with the rest of the electronic certificate system while maintaining relative independence. The Supervision SDK calls an interface provided by the Supervision Center to obtain a list of supervision log processing services, connects to these services, and completes log reporting.

[0012] Connecting to the regulatory log processing service: The Regulatory SDK selects an appropriate service based on the list of regulatory log processing services. The connection process may involve steps such as identity authentication and permission checks.

[0013] Log reporting: The Supervision SDK reports compressed supervision logs to the connected supervision log processing service. This reporting process can be synchronous or asynchronous. Asynchronous reporting ensures that the normal operation of the e-certification system is not affected even in unstable networks or when the supervision log processing service is busy.

[0014] The log information of the supervision log includes: log number, log-related business number, log collection time, log index information and log details; The Regulatory SDK specifies the log format to ensure consistency and readability. The log format includes: Log Number: A unique identifier for each log.

[0015] Log-related business number: a unique identifier for the business operation associated with the log.

[0016] Log collection time: The timestamp when the log is collected.

[0017] Log index information includes log retrieval and query information extracted from log details.

[0018] Log details: describes the specific information of the business operation, such as operation type, operation result, etc.

[0019] Regulatory operations cover the entire life cycle of electronic certificates, including application, issuance, presentation, renewal and cancellation of electronic certificates.

[0020] Corresponding to the supervision operations, the types of supervision logs include: application log, issuance log, presentation log, update log, cancellation request log and cancellation log; The application log includes: the application request number generated by the electronic certificate system when the user applies for an electronic certificate, the user's identity information, and the type of certificate applied for; The issuance log includes: the certificate information and approval results generated by the certificate issuing agency; The presentation log includes: when the electronic certificate user uses the electronic certificate, the time and object of the electronic certificate generated by the electronic certificate system; The update log includes: the update request number generated by the electronic certificate system when the electronic certificate is updated, the user's identity information and the updated certificate information; The cancellation request log includes: the cancellation request number generated by the electronic certificate system when the electronic certificate is cancelled, the user's identity information, and the cancelled certificate information; The cancellation log includes: the cancellation results and approval results generated by the issuing agency after the electronic certificate is cancelled.

[0021] Specifically, during the application process, the user submits an application request through the system front-end. This request includes information such as the user's identity information and the type of certificate being applied for. Upon receiving the request, the system back-end first verifies the user's identity, utilizing authentication mechanisms (such as username and password verification, and biometrics) to ensure the authenticity and legitimacy of the user's identity. Once verified, the system generates a unique application request number and cryptographically signs this number along with the user's identity information, the type of certificate being applied for, and other information, creating an application log. This encrypted signature utilizes an advanced encryption algorithm to ensure the log's immutability. The application log is stored in the system's secure log repository, which employs high-level security measures to prevent unauthorized access or tampering. The system then sends the application request to the issuing authority for approval in real time, ensuring a timely and accurate approval process.

[0022] During the issuance phase, upon receiving an application, the issuing authority will review and approve the application based on pre-set approval rules. During the approval process, the application log is consulted to verify the authenticity and legitimacy of the request. Upon approval, the issuing authority generates an electronic certificate and encrypts and signs the certificate information along with the approval result, creating an issuance log. This issuance log is also stored in the system's secure log library. The system provides real-time feedback on the issuance result to the user and pushes the electronic certificate to the user's electronic certificate card wallet for easy access and use at any time.

[0023] During the presentation phase, when a user needs to use an electronic certificate, they send a presentation request through the system front-end to the back-end. Upon receiving the request, the back-end performs user identity verification. Once verified, it retrieves the corresponding electronic certificate from the user's electronic certificate card holder and performs cryptographic signature verification to ensure the authenticity and integrity of the certificate. Once verified, the system sends the electronic certificate to the user's designated presentation entity or platform, such as a government agency or financial institution. The system generates a presentation log, recording information such as the time and subject of the presentation, and stores it in a security log repository for subsequent auditing and querying.

[0024] During the update phase, when an electronic certificate requires an update (e.g., due to expiration of validity or changes to certificate information), the user submits an update request through the system front-end. Upon receiving the request, the system back-end verifies the user's identity and the certificate information to ensure the authenticity and legitimacy of the request. Upon successful verification, the system generates an update request number and cryptographically signs this number along with the user's identity information and the updated certificate information to form an update log. This update log is stored in a secure log repository. The system then sends the update request to the certificate issuing authority for approval in real time. Upon approval, the issuing authority updates the electronic certificate and generates a cryptographically signed update log along with the approval result. The system then provides real-time feedback to the user regarding the update result and updates the certificate information in the user's electronic certificate card holder.

[0025] During the deregistration process, when an electronic certificate needs to be deregistered (e.g., due to expiration or user-initiated deregistration), the user submits a deregistration request through the system front-end. Upon receiving the request, the system back-end verifies the user's identity and the certificate information to ensure the authenticity and legitimacy of the request. Upon successful verification, the system generates a deregistration request number and cryptographically signs this number along with the user's identity information and the deregistered certificate information, creating a deregistration request log. This log is stored in a secure log repository. The system sends the deregistration request to the certificate issuing authority for approval in real time. Upon approval, the issuing authority deregisters the electronic certificate and generates a deregistration result, along with the approval result, which is cryptographically signed to form a post-deregistration issuance log. The system provides real-time feedback to the user regarding the deregistration result and removes the corresponding certificate information from the user's electronic certificate card wallet, ensuring the accuracy and security of user information.

[0026] This application combines encrypted, signed log storage, real-time monitoring, and dynamic inspections throughout the entire process, enabling comprehensive oversight of every aspect of electronic certificates, from application, issuance, presentation, renewal, to cancellation. This approach effectively prevents data tampering and leakage, ensuring the authenticity and security of certificate data and providing users with more reliable and secure certificate services.

[0027] The Monitoring Center mainly provides service registration and service management functions for the Supervision SDK and Supervision Log Processing Service, monitors the operation status of the Supervision Log Processing Service, and provides an interface for obtaining the list of Supervision Log Processing Services. Specifically, the services provided by the Monitoring Center are as follows: Service Registration and Management: The Monitoring Center provides a service registration interface, allowing the Supervision SDK and Supervision Log Processing Service to register with the Monitoring Center upon startup. Registration information includes, but is not limited to, the service name, address, and port. The Monitoring Center also provides service management capabilities for status monitoring and configuration updates of registered services.

[0028] Status Monitoring: The Monitoring Center continuously monitors the operational status of registered services, particularly monitoring the online and offline status of log processing services. Through heartbeat monitoring and log analysis, the system ensures real-time response to changes in service status.

[0029] Service List API: The Monitoring Center provides an API for obtaining a list of regulatory log processing services. This API returns information about currently available regulatory log processing services, including service name, address, and status. The Regulatory SDK and other related services can use this API to query and select the appropriate service for processing.

[0030] After the supervision log processing service is started, it first registers with the monitoring center and uploads the service IP address and service port. The supervision log processing service sends a heartbeat every T1 second. The monitoring center continuously monitors the heartbeat information of the registered service. If no heartbeat information is received within T2 cycles, the supervision log processing service is considered abnormal and removed from the service list. In this embodiment, T1 is 5 and T2 is 3.

[0031] The supervision SDK provides log collection, log compression, and log reporting functions. After startup, the supervision SDK connects to the monitoring center and calls the supervision log processing service list interface to obtain the currently available supervision log processing services. At the same time, the supervision SDK connects to the supervision log processing service. After the supervision SDK collects the supervision log, it performs log compression operations; for example Figure 5 As shown, log compression operations include: primary compression and secondary compression. The primary compression operation is to compress the log details using a high-ratio compression algorithm to obtain compressed log details. The secondary compression operation is to replace the original log details with the compressed log details and perform secondary compression together with other log information to obtain secondary compressed log information. The supervision SDK reports the secondary compressed log information to the supervision log processing service in real time.

[0032] In practice, the log compression algorithm used is based on existing lossless compression algorithms, such as ZIP and GZIP. The compressed supervision logs are smaller in size and easier to store and transmit.

[0033] like Figure 3 As shown, the supervision log processing service creates a connection manager, which monitors multiple supervision SDKs based on IO multiplexing technology. The supervision log processing service first registers the supervision SDK connection to be monitored with the connection manager and allocates an internal queue buffer in memory for each supervision SDK connection to temporarily store the secondary compressed log information reported by the supervision SDK. If the supervision SDK reports secondary compressed log information first, it will be placed in the corresponding internal queue buffer first. The connection manager will enter a read loop and call the internal queue buffer of all SDK connections every M0 milliseconds to check whether there is data; When the internal queue buffer has data, the connection manager reads N0 pieces of data from the internal queue buffer and sends them to the memory buffer queue inside the supervision log processing service. In this embodiment, M0 is 100 and N0 is 10000.

[0034] A dual memory buffer queue is set up within the supervision log processing service. The memory buffer queue includes a pre-processing queue and a write queue. These two queues are independent of each other but work closely together to form the core part of the log processing process.

[0035] The preprocessing queue is used to receive and preprocess data from different regulatory SDKs in real time. It receives secondary compressed log information reported by the regulatory SDKs. Because regulatory SDKs may be deployed in multiple business systems, the preprocessing queue needs to be able to handle concurrent log data from multiple sources.

[0036] The write queue buffers preprocessed data, awaiting batch storage. It pushes preprocessed and formatted log data to the storage service. As a buffer for log data flowing to the storage service, the write queue effectively mitigates any discrepancies between the log generation rate and the storage service's processing capabilities.

[0037] like Figure 3 As shown, to fully leverage the performance advantages of multi-core processors, the supervisory log processing service uses multi-threaded processing technology. Each queue corresponds to one or more processing threads, which work in parallel to process the log data in the queue. These threads include pre-processing threads and writing threads. Figure 3 The leftmost connection in the figure represents the SDK connection; the preprocessing queue and write queue in the figure are both concurrent queues.

[0038] Preprocessing thread: Responsible for reading raw log data from the preprocessing queue and performing decompression and formatting operations. Decompression ensures that subsequent processing steps can directly operate on uncompressed log data, while formatting includes parsing log fields, converting log formats, and verifying the integrity and accuracy of log data.

[0039] Write thread: Responsible for reading formatted log data from the write queue and writing it in batches to the storage service. Batch writing can significantly improve system throughput and stability, reducing performance losses caused by frequent write operations.

[0040] The supervisory log processing service first initializes a thread pool manager and queue dispatcher, denoted as the first thread pool manager and the first queue dispatcher. The thread pool manager sets the core thread count of the thread pool to M1 and the maximum thread count to M2. The first queue dispatcher periodically pulls N2 secondary compressed log messages from the preprocessing queue every N1 milliseconds and submits the pulled data to the first thread pool manager. The dispatcher then pulls data from the preprocessing queue according to a preset number. In this embodiment, M1 is 6, M2 is 12, and N1 is 1000.

[0041] The first thread pool manager randomly selects an idle thread as a preprocessing thread to preprocess the original log data, and converts the preprocessing thread into a non-idle thread; Preprocessing includes: the preprocessing thread first decompresses the double-compressed log information to obtain the primary compressed log data; after the first decompression is completed, the preprocessing thread formats the primary compressed log data; the formatting operation includes parsing log fields, converting log formats, and verifying the integrity and accuracy of log data to ensure that subsequent analysis and storage operations can be performed based on a unified and standardized data format; After the preprocessing operation is completed, the compressed log data is pushed to the write queue; The supervisory log processing service initializes another thread pool manager and queue dispatcher, designated as the second thread pool manager and second queue dispatcher. The thread pool manager sets the core thread count to M3 and the maximum thread count to M4. The second queue dispatcher periodically pulls N4 compressed log data from the write queue every N3 milliseconds and submits the data to the second thread pool manager. In this embodiment, M3 is 6, M4 is 12, N3 is 1000, and N4 is 200.

[0042] The second thread pool manager randomly selects an idle thread as the write thread to store logs to the database, and converts the write thread to a non-idle thread; The write thread calls the regulatory log storage service to write log data in batches to the regulatory log storage service, which then stores the data in the log storage module. The log storage module is based on a distributed database or file system.

[0043] Specifically, when a thread calls the supervisory log storage service, the log processing process includes the following steps: Receiving logs: The supervision SDK pushes the collected compressed supervision logs to the preprocessing queue. Preprocessing: The preprocessing thread reads the raw log data from the preprocessing queue and performs decompression and formatting operations. Pushing to the write queue: After preprocessing, the formatted log data is pushed to the write queue for further processing. Writing to storage: The write thread reads log data from the write queue and writes it in batches to the storage service. Storage services are implemented based on databases, file systems, etc., depending on the actual needs and architectural design of the system.

[0044] This application shortens the log processing process, simplifying it into three steps: collection, processing, and storage. It implements the collection of regulatory logs based on the regulatory SDK, completes the preprocessing required before storing regulatory logs through the regulatory log processing service, and completes the storage of regulatory logs through the collaboration of the regulatory log processing service and the regulatory log storage service. In this method, a connection manager, queue distributor, and thread pool are set up within the regulatory log processing service. Regulatory log data reported by the regulatory SDK is first placed in the connection manager's internal queue buffer and then sent to the preprocessing queue through the queue distributor for preprocessing. After the preprocessing operation, the log data is pushed to the write queue, which then pushes it in batches to the regulatory log storage service. The entire processing process is performed in memory, eliminating the need for disk read and write operations, saving a significant amount of disk IO processing time. The regulatory log processing service in the system uses dual memory buffer queues and multi-threaded processing technology, greatly improving the efficiency and response speed of log processing. This design enables the system to process large amounts of log data more quickly, reduces processing delays, and provides strong support for real-time supervision and early warning. This effectively improves log processing efficiency and response speed.

[0045] In specific implementations, the capacity of the memory cache queues also needs to be managed: To avoid queue overflow or excessive waiting, the system needs to dynamically manage the capacity of the pre-processing queue and the write queue. When the queue capacity approaches the upper limit, the system takes appropriate measures, such as suspending the acceptance of new log data or increasing the number of processing threads. In a multi-threaded processing environment, load balancing is a key consideration. The system needs to dynamically adjust the number of pre-processing and write threads based on the current processing capacity and load to ensure efficient and stable log processing. During log processing, various anomalies may be encountered, such as data format errors and storage service failures. To enhance system robustness, the system needs to establish a comprehensive error handling mechanism. When encountering anomalies, the system can promptly capture and handle errors and record the corresponding error information for subsequent analysis and troubleshooting. Through the above implementation methods, this full-process electronic certificate supervision method and system can achieve efficient and stable processing of supervision logs, providing strong support for the secure operation and compliance management of the electronic certificate system.

[0046] Regulatory logs are stored in the log storage module as log chains. Each encrypted and signed regulatory log is linked together in chronological order or by business logic to form a complete log chain. In addition to its own information, each log record also contains a hash value (or pointer) pointing to the previous record, forming a chain structure to ensure log continuity and immutability. Hash value calculations use collision-resistant hash functions, ensuring that even minor data changes will result in significantly different hash values, making them easily detectable.

[0047] When a user submits an application for an electronic certificate, a globally unique certificate number ZZBH is first generated for each user; The certificate number ZZBH is generated using a highly secure random number algorithm, combined with user parameters including a timestamp and user identity information. This ensures the uniqueness of the electronic certificate's log chain across the entire system. Based on the certificate number ZZBH, a new log chain record is created, designated the base log chain record. This base log chain record includes the application time, applicant information, certificate type (e.g., driver's license, ID card), and initial status (e.g., "Applied" or "Awaiting Review"). This base log chain record serves as the starting block (application block) of the log chain.

[0048] When any regulatory operation occurs in the electronic certificate system, a new regulatory log record is generated based on the regulatory SDK and associated with the unique certificate number ZZBH. The newly generated log record is encrypted and signed according to the preset encryption and signature process; The encryption and signing process involves encrypting each record in the log chain (including certificate number, timestamp, operation type, and change details) using a national symmetric encryption algorithm (such as AES-256) to ensure data confidentiality during transmission and storage. The encrypted data is then digitally signed using a private key to generate a signature value, ensuring that the log record was created by an authorized entity and has not been tampered with. The signature value is appended to the encrypted content to form the complete log record data.

[0049] The log chain is stored in a distributed database, and the characteristics of distributed storage are used to improve data security and reliability. When it is necessary to verify the history or current status of an electronic certificate, the log chain is traced back to verify the signature and hash value of each record one by one starting from the application block to ensure the authenticity and integrity of all records.

[0050] In practice, the log chain is regularly audited to check the integrity and accuracy of log records, promptly identifying and addressing any anomalies or potential security risks. Log chain data is regularly backed up to prevent data loss or corruption, ensuring the long-term accessibility and security of log information. Through these steps, every change to the electronic certificate is securely and traceably recorded, forming a tamper-proof, highly reliable log chain that effectively guarantees the security and credibility of the electronic certificate.

[0051] The log storage module provides a RESTful API or other standard interfaces for the warning service to access the data in the supervision log chain; the warning service includes: real-time warning service for supervision logs and dynamic warning service for supervision logs.

[0052] This system provides flexible alert configuration capabilities based on the real-time and dynamic alert services for regulatory logs, allowing users to set and adjust alert rules based on specific business process requirements. Furthermore, these services verify data in real time and generate alert messages, which are then quickly delivered to relevant personnel via various communication methods, such as email, SMS, and instant messaging. This flexible alert configuration and rapid response mechanism facilitates the timely identification and resolution of potential security risks, improving system security and stability.

[0053] The real-time regulatory log alert service monitors a single type of data in real time. For example, you can set the alert type to "Application Frequency Alert," the alert rule to "Usage Exceeds 5 Times in 24 Hours," and the alert description to "XX electronic certificate has been used more than 5 times in 24 hours." Once this alert rule takes effect, logs being processed in real time will be updated based on the number of uses within 24 hours. If the number of uses exceeds 5, a real-time alert will be issued. The alert information will be pushed to the relevant personnel via the pre-set communication method, using the designated alert contact in the alert configuration.

[0054] The regulatory log dynamic alert service performs a comprehensive conditional judgment on compliance based on the combination of multiple data types, or on the combined compliance of multiple pieces of data of a single type. For example, a patrol strategy can be created with a frequency of "midnight daily," a scope of inspection for "certificate validity," and a scope for inspection for the last month's regulatory logs. The dynamic alert type can be set to "overdue cancellation alert," with an alert rule of "activate at midnight daily if cancellation has not occurred within one month," and an alert description of "XX electronic certificate has expired."

[0055] After configuring inspection strategies and alert rules, the dynamic alert service will initiate a scheduled task at midnight each day to scan the supervision logs for the past month. If a log has not been deregistered for more than a month, a dynamic alert will be generated. Upon completion of the inspection, an inspection report will be generated, summarizing inspection findings, anomaly detection, and handling results, along with detailed statistics and charts.

[0056] In this method, by combining the two warning services, the real-time warning service of the supervision log and the dynamic warning service of the supervision log, it is ensured that all business contents that need to be supervised are covered, thereby ensuring more accurate supervision of the entire process of electronic certificates.

[0057] After the real-time regulatory log alert service is activated, it first reads the pre-configured alert configuration information. The alert configuration information includes the alert type, alert rules, and alert description. The real-time regulatory log alert service performs real-time verification of relevant data in the business process based on the read alert rules. For example, for data threshold alert rules, the system will determine whether the current data exceeds the preset threshold; for state change alert rules, the system will determine whether the state of the current data exceeds the preset range or has undergone an abnormal change. During the verification process, the system monitors the relevant data in the business process in real time and determines whether it meets the alert conditions. Once data that meets the alert conditions is detected, the system will immediately trigger the alert mechanism.

[0058] Different alert rules correspond to different verification methods. During the verification process, the system determines whether the current data meets the alert conditions, that is, whether it exceeds the preset threshold or state change range. When the real-time supervision log alert service detects data that meets the alert conditions, it immediately generates the alert message details page. The alert message details page includes key information such as the alert time, alert type, triggering rules, and specific data values, allowing relevant personnel to quickly understand the alert situation and take appropriate measures.

[0059] The real-time supervision log alert service pushes brief alert information to the designated alert contacts via pre-set communication methods. The alert contacts can access the alert message details using the brief information. Communication methods include email, SMS, and instant messaging. The specific choice depends on the system's needs and the preferences of the alert contacts. When pushing alert information, the system ensures accuracy and timeliness. Furthermore, to avoid redundant and disruptive messages, the system controls the frequency and method of push notifications.

[0060] The real-time warning service for regulatory logs also provides warning rule management functions; warning rule management functions include: adding, modifying, and deleting warning rules; the status of warning rules includes: closed and open. When the warning rule is set to closed, it means that the warning rule will no longer perform actual warning verification and push operations; the real-time warning service for regulatory logs monitors and executes warning rules that are in the open status.

[0061] Relevant personnel can add, modify, and delete alert rules based on business needs. If an alert rule is set to Off, it means that the alert rule will no longer be verified and pushed. In this case, the real-time alert service for supervision logs will continue to monitor the execution of other alert rules and generate and push corresponding alert information as needed.

[0062] Monitoring nodes are deployed within the real-time alert service for regulatory logs. In practice, monitoring nodes are connected to the log chain's storage network via a network connection. This ensures that monitoring nodes can capture real-time activity on the log chain and exchange data with other monitoring nodes. Monitoring nodes should be granted appropriate permissions to access data on the log chain. These permissions must undergo rigorous security review to ensure that nodes can only access the data they need and cannot make unauthorized modifications to the log chain.

[0063] The method for the monitoring node to capture new log records on the log chain in real time includes: using the event monitoring mechanism provided by the log chain storage network in the log storage module to capture new log records on the log chain in real time, or calling the API interface to regularly query the new log records on the log chain; correspondingly, the log chain storage network of the log storage module supports event monitoring function and can send real-time event notifications to the monitoring node, or provide an API interface for external access to log chain data.

[0064] When the monitoring node captures log records, it ensures that the captured data includes the completeness of the key information of the log records, including: full content, signature, hash value and timestamp; The monitoring node uses the public key to verify the signature of the captured log record; the verification content includes: hash value verification and link relationship verification; when anomalies or potential risks are detected, the alarm mechanism is immediately triggered; Hash value verification is as follows: the monitoring node calculates the hash value of the captured log record and compares it with the hash value stored in the log record; if the two do not match, it indicates that the log record has been tampered with and is marked as an anomaly; Link relationship verification is as follows: the monitoring node checks whether the captured log record is correctly linked to the previous log record; if the link relationship is incorrect, it indicates that the log chain has been broken and it is marked as an anomaly.

[0065] The real-time monitoring log alert service analyzes log data for anomalies. For verified log records, monitoring nodes conduct further analysis to identify any anomalies or potential security risks. This is achieved by analyzing log content, timestamps, and source information. When a monitoring node detects an anomaly or potential risk, it automatically generates an alert.

[0066] The supervision log dynamic warning service performs dynamic inspections according to pre-defined inspection strategies.

[0067] Inspection strategies include inspection frequency, inspection content, and inspection scope. Inspection content includes: log record integrity check, signature validity verification, signature value correctness verification, and certificate application assessment. Inspection scope includes: comprehensive inspection of the entire log or partial inspection of logs within a specific time period. When the Supervision Log Dynamic Alert Service is activated, it first reads the pre-configured alert configuration information. This information includes key parameters such as alert type (e.g., data anomaly alert, status change alert), alert rules (specific data thresholds, status ranges, and other criteria), and alert descriptions (detailed explanations of the alert and recommended actions). This configuration information can be flexibly configured and adjusted based on the needs of different business processes.

[0068] The dynamic early warning service for regulatory logs performs real-time verification of relevant data in business processes based on the warning rules in the early warning configuration information. Different early warning rules correspond to different verification methods. The system compares the current data status with the preset threshold or status change range to determine whether the data meets the early warning conditions. Once data that meets the early warning conditions is detected, the dynamic early warning service for regulatory logs will immediately trigger the early warning mechanism and generate the content of the early warning message details page. This details page will include key information such as the warning time, warning type, triggering rules, and specific data values, so that relevant personnel can quickly understand the warning situation and take appropriate measures. To improve the access speed of early warning information, this information is cached in memory to quickly respond to subsequent access requests.

[0069] After each round of inspections, the Supervision Log Dynamic Alert Service generates an inspection report. This report summarizes all findings from the inspection process, including anomaly detection results and corresponding treatment measures. The report includes detailed statistics and charts, allowing relevant personnel to conduct in-depth analysis and summary of the inspection results, providing a reference for subsequent improvements and optimizations.

[0070] When developing an inspection strategy, you must first conduct a comprehensive risk assessment of the log chain. This includes analyzing the type of data stored in the log chain, data sensitivity, potential threats, and historical security incidents. Based on the risk assessment results, you can determine the importance and security requirements of the log chain, thereby developing a more precise inspection strategy.

[0071] When the supervisory log dynamic alert service performs dynamic inspections, it traverses each log record in the log chain and performs verification tasks, including integrity verification, signature verification, and hash value verification. During the verification process, the verification results of each log record are recorded, including the number of successfully verified log records, the number of anomalies found, and the anomaly type. Inspection results should be recorded in real time and stored in a dedicated database. The database should have a well-structured data structure and indexing mechanism to facilitate rapid query and analysis of inspection results.

[0072] In specific implementations, the inspection nodes of the dynamic log warning service should be equipped with anomaly recognition algorithms capable of identifying anomalies or potential risks in the log chain. These algorithms can be built and optimized based on machine learning, data mining, and other technologies to improve the accuracy and efficiency of anomaly recognition. For detected anomalies, the inspection nodes should trigger an exception handling process. This includes generating an anomaly report, sending an alert to the system administrator or security team, and documenting the exception handling process. Furthermore, appropriate handling measures and recommendations should be developed based on the type and severity of the anomaly.

[0073] The execution process of the supervision log real-time warning service and the supervision log dynamic warning service, such as Figure 4 shown.

[0074] To speed up access to warning information, both the real-time and dynamic supervision log warning services cache the details of generated warning messages in memory for subsequent access. This allows the system to directly retrieve warning information from memory on subsequent access requests, eliminating the need for complex calculations and queries.

[0075] This application collects and stores logs of the entire process of electronic certificate system application, and adopts a combination of real-time warning and dynamic warning to conduct multiple rounds of inspections on the collected log data, which not only meets the needs of real-time application, but also meets the needs of delayed business.

[0076] After using the technical solution of the present invention, through the comprehensive collection and processing of regulatory logs in various links such as application, issuance, presentation, update and cancellation, the authenticity and security of license data can be fully guaranteed, the log processing efficiency and response speed can be improved, and at the same time, the advantages of flexible early warning configuration and rapid early warning response can provide users with more reliable, safe and efficient license services.

Claims

1. A full-process supervision system for electronic certificates, characterized in that: It includes: monitoring Center, supervision SDK, supervision log processing service and supervision log storage service; The supervision SDK is embedded in the electronic certificate system, and pre-sets the operation type that needs to be supervised, which is recorded as: supervision operation; when any of the supervision operations occurs in the electronic certificate system, the supervision SDK will capture the detailed information of these supervision operations and generate a supervision log according to a preset log format; The log information of the supervision log includes: log number, log-related business number, log collection time, log index information and log details; the log index information includes: log retrieval and query information extracted from the log details; The monitoring center mainly provides service registration and service management functions for the supervision SDK and the supervision log processing service, monitors the operation status of the supervision log processing service, and provides an interface for obtaining a list of supervision log processing services; After the supervision log processing service is started, it first registers with the monitoring center and uploads the IP address and service port of the service; the supervision log processing service sends a heartbeat every T1 second; the monitoring center continuously monitors the heartbeat information of the registered service. If no heartbeat information is received within T2 cycles, the supervision log processing service is considered abnormal and removed from the serviceable list; The supervision SDK provides log collection, log compression and log reporting functions; after startup, the supervision SDK connects to the monitoring center and calls the supervision log processing service list interface to obtain the currently available supervision log processing service; at the same time, the supervision SDK connects to the supervision log processing service; After the supervision SDK collects the supervision log, it performs a log compression operation; the log compression operation includes: a primary compression operation and a secondary compression operation; the primary compression operation is: using a high-ratio compression algorithm to compress the log details to obtain compressed log details; the secondary compression operation is: replacing the compressed log details with the original log details and performing secondary compression together with other log information to obtain secondary compressed log information; The supervision SDK reports the secondary compressed log information to the supervision log processing service in real time; A dual memory buffer queue is set inside the supervision log processing service, and the memory buffer queue includes: a pre-processing queue and a writing queue; The pre-processing queue is used to receive the secondary compressed log information data reported by the supervision SDK in real time and pre-process the data, and the write queue is used to buffer the pre-processed data and wait for batch storage; The supervision log processing service first initializes a thread pool manager and a queue distributor, which are denoted as: a first thread pool manager and a first queue distributor; The first queue distributor periodically pulls N2 pieces of the secondary compressed log information from the preprocessing queue at a time of N1 milliseconds, and submits the pulled data to the first thread pool manager; The first thread pool manager randomly selects an idle thread as a preprocessing thread to preprocess the original log data, and converts the preprocessing thread into a non-idle thread; The preprocessing includes: the preprocessing thread first performs a first decompression process on the secondary compressed log information to obtain the first compressed log data; after the first decompression is completed, the preprocessing thread performs a formatting operation on the first compressed log data; the formatting operation includes: parsing log fields, converting log formats, and verifying the integrity and accuracy of log data to ensure that subsequent analysis and storage operations can be performed based on a unified and standardized data format; After the preprocessing operation is completed, the once compressed log data is pushed to the write queue; The supervision log processing service initializes a thread pool manager and a queue distributor again, which are recorded as: a second thread pool manager and a second queue distributor; The second queue distributor periodically pulls N4 pieces of the once compressed log data from the write queue at N3 milliseconds, and submits the pulled data to the second thread pool manager; The second thread pool manager randomly selects an idle thread as a writing thread for storing logs in a database, and converts the writing thread into a non-idle thread; The writing thread calls the supervision log storage service to write the log data in batches into the supervision log storage service, and the supervision log storage service stores the data into the log storage module.

2. According to claim 1, a full-process supervision system for electronic certificates is characterized by: The supervision log processing service also includes the following operations: The supervision log processing service creates a connection manager, and the connection manager monitors multiple supervision SDKs based on IO multiplexing technology; The supervision log processing service first registers the supervision SDK connection that needs to be monitored to the connection manager, and sets up an internal queue buffer for each supervision SDK connection to temporarily store the secondary compressed log information reported by the supervision SDK; The connection manager will enter a read loop, calling the internal queue buffer of the connection every M0 milliseconds to check whether there is data; When there is data in the internal queue buffer, the connection manager reads N0 pieces of data from the internal queue buffer of the connection and sends them to the memory buffer queue inside the supervision log processing service.

3. According to claim 1, the electronic certificate full-process supervision system is characterized by: The regulatory operations include: application, issuance, presentation, renewal and cancellation of electronic certificates; The types of regulatory logs include: application log, issuance log, presentation log, update log, cancellation request log and cancellation log; The application log includes: the application request number generated by the electronic certificate system when the user applies for an electronic certificate, the user's identity information and the type of certificate applied for; The issuance log includes: the certificate information and approval results generated by the certificate issuing agency; The presentation log includes: the time and object of presentation of the electronic certificate generated by the electronic certificate system when the electronic certificate user uses the electronic certificate; The update log includes: when the electronic certificate is updated, the update request number generated by the electronic certificate system, the user's identity information and the updated certificate information; The cancellation request log includes: the cancellation request number generated by the electronic certificate system when the electronic certificate is cancelled, the user's identity information and the cancelled certificate information; The cancellation log includes: the cancellation result and approval result generated by the issuing agency after the electronic certificate is cancelled.

4. According to claim 1, the electronic certificate full-process supervision system is characterized by: The supervision log is stored in the log storage module in the form of a log chain, and each encrypted and signed supervision log is linked in the form of a log record in chronological order or business logic to form a complete log chain; each log record contains not only its own information, but also a hash value pointing to the previous record, forming a chain structure; When a user submits an application for an electronic certificate, a globally unique certificate number ZZBH is first generated for each user; The certificate number ZZBH is generated by a highly secure random number algorithm in combination with user parameters, wherein the user parameters include: timestamp and user identity information; based on the certificate number ZZBH, a new log chain record is created, recorded as a basic log chain record, wherein the basic log chain record includes: application time, applicant information, certificate type and initial status; the basic log chain record is used as the starting block of the log chain; When any of the above-mentioned supervision operations occur in the electronic certificate system, a new supervision log record is generated based on the supervision SDK and associated with the unique certificate number ZZBH. The newly generated log record is encrypted and signed according to the preset encryption and signature process; The encryption and signature process includes: encrypting each record content in the log chain, using the national secret symmetric encryption algorithm, and signing the encrypted data with a national secret digital signature, using a private key to generate a signature; The log chain is stored in a distributed database. When the history record or current status of an electronic certificate needs to be verified, the signature and hash value of each record can be verified one by one starting from the application block by tracing the log chain.

5. According to claim 1, the electronic certificate full-process supervision system is characterized by: The log storage module provides a RESTful API or other standard interface for the early warning service to access the data in the supervision log chain; The warning service includes: real-time warning service of supervision log and dynamic warning service of supervision log.

6. According to claim 5, a full-process supervision system for electronic certificates is characterized by: The real-time warning service for supervision logs performs real-time monitoring on a single type of data; After the real-time warning service of the supervision log is started, the preset warning configuration information is read first; The warning configuration letter includes: warning type, warning rules and warning description; The real-time warning service of the supervision log performs real-time verification of relevant data in the business process according to the read warning rules; different warning rules correspond to different verification methods. During the verification process, the system will determine whether the current data meets the warning conditions; When the real-time warning service of the supervision log detects data that meets the warning conditions, it will immediately generate a warning message, which includes: warning time, warning type, triggering rules, and specific data values; The real-time warning service of the supervision log will push brief information of the warning information to relevant personnel through a preset communication method according to the warning contact person specified in the warning configuration; the warning contact person accesses the detailed content of the warning message according to the brief information of the warning information.

7. According to claim 5, a full-process supervision system for electronic certificates is characterized by: A monitoring node is set in the real-time early warning service of the supervision log, and a method for the monitoring node to capture the newly added log records on the log chain in real time includes: using the event monitoring mechanism provided by the log chain storage network in the log storage module to capture the newly added log records on the log chain in real time, or calling the API interface to regularly query the newly added log records on the log chain; When capturing log records, the monitoring node ensures that the captured data includes the completeness of the key information of the log records, including: complete content, signature, hash value and timestamp; The monitoring node uses the public key to verify the signature of the captured log record; the verification content includes: hash value verification and link relationship verification; when anomalies or potential risks are detected, the alarm mechanism is immediately triggered; The hash value verification is as follows: the monitoring node calculates the hash value of the captured log record and compares it with the hash value stored in the log record; if the two do not match, it indicates that the log record has been tampered with and is marked as abnormal; The link relationship verification is as follows: the monitoring node checks whether the captured log record is correctly linked to the previous log record; if the link relationship is incorrect, it indicates that the log chain has been broken and it is marked as abnormal.

8. According to claim 5, a full-process supervision system for electronic certificates is characterized by: The regulatory log dynamic warning service makes a comprehensive judgment on whether the combined data of multiple types are compliant, or makes a comprehensive judgment on whether the superposition of multiple pieces of data of a single type is compliant; The supervision log dynamic warning service performs dynamic inspections according to pre-established inspection strategies; The inspection strategy includes: inspection frequency, inspection content and inspection scope; the inspection content includes: integrity check of log records, validity verification of signatures, correctness check of signature values ​​and evaluation of license application; the inspection scope includes: comprehensive inspection of the entire log, or partial inspection of logs within a specific time period; After the dynamic warning service of the supervision log is started, the preset warning configuration information is first read, and the relevant data in the business process is verified in real time according to the warning rules in the warning configuration information; when data that meets the warning conditions is detected, the detailed content of the warning message is immediately generated; After each round of inspection, the supervision log dynamic warning service generates an inspection result report; the content of the inspection result report includes: findings during the inspection process, abnormal detection and processing results.

9. According to claim 5, a full-process supervision system for electronic certificates is characterized by: When the dynamic early warning service of the supervision log performs dynamic inspection, it traverses each log record in the log chain and performs verification tasks, which include: integrity verification, signature verification and hash value verification; during the verification process, the verification result of each log record is recorded, and the verification result includes: the number of successfully verified log records, the number of anomalies found, and the type of anomalies.

10. According to claim 5, a full-process supervision system for electronic certificates is characterized by: The supervision log real-time warning service and the supervision log dynamic warning service both cache the detailed content of the generated warning message into the memory for subsequent access.

Images