A replay risk-aware zone admission control method for credential backends

Abstract

This invention belongs to the field of access control, security indexing, and high-cost point query protection technology, and discloses a replay risk-aware region access control method for credential-based backends. The method obtains the point query key, credential region, time period, backend call cost, historical invalid attempt records, replay flags, and access index status for pending point query requests; maps the point query key to a risk region, and statistically calculates invalid attempt density, replay similarity, and backend call cost; constructs or updates a one-sided access index based on the preprocessing results, allowing only requests that meet the region risk constraints, replay risk constraints, and backend cost constraints to the high-cost backend; when the region risk, replay risk, or invalid attempt density exceeds a threshold, it performs rejection, delay processing, or secondary authentication, outputting the access result or rejection result, the region index update result, and the risk audit record, and generates a backend call credential when the request is allowed.

Description

Technical Field

[0001] This invention belongs to the fields of access control, security indexing, high-cost point query protection, replay risk identification and audit tracing. Specifically, it relates to a computer implementation method for constructing a one-sided access index based on risk areas, replay attempts and backend call costs in a credential backend query scenario, and for performing access control, result output and audit logging on point query requests. Background Technology

[0002] In scenarios involving credential verification, token verification, sparse key queries, or other point queries, backend services typically need to perform exact matching, status queries, or further validation on the input keys. If a large number of invalid point queries, repeated attempts, or replay attempts directly reach the high-cost backend, it will increase the burden on backend computation, storage access, or external service calls, and may amplify security risks.

[0003] In existing engineering solutions, one type directly sends point query requests to the backend for verification, making it difficult to pre-constrain regional risks, replay risks, and invalid attempt density before the backend makes the call. Another type relies on a single risk control score, manual offline analysis, or a static blacklist, making it difficult to simultaneously retain the correspondence between input criteria, processing parameters, threshold judgments, output results, and anomaly handling. When query requests have periodicity, regionality, or replay similarity, the above solutions also struggle to unify risk areas, time windows, backend cost status, and access index status into an executable process.

[0004] Therefore, it is necessary to provide an access control method for replay risk perception areas oriented towards the backend of credentials, so that the system can perform unilateral access judgment based on risk areas and replay risks before high-cost backend calls, and form verifiable and traceable processing records. Summary of the Invention

[0005] The technical problem this invention aims to solve is to address the issue of invalid attempts, replay attempts, and high-cost backend calls in post-credential endpoint query requests. It provides a replay risk awareness area access control method for post-credential backends. Through data acquisition, feature construction, one-sided access index construction, threshold judgment, result output, and audit feedback, this method reduces the probability of point query requests that do not meet risk constraints directly entering high-cost backends and improves the verifiability and traceability of the processing.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution.

[0007] A method for access control of replay risk perception area oriented towards the backend of credentials includes the following steps: S1, for the pending point query request, obtain the point query key, the voucher area corresponding to the point query key, the time period, the backend call cost, the historical invalid attempt record, the replay mark, and the admission index status.

[0008] The point query key can be a password, token, session identifier, sparse key, or other key-value pairs used for precise backend queries; the credential region can be a region identifier divided according to credential source, business partition, risk partition, or policy version; the time period can be a fixed time window, rolling time window, or epoch; the backend call cost can be the estimated call cost, cumulative call cost, or cost status related to backend resource consumption; the historical invalid attempt record is used to indicate historical requests that failed access or backend verification within the time period; the replay flag is used to indicate that there is a duplicate, similar, or suspicious association between the pending point query request and the historical request; and the access index status is used to indicate the index item, policy version, or access status corresponding to the current region.

[0009] S2, perform preprocessing on the data obtained in step S1, map the point query key to the risk area, and statistically calculate the invalid attempt density, replay similarity and backend call cost in the risk area based on the time period to obtain the preprocessing result.

