API (Application Program Interface) execution method and device for dynamic authority control and storage medium

Abstract

The invention relates to a dynamic authority control API execution method and device and a storage medium, and the method comprises the steps: receiving an API request sent by a user, and carrying out the authority verification of the API request; evaluating the risk of the API request in response to the fact that the permission verification is not passed; issuing a dynamic temporary permission in response to the risk assessment result meeting a threshold value; and completing the API request according to the dynamic temporary permission.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of data management, and in particular, to an application programming interface (API) execution method and device with dynamic permission control, an electronic device, a storage medium, and a program product. BACKGROUND

[0002] An application programming interface (API) is a tool for function coordination and data intercommunication between different programs or databases. Through the interface definition of the API, the developer and user can conveniently call or read the function or data of other programs or databases, reduce the complexity of the system as a whole, and thus reduce the development difficulty and cost.

[0003] In order to protect the security of the interaction between programs or databases, the specific content that can be accessed or modified by each request needs to be limited, that is, the API performs permission control, so that the content of each access is limited to the content that the object of the request access is allowed to access. At present, the authorization and execution of API requests are often performed by granting corresponding permissions to each object of the request access. SUMMARY

[0004] A brief summary of the present disclosure is presented in the following to provide a basic understanding of some aspects of the present disclosure. It should be understood that this summary is not an exhaustive overview of the present disclosure. It is not intended to identify key or critical elements of the present disclosure or to delineate the scope of the present disclosure. Its purpose is merely to present some concepts of the present disclosure in a simplified form as a prelude to the more detailed description presented later.

[0005] According to a first aspect of the present disclosure, an application programming interface (API) execution method with dynamic permission control is provided, comprising: receiving an API request sent by a user, and performing permission verification on the API request; in response to the permission verification failing, evaluating the risk of the API request; in response to the evaluation result of the risk meeting a threshold, issuing a dynamic temporary permission; and completing the API request according to the dynamic temporary permission.

[0006] In some embodiments, evaluating the risk of the API request comprises integrating a risk policy evaluation, a behavior analysis judgment, and a state management control mechanism to generate an evaluation result.

[0007] In some embodiments, the risk policy evaluation comprises configuring a policy rule library for permission risk, thereby performing risk scoring on the API request, wherein the rule library comprises at least one of operation sensitivity, field sensitivity, time window, access geographic location abnormality, and user's belonging system and role matching degree of the API request.

[0008] In some embodiments, the rule base has context-aware capability and maintains the real-time of risk policy rules through dynamic loading and updating.

[0009] In some embodiments, the behavior analysis judgment comprises: constructing a behavior profile of the user based on past behaviors of the user; and using a behavior consistency calculation to determine whether the API request conforms to the behavior profile.

[0010] In some embodiments, determining whether the API request conforms to the behavior profile comprises: in response to the API request not conforming to the behavior profile, displaying an increased risk level in the evaluation result.

[0011] In some embodiments, the state management control comprises: generating a unique ID for the API request and entering a state machine to perform life cycle control on the API request.

[0012] In some embodiments, the life cycle control comprises: through idempotency marking and execution path recording, keeping the results consistent when the operation corresponding to the API request is retried.

[0013] In some embodiments, in response to the evaluation result of the risk meeting a threshold, issuing a dynamic temporary permission comprises: determining the authorization time and authorization scope of the dynamic temporary permission based on the principle of least privilege.

[0014] In some embodiments, completing the API request according to the dynamic temporary permission comprises: generating a temporary authorization token based on the dynamic temporary permission; and automatically retrying the API request using the temporary authorization token.

[0015] In some embodiments, generating a unique ID for the API request and automatically retrying the API request comprises: based on the unique ID, checking whether the API request has repeated processing; and in response to the absence of repeated processing, automatically retrying the API request.

[0016] In some embodiments, using a state machine to monitor the API request and caching the context of the API request, checking whether the API request has repeated processing comprises: based on the unique ID, the state machine and the context, determining whether the API request has been repeatedly processed.

[0017] In some embodiments, a maximum number of retries and a time interval are preset for automatic retry.

[0018] In some embodiments, completing the API request according to the dynamic temporary permission further comprises: converting the API request into an operation instruction for the database.

[0019] According to a second aspect of the present disclosure, there is provided a dynamic permission control API server device, comprising: a network interface module configured to receive an API request sent by a user; a verification module configured to perform permission verification on the API request; a dynamic authorization module configured to, in response to the permission verification failing, evaluate a risk of the API request, and in response to a result of the risk evaluation meeting a threshold, issue a dynamic temporary permission; and an operation module configured to complete the API request according to the dynamic temporary permission.

[0020] In some embodiments, the dynamic authorization module comprises a risk evaluation module, a behavior pattern evaluation module, and a state management module.

[0021] According to a third aspect of the present disclosure, there is provided a computing device, comprising: a memory; and a processor coupled to the memory and configured to execute an API execution method of any of the preceding embodiments based on a computer program stored in the memory.

[0022] According to a fourth aspect of the present disclosure, there is provided a computer-readable storage medium comprising computer program instructions, wherein the computer program instructions, when executed by a processor, implement an API execution method of any of the preceding embodiments.

[0023] According to a fifth aspect of the present disclosure, there is provided a computer program product comprising computer program instructions, wherein the computer program instructions, when executed by a processor, implement an API execution method of any of the preceding embodiments.

