Access request security assessment method and device, resource server, storage medium and program product

Abstract

The embodiment of the invention provides an access request security assessment method and device, a resource server, a storage medium and a program product, and relates to the technical field of cloud native security. According to the method, entity attributes, access context, behavior features and environment features in an access request are obtained after identity verification is passed, and the features are input into a pre-trained long-short memory network model to dynamically generate trust scores; therefore, the trust evaluation of the access request is changed from the traditional static rule judgment to an intelligent scoring mechanism based on the multi-dimensional dynamic characteristics. After the trust score exceeds the score threshold and the target policy rule matched with the access request is found in the policy rule base, the access request is processed based on the target policy rule, and refined and dynamic security management of the access request is realized through combination of a multi-dimensional intelligent scoring mechanism and a policy rule matching mechanism; therefore, the security and the intelligent level of access control in the cloud native environment are improved.

Description

Technical Field

[0001] This invention relates to the field of cloud-native security technology, and more specifically, to an access request security assessment method, apparatus, resource server, storage medium, and program product. Background Technology

[0002] In cloud-native systems, applications are deployed in a microservice architecture, with frequent east-west communication between services. Traditional security mechanisms often focus on network boundaries (i.e., north-south traffic), making it difficult to effectively address internal security risks posed by lateral attacks between services. Because microservice instances are often dynamically scheduled and scaled up / down using container technology, the identities, addresses, and communication paths of services are constantly changing. Traditional security policies that rely on static configuration cannot adapt in real time, leading to lagging access control policies, misconfigured permissions, or frequent security blind spots, severely weakening the security capabilities of cloud-native systems.

[0003] Furthermore, cloud-native systems emphasize elastic scaling, continuous delivery, and automated operation and maintenance. Traditional access control mechanisms based on fixed Internet Protocol (IP) addresses or preset rules are insufficient to meet the security policy implementation requirements in dynamic resource environments. To address these challenges, it is urgent to build a security protection system adapted to cloud-native systems to effectively manage east-west traffic risks and flexibly respond to dynamic resource environments. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide an access request security assessment method, apparatus, resource server, storage medium and program product that can improve the security and intelligence level of access control in a cloud-native environment.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows: In a first aspect, the present invention provides an access request security assessment method, applied to a resource server in a cloud-native system, the method comprising: Authenticate the accessing entity based on the access request; If authentication is successful, the entity attributes in the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, are obtained. The entity attributes, access context, behavioral features, and environmental features are then input into a pre-trained long short-term memory network model to obtain a trust score. The entity attributes are used to characterize the scope of access permissions, the access context is used to characterize the real-time environmental information when the access request occurs, the behavioral features are used to characterize the degree of abnormality in access frequency, and the environmental features characterize the state information of the environment accessed by the access request. If the trust score exceeds the score threshold, determine whether there is a target policy rule in the policy rule base that matches the access request; If a target policy rule matches the access request, the access request is processed based on the target policy rule.

[0006] In an optional implementation, the access entity includes a user, device, and service account; the step of authenticating the access entity based on the access request includes: The user's identity information, the device's device information, and the service account's service account information are obtained from the access request, respectively. The entity registry is searched based on the user's identity information, the device's device information, the service account's service account information, and the correspondence between the user, the device, and the service account. If the entity registry contains a user identity identifier, device identity identifier, and service account identity identifier that correspond to the user identity information, device information, and service account information, and there is an association relationship that corresponds to the user, device, and service account, then the identity verification is deemed successful.

[0007] In an optional implementation, determining whether a target policy rule matching the access request exists in the policy rule base includes: The policy rules in the policy rule base are matched and validated based on entity attributes, access context, behavioral characteristics, and environmental characteristics. If a matching policy rule exists, the matching policy rule is determined as the target policy rule corresponding to the access request; If multiple matching policy rules exist, the policy rule with the highest priority among the matching policy rules is determined as the target policy rule corresponding to the access request.

[0008] In an optional implementation, the method further includes: When the health status of the accessed environment is abnormal or the accessed environment receives more access requests than the request threshold within a preset time, the policy rules corresponding to the accessed environment in the policy rule base are adjusted.

[0009] In an optional implementation, after obtaining the entity attributes in the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, if authentication is successful, and inputting the entity attributes, access context, behavioral features, and environmental features into a pre-trained long short-term memory network model to obtain a trust score, the method further includes: If the trust score does not exceed the score threshold, secondary authentication is triggered, and additional authentication information from the user is received. If the additional authentication information fails to be verified, the access request is blocked. If the additional authentication information is verified and a target policy rule matching the access request exists in the policy rule base, the access request is processed based on the target policy rule.

[0010] In an optional implementation, after obtaining the entity attributes in the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, if authentication is successful, and inputting the entity attributes, access context, behavioral features, and environmental features into a pre-trained long short-term memory network model to obtain a trust score, the method further includes: If the trust score exceeds the scoring threshold and there is no target policy rule in the policy rule base that matches the access request, the access request is processed based on the default policy rule.

[0011] Secondly, the present invention provides an access request security assessment device, applied to a resource server in a cloud-native system, the device comprising: The authentication module is used to authenticate the accessing entity based on the access request; An evaluation module is used to, if authentication is successful, obtain entity attributes from the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, and input the entity attributes, access context, behavioral features, and environmental features into a pre-trained long short-term memory network model to obtain a trust score; the entity attributes are used to characterize the scope of access permissions, the access context is used to characterize the real-time environmental information when the access request occurs, the behavioral features are used to characterize the degree of abnormality in access frequency, and the environmental features characterize the state information of the environment accessed by the access request; The matching module is used to determine whether there is a target policy rule in the policy rule base that matches the access request if the trust score exceeds the score threshold; if there is a target policy rule that matches the access request, the access request is processed based on the target policy rule.

[0012] Thirdly, the present invention provides a resource server, including a processor and a memory, wherein the memory stores a computer program that can be executed by the processor, and the processor can execute the computer program to implement the access request security assessment method described in any of the foregoing embodiments.

[0013] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the access request security assessment method as described in any of the foregoing embodiments.

[0014] Fifthly, the present invention provides a program product that, when executed by a processor, implements the access request security assessment method as described in any of the foregoing embodiments.

[0015] Compared to existing technologies, the access request security assessment method, apparatus, resource server, storage medium, and program products provided in this invention, after successful authentication, acquire entity attributes, access context, behavioral characteristics, and environmental characteristics from the access request. These characteristics are then input into a pre-trained Long Short-Term Memory (LSTM) network model to dynamically generate a trust score. This transforms the trust assessment of access requests from traditional static rule-based judgment to an intelligent scoring mechanism based on multi-dimensional dynamic features. When the trust score exceeds a threshold and a target policy rule matching the access request is found in the policy rule base, the access request is processed based on the target policy rule. By combining a multi-dimensional intelligent scoring mechanism and a policy rule matching mechanism, refined and dynamic security management of access requests is achieved, thereby improving the security and intelligence level of access control in cloud-native environments and solving the problem of static trust assessment in traditional models.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This diagram illustrates a flowchart of an access request security assessment method provided by an embodiment of the present invention.