[0010] In one implementation, the system determines risk areas based on point query key summaries, credential regions, policy versions, or time periods; it statistically analyzes historical invalid attempt records within the same risk area to obtain invalid attempt density; it obtains replay similarity based on the similarity between pending point query requests and historical requests in terms of key summaries, request times, source regions, replay markers, or other low-sensitivity features; and it obtains backend call costs based on the number of backend calls, call types, or cost status. The preprocessing results can be organized as feature vectors, region status sets, candidate regions, cost status records, or audit evidence sets.

[0011] The system can also mark missing, abnormal, duplicate, or data that does not meet scenario constraints, and use the marking results as input or constraint conditions for subsequent threshold judgments. These markings can be bound and saved with input summaries, time windows, policy versions, or task identifiers.

[0012] S3. Based on the preprocessing results obtained in step S2, construct or update the one-sided admission index, and determine whether the query request for the point to be processed meets the regional risk constraints, replay risk constraints, and backend cost constraints according to the one-sided admission index.

[0013] In one implementation, the unilateral admission index maintains index entries by risk region. Each index entry may include at least one of the following: region identifier, time window, invalid attempt statistics, replay similarity statistics, backend call cost status, admission status, policy version, or audit identifier. The system updates the index entries for the corresponding risk region based on the invalid attempt density, replay similarity, and backend call cost obtained in step S2, and generates the region risk status, replay risk status, and backend cost status for subsequent threshold determination.

[0014] The unilateral admission index is used to perform admission control before high-cost backend calls. For point query requests that meet regional risk constraints, replay risk constraints, and backend cost constraints, the system generates an admission status or backend call credential and allows the point query request to be passed to the high-cost backend; for point query requests that do not meet the above constraints, the system does not directly call the high-cost backend, but instead enters a rejection, delayed processing, or secondary authentication process.

[0015] In an optional implementation, the core processing does not require the recovery of credentials or the original sensitive data of the protected object as a prerequisite, but rather completes the calculation based on at least one of the point query key summaries, statistical reports, risk scores, or low-sensitivity features required for access determination.

[0016] S4. Perform threshold judgment based on the processing result of step S3. When the area risk, replay risk, or invalid attempt density exceeds the corresponding threshold, perform rejection, delay processing, or secondary authentication on the query request for the pending point.

[0017] The threshold can be a fixed threshold, an adaptive threshold, or a scenario-specific threshold. A fixed threshold can be determined by policy configuration; an adaptive threshold can be updated based on historical windows, risk levels, budget status, feedback sparsity, or device status; a scenario-specific threshold can be determined based on voucher area, task type, policy version, or backend cost status. The threshold judgment result can include admission, rejection, delayed processing, secondary authentication, anomaly review, or parameter update triggering.

[0018] S5, output the processing result for the query request of the pending point, the processing result includes the admission result or rejection result, the regional index update result and the risk audit record, and generate the backend call credential when the query request of the pending point is allowed to the high-cost backend.

[0019] The processing results are bound and stored in a traceable record. This traceable record may include at least one of the following: input summary, processing parameters, policy version, threshold judgment result, output hash, and anomaly handling result. The output results may be written to logs, database tables, chained hash records, policy controllers, or model management systems for subsequent review, auditing, or parameter adjustment.

[0020] S6. When the conditions for risk triggering, abnormal review, or parameter update are met, the risk audit record, admission result or rejection result, and regional index update result output in step S5 are fed back to step S2 or step S3 to update the subsequent processing parameters, thresholds, or strategy versions.

[0021] In an optional implementation, the admission index can be updated on a rolling basis by epoch; the point query key can be a password, token, or sparse key; and the one-sided admission index can adopt a one-sided strategy that prioritizes controlling the risk of false admission.

[0022] Compared with existing technologies, this invention can achieve at least the following technical effects: by obtaining the point query key, credential area, time period, backend call cost, historical invalid attempt records, replay markers, and admission index status before high-cost backend calls, admission control has clear data input; by mapping point query requests to risk areas and statistically analyzing invalid attempt density, replay similarity, and backend call cost, risk characteristics can be correlated with the admission index; by constructing or updating a one-sided admission index and only allowing point query requests that meet risk and cost constraints to be allowed to the high-cost backend, it is beneficial to reduce the occupation of backend resources by requests that do not meet the constraints; by binding and saving the processing results with the input summary, processing parameters, threshold judgment results, output hash, and anomaly handling results, it is beneficial to form a verifiable and auditable processing chain. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the system module structure of the present invention; Figure 3 This is a schematic diagram of the output record and audit fields of this invention. Detailed Implementation

