A database vulnerability detection method based on a cloud service system and a cloud service system

Abstract

The application discloses a database vulnerability detection method based on a cloud service system and the cloud service system, and relates to the technical field of security. The cloud service system comprises an infrastructure providing cloud services and a cloud management platform managing the infrastructure, and the infrastructure comprises a cloud instance. The method comprises the following steps: the cloud management platform acquires permission configuration data of a database, wherein the permission configuration data is used for indicating roles and permissions allocated for a user to be configured to operate a cloud resource; the cloud instance maps the permission configuration data to a knowledge graph, wherein the mapped knowledge graph comprises a plurality of nodes and at least one edge connecting the plurality of nodes, each node is used for representing an entity included in the database, and the entity comprises a user, a role, a permission and a cloud resource, and each edge is used for representing a relationship between the entities; and the cloud instance infers a permission vulnerability caused after the permission configuration data is configured to the database according to the mapped knowledge graph. Then, the database vulnerability detection is enriched from the permission risk dimension, so that the diversified market demands can be met, and the method is easy to implement.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to a database vulnerability detection method and cloud service system based on a cloud service system. Background Technology

[0002] Database vulnerabilities refer to situations where the security of a database system is compromised due to software design flaws, misconfigurations, or operational errors. Attackers can exploit these vulnerabilities to illegally access, tamper with, steal, or destroy sensitive data in the database, thereby causing harm to users.

[0003] Currently, academia and industry have proposed a series of detection schemes for database vulnerabilities such as SQL injection and database service interruptions. For example, database fuzzing tools can be used to generate a large number of syntactically correct SQL statements as database input, leveraging quantity to trigger hidden database vulnerabilities. Alternatively, tools such as SQLMap, OWASP ZAP, and Acunetix can be used to provide various attack methods (such as SQL injection and cross-site scripting) to detect existing database vulnerabilities. These detection schemes are often used in combination to identify database vulnerabilities based on vulnerability databases.

[0004] However, on the one hand, these detection schemes have limited probe queries or attack payloads, and can mostly only identify vulnerabilities recorded in vulnerability databases, making vulnerability discovery somewhat accidental and limited. On the other hand, since a complete database scan can only be achieved with sufficient privileges granted by the database administrator, the implementation of these detection schemes is subject to significant constraints. Furthermore, these detection schemes are mostly designed for database logical errors (such as the aforementioned SQL injection vulnerabilities and database service outages), neglecting the detection of other types of database vulnerabilities and failing to meet the diverse needs of the market. Summary of the Invention

[0005] This application provides a database vulnerability detection method based on a cloud service system, a cloud service system, a computing device, a computing device cluster, a computer storage medium, and a computer program product. It can identify permission defects in the database, thereby enriching the dimensions of database vulnerability detection and improving the flexibility and adaptability of database vulnerability detection.

[0006] In a first aspect, embodiments of this application provide a database vulnerability detection method based on a cloud service system. The cloud service system includes infrastructure providing cloud services and a cloud management platform managing the infrastructure. The infrastructure includes cloud instances. The method includes: the cloud management platform acquiring permission configuration data for the database, the permission configuration data indicating the roles and permissions assigned to the user to be configured to operate cloud resources; the cloud management platform sending the permission configuration data to the cloud instance; the cloud instance mapping the permission configuration data to a knowledge graph to obtain a mapped knowledge graph, wherein the mapped knowledge graph includes multiple nodes and at least one edge connecting the multiple nodes, each node representing entities included in the database, entities including users, roles, permissions, and cloud resources in the database, each edge representing the relationships between entities, and users including the user to be configured; the cloud instance infers, based on the mapped knowledge graph, that the permission configuration data, after being configured in the database, triggers a vulnerability detection method.

[0007] In this embodiment, tenants can manage permissions for database instances through the access interface provided by the cloud management platform. This includes creating users and assigning roles and permissions to them for operating cloud resources, or modifying user permissions. During this process, the cloud management platform can also send the received permission configuration data to the cloud instance, which then updates the knowledge graph representing the permission configuration of the database instance. Based on the topological structure and semantic dependencies of nodes and edges in the knowledge graph after data mapping, the cloud instance infers the permission risks present in the database instance. In this way, without a full database scan, the cloud instance can grasp the dynamic permission configuration changes of the database based on the knowledge graph, completing permission risk detection with strong adaptability and high flexibility. Compared to related technologies, this approach enriches database vulnerability detection from the perspective of permission risks, better meeting diverse market demands.

[0008] In some possible implementations, the cloud instance maps permission configuration data to a knowledge graph to obtain the mapped knowledge graph. This includes: the cloud instance converting the permission configuration data into multiple triples, which record the relationship between any two entities to be configured. The entities to be configured include the user to be configured, the cloud resources operated by the user, the assigned role, and the assigned permissions; the cloud instance maps the entities to be configured in the multiple triples to existing or new nodes in the knowledge graph and connects them through corresponding edges to obtain the mapped knowledge graph. The corresponding edges represent the relationship attributes between the entities to be configured through direction or additional attributes.

[0009] In this way, permission configuration data is mapped to the knowledge graph through triple information, transforming dynamic and complex permission management into an easily implemented graph structure. This allows for an accurate and complete overview and display of the database's permission configuration. Consequently, even with highly complex database systems, such as cross-tenant database systems and distributed database environments, the intuitive display and analysis of the graph structure can significantly reduce the risk of overlapping permissions or exposed resources.

[0010] In some possible implementations, the mapped knowledge graph includes at least one of the following: a target user node representing the user to be configured, a target role node representing the assigned role, a target permission node representing the assigned permission, and a target resource node representing the cloud resource to be configured to operate. The cloud instance infers permission vulnerabilities caused by configuring permission configuration data into the database based on the mapped knowledge graph. This includes: the cloud instance traversing at least one inheritance path from the target user node to the target resource node in the mapped knowledge graph, where at least one inheritance path includes a role inheritance path and / or a permission inheritance path formed by the target role node and the target permission node; the cloud instance matching the at least one inheritance path with preset inheritance rules to obtain a matching result, where the inheritance rules define the inheritance specifications followed by the security compliance path; and the cloud instance generating a detection result based on the matching result, where the detection result describes at least one of the following: whether a permission vulnerability is caused, and the type of permission vulnerability caused.

[0011] In this way, by analyzing the inheritance path from user access to resource coverage from multiple aspects such as role inheritance and permission inheritance, we can more comprehensively infer the permission risks caused by role inheritance and permission inheritance in database permission configuration, thereby improving database security.

[0012] In some possible implementations, the cloud instance matches at least one of multiple inheritance paths with preset inheritance rules to obtain matching results, including: the cloud instance determining that at least one inheritance path indicates that the target user node is indirectly associated with the target permission node through the role inheritance path of the target role node, and there is no direct granting relationship between the target user node and the target permission node; the cloud instance matches at least one inheritance path with preset inheritance rules to determine that the matching result is that at least one inheritance path hits the first rule in the inheritance rules, wherein the first rule is used to describe the first risk inheritance path, and the first risk inheritance path is used to indicate that the user indirectly obtains preset sensitive permissions through role inheritance, and the sensitive permissions exceed the permission scope directly possessed by the role assigned to the user; the cloud instance generates detection results based on the matching results, including: the cloud instance generates detection results based on the matching results, and the detection results are used to indicate that the vulnerability type caused is an unauthorized access vulnerability.

[0013] In this way, by analyzing the role inheritance path of the knowledge graph, we can detect privilege escalation vulnerabilities caused by database permission configuration, which improves detection efficiency and is easy to implement.

[0014] In some possible implementations, the cloud instance matches at least one of multiple inheritance paths with preset inheritance rules to obtain matching results, including: the cloud instance determines that at least one of the multiple inheritance paths directly or indirectly associates the target role node with different target permission nodes, and the target role node has a scope of responsibility attribute; the cloud instance matches at least one of the multiple inheritance paths with preset inheritance rules to determine that the matching result is that at least one inheritance path hits the second rule in the inheritance rules, the second rule is used to describe the second risk inheritance path, the second risk inheritance path is used to indicate that the user directly or indirectly obtains preset sensitive permissions through the role, and the sensitive permissions exceed the scope of permissions required for the user's assigned role to perform its duties; the cloud instance generates detection results based on the matching results, including: the cloud instance generates detection results based on the matching results, the detection results are used to indicate that the vulnerability type is a privilege abuse vulnerability.

[0015] In this way, by analyzing the role inheritance path of the knowledge graph, we can detect permission abuse vulnerabilities caused by the database permission configuration process, which improves detection efficiency and is easy to implement.

[0016] In some possible implementations, the cloud instance matches at least one of multiple inheritance paths with a preset inheritance rule to obtain a matching result, including: the cloud instance calculating the depth of each inheritance path; the cloud instance comparing the depth of each inheritance path with a depth threshold defined by the inheritance rule to generate a matching result; and the cloud instance generating a detection result based on the matching result, including: the cloud instance generating a detection result when the matching result indicates that the depth of the target inheritance path exceeds or is equal to the depth threshold, and the detection result indicating that the depth of the target inheritance path is defective.

[0017] In this way, by deeply auditing the inheritance paths of the knowledge graph, path depth defects caused during database permission configuration can be detected. Furthermore, this example can present complex permission defect detection results intuitively in graphical and tabular formats, making it easier for users to quickly understand and fix permission issues, lowering the barrier to entry for administrators, and improving the user experience.

[0018] In some possible implementations, the cloud instance matches at least one of multiple inheritance paths with a preset inheritance rule to obtain a matching result. This includes: the cloud instance determining at least one inheritance path that associates the target role node with multiple target permission nodes; the cloud instance grouping any two target permission nodes from the multiple target permission nodes to obtain at least one node pair; the cloud instance matching the at least one node pair with mutually exclusive permission pairs defined in the inheritance rule to obtain a matching result; and the cloud instance generating a detection result based on the matching result. This includes: if the matching result includes a target node pair matching a mutually exclusive permission pair, the cloud instance generates a detection result, which indicates that there is a permission conflict vulnerability in the inheritance path corresponding to the target node pair.

[0019] In this way, knowledge graphs can be used to efficiently store and query permission relationships. In large-scale permission data analysis scenarios, permission conflict vulnerabilities caused by database permission configuration can be quickly analyzed and detected in real time. This is suitable for systems with complex permission management, such as distributed database systems, and has high adaptability.

[0020] In some possible implementations, the mapped knowledge graph includes target user nodes representing the user to be configured and target permission nodes representing the assigned permissions. The cloud instance infers permission vulnerabilities caused by configuring permission configuration data into the database based on the mapped knowledge graph, including: the cloud instance traversing the authorization paths covered by the target user nodes to the target permission nodes from the mapped knowledge graph; and the cloud instance determining whether configuring permission configuration data into the database causes permission redundancy vulnerabilities based on the number of authorization paths, the number of hops in each authorization path, and the nodes included in each authorization path.

[0021] In this way, redundant permission paths can be identified from the knowledge graph through path analysis, reducing the difficulty of manual path analysis and improving the efficiency of vulnerability remediation.

[0022] In some possible implementations, the mapped knowledge graph includes target user nodes representing the user to be configured and target resource nodes representing the cloud resources operated by the user to be configured. The cloud instance infers the permission vulnerability caused by the permission configuration data being configured into the database based on the mapped knowledge graph, including: the cloud instance traversing the access path covered by the target user node to the target resource node from the mapped knowledge graph; the cloud instance matching the access path with the preset legal access path to obtain the matching result; if the access path is valid and the matching result indicates that the access path does not conform to the legal access path, the cloud instance determines that there is a hidden risk path vulnerability after the permission configuration data is configured into the database.

[0023] In this way, by comprehensively analyzing the access path, hidden risk paths can be identified, thereby improving the reliability of permission risk detection.

[0024] Secondly, embodiments of this application provide a cloud service system, which includes infrastructure for providing cloud services and a cloud management platform for managing the infrastructure. The infrastructure includes cloud instances, wherein:

[0025] The cloud management platform is used to acquire permission configuration data for the database. This data indicates the roles and permissions assigned to the user to be configured to operate cloud resources. The platform also sends the acquired permission configuration data to the cloud instance. The cloud instance maps the permission configuration data to a knowledge graph, resulting in a mapped knowledge graph. This graph includes multiple nodes and at least one edge connecting each node. Each node represents an entity in the database, including users, roles, permissions, and cloud resources. Each edge represents the relationships between entities, and users include the user to be configured. The cloud instance also uses the mapped knowledge graph to infer permission leaks caused by the permission configuration data being configured in the database.