[0019] Figure 2 This diagram illustrates another flowchart of the access request security assessment method provided in an embodiment of the present invention.

[0020] Figure 3 A block diagram of an access request security assessment device provided in an embodiment of the present invention is shown.

[0021] Figure 4A block diagram of a resource server provided in an embodiment of the present invention is shown.

[0022] Icons: 300 - Access Request Security Assessment Device; 301 - Verification Module; 302 - Assessment Module; 303 - Matching Module; 400 - Resource Server; 410 - Memory; 420 - Processor; 430 - Communication Module. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0024] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0025] It should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0026] In cloud-native systems, the widespread application of Kubernetes container orchestration, Docker containerized deployment, and microservice architecture has made the systems highly dynamic and distributed. Traditional perimeter security models mainly rely on the assumption of "trust within the network" and focus primarily on defending against external attacks (i.e., north-south traffic), while lacking effective monitoring methods for abnormal behavior between internal services. This makes it difficult to detect and block internal lateral attacks in a timely manner, creating potential east-west traffic security risks.

[0027] At the same time, the widespread adoption of containerization technology has made application deployment more flexible and efficient. Container instances have short lifecycles and change frequently, making it difficult for traditional static access control strategies to adapt to this highly dynamic operating environment, which may create security blind spots.

[0028] Based on this, embodiments of the present invention propose an access request security assessment method, apparatus, resource server, storage medium, and program product. After successful authentication, the method acquires entity attributes, access context, behavioral characteristics, and environmental characteristics from the access request and inputs these characteristics into a pre-trained Long Short-Term Memory (LSTM) network model to dynamically generate a trust score. This transforms the trust assessment of access requests from traditional static rule-based judgment to an intelligent scoring mechanism based on multi-dimensional dynamic features. When the trust score exceeds a scoring threshold and a target policy rule matching the access request is found in the policy rule base, the access request is processed based on the target policy rule. By combining a multi-dimensional intelligent scoring mechanism and a policy rule matching mechanism, refined and dynamic security management of access requests is achieved, thereby improving the security and intelligence level of access control in a cloud-native environment and solving the problem of static trust assessment in traditional models.

[0029] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0030] Please refer to Figure 1 , Figure 1 This diagram illustrates a flowchart of an access request security assessment method provided by an embodiment of the present invention. The method includes the following steps: Step S10: Authenticate the access entity based on the access request.

[0031] In this embodiment of the invention, authentication is the first layer of security protection for access control, used to ensure that the accessing entity has initial legitimacy. When accessing resources in a cloud-native system, all accessing entities must go through a strict authentication process. The resource server extracts the information required for authentication from the access request and uses this extracted information to authenticate the accessing entity. If authentication fails, the access request is blocked, and the reason for the access request rejection is displayed.

[0032] Step S20: If authentication is successful, obtain the entity attributes in the access request and the access context, behavioral features, and environmental features corresponding to the access request. Input the entity attributes, access context, behavioral features, and environmental features into the pre-trained Long Short Memory Network model to obtain a trust score. The entity attributes are used to represent the scope of access permissions, the access context is used to represent the real-time environmental information when the access request occurs, the behavioral features are used to represent the degree of abnormality in the access frequency, and the environmental features represent the state information of the environment accessed by the access request.

[0033] In this embodiment of the invention, if authentication is successful, the access request is parsed and the data representing the scope of access permissions is normalized to obtain entity attributes, such as the user's role-based access control (RBAC) roles (e.g., administrator, ordinary user), the permission level of the service account, etc.

[0034] Based on the access request, real-time environmental information at the time of the access request is collected, and the data is cleaned and normalized to obtain the access context, such as the security label of the Node where the source Pod is located, the access time, and the Internet Protocol (IP) address of the access source. It should be understood that the access context is a snapshot of the environment at the time of an access action; it is a collection of real-time state and environmental information related to the access.

[0035] Operational data is collected based on access requests, and then cleaned and normalized to obtain behavioral characteristics, such as whether the frequency of calls between microservices exceeds the normal range and the degree to which it exceeds the normal range. Status information of the environment accessed by the access requests is also collected based on the access requests, and then cleaned and normalized to obtain environmental characteristics, such as the health check pass rate of the target container and resource usage.

[0036] Understandably, preprocessing the collected data by cleaning and normalizing ensures the accuracy and consistency of the four dimensions of data: entity attributes, access context, behavioral characteristics, and environmental characteristics. This facilitates trust scoring in the Long Short-Term Memory (LSTM) network model. For example, mapping the data of the four dimensions from different ranges to the [0,1] interval allows for comparison and calculation of the data in each dimension on the same scale.

[0037] Furthermore, pre-set entity attribute weights, access context weights, behavioral feature weights, and environmental feature weights are obtained, and these weights are used as input data to a pre-trained Long Short-Term Memory (LSTM) network model. The LSTM network model is then used to construct a trust evaluation index system that incorporates cloud-native features.

[0038] Long Short-Term Memory (LSTM) network models are based on the LSM network structure and can remember past access behaviors of entities. They analyze the changing trends of behavioral patterns by combining current input access behavior data (entity attributes, access context, behavioral features, and environmental features). Finally, a weighted calculation is performed using the weights of entity attributes, access context, behavioral features, and environmental features to output a trust score between 0 and 100, representing the credibility of the current access request. During the training phase, the LSM network model learns a large number of normal and abnormal access behavior samples, enabling it to classify and judge access behaviors.

[0039] As one possible implementation, assume the entity attribute weight is 30%, the access context weight is 25%, the behavioral feature weight is 20%, and the environment feature weight is 25%. A user's service account is a regular user, accessing from the company IP address. The call frequency is normal, and the target container is healthy. Based on the Long Short Memory network model evaluation, the entity attribute score is 80, the access context score is 90, the behavioral feature score is 85, and the environment feature score is 95. Combining these scores with their respective weights, the trust score is calculated as follows: .

[0040] Step S30: If the trust score exceeds the score threshold, determine whether there is a target policy rule in the policy rule base that matches the access request.

[0041] In this embodiment of the invention, a trust score is used as an important condition for determining access permissions during the policy matching process. If the trust score exceeds a set threshold (e.g., 70 points), the access request is considered preliminarily legitimate. This means that the accessing entity's performance in multiple dimensions conforms to a pre-defined security behavior pattern, and its identity, access environment, and behavior have all passed a comprehensive evaluation, indicating high credibility. The system then enters the policy matching stage, which determines whether a target policy rule matching the access request exists in the policy rule base.

