《云计算的数据安全》由会员分享，可在线阅读，更多相关《云计算的数据安全（5页珍藏版）》请在金锄头文库上搜索。
1、云计算的数据安全本文从数据隐私和数据隔离两个技术角度，对云计算中的数据安全进行了阐释和剖析。与传统的软件架构相比，云计算在运营和支持方面的成本更低廉，同时又能够获得更快速的部署能力和近乎无限的伸缩性等收益。尽管如此，仍然有诸多企业在云计算和传统软件架构中选择了后者，原因很大程度上在于云计算中，有关企业数据的安全问题没有得到妥善解决。一些分析机构的调查结果显示，数据安全问题是企业应用迁移到云计算的最大障碍之一。数据安全意指通过一些技术或者非技术的方式来保证数据的访问是受到合理控制，并保证数据不被人为或者意外的损坏而泄露或更改。从非技术角度上来看，可以通过法律或者一些规章制度来保证数据的安全性；从
2、技术的角度上来看，可以通过防火墙、入侵检测、安全配置、数据加密、访问认证、权限控制、数据备份等手段来保证数据的安全性。由于传统软件和云计算在技术架构上有着非常明显的差异，这就需要我们用不同的思路来思考两种架构下有关数据安全的解决方案。下面我从技术角度探讨一下云计算的数据安全。数据隐私对于任何一个 IT 系统来说，在运行生命周期过程中使用的和生产的数据都是整个系统的核心部分，而我们一般把这些系统数据分为公有数据和私有数据两种类型。公有数据代表着可以从公共资源获得的数据信息，例如股票信息、公开的财务信息等，这类数据可以被任何一个 IT 系统获得并使用。而私有数据则代表这些数据是被 IT 系统所独占
3、并无法和其他 IT 系统所共享的信息。对于公有数据，使用它们的 IT 系统并不需要处理安全相关的事务，然而对于私有数据特别是一些较为敏感的私有数据，在构建 IT 系统时需要专门考虑如何保证数据不被盗用甚至修改。传统的 IT 系统通常搭建在客户自身的数据中心内，数据中心的内部防火墙保证了系统数据的安全性。和传统软件相比，云计算在数据方面的最大不同便是所有的数据将由第三方而非第一方来负责维护，并且由于云计算架构的特点，这些数据可能被存储在非常分散的地方，并且都按照明文的方式进行存储。尽管防火墙能够对恶意的外来攻击提供一定程度的保护，但这种架构使得一些关键性的数据可能被泄露，无论是偶然还是恶意。（例
4、如，由于开发和维护的需要，软件提供商的员工一般都能够访问存储在云平台上的数据，一旦这些员工信息被非法获得，黑客便可以在万维网上访问部署在云平台上的程序或者得到关键性的数据。）这对于对安全性有较高要求的企业应用来说是完全不能接受的。尽管目前在公有云平台还没有很好的数据隐私解决方案，但是企业仍然可以选择构建私有云或者混合云来实现弹性计算和数据隐私的均衡，同时也为未来在公有云平台上的实施积累经验。从弹性计算的角度来看，私有云和公有云并无太大差别，都是通过自动化地管理虚拟化的 IT 资源来实现弹性计算。然而，由于现有的企业应用基本上都基于传统的 IT 基础架构搭建，几乎所有的 IT 资源都要求IT 工
5、程师花费大量的时间和精力来手动管理，并没有其他办法实现敏捷高效的自动化管理，因此无法满足云计算的要求。实施私有云计算的第一步也是最重要的一步便是重新搭建 IT 基础架构将现有的处理器、存储、网络等 IT 资源高度虚拟化并重新组织整合，构建高度扩展性的 IT 集群架构，辅以强大的管理软件来实现高效自动化的 IT 资源管理。整个 IT 架构可以 114 程序员搭建在企业内或者是第三方的数据中心内，但是无论私有云部署在什么地理位置，企业都拥有完全的 IT 资源控制能力。通过网络控制和独享的防火墙保护，私有云上的企业数据能够得到和传统 IT 架构下企业数据相同级别的安全保障。在主流的私有云架构之外，A
6、mazon 的 VirtualPrivateCloud（虚拟私有云，以下简称 VPC）提供了一套全新的企业级私有云构建方案。主流的私有云解决方案都致力于 IT 资源的虚拟化以及自动化管理，而 VPC则将重点放在了如何构建专门针对单个企业的虚拟网络，并与企业现有的 IT 架构安全无缝地连接起来。企业可以在 Amazon 公有云平台上创建 VPC 虚拟网络，通过企业自身的加密 VPN 将 VPC 虚拟网络与企业局域网络连接起来，并将整个 VPC 虚拟网络加入到企业现有的安全架构下。在申请创建 EC2 实例时，可以将其指定与相应的 VPC 网络绑定，在 EC2 实例启动之后，该实例也就相当于运行在整
7、个大的企业局域网之内（如图 1 所示）。虽然 VPC 网络中所有的 EC2 实例仍然位于公有云平台上，但是在这种 IT 架构下，企业内的防火墙能够保证这些公有云上的数据安全。采用 AmazonVPC 的私有云解决方案无需对企业现有 IT 架构做出大规模的调整，因此也就无法减少 IT 运营成本，但是相比主流的私有云解决方案，实施成本和风险则减少了很多。混合云则将云平台与 In-House 系统（自用系统）或者是私有云结合起来，将部分子系统搭建在企业内部的数据中心（通常这些子系统中的数据对安全性有非常严格的要求，或是一些 Legacy 系统（原有的系统），而把系统的其他部分构建于云计算平台之上（通
8、常这类子系统不带有数据安全性的问题），通过ServiceBus（服务总线）将 In-House 系统（私有云）与公有云端系统连接起来。图 2 展示了基于WindowsAzureAppFabric 的混合云系统：AppFabric 提供了 ServiceBus 的功能，私有 In-House 系统可以在 AppFabric 上创建 WCF 服务的 Endpoint 并注册，这样 AppFabric 便成为了公有云系统和私有 In-House 系统的中间平台，两个系统通过 AppFabric 来实现数据交互。由于 ServiceBus 并不存在 NAT（网络地址转换）的问题，因此并不要求企业局域网
9、防火墙开放指定的端口，各个系统都能够比较方便地访问它。在最极端的情况下只需要服务器暴露 80 或者 443 端口，也就是服务能以 HTTP 或者 HTTPS 的方式连接上 AppFabric。此外，AppFabric 还提供了 AccessControl 的功能，以支持常见的基于 AD 的身份认证。用户通过使用域账号登录，并将 Token 传给 AC 以获取相应的资源和服务。数据隔离IT 软件服务商所提供的传统企业软件系统大多基于 Multi-Instance（多实例）架构，即对于每一个客户组织，都有一个单独的软件系统实例为其服务；而搭建于云计算平台的软件系统则广泛采用了 Multi-Tena
10、ncy（多租户）架构，即单个软件系统实例服务于多个客户组织。在 Multi-Instance 架构下，由于每个客户拥有自己的软件实例，所以不存在数据隔离问题，但是在 Multi-Tenancy 架构下，由于所有客户数据将被共同保存在唯一一个软件系统实例内，因此需要开发额外的数据隔离机制来保证各个客户之间的数据不可见性并提供相应的灾备方案。随着云计算技术的成熟，Multi-Tenancy 不再是新鲜的概念，目前已经有几种成熟的架构来帮助系统实现数据隔离：SharedSchemaMulti-Tenancy（下文简称为共享表架构）、SeparatedDatabase（下文简称为分离数据库架构）以及
11、SharedDatabaseSeparatedSchema（下文简称为分离表架构）。共享表架构：即所有的软件系统客户共享使用相同的数据库实例和相同的数据库表，但可以通过类似于图 3 中的 TenantID 字段来区分数据的从属。因为共享表架构最大化地利用了单个数据库实例的存储能力，所以这种架构的硬件成本非常低廉，但对程序开发者来说，却增加了额外的复杂度。由于多个客户的数据共存于相同的数据库表内，因此需要额外的业务逻辑来隔离各个客户的数据。此外，这种架构实现灾难备份的成本也非常高，不但需要专门编写代码实现数据备份，而且在恢复数据时，需要对数据库表进行大量的删除和插入操作，一旦数据库表包含大量其他
12、客户的数据，势必对系统性能和其他客户的体验带来巨大影响。分离数据库架构：即每个软件系统客户单独拥有自己的数据库实例，如图 4 所示。相比于共享表架构，由于每个客户拥有单独的数据库实例，这种架构可以非常高效便捷地实现数据安全性和灾难备份，但是随之而来的缺点便是其硬件成本非常高昂。分离表架构：即软件系统客户共享相同的数据实例，但是每个客户单独拥有自己的由一系列数据库表组成的 Schema。分离表架构是一种折中的 Multi-Tenancy 方案，在这种架构下，实现数据分离和灾难备份相对共享表架构更加容易一些，另一方面，它的硬件成本也较分离数据库架构低。无论是分离数据库还是分离表，抑或是共享表，每种
13、架构都有它的优点和不足，在设计云端系统时，系统架构师需要进行全面的分析和考量，综合各方面的因素以选择合适的 Multi-Tenancy 架构。一般来说，系统服务的客户数量越多，则越适合使用共享表的架构；对数据隔离性和安全性要求越高，则越适合使用分离数据库的架构。在超大型的云系统中，一般都会采用复合型的 Multi-Tenancy 架构，以平衡系统成本和性能，这其中 S 便是一个典型的案例。S 最初搭建于共享表架构，但是随着新客户的不断签入，单纯的共享表架构已经很难满足日益增长的性能要求，Salesforce 逐步开始在不同的物理区域搭建分布式系统。在全局上，S 以类似于分离数据库的架构运行，在单个区域内，系统则仍然按照共享表架构运行。作者简介李季，奥博杰天技术经理，主要致力于基于 Amazon EC2 以及 Windows Azu e 平台的应用开发与研究工作。
