IP context enhanced user entity identification method and system

Abstract

This invention relates to the field of network security technology and provides a method and system for IP context-enhanced user entity identification. The method includes the following steps: acquiring and normalizing reverse proxy access logs to obtain standardized access records; slicing by source IP and time window and performing quality filtering to obtain stable IP time slices; clustering within stable IP time slices according to passive traffic characteristics to obtain IP access context nodes; constructing a weighted bipartite graph of account-IP access context, including edge-weight co-occurrence counting, context reliability scoring, temporal continuity, and feature consistency; performing low-error merging pruning; performing connectivity component analysis on the pruned graph and calculating entity confidence, outputting high-confidence entities, medium-confidence candidate entities, and low-confidence entities to be observed. This invention eliminates the need for front-end injection or terminal probes, reducing erroneous merging caused by public IPs, NAT, and proxy exits, and improving the interpretability and engineering controllability of user entity identification.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, and in particular relates to a method and system for IP context-enhanced user entity identification. Background Technology

[0002] In scenarios such as internet services, network security risk control, identity resolution, and user behavior attribution, user behavior data generally presents many-to-many relationships between accounts, IP addresses, session identifiers, and device signals: a real natural person may have multiple accounts and access the system through different exits such as home networks, enterprise NAT, campus networks, and mobile networks; the same IP address may also be shared by multiple unrelated users, such as public Wi-Fi, carrier-grade NAT (CGNAT), proxy nodes, cloud service exits, or IDC gateways.

[0003] In the user entity resolution process, the industry typically models discrete identifiers such as accounts, IPs, device IDs, and cookies as graph nodes, establishes edges through co-occurrence relationships, and then aggregates nodes into candidate user entities using connected component analysis, community detection, or label propagation. For example, Google Security Operations' EntityContext Graph merges contexts by matching key-value pairs such as hostname, MAC address, user ID, and email across data sources to build a unified entity profile (see Google Cloud Chronicle documentation: https: / / docs.cloud.google.com / chronicle / docs / event-processing / entity-graph); security platforms such as ThreatNG also use graph theory entity resolution, treating IPs, usernames, and device IDs as nodes, and discovering highly interconnected account clusters through community detection (see https: / / www.threatngsecurity.com / glossary / graph-based-entity-resolution). In the field of risk control and linked account detection, platforms such as Dregs automatically construct identity graphs, using relationship types such as SHARED_IP and SAME_DEVICE as edge evidence to discover cross-account linked networks (see https: / / dregs.com / platform / identity-graph / ). Customer identity resolution systems such as Zeotap define "what kind of identifier matching is sufficient to merge two records" through Merge Rules, and use connected component algorithms to obtain user clusters under transitive closure. At the same time, they emphasize that they should start with high-confidence rules and require multi-identifier joints for weak signals such as devices / cookies (see https: / / composable-docs.zeotap.com / identity-resolution / merge-rules / ).

[0004] Under engineering constraints that only reverse proxy access logs can be obtained and front-end JavaScript cannot be injected or terminal probes can be deployed, existing solutions often degenerate into two typical implementations.

[0005] The first category is rule-based matching: for example, "establishing an association if multiple accounts appear under the same IP," or "considering the same account using multiple IPs as the same user," or setting a fixed threshold for co-occurrence times to directly connect edges. This type of method is simple to implement and highly interpretable, but in traffic environments where dynamic IPs, public exits, proxies / VPNs, and one-time access coexist, it is easy to mistakenly aggregate multiple natural persons into the same entity (false merging), or fail to establish effective connections between accounts of the same natural person in multiple network environments (missed merging). Over-resolution will fold multiple real identities into a single profile, causing risk signals to be averaged or suppressed, resulting in "missed detections at the entity structure level" rather than detection logic failure.

[0006] The second type is the direct account-IP bipartite graph method: This method uses the original IP as a stable node, normalizes the co-occurrence frequency as the edge weight, and then generates user entities through maximum weight pruning or connected component generation. This method ignores the fact that an IP may correspond to multiple access subjects within a specific time period. Once public IPs or highly mixed NAT exits are included in the graph structure, it can lead to an abnormal expansion of connected components, causing a large number of irrelevant accounts to be incorrectly connected.

[0007] The third category is solutions that rely on active device fingerprinting: These solutions identify devices using multi-dimensional browser signals such as Canvas, WebGL, and font lists. They have strong distinguishing capabilities in scenarios where active data collection is possible, but within the passive observation boundaries of reverse proxies, complete device fingerprints are unavailable. If weak signals such as User-Agent are forcibly used to replace strong fingerprints and directly as the aggregation basis, the stability and uniqueness are insufficient, and it is still impossible to distinguish between "stable private access environments" and "public shared exits". Summary of the Invention

[0008] The purpose of this invention is to provide an IP context-enhanced user entity recognition method and system, which aims to solve the problems mentioned in the background art.

[0009] This invention is implemented as follows: An IP context-enhanced user entity recognition method includes the following steps: Obtain the reverse proxy access logs and normalize them to obtain standardized access records; each standardized access record includes an account identifier, source IP, timestamp, and passive traffic characteristics; the passive traffic characteristics include at least one of request header characteristics, request path characteristics, and session characteristics; Standardized access records from the same source IP are time-sliced ​​according to the source IP and time window to obtain IP time slices; the IP time slices are quality-filtered, and IP time slices that meet preset quality conditions are retained as stable IP time slices; Within the stable IP time slice, standardized access records are clustered according to the passive traffic characteristics to obtain IP access context nodes and generate an IP access context node set. Based on the co-occurrence relationship between account identifiers and IP access context nodes in standardized access records, a weighted bipartite graph of account-IP access context is constructed. The edge weights of the weighted bipartite graph are determined based on co-occurrence count, context reliability score, temporal continuity, and feature consistency. The context reliability score is determined based on at least one of the stability, purity, sample support, and non-commonness of IP access context nodes. Perform low-error merging and pruning on the account-IP access context weighted bipartite graph to obtain the pruned weighted bipartite graph; Connectivity component analysis is performed on the pruned weighted bipartite graph to obtain candidate user entities; the entity credibility of the candidate user entities is calculated, and the user entity recognition result is output based on the entity credibility.