[0024] The embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the following embodiments are used to illustrate the technical solution of the present invention and are not intended to limit the scope of protection of the present invention. Without departing from the technical concept of the present invention, those skilled in the art can adjust the execution order, data format, deployment method or parameter configuration of each step.

[0025] like Figure 1 As shown, the method of this invention can be executed by a server, gateway, credential verification service, audit service, or a combination thereof. Upon receiving a query request for a point to be processed, the system first performs data acquisition, then preprocessing and feature construction, followed by core processing through a one-sided admission index, and finally outputs the processing result based on threshold conditions. The output result is then bound and saved with the audit field. When risk triggering, anomaly review, or parameter update conditions are met, the system can also feed back the output result to the preprocessing or core processing steps.

[0026] In S1, the system acquires the point query key, credential area, time period, backend call cost, historical invalid attempt records, replay flag, and admission index status. To avoid unnecessary exposure of raw sensitive data, the system can save the point query key summary, identifier, or low-sensitivity features instead of directly saving the raw credential. Input data can be stored hierarchically according to input objects, runtime parameters, and audit metadata: input objects include the point query key and credential area; runtime parameters include the time period, backend call cost, and admission index status; audit metadata includes at least one of the following: time window, policy version, task identifier, or device status.

[0027] In S2, the system performs preprocessing and feature construction. The system can determine risk areas based on point query key summaries, credential regions, and policy versions, and statistically analyze historical invalid attempt records within the corresponding time period to obtain the invalid attempt density. The system can also obtain replay similarity based on duplicate key summaries, similar times, similar source regions, or replay markers between pending point query requests and historical requests. Furthermore, the system can obtain backend call costs based on the number of backend calls and the expected call resource or cost status. For missing, abnormal, duplicate, or scenario-unmet data, the system can generate anomaly markers and use these markers as constraints for subsequent threshold judgments.

[0028] In step S3, the system constructs or updates a one-sided admission index based on the preprocessing results. This one-sided admission index can maintain regional index entries by risk region, with each regional index entry associated with a corresponding time period, invalid attempt density, replay similarity, backend call cost status, and policy version. The system writes or updates the features output in step S2 into the corresponding regional index entries, forming regional risk status, replay risk status, and cost status. For point query requests that meet the risk and cost constraints, the system generates an admission status or backend call credential; for point query requests that do not meet the constraints, the system does not directly call the high-cost backend.

[0029] In S4, the system performs threshold judgments based on regional risk status, replay risk status, invalid attempt density, and backend cost status. Thresholds can be configured by the administrator or updated based on historical windows, risk levels, budget status, feedback sparsity, device status, or task type. If regional risk, replay risk, or invalid attempt density exceeds the corresponding threshold, the system outputs a rejection, delayed processing, or secondary authentication trigger result; if all risk statuses meet the admission constraints, the system outputs an admission result and allows entry into the high-cost backend verification process.

[0030] In S5, the system outputs processing results and generates risk audit records. Processing results include admission or rejection results, region index update results, backend call credentials, and risk audit records. Risk audit records can include input summaries, processing parameters, policy versions, threshold judgment results, output hashes, and exception handling results. Output results can be written to logs, database tables, or chained hash records to facilitate review of processing within the same task identifier, policy version, or time window.

[0031] In step S6, when the system detects a risk trigger, anomaly review, or parameter update condition, it can feed back the risk audit record, admission or rejection result, and region index update result output in step S5 to step S2 or S3. The feedback results can be used to adjust subsequent preprocessing rules, update thresholds, adjust policy versions, or update region index status. This feedback process can be executed by time window or epoch, or it can be triggered by an anomaly review event.

