Non-intrusive inference and management method and system applied to business application system credential attribution

Abstract

The application relates to a non-intrusive inference and management method and system applied to the attribution of business application system credentials. The method comprises the following steps: obtaining control plane side data by using a non-intrusive method, and identifying the access relationship of a business application system to a target resource; according to the access relationship, a candidate set to be verified is constructed by correlating and screening weak signals from multiple observation sources; a risk budget in a current time window is calculated based on an authentication failure locking mechanism of the target resource; under the constraint of the risk budget, priority evaluation is performed on candidate objects in the candidate set, and remote restricted verification is sequentially performed; the candidate set is updated according to the verification result, and it is judged whether the convergence condition is met; when the convergence condition is met, the actual used credential object of the business application system is determined and managed. By using the method, the inference efficiency of the attribution of the implicit credential object of the business application system can be improved without invading the business system and interfering with the business operation.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a non-intrusive inference and management method and system for credential ownership in business application systems. Background Technology

[0002] Credentials are information carriers used by business application systems to authenticate themselves when accessing target resources such as databases and middleware. In actual production environments, due to the decentralized system architecture and lack of unified management standards, credential information for a large number of business application systems is scattered across configuration files, environment variables, the registry, or dedicated configuration centers, making it difficult for operations and maintenance personnel to determine which credential each business application system uses to access target resources.

[0003] Privileged Access Management (PAM) systems are typically used to centrally manage privileged credentials within an enterprise. However, before implementing management, PAM systems require credential attribution inference, i.e., determining the credential objects actually used by business application systems. Traditional techniques mainly rely on manual checks, requiring operations personnel to log into the server and check configuration files one by one to find credential information and compare it with records on the target resource side. This approach has the following technical drawbacks: first, the checking efficiency is low, failing to meet the management needs of large-scale systems; second, it easily triggers the authentication failure locking mechanism of the target resource. When manually or using tools to verify candidate credentials in batches, multiple failed attempts may lead to the business application system being locked, causing production interruptions.

[0004] Therefore, how to efficiently and securely infer the credential objects actually used by business application systems is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] Therefore, it is necessary to provide an efficient and secure method and system for inferring and managing the ownership of credentials in business application systems, addressing the aforementioned technical issues.

[0006] Firstly, this application provides a non-intrusive inference and management method for credential ownership in business application systems, the method comprising:

[0007] Non-intrusive methods are used to acquire control plane data and identify the access relationships of business application systems to target resources;

[0008] Based on the access relationship, a candidate set to be verified is constructed by correlating and filtering weak signals from multiple observation sources. The weak signals are evidence of the existence of indirect inference credentials obtained by non-invasive means.

[0009] Based on the authentication failure locking mechanism of the target resource, calculate the risk budget within the current time window, where the risk budget is the number of credential verifications allowed to be performed within the current time window;

[0010] Under the constraint of the risk budget, the candidate objects in the candidate set are prioritized and selected, and remote restricted verification is performed on the selected candidate objects in sequence;

[0011] Based on the verification results, update the candidate set and determine whether the preset convergence condition is met;

[0012] If the convergence condition is not met and the preset maximum number of verifications has not been reached, the determination of the risk budget, the selection and verification of the candidate objects, and the updating of the candidate set are repeated until the convergence condition is met.

[0013] When the convergence condition is met or the preset maximum number of verifications is reached, the credential object actually used by the business application system is determined based on the updated candidate set, and the management information is output.

[0014] In one embodiment, acquiring control plane-side data and identifying the access relationships of business application systems to target resources includes:

[0015] The interaction data between the business application system and the target resource is collected from the control plane side device, which includes a network control device and a bastion host. The control plane side data includes the connection information of the network control device and the audit logs of the bastion host.

[0016] From the interaction data, the access relationship between the business application system and the target resource is extracted. The access relationship includes the business application system identifier, the target resource identifier, the access protocol type, and the time characteristics of the access behavior.

[0017] In one embodiment, the step of constructing a candidate set to be verified by correlating and filtering weak signals from multiple observation sources based on the access relationships includes:

[0018] Weak signals are acquired from multiple observation sources, including the control plane side device and a preset management information database. The weak signals are acquired through runtime characteristics, interface behavior, or access patterns without directly reading the configuration files or logs of the business system.

[0019] Using the access relationship as a constraint, the weak signals are correlated and matched to filter out candidate objects that match the constraint, and all candidate objects are combined into a candidate set. The attributes of the candidate objects include target resource identifier, account type, access protocol type and data source.

[0020] In one embodiment, the risk budget is calculated as follows:

[0021] Obtain the authentication failure lock threshold of the target resource within the unit time window;

[0022] Get the number of authentication failures that have occurred within the current time window;

[0023] Calculate the difference between the authentication failure lockout threshold and the number of authentication failures, and use the minimum of the difference and the maximum number of verifications within a preset unit time window as the risk budget for the current time window.

[0024] In one embodiment, under the constraint of the risk budget, sequentially performing verification on the candidate objects further includes:

[0025] Calculate the risk cost of a single credential verification, where the risk cost is the maximum number of authentication failures that can be triggered by the single credential verification.

[0026] Verification is permitted when the risk cost is less than or equal to the risk budget within the current time window.

[0027] After the verification is completed, the risk budget for the current time window will be deducted based on the actual number of authentication failures.

