【云计算学习教程】云计算终端技术详解

云终端是用户操作的主要设备，也是用户接入云端的入口。追求完美的用户体验是终端厂商和云服务提供商唯一的选择，也是云计算成败的关键因素。为了使得一款终端实现“用之赏心、观之悦目”的目标，需要从功能、外观、操作、质量几方面入手。终端分类终端在外观上体现为多样性，分类如下。1. 按功能分类1）人/机交互终端不断地通过键盘、鼠标、触摸屏、声控等手段输入信息，通过显示器、打印机、音箱、发光灯等设备输出计算结果

小熊coder

4753人浏览 · 2022-01-02 00:09:16

小熊coder · 2022-01-02 00:09:16 发布

云终端是用户操作的主要设备，也是用户接入云端的入口。追求完美的用户体验是终端厂商和云服务提供商唯一的选择，也是云计算成败的关键因素。为了使得一款终端实现“用之赏心、观之悦目”的目标，需要从功能、外观、操作、质量几方面入手。

终端分类

终端在外观上体现为多样性，分类如下。

1. 按功能分类

1）人/机交互终端

不断地通过键盘、鼠标、触摸屏、声控等手段输入信息，通过显示器、打印机、音箱、发光灯等设备输出计算结果，人机协同完成各种任务，如各种台式云终端、智能手机、平板电脑等。

2）机/机交互终端

生活中的各种智能家电、工厂里的智能流水线、工业机器人等，这些机器本身与嵌入进来的云终端直接互动，完成控制和信息收集任务。

3）输入终端

持续采集数据并源源不断地传输到云端，这些数据将在云端存储、计算，如检测仪、数据采集卡、摄像头、人体监护器等。

4）输出终端

云端把计算结果通过这些终端输出，如音乐播放器、视频播放器、打印机、机械手臂、导航仪、显示屏等。

2. 按移动性分类

1）移动终端

靠离线能源续航，且相对轻便、便于移动，常被人拿在手里、穿在身上、戴在头上、放在移动的设备上。

2）固定终端

相对而言，体积大而且比较重，常会在办公桌上、智能设备中、墙壁上见到它们的身影，如图 1 中的左图所示。

3）固定/移动两用终端

终端由几部分组成，这几部分可以轻易拆卸和组装，组装在一起时充当固定终端，用于办公、软件开发和图形处理等；拆卸之后又便于携带和移动，如图 1 中的右图所示。

图 1 终端

3. 按屏幕尺寸分类

屏幕覆盖 1～50 英寸的各种尺码，按照尺码大小分为以下几类。

1）5 英寸以下的移动终端

主要用于通信、小内容信息收发（短信、微信、微博等）、音乐播放、导航、小游戏、信息采集、远程监控、远程定位、照相等，可随时随地携带和使用，真正体现人机合一的云生活。一般人走动的时候拿在手里使用。但是这样的移动终端很容易丢失、被盗和损坏，所以资料存放于云端就显得非常重要。

2）5～9 英寸的终端

主要功能包括大内容信息阅读（如网页、邮件、各种文档资料、图片、视频等）、各种弱交互性 APP、非经常性的信息收集（如会议记录、采访记录等），配上其他便于交互的部件（如大键盘、鼠标、大显示器等），可以实现日常办公。一般人站立的时候拿在手里使用。

3）10～14 英寸的终端

输入/输出部件分离（如键盘和显示器），能完成绝大多数的日常办公，属于真正的移动办公终端。一般人坐下后放在腿上或桌子上就能投入工作。

4）15～18 英寸（不含 18 英寸）的终端

带触摸屏，常固定，多用于公共场合的信息查询、家庭相册和视屏电话（挂于家庭墙壁上）、老人小孩学习娱乐用机、智能设备的触控、智能会议厅、智慧教室、家庭音乐播放等。

5）18～24 英寸的终端

固定办公终端，替代目前的台式机，完成日常办公、图片处理、音视频剪辑、影视后期制作、软件开发、游戏等，配备标准的输入部件。

6）25～31 英寸的终端

带触摸屏，常固定，多用于公共场合的信息查询，不是大众产品。

7）32～50 英寸的终端

主要用于娱乐和信息展示，采用遥控输入方法。

质量控制

云终端是用户直接携带和操作的设备，使用环境千变万化，所以质量非常重要。云终端要做成纯硬件设备，终端上用到的软件要全固化或者半固化。

全固化是指软件根本无法修改和删除；半固化是指不允许用户自己更改和删除软件，但是允许在线升级、打补丁，并提供出厂配置一键恢复功能。这样就可以大大降低产品的故障率，延长折旧期。

另外，终端中尽量少用软件，甚至只固化一个下载程序（BootLoader），启动时由这个下载软件临时从云端下载经过定制和裁剪的操作系统及会话软件，然后执行这个操作系统，最后运行会话软件，完成登录云端的操作。不过，这种技术要求网络速度足够快。

终极方法是连下载程序都不要，直接采用网卡的网络启动技术，开机时由终端上的网卡直接获取需要的软件并启动终端。

终端项目

1. RPTC

RPTC 的全称是 Raspberry Pi Thin Client project，意为树莓派瘦客户机项目。结合树莓派 ARM 小主板（见图 2），就能定制一台全功能的低功耗云终端，项目网站为 http：//rpitc.blogspot.com/。从此网站可以下载一个安装镜像文件，这个镜像文件采用 Linux 内核，集成了当前绝大多数的协议客户端。截至 2016 年 10 月，包括的客户端及其版本如下：

Citrix ICA 13.3.2.
VMware Horizon 4.1.0.
NoMachine NX 5.1.24.
Thinlinc 4.6.0.
Parallels 2x 15.0.
RedHat Spice/virt-viewer 4.0.
Firefox ESR 48.0.
xFreeRDP GIT build added 20160728.
dFreeRDP build with NEON support.

树莓派3代
图 2 树莓派 3 代

2. Windows 10 IoT Core

这是微软的物联网版本的 Windows 10 操作系统，经过定制可以运行在各种低功耗、资源受限的设备上，支持 ARM 和 X86 架构，如树莓派 2 代和 3 代。Windows 10 IoT Core 是免费的，采用它和树莓派 3 代可以轻松打造一款支持 RDP8.0 的云终端产品，在线定制网站为 https：//developer.microsoft.com/en-us/windows/iot/GetStarted＃，也可以从 https：//www.microsoft.com/en-us/download 网站搜索 Windows 10 IoT Core 并下载。

3. PiNet

PiNet 项目是一个基于树莓派的电子教室项目，用一台普通计算机做教师机，里面安装 PiNet，树莓派采用 SD 卡启动。利用 PiNet 创建的电子教室具备如下功能：

集中管理学生账号。学生可以在任意终端上输入自己的账号并登录。
网络启动终端。终端启动时自动从服务器上下载操作系统并启动。
师生共享文件夹。
作业发放与提交。
广播教学等。

PiNet 项目是 Raspi-LTSP 项目的替代品。图 3 所示是一个实际的电子教室。

图 3 PiNet 电子教室

云计算通信协议有哪几种？

看过中国香港警匪片的人应该对下面两个警察的对话耳熟能详：

“阿Sir，我发现他了，要不要跟上？Over。”

“跟上，但不要靠得太近，以免被发现。Over。”

