第13章-2 合规控制构建

          上一篇：《第13章-1 什么是合规性》，了解完合规性，接着了解如何进行构建？

为合规控制构建

        正如我们所见，全球都在加强企业的合规性要求，由于企业运营所使用的数据量是巨大的，根据每项法律的目标或企业需要的认证，控制措施可能会有很多。好消息是，同样的工作有足够的空间覆盖多个合规性控制，从而可以在管理基础设施时实现高效和更一致的实践。然而，你确实需要了解业务需要哪些合规性控制措施，以及出于什么目的。一旦公司发展到一定规模，需要开始实施这些监管合规控制的任何子集，你将成为向不同类型的审计师提供合规证据的人。了解每项控制的目的将大大有助于提供正确的证据，使审计更容易。

提示

        合规性的构建是一个持续的过程，在需要的时候不容易“添加”。一旦你的公司度过了“仍在寻找市场匹配”的阶段，本章中提出的许多架构建议（角色分离、跟踪变更等）都是你应该考虑和倡导的东西。当合规性成为一种真正的需要，而不仅仅是一种“不错的拥有”时，这些做法将为你的企业的成功奠定基础。

机密管理

在讨论如何管理机密信息之前，让我们先看看基础设施中的哪些内容可能属于该定义：

        ● 应用程序与数据库交互的密码字符串。

        ● 支持人员/操作人员管理数据库实例的密码字符串。

        ● 可以访问/修改数据的API令牌。

        ● SSH私有密钥。

        ● 证书密钥。

        在组织中，为了便于进行大量的安全控制，你需要一种核心能力，即安全地管理机密信息并将其与管理配置分开。你需要一种方法来交付和转换敏感数据（如数据库访问凭据），无论它是供应用程序还是团队使用，或是用于报告目的。

        如果你在云环境中运行应用程序和数据库，我们强烈建议在构建自己的机密信息管理解决方案前，优先从云服务商那里寻求合适的方案。方案中的加密级别必须满足国家标准与技术研究所（NIST）标准 （有关这些标准的更多信息，请与你友好的信息安全团队开始对话，或从O'Reilly获取NIST 网络安全框架（参见链接60 https://oreil.ly/s7XOJ）的袖珍指南） 可接受的最低要求，包括HIPAA和FedRAMP在内的许多法规都有加密级别的要求。

        如果云服务商没有满足要求的机密信息管理解决方案，那你可能不得不自己构建。这对组织来说可能是一项新的尝试，需要比本书提到的方案付出更多的努力。

        无论是使用托管解决方案，还是最终需要运行自己的解决方案，都要注意机密信息管理解决方案会给整个体系结构带来复杂性。此解决方案的目标是管理机密信息，而不是成为产品的单一故障点。当机密信息管理解决方案可用时，应该清楚地写好取舍的理由，解释会发生什么，这将派上用场。提前与法律团队和安全组织进行明确的对话，了解哪些机密信息应被缓存，以及以何种方式缓存，这将有助于避免以后的预期偏差。

        通常，一家公司在其早期开发阶段基于便利性做出的决策，在制定合规性控制计划之前需要重新考虑。你应该准备好向领导解释为什么这项工作在改善你的安全态势和降低风险方面很重要。

不要共享用户

        不要跨服务共享数据库凭据。假设数据库中的信息意外泄露，现在必须评估该问题的影响面，以确定哪些应用程序和流程必须使用新的数据库凭据。如果各个服务使用了独立的数据库凭据，那么在处理这个问题时能节省大量成本。作为一名数据库工程师，加入一家初创公司是很常见的，在那里，人们选择了看似方便的快捷方式，即“所有代码都使用同一对凭据来访问数据库”。相信我们：这是一条非常昂贵的捷径，如果将每个数据库用户的访问权限限制为其所需的服务，你将来会感谢你自己的。

        我们已经介绍了这个基本但至关重要的基础实践，现在让我们讨论在选择存储数据库凭证或密码的解决方案时需要考虑的事项。

