A method, device, and medium for generating permission sessions for database operation and maintenance.

Abstract

This application discloses a method, device, and medium for generating permission sessions for database operation and maintenance, relating to the fields of database security, database operation and maintenance management, and access control. The method includes: receiving a database operation and maintenance request, parsing it, and generating a corresponding operation and maintenance plan; generating a corresponding capability profile based on the operation and maintenance plan; generating a corresponding target permission set based on the capability profile, and then creating and configuring a temporary permission entity in the target database; establishing an operation and maintenance session with the target database and binding the temporary permission entity to the operation and maintenance session; parsing the actually executed SQL statement during the execution of the operation and maintenance session to obtain the corresponding actual capability profile, and comparing and verifying the actual capability profile with the capability profile; blocking the actually executed SQL statement if the comparison and verification result indicates execution drift; and revoking the temporary permission entity if the operation and maintenance session meets the termination conditions.

Description

Technical Field

[0001] This application relates to the fields of database security, database operation and maintenance management and access control, and in particular to a method, device and medium for generating permission sessions for database operation and maintenance. Background Technology

[0002] In database operations and maintenance scenarios, database administrators, automated operations and maintenance platforms, or script tasks often need to perform high-risk operations temporarily, such as viewing system views, terminating sessions, rebuilding indexes, performing VACUUM cleanup, modifying parameters, creating extensions, changing table structures, or adjusting user permissions.

[0003] Existing solutions typically employ fixed high-privilege accounts, coarse-grained operation and maintenance roles, or grant extensive permissions after manual approval, resulting in a single operation and maintenance session acquiring permissions beyond the scope required for actual operation. Furthermore, existing solutions struggle to promptly block statements exceeding the authorized profile and are prone to leaving remnants after operation and maintenance, creating long-term security vulnerabilities. Summary of the Invention

[0004] This application provides a method, device, and medium for generating permission sessions for database operation and maintenance, in order to solve the following technical problem: how to reduce the risk of over-authorization and permission residue in operation and maintenance.

[0005] In a first aspect, embodiments of this application provide a method for generating permission sessions for database operation and maintenance (O&M) operations. The method includes: receiving a database O&M operation request, parsing the request, and generating an O&M operation plan corresponding to the request; generating a capability profile corresponding to the O&M operation request based on the O&M operation plan; generating a target permission set corresponding to the request based on the capability profile, and creating and configuring a temporary permission entity in a target database based on the target permission set; establishing an O&M session with the target database and binding the temporary permission entity to the O&M session to authorize the session to perform operations within a defined scope; parsing the actually executed Structured Query Language (SQL) statement during the execution of the O&M session to obtain an actual capability profile corresponding to the executed SQL statement, and comparing and verifying the actual capability profile with the capability profile to obtain a comparison and verification result; blocking the executed SQL statement if the comparison and verification result indicates execution drift; and revoking the temporary permission entity if the O&M session meets the termination conditions.

[0006] Secondly, embodiments of this application also provide a permission session generation device for database operation and maintenance, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a permission session generation method for database operation and maintenance as described in the first aspect above.

[0007] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement a permission session generation method for database operation and maintenance as described in the first aspect above.

[0008] The method, device, and medium for generating permission sessions for database operation and maintenance provided in this application have the following beneficial effects: In this embodiment, database operation requests can be parsed to generate corresponding operation plans. Based on these plans, corresponding capability profiles are then generated. Furthermore, a target permission set can be generated based on the capability profile, and a temporary permission entity can be created and configured in the target database. An operation session with the target database is established, and the temporary permission entity is bound to this session to authorize it to perform operations within a defined scope. Through these steps, a temporary operation session is generated for each database operation request, allowing fixed high-privilege accounts or long-term operation roles to be replaced with one-time permission contexts, thus reducing the exposure of unused permissions. During the execution of the operation session, the actual SQL statement is parsed to obtain the actual capability profile corresponding to it. This actual capability profile is then compared and verified with the aforementioned capability profile. If the comparison result indicates execution drift, the actual SQL statement is blocked. This effectively blocks execution drift. Finally, when the operation session meets the termination conditions, the temporary permission entity is revoked, thus reducing the risk of permission residue. Attached Figure Description

[0009] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a method for generating permission sessions for database operation and maintenance, provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating a method for generating permission sessions for database operation and maintenance in an application scenario, as provided in the embodiments of this application. Figure 3A schematic diagram illustrating the structure of a database operation and maintenance capability profile provided in an embodiment of this application; Figure 4 A schematic diagram illustrating target permission session binding provided in an embodiment of this application; Figure 5 A schematic diagram illustrating the execution of drift detection as provided in an embodiment of this application; Figure 6 This is a schematic diagram of the internal structure of a permission session generation device for database operation and maintenance, provided in an embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] Database systems typically control access behavior through user, role, object, and system permissions. Taking PostgreSQL as an example, permission objects can include databases, schemas, tables, views, functions, sequences, extensions, system catalogs, and system functions. Different Structured Query Language (SQL) operations may require different permissions. For instance, querying a table requires SELECT permission, executing a function requires EXECUTE permission, modifying a table structure requires ownership of the corresponding object or DDL permission, and terminating a session may require specific system roles or function execution permissions.

[0012] Database maintenance operations differ from ordinary business SQL queries, typically carrying stronger side effects and higher risks. These risks stem not only from the objects accessed but also from the actions themselves, such as locking objects, rewriting tables, generating large amounts of WAL (Write-Ahead Log), affecting replication, modifying global parameters, terminating connections, or changing permissions. Therefore, database maintenance authorization cannot simply determine which objects are accessed; it also needs to identify the database capabilities required for the operation and the scope of its side effects.

[0013] The closest existing technologies include role-based access control, fine-grained database permissions, external policy service authorization, SQL access object identification, and cloud resource least privilege recommendation. These technologies can determine whether access is allowed based on user identity, resources, actions, and policies, or recommend resource permissions required for a specific identity.

[0014] The shortcomings of the aforementioned technologies are that they typically do not generate temporary minimum privilege roles for a specific database maintenance session, nor do they perform abstract syntax tree parsing, system function capability identification, lock level identification, side effect identification, or execution phase splitting for database maintenance SQL execution, nor do they continuously monitor whether the actual SQL deviates from the authorized profile during the maintenance session execution. Therefore, existing technologies struggle to ensure that maintenance operations are executable while converging privileges to the minimum scope required for the current session.

[0015] The drawbacks of existing technology are: 1. Coarse-grained roles lead to excessive permissions: Existing operation and maintenance platforms often pre-define roles such as DBA, read-only, change, and audit. A single role covers a large number of operational capabilities, making it difficult to accurately authorize permissions based on the actual objects and actions of the current operation and maintenance SQL.