“明白。他进入超市了，那里人多，要不要暗地疏散人群？Over。”

“……Over.”

这样，两个人“Over”来“Over”去的通话，其实就是警察局制定好的通话规则，只要向对方说出“Over”，就表明话讲完了，该轮到对方说话了。

通话规则也叫通话协议，规定双方通话时必须遵守的规则。终端与云端通信时相互遵守的规则就是通信协议，双方必须严格遵守事先制定好的通信协议，否则通信无法正常进行。

云计算通信协议涉及安全、图像处理、数据压缩、网络传输协议等多个领域，直接决定着租户的终端体验。目前，终端与云端的通信协议主要有如下几种。

1. HTTP/HTTPS 协议

这是网站采用的通信协议，HTTP 的默认端口为 80，明文通信；而 HTTPS 的默认端口为 443，密文通信。

密文通信是指，通信双方先加密内容然后再发出去，收到对方的信息后需要先解密。本协议常用于 PaaS、SaaS，以及未安装操作系统前的 IaaS。比如租赁了一台裸机（属于 IaaS），通过浏览器打开裸机的远程管理卡网页，然后通过这个网页给裸机安装操作系统。

2. RDP 协议

这是微软的远程桌面协议，最新版本为 RDP10，这个版本改进很大，具备这些特征：

支持最大 32 位色彩。
采用 128 位的 RC4 加密算法。
远/近端电脑共享剪贴板。
允许远程应用使用本地端口（端口重定向）。
本地文件系统重定向到远程计算机。
远程声音重定向到本地播放。

RDP 协议规范公布在官方网站上，任何人都可以参照此规范开发遵循 RDP 协议的通信软件。

RDP 10 在 Windows 10 和 Windows Server 2016 上直接支持，Windows 8 和 Windows Server 2012 支持 RDP 8.0，Windows 7 上需要打支持补丁包才支持 RDP 8.0。

RDP 也有针对 Android\Mac OS 操作系统的客户端软件，但是用户体验要差一些。

微软发布的远程桌面客户端软件是 mstsc.exe，有安卓版和 Mac 版，但是没有 Linux 版。

有一个开源软件 FreeRDP 可以在 Linux 上运行，但是只支持 RDP 7.0/RemoteFX。另外，Ericom 公司推出了多平台版的客户端和具备 RDP 加速功能的服务器端。RDP 协议常用于 PaaS 和安装了 Windows 的 IaaS 云服务。

RDP 协议能同时支持远程桌面虚拟主机（RDVH）和远程桌面服务（RDS），利用微软的终端服务和 RDP 技术可以搭建规模小、性价比高的云计算系统，如十几个人的私有办公云。

图 1 所示是从 Windows 7 登录到云端的 Windows 8 桌面（单击“开始→所有程序→附件→远程桌面连接”或者直接运行命令 mstsc.exe，然后输入云端 IP 地址），采用的是 RDP 8.0 协议。

云端的Windows 8桌面
图 1 云端的 Windows 8 桌面

3. PCoIP协议

这是 EMC 公司（收购 VMware）和 Teradici 公司共同开发的基于 UDP 的远程桌面协议，意为 IP 上的个人计算机（PC-Over-IP），在低带宽的广域网上也能流畅使用。

PCoIP 在主机上做图形渲染，终端只负责解码，因此减少了一些传输量，是专门为瘦终端而设计的。针对 Windows、Linux、MacOS、Android 和 iOS 操作系统，都发布了相应的客户端软件。

利用此协议搭建的云计算系统结构较复杂，软件许可种类多，这是一个缺陷。

图 2 所示是一个最小云计算系统的示意图，从图中可以看出，必须要有一个微软的域控 AD、连接器 Connector、虚拟主机（里面安装连接代理）和终端（安装客户端软件）。

第二个缺陷是目前还不支持微软的远程桌面服务，但是 Teradici 公司的产品 Teradici Arch 弥补了这个缺陷，该公司同时还推出了 PCoIP 的硬件加速卡。

图 2 最小云计算系统示意图

必需的组件包括：AD、Connector、VD 和 View Client。VD 可以是虚拟机桌面，也可以是物理机桌面，被 vCenter 管理的桌面为受管桌面，否则称为非受管桌面，VD 里都要安装 View Agent。vSphere Client 是用来管理 ESXi 或者 vCenter 的，如果没有这些，那么 vSphere Client 也可省掉。客户机上必须安装 View Client。vSphere Web Client 只能访问 vCenter。连接的路径是 View Client←→Connector←→View Agent。

4. HDⅩ/ICA 协议

这是思杰公司发布的远程桌面协议，采用 TCP，这一点与 PCoIP 采用 UDP 不同。思杰是最早做远程访问的公司，所以其技术积淀比较雄厚，在非常低的网络上（10Kb 左右）也有良好的表现。但不管怎样，采用此协议搭建的云计算系统还是要混合微软的产品的（操作系统、AD 域控等），相比微软的 RDP 协议，其架构较复杂。

主要组件包括：外网访问网关（Access Gateway）、桌面交付控制器（Desktop Delivery Controller）、资源池（XenServer Resource Pool）、文件服务器（File Share）、应用控制器（XenApp Controller）、虚拟机镜像供应服务器（Provisioning Server），如图 1 所示。

在局域网里面，最简化的采用 HDX/ICA 协议搭建的云计算系统为：终端（安装客户端软件）←→ Desktop Delivery Controller ←→ 虚拟机（安装 Agent），虚拟机的基础架构可以是 XenServer 6.x、ESXi 6.0 或 Hyper-V。不过，针对远程虚拟桌面市场，思杰公司特别推出了端到端的解决方案包 XenDesktop，目前版本为 7.6。

5. SPICE 协议

作为新兴的远程桌面协议，SPICE 协议最初由 Qumranet 公司开发，后来被红帽公司收购并开源，且被整合到红帽的云计算产品中。

SPICE 首先尝试将渲染的工作交给终端，利用终端的硬件资源来加速，再根据协商的结果考虑是否将渲染工作交给主机来处理，这时可以用软件或者 GPU 来渲染。SPICE 的双向音频流技术支持软件拨号和 IP 电话。SPICE 客户端支持 Android、Linux、Windows 和 Mac OS 操作系统，可以单独从 http：//www.spice-space.org/download.html 下载。

SPICE 协议包括三部分，分别安装在物理机、虚拟机和终端中，如图 2 所示。在图 2 中，通过终端的 SPICE 客户端软件打开 spice：//10.1.50.102：5903，即可连接到云端的虚拟机 2，如果虚拟机里安装了 Windows 7 操作系统，那么在终端上就可以看到 Windows 7 桌面了。

需要注意的是，终端统一访问物理机的 IP 地址，然后由端口号来区分是哪台虚拟机，比如 5903 代表虚拟机 2、5905 代表虚拟机 3。由此可见，SPICE 不支持微软的终端服务，也不支持裸机（不能直接连接到物理机的 Windows 桌面），只支持虚拟机。SPICE 作为一款开源的远程桌面访问协议软件，具备良好的发展势头，尤其是对于中国首次涉足云计算的公司来说，直接集成 SPICE 到自己的云计算产品中，不失为良策。

HDX/ICA协议搭建的云计算系统
图 1 HDX/ICA 协议搭建的云计算系统