不要在代码存储库中检查生产数据库凭据

        这似乎是显而易见的，但正如我们在很多大大小小公司的安全事件事后报告中看到的那样，这种情况一直在发生。对此，保持谦虚的心态是很重要的，不要认为这种错误在你的组织中不太可能发生。一种“信任但验证”的方法大大有助于防止此类问题。一种常见的做法是在合并一个pull请求之前，扫描代码库寻找潜在的机密字符串（GitHub等代码仓库托管服务可以实现）。

        如果你的组织还没有考虑到这一点，那么你需要成为这一需求的倡导者。请记住，合规性和安全性是整个组织所需要的，尽管不是所有的事情都可以或者应该由数据库团队完成，但在整个工程组织谈论这些优先事项的方式中，你是一个利益相关者。

        这些实践对于正确开始合规性和安全姿态至关重要。在使用机密信息管理解决方案时，它们将要涉及的一些操作变得更加简单，尤其是需要进行紧急更改时，这将进一步降低业务风险。

        接下来让我们看看选择机密信息管理解决方案时需要做的取舍。

选择机密信息管理解决方案

        选择机密信息管理解决方案将取决于运行环境，以及如何最简单地实现与数据库和应用程序堆栈的集成。在方便和满足所有需求之间，总会有取舍。因此，你需要让所有利益相关者（其中一些人不在工程领域）清楚有哪些限制，以及可用性或可恢复性的权衡是什么。当检查你的云（或私有）基础设施可以提供什么的时候，你应该考虑以下取舍。

空间限制

        很多云服务商提供的机密信息管理解决方案对机密信息的长度做了限制，如果想存储比数据库的用户和密码对更长的内容，可能会导致意外。如果合规性控制还要求将较长的文本字符串视为机密信息（例如，SSH密钥或SSL专用证书），则应检查给定密钥上可存储容量的最大大小。一些组织后来偶然发现的地雷之一是，随着机密信息长度的增长，需要一种新的、不同的解决方案来容纳更长的机密信息。现在，要么必须迁移（这可能会影响正常运行时间），要么使用工具来集成两个独立的机密信息解决方案，这两种方式都有其自身的复杂性。

机密信息的轮换

        如果是在公有云中运行，且可以使用其托管的机密信息管理解决方案，那么有一个好消息：截至本文撰写之时，所有三种主要的云服务都提供了一些方法，可以自动化地处理机密信息的轮换和版本控制，从而使你的服务无缝地过渡到新的机密信息。如果选择的机密信息管理解决方案不支持轮换，那么你需要规划如何进行计划内的更改（例如，可能有一个控制机制要求数据库凭据按一定的节奏轮换）和计划外的紧急更改（例如，有人意外地在公共代码存储库中上传了数据库密码）。如何做到这一点而不影响正在运行的应用程序呢？这在很大程度上取决于如何将配置更改发布到正在运行的应用程序中，以及部署管道的操作方式。这就是如何编排它的大致思路。这个更改是一个部署工作。即使你的应用程序将数据库凭据作为配置项访问，你仍然需要将此配置更改应用到所有系统，并且通常还需要在不影响整个服务可用性的情况下安排重新启动。

区域的可用性

        考虑到机密信息管理解决方案不仅仅是为了存储机密信息，也是为了传递机密信息。如果要避免在代码中存储机密信息等已知错误做法，则需要应用程序能够在运行时检索处理请求所需的机密信息。这意味着你现在必须考虑如何检索这些机密信息，如果应用程序无法访问机密信息管理服务会发生什么，以及这种新的依赖关系会引入什么故障模式。如果你负责在许多不同的地理区域运行应用程序，则机密信息管理解决方案的区域可用性将成为另一件需要考虑的事情。云服务商的解决方案是否会自动将机密信息复制到其他地区？还是你必须自己建立这种能力？

角色和数据的分离

        这些监管法律的一个重要目标是，基于数据泄露将给企业或客户带来的风险等级对数据进行分离。这是最小特权的概念，既适用于人工访问，又适用于应用程序代码访问。这种策略根据数据类型以及与之相关的风险进行分类，以便进行更恰当的控制和跟踪。

出于合规性原因进行分片

        强制将特定的数据集分离到专用集群的一个原因是，不同的控制机制有不同的合规性要求。假设你是一家营销传播供应商，正在开发一种新的、独立的产品，重点放在医疗保健技术上。目前使用的数据与健康无关，不受许多法律要求的约束。一旦企业进入健康技术领域，你就拥有了一个客户子集及其数据，在这个子集中，你的公司承担了作为个人健康信息（PHI）处理机构的法律责任。在这种情况下，从一开始就在专用的数据存储中开发新产品是有意义的，这样就可以更恰当地应用HIPAA合规性控制，而不会给现有的数据集及其相关的应用程序增加不必要的负担。