[0024] Other features and advantages of the present disclosure will become more apparent from the following detailed description of exemplary embodiments of the present disclosure, taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0025] The accompanying drawings, which form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0026] The present disclosure can be understood more fully by reference to the following detailed description of exemplary embodiments and the accompanying drawings, in which:

[0027] Figure 1 A flowchart of a dynamic permission control API execution method according to an embodiment of the present disclosure is shown;

[0028] Figure 2 A schematic diagram of a dynamic permission control API execution method according to an embodiment of the present disclosure is shown;

[0029] Figure 3 An example block diagram of a dynamic permission control API server device according to an embodiment of the present disclosure is shown;

[0030] Figure 4 A data flow diagram of an API server apparatus of dynamic permission control is shown according to an embodiment of the present disclosure;

[0031] Figure 5 An exemplary block diagram of a computing device that can implement embodiments according to the present disclosure is shown;

[0032] Figure 6 An exemplary configuration of a computing device that can implement embodiments according to the present disclosure is shown.

[0033] Note that, in the following embodiments, the same reference numbers are sometimes used in different drawings to denote the same or similar parts or parts having the same function, and repeated description thereof is omitted. In this specification, like numbers and letters designate like items, and once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

[0034] For ease of understanding, the positions, sizes, ranges, and the like of the structures shown in the drawings and the like are sometimes not actual ones. Therefore, the disclosed application is not limited to the positions, sizes, ranges, and the like disclosed in the drawings and the like. Further, the drawings are not necessarily drawn to scale, and some features can be exaggerated to show details of specific components. DETAILED DESCRIPTION

[0035] Various exemplary embodiments of the present disclosure will now be described in detail below with reference to the accompanying drawings. Note that the relative arrangement, numerical expressions, and numerical values of the components and steps set forth in these embodiments are not limiting to the scope of the present disclosure unless otherwise specifically stated.

[0036] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way limiting to the scope of the disclosure and its applications or uses. Those skilled in the art will recognize that many modifications can be made to the exemplary embodiments and the concepts described herein are intended to be illustrative only and not limiting.

[0037] Techniques, methods, and apparatus known to those of ordinary skill in the relevant art can not be discussed in detail herein, but should be considered as part of the specification, where appropriate.

[0038] The inventors have noticed that the current authorization mechanism for API requests is generally static, and the API works according to the pre-set permissions. When facing temporary additional permission requirements, the increased permission requirements can only be rejected and need to wait for the administrator to manually update, and the corresponding current task can only be ended when the permission verification fails and needs to be resubmitted by the user. This causes waste of time and resources.

[0039] To solve the above problems, the disclosure proposes a dynamic permission control API execution method.

[0040] In an exemplary embodiment of the disclosure, as shown in Figure 1 The dynamic permission control API execution method can include: in step S100, receiving an API request sent by a user, and performing permission verification on the API request; in step S110, in response to the permission verification failing, evaluating the risk of the API request; in step S120, in response to the evaluation result of the risk meeting a threshold, issuing a dynamic temporary permission; and in step S130, completing the API request according to the dynamic temporary permission.

[0041] In some embodiments, upon receiving an API request sent by a user, a user identity token (Token), a calling system ID, a target database identifier, an operation type, a request parameter, a source IP, an operation history, and the like can be extracted. Specifically, the target database identifier can include any target access object in the database, such as a table, a view, a column, an index, a trigger, a process, a constraint, and a rule, etc. The operation type can include creation, addition, deletion, modification, query, reading, and the like. The request parameter can include a path parameter, a query parameter, and the like. After receiving the API request, the API request can be subjected to permission verification by these data.

[0042] In some specific embodiments, the legality of the user and the request itself can be confirmed in step S100 to avoid illegal access and abuse. In one non-limiting embodiment, illegal access behaviors include, but are not limited to, requests for non-existent data; or obviously malicious access, such as using an IP associated with a Trojan program or using a distributed denial of service attack, etc. Abuse behaviors include multiple repeated submission of access requests, which can directly return error information without subsequent steps.

[0043] In some specific embodiments, the permission verification and authorization of the API can employ multi-dimensional rule comprehensive calculation, which can include both attribute-based (ABAC: Attribute Based Access Control) rules and role-based (RBAC: Role Based Access Control) rules. Among them, RBAC adopts pre-defined roles, which carry a set of permissions associated with the role identity, and different roles can have different access permission levels and types; while ABAC makes a comprehensive judgment on the permission according to one or more attribute conditions in the submission request or content. For example, in some specific embodiments, the dimensions of the multi-dimensional rules can include user dimension, role dimension, system dimension, request context dimension, database dimension, database object dimension, operation type dimension, and the like.

[0044] In specific embodiments, the user dimension can include user ID, organization ID, department code, etc. Through the rules of the user dimension, the user identity and organization affiliation can be determined, and the permission limitation of the user level can be realized. For example, for the case where the organization ID and the department code are the finance department, the data related to finance in the database can be open to it, so when the requested content is financial data, authorization can be performed.

[0045] In specific embodiments, the role dimension can include role identifier, permission group, role level and inheritance relationship, role permission mapping rule, etc. Through the rules of the role dimension, the authorization strategy can be matched through the role, and the function and resource access boundary can be controlled in combination with role inheritance or mapping. For example, for the case where the role identifier or the permission group is the administrator, the underlying permissions can be open, allowing the administrator to operate the underlying data.