[0026] In some possible implementations, the cloud instance is used to: convert permission configuration data into multiple triples, which record the relationship between any two entities to be configured. The entities to be configured include the user to be configured, the cloud resources operated by the user, the assigned role, and the assigned permissions; map the entities to be configured in the multiple triples to existing or new nodes in the knowledge graph, and connect them through corresponding edges to obtain the mapped knowledge graph. The corresponding edges represent the relationship between the entities to be configured through direction or additional attributes.

[0027] In some possible implementations, the mapped knowledge graph includes at least one of the following: a target user node representing the user to be configured, a target role node representing the assigned role, a target permission node representing the assigned permission, and a target resource node representing the cloud resource to be operated by the user to be configured; and a cloud instance used to: traverse at least one inheritance path from the mapped knowledge graph, from the target user node to the target resource node, wherein at least one inheritance path includes a role inheritance path and / or a permission inheritance path formed by the target role node associating with the target permission node; match at least one inheritance path with a preset inheritance rule to obtain a matching result, wherein the inheritance rule is used to define the inheritance specification followed by the security compliance path; and generate a detection result based on the matching result, wherein the detection result is used to describe at least one of the following: whether a permission vulnerability is caused, and the type of permission vulnerability caused.

[0028] In some possible implementations, the cloud instance is used to: determine at least one inheritance path indicating that the target user node is indirectly associated with the target permission node through the role inheritance path of the target role node, and there is no direct granting relationship between the target user node and the target permission node; match at least one inheritance path with preset inheritance rules, and determine that the matching result is that at least one inheritance path hits the first rule in the inheritance rules, wherein the first rule is used to describe the first risk inheritance path, the first risk inheritance path is used to indicate that the user indirectly obtains preset sensitive permissions through role inheritance, and the sensitive permissions exceed the permission scope directly possessed by the role assigned to the user; and generate a detection result based on the matching result, the detection result being used to indicate that the vulnerability type is an unauthorized access vulnerability.

[0029] In some possible implementations, the cloud instance is used to: determine at least one or more inheritance paths that directly or indirectly associate target role nodes with different target permission nodes, where the target role nodes have a scope of responsibility attribute; match at least one or more inheritance paths with preset inheritance rules, determining that the matching result is that at least one inheritance path hits the second rule in the inheritance rules, where the second rule describes a second risk inheritance path, indicating that the user directly or indirectly obtains preset sensitive permissions through a role, and the sensitive permissions exceed the scope of permissions required for the user's assigned role to perform its duties; and generate a detection result based on the matching result, where the detection result indicates that the vulnerability type is a privilege abuse vulnerability.

[0030] In some possible implementations, a cloud instance is used to: calculate the depth of each inheritance path; compare the depth of each inheritance path with a depth threshold defined by the inheritance rules to generate a matching result; and generate a detection result if the matching result indicates that the depth of the target inheritance path exceeds the depth threshold, the detection result being used to indicate that there is a defect in the depth of the target inheritance path.

[0031] In some possible implementations, the detection module is used to: determine at least one inheritance path that associates the target role node with multiple target permission nodes; group any two target permission nodes among the multiple target permission nodes to obtain at least one node pair; match the at least one node pair with the mutually exclusive permission pairs defined in the inheritance rules to obtain a matching result; and generate a detection result if the matching result includes a target node pair that matches a mutually exclusive permission pair. The detection result is used to indicate that there is a permission conflict vulnerability in the inheritance path corresponding to the target node pair.

[0032] In some possible implementations, the mapped knowledge graph includes target user nodes representing the user to be configured and target permission nodes representing the assigned permissions; the cloud instance is used to: traverse the authorization paths covered by the target user nodes to the target permission nodes from the mapped knowledge graph; and determine whether the permission configuration data will cause permission redundancy vulnerabilities after being configured into the database, based on the number of authorization paths, the number of hops in each authorization path, and the nodes included in each authorization path.

[0033] In some possible implementations, the mapped knowledge graph includes target user nodes representing the user to be configured and target resource nodes representing the resources operated by the user to be configured. The cloud instance is used to: traverse the access paths covered by the target user nodes to the target resource nodes from the mapped knowledge graph; match the access paths with preset legal access paths to obtain matching results; and determine that there are hidden risk path vulnerabilities after the permission configuration data is configured into the database if the access path is valid and the matching result indicates that the access path does not conform to the legal access path.

[0034] Thirdly, embodiments of this application provide an electronic device, including: at least one memory for storing a program; at least one processor for executing the program stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0035] Fourthly, embodiments of this application provide a computing device cluster, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to perform the method described in the first aspect or any possible implementation of the first aspect.

[0036] Fifthly, embodiments of this application provide a computer program product containing instructions, characterized in that, when the instructions are run by a cluster of computing devices, the cluster of computing devices performs the method described in the first aspect or any possible implementation thereof.

[0037] In a sixth aspect, embodiments of this application provide a computer-readable storage medium, characterized in that it includes computer program instructions, which, when executed by a cluster of computing devices, perform the method described in the first aspect or any possible implementation thereof.

[0038] It is understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0039] Figure 1This is a schematic diagram of the architecture of a cloud service system provided in an embodiment of this application;

[0040] Figure 2 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system provided in an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of the structure of a knowledge graph in one example of this application;

[0042] Figure 4 This is a flowchart illustrating the database vulnerability detection method based on a cloud service system provided in the embodiments of this application;

[0043] Figure 5 This is a schematic diagram illustrating the construction of a knowledge graph in one example of this application;

[0044] Figure 6 This is a schematic diagram illustrating the database permission vulnerability reasoning capability of a cloud instance in one example of this application;

[0045] Figure 7 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0046] Figure 8 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0047] Figure 9 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0048] Figure 10 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0049] Figure 11 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0050] Figure 12 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0051] Figure 13 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system, as shown in one example of this application.

[0052] Figure 14 This is a schematic diagram of the structure of a database vulnerability detection device based on a cloud service system provided in an embodiment of this application.

[0053] Figure 15This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0054] Figure 16 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0055] Figure 17 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0056] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0057] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0058] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0059] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0060] First, the technical terms used in this article will be explained below to facilitate understanding by those skilled in the art.

[0061] Cloud services: Cloud service providers offer cloud service resources to tenants via the Internet, enabling tenants to manage and use the technical services provided by the providers without having to purchase, own, and maintain physical data centers and servers.

[0062] Cloud data center: A data center that provides public cloud services, also known as infrastructure. Infrastructure includes multiple cloud data centers, each of which includes multiple servers, each of which can provide computing, networking, and storage resources.

[0063] Public cloud services, or Infrastructure as a Service (IaaS), refer to providing computing, networking, and storage resources from a public cloud service provider's infrastructure as a service. In this service model, users do not need to build their own physical data center; instead, they use the infrastructure that provides computing, storage, and networking services by renting it. Public cloud services from different tenants are isolated from each other.

[0064] Tenant: A user who rents infrastructure. Tenants can register an account with the public cloud service provider through a browser or other client. The public cloud service provider will record the accounts of different tenants and isolate the public cloud services of different tenants based on the accounts.

[0065] Users: Organizations or individuals who access cloud service resources. Users can include the tenant itself, or other organizations or individuals that the tenant grants access to the cloud service resources to.

[0066] Cloud management platform: A platform provided by public cloud service providers for interacting with users. Users can register an account on the cloud management platform and rent public cloud services using the account, thus becoming a tenant of the public cloud service. The cloud management platform is also used to manage infrastructure and to isolate the computing, network, and / or storage resources rented by different tenants based on their accounts.

[0067] Cloud instance: refers to an instance deployed on a cloud data center for running public cloud services. This cloud instance is used to provide computing, network, or storage resources. Cloud instances include, but are not limited to, services such as Elastic Cloud Server (ECS), containers, Bare Metal Server (BMS), Object Storage Service (OBS) buckets, Elastic Load Balancer (ELB), Network Address Translation Gateway (NAT Gateway), cloud caching, etc. ECS, for example, can be implemented through virtual machines.

[0068] A knowledge graph is a structured semantic knowledge base used to store information related to real-world entities (such as people, places, organizations, events, etc.) and describe the various relationships between these entities. Knowledge graphs are typically represented as graphs, where nodes represent entities and edges represent relationships between entities. This structured semantic network enables machines to understand and reason about complex information, such as distinguishing "100" as an entity number or a natural number, or inferring "A is B's mother, B is C's mother" that "A is C's maternal grandmother".

[0069] Specifically, a knowledge graph is a knowledge base that represents entities (or concepts) and their relationships in the objective world in the form of a graph. A knowledge graph can consist of two parts: a schema layer and a data layer. The schema layer is the conceptual model and logical foundation of the knowledge graph, and it can constrain the data layer using rules and axioms defined by the ontology. If reasoning is not required, a knowledge graph (mostly built from the bottom up) can have only a data layer without a schema layer. In the schema layer, nodes represent concepts, and edges represent relationships between concepts. In the data layer, facts are stored as triples of "entity-relationship-entity" or "entity-attribute-attribute value," forming a graph-like knowledge base. Entities are the basic elements of a knowledge graph, such as specific person names, organization names, place names, dates, and times. Relationships are semantic relationships between two entities and are instances of relationships defined in the schema layer. Attributes describe entities and are mappings between entities and attribute values. Attributes can be viewed as hasValue relationships between entities and attribute values, thus also being stored as triples of "entity-relationship-entity."

[0070] Neo4j: A graph database management system designed for storing and managing complex network structure data, such as social networks, recommendation systems, and knowledge graphs. It is an open-source, transactional database that supports ACID (Atomicity, Consistency, Isolation, Durability) transactions.

[0071] Cyper statements are the query language used by the Neo4j database. Designed for processing graphical data, they allow users to query and manipulate graphical data declaratively. They include statements for creating nodes, creating relationships, querying nodes, querying nodes with conditions, updating node attributes, deleting nodes, querying relationships, and using pattern matching.

[0072] Graph coloring algorithms are graph theory problems that assign colors to vertices in a graph such that adjacent vertices have different colors, while using as few colors as possible.

[0073] Graph traversal algorithms are used to systematically visit all vertices or nodes in a graph. There are two main types: Depth-First Search (DFS) and Breadth-First Search (BFS). DFS is a recursive or stack-driven traversal method that explores as deep as possible along a branch of the graph until it cannot continue, then backtracks to the nearest unfinished branch and continues exploring other branches. BFS is a queue-driven traversal method that starts from the beginning and visits all vertices in the graph layer by layer, moving to the next layer only after completing the previous one.

[0074] To facilitate the explanation of the database vulnerability detection method based on a cloud service system in the embodiments of this application, please refer to the following: Figure 1 , Figure 1 This is a schematic diagram illustrating a scenario of the database vulnerability detection method based on a cloud service system provided in an embodiment of this application. For example... Figure 1 The cloud service system 00 includes a cloud management platform 10 and infrastructure managed by the cloud management platform 10 for providing multiple cloud services. The infrastructure includes multiple cloud data centers 10X, each containing multiple servers X1, X2, ... . A single server (using server X1 as an example) includes a hardware layer and a software layer. The software layer is deployed with at least one cloud instance 1, 2, ... and a host operating system X10. Cloud instances 1, 2, ... can be, but are not limited to, virtual machines, containers, or other virtualized devices. A cloud instance manager X11 is configured on the host operating system X10 to manage cloud instances 1, 2, ... . The cloud instance manager X11 also includes a cloud management platform client X12, which communicates with the cloud management platform 10. The hardware layer of server X11 includes memory X01, a processor X02, a network interface card (NIC) X03, and a hard disk X04. The NIC X04 and network devices (such as routers, switches, firewalls, etc.) in the cloud data centers 10X... Figure 1 (Not shown in the diagram) This connection enables cloud instances 1, 2, ... to connect to the internet via network interface card X03. It can be understood that different cloud instances in different servers X1, X2, ... within different cloud data centers 10X all connect to the internet in this manner.

[0075] In this way, each server X1, X2, ... provides corresponding cloud services to tenants (such as tenants A and B) based on its own cloud service resources (such as computing power, storage capacity, database, etc.). Each tenant's cloud service can be implemented on one or more cloud instances. Cloud services offer a rich variety of database options, such as distributed database systems, multi-tenant database systems, high-security industry database systems, cloud database services, and enterprise-level permission management systems. These database systems present significant challenges in achieving high-security permission configuration. This is because, in a distributed database system environment, permission allocation often involves complex inheritance relationships between different physical nodes and user roles. In a multi-tenant database system architecture, permission configurations between different tenants also need strict isolation to ensure configuration rationality and prevent data leakage or unauthorized access. High-security industry database systems, such as those in finance, healthcare, and government sectors, typically have even stricter permission allocation requirements. Cloud database services (such as Relational Database Service, RDS) involve a large number of dynamic allocation operations in user permission management. Enterprise-level permission management systems, due to the need to address the complex organizational structure within an enterprise, typically require fine-grained permission control.