独立的数据库用户

        随着产品变得越来越复杂，技术栈也随之增加，你将开始拥有多个具有数据访问的应用程序。尽早开始使用良好的数据访问控制机制非常重要，多个应用之间不要共享相同的数据库访问凭据。无论公司规模大小，都会发生安全事件和凭证意外泄露事件，当这些事件发生时，你需要紧急轮换密钥。如果泄露的密钥对业务运营的影响是已知的，并且影响范围是孤立的，那么你可以更好地处理这类事件。

变更跟踪

        很多合规性法规都附带了跟踪变更的控制措施：对影响财务报告的数据子集的更改、对生成发票的系统的更改，以及如何审查、测试和跟踪这些更改。与这种合规性控制相关的重要的地方之一就是数据库。当你为一家合规性责任不断扩大的企业工作时，像“如何在生产环境中审查、应用和跟踪schema更改”这样的过程需要更严格和更有计划性，而不仅仅是简单地记录一句“工程师登录生产环境源节点并进行更改”。如果你与内部审计团队或合规团队一起规划如何处理审计，这将大大减轻你的负担。

        这里的目标是避免在年度审计时，各个团队争相为审计团队收集证据时手忙脚乱。相反，如果你对这些正常业务操作的工作方式进行了一些改进，那么就可以更容易获得和收集用于审计的“自带的”证据。在本节中，你将看到一个反复出现的主题，即从所有内容生成结构化日志。这是有意为之的。这有助于以相同的方式跟踪各种变更，而且这种一致性有助于业务以更少的成本实现其审计需求。可以在图13-1中看到这一切是如何组合在一起的。

        图13-1：不同操作任务将结构化日志发送到一个地方，从而使审核更容易的示例

让我们来看一下数据库系统的不同类型变更，以及如何为它们自动执行合规性跟踪。

数据访问日志记录

        很多合规性控制都要求维护特定数据集的变更日志或访问日志。这可以用于跟踪财务数据的变化，也可以用于PCI或HIPAA等法规，这些法规中的数据足够敏感，需要跟踪所有访问。

        你可以直接在数据库级别解决这一需求，如果运行的是Percona发行的MySQL分支，则可以使用Percona 的审计日志插件（参见链接61 https://oreil.ly/0SJa0）；如果运行的是MySQL的社区版本，可以使用等效的MySQL 企业审计插件（参见链接62 https://oreil.ly/2tanA）。这样做的好处是，可以在数据更改之前的最后一跳来跟踪变更，尤其是在数据库变更可以通过多个路径进行的环境中。

跟踪更改不可取的选项

        你可能会问，“为什么不使用触发器来跟踪我关心的表的更改？”这确实是我们过去见过的方法，但不推荐使用。以下是不建议使用触发器的一些原因：

        ● 众所周知，触发器会导致写性能下降，这会在最糟糕的时候对性能造成影响。

        ● 触发器相当于在数据库中存储业务逻辑，这是不推荐的。

        ● 在数据库中存储代码可能会绕过测试、转移和部署代码的任何过程。触发器可能意外地导致故障。

        ● 触发器只能支持跟踪写入操作。无法扩展成可以跟踪读取访问的解决方案。

让我们来看看如何使用Percona审计日志插件，以及如何对其进行调优

安装和优化Percona审计日志

        Percona审计日志插件是Percona发行的MySQL分支的一部分，但是默认情况下没有安装或启用。你可以在新实例的引导过程中，在实例上运行以下命令来安装：

INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SHOW PLUGINS;

        第二个命令列出了正在运行的插件，这里应该确认审计日志插件已经作为服务器进程的一部分运行。不仅要开启审计日志插件，还需要确定如何接收其输出。这才是真正重要规划的地方。

        Percona的审计日志插件允许定义需要跟踪的语句谓词。这样可以灵活地满足各种控制要求，而不必在审计日志中记录大量无关的干扰信息。请确保查看其文档，以便根据需要正确配置该变量。

        这个插件有一个灵活的优点，就是可以安装但不实际监控查询。 （更多信息请参阅参考插件文档（参见链接63 https://oreil.ly/gwqc2）） 如果你还在研究如何接收插件的输出，并且需要在不影响正常运行时间的情况下关闭和打开，那么这将非常有用。但这种灵活性也带来了复杂性。除了管理审计日志插件附带的配置变量外，还需要监控其是否一直在运行。如果这是业务的关键功能，就意味着值得监控。由于可以在不重启服务器的情况下动态禁用插件，因此你需要做的不仅仅是检查磁盘上的my.cnf文件以确认它正在执行需要的操作，最好的办法是使用shell查询来解析插件的当前状态，并确认它实际上是在监控查询。可以分别执行下面两条单行shell命令：

