数据分类策略的示例包括：例如密码，私钥，SAML令牌和信用卡号。
受限制的数据，例如用户名和客户ID。 br />
此分类具有一定的义务：
在任何情况下都绝不能在日志文件中提供任何高度受限的数据。在特定条件下可以在日志文件中使用。例如，如果服务发生事故，那么值班工程师将能够制定“防碎玻璃”程序来访问此数据以诊断问题。反之，“破坏玻璃”程序将触发该工程师的审查，审核，并可能会暂时取消该工程师的特权。不能提供直接解决此问题的直接方法的市场上广泛的日志记录，监视和检测工具吗？例如，Splunk和AppDynamics都可以根据情况施加不同的访问控制遥测被暴露的程度；这意味着您可以创建一个掩盖
<customerId>NNNNNNNNNNNN</customerId>的过滤器。但是，这两种工具都不能为您提供自动识别信用卡号和自动屏蔽信用卡号的功能。通过将操作平台的职责下放给开发团队，可以访问并手动过滤数据，这些数据可能会暴露给更广泛的受众。#1 楼
我认为解决方案可以归结为确保数据保护的广泛方法：数据分类：最有效的技术策略是在创建时对数据进行严格分类。在其核心处，开发人员负责确保为所有记录的信息分配一个类别。例如，可以通过Splunk元数据实现分类，而Splunk元数据又可以用于根据其数据分类将日志条目定向到不同的存储桶。事件分区：通常需要记录日志敏感信息以及非敏感信息。例如，如果要注册新用户，则可以登录：
客户ID（受限制）
客户类型（受限制）
获取源（不受限制）
相关性ID（不受限制）
可以将这一“事件”分为两部分，一部分包含受限制的信息，另一部分包含无限制的信息。通过允许将过滤规则定向到不同的存储桶，这与第一点是一致的。
数据屏蔽：在特定情况下，可能无法对源数据进行分类，以我的经验，日志记录解决方案确实屏蔽规则以X删除敏感数据。在链接的示例中，使用
sed命令将正则表达式应用于来自特定源的所有数据。一旦屏蔽了受限制的数据，则可以将事件视为不受限制的事件。必须注意该规则，以确保对事件至关重要的信息（如关联ID）与用于匹配敏感数据的正则表达式不匹配。事件过滤：万不得已，如果某些特定类型或来源的事件包含无法分类或屏蔽的敏感数据，则有必要将它们过滤到单独的存储桶中。在这种情况下，只能通过Break-Glass机制访问受限制的存储桶中的信息，以根据事件的规定绕过访问控制。
对于每种解决方案，测试都是确保以下方面的关键：没有任何东西滑过裂缝。日志记录和事件管理必须被视为一流的非功能性要求，并且必须对解决方案应用相同级别的开发严格性-包括同行评审和测试，以确保在所选工具中对数据进行了正确分类和分区。
#2 楼
这取决于您所说的“日志文件”的含义。如果您的意思是用于验证系统运行正常的遥测数据，我会说“不要记录敏感字段”。您不需要这种信息来提醒您高或低的交易速率，对相关服务的响应时间等。只写管道，用于写入数据，但写入器无法读取数据。然后，您的计费和审核管道就开始了，您可以在那里控制哪些人查看了各个记录。最后，安全性归结为带有自己的安全日志文件的文档化流程，等等。点，因为所有数据均已写入，所以您必须信任某人或某个过程，以便以后可以读取。
评论
不予置评。很好巨魔无处不在。
–不退款不退货
17 Mar 27 '17 at 21:03
评论
是关于封闭源/ Saas系统的问题，还是包含ELK堆栈的更通用的问题？我怀疑适用于SaaS日志记录和遥测产品的任何内容都可以适用于开源工具。可能有支持此功能的功能，例如Splunks可根据规则或数据屏蔽将其路由到不同的存储桶，但这些功能在开放源代码堆栈中也可以同时使用。
@ Pierre.Vriens ELK = ElasticSearch，LogStash和Kibana：elastic.co/webinars/introduction-elk-stack
@RichardSlater慈悲的教导！
@ Pierre.Vriens我相信它是DevOps，因为在相对较小的人群可以访问数据并手动过滤数据之前，通过将操作平台的职责下放给开发团队，此数据可能会暴露给更广泛的受众。 br />