微软系统中任何关于如何限制或控制管理员权限的讨论通常都会得到这样的结果：你怎样才能不把管理权限送给那些你不信任的人?这有一定道理，但是在没有证据表明管理员做错了事情的情况下，如何才能正确判断一个管理员是否值得信任呢?再者，你如何证明你的判断呢?
成都创新互联是一家集网站建设,银州企业网站建设,银州品牌网站建设,网站定制,银州网站建设报价,网络营销,网络优化,银州网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
你不能剥夺一个域管理员太多权限，尤其是在每个域都要管理的多网域环境下，所以说有时候限制管理员的权利和授权活动这项工作很难实现。辅助人员和供给人员通常也需要具有管理权利，而且有时政治需求还会需要更多的管理人员。所以，真正的问题是，你如何去审计一个管理员?
虽然答案是只要启用审计就行了，但是只是简单地启用审计功能并不能解决所有的问题。举例来说，我最近与许多管理员一起进行了一项大型的活动目录部署活动。他们有一个应用程序，使用特定的用户对象属性提供对该应用程序的连接。站在安全相关立场，他们发现管理员可以禁用审计功能，修改一些关键的属性，并且可以对该应用程序做坏事。然后该管理员可以重新启用审计功能而不会被觉察---甚至WindowsServer2008R2的属性审计功能也是如此。启用审计功能的时候，系统可以记录足够的事件，从中可以看出谁改变了对象，以及谁改变了属性。但是由于审计功能被禁用，所有这方面的证据都消失了。
安全审计系统的主要功能如下：
对网络或指定系统的使用状态进行跟踪记录和综合梳理的工具， 主要分为用户自主保护 、 系统审计 保护两种 。 网络安全审计 能够对网络进行动态 实时监控 ，可通过寻找入侵和违规行为，记录网络上发生的一切，为用户提供取证手段。
IT治理、内控和风险管理的发展极大地促进了安全审计市场的发展。以美国为例，在SOX法案颁布之前，安全审计市场根本没有纳入Gartner、IDC的专项分析范畴，随着针对上市公司内控和信息披露的SOX法案的实施。
以及象专门针对医疗行业的旨在保护医患隐私的HIPAA法案、针对联邦政府机构的FISMA法案、针对金融机构支付卡行业的PCI-DSS规范等的执行，美国的安全审计市场出现了爆炸式的增长。
Gartner和IDC纷纷对其进行深入分析，并创造出了一个名为GRC（Governance, Risk Management, and Compliance）的IT细分市场。与此同时，各路安全厂商都从自身技术特点出发，提出了各种类型的安全审计产品，介入该市场，力求分一杯羹。例如，国内的有LeagSoft 厂家，国外有SIEM厂家、NBA厂家等。
mysql服务器自身没有提供审计功能,但是我们可以使用init-connect + binlog的方法进行mysql的操作审计。由于mysql binlog记录了所有对数据库长生实际修改的sql语句，及其执行时间，和connection_id但是却没有记录connection_id对应的详细用户信息。在后期审计进行行为追踪时，根据binlog记录的行为及对应的connection-id 结合 之前连接日志记录 进行分析，得出最后的结论。
1. 设置init-connect
1.1 创建用于存放连接日志的数据库和表
create database accesslog;
CREATE TABLE accesslog.accesslog (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))
1.2 创建用户权限
可用现成的root用户用于信息的读取
grant select on accesslog.* to root;
如果存在具有to *.* 权限的用户需要进行限制。
这里还需要注意用户必须对accesslog表具有insert权限
grant select on accesslog.* to user@’%’;
1.3 设置init-connect
在[mysqld]下添加以下设置：
init-connect=’insertinto accesslog.accesslog(id, time, localname, matchname)
values(connection_id(),now(),user(),current_user());’
------注意user()和current_user()的区别
log-bin=xxx
这里必须开启binlog
1.4 重启数据库生效
shell /etc/init.d/mysql restart
2. 记录追踪
2.1 thread_id确认
可以用以下语句定位语句执行人
Tencent:~ # mysqlbinlog --start-datetime='2011-01-26 16:00:00'
--stop-datetime='2011-01-26 17:00:00' /var/lib/mysql/mysql-bin.000010
| grep -B 5 'wsj'
COMMIT/*!*/;
# at 767
#110126 16:16:43 server id 1 end_log_pos 872 Query thread_id=19 exec_time=0 error_code=0
use test/*!*/;
SET TIMESTAMP=1296029803/*!*/;
create table wsj(id int unsigned not null)
--
BEGIN
/*!*/;
# at 940
#110126 16:16:57 server id 1 end_log_pos 1033 Query thread_id=19 exec_time=0 error_code=0
SET TIMESTAMP=1296029817/*!*/;
insert into wsj(id) values (1)
--
BEGIN
/*!*/;
# at 1128
#110126 16:16:58 server id 1 end_log_pos 1221 Query thread_id=19 exec_time=0 error_code=0
SET TIMESTAMP=1296029818/*!*/;
insert into wsj(id) values (2)
2.2 用户确认
thread_id 确认以后，找到元凶就只是一条sql语句的问题了。
mysql select * from accesslog where id=19;
+----+---------------------+---------------------+-----------+
| id | time | localname | matchname |
+----+---------------------+---------------------+-----------+
| 19 | 2011-01-26 16:15:54 | test@10.163.164.216 | test@% |
+----+---------------------+---------------------+-----------+
1 row in set (0.00 sec)