我认为自己在应用程序设计方面相对精通，但我从来不用处理敏感数据。我一直想知道审计跟踪的最佳实践是什么，以及应该如何实施它们。我现在不必这样做，但如果他们要求我为他们做一些工作，能够自信地与医疗公司交谈会很好。
假设我们有一个“学校”数据库，“老师”、“班级”、“学生”都在多对多“成绩”表中标准化。你会记录什么？“成绩表”上的每次插入/更新？只有更新（比如说，一个孩子闯入并想改变成绩，这应该发出危险信号）？这是否完全取决于一个人想要的偏执程度？有最佳实践吗？
这是应该在数据库中完成的事情吗？（每个敏感 SELECT 上的触发器会在记录每个查询的“审计”表中插入一行？）应该记录什么？是否有自动内置到 Oracle/DB2 中的功能为您做这件事？这应该是应用程序端逻辑吗？
如果有人有任何关于如何处理敏感数据的正式文档/书籍（不是国防部的“可信计算”规范，而是类似的东西：P），我将不胜感激。如果这个问题非常模糊，我很抱歉。我意识到这因应用程序而异。我只是想听听您在处理敏感数据方面的详细经验。
首先要了解的是您选择的 DBMS 的原生审计功能。这些在细节上有所不同，但通常提供一种配置审计哪些操作的方法，并为它们生成的审计记录提供安全存储。
接下来要了解的是您要审核的内容。例如，对于 HIPAA 和 SOX，您可能正在查看 PII - 个人识别信息。记住人们对访问奥巴马的电话记录或各种名人医疗记录的大惊小怪，或者......那些被抓住是因为系统审核了谁阅读了这些记录，而审计分析官 (AAO) 发现名人记录被人们访问了没有特别授权这样做的人。因此，这些系统必须记录谁访问了每条记录，并发现这样做的用户没有真正的商业理由这样做。在这些情况下，用户似乎具有读取记录的权限，因此如果他们的日常职责要求他们查看记录，他们可以这样做。但，
这意味着您可能不想跟踪谁访问了状态表，该表记录了州代码和全名（以及有关州的其他信息）。该列表没有任何机密信息 - 谁阅读它并不重要。当然，几乎没有人应该写信给它。状态列表不会经常更改 - 但这可能可以通过撤销每个人对表的更新和删除权限来处理。
OTOH，您可能确实想要记录谁访问了病史 (HIPAA) 中的记录，或者谁修改了会计系统 (SOX) 中的数据。您可能需要也可能不需要担心谁会读取会计数据；其中很多可以通过基本权限来处理（会计人员有权限；IT 人员没有）。但是，审计始终是一道额外的防线。
请记住，如果从未查看过审计记录，它们将无济于事。一般来说，审计会减慢系统的速度（仅仅是因为它在写入审计记录时会做更多的工作）；在决定实施您的审计策略之前，了解它减慢了多少是很重要的。但是，有些事情比申请速度更重要，其中之一就是让自己和其他工作人员免于入狱。审计可能是必要的，以确保发生这种情况。
Oracle 有一个名为 Oracle Audit Vault 的产品——DB2 可能有一个等效产品。
你应该从预防开始。系统不应允许无效操作。时期。如果系统允许需要监视的“可疑”操作，那就是“业务逻辑”，您可能最好像其他业务逻辑一样实施。
如果您想在数据库中执行某些操作，可以查看日志传送（术语可能因 RDBMS 与 RDBMS 不同）。基本上，任何 DML 操作都会记录到文件中。您可以将此信息用于备份和时间点恢复，甚至用于复制/HA/故障转移/等。如果您以“仅附加”的方式将日志发送到单独的“受信任”系统（即日志发送过程具有创建新日志文件的权限，但不能修改现有信息），那么您已经拥有原始审计功能. 如果您以安全的方式（即身份验证、不可否认性）进行操作，您甚至可能非常接近“合规性”：-p
当然，筛选大量的 INSERT/UPDATE/DELETE 语句并不是最复杂的工作方式。