全文约40****00字 阅读约5分钟
“谁访问了你的数据？” 这看似一个简单的问题，却很难回答：
首先，你以为****数据库日志记录了身份，但数据库日志常常是被禁用的；
然后，你以为****应用程序日志记录了身份，但其实没有；
于是，你以为强行启用数据库日志就可以解决问题，但并没有；
接着，你以为****应用程序可以把身份带给数据，但其实不行；
终于，你以为这样就没辙了，但聊暗花明又一村……
上述问题本质上是数据访问的****身份归因。
我们知道，对于应用程序的访问而言，身份归因是比较容易的，通常由单点登录(SSO)即可解决；那对于数据的访问，身份归因为何就如此困难呢？
区别就在于：“谁访问了你的****应用”并不等同于“谁访问了你的****数据”。在应用程序和数据之间，存在一条难以逾越的大河。
所以，将零信任思想应用于数据访问时，听起来很简单；但将零信任技术应用于数据访问时，做起来却很困难。
当然，对于正确的事情，即使困难，也该做。
再问一遍：在贵组织的数据访问过程中，真地有用户身份吗？
关键词：SSO（单点登录）；DSP（数据安全平台）；身份提供者（IdP）；
目 录
1.问题：谁访问了你的数据？
2.你以为数据库日志是默认启用的
3.你以为应用程序日志可以办到
4.你以为强行启用数据库日志就好
5.既然无解，请向前辈(应用程序)学习
6.然而，数据并没有SSO(单点登录)
7.既然没有数据SSO，那就创造一个
8.答案：具备数据SSO的数据访问平台
01
问题：谁访问了你的数据？
谁访问了你的数据？很容易提问，但很难回答。
当我们在被审计过程中试图证明我们过去的访问行为是正当的时，我们可能会被问到这个问题；当我们处理数据泄露问题时，我们可能会被问到这个问题。
在大多数情况下，我们都以非常被动的方式回答这些数据。因为我们看不清也说不清这个问题。
当被问及这个问题时，你可能会觉得自己被置于聚光灯下，甚至是审讯椅上。
02
你以为数据库日志是默认启用的
遇到这个问题，我们通常的想法是查看数据库日志，看看是否可以找到答案。但通常没有数据库日志，因为数据库日志经常被禁用。
为什么我们经常会关闭数据库日志呢？
一是延迟。通常，应用程序中的最慢部分就是数据访问，即连接到数据库并检索数据。而数据库检索数据的最慢部分是从磁盘读取数据。当我们写入日志时，我们需要执行两个磁盘操作，从而增加了应用程序的延迟。因此，出于性能原因，我们可能会选择禁用日志记录。
二是存储。我们也可能出于存储原因选择禁用日志。数据库服务器的工作是存储关键业务数据。随着时间的推移，我们可能会存储大量数据，导致我们很久以前选择的磁盘大小现在可能不够了。我们只好先删除一些不需要的东西，首先想到的自然是删除数据库日志。
另一方面，即便数据库日志存在，它们可能太贫乏而无法获得有价值的见解。对此，后文再做解释。
03
你以为应用程序日志可以办到
接下来，我们考虑应用程序日志。
任何使用我们数据库的东西，都可能来自我们的应用程序。值得庆幸地是，我们对应用程序的使用过程有很好的日志记录。我们可能有非常漂亮的仪表板，向我们展示经过身份验证的用户活动、页面请求、响应HTTP状态代码，以及完成请求所花费的时间。于是，我们希望通过这些日志来回答“谁访问了我们的数据？”这个问题。
但是应用程序日志是否足以回答这个问题？不幸的是，并非如此。因为还存在许多不通过应用程序连接到数据库的场景：
SRE（站点可靠性工程师，Site Reliability Engineer）：会跳转到客户帐户，以快速修复一些数据错误并让客户恢复正常。
DBA**(数据库管理员)**：直接登录数据库，以调整索引或重写慢查询。
部署工具：运行数据库迁移，以部署软件的新版本。
批量数据提取工具：可以帮助新客户加入或帮助老客户离开。
这些连接是否通过应用程序？他们可能不是。他们可能通过数据库管理工具直接访问数据库。
还可以列举多种合法的场景，其中正常的数据访问都不是通过我们的应用程序完成的；而对于其它不合法的活动，当然很可能也不是通过应用程序来完成的。
使用应用程序日志来回答有关数据库访问的问题，仍是一个谎言。因为数据访问不仅仅通过应用程序发生。
04
你以为强行启用数据库日志就好
既然没辙，就让我们启用数据库日志吧。
如果我们查看Postgres官方文档，就会发现：默认情况下日志是禁用的——正如前文所述。
当然，我们可以启用日志，即通过如下配置，将日志级别从无更改为****全部：
postgres -c log_statement=all -c logging_collector=on
启用日志后，再重启数据库。然后，使用应用程序和终端工具访问数据库。这时，我们可以看到类似下面的日志信息：
2021-02-21 15:35:07 CET [3492-349] postgres@prod LOG: execute : SELECT id FROM public.task WHERE id = 7;
2021-02-21 15:35:07 CET [3492-350] postgres@prod LOG: duration: 11.069 ms
2021-02-21 15:35:08 CET [3494-223] postgres@prod LOG: duration: 0.030 ms
2021-02-21 15:35:08 CET [3494-224] postgres@prod LOG: duration: 0.081 ms
我们的确可以看到执行的查询操作、查询的日期/时间、消耗的时间，但****看不到查询是由谁执行的。即便我们想记录用户信息，我们可能只会看到应用程序使用的****服务帐户。
而即便是由非应用程序型工具所运行的查询，也可能仍然使用相同的服务帐户。我敢打赌，DBA或SRE用户只是打开了Web应用程序，又从配置文件中提取了凭据，然后登录。
为何会执着地使用服务帐户？因为在数据库中创建个人用户，并使其在员工加入和离开时保持同步，真是太困难了——所以没法这么做。于是，大家都使用相同的服务帐户。
关于日志的小结和回顾。出于性能原因，可能会关闭数据库日志，以避免额外的磁盘访问延迟或节省宝贵的存储资源。即使我们打开了日志，所有访问都使用单个服务帐户——不论是来自我们的微服务的访问，还是来自非应用程序型工具的访问（如DBA、SRE、DevOps工具）。总之，数据库日志不包含用户身份信息，所以无法帮助我们回答“谁访问了数据？” 这个问题。
05
既然无解，请向前辈(应用程序)学习
或许，你以为没辙了。但还可以向前辈（应用程序）学习。
我们知道，Web应该程序使用单点登录 (SSO) ，完美地解决了身份问题。我们来看看，它是如何做到的。
SSO的工作流需要用户、应用程序、身份提供者 (IdP) 这三方的共同努力：
用户启动Web应用程序
用户点击登录
浏览器重定向到身份提供者 (IdP) 登录页面
用户登录到这个受信任的资源
浏览器重定向回应用程序
用户完成工作
可见，应用程序、身份提供者、用户共同构建了很好的体验：
**身份提供者：**将用户凭据安全地存储在一处。身份提供者提供丰富的用户上下文，包括经过验证的身份和组成员资格。
**应用程序：**接受此令牌，并可以根据用户的组成员资格或其他声明对用户做出授权决定，但Web服务不需要存储凭据或验证用户的电子邮件。
用户：如果已经登录到共享的SSO身份提供程序，他们可能会直接被重定向回网站，而无需再次登录。这是一种很棒的用户体验。
当我们审视SSO内部的这种机制时，我们看到了一个优雅的机制，即应用程序、身份提供者、用户三者一起工作，来创建这个优雅的解决方案。如果我们查看微服务的日志，我们可以看到用户的身份、组成员资格、请求URL、响应状态代码、请求持续时间、日期/时间、连接的细节（如源IP等）。
既然SSO已经解决了应用程序的问题，我们是否可以用SSO解决数据库的问题呢？
06
然而，数据并没有SSO(单点登录)
对于应用程序而言，单点登录 (SSO) 是应用程序的绝佳解决方案，可以获取请求和响应的细节、连接的细节、身份上下文。
那为什么我们不能对数据这么做呢？
图1-数据没有SSO（单点登录）
如上图所示：
面对Web应用程序：我们可以轻松地转发给身份提供者 (IdP)。借助云资源，我们可以使用OIDC或SAML进行身份验证。
面对本地和云中的数据资源：我们却一下子回到了石器时代，因为许多流行的数据库并不支持SAML/OIDC协议。尽管Snowflake或Redshift这样的现代数据库的确可以通过Okta或IAM支持原生SSO，但大多数业务用户使用BI工具（如Looker、Tableau、Thoughtspot等）通过单个服务帐户来访问数据，所以仍然看不清这些工具背后的真实用户。
简言之，应用程序有SSO，但数据没有SSO。
07
既然没有数据SSO，那就创造一个
让我们从应用程序的SSO解决方案中学习，并设计能够为数据提供身份上下文的日志记录解决方案。
我们先列举我们理想中的日志记录解决方案：
SSO用户名
SSO组
SQL查询
结果行数
客户端连接的细节
日期和时间
这正是我们想要的信息：SQL查询、响应的细节、日期和时间、连接的细节、用户身份。
这也正是我们通过启用SSO的应用程序所能获得的数据。我们得到经过身份验证的用户和组、请求URL、响应状态代码、返回的字节数、用户的源IP、查询的日期和时间。
如果我们的数据日志中有这些细节，我们就可以明确而自信地回答问题——谁访问了我们的数据？
那么，我们该如何获得数据存储的这种详细程度？让我们采用数据访问平台，或者称为****数据安全平台（DSP）。
08
答案：具备数据SSO的数据访问平台
我们的方案是一个数据安全平台（DSP），它必须是一个身份****联合访问控制系统，也必须能够****将SSO带入数据网格。
由于数据访问需要区分应用程序访问场景和非应用程序访问场景，故需区分两种场景，分别进行应对。
1）应用程序场景的**********数据SSO**************
图2-传统方案 vs. 数据SSO方案
在上图中，左侧是DSP之前的场景；在右侧，我们添加了DSP来支持身份上下文日志记录。
在左侧（传统方案）：前端向SSO提供者进行身份验证，并检索包含所有 SSO 组和其他声明的 JWT（JSON Web Token）。应用程序可以在微服务之间传递此身份验证令牌，以验证用户的身份并做出授权决策。但是，一旦微服务接触到数据，它就会切换到共享服务帐户，于是身份上下文就丢失了。
在右侧（数据SSO方案）：增加了DSP（数据安全平台）来支持身份上下文日志记录。我们使用相同的SSO身份验证机制，检索相同的JWT，并通过微服务传递此身份验证令牌。然后，我们要做一些新颖的事情：我们还将这个身份验证令牌传递给DSP的Sidecar（边车）代理。DSP捕获查询请求和响应的细节，以及用户身份的细节。DSP将该查询操作，代理到数据存储，并将结果返回给应用程序。也就是说，通过使用DSP，我们可以通过数据层保留用户身份。
2）非应用程序型场景的**********数据SSO**************
注意到，许多数据访问场景并不经过应用程序：SRE、DBA和其他人可以直接连接到数据存储。所以，现在让我们来看看通过终端（terminal）或其他专用连接的数据访问。
图3-传统方案 vs. 数据SSO方案
在左侧（传统方案）：用户直接连接到数据库。他们很可能使用共享服务帐户，从而导致用户身份丢失。
在右侧（数据SSO方案**）：用户通过DSP门户，登录到他们选择的SSO提供商。从那里，他们获得了一个令牌**，用于向DSP的Sidecar验证他们的身份。所以，DSP可以捕获查询请求和响应的细节以及用户身份。然后，DSP将该查询操作，代理到数据存储。
3）结论：具有数据SSO的DSP
对于应用程序和非应用程序的数据访问，DSP都可以在数据访问过程中捕获用户身份。也正是在DSP日志中，我们找到了我们正在寻找的东西：用户身份！
借助DSP，我们可以使用各种身份****联合访问控制，如Okta Azure Active Directory、G-Suite等；也可以连接到各种数据存储，如MariaDB、MongoDB、SQL Server等；还可以将日志发送到您选择的SIEM平台，如ELK、Splunk、DataDog等。
有了DSP的Sidecar代理，我们就可以使用标准SSO工具，向我们的数据库进行身份验证。应用程序用户和非应用程序用户（如SRE、DBA、部署工具）都可以通过SSO进行身份验证。DSP收集的日志包括查询请求、响应行数、所用时间、连接的细节（如客户端IP等），以及最重要的SSO用户和组。
谁访问了我们的数据？有了具备数据SSO能力的DSP****，我们就能知道。
（本篇完）
本文的封面来自于下面这本书：