[0028] When the risk budget is exhausted, the verification of the current time window is paused, and the unverified candidates are postponed to the next time window for processing.

[0029] In one embodiment, prioritizing the candidate objects in the candidate set includes calculating the verification priority of each candidate object based on a joint assessment of the verification benefits and verification risk costs of the candidate object.

[0030] In one embodiment, updating the candidate set based on the verification results includes:

[0031] If the verification is successful, the verified candidate object will be marked as a confirmation credential, and the conflicting object in the candidate set will be removed. The conflicting object is another candidate object that has a mutually exclusive, substitutive, or exclusionary relationship with the candidate object in terms of authentication attribution, and cannot be established as the true attribution object at the same time.

[0032] If the verification fails, the verified candidate object is removed from the candidate set.

[0033] If the verification result is indeterminate, the candidate object being verified will be retained and the subsequent verification priority will be adjusted.

[0034] In one embodiment, the remote restricted verification only performs the authentication phase or the least privilege verification phase. After the verification is completed, the connection is terminated immediately, no persistent session is created, no data write operation is performed, and no business-level resource allocation is triggered.

[0035] In one embodiment, the convergence conditions include: there is only one candidate object remaining in the candidate set, there is a candidate object that has been successfully verified, the rate of change of the candidate set is lower than a preset threshold in multiple consecutive verification cycles, and the preset maximum number of verifications is reached.

[0036] Secondly, this application also provides a non-intrusive inference and management system for credential ownership in business application systems, comprising:

[0037] The runtime interactive observation module is used to acquire control plane side data in a non-intrusive manner and identify the access relationships of business application systems to target resources;

[0038] The candidate set initialization module is used to construct a candidate set to be verified by correlating and filtering weak signals from multiple observation sources. The weak signals are evidence of the existence of indirect inference credentials obtained by non-invasive means.

[0039] The risk budget calculation module is used to calculate the risk budget within the current time window based on the authentication failure locking mechanism of the target resource. The risk budget is the number of credential verifications allowed to be performed within the current time window.

[0040] The verification, evaluation, and execution module is used to prioritize and select candidate objects in the candidate set under the constraints of the risk budget, and to perform remote restricted verification on the selected candidate objects in sequence.

[0041] The convergence verification module is used to update the candidate set based on the verification results and determine whether the preset convergence condition is met. When the convergence condition is not met and the preset maximum number of verifications has not been reached, the determination of the risk budget, the selection and verification of the candidate objects, and the updating of the candidate set are repeated until the convergence condition is met.

[0042] The management output module is used to determine the credential object actually used by the business application system based on the updated candidate set when the convergence condition is met or the preset maximum number of verifications is reached, and to output the management information.

[0043] The aforementioned non-intrusive inference and management method and system for credential ownership in business application systems obtains the access relationships of business application systems to target resources and associates them with weak signals to construct a candidate set. This avoids the need for manual system-by-system configuration file checks and improves the efficiency of credential ownership inference. Based on this, a risk budget for an authentication failure locking mechanism is introduced, and candidate objects are prioritized under the constraint of the risk budget. This avoids the risk of production interruption caused by triggering the target resource locking mechanism due to batch verification, thereby achieving efficient and secure credential management. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is an application environment diagram of a non-intrusive inference and management method for credential ownership in a business application system, as shown in one embodiment.

[0046] Figure 2 This is a flowchart illustrating a non-intrusive inference and management method for credential ownership in a business application system, as shown in one embodiment.

[0047] Figure 3 This is a flowchart illustrating the steps involved in calculating the risk budget in one embodiment.

[0048] Figure 4 This is a flowchart illustrating the verification convergence mechanism for the candidate set in another embodiment;

[0049] Figure 5 This is a block diagram of a non-intrusive inference and management system for credential attribution in a business application system, as shown in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] Privileged Access Management (PAM) systems are platforms within enterprise data centers used for centralized management of user accounts and credentials across all assets and devices. However, the account and credential management capabilities of existing mainstream PAM systems are primarily geared towards infrastructure assets such as operating systems, databases, and domain environments, and have limitations for business application system scenarios. Credentials in business application systems often exist in the runtime structure in the form of implicit references, making it impossible to verify ownership through account enumeration or full login verification. Furthermore, in high-security production environments, intrusive operations such as deploying agents and reading business configuration files are generally not permitted, making it difficult to automate the management of credentials for business application systems.

[0052] To address the aforementioned issues, this application provides a non-intrusive method for inferring and managing credential ownership in business application systems. Figure 1 The system architecture shown comprises two parts: the PAM system service platform 110 and the user data center 120. The PAM system service platform, in addition to existing product modules such as PAM audit data, PAM credential vault, PAM work order module, and PAM governance module, also includes a new module for business application credential inference and verification to execute this method.

[0053] The user data center includes a control plane device 121, a user business application system 122, and target resources 123. The control plane device provides runtime interaction data to the PAM system service platform; the business application server accesses the target resource server via credentials. Based on the acquired interaction data, the PAM system service platform obtains a candidate set from the target resource server, verifies it under risk budget constraints, and ultimately determines and manages the credentials actually used by the business application.

[0054] In one exemplary embodiment, such as Figure 2 As shown, a non-intrusive inference and management method for credential ownership in business application systems is provided. This method is applied to... Figure 1 Taking the PAM server in the example, the following steps are included:

