Network security protection method and system fusing identity authentication and data analysis

Abstract

The application relates to the technical field of data processing of computer network security, and discloses a network security protection method and system fusing identity authentication and data analysis; and is used for solving the problem of lacking subject consistency binding and session level evidence alignment mechanism in the traditional method; the method firstly starts session freezing field mapping and threshold version in runtime, inputs authentication, access, host audit and traffic events, unifies and marks time quality by using fields and time, outputs replayable events by using out-of-order buffering and supplement area; subject binding and confidence are maintained based on an account, a terminal fingerprint, a session certificate and a connection identifier, a session evidence package and an evidence index are established, conflict items and missing items are registered, a trigger condition and an evidence threshold are graded and judged, disposal is issued, and a verifiable and traceable dynamic security disposal is performed.

Description

Technical Field

[0001] This invention relates to the field of data processing technology for computer network security, specifically to a network security protection method and system that integrates identity authentication and data analysis. Background Technology

[0002] As government and enterprise networks evolve from perimeter-based protection to zero-trust and continuous verification, the joint analysis of identity authentication events with multi-source security data such as logs, traffic, and host auditing is gradually becoming an important technical approach for network security protection. For example, the published invention patent application CN105471842B discloses a network security analysis method in a big data environment, focusing on security analysis of access data after identity authentication and implementing protection based on security ratings; the published invention patent application CN113472778B discloses an information network security protection trust system and method, focusing on analyzing network behavior to calculate user trust values ​​and distributing control policies to access gateways for execution. Although the above solutions have certain effects at the identity access or behavior analysis level, they still generally expose key technical defects in complex network and multi-source data environments. On the one hand, the user identity, terminal environment, and session credentials output by the identity authentication system are often inconsistent with the timestamp standards, field structures, and subject identification systems of the multi-source data collected by the security analysis system, such as logs, traffic, and host audits. Simultaneously, the collection, transmission, and aggregation of multi-source data commonly suffer from out-of-order issues, delays, missing data, and inconsistencies in anonymized fields. This makes it difficult to stably correlate authentication events with subsequent accesses, lateral movements, abnormal traffic, or host behavior on a unified time base and unified subject dimension. Furthermore, due to the lack of a subject consistency binding and session-level evidence alignment mechanism that can be implemented within the computer system, even if the security analysis side detects high-risk behavior, it is difficult to establish a connection between that behavior and the authenticated subject or corresponding session credentials. The lack of a verifiable causal chain of evidence between authentications makes it unreliable to trigger actions with minimal impact on business operations, such as dynamic authorization, session demotion, secondary verification, or credential revocation. On the other hand, coarse-grained blocking measures taken to compensate for insufficient evidence chains can easily include irrelevant subjects or sessions in the scope of action, leading to false blocking, damage to business continuity, and difficulty in subsequent review and accountability. Therefore, a unified mechanism is needed to achieve subject consistency binding, session-level evidence alignment, and traceable decision rewrite under conditions of out-of-order, delayed, missing, and inconsistent multi-source data. This would solve the problem of unreliable handling or misjudgment of high-risk behaviors even after authentication has passed, and achieve traceable dynamic authorization, session demotion, and credential revocation as protective controls. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a network security protection method and system that integrates identity authentication and data analysis, solving the problems of lacking subject consistency binding and session-level evidence alignment mechanisms in traditional methods.

[0004] To achieve the above objectives, the present invention provides the following technical solution: Network security protection methods that integrate identity authentication and data analysis include: S1: Freeze the field mapping version and threshold version, generate the running session identifier, and register the data source list; S2: Receive authentication, access, host auditing, and traffic observation events, unify fields and timestamps according to the mapping version, mark time quality level, and output them in a unified time order after out-of-order buffering; S3: Establish a subject binding ledger based on account, terminal key fingerprint, session credential digest, and connection identifier digest; merge bindings according to consistency rules; and mark drifts and adjust confidence levels according to conflict rules. S4: Establish a session evidence package based on the subject number and the session window, associate multi-source events according to strong and weak alignment rules, generate an evidence index and register conflict entries; S5: Within the session window, make tiered decisions based on triggering conditions, issue action orders, record execution confirmations and write-back records, and seal the evidence package.

[0005] Preferably, the field mapping version and threshold version are frozen, a running session identifier is generated, and a list of data sources is registered, including: At startup, a running session is established, the mapping table, threshold table and source list are loaded to generate immutable metadata and perform digest verification; Freeze versions and access boundaries; unauthorized sources or inconsistent statements will be subject to isolation audit. Thresholds are configured according to strategy, on-site baselines, and operational statistics are hierarchically categorized, and changes are written to the candidate area for release verification. Initialize the resource budget and load reduction parameter set.

[0006] Preferably, for receiving authentication, access, host auditing, and traffic observation events, the fields and timestamps are standardized according to the mapping version, including: Authorization verification is performed on events from authentication sources, access sources, host audit sources, and traffic observation sources; unauthorized events are isolated for auditing. For authorized events, perform field mapping and cleaning according to the mapping version. Multi-source candidate fields are selected according to field priority and the mapping summary is retained. Cleaning anomalies is written with anomaly codes and missing reason codes. A unique event number is generated and written with desensitization tags and alignment clue strength limits.

[0007] Preferably, the time quality level is marked, and after being buffered out of order, it is output in a uniform time order, including: A unified reference time is determined by the event occurrence time, the source timestamp, and the receiving timestamp, and a time quality level is assigned. When the difference exceeds the upper limit of time deviation, a time anomaly code is written and the clue strength is reduced. Output is sorted according to the out-of-order buffer window. When the unified base time is the same, the receiving timestamp and event number are used as the secondary sorting key. Late events are written to the supplementary area that is only appended. When the number of events per unit time exceeds the throughput limit, a load reduction record is generated according to the retention priority and sampling interval.

[0008] Preferably, a subject binding ledger is established based on the account, terminal key fingerprint, session credential digest, and connection identifier digest, including: The main ledger is established based on account summary, terminal fingerprint summary, credential summary, and connection summary, and the main number is generated according to the division of labor of the running session; Ledger entry set, initial date, final confirmation date, status, confidence and basis entries; The clue index key consists of the clue type, clue summary, and desensitization tag. When the summary scope is inconsistent, the clues are isolated by bucket and the reason code is written. When the set exceeds the limit, it is truncated according to the most recent confirmation time and a truncated summary is recorded.

[0009] Preferably, the bindings are merged according to the consistency rule, and the drift is marked and the confidence level is adjusted according to the conflict rule, including: When making a consistent determination, the set is deduplicated and appended, and the confidence level is updated according to the scoring criteria. The single event scoring cap, total score cap, and rounding rules are constrained by the parameter group. When determining a conflict, write the drift criteria and deduct points. Repeated conflicts will result in isolation upgrades and the temporary main body strength limit will be weak. Shared accounts and springboard paths use dual-track fingerprints and update confidence levels according to a reduction factor, while generating candidate write-back items.

[0010] Preferably, a session evidence package is established based on the subject number and the session window, including: Successful authentication events are used to determine the start of the session window. If a successful authentication event is missing, the first access event is used to determine a temporary start and a "no authentication start" flag is recorded. The session number is generated by combining the running session identifier, the subject number, and the window start time; The session evidence package records the mapping version number, threshold version number, window start and end, start event index, supplementary area index, and integrity verification summary.

[0011] Preferably, based on strong and weak alignment rules, multi-source events are associated to generate an evidence index and register conflict entries, including: Configure alignment windows and expansion coefficients according to event type; When there are time anomalies, low source credibility level, incomparable desensitization, inconsistent abstract scope, or the main body is temporary or isolated, the upper limit of alignment strength is set to weak. Evidence index entries record alignment strength, source credibility level, time quality level, and reason code. Conflicting and missing entries are registered according to threshold parameter groups and pruned according to truncation priority.

[0012] Preferably, within the session window, tiered adjudication is performed based on triggering conditions, actions are issued, execution confirmations and write-back records are recorded, and evidence packages are sealed, including: Within the session window, validate the evidence threshold according to trigger priority to generate a chain of actions. The action setting confirmation timed out and was reissued according to the demotion chain; The disposal confirmation results will be written back to the subject confidence, execution surface reliability, and threshold candidate area; The evidence package is sealed according to the cutting parameters.

