@dyk
2015-09-23T07:54:17.000000Z
字数 9219
阅读 382
RollBack Workspace
试图根据是否能使用同一种解决方案，将不同的云环境的回滚问题进行分类。
这次的回滚分类相较与其他分类方法将会更加细粒度的进行分析。
具体的分类方法见第二部分。
分类如果单单的就回滚来分类就太过于简单了，实际上面云环境的回滚其实十分少的，大多都是recovery的策略，回滚策略是recovery策略的一个子集，并且现有的回滚策略往往就是
以下的分类是针对回滚的目标的特点进行划分。
产生问题的原因进行分类
应用对应用 应用对虚拟机 虚拟机对虚拟机
分成多个层次进行分类 ———— 应用层，虚拟机层，云层
从本质出发，为什么会产生这些问题，采用通用的方法去解决一类的问题
单机 嵌套虚拟机 多机 Input\Output time issue
rollback rollforward life cycle
分析现有回滚机制的安全性入手，对现有的回滚恢复的机制进行划分？
目前很多的recovery的确没有十分的考虑安全因素，就这样划分是否可行？
现有的recovery感觉很多都是针对单一的虚拟机的
而且划分只有application层面以及infrastructure层面两个层面，面对云环境如何细致的划分？
论文试图分析内容：
安全的回滚是否只是在涉及密钥以及隐私的情况下才能够称为安全的回滚，如果只是一些普通的数据就不需要这样的安全的回滚特性了？回滚是任意的时间段都能够进行回滚的，但是当回滚recover的一些时间段包含了安全敏感的事务的时候，这个时候的回滚可能就必须要考虑安全的回滚了。
回滚的安全，表示回滚对于其他的机制或者系统造成的冲击（输入，输出，状态不一致等问题）不能破坏原先的没有回滚情况下的安全性。（此时能够联想到的还是local的关键的数据的一致性）
时空的一致性是什么，抽象的定义回滚是什么
理想中的回滚 —— 能够通过回滚解决多层次云环境服务的错误，一些难以消除的影响，然后在回滚结束后不会对现有的机制造成攻击
关注程序或者服务的回滚特性，是否需要思考infrastructure的回滚
回滚的主体： 云系统automatic recovery机制，云服务的automatic recovery机制，云用户自主的recovery机制
回滚的起因： 发生错误，虚拟机乃至云系统整个无法正常的完成功能
错误的分类：
原文的分类往往是从高可用性的角度对种种的回滚的性能以及能够解决的问题进行划分。但是并没有考虑回滚的加入对安全带来的影响。原文的normal sporadic发生错误
replay 能够解决很多的问题，但是如何做到完全安全的replay是很难的。replay要做到对内的输入完全相同，对外的输出却可以忽视。对内的输出，即使完全的相同最后的返回可能也会不一样，并且会走向其它的状态
一致性 绝对的一致性还是相对的一致性，绝对的一致性就像是时间的悖论无法重现，最求的只是相对的一致性，A回滚了，但是状态需要和B一致，肯定不是绝对的一致了，如果绝对的一致是否会产生重放问题。一致性问题到底还是数据的问题，状态等一切都是数据的体现。
站在不同的角度对回滚进行分类，回滚是否会导致安全性的漏洞。
Failure，recovery and rollback
这里的回滚指得是虚拟机回滚
攻击者的角度，使用回滚掩盖攻击的轨迹，恶意行为的痕迹，基本所有的回滚都能做到。
保护者的角度，回滚使的密钥，随机数，协议，加密出现漏洞
数据拥有者，数据使用者，服务提供者，服务使用者。
分类标准是什么
| 恢复策略 | 样例 |
|---|---|
| 云应用回滚 | 基于检查点的回滚 基于日志的回滚 |
| 容灾 | 异地容灾 云存储复制 |
| 虚拟机复制 | Remus |
| 容错 | Recovery Block, N-version Programming, Parallel， FTCloud |
| 云内部策略恢复 | FATE&DESTINI |
| 测试驱动脚本 | Chef mini test |
| 云操作错误解决 | 脚本/管理工具异常解决 |
| 云操作事务回滚 | 向前/向后回滚 |
| 云操作进程回滚 | 操作的undo&redo |
| 基于用户的回滚 | 回滚策略的生成 |
感觉下面的划分有很多的重合的地方。
回滚是将虚拟机的感知时间以及状态回转，攻击者往往也能利用这样的特性，掩盖自己的攻击行为（跳过一些触发型的安全检测）。
yes：表示攻击者无法利用回滚隐瞒自己的攻击事实
回滚是将虚拟机的感知时间以及状态回转，防御者的密钥，随机数的特殊个性质将会被回滚而破坏，从而导致保护者需要保护的数据以及程序产生安全问题。
yes表示，用户的安全敏感数据以及进程运行不会应为回滚而变得有漏洞。容易被重放，或者回滚导致的问题。
对于使用者（其他的虚拟机）而言，远端的交互机器回滚之后，将导致种种的状态不一致，将会对使用者的使用产生冲击。
yes表示，回滚不对使用者的安全照成影响。
Replication等等的方式
| 回滚策略 | 攻击者角度安全 | 保护者角度安全 | 使用者角度安全 |
|---|---|---|---|
| 基于检查点 | no | no | weak |
| 基于日志的回滚 | yes | no | yes |
下面的划分是否太过于简单了。
快照分为，内存快照，磁盘快照。
内存快照 => 可能含有恶意进程
,含有漏洞的京城
磁盘快照 => 过期的密钥，已经删除的私密信息。
基于日志的方法，往往对日志不进行处理，如实的重放从上一个节点到现在所有事件。
但是这些事件中，有不能重放的内容（影响数据的单调性，影响其他的使用者，一次性使用的数据），甚至有攻击者的攻击vector，
所以日志安全表示，日志的重放需要满足在达到consistent state的同时不能降低回滚主体的安全性。
以往的算法往往是根据信息来计算回滚的检查点（具体的事件是否需要同时进行讨论，是否有两条必须在一起执行的命令）
重放算法 => 是否完全按照过滤日志的内容如实的重放时间。
包括回滚算法，以及重放算法
对于其他协议甚至是服务产生冲击，面对日益复杂的云环境，越来越多的新的服务，这些新的服务能否在面对rollback机制存在的情况下面保持自身的可用性和安全性。（回滚安全方面）
| 策略 | 快照安全 | 日志安全 | 算法安全 | 安全兼容性 |
|---|---|---|---|---|
| Memoir | weak | not mentioned | yes | yes |
| Defending against VM Rollback Attack | weak | not mentioned | not mentioned | weak |
| Multi-stage Replay with Crosscut | not mentioned | yes | not mentioned | not mentioned |
| Supporting Undoability in Systems Operations | not mentioned | weak | yes | not mentioned |
回滚的问题，本质是由于不一致而产生的。
回滚能够造成：时间逆转漏洞，重放漏洞与欺骗攻击，其中一个是重放而产生的漏洞，一方面是重放能够发动的攻击。
数据回滚漏洞：过去的老的有漏洞的软件，过期的密钥，绝密的文件。
状态回滚漏洞（重放漏洞）：模块的回滚的属性，让其容易受到别的模块的重放攻击。
状态回滚攻击（欺骗手段）：通过回滚自身的状态，达到欺骗一次性的验证的目的。
同步回滚漏洞：
角色分为：
云用户（一或多），SaaS提供商（一或多），云提供商（一或多）。
云中的策略，分布式文件系统（HDFS），热备系统，安全协议(?
)。
云用户能够使用回滚攻击的对象是：SaaS提供商，其他的云用户，（云提供者?）
能够采用的攻击是：欺骗，回滚自身的状态欺骗SaaS提供商。回滚自身欺骗类似远程证明类似的协议。
回滚带来的不一致漏洞：时间限制的数据的过期，由于数据的过期产生一系列的不一致问题（单机的情况下面）。
SaaS提供商层面上面，回滚带来的问题更加的深刻，传播性更加的强。
由于SaaS提供商往往还有一个服务架构，这个架构又较为复杂，在回滚的属性存在的情况下，这个服务框架将会显露出许多的安全隐患。
SaaS层面的回滚的欺骗性也同样是十分严重的，它能够欺骗云用户，也能欺骗云提供商（VMI问题，热备问题）。由于SaaS提供商能够服务于多个云用户，并且能够在云提供商无法察觉的情况下进行攻击。这样对于云环境和云用户都是十分大的安全考验。
云提供者的权限是最大的，能够采用的回滚也是没有限制，能够跳过现有的许多的防御手段通过回滚攻击用户虚拟机（包括云用户，以及SaaS提供商），采取的攻击手段主要是通过回滚跳过Hypervisor层面的防御手段（CloudVisor）来降低目标的安全性，完成入侵的手段。
试图通过解决手段来进行分析
回滚：部分回滚，全部回滚...
重放：完全重放，合并，删除，不重放...
试图让回滚过程揭示更加多的信息，详情请看PPT
回滚 + 数据恢复策略 + 事件恢复策略
回滚的操作的对象和策略都是在设计时候就以及规定好的。
完全回滚：虚拟机的状态，以及所有相关的数据将会回滚到checkpoint的时间点。
场景：如果当前点到检查点之间并没有对时间相关的单调数据的操作。能够回滚的都是一些与时间不相关的数据。
部分回滚：根据不同任务和目标的需要，在设计回滚的时候将一些固定的数据设定为回滚resistant。这些数据将不会随着目标回滚而回滚。这部分内容也不会参与以下的策略。
场景：当目标使用了时间相关的单调counter，回滚将不会回滚这个counter的相关数据。该策略能够适应所有的不适合回滚的单调数据。
数据恢复策略
这个策略所定义的数据并不是在设计时间定义的，而是在运行的时候动态出现了。
完全不恢复：将所有动态生成的数据全部复原成为检查点时候的状态。
场景：不同恢复场景
合并策略：新旧的数据共存，保留原有的数据同时恢复新的数据。
场景：虚拟机中存在密钥key1和key2，其中key1被攻击者破坏，key2密钥发生周期性更新。如果不回滚将会导致key1被攻击者破坏，数据无法再次解密，如果使用不同回滚将会导致key2密钥的周期更新结果丢失（这个用事件恢复策略也能够解决？），采用合并策略恢复key1密钥，并且保留key2密钥。
问题：这个策略如何指定以及如何实现？
强删除策略(阅后即焚策略)：快照中是一个过去的状态集合，存在需要阅后即焚的文件。
场景：于一些安全性高的文件被删除了不希望被恢复，即使是回滚快照中的备份也需要被删除。防止回滚被恶意用户利用，恢复被删除的机密文件（阅后即焚）。
事件相关重放：
除了和回滚相关的数据之外，不同事件，不同的用户需求对于重放的要求也是不一样的。
重做：需要状态的同步，需要和外界进行一致性同意，但是设计的操作不能包括单调的操作。包含的只能是normal operations（包括sporadic operation）。
场景；当用户在SaaS提供商处申请了对另外一个实体E的授权删除。但是当SaaS提供商发生回滚的时候这个删除授权的操作影响将被忽略实体E能够在用户禁止的情况下访问用户在SaaS提供商的数据，
重放：对于单调的操作，即使重做也无法达到一致的状态。
场景：对于通信时候随机数的协商，当A与B进行通信是，他们交互了双方的随机数，当A发生回滚，如果不进行重放，那么信道的随机数需要重新沟通，如果存在重放将A的随机数以及与B交互的随机数，做到状态一致。
时间不一致问题，时间并不是任何时候都能同步的（或者说时间的同步有延迟），当A回滚后，时间出现紊乱，与其他的实体的时间出现冲突，导致问题（什么问题）。重放以及重做的时间设置。（类似于软件）。重放时间与协同方的问题，其实事件的重放过程是单独的，期间外部的响应可能需要挂起，但是自己这方扔在重放。无法做到完全的状态连续保证
场景：时间的紊乱，将导致虚拟机对证书的有效与否做出错误的判断（重放攻击可能）Peers问题。
多机问题与单机策略：对于上面描述的单机策略能否解决多机的问题。对于单机的情况交互的对象往往是Peers，但是多机情况，多个机器的功能往往不一样，他们之间的相互关系也是有层次的。
回滚目标，以及交互的目标+
单纯的交互问题
多级问题，如果能够采取单机的解决方法的组合能解决的问题是多级的同层回滚问题。回滚的目标以及影响的目标都是同层的Peers。
除了虚拟机自身的这一层，还有云管理服务这一层。
多机问题事实上就躲不开分层，云环境自身分为了IaaS，PaaS以及SaaS。在不同的层次之间的回滚应该是透明的？是否会被不同层次而感知？
将云环境下的回滚目标进行分层。上中下三层，被回滚的对象作为中层。中层向上层提供服务，中层利用下层的服务。每一层都能感受到回滚对相邻层的影响。
云块存储，云文件存储，云对象存储。
存储方面，由于现在的存储都趋于平面化，层级结构并不是特别明显，在这个环境环境下面的回滚问题基本都能采用单机的回滚方法，保证单个的节点的回滚安全即能够。
OpenStack
目前的Xen虚拟化环境的有一个倾向就是将dom0减负，设置多个不同的功能域完成一系列的动作。
云环境下的监控，很多情况下都是在用户域之外的域进行的。
VMI问题（一次性检测问题），通过回滚将状态回滚，只让检测者检测恶意虚拟机主提供的“无意义”的状态。
解决方案：回滚时将重做安全措施。回滚意味着状态的变化，在缺乏快照的度量手段，无法预知回滚之后的状态如何。单机的手段无法解决这个问题底层问题
云环境中虚拟机的配额变化问题，云环境中虚拟机将会因为负载的变化而被迁移，在高可用的虚拟机复制策略的支持下，虚拟机也将会在primary节点以及backup节点之间移动。回滚属性的加入将会给这些策略带来什么影响。
auto scaling：回滚的配额变化可能将会触发auto scaling并且引起费用变化问题。Azure中禁止了配额变化的回滚操作。
图形化问题之后的场景。以下场景中回滚的一般是虚拟机
回滚失效错误：AB两用户正在进行建立安全协议时候的多步密钥协商过程（随机数协商）。当A用户发生回滚丢失了B用户的发送过来的RN2，然后B用户在等待A用户发送RN1，这样导致AB两者状态不一致，产生错误，沟通失效。（类似的多步协商协议都会产生问题）
解决方法：回滚的一方进行内容重放。将A用户由于回滚而丢失的RN2进行重放给B。
数据回滚漏洞：CU用户能够理解成为虚拟机，移动终端或者是PC端。快照中的数据可能是有漏洞了，例如，存在过期的密钥（恶意的攻击者破解密钥之后能够进行攻击），有漏洞的软件（就算已经安装了补丁程序但是回滚之后软件的漏洞还是能够暴露出来），阅后即焚的机密文件（存放在这个虚拟机中的机密文件即使删除了，再它的快照中还是存在，通过恢复快照，将能获得该机密文件）
回滚失效错误：AB两用户正在进行建立安全协议TLS时候的多步密钥协商过程（随机数协商）。当A用户发生回滚丢失了B用户的发送过来的RN2，然后B用户在等待A用户发送RN1，这样导致AB两者状态不一致，产生错误，沟通失效。（类似的多步协商协议都会产生问题）。
当SP提供的的对象存储服务（HDFS，OpenStack swift），当SP的HDFS的namenode发生回滚之后，在当前时间点到快照点之间的namenode中发生的操作将全部丢失，发生namenode中记录的k->pos的映射与datanode中的现实状况不一致。运行的过程中将产生回滚失效。
状态回滚攻击（欺骗）：
状态回滚漏洞（重放）：当CU请求SP执行命令的时候，一般将会带有一个随机数，或者其他的机制来保证请求的新鲜度。但是当SP发生回滚的时候，这个确认新鲜度的机制也受到了挑战。过去的命令可能被再次执行。
SP算是一种特殊的CU，对于CP来说并什么太多的不同。
回滚失效错误：类似的协商过程中的失效。主要还是状态的问题。
状态回滚攻击（欺骗）：CP对于运行在虚拟机中的进程能够进行监视，对于出现异常状态的情况下，监控程序将会启动并且，查找异常进程（内核级别的rootkit检测隐藏进程），并且将其杀死。此时在CP检测的过程中CU将自身回滚，让基于VMI的检测程序检测到的只是回滚镜像中的内容。并无法成功检测到rootkit。
状态回滚漏洞（重放）：CU对于SP的命令请求，在SP的管理虚拟机被重放过后，过期的命令可能被再次执行。（例如充值命令，虚拟机提升额度命令）
回滚失效错误：类似的协商过程中的失效。主要还是状态不一致的问题。
数据回滚漏洞：SP是提供服务的一方，它里面的过期密钥，没有打补丁的软件（如果是升级失败的回滚就可能没有这个漏洞）。这些问题的出现将会影响多个CU。
数据回滚漏洞：作为云的提供者，构成云平台的各种组建很多，负载策略，高可用策略，网络中间件（防火墙，IDS等等），对象存储平台。这个软件的升级打补丁，都可能被回滚而破坏。
回滚失效错误：上个例子中的这些组建往往都不是单一的一个，而是多个组成服务，他们之间涉及了很多共享的数据，这些数据的状态不一致将会造成服务发生错误。
主要从各种软件的层次对云环境的回滚问题进行划分。主要是进行纵向的划分。
目标层次：软件层，操作系统层，云检测管控软件，物理层。
ssh，用户软件
系统counter或者timer
VMI策略，监控，负载，网络中间件 vTPM
TPM，智能卡
上面的分层是功能的分成，对于上一层利用下一层的服务。上层的回滚对于下层来说可能并不会造成太多的影响（监控层除外）。
SL-OL：对于OL层的回滚，counter，timer，将会造成软件层的软件被重放。然而对于SL与OL在云环境中仍然是属于同一个用户的，所以不存在欺骗
SL（OL）-CL：然而对于OL与CL属于云用户与云提供商的，他们之间的关系是CL层对OL进行限制，监视，控制的。他们之间可能产生欺骗。然而CL层并不会直接给OL层提供支持，所以重放攻击一般不存在。
CL-PL：对于物理层来说，回滚基本上是不可能的，但是上层的回滚将会导致与物理层的结果产生不一致的问题。这样的不一致，可能会被利用来
SaaS（软件层次）， PaaS（docker），IaaS（VM）
使用上面的分层方法对回滚方法进行分层。
SaaS层就是软件层，回滚对他的影响就如之前的软件层的的影响类似。
回滚失效错误：
数据回滚漏洞：
PaaS层，云平台提供层，暂时把它理解成为docker，docker环境中包含软件，以及常用的bin以及lib。这里考虑的主要是bin以及lib。对于App用户来说一个docker的PaaS类似与一个黑盒环境。SaaS与docker只是简单的使用了docker中的内容。而且具本人的理解PaaS的环境趋于静态的
数据回滚漏洞：
IaaS层，就说的是VM层。在VM层由于VM上跑的应用不同，可能发生的影响也多种多样。
失效错误，回滚漏洞，重放，欺骗都有可能发生。
针对以上的问题提供解决的思路，进行分类。
iPhone预售多扣费的新闻。
新的思路：
对于Remus触发的情况，能否考虑回滚导致side-channel的防御手段失效。
是否有必要在云环境下对几种环境的适应性进行性能测试