WO2019206211A1 - 权限管理方法及装置 - Google Patents

权限管理方法及装置 Download PDF

Info

Publication number
WO2019206211A1
WO2019206211A1 PCT/CN2019/084216 CN2019084216W WO2019206211A1 WO 2019206211 A1 WO2019206211 A1 WO 2019206211A1 CN 2019084216 W CN2019084216 W CN 2019084216W WO 2019206211 A1 WO2019206211 A1 WO 2019206211A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
sql statement
authorization
type
verification
Prior art date
Application number
PCT/CN2019/084216
Other languages
English (en)
French (fr)
Inventor
崔振凯
谷宁波
Original Assignee
新华三大数据技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 新华三大数据技术有限公司 filed Critical 新华三大数据技术有限公司
Publication of WO2019206211A1 publication Critical patent/WO2019206211A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication

Definitions

  • Spark is a big data computing framework based on memory computing. It provides distributed computing functions, reads distributed storage data, and distributes tasks to various nodes for calculation. Spark improves the real-time performance of data processing in a big data environment, and guarantees high fault tolerance and high scalability, allowing users to deploy Spark on a large number of inexpensive hardware to form a cluster.
  • SparkSQL is a Spark-based Distributed SQL (Structured Query Language) engine that supports SQL statements and greatly facilitates users who are familiar with relational databases.
  • Rights management refers to the security rules or security policies set by the system. Users can access and only access resources that they are granted. In related technologies, SparkSQL does not have a rights management function, which reduces information security.
  • FIG. 1 illustrates a flow chart of a rights management method in accordance with an embodiment of the present disclosure.
  • Figure 2 shows a schematic diagram of a Spark architecture.
  • FIG. 3 illustrates a flow chart of a rights management method in accordance with an embodiment of the present disclosure.
  • FIG. 4 illustrates a flow chart of yet another rights management method in accordance with an embodiment of the present disclosure.
  • FIG. 5 illustrates a block diagram of a rights management apparatus in accordance with an embodiment of the present disclosure.
  • FIG. 6 is a block diagram of an apparatus for rights management, according to an example.
  • FIG. 1 illustrates a flow chart of a rights management method in accordance with an embodiment of the present disclosure.
  • FIG. 2 shows a schematic diagram of a Spark architecture.
  • the Spark architecture includes Driver (Driver), Cluster Manager (Cluster Manager), and Worker Node (Working Node).
  • the driver is responsible for scheduling the application, managing the task assignment, and the like.
  • the driver creates a SparkContext at startup, and SparkContext is the starting point for the entire distributed program to run.
  • the cluster manager is responsible for the allocation and management of resources for the working nodes.
  • the worker node is responsible for creating the Executor, further assigning resources and tasks to the executor, and synchronizing the resource information to the cluster manager.
  • the executor is a process on the worker node and is responsible for processing the tasks assigned to the process.
  • the rights management method shown in FIG. 1 can be applied to the driver in the Spark architecture shown in FIG. 2. As shown in FIG. 1, the rights management method includes:
  • SQL refers to structured query language, a database query and programming language for accessing database systems. Access operations to the database can include: insert, query, update, and delete, etc. SQL statements can be used to implement the above access operations.
  • the SQL statement is a descriptive language that specifies the access task. The driver needs to specify an execution plan based on the SQL statement. The execution plan indicates how to complete the access task, and the executor executes the execution plan to implement the access task.
  • the processing flow of a SQL statement includes: Parse (parser) lexical parsing and syntax parsing of the SQL statement, obtaining an Unresolved LogicalPlan (unbound logical plan); Analyzer (analyzer) performing the Unresolved LogicalPlan Semantic parsing, specifically, Binding can be performed on the Unresolved LogicalPlan in conjunction with the Catalog (Data Dictionary) to generate a Resolved LogicalPlan (the bound logical plan); the Optimizer optimizes the Resolved LogicalPlan to generate an Optimized LogicalPlan; The SparkPlan (execution plan module) converts the optimized LogicalPlan to a PhysicalPlan.
  • Parse parser
  • Analyzer analyzer
  • Binding can be performed on the Unresolved LogicalPlan in conjunction with the Catalog (Data Dictionary) to generate a Resolved LogicalPlan (the bound logical plan)
  • the Optimizer optimizes the Resolved LogicalPlan to generate an Optimized Logical
  • the executor converts the PhysicalPlan into an executable physical plan and executes the executable physical plan to generate RDD (Resilient Distributed Datasets).
  • RDD Resilient Distributed Datasets
  • a SQL statement is executed in the drive shown in Figure 2 before being converted into a PhysicalPlan, that is, the above Parse, Analyzer, Optimizer, and SparkPlan are all running in the drive.
  • the PhysicalPlan is distributed to the executor execution in the worker node shown in Figure 2. It should be noted that in the SQL statement processing flow, Unresolved LogicalPlan, Resolved LogicalPlan, and Optimized LogicalPlan are logical plans.
  • the authorization SQL statement can be configured to request permission to certain users to access certain resources in certain ways, for example, requesting user A to grant permission to insert, delete, etc. data table A; for example, request to user B Grant permission to delete, update, etc. column A of data table B.
  • the driver receives the authorization SQL statement, it can obtain the permission information from the authorization SQL statement.
  • SparkSQL's grammar file stores the syntax supported by SparkSQL, and each grammar has a corresponding keyword.
  • the driver handles the SQL statement through Parse, including the lexical analysis stage and the syntax analysis stage. In the lexical analysis stage, the driver can find the syntax corresponding to the SQL statement according to the keywords of the SQL statement, and then parse the SQL statement according to the found syntax. Determine the meaning of each part of the SQL statement.
  • SparkSQL does not support parsing of authorized SQL statements.
  • the parsing function of the authorized SQL statement is added, so that the driver can parse the authorized SQL statement and obtain the permission information from the authorized SQL statement.
  • an authorization syntax may be added in the syllab file of SparkSQL, and a keyword is set for the authorization grammar, which defines an authorized user identifier, an authorized resource identifier, and an authorization type.
  • S11 can be implemented as: performing lexical parsing on the received SQL statement to obtain a keyword; if the keyword is mapped to an authorization syntax, obtaining an authorized user identifier from the received SQL statement according to the authorization syntax.
  • Authorized resource identification and authorization type as permission information.
  • the authorized user identifier may be a user name or a user ID
  • the authorized resource identifier may be a data table name, a data table number, a column name, a column number, etc., and the disclosure is not limited.
  • the authorization type may include inserts and/or queries and/or updates and/or deletes.
  • each authorization type corresponds to a value
  • the driver can determine the authorization type according to the value corresponding to the authorization type in the authorization SQL statement. For example, when the value of the authorization type in the authorization SQL statement corresponds to INSERT (or SELECT or UPDATE or DELETE), the drive can determine that the authorization type is insert (or query or update or delete). When the value of the authorization type in the authorization SQL statement corresponds to INSERT and SELECT, the drive can determine the authorization type as insert and query. In one example, you can set a value ALL for all permissions. When the value of the authorization type in the authorization SQL statement corresponds to ALL, the drive can determine the authorization type as insert, query, update, and delete.
  • the driver may obtain one or more authorized user identifiers, one or more authorized resource identifiers, and one or more authorization types from the authorization SQL statement as the authority information. In this way, the drive can grant the same permissions to different users at the same time, grant multiple data tables or multiple columns to the same user, and grant multiple types of permissions to the same resource.
  • S12 The permission information is saved as metadata in the database by calling an interface of the third-party metadata management component.
  • the third-party metadata management component provides the ability to save metadata to a database and to query metadata from a database.
  • the third party metadata management component can be a Hive Metastore.
  • Hive is a data warehousing tool based on Hadoop that maps structured data files into a single database table. Hive provides a set of tools for data extraction, transformation, and loading. It is a mechanism for storing, querying, and analyzing large-scale data stored in Hadoop.
  • the Hive Metastore is a component of Hive's management metadata. Its metadata is stored in a database, such as Derby, MySQL, and so on. In Hive, the Hive client connects to the Hive Metastore, and the Hive Metastore connects to the database to access metadata.
  • the database can be an embedded database, a local external database, or a remote external database.
  • the driver can establish a connection with a third party metadata management component by invoking an interface of a third party metadata management component. Since the third-party metadata management component provides the function of saving the metadata to the database, after the driver transmits the permission information to the third-party metadata management component, the third-party metadata management component saves the permission information as metadata to the database. The storage of the permission information is realized, and the storage of the permission information is implemented by the third-party metadata management component, which saves the drive resources.
  • the driver can also query the permission information through the third-party metadata management component, thereby implementing the permission verification.
  • Spark provides commands (Command) for running physical plans corresponding to different SQL statements.
  • a command to execute a physical plan for authorizing the SQL statement may be added, denoted as GrantPriviledgeCommand, which may be inherited from the RunnableCommand.
  • the GrantPriviledgeCommand includes a Run() method, and the executor in the working node can execute the physical plan corresponding to the authorized SQL statement by executing the Run() method in the GrantPriviledgeCommand, thereby obtaining a data set corresponding to the authorized SQL statement, the data set It can be RDD or Seq (Row). In some embodiments, the data set can be empty.
  • Step S13 when receiving the access SQL statement, verifying the permission of the access SQL statement according to the permission information.
  • Accessing the SQL statement means that the user accesses the resource, such as inserting data into the database, querying the data, updating the data, deleting the data, and the like.
  • the access SQL statement can be an Insert statement, a Select statement, an Update statement, a Delete statement, and the like.
  • step S13 can have different implementations, as described below.
  • the driver performs lexical parsing of the received SQL statement through Parse to obtain a keyword, and if the keyword is mapped to an access syntax (eg, insert syntax, query syntax, update syntax, and delete syntax, etc.), Then parse according to the syntax mapped by the keyword, and convert the access SQL statement into the corresponding logical plan, and enter the authorization verification process of Analyzer.
  • an access syntax eg, insert syntax, query syntax, update syntax, and delete syntax, etc.
  • the drive confirms that the logical plan construction is complete and enters the optimization phase; if the verification fails, the drive prompts no permission and ends the process.
  • the Analyzer is provided with a series of rules.
  • the driver can traverse each rule through Analyzer, and use these rules to process the obtained logical plan. If the logical plan conforms to the current rule, it traverses the next rule.
  • the rule of the authority verification is added in the Analyzer, and the driver passes the logical plan processed by other rules into the authority verification rule.
  • the driver of the driver does not make any changes to the logic plan, but only Obtain the required verification information from the logical plan and verify the authority.
  • the authority verification process will be explained by the embodiment of FIG.
  • FIG. 3 illustrates a flow chart of a rights management method in accordance with an embodiment of the present disclosure. As shown in Figure 3, the process of authorization verification includes:
  • the access user identifier is the access user identifier.
  • the access user identifier may be a user name or a user ID, etc., and the disclosure is not limited thereto.
  • the type of logical plan corresponding to the Select statement is a logical plan of the Project type.
  • the access type is configured to identify the access operations performed by the user.
  • Access types can be inserts, queries, updates, deletes, and more.
  • the driver can determine the access type of the SQL statement through Parse. For example, when mapping to the insertion syntax according to the keyword, the access type can be determined to be inserted, and when the keyword is mapped to the deletion syntax, the access type can be determined to be deleted. According to the access type of the SQL sentence, the SQL statement can be mapped to the logical plan of the corresponding type, thereby obtaining a mapping relationship between the access type of the SQL statement and the type of the logical plan. For example, when the access type is a query, the SQL statement can be used. Map to the logical plan of the Project type, which can determine that the query type and the Project type have a mapping relationship.
  • the type of the logical plan and the access resource identifier can be obtained. Based on the mapping between the type of the logical plan and the access type obtained by Parse processing, the access type corresponding to the type of the logical plan can be determined.
  • the access resource identifier may be obtained in a lexical parsing stage, for example, an identifier of the data table may be obtained.
  • the access resource identification may be obtained from a logical plan during the parsing stage. Compared with obtaining the access resource identifier in the lexical analysis stage, the method can obtain a more detailed access resource identifier, for example, the identifier of the accessed data table and the identifier of the accessed column in the data table.
  • the access resource identifier may be a data table name, a data table number, a column name, a column number, etc., and the disclosure is not limited thereto.
  • the third-party metadata management component is configured to verify the verification information according to the permission information by calling an interface of the third-party metadata management component.
  • the third-party metadata management component can obtain the existing permission information from the database, compare the verification information with the permission information, and obtain the verification result, and the third-party metadata management component. Will return the verification result.
  • the verification process is implemented by a third-party metadata management component that saves the resources of the drive.
  • user tom starts SparkSQL and enters the SQL statement Select*from salary.
  • the driver lexically parses the received SQL statement, determines that the corresponding access type of the statement is Select, generates a logical plan of type Project in the parsing stage, and forms a mapping of the access type Select and the logical type Project. Based on the formed mapping, the driver determines that the access type corresponding to Project is Select.
  • the driver obtains the access resource identifier salary from the logical plan corresponding to the SQL statement, and determines the access user identifier tom.
  • the drive determines Select, salary, and tom as authentication information, and invokes a third-party metadata management component interface to enable the third-party metadata management component to verify the verification information according to the existing permission information.
  • the rights management method can store the rights information as metadata through the authorization SQL statement, and store the data in the database through the third-party metadata management component, thereby granting the user the right to access certain resources, and receiving the access SQL.
  • the authority to access the SQL statement is verified according to the permission information, and the permission management function in SparkSQL is implemented, thereby improving the security of the information.
  • S13 may include the steps shown in FIG. 4, as described below.
  • the driver when receiving the SQL statement, can perform lexical parsing and syntax parsing on the received access SQL statement through Parse to obtain the corresponding Unresolved LogicalPlan; then bind the Unresolved LogicalPlan through Analyzer to obtain Resolved LogicalPlan; then optimize the obtained Resolved LogicalPlan through Optimizer.
  • At least one analysis rule is defined in the Analyzer, and the Analyzer binds the Unresolved LogicalPlan according to the at least one analysis rule.
  • the Optimizer defines at least one optimization rule, and the optimizer optimizes the Resolved LogicalPlan according to the at least one optimization rule.
  • an analysis rule (hereinafter referred to as "first authority verification rule") for implementing authority verification may be added to the Analyzer. Then, when the Analyzer in the drive accesses the first permission verification rule, obtain the access type, the access resource identifier, and the access user identifier from the Unresolved LogicalPlan as the verification information, and invoke the interface of the third-party metadata management component to Verify the verification information.
  • the first authorization verification rule may be configured as the first analysis rule in the Analyzer, so that the processing of the access SQL statement without the permission may be terminated in time.
  • the solution may be implemented after the first authorization verification rule is set after other analysis rules, and the disclosure does not limit this.
  • an optimization rule (hereinafter referred to as "second authority verification rule") for implementing rights verification may be added to the Optimizer. Then, when the optimizer in the driver accesses the second permission verification rule, obtain an access type, an access resource identifier, and an access user identifier from the Resolved LogicalPlan, and invoke an interface of the third-party metadata management component to verify the information. authenticating.
  • the second authorization verification rule may be configured as the first optimization rule in the Optimizer, so that the processing of the access SQL statement without the permission may be terminated in time. It should be understood that the second permission verification rule is set before other optimization rules, and the disclosure does not limit this.
  • the logical plan corresponding to the access SQL statement may refer to an Unresolved LogicalPlan or a Resolved LogicalPlan.
  • any of the Unresolved LogicalPlan and Resolved LogicalPlan that access the SQL statement carries a keyword indicating the access type of the access SQL statement.
  • the Unresolved LogicalPlan and Resolved LogicalPlan of the query statement carry the keyword "SELECT”
  • the Unresolved LogicalPlan and the Resolved LogicalPlan of the insert statement carry the keyword "INSERT”
  • the Unresolved LogicalPlan and Resolved LogicalPlan of the delete statement carry the keyword " DELETE”
  • the Unresolved LogicalPlan and Resolved LogicalPlan of the update statement carry the keyword "UPDATE”.
  • the access type of the logical plan can be obtained according to the keywords carried in the logical plan.
  • the third-party metadata management component is configured to verify the verification information according to the permission information by calling an interface of the third-party metadata management component.
  • the verifying the verification information may include: if an authorized user identifier matches the access user identifier, and the authorized resource identifier matches the access resource identifier, and the authorization type and the If the access type matches the permission information, it is determined that the verification is passed; otherwise, the verification fails.
  • the third-party metadata management component searches for the authentication information in the existing permission information, when the access user identifier and the authorized user identifier, the access resource identifier, and the authorized resource identifier, and the access type and the authorization type match, the verification is verified. If any of the three does not match, the verification is not passed.
  • Example 1 the rights information is as shown in Table 1, and the authentication information 1 includes an access user identity user 1, an access type query, and an access resource identifier table1.
  • the authorization resource identifier of the privilege information 3 matches that the access resource identifier table1 of the authentication information 1 is matched, and the authorization type of the privilege information 3 matches the access type query of the query and the authentication information 1, and the authorized user identifier is the user.
  • the third-party metadata management component determines that the access SQL statement corresponding to the verification information 1 is verified.
  • Authorized user ID Authorized resource identifier Authorization type Permission information 1 User 1 Table1 delete Permission information 2 User 1 Table2 Inquire Permission information 3 User 1 Table1 Inquire Permission information 4 User 2 Table1 Update Permission information 5 User 3 Table2 All permissions
  • Example 2 the rights information is as shown in Table 1, and the authentication information 2 includes the access user identity user 1, the access type update, and the access resource identifier table1. As shown in Table 1, there is no permission information that matches the access user identifier of the authentication user ID and the authentication information 2, the access resource identifier of the authorization resource identifier and the verification information 2, and the authorization type that matches the access type of the authentication information 3, The three-way metadata management component determines that the access SQL statement verification corresponding to the verification information 2 has not passed.
  • FIG. 5 illustrates a block diagram of a rights management apparatus in accordance with an embodiment of the present disclosure.
  • the device 40 includes:
  • the obtaining module 41 is configured to obtain the permission information from the authorized SQL statement when receiving the authorization SQL statement;
  • the calling module 42 is configured to save the permission information as metadata in the database by calling an interface of the third-party metadata management component;
  • the verification module 43 is configured to, when receiving the access SQL statement, verify the authority to access the SQL statement according to the permission information.
  • the obtaining module 41 is further configured to:
  • the authorized user identifier, the authorized resource identifier, and the authorization type are obtained from the received SQL statement as the authority information according to the authorization syntax.
  • the authorization type includes one or more of insertion, query, update, and deletion.
  • the verification module 43 is further configured to:
  • the third-party metadata management component verifies the verification information according to the permission information.
  • the apparatus further includes a third-party metadata management component 44 configured to:
  • the verification is determined to pass; otherwise, the verification fails.
  • the rights management apparatus can store the rights information as metadata through the authorization SQL statement, and store the data in the database through the third-party metadata management component, thereby granting the user permission to access certain resources, and receiving the access SQL
  • the authority to access the SQL statement is verified according to the permission information, and the permission management function in SparkSQL is implemented, thereby improving the security of the information.
  • FIG. 6 is a block diagram of an apparatus 900 configured for rights management, according to an example.
  • the apparatus 900 can include a processor 901, a machine readable storage medium 902 that stores machine executable instructions.
  • Processor 901 and machine readable storage medium 902 can communicate via system bus 903.
  • the processor 901 executes the rights management method described above by reading machine executable instructions corresponding to the rights management logic in the machine readable storage medium 902.
  • the machine-readable storage medium 902 referred to herein can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like.
  • the machine-readable storage medium may be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as a hard disk drive), solid state drive, any type of storage disk. (such as a disc, dvd, etc.), or a similar storage medium, or a combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

