An electronic license whole-process supervision system

Abstract

The electronic certificate whole-process supervision system provided by the application shortens the processing procedure of log data, simplifies the processing procedure of log data into three steps of collection, processing and storage, and improves the processing efficiency of log data; the supervision SDK realizes the collection step, collects log data, and reports the log data to the supervision log processing service after compression operation; the supervision log processing service completes the processing steps of preprocessing and storage buffering, and realizes the storage step through the supervision log storage service; the application sets double memory buffer queues in the supervision log processing service, manages the memory application thread pool manager and the queue distributor based on the memory application thread pool manager and the queue distributor, and completes the two processing procedures of preprocessing and storage of log data through data transmission between the double memory buffer queues set in the supervision log processing service.

Description

Technical Field

[0001] This invention relates to the field of electronic certificate management technology, specifically to an electronic certificate full-process supervision system. Background Technology

[0002] Electronic certificates refer to various legally valid electronic documents such as licenses, certificates, approvals, appraisal reports, and service results issued by various entities in accordance with the law. Examples include electronic versions of ID cards, marriage certificates, bank statements, and business licenses. With the advancement of information technology, the collaborative application of electronic and physical certificates has become the mainstream method of certificate application. However, the supervision of electronic certificate application faces many challenges, such as recording and monitoring the application process, and promptly detecting and issuing warnings about issues such as certificate tampering and forgery.

[0003] In existing technologies, the use of electronic certificates is typically recorded and monitored based on logs. For example, the ELK log analysis system integrates three open-source tools: Elasticsearch, Logstash, and Kibana, providing users with log query, sorting, and statistical services. However, the ELK system requires a separate log system deployment, involving processes such as log collection, local storage, log upload, log formatting, writing to a message queue, reading from the message queue for consumption, and writing to a database. This process involves multiple disk reads and writes, numerous dependent components, high system performance consumption, and high server resource requirements. The log data process involves: each user request processed generates a log data entry, which is then sent to a message queue (MQ) cluster for caching and access by log analysis tools. Within the MQ, the data also needs to be written to disk to prevent data loss. Simultaneously, the original log data requires distributed storage and backup; backup and distributed storage also need to be implemented based on the MQ. For example, during backup, assuming a single backup strategy, the MQ needs to read the locally cached log data and write a single copy to the backup disk. The log data also involves a consumer 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] Hypothetically, in a regional system dedicated to handling electronic certificate transactions, a certain type of electronic certificate application prints an average of approximately 50KB of raw logs when processing a single user request. Under normal circumstances, this application processes about 10,000 to 20,000 requests per second, while during peak periods, this number can increase to 3-5 times, creating enormous read and write demands. Furthermore, if a system simultaneously hosts multiple types of electronic certificates, and considering the message queue cluster required for log transmission and data backup needs, the log system will need to process massive amounts of data during peak periods, placing extremely high demands on the system's server resources. Given the large volume and frequent updates of electronic certificate data, 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] To address the issue that existing electronic certificate supervision systems cannot meet the demands of high concurrency and high traffic applications, this invention provides an electronic certificate full-process supervision system. This system can record logs in real time during the application process of electronic certificates, meet the demands of high concurrency and high traffic applications, and achieve real-time supervision and full lifecycle management of electronic certificates.

[0006] The technical solution of the present invention is as follows: an electronic certificate full-process supervision system, characterized in that it includes: a monitoring center, a supervision SDK, a supervision log processing service, and a supervision log storage service;

[0007] The regulatory SDK is embedded in the electronic certificate system. It pre-defines the types of operations that need to be regulated, denoted as "regulatory operations." When any of these regulatory operations occur in the electronic certificate system, the regulatory SDK captures detailed information about these operations and generates regulatory logs according to a preset log format. The log information in the regulatory logs includes: log number, log-associated business number, log collection time, log index information, and log details. The log index information includes information extracted from the log details for log retrieval and query purposes.

[0008] The monitoring center mainly provides the functions of service registration and service management for the regulatory SDK and the regulatory log processing service, monitors the running status of the regulatory log processing service, and provides an interface for obtaining a list of regulatory log processing services.

[0009] After startup, the regulatory log processing service first registers with the monitoring center, uploading its IP address and service port. The regulatory log processing service sends a heartbeat every T1 seconds. The monitoring center continuously monitors the heartbeat information of the registered services. If no heartbeat information is received within T2 consecutive periods, the monitoring center considers the regulatory log processing service to be abnormal and removes it from the list of available services.

[0010] The monitoring SDK provides log collection, log compression, and log reporting functions. After startup, the monitoring SDK connects to the monitoring center and calls the monitoring log processing service list interface to obtain the currently available monitoring log processing services. At the same time, the monitoring SDK connects to the monitoring log processing services.

[0011] After the monitoring SDK collects the monitoring logs, 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-rate 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.

[0012] The monitoring SDK reports the secondary compressed log information to the monitoring log processing service in real time.

[0013] The regulatory log processing service is configured with dual memory buffer queues, which include a preprocessing queue and a write queue.

[0014] The preprocessing queue is used to receive secondary compressed log information data reported from the monitoring SDK in real time and preprocess the data. The writing queue is used to buffer the preprocessed data and wait for batch storage.

[0015] The regulatory log processing service first initializes a thread pool manager and a queue dispatcher, denoted as: the first thread pool manager and the first queue dispatcher;

[0016] The first queue distributor periodically (N1 milliseconds) pulls N2 pieces of the secondary compressed log information from the preprocessing queue and submits the data to the first thread pool manager.

[0017] The first thread pool manager randomly selects an idle thread as a preprocessing thread to preprocess the raw log data, and then converts the preprocessing thread into a non-idle thread.

[0018] The preprocessing includes: the preprocessing thread first performs a first decompression process on the secondary compressed log information to obtain a 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;

