参会专家有：京东数科数据库团队负责人-高新刚、交通行业运维经理-Jan、广州维他奶技术总监-叶锡昌、安徽天元技术总监-徐传贵、DBA-秦世丽、DBA-蔡鹏.这两天，“郑大一附院系统瘫痪2小时，运维违规操作被判5年半”事件刷屏。根据目前公开的信息，北京中科科技有限公司的夏某某未经授权或许可，编写了“数据库性能观察程序”和锁表语句，并利用私下记录的账号密码，将程序私连到“郑州大学第一附属医院“HIS数据库”，导致表lock语句运行并锁定在“HIS数据库”，导致郑州大学第一附属医院三个院区所有门诊和临床计算机业务无法正常运行。受到恶意言论的攻击。1个门诊业务系统无法正常运行，所有门诊相关业务停滞近2小时，严重影响了医院的正常医疗工作。事件引发了持续的热议，其中不乏一些争议。高度关注的问题包括防止运维人员失控，如何平衡运维效率和安全，甲乙双方在事件中有哪些不足，企业如何开展并有效执行运维工作等，dbaplus社区将观点整理归纳如下，希望能为以后相关工作的开发处理提供参考：1.如何防止运维人员在生产环境进行测试和自己写程序连生产仓库等show??操作？权限控制+日常审计。对核心生产环境实行白名单机制，明确各终端和账户的连接和流程，对异常情况进行阻断或监控。除了授予权限外，给开发维护人员一个slave或dev环境。通过运维系统和堡垒机隔离运维人员和服务器。程序应纳入代码控制，严禁文件上传下载。2、运维人员为了工作方便，是否应该使用自己写在客户系统上的工具？它必须经过授权、测试和许可。据我所知，电力行业的一些法规要求软件和工具必须落地，甚至需要到电力科学研究院进行测试，取得证书后，才能部署试行。所以，如果甲方要求不是太严格，大家可以拿出自己的工具一起审核。没问题的话可以做，绝对不能私自运行。运维人员不应该有权利在客户的系统上运行自己的程序，所有的程序必须是公开的。包括各种脚本，需要codereview，实验没问题后才能上传。3、流程一旦复杂化，势必会影响运维效率。如何设置运维人员的工作流程和权限划分，兼顾效率和安全性？把你的生命交到别人手里。因此，甲方应精简日常工作流程，明确操作流程，对乙方的权限划分遵循最低限度的授权。这还是要看业务的重要性和核心生产环境的运行情况。在实施之前必须有一个确认和审查过程。这必须严格。其实有些方法在技术上可以杜绝一些高危操作，比如细粒度的权限分配和显式的高危操作，不同的账号做不同的事情，细化分工；阻断drop、rm-rf等高危操作。当涉及到核心问题时，质量可以超过效率。关于流程和标签或标准化的实施和运行，我长期以来只奉行一个观点：所有不能通过代码表达的流程、规范/标准都是扯淡。公司项目多了，人多了，不可能每个人都严格按照流程走。一个人一旦犯错，就会引发事故。因此，现在很多公司实施DevOps也不是没有道理的。如果过程比较复杂，尽量使用脚本操作，或者类似PythonAnsible的方式。4、从事??件中看出乙方有哪些不足？其实这件事本来可以很快定位解决的，但是却拖了这么久！从解决问题的运维人员的运行回顾来看，第一时间居然是通过plsql来看问题，这明显是个问题。我想象的处理场景应该是外包公司有靠谱的监控系统（通过员工审核过程可以看出监控系统应该还是存在的，但是为什么监控没有预警，也有问题这里），当发现异常时运维/DBA应该可以通过平台定位问题甚至解决问题。显然，乙方在平台化上有所欠缺。5、甲方对外包人员应实行怎样的权限管理？一是区分外包人员的管理范围，明确外包人员的岗位职责；第二，甲方管理核心权力。对外包人员要有适当的权限控制；三是用系统或运维平台代替外包人员人工操作。减少人与机器的直接接触。四是定期进行安全检查，根据安全要求修改密码；五是对外包人员进行能力考核，防止能力不足的运维人员接入核心系统。主要从三个方面考虑和控制。一是要明确规章制度和管理规范，明确外包人员的职责范围；一是主要在技术上实现；三是抓好稽核工作，定期稽查管控。我们这里的做法是，供应商不允许有VPN，所有操作都要经过堡垒机，后台录像。然后后面有一套安全的大数据平台，会分析他们的行为，有异常直接报警。一是不给外包的root管理员等过多权限；二是尽量不让外包人员登录生产环境；三是给开发者从机和测试环境。核心职能权限不能授予外包人员。要放权放域，做好安全培训，签订安全协议。6、甲方应制定什么样的应急预案？一是加强系统建设，通过运维管控系统实现自动化管理；二是加强系统管理，提高运维人员的安全意识和操作水平。陪审团，定期评估产品、性能和安全性。制定应急计划。从这起事件来看，技术性不是很强。系统卡死，查数据库，发现锁表，监控锁表的账号和语句，赶紧kill。如果要讨论这次事件的应急预案，建议从时间排查和溯源入手，即当系统中断的时候可以运行的时候，应该从网络、硬件、存储、客户端、数据库、应用等，从问题出发从故障处理方法、策略、日志、操作审计和溯源等方面进行应急预案，加强备份频率和备份验证同时。其实根据我的经验，数据库里有哪些账号，那些client应该有账号，在链接的时候建立白名单信息。安全架构到位，堡垒机、监控、代码审计、账号权限、密码修改策略等；服务器有许多HA解决方案。白天可以做限制表锁等危险操作，编写触发器等监控程序，禁止这一系列危险操作并发出警告，除非得到最高权限授权。备份和高可用方案一定要做好。7、如何开展和落实企业的保障工作？从某种程度上说，保障工作实际上是表面大于实际，这也是企业甲方不够重视造成的。做好保障并不难，难的是按照保障的要求和规范来开展和落实安全工作。保级评价机构带领企业走进安全之门，给予指导和标准，剩下的大部分时间要由企业自己消化、吸收、发展和实施。事实上，MLPS2.0非常具有实用性和指导性，值得企业结合自身情况进行研究。一是从规范化管理，到标准化，再到过程管理、事件管理、故障审查、ISO20000认证考核；二是定期邀请相关专业审计机构进行风险评估，查漏补缺。企业安全需要一定的密码字符复杂度和定期修改密码，以及SSL连接加密。8、运维人员应严格遵守哪些工作规程和安全意识？作为运维人员，一定要谨慎，在发送每条命令之前一定要考虑好可能出现的后果，没有把握的事情就不要去做。每一次代码更新都必须经过严格的CodeReview测试（尤其是在进行大规模操作时，即使只执行一次select，也必须反复确认）。最好有人在手术前与您仔细核实。你必须学会??通过这个过程来处理事情。事先与用户说清楚。9、运维真的像大多数人抱怨的那样是“高危”职业吗？该职业的就业标准和保障规定是否应该进一步优化？规范操作，规范流程制度，加大审计力度，加强应急演练。之后运维就安全了。其实并没有那么夸张。任何职业，只要超出法律的底线，都是高风险的。以后就没有运维了，就做SRE，搞什么运维？未来新世界不需要传统的运维。我个人很同情这个运维人员。确实可惜处罚太重了（想想携程事件）。建议有一定能力的技术人员尽量去互联网公司，无论是个人技术成长还是未来的发展空间，都要靠谱一些。运维确实是一个高危行业，而且经常上夜班。俗话说，卖白菜赚的钱，背着卖白粉的风险。我引用大多数网友总结的一句话作为结尾——不该看的不看，不该记住的不记，不该说的不说。以上观点衍生出更具体的问题，欢迎大家在评论区继续讨论或投稿：如何制定生产经营管理制度，明确权责，提高生产环境安全与责任意识？生产运营如何才能有效？授权、记录、跟踪和监控？未经充分测试的程序、未经充分确认的操作指令、未经充分讨论确认的方案如何严禁在生产中实施？如何管理帐户权限？工作职责是什么？管理？本文转载自微信公众号“DBAplus社区”，可通过以下二维码关注。转载本文请联系DBAplus社区公众号。