SPICE通信协议
图 2 SPICE 通信协议

6. RFB协议

RFB 协议即远程帧缓冲（Remote Frame Buffer）协议，它直接把控制台的底层屏幕帧的内容实时同步到终端，所以能适应所有的操作系统。但是其传输信息量大，所以一般只在局域网内做点到点连接（一台计算机只与一台终端连接），以便远程协助解决计算机问题。

VNC 是由 AT&T 的欧洲研究实验室采用RFB协议开发的最典型的软件，后来在此基础上又衍生出了很多版本，其中 RealVNC、UltrVNC 和 TightVNC 最具代表性。

RealVNC 既发布商业版，也发布免费版，不过免费版的功能太弱，而 UltrVNC 和 TightVNC 则完全免费。三款软件的功能旗鼓相当，但是也有缺陷：

只能看到或者操纵同一个桌面，尽管允许不同的系统账号同时登录，而且这些系统账号必须具有系统管理员权限。
有的信息（比如 Windows 7 经常提示的“需要管理员权限才能运行此软件”）只能显示在本地的屏幕上。RFB 协议如图 3 所示。

RFB协议
图 3 RFB 协议

RFB 协议不太适合云计算，而适合远程协助解决问题和广播教学——老师先进入教师机并启动 VNC 软件，学生以“查看”模式登录教师机，这样学生都能看到教师机的屏幕（参考图 3）。

7. Ⅹ协议

X 协议这是由麻省理工大学开发的开源网络图形显示协议，采用的是客户机/服务器架构。基于这个协议开发的软件有 XFree86 及其继任者 Xorg，被类 UNIX 操作系统广泛采用，作为其图形桌面组件的一部分，比如 Linux 操作系统大多数采用 Xorg。X 协议的客户机/服务器模式可用图 4 表示。

X协议
图 4 X协议

X协议的客户机/服务器模式与传统的客户机/服务器不同，传统的客户机/服务器是针对用户而言的，即用户操作的计算机为客户机，远方的计算机为服务器；而X协议的客户机/服务器是针对程序而言的，即程序运行的那台计算机叫客户机，把结果输出到服务器上，服务器就是用户操作的那台计算机。

如图 5 所示，1 号、2 号和 n 号X客户机各运行一个程序，它们分别输出长方形、圆形和三角形，最终都在X服务器上显示出来。

令人遗憾的是，X 协议不传递声音，比如在 X 客户机上运行音乐播放器，而坐在 X 服务器旁边的用户是听不到声音的，不过有一些能支持声音的第三方开源项目，如 FreeNX、X2Go、LTSP 等。

利用X协议可以打造一台万能终端，即同时接入不同的云端。这一点很重要，因为在云计算时代，没有一家云服务提供商能通吃全部的云服务，一定会存在很多云端，且提供各种不同或者相同的云服务。作为用户，希望只使用一台终端。

PulseAudio 项目弥补了 X 协议不能传递声音的缺陷；开源 LTSP 项目整合了 Linux、Xorg、PulseAudio、OpenSSH 等开源软件，专门用于搭建教育培训机构和中小企业的私有云，终端不用事先安装或者固化任何软件，只要一块支持 PXE 启动的网卡即可，LTSP 的官方网站为http：//www.ltsp.org/。针对树莓派的衍生项目 http：//pinet.org.uk/，结合低廉的树莓派小主板，就能轻松搭建教学云。

NOMACHINE 公司发布的 NX 协议早期就是压缩 X11 协议并通过 SSH 安全通道传输，后来公司认为这样做不安全，从 4.0 版本开始默认采用改进的 NX 协议直接传输，当然仍然支持 SSH 安全通道，并且针对企业用户不再开源。

8. HP RGS

惠普远程图形软件（Remote Graphic Software，RGS）是一款高性能的远程图形系统，它允许用户通过标准 TCP/IP 网络访问和共享远程计算机桌面，在远程计算机上完成图形渲染，然后把渲染结果发给客户端。RGS 为客户机/服务器模式，服务器称为 Sender，客户机称为 Receiver。

典型的应用场景是：配置较高（强悍的 CPU、大容量内存、SSD、独立显卡）的远程工作站安装图形处理软件（如 CAD、SolidWorks 等）和 Sender；用户使用的瘦客户机安装 Receiver，然后运行 Receiver 软件连接到远程的 Sender，即可操作那里的应用程序（如 CAD 等）。相比其他协议，RGS 的用户体验要好很多，NASA 与 HP 实验室合作，利用 RGS 的核心压缩技术实现长距离的火星探测，证实了 RGS 绝非等闲之辈。RGS 的一些重要特性如下：

流畅支持 3D 图形。
先进的视频压缩技术（Windows 和 Linux 有效）。
支持 Windows、Linux 和 Mac OS 操作系统。
允许多个 Receiver 同时连接到相同的 Sender，轻松实现协同办公或教学。
运行同一个 Receiver 同时连接到多个 Sender。
采用惠普 Velocity 技术增强跨广域网的用户体验。
服务器上的高保真音频能通过本地喇叭播放。
本地 USB 设备能挂载到远程机器上。
本地设备允许触摸和手势输入。
RGS 发送像素而非数据，因此，无论你在使用什么应用，RGS 都可正常运行。
可自动进行分辨率和多显示屏设置，以匹配客户端设备。

RGS 的应用领域有桌面虚拟化、远程演示、移动办公、协同办公、教学/培训等。

综上所述，在局域网内做比较，从用户体验方面来看：RGS 最好，PcoIP 协议要优于 HDX 协议，HDX 协议又优于 RDP 8.0（Ericom 公司改进了 RDP 8.0，并且终端可以直接采用浏览器），但是 RDP 10 有了很大改进，RDP 10 要好于 SPICE 协议，X 协议和 RFB 协议似乎垫后。

从架构复杂性方面来看：

采用 RDP 组建的云计算系统最简化，产品单一、软件许可证单一，小到一台计算机即可做云端，甚至可做服务全球的云端。
采用 LTSP 开源项目搭建简单云端比较容易，而且全部是开源软件，但是缺少 Windows 上一些流行的应用软件（如 Photoshop、MicrosoftOffice 等），如果做类似 iPad 的深度定制化，则是一个不错的方向，Raspi-LTSP 是一个替代项目。
采用 SPICE 协议建设的云端复杂度较高，虽然可以全部采用开源软件，但必须具备一支技术水平相当的建设团队。
而采用 HDX 和 PCoIP 协议组建的云计算系统架构复杂，管理也复杂。

全部使用微软产品的应用环境使用 RDP 协议较合适；需要支持多种桌面操作系统的企业会发现 Citrix 的产品更加适合；如果希望通过使用瘦客户端或零客户端设备作为 VDI 解决方案的一部分，那么选择 PCoIP 技术可能更适合；局域网内的富图形处理业务选择 RGS 较明智。

总之，技术变化很快，各种协议都处于快速的发展变化之中，现在比较的结果与数月后的比较结果可能会有所不同，而且还可能有新的协议不断诞生。具备一定技术实力的公司可以在开源协议（SPICE、X、RFB）方面深入发展，并做出全部采用开源软件的云计算方案，这应该具备良好的发展前景。

云计算安全性：从云计算架构、数据生命周期和数据安全3个方面介绍

