中年|思科前员工为报复恶意删除400多台虚拟机,公司损失超1600万


作者 |褚杏娟
一位前思科员工于本周三在圣何塞联邦法院认罪 , 称其曾非法访问思科公司的 Amazon Web Services 基础设施 , 并对其云计算资源施以破坏 。
事件回顾
Sudhish Kasaba Ramesh 于 2016 年 7 月入职思科 , 2018 年 4 月离职 。 Ramesh 在与检察官议定的认罪书中坦言 , 离职之后 , “他曾使用个人 Google Cloud Project 账户部署代码 , 删除掉了 456 台虚拟机 。 这部分虚拟机主要用于交付视频会议、视频消息收发、文件共享以及其他协作工具服务 。 ”
Ramesh 承认自己“鲁莽地”部署了恶意代码 , 而且“明确意识到自己的行为可能给思科业务带来巨大风险 。 ”
根据检察官的说明 , Ramesh 的行为导致超过 16000 个 WebEx Teams 账户被异常关闭 , 持续时间达两个星期 。 为此 , 思科方面共计损失 240 万美元(约合 1650 万人民币) , 其中包括对问题进行修复所支付的约 140 万美元人力成本和超过 100 万美元的客户退款损失 。
对此 , 思科方面表示 , 值得庆幸的是此次事件并未导致客户信息丢失或泄露 。
思科公司发言人在一份邮件声明中表示 , “思科已经于 2018 年 9 月快速解决了此次问题 , 保证不存在任何客户信息丢失或泄露的状况 , 并及时引入了其他保护措施 。 ”同时 , 思科表示:“我们将这个问题提交给了执法部门 , 并在能力配合之下成功将其绳之以法 。 我们相信整改之后的机制足以防止此类事件的再次发生 。 ”
由于认罪协议的更多细节尚未公开 , Ramesh 此举的动机还不明确 。 但更令人意外的是 , Ramesh 的现任雇主、个性化时装公司 Stitch Fix 似乎一副无所谓的态度 , 甚至希望他能继续正常上班 。
根据法院文件 , Ramesh 在美国持有 H-1B 签证 , 而且正在申请绿卡 。 法院文件提到 , “尽管他和他的雇主了解目前的认罪结果有可能影响其正常移民 , 甚至导致其被驱逐出境 , 但雇主方……仍然愿意为他保留工作岗位 , 考虑其继续留在美国并为公司效力的可能性 。 ”
据悉 , 30 岁的 Ramesh 或将面临五年有期徒刑与 25 万美元的罚款 。 目前 , Ramesh 已被保释 , 保释金为 5 万美元 , 其宣判会将于 2020 年 12 月 9 日举行 。

中年|思科前员工为报复恶意删除400多台虚拟机,公司损失超1600万
本文插图
【中年|思科前员工为报复恶意删除400多台虚拟机,公司损失超1600万】
法院文件说明
员工“报复”事件频发
思科遭员工“删虚拟机跑路”并不新鲜 , 此前微盟遭员工“删库跑路”事件更是轰动一时 。
今年 2 月 , 微盟研发中心核心运维人员贺某通过个人 VPN 登入公司内网跳板机对微盟线上生产环境及数据进行了严重的恶意破坏 , 导致微盟的 SaaS 业务服务突然宕机 , 商家后台的所有数据被清零 。
该事件发生后 , 微盟股价大跌 , 累计市值一度蒸发超 30 亿港元 。 300 万左右商家的数据在腾讯云协助下 , 经过七天七夜的努力才被全面找回 。 3 月初 , 微盟表示将拿出 1.5 亿元进行损失赔付 , 其中公司承担 1 亿元 , 管理层承担 5000 万元 。
虽然舆论已经平息 , 但后续赔偿事宜还在进行中 。 由于赔偿金额等问题 , 微盟遭到了大量商家的集体投诉 , 这些投诉已被立案审理 。 据微盟集团发布的 2020 年上半年财报显示 , 由该赔付计划带来的预计赔付支出对微盟带来的损益影响达 0.87 亿元 。
根据微盟发布的通告 , 贺某是由于个人精神、生活等原因发起了破坏行为 。 随后 , 微盟创始人孙涛勇在接受媒体采访时解释到 , 该员工一直深陷网络贷 , 还曾有过轻生的举动 。 春节期间一个人在房间独处 30 多天 , 再加上本身经济上的困扰 , 最终做出了这样的举动 , 事后他也表示跟公司无任何仇恨 。分页标题