[0032] like Figure 2 As shown, the present invention can also be implemented as a system for performing the above-described method. This system includes a data acquisition module, a feature construction module, a core processing module, a threshold judgment module, a result output module, and an audit record module. The data acquisition module is used to acquire the point query key, credential region, time period, backend call cost, historical invalid attempt records, replay markers, and admission index status. The feature construction module is used to map the point query key to a risk region and to statistically calculate the invalid attempt density, replay similarity, and backend call cost. The core processing module is used to construct or update a one-sided admission index based on the preprocessing results and determine whether the point query request to be processed meets the risk constraints. The threshold judgment module is used to trigger rejection, delayed processing, or secondary authentication when the regional risk, replay risk, or invalid attempt density exceeds the corresponding threshold. The result output module is used to output the admission result or rejection result, the regional index update result, the backend call credential, and the risk audit record. The audit record module is used to store traceable records corresponding to the processing results.

[0033] like Figure 3 As shown, the output records and audit fields can include input summary, processing parameters, policy version, threshold judgment result, output hash, and exception handling result. The input summary indicates the low-sensitivity representation corresponding to the query request for the pending point; the processing parameters indicate the risk area, time window, backend call cost, or policy version; the threshold judgment result records whether the area risk, replay risk, or invalid attempt density exceeds the corresponding threshold; the output hash is used to bind the output result; and the exception handling result records the handling results such as rejection, delayed processing, secondary authentication, or exception review.

[0034] This invention can also be implemented as an electronic device. The electronic device includes a processor and a memory, the memory storing computer programs or instructions. When the processor executes the computer programs or instructions, it causes the processor to perform the aforementioned credential-based replay risk awareness area access control method. The electronic device can be a server, gateway device, edge computing device, terminal device, or a distributed computing environment composed of multiple devices.

[0035] Table 1 Input Data and Preprocessing Features Input object Click the query button, then select the voucher area. Limit the query requests for pending points and their respective regions. Running parameters Time period, backend call cost, admission index status Provides parameters for risk statistics, cost constraints, and index updates. Historical and Risk Information Invalid historical attempt record, replay marker Used to calculate invalid attempt density and replay similarity. Preprocessing results Risk areas, invalid attempt density, replay similarity, and backend call cost The computational basis for constructing or updating a one-sided admission index. Threshold judgment criteria Regional risk, replay risk, invalid attempt density and corresponding thresholds Trigger admission, denial, delayed processing, or two-factor authentication Table 2 System Modules and Functions Data acquisition module Retrieve query key, credential area, time period, backend call cost, historical invalid attempt records, replay flag, and admission index status. Input summary and runtime parameters Feature Construction Module Perform risk region mapping, and statistically calculate invalid attempt density, replay similarity, and backend call cost. Preprocessing results and feature set Core processing module Build or update a one-sided admission index and determine whether point query requests meet risk and cost constraints. Regional risk status, replay risk status, and access status; backend call credentials generated upon granting access. Threshold determination module Determine whether the regional risk, replay risk, or invalid attempt density exceeds the threshold. Access, rejection, delayed processing, secondary authentication, or abnormal review trigger results Result Output Module Output the admission or rejection result, the area index update result, and the risk audit record, and generate backend call credentials when granting access. Processing results Audit Log Module The system binds and saves input summaries, processing parameters, strategy versions, threshold judgment results, output hashes, and exception handling results, and writes them to logs, database tables, or chained hash records. Traceable records The specific thresholds, time window lengths, risk area division rules, cost calculation methods, and policy update cycles not limited in the above embodiments can be configured according to the security policies, backend cost status, and deployment environment of the specific system, but should not deviate from the technical concept of this invention to control high-cost point query requests through risk areas, replay risks, and unilateral admission indexes.

Claims