[0076] Due to the aforementioned complexity and difficulty in configuring permissions in these database systems, permission vulnerabilities are unavoidable. Furthermore, the large attack surface of the cloud environments hosting these database systems allows attackers to exploit these vulnerabilities, potentially leading to public data breaches, supply chain attacks, or even complete cluster shutdowns.

[0077] However, related technologies often overlook permission risks in database systems when performing database vulnerability detection, and even when they possess permission vulnerability analysis capabilities, they suffer from limitations. This is because, on the one hand, these technologies rely on explicit rules of the database system's permission configuration for analysis. This means that their permission risk analysis typically only covers the basic correctness of permission allocation, making it difficult to discover hidden risks in complex permission relationships. For example, indirect permissions obtained by users through role hierarchies may lead to unauthorized access or exposure of sensitive resources. On the other hand, the permission allocation relationships in database systems are complex and diverse, and often change dynamically over time, making it difficult for most static analysis tools to handle such complex environments. Furthermore, because these technologies must obtain permission to scan the database before they can rely on known risks for vulnerability matching and detection, the detection is highly constrained and lacks customized detection capabilities.

[0078] To enhance the detection capability of database vulnerabilities and improve its adaptability and flexibility, this application provides a database vulnerability detection method. This method primarily uses a knowledge graph to intuitively represent the database permission configuration and infers the risks inherent in the permission configuration based on the knowledge graph, thereby broadening the database vulnerability detection capability from the perspective of permission vulnerabilities. This method avoids the constraints of database administrator permissions, is highly adaptable, and offers significant flexibility.

[0079] Next, based on Figure 1 The system shown below provides a detailed description of the database vulnerability detection method provided in the embodiments of this application.

[0080] Please see Figure 2 , Figure 2 This is a flowchart illustrating a database vulnerability detection method provided in an embodiment of this application. Figure 2 As shown, the method includes, but is not limited to, the following steps:

[0081] S201, the cloud management platform obtains permission configuration data for the database.

[0082] In this embodiment, please refer to Figure 1 The cloud management platform 10 provides access interfaces (such as user interfaces or application program interfaces, APIs). Each tenant (such as...) Figure 1 Tenants A and B shown in the diagram can operate client 20 to remotely access the access interface, register cloud accounts and passwords on cloud management platform 10, and log in to cloud management platform 10. After successful authentication of the cloud account and password by cloud management platform 10, tenants can use client 20 to log in to cloud management platform 10 via the Internet to manage the rented database cloud service. For example, tenants can create database users, assign roles to database users, and set permissions for database users, but are not limited to this. For example, the client can be a mobile phone with Internet access, a personal computer, a personal digital assistant, a vehicle host, or other terminal device with Internet access capabilities. In addition, it should be understood that a database instance includes a database and a database management system (DBMS). A database system is a complete hardware and software environment that includes the database, DBMS, operating system, applications, and even more. A database instance is a dynamically running instance of a database system. In some contexts, those skilled in the art may also refer to a database system simply as a "database".

[0083] It should be noted that this article focuses on the technical solution for configuring database permissions. Therefore, the term "user" in this article, unless otherwise specified or interpreted or limited in the context of the word "user", refers to the user (or account) created by the tenant in the database instance, that is, the user who uses the database.

[0084] For example, a tenant's access control administrator can access the configuration interface provided by the cloud management platform 10 through a client and enter access control configuration data on the interface. The access control configuration data describes the role and permissions assigned to the user to be configured to operate cloud resources. The user to be configured can be an existing user in the database or a newly added user.

[0085] As a possible example, permission configuration data can include, but is not limited to, users, roles, permissions, and cloud resources, and the relationships between them. A user is an identifiable individual account in the database, representing a specific database user, possessing a unique identifier (such as a username or user ID) and authentication credentials (such as a password). A role is a collection of permissions used to simplify permission management; a role can contain multiple permissions, and a user can have multiple roles or no roles. A permission is the authorization to perform a specified operation on a given database cloud resource, representing a user's or role's access to the cloud resource. A cloud resource is a protected object in the database.

[0086] For example, the relationships contained in these permission configuration data are as follows: If a user has the Admin role, they have permission to manage all database object resources; if a user has the Developer role, they only have permission to access specified table or view resources; if a user has the Customer role, they are only allowed to view certain report resources, but not limited to these.

[0087] It should be understood that users can be granted permissions directly or indirectly through roles.

[0088] For example, different databases may have different permission allocation methods. As an example, and not a limitation, permissions can be subdivided into: database-level permissions, which are permissions to operate on the entire database, such as backing up a database; table-level permissions, which are permissions to operate on data in a specific table; column-level permissions, which are permissions to operate on data in certain columns of a table; and SQL statement permissions, which allow the execution of specific SQL commands. Alternatively, permissions can also be subdivided into: system permissions, which are permissions to operate on the entire database management system; object permissions, which are permissions to operate on specific database objects (such as tables, views, and stored procedures), such as querying a table (SELECT ON table) and modifying a view (UPDATE ON view); and data permissions, such as operating on specific data in a table.

[0089] In addition, in this example, the permissions granted for cloud resources include, but are not limited to, querying (SELECT), inserting (INSERT), modifying (UPDATE), deleting (DELETE), executing (EXECUTE), and changing (ALTER).

[0090] For example, cloud resources include, but are not limited to: data resources, such as tables, views, stored procedures, and column resources (employees.salary); structural resources, such as schemas and databases; and system resources, such as server instances. The specific granularity of cloud resources determines the fineness of permissions.

[0091] S202, the cloud management platform 10 sends the permission configuration data to the cloud instance.

[0092] In this step, the tenant's permission administrator transmits permission configuration data to the cloud management platform 10 through the configuration interface. The cloud management platform 10 can then distribute the permission configuration data to at least one cloud instance of the tenant based on the tenant's cloud account. For ease of description, the following explanation uses cloud instance 1 as an example to illustrate the steps of this method.

[0093] S203, the cloud instance maps permission configuration data to the knowledge graph to obtain the mapped knowledge graph.

[0094] In this step, a knowledge graph is pre-built on the tenant's cloud instance 1. This knowledge graph reflects the permission configuration in the tenant's database instance. The knowledge graph can include multiple nodes and at least one edge connecting them. Each node represents an entity in the database, including users, roles, permissions, and cloud resources. Each edge represents the relationships between entities. In other words, the knowledge graph can convert the database's permission configuration data into nodes and edges. Users, roles, permissions, and cloud resources are mapped to nodes, while the hierarchical relationships between users and roles, the assignment relationships between roles and permissions, and the interaction relationships between permissions and cloud resources are mapped to corresponding edges. Nodes and edges have their own attributes, which provide rich contextual information, enabling the entire knowledge graph to more comprehensively express the database permission configuration relationships. This provides in-depth support for permission analysis and detection, facilitating more accurate reasoning.

[0095] In some possible examples, the node types in a knowledge graph can include:

[0096] User nodes include, but are not limited to, user identifier (which can be username or ID, used to uniquely identify the user), user status (e.g., active / inactive, used to indicate whether the user is active), last login time (used to analyze user activity), user's department (to distinguish the scope of permissions), and user risk level (e.g., high / medium / low, which can be determined based on audit logs).