[0019] After the preprocessing operation is completed, the compressed log data is pushed to the write queue.

[0020] The regulatory log processing service re-initializes a thread pool manager and a queue dispatcher, denoted as: the second thread pool manager and the second queue dispatcher;

[0021] The second queue distributor periodically (N3 milliseconds) pulls N4 compressed log data entries from the write queue and submits the data to the second thread pool manager.

[0022] The second thread pool manager randomly selects an idle thread as a writing thread to store logs in the database, and then converts the writing thread into a non-idle thread.

[0023] The writing thread calls the supervisory log storage service to write log data in batches to the supervisory log storage service, which then stores the data in the log storage module.

[0024] Its further features are:

[0025] The regulatory log processing service also includes the following operations:

[0026] The monitoring log processing service creates a connection manager, which monitors multiple monitoring SDKs based on I / O multiplexing technology.

[0027] The monitoring log processing service first registers the monitoring SDK connections that need to be monitored to the connection manager, and sets up an internal queue buffer for each monitoring SDK connection to temporarily store the secondary compressed log information reported by the monitoring SDK.

[0028] The connection manager will enter a read loop, calling the internal queue buffer of the connection every M0 milliseconds to check if there is data;

[0029] When there is data in the internal queue buffer, the connection manager reads N0 data entries from the internal queue buffer of the connection and sends them to the memory buffer queue inside the supervisory log processing service.

[0030] The regulatory operations include: application, issuance, presentation, renewal, and cancellation of electronic certificates;

[0031] The types of regulatory logs include: application logs, issuance logs, presentation logs, update logs, cancellation request logs, and cancellation logs;

[0032] 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;

[0033] The issuance log includes: certificate information and approval results generated by the certificate issuing authority;

[0034] The presentation log includes: the time and recipient of the electronic certificate presentation generated by the electronic certificate system when the electronic certificate user uses the electronic certificate;

[0035] The update log includes: when an electronic certificate is updated, the update request number generated by the electronic certificate system, the user's identity information, and the updated certificate information;

[0036] The cancellation request log includes: when an electronic certificate is cancelled, the cancellation request number generated by the electronic certificate system, the user's identity information, and the certificate information to be cancelled;

[0037] The cancellation log includes: cancellation results and approval results generated by the issuing authority after the electronic certificate is cancelled;

[0038] The regulatory logs are stored in the log storage module in the form of a log chain. Each encrypted and signed regulatory log is linked together in the form of log records according to time sequence or business logic to form a complete log chain. In addition to its own information, each log record also contains a hash value pointing to the previous record, forming a chain structure.

[0039] When a user submits an application for an electronic certificate, a globally unique certificate number ZZBH is first generated for each user.

[0040] The certificate number ZZBH is generated using a highly secure random number algorithm in combination with user parameters, including timestamps and user identity information. Based on the certificate number ZZBH, a new log chain record is created, denoted as the basic log chain record. 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.

[0041] 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 signing process.

[0042] The encryption and signing process includes: encrypting the content of each record in the log chain using the national standard symmetric encryption algorithm, and simultaneously performing a national standard digital signature on the encrypted data and generating a signature using a private key;

[0043] The log chain is stored in a distributed database. When it is necessary to verify the historical record or current status of an electronic certificate, the signature and hash value of each record are verified one by one by tracing the log chain, starting from the application block.

[0044] The log storage module provides a RESTful API or other standard interfaces for the early warning service to access data in the regulatory log chain;

[0045] The early warning service includes: real-time early warning service for regulatory logs and dynamic early warning service for regulatory logs;

[0046] The real-time alert service for regulatory logs is designed for real-time monitoring of a single type of data.

[0047] After the real-time alert service for regulatory logs is started, it first reads the preset alert configuration information; the alert configuration information includes: alert type, alert rules, and alert description;

[0048] The real-time alert service for regulatory logs performs real-time verification of relevant data in the business process based on the read alert rules. Different alert rules correspond to different verification methods. During the verification process, the system will determine whether the current data meets the alert conditions. When the real-time alert service for regulatory logs detects data that meets the alert conditions, it will immediately generate an alert message, which includes: alert time, alert type, triggering rule, and specific data value.

[0049] The real-time alert service for monitoring logs will push a brief overview of the alert information to relevant personnel via a preset communication method, based on the alert contact person specified in the alert configuration; the alert contact person can then access the detailed content of the alert message based on the brief overview of the alert information.

[0050] The monitoring node is set up in the real-time early warning service of the monitoring log. The method for the monitoring node to capture newly added log records on the log chain in real time includes: using the event listening mechanism provided by the log chain storage network in the log storage module to capture newly added log records on the log chain in real time, or calling the API interface to periodically query newly added log records on the log chain.

[0051] When capturing log records, the monitoring node ensures that the captured data includes the integrity of the key information of the log records, including: complete content, signature, hash value, and timestamp;

[0052] The monitoring node uses a public key to verify the signature of the captured log records; the verification includes: hash value verification and link relationship verification; when an anomaly or potential risk is detected, an alarm mechanism is immediately triggered;

[0053] 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.

[0054] 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.

[0055] The regulatory log dynamic early warning service makes a comprehensive judgment on whether the combination of multiple types of data is compliant, or makes a comprehensive judgment on whether the superposition of multiple data of a single type is compliant.

[0056] The regulatory log dynamic early warning service performs dynamic inspections according to a pre-defined inspection strategy.

[0057] The inspection strategy includes: inspection frequency, inspection content, and inspection scope; the inspection content includes: checking the integrity of log records, verifying the validity of signatures, checking the correctness of signature values, and evaluating the application of certificates and licenses; the inspection scope includes: conducting a comprehensive inspection of the entire log, or conducting a partial inspection of the log within a specific time period.

