@dyk
2015-10-21T02:44:07.000000Z
字数 2921
阅读 372
RollBack
本节内容对先前工作的初步总结。
云环境是新型的计算环境。用户能够使用手机或者PC甚至云主机对云服务进行访问。云服务又能分化为不同种类的服务，云存储，云计算。云存储主要是作为一个remote disk作为使用
我们准备解决的问题是动态与静态的多重问题和其他的解决方案不同
目前的回滚，云系统/云服务的automatice recovery机制（normal and sporadic operation），用户自己驱动的回滚。
回滚的原因，升级失败，数据恢复，事件错误。出现了无法轻松解决的问题。
回滚问题都是由于回滚产生了时间上状态的不一致问题。由于不同的实体之间都是有互相的Input和Output，在回滚属性存在的情况下保证这些实体的安全性，不会由于回滚而产生漏洞和攻击。
某实体回滚会对与其相关的实体造成冲击。
容易受到回滚影响的数据：random number，one time key，key generation/migration/eviction，sealing，unsealing，remote attestation，authorization，time related（前面的数据都是time related的，需要再次的挖掘，虚拟机或者程序的生命周期中都一直存在时间的概念)，以及包含以上数据的各类协议。这些问题往往都是出现在左右环境中（Peers的环境中）。以及协议（VMI机制，高可用热备）的问题能够出现上下以及左右的环境中。
回滚造成的问题分类：
感觉我的分类没有特点，没有CU，SP，CP的特点？感觉每一个场景都可能存在
问题的思考角度：
攻击者的角度，使用回滚掩盖攻击的轨迹，恶意行为的痕迹，基本所有的回滚都能做到。
保护者的角度，回滚使的密钥，随机数，协议，加密出现漏洞
数据拥有者，数据使用者，服务提供者，服务使用者。
云用户CU：可以是云中用户，也能是云外的用户（区别就是是否利用云提供商的服务），他们都会利用SaaS提供商的服务。
SaaS提供商SP：为用户提供服务，同时利用云提供商的服务。
云提供商CP：提供云的基本管理服务，基本监控，虚拟资源。
回滚目标的层次问题：
软件层SL，操作系统层OL，云特有的管控层CL，物理层PL
ssh，用户软件 CU， SP
系统counter或者timer CU， SP
VMI策略，监控，负载，网络中间件 CP
TPM，智能卡 CP
同层的问题成为左右问题，不同的层的回滚交互不一致称之为上下问题。
对于回滚的方法策略的要求，或者是静态回滚的安全考量点
快照安全，日志安全，算法安全，安全兼容性。（这几个考量点，是否并不是需要回滚来完成，其他的工具能否完成）
同层问题
死锁：如果多个虚拟机任意回滚很有可能产生交互死锁。这个情况只有在normal operation的时候才有可能产生。
compensation operation is not available
回滚 + 数据恢复策略 + 事件恢复策略
回滚，在设计的时刻决定回滚的粒度，决定不需要回滚的部分。回滚的部分往往是系统的基础部分（能够提前确定的部分）。IaaS层的考量对象
完全回滚：将目标状态完全回滚到和检查点一样的状态。
场景：对于普通的服务，不存在不能回滚的安全组件
部分回滚：将一些特殊的安全组件排除在外，将其他组件的状态回滚到检查点时的状态。
场景：存在不能回滚的单调counter，单调的记录器。当被回滚后整个状态将会出现漏洞。
数据恢复策略，针对运行服务时候产生的数据，并不像回滚阶段处理的数据是底层的数据。这里讨论的数据是较为上层的数据。例如软件的交互密钥，动态生成的随机数，用户的机密文件。
完全不恢复：不采取数据恢复策略。
（下面的策略感觉和时间回滚重复了）
合并恢复策略：
*强删除策略（阅后即焚）：在以往的模式中，如果要强删除一个文件通常就是把硬件的对应位置变成0或者1。但是在存在快照的环境中，这些需要删除的文件，可能在快照中存在响应的副本。在回滚的过程中这些被强删除的文件不能再次恢复。
事件相关恢复：
重做：需要状态的同步，需要和外界进行一致性同意，但是设计的操作不能包括单调的操作。包含的只能是normal operations（包括sporadic operation）。
场景；当用户在SaaS提供商处申请了对另外一个实体E的授权删除。但是当SaaS提供商发生回滚的时候这个删除授权的操作影响将被忽略实体E能够在用户禁止的情况下访问用户在SaaS提供商的数据，
重放：对于单调的操作，即使重做也无法达到一致的状态。
场景：对于通信时候随机数的协商，当A与B进行通信是，他们交互了双方的随机数，当A发生回滚，如果不进行重放，那么信道的随机数需要重新沟通，如果存在重放将A的随机数以及与B交互的随机数，做到状态一致。
注意：时间在回滚后并不是一直都处于同步的状态。
过去的事件可能需要过去的时间。
时间不一致问题：时间并不是任何时候都能同步的（或者说时间的同步有延迟），当A回滚后，时间出现紊乱，与其他的实体的时间出现冲突，导致问题（什么问题）。重放以及重做的时间设置。（类似于软件）。重放时间与协同方的问题，其实事件的重放过程是单独的，期间外部的响应可能需要挂起，但是自己这方扔在重放。无法做到完全的状态连续保证
场景：时间的紊乱，将导致虚拟机对证书的有效与否做出错误的判断（重放攻击可能）Peers问题。
以上的解决方法目前只能解决同层的交互问题。（这些问题都有问题特性）
这类的问题是否能够再次分类，并且拥有类似的解决办法。
VMI问题（一次性检测问题），跨层的不一致问题，无法通过加强回滚防止问题发生。
解决方法只有重做安全手段。
回滚影响配额，进行云环境中节点移动。（有什么坏处？）
docker问题，docker给人的感觉是一种静态的容器，对于回滚并没有太多的动态的相关性。（docker的回滚基本是在配置环境或者测试的时候做的，在增量的存储的基础上做出变化。）
回滚失效错误，
CU-CU：协商的密钥丢失