[0055] Step S201: Use non-intrusive methods to acquire control plane side data and identify the access relationships of business application systems to target resources.

[0056] The non-intrusive method refers to collecting data from a control plane device independent of the business application system without deploying an agent on the business application system side, reading the business application system's configuration files or log files, or performing any write operations on the business application system. The control plane is the part of a computer network architecture used for decision-making and routing. Control plane data is data collected and observed on the control plane side that describes the communication relationship between the business application system and the target resource. This typically includes, but is not limited to, network traffic logs, firewall access records, and service dependency topology. Access relationships are represented by the IP address, port, service name, or instance identifier of the target resource accessed by the business application system using specific protocols (such as JDBC, HTTP, RPC, etc.). This information is used to infer the authentication credentials that the business application system may use during operation and serves as input conditions for constructing subsequent candidate sets.

[0057] It is understandable that in enterprise information systems, when business application systems access databases, operating systems, API services, or other infrastructure resources, they usually need to establish a connection through an authentication process. This authentication process must use some form of credential object, such as account passwords, access keys, or tokens.

[0058] Therefore, when the system observes a stable access relationship between a business application system asset and a target resource, it can infer that the access behavior must have used some kind of credential object for authentication during operation. Based on this principle, this invention obtains the access relationship of a business application system through control plane side data without reading the internal configuration or logs of the business application system.

[0059] Step S202: Based on the access relationship, a candidate set to be verified is constructed by correlating and filtering weak signals from multiple observation sources.

[0060] The observation sources include the control plane-side devices and a pre-set management information database. Weak signals refer to evidence indirectly inferred from runtime characteristics, interface behavior, and access patterns without directly reading configuration files or logs. Candidate objects are objects to be verified that may correspond to the true authentication attribution of a specific business application system access relationship, selected based on access relationships observed from the control plane, target resource information, protocol type, account mapping relationships, historical audit information, naming rules, or management information. Candidate objects can be account objects, credential objects, or account-credential association units related to authentication. The candidate set is the set of potentially existing account or credential objects inferred through weak signal analysis.

[0061] For example, the candidate set can be represented as:

[0062]

[0063] in, This represents the initial state of the candidate set. Let represent a single candidate object in the set, and n represent the number of candidate objects. Each candidate object... Includes, but is not limited to, the following attributes: target resource identifier, account type, access protocol type, and data source.

[0064] Step S203: Based on the authentication failure locking mechanism of the target resource, calculate the risk budget within the current time window. The risk budget is the number of credential verifications allowed to be performed within the current time window.

[0065] Once the candidate object is determined, it needs to be verified in the target resource to determine the object actually used by the business application system when accessing the target resource.

[0066] It is understandable that in business application system environments, account or credential verification operations typically need to be completed through authentication interfaces or protocols, such as SSH authentication, database login authentication, or API signature authentication. Most operating systems, databases, or authentication services have authentication failure counting policies, such as the deny parameter in Linux PAM, the lockoutThreshold in Active Directory, and database login failure locking policies. These policies specify the maximum number of authentication failures allowed within a certain time window. Consecutive authentication failures usually trigger account locking and security alerts, frequent authentication attempts also trigger security policies, and high-concurrency authentication requests can also impact system resources. Therefore, directly performing batch verification on multiple objects in the candidate set may lead to the aforementioned problems in the target system. To avoid these problems, this invention introduces a risk budget mechanism in the verification control process.

[0067] Based on the principle of this risk budget mechanism, for example, if the maximum number of authentication failures allowed by the target system and the number of authentication failures already recorded within the current time window are known, the remaining risk budget can be obtained by the difference between the two or by using the difference to apply further constraints.

[0068] Step S204: Under the constraint of risk budget, prioritize and select candidate objects in the candidate set, and perform remote restricted verification on the selected candidate objects in sequence.

[0069] After the candidate set is constructed and the risk budget has been calculated, in order to reduce the cost of trial and error, this invention selects the most suitable object from the candidate set to perform remote restricted verification, thereby minimizing the candidate set with the fewest verification actions.

[0070] Priority evaluation refers to assessing the likelihood of a candidate credential being valid based on its attributes and historical information. Evaluation criteria include, but are not limited to: credential creation time, most recent usage time, usage frequency, number of associated application systems, credential strength, and similarity of configuration paths. Under the constraint of a risk budget, only one or more of the highest-priority candidates are selected for verification at a time.

[0071] Step S205: Update the candidate set based on the verification results and determine whether the preset convergence conditions are met.

[0072] It is understandable that the convergence control mechanism is used to dynamically update the candidate set based on the verification results and determine whether the confirmation conditions are met. The convergence process of the candidate set is manifested as the number of candidate objects gradually decreasing until the convergence conditions are met.

[0073] The verification results typically include states such as verification success, verification failure, verification timeout, or indeterminate. Updating the candidate set based on the verification results can be achieved by: marking successfully verified objects as suspected genuine credentials; removing or lowering the priority of objects that failed verification; or further narrowing the candidate range based on the exception information returned by verification failures.

[0074] Convergence conditions include, but are not limited to: only one candidate remains in the candidate set, the confidence level of the successfully verified candidate reaches a preset threshold, the risk budget is exhausted and verification cannot continue, and the results of multiple consecutive verifications remain unchanged.

