Data authority control method and device, electronic equipment and storage medium
By analyzing and verifying the Flink SQL statements in real-time tasks, the problem of low personalization of permission allocation in the real-time development platform is solved, and more fine-grained data permission control is achieved, which improves the security and reliability of data processing.
Patent Information
- Application Number
- CN202411539275.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-31
- Publication Date
- 2025-02-07
AI Technical Summary
In real-time development platforms, the existing technology cannot allocate different data permissions for different users, resulting in low personalization of permission allocation and complex allocation methods.
By analyzing the Flink SQL statement corresponding to the real-time task, obtaining the user's information, and verifying the user's data permissions based on the parsing results, ensuring that the Flink SQL statement is executed only if the permission verification is passed.
It realizes application scenarios that allocate different data permissions to users and meet more data permissions, reduces the possibility of users misoperating data, and improves the security and reliability of data processing.
Smart Images
Figure CN119397577A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of data processing technology, and in particular relates to a data permission control method, device, electronic device and storage medium. Background Art
[0002] In real-time development platforms, related technologies can only rely on the data permissions of the underlying data sources and cannot assign different data permissions to different users. There are problems such as low personalization of permission allocation and complex allocation methods. Summary of the Invention
[0003] The present application proposes a data authority control method, device, electronic device and storage medium to solve the problems of low personalization of authority allocation and complex allocation methods existing in related technologies.
[0004] In a first aspect, the present application provides a data permission control method, the method comprising:
[0005] Receive a first input, where the first input is an operation of creating and submitting a real-time task;
[0006] In response to the first input, parse the Flink SQL statement corresponding to the real-time task to obtain a first parsing result;
[0007] Acquire information of an operating user corresponding to the real-time task, and verify data permissions of the operating user according to the first parsing result;
[0008] If the data permission verification of the operating user passes, the Flink SQL statement is executed.
[0009] The data permission control method provided in the embodiment of the present application parses the Flink SQL statement corresponding to the real-time task to obtain a first parsing result, obtains information of the operating user corresponding to the real-time task, verifies the data permissions of the operating user based on the first parsing result, and executes the Flink SQL statement if the data permissions of the operating user pass the verification. This realizes the allocation of different data permissions to users, can meet more data permission application scenarios, reduce the possibility of user error in data operation, and improve the security and reliability of data processing.
[0010] According to one embodiment of the present application, parsing the Flink SQL statement corresponding to the real-time task includes:
[0011] Call the Flink SQL parser to parse the Flink SQL statement corresponding to the real-time task and obtain an execution plan;
[0012] Obtaining table structure modification statements or data manipulation statements in the execution plan;
[0013] Obtain the operation object and operation content corresponding to the table structure modification statement, or obtain the table name and query execution plan in the operation data type statement, and loop to obtain the sub-plans of the query execution plan until the operation object and operation content of the bottom-level sub-plan are obtained.
[0014] In the above technical solution, the Flink SQL parser is called to parse the Flink SQL statements corresponding to the real-time task to obtain the execution plan. The table structure modification statements or data operation statements in the execution plan are obtained. Different permission verification methods are used for different statements. This can meet more data permission control scenarios and improve data security and reliability.
[0015] According to one embodiment of the present application, verifying the data authority of the operating user according to the first parsing result includes:
[0016] Get the stored authorization information;
[0017] Determining, based on the operation object and operation content, and the authorization information, whether the operation user has the authority to perform the operation corresponding to the operation content on the operation object;
[0018] If the operating user has the authority, the data authority verification of the operating user passes.
[0019] In the above technical solution, by obtaining the stored authorization information, it is determined whether the operating user has the authority to perform the operation corresponding to the operation content on the operation object according to the operation object and operation content, as well as the authorization information. If the operating user has the authority, it is determined that the data permission verification of the operating user has passed, thereby allocating different data permissions to users, meeting more data permission application scenarios, reducing the possibility of users misoperating data, and improving the security and reliability of data processing.
[0020] According to one embodiment of the present application, the operation objects include libraries, tables, and fields.
[0021] In the above technical solution, when verifying the data permissions of the operating user, the operation objects include libraries, tables, and fields, which realizes the level permission control of libraries, tables, and fields. Different levels of permission control can be selected according to the actual scenario, meeting more data permission control scenarios, reducing the possibility of users misoperating data, and improving the security and reliability of data processing.
[0022] According to one embodiment of the present application, the method further includes:
[0023] If the data permission verification of the operating user fails, an error message is output and the Flink SQL statement is not executed.
[0024] In the above technical solution, if the data permission verification of the operating user fails, an error message is output and the Flink SQL statement is not executed. This can reduce the possibility of user error in operating data and improve the security and reliability of data processing.
[0025] According to one embodiment of the present application, the method further includes:
[0026] Receive a second input, where the second input is an operation to create and submit a Flink SQL permission statement;
[0027] In response to the second input, parse the Flink SQL permission statement to obtain a second parsing result;
[0028] According to the second parsing result, a permission processing operation is performed.
[0029] In the above technical solution, by receiving the second input and parsing to obtain the second parsing result, and performing the permission processing operation according to the second parsing result, different data permissions are assigned to users, which can meet more data permission application scenarios.
[0030] According to an embodiment of the present application, the second parsing result includes the authorized user, the authorized operation object, and the authorized operation content;
[0031] The performing of the permission processing operation according to the second parsing result includes:
[0032] When the Flink SQL permission statement is a permission assignment statement, the permission user, permission operation object, and permission operation content are stored as authorization information;
[0033] If the Flink SQL permission statement is a permission revocation statement, the permission user, permission operation object, and permission operation content are deleted.
[0034] In the above technical solution, permission processing operations are performed based on the permission users, permission operation objects and permission operation contents. The permission users, permission operation objects and permission operation contents can be stored or deleted as empowerment information, thereby realizing the storage or deletion of user permissions, reducing the possibility of users misoperating data, and improving the security and reliability of data processing.
[0035] In a second aspect, the present application provides a data authority control device, which includes:
[0036] A receiving unit, configured to receive a first input, where the first input is an operation of creating and submitting a real-time task;
[0037] a parsing unit, configured to parse a Flink SQL statement corresponding to the real-time task in response to the first input, and obtain a first parsing result;
[0038] a permission verification unit, configured to obtain information of an operating user corresponding to the real-time task, and verify data permissions of the operating user according to the first parsing result;
[0039] The execution unit is configured to execute the FlinkSQL statement if the data permission verification of the operation user passes.
[0040] In the above technical solution, the Flink SQL statement corresponding to the real-time task is parsed to obtain a first parsing result, and the information of the operating user corresponding to the real-time task is obtained. The data permissions of the operating user are verified based on the first parsing result. If the data permissions of the operating user pass the verification, the Flink SQL statement is executed. This realizes the allocation of different data permissions to users, can meet more data permission application scenarios, reduce the possibility of user error in data operation, and improve the security and reliability of data processing.
[0041] In a third aspect, the present application provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the data permission control method as described in the first aspect above is implemented.
[0042] In a fourth aspect, the present application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data permission control method as described in the first aspect above.
[0043] In a fifth aspect, the present application provides a chip, which includes a processor and a communication interface, the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the data permission control method as described in the first aspect.
[0044] In a sixth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements the data permission control method as described in the first aspect above.
[0045] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become obvious from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:
[0047] Figure 1 This is one of the flow charts of the data authority control method provided in some embodiments of the present application;
[0048] Figure 2 This is the second flow chart of the data authority control method provided in some embodiments of the present application;
[0049] Figure 3 This is a flowchart of a Flink SQL parsing method provided in some embodiments of the present application;
[0050] Figure 4 This is one of the flowcharts of the permission processing method provided in some embodiments of the present application;
[0051] Figure 5 This is the second flowchart of the permission processing method provided in some embodiments of the present application;
[0052] Figure 6 This is a schematic diagram of the structure of a data authority control device provided in some embodiments of the present application;
[0053] Figure 7 This is a schematic diagram of the structure of an electronic device provided in some embodiments of the present application. DETAILED DESCRIPTION
[0054] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field are within the scope of protection of this application.
[0055] The terms "first," "second," and the like in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this application can be implemented in an order other than that illustrated or described herein, and that the objects distinguished by "first," "second," and the like are generally of the same type, and do not limit the number of objects; for example, the first object can be one or more. In addition, the term "and / or" in the specification and claims refers to at least one of the connected objects, and the character " / " generally indicates that the objects connected are in an "or" relationship.
[0056] References to "embodiments" in this application mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described in this application may be combined with other embodiments.
[0057] A real-time development platform is an environment designed specifically for building, deploying, and managing real-time applications. It is suitable for application scenarios that require immediate feedback. Such platforms can quickly respond to data changes, provide stream data processing capabilities, support the processing and analysis of continuous data streams, and capture and process events in real time.
[0058] Real-time development platforms typically utilize an event-driven architecture and offer robust integration capabilities, enabling seamless integration with other systems and services, facilitating interaction between data sources and applications. They support access to a variety of data sources, enabling them to handle large-scale data processing needs and improving processing capabilities through horizontal scalability. They also offer real-time monitoring and visualization capabilities, streamlining the development process and providing scalability to handle high concurrency demands.
[0059] Among real-time development platforms, Apache Flink is an open-source distributed stream processing framework focused on high-throughput and low-latency data stream processing. Flink supports integrated real-time and batch processing, features fault tolerance and state recovery capabilities, and is capable of horizontal scalability across clusters. It offers a rich API, supports multiple programming languages, and seamlessly integrates with a variety of data sources and storage systems, making it suitable for scenarios such as real-time data analytics, machine learning, and event-driven applications.
[0060] In real-time development platforms, it's currently impossible to assign different data permissions (including table / field deletion, creation, writing, and querying) to different users. This relies solely on data permission management within the underlying data sources, such as HDFS (Hadoop Distributed File System) and JDBC (Java Database Connectivity). However, some underlying data sources don't support comprehensive data permission management. For example, HDFS provides file system-level permission control, which is relatively coarse and only supports read and write permissions. Granting table creation permissions to a library requires write permissions to the library folder, which also includes permissions to delete, read, and write tables. This relatively coarse granularity leads to limited personalization and complex allocation methods.
[0061] In order to solve the above problems, the embodiments of the present application provide a data permission control method. The data permission control method, device, electronic device, and storage medium provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings through specific embodiments and their application scenarios.
[0062] The data permission control method provided in the embodiments of the present application may be executed by an electronic device or a functional module or functional entity in the electronic device that can implement the data permission control method. The electronic devices mentioned in the embodiments of the present application include but are not limited to computers that can run a real-time development platform, a background server of the real-time development platform, etc. The data permission control method provided in the embodiments of the present application is described below using the background server of the real-time development platform (hereinafter referred to as the real-time development platform background) as an example of the execution subject.
[0063] Figure 1 This is one of the flow charts of the data authority control method provided in some embodiments of the present application, such as Figure 1 As shown, the data authority control method includes: step 110, step 120, step 130 and step 140.
[0064] Step 110: Receive a first input, where the first input is an operation of creating and submitting a real-time task;
[0065] It's easy to understand that the user executes the first input on the real-time development platform, an environment that supports real-time data processing and application development. The first input is the operation of creating and submitting a real-time task. A real-time task is a Flink SQL statement filled in by the user based on business logic. The real-time development platform backend receives the user's first input.
[0066] Optionally, the first input may be an operation on table A. For example, the first input is create / drop / altertableA, which indicates creating table A / deleting table A / modifying table A.
[0067] Optionally, the first input may be an operation for processing data in table A. For example, the first input is select / update / delete / insert tableA, which means querying data from table A / updating data in table A / deleting data in table A / inserting data into table A.
[0068] Step 120: In response to the first input, parse the Flink SQL statement corresponding to the real-time task to obtain a first parsing result;
[0069] Furthermore, the real-time development platform backend responds to the user's first input and parses the Flink SQL statement corresponding to the real-time task created in the first input. Flink SQL is a unified SQL language provided by Apache Flink. It allows users to declaratively define data processing tasks in a SQL-like manner without having to delve into the underlying stream processing logic.
[0070] It should be noted that Flink SQL is mainly used to process two types of data:
[0071] 1. Tabular Data (Table API): Flink SQL provides a SQL-like syntax for operating data sets (i.e., tables), including operations such as creating tables, inserting data, querying, joining, grouping, and aggregation, allowing traditional SQL queries to be directly applied to streaming data.
[0072] 2. Streaming data (DataStream API): Through Flink SQL, users can use SQL to perform real-time stream queries, such as window functions and time sliding functions, to achieve complex real-time analysis.
[0073] It's easy to understand that by parsing the Flink SQL statement corresponding to the real-time task, the first parsing result is obtained. The first parsing result includes the operation object and operation content. The operation object refers to the operation entity corresponding to the real-time task, which can include the operated table and operation fields. The operation content specifies the specific operation type or content, including delete, update, write, query, etc.
[0074] For example, the Flink SQL statement is delete id from tableA. The real-time development platform background parses the Flink SQL statement and obtains a first parsing result, in which the operated table is table A, the operation field is id, and the operation content is delete.
[0075] Step 130: Obtain information of the operating user corresponding to the real-time task, and verify the data authority of the operating user according to the first analysis result;
[0076] Furthermore, the real-time development platform backend obtains information about the operating user corresponding to the real-time task through a query. For example, if the Flink SQL statement is "delete id from tableA," the real-time development platform can obtain information that the operating user is user A, indicating that all data in the id column of table A is being deleted. Based on the first parsing result, the real-time development platform backend verifies the operating user's data permissions.
[0077] It is easy to understand that data permission control is a mechanism for managing and restricting the rights of users or systems to access data. It is used to protect sensitive data and ensure that only authorized users can access, modify or delete specific data.
[0078] Optionally, data permission control assigns permissions based on user roles, supports fine-grained control (by row, column, or field), and has audit functions to meet compliance requirements. Data permission control is widely used in scenarios such as enterprise data management, legal compliance, and cloud services to ensure data security and compliance.
[0079] It should be noted that data permission verification includes the verification of permission operation objects and permission operation contents. The permission operation objects represent entities that require permission control, including libraries, tables, fields, etc., and the permission operation contents represent the specific type or content of the operation, including deletion, update, write, query, etc.
[0080] Step 140: If the data permission verification of the operating user passes, execute the Flink SQL statement.
[0081] Furthermore, the real-time development platform backend queries the data permissions of the operating user based on the stored authorization information. If the operating user's data permissions are verified, the Flink SQL statement is executed and the real-time task starts running. The real-time development platform backend monitors the running status of the real-time task and outputs an alarm message when an abnormal situation occurs.
[0082] It should be noted that the real-time development platform backend queries the data permissions of the operating user based on the stored authorization information. If the data permissions of the operating user fail to be verified, an error message is output and the real-time task is terminated.
[0083] Figure 2 This is the second flow chart of the data authority control method provided by some embodiments of the present application, such as Figure 2 As shown, the data authority control method includes: step 210, step 220, step 230, step 240, step 250 and step 260.
[0084] Step 210: The user fills in Flink SQL as the first input;
[0085] For example, the first input is SELECT id,name FROM TABLE_A, which means querying all data in the id and name columns of the TABLE_A table.
[0086] Step 220: The user clicks "Submit Task" and the real-time development platform receives the user's first input.
[0087] It is easy to understand that when the user clicks Submit Task, the real-time development platform receives the user's first input and submits FlinkSQL to the real-time development platform backend for execution.
[0088] Step 230: The real-time development platform background parses Flink SQL;
[0089] Furthermore, the real-time development platform backend parses the Flink SQL statement to obtain the corresponding operated table, operation fields, and operation content. For example, in step 210, the first input is parsed as follows: operated table: TABLE_A, operation fields: id, name, and operation content: SELECT. The real-time development platform backend detects that the current operating user is UserA.
[0090] Step 240: The real-time development platform backend queries the operating user's authority to determine whether the operating user has the corresponding authority;
[0091] Step 250: If the user has the corresponding permission, execute Flink SQL.
[0092] Step 260: If the operating user does not have the corresponding permission, Flink SQL is not executed and an error is reported and the process is terminated.
[0093] The data permission control method provided in the embodiment of the present application parses the Flink SQL statement corresponding to the real-time task to obtain a first parsing result, obtains information of the operating user corresponding to the real-time task, verifies the data permissions of the operating user based on the first parsing result, and executes the Flink SQL statement if the data permissions of the operating user pass the verification. This realizes the allocation of different data permissions to users, can meet more data permission application scenarios, reduce the possibility of user error in data operation, and improve the security and reliability of data processing.
[0094] In one embodiment of the present application, parsing the Flink SQL statement corresponding to the real-time task includes:
[0095] Call the Flink SQL parser to parse the Flink SQL statement corresponding to the real-time task and obtain an execution plan;
[0096] Obtaining table structure modification statements or data manipulation statements in the execution plan;
[0097] Obtain the operation object and operation content corresponding to the table structure modification statement, or obtain the table name and query execution plan in the operation data type statement, and loop to obtain the sub-plans of the query execution plan until the operation object and operation content of the bottom-level sub-plan are obtained.
[0098] Figure 3 This is a flowchart of a Flink SQL parsing method provided by some embodiments of the present application, such as Figure 3 As shown, the method includes step 310 , step 320 , step 330 , step 340 , step 350 , step 360 , step 360 , step 370 and step 380 .
[0099] Step 310: Parse the Flink SQL statement corresponding to the real-time task;
[0100] Step 320: Call the Flink SQL parser to parse the Flink SQL statement corresponding to the real-time task and obtain an execution plan.
[0101] It's easy to understand that in Apache Flink, an execution plan is the detailed steps and strategy for how the system processes and executes SQL queries. An execution plan converts user-written SQL into a series of operations that can be executed by Flink. The execution plan generation process typically includes the following stages:
[0102] Parsing: Parse the input SQL statement into a logical representation and check for syntax and basic semantic errors.
[0103] Logical Optimization: Optimizes the logical plan, for example, by rewriting the query, inferring predicates, and other methods to improve query efficiency, but does not change the query results.
[0104] Physical Planning: Converts the optimized logical plan into a specific physical execution plan and selects an appropriate execution strategy (such as using different join algorithms).
[0105] Code Generation: Generates executable code based on the physical plan, such as compiling Java code into JVM bytecode for efficient execution.
[0106] Execution: Flink executes tasks in parallel on the cluster according to the generated execution plan and processes the actual data stream.
[0107] Step 330: Determine whether it is a DDL statement or a DML statement based on the execution plan;
[0108] It should be noted that DDL statements (Data Definition Language) are table structure modification statements used to define and manage objects in the database, such as tables, indexes, views, etc.
[0109] Common DDL statements are as follows:
[0110] CREATE: Creates a new database object (such as a table, view, etc.). For example, create table1 means creating table1.
[0111] ALTER: Modifies the structure of an existing database object.
[0112] DROP: Deletes a database object. For example, "drop table1" means deleting table1.
[0113] TRUNCATE: Clears the data in a table (but retains the table structure). For example, truncate table1 means clearing the data in table1.
[0114] DML statements (Data Manipulation Language) are data manipulation statements used to manipulate data in a database, including querying, inserting, updating, and deleting data.
[0115] Common DML statements are as follows:
[0116] SELECT: Query data. For example, select id from table1 means querying all data in the id column of table1.
[0117] INSERT: insert new data, insert into table1 id, means inserting the data of id column into table1.
[0118] UPDATE: Update existing data. update table1 means updating the existing data in table1.
[0119] DELETE: Delete data. For example, delete id from table1 means deleting all data in the id column of table1.
[0120] It is easy to understand that since DDL statements and DML statements use different keywords, the real-time development platform backend can determine whether the execution plan is a DDL statement or a DML statement by keywords. By checking the keywords used in the statement, if it contains CREATE, ALTER, DROP, etc., it is a DDL statement; if it contains SELECT, INSERT, UPDATE, DELETE, etc., it is a DML statement.
[0121] Step 340: If it is a DDL statement, obtain the operation object and operation content in the DDL statement;
[0122] Furthermore, if it is a DDL statement, obtain the operation object (such as table name) and operation content corresponding to the table structure modification statement.
[0123] Step 350: Perform permission check on the DDL statement;
[0124] For example, the DDL statement is create table1. The real-time development platform parses the DDL statement in the background and obtains a first parsing result in which the operated table is table1, the operation content is create, and the operating user is user1.
[0125] Furthermore, the real-time development platform backend queries whether user1 has the create permission for table1 based on the stored authorization information. If so, the DDL statement is executed; if not, an error message is output and the execution of the DDL statement is terminated.
[0126] Step 360: If it is a DML statement, obtain the written table name and query execution plan;
[0127] Furthermore, if it is a DML statement, obtain the table name and query execution plan in the data operation statement. The query execution plan is the execution plan that does not contain the table name and is the operation content on the table. For example, the DML statement is insert into a select * from (select a from c) v, where a is the table name and select * from (select a from c) v is the query execution plan.
[0128] Step 370: Continue searching for the query execution plan and querying the sub-plans until the table name of the bottom-level sub-plan is obtained.
[0129] It should be noted that if it is a DML statement, the real-time development platform backend will cyclically obtain the sub-plans of the query execution plan until the operation object and operation content of the bottom-level sub-plan are obtained. The sub-plan is the execution plan nested in the query plan. Taking the DML statement in step 360 as an example, the bottom-level sub-plan is z(select a from c)v, and the operation object is table c.
[0130] Step 380: Perform permission check on the DML statement.
[0131] For example, the DML statement is insert into a select*from(select a from c)v. The real-time development platform backend continuously queries the execution plan and obtains the bottom-level sub-plan as (select a from c)v. It parses the bottom-level sub-plan statement and obtains that the operated table corresponding to the first parsing result is c, the operation content is select, the operation field is a, and the operating user is user2. The real-time development platform backend queries whether user2 has the select permission for field a of table c based on the stored authorization information. If not, it outputs an error message and terminates the execution of the DML statement.
[0132] If user user2 has the select permission on table c, the real-time development platform background parses the write table of the DML statement and obtains the result that the corresponding operated table is a, the operation content is insert, the operation fields are all fields of table a, and the operating user is user2. The real-time development platform background checks whether user user2 has the insert permission on table a based on the stored authorization information. If so, the DML statement is executed. If not, an error message is output and the execution of the DML statement is terminated.
[0133] In the above technical solution, the Flink SQL parser is called to parse the Flink SQL statements corresponding to the real-time task to obtain the execution plan. The table structure modification statements or data operation statements in the execution plan are obtained. Different permission verification methods are used for different statements. This can meet more data permission control scenarios and improve data security and reliability.
[0134] In one embodiment of the present application, verifying the data authority of the operating user according to the first parsing result includes:
[0135] Get the stored authorization information;
[0136] Determining, based on the operation object and operation content, and the authorization information, whether the operation user has the authority to perform the operation corresponding to the operation content on the operation object;
[0137] If the operating user has the authority, the data authority verification of the operating user passes.
[0138] In one embodiment of the present application, the operation objects include libraries, tables, and fields.
[0139] Optionally, the operation object is cc_test.*, which means all data in all tables of the cc_test library.
[0140] Optionally, the operation object is cc_test.table_A.*, which means all the data in table A of the cc_test library.
[0141] Optional, the operation object is cc_test.table_A.select, which represents all the data in the select column of table A in the cc_test library.
[0142] In the above technical solution, when verifying the data permissions of the operating user, the operation objects include libraries, tables, and fields, which realizes the level permission control of libraries, tables, and fields. Different levels of permission control can be selected according to the actual scenario, meeting more data permission control scenarios, reducing the possibility of users misoperating data, and improving the security and reliability of data processing.
[0143] Furthermore, the real-time development platform backend obtains the stored authorization information and, based on the operation object, operation content, and authorization information, determines whether the current operating user has the authority to perform the corresponding operation on the operation object. If it is determined that the operating user has the authority, the data permission verification of the operating user is determined to have passed, and the Flink SQL statement is executed.
[0144] In the above technical solution, by obtaining the stored authorization information, it is determined whether the operating user has the authority to perform the operation corresponding to the operation content on the operation object according to the operation object and operation content, as well as the authorization information. If the operating user has the authority, it is determined that the data permission verification of the operating user has passed, thereby allocating different data permissions to users, meeting more data permission application scenarios, reducing the possibility of users misoperating data, and improving the security and reliability of data processing.
[0145] In one embodiment of the present application, the method further includes:
[0146] If the data permission verification of the operating user fails, an error message is output and the Flink SQL statement is not executed.
[0147] It is easy to understand that if the data permission verification of the operating user fails, it means that the current operating user does not have the permission to perform the corresponding operation on the operation object. The real-time development platform backend outputs an error message, the Flink SQL statement is not executed, and the real-time task is terminated.
[0148] In the above technical solution, if the data permission verification of the operating user fails, an error message is output and the Flink SQL statement is not executed. This can reduce the possibility of user error in operating data and improve the security and reliability of data processing.
[0149] In one embodiment of the present application, the method further includes:
[0150] Receive a second input, where the second input is an operation to create and submit a Flink SQL permission statement;
[0151] In response to the second input, parse the Flink SQL permission statement to obtain a second parsing result;
[0152] According to the second parsing result, a permission processing operation is performed.
[0153] Figure 4 This is one of the flowcharts of the permission processing method provided in some embodiments of the present application, such as Figure 4 As shown, the method includes step 410 , step 420 and step 430 .
[0154] Step 410: Receive a second input, where the second input is an operation of creating and submitting a Flink SQL permission statement.
[0155] It is easy to understand that the user executes the second input on the real-time development platform. The second input is an operation of creating and submitting a Flink SQL permission statement. The second input is, for example, a grant / revoke statement.
[0156] It should be noted that Flink SQL supports grant / revoke statements to add and change user data permissions. The grant statement is used to grant specific permissions to users or roles. These permissions can include operations such as querying, inserting, updating, and deleting database objects. The revoke statement is used to revoke previously granted permissions, which can restrict user access to database objects.
[0157] Optionally, the format of the grant permission assignment statement is grant <permission> [field list] on to <user name>, where the permission includes at least one of select / update / insert / delete / create / drop / alter. The field list is optional and separated by multiple commas, indicating field permissions. For example, the table name is db1.tabla or db1.*, which indicates all tables under the db1 database. The user name is the user name.
[0158] For example, the second input is grant select,create,insert on glake.cc_test.*touser1, which means that the select, create, and insert permissions for all tables in the cc_test database under the glake data source are assigned to user user1.
[0159] Optionally, the format of the revoke permission statement is revoke <permission> [field list] on from <user name>, where permission, field list, table name, and user name have the same meaning as in the grant statement.
[0160] For example, the second input is revoke select, create, insert on glake.cc_test.*touser1, which means that the select, create, and insert permissions of all tables in the cc_test database under the glake data source of user 1 are revoked.
[0161] Step 420: In response to the second input, parse the Flink SQL permission statement to obtain a second parsing result.
[0162] In one embodiment of the present application, the second parsing result includes the authorized user, the authorized operation object, and the authorized operation content;
[0163] It is easy to understand that, taking the permission statement "revoke select, create, insert on glake.cc_test.* to user1" as an example, the second parsing result is obtained by parsing "revoke select, create, insert on glake.cc_test.* to user1". The second parsing result includes the permission user, permission operation object, and permission operation content. The permission user is user1, the permission operation object is glake.cc_test.*, which represents all tables in the cc_test library under the glake data source, and the permission operation content is select, create, insert, indicating that the select, create, and insert permissions are revoked.
[0164] Step 430: Execute permission processing operations according to the second parsing result.
[0165] The performing of the permission processing operation according to the second parsing result includes:
[0166] When the Flink SQL permission statement is a permission assignment statement, the permission user, permission operation object, and permission operation content are stored as authorization information;
[0167] If the Flink SQL permission statement is a permission revocation statement, the permission user, permission operation object, and permission operation content are deleted.
[0168] Figure 5This is the second flow chart of the permission processing method provided by some embodiments of the present application, such as Figure 5 As shown, the method includes step 510 , step 520 , step 530 and step 540 .
[0169] Step 510: Fill in the Flink SQL permission statement.
[0170] Step 520: Parse the Flink SQL permission statement to determine whether it is a grant statement or a revoke statement.
[0171] Step 530: If the Flink SQL permission statement is a permission assignment statement, the permission user, permission operation object, and permission operation content are stored as authorization information.
[0172] For example, if the Flink SQL permission statement is grant select,create,insert onglake.cc_test.* to user1, it means that the select, create, and insert permissions for all tables in the cc_test database under the glake data source are assigned to user1. The real-time development platform backend stores the permission user (user1), permission operation object (glake.cc_test.*), and permission operation content (select, create, insert) as authorization information.
[0173] Step 540: If the Flink SQL permission statement is a permission revocation statement, delete the permission user, permission operation object, and permission operation content.
[0174] For example, if the Flink SQL permission statement is revoke select,create,insert onglake.cc_test.* to user1, it means that the select, create, and insert permissions for all tables in the cc_test database under the glake data source of user 1 are revoked. The real-time development platform backend deletes the relevant information about the permission user (user1), the permission operation object (glake.cc_test.*), and the permission operation content (select, create, insert).
[0175] In the above technical solution, by receiving the second input and parsing to obtain the second parsing result, and performing the permission processing operation according to the second parsing result, different data permissions are assigned to users, which can meet more data permission application scenarios.
[0176] In the above technical solution, permission processing operations are performed based on the permission users, permission operation objects and permission operation contents. The permission users, permission operation objects and permission operation contents can be stored or deleted as empowerment information, thereby realizing the storage or deletion of user permissions, reducing the possibility of users misoperating data, and improving the security and reliability of data processing.
[0177] Figure 6 This is a schematic diagram of the structure of the data authority control device provided in some embodiments of the present application. Figure 6 As shown, the data authority control device 60 includes a receiving unit 601 , a parsing unit 602 , a permission checking unit 603 and an executing unit 604 .
[0178] The receiving unit 601 is configured to receive a first input, where the first input is an operation of creating and submitting a real-time task;
[0179] A parsing unit 602 is configured to parse the Flink SQL statement corresponding to the real-time task in response to the first input to obtain a first parsing result;
[0180] The permission verification unit 603 is used to obtain information of the operating user corresponding to the real-time task and verify the data permission of the operating user according to the first parsing result;
[0181] The execution unit 604 is configured to execute the Flink SQL statement if the data permission verification of the operation user passes.
[0182] Optionally, the parsing unit 602 is configured to:
[0183] Call the Flink SQL parser to parse the Flink SQL statement corresponding to the real-time task and obtain an execution plan;
[0184] Obtaining table structure modification statements or data manipulation statements in the execution plan;
[0185] Obtain the operation object and operation content corresponding to the table structure modification statement, or obtain the table name and query execution plan in the operation data type statement, and loop to obtain the sub-plans of the query execution plan until the operation object and operation content of the bottom-level sub-plan are obtained.
[0186] Optionally, the parsing unit 602 is configured to:
[0187] The verifying the data authority of the operating user according to the first parsing result includes:
[0188] Get the stored authorization information;
[0189] Determining, based on the operation object and operation content, and the authorization information, whether the operation user has the authority to perform the operation corresponding to the operation content on the operation object;
[0190] If the operating user has the authority, the data authority verification of the operating user passes.
[0191] Optionally, the operation objects include libraries, tables, and fields.
[0192] Optionally, the device further includes an output unit, configured to:
[0193] If the data permission verification of the operating user fails, an error message is output and the Flink SQL statement is not executed.
[0194] Optionally, the receiving unit 601 is configured to:
[0195] Receive a second input, where the second input is an operation to create and submit a Flink SQL permission statement;
[0196] Optionally, the parsing unit 602 is configured to:
[0197] In response to the second input, parse the Flink SQL permission statement to obtain a second parsing result;
[0198] Optionally, the execution 604 is used to:
[0199] According to the second parsing result, a permission processing operation is performed.
[0200] Optionally, the second parsing result includes the authorized user, the authorized operation object, and the authorized operation content;
[0201] The performing of the permission processing operation according to the second parsing result includes:
[0202] When the Flink SQL permission statement is a permission assignment statement, the permission user, permission operation object, and permission operation content are stored as authorization information;
[0203] If the Flink SQL permission statement is a permission revocation statement, the permission user, permission operation object, and permission operation content are deleted.
[0204] In the above technical solution, the Flink SQL statement corresponding to the real-time task is parsed to obtain a first parsing result, and the information of the operating user corresponding to the real-time task is obtained. The data permissions of the operating user are verified based on the first parsing result. If the data permissions of the operating user pass the verification, the Flink SQL statement is executed. This realizes the allocation of different data permissions to users, can meet more data permission application scenarios, reduce the possibility of user error in data operation, and improve the security and reliability of data processing.
[0205] The data authority control device 60 in the embodiment of the present application can be an electronic device or a component in an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other device other than a terminal. For example, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, a mobile Internet device (MID), an augmented reality (AR) / virtual reality (VR) device, a robot, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a personal digital assistant (PDA), etc. It can also be a server, a network attached storage (NAS), a personal computer (PC), a television (TV), a teller machine or a self-service machine, etc., and the embodiment of the present application is not specifically limited.
[0206] The data authority control device 60 in the embodiment of the present application can be a device having an operating system. The operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.
[0207] The data authority control device 60 provided in the embodiment of the present application can achieve Figures 1 to 5 To avoid repetition, the various processes implemented in the method embodiment are not described here.
[0208] In some embodiments, as Figure 7As shown, an embodiment of the present application also provides an electronic device 700, including a processor 701, a memory 702, and a computer program stored in the memory 702 and executable on the processor 701. When the program is executed by the processor 701, each process of the above-mentioned data authority control method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.
[0209] It should be noted that the electronic devices in the embodiments of the present application include the mobile electronic devices and non-mobile electronic devices mentioned above.
[0210] An embodiment of the present application also provides a non-transitory computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the various processes of the above-mentioned data authority control method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.
[0211] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0212] An embodiment of the present application also provides a computer program product, including a computer program, which implements the above-mentioned data permission control method when executed by a processor.
[0213] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0214] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned data authority control method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.
[0215] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.
[0216] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved. For example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.
[0217] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.
[0218] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.
[0219] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
[0220] Although the embodiments of the present application have been shown and described, those skilled in the art will appreciate that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and intent of the present application, and that the scope of the present application is defined by the claims and their equivalents.
Claims
1. A data authority control method, characterized in that: include: Receive a first input, where the first input is an operation of creating and submitting a real-time task; In response to the first input, parse the Flink SQL statement corresponding to the real-time task to obtain a first parsing result; Acquire information of an operating user corresponding to the real-time task, and verify data authority of the operating user according to the first analysis result; If the data permission verification of the operation user passes, the Flink SQL statement is executed.
2. The data authority control method according to claim 1, characterized in that: The parsing of the Flink SQL statement corresponding to the real-time task includes: Call the Flink SQL parser to parse the Flink SQL statement corresponding to the real-time task to obtain an execution plan; Obtaining table structure modification statements or data operation statements in the execution plan; Obtain the operation object and operation content corresponding to the table structure modification statement, or obtain the table name and Query execution plan in the operation data type statement, and loop to obtain the sub-plans of the Query execution plan until the operation object and operation content of the bottom-level sub-plan are obtained.
3. The data authority control method according to claim 2, characterized in that: The verifying the data authority of the operating user according to the first parsing result includes: Get the stored authorization information; Determine, based on the operation object and the operation content, and the authorization information, whether the operation user has the authority to perform the operation corresponding to the operation content on the operation object; In the case where the operating user has the authority, the data authority verification of the operating user passes.
4. The data authority control method according to claim 2 or 3, characterized in that: The operation objects include libraries, tables and fields.
5. The data authority control method according to claim 1, characterized in that: The method further comprises: If the data permission check of the operating user fails, an error message is output and the FlinkSQL statement is not executed.
6. The data authority control method according to claim 1, characterized in that: The method further comprises: Receive a second input, where the second input is an operation of creating and submitting a Flink SQL permission statement; In response to the second input, parse the permission statement of the Flink SQL to obtain a second parsing result; According to the second parsing result, a permission processing operation is performed.
7. The data authority control method according to claim 6, characterized in that: The second analysis result includes the authorized user, the authorized operation object and the authorized operation content; The performing of the permission processing operation according to the second parsing result includes: When the permission statement of the Flink SQL is a permission assignment statement, the permission user, permission operation object, and permission operation content are stored as authorization information; When the Flink SQL permission statement is a permission revocation statement, the permission user, permission operation object, and permission operation content are deleted.
8. A data authority control device, characterized in that: include: A receiving unit, configured to receive a first input, wherein the first input is an operation of creating and submitting a real-time task; A parsing unit, configured to parse the Flink SQL statement corresponding to the real-time task in response to the first input, and obtain a first parsing result; A permission verification unit, configured to obtain information of an operating user corresponding to the real-time task, and verify data permissions of the operating user according to the first parsing result; The execution unit is used to execute the Flink SQL statement if the data permission verification of the operation user passes.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the data authority control method as described in any one of claims 1-7 is implemented.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the data authority control method as described in any one of claims 1 to 7 is implemented.