Method and apparatus for constructing a permission topology structure based on least privilege

Abstract

This application provides a method and apparatus for constructing a permission topology structure based on the lowest privilege level. The method includes: obtaining a non-public interface path template by structured parsing and classifying request data from an identity management platform and performing parameterized substitution; establishing a mapping relationship between the non-public interface path template and a preset identity management platform permission model to obtain a non-public interface parameter structure; merging the non-public interface parameter structure with an existing interface parameter structure to obtain a centralized interface parameter structure; under the lowest privilege role, starting from the initial node of the centralized interface parameter structure according to the task scheduling engine and graph operation model, performing a multi-hop breadth traversal along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph; performing fine-grained dependency extraction on the permission graph; updating the permission graph according to the dependency relationships; and determining the corresponding permission topology structure. This application can improve the security and management efficiency of the identity and access management platform.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method and apparatus for constructing a permission topology structure based on the least privilege. Background Technology

[0002] With the rapid development of enterprise informatization and cloud computing technologies, Microsoft Azure, as a leading global cloud service platform, has made its Azure Active Directory (Azure AD) identity and access management service a core component for many organizations to ensure the security of their cloud environments. Azure AD provides powerful identity authentication, access control, and permission management functions, and is deeply integrated with Microsoft 365 (Microsoft's integrated office software), Azure Resource Manager (ARM), PowerPlatform (a low-code application development platform), SaaS applications (Software as a Service applications), and DevOps processes (development and operations integration processes), building a solid "identity infrastructure" for modern organizations.

[0003] However, with the widespread adoption of Azure AD, its security faces increasingly severe challenges. Attackers are constantly attempting to breach Azure AD's security defenses using traditional methods such as phishing emails, misconfigurations, and persistent attacks. Although Microsoft is continuously strengthening Azure AD's security measures, its complex data structures and multi-layered authorization model still present numerous challenges for security research.

[0004] For example, to study the permission topology of Azure Active Directory, a security test environment close to a real-world environment needs to be built. However, due to the diversity and complexity of Azure resources, as well as the restrictions of minimum privileges, building such an environment is not only costly but also technically challenging. Under minimum privileges (such as the Reader role), traditional tools and methods often cannot obtain complete permission information and topology under these constraints, leading to inaccurate and incomplete security analysis. How to comprehensively and accurately construct the permission topology has become an urgent problem to be solved.

[0005] In summary, there is an urgent need for a method to construct a permission topology based on least privilege, which can comprehensively and accurately obtain permission information and data from Azure AD in least privilege scenarios, and build a complete permission topology to help security analysts intuitively understand the relationships between permissions and potential risk paths, thereby improving the security and management efficiency of the identity and access management platform. Summary of the Invention

[0006] To address the problems in the prior art, this application provides a method and apparatus for constructing a permission topology based on least privilege, which can improve the security and management efficiency of the identity and access management platform.

[0007] To solve at least one of the above problems, this application provides the following technical solution:

[0008] Firstly, this application provides a method for constructing a permission topology structure based on least privilege, including:

[0009] The request data from the identity management platform is structured and parsed to determine the corresponding unpublished interface dataset. The unpublished interface dataset is then categorized and parameterized. The corresponding unpublished interface path template is determined, and a mapping relationship is established between the unpublished interface path template and the preset identity management platform permission model. The corresponding unpublished interface parameter structure is then determined, and the unpublished interface parameter structure is merged with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure.

[0010] Under the lowest privilege role, data is collected by traversing the centralized interface parameter structure to determine the corresponding user resource dataset. Based on the preset task scheduling engine and the user resource dataset, the corresponding graph traversal task queue is determined, and an initial node and traversal depth parameter are assigned to each task queue.

[0011] The preset graph running model starts from the initial node and performs a multi-hop breadth-first traversal along the member relationships, role bindings, and permission operation paths until the traversal depth is reached. It records the node and edge relationships during the traversal process, determines the corresponding permission graph, performs fine-grained dependency extraction on the permission graph, and updates the permission graph based on the dependency relationships after fine-grained dependency extraction to determine the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0012] Furthermore, the step of collecting data from the centralized interface parameter structure under the lowest privilege role to determine the corresponding user resource dataset includes:

[0013] By invoking the centralized interface parameter structure through Reader or Audit role permissions, the associated data of users, groups, service subjects and policies are extracted according to preset field mapping rules to determine the corresponding resource object data;

[0014] Establish logical relationships between the resource object data and determine the corresponding user resource dataset, wherein the logical relationships include user-group affiliation, role-policy binding, and service subject-application registration mapping.

[0015] Further, the step of determining the corresponding graph traversal task queue based on the preset task scheduling engine and the user resource dataset, and assigning an initial node and traversal depth parameters to each task queue, includes:

[0016] The preset task scheduling engine dynamically generates graph traversal task types based on the object types in the user resource dataset. The graph traversal task types include user valid permission calculation tasks, resource access backtracking tasks, and permission escalation path detection tasks.

[0017] The corresponding graph traversal task queue is determined according to the task execution order of the graph traversal task type, and an initial node and traversal depth parameter are assigned to each task queue.

[0018] Furthermore, the fine-grained dependency extraction of the permission graph includes:

[0019] Parse the role inheritance chain of the permission graph, extract the indirect permission granting path, and determine the corresponding role inheritance relationship;

[0020] Parse the conditional expressions in the preset policy binding, extract the restriction fields, and determine the corresponding access restriction relationships;

[0021] Parse the resource scope field corresponding to the user role in the permission graph to determine the corresponding resource restriction relationship.

[0022] Further, updating the permission graph based on the dependency relationships after the fine-grained dependency extraction, and determining the corresponding permission topology, includes:

[0023] Based on the dependency relationships extracted by the fine-grained dependency extraction, redundant paths are merged in the permission graph to determine the corresponding permission topology.

[0024] Based on the dependency relationships extracted using fine-grained dependency extraction, a high-risk dependency relationship marking operation is performed on the permission graph to determine the corresponding permission topology.

[0025] Furthermore, the step of parameterizing and replacing the unpublished interface dataset after the classification to determine the corresponding unpublished interface path template includes:

[0026] The common fields of the request paths in the undisclosed interface dataset after the classification are extracted to determine the corresponding static fields and dynamic variables. The static fields are fixed identifiers that represent the service type, and the dynamic variables are unique identifier parameters in the resource layer.

[0027] The dynamic variables are matched based on preset regular expression rules to construct a parameter dictionary. The matched dynamic variables are then parameterized and replaced according to the parameter dictionary to determine the corresponding undisclosed interface path template.

[0028] Furthermore, establishing the mapping relationship between the undisclosed interface path template and the preset identity management platform permission model, and determining the corresponding undisclosed interface parameter structure, includes:

[0029] Extract the key path fields from the unpublished interface path template, parse the resource hierarchy structure of the key path fields, and determine the corresponding unpublished interface resource type;

[0030] Fuzzy match is performed between the undisclosed interface resource types and the resource types in the preset identity management platform permission model. If the match is successful, the mapping relationship is output and the corresponding permission mapping table is determined.

[0031] The request methods in the permission mapping table are semantically segmented to determine the corresponding permission operation types. The permission operation types and the unpublished interface path templates are summarized and aggregated according to the unpublished interface resource types to determine the corresponding unpublished interface parameter structure.

[0032] Secondly, this application provides a permission topology construction device based on least privilege, comprising:

[0033] The undisclosed interface structure extraction module is used to perform structured parsing of request data from the identity management platform, determine the corresponding undisclosed interface dataset, classify the undisclosed interface dataset, perform parameterized substitution on the classified undisclosed interface dataset, determine the corresponding undisclosed interface path template, establish a mapping relationship between the undisclosed interface path template and the preset identity management platform permission model, determine the corresponding undisclosed interface parameter structure, and merge the undisclosed interface parameter structure with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure.

[0034] The lowest-privilege graph traversal task determination module is used to collect data from the centralized interface parameter structure under the lowest-privilege role, determine the corresponding user resource dataset, determine the corresponding graph traversal task queue according to the preset task scheduling engine and the user resource dataset, and allocate an initial node and traversal depth parameter to each task queue.