[0010] Furthermore, the normalization process includes: parsing at least one of the following features from the reverse proxy access log: account identifier, source IP, timestamp, User-Agent, cookie, session identifier, token, request path, and request header combination; performing irreversible hashing on the cookie and / or token; writing records that fail to be parsed into an isolation queue and incrementing the alarm count.

[0011] Furthermore, the time slice adopts a fixed window or a sliding window; under a fixed window, the start time of the IP time slice is obtained by rounding the time window length according to the timestamp, and the end time is the start time plus the time window length; under a sliding window, adjacent IP time slices partially overlap. The quality filtering method includes: calculating the quality assessment parameter Stab(seg) for IP time slices; Stab(seg) is obtained by weighting at least one of User-Agent consistency, token / session distribution purity, access path distribution consistency, and session continuity; if Stab(seg) is less than the stability threshold θ_stab, the corresponding IP time slice is marked as an unstable IP time slice and written into the audit table, without proceeding to the next step; if the number of records in the IP time slice is less than the minimum number of records n_min_seg, it is marked as a low sample and passed down to the downstream with reduced weight.

[0012] Furthermore, the passive traffic features on which the clustering is based include at least one of the following: User-Agent or User-Agent family hash, Accept-Language, Accept-Encoding, Sec-CH-UA, Cookie / session / token continuity, request path sequence, access frequency, adjacent request interval distribution, login interface and business interface access patterns, and request header combination features; the clustering adopts rule-based clustering and / or clustering based on feature vector similarity; when multiple clusters are formed within the same stable IP time slice, the same source IP in the same time slice is split into multiple IP access context nodes.

[0013] Furthermore, when constructing the account-IP access context weighted bipartite graph, no direct edges are established between the account identifier and the original IP string; only edges are established between the account identifier and the IP access context node. The edge table records at least one of the following: co-occurrence count, first occurrence time, last occurrence time, User-Agent set size, and path entropy. Existing edges are incrementally merged and the last occurrence time is updated. If a token conflict occurs within the same IP access context node for the same account, a token conflict flag is added to the edge table. The context reliability score R(c) is obtained by weighting stability S(c), purity P(c), sample support Supp(c), and non-publicness N(c). Among them, purity P(c) is determined based on the number of independent accounts connected to the IP access context node, sample support Supp(c) is determined based on the number of records in the IP access context node and the saturation threshold, and non-publicness N(c) is determined based on at least one of the following: the number of accounts connected per unit time, the number of User-Agent types, path dispersion, whether the ASN belongs to a cloud vendor, IDC, known VPN segment, and access rhythm. If R(c) is less than the reliability threshold θ_R, the corresponding IP access context node is marked as a low-reliability IP access context node. The edge weight w(a,c) is determined based on the original co-occurrence edge weight w_raw(a,c), the context reliability score R(c), the temporal continuity T(a,c), and the feature consistency F(a,c). Among them, w_raw(a,c) is obtained by normalizing the co-occurrence count of account a and IP access context node c; T(a,c) is determined based on the number of times account a accesses IP access context node c within the time interval and the interval between adjacent accesses; F(a,c) is determined based on the stability of the User-Agent, token, and path pattern used by account a within IP access context node c.

[0014] Furthermore, the low-error merging pruning includes: Low reliability context filtering: Remove or isolate IP access context nodes whose R(c) is less than the reliability threshold θ_R, whose number of connected accounts is greater than the account number threshold, whose token distribution is abnormal, or whose IPs are suspected of being automated and frequently accessing the context. Threshold pruning: retain edges that satisfy the following conditions: edge weight w(a,c) is greater than or equal to the edge weight threshold θ_w, co-occurrence count is greater than or equal to the minimum co-occurrence count n_min, and R(c) is greater than or equal to θ_R; Top-k pruning: For each account node, retain at most k edges in descending order of edge weight w(a,c), and each edge satisfies R(c) greater than or equal to θ_R; Maximum edge plus safe edge pruning: Based on Top-k pruning, additional edges that satisfy R(c) greater than or equal to the safety reliability threshold, co-occurrence count greater than or equal to the safety count threshold, and time continuity T(a,c) greater than or equal to the safe time threshold are retained; Accounts that did not retain any edges after pruning will be added to the list of isolated accounts.

[0015] Furthermore, the user entity identification result includes at least one of high-confidence entities, medium-confidence candidate entities, and low-confidence entities to be observed; the connected component analysis adopts disjoint-set data structure or breadth-first search; the entity confidence E(CC_i) is determined based on at least one of the following: the average edge weight of the edges in the candidate user entity, the average context reliability score of the IP access context node, time consistency, and size penalty; if E(CC_i) is greater than or equal to the high-confidence threshold θ_high, a high-confidence entity is output; if E(CC_i) is greater than or equal to the medium-confidence threshold θ_mid and less than θ_high, a medium-confidence candidate entity is output; if E(CC_i) is less than θ_mid or the proportion of low-reliability IP access context nodes exceeds the proportion threshold, a low-confidence entity to be observed is output.

[0016] Furthermore, the IP context-enhanced user entity recognition method also includes the following steps: Parameter adaptive feedback: Monitor at least one of the unstable IP time slice drop ratio and the maximum connected component size; if the unstable IP time slice drop ratio exceeds the drop ratio threshold or the maximum connected component size exceeds the component size threshold, increase the reliability threshold θ_R, decrease the k value in Top-k or shorten the time window length, and set the pruning mode of the next batch to strict mode.

[0017] Furthermore, the IP context-enhanced user entity recognition method also includes the following steps: Results Output and Evidence Tracing: Output structured records, which include at least one of the following: user entity identifier, account list, IP access context node list, entity confidence, evidence edge, main IP access context node, risk marker, creation time and update time; the evidence edge includes at least one of the following: edge weight, context reliability score and co-occurrence count.