中年|思科前员工为报复恶意删除400多台虚拟机,公司损失超1600万
本文插图
很多程序员表示:“删库跑路就是说说而已 , 跑得了和尚跑不了庙 。 ”但为什么还是有人甘愿冒着坐牢的风险破坏公司系统 , 是每个管理人员应该深思的事情 。
当然 , 除了少数的有意为之 , 还有很多“删库”其实是程序员的无心之失 。
据媒体公开报道 , 在 2018 年 , 顺丰一位工程师在升级系统数据库的时候 , 不慎将 RUSS 数据库删除 , 导致很长一段时间顺丰线上发车功能无法使用 , 带来了严重的负面影响 。 最后该员工被辞退 。
还有位自称阿里员工的知乎网友表示 , 自己刚入职的时候 , 数据库可以直接用 bash 执行后台增删改操作 , 各种监管和操作日志机制都不是很完善 。 有一天 , 在使用存储过程进行 update 极度重要的表的时候 , 忘了加 where 条件 , 就直接敲了回车执行 , 所以和删库也差不了多少 。
当时出现失误的第一反应是吓傻了 , 不敢告诉主管 。 “知道没有备份的消息后 , 我是想跑路来着的...”该网友表示 , 后来才意识到 update 是一个事务 , 中途 Kill 掉进程 , 就不可能出现一半更新一半不更新的情况 。 年少无知 , 白白挨了一通批评 。
如何预防
“rm -rf /* , 执行了这个命令就是走上人生巅峰了 。 ”这也不过是一句玩笑话而已 。 对于程序员个体来说 , 一般情况下没人会故意搞破坏 , 而为避免无心之失 , 平时只能处处小心 。
但前有微盟后有思科 , 大企业不断遭遇“删库”事故 , 侧面也说明了企业在数据安全管理上存在一些问题 。 对此 , 有专家从事前预防、事中发现和事后容灾三方面给出了相关建议 。
首先 , 事前预防很重要 。 企业需要统一运维入口 , 实现账号和权限的分配和管理 , 并且要每人独立账号和权限 , 细化至每个人能做什么不能做什么 。 不要为了图省事共用一个权限 , 而且要定期梳理和回收 。 也要对员工进行典型误操作和恶意操作案例的宣传 , 让他们知道后果 , 形成敬畏之心 , 同时在统一运维平台上把已知的高危操作都拦截掉 , 譬如 rm –rf 等 。
其次 , 企业可以通过配置审计规则 , 对一些会变更系统的操作进行告警 , 同时要对系统进行完整性等健康监控 。
最后 , 最重要的就是备份 。 数据是核心 , 有数据才能在灾难后恢复系统 。 备份一定要全量备份、增量备份、异地备份等 , 最好多个机房备份 。
当然 , 数据管理只是一部分 , 真正“删库跑路”的发生归根到底是公司和员工之间矛盾不可调和的爆发 , 结局往往是两败俱伤 。
https://www.zhihu.com/question/375447541
今日荐文
填写申请 , 成为作者
开启你的创作之路吧~
声明:转载此文是出于传递更多信息之目的 。 若有来源标注错误或侵犯了您的合法权益 , 请作者持权属证明与本网联系 , 我们将及时更正、删除 , 谢谢 。邮箱地址:newmedia@xxcb.cn