信息安全的首要目标是保护我们的系统和应用所处理的数据资料。随着单位组织陆续把应用迁移到云端，甚至是迁移到几年前不可想象的外部或公共云端，传统的数据安全措施面临巨大挑战，随“云”而来的资源弹性、多租户、全新的物理和逻辑架构及抽象层控制，迫切寻求新的数据安全策略。

在云计算时代，如何安全地管理信息是所有组织不得不面临的一项艰巨任务，即使那些暂时还不用云计算的机构也不例外。管理信息具体包括内部数据管理、云迁移，以及被分散于多个单位组织的应用和服务中的数据的安全保障。信息管理和数据安全在云计算时代需要新的战略和技术架构。幸运的是，不仅用户拥有需要的工具和技术，而且迁移到云端后，数据还能得到更好的保护。

建议采用数据安全生命周期来评估和定义云端数据的安全策略，在制定明确的信息治理策略的基础上，通过诸如加密和专门的监测手段等关键技术来增强其安全性。

云信息架构

不同的云服务模式具备不同的云信息架构。无论是私有还是公共 IaaS 云服务模式，通常包括下面的存储。

1）原始块存储

存放数据的物理介质，如磁盘、光盘、磁带等。在一些特定的私有云中，这些物理介质能被直接访问。

2）卷存储

包括被附加到 IaaS 实例的卷（如虚拟硬盘驱动器）。在存储后端，卷通常被打散存储以增强可靠性和安全性。卷不同于磁盘分区，磁盘分区是对一块基本的磁盘进行逻辑划分。

比如从 101 柱面到 10000 柱面划为一个分区，从 10001 至 50000 为另一个分区，因此一个分区的容量不可能超过磁盘的容量。而卷是在整合若干存储介质（如硬盘、分区、U 盘等）的基础上进行逻辑划分，因此一个卷允许跨越多个磁盘。

3）对象存储

通常指文件存储。不像虚拟机硬盘这种块设备，对象存储更像文件共享服务。

4）内容分发网络（CDN）

对象存储中的内容被分发到离用户最近的地方，以便增强终端用户的网络体验。

块存储、卷存储、对象存储和CDN的逻辑关系如图 1 所示。

图 1 块存储、卷存储、对象存储和CDN的逻辑关系

PaaS 云服务在对外提供存储服务的同时也要消耗存储空间。PaaS 能提供的存储服务主要有数据库服务、Hadoop/MapReduce 大数据服务，以及应用存储（被整合到 PaaS 应用平台且通过 APIs 访问的其他存储）服务。而 PaaS 消耗的存储空间包括：

数据库：信息内容被直接存储在数据库中（作为文本或二进制对象）或者被数据库表字段所引用的文件中，而数据库本身可能是共享后端存储的 IaaS 实例集合。
对象/文件存储：只能通过 PaaS API 访问。
卷存储：数据被存储在附加给 IaaS 实例的卷中，但这些数据专门供应 PaaS 云服务。
其他存储：不属于上述三类的其他存储。

类似于 PaaS 云服务，SaaS 云服务也提供和消耗各种存储服务，SaaS 云服务提供的存储服务一般通过基于 Web 的用户接口或者 C/S 模式的客户端访问，这点与通过 API 访问的 PaaS 云服务的存储服务不同，不过很多 SaaS 云服务提供商也对外提供 PaaS API 访问接口。

SaaS 云服务可能提供的存储服务包括：

信息存储和管理。比如现在流行的网络硬盘就是这类存储。
内容/文件存储。专门存储基于文件的内容，如网络相册等。

而 SaaS 云服务消耗的存储包括：

数据库。类似于 PaaS 云服务，绝大多数 SaaS 应用程序要依赖后端的数据库服务，甚至是文件存储服务。
对象/文件存储。文件和数据被保存在对象存储中，专门供应 SaaS 应用程序。
卷存储。数据被存储于附加在 IaaS 实例的卷中，并且专门供应 SaaS 应用程序。

云信息架构如图 2 所示。

图 2 云信息架构图

数据打散存储

数据打散存储是一种增强数据安全性的技术，它与加密技术不同，通过对数据分片，每个分片以多个副本的形式分散存储在不同的服务器上，以冗余存储换取数据的高可用性和高可靠性。

目前绝大多数云服务提供商都采用了这种方法。例如，一个 500MB 的文件被划分为 5 个片，每片 3 个副本，一共 15 个片，被分散存储在多台服务器上，这样即使部分服务器损坏，文件也仍然不会遭到破坏。当用户读文件时，读取 5 个分片重新“组装”为一个完整的文件。数据打散存储结合加密技术，将会使数据的安全性得到进一步提高。

数据安全生命周期

尽管信息生命周期管理是一个相当成熟的领域，但是它并不能完全满足安全专家的要求，为此，人们提出了数据安全生命周期的概念。

数据安全生命周期从创建到销毁共六个阶段，如图 3 所示。一旦被创建，数据可处于任何一个阶段，也允许跨到任何一个阶段，也可能不经过全部的六个阶段（比如，并不是所有的数据最后都要销毁）。准确跟踪你的数据处于数据安全生命周期的哪个阶段，是进行敏感数据保护的前提，同时能帮助你确定在哪里应用安全控制措施。

图 3 数据安全生命周期

1）创建

在第一阶段，人们创建结构化或非结构化的数据，如微软办公电子文档、PDF 文件、电子邮件、数据库中记录或者图片文件。通常在此阶段，根据企业的数据安全策略对新产生的数据进行密级分类。

2）存储

一旦创建了一个文件，它就被保存在某个地方。此时，你要确保存储的数据受到保护，同时应用了必要的数据安全控制措施。通过有效保护你的敏感数据，可以减少信息泄露的风险。本阶段通常与创建动作几乎同时发生。

3）使用

一旦一个文件被创建并存储，那么随后可能将被使用。在这个阶段，数据被查看、处理、修改并保存。此时，在使用数据的过程中需要施加安全控制——你要能够监控用户活动并应用安全控制措施，以确保数据不被泄露。

4）共享

数据经常在员工、客户和合作伙伴之间共享，因此必须要持续监控存储中的敏感数据信息。数据在各种公共的和私有的存储、应用程序和操作环境之间移动，并且被各个数据所有者通过不同的设备访问，这些情况可能会发生在数据安全生命周期的任何一个阶段，这就是为什么要在正确的时间引用正确的安全控制的真正原因。

5）归档

数据离开生产活动领域并进入长期离线存储状态。

6）销毁

采用物理或者数字手段永久销毁数据，物理手段如硬盘消磁，数字手段如加密切碎。

数据安全

数据是否完整、数据是否泄密、数据是否一致都属于数据是否安全的范畴。数据不完整是指在违背数据主人意愿的前提下，数据全部丢失或者部分丢失，数据所有者主动删除数据不属于数据不完整。数据泄密是指他人违背数据所有者的意愿而从数据中获取信息。下面几种情况不属于数据泄密：

1）从网上下载的免费的并保存在计算机中的电影被他人复制了，因为你不是电影的所有者。

2）用 AES 加密过的一份个人文档被他人复制了，因为他人无法解密，从而无法获取里面的信息。

3）一个没有加密的保存重要文档的 U 盘掉到大海里了，他人获得U盘中信息的概率可忽略不计。

