Security 生产、测试、开发人员环境与安全
当前有哪些做法使开发人员能够构建包含私有数据的系统？有人能为这类事情提供“最佳实践”指南吗 我们这里有一个第二十二条军规，即开发人员需要编写与具有被视为“私有”数据的系统相违背的应用程序。IT管理部门希望我们的开发人员不能访问数据（即提供模式或数据结构，但不能访问数据本身），而大多数开发人员（包括我自己）希望能够访问生产数据，因为没有具有代表性的数据集可能会导致错误的假设（例如数据格式）和以后的错误Security 生产、测试、开发人员环境与安全,security,Security,当前有哪些做法使开发人员能够构建包含私有数据的系统？有人能为这类事情提供“最佳实践”指南吗 我们这里有一个第二十二条军规，即开发人员需要编写与具有被视为“私有”数据的系统相违背的应用程序。IT管理部门希望我们的开发人员不能访问数据（即提供模式或数据结构，但不能访问数据本身），而大多数开发人员（包括我自己）希望能够访问生产数据，因为没有具有代表性的数据集可能会导致错误的假设（例如数据格式）和以后的错误 有人对这类事情有正式的“最佳实践”吗？特别是来自一些“大公司”（如微软、IBM）的官方指导可能会
有人对这类事情有正式的“最佳实践”吗？特别是来自一些“大公司”（如微软、IBM）的官方指导可能会有所帮助，因为它需要说服管理层。通常情况下，会提供代表私有数据的净化数据子集，而不是私有数据本身。在MediumCo，在测试和开发中，我们将专有数据从生产数据中剥离出来。在过去，没有准确的代表性数据对我们有点伤害，但客户以前曾询问过这一点，这通常不是问题，因为环境中充斥着大量伪造的专有数据。在我的公司，我们开始使用的数据生成器生成测试数据。有一些设置，但是您可以使用这些工具生成非常有用的测试数据。是的，我更愿意使用现场生产数据，但这是不可行的（特别是如果你需要考虑HIPAA）。它对每一列使用regex，并允许您对相关表使用查找表。我没有任何最佳实践文件或任何东西。但我认为，如果您是在一个与生产中承载数据的环境一样受保护的环境中开发的，那么就不会有太多反对它的理由 也就是说，如果您的生产数据库位于由IT员工托管、控制和保护的数据中心中，如果您的开发数据库处于完全相同的场景中，并且不提供任何新的方式来访问信息，那么您的状态将非常好。作为一种善意的附加表示——允许任何担心安全性的人有机会进行某种渗透测试，以确保你说的是关于安全性的真相，这可能是很好的
当然，另一方面是对不使用数据的成本分析：也就是说，它将导致错误代码，这将花费xxxxxx.xx美元的开发时间，而允许开发团队的一小部分访问所述数据几乎不需要任何成本。为了避免手动清理/匿名数据，您可以使用随机文本替换—用随机字母数字替换每个文本字段中的每个字母数字字符。这：
- 从开发人员的角度来看，保持数据在长度、大小等方面相似
- 不会导致字符集出现问题
- 保留日期和数字字段不变，这允许对日期范围和数量进行精确测试
- 将满足大多数隐私要求
这确实意味着少量操作将不现实（例如，在现实生活中围绕普通字母聚集的名称字段上建立索引），但这些操作应该是有限的。我对世界的看法可能会有所不同，因为我在英国，但在过去的20多年中，我主要在公共部门工作，负责处理敏感数据的系统。 规则是完全的。开发区不允许有生产数据 作为一项基本原则，我们不想对敏感数据的丢失负责。用户自己也非常擅长这一点 在过去的12个月里，我的妻子从原来的体制转到了私营部门，在那里他们允许开发者访问生产数据，她对此感到震惊。法律影响（至少在英国）可能是严重的 开发人员不**需要**访问生产数据。这只是懒惰。定义和创建测试数据以执行定义的测试用例（包括边缘用例），并且不依赖于生产数据的随机性
如果您**必须**使用生产数据（即，您设法说服不太了解生产数据的人相信它是可以接受的），请确保在**数据到达开发区之前**将其匿名化。如果测试和开发与生产一样受到保护，则每个开发人员都可以访问生产，或者在开发过程中有限地访问。不能以其他用户的身份运行选择查询或登录将严重阻碍我的发展。这正是我们在这里所做的，我可以诚实地说，我们是一家非常大的公司（即超过10万名员工）