CN116346479A - 数据访问方法、装置、设备和存储介质 - Google Patents

Abstract

本公开的实施例提供了数据访问的方法、装置、设备和存储介质。该方法包括：获取用于对请求进行鉴权的鉴权上下文，请求是向当前服务发出的并且用于数据访问，鉴权上下文是基于请求或由当前服务生成的对请求的响应中的至少一项生成的；基于鉴权上下文和至少一个鉴权策略，生成针对请求的鉴权结果；以及提供与鉴权结果相对应的反馈，以代理当前服务对请求进行响应。以此方式，在实现了针对数据的访问管控的同时，能够有效降低成本，提升数据访问的效率，降低数据访问的延时。

Description

数据访问方法、装置、设备和存储介质

技术领域

本公开的示例实施例总体涉及计算机领域，特别地涉及数据访问方法、装置、设备和计算机可读存储介质。

背景技术

智能化服务是建立在大数据的采集和使用的基础上。各个地区出台了很多关于数据保护相关的法律法规，提供智能化服务的产品在使用数据时需要进行数据保护。因此，针对用户数据访问的在线网络请求，需要有效的数据保护方案。

发明内容

在本公开的第一方面，提供了一种数据访问方法。该方法包括：获取用于对请求进行鉴权的鉴权上下文，所述请求是向当前服务发出的并且用于数据访问，所述鉴权上下文是基于所述请求或由所述当前服务生成的对所述请求的响应中的至少一项生成的；基于所述鉴权上下文和至少一个鉴权策略，生成针对所述请求的鉴权结果；以及提供与所述鉴权结果相对应的反馈，以代理所述当前服务对所述请求进行响应。

在本公开的第二方面，提供了一种数据访问装置。该装置包括：上下文获取模块，被配置为获取用于对请求进行鉴权的鉴权上下文，所述请求是向当前服务发出的并且用于数据访问，所述鉴权上下文是基于所述请求或由所述当前服务生成的对所述请求的响应中的至少一项生成的；鉴权结果生成模块，被配置为基于所述鉴权上下文和至少一个鉴权策略，生成针对所述请求的鉴权结果；以及反馈提供模块，被配置为提供与所述鉴权结果相对应的反馈，以代理所述当前服务对所述请求进行响应。

在本公开的第三方面，提供了一种电子设备。该设备包括至少一个处理单元；以及至少一个存储器，至少一个存储器被耦合到至少一个处理单元并且存储用于由至少一个处理单元执行的指令。指令在由至少一个处理单元执行时使设备执行第一方面的方法。

在本公开的第四方面，提供了一种计算机可读存储介质。介质上存储有计算机程序，计算机程序被处理器执行时实现第一方面的方法。

应当理解，本发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键特征或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的描述而变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了本公开的实施例能够在其中实现的示例环境的示意图；

图2示出了根据本公开的一些实施例的数据访问系统的示例架构的示意图；

图3A示出了根据本公开的一些实施例的数据访问的数据流的示意图；

图3B示出了根据本公开的一些实施例的数据访问系统的示意性框图；

图4A示出了根据本公开的一些实施例的标签设置的示例界面的示意图；

图4B示出了根据本公开的一些实施例的标注设置的一个示例界面的示意图；

图5示出了根据本公开的一些实施例的数据访问的过程的流程图；

图6示出了根据本公开的一些实施例的数据访问装置的框图；以及

图7示出了其中可以实施本公开的一个或多个实施例的电子设备。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中示出了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反，提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实施例的描述中，术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“一些实施例”应当理解为“至少一些实施例”。下文还可能包括其他明确的和隐含的定义。

在本文中，除非明确说明，“响应于A”执行一个步骤并不意味着在“A”之后立即执行该步骤，而是可以包括一个或多个中间步骤。

可以理解的是，本技术方案所涉及的数据(包括但不限于数据本身、数据的获得或使用)应当遵循相应法律法规及相关规定的要求。

可以理解的是，在使用本公开各实施例公开的技术方案之前，均应当根据相关法律法规通过适当的方式对本公开所涉及个人信息的类型、使用范围、使用场景等告知用户并获得用户的授权。

例如，在响应于接收到用户的主动请求时，向用户发送提示信息，以明确地提示用户，其请求执行的操作将需要获得和使用到用户的个人信息，从而使得用户可以根据提示信息来自主地选择是否向执行本公开技术方案的操作的电子设备、应用程序、服务器或存储介质等软件或硬件提供个人信息。

作为一种可选的但非限制性的实现方式，响应于接收到用户的主动请求，向用户发送提示信息的方式，例如可以是弹窗的方式，弹窗中可以以文字的方式呈现提示信息。此外，弹窗中还可以承载供用户选择“同意”或“不同意”向电子设备提供个人信息的选择控件。

可以理解的是，上述通知和获得用户授权过程仅是示意性的，不对本公开的实现方式构成限定，其他满足相关法律法规的方式也可应用于本公开的实现方式中。

如本文中所使用的，术语“鉴权”是指验证数据访问请求的发起方(例如，终端用户)是否具有访问数据的权限。术语“鉴权策略”是指鉴权所使用的一个或多个规则。在本文中，术语“策略”和“规则”可以可互换地使用。

图1示出了本公开的实施例能够在其中实现的示例环境100的示意图。在环境100中，来自客户端的业务请求(即，数据访问请求)通常从接入层(诸如网关层，未示出)发起。接入层将来自客户端的流量进行路由。在路由之后，请求进入应用层110。应用层110将客户端所需的数据组装好，为此应用层110请求更底层的服务节点，即一个或多个服务。也即，应用层110通过一个或多个服务访问数据源。一个或多个服务从最底层的数据源获取数据，然后将数据返回给上一层。在最底层，即数据库层，存储的数据被提供给上游使用。这样的数据可能包括需要被保护的数据(也称为受保护数据)。

一个或多个服务例如包括用于处理不同业务逻辑的服务120-1、服务120-2、服务120-3、……、服务120-N(统称或单独称为服务120)，其中N是正整数。不同服务120之间相互协调、相互配合。每个服务120运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够独立部署。在一个示例中，服务120可以是微服务。微服务由许多较小的、松散耦合的服务组成一个应用程序。

数据源可以是数据库应用程序所使用的数据库或者数据库服务器。在图1的示例中，数据源例如包括数据库130-1、数据库130-2、数据库130-3、……、数据库130-N(统称或单独称为数据库130)。

例如，用户A访问用户B的主页，通过应用层110发出查看用户B的生日的请求。服务120接收请求并访问数据库130，读取数据库130中关于用户B的生日数据。而后，将包含用户B的生日数据的响应返回给应用层110。

环境100还可以包括超文本传输协议(Hyper Text Transfer Protocol，简称HTTP)服务(未示出)。在一些实施例中，服务120可以是远程过程调用(Remote ProcedureCall，简称RPC)服务。例如，用户经由应用层110发出访问数据的请求，HTTP服务内部通过session_lib等方式获取用户身份、调用下游RPC服务，以访问数据库130，实现业务逻辑。

应当理解，仅出于示例性的目的描述示例环境100的结构和功能，而不暗示对于本公开的范围的任何限制。

如前文所简要提及的，图1中的服务120可以是微服务。微服务是一种开发软件的架构和组织方法。软件由通过明确定义的应用程序接口(Application ProgrammingInterface，API)进行通信的小型独立的多个服务组成。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务是围绕业务功能构建的，换言之，每个服务执行一项功能。因此可以针对各个服务进行更新、部署和扩展，以满足对应用特定功能的需求。

目前，由于微服务的自主性和专业性等特点，微服务架构的应用越来越广泛。在微服务架构下，由于不同服务之间的调用、交互等场景比较复杂，因此，对数据(例如，用户数据)的保护显得尤为重要。