[0016] 2. Insufficient object privileges alone: ​​The risks of operational SQL are not only determined by the object, but also by system functions, lock levels, side effects, and scope of impact. For example, `SELECT pg_terminate_backend` is a function call, but its side effect is terminating the session; `REINDEX` is a maintenance action, but it may occupy locks and resources for a long time.

[0017] 3. Inability to handle multi-stage operation and maintenance scripts: Operation and maintenance scripts may contain multiple stages, including detection, pre-check, change, verification, and rollback. Different stages require different permissions. Granting the entire script maximum permissions at once will expand the risk exposure window.

[0018] 4. Lack of execution drift blocking: Even if the script is analyzed during approval, actual execution may still deviate from the original authorized scope due to variable substitution, dynamic SQL, conditional branches, manually added statements, or script version changes. Existing solutions struggle to promptly block statements that exceed the authorized scope.

[0019] 5. Incomplete revocation of permissions: If temporary authorizations are not bound to specific sessions, leases, and timeout periods, they can easily remain after maintenance and operation, creating long-term security risks.

[0020] In practical applications, excessively broad permission scopes can lead to problems such as accidental operations, unauthorized access, and difficulties in auditing. For example, what should only require terminating an abnormal session within a database instance might grant permission to terminate any session; what should only require rebuilding a single index might grant data definition language (DDL) permissions for the entire schema; and what should only allow querying slow SQL views might grant access to business table data. Existing general-purpose identity and permission management solutions typically only authorize based on users, roles, resources, and policies, making it difficult to generate a minimum-privilege session based on the object, system function, lock level, side effects, and actual execution dynamics of the database maintenance SQL to be executed.

[0021] To address the aforementioned issues, this application provides a method for generating permission sessions for database operation and maintenance. The technical solution proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart illustrating a method for generating permission sessions for database operation and maintenance, provided in an embodiment of this application. Figure 1 As shown in the figure, the method for generating permission sessions for database operation and maintenance provided in this application embodiment specifically includes the following steps: Step 101: Receive the database operation and maintenance request, parse the database operation and maintenance request, and generate the operation and maintenance plan corresponding to the database operation and maintenance request.

[0023] In practical applications, database operation and maintenance requests may include operation and maintenance actions to be executed, SQL scripts, or platform-based operation and maintenance work orders.

[0024] In practical applications, database maintenance actions to be executed can be received. These actions include, but are not limited to: (1) querying system views or slow SQL queries; (2) Terminate the specified session; (3) Perform maintenance actions such as cleaning VACUUM, analyzing ANALYZE, and rebuilding index REINDEX; (4) Modify database parameters; (5) Create, delete, or upgrade extensions; (6) Perform table structure changes; (7) Adjust user or role permissions; (8) Execute operation and maintenance scripts that include pre-check, change, verification and rollback phases.

[0025] An SQL script is a text file containing multiple SQL statements.

[0026] In one possible implementation, the database maintenance request includes an SQL script; The step of parsing the database operation and maintenance request and generating the corresponding operation and maintenance plan includes: The SQL script is parsed to generate an abstract syntax tree; Based on the abstract syntax tree, the execution stage and target object of each SQL statement in the SQL script are identified, wherein the execution stage includes at least one of the following: pre-check, execution, verification, and rollback; Extract the script summary, statement number, variable placeholders, and allowed replacement range corresponding to the SQL script.

[0027] In practical applications, SQL scripts can be parsed to generate an Abstract Syntax Tree (AST). Typically, a single SQL statement corresponds to a separate AST. When processing the SQL script mentioned above, the parser can first split the SQL script into multiple independent SQL statements according to statement delimiters (usually semicolons;), and then parse each independent SQL statement separately, generating an AST for each.

[0028] This allows us to identify the execution stage of each SQL statement in the SQL script: Phase = {precheck, execute, verify, rollback} The identification of target objects (such as tables, views, indexes, etc.) is done directly and precisely from specific nodes in the AST. The parser can transform an SQL statement into an AST, where each node corresponds to a component of the SQL statement. Information about the target objects is stored in the specific node attributes representing these objects.

[0029] It can also calculate script summaries, statement numbers, variable placeholders, and allowed replacement ranges, which can be used for subsequent drift detection.

[0030] The script digest mentioned above is a cryptographic hash (e.g., SHA-256) performed on the raw (or normalized) string of the entire SQL script to obtain a unique digital fingerprint, preventing tampering during transmission or storage. Statement numbers are generated during parsing by first dividing the entire script into multiple independent SQL statement text blocks according to statement delimiters (e.g., semicolons;), and then numbering each text block sequentially (1, 2, 3...). Each statement text block is then fed separately into the parser to generate its own AST. Variable placeholders are extracted from the AST and identified in context. When generating the AST, the parser marks constants, identifiers, etc., in the SQL as different nodes. Variable placeholders (e.g., {user_id}, ?, :id) are typically identified as special nodes of parameter or placeholder type in the AST. Traversing the AST locates all these nodes. The names and semantics of placeholders (e.g., representing user ID) may come from script comments, such as variable, user_id. In practical applications, the allowed replacement range can also originate from the structured definition of the platform's work orders, such as explicit definition in the `variables` field of the work order. It's important to note that the allowed replacement range does not come from the Abstract Syntax Tree (AST), but from external constraint declarations. The AST indicates the existence of a variable, but it doesn't reveal what values ​​are allowed for that variable. The allowed range is a security policy that can be explicitly specified by the submitter of the operation request or the approval process. Sources include script comments, such as "allowed range: 1000-2000," and system predefined policies, such as requiring the PID of the terminated session to be the currently active session.

[0031] When the database operation and maintenance request is a platform-based operation and maintenance work order, the information in the platform-based operation and maintenance work order can be parsed to obtain the corresponding SQL statement; then each obtained SQL statement is parsed to generate the corresponding abstract syntax tree, and analysis is performed based on the abstract syntax tree; finally, the two are associated and combined to generate a structured operation and maintenance plan.

[0032] When the database operation request is a maintenance action, action identification and parameter extraction can be performed first. First, the user request is identified as a predefined action type, and the required parameters, such as username, database name, and tablespace path, are extracted. Then, based on pre-defined action-template mapping rules, a standardized SQL template corresponding to the action type is found. The template is a pre-written, security-verified SQL statement framework. Subsequently, the provided parameters are filled into the corresponding placeholders in the template, generating one or more specific, complete, and syntactically correct SQL statements. Each predefined action template is pre-configured with a default, standardized execution phase flow, which can automatically associate the generated specific SQL statements with their respective phases. For example, the SQL statement checking the existence of the target tablespace is associated with the pre-check phase, while the SQL statement performing the expansion operation is associated with the execution phase. Then, the specific SQL statements generated in the previous step are parsed (generating an abstract syntax tree). Finally, the precise semantic information obtained from the parsing (operation object, type) is integrated with the associated execution phase, action parameters, and other metadata to form a complete and structured operation plan. This avoids syntax errors, security vulnerabilities, or non-standard operations that may result from manually writing SQL, and users do not need to memorize complex SQL syntax; they only need to provide business parameters to complete professional operation and maintenance operations.