4）网上银行的密钥卡丢了。

5）我主动把一份重要的方案材料传给客户。

上面的例子中，（2）表明他人虽然复制了经过 AES 加密的文档，但如果没有密码，他是无法解密的，因为就算是使用当今最快的计算机进行暴力破解，也要花上一百多年的时间。（3）表明掉到大海里的U盘算是彻底损毁了，谁也得不到它，更不用说获取里面的信息了。在（4）中，网上银行的密钥卡丢了，就算别人捡到了，也无法操纵我的账户，因为他不知道我的网银账户和登录密码。其他两个例子更容易理解。

数据一致性是指数据没有错乱，能从中获取到这些数据所蕴含的全部信息。为了理解数据完整性和一致性的区别，请看下面的例子，如图 4 所示。

图 4 完整性和一致性

如果把数据比作毛线，那么图 4 左侧的毛线就表示数据是完整的而且是一致的；中间的被使用过的毛线团表示数据是不完整的但是是一致的；而右侧乱糟糟的毛线就表示数据是不一致的，很难从中抽出一根完整的毛线来，比如明显看到文件在硬盘里，但就是打不开，或者打开后显示乱码，这就是数据的不一致。

那么，数据放在云端和放在本地到底哪个更安全呢？结论如下：

数据放在云端比放在本地更安全。

原因如下。

1. 数据完整性方面

云端通过采用服务器集群、异地容灾和容错等技术，可保证数据万无一失，采用数据快照回滚技术，能最大程度降低用户误删数据的损失，所以云端的数据丢失的概率极低；相反，如果数据保存在本地（计算机硬盘、U 盘、光盘、SD 卡、磁带等），这些存储介质都很容易损坏，另外没有任何措施可防止用户误删数据，现在的数据恢复公司业务火爆就充分说明了本地数据丢失的普遍性。

2. 数据泄密方面

使用密码是目前最常用的防止数据泄密的方法，无论是云计算，还是使用本地计算机，都是如此。比如打开计算机，输入账号和密码登录，然后再输入密码登录 QQ、输入密码登录微博、输入密码登录邮箱、输入密码登录云等。另外，也有采用密码加密文档的，如密码保护的 Word 文档、压缩包等。

在当下云计算还不普遍的情况下，因为本地的存储介质（如硬盘、U 盘、SD 卡、手机、光盘等）丢失而导致数据泄密的概率占到 70% 以上，而其他诸如通过网络泄密的概率不到 30%。因此，把数据保存在云端，可以消除因丢失存储介质而泄密的可能性。另外，就算不用云计算，也存在网络泄密的可能性，除非你的计算机不连接网络。

云服务提供商会采取各种防范网络泄密的措施，如防火墙过滤、入侵检测、用户行为异常分析、泄密预测等高精尖技术，个人用户计算机是不可能花费巨资购买这些设备和技术的。

最后，对于一些敏感的数据资料，用户如果实在不放心，还可以先加密，然后再保存到云端，常用的加密工具有 VeraCrypt、AxCrypt、BitLocker、7-Zip 等，也可以对 IaaS 存储产品（如虚拟机硬盘）全部加密处理。

3. 数据一致性方面

数据没有错乱，没有遭到破坏，能正常打开和使用，这一点很关键。用过计算机的人应该都有过这样的经历：不正常关机（如突然停电、不小心按下计算机的电源开关或复位开关等）后重新启动计算机，报告硬盘文件遭到破坏需要修复，好不容易修复并启动完毕，发现之前辛苦几天编辑的 Word 文档打不开了，这就是各种干扰因素破坏了数据的一致性。

放在云端的数据一致性遭到破坏的概率要远远小于本地计算机，原因很简单，云端环境更可靠：机房恒温恒湿、多级电力保障、阵列存储系统、异地灾难备份中心、安全防范措施全面、计算机专业人员维护等，这些措施使得数据不一致的概率几乎为零。

云计算的可靠性（可用性）如何？

前面我们讲过 IT 的概念，即信息技术，其中“I”代表信息（或数据），“T”代表技术（或计算），技术是用来处理信息的，所以说 I 是目的，T 是手段，T 是为 I 服务的。

《云计算安全性》教程中关注的是 I，本节我们再来看看 T，与 T 关联的安全主要是“计算可用性”，如果由于 T 的原因，人们无法处理 I，那么这种情况就称为计算不可用。

首先来看下面几个计算不可用的例子：

停电，计算机无法开机，所有的计算机软件都无法使用。
操作系统损坏，计算机启动失败，保存在 U 盘上的数据完好无损，但是无法浏览和编辑。
别人传了一个 PPT 文件给我，但是计算机上没有安装 Office 办公软件，所以我无法打开这个 PPT 文件。
网络断了，无法通过 QQ 与外界联系，也无法上网和收发邮件。
音箱坏了，而且没有耳机，所以无法使用计算机看电影。
我忘记了公司 ERP 的登录密码，所以无法使用财务系统。

计算不可用会导致人们无法处理全部或者部分数据，而断电、断网、软/硬件故障、缺少应用软件、忘记账号或密码等都会导致全部或部分计算不可用。

相对于传统 IT 系统而言，云计算的确增加了一个可能产生故障的环节——云端，而且一旦云端崩溃，影响范围会很广，但不能因此而全盘否定云计算，因为世上根本就没有完美无缺的事物。

一个公安局长在否决私有云建设方案时说的一句话：“万一云端出问题，大家都不用办公了？！”从正面回答公安局长的问题，估计效果不大，可以顺着其思路提出如下类似的问题：

万一银行的数据中心出问题，大家都不用取钱了？！所以银行不应该建立数据中心，但目前银行都建立了数据中心并实现了数据大集中。
万一电厂出问题，所有的电器设备都不能用了？！所以家家都要自备发电机发电，但今天谁会自备发电机呢？
万一移动公司的数据中心出问题，大家都不用手机了？！但目前几乎人人都在用手机。
万一自来水厂出问题，大家都不用水了？！尽管存在这种断水的可能性，但哪家还会自挖水井呢？
万一地球发生爆炸，大家都不用活命了？！所以人根本不应该活着，而实际情况是活着的我们有谁总担心地球发生爆炸呢？

类似的问题还有很多，不再一一列出。我的一个好朋友从 1994—2002 年在银行工作，从事计算机技术岗位，见证并参与了银行从完全手工办理业务（算盘、手写存折）到全国数据大集中并实现网上银行的整个发展过程。1996 年以前，人们只能到开户行去存取款；而今天，我们不但能异地跨行存取款，而且坐在家里通过网上银行就能轻松实现支付和转账。总之，银行数据大集中利大于弊。

为了确保银行数据中心的可靠性，每家银行一般会在不同城市（如北京、上海和西安）各建一个中心，平时一个中心工作，另外两个作为灾备中心，三个中心的数据实时同步更新。这样，就算战争、地震等损毁了两个中心，也不会影响银行业务的正常办理。即使三个中心全部遭到破坏，也还有离线备份的数据，数据安全性绝对没有问题。

决策者和云计算工程师们会在计算的重要性和成本之间综合权衡，以建设一个令各方都满意的云端。