[0058] After the dynamic early warning service for the monitoring log is started, it first reads the preset early warning configuration information and performs real-time verification on the relevant data in the business process according to the early warning rules in the early warning configuration information; when data that meets the early warning conditions is detected, the detailed content of the early warning message will be generated immediately.

[0059] After each round of inspections, the regulatory log dynamic early warning service generates an inspection result report; the inspection result report includes: findings, anomaly detection and handling results during the inspection process;

[0060] When the monitoring log dynamic early warning service performs dynamic inspection, it traverses each log record in the log chain and performs verification tasks. The verification tasks include: integrity verification, signature verification, and hash value verification. During the verification process, the verification result of each log record is recorded. The verification result includes: the number of successfully verified log records, the number of anomalies found, and the anomaly type.

[0061] Both the real-time early warning service and the dynamic early warning service for regulatory logs cache the detailed content of the generated early warning messages in memory for subsequent access.

[0062] This application provides an electronic certificate end-to-end supervision system that shortens the log data processing flow by simplifying it into three steps: collection, processing, and storage, thereby improving processing efficiency. The supervision SDK implements the collection step, collecting log data, compressing it, and then reporting it to the supervision log processing service. The supervision log processing service performs preprocessing and storage buffering, and the supervision log storage service handles the storage step. This application uses a dual-memory buffer queue within the supervision log processing service, employing a memory-allocated thread pool manager and queue dispatcher. Data transfer between the dual-memory buffer queues within the supervision log processing service completes both the preprocessing and storage of log data. Compared to existing technologies that rely on distributed systems, this system completes both the processing and storage of reported log data in memory, eliminating the need for data transfer and synchronization between distributed systems. This significantly simplifies the log processing flow, saves data transfer time, and effectively improves data processing efficiency, making it particularly suitable for applications requiring high concurrency and high traffic. Meanwhile, in this application, the log index information is extracted from the log details and stored separately for retrieval and querying. The log details, which have a large data size, are subsequently transmitted and stored in the form of compressed data after being compressed using a high-ratio compression algorithm, which effectively reduces the memory requirements during log data processing. Attached Figure Description

[0063] Figure 1 This is a flowchart of the electronic certificate supervision log processing in this application;

[0064] Figure 2 Architecture diagram for electronic certificate supervision services;

[0065] Figure 3 Diagram of the concurrent queue consumption model;

[0066] Figure 4 A flowchart for proactive supervision of electronic certificates;

[0067] Figure 5 This is a diagram illustrating the compression process of regulatory logs. Detailed Implementation

[0068] like Figure 1 and Figure 2 As shown, this application includes an electronic certificate end-to-end monitoring system, comprising: a monitoring center, a monitoring SDK, a monitoring log processing service, a monitoring log storage service, a monitoring log real-time early warning service, and a monitoring log dynamic early warning service. Based on the collaborative work of these components, effective monitoring of the entire electronic certificate process is achieved.

[0069] The regulatory SDK is embedded in the electronic certificate system. It pre-defines the types of operations to be regulated, denoted as "regulatory operations." When any regulatory operation occurs in the electronic certificate system, the regulatory SDK captures the detailed information of these operations and generates regulatory logs according to a preset log format. In practice, the regulatory SDK is built as an independent software module, tightly integrated with other parts of the electronic certificate system, but maintaining relative independence. The regulatory SDK obtains a list of regulatory log processing services by calling the interfaces provided by the regulatory center, connects to these services, and completes log reporting.

[0070] Connecting to the regulatory log processing service: The regulatory SDK selects a suitable service to connect to from the list of regulatory log processing services obtained. The connection process may involve steps such as authentication and permission checks.

[0071] Log Reporting: The regulatory SDK reports the compressed regulatory logs to the connected regulatory log processing service. The reporting process can be synchronous or asynchronous. Asynchronous reporting ensures that the normal operation of the electronic certificate system will not be affected even if the network is unstable or the regulatory log processing service is busy.

[0072] The log information in the regulatory log includes: log number, log associated business number, log collection time, log index information, and log details;

[0073] The regulatory SDK specifies the log format to ensure consistency and readability. The log format includes:

[0074] Log number: A unique identifier for each log.

[0075] Log-related business number: A unique identifier for business operations associated with logs.

[0076] Log collection time: The timestamp when the log was collected.

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

[0078] Log details: Describes specific information about the business operation, such as the operation type and the operation result.

[0079] The regulatory operations cover the entire lifecycle of electronic certificates, specifically including: application, issuance, presentation, renewal, and cancellation of electronic certificates.

[0080] Corresponding to regulatory operations, the types of regulatory logs include: application logs, issuance logs, presentation logs, update logs, cancellation request logs, and cancellation logs;

[0081] 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;

[0082] The issuance log includes: certificate information and approval results generated by the certificate issuing authority;

[0083] The presentation log includes: the time and recipient of the electronic certificate generated by the electronic certificate system when the electronic certificate user uses the electronic certificate;

[0084] The update log includes: the update request number generated by the electronic certificate system, the user's identity information, and the updated certificate information when the electronic certificate is updated;

[0085] 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 certificate information to be cancelled;

[0086] The cancellation log includes the cancellation result and approval result generated by the issuing agency after the electronic certificate is cancelled.

[0087] Specifically, during the application process, users submit application requests through the system front-end. These requests include the user's identity information and the type of certificate or license being applied for. Upon receiving the request, the system back-end first verifies the user's identity using authentication mechanisms (such as username / password verification and biometric identification) to ensure the authenticity and legitimacy of the user's identity. After successful verification, the system generates a unique application request number and encrypts and signs this number along with the user's identity information and the type of certificate or license applied for, creating an application log. The encryption and signing employs advanced encryption algorithms 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 sends application requests to the certificate-issuing authority for approval in real time, ensuring the timeliness and accuracy of the approval process.

