如何防止rogue server破坏数据中心

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

管理员需要防止未经授权的变更对虚拟化环境带来负面影响,及时找到rogue server并决定是否将其从现有环境中移除,避免其对当前环境造成破坏。

理想情况下,应用和服务器能够一直不间断正常运行,不会出现资源和冲突等问题,数据中心的所有一切保持着十分和谐的关系。不幸的是,我们并非生活在这样的理想环境当中。虽然针对虚拟化环境编写文档和制定控制流程能够起到帮助作用,但是尽了所有努力之后,我们依然可能遇到rogue server问题,并且这种问题会产生严重影响。而这种问题通常是管理员工作计划过于紧张的结果。如果没有事先制定清晰的变更流程,那么后期可能需要更多的人参与到其中才能够完成原有目标。

尽管某些操作的最终目的是合理的,但是本质上其仍然属于对系统进行未经授权的变更。仅仅一个未经授权的变更也许不足以摧毁整个虚拟化基础架构,但是如果大量变更累加在一起,就有可能对系统造成严重破坏 。对于那些拥有关键系统控制权的管理员来说,得知变更是在超越其知识或者权限的情况下进行的是一件非常令人沮丧的事情,但是需要记住的是,这种变更从来都不是出于恶意的。作为虚拟化管理员,能够暂时后退一步,不将个人感受带到工作当中是非常重要的;也许听起来有些像心灵鸡汤,但是清醒的头脑对于整个流程来说是至关重要的。

深入研究日志

如果想要修复未经授权变更所带来的影响,那么第一步就是调查并且掌握究竟发生了些什么。问题的根源有可能是一些非常小的事情,比如添加或者调整资源;也有可能是非常大的事情,比如创建新的虚拟机或者彻底更改配置。研究日志的目标在于定位系统变更,之后找出变更的目标、时间以及涉及的人员。如果不进行恰当的调查,那么管理员肯定无法反向推理出整个变更过程。同时作为IT人员,你的首要任务之一就是保证系统正常运行,因此不管怎样也不能拔掉电源插头。

完全弄清楚究竟发生了哪些改变可能是一件非常困难的事情,但是计算机系统最擅长完成的任务之一就是记录日志。有时候改变是显而易见的,但是大多数情况下,管理员必须深入挖掘日志,来找出系统究竟发生了哪些改变以及是何时进行的。如果公司很好地遵守相关流程,不使用通用账户来登陆关键系统和基础架构,那么管理员还能够在日志当中找出是谁执行了这些变更。任何变更都会留下管理员能够追踪的痕迹。在审查日志的过程当中,需要特别注意变更发生的日期和时间,将其和当前查看的日志相互关联,能够提供很大帮助。

移除还是保留?

当管理员了解发生了哪些改变、何时发生以及变更执行人之后,就可以计划一系列操作来修复这个问题。而在这一步,不同管理员可能使用不用的处理方式,因此情况可能会变得复杂。管理员可以选择保留或是移除rogue server,但是无论哪种方案都有缺点。尽管看起来移除服务器非常容易,但是实际上并非如此。假设下面这种情况:你的一位上司告诉你移除服务器。你按照正常的操作流程进行验证,之后移除了服务器。但是两个星期之后,你接到电话说一些重要资料仍然保存在服务器上,而你的上司马上就要使用这些东西。当然,现在所有东西都被删除了,你和你的部门都将陷入困境当中。如果服务器创建时没有遵循正常流程,那么管理员很有可能并不清楚这台服务器的真正用途,因此在移除任何东西之前,都需要关闭服务器,之后将信息存储到单独的SATA磁盘当中。我建议管理员在最初收到命令和真正移除服务器之间等待几个星期,只是以防万一,将其作为一个简单的保险策略。

移除一台rogue server好像不是特别容易,但是将其保留下来需要面对更多的挑战。即便服务器使用基础模板进行创建,管理员也必须进行健康检查。服务器是否已经配置了恰当的安全策略、备份以及监控?以及恰当的资源管理、命令规则和地址规划?所有这些都需要一项一项进行验证。当然,如果系统已经上线,那么管理员可能会遇到更多挑战,但是这些步骤需要被尽快完成。其他关键组件还有申请/批准表格。对于rogue server来说,负责创建这台服务器的管理员很有可能没有完成这些文档工作。为了解决这个问题,你需要让管理员填写恰当的批准/申请表,即便出现问题的服务器已经被移除了。如果出现和rogue server相关的安全问题或者事故,文档能够提供审计线索,未来可能会派上用场。事后完成文档工作对于基础架构滥用者来说也能够起到警示作用,让其认识到不能随便绕过规定。毕竟,这些规则的存在是有原因的——能够避免未来解决问题时遇到的种种麻烦。


本文作者:Brian Kirsch

来源:51CTO

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
SQL 云安全 开发框架