[0013] On the other hand, the present invention provides a network security protection system that integrates identity authentication and data analysis, including: Run Session and Calibration Freeze Module: At the start of the run, load the field caliber mapping table, threshold caliber table and data source list, generate the run session identifier and freeze the mapping version, threshold version and access boundary, form session meta data packet and write it to the audit storage so that subsequent processing modules can refer to the same context caliber. Event Access Specification and Out-of-Order Buffering Module: Receives authentication, access, host auditing and traffic observation events, completes field unification and cleaning according to the mapping version, completes time standardization and marks time quality level according to the unified base time, performs out-of-order buffering and late supplementation processing, and outputs unified event records and unified event sequences. Main entity binding ledger maintenance module: Maintains the main entity binding ledger based on account summary, terminal key fingerprint summary, session credential summary and connection identifier summary, determines the main entity number according to strong clues, merges bindings and updates the confidence level according to consistency rules, marks drift or isolation according to conflict rules, and outputs the candidate set of main entity numbers and incremental update records; Session evidence package construction and evidence alignment module: Merges multi-source events by subject number and session window, generates evidence index and critical chain index according to strong alignment and weak alignment rules, registers conflicting and missing entries, and outputs session evidence package and integrity verification summary; Tiered adjudication and write-back / sealing module: Based on the trigger condition table and the handling level table, it completes tiered adjudication and issues handling actions, records execution confirmation and write-back updates, and seals evidence packages, adjudication records and write-back records according to the sealing and trimming parameter groups.

[0014] Compared with existing technologies, the present invention provides a network security protection method and system that integrates identity authentication and data analysis, which has the following beneficial effects: 1. This invention addresses issues such as inconsistent data sources, easy rule drift, and unverifiable processing by freezing field mapping versions and threshold versions during the running session and writing verifiable session metadata. It resolves instability in event alignment and easy rewriting of historical conclusions caused by out-of-order, delayed, missing, and anonymized data differences by introducing time quality levels, source trust levels, and out-of-order buffers and supplementary areas. It reduces the risk of erroneous merging and triggering by binding the subject to the ledger aggregate account, terminal key fingerprint, session credentials, and connection identifier, combined with consistency merging and conflict drift determination. It solidifies strong / weak alignment, conflict, and missing entries through session evidence packages and evidence indexes, and implements graded adjudication and minimum impact processing based on trigger priority and evidence threshold, forming a closed loop with execution confirmation, downgrading, and write-back sealing. This achieves verifiable, traceable, and reproducible dynamic security processing, thus solving the problem of lacking subject consistency binding and session-level evidence alignment mechanisms in traditional methods.

[0015] 2. This invention transforms the handling of single-source security incidents into a closed-loop management system based on a chain of evidence. It version-based solidifies results according to parameters such as time deviation, alignment window, handling threshold, and deload method, using a threshold caliber table. It also structured and solidifies the chain based on the evidence index, including the evidence entry number, source credibility, and alignment strength corresponding to the trigger entry, reducing the risk of misjudgments based on risk scores or a single log entry. Furthermore, based on the execution-side confirmation timeout and degrade chain, combined with execution-side reliability write-back and candidate area release verification, it incorporates erroneous feedback verification conclusions, weak clue constraints, and threshold candidate changes into a reviewable iterative process, enhancing the security operation capabilities of the handling process to be explainable, traceable, reproducible, and with controllable impact. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the network security protection method integrating identity authentication and data analysis according to the present invention; Figure 2 This is a schematic diagram of the network security protection system that integrates identity authentication and data analysis according to the present invention. Detailed Implementation

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

[0018] Example 1: Figure 1A network security protection method integrating identity authentication and data analysis is presented, including: S1: Freeze the field mapping version and threshold version, generate a runtime session identifier, and register the data source list. The specific implementation is as follows: At the start of the process, a runtime session is created. The runtime session identifier serves as the unique context key for subsequent event specification, subject binding, evidence alignment, and adjudication. When a runtime session is established, the field caliber mapping table, threshold caliber table, and data source list are loaded simultaneously. A session metadata package is created and written to the audit storage in one go. The session metadata package should include the runtime session identifier, mapping version number, threshold version number, data source list summary, source trust level table summary, resource budget parameter summary, isolation audit retention period parameter, and integrity verification summary. After each write to the metadata package, only additional audit fields are allowed; existing fields cannot be modified. Integrity verification is performed at any stage before reading the mapping version or threshold caliber. If the mapping version number, threshold version number, or summary field under the same runtime session identifier differs from what has already been written, the discrepancy event is recorded, and the process switches to isolation mode. Isolation mode does not generate evidence packages for adjudication; unified audit records and isolation audit records no longer exist. Isolation audit records are retained according to the isolation audit retention period parameter, archived in buckets according to the runtime session identifier, and the retention period parameter is determined using the threshold caliber table, referencing the audit traceability period and storage budget. The field mapping table can be versioned. A field includes source type, source identifier, original field name, target field name, field priority, cleaning rules, missing field handling rules, desensitization method flag, and mapping version number. The source type can be authentication source, access source, host audit source, or traffic observation source. The source identifier uniquely identifies the collection point or link node. Field mapping can be one-to-one or many-to-one. In many-to-one mapping, the target field is selected based on the field priority, and missing fields are written into the original mapping summary. The cleaning rules are used to solidify the field standardization actions, such as removing spaces, unifying capitalization, normalizing enumeration values, and unifying address formats. The missing field handling rules are used to record the missing reason code and provide a field availability flag. The desensitization method flag and mapping version number are associated with records such as mask, summary, and truncation to determine field comparability and avoid false conflicts caused by desensitizing fields with the same name. The threshold caliber table adopts a versioned structure, including at least the following fields: parameter name, parameter meaning, value range, example value, source of reference, source type, conflict priority, and threshold version number. The source type can be categorized into three types: policy configuration, field baseline, and operational statistics. Policy configuration values ​​originate from security policies or compliance requirements and are frozen with the threshold version. Field baseline values ​​originate from operational observations within a predetermined sampling period and record the sampling period, statistical caliber field, and statistical quantile. Operational statistics values ​​generate candidate values ​​during operation and are written to the candidate release area, but do not take effect within the current operational session. The threshold caliber table covers time deviation upper limit, out-of-order buffer window, handling confirmation timeout window, session window and renewal caliber, load reduction policy caliber, resource budget parameter caliber, and isolation audit retention period caliber. The time deviation upper limit belongs to... Policy configurations, with values ​​ranging from 30 to 120 seconds (e.g., 60 seconds), are based on the upper bound of end-to-end timing error under network time synchronization policies and are compatible with short-term desynchronization drift. The handling confirmation timeout window ranges from 5 to 30 seconds (e.g., 15 seconds), based on the upper bound of round-trip latency between control plane issuance and execution plane receipt during peak hours. The out-of-order buffer window ranges from 60 to 300 seconds (e.g., 120 seconds), based on the upper bound of acquisition link latency jitter and aggregation queue queuing latency. The isolation audit retention period ranges from 7 to 180 days (e.g., 30 days), based on the audit traceability period and storage budget. Conflict priority is used to determine a unified decision order when multiple rules are concurrent and is fixed in the table, ensuring consistent output paths under the same input conditions. The running session identifier consists of a tenant identifier, a running start timestamp, a mapping version number, and a threshold version number. The running start timestamp is accurate to seconds and includes a start sequence number. The start sequence number is reset after the running session ends or reset by date. The running session identifier and version number are written into the session metadata data packet. The metadata data packet contains at least the running session identifier, mapping version number, and threshold version number fields, and serves as a reference key for the unified event record, subject binding record, and session evidence packet. Cross-stage serialization does not depend on external implicit state. The data source list is used to define access boundaries and expected fields. It must include source identifier, access method, expected field set, and source trust level field. The access method can be an enumerated value such as push, pull, file persistence, message queue subscription, etc. The expected field set is used for subsequent missing field determination. The source trust level is divided into three levels: high, medium, and low and is frozen when the session is established. The following rules can be adopted: if the source is from the authentication domain or core gateway and the characteristics such as link authentication and non-repeated reporting are high; if the source is from the endpoint proxy and the characteristics such as offline caching and supplementary reporting are medium; or if the source is from the bypass mirror or cannot prove integrity, it is low. Then, the source trust level table summary is written into the session metadata data packet, and the source trust field is transparently transmitted in the subsequent unified event record for reference in strength and handling threshold determination. After the runtime session is established, version freezing and access boundary freezing are performed. Version freezing means that hot updates of the mapped version and threshold version are not allowed during runtime. When a version change request is received, a version conflict event is recorded and loading is rejected. The candidate update record for the version change is written to the candidate release area. The candidate update record includes at least the suggested effective window, scope of impact, rollback conditions, and verification list. The candidate release area is loaded into subsequent runtime sessions and can only be used after passing the checks in the verification list. Access boundary freezing means that adding source identifiers or changing source trust levels are not allowed during runtime. When a source change occurs, a boundary conflict event is recorded and the source is marked as an unauthorized source. Events from unauthorized sources enter the isolation audit queue and generate isolation event records, which do not enter the subsequent unified event sequence and adjudication chain. The isolation event record includes at least the runtime session identifier, source identifier, receiving timestamp, change type, and reason code. The candidate effective window and verification list are set from the release verification parameter group frozen by the threshold caliber table. When a session is established, resource budget parameters are initialized and written to the session metadata packet. These parameters include at least the following fields: maximum principal concurrency, maximum session concurrency, out-of-order buffer capacity allocated by source, and maximum number of evidence entries per session. Simultaneously, the threshold caliber table is fixed with fields such as the unit principal record usage caliber, unit session record usage caliber, and peak event rate caliber. For example, the maximum principal concurrency is set to 1 million, and the maximum session concurrency to 200,000, with values ​​calculated based on the unit record usage caliber and the available memory budget, while also covering peak activity levels. The out-of-order buffer capacity is set to, for example, 100,000 records per source, with values ​​referencing the out-of-order buffer window. The peak event rate is converted to the buffer window length and is constrained by the single-source memory quota; the maximum number of evidence entries per session is, for example, 2000, with a range of 500 to 3000, and the value is determined by the evidence package playback latency and long-term storage cost; if the resource budget is insufficient to cover the expected scale, the budget shortfall event is recorded and the default deload caliber is enabled, which prioritizes the deload parameter group in the threshold caliber table; when the deload parameter group is missing, the built-in conservative caliber is used and the missing reason code is recorded, for example, only authentication events and high-sensitivity access events are retained in the unified sequence, the out-of-order buffer window is set to 60 seconds, and the sampling interval is set to 5 seconds; After the session metadata data is stored in the database, the next step is to use the running session identifier as the context to read the mapping version and threshold caliber, unify the event fields, standardize the timestamps, and buffer the out-of-order output. The running session identifier, source trust field, and time quality field will be carried in the subsequent unified event records to provide input boundaries for the maintenance of the subject binding ledger and the construction of the session evidence package.