本公开涉及权限管理，包括接收到授权SQL语句时，从所述授权SQL语句中获取权限信息；通过调用第三方元数据管理组件的接口，将所述权限信息作为元数据保存在数据库中；接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证，根据本公开实施例的权限管理方法及装置能够实现SparkSQL中的权限管理功能，提高信息的安全性。

Description

权限管理方法及装置
相关申请的交叉引用
本申请要求于2018年04月25日提交中国专利局的申请号为201810378730.3、名称为“权限管理”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
背景技术
Spark是一种基于内存计算的大数据计算框架，提供了分布式计算功能，将分布式存储的数据读入，以及将任务分发到各个节点进行计算。Spark提高了在大数据环境下数据处理的实时性，并且保证了高容错性和高可伸缩性，允许用户将Spark部署在大量廉价硬件之上，形成集群。
SparkSQL是一种基于Spark的分布式SQL(Structured Query Language，结构化查询语言)引擎，支持SQL语句，极大地方便了熟悉关系型数据库的用户。
权限管理指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授予权限的资源。相关技术中，SparkSQL不具有权限管理功能，降低了信息的安全性。
附图说明
包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本公开的示例性实施例、特征和方面，并且用于解释本公开的原理。
图1示出根据本公开一实施例的权限管理方法的流程图。
图2示出了一种Spark架构的示意图。
图3示出根据本公开一实施例的权限管理方法的流程图。
图4示出根据本公开一实施例的又一权限管理方法的流程图。
图5示出根据本公开一实施例的权限管理装置的框图。
图6是根据一示例示出的一种用于权限管理的装置的框图。
具体实施方式
以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。
在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。
另外，为了更好的说明本公开，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以实施。在一些实例中，对于 本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本公开的主旨。
图1示出根据本公开一实施例的权限管理方法的流程图。
图2示出了一种Spark架构的示意图。如图2所示，Spark架构中包括Driver(驱动器)、Cluster Manager(集群管理器)和Worker Node(工作节点)。其中，驱动器负责对应用程序进行调度、对task(任务)分配等进行管理。驱动器在启动时会创建SparkContext，SparkContext是整个分布式程序运行的起点。集群管理器负责工作节点的资源的分配和管理。工作节点负责创建Executor(执行器)，将资源和任务进一步分配给执行器，并同步资源信息给集群管理器。其中，执行器是工作节点上的进程，负责对分配给该进程的任务进行处理。
图1所示的权限管理方法可以应用于图2所示的Spark架构中的驱动器。如图1所示，该权限管理方法包括：
S11，接收到授权SQL语句时，从所述授权SQL语句中获取权限信息。
SQL指结构化查询语言，是一种数据库查询和程序设计语言，用于访问数据库系统。对数据库的访问操作可以包括：插入、查询、更新和删除等，SQL语句可以用来实现上述访问操作。SQL语句是一种描述性的语言，指明了访问任务，驱动器需要根据SQL语句指定一个执行计划，该执行计划表明了如何完成所述访问任务，执行器执行该执行计划，从而实现访问任务。
相关技术中，一条SQL语句的处理流程包括：Parse(解析器)对SQL语句进行词法解析和语法解析，得到Unresolved LogicalPlan(未绑定的逻辑计划)；Analyzer(分析器)对得到的Unresolved LogicalPlan进行语义解析，具体地，可以结合Catalog(数据字典)对Unresolved LogicalPlan进行绑定(bind)，生成Resolved LogicalPlan(已绑定的逻辑计划)；Optimizer(优化器)对Resolved LogicalPlan进行优化，生成Optimized LogicalPlan；SparkPlan(执行计划模块)将Optimized LogicalPlan转换成PhysicalPlan。执行器将PhysicalPlan转换成可执行物理计划，并执行该可执行物理计划，生成RDD(Resilient Distributed Datasets，弹性分布式数据集)。其中，一条SQL语句在被转换成PhysicalPlan之前都是在图2所示的驱动器执行，即上述的Parse、Analyzer、Optimizer和SparkPlan均运行在驱动器中。在SQL语句被转换成PhysicalPlan之后，该PhysicalPlan会被分发到图2所示的工作节点中的执行器执行。需要说明的是，在SQL语句处理流程中，Unresolved LogicalPlan、Resolved LogicalPlan、Optimized LogicalPlan均为逻辑计划。
授权SQL语句可以配置成请求向某些用户授予以某些方式访问某些资源的权限，例如，请求向用户A授予对数据表A进行插入、删除等操作的权限；再例如，请求向用户B授予 对数据表B的列A进行删除、更新等操作的权限。驱动器接收到授权SQL语句时，可以从授权SQL语句中获取权限信息。
SparkSQL的语法文件中存储有SparkSQL所支持的语法，每条语法设置有对应的关键字。驱动器通过Parse对SQL语句的处理包括词法解析阶段和语法解析阶段，在词法解析阶段，驱动器可以根据SQL语句的关键字，查找到SQL语句对应的语法，进而按照查找到的语法对SQL语句进行解析，确定出SQL语句每一部分的含义。
相关技术中，SparkSQL不支持对授权SQL语句的解析。在本公开实施例中，在词法解析阶段，增加了对授权SQL语句的解析功能，使得驱动器能够解析授权SQL语句，从授权SQL语句中获取权限信息。
在一种可能的实现方式中，可以在SparkSQL的语法文件中添加授权语法，并为授权语法设置关键字，所述授权语法定义了授权用户标识、授权资源标识和授权类型。如此，S11可以实现为：对接收到的SQL语句进行词法解析，获取关键字；若所述关键字映射到授权语法，则按照所述授权语法，从所接收到的SQL语句中获取授权用户标识、授权资源标识和授权类型，作为权限信息。
其中，授权用户标识可以为用户名或者用户ID等，授权资源标识可以为数据表名、数据表编号、列名、列编号等，对此本公开不做限制。
在一种可能的实现方式中，在一个授权SQL语句中，授权类型可以包括插入和/或查询和/或更新和/或删除。
在一种可能的实现方式中，每种授权类型对应于一个值，驱动器可以根据授权SQL语句中授权类型对应的值确定授权类型。例如，当授权SQL语句中授权类型对应的值为INSERT(或者SELECT或者UPDATE或者DELETE)时，驱动器可以确定授权类型为插入(或者查询或者更新或者删除)。当授权SQL语句中授权类型对应的值为INSERT和SELECT时，驱动器可以确定授权类型为插入和查询。在一个示例中，可以设置一个代表所有权限的值ALL，当授权SQL语句中授权类型对应的值为ALL时，驱动器可以确定授权类型为插入、查询、更新和删除。
在一种可能的实现方式中，驱动器可以从授权SQL语句中获取一个或多个授权用户标识、一个或多个授权资源标识和一种或多种授权类型，作为权限信息。这样，驱动器可以同时对不同的用户授予相同的权限，对同一个用户授予多个数据表或者多个列的权限，以及对同一资源授予多种类型的权限。
S12，通过调用第三方元数据管理组件的接口，将所述权限信息作为元数据保存在数据库中。
第三方元数据管理组件提供了将元数据保存到数据库的功能和从数据库查询元数据的 功能。在一个示例中，第三方元数据管理组件可以为Hive Metastore。Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表。Hive提供了一系列的工具，可以用来进行数据提取、转化、加载，是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。Hive Metastore是Hive中管理元数据的组件。其元数据存储在数据库中，例如Derby、MySQL等。在Hive中，Hive客户端连接Hive Metastore，Hive Metastore再去连接数据库来存取元数据，其中数据库可以为内嵌数据库、本地外部数据库或者远程外部数据库。
在本公开实施例中，驱动器通过调用第三方元数据管理组件的接口，可以建立与第三方元数据管理组件的连接。由于第三方元数据管理组件提供了将元数据保存到数据库的功能，因此驱动器将权限信息传送给第三方元数据管理组件后，第三方元数据管理组件会将权限信息作为元数据保存到数据库中，实现权限信息的存储，权限信息的存储由第三方元数据管理组件实现，节省了驱动器资源。
由于第三方元数据管理组件还提供了从数据库查询元数据的功能，因此，驱动器还可以通过第三方元数据管理组件查询权限信息，进而实现权限验证。
在本公开中，Spark提供有用于运行不同SQL语句对应的物理计划的命令(Command)。在一种可能的实现方式中，可以增设用于执行授权SQL语句的物理计划的命令，记为GrantPriviledgeCommand，所述GrantPriviledgeCommand可以继承自RunnableCommand。GrantPriviledgeCommand中包括Run()方法，工作节点中的执行器可以通过执行GrantPriviledgeCommand中的Run()方法来执行授权SQL语句对应的物理计划，从而得到与所述授权SQL语句对应的数据集，该数据集可以是RDD或Seq(Row)。在一些实施方式中，所述数据集可以为空。
步骤S13，接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证。
访问SQL语句表示用户对资源进行访问操作，例如向数据库中插入数据、查询数据、更新数据，删除数据等。访问SQL语句可以为Insert语句、Select语句、Update语句、Delete语句等。
在本公开中，步骤S13可以有不同的实现方式，描述如下。
在一种可能的实现方式中，驱动器通过Parse对接收到的SQL语句进行词法解析，获取关键字，若关键字映射到访问语法(例如：插入语法、查询语法、更新语法和删除语法等)，则按照关键字映射到的语法进行解析，并将访问SQL语句转换成对应的逻辑计划，并进入Analyzer的权限验证流程。
若验证通过，则驱动器确认逻辑计划构造完成，进入优化阶段；若验证未通过，则驱 动器提示无权限，并结束流程。
Analyzer中设置有一系列的rule(规则)，驱动器可以通过Analyzer遍历每一个规则，利用这些规则对得到的逻辑计划进行处理，如果逻辑计划符合当前规则，则遍历下一个规则。
在本公开实施例中，在Analyzer中增加了权限验证的规则，驱动器将经过其他规则处理后的逻辑计划传入权限验证规则中，根据权限验证规则，驱动器的Analyzer不对逻辑计划做任何改动，只是从逻辑计划中获取需要的验证信息，进行权限验证。权限验证流程将通过图3的实施例进行说明。
图3示出根据本公开一实施例的权限管理方法的流程图。如图3所示，权限验证的流程包括：
S131，接收到访问SQL语句时，获取所述访问SQL语句对应的访问用户标识以及逻辑计划。
访问用户标识为需要验证权限的用户的标识。由于当前使用SparkSQL系统的用户是需要验证权限的用户，因此当前提供访问SQL语句的用户的标识为访问用户标识。访问用户标识可以为用户名或者用户ID等，对此本公开不做限制。
S132，确定所述逻辑计划的类型对应的访问类型、并从所述逻辑计划中获取访问资源标识。
不同类型的SQL语句对应的逻辑计划的类型不同。例如，Select语句对应的逻辑计划的类型是Project(映射)类型的逻辑计划。
访问类型配置成识别用户进行的访问操作。访问类型可以为插入、查询、更新和删除等。
驱动器可以通过Parse确定SQL语句的访问类型，例如，根据关键字映射到插入语法时，可确定访问类型为插入，根据关键字映射到删除语法时，可确定访问类型为删除等。根据SQL句的访问类型可将SQL语句映射到相应类型的逻辑计划，由此可以得到SQL语句的访问类型和逻辑计划的类型之间的映射关系，例如，访问类型为查询时，可将SQL语句映射到Project类型的逻辑计划，由此可以确定查询类型和Project类型具有映射关系。
驱动器利用Analyzer中设置的权限验证规则对该逻辑计划执行处理时，可以获取到该逻辑计划的类型以及访问资源标识。基于Parse处理得到的逻辑计划的类型和访问类型的映射关系，即可确定逻辑计划的类型对应的访问类型。
本公开的一种实施方式中，访问资源标识可以在词法解析阶段获取，例如可以获取到数据表的标识。
在本公开的另一种实施方式中，访问资源标识可以在语法解析阶段从逻辑计划获取。 相比在词法解析阶段获取访问资源标识，该方式可以获取更加详细的访问资源标识，例如可以获取到被访问的数据表的标识，以及该数据表中被访问的列的标识等信息。
访问资源标识可以为数据表名、数据表编号、列名、列编号等，对此本公开不做限制。
S133，将所述访问类型、访问资源标识和访问用户标识，确定为验证信息。
S134，通过调用所述第三方元数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
驱动器将验证信息传送给第三方元数据管理组件后，第三方元数据管理组件可以从数据库中获取已有的权限信息，将验证信息和权限信息进行比较，得到验证结果，第三方元数据管理组件会返回验证结果。验证过程由第三方元数据管理组件实现，节省了驱动器的资源。
在一个示例中，用户tom启动SparkSQL，并输入SQL语句Select*from salary。驱动器对接收的SQL语句进行词法解析，确定该语句对应访问类型为Select，在语法解析阶段生成类型为Project的逻辑计划，形成访问类型Select和逻辑的类型Project的映射。驱动器根据形成的映射，确定出Project对应的访问类型为Select。驱动器从SQL语句对应的逻辑计划中获取访问资源标识salary，并确定访问用户标识tom。驱动器将Select、salary和tom确定为验证信息，通过调用第三方元数据管理组件接口，使第三方元数据管理组件根据已有的权限信息对该验证信息进行验证。
根据本公开实施例的权限管理方法能够通过授权SQL语句将权限信息作为元数据，通过第三方元数据管理组件存储在数据库中，从而对用户授予访问某些资源的权限，并在接收到访问SQL语句时，根据权限信息对访问SQL语句的权限进行验证，实现了SparkSQL中的权限管理功能，提高了信息的安全性。
在又一种可能的实现方式中，S13可以包括图4所示的步骤，描述如下。
S135，在获得所述访问SQL语句对应的逻辑计划时，从所述逻辑计划中获取所述访问SQL语句的访问类型、访问资源标识和访问用户标识。
在此实现方式中，当接收到SQL语句时，驱动器可以通过Parse对接收到的访问SQL语句进行词法解析和语法解析，得到相应的Unresolved LogicalPlan；再通过Analyzer对该Unresolved LogicalPlan进行绑定，得到Resolved LogicalPlan；再通过Optimizer对得到的Resolved LogicalPlan进行优化。
其中，Analyzer中定义有至少一个分析规则(Analysis Rules)，Analyzer按照所述至少一个分析规则对Unresolved LogicalPlan进行绑定。Optimizer中定义有至少一个优化规则(Optimization Rules)，Optimizer按照所述至少一个优化规则对Resolved LogicalPlan进行优化。
在一种实施方式中，可以在Analyzer中增设一用于实现权限验证的分析规则(后称“第一权限验证规则”)。则，当驱动器中的Analyzer访问至该第一权限验证规则时，从Unresolved LogicalPlan中获取访问类型、访问资源标识以及访问用户标识作为验证信息，并调用第三方元数据管理组件的接口，以对所述验证信息进行验证。
可选地，所述第一权限验证规则可以配置成Analyzer中的第一个分析规则，如此，可以及时地终止对没有权限的访问SQL语句的处理。当然，将所述第一权限验证规则设置在其他分析规则之后也可实现本方案，本公开对此不做限制。
在又一种实施方式中，可以在Optimizer中增设一用于实现权限验证的优化规则(后称“第二权限验证规则”)。则，当驱动器中的Optimizer访问至该第二权限验证规则时，从Resolved LogicalPlan中获取访问类型、访问资源标识以及访问用户标识，并调用第三方元数据管理组件的接口，以对所述验证信息进行验证。
可选地，所述第二权限验证规则可以配置成Optimizer中的第一个优化规则，如此，可以及时地终止对没有权限的访问SQL语句的处理。应当理解，将所述第二权限验证规则设置在其他优化规则之前，本公开对此不做限制。
基于上述描述，S135中，所述访问SQL语句对应的逻辑计划可以是指Unresolved LogicalPlan(未绑定的逻辑计划)或者Resolved LogicalPlan(已绑定的逻辑计划)。
可选地，在本公开中，任一访问SQL语句的Unresolved LogicalPlan和Resolved LogicalPlan中，携带有用于表示该访问SQL语句的访问类型的关键字。例如，查询语句的Unresolved LogicalPlan和Resolved LogicalPlan中携带有关键字“SELECT”，插入语句的Unresolved LogicalPlan和Resolved LogicalPlan中携带有关键字“INSERT”，删除语句的Unresolved LogicalPlan和Resolved LogicalPlan中携带有关键字“DELETE”，更新语句的Unresolved LogicalPlan和Resolved LogicalPlan中携带有关键字“UPDATE”。基于此，对于任一访问SQL语句的逻辑计划(包括Unresolved LogicalPlan和Resolved LogicalPlan)，可以根据该逻辑计划中携带的关键字，获得该逻辑计划的访问类型。
S136，将所述访问类型、访问资源标识和访问用户标识确定为验证信息。
S137，通过调用所述第三方元数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
在一种可能的实现方式中，对所述验证信息进行验证可以包括：若存在授权用户标识与所述访问用户标识匹配、且授权资源标识与所述访问资源标识匹配、且授权类型与所述访问类型匹配的权限信息，则确定验证通过；否则，验证不通过。
第三方元数据管理组件在已有的权限信息中查找验证信息时，当访问用户标识和授权用户标识、访问资源标识和授权资源标识，以及访问类型和授权类型均匹配时，确认验证 通过。三者中任意一个不匹配，则确认验证未通过。
示例1，权限信息如表1所示，验证信息1包括访问用户标识用户1、访问类型查询和访问资源标识table1。如表1所示，权限信息3的授权资源标识为table1与验证信息1的访问资源标识table1匹配、权限信息3的授权类型为查询与验证信息1的访问类型查询匹配，且授权用户标识为用户1与验证信息1的访问用户标识用户1匹配，第三方元数据管理组件确定验证信息1对应的访问SQL语句验证通过。
表1
  授权用户标识 授权资源标识 授权类型