[0018] Another object of the present invention is to provide an IP context-enhanced user entity recognition system for implementing the above-described IP context-enhanced user entity recognition method, comprising: The log access and normalization module is used to obtain reverse proxy access logs and normalize them to obtain standardized access records. Each standardized access record includes an account identifier, source IP, timestamp, and passive traffic characteristics. The passive traffic characteristics include at least one of request header characteristics, request path characteristics, and session characteristics. The IP time slice construction and quality filtering module is used to perform time slicing on standardized access records of the same source IP according to the source IP and time window to obtain IP time slices; and to perform quality filtering on the IP time slices, retaining IP time slices that meet preset quality conditions as stable IP time slices. The IP access context clustering module is used to cluster standardized access records according to the passive traffic characteristics within the stable IP time slice to obtain IP access context nodes and generate an IP access context node set. The context reliability scoring module is used to calculate the context reliability score based on at least one of the following: stability, purity, sample support, and non-publicity of the IP access context node. The account-IP access context weighted bipartite graph construction module is used to construct an account-IP access context weighted bipartite graph based on the co-occurrence relationship between account identifiers and IP access context nodes in standardized access records; the edge weights of the account-IP access context weighted bipartite graph are determined based on co-occurrence counts, context reliability scores, temporal continuity, and feature consistency. The edge weight calculation and low-error merging and pruning module is used to perform low-error merging and pruning on the account-IP access context weighted bipartite graph to obtain the pruned weighted bipartite graph. The connected component analysis and entity credibility assessment module is used to perform connected component analysis on the pruned weighted bipartite graph to obtain candidate user entities; calculate the entity credibility of the candidate user entities, and output the user entity recognition result based on the entity credibility; The result output and evidence tracing module is used to output the user entity identification results and evidence chain.

[0019] The IP context-enhanced user entity recognition method provided by this invention eliminates the need for front-end injection or terminal probes, reducing false merging caused by public IPs, NAT, and proxy exits, and improving the interpretability and engineering controllability of user entity recognition. Specifically, under the condition that only reverse proxy passive traffic logs can be obtained and front-end injection or terminal probes cannot be deployed, this invention sinks the original IP node to a secondary node of "IP time slice + IP access context," and constructs a weighted bipartite graph of account-IP access context by combining co-occurrence count, context reliability score, time continuity, and feature consistency. Then, through low-false-merging pruning and connectivity component analysis, hierarchical user entities are output. This effectively reduces the risk of false account merging caused by shared network environments such as public IPs, NAT, proxy exits, and IDC gateways, while preserving legitimate connections of the same natural person in multiple network environments, and outputting interpretable, auditable, and hierarchical user entity recognition results. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the IP context-enhanced user entity recognition method provided in an embodiment of the present invention.

[0021] Figure 2 This is a weighted bipartite graph of account-IP access context and a low-error merging and pruning diagram provided in an embodiment of the present invention. In the graph, A1, A2, A3, and A4 are account entities; C1, C2, C3, C4, and C5 are conditional IP contexts; C3 represents a highly promiscuous public exit; C1, C2, and C4 represent stable private or relatively clean contexts; the high w edge connecting A1 to C1 indicates high R and high T / F; the low w edge connecting A1 to C3 indicates that it was deleted during pruning due to low R (C3); the double network connection retained by Top-k is the connection between A2 and C2 / C4; the no edge connecting A3 indicates the orphan path after pruning. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0023] like Figure 1 As shown, in one embodiment of the present invention, an IP context-enhanced user entity recognition method is provided, comprising the following steps: S1. Obtain the reverse proxy access logs and perform normalization processing to obtain standardized access records; each standardized access record includes account identifier, source IP, timestamp, and passive traffic characteristics; the passive traffic characteristics include at least one of request header characteristics, request path characteristics, and session characteristics; S2. Perform time slicing on the standardized access records of the same source IP according to the source IP and time window to obtain IP time slices (IPSegment); perform quality filtering on the IP time slices and retain the IP time slices that meet the preset quality conditions as stable IP time slices; S3. Within the stable IP time slice, cluster the standardized access records according to the passive traffic characteristics to obtain IP access context nodes (IPContext nodes) and generate a set of IP access context nodes. S4. Construct an account-IP access context weighted bipartite graph based on the co-occurrence relationship between account identifiers and IP access context nodes in standardized access records; the edge weights of the account-IP access context weighted bipartite graph are determined based on co-occurrence count, context reliability score, temporal continuity, and feature consistency; the context reliability score is determined based on at least one of the stability, purity, sample support, and non-commonness of IP access context nodes. S5. Perform low-error merging and pruning on the account-IP access context weighted bipartite graph to obtain the pruned weighted bipartite graph; S6. Perform connected component analysis on the pruned weighted bipartite graph to obtain candidate user entities; calculate the entity credibility of the candidate user entities, and output the user entity recognition result based on the entity credibility.

[0024] This invention, under the condition that only the passive traffic logs of the reverse proxy can be obtained, constructs an account-IP access context weighted bipartite graph by performing time slicing and context enhancement modeling on IPs, and generates high-confidence user entities with context reliability scoring and low-error merging pruning strategy, thereby reducing the risk of erroneous merging caused by public IPs and shared network environments.

[0025] To address the shortcomings of existing technologies in rule-based merging, this invention introduces IP time slices and IP access context (IPContext) nodes. Instead of assuming a stable identity meaning for the IP itself, it determines the purity of the access context within a specific time window and passive feature cluster. To address the shortcomings of existing technologies in direct bipartite graph public IP pollution, this invention introduces context reliability scoring and a low-error merging pruning strategy to filter or downgrade contexts with excessive number of connected accounts, abnormal session / token distribution, or suspected IDC / proxy exits. To address the shortcomings of existing technologies where edge weights rely solely on co-occurrence frequency, this invention combines context reliability, temporal continuity, and feature consistency in edge weight calculation, preventing edges that are "frequently co-occurring but with untrustworthy contexts" from forming strong connections. To address the shortcomings of existing technologies in engineering constraints (only passive traffic), this invention utilizes fields that can be recorded by reverse proxies, such as source IP, timestamp, Cookie / Session / Token, User-Agent, request header combinations, access path, and access rhythm, to complete context slicing without requiring JS injection or client probes. Through the above methods, the solution can balance interpretability, unsupervised operation, and engineering controllability in the security analysis scenario of "low error merging priority".

[0026] In a preferred embodiment of the present invention, the normalization process includes: parsing at least one of the following in the reverse proxy access log: account identifier, source IP, timestamp, User-Agent, Cookie, session identifier, token, request path, and request header profile; performing irreversible hashing on the Cookie and / or token; writing records that fail to be parsed into a DLQ and incrementing the alarm count.

