【问题标题】:Security Monitoring and Tracking Standards [closed]安全监控和跟踪标准 [关闭]
【发布时间】:2011-08-29 02:17:45
【问题描述】:

我正在开发一个处理身份验证/授权的系统,并且需要跟踪个人登录尝试、更改权限/用户、尝试失败等。我们希望能够解析这些信息到数据库中以供以后进一步分析/检索。

在我们当前的实现中,我们使用的是使用日志框架(在本例中为 Log4j,但这不是重要的)进行日志记录的自制标准。日志框架是跟踪这些信息的正确机制吗?在我看来不是;我一直认为日志记录是对代码的一种验尸形式——更多的是为了说明调试等目的时发生了什么。这对我来说更像是一种报告机制。这类问题有什么标准吗?是否有人们使用的标准解决方案/格式?使用日志框架是正确的解决方案,还是有更好的方法来处理此类数据?在查看这些信息并将其呈现给利益相关者时,我可以参考哪些来源?

我应该注意 - 正在记录的数据已经根据合规/安全标准(无密码等)进行过滤,并且所有记录都发生在我们的内部环境中。我更多的是在寻找一种我们可以管理认证和授权系统的更改信息的方法。

【问题讨论】:

  • 这有点不同——我们谈论的是认证和授权访问的机制,而不是访问应用程序数据的方法。我们通过数据库系统跟踪该信息。

标签: security tracking usage-tracking


【解决方案1】:

您似乎正在使用 log4J 进行审计(也可能用于记录诊断或跟踪信息)。回答你的问题:

是一个Logging框架吧 跟踪此情况的机制 信息?

直接的答案是“不,日志框架不是正确的机制”。有某些属性,如果存在于日志框架中,将使其具备被用作审计框架的能力。

其中一些要求如下所示,log4j 可用于满足其中一些要求。这并非详尽无遗,我建议您查看审计框架(如 LAUS)的实施,以得出更全面的列表。

  • 审计框架必须确保对事件进行故障安全审计。这可能取决于应用程序如何使用框架,但基本要求是如果审计失败,那么应用程序也应该如此。如果无法审核事件,则应用程序不应尝试处理任何请求。日志框架通常无法满足此要求。
  • 理想情况下,审计框架应提供一次写入和只读的存储。换句话说,写入审计日志的事件必须也不应该被删除。审计框架通常不会自行实现这种保护,而是依靠其他因素的组合来确保日志是防篡改的。
  • 审计框架应允许在不同系统上存储审计日志。这将确保一个系统的危害不会自动导致审计日志的危害。
  • 该框架还应允许捕获重要信息,并且最好不要将其留给程序员。重要信息将包括来自同步时间源的时间戳、负责请求的用户(或识别用户的任何信息)、请求的来源、请求的状态(无论是成功还是失败)、期间遇到的任何错误处理请求等。

【讨论】:

  • 啊,这就是我要找的术语——审计框架。谢谢!非常翔实的答案。
【解决方案2】:

在这里使用日志框架并不是一件坏事。记录到文件通常比记录到数据库更快。不过,使用 Log4j,您可以实现或使用现有的 JDBC appender,它将在记录时将所有数据插入数据库。为了可靠性,您可以为审计日志配置文件和数据库附加程序,以便在日志数据库失败时进行备份。

其他替代方案可能是围绕您的安全/业务逻辑的 AOP 方面,将数据直接插入日志记录数据库。

不过,我认为这类数据没有任何通用标准。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-04-10
    • 2012-10-06
    • 2023-03-25
    • 1970-01-01
    相关资源
    最近更新 更多