[0035] The permission topology determination module is used to perform a multi-hop breadth-first traversal of the preset graph running model starting from the initial node, along the member relationships, role bindings, and permission operation paths until the traversal depth is reached. It records the node and edge relationships during the traversal process, determines the corresponding permission graph, performs fine-grained dependency extraction on the permission graph, and updates the permission graph according to the dependency relationships after the fine-grained dependency extraction, thereby determining the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0036] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the least privilege-based permission topology construction method described above.

[0037] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the least privilege-based permission topology construction method described above.

[0038] Fifthly, this application provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the least privilege-based permission topology construction method described above.

[0039] As can be seen from the above technical solution, this application provides a method and apparatus for constructing a permission topology structure based on the lowest privilege. It obtains undisclosed interface path templates by structured parsing and classifying request data from the identity management platform and performing parameterized substitution. A mapping relationship is established between the undisclosed interface path templates and a preset identity management platform permission model to obtain an undisclosed interface parameter structure. This undisclosed interface parameter structure is then merged with existing interface parameter structures to obtain a centralized interface parameter structure. Under the lowest privilege role, based on the task scheduling engine and graph operation model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth-first traversal is performed along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationships to determine the corresponding permission topology structure. This improves the security and management efficiency of the identity and access management platform. Attached Figure Description

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

[0041] Figure 1 This is one of the flowcharts illustrating the method for constructing a permission topology based on the lowest privilege in this application embodiment;

[0042] Figure 2 This is a structural diagram of the permission topology construction device based on the lowest permission in the embodiments of this application;

[0043] Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0044] Figure label:

[0045] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0048] Considering the increasingly severe security challenges facing Azure AD with its widespread adoption, this application provides a method and apparatus for constructing a permission topology based on least privilege. By structurally parsing and classifying request data from the identity management platform and performing parameterized substitution, a non-public interface path template is obtained. A mapping relationship is established between the non-public interface path template and the preset identity management platform permission model to obtain a non-public interface parameter structure. This non-public interface parameter structure is then merged with the existing interface parameter structure to obtain a centralized interface parameter structure. Under the least privilege role, based on the task scheduling engine and graph execution model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth-first traversal is performed along membership relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependencies to determine the corresponding permission topology. This improves the security and management efficiency of the identity and access management platform.

[0049] To improve the security and management efficiency of the identity and access management platform, this application provides an embodiment of a method for constructing a permission topology structure based on least privilege, see [link to embodiment]. Figure 1 The method for constructing a permission topology based on the lowest privilege level specifically includes the following:

[0050] Step S101: Perform structured parsing on the request data from the identity management platform to determine the corresponding unpublished interface dataset, classify the unpublished interface dataset, perform parameterized substitution on the classified unpublished interface dataset, determine the corresponding unpublished interface path template, establish a mapping relationship between the unpublished interface path template and the preset identity management platform permission model, determine the corresponding unpublished interface parameter structure, and merge the unpublished interface parameter structure with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure;

[0051] Optionally, in this embodiment, the request data from the identity management platform is subjected to structured parsing to determine the corresponding undisclosed interface dataset.

[0052] Specifically, input HTTP request data from the identity management platform (Azure AD), including the request URL, request method (GET, POST, PUT, DELETE, etc.), request headers (such as Authorization, Content-Type, etc.), request body (such as JSON formatted data), and response status code and response body.

[0053] The HTTP protocol parser is used to perform content analysis on network packets; syntax parsing is performed on the structured formats of common cloud platform SDK calls (such as JSON, REST API path specifications); key fields are extracted: URI path, request method, parameter location, and authentication credentials. This results in a structured raw API dataset, including:

[0054] {

[0055] "method": "GET", [Request Method]

[0056] "url":" / subscriptions / xxxx / resourceGroups / rgname / providers / Microsoft.Compute / virtualMachines / vm-name", [Requested resource path]

[0057] "headers": {[Request headers]}

[0058] "Authorization": "Bearer eyxxxx...", [Authorization credentials]

[0059] "Content-Type": "application / json" [Media type in the request body]

[0060] },

[0061] "query": {}, [query parameters]

[0062] "body": {} [Request Body]

[0063] }

[0064] The system compares the structured request data with known public interfaces to identify unpublished interface datasets.

[0065] Specifically, one way to identify undisclosed interfaces is by having the request path contain a specific resource type or operation that is not mentioned in the public documentation.

[0066] One way to identify undisclosed interfaces is by having the request path contain a specific prefix or suffix.

[0067] Optionally, in this embodiment, the unpublished interface dataset is categorized, and the categorized unpublished interface dataset is parameterized and replaced to determine the corresponding unpublished interface path template.

[0068] Specifically, this step categorizes and abstracts the data from unpublished APIs, extracting the corresponding unpublished API path templates. First, the intercepted API requests are categorized as follows:

[0069] Categorized by cloud platform (Azure, AWS, GCP);

[0070] Categorize by service type (e.g., resource management, storage, containers, KeyVault, etc.);

[0071] Categorize by resource level and URI pattern, and extract common fields.

[0072] The categorized unpublished interface dataset has a unified structure and characteristics for each category, which facilitates subsequent processing.

[0073] Specifically, for the categorized unpublished interface dataset, the specific resource ID or other variable parts are abstracted from the URI path and replaced with parameter placeholders to form a path template.

[0074] Taking the request paths in the original API dataset above as an example, we construct a parameter dictionary to abstract the specific request paths:

[0075] Specific request path:

[0076] " / subscriptions / xxxx / resourceGroups / rgname / providers / Microsoft.Compute / virtualMachines / vm-name" [Original request path]

[0077] Abstracted request path:

[0078] " / subscriptions / {subscriptionId} / resourceGroups / {resourceGroup} / providers / Microsoft.Compute / virtualMachines / {vmName}" [Template for Undisclosed Interface Path]

[0079] "parameters": {[parameter dictionary]}

[0080] "subscriptionId": "xxxxxxx",

[0081] "resourceGroup": "rg-name",

[0082] "vmName": "vm-name

[0083] Optionally, in this embodiment, a mapping relationship is established between the undisclosed interface path template and the preset identity management platform permission model to determine the corresponding undisclosed interface parameter structure.

[0084] Specifically, a permission model typically includes role definitions, permission actions, and other information. The corresponding permission item category is determined by the path key fields and request methods in the undocumented interface path template. The permission mapping table is then obtained by associating the undocumented interface path template with the permission items in the permission model.

[0085] For example:

[0086] To achieve semantic consistency, establish a mapping relationship between unpublished interface path templates and the following dimensions:

[0087] The permission model mapped to the cloud platform, Azure:

[0088] Mapped to Microsoft. / /

[0089] Mapped to permission entries in Role Definitions.

[0090] The permission mapping table can be obtained by using the path key field + method:

[0091] {

[0092] "path_template": [Path template]

[0093] " / subscriptions / {s} / resourceGroups / {r} / providers / Microsoft.KeyVault / vaults / {v}",

[0094] "method": "GET", [Request Method]

[0095] "mapped_permission": "Microsoft.KeyVault / vaults / read", [Mapped Permission]

[0096] "resource_type": "KeyVault", [Resource Type]

[0097] "cloud": "Azure" [Cloud Platform]

[0098] }

[0099] Next, based on the path parameter structure, we uniformly identify resource operation interfaces of the same type and perform semantic classification according to HTTP Method:

[0100] GET → read permission

[0101] PUT / POST → write / contribute

[0102] DELETE → delete permission

[0103] Based on the same type of resource operation interfaces and the semantically divided permission operations, they are organized into an interface dictionary + permission directory structure, and the undisclosed interface parameter structure is constructed as follows:

[0104] {

[0105] "resource": "Microsoft.Compute / virtualMachines", [Resource Type]

[0106] "operations": [This represents a list of operations supported by this resource type]

[0107] {

[0108] "action": "read", [Permission operation type]

[0109] "method": "GET", [Request Method]

[0110] "path": " / subscriptions / {...} / ... / virtualMachines / {vmName}" [Path Template]

[0111] },

[0112] {

[0113] "action": "write", [Permission operation type]

[0114] "method": "PUT", [Request Method]

[0115] "path": " / subscriptions / {...} / ... / virtualMachines / {vmName}" [Path Template]

[0116] } ]

[0118] }

[0119] Obtain the API permission call interface mapping table; summarize the unpublished interface structure under each resource type; and define the unpublished interface structure based on the ternary relationship of interface → permission → user / identity.