[0097] The Role node has attributes including, but not limited to, Role Name (used to uniquely identify the role), Role Hierarchy (used to describe the role's position in the permission inheritance chain), Role Creation Time (used to audit the role's history), and Role Description Information (to help personnel understand the role's purpose).

[0098] The Privilege node has attributes including, but not limited to, the validity period of the permission (determined by the start and end times) and the permission grantor (used to track the source of the permission).

[0099] Cloud resource nodes, also known as database object nodes, have attributes including but not limited to the sensitivity level of the database object (such as confidential, public, restricted).

[0100] In this example, each edge of the knowledge graph can also have additional attributes added to record the information represented by the edge. The types of relationships (i.e., edge types) that edges between nodes can represent include, but are not limited to, the following:

[0101] Dependency Relationships (BELONGS_TO / HAS_ROLE): Used to connect user nodes and role nodes to describe the permissions inherited by users through roles. The structure of a dependency relationship can be represented as: (User)-[:BELONGS_TO]->(Role). It can be understood that "-[:]->" indicates a connection between two entities, and "-[:BELONGS_TO]->" indicates a "belongs to" relationship between the two connected entities. This dependency relationship has no specific attributes; that is, it does not attach any additional characteristics.

[0102] The HAS_PERMISSION permission relationship connects role nodes and permission nodes to describe the set of permissions a role directly possesses. The structure of a permission relationship can be represented as: (Role)-[:HAS_PERMISSION]->(Privilege). Attributes of the permission relationship can include, but are not limited to, the validity period of the permission.

[0103] The `ON_OBJECT` relation connects a privilege node and a database object node to describe the database object that grants permission for an operation. The structure of an `ON_OBJECT` relation can be represented as: `(Privilege)-[:ON_OBJECT]->(DatabaseObject)`. The attributes of an `ON_OBJECT` relation can include, but are not limited to, the sensitivity level of the database object.

[0104] Permission inheritance relationship (DEPENDS_ON): Used to connect two permission nodes to describe the propagation or dependency relationship of permissions. The structure of the permission inheritance relationship can be represented as: (Privilege)-[:DEPENDS_ON]->(Privilege). The attributes of the permission inheritance relationship can include, but are not limited to, the inheritance hierarchy.

[0105] Permission Conflict Relationship (CONFLICTS_WITH): Used to connect two permission nodes, describing the possible conflict relationships between them. The structure of a permission conflict relationship can be represented as: (Privilege)-[:CONFLICTS_WITH]->(Privilege). The attributes of a permission conflict relationship may include, but are not limited to, conflict rule descriptions. Permission conflict refers to the situation where different users or roles are granted contradictory or inconsistent permissions, causing the system to malfunction or exhibit unpredictable behavior. Therefore, permission conflicts may exist between different permission nodes of the same user, or between different user nodes.

[0106] Permission extension relationships (EXTENDS): Used to connect two permission nodes to describe the extension of permissions. For example, the UPDATE permission implicitly includes the SELECT permission. The structure of a permission extension relationship can be represented as: (Privilege)-[:EXTENDS]->(Privilege). The attributes of the permission extension relationship include, but are not limited to, the extension description (extensionDetails).

[0107] Temporary authorization relationship (TEMPORARY_GRANTED): Used to connect the permission node and the user node to describe a permission that is temporarily granted to a user. The structure of a temporary authorization relationship can be represented as: (Privilege)-[:TEMPORARY_GRANTED]->(User). The attributes of the temporary authorization relationship include, but are not limited to, the authorization expiration time.

[0108] For example, refer to Figure 3 The example shown is a knowledge graph that may include a schema layer and a data layer. Nodes and edges form the schema layer; nodes represent entities that configure permission data, and edges represent relationships between entities. In the data layer, permission configuration facts from the database are stored as triples of "entity-relationship-entity," forming a graph-like knowledge base. For example, in... Figure 3 In the knowledge graph, the data layer records the triple "Alice-{:BELONGS_TO}-Admin", which represents the permission configuration fact that "user Alice belongs to the administrator role Admin". Correspondingly, this permission configuration fact can be represented in the schema layer of the knowledge graph as a subordinate relationship between the user node u (representing user Alice) and the role node r (representing administrator role Admin).

[0109] In this way, the knowledge graph on cloud instance 1 can clearly store and intuitively display the rich permission configuration relationships in the tenant's database.

[0110] In this step, whenever a tenant performs a permission configuration operation on its database—that is, the cloud management platform 10 obtains the permission configuration data input for this operation and transmits it to cloud instance 1—cloud instance 1 can map the permission configuration data to the stored knowledge graph, resulting in the mapped knowledge graph, also referred to as the updated knowledge graph in this paper. Specifically, when mapping permission configuration data to the knowledge graph, the user to be configured in the permission configuration data can be mapped to an existing user node in the knowledge graph (i.e., the user to be configured is an existing user in the database). If no matching existing user node exists, it is mapped to a newly added user node (i.e., the user is a newly added user in the database). Similarly, information such as cloud resources, roles, permissions, and their relationships in the permission configuration data is mapped to existing or newly added nodes and edges in the knowledge graph.

[0111] In this way, when a tenant's database permission configuration changes, cloud instance 1 can dynamically update the knowledge graph accordingly. This eliminates the need for a full database scan, allowing for real-time analysis of the database's permission configuration without significantly impacting database operations, and providing a clear representation through the knowledge graph.

[0112] S204 indicates a permission vulnerability caused by a cloud instance inferring that restricted configuration data was configured into the database based on the mapped knowledge graph.

[0113] In this step, cloud instance 1 can infer whether the permission configuration data currently entered by the tenant will cause a permission vulnerability after being configured into the database, and the type of vulnerability when it does, based on the topology formed by the nodes and edges in the mapped knowledge graph, mainly the propagation path of roles and permissions.

[0114] For example, privilege vulnerabilities may include, but are not limited to, privilege escalation risk vulnerabilities, privilege abuse risk vulnerabilities, privilege conflict risk vulnerabilities, privilege redundancy risk vulnerabilities, and related hidden privilege risk vulnerabilities.

[0115] Among these, unauthorized access vulnerabilities occur when a user possesses operational capabilities in the database beyond their authorized scope, potentially allowing them to access or modify other users' sensitive data or critical cloud resources. Permission abuse vulnerabilities occur when a user possesses permissions in the database beyond their role's responsibilities, potentially leading to security risks. Permission conflict vulnerabilities arise from conflicting permissions, causing the database to fail to correctly determine a user's actual privileges. Redundancy vulnerabilities refer to the repeated assignment of unnecessary permissions to users, increasing the burden of permission management. Hidden permission vulnerabilities occur when users acquire relatively hidden permissions through methods such as role inheritance, leading to security risks.

[0116] In this way, Cloud Instance 1 can deduce a variety of permission configuration vulnerabilities based on the node and edge types of the knowledge graph, which meets the diverse needs of the market for database permission vulnerability detection. Moreover, the detection process is not constrained by factors such as the database's full authorization for vulnerability detection, making it highly adaptable and flexible.

[0117] For further clarification, please see Figure 4 , Figure 4 This is a flowchart illustrating a database vulnerability detection method based on a cloud service system provided in an embodiment of the present invention.

[0118] Specifically, Figure 4 yes Figure 2 Further details on the database vulnerability detection method provided for cloud service systems, combined with... Figure 1 The system shown, further as Figure 4 As shown, the method includes the following steps:

[0119] S401, the cloud instance collects database permission configuration data according to data collection rules.

[0120] In this step, after creating a database instance on cloud instance 1, the tenant can collect the corresponding database permission configuration data to build the corresponding knowledge graph. In addition, cloud instance 1 can also periodically (customizable according to time requirements, such as daily or weekly) collect permission configuration data from the database to update the constructed knowledge graph, so as to ensure the accuracy and timeliness of the knowledge graph.

[0121] For example, since permission management differs across databases, data collection rules can be pre-configured on cloud instance 1 to describe the collection methods or channels (i.e., sources) that match different databases. As an example, there are multiple sources for obtaining permission configuration data, such as from the database access layer (DAL), through third-party permission management tools used by the DBMS, or through manually defined methods, and so on. It should be understood that the database access layer is the middle layer in the application architecture responsible for interacting with the database. It encapsulates all data persistence operations, including CRUD (create, read, modify, delete) operations, and provides a unified data access interface. As an example, the interface includes, but is not limited to, metadata interfaces, access control interfaces, and audit log interfaces (interfaces used to record data access operations). Metadata interfaces can be used to obtain structural information related to permission configuration, such as metadata tables and field types. Access control interfaces refer to the set of interfaces in DBMS20 used to extract the association information between users, roles, and permissions. From these, one can obtain information such as the binding relationship between users and roles, the set of permissions possessed by roles, the cloud resources corresponding to permissions, and the corresponding operation actions. The access control interface supports parsing access control policies and reading configuration data, covering static authorization relationships (such as user-role-permission mapping) as well as possible policy-based dynamic authorization rules (such as time, location and other contextual constraints).

[0122] The following explains the principles by which cloud instance 1 obtains permission configuration data from the aforementioned sources.

[0123] For example, since basic permission configuration information is recorded in the metadata tables of different database DBMSs, Cloud Instance 1 can request and query metadata tables and permission configuration-related information from these DBMSs through the metadata interface and access control interface of the access layer to obtain structured permission configuration data. As an example, Table 1 below shows the permission configuration data obtained by Cloud Instance 1 from MySQL and PostgreSQL DBMSs.

[0124] Table 1:

[0125]

[0126] As shown in Table 1, MySQL and PostgreSQL have different permission management methods. Cloud Instance 1 can adapt to these differences by accessing different metadata tables or permission configuration information as shown in Table 1 from both MySQL and PostgreSQL. In Table 1, user information may include fields such as: user ID / name, user status (e.g., active / inactive, indicating whether the user is active), creation time (created_date), last login time, password expiration time, and account type (system account / regular account), but is not limited to these. Role information may include fields such as: role name, role ID, creator, creation time, whether it is inheritable, whether a password is required, and role description information, but is not limited to these. Role inheritance relationships may include fields such as: parent role / inherited role, child role / inherited role, inheritance method, permission grantor, and authorization time, but is not limited to these. It should be understood that permission inheritance is a mechanism in database permission management, referring to a child role automatically acquiring some or all of the permissions of the parent role. Role inheritance relationships are multi-level containment relationships between roles, which can form a tree-like or graph-like structure. The complete path of permissions acquired by a role from other roles through inheritance is called a permission inheritance chain. For example, "Senior Administrator Role → Department Administrator Role → Regular User Role" is a permission inheritance chain, where "→" indicates a "being inherited" relationship. The inheritance method is that when a higher-level role is granted permissions, these permissions can automatically propagate to lower-level roles.

[0127] In this way, cloud instance 1 obtains some or all of the permission configuration data required for subsequent knowledge graph construction from the metadata tables and permission configuration information of different DBMSs.

[0128] For example, cloud instance 1 can also obtain database audit logs through the access layer's audit log interface. The database audit logs record user operation behaviors, allowing cloud instance 1 to capture dynamic permission changes and the actual use of operational permissions. As an example, the database audit logs include, but are not limited to: cloud resources accessed by users (such as tables, views, and stored procedures), operations performed by users (such as SELECT, INSERT, and UPDATE), and permission change events (such as granting permissions GRANT and revoking permissions REVOKE). Therefore, the collection module 110 can obtain some or all of the permission configuration data required for subsequent knowledge graph construction from the database audit logs.

[0129] For example, if the DBMS uses a third-party permission management tool, Cloud Instance 1 can also obtain permission configuration data through the application programming interface (API) of these tools. For instance, in a cloud-based database management system, Identity and Access Management (IAM) is the core tool for permission configuration, used to define permission policies for users, roles, groups, and interactions with cloud resources. Therefore, Cloud Instance 1 can also obtain detailed permission allocation information for users and roles (including access permissions to specific cloud resources such as OBS buckets and ECS instances) through the API provided by IAM or exported permission configuration files, to obtain some or all of the permission configuration data needed for subsequent knowledge graph construction.

[0130] Furthermore, in some scenarios, permission configuration data can be manually entered or corrected by the DBMS administrator (i.e., someone with the administrator role), such as custom permission policies or permission configurations outside the database (e.g., system-level operation permissions or file system permissions). This enriches the sources of permission configuration data, which on the one hand improves adaptability to different DBMSs, and on the other hand, enhances the diversity, accuracy, and comprehensiveness of permission configuration data required for subsequent knowledge graph construction, thereby improving the quality and effectiveness of vulnerability detection.

[0131] In some possible implementations, cloud instance 1 can establish a secure connection with the database under test (referred to as the "target database" in this document) through a database connection interface (such as JDBC / ODBC or a database driver). Then, depending on the type of the target database, cloud instance 1 executes standardized query statements or calls API interfaces to obtain the required permission configuration data from some or all of the aforementioned sources, and obtains the permission configuration data through a secure transmission protocol (such as SSL / TLS).

[0132] In some optional examples, after collecting the required permission configuration data, cloud instance 1 also performs format verification and cleaning operations on the permission configuration data to improve data quality. For example, the format verification operation includes checking whether the permission configuration data is accurate and complete according to preset format specifications (such as whether the user corresponds to the role and whether the permission is bound to cloud resources), and the cleaning operation includes removing duplicate and redundant data to ensure the efficiency of using the permission configuration data for graph construction in the future.

[0133] S402, cloud instances convert permission configuration data into multiple triplet information.

[0134] In this step, similar to the execution principle of S430 in the example above, Cloud Instance 1 can convert all entities such as users, resources, roles, and permissions in the obtained permission configuration data, as well as the relationships between these entities, into corresponding triplet information. Each triplet records the relationship between two entities. For example, the dependency relationship between user A and role R (BELONGS_TO) can be represented by the triplet information as "User A - {:BELONGS_TO} - Role R"; the granting relationship between user B and permission P (GRANTED) can be represented by the triplet information as "User B - {:GRANTED} - Permission P"; the action relationship between permission P and resource S (ON_OBJECT) can be represented by the triplet information as "Permission P - {:ON_OBJECT} - Resource S". The triplet information for other entity relationships is similar.

[0135] S403, Cloud Instance 1 maps entities from multiple triples to existing or newly added nodes in the knowledge graph, and connects them through corresponding edges to obtain the mapped knowledge graph.

[0136] In this step, Cloud Instance 1 maps the entities in the multiple triples obtained to existing or newly added nodes in the knowledge graph, connecting them with corresponding edges to correctly and completely represent the topological relationships and semantics reflected by these triples in the knowledge graph, thus obtaining the mapped knowledge graph. During the mapping process, the entity relationships in the triples are mapped to corresponding edges, which can be directed edges or edges with attached attributes, thereby representing the characteristics of the entity relationships. For example, if a triple records the granting relationship between user B and permission P, the resulting edge will have an attached authorization expiration time to restrict user B's temporary use of permission P. As another example, if a triple records the inheritance relationship (INHERITS_FROM) between role R1 and role R2, the resulting edge will be a directed edge, pointing from the role node representing role R1 to the role node representing role R2, indicating that role R1 inherits from role R2. The corresponding role inheritance chain can be represented as "R2→R1". It is understandable that directed edges are used to point lower-level character nodes to higher-level character nodes, and the "→" symbol in the character inheritance chain representation is used to point from a higher-level character to a lower-level character.

[0137] In this way, by converting the database permission configuration data into triple information and then mapping it to the knowledge graph, subsequent database permission vulnerability detection can be performed based on the obtained knowledge graph.

[0138] In some possible implementations, the knowledge graph can be stored in a graph database (such as Neo4j), and during the construction or updating of the knowledge graph, batch creation operations of nodes and edges can be performed using the Cypher language. Below are a few examples of completing the mapping of entities and their relationships in a knowledge graph:

[0139] Please refer to Figure 5 The example shown illustrates the construction of a knowledge graph. Regarding the creation of user-role relationships, if user Alice is determined to have the role admin based on permission configuration data, the code for creating this relationship using the Cypher language could include:

[0140] "MERGE(u:User{name:'alice'})

[0141] MERGE(r:Role{name:'admin'})

[0142] MERGE(u)-[:BELONGS_TO]->(r)”

[0143] The first MERGE statement in this code snippet checks if a node with the user label "User" and the name attribute "alice" exists. If it doesn't exist, the node "u" is created; if it already exists, it is matched, and the matched or created node is bound to node "u". The second MERGE statement is similar, checking if a node "r" with the role label "Role" and the name attribute "admin" exists. If it doesn't exist, it is created; if it exists, it is matched and bound to node "r". The third MERGE statement checks if a relationship of type "BELONGS_TO" exists between nodes "u" and "r". If it doesn't exist, this relationship is created; if it already exists, no action is taken. This results in the following... Figure 5 The node-edge relationship is shown in (5a).

[0144] Similarly, when creating the relationship between roles and permissions, if the role admin is granted SELECT and DROP permissions (used to remove one or more objects from the database), then Cypher code snippets could include:

[0145] MERGE(p1:Privilege{type:'SELECT'}) creates a privilege node.

[0146] MERGE(p2:Privilege{type:'DROP'})

[0147] MERGE(r)-[:HAS_PERMISSION]->(p1)

[0148] MERGE(r)-[:HAS_PERMISSION]->(p2)”

[0149] The first MERGE statement in this code snippet checks if a node with the permission label "Privilege" and the type attribute "SELECT" exists. If it doesn't exist, the node p1 is created; if it already exists, it is matched directly, and then the matched or created node is bound to node p1. The second MERGE statement is similar, checking if a node with the permission label "Privilege" and the type attribute "DROP" exists. If it doesn't exist, node p2 is created; if it exists, it is matched and bound to node p2. The third and fourth MERGE statements check if nodes p1 and p2 have a relationship of type HAS_PERMISSION with node r (i.e., the role admin). If they don't exist, this relationship is created; if it already exists, no action is taken. This results in the following... Figure 5 The node-edge relationship is shown in (5b).

[0150] Similarly, when creating a relationship between permissions and cloud resources, if the permission SELECT applies to the cloud resource SensitiveTable, then Cypher code snippets can include:

[0151] "MERGE(res:Resource{name:'SensitiveTable'})

[0152] MERGE(p1)-[:ON_OBJECT]->(res)

[0153] MERGE(r)-[:HAS_PERMISSION]->(p1)”

[0154] The MERGE statement in this code snippet is similar to the examples above. It creates or binds a cloud resource node `res` with the label `Resource` and the name attribute `name` of 'SensitiveTable'. Then, it establishes the relationship between the cloud resource node `res` and node `p1` (i.e., the 'SELECT' permission), and the permission association between node `r` (i.e., the role `admin`) and node `p1`. Thus, the `SELECT` permission held by the role `admin` can be applied to the cloud resource `SensitiveTable`. This creates a result like... Figure 5 The node and edge relationships are shown in (5c).

[0155] It is understandable that the creation of the same type of relationship between other nodes, or the creation of other types of relationships between other nodes, is similar to the creation of the above-mentioned types of relationships, and will not be listed one by one.

[0156] The knowledge graph created in this example allows for the intuitive and accurate representation of the relationships between database users, roles, permissions, and cloud resources through a graph structure. Even with complex and overlapping relationships between users and roles, roles and permissions, and permissions and cloud resources, a knowledge graph describing the permission configuration in the database can be quickly constructed. Specifically, it can adapt to various scenarios, including multi-level permission systems (such as object permissions and statement permissions (such as SELECT, INSERT, UPDATE), complex inheritance relationships (such as permission stacking and conflicts), dynamic permission changes (such as frequent permission modifications due to business needs), and permission auditing and compliance requirements. It also enables timely dynamic updates and efficient storage of multi-dimensional permission configurations, making it easy to implement. This solves the problem of traditional detection tools struggling to intuitively represent complex permission relationships, improving the efficiency and scalability of permission risk analysis.

[0157] Continue to refer to Figure 4 After building or updating the knowledge graph, tenants can also input permission management data into the configuration interface of the cloud management platform 10 as needed (e.g., a tenant configuring new permissions for its employees). This requests the cloud management platform 10 to configure the permission configuration data into the tenant's database instance, and simultaneously triggers the cloud instance 1 platform to send the permission configuration data to cloud instance 1, enabling cloud instance 1 to perform similar operations on the current knowledge graph. Figure 2 The update operations described in S201 to S203 are shown below. Furthermore, in this example, the principle of mapping permission configuration data to the knowledge graph involved in S201 to S203 is similar to the process of mapping permission configuration data to the knowledge graph in S402 to S403 above, and will not be repeated here. Thus, after S203 or S403, a mapped knowledge graph can be obtained, and then cloud instance 1 can infer permission vulnerabilities based on the mapped knowledge graph. For ease of explanation, the following section uses the mapped knowledge graph obtained through S203 as an example to further illustrate the process of inferring database permission vulnerabilities.

[0158] For example, such as Figure 4 As shown, after obtaining the updated knowledge graph, this method may further include:

[0159] S404 indicates a permission vulnerability caused by the cloud instance inferring the permission database configuration after it was added to the database based on the mapped knowledge graph.

[0160] In this step, after cloud instance 1 maps the tenant's data configuration information to the knowledge graph, it can perform path analysis and reasoning based on the mapped knowledge graph. From the nodes of the mapped knowledge graph and the relationship types between the nodes, it can infer the permission vulnerabilities existing in the database and generate a detection report for personnel to understand the detailed detection situation.

[0161] The mapped knowledge graph includes at least one of the following: a target user node representing the user to be configured, a target role node representing the assigned role, a target permission node representing the assigned permissions, and a target resource node representing the resources operated by the user to be configured. A target user node is connected to at least one target role node, a target role node is connected to at least one target permission node, and a target permission node is connected to at least one target resource node, but is not limited to these. The topological structure and semantic dependencies formed between target user nodes, target role nodes, target permission nodes, and target resource nodes form the basis for Cloud Instance 1 to infer whether a permission vulnerability has been introduced in the database.

[0162] Optionally, to ensure the reliability of permission risk detection, in this example, cloud instance 1 can perform a preliminary verification task on the mapped knowledge graph before executing S470 to check all nodes and edges in the knowledge graph and verify its correctness. For example, the preliminary verification task may include isolated node detection and edge type consistency detection.

[0163] Orphan node detection involves checking for unassociated nodes (such as orphaned users or permissions). Orphaned nodes are those without any connections. For example, an orphaned user node indicates that the user is not associated with any role or permission; an orphaned permission node indicates that the permission has not been granted to any role or cloud resource; and an orphaned role node indicates that the role has not been assigned to any user.

[0164] For example, the process of orphan node detection in Cloud Instance 1 includes: traversing all nodes in the mapped knowledge graph and calculating the number of edges (or degree, including in-degree and out-degree) connected to each node. In-degree refers to the number of edges pointing to that node; for example, if a permission node is assigned multiple roles, then that permission node has a high in-degree. Out-degree refers to the number of edges pointing to other nodes from that node; for example, when a role node has multiple permissions, the role node has a high out-degree. Next, Cloud Instance 1 identifies orphan nodes with 0 edges from all nodes, and then generates knowledge graph optimization suggestions based on these orphan nodes.

[0165] In this way, by efficiently traversing and analyzing the large-scale permission configuration data in the database, isolated nodes can be identified to facilitate personnel in correcting the knowledge graph, thus avoiding the inefficiency and error rate of manual inspection.

[0166] For example, edge type consistency checking verifies whether edge types conform to predefined permission management rules. Permission management rules are a collection of rules describing how to manage access control, how to assign permissions, and how to ensure that only appropriate users can access specific cloud resources, thereby defining and managing the compliance relationships between users, roles, permissions, and cloud resources. Permission management rules can be abstracted into a permission model. As an example, and not a limitation, a permission model may include:

[0167] Role-Based Access Control (RBAC) is a model used to constrain the assignment of different types of permissions to different levels of roles, and to assign different levels of roles to users, so that users can obtain access to cloud resources through their roles.

[0168] Attribute-Based Access Control (ABAC) model: It can constrain access control based on attributes such as user, cloud resource, and environment.

[0169] Access Control List (ACL) based model: Used to configure an access control list for each cloud resource to list which users or roles have permissions for that cloud resource.

[0170] Policy-Based Access Control (PBAC) is a model used to define access permissions based on specific policies (such as time, location, and other contextual conditions).

[0171] These permission models are used to standardize the allocation of permissions, prevent unauthorized access and abuse of permissions, and ensure the compliance of the knowledge graph (e.g., role nodes must be connected to permission nodes).

[0172] Based on the permission model, the process of edge type consistency detection in cloud instance 1 may include: traversing all edge types and their connected nodes in the knowledge graph, matching these edge types and their connected nodes using rules in the permission model, thereby verifying whether user nodes are correctly connected to compliant role nodes and whether they conform to role allocation rules, as well as verifying whether role nodes are correctly connected to permission nodes and whether they conform to permission allocation rules. It can also verify whether the edges between permission nodes and cloud resource nodes conform to cloud resource access rules. After verification, edges in the knowledge graph that do not conform to permission management rules are marked as "defects," "vulnerabilities," or "risks," and relevant error or warning messages are output to remind administrators to make corrections, ensuring the correctness of the knowledge graph.

[0173] In this embodiment, after cloud instance 1 completes the aforementioned preliminary verification task, it can execute step S407 of this method, namely, performing a permission vulnerability assessment based on the mapped knowledge graph. For example, as shown... Figure 6 As shown, permission vulnerability reasoning can include, but is not limited to, inheritance path inference and redundant permission detection. Inheritance path inference identifies unreasonable permission transfers by analyzing role and permission inheritance relationships. The inference process involves precise tracking and analysis of inheritance paths to discover risks caused by potential improper permission configurations. Redundant permission detection identifies redundancy and bypass phenomena in permission configurations by traversing paths in a knowledge graph.

[0174] For example, continue to refer to Figure 6 Inheritance path inference is based on the inter-node paths of a knowledge graph, enabling unauthorized path detection, permission abuse detection, inheritance depth auditing, and / or permission conflict checking. Unauthorized path detection determines whether a low-privilege user can indirectly inherit undue high privileges (such as DROP or DELETE permissions) through role inheritance paths (role nesting or multi-level inheritance). Permission abuse detection determines whether a user intentionally or unintentionally performs operations beyond the expected scope within their granted permissions. For example, a role may have query and delete permissions, but the actual responsibility of that role only requires query permissions. If user A is assigned this role, then user A can use the delete permission to delete other users' cloud resources. Inheritance depth auditing restricts the length of permission inheritance paths. If a user's permission inheritance chain is too long (exceeding a set threshold), it may mean an additional management burden is needed. Permission conflict checking primarily detects whether the same user is granted mutually exclusive permissions in different paths, such as having both read / write and delete permissions simultaneously, which may pose a security risk.

[0175] The following section, with reference to the accompanying diagram, describes the process of inferring database permission vulnerabilities using the S404 vulnerability in Cloud Instance 1 through this method.

[0176] For example, such as Figure 7 As shown, S404 in this method may include:

[0177] S4041, the cloud instance traverses at least one inheritance path from the target user node to the target resource node from the mapped knowledge graph.

[0178] In this step, given that inheritance relationships typically exist between roles—one role may inherit from another and acquire the permissions of that role through inheritance—Cloud Instance 1 first identifies the inheritance relationships formed by all target role nodes in the mapped knowledge graph. These inheritance relationships are represented by directed paths (directed edges, from lower-level nodes to higher-level nodes) between nodes, forming role inheritance paths. For example, if target role node R points to role node R1 in the knowledge graph through an inheritance edge, and the permission node connected to role node R1 (such as a node representing DROP permissions) forms an indirect connection with target role node R, this means that the role represented by role node R1 possesses DROP permissions, and the role represented by target role node R also acquires DROP permissions through this role inheritance path.

[0179] Furthermore, Cloud Instance 1 will also identify the inheritance relationships formed by all target permission nodes in the mapped knowledge graph. This inheritance relationship is represented by directed edges between nodes, forming permission inheritance paths. For example, in this knowledge graph, there is a resource node s1, which represents a table. Resource node s1 connects to permission nodes (such as the node representing the DROP permission). The target resource node res represents a column of data in this table, and the target resource node res points to resource node s1 through hierarchical relationship edges. In this way, the node with the DROP permission forms an indirect connection with the target resource node res, indicating that the DROP permission can be applied to the column of data represented by the target resource node res.

[0180] As an example, and not a limitation, Cloud Instance 1 can use either Depth-First Search (DFS) or Breadth-First Search (BFS) algorithms to traverse the inheritance relationships between role nodes in the knowledge graph, obtaining all role inheritance paths from each parent role to its child roles. For example, the inheritance path "Role Admin → Role Editor → Role Viewer" indicates that Role Viewer inherits the permissions of Role Editor, and Role Editor inherits the permissions of Role Admin. In this example, Cloud Instance 1 can use the DFS algorithm to delve as deep as possible along an inheritance path in the knowledge graph until it can no longer inherit (reaching a leaf node), then backtrack to explore other branches, traversing from low-privilege roles (such as Guest) to high-privilege roles at higher levels, thereby finding all possible inheritance paths and detecting the risk of multi-level permission leaks. Furthermore, Cloud Instance 1 can also use the BFS algorithm to expand the search of the knowledge graph layer by layer, first exploring all child roles that directly inherit the permissions of the highest-level parent role, and then continuing to advance to lower levels.

[0181] S4042, the cloud instance will match at least one inheritance path with the preset inheritance rules to obtain the matching result.

[0182] In this step, after Cloud Instance 1 traverses the inheritance paths, it determines whether these inheritance paths are reasonable according to preset inheritance rules. Specifically, it checks whether the inheritance paths are unauthorized, whether the inheritance depth exceeds a threshold, or whether there are permission conflicts. Inheritance rules define the inheritance specifications that security-compliant paths must follow (such as the principle of least privilege and the principle of separation of duties). These rules define inheritance rules and security path length thresholds between different user levels, roles, and permission types with different sensitivities. This regulates which child nodes (lower-level roles) in the inheritance path can inherit permissions from various parent nodes, based on dimensions such as role inheritance, permission inheritance, and path depth. Lower-level roles have fewer permissions. Furthermore, it can define which child nodes (lower-level roles) in the inheritance path can inherit permissions from various parent nodes based on the different sensitivities of different permission types.

[0183] In this way, Cloud Instance 1 matches each inherited path with the inherited rules. If an inherited path matches an inherited rule, or if it violates the principles followed by the inherited rules, Cloud Instance 1 determines that the inherited path is unreasonable. For example, if the inherited rule defines that the administrator's DROP permission (a sensitive permission) should not be passed to ordinary users, then if inherited path L indicates that the target user u is an ordinary user and obtains the administrator's DROP permission through role inheritance, then because inherited path L matches the inherited rule, Cloud Instance 1 determines that inherited path L is a risky path. It can be understood that the content of the inherited rules is defined according to the actual permission configuration requirements of the database; this example does not impose specific limitations.

[0184] The following section explains the principles behind analyzing various permission risks through path matching.

[0185] In an example of privilege escalation vulnerability detection, such as Figure 8 As shown, S4042 may include:

[0186] S40421, The cloud instance determines at least one inheritance path indicating that the target user node is indirectly associated with the target permission node through the role inheritance path of the target role node, and there is no direct granting relationship between the target user node and the target permission node.

[0187] In this step, cloud instance 1 determines through querying that there is at least one inheritance path. These inheritance paths indicate that the target user node is indirectly associated with the target permission node through the role inheritance path of the target role node. The target permission node has specified sensitive permissions, and there is no direct granting relationship between the target user node and the target permission node. Sensitive permissions can be high-level permissions, such as the delete permissions DROP and DELETE that may lead to data loss, or the GRANT and REVOKE permissions assigned by management permissions, but are not limited to these.

[0188] S40422, the cloud instance will match at least one inheritance path with the preset inheritance rules, and determine the matching result as at least one inheritance path matching the first rule in the inheritance rules.

[0189] In this step, the first rule describes a path that may contain privilege escalation vulnerabilities, also referred to as the first risk inheritance path. The first risk inheritance path indicates that a user indirectly obtains preset sensitive permissions through role inheritance, and these sensitive permissions exceed the scope of permissions directly possessed by the user's assigned role. If the inheritance path matches this first rule, Cloud Instance 1 determines that the inheritance path is unreasonable and contains a privilege escalation vulnerability.

[0190] For example, Cloud Instance 1 uses a Cypher code snippet similar to the following to find multiple inheritance paths that match this first rule:

[0191] "MATCH path=(u:User)-[:ASSIGNED]->(r:Role)-[:GRANTED]->(p:Privilege)-

[0192] [:APPLIED]->(res:Resource)

[0193] WHERE p.type IN['DROP','DELETE']AND res.name='SensitiveTable'

[0194] WITH u,path,p

[0195] WHERE NOT(u)-[:GRANTED]->(:Privilege)

[0196] RETURN u.name AS UserName,COLLECT(DISTINCT r.name)AS Roles,COLLECT(DISTINCT p.type)AS Privileges,res.name AS Resource”

[0197] In this code snippet, the MATCH statement is used to query the path, starting from user node u and matching along the path of role assignment, role-granted permissions, and permission application to cloud resources to query the permissions acquired by the user through the role inheritance chain, and these permissions apply to a specified cloud resource (such as SensitiveTable). The first WHERE statement is used to filter out high-level permissions of a specified type that user node u may have, that is, permissions with permission type (p.type) of "DROP" or "DELETE", and the cloud resource name res.name that these two permissions apply to is 'SensitiveTable'. In other words, this WHERE statement only focuses on "DROP" or "DELETE" permissions for a specific operation-sensitive table (e.g., 'SensitiveTable'). The WITH statement passes the retrieved user node u, path, and privilege nodes to the next query step (i.e., the query logic qualified by WHERE NOT) for further processing. The second WHERE clause further filters user u, ensuring that the filtered user u has not been directly granted any permissions (i.e., not directly connected to a permission node through a GRANTED relationship). This means ensuring that the queried user u acquired permissions through role inheritance in the path, but the user u itself has not been directly granted permissions. The RETURN statement returns the names of the users in the query results and the roles associated with these users, aggregated using COLLECT(DISTINCT r.name) to ensure role names are unique. The RETURN statement also returns the types of permissions the user possesses, similarly aggregated using COLLECT(DISTINCT p.type) to remove duplicates. Finally, the RETURN statement returns the names of the cloud resources operated by the user. The purpose of this section is to organize and output information related to users, roles, permissions, and cloud resources to help analyze the specific situation of user permission configurations.

[0198] In this way, cloud instance 1 can quickly find and match users who have obtained high-level permissions (i.e., high privileges) such as "DROP" or "DELETE" through role inheritance chains based on preset inheritance rules and traversal algorithms, and these users have not been directly granted these high privileges, thereby determining whether these users have a potential risk of unauthorized access to cloud resources.

[0199] Similarly, taking finding the inheritance path of low-privilege users accessing highly sensitive cloud resources through inheritance chain in cloud instance 1 as an example, the following Cypher language code snippet can be used to implement the detection:

[0200] "MATCH path=(low:User)-[:INHERITS_FROM*1..]->(high:User)-[:GRANTED_TO]->(p:Privilege)

[0201] WHERE low.level <high.levelAND p.object='SensitiveResource'

[0202] RETURN low.name,high.name,path”

[0203] In this code snippet, the first MATCH statement queries the inheritance relationship between a low-privilege user (low) and a high-privilege user (high), where the low-privilege user inherits the role or permissions of the high-privilege user through the inheritance relationship (INHERITS_FROM). The inheritance chain can be one or more levels long (*1..). Meanwhile, the high-privilege user has been granted certain permissions (through the GRANTED_TO relationship). The WHERE statement filters for cases where there is a level difference between the low-privilege and high-privilege users, and the high-privilege user has been granted permissions to "SensitiveResource". The RETURN statement then returns the names of each low-privilege and high-privilege user filtered by the WHERE statement, along with the complete inheritance path between them.

[0204] In this way, Cloud Instance 1 automatically queries low-privilege users who have gained access to sensitive cloud resources (SensitiveResource) through role inheritance chains, as well as their inheritance paths, by scheduling this type of code. In other words, Cloud Instance 1 not only performs risk inference on the paths of a specific user to be configured, but can also batch traverse all low-privilege users with permission configuration risks and their inheritance paths across the entire knowledge graph. This helps personnel identify the permissions obtained by low-level users through inheritance relationships, determine which permissions high-level users have granted to low-level users, and understand how permissions are passed in the inheritance chain. Furthermore, it determines whether these low-privilege inheritance paths pose risks, thereby helping to ensure that sensitive cloud resources are subject to appropriate access control.

[0205] In an example of privilege abuse vulnerability detection, such as Figure 9 As shown, S4042 may include:

[0206] S40423, The cloud instance determines at least one inheritance path to directly or indirectly associate the target role node with different target permission nodes, and the target role node has a scope of responsibility attribute.

[0207] In this step, cloud instance 1 determines through querying that there is at least one inheritance path. These inheritance paths directly or indirectly link target role nodes to different target permission nodes, and the target role nodes have a scope of responsibility attribute. For example, the role of the user u to be configured is a regular employee in the department, and fulfilling its responsibilities only requires the SELECT permission. However, after querying the target user nodes in the mapped knowledge graph for the user u to be configured, it is determined that the target user node is directly connected to the Write permission node through the grant relationship edge, and is also directly connected to the SELECT permission node through the role node. Furthermore, it inherits the modification permission of the department manager through its role.

[0208] S40424, the cloud instance will match at least one inheritance path with the preset inheritance rules, and determine the matching result as at least one inheritance path matching the second rule in the inheritance rules.

[0209] In this step, the second rule describes a path where a potential privilege abuse vulnerability may exist; this is also referred to as the second risk inheritance path. The second risk inheritance path indicates that a user directly or indirectly obtains preset sensitive privileges through a role, and these sensitive privileges exceed the scope of permissions required for the user's assigned role to perform its duties. Let's continue with the example of S40423. According to the second rule, the inheritance path of the user to be configured, u, indicates that the Write and Modify permissions (which are sensitive permissions) directly granted to u exceed the scope of responsibilities of its assigned role. Furthermore, the edges connecting the target user node to the target permission node in the inheritance path do not have attached permission usage restriction attributes (such as validity period). In other words, the user to be configured, u, uses Write and Modify permissions without any restrictions, posing a risk of abusing Write and Modify permissions to tamper with data.

[0210] For example, when Cloud Instance 1 can determine whether a user has obtained operations beyond their role's permission scope (permission abuse), it can use a Cypher code snippet similar to the following:

[0211]

[0212]

[0213] In this code snippet, the MATCH statement queries two paths: The first part, (u:User)-[:HAS_ROLE]->(r:Role)-[:ROLE_GRANTED]->(p:Privilege), matches the permissions obtained by user node u through role node r (the permissions represented by permission node p). HAS_ROLE represents the relationship between user and role, and ROLE_GRANTED represents the permissions granted by role. The second part, (u)-[:GRANTED_TO]->(p2:Privilege), matches the permission node p2 directly associated with user node u (connected by the GRANTED_TO relationship). The WHERE NOT(p=p2) condition excludes cases where permissions are granted directly through role and role, focusing only on permissions directly granted by the user (i.e., the permissions represented by node p2). Finally, the RETURN statement returns the user u who directly obtained the permissions represented by permission p2 through the GRANTED_TO relationship.

[0214] In this way, based on the preset inheritance rules, if the returned user u obtains a permission (such as view permission) by direct grant and at the same time associates another permission (delete permission) through a role, and the inheritance rules define that the user u's own responsibility scope only requires the view permission, then since the permission inherited by the user u through the role exceeds the user u's own responsibility scope, the cloud instance 1 determines that there may be a permission abuse vulnerability in the database.

[0215] In a path depth audit example, such as Figure 10 As shown, S4042 may include:

[0216] S40425, cloud instance calculates the depth of each inheritance path.

[0217] In this step, cloud instance 1 calculates the depth of the inheritance path covered by the connection from the target user node to the target resource node. The depth refers to the number of hops included in the path.

[0218] S40426, the cloud instance compares the depth of each inheritance path with the depth threshold defined by the inheritance rules to generate a matching result.

[0219] In this step, cloud instance 1 compares the depth of each inheritance path with a depth threshold to determine if the depth of each inheritance path exceeds the threshold. If any inheritance path exceeds the depth threshold, then that inheritance path has a depth defect; otherwise, there is no depth defect. This is used to detect whether permission transfer is too long and whether the resulting increase in management complexity exceeds the set level.

[0220] For example, Cloud Instance 1 can implement deep path auditing using similar Cypher code snippets as follows:

[0221] "MATCH path=(u:User)-[:INHERITS_FROM*5..]->(p:Privilege)

[0222] RETURN u.name,length(path)AS chainLength”

[0223] In this fragment, the MATCH statement performs a lookup operation: starting from a user node u in the knowledge graph, it searches for inheritance paths that inherit to a permission node p through one or more INHERITS_FROM relationships. *5.. indicates that the inheritance path contains at least 5 inheritance relationships, meaning that user User may have inherited the permissions represented by permission p through multiple roles or paths. The RETURN statement returns the query results, consisting of two parts: one part (u.name) returns the name of each user, and the other part (length(path)) calculates and returns the path length from user node u to permission node p, which is the number of levels through which the user acquired permissions via the inheritance chain. This allows finding permission paths with inheritance relationships of 5 levels or more and the names of the users associated with them.

[0224] Then all users whose path depth is greater than the length threshold of 5 can be found. It is determined that the inheritance path (i.e. the target inheritance path) of these users is too long, making management complicated and requiring optimization of their permission configuration.

[0225] In an example of a privilege conflict vulnerability, such as Figure 11 As shown, S4042 may include:

[0226] S40427, The cloud instance determines at least one inheritance path to associate the target role node with multiple target permission nodes respectively.

[0227] In this example, cloud instance 1 can traverse the permission nodes connected to each target role node using a traversal algorithm (such as depth-first search (DFS) or breadth-first search (BFS), and use a coloring algorithm to color the permission nodes connected to the same target role node with the same color, thereby obtaining the permission set P = {p1, p2, ..., pn}, indicating that these permissions p1, p2, ..., pn are held by the user assigned the role.

[0228] S40428, The cloud instance groups any two target permission nodes from multiple target permission nodes to obtain at least one node pair.

[0229] In this example, cloud instance 1 groups any two target permission nodes in the inheritance path to obtain at least one node pair. For example, the SELETE permission node and the modify permission node in the inheritance path are one node pair, and the SELETE permission node and the Write permission node are another node pair.

[0230] S40429, the cloud instance will match at least one node pair with the mutually exclusive permission pair defined in the inheritance rule to obtain the matching result.

[0231] In this step, the inheritance rules can include mutually exclusive permission rules, which define which permission pairs are mutually exclusive. For example, a mutually exclusive permission rule might describe that view permission and delete permission are a mutually exclusive permission pair, edit permission and delete permission are a mutually exclusive permission pair, create permission and delete permission are a mutually exclusive permission pair, and view permission and edit permission can coexist. Thus, cloud instance 1 can check for conflicting permission node pairs (i.e., target node pairs) in each inheritance path according to the mutually exclusive permission rules to determine if there is a path for a low-privilege user to obtain sensitive cloud resources. The checking process includes:

[0232] Cloud instance 1 is analyzed along the paths "role → permission → cloud resource" to check if any permission pairs defined in the mutual exclusion permission rules are included. For example, it checks whether the "delete" and "view" permissions for the same cloud resource (such as an employee file table) appear in the same permission set P for role r. If so, it indicates a permission conflict in the user's inheritance path. This means that any user granted role r can not only view the employee file table, which belongs to a sensitive cloud resource, but also directly delete it. Such a permission combination violates the principle of least privilege in inheritance rules and may lead to permission abuse. Therefore, it is identified as a conflicting permission vulnerability, requiring administrators to adjust permission configurations. Conversely, if there is no conflict between the "delete" and "view" permissions...

[0233] In this embodiment, combined again Figure 6 As shown, in addition to performing permission inheritance reasoning through S4041 to S4042 as described above, cloud instance 1 can also perform permission redundancy detection. For example, permission redundancy detection can include redundant authorization path detection and covert access path detection. Redundant authorization paths refer to users obtaining the same permissions through multiple independent paths, which may lead to multiple permission allocations, configuration bloat, management complexity, and even potential security risks. Covert access paths are potential paths that bypass permission controls, enabling users to perform operations beyond the scope of their role's permissions.

[0234] Therefore, for example, such as Figure 12 As shown, S404 of this method may further include:

[0235] S4043, the cloud instance traverses the authorized path covered by the target user node to the target permission node from the mapped knowledge graph.

[0236] In this example, the authorization path is the right granting relationship from the target user node to the target permission node, which can be granted through role inheritance or right inheritance, or it can be granted directly.

[0237] As an example, Cloud Instance 1 can perform the Floyd-Warshall algorithm on the permission graph in the knowledge graph through multi-path analysis (Floyd-Warshall algorithm) to count the number of reachable paths for each node pair consisting of each user node and each permission node.

[0238] S4044, The cloud instance determines whether the permission configuration data will cause a permission redundancy vulnerability after being configured into the database, based on the number of authorized paths, the number of hops in each authorized path, and the nodes included in each authorized path.

[0239] In this step, cloud instance 1 determines, based on the number of authorized paths, the number of hops in each authorized path, and the nodes included in each authorized path, that if the same permission node p1 has two or more reachable paths for a certain user u, and the roles included in the reachable paths are not attached with attributes for authorization constraints or differentiation conditions, then it determines that there is permission redundancy between user node u and permission node p.

[0240] For example, Cloud Instance 1 can use the Cypher language to execute multi-path analysis algorithms to check whether a user has obtained specified permissions indirectly or directly through a multi-level permission chain. Taking checking all GRANT type permissions obtained by a user across up to n levels of paths as an example, the Cypher language code snippet used could include:

[0241] "MATCH(u:User)-[:GRANTED_TO*1..n]->(p:Privilege)

[0242] WHERE p.type="GRANT"

[0243] RETURN u.name,p”

[0244] In this code snippet, the `MATCH` statement searches for relationships between user node `u` and permission node `p` in the knowledge graph. These relationships are connected by `GRANTED_TO` edges, where 1..n indicates that the relationship can span from 1 to n levels, meaning a user can directly or indirectly obtain the permission through multiple layers of relationships (such as multiple roles or multiple permission inheritance). The `WHERE` statement filters out permission nodes `p` of type "GRANT". The `RETURN` statement then tracks and returns the permission grant chain from user `User` to permission node `p`, showing which users possess "GRANT" permissions. Thus, Cloud Instance 1 can quickly track and detect all authorization paths from user nodes to specified permission nodes based on the permission configuration relationships represented by the knowledge graph, enabling redundant authorization path detection.

[0245] In another possible example, for any single user node u, cloud instance 1 executes a shortest path algorithm (such as Dijkstra's algorithm) starting from user node u, traversing the shortest paths from user node u to all authorized nodes. If, besides the shortest path, there are other unnecessary paths from user node u to a certain authorized node p1, the redundancy of the paths from user node u to the authorized node p1 is further analyzed to determine whether the authorization path can be optimized. The principle of redundancy judgment includes: if there are more than one valid path from user node u to a certain authorized node p1, and the roles covered by these paths do not show differences in responsibilities (e.g., all are department managers) or differences in access granularity, then permission redundancy exists. If the roles covered by these more than one valid path can both directly access p1 and indirectly access p1 through inheritance paths, then it can be determined that the permission configuration overlaps and there is room for optimization. Then, the detection module 130 outputs the path information of the more than one valid path so that personnel can adjust the role structure or permission allocation accordingly to solve the permission redundancy problem.

[0246] For example, such as Figure 13 As shown, S404 of this method may further include:

[0247] S4045, the cloud instance traverses the access path from the target user node to the target resource node from the mapped knowledge graph.

[0248] In this step, the access path is the path that the target user node takes to connect to the target resource node.

[0249] S4046, the cloud instance matches the access path with the preset legal access path and obtains the matching result.

[0250] S4047, If a cloud instance has a hidden risk path vulnerability after configuring permission configuration data into the database, even if the access path is valid and the matching result indicates that the access path does not conform to the legal access path, the instance will find that the access path vulnerability exists.

[0251] In this example, Cloud Instance 1 can predefine several legal permission paths (which can be called the main path strategy). Then, it matches each of the enumerated actual access paths in the knowledge graph with the legal permission paths to determine whether the actual access path belongs to the predefined legal permission paths. If an actual access path can successfully access cloud resources but does not meet any legal permission criteria, then the path is identified as a potential hidden access path. For the identified hidden access paths, the key nodes and structural features in their access chain are analyzed to assess the risk of the hidden access paths from the perspectives of path length (the longer the path, the greater the risk), whether it contains cross-functional roles (if it does, the risk is high), or whether it contains unknown inheritance nodes (if it does, the risk is high). As a result, Cloud Instance 1 outputs the detection results, including all access paths from user to cloud resources, as well as the identified hidden access paths and their risk levels, so that personnel can optimize and adjust the paths accordingly.

[0252] For example, in practical applications, when performing permission vulnerability inference, Cloud Instance 1 can automate the connection to the Neo4j database using Python scripts and execute predefined Cypher queries to efficiently obtain and process permission data. Furthermore, the Python scripts can batch process multiple user, role, and permission configurations, dynamically constructing query statements to perform complex permission analysis, thus avoiding manual processing. In this way, the permission detection process is automated, reducing manual intervention, improving efficiency, and offering high scalability to adapt to larger-scale and more complex permission management needs.

[0253] S405, the cloud instance generates detection results based on the matching results.

[0254] In this step, cloud instance 1 can generate corresponding detection results based on the matching results, such as whether an inheritance rule is hit, which inheritance rule is hit, and whether it matches a legitimate access path. These detection results describe at least one of the following: whether the aforementioned permission vulnerability is triggered, and the type of permission vulnerability triggered, to help personnel intuitively understand the detection results and, in the event of a permission vulnerability, to make targeted adjustments to permission configurations based on the detection results.

[0255] In this embodiment, Cloud Instance 1 uses knowledge graphs for path analysis and logical reasoning to efficiently discover permission conflicts, redundancies, and other potential problems. It supports defining permission inheritance rules based on actual scenario needs (such as sensitive operation restrictions for specific cloud resources), enabling customized detection and improving system flexibility and adaptability. The detection results output by Cloud Instance 1 can be visualized, presenting complex permission defect detection results intuitively in graphical and tabular formats. This facilitates users' quick understanding and remediation of permission issues, lowers the barrier to entry for administrators, improves system usability and user experience, and reduces the complexity of permission management.

[0256] In some possible implementations, in addition to permission vulnerability reasoning implemented by the Cyber ​​statement query method mentioned above, permission defect detection can also be implemented through custom graph algorithms, such as degree centrality algorithms or connectivity analysis algorithms, to assess the scalability of database permission configuration and ensure that the database can maintain security as the complexity of permission configuration increases.

[0257] In this implementation, when cloud instance 1 uses the degree centrality analysis algorithm, degree centrality represents the degree of connectivity of a node. In a knowledge graph, degree centrality can be used to measure the centrality and influence of a user node, role node, or permission node in the permission configuration. Degree centrality is usually calculated by the degree of each node in the knowledge graph. The degree refers to the number of edges connecting a node to other nodes, which can be calculated as follows: First, for each node, calculate its degree (the sum of its out-degree and in-degree), that is, the number of edges it is connected to. For example, if a user node is connected to three permission nodes, then its degree is 3. It can be understood that if a node has a high degree, it may play a more important role in the entire knowledge graph, which means that a node with a high degree centrality may pose a greater risk to database security because it can directly or indirectly control more permissions. As an example, the degree of a node can be calculated using queries such as COUNT in Neo4j, which will not be elaborated further.

[0258] Thus, based on degree centrality, we can assess whether certain users or roles will become potential security bottlenecks when the database management system expands. In particular, when new users, roles, or permissions are added to the system, nodes with high degree centrality may cause potential scalability issues, leading to overly concentrated or unevenly distributed permissions.

[0259] In this implementation, when Cloud Instance 1 employs the connectivity analysis algorithm, this algorithm analyzes the connections between nodes in the knowledge graph to assess the overall connectivity of the network structure, thereby evaluating whether the transfer of permissions can remain stable and avoiding improper permission isolation or unclear permission transfer paths. Specifically, Cloud Instance 1 uses the connectivity analysis algorithm to identify whether there are isolated permission nodes in the knowledge graph, ensuring that as the database management system expands, new permissions can be reasonably connected with existing permissions and roles, thus guaranteeing that the overall permission system represented by the knowledge graph is effective and connected. If, after processing by this algorithm, some permission nodes are found to be unable to be inherited or assigned through normal paths, these permission nodes are determined to potentially cause permission vulnerabilities or operational conflicts in the system.

[0260] In this way, through the processing of scalable analysis algorithms, a higher level of abstraction and finer-grained control can be provided for permission defect detection, enabling the handling of more complex permission relationships and large-scale data.

[0261] This application also provides a database vulnerability detection device 1400 based on a cloud service system, such as... Figure 14 As shown, it includes:

[0262] The receiving module 110 is used to receive permission configuration data for the database;

[0263] Module 120 is used to map permission configuration data to the knowledge graph to obtain the mapped knowledge graph;

[0264] The detection module 130 is used to infer permission vulnerabilities caused by configuring configuration data into the database based on the mapped knowledge graph.

[0265] The receiving module 110, the construction module 120, and the detection module 130 can all be implemented in software or in hardware. For example, the implementation of the receiving module 110 will be described below. Similarly, the implementation of the construction module 120 and the detection module 130 can refer to the implementation of the receiving module 110.

[0266] As an example of a software functional unit, the receiving module 110 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the receiving module 110 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0267] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0268] As an example of a hardware functional unit, the receiving module 110 may include at least one computing device, such as a server. Alternatively, the receiving module 110 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0269] The multiple computing devices included in the receiving module 110 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the receiving module 110 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the receiving module 110 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0270] It should be noted that, in other embodiments, the receiving module 110 can be used to execute any step in the database vulnerability detection method based on the cloud service system, the building module 120 can be used to execute any step in the database vulnerability detection method based on the cloud service system, and the detection module 130 can be used to execute any step in the database vulnerability detection method based on the cloud service system. The steps implemented by the receiving module 110, the building module 120, and the detection module 130 can be specified as needed. By implementing different steps in the database vulnerability detection method based on the cloud service system through the receiving module 110, the building module 120, and the detection module 130, all functions of the database vulnerability detection device based on the cloud service system can be realized.