[0019] S2: Receives authentication, access, host auditing, and traffic observation events, standardizes fields and timestamps according to the mapped version, marks time quality levels, and outputs them in a unified time order after out-of-order buffering. Specifically, the implementation is as follows: After the session metadata is stored in the database, the event access and standardization process begins. The session identifier is used as the context key, and the mapping version and threshold caliber table are referenced according to the session identifier to complete field unification, timestamp standardization, out-of-order buffering, and load reduction control. The threshold caliber table and threshold version number are bound together. Each parameter must include at least the parameter name, parameter meaning, value range, example value, source type, value description, and conflict priority. The source type can be selected as policy configuration or field baseline. For statistical thresholds, only candidate values ​​are generated and written to the candidate release area without changing the caliber of the current session. The original event records of authentication source, access source, host audit source, and traffic observation source are input. The original events must include at least the source identifier, receiving timestamp, and original field set. If the source identifier is not in the data source list, it is determined to be an unauthorized source. Unauthorized source events are only written to the isolation audit queue and generate isolation event records. They do not enter the unified event sequence and alignment / adjudication chain. The isolation event records must include at least the session identifier, source identifier, receiving timestamp, change type, and reason code. For authorized source events, field unification is performed according to source type. Field unification is based on the target field set defined in the mapping version referenced by the running session identifier. The target field set includes at least account field, terminal field, session field, connection field, resource field, and event type field, and the corresponding fields in the original event are mapped to internal unified fields. Mapping prioritizes a one-to-one rule. When multiple candidate source fields exist for the same target field, the field priority recorded in the mapping version is selected. Unselected candidate fields are retained in the form of the original field mapping summary for replay verification. Field cleaning is performed according to the cleaning rules fixed in the mapping version. The cleaning rules adopt deterministic actions, such as removing leading and trailing spaces, merging enumerated values ​​into a standard set, and unifying address formats. When illegal or out-of-range values ​​appear in the cleaning results, a field exception code is written and the field is set as missing. At the same time, a missing reason code is written and retained with the original field mapping summary. Internal event numbers are generated in ascending order within the same running session identifier range, or generated by combining the source identifier, receiving timestamp, and ascending order number, to ensure event uniqueness and support replayability sorted by a unified base time. The timestamp specification centers on a unified reference time, extracting fields such as event occurrence time, source timestamp, and receive timestamp to generate a unified reference time and label it with a time quality level, while retaining the original timestamp summary. The time quality level is categorized into high, medium, and low. The criteria are: high if both the event occurrence time and source timestamp are present and their difference does not exceed the time deviation limit; medium if only one of the event occurrence time or source timestamp is present; and low if only the receive timestamp is present. The time deviation limit ranges from 30 to 120 seconds (e.g., 60 seconds), determined by the upper bound of the end-to-end clock offset under the enterprise network time synchronization policy and the jitter level of the acquisition link. When the difference exceeds the time deviation limit, a time anomaly code is written, and the time quality level is set to low. When a time anomaly code, a low time quality level, or a low source trust level occurs, the alignment clue strength limit is set to weak. The original timestamp summary includes at least a summary of the difference between the source and receive timestamps, an existence marker for the event occurrence time field, and a time anomaly code, used for verifying the time caliber during audit playback. After field unification and timestamp standardization are completed, out-of-order buffering is initiated. The out-of-order buffer sets a buffer window based on the source type and remains unchanged throughout the session. The buffer window value ranges from 60 to 300 seconds; for example, a value of 120 seconds. The value is derived from the out-of-order buffer window parameter in the threshold table. Within the buffer window, out-of-order buffers output data in a unified base time order. When the unified base times are the same, the received timestamp and internal event number are used as the secondary and final sorting keys, respectively, ensuring a deterministic output order. Events arriving after the out-of-order buffer window are then processed... The event is designated as late. A late event is marked with a late flag and the number of seconds of lateness, and is also written as a supplementary event record to the supplementary area. The supplementary area only allows appending and does not allow rewriting the sequential references of the output unified event sequence. The supplementary event record includes at least the following fields: internal event number, number of seconds of lateness, original sequence anchor number, write timestamp, and running session identifier. It is also subject to the upper limit of evidence entries per session and the retention period parameter. The upper limit of evidence entries per session is determined with reference to the resource budget parameter, and the retention period parameter is determined with reference to the retention period parameter in the threshold caliber table. Output unified event logs and unified event sequences. Unified event logs should include at least the following fields: internal event number, source type, source identifier, unified reference time, time quality level, source trust level, key field summary, alignment clue set, original field mapping summary, and original timestamp summary. Key field summaries should include at least the following fields: account identifier summary, terminal key fingerprint summary, session credential summary, connection identifier summary, resource identifier summary, and event type enumeration. Alignment clue sets should be grouped by clue type and carry clue strength markers. Clue types should include at least the following fields: session credential summary clue, connection identifier summary clue, terminal certificate summary clue, access gateway clue, application identifier clue, and address / network segment clue. When the upper limit of the clue strength marker is weak, it cannot be used for strong alignment. Missing clues should be marked with a missing reason code and the field should be marked as unusable for strong clue generation. Inconsistent desensitization should be marked according to the desensitization method, marking the field as uncomparable. Only weak clues can be generated with desensitization method markers to avoid judging inconsistent desensitization criteria as conflicts during subsequent comparisons. During operation, runtime statistics records are synchronously generated and archived, and bound to runtime session identifiers. These records include at least the following fields: throughput, latency, and load reduction. Throughput records include at least the following fields: number of events per unit time, number of events by source, and current buffer usage. Latency records include at least the following fields: average receive latency, maximum receive latency, proportion of late events, and proportion of time-abnormal events. Load reduction control is triggered when the number of events per unit time exceeds the throughput limit parameter. The throughput limit parameter is taken from the throughput limit item in the threshold table, for example, 50,000 records per second, and its value is determined based on the processing resource budget and peak access rate. The load reduction parameter group includes at least the following fields: throughput limit, sampling interval, event retention priority table, high-sensitivity judgment threshold, and abnormal label whitelist. The event retention priority table specifies that authenticated events and high-sensitivity access events are retained first. The high-sensitivity judgment threshold can be selected as a resource sensitivity greater than or equal to 4 or an operation semantic falling into the high-sensitivity operation semantic set. The high-sensitivity operation semantic set is stored as an enumeration code or a list of standardized action names, and the source side action fields are merged into this set by the mapping version. Host audit and traffic observation events are retained first according to the abnormal label whitelist. Other events output the same type of event summary according to the sampling interval. The sampling interval is the sampling interval item in the threshold caliber table, for example, a value of 5 seconds. Its value is determined with reference to the audit traceability granularity and the upper limit of processing capacity. The load reduction record includes at least the load reduction trigger reason code, retention priority hit item, sampling decision summary and other fields to support the replayability and interpretability auditing of the unified event sequence under load reduction conditions.

