似乎每周都有新的数据泄露需要阅读(或发推(。 我最近发现了这种可爱的可视化现象，关于像你我这样的人的越来越多的私人数据被暴露了。 您可以按行业、泄漏方式和数据敏感度对数据进行过滤和/或排序。 这是一个非常令人沮丧的休息时间。
读完之后，您可能想查看您的详细信息是否包含在haveibeenpwned上列出的任何数据泄露中。com。 多亏了这个网站，以及我在2016年领英被入侵后收到的一个警告，我现在使用了一个密码管理器——我建议你也这样做。
如果你负责一个数据库，并希望避免你的公司成为一个高度批判性的——也是有趣的——电视小品的主题，比如史蒂芬·科拜尔在《晚间秀》中的《公平》(Equifax)咆哮，你需要非常认真地考虑如何保护你的数据，尤其是在GDPR等数据隐私法规日益涌现的情况下。
作为数据库生命周期管理(DLM)和数据库开发顾问，我看到了许多开发、测试和生产环境。 我很惊讶我在开发数据库中经常看到敏感的生产数据，这些数据对整个开发团队都是可用的。 我有时需要要求客户取消我对这些开发系统的访问权限，因为作为一名顾问，我不想让自己暴露在这样的风险中，即我可能会无意中点击一个网络钓鱼链接，让坏人进入，从而导致数据泄露。
(如果你认为自己不会犯像点击网络钓鱼链接这样的愚蠢错误，那就认真点。 它会发生在我们中最好的人身上。 谨慎和保护自己是明智的，不管你有多自信永远不会犯错。)
关键是黑客不再瞄准生产系统了。 数据库管理员(DBAs)非常正确地做出了越来越大的努力来锁定那些系统，这样就更难进入。 黑客更容易在网络上扫描开发数据库或被遗忘的备份文件。 问问你自己，如果有人把你的开发数据库上传到互联网上，你(或者你的老板)会有什么感觉？
你需要担心的不仅仅是黑客。 根据IBM的2017年数据泄露成本研究，恶意攻击是略低于一半数据泄露的根本原因。 系统故障和人为错误大约各占四分之一。
毫无疑问，如果开发数据库和备份中的数据得到了同等程度的重视，这些数据泄露中的很大一部分是可以避免的。
也许2016年的优步黑客无法找到保存在开发者的GitHub报告中的凭证，该报告允许他们访问骑手和司机信息的档案。 也许那个有1的错误备份。垃圾邮件公司河城媒体不会将370亿个电子邮件地址错误地上传到公共存储帐户。
不幸的是，传统的数据库安全让我们失望了。
开发人员需要访问开发数据库来完成他们的工作。 他们需要能够使用适当的测试数据来测试他们的代码。 传统的安全功能(登录、角色和用户，甚至是加密技术、动态数据屏蔽和行级安全等)可以用来管理谁有权访问生产系统中的数据，但是如果开发或测试数据库已经拥有敏感数据，这些基本的安全功能在数据保护方面毫无价值。 即使是加密数据也只有在**保持安全的情况下才会保持安全。
当然，传统的安全功能会保护生产系统中的数据，但如果数据已经被复制到不太安全的环境中，则不会。 大多数人都没有尽可能严密地跟踪它。
为了有效地保护数据，我们需要更有意识地思考，不仅要考虑生产数据库，还要考虑构成我们数据库生命周期的所有其他数据库和备份，包括开发和测试系统以及开发工作站。 我们需要知道我们的安全边界到底在哪里。 敏感生产数据的任何拷贝都需要在安全范围内，而不是在安全范围之外。
我建议开发和测试系统位于安全边界之外，它们不应该包含敏感数据。 证据告诉我们，如果数据开始传播到具有较低优先级安全策略且有更多人可以访问的许多环境中，人们更有可能遭受数据泄露。 我们应该假设我们的开发和测试系统可能在任何时候被泄露到互联网上，我们应该在设计我们的开发和测试数据时牢记这一点。
此外，如果您的数据受到GDPR等法规的监管，您可能需要通过获得100%的数据主体的“明确同意”(这可能几乎不可能)或论证“合法利益”(对大多数人来说，这可能是一个相当大胆和困难的案例)来证明出于开发/测试目的处理数据是合理的。
相比之下，通过确保敏感数据不会离开生产领域，您的流程符合监管期望，如GDPR协议第5条中描述的数据处理六项原则，涵盖数据最小化、用途限制、存储限制和完整性/保密性等领域。
那么，我们如何保护自己，防止敏感的生产数据泄露到开发领域呢？
由于传统的数据库安全对我们帮助不大，我建议采用以下五个步骤。 这符合各种标准，如国际标准化组织27001和英国信息专员办公室的官方建议。
坦白说，这只是常识。
数据保护就是风险管理。 有些数据比其他数据更敏感和/或更有风险，值得特别关注。 GDPR等法规明确承认这一点:
“可特别通过经批准的行为守则、经批准的认证、理事会提供的准则或数据保护官员提供的指示，提供关于执行适当措施的指导，以及关于管制员或处理员证明遵守规定的指导，特别是关于确定与处理有关的风险、评估其来源、性质、可能性和严重性以及确定减轻风险的最佳做法的指导。”
采取基于风险的数据保护方法要求组织了解与其持有的数据相关的风险以及这些数据的位置。 因此，任何负责管理数据安全的人的首要任务应该是对他们(在每个环境中)持有的所有数据进行审核/清点，并记录数据敏感度。
Gartner最近宣布，数据目录是数据管理和分析领域的新亮点。 理解数据敏感性是任何基于风险的数据安全方法的基本要求，数据目录允许用户轻松了解数据库中存在哪些数据以及数据的敏感性。
根据步骤1的结果，对不同种类的数据应用不同的安全措施可能是合适的。 例如，如果您在一列中存储外币汇率，在另一列中存储银行余额，您可能希望对每一列应用不同的安全流程。
例如，你可以选择将实际汇率复制到dev中(因为这些都是公共知识)，但以某种方式掩盖银行余额(因为这显然是私人信息)。
我们的安全流程应该由一个策略来定义，该策略基于数据敏感性分类来确定诸如谁应该有权访问数据、如何实施访问、数据最小化和屏蔽技术以及如何管理备份等事项。
这些策略非常有用，因为它们通常允许组织通过单一流程同时遵守多个法规。 只要您的数据保护政策对与数据处理/控制相关的道德和安全问题采用常识性的、基于风险的方法(并且您可以提供证据证明您的政策得到了遵守)，您可能会发现，当下一个数据隐私法规出台时，您需要做的额外工作相对较少。
然而，根据我的经验，这些数据保护策略通常是陈旧的Word文档，它们会被遗忘在办公室黑暗角落里布满灰尘的文件柜中。 他们很少被审查，他们只是在审计时被挖掘出来，而且他们经常是过时的。 如果我问普通开发人员他们的组织是否有数据保护策略，他们的回答可能是: “我想是的——但我从来没读过。”
我的建议是，我们需要将我们的数据保护政策数字化。
我可以想象未来我们的数据保护政策将积极保护我们的财产。 它们将成为由数据库管理员或数据保护官员管理的工具(DPO)。 数据库管理员团队旁边的监视器上会显示数据隐私监控仪表板。 对策略的更改可以被审计，甚至是源代码控制。
当审计员来评估数据保护和隐私方面的合规性时，解释您的财产的安全性是如何管理的并不重要，您将有证据来支持它。
如果您处理敏感数据，这是您的安全策略的重要部分。
我们使用传统的安全功能来锁定生产，但是我们使用自动配置过程来保护敏感数据免受lea攻击king into our non-production environments. And since the non-production environments are often an easier target, it’s arguable that the automated provisioning processes are more (or at least equally) important.
DevOps has taught us the importance of shifting as much testing as possible as far left as possible. Gone are the days of those integration testing and release testing phases during month 10 and 11 of a 12-month project (which always seemed to run late and over-budget). These are activities that are largely automated nowadays, and which are running constantly as part of your development processes.
By shifting testing activities to the left, we can write better quality code and ship fewer bugs and regressions. That alone has value with regards to a risk-based approach to data protection. 虫子很危险。
可以说，测试的最佳数据是生产数据。 不幸的是，根据我到目前为止所说的，如果你有敏感数据，这是不可行的。 我们能提供的最好的现实情况是生产数据的匿名或屏蔽副本，其中所有敏感和/或识别信息都已被删除。 我建议您的数据库是否适当匿名的衡量标准如下:
“想象一下，有人将您的未加密开发数据库复制到公共互联网，然后在一个受欢迎的黑客网站上发布链接。 你的心跳了一拍吗？”
如果答案是肯定的，那么数据就不应该在开发领域。 基于我前面提到的IBM的研究，你不能相信你的开发人员有这些数据。 这不是针对个人的——我不相信自己。 这也是我系安全带的原因，也是你做备份的原因。 让你的组织面临风险是不值得的。
DevOps还教会我们自助服务很重要。 为数据库管理员手工进入和配置数据库以及为每个开发人员和每个新特性分支手工运行屏蔽规则记录一张票据(例如)是非常低效的。
我们需要为开发人员提供一个实用且可重复的过程，以便他们能够为自己提供一个包含合适测试数据的开发数据库。 这应该是他们能够为自己提供测试数据的唯一方法。
没错。 这是第四步。 不是第一步。
如果我主要考虑我的生产系统的安全性，也许我会以不同的方式安排这些步骤，但是现在，我谈论的是数据保护环境中的安全性，如果开发和测试系统中的所有敏感数据都可以访问，那么锁定生产数据库有什么意义？ 我向你保证，无论如何，黑客和任何恶意(或粗心)的员工在攻击你的生产服务器之前，都会从你的开发服务器上泄露数据。 这只是更容易做到。
当然，我们确实需要锁定生产系统，但是我的情况很简单，如果您跳过了前三个步骤中的任何一个，这可能是一个毫无意义的练习。 你在打磨泰坦尼克号上的黄铜。 水正冲刷着你的双脚，但如果这是你做的最后一件事，你会把舷窗闩弄得一尘不染。
也就是说，虽然它可能只是列表中的第四步，但它仍然很重要。 当然是了！ 没有锁定生产，你显然是在敞开大门。 我们确实需要我上面提到的所有传统安全工具和特性来帮助我们做到这一点。 我不想让你读这篇博文，并认为它们不重要。 是的。
我们的访问控制将由我们目录中的敏感性标签和我们关于谁应该访问和谁不应该访问的政策来驱动。 我们当然希望报告我们的访问控制与我们的政策的符合程度，并监控违反政策的情况。 如果有人针对生产系统创建了新用户，也应该记录下来，并可能需要发出警报。
至此，您拥有了一个数据目录、一个数字化的策略引擎、一个基于策略的自动化过程来调配掩蔽的非生产环境，以及一套针对您的生产系统的基于策略和基于数据敏感性的访问控制。
然而，数据保护不是一次性的任务，而是一个持续的过程。 一旦我们把船整理好，我们希望它保持整洁。 例如:
- 随着我们的数据、环境和法规的发展，我们需要不断审查我们的政策
- 随着时间的推移，将会添加新的列，它们需要根据隐私进行分类，我们可能需要为它们创建屏蔽规则
这些东西中的一部分需要通过手动检查我们的流程来监控。 例如，软件不太擅长捕捉可能导致我们重新评估数据敏感度分类的不断变化的社会环境。
另一方面，其中一些可以(也应该)被自动监控。 例如，可以想象，如果我的监控软件发现开发域中的数据看起来可疑地像敏感的生产数据，它会发出警报。 如果任何不是数据库管理员组成员的用户获得了对生产系统的访问权限，我也可能会收到警报。
很抱歉，这可能会让你觉得工作量很大。 我也意识到我所描述的许多软件还没有被编写出来，并且还没有上市。
然而，当我们中的绝大多数人已经受到多次数据泄露的影响，当我们目睹数据泄露的规模、频率和后果越来越危险时，很明显，我们迄今为止管理数据安全的方式并没有奏效。
这就是为什么我认为我们认为传统数据库安全的特性不足以保护您的数据。 为了满足日益严格的数据隐私和保护要求，我们还需要做更多的工作。 作为一个行业，我们需要改变我们对数据安全的看法。
好消息是，我预计未来几年将会出现大量的创新和新工具来填补一些空白。 我希望我在雷德盖特的朋友们站在这场运动的最前列。 看看他们的SQL数据隐私套件。