权限信息1 用户1 table1 删除
权限信息2 用户1 table2 查询
权限信息3 用户1 table1 查询
权限信息4 用户2 table1 更新
权限信息5 用户3 table2 全部权限
示例2，权限信息如表1所示，验证信息2包括访问用户标识用户1、访问类型更新和访问资源标识table1。如表1所示，不存在授权用户标识与验证信息2的访问用户标识匹配、授权资源标识与验证信息2的访问资源标识匹配，且授权类型与验证信息3的访问类型匹配的权限信息，第三方元数据管理组件确定验证信息2对应的访问SQL语句验证未通过。
图5示出根据本公开一实施例的权限管理装置的框图。如图4所示，该装置40包括：
获取模块41，配置成接收到授权SQL语句时，从所述授权SQL语句中获取权限信息；
调用模块42，配置成通过调用第三方元数据管理组件的接口，将所述权限信息作为元数据保存在数据库中；
验证模块43，配置成接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证。
在一种可能的实现方式中，所述获取模块41还配置成：
对接收到的SQL语句进行词法解析，获取关键字；
若所述关键字映射到授权语法，则按照所述授权语法，从所接收到的SQL语句中获取授权用户标识、授权资源标识和授权类型，作为权限信息。
在一种可能的实现方式中，所述授权类型包括插入、查询、更新和删除中的一者或多者。
在一种可能的实现方式中，所述验证模块43还配置成；
接收到访问SQL语句时，获取所述访问SQL语句对应的访问用户标识以及逻辑计划；
确定所述逻辑计划的类型对应的访问类型、并从所述逻辑计划中获取访问资源标识；
将所述访问类型、访问资源标识和访问用户标识，确定为验证信息；
通过调用所述第三方元数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
在一种可能的实现方式中，所述装置还包括第三方元数据管理组件44，所述第三方元数据管理组件配置成：
若存在授权用户标识与所述访问用户标识匹配、且授权资源标识与所述访问资源标识匹配、且授权类型与所述访问类型匹配的权限信息，则确定验证通过；否则，验证不通过。
根据本公开实施例的权限管理装置能够通过授权SQL语句将权限信息作为元数据，通过第三方元数据管理组件存储在数据库中，从而对用户授予访问某些资源的权限，并在接收到访问SQL语句时，根据权限信息对访问SQL语句的权限进行验证，实现了SparkSQL中的权限管理功能，提高了信息的安全性。
图6是根据一示例示出的一种配置成权限管理的装置900的框图。参照图6，该装置900可包括处理器901、存储有机器可执行指令的机器可读存储介质902。处理器901与机器可读存储介质902可经由系统总线903通信。并且，处理器901通过读取机器可读存储介质902中与权限管理逻辑对应的机器可执行指令以执行上文所述的权限管理方法。
本文中提到的机器可读存储介质902可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。
以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (15)

  1. 一种权限管理方法，其特征在于，所述方法包括：
    接收到授权SQL语句时，从所述授权SQL语句中获取权限信息；
    通过调用第三方元数据管理组件的接口，将所述权限信息作为元数据保存在数据库中；
    接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证。
  2. 根据权利要求1所述的方法，其特征在于，所述接收到授权SQL语句时，从所述授权SQL语句中获取权限信息，包括：
    对接收到的SQL语句进行词法解析，获取关键字；
    若所述关键字映射到授权语法，则按照所述授权语法，从所接收到的SQL语句中获取授权用户标识、授权资源标识和授权类型，作为权限信息。
  3. 根据权利要求2所述的方法，其特征在于，所述授权类型包括插入、查询、更新和删除中的一者或多者。
  4. 根据权利要求1所述的方法，其特征在于，所述接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证包括：
    接收到访问SQL语句时，获取所述访问SQL语句对应的访问用户标识以及逻辑计划；
    确定所述逻辑计划的类型对应的访问类型、并从所述逻辑计划中获取访问资源标识；
    将所述访问类型、访问资源标识和访问用户标识，确定为验证信息；
    通过调用所述第三方元数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
  5. 根据权利要求1所述的方法，其特征在于，所述接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证包括：
    在获得所述访问SQL语句对应的逻辑计划时，从所述逻辑计划中获取所述访问SQL语句的访问类型、访问资源标识和访问用户标识；
    将所述访问类型、访问资源标识和访问用户标识确定为验证信息；
    通过调用所述第三方元数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
  6. 根据权利要求5所述的方法，其特征在于，所述访问SQL语句对应的逻辑计划为已绑定的逻辑计划或未绑定的逻辑计划。
  7. 根据权利要求4-6中任意一项所述的方法，其特征在于，所述对所述验证信息进行验证，包括：
    若存在授权用户标识与所述访问用户标识匹配、且授权资源标识与所述访问资源标识 匹配、且授权类型与所述访问类型匹配的权限信息，则确定验证通过；否则，验证不通过。
  8. 一种权限管理装置，其特征在于，所述装置包括：
    获取模块，配置成接收到授权SQL语句时，从所述授权SQL语句中获取权限信息；
    调用模块，配置成通过调用第三方元数据管理组件的接口，将所述权限信息作为元数据保存在数据库中；
    验证模块，配置成接收到访问SQL语句时，根据所述权限信息对所述访问SQL语句的权限进行验证。
  9. 根据权利要求8所述的装置，其特征在于，所述获取模块还配置成：
    对接收到的SQL语句进行词法解析，获取关键字；
    若所述关键字映射到授权语法，则按照所述授权语法，从所接收到的SQL语句中获取授权用户标识、授权资源标识和授权类型，作为权限信息。
  10. 根据权利要求9所述的装置，其特征在于，所述授权类型包括插入、查询、更新和删除中的一者或多者。
  11. 根据权利要求8所述的装置，其特征在于，所述验证模块还配置成：
    接收到访问SQL语句时，获取所述访问SQL语句对应的访问用户标识以及逻辑计划；
    确定所述逻辑计划的类型对应的访问类型、并从所述逻辑计划中获取访问资源标识；
    将所述访问类型、访问资源标识和访问用户标识，确定为验证信息；
    通过调用所述第三方元数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
  12. 根据权利要求8所述的装置，其特征在于，所述验证模块还配置成：
    在获得所述访问SQL语句对应的逻辑计划时，从所述逻辑计划中获取所述访问SQL语句的访问类型、访问资源标识和访问用户标识；
    将所述访问类型、访问资源标识和访问用户标识确定为验证信息；
    通过调用所述第三方数据管理组件的接口，以使所述第三方元数据管理组件根据所述权限信息对所述验证信息进行验证。
  13. 根据权利要求11或12所述的装置，其特征在于，所述装置还包括第三方元数据管理组件，所述第三方元数据管理组件配置成：
    若存在授权用户标识与所述访问用户标识匹配、且授权资源标识与所述访问资源标识匹配、且授权类型与所述访问类型匹配的权限信息，则确定验证通过；否则，验证不通过。
  14. 一种权限管理装置，其特征在于，包括：
    处理器和机器可读存储介质，所述机器可读存储介质存储有机器可执行指令，所述处理器执行所述机器可执行指令以实现权利要求1至7中任意一项所述的方法。
  15. 一种机器可读存储介质，其特征在于，所述机器可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现权利要求1至7中任意一项所述的方法。