[0075] Step S206: Determine whether the preset maximum number of verifications has been reached.

[0076] Step S207: When the convergence condition is not met and the preset maximum number of verifications has not been reached, repeat the determination of the risk budget, the selection and verification of the candidate objects, and the updating of the candidate set until the convergence condition is met.

[0077] Step S208: When the convergence condition is met or the preset maximum number of verifications is reached, determine the credential object actually used by the business application system based on the updated candidate set, and output the management information.

[0078] When the convergence condition is met or the preset maximum number of verifications is reached, the system extracts the credential object actually used by the business application system from the converged candidate set and outputs the credential object as the managed object of the PAM system. The managed output mechanism is used to transform the confirmation result into an executable management operation.

[0079] Specifically, the methods for determining the actual credential object to be used include: if there is only one candidate object left in the candidate set, it is directly confirmed as the real object; if there are multiple candidate objects but one of them has a significantly higher confidence level than the others, it is confirmed as the real object and a confidence level label is attached.

[0080] If the candidate object is a credential object, it is confirmed as a genuine credential; if the candidate object is an account object, the credential object corresponding to the account object is obtained from the PAM system; if the candidate object is an account-credential association unit, the credential object is extracted from it and used as a genuine credential.

[0081] The above method establishes access relationships by acquiring control plane data and constructs a candidate set by associating weak signals. It eliminates the need to deploy agents on the business system side, read configuration files or log files, or perform write operations, thus avoiding the inefficiency of traditional manual investigation methods. At the same time, it introduces a risk budget constraint on the number of verifications based on an authentication failure locking mechanism. Within the budget, it prioritizes and iteratively verifies candidate objects, controls the verification frequency through risk budget, avoids interference with the business system through remote restricted verification, and prevents production interruptions caused by target resource locking mechanisms triggered by batch verification. This achieves efficient, secure, and non-intrusive attribution inference and management of credentials for business application systems.

[0082] In one exemplary embodiment, to improve verification efficiency, the verification process is implemented using a Restricted Remote Verification Model (RRVM).

[0083] The Remote Restricted Authentication Mechanism (RRVM) is used to verify the authenticity of candidate objects without affecting the operation of business systems. Unlike the full login authentication in existing technologies, RRVM is a restricted remote authentication call structure initiated based on existing authentication protocols. It only performs the authentication phase or the least privilege verification phase and terminates the connection immediately after the authentication result is returned. This mechanism has the following characteristics:

[0084] (1) Only the authentication phase is performed. The authentication process only completes the authentication handshake or credential verification and does not perform any business operations. For example: the SSH protocol only performs the authentication handshake and does not enter the shell session; the database protocol only performs the login phase and does not perform SQL queries; API authentication only performs the signature verification request.

[0085] (2) No persistent session is created. The connection is closed immediately after the verification process is completed, and no persistent session is established.

[0086] (3) No write operations are performed. No data write operations are performed during the verification process, and the target system state is not modified.

[0087] (4) Do not trigger resource allocation. Control the allocation of business-level resources through protocol parameters to avoid triggering resource allocation, such as: do not create database transactions, do not create remote session objects, and do not execute application interface calls.

[0088] Remote restricted authentication can obtain authentication capabilities through existing credentials, temporary credentials, authentication verification interfaces, or credential rotation mechanisms. During execution, the PAM system first constructs an authentication request based on the candidate object, and then sends the authentication request to the target resource through the corresponding protocol. Once the authentication response result is received, the connection is terminated immediately.

[0089] In other embodiments, other verification methods can also be used to achieve remote verification of the validity of credential objects. Examples include API authentication interface verification, OAuth or Token validity verification interfaces, cloud platform IAM authentication interfaces, and authentication gateway verification interfaces. These verification methods do not require execution locally on the business application system, avoiding the security risks associated with executing commands or reading configuration files on the target server. Furthermore, they allow for flexible selection of appropriate verification interfaces based on the target resource type and credential format, thus improving the security of the verification operation.

[0090] In an exemplary embodiment, step S201, acquiring control plane side data and identifying the access relationship between the business application system and the target resource includes the following steps:

[0091] Step S301: Collect interaction data between the business application system and the target resource from the control plane side device.

[0092] For example, control plane devices include network control devices and bastion hosts. Network control devices can acquire network control plane data at the data center inlet, which is typically collectable and observable. These devices include switches, routers, firewalls, or load balancers, and can provide network connection statistics such as source address, destination address, protocol type, and connection frequency. Furthermore, enterprises typically deploy bastion hosts to control access to equipment assets and business application systems within the data center and to perform operational audits. Audit logs are collectable and observable. During access control, audit data such as session establishment, access targets, and authentication results are recorded. This information reflects the actual access relationship between business systems and target resources.

[0093] In some other embodiments, the sources of control plane side data may also include logs from more network traffic acquisition devices and gateway devices, such as network traffic analysis systems, API gateway access logs, cloud platform access logs, and other data sources that can reflect the access relationship between business application systems and target resources.

[0094] Step S302: Extract the access relationship between the business application system and the target resource from the interaction data. The access relationship includes the business application system identifier, the target resource identifier, the access protocol type, and the time characteristics of the access behavior.

[0095] By performing correlation analysis on the above data, the access relationship between the business application system and the target resource can be obtained:

