大型 IT 公司如何防止运维偷窥和篡改数据

问题：像 BAT 这类公司，以及各种银行，金融行业的 IT 运维，他们有着服务器的最高权限，那么这种行业如何对运维的操作权限进行审计和监管？

以下为知乎用户@张成的回答：

曾经在AppAnnie做过一段时间运维，分享一下AppAnnie的做法。

先说一些一些背景信息：AppAnnie有两个相关的团队，一个是运维，一个是安全。从线上操作来说，运维和安全的权限是一样的。研发团队大多数人都没有访问生产环境主机的权限，只有极个别Leader有权访问，但是每次访问都需要安全组授权，一般只有在处理紧急问题时才会允许。

接下来讲一些具体的措施或者操作方法。

1、每个人（运维&安全）都使用个人账号登陆服务器，不允许使用root登陆。线上的所有命令都会被记录到系统日志中，包括通过sudo执行的命令，SUDO_USER也会被记录下来，因此主机上执行的所有命令，都可以找到是谁在什么时间做的。

所有主机上安装了ossec，监控命令日志，对于所有可能的敏感操作（如sudo、rm、对某些路径的访问等等），都会立刻发邮件到安全组+运维组的列表里。因此，运维和安全组里的任何人执行的命令，都是时刻接受两个组所有人的监督的。除非你能找到漏洞绕过这个命令日志监控，否则很难偷偷的做一些事情。

2、数据库的主机有着更严格的安全策略。上面的防火墙设置了按会话流量切断连接的的规则，一个SSH会话的流量超过100K之后就会强制断开，因此，就算你想select *，然后手动从终端上复制数据出来，能得到的数据量都非常有限（更何况你执行的所有命令都有集体监督）。

3、研发人员有时候确实需要访问一些生产环境数据的，需要向安全组申请。安全组同意后，由运维组写脚本dump数据，这个脚本中会在dump数据时，将敏感信息隐藏掉（比如替换成无意义的随机字符），这个脚本给安全组审查同意后，再去生产环境执行。最后把dump出来的数据拷贝回来。（拷贝时，会在防火墙上开一个临时规则。）

总结的说，有这几点：

1、制度上最小权限原则。虽然你有root（sudo）权限，但你不允许执行未经许可的命令，而且除非必要，不允许查看敏感数据。比如前面讲的导出数据库中的数据时，运维其实也是看不到生产环境中的敏感数据的。

2、相互监督。我们当时运维+安全+CTO共6个人，6个人都会接收命令日志告警（但CTO没有生产环境的账号，他接收告警纯粹是监督）。如果要做坏事，除非这6个人都达成一致，一起干。如果真的到这个局面了，那基本上就是CEO被架空了，这帮人要携数据跑路了。

AppAnnie这样做的代价是，凡是与安全相关的流程都很冗长，一件事要拖很久。除了上述提到的事情，平时研发团队的代码里如果要用到加密，那么加密的算法、参数也都是要安全组审查的，没通过审查是不能上线的。代码里所有的数据库操作也都会有审查。

而当时的安全组其实就一个人（其他都是实习生，没有决定权，这个人曾经在某银行做安全），这个人经常在世界各地的多个办公室之间跑，因此常常一个审查要等上一周。但是公司层面愿意为了安全而妥协上线效率。

我觉得，企业文化中的安全意识非常重要。国内的绝大多数公司，并没有这样的安全意识，大家的安全仅仅是建立在对人的信任之上，这是很可怕的。而且，在安全和更高的运作效率上，国内大多数企业是倾向于后者的，大家嘴上都说安全很重要，但实际上在大家的内心中，安全与我有何干？又不算KPI的。