我认为我的应用设计能力相对较强，但我从未涉及过敏感数据的工作。我一直在思考审计跟踪的最佳实践以及如何确切地实现它们。我现在不必这样做，但如果医疗公司要求我为他们做一些工作，能够自信地与他们交流将是一件好事。
假设我们拥有一个“学校”数据库，其中教师，课程和学生都在一个多对多成绩表中进行了规范化。您会记录什么？在成绩表上每次插入/更新？仅更新（比如说，一个孩子闯进来想改变成绩，这应该引起警觉）？这是否完全取决于一个人想要多么偏执？是否有最佳实践？
这是应该在数据库中执行的操作吗？（对于每个敏感的SELECT，触发器会插入一行到审计表，记录每个查询？）应该记录什么？Oracle/DB2中是否已经自动集成了相应功能？这应该是应用程序端的逻辑吗？
如果有任何关于如何处理敏感数据的正式文档/书籍（不完全是DoD的“可信计算”规范，但类似），我会很感激的。如果这个问题过于模糊，我很抱歉。我意识到这因应用程序而异。我只是想听听你们处理敏感数据的详细经验。
首先要了解的是您选择的DBMS的本地审计功能。这些功能的详细程度各不相同，但通常提供了一种配置哪些操作被审计，并为它们生成的审计记录提供安全存储的方法。
下一件需要了解的是您要审核什么。例如，在HIPAA和SOX的情况下，您可能会查看PII-个人识别信息。记住，在人们访问奥巴马的电话记录或各种名人的医疗记录时引起的烦恼......这些都是因为系统审核了谁读取了这些记录，审核分析官（AAO）发现未经特别授权的人访问了名人记录。因此，这些系统必须记录访问每个记录的人，并在用户没有真正业务理由的情况下发现访问记录的用户。在这些情况下，似乎用户具有记录的阅读权限，因此如果他们的日常工作需要他们查看记录，则可以这样做。但是，当他们不需要这样做时，他们就会滥用权力并受到相应的制裁（包括失去工作）。
这意味着您可能不想追踪访问记录状态代码和全名（以及有关州的其他信息）的“州表”的用户。该列表没有涉及任何机密信息 - 这并不重要谁读它。当然，几乎没有人应该对其进行写操作；州的列表并不经常更改 -但是可以通过撤销表上每个人的更新和删除权限来处理该问题。
另一方面，您可能确实想记录医疗历史记录（HIPAA）中访问记录的人员，或者在会计系统（SOX）中修改数据的人员。 您可能需要担心谁阅读会计数据，也可能不需要担心；这方面的许多问题可以通过基本权限解决（会计人员有权限，IT人员没有权限）。 然而，审计始终是额外的防线。
请记住，审计记录如果从未查看，则毫无帮助。通常情况下，审计会使系统变慢（因为它在编写审计记录时正在执行更多工作）；在决定实施审计策略之前，了解它会拖慢多少速度非常重要。然而，有些事情比应用程序速度更重要，其中之一是确保自己和其他员工不被监禁。审计可能是必要的，以确保发生这种情况。
Oracle 有一个名为 Oracle Audit Vault 的产品 - DB2 可能有一个相当的产品。
你应该从预防开始。系统不应该允许无效的行为。 如果系统允许需要监控的可疑行为，则应该像其他业务逻辑一样实现，这就是“业务逻辑”。
如果你想在你的数据库中执行某些操作，你可以研究一下日志传送（术语可能会因不同的关系型数据库管理系统而有所不同）。基本上，任何 DML 操作都会被记录到一个文件中。你可以利用这个信息进行备份和时间点恢复，甚至进行复制/高可用性/故障转移等。如果你以“附加只读”方式将日志发送到一个独立的“可信”系统中（即，日志传送过程有权限创建新的日志文件，但没有修改现有信息的权限），你已经拥有了原始审计功能。如果你以安全的方式实现（例如，身份验证、不可否认性），你很可能已经接近“符合性”:-p
当然，浏览大量的INSERT / UPDATE / DELETE语句并不是最复杂的工作方式。