[0271] This application also provides a computing device 100. For example... Figure 15 As shown, the computing device 100 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other via the bus 102. The computing device 100 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 100.

[0272] Bus 102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 15 The bus 104 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 104 may include a path for transmitting information between various components of the computing device 100 (e.g., memory 106, processor 104, communication interface 108).

[0273] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0274] Memory 106 may include volatile memory, such as random access memory (RAM). Processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0275] The memory 106 stores executable program code, which the processor 104 executes to implement the functions of the aforementioned receiving module 110, construction module 120, and detection module 130, thereby realizing a database vulnerability detection method based on a cloud service system. In other words, the memory 106 stores instructions for executing the database vulnerability detection method based on a cloud service system.

[0276] The communication interface 103 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 100 and other devices or communication networks.

[0277] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0278] like Figure 16 As shown, the computing device cluster includes at least one computing device 100. The memory 106 of one or more computing devices 100 in the computing device cluster may store the same instructions for executing database vulnerability detection methods.

[0279] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the database vulnerability detection method. In other words, a combination of one or more computing devices 100 can jointly execute instructions for executing the database vulnerability detection method based on the cloud service system.

[0280] It should be noted that the memory 106 in different computing devices 100 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the database vulnerability detection device. That is, the instructions stored in the memory 106 of different computing devices 100 can implement the functions of one or more modules among the receiving module 110, the building module 120, and the detection module 130.

