☰

Server 2012 上的文件访问审计

tag-icon • tag-icon windows-event-log audit
Server 2012 上的文件访问审计

我正在对 IIS 服务器上的目录实施文件审核，以便当有人试图修改或删除任何文档时收到通知。

我设置Advanced Auditing Policy\Audit Policies\Object Access:File System为审核成功和失败。

根据我读过的所有文档，下一个阶段是在我需要监控的任何文件/目录上设置 SACL。

但是，在设置 SACL 之前检查安全事件日志会显示许多事件 ID 4656（请求了对象的句柄）。阅读这些事件表明它们是为了访问各种系统文件而引发的。

我访问了特性这些文件/目录的对话框，然后单击安全标签。接下来我点击先进的按钮并选择审计选项卡。在那里我看到已为用户设置了审计Everyone以记录所有写入操作。

接下来我运行了一个 powershell 脚本：

Get-ChildItem -Path "C:\" -Recurse | ForEach-Object {
    $file = $_.FullName
    $(Get-Acl -Audit $file).GetAuditRules($true,$false, [System.Security.Principal.SecurityIdentifier]) | ForEach-Object { Write-Output $file }
}

列出所有启用了审核的文件/目录。结果发现，在这个 IIS 框中，我有超过 32,000 个启用了审核的文件。

考虑到我过去可能以某种方式启用了这些功能，我接下来针对域控制器运行了相同的脚本，并计算出了类似的数字。 这两个都在测试环境中，因此我接下来针对另一台生产 IIS 服务器（我没有构建）运行了脚本，并得到了类似的结果。

因此，我的问题是：

这是正常的吗？是否有超过 32K 个文件安装了审核 SACL，但该策略最初被禁用？启用该策略会导致事件日志充满无用事件 - 在测试 IIS 服务器上，我注意到一小时内大约有 100 个事件。

虽然我可以轻松修改上述脚本以删除这些 SACL，然后仅添加我需要的 SACL，但这样做安全吗？

甚至更加普遍——我是否遗漏了一些显而易见的东西？

相关内容