[0088] During the issuance process, upon receiving an application request, the issuing authority reviews it according to pre-defined approval rules. During the review process, the application log is queried to verify the authenticity and legality 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 repository. The system provides real-time feedback on the issuance results to the user and pushes the electronic certificate to the user's electronic certificate wallet for convenient viewing and use at any time.

[0089] During the presentation process, when a user needs to use an electronic certificate, they send a presentation request from the system frontend to the system backend. Upon receiving the request, the system backend verifies the user's identity. If verification is successful, the backend retrieves the corresponding electronic certificate from the user's electronic certificate wallet and performs encrypted signature verification to ensure the certificate's authenticity and integrity. After successful verification, the system sends the electronic certificate to the user-designated presentation recipient or platform, such as a government department or financial institution. The system generates a presentation log, recording the presentation time, recipient, and other information, and stores it in a secure log database for subsequent auditing and retrieval.

[0090] During the update process, when electronic certificates need updating (such as certificate expiration or changes in certificate information), users submit an update request through the system front-end. Upon receiving the request, the system back-end verifies user identity and certificate information to ensure the authenticity and legality of the request. After successful verification, the system generates an update request number and encrypts and signs this number along with the user's identity information and the updated certificate information, creating an update log. The update log is stored in a secure log repository. The system 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 updated certificate information, which, along with the approval result, is encrypted and signed to create an updated issuance log. The system provides real-time feedback on the update result to the user and updates the certificate information in the user's electronic certificate wallet.

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

[0092] This application utilizes a combination of end-to-end encrypted signature storage of logs, real-time monitoring, and dynamic inspection to achieve comprehensive oversight of electronic certificates from application, issuance, presentation, update to cancellation. This method effectively prevents data tampering and leakage, ensuring the authenticity and security of certificate data and providing users with more reliable and secure certificate services.

[0093] The monitoring center primarily provides registration and service management functions for the regulatory SDK and regulatory log processing service, monitors the operational status of the regulatory log processing service, and provides an interface for retrieving a list of regulatory log processing services. Specifically, the services provided by the monitoring center are as follows:

[0094] Service Registration and Management: The monitoring center provides a service registration interface, allowing the monitoring SDK and monitoring log processing service to register with the monitoring center upon startup. Registration information includes, but is not limited to, service name, address, and port. Simultaneously, the monitoring center provides service management functions for monitoring the status and updating the configuration of registered services.

[0095] Status Monitoring: The monitoring center continuously monitors the operational status of registered services, especially the online / offline status of the log processing service. Through heartbeat detection, log analysis, and other methods, it ensures the system can respond to changes in service status in real time.

[0096] Service List Interface: The monitoring center provides an interface to retrieve a list of regulatory log processing services. This interface returns information on currently available regulatory log processing services, including service name, address, and status. The regulatory SDK and other related services can use this interface to query and select the appropriate service for processing.

[0097] After startup, the regulatory log processing service first registers with the monitoring center, uploading its IP address and service port. The regulatory log processing service sends a heartbeat every T1 seconds. The monitoring center continuously monitors the heartbeat information of the registered services. If no heartbeat information is received within T2 consecutive periods, the regulatory log processing service is considered abnormal and removed from the list of available services. In this embodiment, T1 is 5 and T2 is 3.

[0098] The monitoring SDK provides log collection, log compression, and log reporting functions. After startup, the monitoring SDK connects to the monitoring center and calls the monitoring log processing service list interface to obtain the currently available monitoring log processing services. At the same time, the monitoring SDK connects to the monitoring log processing services.

[0099] After the monitoring SDK collects the monitoring logs, it performs log compression operations; such as... Figure 5 As shown, the log compression operation includes a primary compression operation and a secondary compression operation. The primary compression operation involves compressing the log details using a high-rate compression algorithm to obtain compressed log details. The secondary compression operation involves replacing the original log details with the compressed log details and performing secondary compression together with other log information to obtain secondary compressed log information. The monitoring SDK reports the secondary compressed log information to the monitoring log processing service in real time.

[0100] In practice, the log compression operation uses lossless compression algorithms based on existing technologies, such as ZIP and GZIP. The compressed regulatory logs are smaller in size, making them easier to store and transmit.

[0101] like Figure 3 As shown, the regulatory log processing service creates a connection manager, which monitors multiple regulatory SDKs based on I / O multiplexing technology;

[0102] The monitoring log processing service first registers the monitoring SDK connections that need to be monitored with the connection manager, and then allocates an internal queue buffer in memory for each monitoring SDK connection to temporarily store the secondary compressed log information reported by the monitoring SDK; if the monitoring SDK reports secondary compressed log information first, it is placed in its corresponding internal queue buffer first.

[0103] The connection manager will enter a read loop, checking the internal queue buffer of all SDK connections every M0 milliseconds to see if there is any data.

[0104] When the internal queue buffer contains data, the connection manager reads N0 data entries from the internal queue buffer and sends them to the memory buffer queue within the supervisory log processing service. In this embodiment, M0 is 100 and N0 is 10000.

[0105] The monitoring log processing service is equipped with two memory buffer queues: a preprocessing queue and a write queue. These two queues are independent of each other but work closely together to form the core of the log processing flow.

[0106] The preprocessing queue is used to receive and preprocess data from different monitoring SDKs in real time. The preprocessing queue receives secondary compressed log information reported by the monitoring SDKs. Since the monitoring SDKs may be deployed in multiple different business systems, the preprocessing queue needs to be able to process concurrent log data from multiple sources simultaneously.

[0107] The write queue buffers preprocessed data, awaiting batch storage. It is responsible for pushing preprocessed and formatted log data to the storage service. As a buffer for log data flow to the storage service, the write queue effectively mitigates potential discrepancies between log generation rate and storage service processing capacity.