[0281] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 17 One possible implementation is shown. For example... Figure 17 As shown, two computing devices 100A and 100B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 106 in computing device 100A stores instructions for performing the functions of the receiving module 110. Simultaneously, the memory 106 in computing device 100B stores instructions for performing the functions of the building module 120 and the detection module 130.

[0282] It should be understood that Figure 17The functions of the computing device 100A shown can also be performed by multiple computing devices 100. Similarly, the functions of the computing device 100B can also be performed by multiple computing devices 100.

[0283] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a database vulnerability detection method based on a cloud service system.

[0284] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform a database vulnerability detection method, or instruct the computing device to perform a database vulnerability detection method.

[0285] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A database vulnerability detection method based on a cloud service system, characterized in that, The cloud service system includes infrastructure that provides cloud services and a cloud management platform that manages the infrastructure. The infrastructure includes cloud instances. The method includes: The cloud management platform obtains permission configuration data for the database, wherein the permission configuration data is used to indicate the roles and permissions assigned to the user to be configured to operate cloud resources; The cloud management platform sends the permission configuration data to the cloud instance; The cloud instance maps the permission configuration data to a knowledge graph to obtain a mapped knowledge graph. The mapped knowledge graph includes multiple nodes and at least one edge connecting the multiple nodes. Each node is used to represent the entities included in the database. The entities include users, roles, permissions, and cloud resources in the database. Each edge is used to represent the relationship between the entities. The users include the user to be configured. The cloud instance infers the permission vulnerability caused by configuring the permission configuration data into the database based on the mapped knowledge graph.