[0042] For example, if a service account has reasonable permissions, the security label of the Node where the source Pod is located meets the security policy requirements when accessing it, the microservice call frequency is normal, the target container health check pass rate is high, and the trust score calculated by the Long Short Memory Network Model is 80 points, which is greater than the threshold of 70 points, then it enters the policy matching stage.

[0043] It should be noted that the rules in the policy rule base are written based on the extended policy language and cover multiple dimensions such as cloud-native resource attributes (such as namespaces and service versions), access entity attributes (such as RBAC roles), and resource sensitivity levels.

[0044] Step S40: If a target policy rule matching the access request exists, process the access request based on the target policy rule.

[0045] In this embodiment of the invention, if a target policy rule matching the access request exists in the policy rule base, the access request is determined to be a legitimate access, and the access request is processed according to the target policy rule.

[0046] In summary, the access request security assessment method provided by this invention, after successful authentication, acquires entity attributes, access context, behavioral characteristics, and environmental features from the access request. These features are then input into a pre-trained Long Short-Term Memory (LSTM) network model to dynamically generate a trust score. This transforms the trust assessment of access requests from traditional static rule-based judgment to an intelligent scoring mechanism based on multi-dimensional dynamic features. When the trust score exceeds a threshold and a target policy rule matching the access request is found in the policy rule base, the access request is processed based on the target policy rule. By combining a multi-dimensional intelligent scoring mechanism and a policy rule matching mechanism, refined and dynamic security management of access requests is achieved, thereby improving the security and intelligence level of access control in cloud-native environments and solving the problem of static trust assessment in traditional models.

[0047] Optionally, in practical applications, access entities include, but are not limited to, users, devices, and service accounts. Faced with access from various types of entities, this embodiment of the invention overcomes the problem of unified management due to the lack of authentication mechanisms in existing technologies. Regarding how to use access requests for authentication, a possible implementation method is provided below. Figure 1 The sub-steps of step S10 may include: Step S101: Obtain the user's identity information, the device's device information, and the service account's service account information from the access request.

[0048] In this embodiment of the invention, the first step of authentication is to obtain the user's identity information, the device's device information, and the service account information from the access request. The user identity information includes, but is not limited to, the username and RBAC role; the device information includes, but is not limited to, the device fingerprint (such as the Central Processing Unit (CPU) serial number + Media Access Control (MAC) address) and the device security status; and the service account information includes, but is not limited to, the service account identifier, the JSON network token (JWT token) bound to the container PID, and the service validity period.

[0049] Step S102: Search the entity registry based on the user's identity information, the device's device information, the service account's service account information, and the correspondence between the user, device, and service account.

[0050] In this embodiment of the invention, the entity registry serves as a unified identity information storage structure, employing distributed key-value storage (such as the electronic distributed configuration database etcd). It is classified and stored according to resource entities and access entities, and records user identity identifiers, device identity identifiers, service account identity identifiers, and the relationships between the three.

[0051] Specifically, when a resource entity starts up, it is registered, and the corresponding resource entity information is added to the entity registry. Resource entities include, but are not limited to, microservices, containers, and storage volumes. Resource entity information includes, but is not limited to, resource identifiers, resource tags, resource lifecycle states, and associated resource identifiers. Resource tags are attribute tags for resource entities and are used for policy matching.

[0052] Resource identifiers are unique identifiers (i.e., triple identifiers) generated based on the resource's namespace, resource type, and resource name, such as prod / Deployment / user-service. Namespaces are essentially multiple logically isolated spaces within the same Kubernetes cluster, used for grouping and isolating resources. Resources in different namespaces are isolated from each other, while services within the same namespace can communicate with each other by default. For example, independent namespaces can be created for different environments (such as testing and production environments) or different projects, ensuring that resource management in different environments and projects does not interfere with each other. For instance, the `test` namespace can be used for the testing environment, and the `prod` namespace for the production environment.