例如，一个全国性的关系到每个人利益的公共云，就会考虑在不同的城市建立灾备云端，在另一个国家建立数据备份中心；一个涉及全省的公共云，可能会考虑在其他省的城市建立数据备份中心；一个世界500强企业的私有云，可能会建立一个异地灾备云端；一家中型企业的私有云，可能会引入集群、容错和故障转移技术；即使一家只有十几个人的小型公司的私有办公云，也会采用双机容错技术，只有当两台服务器同时出现故障时才会影响办公，但同时出现故障的概率几乎可以忽略不计，除非发生断电或地震等不可控事件。

就像银行数据中心的演化过程，IT 系统也遵循“手工→单机→私有云→公共云”的发展过程，每一次演化带来的好处要远远大于引入的弊端。

即使没有使用云计算的企业，在其 IT 系统中，也存在不少“单点故障”——一出问题就会影响整个企业的业务办理。比如企业的邮件系统、门户网站、ERP 系统、文件服务器、局域网接入认证系统等，即 C/S 或 B/S 的 S 端（服务器端）就是单点故障点。导致计算不可用的主要原因有停电、断网、硬件故障、软件故障（含病毒感染）。

在传统 IT 系统中，个人计算机的软、硬件故障导致计算不可用的概率接近 95%，其中又以软件故障最为普遍，而因停电、断网导致计算不可用的概率微乎其微，服务器故障导致计算不可用的概率还不到 5%。而当一家企业采用云计算后，云终端是一个纯硬件、低功耗产品，而且 CPU、内存都焊死在主板上，又没有硬盘，所以云终端出故障的概率几乎可以忽略不计。

云端采用多路供电、恒温恒湿系统，引入集群技术、容错技术及负载均衡技术等措施确保计算持续可用，这样由云端、网络、终端组成的云计算系统具备极高的可靠性和安全性，计算可用性非常高。

云计算的互操作性与可移植性如何？

不同于传统的位于单位组织内部的 IT 基础设施，云计算的诞生给单位组织的 IT 资源供给带来了前所未有的灵活性——可以瞬时增加、转移或者减少计算资源来快速响应动态的资源需求变化，能在几个小时而不是几周内部署一个新的应用来满足业务需求。

为了达到这种更具弹性的计算能力，在设计任何云系统时必须要考虑互操作性与可移植性。

互操作性规定，IT 系统中应用软件层以下各层采用开放的通用型组件，杜绝使用云服务提供商各自内部的封闭组件。
可移植性规定，IT 系统中应用软件层和数据信息层应采用开放的通用数据格式和软件运行环境，保证同一个应用和数据能随意迁移到其他地方。

一方面，互操作性与可移植性能让你把服务扩充到多个由不同云服务提供商提供的云端，在操作层面就像一个系统；另一方面，互操作性与可移植性能在不同平台或者不同云端之间轻松移动数据和应用。

互操作性与可移植性不是随云计算出现而产生的新概念，也不只是在云计算环境中人们才考虑互操作性与可移植性，只不过与传统 IT 系统相比，具备开放和共享处理能力的云计算更需要考虑互操作性与可移植性。多租户意味着多个单位组织的数据和应用并存，并且不排除能通过共享平台、共享存储和共享网络访问（有意或无意）他人机密数据的可能性。

下面重点介绍在设计互操作性与可移植性时必须考虑的关键因素。

互操作性

互操作性是云计算生态系统中各个协同工作的组件应具备的特征，这些组件可能来自各种云端和传统 IT 系统。互操作性使得我们可以随时使用新的或者来自不同云服务提供商的组件来替换已有的组件，而不会中断云中的任务，也不影响数据在不同系统之间进行交换。

单位组织在使用云服务的过程中可能会考虑更换云服务提供商，常见的原因如下：

续签合同时，云服务提供商的报价令消费者难以接受。
消费者发现有价格更便宜的同类型云服务产品。
云服务提供商停止了业务运营。
云服务提供商在没有给出合理的数据迁移计划之前，关停了企业正在使用的服务。
云服务提供商的服务质量难以令消费者满意，如未能达到服务水平协议（SLA）中规定的一些关键性能指标。
云服务供/需双方之间存在商业纠纷。

如果缺少互操作性（与可移植性），就会出现消费者被云服务提供商捆绑的现象，最终会损害消费者的利益。

一个云端互操作性的优劣程度往往取决于该云服务提供商是否使用开放的或者公开发布的架构和标准协议及标准的 API 接口。许多云服务提供商（如 Eucalyptus）喜欢在标准组件的基础上添加非公开的钩子和扩展，以及一些增强功能，显然这些都会降低互操作性与可移植性。

可移植性

可移植性是指能把应用和数据迁移到其他地方而不用理会云服务提供商、平台、操作系统、基础设施、地点、存储、数据格式或者 API 接口如何。

在选择云服务提供商时，可移植性是需要考虑的一个重要方面，因为可移植性既能防止云服务提供商锁定客户，又允许我们把相同的云应用部署到不同的云服务提供商那里，如建设灾备中心、同一应用全球分布式部署等。

如果未能妥善解决云迁移中的可移植性与互操作性，那么可能会无法实现迁移到云计算后的预期效益，并可能导致成本上升或项目延期，这是因为本该避免而未能避免的如下因素：

1）云服务代理商或提供商锁定——一个特定的云解决方案的选择可能会限制以后转移到另一个云服务提供商。

2）处理不兼容和冲突造成服务中断——云服务提供商、云平台和应用的差异可能会引发不兼容性，这种不兼容性会导致应用系统在不同的云基础架构中发生不可预料的故障。

3）不可预料的应用系统重新设计或者业务流程更改——当迁移到一个新的云服务提供商时，可能需要重新审视程序的功能或者要求修改代码，以确保其最初的执行行为。

4）高昂的数据迁移或数据转换成本——由于缺乏互操作性与可移植性，当迁移到新的云服务提供商时，可能会导致计划外的数据变化。

5）数据或应用程序安全的丧失——不同的云服务提供商可能采用不同的安全控制、密钥管理或者数据保护策略，当迁移到一个新的云服务提供商或云平台时，可能会暴露原先未被发现的安全漏洞。

把应用迁移到云端是外包的一种形式，而外包的金科玉律是“了解前期并做好如何退出合同的计划”。因此，可移植性（和在一定程度上互操作性）应该是任何单位组织计划迁入云端时必须考虑的关键标准，同时开发好一个切实可行的退出方案。

实施建议

1. 关于互操作性方面的建议

1）物理计算设备

同一个云服务提供商在不同时期的硬件或者同一时期不同云服务提供商的硬件差别很大，如果直接让消费者访问硬件设备（如物理服务器），则会存在巨大的互操作性鸿沟。建议：

尽可能采用虚拟化来屏蔽底层硬件的差异，但是要注意虚拟化并不能屏蔽全部的硬件差异，特别是目前的系统。
如果消费者必须要直接访问硬件，那么从一个云服务提供商迁移到另一个云服务提供商时，选择相同或更好的物理硬件和管理安全控制就显得至关重要。

2）物理网络设备

不同的云服务提供商使用的网络设备（包括安全设备）也不尽相同，包括它们的 API 和配置流程也不尽相同。为了保证互操作性，网络硬件设备应该虚拟化，并尽可能使得 API 具备相同的功能。

3）虚拟化

虽然虚拟化有助于消除物理硬件的差异，但是常用的虚拟机管理程序（如 Xen、VMware、KVM 等）之间存在明显的差异。建议：

