我已经审核了授权成功，失败和注销。
我考虑过审计（记录）每个方法调用并保留所有修改过的每一行和一列的版本，但这两个选项都会大大增加审计的复杂性。审核随机子集看起来太随机了。
法律规范（FISMA，C＆amp; A）只是说需要审核的事情。
我还忘记了其他任何非特定领域的审核策略吗？
答案 0 :(得分：3)
考虑到审核通常是关于问责制，您可能希望记录那些可能导致某人/某事需要负责的事件的行动。
最好将这些内容保留为版本，以便您可以回滚对重要数据的更改。首先添加'谁改变'是非常直接的。
除非有人可以直接访问数据库，否则通常应用程序记录影响数据库的任何事件......例如更改许多表的事务......可能就足够了。只要您可以将可审计的逻辑操作链接到逻辑责任单元，无论它影响哪个子系统，您都应该能够追踪责任。
您不应该直接记录方法调用和数据库更改，而是导致这些调用和更改的业务逻辑，以及使用该逻辑的人员。调用/表格更改与某些审计消息之间的少量后端代码链接因果关系也是有益的（如果您有资源）。
将您的应用程序的审计元素视为事件树。根目录是您记录的内容，例如“Dave删除客户记录2938”。根的所有子项都可以进行记录，如果将其作为审计事件的一部分进行记录很重要，则可以将其绑定到根目录。例如，您可以断言某些审计事件“Dave已删除...”与某些结算信息相关联，这些信息也会作为约束或其他内容的一部分进行操作
但我不是专家。
答案 1 :(得分：2)
我同意Aiden所说的很多内容，但我坚信审计应该在数据库层面。使用动态sql访问的数据库太多，因此权限位于表级别（至少在SQL Server中）。因此，提交欺诈的人可以绕过所有规则在数据库中输入删除或更改数据。在一个设计良好的系统中，只有几个人（dba和备份）有权在prod中更改审计触发器，因此如果他们更改了他们无权更改的数据，大多数人都会被抓住。通过应用程序审核永远不会抓住这些人。当然，如果他们选择这样做，几乎没有办法阻止dbas进行欺诈，但是某人必须拥有数据库的管理员权限，所以在选择这样的人时你必须格外小心。
我们审核数据库中所有数据的更改，所有插入以及数据库中大多数表的所有删除。这样可以轻松退出更改并提供审计跟踪。根据数据库存储的内容，您可能不需要这样做。但我会审核每一笔金融交易，每笔人事交易，以及与订单，仓储或任何其他可能遭受犯罪活动有关的交易。
如果您真的想知道绝对必须审核的内容，请与将审核您的人交谈并询问他们希望看到的内容。