生产,测试,开发人员环境与安全性

时间:2008-09-16 19:50:20

标签: security

使开发人员能够构建包含私有数据的系统的当前做法是什么?对于那种事情,有人能指出“最佳实践”指南吗?

我们在这里有一个Catch-22,开发人员需要编写与具有被视为“私有”数据的系统相对应的应用程序。 IT管​​理部门希望我们的开发人员无法访问数据(即提供模式或数据结构,但不提供数据本身),而大多数开发人员(包括我自己)希望能够访问生产数据,因为没有代表性数据集可能导致错误的假设(例如数据格式)和稍后的错误。

有没有人对此类事情有任何正式的“最佳做法”?特别是来自某些“BigCo”(例如微软,IBM)的官方公会可能会有所帮助,因为需要说服管理层。

6 个答案:

答案 0 :(得分:5)

我对世界的看法可能有所不同,因为我的总部设在英国,但在过去的20多年里,我主要在公共部门工作处理敏感数据的系统。 规则**完全**切割和干燥。开发区不允许生产数据。

作为一项基本原则,我们不希望对敏感数据的丢失负责。用户对此非常擅长。

在过去12个月内,我的妻子已经从同一制度转变为私营部门,允许开发人员访问生产数据,并对此感到震惊。法律影响(至少在英国)可能很严重。

开发人员不需要**访问生产数据。这简直就是懒惰。定义和创建测试数据以运行定义的测试用例(包括边缘情况),而不依赖于生产数据的随机性质。

如果你**必须**使用生产数据(即你设法说服那些不太了解可以接受的人),确保数据在**到达开发区之前是匿名的**。 p>

答案 1 :(得分:3)

通常,将提供代表私人数据的清理数据子集,但不提供私人数据本身。

答案 2 :(得分:2)

在我的公司,我们开始使用Red-gate的数据生成器来生成测试数据。有一些设置,但您可以使用这些工具生成非常有用的测试数据。是的,我更愿意使用实时生产数据,但这是不可行的(特别是如果您需要在HIPAA中考虑)。它为每列使用正则表达式,并允许您使用相关表的查找表。

答案 3 :(得分:1)

在MediumCo,我们从Test和Dev的生产数据中删除专有数据。过去曾经因为没有完全具有代表性的数据而伤害了我们,但客户之前已经问过这一点,而且通常不是问题,因为这些环境中充斥着大量虚假的专有数据。

答案 4 :(得分:0)

我没有任何最佳实践论文或任何东西。但我认为,如果您正在开发一个作为受保护的环境,而不是生产中承载数据的环境,那么就不会有太多的争论。

也就是说,如果您的生产数据库位于由IT人员托管和控制并受其保护的数据中心中,如果您的开发数据库位于完全相同的方案中,并且未提供任何新方法来访问该信息 - 你的身材会很好。作为良好意愿的附加标记 - 提供允许任何担心安全性的人有机会进行某种渗透测试以确保您说出安全性的事实可能会很好。

当然,另一方面是对不使用数据的成本进行分析:也就是说,它会导致更加繁琐的代码,这将花费开发时间$ xxxxxx.xx,而实际上没有成本允许开发团队的一小部分访问所述数据。

答案 5 :(得分:0)

为避免手动清理/匿名数据,您可以使用随机文本替换 - 用随机字母数字替换每个文本字段中的每个字母数字字符。这样:

  • 从开发人员的角度保持数据的长度,大小等相似
  • 不会导致字符集出现问题
  • 保持日期和数字字段不变,从而可以对日期范围和数量进行准确测试
  • 将满足大多数隐私要求

如果您想再往前一点,可以在电话号码和邮政编码上使用随机数字替换,同时在其他文本字段上使用字母数字替换。

拥有自动替换脚本可让您定期从实时系统获取最新数据转储,因此您的测试在实践中与数据的大小和可变性保持同步。

这确实意味着少数操作将不切合实际(例如,在名称字段上建立索引,在现实生活中将其聚集在普通字母周围)但这些操作应该是有限的。