在一些情况下，微服务架构下对数据进行访问管控，从而实现对数据(例如，受保护数据)的保护。传统上，存在三种对数据的访问管控方案。在第一种方案中，在各个独立运行的服务中分布有与服务相对应的逻辑控制模块。这些独立的逻辑控制模块用于针对与逻辑控制模块相对应的服务要访问的数据进行访问管控，从而实现对数据的保护。换言之，由分属各个功能的服务自行实现数据访问的管控。在第二种方案中，在各个独立运行的服务和数据源之间设置中心化服务，通过中心化服务来实现对数据的保护。具体而言，分属各个功能的服务从数据源获取数据之前，都通过访问该中心化服务来得到数据访问的授权，从而实现对数据的访问管控。在第三种方案中，在各个独立运行的服务中统一接入标准化的软件开发工具包(SDK)，SDK用于对访问数据的请求进行鉴权得到鉴权结果。分属各个功能的服务可以同时访问SDK，并且根据SDK的鉴权结果调整请求的结果，从而实现服务要访问对数据的访问管控。

然而，这些传统方案存在一些问题。一方面，对于第一种和第三种方案，由于分属各个功能的服务均独立处理业务逻辑，相互之间并不依赖，导致这些服务针对数据的访问管控的控制逻辑并不统一，并且控制逻辑依赖于开发者的自觉性，导致微服务架构的开发、维护、优化的成本较高。对于第二种方案，在各个独立运行的服务之间增加一个访问节点(例如，中心化服务)，不仅限制整个微服务架构的扩展性，还导致访问延时升高，访问数据的效率降低。此外，管控逻辑也依赖于服务开发者的自觉性。

根据本公开的实施例，提出了一种数据访问方案。根据该方案，基于向当前服务发出的并且用于数据访问的请求或由当前服务生成的对请求的响应中的至少一项生成鉴权上下文。进一步地，获取鉴权上下文，并且基于鉴权上下文和至少一个鉴权策略生成针对该请求的鉴权结果。提供与鉴权结果相对应的反馈，以代理当前服务对请求进行响应。例如，在鉴权结果指示拒绝该请求的情况下，提供负反馈(例如，拒绝数据访问的响应)。在鉴权结果指示修改的情况下，提供更新后的响应。在鉴权结果指示通过的情况下，提供当前服务生成的响应。

以此方式，对向各个服务发出的数据访问的请求进行统一、标准化鉴权，在实现了针对数据的访问管控的同时，能够有效降低成本(例如，开发、维护、优化微服务架构的成本)，提升数据访问的效率，降低数据访问的延时。

以下将继续参考附图描述本公开的一些示例实施例。

图2示出了根据本公开的一些实施例的数据访问系统200的示例架构的示意图。数据访问系统200包括分布式模块210-1、分布式模块210-2、分布式模块210-3、……、分布式模块210-N(统称为分布式模块210)以及控制模块220。数据访问系统200可以实现在环境100中。下面参考图1描述数据访问系统200。

分布式模块210用于鉴权，即验证用户是否拥有访问数据的权限。例如，分布式模块210从引入的流量中解析请求、响应以及鉴权上下文。分布式模块210根据鉴权上下文构建鉴权输入、执行鉴权策略(也简称为策略)并根据鉴权结果执行相应的鉴权动作。分布式模块210可以与其所负责鉴权的服务部署或实现在同一主机(host)中。

鉴权输入包括请求发起方的信息、访问方的信息以及上下文信息。请求发起方的信息例如包括请求来自哪个用户、哪个应用、第一跳和上一跳的内部服务标识(ProductSubsys Module，PSM)是谁、请求发起方的位置信息、发起请求的网址、发起请求的路径等等。访问方的信息例如包括要访问哪个应用或服务、哪个用户，等等。上下文信息例如包括发起方和访问方的关系、访问了哪些信息，等等。

鉴权策略例如包括未成年用户信息只能被绑定某一数据秘钥的PSM用户访问、某平台的用户的生日信息只能被其好友访问，等等。

鉴权动作执行包括根据鉴权策略的执行结果，执行相应的动作，修改响应信息进行返回。执行的动作例如包括对一个或多个字段执行擦除、拦截，等等。

作为一个示例，用户A访问用户B的主页，查看生日信息。分布式模块210提取鉴权上下文，确认用户A要访问用户B的生日信息，但用户A和用户B不是好友。基于用户的生日信息只能被其好友访问的鉴权策略，确定用户A没有查看用户B的生日信息的权限。由此，执行擦除生日信息的动作，返回新的响应。

分布式模块210可以挂载在服务120上，作为与服务120部分地独立的进程运行在业务实例中。由此，可以降低调用延时，去除中心化带来的性能瓶颈和稳定性影响。此外，由于服务120更靠近数据库130，可以从数据源头保护数据，防止数据泄露。

控制模块220可以是独立的配置平台，用于接收用户配置并分发。管理员或安全团队可以通过控制模块220设置流量控制、安全或访问控制等策略。例如，管理员通过控制模块220对分布式模块210-1进行鉴权策略配置或运维配置。控制模块220传送指令、封装数据并转发，实现将配置下发给分布式模块210。分布式模块210基于下发的配置可以动态操作数据，以实现在线数据保护。此外，多个分布式模块210可以共享控制模块220。

图3A示出了根据本公开的一些实施例的数据访问的数据流300A示意图。数据流300A可以在数据访问系统200处实现。为便于讨论，将参考图2的数据访问系统200来描述数据流300A。

应用层110向服务(也称为当前服务)发出用于数据访问的请求301。例如，请求301可以来自当前服务的上游服务。。例如，如果当前服务120为RPC服务，那么RPC服务发出的请求可以是RPC请求。作为示例，请求可以包括请求的身份标识信息。如上文所述，请求的身份标识信息例如请求发起方的信息、访问方的信息以及上下文信息。接下来，数据访问系统200可以利用处理程序(Handler)来对请求301进行业务逻辑处理。例如，处理程序可以是RPC Handler。在利用与当前服务对应的业务逻辑360对请求进行处理之后，向数据库130发出访问数据的请求，以从数据库130中获取相应的数据。获取的数据中可能包含有需要保护的数据。数据库130返回访问数据的响应。由处理程序对访问数据的响应进行处理生成原始响应。

以上描述了数据访问的一般过程。数据访问系统200可以通过控制模块220和各个服务对应的分布式模块210对各个服务的数据访问进行管控。分布式模块210用于对向当前服务发出的并且用于数据访问的请求进行鉴权，生成鉴权结果，并且提供与鉴权结果相对应的反馈，以代理当前服务120对请求进行响应。作为示例，在图3A中，分布式模块210接收向当前服务发出的请求301。分布式模块210可以包括接入点模块330和更新模块340。接入点模块330可以被配置为向服务提供接入方式。也即，分布式模块210通过接入点模块330接入当前服务120，使得当前服务120可以使用分布式模块210的各种功能(例如，鉴权功能)。接入点模块330被配置为获取对请求进行鉴权的鉴权上下文。接入点模块330将鉴权上下文发送至更新模块340。更新模块340被配置为基于鉴权上下文和至少一个鉴权策略生成针对请求的鉴权结果。更新模块340将鉴权结果返回至接入点模块330，接入点模块330提供与鉴权结果相对应的反馈，以代理当前服务请求进行响应。可以理解，分布式模块210的实现方式包括但不限于上述文中所描述的接入点模块330和更新模块340，还可以以任意适当数目、功能的其它模块来实现，本实施例不做具体限定。