[0120] The undisclosed interface structure presents the structure and permission policies of the undisclosed interfaces of the identity management platform under different resource types in a hierarchical manner, enabling users to quickly understand the undisclosed interface paths, supported operation methods and their corresponding permission policies under each resource type.

[0121] Finally, the parameter structures of undocumented interfaces are merged with those of known public interfaces to form a unified and complete set of interface parameter structures. This provides a unified reference framework for subsequent interface calls and data interactions, simplifies the interface call process, and improves system efficiency.

[0122] Step S102: Under the lowest privilege role, perform data traversal and collection on the centralized interface parameter structure to determine the corresponding user resource dataset. Based on the preset task scheduling engine and the user resource dataset, determine the corresponding graph traversal task queue and assign an initial node and traversal depth parameter to each task queue.

[0123] Optionally, in this embodiment, in a real environment, users only have Reader or Audit permissions (the lowest possible permissions) for auditing. However, many current permission graph construction technologies are tested under high permissions (such as Global Administrator or Application Administrator). Once switched to a "minimally accessible scenario," the following problems arise:

[0124] Restricted field access; most interfaces return 403 permission errors; fields linking users and resources are not visible; overlapping permission areas between modules are unclear, leading to frequent false negatives.

[0125] The obvious consequences are: the tool's operational capabilities are severely limited; it cannot restore Object Dependency Links; and the promotion of security analysis in various scenarios is hindered, such as compliance documentation and third-party audits.

[0126] To address the aforementioned technical deficiencies and research bottlenecks, this solution, based on the discovery and analysis system of the unpublished Microsoft Graph API (interface) in step S101, performs comprehensive Azure AD object collection in the least privilege mode. This aims to leverage "Reader" permissions to maximize the reconstruction of the following data objects:

[0127] Users, groups, service entities, applications, policy sets; device lists, registration relationships; security policies and identity protection rules (CAP); role assignments and role definitions; extended fields and dependency topology of each object. Data is organized in a structural graph format to reconstruct a complete picture of tenant information security.

[0128] Optionally, in this embodiment, the core objective of this step is to restore key information such as users, groups, service subjects, policies, and role assignments as much as possible through a systematic data collection strategy without elevating privileges.

[0129] Optionally, in this embodiment, under the lowest privilege role, data is collected by traversing the centralized interface parameter structure to determine the corresponding user resource dataset.

[0130] Specifically, the system calls the centralized interfaces of the Microsoft Graph API (such as / users, / groups, / servicePrincipals) and parses the returned JSON data structure. The centralized interfaces include the public interfaces and the unpublic interfaces obtained in step S101 above.

[0131] Due to minimum access restrictions, some sensitive fields (such as user password policies and role assignment details) may be filtered or return null values. The system needs to identify these restricted fields and record the data gaps.

[0132] Next, we will fill in the data gaps.

[0133] One method for data completion is a multi-interface collaborative collection approach. For example, if the / users interface cannot return the user's complete role binding information, the system may indirectly obtain it through the / roleManagement / directory / roleAssignments interface.

[0134] One data completion method is logical inference, which infers possible permission paths (such as roles bound to a group) based on known data (such as the user's group).

[0135] One data completion method is incremental collection, which caches the results of paginated queries to avoid duplicate requests and supports resume collection from breakpoints.

[0136] The collected and completed raw data is categorized and stored according to object type (user, group, role, etc.), and relationships are established (such as the memberOf relationship between user and group, and the applyTo relationship between role and policy). Even with restricted permissions, a near-complete data model can still be built, providing a foundation for subsequent graph analysis.

[0137] Example of a dataset structure:

[0138] User table: UserID, DisplayName, GroupMemberships

[0139] Group tables: GroupID, RoleAssignments, DynamicMembershipRules

[0140] Role Assignment Table: RoleDefinitionID, PrincipalID, Scope

[0141] In the above data structure,

[0142] Node types: User, Group, RoleAssignment, RoleDefinition, Action, Resource.

[0143] In this context, User represents a specific user; Group represents a group to which the user belongs; RoleAssignment represents a role assignment node; RoleDefinition represents a role definition node; Action represents a permission operation node; and Resource represents a resource node.

[0144] Edge types: memberOf, assignedTo, hasPermission, applyTo.

[0145] Among them, memberOf indicates that a user or group belongs to another group; assignedTo indicates a role assignment; hasPermission indicates that a role definition contains specific permissions; applyTo indicates that a role definition or permission action is applied to a specific resource.

[0146] Optionally, in this embodiment, a corresponding graph traversal task queue is determined based on a preset task scheduling engine and the user resource dataset, and an initial node and traversal depth parameter are assigned to each task queue.

[0147] The core purpose of this step is to generate a traversal task, transforming statically stored categorized data into a dynamic permission relationship analysis process.

[0148] Specifically, the data in the user resource dataset has been categorized and stored (e.g., user table, group table, role table), but at this point, the data are still isolated entries without contextual relationships. In this step, the task scheduling engine's role is to identify the permission path types that need to be explored, establish dynamic analysis tasks, take the raw data as input, and generate specific graph traversal tasks, enabling the system to uncover hidden relationships between data as needed.

[0149] In this embodiment, the task scheduling engine adopts Task Engine, which transforms the permission issue into a graph traversal task.

[0150] Specifically, the task structure is defined as follows:

[0151] {

[0152] "task_id": "task-001", [Unique identifier for the task]

[0153] "type": "EffectiveAccessTask", [Task type, here indicating a task to calculate the effective access permissions for a specific subject]

[0154] "input": {[Task input parameters]}

[0155] "principal_id": "user-1234", [Identifier of the identity subject, user ID is 1234]

[0156] "cloud": "Azure" [Azure platform]

[0157] },

[0158] "config": {[Task configuration parameters]}

[0159] "max_depth": 5, [Maximum traversal depth]

[0160] "resolve_custom_roles": true [Whether to resolve custom roles]

[0161] }

[0162] }

[0163] Specifically, Example 1 of the graph traversal task: Forward permission chain analysis (user → resource).

[0164] Objective: To answer the question, "What resources can a given identity (user / service entity) ultimately access?"

[0165] Task type: EffectiveAccessTask, starting from the user, traversing groups, roles, policies along relationships such as memberOf and assignedTo, until reaching the resource node.

[0166] Application scenarios: access control auditing, compliance checks.

[0167] Specifically, Example 2 of the graph traversal task: Reverse permission chain analysis (resource → user).

[0168] Objective: To answer the question, "Which users can access a sensitive resource (such as Key Vault)?"

[0169] Task type: ResourceAccessBacktraceTask, which iterates back through resource nodes to determine role assignments and group membership relationships.

[0170] Application scenarios: attack surface assessment, vulnerability impact analysis.

[0171] Specifically, Example 3 of the graph traversal task: High-risk path detection.

[0172] Objective: To identify potential privilege escalation paths (Guest user → privileged group → administrator role).

[0173] Task type: PrivilegeEscalationDetectionTask, which marks abnormal paths by combining risk rules (such as role sensitivity scores).

[0174] Application scenarios: Red team drills, security reinforcement.

[0175] Specifically, after generating the graph traversal task described above, the system selects the initial node and sets the traversal parameters based on the analysis objective, for example:

[0176] If the goal is to analyze a user's permissions, then the user's UserID should be used as the initial node.

[0177] If the goal is to detect high-risk role assignments across all tenants, then start with all RoleAssignment records.

[0178] The traversal parameters can be dynamically set according to the task type, with a default value of 5.

[0179] Step S103: The preset graph running model starts from the initial node and performs a multi-hop breadth-first traversal along the member relationship, role binding, and permission operation path until the traversal depth is reached. The node and edge relationships during the traversal are recorded to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationship after the fine-grained dependency extraction to determine the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0180] Optionally, in this embodiment, after the task queue is generated, the graph running model executes the specific traversal logic and constructs the permission graph. Specifically, in this embodiment, the graph running model uses GraphRunner.

[0181] Optionally, in this embodiment, the graph running model starts from the initial node and performs a multi-hop breadth-first traversal along the membership relationship, role binding, and permission operation path until the traversal depth is reached. The node and edge relationships during the traversal process are recorded to determine the corresponding permission graph.

[0182] Specifically, the graph computation kernel expands layer by layer from the initial node based on multi-hop breadth-first search, following the following three types of critical paths:

[0183] Membership (memberOf): Starting from the user, recursively query the groups to which the user belongs, user A → group G1 → group G2.