# Single liner to check that the audit log plugin is active
$ mysql -e "show plugins" | grep -w audit_log | grep -iw active# Single liner to check that the plugin policy is actually monitoring queries
$ mysqladmin variables | grep -w audit_log_policy | grep -iw queries

这里假设你只监控查询。如果还希望使用插件跟踪登录，则需要编辑这些用于检查的shell语句。

接收和使用审计日志

        正如你所见，审计日志插件有很大的灵活性，但它也只能生成审计事件。你需要确定接收这些日志的最佳方式，将它们放在易于搜索和分析的地方，并合理地发现其中的异常，而不会让其成为主要负担。该插件可以简单地将输出转储到本地文件，但这可能会增加宕机的风险，因为日志文件可能会填满数据库主机中的磁盘。

        一个更复杂的选项是使用插件的能力将输出发送到rsyslog（一种常见的UNIX日志管理工具），然后使用rsyslog将所有这些事件转发到组织所选择的结构化日志平台。这个选项很有吸引力，因为它将这些数据带到了组织已经进行结构化日志存储的地方，这降低了数据库团队之外的利益相关者查看、搜索和分析这些事件的障碍。但是请记住，以这种方式使用rsyslog进行日志转发需要熟悉它的工作原理，确保以一种有意的方式决定和记录此数据流的rsyslog配置方式。 （作为起点，这里有一整页关于“可靠日志转发”的信息（参见链接64 Reliable Forwarding of syslog Messages with Rsyslog — Rsyslog documentation）） rsyslog中可能有许多默认配置对你想要的结果没有帮助，应该尽最大努力找到这些配置并进行相应的更改。

警告

        由插件输出的审计日志，要确保有很好的文档描述（即使是临时存储）。如果这些文件的传输方法变慢，那么在插件中缓冲事件可能会影响数据库服务器本身的性能。这种故障状态很难调试，因为它的唯一症状是查询执行速度变慢。考虑到可恢复性，应该计划对这些日志的整个管道进行混沌测试。

        Percona审计日志插件是一个功能强大的工具，可以帮助实现很多合规性控制。根据我们的经验，这是一个比使用触发器性能更好的解决方案，并且它与配置管理和结构化日志软件集成得很好，使得解决方案在许多利益相关者团队中都是有效的。

schema变更的版本控制

        第6章中介绍了不同的策略和工具，有助于大规模地进行schema变更。现在让我们看看这些策略带来的合规性问题。

        使用版本控制来跟踪和运行schema变更可以附带内置的跟踪功能，包括谁请求了更改、谁审查和批准了更改，以及它在生产环境中是如何运行的。这也是为每个数据库集群的变更使用单独代码存储库的一个很好的原因。随着公司中数据库量级的增加，你会发现并不是所有的数据库都是相同的。有些数据库将需要遵循更严格的法规（例如，保存财务数据的数据库），而有些实验性数据库并不那么重要。如果使用了单独代码存储库，在进行审计时为每个数据集和集群提供变更记录将会非常方便。

        这种基于合规性需求的数据和集群schema管理的分离，使得在版本控制管理中更容易控制谁可以提交或批准schema变更。在进行业务审计时，通常需要确定谁可以更改数据库。减少可以修改数据的人工操作员的人数，符合最小权限安全原则。

数据库用户管理

        对数据库的更改不限于schema变更。还需要以一种可跟踪和可重复的方式管理数据库用户及其细粒度权限。让我们看看如何满足一些用于处理数据库访问控制的常见合规性控制。

使用配置管理

        一种简单的使数据库用户跟踪合规的方式是，使用和数据库配置变更合规性相同的过程。你可以在配置管理的代码存储库中管理这一切，并使用源代码控制、PullRequest流程和同行评审来提供证据，证明对数据库用户的所有更改都是以一种可以审计和跟踪的方式完成的。