[0020] S3: Establish a principal binding ledger based on account, terminal key fingerprint, session credential digest, and connection identifier digest; merge bindings according to consistency rules; mark drifts and adjust confidence levels according to conflict rules. The specific implementation is as follows: After the unified event sequence is generated, it will enter the subject binding ledger maintenance process. The process takes the running session identifier as a prerequisite and references the unified event record, which includes at least the following fields: account identifier summary, terminal key fingerprint summary, session credential summary, connection identifier summary, time quality level, source trust level, missing reason code, and de-identification method mark. It references the subject binding parameter group and confidence update parameter group in the threshold caliber table to perform subject positioning, set merging, drift marking and confidence update. The alignment strength upper limit is uniformly controlled. When any one of the following conditions is met, such as unauthorized source, de-identification not comparable, inconsistent summary caliber, time anomaly code, low time quality level, low source trust level, or subject number value is temporary or isolated, the alignment strength upper limit is weak. In other cases, it is strong. The entity binding ledger uses the entity number as the primary key. Each record includes at least the following fields: account set, terminal key fingerprint set, session credential set, connection identifier set, first appearance time, last confirmation time, binding status, binding confidence level, binding basis entries, reason code set, and set truncation flag. The binding status has values ​​of normal, pending confirmation, suspected drift, and isolated. The binding confidence level ranges from 0 to 100. The entity number is generated by binning and incrementing according to the running session identifier, or by combining the tenant identifier and the incrementing sequence number. The first appearance time is taken from the unified base time when the entity number was created, and the last confirmation time is taken from the most recent strong clue hit with good time quality. The level is no lower than the unified reference time of the medium; the binding basis items adopt structured records, including at least the fields of trigger event number, trigger clue type, trigger clue value summary, trigger time, source type, source identifier, source trust level, time quality level, de-identification method mark, reason code, etc.; the reason code takes the value of an enumerated value and registers the code table version number. The code table version number is bound to the mapping version or threshold version. The reason code includes at least the following: field not reported, field invalid, parsing failure, de-identification cannot be compared, summary caliber inconsistent, conflict adjudication triggered, shared account triggered, capacity truncation triggered, isolation upgrade triggered, etc., which are used to verify the main aggregated link during audit follow-up visits; The subject binding parameter group values ​​are taken from the subject binding parameter group in the threshold caliber table. The parameter group includes at least the account aggregation window, session activity window, binding confidence threshold, rollback threshold, sharing threshold, drift reduction threshold, drift number threshold, key field judgment item, subject set capacity limit, summary length parameter, and temporary subject strength limit parameter. The account aggregation window value is 10 minutes to 60 minutes, for example, 30 minutes; the session activity window value is 30 minutes to 4 hours, for example, 2 hours; the binding confidence threshold value is 50 to 90, for example, 70; the rollback threshold value is 60 to 95, for example, 80; the sharing threshold value is 2 to 10, for example, 3; the drift reduction threshold value is 10 to 50, for example, 30; and the drift number threshold value is 1 to 5, for example, 2. The above values ​​are registered in the threshold caliber table with reference to the balance between business continuity constraints, the cost of mishandling, and the risk of missed detection. The key field determination item is used to determine the unified set of fields for determining key fingerprint conflicts on the terminal. The unified field names are determined by the mapping version. The key field determination item includes at least the device certificate digest, trusted execution environment mark, platform proof digest, and hardware digest. When a key field is missing, marked as desensitized and uncomparable, or the missing reason code indicates that it cannot be used for strong clues, only weak clues are allowed to be formed and the confidence level is updated according to the reduction caliber. The digest length parameter is used to constrain the fixed length of the clue value digest, with a value of 32 or 64 hexadecimal characters. The clue index key includes at least the clue type, clue value digest, and desensitization method mark. The subject set capacity limit is used to constrain the maximum number of entries to be retained in the account set, fingerprint set, credential set, and connection identifier set. The capacity limit is 10 to 500, for example, 100. When the capacity limit is exceeded, the most recent N entries are retained according to the most recent confirmation time, with N being 10 to 500, for example, 100, and the capacity truncation trigger reason code and the set digests before and after truncation are written. The temporary subject strength limit parameter is set to weak, which is used to restrict subjects with unconverged conflicts from entering the strong alignment path. The subject localization adopts a deterministic matching rule that prioritizes strong clues. For each unified event record, it prioritizes checking whether the session credential summary and connection identifier summary exist and are not marked as uncomparable due to desensitization. If the conditions are met, it retrieves the subject number in the ledger clue index according to the clue type and clue value summary. The clue index key includes at least the fields of clue type, clue value summary, and desensitization method mark. When the clue value summaries are the same but the desensitization method marks are different, or the original field mapping summary shows inconsistent generation standards, the corresponding index is bucketed and isolated, and a reason code for the inconsistency of summary standards is written to avoid erroneous merging caused by summary collisions or differences in standards. When a unique subject number is matched and the binding status is not isolated, the trigger event number and clue information are written into the binding basis entry, the last confirmation time is updated, and then... The consistency rule appends the account identifier digest and the terminal key fingerprint digest to the set; when the session credential digest and connection identifier digest are not matched, the account is located by the account identifier digest, and the subject number that meets the last confirmation time constraint is searched in the account aggregation window; when a unique subject number is matched, the same basis writing and set update are performed; when multiple subject numbers are matched, the conflict resolution is initiated, and subject numbers that are completely consistent in the key field judgment item of the terminal key fingerprint are selected in order of deterministic priority, followed by subject numbers that are consistent in the access gateway clue and have the latest last confirmation time; if a unique determination is still not possible, a temporary subject number is created and the binding status is set to pending confirmation, while the conflict resolution trigger reason code and the candidate subject number list are recorded, and the upper limit of the alignment strength of the temporary subject number is set to weak. Consistency rules are used to trigger set merging and confidence level updates. Set merging is triggered when one of three strong consistency conditions—account consistency, terminal key fingerprint consistency, or session credential consistency—is met. Set writing uses a deduplication appending method and does not overwrite existing entries. The confidence update parameter group is taken from the threshold table and includes at least the following fields: bonus items, deduction items, single-event bonus cap, total score cap, low-confidence reduction coefficient, springboard reduction coefficient, and reduction rounding rules. Bonus items use a segmented deterministic approach; for example, 20 points are added when the same event carries both account identifier digest and session credential digest, and 15 points are added when it carries one of the following from the strong terminal clue type enumeration: device certificate digest, trusted execution environment marker, or platform proof digest. Points are awarded as follows: 5 points are added when the access gateway clue matches the historical data; the maximum score for a single event is between 10 and 40 points, for example, 30 points; the total score is capped at 100 points, and the above values ​​are determined with reference to the risk of erroneous merging and the constraint of single event elevation; when a time anomaly code, a low time quality level, or a low source trust level occurs, the points are reduced by a low trust factor, which ranges from 0.2 to 0.8, for example, 0.5, and is rounded down according to the reduction and rounding rules; when in a bastion host or jump server environment, the jump server reduction factor is applied, which ranges from 0.1 to 0.6, for example, 0.3, and is rounded down according to the reduction and rounding rules, and the above coefficient values ​​are determined with reference to the subject confusion risk of the jump server link; Conflict rules are used to mark drift and trigger point deductions. Conflict triggers include at least the following: the session credential digest is consistent and the terminal's key fingerprint conflicts in the key field judgment item; the account is consistent and the number of times the terminal's key fingerprint changes within the session activity window exceeds the drift number threshold. When a conflict occurs, the binding status is set to "suspected drift," and the confidence level is reduced according to the point deduction item, for example, deducting 30 points but not lower than 0 points. At the same time, a drift basis entry is written, which includes at least the conflict field type, conflict event number sequence, conflict occurrence time sequence, and conflict reason code. When the binding status is already "suspected drift" and a conflict occurs again, it enters the upgrade branch. The binding status is set to "isolated," and the isolation upgrade trigger reason code is recorded. The isolation reason code can include session credential reuse conflict, high-frequency change of key fingerprint, cross-region jump conflict, etc. The isolated subject number is still output as a candidate subject number, and its alignment strength upper limit is set to "weak." The upper limit of the handling level is constrained by the handling threshold parameter group. The point deduction item, drift number threshold, and session activity window value are determined with reference to the corresponding parameter items in the threshold caliber table. To cover typical projects, the main body is bound to a shared account branch and a bastion host branch. The shared account branch session activity window counts the number of duplicate key fingerprints of the same account corresponding to the terminal. When the number exceeds the shared threshold, the binding status of the account's associated main number is set to pending confirmation and written to the shared account trigger reason code. At the same time, the upper limit of the alignment strength of subsequent high-sensitivity operations is set to weak to avoid directly entering the strong handling path. The bastion host branch detects bastion host nodes based on the unified event record access path summary or jump board mark. The relevant fields include at least the path node identifier, node type mark, upstream and downstream host identifiers, etc. When a bastion host node is detected, the terminal key fingerprint is recorded in a dual-track manner, that is, the fingerprint on the bastion host side and the fingerprint on the downstream target host side are recorded, with the fingerprint on the downstream target host side taking priority. When the fingerprint on the downstream target host side is missing, the fingerprint on the bastion host side is allowed to be merged. The confidence level is updated according to the jump board reduction coefficient. The value of the jump board reduction coefficient is set with reference to the risk of erroneous merging and traceability requirements in the jump board environment. The jump board environment trigger reason code is written. The output consists of incremental update records of the subject-bound ledger, a candidate set of subject numbers, and write-back candidate records. Incremental update records include at least the subject number, change type, binding status before and after the change, confidence level before and after the change, change set summary, trigger event number, reason code, alignment strength upper limit flag, and parameter reference summary, serving as audit playback entries. The subject number candidate set outputs 0, 1, or more subject numbers and corresponding confidence levels for each unified event record; when multiple candidates exist, it also outputs the conflict reason code and candidate sorting criteria. Write-back candidate records include at least the shared threshold, drift reduction threshold, drift count threshold, key field judgment item, summary length parameter, and capacity upper limit parameter, along with triggering criteria, used to generate a verifiable threshold adjustment candidate list and archive it with evidence.