PCT/CN2019/084216 2018-04-25 2019-04-25 权限管理方法及装置 WO2019206211A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810378730.3 2018-04-25
CN201810378730.3A CN109766686A (zh) 2018-04-25 2018-04-25 权限管理

Publications (1)

Publication Number Publication Date
WO2019206211A1 true WO2019206211A1 (zh) 2019-10-31

Family

ID=66449628

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/084216 WO2019206211A1 (zh) 2018-04-25 2019-04-25 权限管理方法及装置

Country Status (2)

Country Link
CN (1) CN109766686A (zh)
WO (1) WO2019206211A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110287686B (zh) * 2019-06-24 2021-06-15 深圳市同泰怡信息技术有限公司 一种基本输入输出系统的安全启动权限管理方法以及设备
CN110532279A (zh) * 2019-07-12 2019-12-03 平安普惠企业管理有限公司 大数据平台权限控制方法、装置、计算机设备及存储介质
CN111737293A (zh) * 2019-10-21 2020-10-02 北京京东尚科信息技术有限公司 一种数据仓库权限管理方法、装置、设备和存储介质
CN111767574A (zh) * 2020-06-28 2020-10-13 北京天融信网络安全技术有限公司 用户权限确定方法、装置、电子设备及可读存储介质
CN111767572A (zh) * 2020-06-28 2020-10-13 北京天融信网络安全技术有限公司 一种安全访问数据库的方法及装置
CN112231686B (zh) * 2020-10-20 2024-02-27 城云科技（中国）有限公司 一种基于安全认证标识的系统安全认证方法和装置
CN115757526B (zh) * 2022-12-02 2023-08-15 广州市玄武无线科技股份有限公司 一种元数据的管理方法、装置、设备和计算机存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103530568A (zh) * 2012-07-02 2014-01-22 阿里巴巴集团控股有限公司 权限控制方法、装置及系统
CN105912949A (zh) * 2016-04-13 2016-08-31 北京京东尚科信息技术有限公司 数据权限管理方法、数据权限管理系统以及业务管理系统
CN107403106A (zh) * 2017-07-18 2017-11-28 北京计算机技术及应用研究所 基于终端用户的数据库细粒度访问控制方法
CN107622211A (zh) * 2017-09-27 2018-01-23 浪潮软件股份有限公司 一种大数据集群权限访问控制方法及装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101515931B (zh) * 2009-03-24 2012-09-19 北京理工大学 一种基于代理方式的数据库安全增强方法
CN101789027A (zh) * 2010-03-15 2010-07-28 江苏大学 一种基于dbms的元数据管理方法和元数据服务器
CN102184371B (zh) * 2011-04-15 2013-03-20 国都兴业信息审计系统技术（北京）有限公司 Sql语句的数据库操作权限检测方法与系统
CN102508898A (zh) * 2011-11-04 2012-06-20 浪潮(北京)电子信息产业有限公司 一种基于云计算的数据访问方法和数据库系统
CN102722667B (zh) * 2012-03-07 2015-12-02 甘肃省电力公司信息通信公司 基于虚拟数据库和虚拟补丁的数据库安全防护系统和方法
CN103294966B (zh) * 2013-03-12 2016-02-24 中国工商银行股份有限公司 一种数据库的安全访问控制方法以及系统
CN104766023B (zh) * 2015-02-02 2017-09-19 苏州全维软件科技有限公司 基于oracle数据库的用户管理方法
CN105786998B (zh) * 2016-02-19 2019-02-26 创元网络技术股份有限公司 数据库中间件系统及利用其处理数据的方法
CN107239710B (zh) * 2016-03-29 2020-06-16 北京明略软件系统有限公司 一种数据库权限实现方法和系统
CN107832618B (zh) * 2017-09-20 2019-12-24 武汉虹旭信息技术有限责任公司 一种基于细粒度权限控制的sql注入检测系统及其方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103530568A (zh) * 2012-07-02 2014-01-22 阿里巴巴集团控股有限公司 权限控制方法、装置及系统
CN105912949A (zh) * 2016-04-13 2016-08-31 北京京东尚科信息技术有限公司 数据权限管理方法、数据权限管理系统以及业务管理系统
CN107403106A (zh) * 2017-07-18 2017-11-28 北京计算机技术及应用研究所 基于终端用户的数据库细粒度访问控制方法
CN107622211A (zh) * 2017-09-27 2018-01-23 浪潮软件股份有限公司 一种大数据集群权限访问控制方法及装置