如图3所示，接入点模块330可以包括数据抽取模块331。数据抽取模块331用于对请求301或服务120生成的针对请求301的原始响应进行处理，以获取对请求进行鉴权的鉴权上下文。作为示例，鉴权上下文可以包括标准化的信息。例如，标准化的信息可以是具有预定格式、预定类型的信息(在下文中进行更详细的解释)。具体而言，在图3A的示例中，数据抽取模块331可以对请求301或原始响应进行解析，得到原始的鉴权上下文。在一些实施例中，数据抽取模块331还可以进一步将原始的鉴权上下文转换为标准的鉴权上下文。在解析完成之后，如上文所述，数据访问系统200可以利用处理程序来对请求进行上文中所述的业务逻辑处理。此时，分布式模块210并不会干扰业务逻辑处理的流程。对请求进行业务逻辑处理之后，请求的原始响应返回至分布式模块210。

接入点模块330还可以包括动作模块332、路由模块333。路由模块333基于路由规则和请求的信息(例如，请求的身份标识信息)判断是否需要对请求301进行鉴权。例如，如果请求来自一些已被授权的特定的应用(例如，某社交类应用)，则不需要鉴权。如果请求301来自一些非特定网站、应用，则需要鉴权。如果请求301不需要鉴权，则可以直接提供该请求301的原始响应，例如原始响应可以直接返回至上游服务。如果请求301需要鉴权，则路由模块333将原始响应发送至数据抽取模块331。数据抽取模块331从原始响应中提取信息，与从请求301中提取的信息一起作为鉴权上下文。备选的，如果请求301为读请求，在请求301进入业务逻辑360之前，可以不从请求301中提起鉴权信息，而是可以与原始响应一起提取鉴权信息，以生成鉴权上下文。

接下来，鉴权上下文可以经由动作模块332而被提供给更新模块340。例如，动作模块332向更新模块340发起针对请求301的权限检查。具体地，动作模块332将数据抽取模块331对请求301和原始响应进行解析得到的鉴权上下文发送至更新模块340，以由更新模块340对请求301进行鉴权。

更新模块340基于鉴权上下文和至少一个鉴权策略，生成针对请求301的鉴权结果。更新模块340可以包括鉴权模块341和至少一个策略加载器。在图3A的示例中，策略加载器例如包括策略加载器350-1、策略加载器350-2…策略加载器350-N(其也统称或单独称为策略加载器350)。每个策略加载器350用于向鉴权上下文应用对应的鉴权策略。

在一些实施例中，鉴权模块341可以被配置为将原始的鉴权上下文转换为标准的鉴权上下文。也即，数据抽取模块331和鉴权模块341中的任一模块可以对原始的鉴权上下文进行转换(例如，封装)，从而得到标准的鉴权上下文。鉴权模块341根据鉴权上下文(例如，标准的鉴权上下文)从多个策略加载器中选择对应策略加载器执行鉴权，从而生成针对请求301的鉴权结果。备选地，鉴权模块341还可以根据鉴权上下文从多个策略加载器中选择多个策略加载器的集合执行鉴权。具体的，鉴权模块341可以遍历集合中的全部策略加载器以确定出与请求301相关联的多个策略加载器，然后利用这些策略加载器生成多个中间鉴权结果。而后，对多个中间鉴权结果进行聚合，生成最终的鉴权结果。

更新模块340将鉴权结果返回至接入点模块330。接入点模块330中的动作模块332可以针对更新模块340返回的针对请求301的鉴权结果提供相对应的反馈。这样的反馈能够代理当前服务对请求301进行响应。例如，在鉴权结果指示拒绝该请求的情况下，提供负反馈(例如，拒绝数据访问的响应)。在鉴权结果指示修改的情况下，提供更新后的响应。在鉴权结果指示通过的情况下，提供当前服务生成的响应。也就是说，这样的反馈可以代替原始响应返回至上游服务。在一些实施例中，接入点模块330经由以下至少之一提供反馈：用于处理当前服务与其他服务之间的通信的代理，或位于当前服务与应用层之间的中间件。通信的代理例如，无线网格网络(例如，Mesh Sidecar，网格边车模式)。当前服务与应用层之间的中间件例如不同语言的中间件(例如，针对Go语言的KiteX框架、针对Java语言的Spring Boot框架)。

以上描述的数据抽取模块331、路由模块333、动作模块332和更新模块340可以视为数据面。控制模块220可以是独立于各个服务的模块。控制模块220和分布式模块210可以是解耦的。控制模块220用于生成鉴权的配置信息，并且将配置信息发送至分布式模块210，以对其进行配置。在一些实施例中，配置信息指示以下至少一项：请求中用于鉴权的一个或多个字段(例如，受保护字段、取值字段、鉴权字段的标注信息)，响应中用于鉴权的一个或多个字段(例如，受保护字段、取值字段、鉴权字段的标注信息)，或请求需要被鉴权的条件。例如，请求需要被鉴权的条件可以包括请求的响应中包括需要被保护的字段或数据，例如，受保护字段、受保护数据，等等。以此方式，管理员或安全团队可以通过控制模块220调整数据访问管控的配置。

控制模块220可以将配置信息例如鉴权策略发送至更新模块340。例如，控制模块220可以周期性发送更新后的鉴权策略至更新模块340。备选地，如果鉴权策略一旦被更新，控制模块220可以立即发送更新后的鉴权策略至更新模块340。由此，更新模块340可以在不调整业务逻辑的代码的情况下，基于配置信息动态更新鉴权策略。控制模块220还可以将配置信息(例如路由规则)发送至路由模块333。由此，路由模块333可以基于配置信息动态更新路由规则，以确定哪些请求需要鉴权。在一些实施例中，控制模块220可以包括标注模块371、观测模块372、发布模块373、路由模块374。将在下文对此进行更详细的描述。

参考图2和图3A描述了通过分布式模块210对请求进行鉴权，并且基于鉴权结果提供针对数据访问请求的反馈(例如，拒绝、修改、通过)，以针对请求访问的受保护数据等进行有效保护。以上仅给出了数据访问的数据流的示例，可以理解，接入点模块330和更新模块340的实现方式包括但不限于上述文中所描述的，还可以以任意适当数目、功能的其它模块来实现。

上文参考图3A从数据流的角度描述了数据访问过程。下面参考图3B来具体介绍数据访问系统200中的各个模块的功能。图3B示出了根据本公开的一些实施例的数据访问系统的示意性框图。如图3B所示，总体上，数据访问系统200可以包括接入点320、数据面390、控制面330。接入点320和数据面390可以被实现为分布式模块210，控制面330可以被实现为控制模块220。数据访问系统200所管控的服务可以包括各种合适类型的服务，例如但不限于，BIZ服务、平台服务、Cronjob服务、API服务等。

接入点320旨在为服务提供使用鉴权功能的接入方式。接入点320可以被配置为针对服务中的业务逻辑提供多种接入方式，以使得不同的业务可以根据自身的业务逻辑选择适合的接入方式。例如，接入方式可以包括无线网格网络、不同语言的中间件。也即，服务可以通过无线网格网络、不同语言的中间件来使用分布式模块210的功能。通过多样化的接入方式能够降低对服务的代码(例如，用户代码)的干扰，同时提高对数据(例如，用户数据)的管控。接入点320还可以进一步被配置为针对服务的业务逻辑提供标准化的接入方式，以使得业务可以根据业务逻辑按照标准化的步骤接入服务。

在这样的实施例中，分布式模块210通过接入点320提供的多种接入方式接入服务120，无需进行代码改造或者极少修改代码，具有较低的接入成本。例如，如果通过边车模式接入服务120，针对服务120中的业务逻辑无需进行代码改造。如果通过中间件接入服务120，针对服务120中的业务逻辑可以修改较少的代码。相比上文所述的现有的第一和第三种方案，明显降低代码改造成本。

在一些实施例中，数据面390用于通过对请求和/或响应进行解析得到鉴权上下文，根据鉴权上下文判断是否需要鉴权。进一步地，数据面390可以根据鉴权上下文和至少一个鉴权策略执行鉴权，以得到鉴权结果，并且根据鉴权结果调整针对请求的响应(也即，原始响应)，返回调整后的响应至应用层110。数据面390可以包括数据抽取模块331、路由模块333、更新模块340、动作模块332。