[0053] Resource types (kind) characterize the type of resource entities. Examples include Deployment (used to deploy and manage collections of Pods, ensuring the application's desired state is maintained and it has self-healing capabilities), Service (provides an abstract network facade for applications, enabling service discovery and load balancing), Pod (the smallest deployable unit in Kubernetes, representing an application instance; a Pod can contain one or more tightly cooperating containers sharing network and storage), and Volume (a storage volume used to provide persistent storage for containers). Resource types allow for quick differentiation of resource entities of different natures.

[0054] The resource name (name) is used to accurately identify a resource entity. It is a unique name assigned to a resource entity within a specific namespace and resource type. For example, in the Deployment resource "user-service" under the "prod" namespace, "user-service" is the name of the resource entity. Combined with the namespace and resource type, it can uniquely identify the resource entity throughout the entire Kubernetes cluster.

[0055] When registering an access entity, the corresponding access entity information is added to the entity registry. Access entities in the entity registry include, but are not limited to, users, devices, and service accounts. Access entity information includes, but is not limited to, identity identifiers, identity attributes, and the association between the access entity and other access entities (such as the association between users and devices, or service accounts). Identity identifiers include, but are not limited to, user identity identifiers, device identity identifiers, and service account identity identifiers.

[0056] The user identity is generated based on the username and RBAC role, such as user:u12345, and is used to associate the user's permission scope and authentication records. The device identity is generated based on the device fingerprint and device security status (such as whether malware is installed), such as device:d67890. The service account identity is generated based on the JWT token, container PID, and service validity period, such as service:s54321.

[0057] The distributed entity registry records the association relationships between user identity identifiers, device identity identifiers, and service account identity identifiers. For example, the association relationship is user:u12345→device:d67890+ service:s54321. This association mechanism ensures that multiple dimensions of identity can be jointly verified when accessing the system, avoiding security risks caused by the theft of a single identity.

[0058] Assuming the entity registry contains resource entity information and access entity information as shown in Table 1, this embodiment of the invention sets unique identifiers for resource entities and access entities, and uses the entity registry to uniformly manage resource entity information and access entity information. This can effectively overcome the problem of the lack of a unified identification and registration mechanism for cloud-native resources such as containers and microservices in the prior art. An entity identification system is designed for the Kubernetes resource model to realize the full lifecycle management of dynamic resources such as containers and microservices.

[0059] Table 1

[0060] Step S103: If the entity registry contains user identity identifiers, device identity identifiers, and service account identity identifiers that correspond to the user identity information, device information, and service account information, and there is an association relationship that corresponds to the user, device, and service account, then the identity verification is deemed successful.

[0061] In this embodiment of the invention, if the entity registry contains user identity identifiers, device identity identifiers, and service account identity identifiers that correspond one-to-one with user identity information, device information, and service account information, and if there is an association relationship consistent with the correspondence between the user identity identifiers, device identity identifiers, and service account identity identifiers, then the authentication is deemed successful. Otherwise, the authentication is deemed unsuccessful, and the access request is blocked.

[0062] This multi-dimensional identity verification mechanism, combined with the verification of the relationship between accessing entities, can effectively prevent security risks caused by the misuse of a single identity, thereby improving the accuracy of identity verification and the overall security of access control.

[0063] For example, in a scenario where a user accesses a service through a device, the system must simultaneously verify that the user's identity information matches the user's identity identifier (i.e., permissions), the device information matches the device's identity identifier (i.e., security), the service account information matches the service account's identity identifier (i.e., legitimacy), and that the correspondence between the user's identity information, device information, and service account information matches the association between the user's identity identifier, device identity identifier, and service account identity identifier before determining that the identity verification is successful, thus ensuring the authenticity and legitimacy of the accessed entity.

[0064] As can be seen, this embodiment of the invention defines the access entity as the user, device, and service account participating in the access request. These three types of entities together constitute the subject identity elements of the access behavior. By simultaneously verifying the identities of the user, device, and service account in the access request and the relationships between them, the accuracy and security of identity authentication can be effectively improved, preventing illegal entities from impersonating legitimate identities to initiate access.

[0065] Optionally, the following is one possible implementation for how to obtain the target policy rule that matches the access request. Figure 1 The sub-steps of step S30 may include: Step S301: Match and verify the policy rules in the policy rule base according to entity attributes, access context, behavioral characteristics and environmental characteristics.

[0066] In this embodiment of the invention, during the policy matching process, entity attributes, access context, behavioral characteristics, and environmental characteristics are extracted and integrated as metadata, and compared item by item with policy rules in the policy rule base to refine the conditions of the policy rules. The rules in the policy rule base are written based on an extended policy language and cover multiple dimensions, including cloud-native resource attributes (such as namespaces and service versions), access entity attributes (such as RBAC roles), resource sensitivity levels, and authorization actions (such as allowing access, denying access, and requiring secondary authentication).

[0067] For example, a policy rule might be: when the namespace is prod, the target service version is 2.0, the request path is / api / orders, the RBAC role is a regular user, and the resource sensitivity level is medium, GET method access is allowed, but access logs must be recorded. A policy rule is only determined to be a matching policy rule when all conditions in the policy rule are met during the matching of entity attributes, access context, behavioral characteristics, and environmental characteristics.

[0068] Specifically, during policy matching, cloud-native resource attributes such as namespaces and service versions are matched first. Then, entity attributes (such as service account permission scope) are matched with access attributes in the policy rules, such as RBAC roles, request access, and resource sensitivity levels. For example, only administrator accounts are allowed to access resources with a high sensitivity level. The access context (such as the security label of the Node where the source Pod resides) is incorporated into the environment conditions of the policy rules; for example, only access from Nodes with the security label "trusted" is allowed. Behavioral characteristics (such as the abnormality of microservice call frequency) and environmental characteristics (such as container health check pass rate) influence the policy matching results through trust scores. For example, if an abnormal call frequency leads to a low trust score, cross-namespace calls are rejected.

[0069] It's important to note that before setting resource sensitivity levels, it's essential to first categorize the data carried by resources in the cloud-native environment, clearly defining the data type and content. This includes user personal information (name, ID number, contact information), business data (order information, transaction records), system configuration data (server account password, API key), and publicly available data (product introductions, marketing articles). In a healthcare cloud platform, the data carried by resources might include patient medical records, diagnostic reports, basic personal information (such as name, gender, age), hospital operational data (such as outpatient visits, departmental revenue), and publicly available health education articles.

[0070] Secondly, a security risk assessment is conducted to evaluate the potential security risks of different types of data breaches, alterations, or damage, including their impact on corporate reputation, economic losses, and legal compliance. The risk level of each type of data is determined by referencing relevant laws, regulations, and industry standards. For patient medical records and diagnostic reports, leakage could lead to violations of patient privacy, breaches of personal information protection laws and relevant medical industry regulations, resulting in severe legal consequences and reputational damage to the hospital; therefore, the risk level is extremely high. In contrast, publicly available health education articles, even if altered or leaked, have a smaller impact on the hospital and patients; therefore, the risk level is low.

[0071] Finally, based on the security risk assessment results, the resource sensitivity level is set to multiple levels, typically divided into low, medium, and high levels, with an additional "extremely high" level for some scenarios. This invention does not limit the scope of this assessment.

[0072] The low-sensitivity level includes publicly available data or data with minimal impact on business and security, such as publicly available product descriptions, marketing content, and non-core system logs. For example, product images and basic function descriptions displayed on e-commerce platforms.

[0073] Medium-sensitivity data includes data involving general business information or limited privacy information, the leakage or alteration of which would have a certain impact, such as ordinary users' order history and non-core business reports within an enterprise. For example, ordinary shopping order information from users on e-commerce platforms does not contain payment-sensitive information.

[0074] Highly sensitive data includes information containing important privacy details, core business data, or critical system configurations. Leakage or alteration of such data could have serious consequences. Examples include users' ID numbers, bank card information, core technical documents of enterprises, and system administrator account passwords. For instance, encrypted bank card numbers and passwords in financial platforms, and complete patient medical records in medical platforms.

[0075] Utilizing a dynamic sensitivity level adjustment mechanism, the sensitivity level of resources is reviewed and adjusted regularly (e.g., quarterly). When business needs change, data usage changes, or the security situation changes, the sensitivity level of resources is updated promptly. For example, an e-commerce platform initially classified users' browsing history data as low-sensitivity data. Later, due to business adjustments, this data was used for targeted marketing and involved user behavior analysis, potentially leaking user preferences. After evaluation, it was adjusted to a medium-sensitivity level.

[0076] Step S302: If a matching policy rule exists, the matching policy rule is determined as the target policy rule corresponding to the access request.

[0077] In this embodiment of the invention, if only one matching policy rule exists, that policy rule is directly used as the target policy rule corresponding to the access request. For example, suppose the policy rule is: when the target service version is 2.0 and the resource sensitivity level is medium, deny access via the POST method and record the access log. The current access request corresponds to a target service version of 2.0, a medium resource sensitivity level, and a GET request method. Therefore, this policy rule does not conflict with the access request, and it is determined as the target policy rule corresponding to the access request. The final decision is to allow access and record the access log.

[0078] As one possible implementation, the resource server includes a decision engine and an Envoy agent. The decision engine feeds back the decision results to the Envoy agent, which then performs the corresponding actions (such as allowing traffic, blocking traffic, or redirecting to a secondary authentication interface). Simultaneously, the decision process and results are recorded in the audit log. For example, the Envoy agent might allow the access request according to the decision result, record the access information (such as user ID, access time, and request path) in the audit log, and synchronize the audit log to the security audit system in real time for subsequent security auditing and traceability.

[0079] Step S303: If there are multiple matching policy rules, the policy rule with the highest priority among the matching policy rules shall be determined as the target policy rule corresponding to the access request.

[0080] In this embodiment of the invention, if multiple matching policy rules exist, the policy rule with the highest priority is selected as the target policy rule corresponding to the current access request based on the policy rule priority mechanism. The priority setting of policy rules is based on a preset priority strategy, for example, rules with higher resource sensitivity levels have higher priority, and policy rules with more specific matching conditions have higher priority.

[0081] For example, in a scenario where a user accesses a highly sensitive resource, if two policy rules both meet the matching conditions, one being a general rule (such as allowing access by a specific RBAC role) and the other a more specific rule (such as restricting access to the source Node security label), the latter is prioritized as the target policy rule. Fine-grained access control is then implemented based on the target policy rule. For instance, field-level authorization based on Kubernetes resource labels or HTTP path parameters can be supported to achieve more granular access control. In other words, by supporting multi-level authorization from service interfaces to data fields, the sophisticated security requirements of cloud-native applications for calls between microservices are met.

[0082] One possible implementation is to intercept the access request and then parse the HTTP path parameters (e.g., / api / users?role=admin), request headers (e.g., Content-Type: application / json), and request body fields (e.g., {"user_id": "123", "action": "delete"}) to extract the specific characteristics of the resource operation. For example, a request might access the path / api / users / 123 of prod / Service / user-service, carrying the method=PUT parameter, intending to modify the information of user ID=123.

[0083] Retrieve the target resource's attribute information from the entity registry, including but not limited to Kubernetes resource tags (such as app=user-service, sensitivity=high) and field-level permission configurations (such as user_id: 123, which can only be modified by administrators). Match the operation object in the access request (such as user ID=123) with the resource tags to determine the sensitivity level and permission requirements corresponding to the operation.

[0084] Rego rules based on Open Policy Agent (OPA) perform field-level authorization checks. For example, the default rule is: resource sensitivity level is high, RBAC role is administrator, and target user ID is a user ID within the management scope. If the access request has an RBAC role of administrator and the modified user ID is within the management scope, then it is determined that there is a target policy rule in the policy rule base that matches the access request, and the verification is passed.

[0085] It's important to note that during cross-service calls, Istio metadata extracted by the service mesh (such as service version and request path) and trust scores are used together for policy matching. For example, only services with a trust score of 80 or higher (version 2.0) are allowed to call the payment interface.

[0086] As can be seen, the embodiments of the present invention combine multi-dimensional feature matching with priority filtering for policy matching, ensuring that the most suitable policy rule can still be accurately selected even when multiple matching rules exist, thereby improving the accuracy of policy matching and decision consistency, and thus enhancing the flexibility and security of access control in the cloud-native environment.

[0087] Optionally, regarding how to update the policy rule base, the following is a possible implementation method. This method also includes the following steps: When the health status of the accessed environment is abnormal or the accessed environment receives more access requests than the request threshold within a preset time, the policy rules corresponding to the accessed environment in the policy rule base are adjusted.

[0088] In this embodiment of the invention, a robust real-time monitoring mechanism continuously collects and analyzes various security-related data, including but not limited to network traffic, user behavior, system logs, and container status. For example, a service mesh proxy software (such as Envoy) intercepts north-south / east-west traffic in real time, and monitors the health status of containers in real time, including but not limited to container CPU utilization, memory usage, and network connection status. If a container experiences abnormal conditions such as resource exhaustion or network connection interruption, the relevant data can be detected and recorded promptly.

[0089] Specifically, in the cloud-native architecture of a large internet enterprise, multiple microservices are deployed, and these microservices frequently communicate with each other in both north-south (between external users and internal services) and east-west (between internal services). By deploying Envoy proxy software in the service mesh, all network traffic can be intercepted in real time. For north-south traffic, Envoy can obtain user request information, such as the request source IP, the requested service interface, and the request time; for east-west traffic, it can obtain relevant information about the source and target services, such as service name, version, call frequency, and other Istio metadata.

[0090] The decision engine needs to be deeply integrated with service meshes and container orchestration systems (such as Kubernetes) to ensure timely access to information provided by these systems, such as event information like resource creation, destruction, and state changes, as well as contextual information like network topology and service dependencies. Simultaneously, it should be able to feed back policy decision results to relevant systems to achieve coordinated control.

[0091] Taking an e-commerce platform as an example, when a new promotional campaign is launched, the Kubernetes container orchestration system creates new Pods to handle the increased workload based on business needs. The policy decision engine can promptly obtain the creation information of these new Pods from the Kubernetes system, including the Pod's name, the service it belongs to, and the deployment namespace. Simultaneously, it understands the dependencies between the new Pods and other services; for example, a new Pod for the order service might depend on the inventory and payment services. When the decision engine detects an attack on a service based on real-time monitoring data, it can quickly formulate reasonable security policies based on this contextual information, such as restricting access traffic to the attacked service or redirecting some traffic to backup services. These policies are then promptly fed back to the service mesh and Kubernetes system via API interfaces, enabling coordinated control of network traffic and resource scheduling.

[0092] Furthermore, attack detection rules and models are used to identify various potential attack patterns. For example, by establishing an abnormal traffic detection model, attacks such as traffic surges exceeding normal ranges and port scanning can be identified; machine learning algorithms are used to model user behavior and detect abnormal logins, data access, and other behaviors.

[0093] In an online gaming platform, an anomaly traffic detection model based on historical traffic data was established to detect abnormal traffic attacks. This model learned the network traffic characteristics of the game at different times and in different game scenarios during normal operation, such as peak traffic during player logins and average traffic during gameplay. When abnormal traffic occurs, such as a single IP address sending a large number of login requests in a short period, far exceeding the normal login frequency of players, or a service port suddenly receiving a large number of connection requests from different IP addresses, exhibiting characteristics of a port scanning attack, the anomaly traffic detection model can promptly identify these attack behaviors.

[0094] Simultaneously, machine learning algorithms are used to model player behavior and analyze players' operational habits in the game, such as the character's movement speed, skill release frequency, and interaction patterns with other players. If a player's behavior is abnormal, such as instantly teleporting to an unreasonable location or frequently releasing high-level skills in a short period of time, the behavior modeling algorithm can detect the anomaly and determine whether there may be cheating or malicious attacks.

[0095] Once an abnormal health status of the accessed environment is detected, or if the accessed environment receives more access requests than the required threshold within a preset time period, the policy rule adjustment process is immediately initiated. Simultaneously, relevant information about the attack event (such as the attack source, attack type, and affected resources) is transmitted to the decision engine. For example, when the container lifecycle status changes (from "running" to "terminated"), the dynamic trust assessment updates the score of the environment characteristic dimension, and the policy matching adjusts the access policy for that container based on the new score (e.g., from "allow access" to "deny access").

[0096] Taking a company's cloud data center as an example, the real-time monitoring system, through network traffic analysis, discovered that the IP address "192.168.1.100" initiated connection requests to more than 50 different ports within one minute. Based on past network traffic data and security policies, normal internal devices or external users would not attempt to connect to so many ports in such a short period. Therefore, according to the preset port scan attack detection rules, it was determined that the IP address (192.168.1.100) was conducting a port scan attack.

[0097] Once it is determined that the IP address (192.168.1.100) has launched a port scanning attack, the policy rule adjustment process is immediately initiated. The attack source IPD address is 192.168.1.100, the attack type is a port scanning attack, and the resources that may be affected (such as the services corresponding to the scanned port) are transmitted to the decision engine so as to adjust the policy rules corresponding to the accessed environment in the policy rule base.

[0098] Based on attack event information and the overall state of the current cloud-native system, the decision engine generates new policy rules in conjunction with pre-defined policy adjustment rules. These new rules are then saved to the policy rule base and rapidly distributed to relevant components via API interfaces with the service mesh and container orchestration system. For example, if an attack originating from a specific IP address is detected, the policy decision engine may generate a policy that prohibits that IP address from accessing all services. If an abnormal traffic attack is detected on a microservice, the engine may adjust the traffic control policies related to that microservice, limiting the traffic rate or blocking some suspicious traffic.

[0099] Suppose that in an e-commerce platform, a product detail display microservice suffers an abnormal traffic attack, resulting in slow service response or even brief periods of unresponsiveness. Upon receiving the attack information, the policy decision engine analyzes the overall system status and finds that the server resources hosting the microservice are nearly exhausted, while other related microservices (such as order services and payment services) have not yet been significantly affected. Based on pre-defined policy adjustment rules, the policy decision engine generates a new security policy: First, it limits the inbound traffic rate of the product detail display microservice, reducing the original allowed 1000 requests per second to 200 requests per second to alleviate server pressure; second, it blocks traffic from certain suspicious IP addresses whose traffic characteristics are similar to the attack traffic.

[0100] As can be seen, by introducing a policy adaptive mechanism based on changes in environmental state and access traffic, the embodiments of the present invention enable policy rules to be adjusted in real time according to the dynamically changing operating state in the cloud-native environment. This achieves dynamic adjustment of policy rules and real-time blocking of attack events, effectively enhancing the security protection capability and policy flexibility of the cloud-native system in abnormal scenarios, thereby improving the overall security and adaptability of access control.

[0101] Optionally, regarding how to perform secondary authentication after trust score verification fails, the following is a possible implementation method. Please refer to... Figure 2 The method also includes the following steps: In step S50, if the trust score does not exceed the score threshold, secondary authentication is triggered, and additional authentication information from the user is received.

[0102] In this embodiment of the invention, if the trust score does not exceed a scoring threshold (e.g., set to 70 points), the access request is considered illegal. At this time, the resource server considers the accessing entity to be abnormal or not meeting security requirements, potentially posing a security risk, and requires further action. The resource server automatically triggers a secondary authentication process and sends an additional authentication request to the accessing entity through the authentication interface, requesting additional identity verification information, such as SMS verification codes, biometric identification information like fingerprints, etc.

[0103] Step S60: If the additional authentication information fails to be verified, the access request is blocked.

[0104] In this embodiment of the invention, after receiving additional authentication information returned by the accessing entity, the resource server verifies the legitimacy of the additional authentication information. If the additional authentication information fails verification, it indicates that the trustworthiness of the accessing entity does not meet the security policy requirements, and the access request is directly blocked to prevent potential unauthorized access from posing a security threat to the cloud-native system.

[0105] For example, if a user's access behavior is abnormal and the frequency of microservice calls is abnormally high, resulting in a trust score of 50 points, which is lower than the scoring threshold of 70 points, two-factor authentication will be triggered. If the user fails the two-factor authentication, the system will block the access request.

[0106] Step S70: If the additional authentication information is verified and a target policy rule matching the access request exists in the policy rule base, the access request is processed based on the target policy rule.

[0107] In this embodiment of the invention, if the additional authentication information is verified, the resource server continues to execute the policy matching process, that is, it determines whether there is a target policy rule in the policy rule base that matches the current access request, and if there is a matching target policy rule, it processes the access request based on the target policy rule.

[0108] Specifically, provided that the secondary authentication is successful, the policy matching process still performs matching and verification based on the aforementioned four-dimensional feature information (entity attributes, access context, behavioral features, and environmental features) and the preset rules in the policy rule base, to ensure that after the accessing entity passes the additional authentication, its access behavior still needs to comply with the access control policy in the policy rule base.

[0109] As can be seen, the embodiments of the present invention introduce a secondary authentication mechanism based on trust scoring and combine it with policy rule matching conditions to differentiate the additional authentication results, thereby achieving enhanced identity verification and policy control when trust assessment is insufficient. This ensures system security while maintaining the ability to flexibly handle legitimate access requests, thus improving the adaptability and security of access control in cloud-native environments.

[0110] It is worth mentioning that, according to the embodiments of the present invention, security assessments are performed on access requests that the cloud-native system has just received or is currently processing, according to a preset monitoring cycle. A complete security assessment process, including identity verification, trust score calculation, and policy rule matching, is periodically executed. To further enhance security within the monitoring cycle, after the trust score exceeds the scoring threshold or secondary authentication is successful, an authentication session ticket is generated based on the entity attributes in the access request and the access context, behavioral characteristics, and environmental characteristics corresponding to the access request. This authentication session ticket is then used for rapid identity authentication within the monitoring cycle.

[0111] As one possible implementation, the authentication session ticket includes, but is not limited to, identity information, device fingerprint, environmental information, authentication factors, and lifespan. Identity information includes, but is not limited to, user ID (e.g., uid=10086) and RBAC role (e.g., role=finance); device fingerprint includes, but is not limited to, CPU serial number hash (e.g., cpu=sha256(ABC123)) and MAC address hash (e.g., mac=sha256(DE:AD:BE:EF:12:34)); environmental information includes, but is not limited to, cluster ID (e.g., cluster=cn-beijing-1), Node IP (e.g., node=10.0.1.5), and namespace (ns=prod); authentication factors include, but are not limited to, authentication method (e.g., auth=password+fingerprint) and MFA result (e.g., mfa=passed); and lifespan includes, but is not limited to, issuance time (e.g., iat=1720675200) and expiration time (exp=1720678800, 1-hour validity period).

[0112] Suppose the content of the authentication session ticket is as follows: { "user_id": "u123456", "username": "zhangsan", "rbac_role": "user", "device_fingerprint": "a1b2c3d4e5f67890hash", "cluster_id": "cluster - prod - 001", "node_ip": "10.0.2.15", "access_time": "2025-07-11T09:30:00Z", "namespace": "prod", "mfa_result": "passed", "auth_method": "password + sms", "expiration_time": "2025-07-11T10:30:00Z", "signature": "jwt_signature_here" } The “signature” is the result of signing the content of the authentication session ticket using a private key. It is used to verify the integrity and authenticity of the authentication session ticket and prevent it from being tampered with.

[0113] Once authentication is successful in each monitoring period, there is no need to repeat the full authentication process when accessing the same namespace or other related resources. For example, after logging into an e-commerce platform, a user can quickly pass authentication by first accessing the product list page and then the shopping cart page using an authentication session ticket.

[0114] Furthermore, when microservices communicate with each other (i.e., cross-service calls), the service account carries an authentication session ticket to prove its identity and access permissions. For example, when the order service calls the payment service, it passes the service account's authentication session ticket, and the payment service verifies the authentication session ticket before allowing the call.

[0115] During the validity period of the authentication session ticket, when a user performs an operation or refreshes the page, the resource server maintains the session state of the access request by verifying the authentication session ticket. Specifically, the authentication session ticket usually exists in the form of a JWT token and is transmitted between the client and the server via HTTP headers (such as Authorization: Bearer), cookies, or request parameters.

[0116] After receiving an access request, the resource server extracts the authentication session ticket and verifies the validity of the signature. It checks whether the authentication session ticket is within its validity period and compares the device fingerprint, environment information, and other information to ensure they match those generated at the time of generation. If the verification passes, access is granted; if the verification fails (e.g., invalid signature, expired, or mismatched device information), the user is required to re-authenticate.

[0117] When an authentication session ticket is about to expire (e.g., 5 minutes remaining), if the user is still performing operations, a new authentication session ticket can be automatically generated and returned to the client, extending the session time and avoiding frequent authentication by the user. For example, when a user is engaged in long-term online editing work, the resource server automatically refreshes the authentication session ticket, ensuring that the user can continue operating without logging in again.

[0118] Optionally, in the absence of a target policy rule matching the access request, the following is a possible implementation method for handling the access request. Please refer to... Figure 2 The method also includes the following steps: Step S80: If the trust score exceeds the score threshold and there is no target policy rule in the policy rule base that matches the access request, the access request is processed based on the default policy rule.

[0119] In this embodiment of the invention, if the calculated trust score exceeds the set score threshold, it indicates that the accessing entity has a high degree of credibility in terms of behavioral characteristics and environmental context. At this time, the system further enters the policy matching process to determine whether there is a target policy rule in the policy rule base that matches the access request.

[0120] If the policy matching process does not find any target policy rule that meets the matching conditions, the access request is processed based on the preset default policy rule. The default policy rule serves as a fallback policy when the policy rule base does not cover a specific access scenario. Its processing logic is usually set to the strictest access control mode, such as denying access or allowing only basic read operations.

[0121] As can be seen, by introducing a default policy rule mechanism, this embodiment of the invention ensures that access requests can still be processed in compliance with regulations even when trust assessment is passed but there is a lack of clear policy guidance. This ensures the integrity and continuity of the access control process, avoids the stagnation of access request processing due to missing policies, and improves the robustness and operability of cloud-native systems in scenarios where policies are not covered.

[0122] It is worth mentioning that the embodiments of the present invention obtain a zero-trust model corresponding to the security architecture through a security assessment process that runs through the entire chain of "authentication, trust assessment based on entity attributes, access context, behavioral characteristics and environmental characteristics, and policy rule matching". The zero-trust model is a network security concept whose core principle is "never trust, always verify". It abandons the assumption of "trust within the network" in traditional network security, and believes that in a digital environment, users, devices and traffic, whether inside or outside the network, should not be pre-assumed as trustworthy.

[0123] The Zero Trust model emphasizes continuous authentication, authorization, and security assessment of all access requests. By analyzing multi-dimensional information such as user behavior, device status, and network environment in real time, it dynamically grants or adjusts access permissions, building a "data-centric" security architecture. This ensures that only legitimate access that complies with security policies is permitted, thereby effectively improving network defense capabilities and security levels. The core mechanisms of the Zero Trust model include the principle of least privilege, continuous verification mechanisms, and deep visualization.

[0124] The principle of least privilege grants entities only the permissions necessary to complete the current operation. For example, finance personnel can only access the accounting data they are responsible for and cannot view the financial records of other departments. Continuous verification measures trust in real time during access; even after access has begun, if an anomaly is detected (such as a user suddenly attempting to perform an operation outside their authorized scope), the session is immediately terminated. Deep visualization uses a security orchestration platform to display entity access paths and resource dependencies in real time, forming a dynamic security topology map that helps administrators discover hidden risks.

[0125] Based on the same inventive concept, the basic principle and technical effects of the access request security assessment device provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments.

[0126] Please refer to Figure 3 , Figure 3 This is a block diagram of an access request security assessment device 300 provided in an embodiment of the present invention. The access request security assessment device 300 includes a verification module 301, an assessment module 302, and a matching module 303.

[0127] The verification module 301 is used to authenticate the access entity based on the access request.

[0128] The evaluation module 302 is used to obtain the entity attributes in the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, if the authentication is successful. The entity attributes, access context, behavioral features, and environmental features are then input into a pre-trained long short-term memory network model to obtain a trust score. The entity attributes are used to represent the scope of access permissions, the access context is used to represent the real-time environmental information when the access request occurs, the behavioral features are used to represent the degree of abnormality in the access frequency, and the environmental features represent the state information of the environment accessed by the access request.

[0129] The matching module 303 is used to determine whether there is a target policy rule in the policy rule base that matches the access request if the trust score exceeds the score threshold; if there is a target policy rule that matches the access request, the access request is processed based on the target policy rule.

[0130] In summary, the access request security assessment device provided in this embodiment of the invention acquires entity attributes, access context, behavioral characteristics, and environmental characteristics from the access request after successful authentication. These characteristics are then input into a pre-trained Long Short-Term Memory (LSTM) network model to dynamically generate a trust score. This transforms the trust assessment of access requests from traditional static rule-based judgment to an intelligent scoring mechanism based on multi-dimensional dynamic features. When the trust score exceeds a scoring threshold and a target policy rule matching the access request is found in the policy rule base, the access request is processed based on the target policy rule. By combining a multi-dimensional intelligent scoring mechanism and a policy rule matching mechanism, refined and dynamic security management of access requests is achieved, thereby improving the security and intelligence level of access control in a cloud-native environment and solving the problem of static trust assessment in traditional models.

[0131] Optionally, the verification module 301 is specifically used to obtain the user's identity information, the device's device information, and the service account's service account information from the access request; search the entity registry based on the user's identity information, the device's device information, the service account's service account information, and the correspondence between the user, device, and service account; if the entity registry contains a user identity identifier, device identity identifier, and service account identity identifier that correspond to the user's identity information, device information, and service account information, and there is an association relationship that corresponds to the user, device, and service account, then the identity verification is deemed successful.

[0132] Optionally, the matching module 303 is specifically used to perform matching and verification of policy rules in the policy rule base based on entity attributes, access context, behavioral characteristics and environmental characteristics; if there is a matching policy rule, the matching policy rule is determined as the target policy rule corresponding to the access request; if there are multiple matching policy rules, the policy rule with the highest priority among the matching policy rules is determined as the target policy rule corresponding to the access request.

[0133] Optionally, the matching module 303 is also used to adjust the policy rules corresponding to the accessed environment in the policy rule base when the health status of the accessed environment is abnormal or when the accessed environment receives more access requests than the request threshold within a preset time.

[0134] Optionally, the verification module 301 is further configured to trigger secondary authentication and receive additional authentication information from the user if the trust score does not exceed the scoring threshold; if the additional authentication information fails verification, the access request is blocked. The matching module 303 is further configured to process the access request based on the target policy rule if the additional authentication information passes verification and a target policy rule matching the access request exists in the policy rule base.

[0135] Optionally, the matching module 303 is also used to process the access request based on the default policy rule if the trust score exceeds the score threshold and there is no target policy rule in the policy rule base that matches the access request.

[0136] Please refer to Figure 4 This is a block diagram illustrating a resource server 400 provided in an embodiment of the present invention. The resource server 400 includes, but is not limited to, personal computers (PCs), handheld computers (PDAs), laptops, tablets, servers, and other devices. The resource server 400 includes a memory 410, a processor 420, and a communication module 430. The memory 410, processor 420, and communication module 430 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0137] The memory 410 is used to store programs or data. The memory 410 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0138] The processor 420 is used to read / write data or programs stored in the memory 410 and perform corresponding functions. For example, when a computer program stored in the memory 410 is executed by the processor 420, the access request security assessment method disclosed in the above embodiments can be implemented.