利用开放虚拟化文件格式，如 OVF，以确保互操作性。
了解并记录使用了哪些特定的虚拟化扩展钩子（Hook），虽然这些钩子与虚拟化文件格式无关，但是仍然存在这种可能性：在其他虚拟机管理程序中不起作用。

4）框架

不同的平台提供商提供了不同的云应用程序框架，而且这些框架之间确实存在影响互操作性的差异。建议：

在迁移到一个新的云服务提供商时，先搞清楚API的不同之处，然后拟定修改应用系统的计划。
使用公开发布的API以保证各组件之间具备最佳的互操作性，为了便于迁移应用和数据，有时很有必要变更云服务提供商。
云端的应用系统一般通过因特网交互，可能随时发生各种故障（如组件运行失败、网络中断等）。

我们要做的是，确定一个组件发生故障（或反应慢）将如何影响其他组件，而且当一个远程组件出现故障时，要尽量避免可能会破坏系统的数据完整性的状态依赖——依赖另一个组件对数据的修改。

5）存储

数据类型不同对存储的要求也不同，结构化数据通常保存在关系数据库系统中，非结构化数据通常是按照应用程序（如微软的 Word 文字处理程序、Excel 表格程序和 Powerpoint 程序）所要求的格式存放。为了无缝地在不同云服务提供商之间移动数据，建议如下：

以一个被广泛接受的可移植的格式存放非结构化数据。
评估数据在传输过程中是否需要加密。
检查各种兼容的数据库系统，如果需要，再评估不同数据库之间进行数据移植的难易程度。

2. 关于可移植性方面的建议

把应用迁入云端的过程中会遇到很多问题，在可移植性方面的建议如下。

1）服务水平

不同云服务提供商的SLA也不同，所以有必要了解清楚SLA会如何影响你将来更换云服务提供商。

2）不同的架构

云中的应用系统可以驻留在不同的平台架构中。通过了解应用与平台的依赖性，我们就能搞清楚这些（包括API、虚拟机管理程序、应用程序逻辑等）将如何影响可移植性。

3）安全集成

在维护安全性方面，云系统引入了独特的可移植性担忧，具体包括：

现在云系统中的所有组件都会使用认证和身份机制，使用诸如SAML这种开放标准的身份机制将有助于提高可移植性，开发遵循SAML协议的内部IAM系统有助于系统将来移植到云中。
加密密钥应该托管在本地，并尽可能地在本地维护。
元数据是数据信息的一部分，但经常容易被忽视，因为我们在操作文件和文档时不能直接看到元数据。在云端，我们必须重视元数据，因为元数据随着文件一起移动，当移动文件和文件的元数据到一个新的云端时，要确保安全地删除了源文件元数据的全部副本，否则遗留下来的元数据可能会成为一个安全隐患。

用户自由度

互操作性与可移植性都是为了保障用户能自由使用云服务，这里的“自由”体现在以下几方面。

1）用户可以自由地迁入、迁出云计算，不花或者花费很少的时间和金钱成本。

2）用户能自由访问其他云应用：每个云端都是开放的，在这个云端中的用户能访问其他云端中的应用和资料。坚决杜绝运营商出于利益的考量封闭自身的云应用来黏住用户。

3）用户能自由选择云服务提供商：买方能自由选择卖方是完全竞争市场的一个重要特征。为了保证自由度，政府应该努力营造完全自由竞争的云计算市场，坚决打击运营商“捆绑”用户的不正当竞争行为。

4）用户能自由地把应用和数据从一个云服务提供商迁移到另一个云服务提供商：云端保存了用户的资料并安装用户需要的软件，当用户想更换云服务提供商时不应该存在障碍。扫除人为的障碍，杜绝不兼容性。所以，政府应该制定合理的云计算标准，并提供简单易用的迁移工具。

5）云服务提供商能自由选择云组件：云服务提供商搭建云端，涉及很多技术和软/硬件产品，规划之初就要充分考虑伸缩性、开放性、标准性，杜绝被组件产品厂商捆绑。现在的很多云服务提供商热衷于采用开源的软/硬件产品，这是对的。

6）云终端可以自由接入任何云端：一台终端设备成为人们的云计算总出入口。

云计算的加密与密钥管理详解

“如果你不信任他们，你就把数据加密。”这是数据安全专家常常挂在嘴边的一句话。部署在企业内部的数据中心，由于单位组织完全控制全部的软/硬件设备，所以数据要不要加密由企业规章制度界定。

但是在云端，多个互不认识的租户共用计算资源，每个租户需要加密的数据自然就更多，需要加密的数据越多，业务流程越复杂，密钥管理也就越繁重。所以，在实际的操作过程中，我们要综合考虑各个因素，制定出一套既满足安全要求又不大幅度增加加/解密和密钥管理的工作难度的方案。

加密介绍

根据企业的规章制度，某些数据被列为机密并必须要加以保护，当前存储在企业内部的机密数据开始被陆续迁入云端，所以数据保护的力度必须要加大。把机密数据存储在企业的安全边界之外，这增加了数据保护的复杂度，同时也增加了风险系数。

关于云端的数据加密，以下因素必须慎重考虑。

1）不单单在传输过程中需要加密保护，在云端存储和使用数据的过程中也依然需要加密保护。

2）存储在云端并被共享的非结构化数据文件保护方法有以下两种：

采用授权服务器进行集中加密；
加密直接被嵌入到每个文件当中（分散加密）。

当使用经第一种方法加密的文件时，首先要联系授权服务器进行解密，比如微软的 Word 文字处理软件会自动联系服务器并完成身份验证和解密工作。

3）加/解密的密钥的管理期限就是数据的整个生命周期，在数据被销毁之前如果密钥丢失，则会导致数据无法解密。另外，对于密钥的保护和正当使用，要尽可能避免依赖云服务提供商。

4）保护那些经常被忽视却又包含敏感信息的文件，比如日志文件和元数据如果不加以保护，那么很可能成为数据泄露的途径。

5）云端的加密密钥应具备足够的强度（如 AES-256），且与同一单位组织内部的加密密钥一致。提倡使用开放的且经过验证的加密格式，尽可能避免使用特有的加密格式。

云端数据库加密

首先考虑数据要不要加密，因为加密数据会提高成本并使得业务处理复杂化。目前几乎所有的数据库都具备权限管理机制，如果配置得当，数据库管理系统本身就能很好地保护敏感数据。如果遇到下面 3 种情况，那么我们就不得不对数据库中的记录进行加密了：

不想让有权限的人（如数据库管理员）看到记录信息。
法律规定一些记录必须要加密（如交易记录中的信用卡信息）。
数据存储在数据库的一个 Schema 中，但是数据的主人无法控制访问这些数据的账号（比如多人使用的共享账号，每个人都不能随意修改账号密码）。

当人们使用云端数据库，尤其是 SaaS 应用（该应用需要使用数据库）时，如果数据库不能操作加密的数据，那么数据库的功能会大打折扣。当然，前提是数据库管理系统或者应用能够访问密钥。

数据加密是以提高复杂度和降低性能为代价的，下面是一些替代的方法。

1）使用数据库本身的对象安全机制