[0184] Role binding (assignedTo): Queries the roles directly assigned to a user or group and parses the permission actions in the role definition.

[0185] Permission operation path (hasPermission): For example, role definition → resource operation (such as Microsoft.KeyVault / vaults / read), which maps to the actual executable action.

[0186] For example, the graph computing kernel executes the traversal path from the user to the resource:

[0187] User ➝ GroupA ➝RoleAssignment ➝ RoleDefinition ➝Action ➝Resource

[0188] in:

[0189] User: User node, representing a specific user, such as user ID 1234.

[0190] GroupA: The group node to which the user belongs, indicating that the user belongs to a certain group, such as group A.

[0191] RoleAssignment: A role assignment node that indicates that group A has been assigned a role, such as a role assignment.

[0192] RoleDefinition: The role definition node represents the role definition corresponding to the role assignment, that is, the definition information such as the permission action set of the role.

[0193] Action: Action node represents the specific permission actions contained in the role definition, such as read and write operations.

[0194] Resource: A resource node that represents a resource that can ultimately be accessed, such as an Azure resource.

[0195] For example, consider the traversal path from the kernel execution service body to the resource in graph computation:

[0196] SPN ➝ AppRole ➝ API Permissions ➝ Resource

[0197] in:

[0198] SPN: Service Principal node, representing a service principal, such as the service principal of a certain application.

[0199] AppRole: Application Role Node, representing the application role associated with the service subject, that is, the role played by the service subject in the application.

[0200] API Permissions: The API permission node represents the API permissions corresponding to the application role, that is, the access permissions to the API obtained by the service subject through the application role.

[0201] Resource: A resource node that represents a resource that can ultimately be accessed, such as an Azure resource.

[0202] Optionally, in this embodiment, fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationship after fine-grained dependency extraction to determine the corresponding permission topology.

[0203] First, in Azure RBAC, custom roles may inherit permissions from built-in roles. However, multi-hop BFS can only capture directly bound roles and cannot automatically deduce implicit permissions in the inheritance chain. For example, if user A is assigned the custom role CustomRole, and CustomRole inherits permissions from the built-in role Contributor, the inheritance relationship will be missed in the graph if it is not explicitly extracted, resulting in incomplete permission analysis.

[0204] After generating the initial permission graph, we further extracted the implicit role inheritance dependencies to enhance the accuracy of the analysis. By parsing the Permissions and AssignableScopes fields in the role definitions, we constructed an inheritance tree and marked derived permissions, ensuring that the graph covered indirect authorization paths.

[0205] Example: If role A inherits the permissions of role B, then when a user binds to role A, they actually have the permissions of role B.

[0206] Secondly, Azure policies (such as Conditional Access Policies and ResourcePolicies) may dynamically restrict the validity of permissions. For example:

[0207] While role assignments exist, policies may restrict access to resources to only those from specific IP addresses.

[0208] If the policy conditions are ignored, the path generated by multi-hop BFS will be mistakenly judged as a "valid path", leading to false risk reports.

[0209] Specifically, to address the aforementioned issues, we extract the constraints (such as requiring MFA or specific IP access) from the Conditional Access Policy, analyze the impact of the policy on the scope of permission effectiveness, mark "conditional edges" in the graph, and dynamically filter paths that do not meet the conditions during analysis to improve accuracy.

[0210] Finally, Azure permissions can be scoped to a subscription, a resource group, or a single resource. For example:

[0211] Users have the Reader role, but their scope is limited to a specific resource group, not the entire tenant.

[0212] Coarse-grained traversal may incorrectly generalize permissions to the entire scope, while fine-grained extraction of the RoleAssignment's scope field can precisely define permission boundaries.

[0213] Specifically, we resolve scopes as "attribute nodes" in the graph, supporting scope-based permission pruning.

[0214] Next, based on the fine-grained dependency extraction results, the initial map is corrected and enhanced in the following ways:

[0215] Merge redundant paths. If a user obtains the same permissions through multiple paths (such as being bound by both a group and a direct role), only the simplest path will be retained.

[0216] Example: User A → Role R1 (direct binding) and User A → Group G1 → Role R1 are merged into a single relationship.

[0217] Mark high-risk dependencies, label sensitive relationships (such as service entities having cross-tenant access permissions), and identify roles with excessive authorization (such as...). / Wildcard permissions).

[0218] Finally, the spectral data is converted into a weighted directed graph, and the output format supports visualization tools (such as Neo4j and BloodHound) or structured reports.

[0219] The generated permission topology is used in the following scenarios:

[0220] (1) Security audit

[0221] Identify configurations that violate the principle of least privilege (such as a Guest user having an administrator role).

[0222] Generate a compliance report and mark the permission assignments that need to be corrected.

[0223] (2) Attack path simulation

[0224] Combine tools (such as BloodHound) to simulate possible paths for attackers to escalate privileges from low-privilege accounts.

[0225] Example: Implementing permission escalation through nested group relationships.

[0226] (3) Dynamic monitoring

[0227] Regularly run graph construction, compare historical data, and detect permission changes (such as adding high-risk role bindings).

[0228] This example demonstrates how this embodiment deconstructs the undocumented interface of the identity management platform and, based on that interface, collects a complete view of the user structure in Azure AD under the least privilege mode.

[0229] As described above, the permission topology construction method based on least privilege provided in this application can obtain undisclosed interface path templates by structured parsing and classifying request data from the identity management platform and performing parameterized substitution. It then establishes a mapping relationship between the undisclosed interface path templates and a preset identity management platform permission model to obtain an undisclosed interface parameter structure. This undisclosed interface parameter structure is then merged with existing interface parameter structures to obtain a centralized interface parameter structure. Under the least privilege role, based on the task scheduling engine and graph operation model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth traversal is performed along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationships to determine the corresponding permission topology. This improves the security and management efficiency of the identity and access management platform.

[0230] In one embodiment of the least privilege-based permission topology construction method of this application, the following may also be included:

[0231] Step S201: Call the centralized interface parameter structure through Reader or Audit role permissions, extract the associated data of users, groups, service subjects and policies according to the preset field mapping rules, and determine the corresponding resource object data;

[0232] Step S202: Establish logical relationships between the resource object data and determine the corresponding user resource dataset, wherein the logical relationships include user-group affiliation, role-policy binding, and service subject-application registration mapping.

[0233] Optionally, in this embodiment, the core objective of this step is to extract key object data from Azure AD by calling a centralized interface parameter structure (such as the Microsoft Graph API) when only having Reader or Audit role permissions, and to perform structured mapping according to preset rules to finally generate a resource object dataset.

[0234] Specifically, the system calls centralized API interfaces: basic data is obtained through endpoints such as / users, / groups, / servicePrincipals, and / policies of the Microsoft Graph API.

[0235] If certain key fields (such as a user's assigned Roles or a group's dynamicMembershipRules) cannot be directly retrieved due to insufficient permissions, they can be completed through a combination of queries using multiple interfaces. For example, if a user's role assignment cannot be directly read, it can be indirectly queried through the / roleAssignments interface combined with the user ID.

[0236] Another approach is to use data inference strategies to infer the group relationships of users by looking at the group's members list;

[0237] An incremental collection strategy can also be adopted to cache the paginated query results, avoid duplicate requests, and support resume collection after interruption.

[0238] Specifically, the collected data is categorized and stored according to object type, and integrated into a user resource dataset through logical association rules. The construction of logical associations mainly covers the following three core relationships:

[0239] User-group membership: A two-way mapping is established by resolving the members attribute of a group or the memberOf attribute of a user.

[0240] Role-policy binding relationship: Parse roleAssignments data to determine which users / groups are granted specific roles (such as Global Administrator).

[0241] Service Subject-Application Registration Mapping: Associates a service subject with its registered Azure AD application using the appId.

[0242] The final generated user resource dataset is stored using a graph structure.

[0243] Through step S202, this embodiment successfully collected raw data in a low-privilege environment, established logical relationships between data, and formed a structured dataset that can be used for in-depth permission analysis, laying the foundation for subsequent user permission structure analysis.

[0244] In one embodiment of the least privilege-based permission topology construction method of this application, the following may also be included:

[0245] Step S301: The preset task scheduling engine dynamically generates graph traversal task types based on the object types in the user resource dataset. The graph traversal task types include user valid permission calculation tasks, resource access backtracking tasks, and permission escalation path detection tasks.