数据抽取模块331可以被配置为针对请求和/或响应抽取鉴权上下文。鉴权上下文例如终端流量身份标识上下文、请求目的上下文、请求来源上下文。通过鉴权上下文可以判断出当前请求是来源于哪个用户、由哪个服务发起，要对哪个服务的哪些数据进行访问。在一些实施例中，鉴权上下文可以是标准化的，例如可以包括预定类型信息。预定类型信息例如包括以下至少一项：与请求的发起有关的身份信息(也称为流量身份信息)，与当前服务的上游服务和下游服务有关的上下游信息，或与请求中的鉴权主体有关的主体信息。

作为一个示例，数据抽取模块331可以对抽取的鉴权上下文(也即，原始的鉴权上下文)进行封装，得到标准的鉴权上下文(例如，预定类型信息)。示例性地，数据抽取模块331可以将抽取的鉴权上下文封装为三种预定类型信息。

身份信息例如可以被实现为流量身份标志。流量身份信息代表了本次流量的源头身份，也即代表流量起点。流量身份信息可以包括发起的用户标识、发起的API地址、发起的用户身份、发起的服务节点等。具体地，流量身份信息例如可以包括：Meta标签(html语言头部head区的一个辅助性标签)类信息，例如协议相关信息；用户类信息，例如流量的用户维度相关信息，这样的用户维度相关信息可以标识流量来自哪个用户；设备类信息，例如流量的设备维度相关信息，这样的设备维度相关信息可以标识流量来自哪个设备；地域类信息，例如用户数据户口相关的参数，这样的参数可以标识用户数据所在机房、地区等；应用类信息，例如流量的所属应用相关信息，这样的信息可以标识流量来自哪个应用；服务类信息，例如流量的起始服务相关信息，这样的信息可以标识流量的入口API服务信息；请求类信息，例如流量的请求相关信息，这样的信息可以标识流量的域名或请求路径；场景类信息，例如流量的场景属性信息，这样的属性信息可以标识流量是否属于压测流量。

上下游信息例如可以被实现为RPC端点信息(RPC EndPoint Information)，其表示当前请求的上一跳信息以及下一跳信息。上下游信息可以包括上游服务的信息，例如服务名、服务地址、服务调用方法。上下游信息还可以包括下游服务的信息，例如服务名、服务地址、服务调用方法。

主体信息可以被实现为鉴权点信息(Auth Point Information)。示例性地，鉴权节点信息表示了本次请求预期内被鉴权的位置信息，包括了需要被鉴权的字段以及对应的字段值。换言之，主体信息包括本次鉴权的最小维度，以及最小维度所包含的相关不可分割的数据。例如，主体信息可以包括鉴权点(Auth Point)和鉴权元素(Auth Element)。鉴权点表示当前鉴权主体的范围，鉴权元素表示当前鉴权主体的单个元素。例如，鉴权点可以包括鉴权范围的名字、鉴权范围路径、当前鉴权范围所包含的受保护字段、当前鉴权范围所包含的所有鉴权主体元素。鉴权元素可以包括鉴权主体元素索引、鉴权主体元素的常量值图。

在一些实施例中，数据抽取模块331接收控制面390发送的数据标注的配置信息(将在下文中详细描述)，根据数据标注的配置信息对请求以及针对请求的响应进行解析得到原始的鉴权上下文。将原始的鉴权上下文封装为标准的鉴权上下文，以供更新模块340使用。

路由模块333可以被配置为对请求进行路由。如果请求被路由命中，则对请求进行鉴权，如果请求没有被路由命中，则请求的响应可以直接返回应用层110。在一些实施例中，路由规则可以包括如下至少一项：降级路由规则、灰度路由规则、采样路由规则以及精细化终端请求标记路由规则。降级路由规则表示当某个服务发生故障或者某个服务对应的加载器降级的情形下，都会达到降级效果，则无需对请求进行鉴权，直接返回应用层110。灰度路由规则表示当某个服务存在于不同的机房时，可以控制路由规则只针对一部分机房生效，针对这部分机房的服务发出的请求可以进行鉴权，而针对其它的机房的服务发出的请求可以不进行鉴权。采样路由规则表示分布式模块210也提供的按照百分比进行采样的逻辑，只有命中采样内的流量，才会进入下一阶段的鉴权逻辑。精细化终端请求路由规则表示分布式模块210还会根据数据抽取模块331内抽取的终端流量身份信息来判断是否命中路由。例如，如果终端用户是在线用户，其发起的请求会命中路由规则，从而对请求进行鉴权。如果终端用户是非在线用户，其发起的请求将不会命中路由，则不会对请求进行鉴权。

更新模块340可以被配置为基于鉴权上下文和至少一个鉴权策略，生成针对请求的鉴权结果。也即，更新模块340用于实现鉴权逻辑进程。业务逻辑进程和鉴权逻辑进程是相互独立的进程。二者可以并行执行，也可以按照设定的规则适应性地执行，本公开的范围对此不做具体限定。鉴权逻辑进程可以和业务逻辑进程共同部署在同一个主机上。鉴权逻辑进程可以使用和业务逻辑进程相同的环境资源，例如在分布式模块210中，二者就依赖了相同的环境资源。由于鉴权逻辑进程靠近同一主机上的业务逻辑进程，因而它们之间通信并没有明显的延迟。通过将鉴权逻辑进程和其余逻辑(例如，业务逻辑进程)进程分割开，降低了不同逻辑进程的代码复杂度。示例性地，更新模块340可以通过边车模式实现，这具有热更新的特定。以此方式，使得鉴权逻辑进程更好的服务于业务逻辑进程。在不调整业务逻辑代码的情况下动态更改鉴权逻辑。

在一些实施例中，至少一个鉴权策略是基于身份信息从预先配置的候选鉴权策略中选择的。例如，到达分布式模块210的请求可以源自多个租户(例如，A租户，B租户、C租户)。分布式模块210基于这些请求的身份信息确定请求来源于哪个租户(例如，来源于A租户)，并从多个候选鉴权策略中选择为A租户配置的一个或多个鉴权策略，以对该用户的访问数据的请求/响应进行鉴权。

考虑到上文所述的标准化的鉴权上下文和标准化的接入方式，分布式模块210还可以配置标准化的鉴权策略。控制面向数据面中的更新模块340发送预先配置的候选鉴权策略(即，标准化的鉴权策略)。更新模块340基于标准化的鉴权上下文和标准化的鉴权策略对请求进行鉴权，得到鉴权结果。

在一些实施例中，更新模块340从鉴权上下文中确定作为鉴权对象的鉴权元素和包括鉴权元素的受保护数据的受保护字段；并且通过向鉴权元素和受保护字段应用至少一个鉴权策略，从多个预定鉴权动作中选择要针对响应执行的目标鉴权动作，作为鉴权结果。受保护字段包括受保护数据。鉴权对象(也称为鉴权主体)可以包括一个或多个鉴权元素。鉴权元素指代的是上文中出现的鉴权主体的单个元素，例如单个用户。

预定鉴权动作可以包括对原始响应应用的标准化的调整动作，例如，修改、拒绝、通过等等。通过可以是指请求正常通过，不对请求或响应做任何调整。拒绝可以是指对请求进行拦截，不允许任何数据返回到客户端。修改可以是指对请求进行修改，可能修改所有元素的字段，也可能修改某个元素的某个字段。标准化的修改动作可以包括擦除所有字段、擦除单个元素的字段、修改所有字段、擦除单个元素的字段，等等。由此，向鉴权元素和受保护字段应用标准的鉴权策略，从标准化的鉴权动作中选择针对响应执行的目标鉴权动作，作为对鉴权元素和受保护字段的标准的鉴权结果。无论哪种服务、请求、接入方式，鉴权动作和鉴权结果都是标准化的、可预期的、可枚举的动作和结果。

