在SQL Server中为安全依从性记录日志
对于你的业务来说什么是正确的?
“合理”这个词非常棘手，因为每个人对于什么应该被记录日志，以及以何种方式进行管理都有自己的定义。最终，合理的记录很可能会终结在法庭的定义中。虽然如此，你在这个时候能够做什么才能确保你是在安全的，并且不会被踢出局呢。第一件事情就是判断什么服务器和哪个数据库真的包含了那些需要被保护的敏感信息。这是你自己需要做的，或者是在最近的信息风险评估中已经作过的。记住，在开发或者测试中你需要有一些服务器存放敏感信息，因此，不需要任何级别的日志。
每个环境都是不同的，所有的业务都有不同程度的风险，但是至少考虑如下日志:
·SQL Server日志——默认情况下是激活的，通过企业管理器C2 审计模式可以访问——通过sp_configure存储过程(将c2审计模式设置为1)跟踪权限、访问数据库对象，以及更多内容。
·对失败的认证尝试记录日志——通过企业管理器/属性/安全标签
·IIS日志——通过IIS服务管理器
·一般的Windows审计日志——通过Windows本地策略或者GPO
当深入谈论审计日志和系统监控的时候，你自己要很努力，并且投资购买一个第三方的日志以及事件管理应用程序，例如GFI的 EventsManager，或者用于普通SQL Server日志审计的ApexSQL Log。访问LogAnalysis.org，了解其他一些商用产品。这些工具都会为你节省大量时间和努力。我也推荐使用NIST的Guide，用于计算机安全日志管理(Computer Security Log Management)。
小心进行
任何激活了日志的管理员都知道，它可以对系统性能和存储需求产生非常大的影响。我听到过法律专家、缺少经验的管理员，还有其他一些人都不理解日志的负面影响。我也听到过很糟糕的推荐，包括“怀疑得越多越好”，“对所有事情都记录日志”,还有“永远保存你的日志”。一些数据库安全审计工具甚至推荐使用各种各样的SQL Server日志特性，例如C2 审计模式来追踪错误应用。所有这些在纸面上听起来都很不错，它可以取悦规律制定者、审计员，还有投资方，但是它的花费呢?
盲目跟随供应商们、审计员们这些理想化的推荐，以及没有基于你的业务风险作出的计划所产生的问题，就是你会创建一个日志真的会对你的业务产生负面影响的环境。无论它是否会吃掉内存，需要太多的处理器时间偏，或者也许最糟糕的是，以更快的速度用光你的几个PB的存储空间。我曾见过Windows和SQL Server 日志引起了本地系统分区在几分钟内被填满，还让SQL Server一块停止响应。对于你网络中的所有服务器，你也许最不想挂掉或者重起你的SQL Server。以商业的角度来说，在安全上的考虑多得过分了!除了技术问题之外，另外一个需要注意的问题就是，对所有的事情记录日志，并且无限期的保留日志也会导致法律责任，和巨额的发现费用。我还需要再说明一下从太多的日志中找出有用信息的管理负担和一般人的无能为力吗?
不要对隐私和安全法律、法规过分担忧。他们当然不会深入研究日志。无论以何种方式，都不要试图分别管理审计记录和监控每个法律/法规的需求。相反，进行一次风险评估，把你的依从性动机结合到一个信息安全框架或者标准中，例如ISO/IEC 17799, CoBIT, 或者 ITIL。如果IT和依从性都以这种程度管理，并且以正确的方式完成的话，你的企业就可以在很大范围内满足所有的依从性需求，不需要为HIPAA，SOX，PCI等等记录日志了。
无论你做了什么，不要孤立起来。你不想要承担与审计日志有关的关键业务决策的负担。当发生事情的时候，规则制定者、审计员、或者争议调查员把你按住，想要让你对于你所做(或者没做的)的日志说出理由和进行业务辩护的时候，这一点尤其明显。如果你和你的IT职员正在承担大部分的依从性负担(在大多数企业中都是如此)，在你的企业法律顾问或者依从性经理的帮助下执行你的日志决定吧。理想情况下，判断要记录什么和如何管理日志都是由依从性或者IT管理委员会进行委托管理和支持的。我想要说的是，让其他人也卷进来吧。你不会后悔的。