[0033] In practical applications, regardless of the input format, a machine-understandable operation plan with a complete context can be generated. This operation plan can include SQL statements, execution phases, variables, and target objects.

[0034] Step 102: Based on the operation and maintenance plan, generate a capability profile corresponding to the database operation and maintenance request.

[0035] In one possible implementation, generating the capability profile corresponding to the database operation and maintenance request based on the operation and maintenance plan includes: Based on the operation and maintenance plan, basic information for generating a capability profile is generated, wherein the basic information includes a unique identifier for the capability profile, a script summary calculated based on the operation and maintenance plan, and an effective time window determined according to the database operation and maintenance request. For each SQL statement in the aforementioned operation and maintenance plan, and considering the execution phase of the SQL statement, the following parsing is performed: Based on the abstract syntax tree of the SQL statement, the database object type involved in the operation corresponding to the SQL statement is identified, so as to generate the object permission requirements corresponding to the SQL statement. Based on the syntax type of the SQL statement, identify whether the SQL statement belongs to a predefined system-level operation. If the SQL statement belongs to the system-level operation, determine the system capability item corresponding to the SQL statement. Based on the operation type, database version, object type, and execution options of the SQL statement, infer the lock level, side effects, and scope of impact that may occur when the SQL statement is executed. The object permission requirements, system capability items, lock levels, side effects, and scope of impact obtained from parsing the SQL statements belonging to the same execution phase are merged and aggregated to form a capability sub-profile corresponding to the execution phase. Combine the capability sub-profiles corresponding to all the execution stages to generate the capability profile corresponding to the database operation and maintenance request.

[0036] In practical applications, a capability profile is a structured authorization description generated for a database operation and maintenance request to be executed. It can be used as both a basis for generating target permissions beforehand and a standard for detecting permission drift during execution. A capability profile can be represented as `capability_profile`, and for example, the capability profile mentioned above can include the fields shown in Table 1.

[0037] Table 1. Components of a Capability Profile

[0038] In the capability profile, `object_permission` can be used to generate native database permissions; `system_capability` can be used to generate controlled function permissions or proxy layer policies; `allowed_arguments` is used to restrict function parameters, target sessions, or target parameter names; `lock_level` and `side_effect` are used to verify before execution whether the actual SQL generates locks and side effects that exceed the scope of permissions; and `phase` is used to control the scope of permissions in different phases of a multi-phase script.

[0039] In practical applications, database objects can be identified based on the SQL AST, and then the object permission requirements can be inferred. For example, this may include: object permission object_permission = { database schema table view function sequence Extension system catalog } For example, querying a system view requires read permissions for the corresponding view or catalog; executing a function requires function execution permissions; modifying a table structure requires DDL capabilities for the target table or schema.

[0040] In this way, the AST can be traversed to locate all nodes representing database objects (such as table names, function names, etc.), and their specific types can be determined based on their context. Then, permission mapping can be performed, mapping the required target permissions according to the type of SQL operation. In this way, a structured set of object permissions (object_permission) can be generated, which helps to ensure that authorization is both sufficient (to accomplish the task) and free from unnecessary permissions.

[0041] In practical applications, the database system capabilities and operational capabilities involved in SQL statements can be identified, including but not limited to: Session termination capabilities, such as pg_terminate_backend; Parameter modification capability, such as ALTER SYSTEM or SET specific parameters; Extend management capabilities, such as CREATE EXTENSION and ALTER EXTENSION; Maintain operational capabilities, such as VACUUM, ANALYZE, REINDEX; Access control capabilities, such as GRANT, REVOKE, and ALTER ROLE; Replication or high availability related capabilities, such as reading replication status, modifying replication slots, or subscription configurations.

[0042] In practical applications, we can focus on the privileged operations that directly affect the database engine behavior, cluster topology, or instance stability. To precisely control these capabilities, they can be represented as capability items: capability = (capability_type, target_scope, allowed_arguments, phase).

[0043] Capability types can be used to identify specific action categories, such as TERMINATE_SESSION. The target scope defines the range in which the capability is effective. For example, specifying which database or table it applies to, allowing operations only on instance A and prohibiting operations on instance B. Because SQL is dynamic, allow parameter fields can be used for whitelisting parameters. For example, while pg_terminate_backend is allowed, allowed_arguments are limited to pid IN (123, 456) to prevent termination of other PIDs. The execution phase corresponds to multi-stage operation and maintenance scripts. For example, a dangerous operation like ALTER SYSTEM might only be allowed in the execute phase and not in the precheck phase.

[0044] The steps described above extend the traditional concept of object permissions to a broader range of system and operational capabilities. Traditional database permissions often focus only on whether a user can read or write a specific table, while this application further focuses on whether a user can execute certain high-risk management actions. Through deep analysis of SQL statements, high-risk operations are abstracted into structured capability items to facilitate unified risk assessment and dynamic authorization. This allows for the protection of database data without sacrificing operational efficiency.

[0045] In practical applications, the system infers the potential lock level, side effects, and scope of impact based on the SQL type, database version, object type, and execution options. For example: side effect = { lock level, lock_level Should the table be rewritten (rewrites_table)? WAL log volume generates_wal, Does it terminate the session? Global configuration changes (changes_global_config) Permission changes (changes_privilege) Affects_replication } In the above embodiments, the judgment is not based solely on the SQL statement, but rather on cross-validation using four-dimensional information, including (1) the SQL type, whether it is DDL (e.g., ALTER), DML (e.g., UPDATE) or management command (e.g., VACUUM).

[0046] (2) Database version. Different versions of the database kernel may behave differently (for example, the behavior of some locks differs in different versions).

[0047] (3) Object type: whether the operation is on a large table or a small table, a system table or a regular table.

[0048] (4) Execution options, whether CONCURRENTLY (concurrent execution, low lock level but long execution time) or FULL (complete refactoring, high lock level).

[0049] The identified risks can then be quantified as a set of Boolean or enumerated values.

[0050] During the capability profile generation process, based on the type of SQL statement, the version of the target database, the specific type of the objects being operated on (such as tables and indexes), and the execution options specified in the statement (such as CONCURRENTLY), the potential lock level, side effects, and scope of impact that the statement might generate during execution are statically inferred. This process aims to identify operational risks in advance. For example, operations like ALTER TABLE, REINDEX, and VACUUM FULL typically involve physical data restructuring. The system identifies the lock levels they may hold and whether they rewrite tables. For pg_terminate_backend, the system identifies the range of target sessions that can be terminated; thus, the system can record "only sessions with PID=12345 are allowed to be terminated" through profiling, thereby accurately intercepting unauthorized SQL statements that terminate other sessions at runtime. For ALTER SYSTEM, the system identifies a whitelist of parameters that can be modified.