在一些实施例中，多个预定鉴权动作包括以下两项或更多项：提供响应；防止响应的提供，防止受保护的数据随响应被提供。在提供响应的情况下，动作模块332将原始响应正常通过，不会做任何调整。在防止响应提供的情况下，动作模块332对原始响应进行拦截，不允许任何用户数据返回到应用层110，从而不允许任何用户数据返回到用户的客户端。在防止受保护的数据随响应被提供的情况下，动作模块332对原始响应进行擦除、修改、同时修改和擦除、抹除元素等，以防止受保护的数据随原始响应返回到应用层110。例如，动作模块332可以修改原始响应中所有元素的字段。备选地，动作模块332可以修改某个元素的某个字段。例如，针对原始响应中的某个字段，可以修改为其他值。备选地，动作模块332可以针对原始响应中的某个字段，擦除为该字段的零值。备选地，动作模块332可以同时修改和擦除原始响应。例如，将原始响应中的某些字段擦除，某些字段修改。在抹除元素的情况下，如果原始响应中返回了多个元素，动作模块332可以对其中某个元素直接移除。

如上文中所描述的，控制面可以向更新模块340发送多个鉴权策略，使得更新模块340基于多个鉴权策略确定目标鉴权动作。更新模块340首先分别基于各个鉴权策略，生成多个中间鉴权结果，例如从预定鉴权动作中选择一个。然后，更新模块340将这些中间鉴权结果聚合成最终的鉴权结果。例如，在一些实施例中，更新模块340通过向鉴权元素和受保护字段应用至少一个鉴权策略中的第一鉴权策略，从多个预定鉴权动作中选择第一鉴权动作；通过向鉴权元素和受保护字段应用至少一个鉴权策略中的第二鉴权策略，从多个预定鉴权动作中选择第二鉴权动作。更新模块340至少基于第一鉴权动作和第二鉴权动作，确定目标鉴权动作。

更新模块340可以包括两个子模块，其分别是插件(Plugin)和加载器(Loader)。插件可以被配置为将上文所述的原始的鉴权上下文进一步封装为标准化的鉴权上下文。插件还可以为加载器提供标准的接口，以供加载器通过接口来获取标准化的鉴权上下文、执行鉴权动作，以及修改针对请求的响应。标准化的接口不是使用具体的函数来定义的接口机制，而是依赖语言(例如，Go语言)来定义的接口机制。此外，插件还可以被配置为根据请求判断使用哪个加载器来执行鉴权动作，以及将不同的加载器返回的鉴权结果聚合为统一的鉴权结果。当不同的加载器执行鉴权时，可以不直接返回鉴权结果，而是在插件内部缓存临时鉴权中间体。当所有的加载器执行完毕之后，插件对这个临时鉴权中间体进行聚合，最终将聚合后的鉴权结果返回到动作模块332，以基于聚合的鉴权结果调整原始响应。

鉴权策略或称鉴权规则被抽象为加载器。相应的，不同的加载器可以具有相同定义的接口，在插件内部通过相同定义的接口调用所有的加载器的鉴权策略来获取不同的加载器的鉴权结果。每个加载器可以加载鉴权上下文。由于所有加载符合相同的定义，这样就可以在插件按照顺序执行不同加载器的加载方法。鉴权上下文也可以是一个接口，通过该接口，可以使加载器获取到上文提及的鉴权上下文。

加载器可以不依赖具体的插件代码，就能够通过标准的接口从插件获取到相关的数据、执行具体的动作，进而实现了加载器和插件解耦。

加载器是一整套鉴权规则的集合，一次请求可以命中一个或多个鉴权规则的集合，即一个或多个加载器。在加载器中，具体的鉴权规则可以根据上文的标准鉴权上下文来判断此次请求是否合法，是否需要拒绝，是否需要调整。如果需要调整，加载器可以按照标准的修改接口来修改请求结果。加载器可以根据请求确定一个或多个鉴权策略，从而利用一个或多个鉴权策略、鉴权上下文来判断原始响应是否通过、拒绝、调整。如果确定通过原始响应，原始响应返回至应用层110。如果确定拒绝原始响应，原始响应不返回至应用层110。如果确定原始响应需要调整，加载器则会按照标准的接口来调整。

插件从加载器中获取鉴权结果。鉴权点和鉴权元素也可以以接口方式定义，通信向加载器提供这一接口可以操控鉴权点和鉴权元素的接口，就可以让不同的加载器在其内部调整鉴权结果。加载器获取当前请求的鉴权点以及鉴权点内的鉴权元素。鉴权点接口可以通过调用所定义的函数来获取受保护字段和鉴权元素。针对鉴权元素可以获取其相关值。该接口还可以定义上述的鉴权动作，例如拒绝、擦除、擦除自己、修改、替换等。如果加载器确定拒绝该请求，则会直接调用阻止方法(BlockMethod)。如果加载器确定擦除某个鉴权元素内的字段，则调用擦除(Erase)函数。如果加载器确定擦除某个鉴权元素，则调用擦除自己(EraseSelf)函数。如果加载器确定修改某个鉴权元素内的字段，则调用修改(Modify)函数。

在一些实施例中，动作模块332可以被配置为基于更新模块340的鉴权结果，实现对请求的响应(即，原始响应)的调整。在对原始响应进行调整的过程是在分布式模块210内部完成，业务逻辑进程并不受影响，也即不需要相应的调整业务逻辑的代码。具体的，动作模块332可以根据标注模块371和数据路径定义鉴权主体中的节点实体类型(RefNode)。不同的节点实体类型代表了鉴权主体中的不同节点。节点可以定义为擦除、修改、替换的调整方法，这些调整方法与插件返回的鉴权结果相对应。动作模块332拦截原始响应，解析原始响应中节点实体类型，并且接收从插件返回的鉴权结果，根据鉴权结果操作节点实体，以达到正确调整原始响应的效果。具体而言，每个节点包含唯一的鉴权键(Key)。而在鉴权结果中包含有不同的鉴权元素，这样的鉴权元素也包含不同的鉴权键，节点中的鉴权键与鉴权结果中的鉴权键一一对应。由此，动作模块332可以根据鉴权元素的鉴权键来确定对应的节点，并对节点进行操作来调整原始响应。

以上对数据面的模块进行了介绍。本公开的各个实施例可以实现标准的鉴权上下文、标准的鉴权接入方式、标准的鉴权策略、标准的鉴权动作和配置，无论是否调整业务逻辑的代码，都不需要更改鉴权逻辑的代码，从而降低接入成本、维护成本。同时，在源头上会对所有进入分布式模块的流量实时管控，从而降低开发成本。

以下对控制面的模块进行介绍。考虑到对于不同的业务逻辑，服务要访问的数据中包含有需要保护的数据(例如，受保护数据等)不同。在本公开的一些实施例中，可以通过通用的方式来获取不同业务逻辑下所需要访问的需要保护的数据。返回图3B的示例，标注模块371用于实现数据标注功能。在一些实施例中，标注模块371将标记后的数据作为数据抽取模块331的输入，以使数据抽取模块331基于标记后的数据抽取鉴权上下文。

在一些实施例中，标注模块371可以生成用于识别相应字段的预定标签，并将具有预定标签的字段映射到请求或响应中。预定标签可以包括受保护标签、取值标签和鉴权标签。

受保护标签用于标识需要被管控的字段。这样的字段可能会被擦除或审计。受保护标签表示请求或者响应结构体所代表的受保护字段。如果某个字段被标记为受保护字段，则会被用做鉴权的输入参数(即，鉴权上下文的一部分)，可能的结果是该字段被擦除，或者被修改，或者由于该字段整个请求被拒绝。获取请求返回了哪些受保护数据，返回了哪些保护级别的数据。