[0046] In specific embodiments, the system dimension can include system code, call source ID, etc. Through the rules of the system dimension, the legality of the system source of the interface call can be controlled to prevent cross-system unauthorized calls. For example, for the request of the administrator from the task scheduling system to call the underlying data of the finance system, although the administrator role can obtain the permission of the underlying data, the administrator level permission can not be granted in a non-self system to ensure the security of the data.

[0047] In specific embodiments, the request context dimension can include time window, IP address segment, device type, etc. Through the rules of the context dimension, the space-time environment and terminal characteristics where the request is located can be limited, and the dynamic access control capability can be enhanced. For example, for the request made at non-working hours or using a network outside the company or a strange device, since the time range or the request source security is low, only a lower level of permission can be granted to ensure the security of important data.

[0048] In specific embodiments, the database dimension can include database type, instance ID, target address, etc. Through the rules of the database dimension, the target database type and specific address can be specified, and access control across database types can be realized. For example, the secret database and the non-secret database can have different permission requirements, and only the non-secret database can be authorized.

[0049] In specific embodiments, the data object dimension can include database name, table name, field name, etc. Through the rules of the data object dimension, the access permission to the specific object of the database can be controlled, and the object-level fine-grained authorization can be realized. For example, even in the same database, different types of data have different security levels, and only more public data can be authorized, while some sensitive data is not authorized.

[0050] In specific embodiments, the operation type dimension can include structured query language (SQL) operation types, such as data manipulation language (DML), data definition language (DDL), data control language (DCL), data query language (DQL), etc., core commands such as query SELECT, modify UPDATE, create table CREATE TABLE, etc. Through the rules of the operation type dimension, the types of database operations that can be performed by the user can be controlled, distinguishing between data read and write, structure change, permission management, etc. For example, the permission to access data and the permission to add or delete data can have different permission requirements, so that ordinary users only have the permission to access data but not the permission to add or delete data.

[0051] It should be understood that, according to the preset verification condition, for the API request whose permission verification passes, the corresponding data processing or operation request can be directly performed according to part or all of the API request that passes the permission verification.

[0052] In step S110, in response to the permission verification failing, the risk of the API request is evaluated.

[0053] In some embodiments, mechanisms of risk policy evaluation, behavior analysis judgment, and state management control can be integrated to generate an evaluation result of the API request.

[0054] In some embodiments, the risk policy evaluation can include configuring a policy rule library for permission risk, thereby performing risk scoring on the API request, wherein the rule library includes at least one of operation sensitivity, field sensitivity, time window, access geographic location abnormality, and user's belonging system and role matching degree of the API request. Through the policy rule library, the risk of a specific API request can be evaluated to obtain a risk score, so that some API requests with higher risk are less likely to be authorized.

[0055] Specifically, in terms of operation sensitivity, the sensitivity of accessing data can be lower than that of adding or deleting data, and thus is assessed as having a lower risk. In terms of field sensitivity, the sensitivity of accessing internal confidential data (such as personal identity information, financial fields, etc.) can be higher than that of accessing public data, and thus is assessed as having a higher risk. In terms of time window, the time of normal business can be defined as a time of lower risk, and the time other than the time of normal business can be defined as a time of higher risk. In terms of access geographical location abnormality, the geographical location close to the business location can be defined as a region of lower risk, and the geographical location far away from the business location can be defined as a region of higher risk. In terms of matching degree of the system and role to which the user belongs, if the user accesses data belonging to the system to which the user belongs or the identity is matched, it is determined that the risk is lower, for example, the human resource system accesses the identity information of all employees, which is a request of matching identity, and thus the risk is lower.

[0056] In some embodiments, the rule base can also have context awareness capability, and keep the real-time of the risk policy rules through dynamic loading and updating. Specifically, if the behavior of the user before and after the current API request includes other behaviors that increase the reliability of the permission or there is corresponding logic, it can be considered that the rationality of the request of the user is higher, and thus the risk is lower. For example, in the context analysis of the user behavior, it is shown that the user has previously successfully logged in to the internal system, or the previous query has queried low-risk content directly related to the current request, and the like, it can be determined that the API request has a lower risk.

[0057] Additionally, since the management of the database changes in real time, the rule base can cope with changing permission requirements through dynamic loading and updating. For example, in a non-limiting embodiment, data that was originally a trade secret is no longer important, or some newly added data is more needed to be added to the confidential, and the changes of these data rules and parameters can be reflected in the rule base through dynamic loading and updating, so as to keep the real-time of the rules, and avoid the leakage of data with high permission requirements and / or the difficulty of accessing data with low permission requirements. The API request of the user is judged through at least one of the above-mentioned strategy sets, and thus a preliminary risk score is obtained.

[0058] Further, in some embodiments, the behavior analysis judgment can include: constructing a behavior profile for the user's past behavior; and using a behavior consistency calculation to determine whether the API request conforms to the behavior profile. In one non-limiting embodiment, it can be determined whether the user has submitted related, identical or similar requests multiple times in the past period of time (e.g., 30 days). If such requests have been submitted, it indicates that the user has related data access needs, and the current request conforms to the behavior profile. Specifically, the behavior consistency calculation method such as K-neighbor clustering, sliding window evaluation, etc. can be used to determine whether the current request conforms to the behavior profile. In the case where the current API request does not conform to the behavior profile, the risk level can be displayed in the evaluation result to reduce the possibility of authorization. Through the behavior analysis judgment, the authorization decision not only depends on the static rules mentioned above, but also better adapts to the specific behavior patterns of the user.