Also Published As

Publication number Publication date
CN109766686A (zh) 2019-05-17

Similar Documents

Publication Publication Date Title
WO2019206211A1 (zh) 权限管理方法及装置
CN109144978B (zh) 权限管理方法及装置
US10176222B2 (en) Query plan optimization for prepared SQL statements
US10757106B2 (en) Resource access control method and device
JP7038710B2 (ja) データ管理方法及びシステム
JP4842279B2 (ja) データベースサーバによるファイル操作を実行するためのインフラストラクチャ
US8510316B2 (en) Database processing system and method
US9043309B2 (en) SQL transformation-based optimization techniques for enforcement of data access control
US20150363610A1 (en) Common users, common roles, and commonly granted privileges and roles in container databases
US7548918B2 (en) Techniques for maintaining consistency for different requestors of files in a database management system
US10936478B2 (en) Fast change impact analysis tool for large-scale software systems
US20130198231A1 (en) Distributed query cache in a database system
AU2005317196A1 (en) Techniques for providing locks for file operations in a database management system
US20150095973A1 (en) Cloud database lockdown
CN109543448B (zh) Hdfs文件访问权限控制方法、设备及存储介质
KR20200094074A (ko) 인덱스 관리 방법, 장치, 기기 및 저장 매체
CN113056734A (zh) 管理共享数据库的系统和方法
CN117421302A (zh) 一种数据处理方法及相关设备
US20050097090A1 (en) System and method for managing query access to information
CN109446219B (zh) 权限管理方法及装置
JP2001075854A (ja) データ管理方法、およびデータ管理システム、ならびにデータ管理プログラムを格納した記憶媒体
CN113626870A (zh) 访问控制方法、装置、电子设备及存储介质
US7716260B2 (en) Techniques for transaction semantics for a database server performing file operations
CN116204546A (zh) Sql预编译方法、装置、服务器和存储介质
CN117494173B (zh) 一种控制策略的管理方法、系统、设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19792507

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19792507

Country of ref document: EP

Kind code of ref document: A1