1. A method for access control of replay risk perception area oriented towards the back-end of credentials, characterized in that, include: S1, for the pending point query request, obtain the point query key, the voucher area corresponding to the point query key, the time period, the backend call cost, historical invalid attempt records, replay markers and admission index status; S2, perform preprocessing on the data obtained in step S1, map the point query key to the risk area, and statistically or calculate the invalid attempt density, replay similarity and backend call cost in the risk area based on the time period to obtain the preprocessing result; S3, construct or update the one-sided admission index based on the preprocessing result, and determine whether the query request for the point to be processed meets the regional risk constraint, replay risk constraint and backend cost constraint according to the one-sided admission index. Only the query requests for the point that meet the regional risk constraint, replay risk constraint and backend cost constraint are allowed to the high-cost backend. S4. Based on the processing result of step S3, a threshold judgment is performed. When the area risk, replay risk, or invalid attempt density exceeds the corresponding threshold, the query request for the point to be processed is rejected, delayed, or re-authenticated. S5, output the processing result for the query request of the pending point, the processing result includes the admission result or rejection result, the regional index update result and the risk audit record, and generate the backend call credential when the query request of the pending point is allowed to the high-cost backend.

2. The method according to claim 1, characterized in that, The data obtained in step S1 is stored in layers according to input objects, running parameters, and audit metadata; the input objects include point query keys and credential areas, the running parameters include time periods, backend call costs, and admission index status, and the audit metadata includes at least one of time windows, policy versions, task identifiers, or device status.

3. The method according to claim 1, characterized in that, Step S2 further includes: marking missing, abnormal, duplicate, or data that does not meet the scenario constraints, and using the marking results together with the mapped risk area, invalid attempt density, replay similarity, or backend call cost as inputs or constraints for threshold judgment in step S4.

4. The method according to claim 1, characterized in that, The core processing in step S3 does not require the recovery of the original sensitive data of the credentials or protected object as a necessary condition. Instead, it completes the construction or update of the one-sided access index based on at least one of the point query key summary, statistical report, risk score or low-sensitivity feature required for access judgment.

5. The method according to claim 1, characterized in that, The threshold in step S4 includes a fixed threshold, an adaptive threshold, or a scenario-specific threshold. The adaptive threshold is updated based on at least one of the following: historical window, risk level, budget status, feedback sparsity, or device status.

6. The method according to claim 1, characterized in that, The processing result in step S5 is bound and saved with a traceable record, which includes at least one of the following: input summary, processing parameters, threshold judgment result, output hash, and anomaly handling result.

7. The method according to claim 1, characterized in that, The method further includes: when the risk triggering, abnormal review or parameter update conditions are met, feeding back the risk audit record, admission result or rejection result, and regional index update result output in step S5 to step S2 or step S3 to update the subsequent processing parameters, thresholds or strategy versions.

8. The method according to claim 1, characterized in that, The admission index is updated on a rolling basis by epoch; and / or, the point query key is a password, token, or sparse key; and / or, the one-sided admission index adopts a one-sided strategy that prioritizes controlling the risk of false release.

9. A system for performing the method according to any one of claims 1 to 8, characterized in that, It includes a data acquisition module, a feature construction module, a core processing module, a threshold judgment module, a result output module, and an audit log module; The data acquisition module is used to acquire the point query key, voucher area, time period, backend call cost, historical invalid attempt records, replay marker, and admission index status; The feature construction module is used to map the point query key to the risk area, and to count or calculate the invalid attempt density, replay similarity and backend call cost. The core processing module is used to construct or update the one-sided admission index based on the preprocessing results output by the feature construction module, and to determine whether the query request of the point to be processed meets the regional risk constraint, replay risk constraint and backend cost constraint. The threshold judgment module is used to trigger rejection, delayed processing, or secondary authentication when the area risk, replay risk, or invalid attempt density exceeds the corresponding threshold. The result output module is used to output the admission result or rejection result, the regional index update result and the risk audit record, and to generate a backend call credential when the query request of the pending point is allowed to the high-cost backend. The audit log module is used to save traceable records corresponding to the processing results, and writes at least one of the following into a log, database table or chained hash record: input summary, processing parameters, strategy version, threshold judgment result, output hash and exception handling result.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program or instructions that, when executed by the processor, implement the method according to any one of claims 1 to 8.

Images