[0059] In some embodiments, the state management control can include: generating a unique ID for the API request and entering a state machine to control the life cycle of the API request. In one non-limiting embodiment, the state machine for the API request can include the following processes: initial state→waiting for evaluation→temporary authorization→automatic retry→completion / failure. In this way, the corresponding API request can be located according to the unique ID, and the current state of the API request and whether it has been evaluated, etc. can be queried according to the state machine. In this way, repeated judgments on the same API request are avoided, and the operation pressure is reduced. In some specific embodiments, the life cycle control can include: through the idempotency marker and the execution path record, the results of the operation corresponding to the API request remain consistent when the operation is retried.

[0060] Specifically, the state machine can be used to maintain the life cycle of the current request, and the context of the original request can be cached. Before retrying, the system checks the state, and for business data changes, a database unique index or business logic check can be used to prevent repeated processing. Non-limitingly, the automatic retry process can use a distributed lock or atomic operation to ensure idempotency. By judging whether there is an idempotency marker or whether the same core parameters are included in the execution path record, it is determined whether the API request corresponding to the retry process has been executed. Based on this, the past execution process can be directly used, saving resource and time consumption, especially in a high-concurrency or distributed environment, the concurrency safety and consistency of the retry can be ensured, avoiding concurrency conflicts and data inconsistency, and further improving the reliability of the business.

[0061] In step S120, in response to the evaluation result of the risk meeting the threshold, issuing the dynamic temporary permission comprises: integrating the calculation results of the aforementioned risk policy evaluation, behavior analysis judgment and state management control to form a final comprehensive risk score and policy suggestion. Through the synergy of the three, the dynamic rationality and controllability of the insufficient permission API request are determined, thereby ensuring business continuity.

[0062] Additionally, the authorization time limit and authorization scope of the dynamic temporary permission can be determined based on the principle of least privilege. Specifically, temporary permission with a specific time limit and a specific scope can be issued to avoid the risk of misuse of the permission. For example, permission that lasts only 10 to 30 minutes can be issued to avoid the risk of long-term authorization. Additionally or alternatively, permission limited to the current API, current table, current field, and specific operation can be issued to avoid the risk of incorrect authorization of permission beyond the risk evaluation result.

[0063] In step S130, completing the API request according to the dynamic temporary permission can include: generating a temporary authorization token based on the dynamic temporary permission; and automatically retrying the API request using the temporary authorization token. In some embodiments, in order to automatically retry the API, a unique ID generated in the previous step can be generated or read and based on the unique ID, it is checked whether the API request is duplicated; and in response to the absence of duplication, the API request is automatically retried. Specifically, the API request can be monitored using a state machine and the context of the API request is cached, thereby determining whether the API request is duplicated based on the unique ID, the state machine and the context. In the case of granting temporary permission, the API request can be retried to call the access object allowed by the permission, avoiding repeated submission of the API request by the user, making the entire process more coherent, and improving user experience and system robustness.

[0064] In some embodiments, the maximum number of retries and the time interval for automatic retry can also be preset. This can avoid frequent occurrence of failed retry requests, improving the security and stability of the system. It can be understood that the retry strategy can be adjusted in combination with the evaluation of the aforementioned risk policy, and a reasonable maximum number of retries and time interval can be set in combination with the environmental characteristics of data access, thereby ensuring the security and stability of the database.

[0065] In some embodiments, the API request can be converted into an operation instruction for the database. This can standardize the process content of API authorization and API operation to reduce the difficulty of interaction between different API request languages and different target databases, reduce the burden of using and developing interfaces, and improve development efficiency.

[0066] In some embodiments, the whole process can also be structured and logged, including API request content and receiving status, identity verification results, specific decision paths of permission calculation, trigger status of dynamic authorization, evaluation results of dynamic authorization, temporary permission content of dynamic authorization, and final database operation results, etc. Query and audit analysis can be performed in different aspects to improve the security of the whole process and make the process standard and controllable.

[0067] Figure 2 A schematic diagram of the API execution method of dynamic permission control is shown according to an embodiment of the present disclosure.

[0068] Specifically, Figure 2 After the API execution method shown is started, in step S200, the target of the API request sent by the user and the identity information of the user are obtained to verify the user identity and the request content, including but not limited to Token verification, IP verification, and frequency control verification, etc. Next, in step S202, the verification results of step S200 are judged to determine whether the user identity and the request are legal. In response to the verification result being failed (step S202 is judged as “No”), it is determined that the identity and the request are not legal, and step S204 is entered to return error information and end the request process. Alternatively, in response to the verification result being successful (step S202 is judged as “Yes”), it is determined that the identity and the request are legal, and then step S206 is entered to perform dynamic permission calculation. In step S206, the permissions required for the content of the API request are calculated based on the multi-dimensional rules described in the foregoing embodiments, including using ABAC and RBAC, and the permissions possessed by the user who sends the API request, to enter step S208. It can be understood that the above steps S200 to S208 are a refinement of step S100 of the API execution method. Figure 1