[0051] In practical applications, the SQL statements in the operation and maintenance plan can also be analyzed one by one and then combined to generate the corresponding capability profile. This application does not impose any specific restrictions.

[0052] Step 103: Based on the capability profile, generate the target permission set corresponding to the database operation and maintenance request, and create and configure a temporary permission entity in the target database based on the target permission set.

[0053] In one possible implementation, generating the target permission set corresponding to the database operation and maintenance request based on the capability profile includes: Based on the capability profile, different types of requirements and constraints in the capability profile are mapped and generated into executable control policies to generate the target permission set corresponding to the database operation and maintenance request. Specifically, mapping and generating executable control strategies from different types of needs and constraints in the capability profile includes at least the following three categories: For the object permission requirements directly expressed by the database native permission model in the capability profile, the object permission requirements are mapped and generated into standard database authorization statements; For system capability items in the capability profile that cannot be expressed by the database's native permission model, they are implemented by creating controlled wrapper functions or configuring proxy layer strategies. For the constraints related to lock level, side effects, and execution phase in the capability profile, the constraints are generated into an executor verification strategy to be validated before the SQL statement is executed, and executed through the proxy layer, platform executor, or database extension hook, so as to block execution when the lock level triggered by the actual operation, the side effects generated, or the execution phase exceeds the authorized scope.

[0054] In practical applications, a target permission set (permission_set) can be generated based on object permission requirements, system capabilities, lock levels, side effect scope, allowed parameters, and execution phase. In practice, when the required scope is minimized, it can also be called the minimum permission set. This permission_set includes not only native database permissions but also proxy layer strategies, controlled function strategies, or executor verification strategies required when native database permissions cannot be directly expressed. For example, the mapping relationship for generating the above target permission set is shown in Table 2.

[0055] Table 2. Generation Mapping Relationship of Target Permission Sets

[0056] For parts that can be expressed using native database permissions, temporary roles and corresponding GRANT statements can be generated. For parts that are difficult to express using native database permissions, controlled function wrappers, proxy layer strategies, or executor strategies can be generated. For example, the native permissions of pg_terminate_backend are often difficult to express as allowing termination of a specified PID. Therefore, a terminate_backend_checked(pid) wrapper function can be generated. This function verifies the session token (session_token), the profile identifier (profile_id), the target database identifier (target_database), allowed_pid, and expire_time before calling the underlying termination capability.

[0057] Thus, the above mappings can be summarized into three categories: the first category is object permissions that can be expressed by native database permissions, generating GRANT / REVOKE; the second category is capabilities that cannot be precisely expressed by native database permissions, generating controlled wrapper functions or proxy layer strategies; among them, the controlled wrapper functions or proxy layer strategies have embedded validation logic for session context, target scope, and allowed parameters; the third category is stage, lock level, and side effect constraints, generating pre-execution validation rules and having out-of-scope SQL blocked by the proxy layer, platform executor, or database hook.

[0058] In practical applications, the aforementioned target permission set is a structured set of policies, whose components may include at least one of the following: standard database authorization statements; definitions of controlled wrapper functions and their calling permissions; policy rule configurations of the proxy layer or platform executor; and dynamic permission switching instructions bound to the execution phase.

[0059] In practical applications, controlled wrapper functions can be implemented in the following ways: create a database function that encapsulates calls to target system functions or high-risk operations; integrate verification code for the security token bound to the current session, capability profile identifier, target database, allowed parameter range, and validity period within the function body of the wrapped function; grant only temporary permission entities permission to execute this wrapped function, without granting them permission to directly call underlying system functions or perform high-risk operations.

[0060] In practical applications, the proxy layer strategy can be implemented in the following way: Deploy a strategy engine in the proxy layer of database communication to intercept SQL requests sent to the database; the strategy engine can be configured to: parse the intercepted SQL statement, extract its operation semantics, target object and parameters, and compare it with the capability profile bound to the current session; if the extracted information exceeds the authorization scope of the capability profile, the strategy engine will block the SQL statement from being sent to the database.

[0061] In practical applications, the executor validation strategy that performs validation before SQL statement execution includes at least one of the following methods: validation is performed by the proxy layer before forwarding the SQL; validation is performed by the platform executor before calling the database interface; or validation is performed within the database before the query plan is generated or executed by registering an extension hook with the database.

[0062] In one possible implementation, the step of creating and configuring temporary permission entities in the target database based on the target permission set includes: Based on the target permission set, a temporary permission entity is created in the target database, wherein the temporary permission entity includes one of the following: a one-time temporary role, a temporary authorization, or a session-level permission token; Based on the target permission set, a session authorization record corresponding to the temporary permission entity is generated, wherein the session authorization record is associated with at least the following information: the identifier of the temporary permission entity, the script summary corresponding to the operation and maintenance plan, the identifier of the capability profile, the identifier of the current operation and maintenance session, the identifier of the target database, the operator identifier, the authorization time, the validity period, and the revocation policy.

[0063] The system creates one-time temporary roles, temporary authorizations, or session-level permission tokens based on the permission_set, and generates a session authorization record (session_grant). For example, session_grant includes at least: temporary role (temp_role), session token (session_token), session ID (session_id), backend process ID (backend_pid), operator ID (operator_id), target database ID (target_database), profile ID (profile_id), script digest (script_digest), permission set (permission_set), allowed phase (allowed_phase), grant time (grant_time), expiration time (expire_time), and revocation policy (revoke_policy).

[0064] In practical applications, an operation and maintenance session with the target database can be established, and the temporary permission entity can be bound to the operation and maintenance session along with the information in the session authorization record. The temporary permission entity can then be activated in the operation and maintenance session to grant the session the corresponding operation permissions.

[0065] Step 104: Establish an operation and maintenance session with the target database and bind the temporary permission entity to the operation and maintenance session to authorize the operation and maintenance session to perform operations within a limited scope.

[0066] In one possible implementation, binding the temporary permission entity to the operation and maintenance session includes: Obtain the database connection identifier of the operation and maintenance session; A verification request is sent to the authorization service so that the authorization service can verify the verification request based on the session authorization record, wherein the verification request carries at least the operator identifier, the script digest, the identifier of the target database, and the current time; If the authorization service passes the verification, execute the permission switching command on the database connection corresponding to the operation and maintenance session to enable the one-time temporary role, or inject and enable the session-level permission token in the context of the operation and maintenance session.