取值标签用于标识其数值要被读取的字段。被取值标签标识的字段(也称为取值字段)需要被分布式模块210(例如，数据抽取模块331)提取并解析出对应值，以便于进行管控决策。作为示例，取值字段能够作为请求的目的，例如，请求要访问的用户、租户等。例如，在每次被调用时，分布式模块210从每个请求中提取用户身份的具体值，以判断该请求访问了哪个用户的信息。因此，标注模块320需要将请求中的用户身份字段打上取值标签，并设置对应的策略规则，以对符合规则的用户放行。

鉴权标签用于标识表示鉴权对象(也称为鉴权主体)的字段。分布式模块210可以对标识有鉴权标签的字段进行鉴权。鉴权标签可以用来标记鉴权维度，如果某一字段被标注有这一标签，则会在该字段中进行鉴权。如果是在整个响应上标注这一标签，则鉴权的粒度是整个响应。如果在一个批量的容器上标注这一标签，则鉴权的粒度则是容器内的元素。这个标签的主要目的是为了能够让鉴权规则作用在正确的鉴权维度上，一般用来标注批量的响应可以自动根据鉴权标签的字段路径，将该路径根节点下的元素进行分类：如果字段类型是列表(List)，则可以按照列表元素分类；如果字段类型是图(Map)，则会按照图元素分类；如果字段类型是结构(Struct)，则不会拆分。

在一些实施例中，控制模块220可以提供用于标注的界面，以便于管理员或安全团队成员配置数据标注相关的功能。

图4A示出了根据本公开的一些实施例的标签设置的示例界面400A的示意图。界面400A示意性地示出了针对响应的标签设置界面，其包括字段名称栏410，字段类型栏420以及标签类型栏430。

字段名称栏410包括多个字段名称，“用户响应”、“用户”、“地址”，等等。这些字段名称可以层级结构进行排列。在字段名称之前的符号“+”或“-”表示可以展开或收起该字段名称所包含的子字段名称。层级结构的最顶层字段名称可以称为根节点，其所包含的子字段名称可以称为节点。例如，层级结构的根节点为“用户响应”。“用户响应”可以展开为两个字段：“基础响应”和“用户”。“用户”可以进一步展开为多个字段：“地址”、“列表”、“图”、“性别”＝，等等。附加地或备选地，在字段名称之后的符号“+”或“-”表示可以新增或删除该子字段名称。

字段类型栏420包括多种字段类型，例如“结构体”、“列表”、“字符串”、“图”，等等。

标签类型栏430包括多种标签，例如“受保护标签”栏、“取值标签”栏、“鉴权标签”栏，等等。标签类型栏430中的符号“+”表示可以为对应的字段添加标签。例如，为字段“地址”添加名为“地址”的受保护标签，则在受保护标签栏显示标签名“地址”。类似地，还可以添加取值标签、鉴权标签等。

管理员或安全团队成员可以通过界面400A进行字段和预定标签的选择和关联，从而实现数据标注。控制模块220可以将标注结果转换为数据路径与预定标签的映射，并作为配置下发给分布式模块210。

作为一个示例，如图4A所示，如果受保护字段标签“性别”被标注在用户响应结构体的“性别”属性上，代表响应中包含了“性别”的受保护字段。取值标签“目标ID”被标注在用户响应结构体的“ID”属性上，代表响应中需要解析“目标ID”的具体值。鉴权标签“响应”和“默认”分别标注在“用户响应”和“用户”上，这分别代表了鉴权维度是原始的用户响应，以及用户响应下的用户数组内的元素。以上介绍演示的是用户视角的标注界面。

在一些实施例中，分布式模块210基于鉴权标签和数据路径(也称为位置信息)确定鉴权主体的位置，以执行鉴权动作。因此，鉴权主体和数据路径是鉴权动作的最小执行单位。

在一些实施例中，数据路径包括多个字段以及字段间的结构关系。

在一些实施例中，标注模块371从接口描述语言(Interface descriptionlanguage，简称IDL)中提取标注的数据。附加地或备选地，标注模块371通过解析IDL文件渲染与请求或响应对应的结构，以实现人机交互，从而管理员可以对特定字段进行标注。例如，标注用户身份、用户姓名、用户生日等信息。

在一些实施例中，分布式模块210(例如，接入点模块330)可以基于与鉴权标签相对应的数据路径(也称为标注的位置信息)，对针对请求响应的字段进行分类。例如，字段类型可以分为结构体类型、列表类型、图类型，等等。具体而言，分布式模块210可以根据数据路径规则确定数据路径和接口字段之间的映射。每个字段可以用一个数据路径来表示。如果字段是原始类型或者结构体，可以直接使用字段名来表示相对路径，例如用户响应。如果字段是容器类型，例如，列表或图，则需要区别处理。具体地，如果字段是列表类型，则需要在字段名后面加上".[]"。如果字段是列表中指定Id的元素，则需要在字段名后面加上".[id]"。如果字段是图类型，则需要在字段名后面加上".{}"。如果需要获取图类型中的键(Key)，则需要在字段名后面加上".{键}"。此外，不同的字段之间，用符号“.”来分割。例如“用户响应.用户”表示不同的两个字段，一个字段是“用户响应”，另一个字段是“用户”。

作为示例，图4B示出了根据本公开的一些实施例的响应的数据结构的示例400B的示意图。示例400B以框图的形式示意性地示出了诸如IDL格式的响应的数据结构。用户响应为最上层的结构体460，用户响应包括多个字段，诸如“用户ID”、“用户ID列表”、“用户图”，等等。字段“用户图”又包含了另一用户结构体470，用户结构体470又包括多个字段，诸如“用户ID”、“用户姓名”、“用户性别”、“地址”，“电话”等等。以上数据路径仅作为示例给出，而不暗示对本公开范围的任何限制。

以下列举分布式模块210可以对一些示例的数据路径应用鉴权动作的示例。示例性地，数据路径“用户响应.用户ID”表示对“用户响应.用户ID”字段进行操作。数据路径“用户响应.用户ID列表.[]”表示遍历“用户响应.用户列表”中的所有元素，对已遍历的元素操作。数据路径“用户响应.用户列表.[2]”表示对“用户响应.用户列表”中第三个元素(第一个元素为“用户响应.用户列表.[0]”、第二个元素为“用户响应.用户列表.[1]”)操作。示例性地，数据路径“用户响应.用户图.{键}.名字”表示遍历“用户响应.用户图”中的所有键对应的用户，对已遍历的用户的“名字”字段操作。例如，数据路径“用户响应.用户图.{键}”表示遍历“用户响应.用户图”中的所有键的值，对其操作。以上仅是数据路径的示例，而不暗示对本公开范围的任何限制。

返回继续参考图3B，观测模块372被配置为实时观测服务的运行状态。报警模块(未示出)被配置为基于服务的运行状态确定服务是否发生故障，如果发生故障，发出报警信息或者故障提示信息。发布模块373可以被配置为针对以上所有模块里涉及到的可变信息的配置提供非常可靠、安全的分级发布、回滚能力。路由模块374被配置为提供精细化的方法级别的路由能力，支持路由规则配置，支持完善的各级别的运维策略配置能力。

本公开的各个实施例可以实现标准化、低成本、高性能、低延时的分布式架构的数据保护方案。例如，在上文描述的一些实施例中，实现了鉴权上下文标准化。在这些实施例中，将数据访问保护核心上下文进行了封装，分别对应了终端流量身份标识上下文，请求目的上下文，以及请求来源上下文，通过这三个标准上下文，可以判断出本次请求是来源于哪个用户，在哪个服务发起，要对哪个服务的哪个数据进行访问。

在上文描述的一些实施例中，实现了鉴权接入方式标准化。在这些实施例中，对接入方式做了标准化，不同的语言、不同的框架，概括来说，都只有两种接入方式，一种是通过本身语言所依赖的框架中的中间件，另一种是通过微服务架构下的边车模式来接入。对于需要接入的服务来说，只需要找到适合自己服务的接入方式接入即可。