[0246] Step S302: Determine the corresponding graph traversal task queue according to the task execution order of the graph traversal task type, and assign an initial node and traversal depth parameter to each task queue.

[0247] Optionally, in this embodiment, the task scheduling engine is a Task Engine, which transforms the permission issue into a graph traversal task.

[0248] Specifically, the task structure is defined as follows:

[0249] {

[0250] "task_id": "task-001", [Unique identifier for the task]

[0251] "type": "EffectiveAccessTask", [Task type, here indicating a task to calculate the effective access permissions for a specific subject]

[0252] "input": {[Task input parameters]}

[0253] "principal_id": "user-1234", [Identifier of the identity subject, user ID is 1234]

[0254] "cloud": "Azure" [Azure platform]

[0255] },

[0256] "config": {[Task configuration parameters]}

[0257] "max_depth": 5, [Maximum traversal depth]

[0258] "resolve_custom_roles": true [Whether to resolve custom roles]

[0259] }

[0260] }

[0261] Specifically, Example 1 of the graph traversal task: User valid permission calculation task (User → Resource).

[0262] Objective: To answer the question, "What resources can a given identity (user / service entity) ultimately access?"

[0263] Task type: EffectiveAccessTask, starting from the user, traversing groups, roles, policies along relationships such as memberOf and assignedTo, until reaching the resource node.

[0264] Application scenarios: access control auditing, compliance checks.

[0265] Specifically, Example 2 of the graph traversal task: Resource access backtracking task (resource → user).

[0266] Objective: To answer the question, "Which users can access a sensitive resource (such as Key Vault)?"

[0267] Task type: ResourceAccessBacktraceTask, which iterates back through resource nodes to determine role assignments and group membership relationships.

[0268] Application scenarios: attack surface assessment, vulnerability impact analysis.

[0269] Specifically, Example 3 of the graph traversal task: Privilege escalation path detection task.

[0270] Objective: To identify potential privilege escalation paths (Guest user → privileged group → administrator role).

[0271] Task type: PrivilegeEscalationDetectionTask, which marks abnormal paths by combining risk rules (such as role sensitivity scores).

[0272] Application scenarios: Red team drills, security reinforcement.

[0273] Specifically, after generating the graph traversal task described above, the system selects the initial node and sets the traversal parameters based on the analysis objective, for example:

[0274] If the goal is to analyze a user's permissions, then the user's UserID should be used as the initial node.

[0275] If the goal is to detect high-risk role assignments across all tenants, then start with all RoleAssignment records.

[0276] The traversal parameters can be dynamically set according to the task type, with a default value of 5.

[0277] Through step S302, this embodiment successfully generates a graph traversal task queue, laying the foundation for subsequent dynamic permission analysis of graph traversal.

[0278] In one embodiment of the least privilege-based permission topology construction method of this application, the following may also be included:

[0279] Step S401: Parse the role inheritance chain of the permission graph, extract the indirect permission granting path, and determine the corresponding role inheritance relationship;

[0280] Step S402: Parse the conditional expression in the preset policy binding, extract the restriction fields, and determine the corresponding access restriction relationship;

[0281] Step S403: Parse the resource scope field corresponding to the user role in the permission graph to determine the corresponding resource restriction relationship.

[0282] Optionally, in this embodiment, after generating the initial permission graph, we first extract the implicit role inheritance dependencies to enhance the accuracy of the analysis. By parsing the Permissions field and AssignableScopes in the role definition, we construct an inheritance tree and mark derived permissions to ensure that the graph covers indirect authorization paths.

[0283] Example: If role A inherits the permissions of role B, then when a user binds to role A, they actually have the permissions of role B.

[0284] Secondly, Azure policies (such as Conditional Access Policies and ResourcePolicies) may dynamically restrict the validity of permissions. For example:

[0285] While role assignments exist, policies may restrict access to resources to only those from specific IP addresses.

[0286] If the policy conditions are ignored, the path generated by multi-hop BFS will be mistakenly judged as a "valid path", leading to false risk reports.

[0287] Specifically, to address the aforementioned issues, we extract the constraints (such as requiring MFA or specific IP access) from the Conditional Access Policy, analyze the impact of the policy on the scope of permission effectiveness, mark "conditional edges" in the graph, and dynamically filter paths that do not meet the conditions during analysis to improve accuracy.

[0288] Finally, Azure permissions can be scoped to a subscription, a resource group, or a single resource. For example:

[0289] Users have the Reader role, but their scope is limited to a specific resource group, not the entire tenant.

[0290] Coarse-grained traversal may incorrectly generalize permissions to the entire scope, while fine-grained extraction of the RoleAssignment's scope field can precisely define permission boundaries.

[0291] Specifically, we resolve scopes as "attribute nodes" in the graph, supporting scope-based permission pruning.

[0292] Through step S403, this embodiment successfully performed fine-grained extraction of the permission graph, obtaining the implicit permission dependencies, which lays a solid data foundation for subsequent permission correction and enhancement of the permission graph.

[0293] In one embodiment of the least privilege-based permission topology construction method of this application, the following may also be included:

[0294] Step S501: Based on the dependency relationships extracted by the fine-grained dependency extraction, perform redundant path merging operations on the permission graph to determine the corresponding permission topology.

[0295] Step S502: Based on the dependency relationships extracted by the fine-grained dependency extraction, perform a high-risk dependency relationship marking operation on the permission graph to determine the corresponding permission topology.

[0296] Optionally, in this embodiment, the initial map is corrected and enhanced based on the fine-grained dependency extraction results, including the following methods:

[0297] Merge redundant paths. If a user obtains the same permissions through multiple paths (such as being bound by both a group and a direct role), only the simplest path will be retained.

[0298] Example: User A → Role R1 (direct binding) and User A → Group G1 → Role R1 are merged into a single relationship.

[0299] Mark high-risk dependencies, label sensitive relationships (such as service entities having cross-tenant access permissions), and identify over-authorized roles (such as * / * wildcard permissions).

[0300] Finally, the spectral data is converted into a weighted directed graph, and the output format supports visualization tools (such as Neo4j and BloodHound) or structured reports.

[0301] Through step S502, this embodiment successfully corrected and enhanced the permission map.

[0302] In one embodiment of the least privilege-based permission topology construction method of this application, the following may also be included:

[0303] Step S601: Extract common fields from the request paths in the undisclosed interface dataset after classification, and determine the corresponding static fields and dynamic variables. The static fields are fixed identifiers that represent the service type, and the dynamic variables are unique identifier parameters in the resource layer.

[0304] Step S602: Match the dynamic variables based on preset regular expression rules, construct a parameter dictionary, and perform parameterized replacement on the matched dynamic variables according to the parameter dictionary to determine the corresponding undisclosed interface path template.

[0305] Optionally, in this embodiment, the system parses the request path in the dataset for each service category interface. The request path is the URL portion of the API call:

[0306] " / subscriptions / xxxx / resourceGroups / rgname / providers / Microsoft.Compute / virtualMachines / vm-name"

[0307] During the request path parsing process, the system extracts static common fields from the path. Static common fields refer to the parts that appear consistently in similar interface paths; these fields typically represent the service type or resource type. For example, in the path above:

[0308] / subscriptions / , / resourceGroups / , and / providers / Microsoft.Compute / virtualMachines / are all static public fields that remain unchanged across similar interfaces, helping to identify the service type and resource level to which the interface belongs.

[0309] Next, in addition to static public fields, the path also contains dynamic variables, which are unique identifier parameters at the resource level. For example, {subscriptionId}, {resourceGroupName}, and {vmName} are all dynamic variables that will take different values ​​in different API calls.

[0310] We have predefined a series of regular expression rules for matching dynamic variables.

[0311] Regular expression rules can be:

[0312] The Resource Identifier pattern matches the unique identifier of an Azure resource (such as virtualMachines, storageAccounts).

[0313] The Subscription ID pattern matches the Azure Subscription ID, which is a 32-bit hexadecimal string.

[0314] Resource Group Name pattern that matches Azure resource group names (such as my-resource-group), allowing letters, numbers, hyphens, and underscores.

[0315] Resource Name pattern that matches Azure resource names (such as myVM, storageAccount01) and consists of letters, numbers, and hyphens.

[0316] Resource Path pattern matches the complete Azure resource path.