[0096] Ref=(SourceAsset,TargetEndpoint,Protocol,TimePattern)

[0097] Here, SourceAsset represents the business application system asset; TargetEndpoint represents the target resource being accessed; Protocol represents the access protocol type; and TimePattern represents the temporal characteristics of the access behavior. This access relationship is used to infer the authentication credentials that the business application system may use during operation and serves as input conditions for constructing subsequent candidate sets.

[0098] In one embodiment, based on the aforementioned access relationships, a candidate set to be verified is constructed by correlating and filtering weak signals from multiple observation sources, including:

[0099] Weak signals are acquired from multiple observation sources, including the control plane side device and a preset management information database. The weak signals are evidence that indirectly infers the existence of credentials through runtime characteristics, interface behavior, or access patterns without directly reading the configuration files or logs of the business system.

[0100] Using the access relationship as a constraint, the weak signals are correlated and matched to filter out candidate objects that match the constraint, and all candidate objects are combined into a candidate set. The attributes of the candidate objects include target resource identifier, account type, access protocol type and data source.

[0101] For example, the candidate set is primarily derived from the target system's account object list or authentication entity list; the PAM account database is used to supplement the historical accounts and naming rule matching items in the candidate set, mainly derived from the following data: the target system's account list / key list, managed account objects associated with the target resource in the PAM account database, historical audits / naming rules / CMDB, account types filtered according to access protocol type, and account sets inferred from asset access relationships, etc. Through the above constraints, an initial candidate set can be constructed. .

[0102] In one embodiment, such as Figure 3 As shown, the risk budget can be calculated in the following way:

[0103] Step S401: Obtain the authentication failure locking threshold LockoutThreshold for the target resource within a unit time window.

[0104] Step S402: Obtain the number of authentication failures that have occurred within the current time window: FailureCount(t).

[0105] Step S403: Calculate the difference between the authentication failure lockout threshold and the number of authentication failures. Use the minimum of the difference and the maximum number of verifications within the preset unit time window as the risk budget for the current time window.

[0106] Among them, after predefining the maximum number of verifications allowed within a unit time window (MaxVerificationPerWindow), the risk budget is defined as:

[0107] RiskBudget(t)=min(LockoutThreshold-FailureCount(t),MaxVerificationPerWindow)

[0108] Furthermore, in one embodiment, under the constraint of a risk budget, sequentially performing verification on candidate objects further includes the following steps:

[0109] Step S501: Calculate the risk cost of a single credential verification, where the risk cost is the maximum number of authentication failures that can be triggered in a single credential verification.

[0110] For remote authentication actions, this invention defines their risk cost as the increased number of authentication failures that the authentication action may cause in the target system. This represents the failure count increment for the i-th authentication action. In most authentication protocols, each authentication failure increases the failure count by 1. Therefore, we can conclude that:

[0111]

[0112] However, for some authentication methods, there may be multiple failed attempts, such as multi-stage authentication processes and automatic retry mechanisms. In this case:

[0113]

[0114] in, This represents the maximum number of failures that the authentication process may trigger.

[0115] Step S502: When the risk cost is less than or equal to the risk budget within the current time window, verification is allowed.

[0116] It is understood that the verification action is only allowed to be executed if the following conditions are met:

[0117]

[0118] If the conditions are not met, the verification action will be delayed or skipped.

[0119] Step S503: After the verification is completed, deduct the risk budget within the current time window based on the actual number of authentication failures.

[0120] Step S504: When the risk budget is exhausted, pause the verification of the current time window and postpone the processing of unverified candidates to the next time window.

[0121] In the above embodiments, by calculating the risk cost of a single verification and comparing it with the current risk budget, it is possible to prevent accounts from being locked due to batch verification. Through dynamic control of the risk budget, verification efficiency is improved. By deducting the risk budget based on the actual number of authentication failures and defining risk costs differently, it is possible to avoid overspending due to underestimating risk costs.

[0122] In one embodiment, prioritizing candidates in the candidate set includes a joint assessment of the verification benefits and verification risk costs of each candidate, calculating the verification priority of each candidate. Specifically, this can be determined by analyzing the following factors:

[0123] (1) Access Relationship Stability: Access stability describes the stability of the access relationship between the business application system and the target resource, such as access frequency and access duration. If an access relationship persists for a long period of time, it indicates that the access behavior is very likely to rely on a fixed credential object to complete the authentication. Therefore, the higher the access stability, the higher the verification priority of the corresponding candidate object.

[0124] (2) Account matching degree: The candidate object contains account type information, such as database account, operating system account, and API access key. When the access protocol type and account type are highly matched, for example, the MySQL protocol access corresponds to the database account and the SSH protocol access corresponds to the operating system account, the candidate object is more trustworthy and should be verified first.

[0125] (3) Risk cost of single voucher verification: It is understandable that when the risk budget is limited, candidates with lower verification costs should be given priority.

[0126] (4) Historical verification results information: If a candidate has failed multiple times in historical verification, its priority should be reduced to avoid repeatedly consuming risk budget.

[0127] By comprehensively analyzing the above factors, the verification priority of each candidate object can be calculated. Based on the verification priority, the candidate set is sorted to generate a verification action queue.

[0128] In one embodiment, when updating the candidate set based on the verification results, the following verification results are included:

[0129] If the verification is successful, the verified candidate object is marked as confirmed, and the object that conflicts with it in the candidate set is removed.

[0130] Among them, conflicting objects are other candidate objects that have a mutually exclusive, substitutive, or exclusionary relationship with the candidate objects in terms of authentication attribution, and cannot be simultaneously established as the true attribution objects.

[0131] If the verification fails, it means that the candidate object is not actually used, and the verified candidate object is removed from the candidate set.

[0132] If the verification result is indeterminate, such as due to network anomalies or access control restrictions, the candidate object being verified will be retained and its subsequent verification priority will be adjusted for re-evaluation in subsequent rounds.

[0133] In one embodiment, after the candidate set is updated, the system performs a convergence determination. The convergence conditions include the following:

[0134] When only one candidate object remains in the candidate set, it can be confirmed that the candidate object is the real object.

[0135] If there are candidate objects that have been successfully verified, the objects that have been successfully verified will directly become the confirmation results.

[0136] When the preset maximum number of verifications is reached, and the candidate set no longer changes in multiple verification cycles, the system considers the set to have converged.

[0137] In addition, in specific implementation, the following methods can be selected for convergence determination according to the actual situation: such as the probability of candidate objects exceeding the set threshold, the confidence level stabilizing after multiple rounds of verification, and the change rate of the candidate set being lower than the preset threshold.

[0138] In the above embodiments, the verification efficiency of credentials is effectively improved through the candidate set convergence mechanism.

[0139] In a detailed embodiment, such as Figure 4 As shown, the verification convergence mechanism for the candidate set includes the following steps:

[0140] Step S601: Input the access relationship and the initial candidate set.

[0141] Step S602: Calculate the risk budget.

[0142] Step S603: Determine whether the risk budget meets the convergence conditions.

[0143] If the judgment result is yes, then proceed to step S604.

[0144] If the judgment result is negative, then proceed to step S605.

[0145] Step S604: Output the management result.

[0146] Step S605: Determine whether the risk budget is sufficient.

[0147] If the judgment result is negative, then proceed to step S606.

[0148] If the judgment result is yes, then proceed to step S607.

[0149] Step S606: End the current time window, output "Uncertain", and proceed to the next time window. Then return to execute step S602.

[0150] Step S607: Perform verification action evaluation and select the optimal candidate.

[0151] Step S608: Perform remote restricted verification.

[0152] Step S609: Determine the verification result.

[0153] If the verification result is successful, then proceed to step S610.

[0154] If the verification result is that the verification failed, then proceed to step S611.

[0155] If the result is uncertain, then proceed to step S612.

[0156] Step S610: Update the candidate set, confirm and remove conflicting candidate objects, and then return to execute step S602.

[0157] Step S611: Update the candidate set, remove failed candidate objects, and then return to execute step S602.

[0158] Step S612: Update the candidate set, postpone or reduce the priority of relevant candidate objects, and then return to step S602.

[0159] In one embodiment, once the candidate set meets the convergence criteria, the system outputs the confirmed credential object as a managed object of the PAM system. The managed output mechanism is used to transform the confirmation result into an executable management operation. The managed output mainly includes the following parts:

[0160] (1) Voucher object generation: The system generates a standardized voucher object description that meets the internal data structure requirements of the PAM product based on the confirmation result. The content includes, but is not limited to, asset information, account objects and attributes, voucher type, agreement, etc., which constitute the voucher management object in the PAM system.

[0161] (2) Management suggestion generation: The system generates management suggestion records and submits them to the administrator for review. The content includes, but is not limited to, the basis for inferring the source of the voucher, the verification success record, the risk assessment information, and the recommended management strategy.

[0162] (3) Work order generation: The system can automatically generate management work orders to trigger subsequent PAM management processes, such as voucher collection, voucher custody, periodic password change, and voucher inspection.

[0163] (4) Writing of managed objects: After confirmation by the administrator, the system will write the credential object into the PAM credential safe. The credential object can then be included in the unified management scope of the PAM system, including but not limited to: secure storage of credentials, automatic password change, credential access control, auditing and monitoring.

[0164] (5) Continuous learning mechanism: The system can record the data in the verification process as historical knowledge, which can be used to optimize the subsequent candidate set construction and verification scheduling strategy, thereby improving the efficiency of future credential discovery and confirmation.

[0165] In a specific embodiment, taking the order processing system of a certain enterprise data center as an example, the automatic confirmation process of database connection credentials is described in detail.

[0166] The order processing system (business application system) did not have explicit account credential records registered in the PAM system, requiring administrators to manually review configuration files and manage them one by one. However, the system maintained continuous access records to the enterprise database server (target resource) while processing orders.

[0167] First, the runtime interaction observation module discovered the following access relationship through the network control device logs: the business application system is identified as "OrderService", the target resource is identified as "MySQL-DB01", the access protocol type is MySQL protocol, and the access mode is persistent connection pool access. Based on this access relationship, the system infers that the business application system must be using a database account for authentication during runtime.

[0168] Secondly, the account objects associated with the target resource are filtered from the database account list to obtain a candidate set. = {db_app_user, db_report_user, db_admin}. Where db_app_user is the application-specific account, db_report_user is the report query account, and db_admin is the database administrator account.