在上文描述的一些实施例中，实现了鉴权策略标准化。在这些实施例中，对于数据保护策略来说，将其抽象为不同的横向业务加载器，无论哪种业务来接入本方案，只需要在控制面中选择不同的加载器即可，不需要业务方在自己的代码中调整任何代码。

在上文描述的一些实施例中，实现了鉴权配置标准化。在这些实施例中，对于需要接入的业务方来说，所有的配置都是标准化的，不会有让业务方动态调整的场景。如上文所描述的，鉴权配置包括了标注模块，路由模块，观测模块，以及发布模块共计四个模块。

在上文描述的一些实施例中，实现了鉴权动作标准化。在这些实施例中，对于鉴权动作来说，鉴权结果可预期以及可枚举是非常重要的。无论是哪种接入方式，都可以根据鉴权规则生成一个标准的鉴权结果，该鉴权结果分为三类，分别是：通过，拒绝，修改。同时修改这一个类型中，又包括了若干子项，比如擦除所有字段，擦除单个元素的字段，修改所有字段，修改单个元素的字段等等。无论什么服务，什么请求，什么接入方式，通过本方案鉴权之后，鉴权动作和结果都是严格可枚举以及处于预期内的。

在上文描述的一些实施例中，实现了较低的接入成本。在这些实施例中，上文所描述的两者接入方式相对于传统的三种方案，明显具有较低的接入成本。如果是通过边车模式来接入，业务接入无需任何代码改造，业务零感知，零成本。如果是通过中间件方式来接入，业务虽然需要改动代码，但是相对于上述传统的三个方案，改动非常少，只需要在代码中初始化引入脚本即可。实践当中，代码改动往往少于5行。

在上文描述的一些实施例中，实现了较低的维护成本。在这些实施例中，无论是哪种接入方式，数据访问控制和业务本身的逻辑，代码耦合程度非常低，这也导致了业务无论自己的代码做什么调整，正常情况下，几乎感知不到本公开实施例的数据访问方案的存在。举个例子，日常运维中，接口逻辑调整是非常常见的一种情况，在传统的三种方案中，如果业务逻辑本身发生了调整，那么对应的接入管控的代码逻辑势必也需要调整(分别为调整自定义的鉴权逻辑，调整发起RPC请求的逻辑，以及调整对鉴权SDK的输入等)，但是与之相对，在本公开的方案中，业务无论是否调整业务逻辑，都不需要更改接入点内的逻辑，至多可能需要在控制面调整标注配置。这相对于其余的方案来说，维护成本低了非常多。

在上文描述的一些实施例中，实现了防劣化。传统的三种方案都依赖业务开发人员在日常开发的自觉性，在新增接口的时候，依赖自觉性加上对数据访问保护逻辑的开发，如果开发时间较为紧张，又或者开发人员对此没有意识，又或者由于时间变更，人员迭代，开发人员不清楚需要增加数据保护逻辑，那么久而久之，鉴权规则就会疏于管理，容易劣化，最终导致鉴权逻辑漏洞百出。而本公开的方案在源头上会对所有流量实行管控，所有流量都会进入分布式模块，不需要业务开发人员在日常迭代的时候再耗费心智调整数据访问保护相关的代码，解放了开发人员的人力成本。虽然降低了人力成本，但是管控入口会把所有的流量都路由到管控模块，通过观测模块以及报警模块，告知治理相关的人员在控制面调整治理规则，保证日常迭代的逻辑不会劣化。

在上文描述的一些实施例中，实现了较高的性能。相对于集中式鉴权架构，本公开的方案属于分布式架构，从架构上消除了单点问题，不会造成由于数据保护模块的性能瓶颈问题导致所有业务服务出现请求失败的情况。另外，在采用中间件接入方式的实施例中，鉴权逻辑和业务逻辑同处同一个实例中，相对比RPC调用，减少了一次网络开销，延迟和CPU开销具有优势。

示例过程

图5示出了根据本公开的一些实施例的数据访问的过程500的流程图。例如，过程500可以由数据访问系统200来执行。

在框510，获取用于对请求进行鉴权的鉴权上下文，请求是向当前服务发出的并且用于数据访问，鉴权上下文是基于请求或由当前服务生成的对请求的响应中的至少一项生成的。

在框520，基于鉴权上下文和至少一个鉴权策略，生成针对请求的鉴权结果。

在框530，提供与鉴权结果相对应的反馈，以代理当前服务对请求进行响应。

在一些实施例中，生成鉴权结果包括：从鉴权上下文中确定作为鉴权对象的鉴权元素和包括鉴权元素的受保护数据的受保护字段；以及通过向鉴权元素和受保护字段应用至少一个鉴权策略，从多个预定鉴权动作中选择要针对响应执行的目标鉴权动作，作为鉴权结果。

在一些实施例中，多个预定鉴权动作包括以下两项或更多项：提供响应，防止响应的提供，或防止受保护数据随响应被提供。

在一些实施例中，选择目标鉴权动作包括：通过向鉴权元素和受保护字段应用至少一个鉴权策略中的第一鉴权策略，从多个预定鉴权动作中选择第一鉴权动作；通过向鉴权元素和受保护字段应用至少一个鉴权策略中的第二鉴权策略，从多个预定鉴权动作中选择第二鉴权动作；以及至少基于第一鉴权动作和第二鉴权动作，确定目标鉴权动作。

在一些实施例中，鉴权上下文包括预定类型信息，预定类型信息包括以下至少一项：与请求的发起有关的身份信息，与当前服务的上游服务和下游服务有关的上下游信息，或与请求中的鉴权主体有关的主体信息。

在一些实施例中，至少一个鉴权策略是基于身份信息从预先配置的候选鉴权策略中选择的。

在一些实施例中，还包括经由以下至少之一提供反馈：用于处理当前服务与其他服务之间的通信的代理，或位于当前服务与应用层之间的中间件。

在一些实施例中，还包括基于用户输入生成与鉴权有关的配置信息，配置信息指示以下至少一项：请求中用于鉴权的一个或多个字段，响应中用于鉴权的一个或多个字段，或请求需要被鉴权的条件。

图6示出了根据本公开的一些实施例的数据访问的装置600的示意性结构框图。装置600中的各个模块/组件可以由硬件、软件、固件或者它们的任意组合来实现。

装置600包括上下文获取模块610，被配置为获取用于对请求进行鉴权的鉴权上下文，请求是向当前服务发出的并且用于数据访问，鉴权上下文是基于请求或由当前服务生成的对请求的响应中的至少一项生成的；鉴权结果生成模块620，被配置为基于鉴权上下文和至少一个鉴权策略，生成针对请求的鉴权结果；以及反馈提供模块630，被配置为提供与鉴权结果相对应的反馈，以代理当前服务对请求进行响应。

在一些实施例中，鉴权结果生成模块620还被配置为从鉴权上下文中确定作为鉴权对象的鉴权元素和包括鉴权元素的受保护数据的受保护字段；以及通过向鉴权元素和受保护字段应用至少一个鉴权策略，从多个预定鉴权动作中选择要针对响应执行的目标鉴权动作，作为鉴权结果。

在一些实施例中，多个预定鉴权动作包括以下两项或更多项：提供响应，防止响应的提供，或防止受保护数据随响应被提供。

在一些实施例中，鉴权结果生成模块620还被配置通过向鉴权元素和受保护字段应用至少一个鉴权策略中的第一鉴权策略，从多个预定鉴权动作中选择第一鉴权动作；通过向鉴权元素和受保护字段应用至少一个鉴权策略中的第二鉴权策略，从多个预定鉴权动作中选择第二鉴权动作；以及至少基于第一鉴权动作和第二鉴权动作，确定目标鉴权动作。

