保护开发人员的敏感数据

我运行的企业应用程序同时使用MySQL和MongoDB数据存储。我的开发团队都具有对计算机的SSH访问权限，以便执行应用程序发布，维护等。

最近，当用户开始在应用程序上存储高度敏感的数据时，我对企业产生了风险，因为开发人员可以间接访问此数据，这引起了很大的麻烦，因此我现在受命保护数据，以防止数据被盗用。无障碍。

在我看来，这是不可能的，因为如果应用程序可以访问数据库，那么有权访问计算机和应用程序源的开发人员将始终能够访问数据。

安全性不是您在项目结束时就可以挥舞的魔杖，它需要从第一天开始考虑和构建。它不是一个固定的工具，它是一系列反复应用和审查的解决方案的一致应用定期作为整个系统的一部分，只有最薄弱的环节一样强大。

就目前而言，您已标记出安全方面的关注，这是一个很好的第一步。现在，您至少需要定义：-

• 您要保护哪些数据？
• 您正在尝试保护谁免受数据攻击？
• 谁真正需要访问什么（何时）？
• 数据被泄露会对法律/财务/业务产生什么影响？
• 具有访问数据权限的个人/团体的法律/财务/业务需求是什么？
• 当企业以前没有业务需求时，企业愿意分配给“获得安全，保持安全”策略的预算是多少？
• 系统需要对数据进行什么访问？
• 此应用程序依赖于什么过程和系统？
• 如何保护这些环境？
• 谁将负责实施它并审查整个过程？

除非您详细了解所有这些内容，否则您实际上将一无所有。这些信息将定义可以（和不能）应用哪些缓解措施以及原因。

最好的办法可能是认识到您没有必要的经验，最好是请具有这种经验的新人来。我经常听到有人回答说没有预算-如果认为这确实很重要，那么就会找到预算。

你是对的。如果应用程序能够访问公司机器上存储的内容，而无需用户每次都传递额外的信息，则服务提供商的程序员，维护人员，系统管理员等都可以访问该内容。从根本上讲，这是不可避免的，并且是不安全的主要根源（爱德华·斯诺登（Edward Snowden）是系统管理员，在“最高机密”之上具有特殊特权，因为根本就没有不授予它们的方法。）

避免这种情况的唯一方法是要求用户向企业计算机提供永远不会提供的信息。这是乏味且容易出错的，因为没人会记住足够的信息来形成安全的访问屏障，因此人们将立即开始以电子方式将其凭据存储在某个地方，这将成为新的攻击目标（并且很可能成为攻击的目标）。比您要维持的目标更弱的目标）。但是，如果您要真实地断言“我们的员工实际上无法访问我们用户的内容”，那是唯一的方法。

（还要注意，这种商业模式在政治上似乎变得站不住脚。由于试图做到这一点，安全服务迫使企业不得不倒闭。我知道提供隐私保证具有商业价值，但不可能有更多的商业价值。商业价值，而不是坚持经营的根本目标。）

你说的很对；如果只是为了诊断生产问题，某些开发人员将始终需要访问实时数据。您能做的最好的事情就是通过减少涉案人数来限制潜在的损失。

With great power comes great ... opportunity to really, *really* foul things up. 

许多开发人员不希望承担这种责任，而其他人则不想承担这些责任，因此不应该承担。

问题：您的开发团队为什么要执行实时发布？
我建议您需要一个发布管理“团队”（即使这只是您团队的一部分，再加上业务代表才能做出任何日常的“决定”，例如“执行/不执行”）？这将消除开发人员接触Live的任何 “需求” 。

开发商与公司之间是否有任何保密/保密协议？它是笨拙的，但可能有一些优点。

问题是您的开发人员可以访问系统。如果他们需要生产数据进行调试，请给他们一个数据库转储，在其中删除所有敏感信息。然后，开发人员可以使用该转储。

部署新版本不应涉及任何开发人员-纯粹的管理任务，甚至更好的是完全自动化的任务。还应注意释放和部署是两个非常不同的任务。如果您的进程不知道这一点，则相应地进行更改。

安全规则＃1：如果某人有权访问信息，则他们有权访问该信息

该重言式很烦人，但这是事实。如果您授予个人访问权限，则他们有权访问数据。对于用户而言，这通常意味着访问控制，但对于开发人员……好……他们是必须编写访问控制的人。

如果这对您来说是一个主要问题（听起来确实如此），请考虑在软件中构建安全性。一种常见的模式是分层设计安全软件。在最底层，一个值得信赖的开发团队设计可以管理访问控制最裸露的软件。该软件已得到尽可能多的人的验证。设计该代码的任何人都可以访问所有内容，因此信任至关重要。

之后，开发人员可以在该核心层之上构建更灵活的访问控制。这段代码仍然必须是V＆Vd，但它并不那么严格，因为您始终可以依赖核心层来覆盖要点。

图案向外延伸。

最困难的部分，确实是艺术设计这些系统中，是如何建立的每一层，使开发人员可以继续开发和调试，同时还提供贵公司与你期望的安全性。特别是，您将需要接受调试需要比您想象的更多的特权，而尝试将其锁定将导致一些非常生气的开发人员。

作为辅助解决方案，请考虑出于测试目的而创建“安全”数据库，以便开发人员可以提取所有安全机制并进行认真的调试。

最后，您和您的开发人员都需要了解安全性的关键原则：所有安全性都是安全性和可用性之间的平衡。作为一家公司， 您必须保持自己的平衡。该系统将不是完全安全的，并且将不能完全使用。随着公司的发展和/或对开发人员的需求变化，这种平衡甚至可能会发生变化。如果您对这种现实持开放态度，则可以解决它。

设置应用程序的两个部署，这些部署也使用单独的数据库部署。一种是生产部署，一种是测试部署。

测试部署应仅具有测试数据。这可以是为此目的而创建的幻想数据，也可以是匿名的生产数据副本，以防止开发人员发现数据背后的真实人物和实体。

在两家金融公司中，开发人员无法使用生产机器。所有修改生产机器的请求都必须通过脚本进行审批，并由经理批准。开发团队已完成实际部署。我认为这个团队只是员工，并且通过了背景调查。他们也没有开发人员知识，因此如果愿意的话可能无法窥探。除此之外，您还可以使用存储在环境变量中的密钥对所有数据库条目进行加密。即使数据库公开泄漏，也没有人可以读取它。可以进一步对该密钥进行密码保护（PBKDF），以便只有主管才能对其进行解锁。您的系统在启动时可能需要输入执行密码（或更可能是委派给dev-ops或dev-ops管理器）。基本上，策略是分散知识，因此一个人不存在必要数量的必需知识，并且存在制衡。这就是可口可乐保护配方的方式。坦白地说，其中一些答案是解决方案。

MongoDB具有有限的安全控制，并且依赖于安全环境。绑定到特定的ip和端口（以及自2.2起的ssl）和粗略的身份验证，这就是它所提供的。MYSQL将GRANT o ON db.t添加到...静态数据未加密，默认情况下不使用ssl。创建一个围栏​​。开发人员对与应用程序相关的日志文件的只读访问权限应足以调试。自动化应用程序生命周期。

Ansible帮助我们在许多单租户环境中自动化标准操作（部署，升级，还原），同时使用独特的加密保管库存储敏感的环境变量，例如主机，端口和凭据。如果每个保管库只能由不同角色解密，并且只能在堡垒主机上进行记录操作，则可审计性提供了可接受的安全性。如果您授予SSH，请使用selinux避免密钥篡改，使用具有ldap / kerberos身份验证的堡垒主机进行管理，并明智地使用sudo。