我的客户端已经使用Microsoft Access 2010很长一段时间了，他们收到了一些安全审核要求。他们正在使用链接表方法连接到Microsoft SQL Server 2012 Express。
要求声明必须记录针对数据的所有操作。 （INSERT，UPDATE，DELETE和SELECT语句）
对于INSERT，UPDATE，DELETE语句，我可以创建一个记录更改的触发器。
问题在于SELECT语句的审计。如果数据是只读的，我本可以使用存储过程来记录查询。但是执行Stored Proc会使Recordset无法更新。
有没有人知道如何应对这一挑战？
我对很多策略持开放态度......（通过Web服务连接SQL，任何东西......）
值得注意的是，我的客户在SQL Sever企业版上的花费不会超过3万美元，因为他们是一家员工少于10人的小型企业。
答案 0 :(得分：1)
SELECT语句是database-level audit action groups in SQL Server的一部分。 （在该页面中搜索“数据库级审计操作”。）但该级别的审计需要SQL Server Enterprise版本。
从理论上讲，无论数据是否为只读，您都可以限制所有访问权限仅使用存储过程。编写存储过程首先将审计信息写入日志，然后执行其他任何需要完成的操作 - SELECT，INSERT等。
实际上，可能无法做到这一点。这取决于命中数据库的应用程序。限制所有仅使用存储过程的访问权限可能会破坏期望其他事物的应用程序。 （如果切换到只是存储过程，Ruby on Rails应用程序将如何响应？）
使您的数据库无法使用的防弹审核系统不是很好;完全关闭数据库服务器更简单，更便宜。
答案 1 :(得分：0)
您可以升级到支持SQL Server探查器的SQL Server版本。 另一个选择是让其他工具像sql audit一样进行审计。
答案 2 :(得分：0)
你可以打开JET showplan。这将记录Access使用的所有查询。
正如我在评论中指出的那样，你实际上是在欺骗审计要求，除非使用where子句打开每个表单，该子句限制将该表单中的数据查看到ONE记录。如果你不这样做，那么打开到链接表的表单可以有1000个记录，而用户点击ctrl -f查找并跳转到一个记录意味着SELECT语句告诉你ZERO实际上是什么用户看着。因此，虽然您可以启用展示计划，但除非进行应用程序设计更改以将表单限制为一个记录，否则审计概念不会告诉您有关用户实际查看的内容的任何信息。公平地说，99％的应用程序实际上是通过where子句打开并限制主编辑表单到一条记录。
因此，虽然您可以按照上面的技术明智地记录所有SELECT命令，但实际上并不是这样的日志，因为这样的日志对于确定用户看到的实际记录没有任何用处。