[0317] Tenant ID pattern, matching Azure AD tenant ID, format is similar to subscription ID.

[0318] Access Token mode, matching Azure AD access tokens in JWT format.

[0319] Storage Connection String pattern that matches the connection string of an Azure storage account.

[0320] More complex rules (such as nested JSON parsing) can be combined with recursive regular expressions or JSON parsing libraries to enhance matching capabilities.

[0321] The system uses preset regular expression rules to match the identified dynamic variables. Through matching, the system can verify whether the dynamic variables conform to the expected format and extract their specific values.

[0322] Then, based on the dynamic variables matched by regular expressions, the system constructs a parameter dictionary.

[0323] The parameter dictionary is a collection of key-value pairs, where the key is the name of the dynamic variable and the value is the actual value of the dynamic variable.

[0324] For example, for the original URL path mentioned above

[0325] / subscriptions / xxxx / resourceGroups / rgname / providers / Microsoft.Compute / virtualMachines / vm-name"

[0326] The dynamic variables are "xxxxxxx", "rg-name", and "vm-name".

[0327] We construct a parameter dictionary based on the aforementioned dynamic variables.

[0328] "parameters": {[parameter dictionary]}

[0329] "subscriptionId": "xxxxxxx",

[0330] "resourceGroup": "rg-name",

[0331] "vmName": "vm-name

[0332] },

[0333] Parameterized replacement replaces dynamic variables with specific values ​​from a parameter dictionary, thereby generating standardized interface paths.

[0334] Let's take the original URL path mentioned above as an example again:

[0335] / subscriptions / xxxx / resourceGroups / rgname / providers / Microsoft.Compute / virtualMachines / vm-name"

[0336] The template for the unpublished interface path after parameter replacement using a parameterized dictionary is as follows:

[0337] " / subscriptions / {subscriptionId} / resourceGroups / {resourceGroup} / providers / Microsoft.Compute / virtualMachines / {vmName}", [Path Template]

[0338] After obtaining the standardized interface path, we construct a unified invocation template based on the standardized interface path, the parameter dictionary we just built, and the request methods present in the original unpublished interface data. For example, the unified invocation template is as follows:

[0339] {

[0340] "template": " / subscriptions / {subscriptionId} / resourceGroups / {resourceGroup} / providers / Microsoft.Compute / virtualMachines / {vmName}", [Standardized Interface Path Template]

[0341] "parameters": {[parameter dictionary]}

[0342] "subscriptionId": "xxxxxxx",

[0343] "resourceGroup": "rg-name",

[0344] "vmName": "vm-name

[0345] },

[0346] "method": "GET" [Request method]

[0347] }

[0348] Mapping relationship: Request URL → Abstract resource type → Permission item category (e.g., Microsoft.Compute / virtualMachines / read)

[0349] Through step S602, this embodiment successfully generates a unified calling template for undisclosed interfaces, providing a solid foundation for subsequent interface calls, data collection, and permission analysis.

[0350] In one embodiment of the least privilege-based permission topology construction method of this application, the following may also be included:

[0351] Step S701: Extract the path key fields from the undisclosed interface path template, perform resource hierarchy structure parsing on the path key fields, and determine the corresponding undisclosed interface resource type;

[0352] Step S702: Perform fuzzy matching between the undisclosed interface resource type and the resource type in the preset identity management platform permission model. If the match is successful, output the mapping relationship and determine the corresponding permission mapping table.

[0353] Step S703: Semantically segment the request methods in the permission mapping table, determine the corresponding permission operation types, summarize and aggregate the permission operation types and the unpublished interface path templates according to the unpublished interface resource types, and determine the corresponding unpublished interface parameter structure.

[0354] First, the resource level identifier is extracted from the undisclosed interface path template, and the resource type of the undisclosed interface is parsed.

[0355] For example: path / beta / internalVaults / {vaultName} / secrets → the key fields are internalVaults and secrets.

[0356] Map key fields to resource types according to the Azure resource naming convention ({service name} / {resource type} / {sub-resource}). For example:

[0357] internalVaults → Inferred to be an undocumented variant of Microsoft.KeyVault / vaults.

[0358] secrets → Sub-resource type, belonging to the KeyVault main resource.

[0359] Then, role definition data is extracted from the permission entries in Azure AD's permission model, including predefined roles (such as "Global Administrator" and "Reader") and custom roles. Role definition data contains two core parts:

[0360] Permission Action Set: Describes the operations that a role can perform.

[0361] For example: Microsoft.Compute / virtualMachines / read

[0362] Associated resource type: Specifies the scope of resources to which the operation applies. Each set of permission actions is associated with a specific resource type.

[0363] For example: VirtualMachines, KeyVault

[0364] Next, compare the undisclosed interface resource types (internalVaults) with the resource types (KeyVaults) defined in the permission model role definition, allowing partial string matching (e.g., internal* matching *vaults). If the resource type match is successful, output the permission mapping table. For example, the mapped permission table is as follows:

[0365] {

[0366] "path_template": Standardized interface path template

[0367] " / subscriptions / {s} / resourceGroups / {r} / providers / Microsoft.KeyVault / vaults / {v}",

[0368] "method": "GET", [Request Method]

[0369] "mapped_permission": "Microsoft.KeyVault / vaults / read", [Mapped Permission]

[0370] "resource_type": "KeyVault", [Resource Type]

[0371] "cloud": "Azure" [Cloud Platform]

[0372] }

[0373] After obtaining the mapping permission table, semantic segmentation is performed according to the HTTP Method (request method):

[0374] GET → read permission

[0375] PUT / POST → write / contribute

[0376] DELETE → delete permission

[0377] The resource-operation matrix is ​​constructed by using the parsed unpublished interface resource types (such as KeyVault and VirtualMachines) as rows and the semantically divided actions (such as read, write, and delete) as columns. Each cell records all interface paths that support a certain operation under the resource type.

[0378] By establishing a resource-operation matrix, the operation types and interface paths under different resource types can be managed systematically, supporting multi-dimensional analysis and allowing for easy querying of all operation types and their corresponding interface paths under a specific resource type.

[0379] Next, based on the resource-operation matrix, a corresponding standardized interface structure tree is generated for each resource type. The standardized interface structure tree is a hierarchical data structure that includes resource levels, supported operation methods, and associated permission policies.

[0380] The resource-operation matrix and structure tree provide a multi-dimensional perspective, allowing for both macroscopic comparison of the capability differences between public and non-public interfaces and microscopic analysis of the compliance of permission policies for individual interfaces.

[0381] For a specific implementation example, the interface structure tree is as follows:

[0382] {

[0383] "resource": "Microsoft.Compute / virtualMachines", [Resource Type]

[0384] "operations": [This represents a list of operations supported by this resource type]

[0385] {

[0386] "action": "read", [Operation Type]

[0387] "method": "GET", [Request Method]

[0388] "path": " / subscriptions / {...} / ... / virtualMachines / {vmName}" [Path Template]

[0389] },

[0390] {

[0391] "action": "write", [Operation Type]

[0392] "method": "PUT", [Request Method]

[0393] "path": " / subscriptions / {...} / ... / virtualMachines / {vmName}" [Path Template]

[0394] } ]

[0396] }

[0397] The standardized interface structure tree presents the structure and permission policies of the identity management platform's unpublished interfaces under different resource types in a hierarchical manner, enabling users to quickly understand the unpublished interface paths, supported operation methods, and corresponding permission policies for each resource type.

[0398] Through step S703, this embodiment successfully summarized and constructed an undisclosed interface parameter structure, laying the foundation for subsequent permission queries and the generation of user permission structure graphs.

[0399] To improve the security and management efficiency of the identity and access management platform, this application provides an embodiment of a permission topology construction apparatus based on least privilege, which implements all or part of the aforementioned method for constructing a permission topology based on least privilege. See [link to embodiment]. Figure 2 The permission topology construction device based on the lowest permission specifically includes the following components:

[0400] The undisclosed interface structure extraction module 10 is used to perform structured parsing of request data from the identity management platform, determine the corresponding undisclosed interface dataset, classify the undisclosed interface dataset, perform parameterized substitution on the classified undisclosed interface dataset, determine the corresponding undisclosed interface path template, establish a mapping relationship between the undisclosed interface path template and the preset identity management platform permission model, determine the corresponding undisclosed interface parameter structure, and merge the undisclosed interface parameter structure with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure.