计划凭证轮换

        无论是针对计划外的安全事件，还是因为有一个按计划轮换凭据的控制规则，你都需要制订一个计划，以便在不影响应用程序在线时间的情况下轮换数据库用户。这可能意味着要更改应用程序使用的用户名和密码字符串。如果尚未运行具有双密码支持的最新的数据库版本，那么你应该采取以下步骤，在不影响服务在线时间的情况下，在生产应用程序中轮换数据库凭据：

        1. 首先在数据库中引入新的用户名/密码对。

        2. 测试新凭据是否具有与旧凭据相同的访问权限。在理想情况下，可以在部署新凭据时自动通过比较SHOW GRANTS来确认是否有相同的权限。

        3. 部署应用程序，替换原应用程序配置中的凭据。

        4. 重新启动此服务的所有实例，以确保新的用户名/密码对可以使用。

        5. 删除旧的用户名/密码对。

        无论是例行变更还是由于凭证泄露或安全风险而造成的紧急变更，此过程都应该相同。因为后者不是一个可以控制或可以完全避免发生的事件，因此最好让这个过程自动化，或者至少在运行手册中有很好的记录并可以定制演练，这样当意外发生时，对你的团队来说，才不会是一次可怕的消防演习。

提示

        在不影响可用性的情况下，在MySQL中轮换数据库的用户密码曾经是一项复杂的协调工作。在MySQL  8.0.14引入了双密码支持，再结合密码过期策略，使得轮换密码更加容易操作。

删除未使用的数据库用户

        任何未使用的、在实例上保持激活状态的数据库用户都会带来额外的安全负担。定期审计实例上激活的数据库用户（与应用程序上配置的用户相比），并删除任何应用程序不再使用的用户，这一点很重要。

        在满足公司的合规性需求时，你会发现许多合规性控制会要求公司跟踪某些资产的一切更改。这些控制在SOC 2等报告中是典型的，我们在本章前面介绍了SOC 2，其中主要关注的是提供数据完整性和安全性的证据。

        有几种方法可以查明是否在使用一个指定的数据库用户。我们在第3章中详细介绍了Performance Schema，是将其作为一种检查服务器性能的方法进行介绍的。Performance Schema中有一张用户表，其中存储了有关已连接到服务器的用户的历史信息。这种历史跟踪可以追溯到服务器进程的生命周期或该表允许的最大大小（以最先发生的为准）。由于该表跟踪已经连接的用户，而不是没有连接的用户，因此你需要遍历已知用户，看看是否有用户没有出现在该表中，可将这个结果作为他们可能不再被使用的信号。

以下是在Performance Schema中启用该工具的查询：

mysql> UPDATE performance_schema.setup_instruments-> SET ENABLED=‘YES’ WHERE NAME='memory/sql/user_conn';
Query OK, 1 rows affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

启用该功能后，可以通过Performance_schema.users表查找此信息。

        如果你使用审计日志解决方案进行合规控制，例如，我们前面提到的Percona插件，那么可以使用这些日志来确定用户是否在给定的时间内连接过实例。

        无论以何种方式确定这一点，都建议设置这样一个策略：“删除六个月内未连接过数据库的用户”。这一做法将有助于防止使用不需要的、现在已成为负担的访问。

        数据库将处于需要这种级别的努力的控制范围内。随着公司逐渐成熟，并开始考虑变得更加合规，你将需要证明对生产数据库的变更在执行之前已经过审核和跟踪。合规控制关注的另一件事是，证明当灾难性事件发生时，你具有恢复数据和服务的能力。为此，接下来讨论备份和恢复，看看它们是如何符合合规要求的。

备份和恢复程序

        第10章介绍了不同类型的备份。备份显然很重要。它们在发生事故时会非常有用，也是许多合规控制的关键部分。在大多数SOC 2实现中，都有创建和测试备份的控制要求（即使没有合规性要求，你也应该测试备份）。随着管理的数据库集群数量的增长，你很快就会发现无法继续手动执行备份和备份测试等过程，甚至无法通过手动读取日志文件来报告成功和失败。

从合规性角度，在评估如何管理备份时，需要满足以下一些要求：

        ● 需要将备份过程自动化。

        ● 如果备份失败，需要在备份过程中发出警报。

        ● 需要自动测试备份。

        ● 失败的备份测试也应该是可以在某处跟踪的事件。

接下来，我们将讨论如何安排备份和备份测试。