[0069] ​Further, in step S208, the two permissions calculated in step S206 are compared to determine whether the permissions meet the rule requirements. In response to the user permissions meeting the required permissions for the requested content (step S208 determines "Yes"), step S216 is entered to complete the API request. Alternatively, in response to the user permissions not meeting the required permissions for the requested content (step S208 determines "No"), step S210 is entered to assess the risk of the request. In step S210, the API request is assessed according to the method described in the foregoing embodiments to enter step S212, where the risk assessment result calculated in step S210 is determined. In response to determining that the risk is higher than the threshold (step S212 determines "No"), step S214 is entered to return an error message and end the current request process; in response to determining that the risk meets the threshold (step S212 determines "Yes"), dynamic temporary permissions can be issued to enter step S216. It can be understood that steps S210 to S216 are a refinement of steps S110 and S120 of the method 100, where the process from step S208 to step S216 corresponds to an API request that passes the permission check, and the process from step S212 to step S216 corresponds to an API request that is granted temporary dynamic permissions as described in the present disclosure. Figure 1 In particular, in step S216, data operations are performed according to the user permissions that meet the permission requirements of the requested information determined in step S208 or the dynamic temporary permissions granted in step S212, including converting the API request into scalable data operation instructions that adapt to multiple databases and multiple data sources. Then step S218 is entered, where the database is operated according to the operation instructions obtained in step S216. It can be understood that steps S216 to S218 are a refinement of step S130 of the method 130.

[0070] In particular, in step S216, data operations are performed according to the user permissions that meet the permission requirements of the requested information determined in step S208 or the dynamic temporary permissions granted in step S212, including converting the API request into scalable data operation instructions that adapt to multiple databases and multiple data sources. Then step S218 is entered, where the database is operated according to the operation instructions obtained in step S216. It can be understood that steps S216 to S218 are a refinement of step S130 of the method 130. Figure 1

[0071] Further, in step S220, the corresponding permissions can be checked again at the end of the database operation to avoid a request content that appears during the operation process and requires higher permissions being completed by a user who has not obtained the corresponding permissions. In the case where the permissions required for the corresponding database operation exceed the user's permissions or the scope of the temporary permissions granted, step S210 is returned to recalculate the corresponding permissions to determine whether to grant the permissions for the corresponding operation. It can be understood that step S220 corresponds to step S130 of the method 130. Figure 1

[0072] Additionally, the entire process can further include step S222 of recording audit logs. In step S222, the entire process from step S200 to step S220 is logged to provide a basis for subsequent monitoring and adjustment of the API execution process. Additionally, the entire process can further include step S222 of recording audit logs. In step S222, the entire process from step S200 to step S220 is logged to provide a basis for subsequent monitoring and adjustment of the API execution process.​

[0073] In the application program interface (API) execution method of dynamic permission control, an API request sent by a user can be received, and permission verification is performed on the API request. Then, in response to the permission verification failing, risk of the API request is evaluated. Then, in response to a result of the risk evaluation meeting a threshold, a dynamic temporary permission is issued. And the API request is completed according to the dynamic temporary permission. In this way, the process of the API request with low risk but no permission can be continued without interruption, and the robustness of the data management system in a high-pressure scenario is improved.

[0074] According to another aspect of the present disclosure, a dynamic permission control application program interface (API) server device is also provided. As shown in Figure 3 The dynamic permission control application program interface (API) server device 300 can include a network interface module 320, a verification module 340, a dynamic authorization module 360, and an operation module 380.

[0075] In some embodiments, the network interface module 320 is configured to receive an API request sent by a user. As a unified API gateway entrance, the network interface module 320 is responsible for receiving API requests from various business systems with high concurrency, and performs preliminary network layer verification.

[0076] In some embodiments, the verification module 340 is configured to perform permission verification on the API request. The permission verification of the verification module 340 can include parsing and verifying a user identity token, verifying a request source IP, and limiting access frequency based on a user or an API. Specifically, the verification module 340 is built-in with a permission calculation engine based on the authorization verification method in the foregoing embodiments, as a core permission decision unit, which includes a permission rule parser, an efficient decision engine, and a multi-dimensional context collector. In one non-limiting embodiment, the engine obtains multi-dimensional permission rules (including rules of an ABAC / RBAC hybrid model) from a permission rule library, and efficiently processes rule matching in combination with a request context to determine operation permissions. The design of the engine ensures millisecond-level response, supports dynamic loading and hot updating of massive rules, and is suitable for high-availability environments.

[0077] In some embodiments, the dynamic authorization module 360 is configured to, in response to the permission check failing, evaluate the risk of the API request, and in response to the evaluation result of the risk meeting a threshold, issue a dynamic temporary permission. The dynamic authorization module 360 dynamically evaluates and generates an authorization token based on the context. It internally contains a risk evaluation module 362 based on risk policy evaluation, a behavior pattern evaluation module 364 based on a behavior analysis model, and a state management module 366 based on state management control. The sub-modules work together: the risk evaluation module 362 evaluates the risk through risk rules, the behavior pattern evaluation module 364 calculates the deviation of the user behavior portrait, and the state management module 366 maintains the state transition and idempotency identification during the request execution process. It can be understood that the dynamic authorization module 360 supports dynamic loading of authorization policies, adapts to different business scenarios and data object security levels, and ensures flexibility and security.

[0078] In some embodiments, the operation module 380 is configured to complete the API request according to the dynamic temporary permission. The operation module 380 internally contains various database adapters (such as MySQL adapter, SQL Server adapter, Oracle adapter, Dream Database adapter, etc.), which can realize seamless interaction with different database types. Thus, it ensures the safe execution of DML, DDL, DCL, and other SQL actions. It is responsible for converting uniform API requests into corresponding database dialects or driving instructions, ensuring the effective transmission and execution of permissions, and performing encryption processing on sensitive data operations.