[0021] S4: Establish a session evidence package based on the subject number and the session window, associate multi-source events according to strong and weak alignment rules, generate an evidence index, and register conflict entries. The specific implementation is as follows: After the entity binding ledger outputs the candidate set of entity numbers, it enters the session evidence package generation and evidence alignment process. Based on the entity number and the session window, the event sequence is merged and unified. The evidence index table solidifies the alignment strength, source credibility level, and time quality level constraints of the evidence entries. The upper limit of the alignment strength adopts the subject binding process caliber. The upper limit of the alignment strength is weak when one of the following situations exists: unauthorized source, desensitization and incomparability, inconsistent summary caliber, time abnormal code, low time quality level, low source credibility level, temporary entity number, or isolated entity number. Otherwise, the upper limit of the alignment strength is strong. The session window starts at a unified reference time based on the authentication success event. The authentication success event is identified by an event type enumeration code, which is merged from the mapping version and stored together with the code table version number. If no authentication success event is found, a temporary starting point is determined by the first access event and marked as "no authentication starting point." The session window parameter group comes from the threshold caliber table and includes at least the initial window duration, sliding renewal duration, maximum session duration, renewal trigger condition, and the upper limit of allowed levels for "no authentication starting point." The source type and applicable scenario labels are registered in the threshold caliber table. The initial window duration ranges from 30 minutes to 4 hours, for example, 2 hours. The sliding renewal duration... The value range is from 10 minutes to 60 minutes, for example, 30 minutes; the maximum session duration range is from 2 hours to 12 hours, for example, 8 hours. The above ranges and values ​​are formed with reference to the token validity period policy and the office session statistics baseline; the renewal trigger condition is the occurrence of an access event within the session window, and the renewal rule is to extend the renewal duration backward from the unified reference time of the last access event as the anchor point, without exceeding the maximum session duration. When the maximum session duration is reached, the session is truncated and a new session window is opened; the session number is generated by combining the running session identifier, the subject number, and the unified reference time of the session window start point, and is used to distinguish the evidence archiving units of the same subject in different session windows; The alignment rule parameter group takes values ​​from the alignment rule parameter group in the threshold caliber table, including at least the alignment window parameter configured by event type, the alignment window expansion coefficient parameter, strong consistency thread enumeration, weak consistency thread enumeration, chain write threshold item, and weak alignment write threshold item. The alignment window is configured by event type. The authentication alignment window ranges from 60 seconds to 300 seconds, for example, 120 seconds; the access alignment window ranges from 120 seconds to 600 seconds, for example, 300 seconds; the audit alignment window ranges from 300 seconds to 1800 seconds, for example, 600 seconds; and the traffic alignment window ranges from 120 seconds to 900 seconds, for example, 300 seconds. The alignment window is marked as having a source type of "on-site baseline" in the threshold caliber table and its formation period and statistical caliber are registered. The alignment window expansion coefficient ranges from 1.5 to 3, for example, 2. When the unified event record has a time anomaly code or a low time quality level, the alignment window is enlarged by the expansion coefficient, and the alignment strength value of the entry is constrained according to the upper limit of the alignment strength caliber. Strong alignment falls within the alignment window and the main clue is strong. Strong alignment means that the main clue is consistent with any one of the following: session credential digest consistency, connection identifier digest consistency, terminal key fingerprint digest consistency, and account identifier digest consistency. Weak alignment falls within the alignment window and the weak clue is consistent. Weak clue consistency means that the access gateway clue consistency, address network segment consistency, and application identifier clue consistency. Alignment determination is performed in the session window according to the base time order. First, the main body and session are associated according to the strong alignment rule, and then the context is supplemented according to the weak alignment rule. The critical chain index is written to the execution chain writing threshold item. When a weak alignment entry is written to the critical chain index, it must also meet the weak alignment writing threshold item. The weak alignment writing threshold item must at least constrain the source trust level to be no less than medium and the time quality level to be no less than medium. If the threshold is not met, the entry is written to the supplementary area index and marked with a reference reason code. The session evidence package is generated by merging events within a session window according to a unified event sequence. Fixed fields include at least the running session identifier, mapping version number, threshold version number, subject number, session number, session window start and end, no authentication start marker, authentication start event index, evidence index table, critical chain index set, conflict entry table, missing entry table, supplementary area index, and integrity verification digest. The evidence index table is an in-session entry-based index structure. Each entry includes at least the evidence entry number, evidence type, unified base time, alignment strength, alignment strength upper limit marker, associated subject number, associated session number, source type, source identifier, source trust level, time quality level, reason code, and digest field. The digest field is the minimum value of the unified event record. Auditable fields include at least the following: account summary, terminal key fingerprint summary, session credential summary, connection identifier summary, resource summary, event type enumeration, anonymization method marker, and missing reason code. Evidence entry numbers are generated incrementally within the session based on the main sequence number segment. When an entry fails to meet the chain writing threshold or is late, it is written to the supplementary area index. Supplementary area evidence entry numbers are generated incrementally based on the supplementary sequence number segment, recording fields such as anchor evidence entry number, number of seconds late, and reference reason code, without changing the main sequence number segment's order of reference. Supplementary area inclusion conditions include at least the following: lateness exceeding the out-of-order buffer window but not exceeding the maximum delay threshold; alignment strength upper limit value being weak and not meeting the weak alignment writing threshold; and source trust level value being low and only reference writing allowed. The critical chain index set is used to extract high-value evidence from a unified event to form an auditable chain. The chain screening threshold is fixed by a threshold caliber table and configured according to the evidence type. The mandatory chain condition for a critical access chain is a resource sensitivity greater than or equal to 4 or the operation semantics falling into the high-sensitivity operation semantic set. The high-sensitivity operation semantic set consists of enumerated items such as export, authorization, privilege escalation, and deletion, and is merged by the mapping version. When the resource sensitivity field is missing, the resource sensitivity is set to medium sensitivity according to the resource type mapping table and the missing reason code is marked. The resource type mapping table serves as an appendix to the mapping version. Register version number; the mandatory entry condition for key audit chains is that the event type enumeration code falls into enumeration items such as privilege escalation attempt, credential access, persistent trace, etc.; when the audit event lacks account or session clues, it is only entered into the chain when weak alignment is established and the source trust level is high, and the rest are written into the supplementary area index; the mandatory entry condition for key traffic chains is that the abnormal feature label falls into enumeration items such as lateral scan or suspected tunnel, and before entering the chain, it is required that there is at least one access event in the traffic alignment window and the session window that meets the weak clue consistency, so as to avoid bypass noise entering the chain independently; The evidence compression parameter group is a threshold-based table, which includes parameters such as the summary extraction period, the maximum number of evidence items per session, the summary retention strategy, and the evidence truncation priority table. The source type is marked as a strategy configuration type and the applicable scenario label in the threshold-based table. The summary extraction period ranges from 1 minute to 30 minutes, for example, 5 minutes, which is used to retain the most recent summary for non-mandatory chain events according to the same type of event. The maximum number of evidence items per session ranges from 500 to 3000, for example, 2000. When the maximum number of items is exceeded, pruning is performed according to the evidence truncation priority table. The priority order includes at least the authentication starting event index, key access chain, key audit chain, key traffic chain, evidence associated with conflict items, evidence associated with missing items, and summary area items. The capacity truncation reason code and the statistical summary before and after truncation are marked. The priority order and the maximum number of items are fixed with the threshold version. Conflict entries are registered synchronously during evidence alignment. The conflict determination parameter set is taken from the threshold caliber table and includes at least the regional boundary caliber, short time window parameters, connection reuse determination caliber, and multi-candidate non-convergence determination caliber. The regional boundary caliber is provided by the regional mapping table or geographic partition table and is registered as a version number in the threshold version appendix. The short time window ranges from 10 seconds to 300 seconds, for example, 60 seconds. Conflict types include at least account consistency terminal conflict, session credential consistency network location cross-regional jump, connection identifier reuse conflict, and multi-subject candidate non-convergence conflict. Account consistency terminal conflict refers to a situation where the account digest is consistent within the session window but the terminal's key fingerprint is inconsistent in the key field determination item, and the relevant evidence entries are strongly aligned. The degree is strong; the session credential consistency network location cross-region jump refers to the session credential digest being consistent and the network location clue crossing the regional boundary caliber, while lacking a secondary verification event index. The secondary verification event is determined by the event type enumeration code as the secondary verification success or failure and is merged by the mapping version; the connection identifier reuse conflict refers to the connection identifier digest being associated with different subject numbers within a short time window and the terminal key fingerprint conflict; the multi-subject candidate non-converged conflict refers to the same evidence entry corresponding to multiple subject candidates and the candidate sorting criteria cannot converge to a uniqueness; the conflict entry table should at least include the conflict number, conflict type, set of involved evidence entry numbers, involved clue type, set of involved source identifiers, conflict time interval, reason code and other fields; Missing entries are registered according to the missing judgment parameter group, which is fixed in the threshold caliber table and includes at least the maximum delay threshold, the minimum set of key source fields list, and the missing reason code caliber. The maximum delay threshold ranges from 300 seconds to 3600 seconds, for example, 900 seconds. When a key source event is missing or its arrival delay exceeds the maximum delay threshold, it is written into the missing entry table. The minimum set of key source fields is determined by the data source list and the mapping version and includes at least the source identifier, unified base time, event type enumeration, account summary or session credential summary, and is registered in the form of a field list. The missing entry table includes at least the missing type, missing source type, expected field set summary, missing time interval, and missing reason code, and the affected entries are marked with an incomplete evidence mark in the evidence index table. When there is a no authentication start point mark, the evidence package is written with the no authentication start point allowable level upper limit parameter. The allowable level upper limit parameter is the allowable level upper limit item of the handling threshold parameter group. For example, direct credential revocation is not allowed, and only low-impact handling levels such as prompt records, secondary verification suggestions, or session downgrading are allowed. When the session evidence package is output, an integrity verification digest is generated. The integrity verification digest includes at least the following fields: evidence index table digest, critical chain index set digest, conflict entry table digest, and missing entry table digest. The digest string is 32 or 64 hexadecimal characters long and is stored together with the mapping version number and threshold version number. The session evidence package, evidence index table, supplementary area index and integrity verification digest are written to the evidence storage queue for adjudication reference.

