读数据保护：工作负载的可恢复性01数据所面临的风险
1. 3-2-1原则
1.1. 每份数据做三个副本
1.2. 放到两种介质上
1.3. 其中一份放在远处
1.4. 3-2-1原则是所有备份工作的基础原则
2. 数据保护即服务
2.1. Data-Protection-as-a-Service,DPaaS
2.2. 信息安全是一个跟数据保护完全不同的学科
3. 软件即服务
3.1. Software as a Service
3.2. SaaS
4. 为什么要把这么多钱投到备份与灾难恢复上？
4.1. 数据备份是一件很重要的事
- 4.1.1. 假如不做备份，那么将无法恢复数据
4.2. 备份本身并不是重点，重点在于必须有备份，才能够从中恢复数据
-
4.2.1. 没人关心你能不能备份
-
4.2.2. 只关心你能不能从备份中恢复数据
4.3. 不做备份的人，不太可能在数据保护工作方面成功
4.4. 备份、恢复以及DR变得比原来更为重要，而且更复杂
4.5. 在设计数据保护系统之前，必须先把相关的需求收集到位
4.6. 人为错误
4.7. 机械故障或系统故障
4.8. 自然灾害
5. 人为错误
5.1. 在大多数情况下，之所以要做数据恢复与灾备，就是因为有人犯了错误，让计算环境遭到破坏，这种错误可能是无心的，也可能是故意的
-
5.1.1. 人难免犯错
-
5.1.2. 有时可能并没有恶意，但却把数据给删除或破坏掉了，这就是我们要做备份的另一项原因
5.2. 操作失误
-
5.2.1. 人总是会失误
-
5.2.1.1. 可能会把错误的文件复制到错误的地方
-
5.2.1.2. 拿一份没用的文件把一份有用的文件覆盖掉
-
-
5.2.2. user error
-
5.2.2.1. 用户错误或用户操作失误
-
5.2.2.2. IT部门中的系统管理员、网络管理员与数据管理员，同样容易出这种错误
5.2.2.2.1. 拿到管理员权限相当于拥有一把利剑，如果砍错了方向，可能会造成严重的后果
5.2.2.2.2. 之所以要备份数据，一个很重要的原因就在于应对管理员的失误
-
-
5.2.3. PEBKAC
-
5.2.3.1. Problem Exists Between Keyboard And Chair
5.2.3.1.1. 问题出在键盘和椅子之间
-
-
5.2.4. 把数据里面不该删的数据表给删了
-
5.2.5. 把不该格式化的盘（即一个本来毫无问题的盘）给格式化了
-
5.2.6. 把开发用的数据库恢复到了生产用的数据库（即给实际产品用的数据库）上
-
5.2.7. 本来想写个脚本把那些用不到的home目录给删掉，结果这个脚本把每一位用户的home目录全都删掉了
-
5.2.8. 把不该删的虚拟机(Virtual Machine, VM)给删了
5.3. 代码错误
-
5.3.1. 代码错误到处都有
-
5.3.1.1. 软件通常也会运行在权限较高的模式下，因此有可能会损坏大量数据
-
5.3.1.2. 由于那种软件会有成百上千的公司安装，因此其中如果隐藏着什么问题，那么一旦爆发，就会造成相当大的危害
-
5.4. 恶意攻击
-
5.4.1. 有人故意要搞破坏
-
5.4.2. 恶意攻击数据中心，是经常发生的事情
-
5.4.3. 真正的敌人就是那些想通过某种形式的电子攻击来破坏这个组织的人
-
5.4.4. 绝不会知道网络攻击会从哪里发起
-
5.4.5. 每次更新软件时都应该先验证，看它是否有安全漏洞（或者说安全隐患）
-
5.4.6. 备份数据保留得比现有计划稍长一些
5.5. 恐怖攻击
-
5.5.1. 恐怖攻击是你必须遵循3-2-1原则的另一个理由
-
5.5.2. 如果放置数据库副本的服务器离主站只有数百码（1码=0.9144米），那这种DR方案就不够稳妥
-
5.5.2.1. 其中一套备份放在距离受保护的数据比较远的地方
-
5.5.2.2. Disaster Recovery，DR
5.5.2.2.1. 灾难恢复
-
5.6. 电子攻击
-
5.6.1. 你的组织更有可能遭受的，应该是某种形式的电子攻击（也叫网络攻击）
-
5.6.2. 入侵手段根本就都没有利用防火墙的漏洞，它们利用的都是人的某种弱点，以促使员工自己去打开这个后门
- 5.6.2.1. 通过网络钓鱼(phishing)或者社交欺骗的手段安插的，攻击者会利用这些手段，诱导员工把恶意代码直接下载到他的工作环境里面
-
5.6.3. 攻击者通过给手机充电的线缆来部署恶意软件
5.7. 勒索软件
-
5.7.1. ransomware
-
5.7.2. 如果针对的是个人，那可能是几百美元，如果针对的是比较大的组织，那可能是上百万美元
-
5.7.3. 恶意软件与勒索病毒已经横行很久了
-
5.7.4. RaaS
-
5.7.4.1. Ransomware-as-a-Service，勒索病毒即服务
-
5.7.4.2. 让很多人都能相当轻易地发起勒索攻击
-
5.7.4.3. 你只要说出自己想攻击谁，并提供一些有助于入侵的信息，他们就会帮你执行勒索攻击
5.7.4.3.1. 这样的犯罪团伙完全是为了谋利，他们会从勒索到的钱财里面分走很大一部分
-
5.7.4.4. RaaS出现之后，就不再有这个障碍了，只要知道怎样进入暗网(dark web)并联系到提供RaaS的团伙，就可以发动勒索攻击
-
5.7.4.5. 勒索病毒也随着RaaS模式的兴起变得越来越猖狂，这种攻击对数据造成的风险与日俱增
-
5.8. 内部威胁
-
5.8.1. 很多组织都没有对从内部发起的攻击做好准备，其实这种攻击也会给数据带来损失
-
5.8.2. 就算某些攻击不是从内部发起的，它也需要内部因素的配合才能实现
-
5.8.3. 最常见的内部威胁，来自对本组织不满的正式员工或合同工，他们会利用手中的权限来损害公司的财产
-
5.8.4. rogue admin（“流氓”管理员）问题
-
5.8.4.1. 拥有特权，因此能够悄悄地对数据造成极大破坏
-
5.8.4.2. 植入一些能够在自己离职之后，继续破坏原公司数据的代码
-
5.8.4.3. Yung-Hsun Lin（音译：林永勋）事件
5.8.4.3.1. 2004年给公司的70台服务器安装了所谓的“逻辑炸弹”(logic bomb)
5.8.4.3.2. 是一个脚本，他怕公司将其解雇，所以编写了这个脚本，一旦公司把他炒掉，他就通过触发该脚本来删除服务器中的所有数据，以此报复公司
5.8.4.3.3. 于2006年获罪
-
5.8.4.4. 如果有人能不受限制地使用Windows系统的Administrator（管理员）账户、UNIX与Linux系统的root（根）账户或其他操作系统中的类似账户，那么就能轻而易举地变身为一个rogue admin，让你很难追查他所造成的破坏
-
-
5.8.5. 系统管理员拥有很高的权限。因此你必须尽力限制这些拥有特权的人在做出恶意行为时有可能波及的范围
-
5.8.5.1. 让他们总是以自己的身份登录系统
5.8.5.1.1. 每个人都应该用自己的名字登录
5.8.5.1.2. 就算要获取root或Administrator权限，也必须先以自己的名字登录，然后再通过某种留存有记录的机制来获取管理权限
5.8.5.1.3. 尽量限制或阻止他们使用那种必须以root或Administrator身份运行的工具
-
5.8.5.2. 不要把root密码告诉任何人
5.8.5.2.1. 把root或Administrator账户的密码设置成一个随机的字符串，没有人知道这个字符串具体是什么
5.8.5.2.2. 为了让想要获取root或Administrator权限的人，必须先以自己的身份登录，然后再通过sudo或Run as Administrator（以系统管理员身份执行）等手段来获取管理权限
5.8.5.2.3. 所有的操作都会留有记录
-
5.8.5.3. 删除或禁用那种能够提供shell环境（命令行执行环境）的程序
5.8.5.3.1. 用户以root身份运行vi，那么就可以通过这个机制进入一个有root权限的shell界面，并在其中不被记录地执行任意命令
-
5.8.5.4. 让超级用户只能通过控制台登录
5.8.5.4.1. 用户只能通过控制台(console)登录
5.8.5.4.2. 一定要把能够实际接触到控制台的访问行为记录下来
5.8.5.4.3. 针对虚拟控制台的访问行为记录下来
-
5.8.5.5. 启用主机之外的记录机制
5.8.5.5.1. 凡是有人访问超级用户的账户（无论这次访问是否经过授权），都应该记录成一次安全事件，并把相关信息（例如视频监控画面或针对虚拟控制台而设的日志）稳妥地保存下来，让网络入侵者无法删除这份证据
5.8.5.5.2. 就算有人想要破坏系统，他也不可能轻易地抹除自己的踪迹
-
5.8.5.6. 不让计算机从其他启动盘里启动
5.8.5.6.1. 尽量设法阻止用户从系统盘之外的其他启动盘启动服务器或虚拟机
-
-
5.8.6. 将各种权限分离
- 5.8.6.1. 备份与DR系统是最后一道防线，因此应该由完全不同的一方来管理，而且你不能让这个管理方有机会破坏你所要保护的基础设施
-
5.8.7. 基于角色的管理
-
5.8.7.1. role-based administration
-
5.8.7.2. 把数据保护系统里面的各个部分交给不同的人来管理，这些人各自具备不同的权力
-
5.8.7.3. 把备份策略的配置权（也就是定义权）与操作权（也就是执行权）分开，能够限制其中一方所拥有的权力
5.8.7.3.1. 一种角色可能拥有日常的备份操作权，也就是说，此类人员可以执行预先定义好的备份任务
5.8.7.3.1.1. 这些人无权修改备份策略
5.8.7.3.2. 备份策略的修改权，掌握在另一种角色的手里，然而他们虽然能修改备份策略
5.8.7.3.2.1. 无权执行这些策略
-
5.8.7.4. 恢复工作可能会由一个与上述两者完全不同的角色负责
5.8.7.4.1. 以防止此类人员利用数据恢复功能，将数据泄漏到本组织之外
-
5.8.7.5. 从安全角度看，最好能把备份系统中的每个角色指派给不同的人
5.8.7.5.1. 并不能完全消除来自内部的威胁，但确实可以大幅降低这种概率
-
-
5.8.8. 最低权限
- 5.8.8.1. 一定要保证每个人与每个程序都只获得了执行其工作所必需的权限，而没有获得与其工作无关的权限
-
5.8.9. 多人认证机制
-
5.8.9.1. 多人认证/多人授权(multiperson authentication)机制
-
5.8.9.2. 多重认证（multifactor authentication，也叫多因素认证）机制
5.8.9.2.1. 在执行某项操作之前，必须同时获得两人同意
5.8.9.2.2. 四眼授权(four-eyes authentication)，因为会有两双眼睛盯着这个事情
-
5.8.9.3. 某些数据保护产品要求用户同时获得两个人的许可，如此才能执行恢复操作、修改备份策略或减少某个备份的保留时间
-
6. 机械故障或系统故障
6.1. 关键的工作数据现在都保存在某种形式的固态介质上
6.2. 存储设备比原来更加健壮，而且任何一个重视数据的数据中心，都会配备RAID这样的冗余存储机制以及纠删码(erasure coding)技术
- 6.2.1. 整个RAID阵列中的磁盘同时故障的情况相当少见，但也不是从来没有发生过
6.3. 设备的固件里面内置完整性检查(integrity checking)逻辑，宁可让数据无法保存，也不让磁盘发生故障
- 6.3.1. 很少出现因为硬盘故障而恢复数据的情形，但这并不意味着这种情形绝不会发生
6.4. 目前的系统与数据库已经能够应对许多数据问题，因此由物理故障及系统故障所造成的数据损失，应该不会很常见
- 6.4.1. 很少遇到这种因发生机械故障而必须恢复数据的情形，但这样的情形确实存在
6.5. 电力中断
-
6.5.1. 任何一个颇具规模的数据中心，都会有冗余电源与大型发电机
-
6.5.2. 结构化的数据基本上应该不会受到破坏，因为数据库有内置的数据完整性检查机制，不会让结构上有问题的数据写到数据库里面
-
6.5.3. 无结构的数据（也叫非结构化的数据）基本上也应该没事，只是停电那一刻正在写入的少数几个文件可能会有点问题
6.6. 云平台没有那么神奇
-
6.6.1. 并没有所谓云(cloud)这个东西，它还是得依靠别人的计算机来实现
-
6.6.2. 云平台没有那么神奇，它本质上还是一批给你提供服务的计算机而已
-
6.6.3. 云平台所支持的各种数据存储机制，从数据保护的角度看，是有所区别的
-
6.6.3.1. 采用对象存储(object storage)机制来保存的数据，可以在多个位置上存留多份副本，因此能够经受多次事故
-
6.6.3.2. 采用块存储(block storage)机制来保存的数据，则只是虚拟驱动器里面的一个LUN（Logical Unit Number，逻辑单元号），这个虚拟的驱动器仅位于某一间数据中心的某一个存储阵列里面
6.6.3.2.1. 这种存储方式没有任何冗余机制，因此采用该方式存储的数据必须加以备份
-
6.7. 系统故障
-
6.7.1. 无论你用的是仅依赖某一个存储阵列的单一服务器（由不同位置的多个数据中心所构成的大型服务器集群），还是由云端所提供的服务，都无法保证其完美无缺
-
6.7.2. 软件与硬件未必总是按照预想的方式运作，因此我们必须做备份
7. 自然灾害
7.1. 自然灾害是我们必须遵循3-2-1原则的一个重要原因
7.2. 计算机不仅怕水，它还怕火
7.3. 水灾
-
7.3.1. 数据中心可能受各种原因影响而发生水患
-
7.3.2. 就洪水这一因素而言，数据保存得越高越好
-
7.3.3. 要确保DR站完全位于洪水的波及范围之外
-
7.3.4. 把DR站放在距离主站较近的位置，但是要保证它比主站更高
7.4. 火灾
-
7.4.1. 烧毁数据中心的不一定是山火，也有可能是那种因为短路而引发的火灾
-
7.4.2. 电路里面要有断路器(breaker)，以便在短路时自动跳闸，然而这种断路器未必总是能及时跳闸
-
7.4.3. 火对数据中心会造成巨大损害
-
7.4.4. 有许多种与备份及数据恢复无直接关系的办法，均能防止数据中心失火
-
7.4.5. 防火也是我们要备份数据的一项原因
7.5. 地震
-
7.5.1. 应对地震，关键是要做好准备
-
7.5.1.1. 建筑方面的法规也要求建筑物里面的东西必须绑住。就连热水器也是绑住的
-
7.5.1.2. 数据中心的机架（rack，也叫机柜）放在防震座上，让我们可以在地板出现震动的情况下移动机架
-
-
7.5.2. 确保DR站位于伤害范围之外
- 7.5.2.1. 由于地震的伤害范围通常会局限在某一个区域内，因此这一点并不是很难做到
7.6. 飓风、台风、旋风
- 7.6.1. 应对飓风的关键在于把DR计划所依据的系统，放在完全不受飓风侵扰的地方
7.7. 龙卷风
-
7.7.1. 龙卷风是一种猛烈的旋转风暴，它会把巨大的破坏力集中在某一点上
-
7.7.2. 应对龙卷风的关键，也在于让DR站远离频发龙卷风的地带
7.8. 落水洞
-
7.8.1. 又叫渗穴、天坑
-
7.8.2. 这种灾害能够像龙卷风那样，对某地施以外科手术式的打击，同时又像地震那样无法预测
-
7.8.3. 经历过龙卷风的人，会说风刮得跟货运车经过时一样，而落水洞则是突然出现的，它不声不响地带来巨大伤害
-
7.8.4. DR站一定要放在远离主站的地方
-
7.8.5. 从每平方英里的角度看，落水洞的出现数量似乎很少，但问题在于，这种现象随时有可能发生