运行自动备份和备份测试

        你需要一种机制来满足这些要求，该机制不仅可以运行调度作业（如Linux系统中的crond），而且可以确保作业按计划运行，且可以向监控系统和工单系统发送事件，以便在出现故障时发出警报，并跟踪故障以便以后进行审计。实现这一点的一种方法是，运行备份和备份测试作为监控检查 （在博客文章“使用 Sensu 进行 DBA 任务”中（参见链接65 Using Sensu for DBA tasks），你可以看到一些将备份等任务作为数据库监控解决方案的一部分的示例），但备份可能需要一段时间才能运行，尤其是当一些数据库实例的大小为TB级时。只要用于运行备份任务的监控系统能够处理比通常几秒长得多的检查，作为监控项运行备份就可以工作。因此，请确保运行监控系统的团队了解这个用例。

        如果监控系统不能处理这种用例，那么请确保有一些方法可以留下“面包屑”，以跟踪备份以及备份测试已经发生并成功完成。这样的“面包屑”可以是一个包含时间戳的文件，备份程序在每次备份或备份测试运行结束时编辑该文件，作为任务发生和完成的证明。一旦“面包屑”就位，就可以使用监控系统更快地检查其存在。

        在所有这些策略中，你想要的，以及SOC 2控制所需要的，是成功完成备份以及失败备份的跟踪记录，显示它们已被正确跟踪到工作项。

备份和备份测试的集中日志

        你还可能被要求展示成功完成备份和备份测试过程的日志。通过使用集中式日志解决方案，你可以将日志发送到该解决方案以保持日志连续性，从而为此类审计项目做好准备。

请记住，我们为这些业务需求构建的解决方案应该假设服务器是易于重复替换而不是定制的。因此，如果你在下次审计之前让机器“退役”并更换，那么随机实例上的本地日志文件就不是理想的方案。你应该将任何与业务相关的资产（如备份过程的日志）都放在一个集中的位置，任何具有正确访问策略的人都可以访问。

通过备份进行灾难恢复规划

        SOC 2还要求有适当的灾难恢复规划。这意味着可以证明你测试了系统生成的任何备份，跟踪了这些测试失败以及故障被恢复的时间，并且，在理想情况下，你可以知道数据灾难恢复需要多长时间。后面这一条需要跟踪备份测试所需的时间。在第2章提到过，数据库实例大小是一个衡量标准，用于确定在预定的目标时间内，数据库实例是否变得太大而无法进行备份恢复。让这成为一个自我改进的循环的方法是，让备份和测试备份的脚本也发送每个备份所需时间的度量。这样，你就有了每个数据库群集的备份时间以及恢复和测试这些备份所需的时间。现在，你有了一种方法来跟踪任何给定的数据集是否变得太大而无法满足业务对MTTR的期望。如果是，那么你就有了数据，可以对工作进行优先级划分，将数据集拆分为可接受的大小，或者重新检查关于数据恢复的SLA。

        关于备份的最后一个重要注意事项是，需要确保你的安全利益相关者对当前数据库和备份的访问受控制规范管控。确保你的云服务商不会将存储备份文件的存储桶访问策略设置为默认允许访问。许多安全事件不是通过破坏当前的基础设施而发生的，而是通过从某个存储桶泄露的备份而发生的。

小结

        合规是一个涉及政策和控制的广泛领域，对每种政策和控制的解释也很多。它不仅影响企业运行数据库的方式，还影响法律、财务和IT部门，甚至影响软件变更的部署方式。本章重点介绍了每种常见的合规性法规如何影响你作为数据库工程师的职责。然后，我们讨论了可能受到这些规则影响的不同实践和架构决策，你也需要考虑这些规则。

        总的来说，解决与控制措施相关的难题的最佳方法是及早计划。分离应用程序用户，计划凭据轮换策略，并确保密码始终以加密方式而不是以明文形式存储。确保在需要开启数据库访问日志之前，有一个可以信任的日志接收管道。最后，你需要对schema变更进行控制和记录。

        本章的目标并不是让你一下子就理解整个基础设施的所有控制，而是让你为每个法规范围内的零碎要求提供证据的任务变得更容易，并且尽可能自动化或简单地将它们组装起来。

        最终，这些控制措施旨在保护企业和客户的隐私。随着公司的发展和进入更广阔的市场，透彻理解每项控制的目标，将使这项重要任务对你和你的团队来说更易于管理。

        上一篇：《第13章-1 什么是合规性》