[0108] like Figure 3 As shown, to fully leverage the performance advantages of multi-core processors, the regulatory log processing service employs 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. Specifically, this includes preprocessing threads and writing threads. Figure 3The leftmost connection in the diagram represents the SDK connection; the preprocessing queue and write queue in the diagram are both concurrent queues.

[0109] The preprocessing thread is responsible for reading raw log data from the preprocessing queue and performing decompression and formatting operations. Decompression ensures that subsequent processing steps can directly manipulate the uncompressed log data, while formatting includes parsing log fields, converting log formats, and verifying the integrity and accuracy of the log data.

[0110] The write thread is responsible for reading formatted log data from the write queue and writing it to the storage service in batches. Batch writing can significantly improve the system's throughput and stability, and reduce the performance loss caused by frequent write operations.

[0111] The monitoring log processing service first initializes a thread pool manager and a 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 pulls N2 secondary compressed log messages from the preprocessing queue at intervals of N1 milliseconds, and submits the pulled data to the first thread pool manager. The dispatcher pulls data from the preprocessing queue according to a preset number. In this embodiment, M1 is 6, M2 is 12, and N1 is 1000.

[0112] The first thread pool manager randomly selects an idle thread as a preprocessing thread to preprocess the raw log data, and then turns the preprocessing thread into a non-idle thread;

[0113] Preprocessing includes: the preprocessing thread first decompresses the secondary compressed log information to obtain the primary compressed log data; after the first decompression, 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;

[0114] After the preprocessing operation is completed, the compressed log data is pushed to the write queue.

[0115] The monitoring log processing service re-initializes a thread pool manager and a queue dispatcher, denoted as: Second Thread Pool Manager and Second Queue Distributor. The thread pool manager sets the core thread count of the thread pool to M3 and the maximum thread count to M4. The second queue dispatcher periodically pulls N4 compressed log data entries 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.

[0116] The second thread pool manager randomly selects an idle thread as a writing thread to store logs in the database, and then converts the writing thread into a non-idle thread.

[0117] The write thread calls the supervisory log storage service to write log data in batches to the supervisory 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.

[0118] Specifically, in a thread calling a supervisory log storage service, the log processing flow includes the following steps:

[0119] Log Reception: The monitoring SDK pushes the collected compressed monitoring logs to the preprocessing queue. Preprocessing: The preprocessing thread reads the raw log data from the preprocessing queue and performs decompression and formatting operations. Push to Write Queue: After preprocessing, the formatted log data is pushed to the write queue for further processing. Write to Storage: The write thread reads the log data from the write queue and writes it in batches to the storage service. The storage service is implemented based on a database, file system, etc., depending on the actual needs and architecture design of the system.

[0120] This application simplifies the log processing flow to three steps: collection, processing, and storage. It implements the collection of regulatory logs based on the regulatory SDK, performs preprocessing operations required before storage through the regulatory log processing service, and completes the storage operation using the combined services of the regulatory log processing and storage services. Within the regulatory log processing service, a connection manager, queue dispatcher, and thread pool are configured. Regulatory log data reported by the regulatory SDK is first placed in the internal queue buffer of the connection manager, and then sent to the preprocessing queue via the queue dispatcher for preprocessing. The preprocessed log data is then pushed to the write queue, and subsequently pushed in batches to the regulatory log storage service. The entire process is performed in memory, eliminating the need for disk read / write operations and saving significant disk I / O time. The regulatory log processing service in the system employs dual-memory buffer queues and multi-threaded processing technology, greatly improving log processing efficiency and response speed. This design enables the system to process large amounts of log data faster, reduces processing latency, and provides strong support for real-time monitoring and early warning, effectively improving log processing efficiency and response speed.

[0121] In practical implementation, the capacity of the memory cache queue also needs to be managed: to avoid queue overflow or excessive waiting, the system needs to dynamically manage the capacity of the preprocessing queue and the write queue. When the queue capacity approaches its limit, the system takes corresponding measures, such as pausing the reception of new log data or increasing the number of processing threads. In a multi-threaded processing environment, load balancing is an important consideration. The system needs to dynamically adjust the number of preprocessing threads and write threads based on the current processing capacity and load to ensure the efficiency and stability of log processing. During log processing, various abnormal situations may be encountered, such as data format errors and storage service failures. To enhance the robustness of the system, a robust error handling mechanism needs to be established. When abnormal situations are encountered, the system can promptly capture and process errors and record the corresponding error information for subsequent analysis and troubleshooting. Through the above implementation methods, this electronic certificate full-process 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.

[0122] Regulatory logs are stored in the log storage module as a log chain. Each encrypted and signed regulatory log is linked together in chronological order or according to business logic to form a complete log chain. Each log record contains its own information and a hash value (or pointer) to the previous record, forming a chain structure that ensures the continuity and immutability of the logs. Hash value calculation uses a collision-resistant hash function, ensuring that even minor data changes will result in significantly different hash values, making them easily detectable.

[0123] When a user submits an application for an electronic certificate, a globally unique certificate number ZZBH is first generated for each user.