在一些实施例中，鉴权上下文包括预定类型信息，预定类型信息包括以下至少一项：与请求的发起有关的身份信息，与当前服务的上游服务和下游服务有关的上下游信息，或与请求中的鉴权主体有关的主体信息。

在一些实施例中，至少一个鉴权策略是基于身份信息从预先配置的候选鉴权策略中选择的。

在一些实施例中，反馈提供模块630还被配置为经由以下至少之一提供反馈：用于处理当前服务与其他服务之间的通信的代理，或位于当前服务与应用层之间的中间件。

在一些实施例中，装置600还包括配置信息生成模块，被配置为基于用户输入生成与鉴权有关的配置信息，配置信息指示以下至少一项：请求中用于鉴权的一个或多个字段，响应中用于鉴权的一个或多个字段，或请求需要被鉴权的条件。

图7示出了其中可以实施本公开的一个或多个实施例的电子设备700的框图。应当理解，图7所示出的电子设备700仅仅是示例性的，而不应当构成对本文所描述的实施例的功能和范围的任何限制。图7所示出的电子设备700可以用于实现图1的终端设备110。

如图7所示，电子设备700是通用电子设备的形式。电子设备700的组件可以包括但不限于一个或多个处理器或处理单元710、存储器720、存储设备730、一个或多个通信单元740、一个或多个输入设备750以及一个或多个输出设备770。处理单元710可以是实际或虚拟处理器并且能够根据存储器720中存储的程序来执行各种处理。在多处理器系统中，多个处理单元并行执行计算机可执行指令，以提高电子设备700的并行处理能力。

电子设备700通常包括多个计算机存储介质。这样的介质可以是电子设备700可访问的任何可以获得的介质，包括但不限于易失性和非易失性介质、可拆卸和不可拆卸介质。存储器720可以是易失性存储器(例如寄存器、高速缓存、随机访问存储器(RAM))、非易失性存储器(例如，只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、闪存)或它们的某种组合。存储设备730可以是可拆卸或不可拆卸的介质，并且可以包括机器可读介质，诸如闪存驱动、磁盘或者任何其他介质，其可以能够用于存储信息和/或数据(例如用于训练的训练数据)并且可以在电子设备700内被访问。

电子设备700可以进一步包括另外的可拆卸/不可拆卸、易失性/非易失性存储介质。尽管未在图7中示出，可以提供用于从可拆卸、非易失性磁盘(例如“软盘”)进行读取或写入的磁盘驱动和用于从可拆卸、非易失性光盘进行读取或写入的光盘驱动。在这些情况中，每个驱动可以由一个或多个数据介质接口被连接至总线(未示出)。存储器720可以包括计算机程序产品725，其具有一个或多个程序模块，这些程序模块被配置为执行本公开的各种实施例的各种方法或动作。

通信单元740实现通过通信介质与其他电子设备进行通信。附加地，电子设备700的组件的功能可以以单个计算集群或多个计算机器来实现，这些计算机器能够通过通信连接进行通信。因此，电子设备700可以使用与一个或多个其他服务器、网络个人计算机(PC)或者另一个网络节点的逻辑连接来在联网环境中进行操作。

输入设备750可以是一个或多个输入设备，例如鼠标、键盘、追踪球等。输出设备770可以是一个或多个输出设备，例如显示器、扬声器、打印机等。电子设备700还可以根据需要通过通信单元740与一个或多个外部设备(未示出)进行通信，外部设备诸如存储设备、显示设备等，与一个或多个使得用户与电子设备700交互的设备进行通信，或者与使得电子设备700与一个或多个其他电子设备通信的任何设备(例如，网卡、调制解调器等)进行通信。这样的通信可以经由输入/输出(I/O)接口(未示出)来执行。

根据本公开的示例性实现方式，提供了一种计算机可读存储介质，其上存储有计算机可执行指令，其中计算机可执行指令被处理器执行以实现上文描述的方法。根据本公开的示例性实现方式，还提供了一种计算机程序产品，计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，而计算机可执行指令被处理器执行以实现上文描述的方法。

这里参照根据本公开实现的方法、装置、设备和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其他可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

可以把计算机可读程序指令加载到计算机、其他可编程数据处理装置、或其他设备上，使得在计算机、其他可编程数据处理装置或其他设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其他可编程数据处理装置、或其他设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实现的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实现，上述说明是示例性的，并非穷尽性的，并且也不限于所公开的各实现。在不偏离所说明的各实现的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实现的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文公开的各个实现方式。

Claims (11)

1.一种数据访问方法，包括：

获取用于对请求进行鉴权的鉴权上下文，所述请求是向当前服务发出的并且用于数据访问，所述鉴权上下文是基于所述请求或由所述当前服务生成的对所述请求的响应中的至少一项生成的；

基于所述鉴权上下文和至少一个鉴权策略，生成针对所述请求的鉴权结果；以及

提供与所述鉴权结果相对应的反馈，以代理所述当前服务对所述请求进行响应。

2.根据权利要求1所述的方法，其中生成所述鉴权结果包括：

从所述鉴权上下文中确定作为鉴权对象的鉴权元素和包括所述鉴权元素的受保护数据的受保护字段；以及

通过向所述鉴权元素和所述受保护字段应用所述至少一个鉴权策略，从多个预定鉴权动作中选择要针对所述响应执行的目标鉴权动作，作为所述鉴权结果。

3.根据权利要求2所述的方法，其中所述多个预定鉴权动作包括以下两项或更多项：

提供所述响应，

防止所述响应的提供，或

防止所述受保护数据随所述响应被提供。

4.根据权利要求2所述的方法，其中选择所述目标鉴权动作包括：

通过向所述鉴权元素和所述受保护字段应用所述至少一个鉴权策略中的第一鉴权策略，从所述多个预定鉴权动作中选择第一鉴权动作；

通过向所述鉴权元素和所述受保护字段应用所述至少一个鉴权策略中的第二鉴权策略，从所述多个预定鉴权动作中选择第二鉴权动作；以及

至少基于所述第一鉴权动作和所述第二鉴权动作，确定所述目标鉴权动作。

5.根据权利要求1所述的方法，其中所述鉴权上下文包括预定类型信息，所述预定类型信息包括以下至少一项：

与所述请求的发起有关的身份信息，

与当前服务的上游服务和下游服务有关的上下游信息，或

与所述请求中的鉴权主体有关的主体信息。

6.根据权利要求2所述的方法，其中所述至少一个鉴权策略是基于所述身份信息从预先配置的候选鉴权策略中选择的。

7.根据权利要求1所述的方法，还包括经由以下至少之一提供所述反馈：

用于处理所述当前服务与其他服务之间的通信的代理，或

位于所述当前服务与应用层之间的中间件。

8.根据权利要求1所述的方法，还包括基于用户输入生成与所述鉴权有关的配置信息，所述配置信息指示以下至少一项：

所述请求中用于所述鉴权的一个或多个字段，

所述响应中用于所述鉴权的一个或多个字段，或

所述请求需要被鉴权的条件。

9.一种数据访问装置，包括：

上下文获取模块，被配置为获取用于对请求进行鉴权的鉴权上下文，所述请求是向当前服务发出的并且用于数据访问，所述鉴权上下文是基于所述请求或由所述当前服务生成的对所述请求的响应中的至少一项生成的；

鉴权结果生成模块，被配置为基于所述鉴权上下文和至少一个鉴权策略，生成针对所述请求的鉴权结果；以及

反馈提供模块，被配置为提供与所述鉴权结果相对应的反馈，以代理所述当前服务对所述请求进行响应。

10.一种电子设备，包括：

至少一个处理单元；以及

至少一个存储器，所述至少一个存储器被耦合到所述至少一个处理单元并且存储用于由所述至少一个处理单元执行的指令，所述指令在由所述至少一个处理单元执行时使所述设备执行根据权利要求1至8中任一项所述的方法。

11.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1至8中任一项所述的方法。

Images