[0169] Next, the database's authentication failure locking policy is read, with a locking threshold of LockoutThreshold = 10, meaning a lock is triggered after 10 consecutive failures. The database error log is retrieved, showing the number of authentication failures (FailureCount = 2) that have occurred within the current time window. This number of failures could be due to other erroneous operations. Therefore, the available risk budget within the current time window is RiskBudget = LockoutThreshold - FailureCount = 8.

[0170] Next, based on factors such as the matching degree between account type and business application system, and the stability of historical access records, the candidate objects are prioritized, resulting in the verification queue VerificationQueue = {db_app_user→db_report_user→db_admin}. The system first performs remote restricted verification on the highest priority db_app_user. The remote restricted verification module simulates the MySQL login authentication process, performing only the authentication handshake and not any SQL operations. The authentication result returns success.

[0171] Finally, the candidate set is updated based on the verification results. Successfully verified `db_app_user` is retained, while other candidate credentials are removed due to conflicts with successfully verified credentials. The updated candidate set is C = {db_app_user}. This candidate set satisfies the unique convergence condition, and the system confirms that the credential object is the authentication credential actually used by the business application system. The management output module generates management suggestions and creates the corresponding database credential management object in the PAM system, completing the automatic management process.

[0172] In another specific embodiment, taking a microservice architecture environment as an example, the automatic confirmation process of service call token credentials is described in detail.

[0173] In a microservices architecture environment, service A (the business application system) needs to call the internal API interface provided by service B (the target resource). The system observes the following access relationship through the access logs of the service mesh or API gateway: the business application system is identified as "Service-A", the target resource is identified as "Service-B", the access protocol type is HTTP API, and the access pattern is periodic calls.

[0174] First, based on the enterprise's unified authentication architecture, API calls between services typically use service access tokens for authentication. The candidate set initialization module filters token objects from the token management repository that may be used to access service B, thus obtaining the candidate set. = {token_serviceA, token_serviceB, token_shared}. Where token_serviceA is the dedicated call token for service A, token_serviceB is the token used by service B itself, and token_shared is the shared API access token.

[0175] Secondly, we read the API gateway authentication failure locking policy of Service B: the locking threshold LockoutThreshold = 5, which means that a temporary IP ban is triggered after 5 consecutive calls using an invalid token; we also retrieved the authentication failure count (FailureCount = 0) from the gateway access log within the current time window. Therefore, the available risk budget within the current time window is RiskBudget = 5.

[0176] Then, based on information such as the token's issuing object, validity period, and permission scope, the tokens are prioritized to obtain the verification queue VerificationQueue={token_serviceA→token_shared→token_serviceB}. Under risk budget constraints, the system first performs remote restricted verification on token_serviceA by calling the API authentication interface of service B to verify the token's validity. The authentication interface returns that the token is valid and grants the user permission to call service B.

[0177] Upon successful verification, the candidate set is updated, marking `token_serviceA` as successfully verified. Based on the verification result, other candidate credentials are deduced to be invalid, and the updated candidate set is C = {token_serviceA}. This candidate set satisfies the unique convergence condition, and the system confirms that this token is the credential object actually used by the business application system. The management output module includes this token in the PAM management scope and associates it with the application identifier of service A.

[0178] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0179] Based on the same inventive concept, this application also provides a system for implementing the aforementioned non-intrusive inference and management method for credential attribution in business application systems. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations of one or more embodiments of the non-intrusive inference and management system for credential attribution in business application systems provided below can be found in the above-described limitations of the non-intrusive inference and management method for credential attribution in business application systems, and will not be repeated here.

[0180] In one exemplary embodiment, such as Figure 5 As shown, a non-intrusive inference and management system 700 for credential attribution in business application systems is provided, comprising:

[0181] The runtime interactive observation module 701 is used to acquire control plane side data in a non-intrusive manner and identify the access relationship of business application systems to target resources;

[0182] The candidate set initialization module 702 is used to construct a candidate set to be verified by associating and filtering weak signals from multiple observation sources based on the access relationship. The weak signals are evidence of the existence of indirect inference credentials obtained by non-invasive means.

[0183] The risk budget calculation module 703 is used to calculate the risk budget within the current time window based on the authentication failure locking mechanism of the target resource. The risk budget is the number of credential verifications allowed to be performed within the current time window.

[0184] The verification evaluation and execution module 704 is used to prioritize and select candidate objects in the candidate set under the constraint of the risk budget, and to perform remote restricted verification on the selected candidate objects in sequence.

[0185] The convergence verification module 705 is used to update the candidate set according to the verification results and determine whether the preset convergence condition is met. When the convergence condition is not met and the preset maximum number of verifications has not been reached, the determination of the risk budget, the selection and verification of the candidate objects, and the updating of the candidate set are repeated until the convergence condition is met.

[0186] The management output module 706 is used to determine the credential object actually used by the business application system based on the updated candidate set when the convergence condition is met or the preset maximum number of verifications is reached, and to output the management information.

[0187] The modules described above in the non-intrusive inference and management system for credential attribution in business application systems can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0188] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0189] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer 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. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0190] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0191] The embodiments described above are merely examples of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application.

Claims