[0067] In practical applications, after establishing a database connection, the operations and maintenance executor obtains the database session identifier (session_id) or backend_pid and requests the authorization service to verify the operator_id, script_digest, target_database, and expire_time. That is, after the database connection is established but before activating temporary permissions, the operations and maintenance executor needs to initiate a security query to an independent, centralized authorization service to confirm whether the current connection has the right to use the temporary permissions previously generated for it. This prevents permission hijacking; even if the name of the temp_role or a fragment of the session_token is leaked, permissions cannot be activated without passing the authorization service's verification (verifying operator_id and script_digest, etc.). Furthermore, the authorization service can decide whether to allow access in real time based on the latest security policies without modifying the temporary roles already created in the database.

[0068] In practical applications, during the execution of an operation and maintenance session, the system verifies whether the connection identifier, the bound token or role identifier, and the capability profile identifier of the current session are consistent with the session authorization record before each SQL statement is executed; if they are inconsistent, the temporary permission entity is immediately invalidated in the current session.

[0069] In practical applications, the script summary, capability profile identifier, session identifier, and validity period associated with the session authorization record can together constitute the usage constraints of the temporary permission entity. When the context information of the actual operation and maintenance session does not match any of the usage constraints, the system will refuse to activate or immediately revoke the activated temporary permission.

[0070] After successful verification, you can execute `SET ROLE temp_role` or inject a `session_token` on the connection to put it into a temporary minimum privilege context. The system verifies the consistency of the current connection's `session_id`, `backend_pid`, `session_token`, and `profile_id` before each SQL statement execution. If the connection is reused, the session is reconnected after being closed, the script digest is changed, or the expiration date is reached, the temporary privileges immediately become invalid.

[0071] The session_id, backend_pid, profile_id, script_digest, and expire_time in session_grant together limit the scope of this temporary permission; if any field does not match, the system will refuse SET ROLE, refuse controlled function calls, or invalidate the session token.

[0072] In practical applications, operations and maintenance personnel, automated tasks, or platform executors establish database sessions through controlled entry points. The system binds temporary roles to these sessions and only allows them to execute statements that match the script summary and capability profile within an authorized time window.

[0073] Step 105: During the execution of the operation and maintenance session, the actual executed Structured Query Language (SQL) statement is parsed to obtain the actual capability profile corresponding to the actual executed SQL statement, and the actual capability profile is compared and verified with the capability profile to obtain the comparison and verification result.

[0074] Step 106: If the comparison and verification result indicates that execution drift has occurred, block the actually executed SQL statement.

[0075] In an authorized operations and maintenance session, each SQL statement about to be executed is parsed by the system in real time, and its corresponding actual capability profile is quickly generated. This actual capability profile can be compared and verified with the authorized capability profile initially granted to the operations and maintenance session. Comparison dimensions can include at least one of the following: operation object, operation type, function parameters, scope of impact, execution stage, etc. If a match is found, it means the actual request falls within the authorized profile and can be allowed to execute. If execution drift occurs, it means the actual request exceeds the authorized scope, such as attempting to operate on an unauthorized table, using unpermitted parameters, or executing in an unauthorized stage; in this case, the execution of the statement needs to be blocked immediately.

[0076] In one possible implementation, comparing and verifying the actual capability profile with the capability profile includes verifying at least one of the following: Does the object accessed by the actually executed SQL statement exceed the scope of the capability profile? Whether the system capability item invoked by the actually executed SQL statement is not permitted in the capability profile; Whether the operation parameters of the actually executed SQL statement exceed the range allowed by the capability profile; Whether the lock level or side effects of the actually executed SQL statement exceed the range allowed by the capability profile; Does the execution stage of the actual executed SQL statement differ from the execution stage in the capability profile?

[0077] In practical applications, it is also possible to verify whether the script summary of the actually executed SQL statement is inconsistent with the script summary in the capability profile.

[0078] During execution, the system performs real-time parsing of the actual SQL statements (hereinafter referred to as actual SQL), generates an actual capability profile, and compares it with the authorized capability profile. For example, execution drift can be determined to have occurred if any of the following conditions are met: The actual SQL query accessed an object outside the authorized profile; The actual SQL query invoked an unauthorized system function; The actual SQL parameters exceeded the allowed range; The actual SQL statement has a higher locking level or side effects than the authorization profile. The actual execution phase of the SQL statement differs from the authorization phase. The actual script digest does not match the authorized script digest.

[0079] In one possible implementation, when execution drift is determined to have occurred, at least one of the following actions can be performed: block the execution of the current SQL statement, terminate the current operation and maintenance session, record the reason for the drift, or trigger an alarm.

[0080] In practical applications, drift detection may include the following steps: obtaining the actual executed SQL statement; re-parsing and generating the actual_profile; reading the capability_profile bound to this operation and maintenance session; comparing the object, operation type, system function, parameter range, lock level, side effects, execution stage, and script summary item by item; if none exceed the authorized profile, then allow execution; if any item exceeds the authorized profile, then block, audit, and trigger permission revocation.

[0081] In practical applications, drift detection can be deployed in one or more of the following technology stack locations: First, the database proxy layer or SQL gateway, which parses, profiles, and compares policies before the SQL reaches the database; Second, the platform executor, which calls the authorization service for verification before executing each statement in the script; Third, database extension hooks, which intercept SQL before parsing, planning, or execution, for example, in a PostgreSQL scenario, they can be deployed in ProcessUtility, ExecutorStart, or related statement execution entry points; Fourth, controlled function wrapper entry points, where the wrapper function uniformly verifies parameters and session tokens for system functions or high-risk actions; Fifth, SQL firewalls or auditing plugins, which block statements that do not conform to the capability profile before execution.

[0082] Step 107: If the operation and maintenance session meets the termination conditions, revoke the temporary permission entity.

[0083] In one possible implementation, the termination condition includes one of the following: The operation and maintenance session ends normally, execution fails, execution drift is triggered and blocking occurs, or the predetermined validity period of the temporary permission entity is reached.

[0084] When an operation and maintenance session ends, fails to execute, drifts, or exceeds the authorization time, the system can automatically revoke temporary authorization, delete temporary roles, or invalidate session-level permission tokens.

[0085] In one possible implementation, after revoking the temporary permission entity when the operation and maintenance session meets the termination conditions, the method includes: Generate audit records corresponding to the operation and maintenance session; The audit log includes at least one of the following: operator identifier, session identifier, script summary, target permission set, actual executed SQL statement, blocked SQL statement, drift reason, authorization time and permission revocation time.

[0086] In practical applications, the generated audit logs shall include at least one of the following: operator_id, session_id, script_digest, permission_set, executed_sql, blocked_sql, drift_reason, grant_time, and revoke_time.