[0401] The lowest-privilege graph traversal task determination module 20 is used to collect data from the centralized interface parameter structure under the lowest-privilege role, determine the corresponding user resource dataset, determine the corresponding graph traversal task queue according to the preset task scheduling engine and the user resource dataset, and allocate an initial node and traversal depth parameter to each task queue.

[0402] The permission topology determination module 30 is used to perform a multi-hop breadth-first traversal of the preset graph running model starting from the initial node, along the member relationship, role binding, and permission operation path until the traversal depth is reached. It records the node and edge relationships during the traversal process, determines the corresponding permission graph, performs fine-grained dependency extraction on the permission graph, and updates the permission graph according to the dependency relationship after the fine-grained dependency extraction, and determines the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0403] As described above, the permission topology construction device based on the lowest privilege provided in this application can obtain undisclosed interface path templates by structured parsing and classifying request data from the identity management platform and performing parameterized substitution. It then establishes a mapping relationship between the undisclosed interface path templates and a preset identity management platform permission model to obtain an undisclosed interface parameter structure. This undisclosed interface parameter structure is then merged with existing interface parameter structures to obtain a centralized interface parameter structure. Under the lowest privilege role, based on the task scheduling engine and graph operation model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth traversal is performed along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationships to determine the corresponding permission topology. This improves the security and management efficiency of the identity and access management platform.

[0404] To further illustrate this solution, this application also provides a specific application example of using the above-described least-privilege-based permission topology construction device to implement the least-privilege-based permission topology construction method, which specifically includes the following:

[0405] This embodiment describes the application model and data flow for high-level graph traversal.

[0406] Initiate a Task: such as "Calculate the valid permissions of a user".

[0407] TaskEngine received a task request:

[0408] Type: EffectiveAccessTask

[0409] User: user@contoso.com

[0410] Locate the starting node User:user@contoso.com from the graph database.

[0411] GraphRunner traverses permission paths

[0412] Following the Azure RBAC model expansion path, GraphRunner executes the following chain of operations:

[0413] Find your group (Group Membership)

[0414] Find the Role Assignments bound to each group.

[0415] Iterate through Role Assignments to obtain Role Definitions

[0416] Expand the Actions (permitted actions) and NotActions (disallowed actions) sections in the Role list.

[0417] Depending on the scope of the Role Assignment, it is applied to match resource nodes.

[0418] Perform high-level filtering based on policy calculations (conditional policy and environment constraint analysis).

[0419] In Azure, some Role Assignments may have conditional expressions or only take effect under specific address / IP / MFA conditions.

[0420] GraphRunner parses conditional expressions (such as Azure Conditional Access controls), infers whether these policies are effective (in conjunction with the Task's input context), and filters out "ineffective paths".

[0421] Generate structured permission path output (supports security policy analysis and least privilege summary).

[0422] Output:

[0423] {

[0424] "user": "alice@contoso.com", [User ID]

[0425] "effective_permissions": [List of effective permissions]

[0426] {

[0427] "resource": " / subscriptions / x / resourceGroups / dev / ...", [Resource path, indicating the Azure resource that the user can access]

[0428] "action": "Microsoft.Compute / virtualMachines / write", [Permission action, indicating the operations a user is allowed to perform on this resource]

[0429] "via": [Permission path, indicating which roles or groups the user obtained this permission through.]

[0430] "Group: DevOps", [Passed the DevOps group test]

[0431] "Role: Contributor" [Through the Contributor role]

[0432] ],

[0433] "scope": "resourceGroup", [Scope: This permission applies to the resource group level.]

[0434] "risk": "Medium" [Risk level, indicating that the risk level of this access path is medium]

[0435] },

[0436] {

[0437] "resource": " / subscriptions / x / resourceGroups / poc / keyvaults / k1", [Resource path]

[0438] "action": "Microsoft.KeyVault / vaults / secrets / delete", [Permission operation action]

[0439] "via": ["SPN: AppIdentity", "Custom Role: SecretAdmin"], [Permission Path]

[0440] "scope": "resource", [Scope of application]

[0441] "risk": "Critical" [Risk Level]

[0442] } ]

[0444] }

[0445] From a hardware perspective, in order to improve the security and management efficiency of the identity and access management platform, this application provides an embodiment of an electronic device for implementing all or part of the content of the least privilege-based permission topology construction method, wherein the electronic device specifically includes the following:

[0446] The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to implement information transmission between the least privilege-based permission topology construction method and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the least privilege-based permission topology construction method in the previous embodiments, and the contents of the embodiments are incorporated herein, and repeated details will not be repeated.

[0447] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0448] In practical applications, the method for constructing a permission topology based on least privilege can be partially executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0449] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0450] Figure 3 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 3 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 3 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0451] In one embodiment, the function of constructing a permission topology based on least privilege can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0452] Step S101: Perform structured parsing on the request data from the identity management platform to determine the corresponding unpublished interface dataset, classify the unpublished interface dataset, perform parameterized substitution on the classified unpublished interface dataset, determine the corresponding unpublished interface path template, establish a mapping relationship between the unpublished interface path template and the preset identity management platform permission model, determine the corresponding unpublished interface parameter structure, and merge the unpublished interface parameter structure with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure;

[0453] Step S102: Under the lowest privilege role, perform data traversal and collection on the centralized interface parameter structure to determine the corresponding user resource dataset. Based on the preset task scheduling engine and the user resource dataset, determine the corresponding graph traversal task queue and assign an initial node and traversal depth parameter to each task queue.

[0454] Step S103: The preset graph running model starts from the initial node and performs a multi-hop breadth-first traversal along the member relationship, role binding, and permission operation path until the traversal depth is reached. The node and edge relationships during the traversal are recorded to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationship after the fine-grained dependency extraction to determine the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0455] As described above, the electronic device provided in this application embodiment obtains a non-public interface path template by structured parsing and classifying request data from the identity management platform and performing parameterized substitution. It then establishes a mapping relationship between the non-public interface path template and a preset identity management platform permission model to obtain a non-public interface parameter structure. This non-public interface parameter structure is then merged with the existing interface parameter structure to obtain a centralized interface parameter structure. Under the lowest permission role, based on the task scheduling engine and graph operation model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth traversal is performed along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationships to determine the corresponding permission topology. This improves the security and management efficiency of the identity and access management platform.

[0456] In another implementation, the least privilege-based permission topology construction method can be configured separately from the central processing unit 9100. For example, the least privilege-based permission topology construction method can be configured as a chip connected to the central processing unit 9100, and the function of the least privilege-based permission topology construction method can be implemented through the control of the central processing unit.

[0457] like Figure 3 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 3 All components shown; in addition, the electronic device 9600 may also include Figure 3 For components not shown, please refer to existing technologies.

[0458] like Figure 3 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0459] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0460] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0461] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0462] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0463] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0464] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor 9130 is also coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored sound via the speaker 9131.

[0465] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the least-privilege-based permission topology construction method with a server or client as the execution subject in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the least-privilege-based permission topology construction method with a server or client as the execution subject in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0466] Step S101: Perform structured parsing on the request data from the identity management platform to determine the corresponding unpublished interface dataset, classify the unpublished interface dataset, perform parameterized substitution on the classified unpublished interface dataset, determine the corresponding unpublished interface path template, establish a mapping relationship between the unpublished interface path template and the preset identity management platform permission model, determine the corresponding unpublished interface parameter structure, and merge the unpublished interface parameter structure with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure;

[0467] Step S102: Under the lowest privilege role, perform data traversal and collection on the centralized interface parameter structure to determine the corresponding user resource dataset. Based on the preset task scheduling engine and the user resource dataset, determine the corresponding graph traversal task queue and assign an initial node and traversal depth parameter to each task queue.

[0468] Step S103: The preset graph running model starts from the initial node and performs a multi-hop breadth-first traversal along the member relationship, role binding, and permission operation path until the traversal depth is reached. The node and edge relationships during the traversal are recorded to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationship after the fine-grained dependency extraction to determine the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0469] As described above, the computer-readable storage medium provided in this application provides a structured parsing and classification of request data from the identity management platform, followed by parameterized substitution to obtain a non-public interface path template. A mapping relationship is established between the non-public interface path template and a preset identity management platform permission model to obtain a non-public interface parameter structure. This non-public interface parameter structure is then merged with existing interface parameter structures to obtain a centralized interface parameter structure. Under the lowest-authority role, based on the task scheduling engine and graph operation model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth-first traversal is performed along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated based on the dependency relationships to determine the corresponding permission topology. This improves the security and management efficiency of the identity and access management platform.