数据库中的表、视图、存储过程、函数等统称为对象，对这些对象的访问，数据库管理系统本身提供了一套权限管理机制，诸如账号、分组、角色、授权、撤权等。要严格控制那些被授权的账号，确保这些账号只分配给正确的人。

2）存储安全哈希值

只存储数据的哈希值，而不直接存储数据本身。这使得你的应用程序能证明持有正确哈希值的人就是持有正确数据的人，因为数据与哈希值是一一对应关系，即 hash（data）=x，把 x 存储在数据库中，而 data 存储在另外一个私密的地方，从 x 是无法反算出 data 的。

密钥管理

无论是采用对称加密算法还是采用非对称加密算法，密钥的管理都是重中之重，尤其是对于多租户模式的公共云端来说，密钥管理是一个比较繁重的任务。

最简单的案例是应用在云端运行，而只在企业内部使用密钥对迁移到云端的数据进行加密——在企业的网络安全边界部署一个加密引擎，只要通过这个加密引擎，那么离开企业的数据就会自动加密，而进入企业的数据则会自动解密。

而下面这种情况会把事情搞得很复杂：如果一个使用密钥的应用又包含其他需要使用密钥解密数据的进程（如一个批处理应用可能包含很多进程），且这些进程又驻留云端，那么此时的密钥需要离开企业内部的网络安全边界而进入云端。

企业一般为每个需要加密功能的实体（用户、设备、进程等）分配单独的密钥，这样就不用共享一个密钥，从而避免带来很多隐患。

为了管理众多的实体密钥，最简便的方法是部署一个基于身份的密钥管理中心，从而使得为一个具体实体加密的任何数据只对该实体本身有效。如果同一个组的成员确实需要共享数据，那么可以给该组分配组级的密钥，同组成员共享组级密钥。正如前面所提到的那样：密钥的管理必须局限在企业内部。

如果数据存储在公共云环境中，那么在退出这个环境时，需要确保所有的数据（特别是 PII、SPI 数据或受到监管的数据）已经从公共云环境中删除，其中包括其他存储介质（如备份磁带）上的数据。本地管理密钥的做法很容易实现这个目标：只要从本地密钥管理中心删除相应的密钥即可，从而保证残留在公共云的任何数据再也不能被解密。

如果云服务提供商和消费者不严格执行各自的密钥管理流程，那么数据加密就没有什么实际意义。比如云服务提供商，如果职责混乱，大家可以随意访问密钥服务器和存储了加密数据的服务器，或者 DBA 能随意访问数据库中的个人密钥，那么数据加密就形同虚设。

同样，比如云服务消费者，如果存储密钥的终端设备本身就不安全（如移动设备）或者没有达到与加密系统同等安全级别的终端设备，这就像用木板做保险柜，那么这时加密数据无疑也是形同虚设。

围绕如何保护密钥本身，方案设计师通常的做法是采用密钥来加密密钥，只在内存中产生有效密钥，并且只存储加密过的密钥。这理解起来有点绕，其实就是把密钥当作普通的数据再次进行加密。

国内外主流云服务提供商有哪些？

前面讲到，经营云端的公司应具备更多的投入和技术以保证其安全性，但是一个真正落地的云端能不能达到理想的安全级别，还要看云端运营公司的声誉、品牌、技术实力，以及当地政府的监管力度。

欧美国家的云服务提供商普遍好于国内的公司，其资金雄厚、技术实力强、品牌声誉好。选择一家技术过硬、实力雄厚、信誉良好、服务到位的云服务提供商很重要，因为云服务不是一次性买卖，供需双方需要长久合作。

为了搞清楚一家云服务公司的产品线，我们首先要理解一个传统数据中心的组成，否则很难搞清楚一家云服务提供商提供的众多产品线的作用和它们之间的关系。

传统的数据中心由若干个局域网、一定数量的服务器、若干存储设备、一些负载均衡器、入侵检测设备、域名服务、数据库服务、DNS 服务、DHCP 服务、邮箱系统、门户网站、目录服务、用户身份认证和权限管理服务、文件服务、虚拟办公桌面等组成。如果一家云服务公司能全面接管一家企业的数据中心，而这家企业只需摆放云终端和出口宽带设备，那么这家云服务公司的产品线是最全面的。

截至 2015 年，云服务提供商以美国企业为主。中国云服务提供商发展迅速，而且绝大多数的云服务提供商提供 IaaS 和 PaaS 类型的云服务，而紧贴人们生活的 SaaS 类云应用不多。下面简单介绍一下目前一些典型的云服务提供商。

1. 亚马逊 AWS

亚马逊刚开始是做电商的，购买了一批服务器搭建电商平台，由于服务器具备富余的计算资源，于是其考虑对外出租这些资源，从此开展了云计算业务并越做越大。现在，亚马逊算是世界上最大的云计算服务公司，产品线丰富，具体包括如图 1 所示的云服务。

图 1 亚马逊AWS

图 1 中右侧就是亚马逊公司提供的云计算服务产品线，涵盖了 IT 系统架构的各个层次，加上另外几个部署和运维产品，一个企业的数据中心可以采用亚马逊云计算服务产品来完全替换。亚马逊公司最核心的云服务产品是主机（EC2）和存储，其他是增值产品或者支撑产品。

一台主机（EC2）就是一台供用户租用的虚拟服务器或者物理服务器，属于 IaaS 类型。亚马逊目前提供几十种不同的主机类型供用户选择，主要是 Windows 和 Linux 各版本。用户可以根据实际应用的计算需求来选择不同主机的种类和数量，并可以在数分钟内构建起自己的计算环境。

虚拟桌面（WorkSpaces）就是一个基于云的桌面虚拟化服务，是传统 VDI 方案的一种基于云计算的实现方式，用户可以使用诸如个人计算机、平板电脑、Kindle 和 Android 平板等各种终端设备通过网络访问虚拟桌面，但要首先安装一个相应的小客户端软件，采用 PCoIP 通信协议。只要网速满足要求，用户就可以用任何设备在任何地点接入远程桌面，真正实现移动办公。

软件流（AppStream）将软件界面直接显示到云终端屏幕上，不同于 WorkSpaces 把整个电脑桌面显示到终端上，AppStream 只把运行在亚马逊服务器上的软件界面显示到终端屏幕上，与其他软件界面（无论是本地还是云端的软件）一起整合到本地桌面上。

最终的结果就是，用户的云终端屏幕上同时显示多个软件的界面，而这些软件有的是 Windows 软件，有的是 Linux 软件，有的是 Mac 软件，还有的可能是 Android 软件。有的运行在亚马逊，有的运行在私有云端，有的运行在本地。

亚马逊的 AppStream 与微软的 RemoteApp、思杰的 XenApp 及 VMware 公司的 ThinApp 互为竞争产品。AppStream 特别适合那些需要大量计算资源而操作终端又需要多样化的软件，如跨平台的多人游戏、图形渲染、生命科学研究等软件，如图 2 所示。

图 2 AppStream

2. 微软Azure

微软云端的技术绝大多数是自己的，如 Windows 操作系统、SQL Server 数据库、Office 办公软件、活动目录等，优点是架构简洁、综合成本低，但是缺点也很明显，即开放性有待提高，目前虽然引入了 Linux、Hadoop、Eclipse 等开源产品，但还远远不够。微软 Azure 云服务产品线如图 3 所示。

图 3 微软Azure