“删库跑路”重现江湖，技术和制度如何保障数据安全？
作者：互联网
摘要：近日，一则来自微盟官网的消息在业内引起轩然大波，“删库跑路”重现江湖……由此，关于如何从技术和制度两方面进行数据安全防范的关注和讨论广泛展开。
近日，一则来自微盟官网的消息在业内引起轩然大波，“删库跑路”重现江湖……由此，关于如何从技术和制度两方面进行数据安全防范的关注和讨论广泛展开。
事件的具体细节想必大家都知道了，我们仅在这里回顾一下时间节点：
- 2月23日18:56，运维员工（犯罪嫌疑人）通过 VPN 登入公司服务器并实施破坏。
- 2月23日19时，系统监控报告故障，生产环境及数据遭受严重破坏，随即微盟启动紧急响应机制。
- 2月24日，微盟向警方报案，犯罪嫌疑人现已被抓获。
- 2月25日7时，生产环境和数据修复有序进行，并预计到25日晚上24点前可完成生产环境修复，恢复对新用户的服务。
- 2月27日下午，微盟创始人孙涛勇回应删库事件：涉事员工深陷网络贷。
- 预计2月28日晚上24点才能完成老用户的数据修复。
“微盟删库”事件发生后的一天内，微盟集团蒸发的市值超过10亿港元！基于微盟的300万家商户生意基本停摆！长达53-125小时崩溃时间，已属非常严重事故！
一个个数字的背后，是中小商家的叫苦连天，是微盟公司的追悔莫及，是当事人贺某即将面临的严厉刑罚，更是其他企业和相关从业人员的警钟长鸣……
数据安全无小事
针对这次“微盟删库”事件，有业界专家表示，企业在进行数据管理的时候应该做到两点：一是实行备份机制；二是管理权限要分开。备份的工作必须从业务条线独立出来，把权责分开；同时，做到“最小化授权”，只有需要的权限才给。另外，企业还需要加强演练，做好应急预案，提升对生产环境的定位，并对员工做好安全教育和人文关怀。
这似乎是老生常谈了，而事实上，在灾难来临之前，多数人都会觉得自己是幸运者。数据安全，是时刻悬在企业和IT从业人员头顶的一把利剑，大意不得。
回看历史，类似这次事件而导致的业务停摆事故其实屡见不鲜，不论是人为破坏，还是技术Bug、设备故障，归根结底都是“人祸”，我们能做的必须是防患于未然，从技术和制度两方面齐抓，才能将“灾难”的发生概率降到最低（还不可能绝对避免）。
云和恩墨创始人盖国强先生曾在2017年和2018年分别就业内的两起数据安全事故分享过自己的观点，现在重新翻看，依然有很高的参考价值：
“对于运维来说，最重要的是提高自身的免疫力，获得高抗风险能力，从而在灾难中幸存下来。事关企业数据安危的情况，无论如何都不能疏忽大意。”那么如何避免陷入数据安危的困境？首先，要有完善、有效的备份和容灾机制；其次，要有完善的故障处理策略和流程；再次，要有端到端融会贯通的应急机制；最后，要有能够快速协同的团队资源。
这里，备份被放在了首位，因为它是最基本也是最重要的。盖老师曾总结的DBA四大守则，第一条便是“备份重于一切”。正所谓：硬件一坏，谁也没招；线路再稳，蓝翔报销；功夫再高，也怕菜刀。只有有效的备份才能让企业高枕无忧。但这就够了吗？当然不够。在盖老师曾总结的提升数据安全的“16条军规”中，严管权限、明确职责、网络隔离、防范内患、安全审计等都有提及，这都需要技术和制度相互协同来得以落实。
为此，笔者就技术和制度两个层面在保障数据安全的举措上做了一些归纳，希望能给读者带来些许提示。
最原始的方式便是传统备份与恢复。现在很多中小企业受限于技术能力和成本，还是通过逻辑或物理的方式进行备份，在必要的时候进行恢复。但这存在的很多问题，比如：数据量越大，RTO越长；备份时间点与问题发生点之间的时间间隔越大，RTO也很长。注意，备份的恢复速度是必须要充分考虑的，因为这直接影响着业务的连续性。低效备份在关键时刻会害死人，这不是危言耸听。此外，逻辑备份容易造成数据丢失，而备份介质损坏更是致命，这就是前面提到的“硬件一坏，谁也没招”。
提到备份，就不得不提容灾，就是采用逻辑或物理同步方式搭建容灾环境，通过数据同步到备库的方式进行数据的同步复制。这里存在一个问题是一旦主库数据进行删除，备库也会做相应的删除操作，没有真正起到保护数据安全的作用，是有漏洞的。那么，采用存储镜像的方式进行容灾呢？会存在镜像时间点和故障点之间的数据差异，导致一致性问题。
为了简化备份，持续性数据保护（Continuous Data Protection）出现了。CDP是对传统数据保护技术的一个重大突破。系统管理者无须关注数据的备份过程，而是仅仅当灾难发生后，简单地选择需要恢复到的数据备份时间点即可实现数据的快速恢复。连续性的问题不存在了，然而数据的不一致问题依旧没有得到有效解决。由于CDP开发者并不关心一个或多个I/O记录对应的事务行为，以及是否包含有效数据，所以逻辑一致性的检测往往被忽视了，其结果会导致数据库无法启动，或者启动后出现其他问题，例如：数据对象损坏、无法插入数据等。
为了解决一致性的问题，复制数据管理（Copy Data Management）技术可以说是CDP的进阶，重点在于对已经复制出来的数据的管理，结合日志处理技术，提高数据的实时性并解决了数据一致性的问题。CDP解决保护的持续性问题，CDM解决保护出来数据的管理问题；CDM的数据获取基于CDP方式来采集数据，也算是“数据管理”和“数据保护”的有机结合，既解决了数据持续保护的问题，也解决了容灾、开发测试快速使用数据的需求。数据保护+数据管理，既满足了用户保护数据的需求，也满足了用户对数据管理和敏捷使用的诉求。
云和恩墨的ZDBM产品就是采用CDM技术的数据库备份、容灾、复制数据管理平台。对于一致性还是连续性，相信每一个运维团队都会根据业务特性形成预先的准则，不同的业务系统在不同的阶段就会有不同的取舍。ZDBM做到了两者的平衡，满足了组织在数据安全保护和高效利用备份数据方面的迫切需求。
此外，另一款MyData产品，其备份恢复功能提供了基于XtraBackup的物理全量、增量备份，binlog日志备份以及使用mydumper逻辑备份的三种备份方式，可以根据不同的备份恢复需求进行灵活的搭配，提供了更多选择。
首先从预防的角度看，建立敏感数据操作的双人复核机制，关键应用业务的删库监控机制，以及基于权限审核的权限控制机制都是行之有效的举措。
从这次的“微盟删库”事件来说，本质上更多的就是制度问题。从防范难度级别以及安全透视级别来分析，运维外包人员（乙方），受监管范围最大，一般通过网络隔离就可以避免“人祸”的发生；接下来是开发人员，主要风险在于系统上线更新及其数据库操作权限管理上，这就需要前面提到的“最小化授权”。那么对于运维人员（甲方）呢？区别于外包人员的运维权限，甲方运维人员所掌握的权限范围更大，操作更加频繁，因此是人为因素导致事故的高发区。微盟的那位研发中心运维部核心运维人员贺某正是这个角色。最后，权限最高，防范难度最大的就是组织内的IT部门主管了。所以说，组织除了要在内部机制上加强管控，包括数据安全、研发技术安全等以外，为了避免百密一疏，还必须在文化上让员工对自身的道德底线有所认知，恪守信条，不可触碰法律红线。
其次便是应急策略。组织需要制定极端情况下的应急防范措施，并定期进行备份恢复演练。尽管没有谁敢真的在线上全盘执行"rm -fr /*"这样的操作，但依旧可以模拟各种可能的情况，以及不同情况的组合，再针对这些情况制定不同的预案，并在开发、测试环境试着进行演练。
总之，制度是“文”、技术是“武”，文武双全方能高枕无忧。从大部分企业的情况看，现在数据安全最薄弱的环节就是在管理安全上，这部分是高权限、高风险的所在，必须以技术+管理的方式相辅相成，依靠技术手段来杜绝管理制度的人为逾越，并通过技术来保障数据的可防守、可恢复。
防范攻击 加强管控
在盖老师的《数据安全警示录》一书中，提出了数据安全的五个纬度，可以基于这五个纬度来梳理企业的数据安全，并据此建立相应的安全防护措施。
在数据安全的范畴内，我们将安全划分为五大方面，分别是：软件安全、备份安全、访问安全、防护安全、管理安全。在企业数据安全中，这五大方面是相辅相成、互有交叉、共同存在的，下面是关于数据库安全的一张思维导图：
在这五大安全方向中，可能出现两种性质的安全问题。第一，由于内部管理不善而导致的数据安全问题；第二，由于外部恶意攻击入侵所带来的安全问题。通常我们把安全问题狭义化为后者，这实际上是片面的，在数据安全问题上，前者造成的数据损失、数据损毁，其发生概率和影响度都远远超过后者。
下面我们对数据安全的五大方面做一下简要的分析和探讨：
1.软件安全是指我们选择的数据库产品、版本是否稳定安全；厂商所能提供的补丁集和BUG修正是否及时、基础硬件与操作系统是否经过认证。很多用户在部署数据库软件时，仅仅选择了最容易获得的初始发布版本，遗漏了可能已经存在的补丁修正，并且在运行维护中并不能够及时跟踪软件更新，也无法获得BUG信息、补丁修正和安全告警，这就使得软件本身的很多风险隐患得不到修正。如果软件安全无法保证，数据库安全的基础也就丧失了。
2.备份安全是指用户数据能否得到及时有效的备份保全，能否在故障灾难之后获得及时的恢复和挽救。在数据库运行期，最为重要的就是备份安全，如果没有可靠的备份，将数据集中起来就只能是等待数据灾难，所以我们将备份安全提升到核心地位，备份以及随之衍生的容灾安全等，都是企业整体数据架构应该考虑的因素。很多企业在数据灾难之后因为缺乏有效备份而一蹶不振，根据Gartner 2007年的一份调查报告显示，在经历了数据完全丢失而导致系统停运的企业中，有2/5再也没能恢复运营，余下的企业也有1/3在两年内宣告破产。由此可见，由于备份安全问题导致的企业伤害可能远远大于黑客攻击。
3.访问安全是指用户数据库的访问来源和访问方式是否安全可控。通常数据库系统处于IT系统的核心，其安全架构涉及主机、系统、存储、网络等诸多方面，如果没有明确的访问控制，缺乏足够的访问分析与管理，那么数据库的安全将是混乱和无法控制的。在应用软件使用和访问数据库时，要正确设置权限，控制可靠的访问来源，保证数据库的访问安全，唯有保证访问安全才能够确保数据不被越权使用、不被误操作所损害，通常最基本的访问安全要实现程序控制、网络隔离、来源约束等。
4.安全防范是指通过主动的安全手段对数据库通讯、传输等进行增强、监控、防护、屏蔽或阻断，诸如数据加密、审计、数据防火墙等技术都在这一范畴之内。我们必须认识到，在IT技术高度发展的今天，风险是无处不在、层出不穷的，可能我们从未思考过的安全问题，每天都在不断涌现，所以在数据库环境中采取主动式防护，可以帮助我们监控分析和屏蔽很多未知风险，已经有很多成熟的产品和技术可以用于安全防范。
5.管理安全是指在企业数据的日常管理维护范畴内，能否充分保证数据安全以及服务的高可用连续提供。诸如DBA的维护、文件的管理、参数或数据结构的变更等等都可能引入数据风险，管理安全要求我们通过规范、制度以及技术手段去确保维护管理安全；另外，基于硬件、电力等基础平台的故障都可能影响数据库服务的高可用性，在管理中要通过监控手段及时预警，通过集群、备库等切换与服务分担保障服务的连续性。
针对这次“微盟删库”事件而引出的技术和制度如何保障数据安全的话题，笔者在此摘录了盖老师三年前的一篇文章中总结的提升数据库安全的“16条军规”供大家参考。也许事后回看，微盟乃至所有的数据灾难的避免，都可以从以下16条建议中找到答案：
1.备份重于一切：我曾经在总结的DBA四大守则的第一条就指出，『备份重于一切』，有了有效的备份，即使遭遇灾难，也可以从容应对，对于重要的生产环境，适当建立备库进行数据保护，查询分担，也会减少生产库的风险；唯一会让DBA们从梦中惊醒的就是：没有备份！所以对于数据库运维来说，第一重要的是做好备份！有备方能无患！
2.严格管控权限：过度授权即是为数据库埋下安全隐患，在进行用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。本次安全风险，如果用户只具备最低权限，如不具备DDL权限，那么也不会遭到风险。
3.明确用户职责：应当明确不同的数据库用户能够用于的工作范围，应当使用普通用户身份的，就绝对不应该使用DBA的用户身份，只有职权相称，才能够避免错误，降低风险。 即便是拥有管理员职责的用户，也应当遵循以不同身份执行不同任务的习惯，比如SYS和SYSTEM用户的使用就应当进行区分和界定。
4.密码策略强化：毫无疑问，数据库用户应当使用强化的密码规则，确保弱口令带来的安全风险，很多数据泄露问题来自弱口令攻击和提权。
5.限制登录工具：明确限制不同工具的使用场景，明确规定工具的准确来源，或者通过堡垒机等来限制数据库访问。对于工具也可以做出明确规则和限制，如限制仅能通过SQL Developer访问生产，PL/SQL Developer工具仅能访问测试环境，以减少安全风险甚至误操作风险。
6.禁止远程DDL：可以限制DDL操作仅能在数据库服务器本地进行，禁止远程连接执行DDL操作，这一手段在很多公司被严格执行，如果具备这一规则，此次的事故可以被直接屏蔽掉。
7.使用绑定变量：在开发过程中，严格使用绑定变量，绑定变量可以防范SQL注入攻击，减少数据库安全风险；这次安全事故，很多用户开始猜测是SQL注入，走了很多分析上的弯路。
8.监控监听日志：监听日志记录了数据库访问的来源、程序等信息，包括恶意扫描，密码尝试等，一定要重视监听日志的作用，并对其进行分析和监控，以清楚的汇制数据库访问图谱；云和恩墨一直帮助用户通过监听日志分析来揭示风险，白求恩平台（https://bethune.enmotech.com）为用户免费提供这一分析纬度的预警。
9.数据网络隔离：数据库的网络环境应该一直隐藏在最后端，避免将数据库置于直接的访问连接之下，由此可以减少数据库的访问风险。
10.测试和生产隔离：互通就意味着同时可以访问，也就可能带来很多意想不到的安全风险，企业应当将测试环境和生产环境部署于不可互通，或者不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。 分离部署一方面可以降低误操作的可能性，也可以屏蔽一些无关的访问可能，从而从网络链路上保证数据安全。
11.密码差异设置：有些测试环境或者非产品环境是利用产品环境恢复得到的，DBA在建立了测试环境后，就没有修改数据库用户的登录密码；经常性的，DBA也习惯在所有环境中设置通用的密码；这些习惯为系统带来了很多风险和不确定性。我们建议用户在不同环境中采用不同的密码设置，这是因为一方面产品环境和测试环境面对的访问用户不同，密码设置相同则意味着产品环境的安全性完全得不到保障；另一方面，DBA登录到不同的数据库需要使用不同的密码，这进一步减低了DBA在错误的环境下执行命令的可能性。
12.重要数据加密：很多重要的数据，需要加密存储，最典型的就是用户和密码信息，大量的泄密事件本质上是因为缺乏最基本的加密防范，对重要数据实施一定的安全防护加密，是应当予以适时考虑的安全方面之一。
13.适时的软件升级：这里的软件指数据库软件，尤其是当Oracle已经发布了安全补丁，已知的安全漏洞被黑客利用，则更可能对数据库产生致命的伤害。
14.防范内部风险：不可否认，绝大部分安全问题都来自于企业内部，来自最紧密、最轻易的接触和访问；企业的人员变动，岗位变更，都可能导致数据安全问题的出现，单纯依靠对管理员的信任不足以保障数据安全，必须通过规章、制度与规范的约束才能够规避安全风险。很多企业为了便利而舍弃规范、规章或者安全限制是得不偿失的做法。安全防范应当从内部做起，从限制约束自我做起，当最紧密相关的访问都遵从守则，那么系统的安全性就能够获得大幅度的提升。
15.树立安全意识：安全问题最大的敌人是侥幸，很多企业认为安全问题概率极低，不会落到自己的环境中，所以对于安全不做必要的投入，造成了安全疏忽。所以安全问题最大的敌人是我们自己，安全需要一点一滴的加强，逐步完善，云和恩墨一直帮助核心客户进行全面的安全评估，制定安全方案，守护数据安全。
16.开始安全审计：以Oracle数据库为例，数据库已经提供了很多安全防范的手段和方法，我们建议用户适当展开安全防范措施，开启部分任务审计，定期分析数据库风险，由此逐步完善数据库安全。
写在最后
在当今数据安全问题日益凸现的时代，对于安全的防范和防护已成为企业IT建设中的重要环节。云和恩墨数据安全解决方案从漏洞扫描、入侵检测、访问控制、查询审计等多方面保障组织的核心数据资产安全。自研软件ZDBM和MyData都能对数据库进行高效备份，与紧急救援、数据库恢复等服务相结合，可实现全方位的数据保护。重视数据安全，让“删库跑路”的悲剧不再上演。
最后的最后，祝所有运维兄弟们保持身心健康，也请各企业在当下的非常时期对自己的将士们给予更多关怀！愿类似事件不再发生，让技术和制度有效规避风险，保障企业健康、良性发展！
（部分图片来自网络）
想了解更多关于数据库、云技术的内容吗？
快来关注“数据和云"、"云和恩墨，"公众号及"云和恩墨"官方网站，我们期待大家一同学习与进步！
小程序”DBASK“在线问答，随时解惑，欢迎了解和关注！
Enmotech
发布了281 篇原创文章 · 获赞 381 · 访问量 35万+
私信
关注
标签：安全,数据库,删库,数据安全,微盟,数据,备份,重现 来源： https://blog.csdn.net/Enmotech/article/details/104552749