[0079] The API server device 300 for dynamic permission control can be configured to perform the method according to any of the preceding embodiments of the present disclosure.

[0080] Next, please refer to Figure 4 , Figure 4 The data flow diagram of the API server device for dynamic permission control according to an embodiment of the present disclosure is shown. Among them, in contrast Figure 3 , the API server device includes a network interface module 320, a verification module 340 including an authentication module 342 and a dynamic permission calculation module 344, a dynamic authorization module 360, an operation module 380 including a data operation module 382 and a multi-database instance module 384, etc. The network interface module 320, the dynamic authorization module 360, and the operation module 380 are in communication with Figure 3The functions of the corresponding modules are similar and are not described here. The authentication module 342 is configured to parse the user identity token, and to perform preliminary authentication of the IP source of the request. The dynamic permission calculation module 344 is configured to obtain multi-dimensional permission rules and to calculate a dynamic permission score in combination with the request context. The data operation module 382 is configured to perform data operations on the API request based on the calculation result of the dynamic permission. The multi-database instance module 384 is configured to call the adapters of multiple databases to convert the API request into operation instructions in the language of the corresponding database. Additionally, the API server device can include a permission rule library module 368 and a risk policy / behavior analysis configuration module 370. As can be easily understood, the permission rule library module 368 and the risk policy / behavior analysis configuration module 370 can be integrated in the dynamic authorization module 360 to enable the dynamic authorization module 360 to directly assess the risk of the API request. The permission rule library module 368 and the risk policy / behavior analysis configuration module 370 can also be separately provided as shown in Figure 4 and controlled by the management console module 392, and interact with the dynamic authorization module 360 to enable the dynamic authorization module 360 to assess the risk of the API request.

[0081] In particular, the API server device can also include an audit log module 390 and a management console module 392. In some embodiments, the audit log module 390 is configured to structurally record all key events during the operation of the entire system, in particular API requests, authentication results, permission determination results, intelligent dynamic authorization behaviors (including assessment results, temporary permission details), and finally database operation logs. The audit log module 390 supports pushing data to external log and security analysis platforms, is capable of aggregating and analyzing unified audit information from different database operations, and provides a refined query interface.

[0082] Additionally, in some embodiments, the management console module 392 is configured to provide a user-friendly interface for unified configuration and management of multi-dimensional permission rules, interface registration and publishing, dynamic authorization policy, and parameters of risk policy and behavior analysis model; provide real-time permission monitoring, query and report generation function of audit logs, support centralized management and visual presentation of permissions across databases. Among them, the management console module 392 can interact with the risk policy / behavior analysis configuration module 370, so as to update the risk policy settings and the behavior analysis method. The management console module 392 can also interact with the verification module 340 and the permission rule library module 368, so as to obtain and update the authentication policy. In particular, the management console module 392 can also provide the function of converting the temporary authorization behavior meeting certain conditions, such as being granted temporary permission multiple times and successfully executing, and no security incidents, into access authorization, and converting such temporary authorization into permanent permission rules or policies through explicit approval process or automatic rule triggering mechanism, while ensuring the principle of permission minimization in the rule making process, so as to realize the continuous optimization and automatic evolution of the permission system.

[0083] Further, the data flow of the API execution process is as shown in Figure 4 After the requestor sends the API request data, the network interface module 320 receives it. The network interface module 320 sends the received API request data to the authentication module 342 for authentication and to the audit log 390 module for logging. In the case of authentication failure, the authentication module 342 returns an error message to the requestor, and in the case of authentication success, sends the request data to the dynamic permission calculation module 344, and sends the authentication process and result to the audit log module 390 for logging. The dynamic permission calculation module 344 performs permission calculation on the received request data, and in the case of permission, sends the request data to the data operation module 382, and in the case of insufficient permission, sends the request data to the dynamic authorization module 360, and sends the permission calculation process and result to the audit log module 390 for logging.

[0084] Additionally, the dynamic authorization module 360 interacts with the risk policy / behavior analysis configuration module 370 to obtain the currently configured risk policy and behavior analysis configuration, and interacts with the permission rule library module 368 to obtain the current permission rule library corresponding to the request data, so as to perform dynamic authorization calculation combined with the risk policy and behavior analysis configuration and the permission rule library. In the case of refusing dynamic authorization, an error message is returned to the requestor, and in the case of successful dynamic authorization, the request data is sent to the dynamic permission calculation module 344 together with the dynamic temporary permission to complete the request using the temporary permission, and the authorization evaluation result and the details of the issued temporary permission are sent to the audit log module 390 for logging.

[0085] Additionally, the data operation module 382 sends the request data to the multi-database instance module 384, executes the operation instruction returned by the multi-database instance module 384 and sends the result to the requester to complete the request, and sends to the audit log module 390 for logging. The multi-database instance module 384 converts the request data into operation instructions in the corresponding database language and returns the operation instructions to the data operation module 382, in the event of insufficient rights in the data operation, determines that the current operation fails and sends the corresponding operation instruction back to the dynamic authorization module 360 for dynamic authorization operation. The management console module 392 reads the audit log module 390 and the right rule library module 368 and the risk strategy / behavior analysis configuration module 370 for monitoring and management, and updates the right rule library module 368 and the risk strategy / behavior analysis configuration module 370.

