反思微盟删库事件：如何保障 SaaS 服务的安全？
编者按：本文来自微信公众号“毛苇频道”（ID:maoweichannel），作者：毛苇，36氪经授权发布。原题目《如何保障 SaaS 服务的安全？》
微盟删库事件发生36小时后，微盟集团对外发布公告，公告声称“我们对此次因人为造成的事故灾难无比愧疚，我们今后将一定吸取这个惨痛的教训，加强对线上运维的治理，同时我们也对因远程办公而疏忽对员工的精神状态的关注而深表痛惜！”
微盟将此次事件定性为“人为造成的事故灾难”，并归因于“因远程办公而疏忽对员工的精神状态的关注”。
作为个人，我对微盟的遭遇感到同情，但作为 SaaS 从业者，我们更应该反省这件事。人为因素确实是原因，但像删库这种事是极其罕见的，如果我们只停留在“人为因素”、“精神状态”的层面，有点表面化，不利于行业。
作为行业人士，我们很难对这样的灾难视而不见。每一次灾难都有背后的原因，每一次灾难之后都必须找到解决方案，把风险扼杀在摇篮里，才能让SaaS服务避免这类悲剧的再次发生。
所幸的是，很多SaaS服务商在这方面都积累了足够多的经验，通过系统架构、管理权限、操作流程等方面的控制，SaaS服务可以尽量杜绝人为因素的影响。
架构备份
SaaS 的技术架构是比较成熟的，数据库有主库、从库。主库用于生产环境的业务支撑；从库一般用于查询或主从切换。
备份数据有增量备份和全量备份，备份策略也包括跨机房、跨区域等。
数据备份是生产环境安全的防护，如果技术架构不支持备份，那 CTO 可以下课了。
分权管理
这里谈分权，而不是分级管理，是针对大多数中小供应商，而不是大规模服务商。大体量的服务商分级的权限管理，是安全级别很高的；也是普遍的做法。
分权首先要做数据库操作权限和备份权限分开。DBA负责日常主数据的管理和维护；运维负责备份，且采用全量和增量备份的方式，进行多重数据备份。
这样即便是DBA有删除主库的风险，主从同步，收到业务报警运维能马上接管数据库服务，快速备份恢复；不至于对业务造成影响。
流程管理
关闭DBA操作数据库终端的权限；执行高风险操作直接拒绝执行，并发出报警；报警要 CTO 和对应的技术主管都能接收到。确实业务需要进行数据或数据表调整，增加审批流程，需要申请才能进行操作。
DBA或开发要做数据库的表删除、修改等操作，流程定义上要做申请；控制DBA的操作权限。技术主管或者核心创始合伙人审批，并生成操作密钥。开发或 DBA通过生成的密钥才能进一步操作。
流程上的控制客观上实现了即便是某个个人有作案嫌疑，也无法群体作案的可能。从制度层面实现安全控制。
安全屋和操作监督
对于那些特别敏感、需要高级别权限的操作，可以设置“安全屋”，必须进入专门的机房、通过专门的设备才能登录操作。即使操作，也要提前申请。即使申请通过了，也要有专人监督。如果出了问题，监督员要付连带责任。
对于SaaS服务商来说，如果做到了上述四点，所谓的“人为因素”就可以基本杜绝，也不会因为“员工精神状态”而导致灾难性事故的发生。再退一万步，即使发生了灾难，也可以在很短的时间内修复。
无论做任何事情，风险、灾难都伴随我们左右，SaaS服务也一样，SaaS服务并不比银行业、航空业有更高的风险。
很多的人为因素，背后都是管理的问题。只要我们建立系统化的防御体系，我们是可以将灾难隐患扼杀在摇篮中的。
SaaS 服务发展20多年，到今天成为事实上的全球标准，并涌现出了像Salesforce、Office 365、Adobe等等世界级的SaaS服务，事实证明绝大部分 SaaS 服务都是安全的、可靠的。
相关推荐
反思微盟删库事件：如何保障 SaaS 服务的安全？
微盟筹集1.5亿元赔付商家，删库事件致市值蒸发超30亿港元
删库后这 10 天里，微盟的卑微与傲慢
微盟大跌，“钱路”存否
对话商汤田丰：SaaS平台与云厂商，谁该为数据安全买单？
数据泄露事件频发，“数据安全”创业机会何在？
最前线 | 微盟后台遭员工恶意破坏，宕机36小时，客户数据丢失
“乘风破浪”的中国SaaS ：风浪越大，机会越大？
微盟撤资、经营不善，死在风口上的酒店SaaS服务商“向蜜鸟”
千亿交易额的「微票宝」，不仅做票据交易，也封装SaaS产品
网址: 反思微盟删库事件：如何保障 SaaS 服务的安全？ http://m.xishuta.com/zhidaoview7235.html