[0022] S5: Within the session window, make tiered decisions based on triggering conditions, issue action orders, record execution confirmations and write-back records, and seal the evidence package. The specific implementation is as follows: The session evidence package undergoes tiered adjudication and write-back. Within the same session window, activities such as trigger judgment, evidence threshold verification, disposal issuance, confirmation, and write-back update are executed separately, and the adjudication process is recorded in a structured manner for replay processing. The input must include at least the following fields: session evidence package, binding status and binding confidence level of the corresponding subject number in the subject binding ledger, trigger condition table, disposal level table, and write-back rule table. It references the threshold version number and disposal timing parameter group of the running session metadata data package. The threshold and timing parameters are bound to the threshold version number according to the threshold caliber table. The trigger condition table takes the trigger condition parameter group registered in the threshold caliber table. Trigger conditions are expressed as deterministic rules and their priority order is registered in an integer sequence field. They include at least fields such as subject drift trigger, sensitive operation trigger, abnormal link trigger, and evidence conflict trigger. Subject drift trigger is based on a binding status of suspected drift and a decrease in binding confidence level exceeding the drift reduction threshold. The drift reduction threshold ranges from 10 to 50 points, for example, 30 points, referencing the distinction between shared account erroneous merging and actual drift. Sensitive operation trigger is based on the occurrence of a resource sensitivity greater than or equal to the high-sensitivity threshold in a critical access chain and the operation semantics falling into the high-sensitivity operation semantic set. The high-sensitivity threshold ranges from 3 to 5, for example, 4. The high-sensitivity operation semantic set includes values ​​such as export, authorization, privilege escalation, etc. Deleting enumerated items and merging them by mapping version; when resource sensitivity is missing, filling in the missing items according to the resource type mapping table and marking the missing reason code; abnormal link triggering is based on the appearance of abnormal tags such as lateral scanning or suspected tunnel in the traffic chain, and the evidence item alignment strength is strong and meets the upper limit of alignment strength of strong, while requiring the source trust level to be no less than medium; evidence conflict triggering is based on the number of conflict items reaching the conflict count threshold and the conflict type hitting the strong conflict set, with the conflict count threshold ranging from 1 to 5 items, for example 2 items, and the strong conflict set including at least enumerated items such as account consistency terminal conflict, session credential consistency network location cross-region jump; when multiple triggers are concurrent, they enter the adjudication path in ascending order of priority number, and the triggered hit item and priority number are written into the trigger segment field of the adjudication record; The disposal level table references the disposal threshold parameter group registered in the threshold caliber table. The disposal level is set according to the principle of minimum impact, with values ​​of six levels: prompt record, secondary verification suggestion, session demotion, sensitive operation interception, credential revocation, and temporary account freeze. The disposal level table includes at least the following fields: level code, evidence threshold item set, source category threshold, alignment strength threshold, subject status threshold, subject confidence threshold, scope upper limit, validity period parameter reference, rollback condition set, allowed level upper limit, and demotion chain. The source category threshold ranges from 2 to 4 categories. For example, credential revocation requires at least 2 strong alignment evidences from different sources to be established simultaneously, and the binding status to be suspected drift or isolated, while the binding confidence level is lower than the binding confidence threshold. The confidence threshold for binding is set between 50 and 90 points, for example, 70 points, based on the balance constraint between the cost of false blocking and the risk of false negatives; the temporary account freeze threshold is set when the credential revocation has been confirmed and a new successful authentication event occurs within the freeze observation window and the subject drift is triggered again, with the freeze observation window ranging from 5 to 60 minutes, for example, 15 minutes, based on the retry rhythm after revocation and the acceptable interruption duration of the business; the session demotion threshold is set when the sensitive operation is triggered and the evidence conflict is triggered, and the existence of missing entries is allowed; the sensitive operation interception threshold is set when the sensitive operation is triggered and at least one abnormal link strong alignment evidence is established, and the upper limit of the scope is set to the high-sensitivity resource path or the semantic set of the operation; The adjudication process is conducted within the session window using a state machine. The state machine includes at least the following states: pending trigger, evidence verification, disposition issuance, execution confirmation, write-back update, and end of archiving. In the pending trigger state, the session evidence package is updated incrementally, and the process transitions to the evidence verification state when the conditions are met. In the evidence verification state, evidence thresholds are verified sequentially from low to high according to the disposition level table, and the disposition level and hit path are determined according to the rule of stopping once the threshold is met. In the disposition issuance state, a disposition action chain is generated and written to the disposition queue. The disposition action chain includes at least the following fields: action number, action type, action target, scope, effective time, validity period, rollback conditions, basis evidence index set, execution surface identifier, running session identifier, and version number reference summary. The granularity of the action target varies with the handling level. The prompt record targets the session number; secondary verification suggestions target a combination of the subject number and session number; session demotion targets the session credential digest; sensitive operation interception targets a combination of the resource path digest and operation semantics; credential revocation targets the session credential digest or ticket digest; and temporary account freezing targets the account digest. The scope and target granularity are consistent and constrained by the scope upper limit field of the handling level table. The handling validity period parameter group takes the validity period parameter group registered in the threshold caliber table, and the validity period for session demotion ranges from 5 minutes. The validity period for sensitive operation interception ranges from 1 minute to 30 minutes, for example, 10 minutes. The validity period for secondary verification is suggested to range from 5 minutes to 1 hour, for example, 15 minutes. The above values ​​are set with reference to the attack duration window and business blocking cost constraints. The rollback condition set is the rollback condition caliber registered in the threshold caliber table. Rollback is triggered when secondary verification is completed and strongly aligned with the session credentials. Session demotion is triggered when the bound confidence level rises back to the rollback threshold and there are no new enhanced conflict entries. The rollback threshold ranges from 60 to 95 points, for example, 80 points. The execution confirmation status confirms each action in the action chain. The confirmation timeout window is set to the confirmation timeout parameter registered in the threshold table, ranging from 5 to 30 seconds (e.g., 10 seconds). The timeout is set with reference to the upper bound of the execution surface round-trip delay and the upper bound of the queue queuing delay. If the timeout occurs, the action is transferred to the unconfirmed branch. The confirmation receipt includes at least the action number, execution surface identifier, confirmation status enumeration, confirmation timestamp, failure reason code, and execution surface feedback summary. The unconfirmed branch marks the action as unconfirmed and records the unconfirmed reason code. The reason code includes at least the enumeration items such as execution surface no response, execution surface rejection, insufficient execution surface permissions, and network unreachable. The action is then downgraded and reissued according to the degradation chain. The degradation chain is defined as follows: voucher revocation downgrades to sensitive operation interception, sensitive... Operation interception is downgraded to session demotion, and session demotion is downgraded to secondary verification recommendation; the execution plane reliability parameter group constrains the handling intensity of repeated unconfirmed cases, with the threshold value for the number of repeated unconfirmed cases ranging from 2 to 10 times, for example, 3 times. Execution planes exceeding the threshold are marked as low reliability and written into the write-back update record. Subsequently, strong handling is restricted for this execution plane, and the threshold value of the number of source categories is increased. At the same time, the threshold adjustment reason code and recovery conditions are written; the execution plane trust downgrade item quantifies the propagation delay and execution uncertainty impact. The execution plane trust level can be selected as high, medium, or low. The downgrade rule value is the execution plane trust downgrade item registered in the threshold caliber table, for example, downgrading from high to medium or from medium to low. The downgrade reason code and recovery conditions are written into the write-back record; The write-back update status is performed according to the write-back rule table, which takes the write-back rule parameter group registered in the threshold caliber table. The write-back targets include at least the subject binding ledger, session evidence package, execution plane reliability record, execution plane trust level record, and threshold candidate area. When the secondary verification completion event is written into the session evidence package and is strongly aligned with the session credential, the subject binding confidence level is increased by the confidence increment and the binding status is changed to normal. The confidence increment ranges from 1 to 30 points, for example, 10 points. At the same time, the verification completion evidence index is written into the session evidence package. When the same credential digest associated access event is still observed after the credential revocation confirmation execution, a propagation delay flag is written and the corresponding execution is reduced according to the execution plane trust downgrade item. The credibility level is increased, and the threshold parameter value for the number of source categories for subsequent strong actions is raised. When manually reviewing and annotating false alarms, the weak clue types that trigger false alarms are written into the weak clue blacklist and a threshold candidate change record is generated. The threshold candidate change record includes at least the following fields: candidate parameter name, candidate value, trigger basis evidence index set, suggested scope of application, rollback conditions, code table version number reference summary, etc. The candidate change is only recorded and does not take effect in the current running session. The write-back update also solidifies the adjudication record. The adjudication record includes at least the following fields: adjudication number, session number, trigger type set, trigger priority sequence number, evidence threshold hit path, selected action level, action action number set, execution confirmation result set, and write-back item number set. The sealing process is triggered when a session ends naturally, a decision is revoked, or a session is truncated and a new window is opened. The session evidence package is written to long-term storage, and the sealing timestamp and sealing reason code are recorded. The sealed object includes at least the following fields: running session identifier, mapping version number, threshold version number, evidence index summary, adjudication record summary, action summary, write-back record summary, missing item summary, and integrity verification summary. The sealing pruning parameters are taken from the sealing pruning parameter group registered in the threshold caliber table, and include at least the single session evidence item limit parameter and the maximum number of bytes in the sealed package parameter. The maximum number of records can be set from 500 to 3000, for example, 2000, based on the criteria for single evidence record usage and acceptable playback latency. The maximum number of bytes in the archive can be set from 5 megabytes to 200 megabytes, for example, 50 megabytes, based on long-term storage costs and retrieval throughput budget. When the archive pruning parameter is exceeded, the key chain and adjudication-related evidence entries are retained according to the evidence truncation priority table, and the remaining entries are moved to the archive area while retaining index references. The archived content carries the running session identifier, mapping version number, and threshold version number for review reference.