[0086] As shown in Figure 5 The present disclosure also provides a computing device 400 that can include one or more processors 402 and a memory 404 storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the methods described in any of the preceding embodiments of the present disclosure. The processor(s) 402 can be, for example, a central processing unit (CPU) of the computing device 400. The processor(s) 402 can be any type of general purpose processor, or can be a processor specifically designed for API execution, such as an application-specific integrated circuit (“ASIC”). The memory 404 can include various computer-readable media accessible by the processor(s) 402. In various embodiments, the memory 404 described herein can include volatile and non-volatile media, removable and non-removable media. For example, the memory 404 can include any combination of random access memory (“RAM”), dynamic RAM (“DRAM”), static RAM (“SRAM”), read-only memory (“ROM”), flash memory, cache memory, and / or any other type of non-transitory computer-readable media. The memory 404 can store instructions that, when executed by the processor 402, cause the processor 402 to perform the methods described in any of the preceding embodiments of the present disclosure.

[0087] The present disclosure also provides a computer-readable storage medium having computer-executable instructions stored thereon that, when executed by a computer, cause the computer to perform the method according to any one of the preceding embodiments of the present disclosure. When the program runs on a server processor, the server can be driven to perform the unified API permission control method according to the above steps, to realize dynamic permission control, database adaptation operation and behavior auditing functions, and is suitable for multi-system and multi-database scenarios. The storage medium can be various forms of non-volatile storage media, such as hard disks, solid state disks, flash memories, optical disks, etc., to ensure the wide applicability of the implementation scheme.

[0088] The present disclosure also provides a computer program product that can include instructions that, when executed by a processor, can implement the method according to any one of the preceding embodiments of the present disclosure. The instructions can be any instruction set that is executed directly by one or more processors, such as machine code, or indirectly, such as scripts. The instructions can be stored in object code format for direct processing by one or more processors, or in any other computer language, including scripts or collections of independently interpretable or pre-compiled independent source code modules, either on demand or in advance.

[0089] Figure 6 A block diagram of an electronic device according to some other embodiments of the present disclosure is shown.

[0090] Figure 6 The electronic device 600 shown can be a computer system with a dedicated hardware structure, which can perform corresponding functions when the relevant application program is installed.

[0091] As Figure 6 shown, a central processing unit (CPU) 601 performs various processing according to programs stored in a read-only memory (ROM) 602 or loaded from a storage section 608 to a random access memory (RAM) 603. In the RAM 603, data required when the CPU 601 performs various processing, etc. is stored as needed. The central processing unit is merely exemplary and can also be other types of processors. The ROM 602, the RAM 603, and the storage section 608 can be various forms of computer-readable storage media. Note that, although Figure 6 The ROM 602, the RAM 603, and the storage section 608 are shown separately in the above, but one or more of them can be combined or located in the same or different memory or storage modules.

[0092] The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output interface 605 is also connected to the bus 604.

[0093] The following components are connected to the input / output interface 605: an input portion 606, such as a touch panel, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, and the like; an output portion 607, including a display, such as a cathode ray tube (CRT), a liquid crystal display (LCD), a speaker, a vibrator, and the like; a storage portion 608, including a hard disk, a magnetic tape, and the like; and a communication portion 609, including a network interface card, such as a LAN card, a modem, and the like. The communication portion 609 allows communication processing to be performed via a network, such as the Internet. It is easily understood that, although Figure 6 It is easily understood that, although

[0094] The driver 610 is also connected to the input / output interface 605 as necessary. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like, is attached to the driver 610 as necessary, so that a computer program read therefrom is installed in the storage portion 608 as necessary.

[0095] In the case where the above-described series of processes are implemented by software, the program constituting the software can be installed from a network or a storage medium 611 such as a removable medium.

[0096] According to an embodiment of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, some embodiments of the present disclosure include a computer program product that, when run on a computer, causes the computer to implement the method described in any of the preceding embodiments. The computer program product includes computer instructions carried on a computer-readable medium, including program code for executing the method shown in the flowchart. In such an embodiment, the computer instructions can be downloaded and installed from a network by the communication portion 609, or installed from the storage portion 608, or installed from the ROM 602. When the computer program is executed by the CPU 601, the method of the embodiment of the present disclosure is executed.

[0097] It is to be noted that, in the context of the present disclosure, the computer-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0098] The above-described one or more exemplary embodiments of the present disclosure are described. Other embodiments are within the scope of the following claims. In some cases, the acts or steps recited in the claims can be performed in a different order than those in the embodiments and still achieve desirable results. Also, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order in order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

[0099] The systems, apparatuses, modules or units illustrated by the above-described embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present disclosure does not exclude that with the development of computer technology in the future, computers implementing the functions of the above-described embodiments may, for example, be personal computers, laptop computers, in-vehicle human-machine interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, game consoles, tablet computers, wearable devices, or any combination thereof.

[0100] The terms "comprising", "containing", or any other similar words are intended to encompass non-exclusive inclusion, so that processes, methods, products, or devices including a series of elements include not only those elements, but also other elements not explicitly listed, or other elements inherent in such processes, methods, products, or devices. Without more limitations, it does not exclude the presence of other same or equivalent elements in the processes, methods, products, or devices including the elements. For example, if the words "first", "second", etc. are used to indicate names, they do not mean any particular order.

[0101] For the convenience of description, the above apparatus is described as various modules respectively described in function. Of course, in implementing one or more embodiments of the present disclosure, the functions of each module can be implemented in the same or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of multiple sub-modules or sub-units. The above-described apparatus embodiments are only illustrative, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point, the coupling or direct coupling or communication connection between the displayed or discussed each other can be through some interface, indirect coupling or communication connection between the devices or units, and can be electrical, mechanical or other forms.