[0139] The communication module 430 is used to establish a communication connection between the resource server 400 and other communication terminals via the network, and to send and receive data via the network.

[0140] It should be understood that, Figure 4 The structure shown is only a schematic diagram of the resource server 400. The resource server 400 may also include more than [other components]. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4The components shown can be implemented using hardware, software, or a combination thereof.

[0141] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor 420, implements the access request security assessment method disclosed in the above embodiments.

[0142] This invention also provides a program product that, when executed by processor 420, implements the access request security assessment method disclosed in the above embodiments.

[0143] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0144] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

[0146] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for security assessment of access requests, characterized in that, The method, applied to resource servers in cloud-native systems, includes: Authenticate the accessing entity based on the access request; If authentication is successful, the entity attributes in the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, are obtained. The entity attributes, access context, behavioral features, and environmental features are then input into a pre-trained long short-term memory network model to obtain a trust score. The entity attributes are used to characterize the scope of access permissions, the access context is used to characterize the real-time environmental information when the access request occurs, the behavioral features are used to characterize the degree of abnormality in access frequency, and the environmental features characterize the state information of the environment accessed by the access request. If the trust score exceeds the score threshold, determine whether there is a target policy rule in the policy rule base that matches the access request; If a target policy rule matches the access request, the access request is processed based on the target policy rule.