[0087] In practical applications, obtaining audit logs helps achieve a closed loop and continuous evolution of security operations and maintenance. It not only meets compliance requirements but also provides evidence for post-event traceability. Furthermore, by comparing the actual execution information captured in the audit logs with the pre-predicted authorizations in the capability profile, the accuracy of the capability profile can be verified and policy deviations can be identified. This deviation data can be used to continuously optimize the profile generation rules and drift detection model, thereby making the system's permission prediction and real-time control increasingly accurate.

[0088] In this embodiment, database operation requests can be parsed to generate corresponding operation plans. Based on these plans, corresponding capability profiles are then generated. Furthermore, a target permission set can be generated based on the capability profile, and a temporary permission entity can be created and configured in the target database. An operation session with the target database is established, and the temporary permission entity is bound to this session to authorize it to perform operations within a defined scope. Through these steps, a temporary operation session is generated for each database operation request, allowing fixed high-privilege accounts or long-term operation roles to be replaced with one-time permission contexts, thus reducing the exposure of unused permissions. During the execution of the operation session, the actual SQL statement is parsed to obtain the actual capability profile corresponding to it. This actual capability profile is then compared and verified with the aforementioned capability profile. If the comparison result indicates execution drift, the actual SQL statement is blocked. This effectively blocks execution drift. Finally, when the operation session meets the termination conditions, the temporary permission entity is revoked, thus reducing the risk of permission residue.

[0089] To provide a more detailed explanation of the database operation and maintenance session generation method in this application embodiment, the following supplementary description is also provided in this application embodiment: Figure 2 This is a flowchart illustrating the process of generating permission sessions for database operation and maintenance in an application scenario provided by an embodiment of this application. Figure 2 As shown, the database operation and maintenance permission session generation method in this embodiment may further include the following execution process: (1) Receive operation and maintenance actions or structured query language SQL scripts.

[0090] (2) Parsing the abstract syntax tree and the execution phase.

[0091] (3) Identify the permission requirements of the object.

[0092] (4) Identify system capabilities and operation and maintenance capabilities.

[0093] (5) Identify lock levels and side effects.

[0094] (6) Generate the set of minimum permissions.

[0095] (7) Generate a one-time temporary role or authorization.

[0096] (8) Bind the operation and maintenance session.

[0097] (9) Parse the actual SQL during execution.

[0098] (10) Whether it deviates from the authorized portrait.

[0099] If (10) is true, proceed with (11) to block execution and log the process.

[0100] If (10) is not true, proceed to (12) to allow execution to continue.

[0101] (13) Has the session ended?

[0102] If (13) is not true, return (9) to parse the actual SQL.

[0103] If (13) is true, perform (14) to revoke permissions and generate an audit.

[0104] The above process incorporates two SQL parsing nodes: one for parsing the abstract syntax tree (AST) and another for parsing the actual SQL during execution. The pre-parsing stage anticipates permission requirements and risks, while the execution-time parsing performs real-time verification. This ensures that even if an attacker bypasses the pre-parsing stage—for example, by exploiting a specific database dialect to bypass the AST parser—the actual SQL can still be compared to the authorized profile at the moment of execution. Once any unauthorized access or structural tampering is detected, it is immediately intercepted at the database level, achieving zero-trust dynamic defense.

[0105] From generating the minimum set of permissions to creating one-time temporary roles, and then revoking permissions after the session ends, a perfect closed loop is formed. Permissions are not static attributes attached to user accounts, but rather follow the lifecycle of a single task. The validity period of permissions is limited to the specific session lease. Temporary permissions are bound to session_id, backend_pid, script digest, capability profile, and timeout; when the session ends, the task fails, the script deviates, or the timeout occurs, the system automatically revokes the temporary role, temporary authorization, or session token, thereby reducing the risk of permission residue.

[0106] Figure 3 This is a schematic diagram illustrating the structure of a database operation and maintenance capability profile provided in an embodiment of this application. Figure 3This solution demonstrates how to transform the underlying SQL abstract syntax tree (AST) into a top-level security policy language, namely a capability profile. Traditional security auditing often focuses only on the content of the SQL statement, while this solution delves into the syntactic structure level through the SQL AST, breaking down complex SQL statements into different dimensions: object permissions, system function capabilities, maintenance action capabilities, lock levels, side effect scope, and execution phase. This allows for understanding the true intent of the SQL statement. Furthermore, it provides a dynamic basis for generating target permission sets, and during actual SQL execution, the AST can be extracted again and compared with the pre-generated capability profile. If the actual lock level or side effects exceed the limits allowed by the capability profile (e.g., attempting to execute unauthorized DDL), a blocking mechanism can be triggered. This multi-dimensional attribute extraction ensures fine-grained security control for database operations and maintenance.

[0107] Figure 4 This is a schematic diagram illustrating a target permission session binding provided in an embodiment of this application. Figure 4 In this context, the target permission set is the sum of absolute target (e.g., minimum) permissions (including object permissions, system functions, maintenance actions, etc.) required to complete the maintenance task after parsing the database maintenance request. A one-time temporary role is a temporary role created in the target database based on the above target permission set. Before delivering permissions to a session, four strict context bindings are required to ensure that permissions are not abused: (1) Bind the session identifier session_id to strongly associate permissions with the current specific database connection / session ID. (2) Bind the script digest script_digest to associate permissions with the unique hash fingerprint of the maintenance script. (3) Bind the expiration time expire_time to set the automatic expiration time (TTL) of the permissions. (4) Bind the allowed phase allowed_phase to limit the permissions to only be effective in a specific execution phase (e.g., only the execution phase is allowed, and the parsing phase is not allowed).

[0108] After the above encapsulation and binding, the permissions are finally injected into a session protected by strict policies, namely a controlled operation and maintenance session, for the actual operation to be performed.

[0109] Figure 5 This is a schematic diagram illustrating the execution of drift detection as provided in an embodiment of this application, such as... Figure 5 As shown, the drift detection in this embodiment may further include the following execution process: (1) Obtain the actual Structured Query Language (SQL). This refers to the actual SQL statements entered by the operations and maintenance personnel or ultimately issued by the system during the operations and maintenance session.

[0110] (2) Real-time parsing of the abstract syntax tree: The system intercepts the above SQL and performs syntax analysis on it to generate the AST.

[0111] (3) Generate actual capability profile. Based on the parsed AST, the objects to be operated on by the SQL, the required permissions, the lock level and side effects, etc., can be extracted to form an actual capability profile of the same dimension as the pre-authorization capability profile.

[0112] (4) Read the authorization capability profile. Retrieve the authorization profile issued and bound by the authorization service before the SQL is executed.

[0113] (5) Whether the object and the capability match.

