一次沟通不佳造成的深刻教训

Posted 2020-06-25

  原因：

   公司由于正在发展期，服务器上线业务上线，因为我是安全运维，从安全考虑我把线上mysql数据库的权限收回，因为以前权限太大。

   

   删除掉root，还有一个账号的所有权限%，我们都知道%代表任意地址登录，如果被黑，可以得到数据库密码然后破解服务器密码然后可以任意乱搞，为了安全着想，所以我设置了iptables和ssh权限。

/etc/hosts.allow

sshd:*.*.*.*:allow                             //只允许公司ip SSH登录

 

/etc/hosts.deny

sshd ：ALL                                               //拒绝所有SSH登录

然后通过vpn连接公司内网在跳转到内部服务器 然后在ssh外网服务器

 Connecting to 192.168.1.21:22...
Connection established.
To escape to local shell, press ‘Ctrl+Alt+]‘.

Last login: Tue Mar 15 09:27:02 2016 from 192.168.1.158
[[email protected] ~]# ssh 外网服务器
[email protected]外网服务器‘s password: 
Last login: Thu Mar 17 16:52:38 2016 from 公司地址

   这样本来是没问题的，但是研发开发的mysql存储过程是w这个用户，然后用的是%这个任意地址访问。

而且权限是all，这样就报错了。并且我处理mysql权限的时候没有及时跟研发沟通，尚自做主删除了%的权限。

   然后半夜 客户提现的时候，都报错所有人多提现了。

处理方式：

首先我调整了系统时间，让所有用户无法提现

date -s 03/17/2016

date -s 23:30:00

然后创建用户w用户all权限，先让其正常使用

因为做了计划任务自动备份mysql

 2016-03-17_23-40-01 

然后做过主从，对比备份数据和线上数据

然后还原数据

然后调回系统时间

ntpdate time.nist.gov

刷新redis缓存

flushall

教训：

   擅做主张：因为运维部门就我一个人，上面是研发部经理，没有及时跟研发部经理沟通删除权限用户造成事故。

   没有及时沟通：如果删除前，在讨论组里跟研发部门开发存储过程的同事沟通，及时更改存储过程用户，删除后就不会造成这个影响。

   经过这次事故后，以后做任务操作要跟领导说下，然后跟研发部沟通下，尽管如果没有他们的事，也可以沟通做了什么操作及时记录，还好及时补救，做了数据库备份，主从等操作。还原回去，现在数据正常。但是这个锅我还是要背的。毕竟是我自己的错，有错就认，及时更改。以后不犯。

本文出自 “浩子的▁运维笔录ヽ” 博客，请务必保留此出处http://chenhao6.blog.51cto.com/6228054/1752465