[0470] Embodiments of this application also provide a computer program product capable of implementing all steps in the least privilege-based permission topology construction method described above, where the execution subject is a server or client. When executed by a processor, this computer program / instruction implements the steps of the least privilege-based permission topology construction method. For example, the computer program / instruction implements the following steps:

[0471] Step S101: Perform structured parsing on the request data from the identity management platform to determine the corresponding unpublished interface dataset, classify the unpublished interface dataset, perform parameterized substitution on the classified unpublished interface dataset, determine the corresponding unpublished interface path template, establish a mapping relationship between the unpublished interface path template and the preset identity management platform permission model, determine the corresponding unpublished interface parameter structure, and merge the unpublished interface parameter structure with the preset existing interface parameter structure to determine the corresponding centralized interface parameter structure;

[0472] Step S102: Under the lowest privilege role, perform data traversal and collection on the centralized interface parameter structure to determine the corresponding user resource dataset. Based on the preset task scheduling engine and the user resource dataset, determine the corresponding graph traversal task queue and assign an initial node and traversal depth parameter to each task queue.

[0473] Step S103: The preset graph running model starts from the initial node and performs a multi-hop breadth-first traversal along the member relationship, role binding, and permission operation path until the traversal depth is reached. The node and edge relationships during the traversal are recorded to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationship after the fine-grained dependency extraction to determine the corresponding permission topology. The permission topology is used to fully display the user network structure of the identity management platform.

[0474] As described above, the computer program product provided in this application provides that, through structured parsing and classification of request data from the identity management platform, and parameterized substitution, obtains a non-public interface path template, establishes a mapping relationship between the non-public interface path template and the preset identity management platform permission model, obtains a non-public interface parameter structure, and merges the non-public interface parameter structure with the existing interface parameter structure to obtain a centralized interface parameter structure. Under the lowest permission role, based on the task scheduling engine and graph operation model, starting from the initial node of the centralized interface parameter structure, a multi-hop breadth traversal is performed along member relationships, role bindings, and permission operation paths to determine the corresponding permission graph. Fine-grained dependency extraction is performed on the permission graph, and the permission graph is updated according to the dependency relationship to determine the corresponding permission topology. This improves the security and management efficiency of the identity and access management platform.

[0475] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0476] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0477] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0478] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0479] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method of constructing a permission topology based on least-privilege, characterized by, The method comprises: structurally analyzing request data from an identity management platform, determining a corresponding undisclosed interface data set, classifying the undisclosed interface data set, extracting request paths in the classified undisclosed interface data set for common fields, determining corresponding static fields and dynamic variables, wherein the static fields are fixed identifiers representing service types, the dynamic variables are unique identification parameters in a resource hierarchy, matching the dynamic variables based on a preset regular expression rule, constructing a parameter dictionary, parameterizing and replacing the matched dynamic variables based on the parameter dictionary, determining a corresponding undisclosed interface path template, establishing a mapping relationship between the undisclosed interface path template and a preset identity management platform permission model, determining a corresponding undisclosed interface parameter structure, fusing the undisclosed interface parameter structure with a preset existing interface parameter structure, and determining a corresponding centralized interface parameter structure; under a minimum permission role, data traversal collection is performed on the centralized interface parameter structure to determine a corresponding user resource data set, a graph traversal task queue is determined based on a preset task scheduling engine and the user resource data set, and an initial node and a traversal depth parameter are assigned to each task queue; a preset graph running model starts from the initial node, performs multi-hop breadth traversal along membership, role binding, and permission operation paths until the traversal depth is reached, records node and edge relationships in the traversal process, determines a corresponding permission graph, performs fine-grained dependency extraction on the permission graph, and performs redundant path merging operations and high-risk dependency relationship marking operations on the permission graph based on the dependency relationships obtained after the fine-grained dependency extraction, and determines a corresponding permission topology structure, which is used to completely display the user context structure of the identity management platform.

2. The least-privilege-based privilege topology construction method according to claim 1, characterized in that, The data traversal collection on the centralized interface parameter structure under the minimum permission role to determine the corresponding user resource data set comprises: The centralized interface parameter structure is called through a Reader or Audit role permission, and associated data of users, groups, service principals, and policies is extracted according to a preset field mapping rule to determine corresponding resource object data; logical association relationships between the resource object data are established to determine a corresponding user resource data set, wherein the logical association relationships include user-group membership relationships, role-policy binding relationships, and service principal-application registration mapping relationships.

3. The least-privilege-based privilege topology construction method according to claim 1, characterized in that, The determination of a graph traversal task queue based on a preset task scheduling engine and the user resource data set, and the assignment of an initial node and a traversal depth parameter to each task queue, comprises: The preset task scheduling engine dynamically generates a graph traversal task type according to the object types in the user resource data set, wherein the graph traversal task type includes a user effective permission calculation task, a resource access backtracking task, and a permission promotion path detection task; a graph traversal task queue is determined according to a task execution order of the graph traversal task type, and an initial node and a traversal depth parameter are assigned to each task queue.

4. The least-privilege-based privilege topology construction method according to claim 1, characterized by, The fine-grained dependency extraction on the permission graph comprises: analyzing a role inheritance chain of the permission graph, extracting an indirect permission granting path, and determining a corresponding role inheritance relationship; analyzing a condition expression in a preset policy binding, extracting a restriction field therein, and determining a corresponding access restriction relationship; analyzing a resource scope field corresponding to a user role of the permission graph, and determining a corresponding resource restriction relationship.

5. The least-privilege-based privilege topology construction method according to claim 1, characterized in that, The mapping relationship between the undisclosed interface path template and the preset identity management platform permission model is established, and a corresponding undisclosed interface parameter structure is determined, comprising: extracting a path key field in the undisclosed interface path template, performing resource hierarchical structure analysis on the path key field, and determining a corresponding undisclosed interface resource type; performing fuzzy matching on the undisclosed interface resource type and a resource type in the preset identity management platform permission model, and if the matching is successful, outputting a mapping relationship and determining a corresponding permission mapping table; performing semantic division on a request method in the permission mapping table, determining a corresponding permission operation type, and according to the undisclosed interface resource type, aggregating the permission operation type and the undisclosed interface path template to determine a corresponding undisclosed interface parameter structure.

6. A least-privilege-based privilege topology construction apparatus characterized by comprising: The device comprises: an undisclosed interface structured extraction module configured to perform structured analysis on request data from an identity management platform, determine a corresponding undisclosed interface data set, classify the undisclosed interface data set, and extract a request path in the classified undisclosed interface data set to determine a corresponding static field and dynamic variable, wherein the static field is a fixed identifier representing a service type, the dynamic variable is a unique identification parameter in a resource hierarchy, a parameter dictionary is constructed by matching the dynamic variable based on a preset regular expression rule, and the dynamic variable after the matching is parameterized and replaced according to the parameter dictionary to determine a corresponding undisclosed interface path template, establish a mapping relationship between the undisclosed interface path template and a preset identity management platform permission model, determine a corresponding undisclosed interface parameter structure, fuse the undisclosed interface parameter structure with a preset existing interface parameter structure, and determine a corresponding centralized interface parameter structure; a minimum permission graph traversal task determination module configured to perform data traversal collection on the centralized interface parameter structure under a minimum permission role to determine a corresponding user resource data set, determine a graph traversal task queue according to a preset task scheduling engine and the user resource data set, and assign an initial node and a traversal depth parameter to each task queue; A permission topology determination module is configured to preset a graph running model to start from the initial node, perform multi-hop breadth traversal along membership, role binding, and permission operation paths until the traversal depth is reached, record node and edge relationships in the traversal process, determine a corresponding permission graph, perform fine-grained dependency extraction on the permission graph, perform redundant path merging and high-risk dependency marking operations on the permission graph according to the dependency relationship after the fine-grained dependency extraction, and determine a corresponding permission topology, which is used to completely present a user context structure of the identity management platform.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the steps of the permission topology construction method based on the lowest permission according to any one of claims 1 to 5 when executing the program.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program implements the steps of the permission topology construction method based on the lowest permission according to any one of claims 1 to 5 when executed by the processor.

Images