[0124] The certificate number ZZBH is generated using a highly secure random number algorithm, combining user parameters including a timestamp and user identity information. The uniqueness of the electronic certificate's log chain is ensured based on the certificate number ZZBH throughout the system. A new log chain record, designated as the base log chain record, is created based on the certificate number ZZBH. This base log chain record includes: application time, applicant information, certificate type (e.g., driver's license, ID card), and initial status (recording the certificate's initial status, such as "applied for" or "pending review"). This base log chain record serves as the starting block (application block) of the log chain.

[0125] 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 signing process.

[0126] The encryption and signing process includes: encrypting each record in the log chain (including certificate number, timestamp, operation type, changes, etc.) using a national standard symmetric encryption algorithm (such as AES-256) to ensure data confidentiality during transmission and storage. Then, applying a national standard digital signature to the encrypted data, using a private key to digitally sign the encrypted content and generate a signature value, ensuring that the log record was created by an authorized entity and has not been tampered with. Finally, appending the signature value to the encrypted content forms the complete log record data.

[0127] By storing the log chain in a distributed database, the security and reliability of data can be improved by leveraging the characteristics of distributed storage. When it is necessary to verify the historical record or current status of an electronic certificate, the signature and hash value of each record can be verified one by one by tracing the log chain, starting from the application block, to ensure the authenticity and integrity of all records.

[0128] In practice, the log chain is audited regularly to check the completeness and accuracy of log records, and to promptly identify and address any anomalies or potential security risks. Log chain data is backed up regularly 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 trustworthiness of the electronic certificate.

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

[0130] This system provides flexible alert configuration capabilities based on real-time and dynamic alert services for regulatory logs, allowing users to set and adjust alert rules according to different business process requirements. Simultaneously, the real-time and dynamic alert services can verify data in real time and generate alert messages, which are quickly pushed to relevant personnel via various communication methods such as email, SMS, and instant messaging tools. This flexible alert configuration and rapid alert response mechanism helps to promptly identify and address potential security risks, improving system security and stability.

[0131] The real-time alert service for regulatory logs monitors a single type of data in real time. For example, the alert type can be set to "Application Frequency Alert," the alert rule to "Usage exceeding 5 times in 24 hours," and the alert description to "XX electronic certificate has been used more than 5 times in 24 hours." After this alert rule is configured and takes effect, logs in real-time processing will issue a real-time alert based on the number of uses within 24 hours. If the number of uses exceeds 5, the alert will be sent to the relevant personnel via a preset communication method according to the alert contact person specified in the alert configuration.

[0132] The regulatory log dynamic early warning service makes a comprehensive judgment on compliance based on the combination of multiple data types, or on the compliance of multiple data points of a single data type. For example, the following inspection strategy can be formulated: the inspection frequency is "every day at midnight", the inspection content is "judgment of the validity of licenses and permits", and the inspection scope is "regulatory logs of the most recent month". The dynamic early warning can be set as "overdue cancellation warning", the warning rule is "not cancelled within one month of expiration, executed at midnight every day", and the warning description is "XX electronic license has expired".

[0133] After configuring the inspection strategy and early warning rules, the dynamic early warning service will start a scheduled task at midnight every day to scan the regulatory logs of the past month. If the logs are not deregistered for more than a month, a dynamic early warning message will be generated. Upon completion of the inspection, an inspection result report will be generated, summarizing information such as the findings, anomaly detection and handling results during the inspection process, and generating detailed statistical data and charts.

[0134] This method combines real-time and dynamic early warning services based on regulatory logs to ensure coverage of all business activities requiring regulation, thereby ensuring more accurate regulation of the entire electronic certificate process.

[0135] After the real-time alert service for regulatory logs is activated, it first reads the pre-set alert configuration information. This configuration includes the alert type, alert rules, and alert description. Based on the read alert rules, the service performs real-time verification of relevant data in the business process. For example, for data threshold alert rules, the system determines whether the current data exceeds a preset threshold; for status change alert rules, the system determines whether the current data status exceeds a preset range or has undergone abnormal changes. During the verification process, the system monitors relevant data in the business process in real time and determines whether it meets the alert conditions. Once data meeting the alert conditions is detected, the system immediately triggers the alert mechanism.

[0136] Different warning rules correspond to different verification methods. During the verification process, the system will determine whether the current data meets the warning conditions, i.e., whether it exceeds the preset threshold or state change range. When the real-time warning service of the monitoring log detects data that meets the warning conditions, it will immediately generate the content of the warning message details page. The warning message details page includes key information such as warning time, warning type, triggering rule, and specific data value, so that relevant personnel can quickly understand the warning situation and take appropriate measures.

[0137] The real-time alert service for regulatory logs will push a brief summary of the alert information to relevant personnel via preset communication methods, based on the alert contacts specified in the alert configuration. The alert contacts can then access the detailed content of the alert message based on this summary. Communication methods include email, SMS, and instant messaging tools. The specific choice depends on the actual needs of the system and the preferences of the alert contacts. When pushing alert information, the system ensures the accuracy and timeliness of the information. Simultaneously, to avoid information redundancy and disruption, the system controls the frequency and method of alert information pushes.

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

[0139] Relevant personnel add, modify, and delete alert rules according to business needs. If an alert rule is set to "off," it means that the rule will no longer be subject to actual alert verification and push operations. In this case, the real-time alert service for regulatory logs will continue to monitor the execution of other alert rules and generate and push corresponding alert information as needed.

[0140] The real-time alert service for monitoring logs includes monitoring nodes. Specifically, these nodes connect to the log chain's storage network via a network link. This ensures that the monitoring nodes can capture activity on the log chain in real time and exchange data with other monitoring nodes. Monitoring nodes should be granted appropriate permissions to access data on the log chain. These permissions should undergo rigorous security review to ensure that nodes can only access the data they need and cannot make unauthorized modifications to the log chain.

[0141] Methods for monitoring nodes to capture newly added log records on the log chain in real time include: using the event listening mechanism provided by the log chain storage network in the log storage module to capture newly added log records on the log chain in real time, or calling the API interface to periodically query newly added log records on the log chain; correspondingly, the log chain storage network of the log storage module supports event listening function and can send real-time event notifications to the monitoring node, or provide an API interface for external access to log chain data.

[0142] When monitoring nodes capture log records, they ensure that the captured data includes the completeness of key information in the log records. Key information includes: complete content, signature, hash value, and timestamp.

[0143] The monitoring node uses a public key to verify the signature of the captured log records; the verification includes: hash value verification and link relationship verification; when an anomaly or potential risk is detected, an alarm mechanism is immediately triggered;

[0144] Hash value verification is performed 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.

[0145] 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 an anomaly.

[0146] The real-time alert service for monitoring logs performs anomaly analysis on log data: For verified log records, monitoring nodes conduct further analysis to identify any anomalies or potential security risks. This can be achieved by analyzing information such as the content, timestamps, and source of the log records. When a monitoring node detects an anomaly or potential risk, it should automatically generate an alarm message.

[0147] The regulatory log dynamic early warning service performs dynamic inspections according to pre-defined inspection strategies.

[0148] The inspection strategy includes: inspection frequency, inspection content, and inspection scope; the inspection content includes: checking the integrity of log records, verifying the validity of signatures, checking the correctness of signature values, and evaluating the application of certificates and licenses; the inspection scope includes: conducting a comprehensive inspection of the entire log, or conducting a partial inspection of the logs within a specific time period.

[0149] After the dynamic early warning service for regulatory logs is activated, it first reads the pre-configured early warning information. This information includes key parameters such as early warning type (e.g., data anomaly warning, status change warning), early warning rules (specific data thresholds, status ranges, and other judgment criteria), and early warning description (detailed explanation of the warning and handling suggestions). This configuration information can be flexibly set and adjusted according to different business process requirements.

[0150] The regulatory log dynamic early warning service performs real-time verification of relevant data in the business process based on the early 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 preset thresholds or status change ranges to determine whether the data meets the early warning conditions. Once data that meets the early warning conditions is detected, the regulatory log dynamic early warning service immediately triggers the early warning mechanism and generates an early warning message details page. This details page will include key information such as the early warning time, early warning type, triggering rule, and specific data values, so that relevant personnel can quickly understand the early 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.

[0151] After each round of inspections, the regulatory log dynamic early warning service generates an inspection result report. This report summarizes all findings during the inspection process, including anomaly detection results and corresponding handling measures. The report will include detailed statistical data and charts to enable relevant personnel to conduct in-depth analysis and summarization of the inspection results, providing a reference for subsequent improvements and optimizations.

[0152] When developing an inspection strategy, a comprehensive risk assessment of the log chain is necessary first. This includes analyzing the data types stored in the log chain, data sensitivity, potential threats, and historical security incidents. Based on the risk assessment results, the importance and security requirements of the log chain can be determined, thereby enabling the development of a more precise inspection strategy.

[0153] When the regulatory log dynamic early 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 result for each log record is 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 robust data structure and indexing mechanism to facilitate rapid querying and analysis of the inspection results.

[0154] In practical implementation, the inspection nodes of the dynamic early warning service for regulatory logs should be equipped with anomaly detection 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 detection. For detected anomalies, the inspection nodes should trigger anomaly handling procedures, including generating anomaly reports, sending alarm information to system administrators or security teams, and recording the anomaly handling process. Simultaneously, corresponding handling measures and recommendations should be formulated based on the anomaly type and severity.

[0155] The execution process of real-time alert service and dynamic alert service for regulatory logs, such as Figure 4 As shown.

[0156] To improve the speed of accessing early warning information, both the real-time early warning service and the dynamic early warning service for regulatory logs cache the detailed content of the generated early warning messages in memory for subsequent access. This way, in subsequent access requests, the system directly reads the early warning information from memory without needing to perform complex calculations and queries again.

[0157] This application collects and stores logs from the entire process of the electronic certificate system application. It adopts a combination of real-time and dynamic early warning methods to conduct multiple rounds of inspections on the collected log data, which meets both the needs of real-time applications and delayed business operations.

[0158] By using the technical solution of this invention, comprehensive collection and processing of regulatory logs in all stages such as application, issuance, presentation, update and cancellation can fully guarantee the authenticity and security of certificate data, improve log processing efficiency and response speed, and provide users with more reliable, safe and efficient certificate services through flexible early warning configuration and rapid early warning response.

Claims

1. A full-process supervision system for electronic certificates and licenses, characterized in that, It includes: monitoring The center, the regulatory SDK, the regulatory log processing service, and the regulatory log storage service; The regulatory SDK is embedded in the electronic certificate system. The types of operations that need to be regulated are preset and denoted as: regulatory operations. When any of the regulatory operations occur in the electronic certificate system, the regulatory SDK will capture the detailed information of these regulatory operations and generate regulatory logs according to the preset log format. The log information in the regulatory log includes: log number, log associated 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 provides the regulatory SDK and the regulatory log processing service with service registration and service management functions, monitors the running status of the regulatory log processing service, and provides an interface for obtaining a list of regulatory log processing services. After startup, the regulatory log processing service first registers with the monitoring center, uploading its IP address and service port. The regulatory log processing service sends a heartbeat every T1 seconds. The monitoring center continuously monitors the heartbeat information of the registered services. If no heartbeat information is received within T2 consecutive periods, the monitoring center considers the regulatory log processing service to be abnormal and removes it from the list of available services. The monitoring SDK provides log collection, log compression, and log reporting functions. After startup, the monitoring SDK connects to the monitoring center and calls the monitoring log processing service list interface to obtain the currently available monitoring log processing services. At the same time, the monitoring SDK connects to the monitoring log processing services. After the monitoring SDK collects the monitoring logs, 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-rate 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 monitoring SDK reports the secondary compressed log information to the monitoring log processing service in real time. The regulatory log processing service is configured with dual memory buffer queues, which include a preprocessing queue and a write queue. The preprocessing queue is used to receive secondary compressed log information data reported from the monitoring SDK in real time and preprocess the data. The writing queue is used to buffer the preprocessed data and wait for batch storage. The regulatory log processing service first initializes a thread pool manager and a queue dispatcher, denoted as: the first thread pool manager and the first queue dispatcher; The first queue distributor periodically (N1 milliseconds) pulls N2 pieces of the secondary compressed log information from the preprocessing queue and submits the data to the first thread pool manager. The first thread pool manager randomly selects an idle thread as a preprocessing thread to preprocess the raw log data, and then 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 a 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 compressed log data is pushed to the write queue. The regulatory log processing service re-initializes a thread pool manager and a queue dispatcher, denoted as: the second thread pool manager and the second queue dispatcher; The second queue distributor periodically (N3 milliseconds) pulls N4 compressed log data entries from the write queue and submits the data to the second thread pool manager. The second thread pool manager randomly selects an idle thread as a writing thread to store logs in the database, and then converts the writing thread into a non-idle thread. The writing thread calls the supervisory log storage service to write log data in batches to the supervisory log storage service, which then stores the data in the log storage module.

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

3. The electronic certificate full-process supervision system according to claim 1, characterized in that: The regulatory operations include: application, issuance, presentation, renewal, and cancellation of electronic certificates; The types of regulatory logs include: application logs, issuance logs, presentation logs, update logs, cancellation request logs, and cancellation logs; 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: certificate information and approval results generated by the certificate issuing authority; The presentation log includes: the time and recipient of the electronic certificate presentation generated by the electronic certificate system when the electronic certificate user uses the electronic certificate; The update log includes: when an 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: when an electronic certificate is cancelled, the cancellation request number generated by the electronic certificate system, the user's identity information, and the certificate information to be cancelled; The cancellation log includes the cancellation result and approval result generated by the issuing authority after the electronic certificate is cancelled.

4. The electronic certificate full-process supervision system according to claim 1, characterized in that: The regulatory logs are stored in the log storage module in the form of a log chain. Each encrypted and signed regulatory log is linked together in the form of log records according to time sequence or business logic to form a complete log chain. In addition to 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 timestamps and user identity information. Based on the certificate number ZZBH, a new log chain record is created, denoted as the basic log chain record. 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 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 signing process. The encryption and signing process includes: encrypting the content of each record in the log chain using the national standard symmetric encryption algorithm, and simultaneously performing a national standard digital signature on the encrypted data and generating a signature using a private key; The log chain is stored in a distributed database. When it is necessary to verify the historical record or current status of an electronic certificate, the signature and hash value of each record are verified one by one by tracing the log chain, starting from the application block.

5. The electronic certificate full-process supervision system according to claim 4, characterized in that: The log storage module provides a standard interface, including a RESTful API, for the early warning service to access regulatory logs and data in the log chain; The early warning service includes: real-time early warning service for regulatory logs and dynamic early warning service for regulatory logs.

6. The electronic certificate full-process supervision system according to claim 5, characterized in that: The real-time alert service for regulatory logs is designed for real-time monitoring of a single type of data. After the real-time alert service for regulatory logs is started, it first reads the preset alert configuration information; The early warning configuration information includes: early warning type, early warning rules, and early warning description; The real-time alert service for regulatory logs performs real-time verification of relevant data in the business process based on the read alert rules. Different alert rules correspond to different verification methods. During the verification process, the system will determine whether the current data meets the alert conditions. When the real-time alert service for regulatory logs detects data that meets the alert conditions, it will immediately generate an alert message, which includes: alert time, alert type, triggering rule, and specific data value. The real-time alert service for monitoring logs will push a brief overview of the alert information to relevant personnel through a preset communication method, based on the alert contact person specified in the alert configuration; the alert contact person can then access the detailed content of the alert message based on the brief overview of the alert information.

7. The electronic certificate full-process supervision system according to claim 5, characterized in that: The monitoring node is set up in the real-time early warning service of the monitoring log. The method for the monitoring node to capture newly added log records on the log chain in real time includes: using the event listening mechanism provided by the log chain storage network in the log storage module to capture newly added log records on the log chain in real time, or calling the API interface to periodically query newly added log records on the log chain. When capturing log records, the monitoring node ensures that the captured data includes the integrity of the key information of the log records, including: complete content, signature, hash value, and timestamp; The monitoring node uses a public key to verify the signature of the captured log records; the verification includes: hash value verification and link relationship verification; when an anomaly or potential risk is detected, an 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. The electronic certificate full-process supervision system according to claim 6, characterized in that: The regulatory log dynamic early warning service makes a comprehensive judgment on whether the combination of multiple types of data is compliant, or makes a comprehensive judgment on whether the superposition of multiple data of a single type is compliant. The regulatory log dynamic early warning service performs dynamic inspections according to a pre-defined inspection strategy. The inspection strategy includes: inspection frequency, inspection content, and inspection scope; the inspection content includes: checking the integrity of log records, verifying the validity of signatures, checking the correctness of signature values, and evaluating the application of certificates and licenses; the inspection scope includes: conducting a comprehensive inspection of the entire log, or conducting a partial inspection of the log within a specific time period. After the dynamic early warning service for the monitoring log is started, it first reads the preset early warning configuration information and performs real-time verification on the relevant data in the business process according to the early warning rules in the early warning configuration information; when data that meets the early warning conditions is detected, the detailed content of the early warning message will be generated immediately. After each round of inspections, the regulatory log dynamic early warning service generates an inspection result report; the inspection result report includes: findings, anomaly detection and handling results during the inspection process.

9. The electronic certificate full-process supervision system according to claim 5, characterized in that: When the regulatory log dynamic early warning service performs dynamic inspection, it traverses each log record in the log chain and performs verification tasks. The verification tasks include: integrity verification, signature verification, and hash value verification. During the verification process, the verification result of each log record is recorded. The verification result includes: the number of successfully verified log records, the number of anomalies found, and the anomaly type.

10. The electronic certificate full-process supervision system according to claim 6, characterized in that: Both the real-time early warning service and the dynamic early warning service for regulatory logs cache the detailed content of the generated early warning messages in memory for subsequent access.

Images