[0023] In this embodiment, the solution first employs unified identity authentication and office gateway access, with terminal agents reporting host audits, core gateways outputting access logs, and bypass mirrors outputting traffic observations. Upon startup, a running session is established and field mapping versions and threshold versions are frozen. A data source list and source trust level are loaded, and a running session identifier is generated as the end-to-end context key. Subsequently, inbound authentication, application access, host audits, and traffic events are received. Field and time normalization are performed according to the mapping versions, a unified baseline time is generated, and time quality levels are marked. High-quality events enter the main sequence, while late events enter the supplementary area. An out-of-order buffer window, for example, is set to 120 seconds. After the unified event sequence is output, the entity binding ledger is maintained based on the account summary, terminal key fingerprint summary, session credential summary, and connection identifier summary. Prioritize locating the subject number based on strong clues and update the confidence level, for example, a threshold of 70 points; when session credentials are consistent but terminal fingerprints conflict, mark suspected drift and deduct; then construct a session evidence package starting from successful authentication, for example, an initial window of 2 hours, a renewal window of 30 minutes, and a maximum of 8 hours, and complete strong and weak alignment according to authentication alignment window of 120 seconds, access alignment window of 300 seconds, audit alignment window of 600 seconds, and traffic alignment window of 300 seconds, generate evidence index and register conflict entries; if a high-sensitivity export occurs in the same session and hits abnormal tunnel traffic and forms strong alignment, then make a graded adjudication according to the triggering conditions and evidence threshold, issue session demotion or credential revocation, record execution confirmation and write-back update, and write the evidence package and adjudication record to long-term storage according to the sealed and trimmed parameter group.