[0102] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0103] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0104] Those skilled in the art will appreciate that one or more embodiments of the disclosure can be furnished in the form of a software logic for implementation in an analog or digital electronic circuitry or computer hardware, firmware, micro-code, or program to perform the processing functions of the present disclosure. One of ordinary skill in the art will further appreciate that one or more embodiments of the present disclosure can be implemented as a machine-readable storage medium, configured with a computer program, where the storage medium so configured causes a machine to operate as described herein.

[0105] One or more embodiments of the disclosure can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. One or more embodiments of the disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0106] The same parts and / or features of the various embodiments of the present disclosure can be referred to with the same or similar reference numerals. Each embodiment described herein is intended to serve as a representative example only, and is not intended in any way to limit the overall scope of the present disclosure. Furthermore, the various embodiments of the present disclosure can be used together or in various combinations, as would be understood by one of ordinary skill in the art. In the description of the present disclosure, the terms "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" are intended to mean that a particular feature, structure, material, or characteristic is included in at least one embodiment or example of the present disclosure, and is used in certain instances to

[0107] In addition, the words "herein," "above," "below," "nowhere," "above-mentioned," and words of similar meaning, when used in this disclosure, shall not

[0108] The above description is intended to be illustrative and not restrictive. Many other embodiments of the disclosure will suggest themselves to those skilled in the art having the benefit of this disclosure. Therefore, the disclosure should not be limited to the embodiments described herein, but should be given broad coverage.

Claims

1. A method for executing an application programming interface (API) with dynamic access control, comprising: Receive API requests sent by users and perform permission verification on the API requests; In response to the failed permission verification, assess the risk of the API request; If the risk assessment result meets the threshold, a dynamic temporary permission is granted; as well as The API request is completed based on the aforementioned dynamic temporary permissions.

2. The API execution method according to claim 1, wherein, Assessing the risk of the API request includes integrating risk strategy assessment, behavioral analysis and judgment, and state management control mechanisms to generate the assessment results.

3. The API execution method according to claim 2, wherein, The risk strategy assessment includes: Configure a policy rule base for permission risks to perform risk scoring on the API requests. The rule base includes at least one of the following: the API request's operation sensitivity, field sensitivity, time window, access geolocation anomaly, and the user's system and role matching degree.

4. The API execution method according to claim 3, wherein, The rule base has context awareness capabilities and maintains the real-time nature of risk strategy rules through dynamic loading and updating.

5. The API execution method according to claim 2, wherein, The behavioral analysis and judgment include: Build a behavioral profile based on the user's past behavior; and Behavioral consistency calculations are used to determine whether the API request conforms to the behavioral profile.

6. The API execution method according to claim 5, wherein, Determining whether the API request matches the behavioral profile includes: If the API request does not match the behavioral profile, the risk level is increased in the assessment results.

7. The API execution method according to claim 2, wherein, The state management control includes: A unique ID is generated for the API request and entered into a state machine to control the lifecycle of the API request.

8. The API execution method according to claim 7, wherein, The lifecycle control includes: By using idempotency flags and execution path records, the results of retries for the operations corresponding to the API requests are kept consistent.

9. The API execution method according to claim 1, wherein, In response to the risk assessment result meeting the threshold, dynamic temporary permissions are granted, including: The validity period and scope of the dynamic temporary permissions are determined based on the principle of least privilege.

10. The API execution method according to claim 1, wherein, Completing the API request based on the aforementioned dynamic temporary permissions includes: Generate a temporary authorization token based on the aforementioned dynamic temporary permissions; and The API request is automatically retried using the temporary authorization token.

11. The API execution method according to claim 10, wherein, Generating a unique ID for the API request and automatically retrying the API request includes: Based on the unique ID, check whether the API request is processed repeatedly; and If no duplicate processing is found, the API request will be automatically retried.

12. The API execution method according to claim 11, wherein, Using a state machine to monitor the API request and caching the context of the API request, checking for duplicate processing of the API request includes: Based on the unique ID, the state machine, and the context, determine whether the API request has been processed repeatedly.

13. The API execution method according to claim 10, wherein, The maximum number of retries and the time interval are preset for the automatic retries.

14. The API execution method according to claim 1, further comprising completing the API request based on the dynamic temporary permission: The API request is converted into database operation instructions.

15. An application programming interface (API) server device for dynamic access control, comprising: A network interface module, configured to receive API requests sent by users; A verification module, configured to perform permission verification on the API request; A dynamic authorization module is configured to assess the risk of the API request in response to the permission verification failing, and to issue dynamic temporary permissions in response to the risk assessment result meeting a threshold. as well as An operation module is configured to complete the API request based on the dynamic temporary permissions.

16. The API server apparatus according to claim 15, wherein, The dynamic authorization module includes a risk assessment module, a behavior pattern assessment module, and a status management module.

17. A computing device, comprising: Memory; as well as A processor coupled to the memory is configured to execute the API execution method of any one of claims 1-14 based on a computer program stored in the memory.

18. A computer-readable storage medium comprising computer program instructions, wherein, When the computer program instructions are executed by the processor, they implement the API execution method of any one of claims 1-14.

19. A computer program product comprising computer program instructions that, when executed by a processor, implement the API execution method of any one of claims 1-14.

Images