Security 对一个业务线应用程序进行审计时会发生哪些安全事件？

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

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

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

---

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

考虑到审计通常是关于责任的您可能希望记录那些可能导致任何人/事需要负责的事件的行为

更改客户记录

形态改变

删除数据

保持其中一些内容的版本化是一个好主意，这样您就可以回滚对重要数据的更改。首先加上“谁改变了”是很直截了当的

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

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

将应用程序的审计元素视为事件树。根目录是您记录的内容，例如“Dave删除了客户记录2938”。可以记录根目录的任何子目录，并且如果必须将其作为审核事件的一部分记录，则可以将其绑定到根目录。例如，您可以断言某个审核事件“Dave deleted…”与某些账单信息关联，也可以作为约束条件的一部分进行漫游

---

但我不是专家。

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

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

---

如果你真的想知道什么是绝对必须审核的，请与审核你的人员交谈，询问他们希望看到什么。

通常审核与业务控制和业务流程有关。审计的目的是证明遵循了特定的流程或政策。您是否有任何已定义的策略或规则？最好将审核日志放在调用堆栈的顶部（谢谢：）将其视为事件树，由根触发，根是已审核的元素。事实上，我会在答案中加上：P@HLGM-+1我同意，我的答案是使用更细粒度的下游控制对基于角色的访问事件进行更多的审计，例如您建议在通用审计/身份验证系统的保护伞下进行的控制。分层安全等等。您的许多建议可能还涉及操作系统级权限/审核问题（捕获DBA和使用USB HDs运行的人员）