[0024] Example 2: Figure 2 This invention presents a network security protection system that integrates identity authentication and data analysis, comprising: Run Session and Calibration Freeze Module: At the start of the run, load the field caliber mapping table, threshold caliber table and data source list, generate the run session identifier and freeze the mapping version, threshold version and access boundary, form session meta data packet and write it to the audit storage so that subsequent processing modules can refer to the same context caliber. Event Access Specification and Out-of-Order Buffering Module: Receives authentication, access, host auditing and traffic observation events, completes field unification and cleaning according to the mapping version, completes time standardization and marks time quality level according to the unified base time, performs out-of-order buffering and late supplementation processing, and outputs unified event records and unified event sequences. Main entity binding ledger maintenance module: Maintains the main entity binding ledger based on account summary, terminal key fingerprint summary, session credential summary and connection identifier summary, determines the main entity number according to strong clues, merges bindings and updates the confidence level according to consistency rules, marks drift or isolation according to conflict rules, and outputs the candidate set of main entity numbers and incremental update records; Session evidence package construction and evidence alignment module: Merges multi-source events by subject number and session window, generates evidence index and critical chain index according to strong alignment and weak alignment rules, registers conflicting and missing entries, and outputs session evidence package and integrity verification summary; Tiered adjudication and write-back / sealing module: Based on the trigger condition table and the handling level table, it completes tiered adjudication and issues handling actions, records execution confirmation and write-back updates, and seals evidence packages, adjudication records and write-back records according to the sealing and trimming parameter groups.

[0025] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0026] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0027] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0028] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0029] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0030] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0031] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0032] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0033] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A network security protection method integrating identity authentication and data analysis, characterized in that, include: S1: Freeze the field mapping version and threshold version, generate the running session identifier, and register the data source list; S2: Receive authentication, access, host auditing, and traffic observation events, unify fields and timestamps according to the mapping version, mark time quality level, and output them in a unified time order after out-of-order buffering; S3: Establish a subject binding ledger based on account, terminal key fingerprint, session credential digest, and connection identifier digest; merge bindings according to consistency rules; and mark drifts and adjust confidence levels according to conflict rules. S4: Establish a session evidence package based on the subject number and the session window, associate multi-source events according to strong and weak alignment rules, generate an evidence index and register conflict entries; S5: Within the session window, make tiered decisions based on triggering conditions, issue action orders, record execution confirmations and write-back records, and seal the evidence package.

2. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, Freeze field mapping versions and threshold versions, generate running session identifiers, and register a list of data sources, including: At startup, a running session is established, the mapping table, threshold table and source list are loaded to generate immutable metadata and perform digest verification; Freeze versions and access boundaries; unauthorized sources or inconsistent statements will be subject to isolation audit. Thresholds are configured according to strategy, on-site baselines, and operational statistics are hierarchically categorized, and changes are written to the candidate area for release verification. Initialize the resource budget and load reduction parameter set.

3. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, Receive authentication, access, host auditing, and traffic observation events, and standardize fields and timestamps according to the mapped version, including: Authorization verification is performed on events from authentication sources, access sources, host audit sources, and traffic observation sources; unauthorized events are isolated for auditing. For authorized events, perform field mapping and cleaning according to the mapping version. Multi-source candidate fields are selected according to field priority and the mapping summary is retained. Cleaning anomalies is written with anomaly codes and missing reason codes. A unique event number is generated and written with desensitization tags and alignment clue strength limits.

4. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, The time quality level is marked, and after being buffered out of order, it is output in a uniform time order, including: A unified reference time is determined by the event occurrence time, the source timestamp, and the receiving timestamp, and a time quality level is assigned. When the difference exceeds the upper limit of time deviation, a time anomaly code is written and the clue strength is reduced. Output is sorted according to the out-of-order buffer window. When the unified base time is the same, the receiving timestamp and event number are used as the secondary sorting key. Late events are written to the supplementary area that is only appended. When the number of events per unit time exceeds the throughput limit, a load reduction record is generated according to the retention priority and sampling interval.

5. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, A principal binding ledger is established based on account, terminal key fingerprint, session credential digest, and connection identifier digest, including: The main ledger is established based on account summary, terminal fingerprint summary, credential summary, and connection summary, and the main number is generated according to the division of labor of the running session; Ledger entry set, initial date, final confirmation date, status, confidence and basis entries; The clue index key consists of the clue type, clue summary, and desensitization tag. When the summary scope is inconsistent, the clues are isolated by bucket and the reason code is written. When the set exceeds the limit, it is truncated according to the most recent confirmation time and a truncated summary is recorded.

6. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, Merge bindings according to consistency rules, mark drifts and adjust confidence levels according to conflict rules, including: When making a consistent determination, the set is deduplicated and appended, and the confidence level is updated according to the scoring criteria. The single event scoring cap, total score cap, and rounding rules are constrained by the parameter group. When determining a conflict, write the drift criteria and deduct points. Repeated conflicts will result in isolation upgrades and the temporary main body strength limit will be weak. Shared accounts and springboard paths use dual-track fingerprints and update confidence levels according to a reduction factor, while generating candidate write-back items.

7. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, Create a session evidence package based on the subject number and the session window, including: Successful authentication events are used to determine the start of the session window. If a successful authentication event is missing, the first access event is used to determine a temporary start and a "no authentication start" flag is recorded. The session number is generated by combining the running session identifier, the subject number, and the window start time; The session evidence package records the mapping version number, threshold version number, window start and end, start event index, supplementary area index, and integrity verification summary.

8. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, Based on strong and weak alignment rules, multi-source events are correlated, an evidence index is generated, and conflict entries are registered, including: Configure alignment windows and expansion coefficients according to event type; When there are time anomalies, low source credibility level, incomparable desensitization, inconsistent abstract scope, or the main body is temporary or isolated, the upper limit of alignment strength is set to weak. Evidence index entries record alignment strength, source credibility level, time quality level, and reason code. Conflicting and missing entries are registered according to threshold parameter groups and pruned according to truncation priority.

9. The network security protection method integrating identity authentication and data analysis according to claim 1, characterized in that, Within the session window, tiered decisions are made based on triggering conditions, actions are issued, execution confirmations and write-back records are recorded, and evidence packages are sealed, including: Within the session window, validate the evidence threshold according to trigger priority to generate a chain of actions. The action setting confirmation timed out and was reissued according to the demotion chain; The disposal confirmation results will be written back to the subject confidence, execution surface reliability, and threshold candidate area; The evidence package is sealed according to the cutting parameters.

10. A network security protection system integrating identity authentication and data analysis, used to implement the network security protection method integrating identity authentication and data analysis as described in any one of claims 1-9, characterized in that, include: Run Session and Calibration Freeze Module: At the start of the run, load the field caliber mapping table, threshold caliber table and data source list, generate the run session identifier and freeze the mapping version, threshold version and access boundary, form session meta data packet and write it to the audit storage so that subsequent processing modules can refer to the same context caliber. Event Access Specification and Out-of-Order Buffering Module: Receives authentication, access, host auditing and traffic observation events, completes field unification and cleaning according to the mapping version, completes time standardization and marks time quality level according to the unified base time, performs out-of-order buffering and late supplementation processing, and outputs unified event records and unified event sequences. Main entity binding ledger maintenance module: Maintains the main entity binding ledger based on account summary, terminal key fingerprint summary, session credential summary and connection identifier summary, determines the main entity number according to strong clues, merges bindings and updates the confidence level according to consistency rules, marks drift or isolation according to conflict rules, and outputs the candidate set of main entity numbers and incremental update records; Session evidence package construction and evidence alignment module: Merges multi-source events by subject number and session window, generates evidence index and critical chain index according to strong alignment and weak alignment rules, registers conflicting and missing entries, and outputs session evidence package and integrity verification summary; Tiered adjudication and write-back / sealing module: Based on the trigger condition table and the handling level table, it completes tiered adjudication and issues handling actions, records execution confirmation and write-back updates, and seals evidence packages, adjudication records and write-back records according to the sealing and trimming parameter groups.

Images