[0027] Specifically, the original reverse proxy logs are processed by ETL (Extract, Transform, Load) to form standardized access records r=(a,ip, t, h, p, s), where a is the account identifier (account_id, email, or username hash), ip is the source IP, t is the millisecond-level timestamp, h is the request header feature vector (User-Agent, Accept-Language, Accept-Encoding, Sec-CH-UA, etc.), p is the request path or interface type enumeration, and s is the session-related feature (irreversible hash identifier of Cookie / Session / Token). Sensitive fields are desensitized using SHA-256 or HMAC, retaining only the identifiers required for consistency checks. Records that fail to be parsed (such as missing account_id or ip fields) are written to the isolation queue "dlq:proxy_log", and the alarm counter is incremented to prevent dirty data from entering the subsequent graph construction state.

[0028] In a preferred embodiment of the present invention, the time slice adopts a fixed window or a sliding window; under a fixed window, the start time of the IP time slice is obtained by rounding the time window length according to the timestamp, and the end time is the start time plus the time window length; under a sliding window, adjacent IP time slices partially overlap. Specifically, due to the characteristics of IP addresses such as dynamic allocation, multi-user sharing, and egress drift, this embodiment of the invention does not directly use long-existing IP strings as graph nodes, but first slices them in the time dimension. Let the time window length be Δt (milliseconds). After sorting all access records of a given IP in ascending order by t, a fixed window or sliding window strategy is used to divide the IP time slice (IPSegment): for example, under a fixed window, t_start = floor(t / Δt) × Δt, t_end = t_start + Δt; under a sliding window, adjacent IP time slices can overlap by 50% to capture cross-boundary sessions. The window length Δt can be configured to 1 hour, 6 hours, 24 hours, or 7 days. In engineering, offline experiments can be conducted to compare the distribution of connected component sizes, the number of ultra-large connected components, and the precision index under different Δt values. A default value of 24 hours is selected based on the business access cycle (such as the median login frequency), while also allowing configuration overlay by IP type (IPv4 / IPv6, whether from the cloud vendor's Autonomous System Number (ASN)).

[0029] The quality filtering method includes: calculating the quality assessment parameter Stab(seg) for IP time slices; Stab(seg) is obtained by weighting at least one of User-Agent consistency, token / session distribution purity, access path distribution consistency, and session continuity; if Stab(seg) is less than the stability threshold θ_stab, the corresponding IP time slice is marked as an unstable IP time slice and written into the audit table, without proceeding to the next step; if the number of records in the IP time slice is less than the minimum number of records n_min_seg, it is marked as a low sample and passed down to the downstream with reduced weight.

[0030] Specifically, the Segment-level quality assessment function Stab(seg) is used to identify highly mixed time slices where "access subjects within the same IP segment drift significantly". Stab(seg) can be defined as a weighted combination of multiple sub-indicators: user agent consistency (UA_consist, the proportion of the dominant user agent (dominant UA) in the same IP time slice), token / session distribution purity (Token_purity, the maximum token hash proportion), access path distribution consistency (Path_consist, the sum of the proportions of the top 5 paths), session continuity (Sess_cont, the proportion of adjacent requests with an interval less than 30 minutes), etc. For example, Stab(seg) = 0.3·UA_consist + 0.25·Token_purity + 0.25·Path_consist + 0.2·Sess_cont, and each sub-indicator is normalized to [0,1]. In terms of dynamic time series processing, an If-Then-Else branch is executed for each IP time slice: if Stab(seg)<θ_stab, the IP time slice is marked as unstable, written into the "segment_audit" table (including ip, t_start, Stab component details, drop_reason = low_stability), and does not enter the IP access context construction; otherwise, it is marked as stable and pushed to the clustering queue "queue:ipcontext_build". If the number of records n_rec in the IP time slice is less than n_min_seg (for example, n_min_seg = 3), Stab(seg) will not participate in hard discarding, but will be marked as low_sample =true and transmitted to the downstream with reduced weight, and the sample support term will be automatically reduced when calculating R(c). After each batch ends, the module outputs a JSON summary {"batch_id":"...","stable_segments":81234,"dropped_segments":12045,"avg_stab":0.71} for the monitoring dashboard and parameter tuning.

[0031] In a preferred embodiment of the present invention, the passive traffic features on which the clustering is based include at least one of the following: User-Agent or User-Agent family hash, Accept-Language, Accept-Encoding, Sec-CH-UA, Cookie / session / token continuity, request path sequence, access frequency, adjacent request interval distribution, login interface and business interface access patterns, and request header combination features; the clustering adopts rule-based clustering and / or clustering based on feature vector similarity; when multiple clusters are formed within the same stable IP time slice, the same source IP in the same time slice is split into multiple IP access context nodes.

[0032] Specifically, after IP time-slice quality filtering, this invention constructs a finer-grained IP access context node (IPContext node) c = (ip, t_start, t_end, cluster_id) within each stable IP time slice based on passive traffic characteristics. Context clustering features include: User-Agent string or User Agent family hash (UA family hash), Accept-Language, Accept-Encoding, Sec-CH-UA related client hint headers, Cookie / session / token continuity (duration of the same token hash), request path sequence (e.g., the pattern / login→ / api / user), access frequency and adjacent request interval distribution, login interface and business interface access patterns, request header field combination profiles (e.g., SimHash of header_profile), etc. It is important to emphasize that the above features should not be equated with active device fingerprints: their uniqueness and stability are weaker than Canvas / WebGL-type signals, and they are more suitable as auxiliary evidence for judging IP internal slicing and context consistency. In engineering implementation, a two-stage strategy can be adopted: the first stage uses rule clustering—for example, if (UA_hash, Token_hash) are the same, they are grouped into the same cluster, and when the token is empty, it degenerates into (UA_hash, Path_prefix); the second stage introduces hierarchical clustering or DBSCAN (density clustering algorithm) based on the cosine similarity of feature vectors, and the similarity threshold ε can be set to 0.75~0.85. In the dynamic processing flow, records[] within the IP time slice are read, cluster labels are output and IP access context node IDs are generated, for example, ctx_id = SHA256(ip|t_start|cluster_id)[0:16]. If only one cluster is formed within the same IP time slice, a single node is still retained, but intra_seg_clusters = 1 is recorded in the metadata; if multiple clusters are formed (such as 3 different UA+Token combinations under public Wi-Fi), the same IP and the same time slice are split into 3 IP access context nodes, thereby avoiding incorrect connection of unrelated accounts through "same IP node" at the graph level. Typically, the size of the IP access context node set C is 1.2 to 3 times the original number of IP nodes (depending on the proportion of public IPs). Anomaly handling: When features are extremely sparse, they can be merged into a single cluster and labeled degraded_clustering. In subsequent pruning stages, a stricter θ_R is applied to this context.

[0033] like Figure 2As shown, in a preferred embodiment of the present invention, when constructing the account-IP access context weighted bipartite graph, no direct edge is established between the account identifier and the original IP string; only the edge between the account identifier and the IP access context node is established. The edge table records at least one of the following: co-occurrence count, first occurrence time, last occurrence time, User-Agent set size, and path entropy. Incremental merging is performed on existing edges, and the last occurrence time is updated. If a token conflict occurs within the same IP access context node for the same account, a token conflict flag is added to the edge table. Specifically, this embodiment of the invention constructs a weighted bipartite graph G = (A, C, E) between the account node set A and the IP access context node set C. If account a co-occurs with IP access context node c in one or more log entries, an edge e(a,c)∈E is established, and the original co-occurrence count count(a,c) is recorded (the cumulative number of visits by the same account within the same context). The key difference from the original account-IP graph is that no direct edge is established between the account and the original IP string; instead, only an edge is established between the account and the IP access context node. This makes the semantics of the edge connection "account co-occurrence under a specific time window and a specific passive feature context," rather than the coarse-grained fact that "account has used a certain IP." In the static logical architecture, an adjacency table or edge table edge_table(account_id, ctx_id, count, first_seen, last_seen, ua_set_size, path_entropy) is maintained, where first_seen / last_seen are millisecond timestamps for subsequent time continuity T(a,c) calculation. For large-scale datasets, the edge table can be stored as a columnar storage table (Parquet) or a distributed graph partition (GraphX / Neo4j batch import). In dynamic time series, after each batch of IP access context generation is completed, incremental merging is performed: if an edge already exists, the count is incremented and `last_seen` is updated; otherwise, a new edge is inserted. The final output is a graph snapshot `G_batch` and statistical summaries `|A|`, `|C|`, `|E|`, and `avg_degree`, which serve as input for subsequent steps. Anomaly handling: If a mutual exclusion token appears within the same IP access context node for an account (e.g., switching between more than 10 different session hashes in a short period), a `token_conflict=true` flag is appended to the edge table, and the consistency term of the subsequent `F(a,c)` feature is set to a low value. After graph construction is complete, the event `graph_built` is triggered, waking up the downstream scoring task; if `|E|` exceeds the memory budget, the graph is constructed in parallel by IP prefix shards before merging.

[0034] The context reliability score R(c) is obtained by weighting stability S(c), purity P(c), sample support Supp(c), and non-publicness N(c). Among them, purity P(c) is determined based on the number of independent accounts connected to the IP access context node, sample support Supp(c) is determined based on the number of records in the IP access context node and the saturation threshold, and non-publicness N(c) is determined based on at least one of the following: the number of accounts connected per unit time, the number of User-Agent types, path dispersion, whether the ASN belongs to a cloud vendor, IDC, known VPN segment, and access rhythm. If R(c) is less than the reliability threshold θ_R, the corresponding IP access context node is marked as a low-reliability IP access context node. Specifically, to measure whether an IP access context node is suitable as an intermediary node for account aggregation, this invention defines a context reliability score R(c)∈[0,1] for each c∈C, which is composed of stability S(c), purity P(c), sample support Supp(c), and non-commonness N(c). For example, R(c) = w1·S(c) + w2·P(c) + w3·Supp(c) + w4·N(c), where w1 + w2 + w3 + w4 = 1, with the default values ​​w1 = 0.3, w2 = 0.3, w3 = 0.2, and w4 = 0.2. Stability S(c) measures the consistency of passive features within the context: if the dominant user agent (UA) accounts for less than 0.5, or the number of request header profile types exceeds a threshold (e.g., greater than 8), then S(c) decreases linearly. Purity P(c) measures the account dispersion of the context connection and can be defined as P(c) = 1 / (1 + α·|A_c|), where |A_c| is the number of independent accounts connected to c, and α is a scaling factor (e.g., α = 0.15). If |A_c| > 50 and the connection occurs within 1 hour, an additional penalty factor of 0.5 is applied. Sample support Supp(c) avoids accidental associations from one-time visits. For example, Supp(c) = min(1, n_rec(c) / n_sat), where n_rec(c) is the number of records in the context, and n_sat is the saturation threshold (e.g., n_sat = 10). Non-public N(c) is determined by factors such as the number of connected accounts per unit time, the number of user agent types, path dispersion, whether the Autonomous System Number (ASN) belongs to a cloud vendor / Internet Data Center (IDC) / known Virtual Private Network (VPN) segment, and whether there is an abnormally high frequency of automated rhythm. If the ASN hits the public exit blacklist or the request interval is machine-cycled, then N(c) approaches 0 or even triggers hard removal. In the dynamic processing flow, the metadata of the IP access context node is read in batches and the edge_table is aggregated and statistically analyzed, and written to context_reliability(ctx_id,R, S, P, Supp, N, flags[]). If R(c) < θ_R (e.g., θ_R = 0.25), the context is marked as low_reliability in subsequent pruning: either it is removed from the aggregate graph, or the edge is retained but only used for risk identification output and does not participate in the calculation of user entity connectivity components. Exception handling: For a context where feature_sparse = true, the upper limit of R(c) is capped at 0.6; for a context where degraded_clustering = true, θ_R is automatically increased by 0.1.

[0035] The edge weight w(a,c) is determined based on the original co-occurrence edge weight w_raw(a,c), the context reliability score R(c), the temporal continuity T(a,c), and the feature consistency F(a,c). Among them, w_raw(a,c) is obtained by normalizing the co-occurrence count of account a and IP access context node c; T(a,c) is determined based on the number of times account a accesses IP access context node c within the time interval and the interval between adjacent accesses; F(a,c) is determined based on the stability of the User-Agent, token, and path pattern used by account a within IP access context node c.

[0036] Specifically, in the original scheme, the edge weights can be obtained by normalizing the co-occurrence counts, resulting in w_raw(a,c) = count(a,c) / Σ_{c} count(a,c). This embodiment further defines enhanced edge weights: w(a,c) = w_raw(a,c)·R(c)·T(a,c)·F(a,c). Here, T(a,c) represents temporal continuity: if a is accessed ≥ 3 times within the [first_seen, last_seen] interval of c and the median interval between adjacent accesses is less than 2 hours, then T = 1; if there is only one co-occurrence, then T = 0.1. F(a,c) represents feature consistency: whether the user agent (UA), token, and path pattern used by a within c are stable; for example, F = 1 when the number of UA types is 1, and F = 0.3 when the number of UA types is ≥ 3. This design ensures that even if count(a,c) is high, w(a,c) will still be suppressed if R(c) or T / F is low; conversely, long-term co-occurrence edges in a stable private environment will receive high weights.

[0037] In a preferred embodiment of the present invention, the low-error merging pruning includes: Low reliability context filtering: Remove or isolate IP access context nodes whose R(c) is less than the reliability threshold θ_R, whose number of connected accounts is greater than the account number threshold, whose token distribution is abnormal, or whose IPs are suspected of being automated and frequently accessing the context. Threshold pruning: retain edges that satisfy the following conditions: edge weight w(a,c) is greater than or equal to the edge weight threshold θ_w, co-occurrence count is greater than or equal to the minimum co-occurrence count n_min, and R(c) is greater than or equal to θ_R; Top-k pruning: For each account node, retain at most k edges in descending order of edge weight w(a,c), and each edge satisfies R(c) greater than or equal to θ_R; Maximum edge plus safe edge pruning: Based on Top-k pruning, additional edges that satisfy R(c) greater than or equal to the safety reliability threshold, co-occurrence count greater than or equal to the safety count threshold, and time continuity T(a,c) greater than or equal to the safe time threshold are retained; Accounts that do not retain any edges after pruning are added to the orphan account list (orphan_accounts).

[0038] Specifically, the low-error merging pruning strategy is implemented in stage T+2 after edge weight calculation and includes four levels: Level 1, low-reliability context filtering: removing or isolating context nodes with R(c) < θ_R, |A_c| > threshold (e.g., 100), abnormal token distribution, or suspected high-frequency automation. Level 2, threshold pruning: retaining edges that satisfy w(a,c) ≥ θ_w, count(a,c) ≥ n_min (e.g., n_min = 2), and R(c) ≥ θ_R. Level 3, Top-k pruning: for each account a, retaining at most k edges in descending order of w(a,c) (k defaults to 3~5), and each edge must satisfy R(c) ≥ θ_R; avoiding the "only one maximum edge per account" approach that cuts off legitimate connections for the same user across multiple networks (family / company / mobile). Level 4, Maximum Edge + Safe Edge Strategy: In addition to the Top-k edge selection, safe edges satisfying "R(c) ≥ 0.7, count ≥ 5, and T(a,c) ≥ 0.8" are retained, even if their ranking is lower than Top-k. The pruned sparse graph is denoted as G' = (A, C', E'), and used as input for connected component analysis. In terms of control flow, if |E'| / |E| < 0.01 after pruning and the business requires improved recall, θ_w is automatically decreased or k is increased, and prune_mode = 'relaxed' is recorded for auditing. Exception handling: If all edges of an account are pruned, the account is added to the orphan account list (orphan_accounts), and no entity is forcibly merged into it.

[0039] In a preferred embodiment of the present invention, the user entity identification result includes at least one of high-confidence entities, medium-confidence candidate entities, and low-confidence entities to be observed; the connected component analysis employs Union-Find or Breadth-First Search (BFS); the entity confidence E(CC_i) is determined based on at least one of the following: the average edge weight of the edges in the candidate user entity, the average context reliability score of the IP access context node, time consistency, and size penalty; if E(CC_i) is greater than or equal to the high-confidence threshold θ_high, a high-confidence entity is output; if E(CC_i) is greater than or equal to the medium-confidence threshold θ_mid and less than θ_high, a medium-confidence candidate entity is output; if E(CC_i) is less than θ_mid or the proportion of low-reliability IP access context nodes exceeds the proportion threshold, a low-confidence entity to be observed is output.

[0040] Specifically, connected component analysis (Union-Find or Breadth-First Search) is performed on the pruned graph G'. Each connected component CC represents a candidate user entity, containing an account subset A and a context subset C. This embodiment emphasizes that the connected component CC_i is not directly equivalent to the final user entity; the entity credibility E(CC_i) still needs to be calculated: E(CC_i) = β1·mean_{e∈CC_i} w(e) + β2·mean_{c∈C_i} R(c) + β3·TimeConsist(CC_i) -β4·SizePenalty(A_i). Here, TimeConsist measures whether the account-context timeline within the entity is consistent, and SizePenalty penalizes components with abnormally large |A_i| values ​​(e.g., greater than 20). If E ≥ θ_high (e.g., 0.65), the output is a high-confidence user entity; if θ_mid ≤ E < θ_high, the output is a medium-confidence candidate entity; if E < θ_mid or the proportion of low_reliability context is too high, the output is a low-confidence / unobservable entity, which does not participate in the determination merging and is only used for public exit identification or risk screening.

[0041] In a preferred embodiment of the present invention, the IP context-enhanced user entity recognition method further includes the following steps: Parameter adaptive feedback: Monitor at least one of the unstable IP time slice drop ratio and the maximum connected component size; if the unstable IP time slice drop ratio exceeds the drop ratio threshold or the maximum connected component size exceeds the component size threshold, increase the reliability threshold θ_R, decrease the k value in Top-k or shorten the time window length, and set the pruning mode of the next batch to strict mode.

[0042] Specifically, if the monitored metric segment_dropped_ratio > 40% or max_component_size > the threshold (e.g., 50 accounts), automatically increase θ_R, decrease k, or shorten Δt, and issue an alarm JSON {"alert":"over_merge_risk","suggested_action":"tighten_prune"}, and mark the next batch with prune_mode = strict. This closed loop ensures that the low-error merging constraint is maintained even during distribution drift.

[0043] In a preferred embodiment of the present invention, the IP context-enhanced user entity recognition method further includes the following steps: Results Output and Evidence Tracing: Output structured records, which include at least one of the following: user entity identifier, account list, IP access context node list, entity confidence, evidence edge, main IP access context node, risk marker, creation time and update time; the evidence edge includes at least one of the following: edge weight, context reliability score and co-occurrence count.

[0044] Specifically, the structured record fields include: user_entity_id, account_list, context_list, entity_confidence, evidence_edges (including w, R, and count), main_context, risk_flags, create_time, and update_time, and retains a JSON evidence chain for compliance auditing. Furthermore, when R(c) < θ_R or N(c) matches a public exit rule, the control flow routes this context to the risk-only analysis channel (analysis_only), whose edges do not participate in connected component merging but are written to the public exit watchlist (public_exit_watchlist) for security operations analysis. This bypass prevents pollution of the main aggregate graph while preserving public IP behavior visibility.

[0045] In another embodiment of the present invention, an IP context-enhanced user entity recognition system is also provided to implement the above method, specifically including: The log access and normalization module is used to obtain reverse proxy access logs and normalize them to obtain standardized access records. Each standardized access record includes an account identifier, source IP, timestamp, and passive traffic characteristics. The passive traffic characteristics include at least one of request header characteristics, request path characteristics, and session characteristics. The IP time slice construction and quality filtering module is used to perform time slicing on standardized access records of the same source IP according to the source IP and time window to obtain IP time slices; and to perform quality filtering on the IP time slices, retaining IP time slices that meet preset quality conditions as stable IP time slices. The IP access context clustering module is used to cluster standardized access records according to the passive traffic characteristics within the stable IP time slice to obtain IP access context nodes and generate an IP access context node set. The context reliability scoring module is used to calculate the context reliability score based on at least one of the following: stability, purity, sample support, and non-publicity of the IP access context node. The account-IP access context weighted bipartite graph construction module is used to construct an account-IP access context weighted bipartite graph based on the co-occurrence relationship between account identifiers and IP access context nodes in standardized access records; the edge weights of the account-IP access context weighted bipartite graph are determined based on co-occurrence counts, context reliability scores, temporal continuity, and feature consistency. The edge weight calculation and low-error merging and pruning module is used to perform low-error merging and pruning on the account-IP access context weighted bipartite graph to obtain the pruned weighted bipartite graph. The connected component analysis and entity credibility assessment module is used to perform connected component analysis on the pruned weighted bipartite graph to obtain candidate user entities; calculate the entity credibility of the candidate user entities, and output the user entity recognition result based on the entity credibility; The parameter configuration module is used to issue at least one of the following: time window length, stability threshold θ_stab, edge weight threshold θ_w, reliability threshold θ_R, k value in Top-k, and minimum co-occurrence count n_min. It also monitors the unstable IP time slice drop ratio and the maximum connected component size. If the unstable IP time slice drop ratio exceeds the drop ratio threshold or the maximum connected component size exceeds the component size threshold, then θ_R is increased, k value is decreased, or time window length is shortened. The result output and evidence tracing module is used to output the user entity identification results and evidence chain.

[0046] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods.

[0047] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this patent should be determined by the appended claims.

Claims

1. An IP context-enhanced user entity recognition method, characterized in that, Includes the following steps: Obtain the reverse proxy access logs and normalize them to obtain standardized access records; each standardized access record includes account identifier, source IP, timestamp, and passive traffic characteristics; The passive traffic characteristics include at least one of request header characteristics, request path characteristics, and session characteristics; Standardized access records from the same source IP are time-sliced ​​according to the source IP and time window to obtain IP time slices; the IP time slices are quality-filtered, and IP time slices that meet preset quality conditions are retained as stable IP time slices; Within the stable IP time slice, standardized access records are clustered according to the passive traffic characteristics to obtain IP access context nodes and generate an IP access context node set. Based on the co-occurrence relationship between account identifiers and IP access context nodes in standardized access records, a weighted bipartite graph of account-IP access context is constructed; the edge weights of the weighted bipartite graph of account-IP access context are determined based on co-occurrence count, context reliability score, temporal continuity, and feature consistency. The context reliability score is determined based on at least one of the following: stability, purity, sample support, and non-publicity of the IP access context node. Perform low-error merging and pruning on the account-IP access context weighted bipartite graph to obtain the pruned weighted bipartite graph; Connectivity component analysis is performed on the pruned weighted bipartite graph to obtain candidate user entities; the entity credibility of the candidate user entities is calculated, and the user entity recognition result is output based on the entity credibility.

2. The IP context-enhanced user entity recognition method according to claim 1, characterized in that, The normalization process includes: parsing at least one of the following features from the reverse proxy access log: account identifier, source IP, timestamp, User-Agent, cookie, session identifier, token, request path, and request header combination; performing irreversible hashing on the cookie and / or token; writing records that fail to be parsed into an isolation queue and incrementing the alarm count.

3. The IP context-enhanced user entity recognition method according to claim 1, characterized in that, The time slice uses a fixed window or a sliding window; under a fixed window, the start time of the IP time slice is obtained by rounding the time window length according to the timestamp, and the end time is the start time plus the time window length. Under a sliding window, adjacent IP time slices partially overlap; The quality filtering method includes: calculating the quality assessment parameter Stab(seg) for the IP time slice; The Stab(seg) is obtained by weighting at least one of User-Agent consistency, token / session distribution purity, access path distribution consistency, and session continuity. If Stab(seg) is less than the stability threshold θ_stab, the corresponding IP time slice is marked as an unstable IP time slice and written into the audit table, without proceeding to the next step. If the number of records in the IP time slice is less than the minimum number of records n_min_seg, it is marked as a low sample and passed down downstream with reduced weight.

4. The IP context-enhanced user entity recognition method according to claim 1, characterized in that, The passive traffic features on which the clustering is based include at least one of the following: User-Agent or User-Agent family hash, Accept-Language, Accept-Encoding, Sec-CH-UA, Cookie / session / token continuity, request path sequence, access frequency, adjacent request interval distribution, login interface and business interface access patterns, and request header combination features; the clustering adopts rule-based clustering and / or clustering based on feature vector similarity; when multiple clusters are formed within the same stable IP time slice, the same source IP in the same time slice is split into multiple IP access context nodes.

5. The IP context-enhanced user entity recognition method according to claim 4, characterized in that, When constructing the account-IP access context weighted bipartite graph, no direct edges are created between the account identifier and the original IP string; only edges are created between the account identifier and the IP access context node. The edge table records at least one of the following: co-occurrence count, first occurrence time, last occurrence time, User-Agent set size, and path entropy. Existing edges are incrementally merged and the last occurrence time is updated. If a token conflict occurs within the same IP access context node for the same account, a token conflict flag is added to the edge table. The context reliability score R(c) is obtained by weighting stability S(c), purity P(c), sample support Supp(c), and non-publicness N(c). Among them, purity P(c) is determined based on the number of independent accounts connected to the IP access context node, sample support Supp(c) is determined based on the number of records in the IP access context node and the saturation threshold, and non-publicness N(c) is determined based on at least one of the following: the number of accounts connected per unit time, the number of User-Agent types, path dispersion, whether the ASN belongs to a cloud vendor, IDC, known VPN segment, and access rhythm. If R(c) is less than the reliability threshold θ_R, the corresponding IP access context node is marked as a low-reliability IP access context node. The edge weight w(a,c) is determined based on the original co-occurrence edge weight w_raw(a,c), the context reliability score R(c), the temporal continuity T(a,c), and the feature consistency F(a,c). Among them, w_raw(a,c) is obtained by normalizing the co-occurrence count of account a and IP access context node c; T(a,c) is determined based on the number of times account a accesses IP access context node c within the time interval and the interval between adjacent accesses; F(a,c) is determined based on the stability of the User-Agent, token, and path pattern used by account a within IP access context node c.

6. The IP context-enhanced user entity recognition method according to claim 5, characterized in that, The low-error merging pruning includes: Low reliability context filtering: Remove or isolate IP access context nodes whose R(c) is less than the reliability threshold θ_R, whose number of connected accounts is greater than the account number threshold, whose token distribution is abnormal, or whose IPs are suspected of being automated and frequently accessing the context. Threshold pruning: retain edges that satisfy the following conditions: edge weight w(a,c) is greater than or equal to the edge weight threshold θ_w, co-occurrence count is greater than or equal to the minimum co-occurrence count n_min, and R(c) is greater than or equal to θ_R; Top-k pruning: For each account node, retain at most k edges in descending order of edge weight w(a,c), and each edge satisfies R(c) greater than or equal to θ_R; Maximum edge plus safe edge pruning: Based on Top-k pruning, additional edges that satisfy R(c) greater than or equal to the safety reliability threshold, co-occurrence count greater than or equal to the safety count threshold, and time continuity T(a,c) greater than or equal to the safe time threshold are retained; Accounts that did not retain any edges after pruning will be added to the list of isolated accounts.

7. The IP context-enhanced user entity recognition method according to claim 1, characterized in that, The user entity identification results include at least one of high-confidence entities, medium-confidence candidate entities, and low-confidence entities to be observed; the connected component analysis adopts disjoint-set data structure or breadth-first search; the entity confidence E(CC_i) is determined based on at least one of the following: the average edge weight of the candidate user entity, the average context reliability score of the IP access context node, time consistency, and size penalty; if E(CC_i) is greater than or equal to the high-confidence threshold θ_high, a high-confidence entity is output; if E(CC_i) is greater than or equal to the medium-confidence threshold θ_mid and less than θ_high, a medium-confidence candidate entity is output; if E(CC_i) is less than θ_mid or the proportion of low-reliability IP access context nodes exceeds the proportion threshold, a low-confidence entity to be observed is output.

8. The IP context-enhanced user entity recognition method according to claim 6, characterized in that, It also includes the following steps: Parameter adaptive feedback: Monitor at least one of the unstable IP time slice drop ratio and the maximum connected component size; if the unstable IP time slice drop ratio exceeds the drop ratio threshold or the maximum connected component size exceeds the component size threshold, increase the reliability threshold θ_R, decrease the k value in Top-k or shorten the time window length, and set the pruning mode of the next batch to strict mode.

9. The IP context-enhanced user entity recognition method according to claim 1, characterized in that, It also includes the following steps: Results Output and Evidence Tracing: Output structured records, which include at least one of the following: user entity identifier, account list, IP access context node list, entity confidence, evidence edge, main IP access context node, risk marker, creation time and update time; the evidence edge includes at least one of the following: edge weight, context reliability score and co-occurrence count.

10. An IP context-enhanced user entity recognition system, used to implement the IP context-enhanced user entity recognition method according to any one of claims 1-9, characterized in that, include: The log access and normalization module is used to obtain reverse proxy access logs and normalize them to obtain standardized access records. Each standardized access record includes an account identifier, source IP address, timestamp, and passive traffic characteristics; The passive traffic characteristics include at least one of request header characteristics, request path characteristics, and session characteristics; The IP time slice construction and quality filtering module is used to perform time slicing on standardized access records of the same source IP according to the source IP and time window to obtain IP time slices; The IP time slices are quality filtered, and IP time slices that meet the preset quality conditions are retained as stable IP time slices; The IP access context clustering module is used to cluster standardized access records according to the passive traffic characteristics within the stable IP time slice to obtain IP access context nodes and generate an IP access context node set. The context reliability scoring module is used to calculate the context reliability score based on at least one of the following: stability, purity, sample support, and non-publicity of the IP access context node. The account-IP access context weighted bipartite graph construction module is used to construct an account-IP access context weighted bipartite graph based on the co-occurrence relationship between account identifiers and IP access context nodes in standardized access records; the edge weights of the account-IP access context weighted bipartite graph are determined based on co-occurrence counts, context reliability scores, temporal continuity, and feature consistency. The edge weight calculation and low-error merging and pruning module is used to perform low-error merging and pruning on the account-IP access context weighted bipartite graph to obtain the pruned weighted bipartite graph. The connected component analysis and entity credibility assessment module is used to perform connected component analysis on the pruned weighted bipartite graph to obtain candidate user entities; calculate the entity credibility of the candidate user entities, and output the user entity recognition result based on the entity credibility; The result output and evidence tracing module is used to output the user entity identification results and evidence chain.

Images