2. The method according to claim 1, characterized in that, The cloud instance maps the permission configuration data to a knowledge graph, resulting in a mapped knowledge graph, including: The cloud instance converts the permission configuration data into multiple triples, which are used to record the relationship between any two entities to be configured. The entities to be configured include the user to be configured, the cloud resources operated by the user to be configured, the assigned role, and the assigned permissions. The cloud instance maps the entities to be configured from the multiple triple information to existing or new nodes in the knowledge graph, and connects them through corresponding edges to obtain the mapped knowledge graph. The corresponding edges represent the relationship attributes between the entities to be configured through direction or additional attributes.

3. The method according to claim 1 or 2, characterized in that, The mapped knowledge graph includes at least one of the following: a target user node for representing the user to be configured, a target role node for representing the assigned role, a target permission node for representing the assigned permission, and a target resource node for representing the cloud resources operated by the user to be configured. The cloud instance, based on the mapped knowledge graph, infers permission vulnerabilities caused by the permission configuration data being configured into the database, including: The cloud instance traverses at least one inheritance path from the mapped knowledge graph to the target resource node, where the at least one inheritance path includes a role inheritance path or a permission inheritance path formed by the target role node and the target permission node. The cloud instance matches the at least one inheritance path with a preset inheritance rule to obtain a matching result. The inheritance rule is used to define the inheritance specifications followed by the security compliance path. The cloud instance generates a detection result based on the matching result. The detection result is used to describe at least one of the following: whether the permission vulnerability is caused, and the type of permission vulnerability caused.

