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