1. A non-intrusive inference and management method for credential ownership in business application systems, characterized in that, The method includes: Non-intrusive methods are used to acquire control plane data and identify the access relationships of business application systems to target resources; Based on the access relationship, a candidate set to be verified is constructed by correlating and filtering weak signals from multiple observation sources. The weak signals are evidence of the existence of indirect inference credentials obtained by non-invasive means. Based on the authentication failure locking mechanism of the target resource, calculate the risk budget within the current time window, where the risk budget is the number of credential verifications allowed to be performed within the current time window; Under the constraint of the risk budget, the candidate objects in the candidate set are prioritized and selected, and remote restricted verification is performed on the selected candidate objects in sequence; Based on the verification results, update the candidate set and determine whether the preset convergence condition is met; If the convergence condition is not met and the preset maximum number of verifications has not been reached, the determination of the risk budget, the selection and verification of the candidate objects, and the updating of the candidate set are repeated until the convergence condition is met. When the convergence condition is met or the preset maximum number of verifications is reached, the credential object actually used by the business application system is determined based on the updated candidate set, and the management information is output.

2. The method according to claim 1, characterized in that, The acquisition of control plane side data and identification of the access relationships of business application systems to target resources includes: The interaction data between the business application system and the target resource is collected from the control plane side device, which includes a network control device and a bastion host. The control plane side data includes the connection information of the network control device and the audit logs of the bastion host. From the interaction data, the access relationship between the business application system and the target resource is extracted. The access relationship includes the business application system identifier, the target resource identifier, the access protocol type, and the time characteristics of the access behavior.

3. The method according to claim 2, characterized in that, The step of constructing a candidate set to be verified by correlating and filtering weak signals from multiple observation sources based on the access relationships includes: Weak signals are acquired from multiple observation sources, including the control plane side device and a preset management information database. The weak signals are acquired through runtime characteristics, interface behavior, or access patterns without directly reading the configuration files or logs of the business system. Using the access relationship as a constraint, the weak signals are correlated and matched to filter out candidate objects that match the constraint, and all candidate objects are combined into a candidate set. The attributes of the candidate objects include target resource identifier, account type, access protocol type and data source.

4. The method according to claim 1, characterized in that, The risk budget is calculated as follows: Obtain the authentication failure lock threshold of the target resource within a unit time window; Get the number of authentication failures that have occurred within the current time window; Calculate the difference between the authentication failure lockout threshold and the number of authentication failures, and use the minimum of the difference and the maximum number of verifications within a preset unit time window as the risk budget for the current time window.

5. The method according to claim 4, characterized in that, Under the constraint of the risk budget, the verification of the candidate objects in sequence further includes: Calculate the risk cost of a single credential verification, where the risk cost is the maximum number of authentication failures that can be triggered by the single credential verification. Verification is permitted when the risk cost is less than or equal to the risk budget within the current time window. After the verification is completed, the risk budget for the current time window will be deducted based on the actual number of authentication failures. When the risk budget is exhausted, the verification of the current time window is paused, and the unverified candidates are postponed to the next time window for processing.

6. The method according to claim 5, characterized in that, Prioritizing candidates in the candidate set includes calculating the verification priority of each candidate based on a joint assessment of the verification benefits and verification risk costs of the candidate.

7. The method according to claim 1, characterized in that, The step of updating the candidate set based on the verification results includes: If the verification is successful, the verified candidate object will be marked as confirmed, and the conflicting object in the candidate set will be removed. The conflicting object is another candidate object that has a mutually exclusive, substitutive, or exclusionary relationship with the candidate object in terms of authentication attribution, and cannot be established as the true attribution object at the same time. If the verification fails, the verified candidate object is removed from the candidate set. If the verification result is indeterminate, the candidate object being verified will be retained and the subsequent verification priority will be adjusted.

8. The method according to claim 1, characterized in that, The remote restricted authentication only performs the authentication phase or the least privilege verification phase. After the authentication is completed, the connection is terminated immediately, no persistent session is created, no data write operation is performed, and no business-level resource allocation is triggered.

9. The method according to claim 1, characterized in that, The convergence conditions include: there is only one candidate object remaining in the candidate set, there is a candidate object that has been successfully verified, and the rate of change of the candidate set is lower than a preset threshold within multiple consecutive verification periods.

10. A non-intrusive inference and management system for credential attribution in business application systems, characterized in that, The system includes: The runtime interactive observation module is used to acquire control plane side data in a non-intrusive manner and identify the access relationships of business application systems to target resources; The candidate set initialization module is used to construct a candidate set to be verified by associating and filtering weak signals from multiple observation sources based on the access relationship. The weak signals are evidence of the existence of indirect inference credentials obtained by non-invasive means. The risk budget calculation module is used to calculate the risk budget within the current time window based on the authentication failure locking mechanism of the target resource. The risk budget is the number of credential verifications allowed to be performed within the current time window. The verification, evaluation, and execution module is used to prioritize and select candidate objects in the candidate set under the constraints of the risk budget, and to perform remote restricted verification on the selected candidate objects in sequence. The convergence verification module is used to update the candidate set based on the verification results and determine whether the preset convergence condition is met. When the convergence condition is not met and the preset maximum number of verifications has not been reached, the determination of the risk budget, the selection and verification of the candidate objects, and the updating of the candidate set are repeated until the convergence condition is met. The management output module is used to determine the credential object actually used by the business application system based on the updated candidate set when the convergence condition is met or the preset maximum number of verifications is reached, and to output the management information.

Images