4. The method according to claim 3, characterized in that, The cloud instance matches the at least one inheritance path with preset inheritance rules to obtain matching results, including: The cloud instance determines that the at least one inheritance path indicates that the target user node is indirectly associated with the target permission node through the role inheritance path of the target role node, and there is no direct granting relationship between the target user node and the target permission node; The cloud instance matches the at least one inheritance path with a preset inheritance rule and determines that the matching result is that the at least one inheritance path hits the first rule in the inheritance rule. The first rule is used to describe a first risk inheritance path. The first risk inheritance path is used to indicate that the user indirectly obtains preset sensitive permissions through role inheritance, and the sensitive permissions exceed the permission range directly possessed by the role assigned to the user. The cloud instance generates detection results based on the matching results, including: The cloud instance generates a detection result based on the matching result, and the detection result is used to indicate that the type of vulnerability is an escalation vulnerability.

5. The method according to claim 3 or 4, characterized in that, The cloud instance matches the at least one inheritance path with preset inheritance rules to obtain matching results, including: The cloud instance determines that the at least one inheritance path directly or indirectly associates the target role node with different target permission nodes, and the target role node has a scope of responsibility attribute; The cloud instance matches the at least one inheritance path with a preset inheritance rule and determines that the matching result is that the at least one inheritance path hits the second rule in the inheritance rule. The second rule is used to describe a second risk inheritance path. The second risk inheritance path is used to indicate that the user directly or indirectly obtains preset sensitive permissions through a role, and the sensitive permissions exceed the permission range required for the user's assigned role to perform its duties. The cloud instance generates detection results based on the matching results, including: The cloud instance generates a detection result based on the matching result, and the detection result is used to indicate that the type of vulnerability is an abuse of privilege vulnerability.

6. The method according to any one of claims 3 to 5, characterized in that, The cloud instance matches the at least one inheritance path with preset inheritance rules to obtain matching results, including: The cloud instance calculates the depth of each of the inheritance paths; The cloud instance compares the depth of each inheritance path with the depth threshold defined by the inheritance rule to generate a matching result; The cloud instance generates detection results based on the matching results, including: The cloud instance generates the detection result when the matching result indicates that the depth of the target inheritance path is greater than or equal to the depth threshold. The detection result is used to indicate that there is a defect in the depth of the target inheritance path.

7. The method according to any one of claims 3 to 6, characterized in that, The cloud instance matches the at least one inheritance path with preset inheritance rules to obtain matching results, including: The cloud instance determines that the at least one inheritance path associates the target role node with multiple target permission nodes respectively; The cloud instance groups any two target permission nodes from the plurality of target permission nodes to obtain at least one node pair. The cloud instance matches the at least one node pair with the mutually exclusive permission pairs defined in the inheritance rules to obtain the matching result; The cloud instance generates detection results based on the matching results, including: When the matching result includes a target node pair that matches the mutually exclusive permission pair, the cloud instance generates the detection result, which is used to indicate that there is a permission conflict vulnerability in the corresponding inheritance path of the target node pair.

8. The method according to claim 1 or 2, characterized in that, The mapped knowledge graph includes target user nodes for representing the user to be configured and target permission nodes for representing the assigned permissions. The cloud instance, based on the mapped knowledge graph, infers permission vulnerabilities caused by the permission configuration data being configured into the database, including: The cloud instance traverses the authorization path covered by the target user node to the target permission node from the mapped knowledge graph; The cloud instance determines whether configuring the permission configuration data into the database will cause a permission redundancy vulnerability based on the number of authorized paths, the number of hops in each authorized path, and the nodes included in each authorized path.

9. The method according to claim 1 or 2, characterized in that, The mapped knowledge graph includes target user nodes for representing the user to be configured, and target resource nodes for representing the cloud resources operated by the user to be configured. The cloud instance, based on the mapped knowledge graph, infers permission vulnerabilities caused by the permission configuration data being configured into the database, including: The cloud instance traverses the access path covered by the target user node to the target resource node from the mapped knowledge graph; The cloud instance matches the access path with a preset legal access path to obtain a matching result; If the cloud instance determines that there is a hidden risk path vulnerability after the permission configuration data is configured into the database, and the access path is valid and the matching result indicates that the access path does not conform to the legal access path, then the cloud instance determines that there is a hidden risk path vulnerability after the permission configuration data is configured into the database.

10. A cloud service system, characterized in that, The cloud service system includes infrastructure that provides cloud services and a cloud management platform that manages the infrastructure. The infrastructure includes cloud instances, wherein... The cloud management platform is used to obtain permission configuration data for the database, and the permission configuration data is used to indicate the roles and permissions assigned to the user to be configured to operate cloud resources. The cloud management platform is also used to send the permission configuration data obtained by the cloud management platform to the cloud instance; The cloud instance is used to map the permission configuration data to a knowledge graph to obtain a mapped knowledge graph. The mapped knowledge graph includes multiple nodes and at least one edge connecting the multiple nodes. Each node is used to represent an entity included in the database. The entity includes users, roles, permissions, and cloud resources in the database. Each edge is used to represent the relationship between the entities. The user includes the user to be configured. The cloud instance is used to infer, based on the mapped knowledge graph, the permission vulnerabilities caused by configuring the permission configuration data into the database.

11. The cloud service system according to claim 10, characterized in that, The cloud instance is used to: convert the permission configuration data into multiple triple information, the multiple triple information being used to record the relationship between any two entities to be configured, the entities to be configured including the user to be configured, the cloud resources operated by the user to be configured, the assigned role, and the assigned permissions; The entities to be configured in the multiple triplet information are mapped to existing or newly added nodes in the knowledge graph, and connected by corresponding edges to obtain the mapped knowledge graph. The corresponding edges represent the relationship attributes between the entities to be configured through direction or additional attributes.

12. The cloud service system according to claim 10 or 11, characterized in that, The mapped knowledge graph includes at least one of the following: a target user node for representing the user to be configured, a target role node for representing the assigned role, a target permission node for representing the assigned permission, and a target resource node for representing the cloud resources operated by the user to be configured. The cloud instance is used for: From the mapped knowledge graph, traverse at least one inheritance path from the target user node to the target resource node, wherein the at least one inheritance path includes a role inheritance path or a permission inheritance path formed by the target role node associating with the target permission node; The at least one inheritance path is matched with a preset inheritance rule to obtain a matching result. The inheritance rule is used to define the inheritance specifications followed by the security compliance path. Based on the matching results, a detection result is generated, which describes at least one of the following: whether the privilege vulnerability is caused, and the type of privilege vulnerability caused.

13. The cloud service system according to claim 12, characterized in that, The cloud instance is used for: Determining that there is at least one inheritance path indicates that the target user node is indirectly associated with the target permission node through the role inheritance path of the target role node, and there is no direct granting relationship between the target user node and the target permission node; The at least one inheritance path is matched with a preset inheritance rule, and the matching result is determined to be that the at least one inheritance path hits the first rule in the inheritance rule, wherein the first rule is used to describe a first risk inheritance path, and the first risk inheritance path is used to indicate that the user indirectly obtains preset sensitive permissions through role inheritance, and the sensitive permissions exceed the permission range directly possessed by the role assigned to the user. Based on the matching results, a detection result is generated, which indicates that the vulnerability type is an escalation vulnerability.

14. The cloud service system according to claim 12 or 13, characterized in that, The cloud instance is used for: The at least one inheritance path is determined to directly or indirectly associate the target role node with different target permission nodes, and the target role node has a scope of responsibility attribute; The at least one inheritance path is matched with a preset inheritance rule, and the matching result is determined to be that the at least one inheritance path hits the second rule in the inheritance rule. The second rule is used to describe a second risk inheritance path. The second risk inheritance path is used to indicate that the user directly or indirectly obtains preset sensitive permissions through a role, and the sensitive permissions exceed the permission range required for the user's assigned role to perform its duties. Based on the matching results, a detection result is generated, which indicates that the vulnerability type is an abuse of privilege vulnerability.

15. The cloud service system according to any one of claims 12 to 14, characterized in that, The cloud instance is used for: Calculate the depth of each of the aforementioned inheritance paths; The depth of each inheritance path is compared with the depth threshold defined by the inheritance rule to generate a matching result; If the matching result indicates that the depth of the target inheritance path is greater than or equal to the depth threshold, the detection result is generated, and the detection result is used to indicate that there is a defect in the depth of the target inheritance path.

16. The cloud service system according to any one of claims 12 to 15, characterized in that, The cloud instance is used for: Determine at least one inheritance path to associate the target role node with multiple target permission nodes respectively; Group any two target permission nodes from the plurality of target permission nodes to obtain at least one node pair; The at least one node pair is matched with the mutually exclusive permission pairs defined in the inheritance rules to obtain the matching result; If the matching result includes a target node pair that matches the mutually exclusive permission pair, the detection result is generated. The detection result is used to indicate that there is a permission conflict vulnerability in the corresponding inheritance path of the target node pair.

17. The cloud service system according to claim 10 or 11, characterized in that, The mapped knowledge graph includes target user nodes for representing the user to be configured and target permission nodes for representing the assigned permissions. The cloud instance is used for: From the mapped knowledge graph, traverse the authorization path covered by the target user node to the target permission node; Based on the number of authorized paths, the number of hops in each authorized path, and the nodes included in each authorized path, determine whether configuring the permission configuration data into the database will cause a permission redundancy vulnerability.

18. The cloud service system according to claim 10 or 11, characterized in that, The mapped knowledge graph includes target user nodes for representing the user to be configured, and target resource nodes for representing the resources operated by the user to be configured. The cloud instance is used for: From the mapped knowledge graph, traverse the access paths covered by the target user node to the target resource node; The access path is matched with a preset legal access path to obtain a matching result; If the access path is valid and the matching result indicates that the access path does not conform to the legitimate access path, it is determined that there is a hidden risk path vulnerability after the permission configuration data is configured into the database.

19. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-9.

20. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1-9.

21. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1-9.

Images