security - 一个业务线应用程序审计哪些安全事件？

Question

我已经审核了授权成功、失败和注销。

我考虑过审计（记录）每个方法调用并保留曾经修改过的每一行和每一列的版本，但是这两个选项都会大大增加审计的复杂性。审计一个随机子集太随机了。

法律规范（FISMA、C&A）只是说需要审计一些东西。

还有其他我忘记的非域特定审计策略吗？

Answer 1

考虑到审计通常与问责制有关，您可能希望记录那些可能导致某人/某事需要负责的任何事件的行为..

1. 更改客户记录
2. 配置变更
3. 数据删除

保留其中一些内容的版本是一个好主意，这样您就可以回滚对重要数据的更改。首先添加“谁改变了”非常简单。

除非有人可以直接访问数据库，否则通常应用程序记录任何影响数据库的事件……例如更改许多表的事务……可能就足够了。只要您可以将可审计的逻辑操作与责任的逻辑单元联系起来，无论它影响哪个子系统，您都应该能够追踪责任。

您不应该直接记录方法调用和数据库更改，而是记录导致这些调用和更改的业务逻辑，以及使用该逻辑的人。少量后端代码链接调用/表更改和一些审计消息之间的因果关系也将是有益的（如果你有资源）。

将您的应用程序的审计元素视为事件树。根是您记录的内容，例如“Dave 已删除客户记录 2938”。可以记录根的任何子节点，如果将其作为审计事件的一部分进行记录很重要，您可以将其绑定到根。例如，您可以断言某些审计事件“Dave deleted ...”与某些计费信息相关联，并且作为约束或某些东西的一部分也将被随身携带

但我不是专家。

Answer 2

我同意 Aiden 所说的很多内容，但我坚信审计应该在数据库级别进行。使用动态 sql 访问的数据库太多，因此权限位于表级别（至少在 SQL Server 中）。因此，进行欺诈的人可以绕过所有规则在数据库中输入删除或更改数据。在一个设计良好的系统中，只有几个人（dba 和备份）有权更改 prod 中的审计触发器，因此如果他们更改未经授权更改的数据，大多数人可能会被抓住。通过应用程序进行审计永远不会抓住这些人。当然，如果 dbas 选择这样做，几乎没有办法防止他们进行欺诈，但是必须有人对数据库具有管理员权限，所以在选择这样的人时必须格外小心。

我们审计数据库中大多数表的所有数据更改、所有插入和所有删除。这允许轻松退出更改并提供审计跟踪。根据您的数据库存储的内容，您可能不需要这样做。但我会审计每一笔金融交易、每一笔人事交易，以及每一笔与订单、仓储或其他任何可能涉及犯罪活动的交易。

如果您真的想知道绝对必须审核的内容，请与将要审核您的人交谈，并询问他们想要查看的内容。