[0114] If the actual operation involves tables, columns, functions, etc., within the authorized scope, proceed to the next step (6).

[0115] No indicates an attempt to access an unauthorized object or use an unauthorized function; jump to (9) to block and record the drift.

[0116] (6) Whether the lock level and side effects are beyond the scope.

[0117] This indicates that the lock level generated by the actually executed SQL or its impact on system performance has not exceeded the preset security threshold, and proceed to the next step (7).

[0118] If no, it means that the SQL has generated a high-risk lock or serious side effects, such as an unauthorized full table scan or deadlock risk. Jump to (9) to block and record the drift.

[0119] (7) Whether the stage and script summary match.

[0120] Here, indicates that the current execution stage is correct and the script content has not been tampered with (the script summary is consistent), and jumps to (8) to allow execution.

[0121] If no, it indicates that the script was executed in an unexpected phase or that the script was tampered with by a middleman. Jump to (9) to block and record the drift.

[0122] If all three checks pass, the system will allow the SQL to be executed by the database, i.e., (8) allow execution.

[0123] If any round of verification fails, the system intercepts the request and records a detailed alarm log for subsequent auditing, and executes (9) to block and record the drift.

[0124] In practical applications, authorization profiles are typically generated upon connection establishment, while the actual SQL may not be executed until after a prolonged run. During this time, attackers may attempt to inject malicious SQL or modify the script. This solution addresses this vulnerability by employing triple verification of permissions (objects), risks (locks / side effects), and context (phases / digests) to prevent malicious actions after authorization. Furthermore, the process includes script digest matching, meaning the system doesn't simply compare SQL text but compares the script's fingerprint using a hash algorithm. Even if an attacker adds a harmless comment, the digest verification will fail, preventing bypass attempts. The entire verification process uses a serial verification mechanism; failure at any stage triggers a block. This design ensures high-risk operations are completely intercepted before entering the database kernel, maximizing database security.

[0125] The following two embodiments provide a more detailed explanation of the database operation and maintenance permission session generation method in this application: Example 1: Allow termination of only specified abnormal sessions Implementation scenario: Operations personnel discover an abnormally long transaction session in the database db_prod with a backend_pid of 12345. They need to terminate this session, but terminating other sessions or querying business table data is not allowed.

[0126] The input work order and SQL are: SELECT terminate_backend_checked(12345); or SELECT pg_terminate_backend(12345); The work order includes operator_id, target_database=db_prod, allowed_pid=12345, expire_time=10 minutes.

[0127] After parsing the SQL, the system generates a capability profile: object_permission includes reading necessary fields such as pid, username, dataname, and state from pg_stat_activity; system_capability is terminate_session; target_scope is database=db_prod and pid=12345; allowed_arguments requires pid to be equal to 12345 or belong to the approved pid set; side_effect is terminates_session; phase is execute; valid_window is 10 minutes after authorization.

[0128] The system does not directly grant temporary roles the ability to terminate sessions arbitrarily. Instead, it grants them permission to execute `terminate_backend_checked(integer)`. This controlled function verifies the `session_token`, `profile_id`, `target_database`, `allowed_pid`, and `expire_time` before execution. Only if the `pid` matches the capability profile will the underlying session termination capability be invoked.

[0129] If the actual SQL is SELECT terminate_backend_checked(12345), the system allows execution; if the actual SQL becomes SELECT terminate_backend_checked(67890), the system blocks the statement because the parameter exceeds the authorized PID range, records drift_reason=argument_out_of_scope, and revokes temporary privileges.

[0130] Example 2: Staged execution of index reconstruction script Implementation Scenario: The operation and maintenance script comprises four phases: pre-check, execution, verification, and rollback, used to rebuild the public.idx_order_create_time index. The pre-check phase only allows queries on the system catalog and the target index status; the execution phase only allows REINDEX of the specified index; the verification phase only allows queries on index validity and slow SQL views; and the rollback phase only allows the execution of predefined rollback SQL statements.

[0131] After parsing the script, the system generates phase profiles for each stage. `precheck_profile` only includes read permissions for system catalogs such as `pg_class` and `pg_index`; `execute_profile` includes the ability to perform maintenance actions on `REINDEX INDEXpublic.idx_order_create_time`, the target index range, the estimated lock level, and `side_effect=may_generate_wal`; `verify_profile` only includes permissions to read the target index status and execution plan; `rollback_profile` includes the object range and operation type of predefined rollback statements.

[0132] During the precheck phase, temporary roles do not have REINDEX capabilities; the system only enables REINDEX to specify an index when the phase switches to execute and the script digest remains unchanged. If REINDEX is actually executed during the precheck phase, the system blocks it based on phase_mismatch; if the target index is changed to public.idx_user_name during the execute phase, it blocks it based on object_out_of_scope; if REINDEX INDEX is changed to REINDEX DATABASE, it blocks it based on target_scope or side effects exceeding the profile.

[0133] In addition, this application embodiment also provides a permission session generation device for database operation and maintenance, the structure of which is as follows: Figure 6 As shown.

[0134] Figure 6 This is a schematic diagram of the internal structure of a permission session generation device for database operation and maintenance, provided as an embodiment of this application. Figure 6 As shown, the device includes: At least one processor 601; And a memory 602 that is communicatively connected to at least one processor; The memory 602 stores instructions that can be executed by at least one processor. The instructions are executed by at least one processor 601 to enable at least one processor 601 to: execute the permission session generation method for the above-mentioned database operation and maintenance.

[0135] In one possible implementation, the processor is capable of receiving database operation and maintenance (O&M) requests, parsing the requests, generating an O&M plan corresponding to the requests, generating a capability profile based on the O&M plan, generating a target permission set corresponding to the O&M requests based on the capability profile, creating and configuring a temporary permission entity in the target database based on the target permission set, establishing an O&M session with the target database, and binding the temporary permission entity to the O&M session to authorize the O&M session to perform operations within a defined scope, parsing the actual executed Structured Query Language (SQL) statements during the O&M session execution to obtain the actual capability profile corresponding to the executed SQL statements, comparing and verifying the actual capability profile with the capability profile to obtain a comparison and verification result, blocking the executed SQL statements if the comparison and verification result indicates execution drift, and revoking the temporary permission entity if the O&M session meets the termination conditions.

[0136] Some embodiments of this application provide corresponding to Figure 1 A non-volatile computer storage medium stores computer-executable instructions, which are configured as: a permission session generation method for performing the aforementioned database operation and maintenance.