2. The access request security assessment method according to claim 1, characterized in that, The access entity includes users, devices, and service accounts; the authentication of the access entity based on the access request includes: The user's identity information, the device's device information, and the service account's service account information are obtained from the access request, respectively. The entity registry is searched based on the user's identity information, the device's device information, the service account's service account information, and the correspondence between the user, the device, and the service account. If the entity registry contains a user identity identifier, device identity identifier, and service account identity identifier that correspond to the user identity information, device information, and service account information, and there is an association relationship that corresponds to the user, device, and service account, then the identity verification is deemed successful.

3. The access request security assessment method according to claim 1, characterized in that, The determination of whether a target policy rule matching the access request exists in the policy rule base includes: The policy rules in the policy rule base are matched and validated based on entity attributes, access context, behavioral characteristics, and environmental characteristics. If a matching policy rule exists, the matching policy rule is determined as the target policy rule corresponding to the access request; If multiple matching policy rules exist, the policy rule with the highest priority among the matching policy rules is determined as the target policy rule corresponding to the access request.

4. The access request security assessment method according to claim 1, characterized in that, The method further includes: When the health status of the accessed environment is abnormal or the accessed environment receives more access requests than the request threshold within a preset time, the policy rules corresponding to the accessed environment in the policy rule base are adjusted.

5. The access request security assessment method according to claim 1, characterized in that, If authentication is successful, the system retrieves the entity attributes from the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request. After inputting the entity attributes, access context, behavioral features, and environmental features into a pre-trained Long Short Memory network model to obtain a trust score, the system further includes: If the trust score does not exceed the score threshold, secondary authentication is triggered, and additional authentication information from the user is received. If the additional authentication information fails to be verified, the access request is blocked. If the additional authentication information is verified and a target policy rule matching the access request exists in the policy rule base, the access request is processed based on the target policy rule.

6. The access request security assessment method according to claim 1, characterized in that, If authentication is successful, the system retrieves the entity attributes from the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request. After inputting the entity attributes, access context, behavioral features, and environmental features into a pre-trained Long Short Memory network model to obtain a trust score, the system further includes: If the trust score exceeds the scoring threshold and there is no target policy rule in the policy rule base that matches the access request, the access request is processed based on the default policy rule.

7. An access request security assessment device, characterized in that, The device is used in a resource server within a cloud-native system and includes: The authentication module is used to authenticate the accessing entity based on the access request; An evaluation module is used to, if authentication is successful, obtain entity attributes from the access request, as well as the access context, behavioral features, and environmental features corresponding to the access request, and input the entity attributes, access context, behavioral features, and environmental features into a pre-trained long short-term memory network model to obtain a trust score; the entity attributes are used to characterize the scope of access permissions, the access context is used to characterize the real-time environmental information when the access request occurs, the behavioral features are used to characterize the degree of abnormality in access frequency, and the environmental features characterize the state information of the environment accessed by the access request; The matching module is used to determine whether there is a target policy rule in the policy rule base that matches the access request if the trust score exceeds the score threshold; if there is a target policy rule that matches the access request, the access request is processed based on the target policy rule.

8. A resource server, characterized in that, It includes a processor and a memory, the memory storing a computer program executable by the processor, the processor being able to execute the computer program to implement the access request security assessment method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the access request security assessment method as described in any one of claims 1-6.

10. A program product, characterized in that, When the program product is executed by the processor, it implements the access request security assessment method as described in any one of claims 1-6.

Images