[0137] In one possible implementation, the computer-executable instructions are configured to receive a database operation and maintenance request, parse the request, and generate an operation and maintenance plan corresponding to the request. Based on the operation and maintenance plan, a capability profile corresponding to the request is generated. According to the capability profile, a target permission set corresponding to the request is generated, and a temporary permission entity is created and configured in the target database based on the permission set. An operation and maintenance session with the target database is established, and the temporary permission entity is bound to the session to authorize it to perform operations within a defined scope. During the execution of the session, the actual executed Structured Query Language (SQL) statement is parsed to obtain the actual capability profile corresponding to the SQL statement. The actual capability profile is compared and verified with the capability profile to obtain a verification result. If the verification result indicates execution drift, the SQL statement is blocked. If the session meets the termination conditions, the temporary permission entity is revoked.

[0138] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0139] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0142] 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.

[0143] 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.

[0144] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0145] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0146] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0148] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating permission sessions for database operation and maintenance, characterized in that, The method includes: Receive database operation and maintenance request, parse the database operation and maintenance request, and generate an operation and maintenance plan corresponding to the database operation and maintenance request; Based on the operation and maintenance plan, a capability profile corresponding to the database operation and maintenance request is generated; Based on the capability profile, a target permission set corresponding to the database operation and maintenance request is generated, and a temporary permission entity is created and configured in the target database based on the target permission set. Establish an operation and maintenance session with the target database, and bind the temporary permission entity to the operation and maintenance session to authorize the operation and maintenance session to perform operations within a limited scope; During the execution of the operation and maintenance session, the actual executed Structured Query Language (SQL) statement is parsed to obtain the actual capability profile corresponding to the actual executed SQL statement, and the actual capability profile is compared and verified with the capability profile to obtain the comparison and verification result. If the comparison and verification results indicate that execution drift has occurred, the actually executed SQL statement will be blocked. If the operation and maintenance session meets the termination conditions, the temporary permission entity is revoked.

2. The method according to claim 1, characterized in that, The database maintenance request includes an SQL script; The step of parsing the database operation and maintenance request and generating the corresponding operation and maintenance plan includes: The SQL script is parsed to generate an abstract syntax tree; Based on the abstract syntax tree, the execution stage and target object of each SQL statement in the SQL script are identified, wherein the execution stage includes at least one of the following: pre-check, execution, verification, and rollback; Extract the script summary, statement number, variable placeholders, and allowed replacement range corresponding to the SQL script.

3. The method according to claim 2, characterized in that, The step of generating a capability profile corresponding to the database operation and maintenance request based on the operation and maintenance plan includes: Based on the operation and maintenance plan, basic information for generating a capability profile is generated, wherein the basic information includes the identifier of the capability profile, a script summary calculated based on the operation and maintenance plan, and an effective time window determined according to the database operation and maintenance request; For each SQL statement in the operation and maintenance plan, and considering the execution stage of the SQL statement, the following parsing is performed: Based on the abstract syntax tree of the SQL statement, the database object type involved in the operation corresponding to the SQL statement is identified, so as to generate the object permission requirements corresponding to the SQL statement. Based on the syntax type of the SQL statement, identify whether the SQL statement belongs to a predefined system-level operation. If the SQL statement belongs to the system-level operation, determine the system capability item corresponding to the SQL statement. Based on the operation type, database version, object type, and execution options of the SQL statement, infer the lock level, side effects, and scope of impact that may occur when the SQL statement is executed. The object permission requirements, system capability items, lock levels, side effects, and scope of impact obtained from parsing the SQL statements belonging to the same execution phase are merged and aggregated to form a capability sub-profile corresponding to the execution phase. Combine the capability sub-profiles corresponding to all the execution stages to generate the capability profile corresponding to the database operation and maintenance request.

4. The method according to claim 3, characterized in that, The step of generating the target permission set corresponding to the database operation and maintenance request based on the capability profile includes: Based on the capability profile, different types of requirements and constraints in the capability profile are mapped and generated into executable control policies to generate the target permission set corresponding to the database operation and maintenance request. Specifically, mapping and generating executable control strategies from different types of needs and constraints in the capability profile includes at least the following three categories: For the object permission requirements directly expressed by the database native permission model in the capability profile, the object permission requirements are mapped and generated into standard database authorization statements; For system capability items in the capability profile that cannot be expressed by the database's native permission model, they are implemented by creating controlled wrapper functions or configuring proxy layer strategies. For the constraints related to lock level, side effects, and execution phase in the capability profile, the constraints are generated into an executor verification strategy to be validated before the SQL statement is executed, and executed through the proxy layer, platform executor, or database extension hook, so as to block execution when the lock level triggered by the actual operation, the side effects generated, or the execution phase exceeds the authorized scope.

5. The method according to claim 1, characterized in that, The step of creating and configuring temporary permission entities in the target database based on the target permission set includes: Based on the target permission set, a temporary permission entity is created in the target database, wherein the temporary permission entity includes one of the following: a one-time temporary role, a temporary authorization, or a session-level permission token; Based on the target permission set, a session authorization record corresponding to the temporary permission entity is generated, wherein the session authorization record is associated with at least the following information: the identifier of the temporary permission entity, the script summary corresponding to the operation and maintenance plan, the identifier of the capability profile, the identifier of the current operation and maintenance session, the identifier of the target database, the operator identifier, the authorization time, the validity period, and the revocation policy.

6. The method according to claim 5, characterized in that, The step of binding the temporary permission entity to the operation and maintenance session includes: Obtain the database connection identifier of the operation and maintenance session; A verification request is sent to the authorization service so that the authorization service can verify the verification request based on the session authorization record, wherein the verification request carries at least the operator identifier, the script digest, the identifier of the target database, and the current time; If the authorization service passes the verification, execute the permission switching command on the database connection corresponding to the operation and maintenance session to enable the one-time temporary role, or inject and enable the session-level permission token in the context of the operation and maintenance session.

7. The method according to claim 3, characterized in that, The comparison and verification between the actual capability profile and the capability profile includes verifying at least one of the following: Does the object accessed by the actually executed SQL statement exceed the scope of the capability profile? Whether the system capability item invoked by the actually executed SQL statement is not permitted in the capability profile; Whether the operation parameters of the actually executed SQL statement exceed the range allowed by the capability profile; Whether the lock level or side effects of the actually executed SQL statement exceed the range allowed by the capability profile; Does the execution stage of the actual executed SQL statement differ from the execution stage in the capability profile? 8. The method according to claim 1, characterized in that, After revoking the temporary permission entity when the operation and maintenance session meets the termination conditions, the method further includes: Generate audit records corresponding to the operation and maintenance session; The audit log includes at least one of the following: operator identifier, session identifier, script summary, target permission set, actual executed SQL statement, blocked SQL statement, drift reason, authorization time and permission revocation time.

9. A permission session generation device for database operation and maintenance, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a permission session generation method for database operation and maintenance as described in any one of claims 1-8.

10. A computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instruction is executed, it implements a permission session generation method for database operation and maintenance as described in any one of claims 1-8.

Images