云上数据安全的挑战
数据是企业的生命，对数据提供必备的保护，就是保护企业的生命，因此数据安全是企业上云的刚需。
在原来传统的IT系统中，企业是将应用系统跟数据放在自己的IDC里，认为在这样的环境下其系统和硬件、数据安全是可控的。企业会花更多的成本去打造防火墙，保证逻辑上的城墙牢不可破。这就是传统的鸡蛋壳模型——在这种模型下，企业对防火墙内的数据保护是有限度和有选择的。
而如今企业上云，底层的基础设施是共享的，企业不再物理上拥有对计算设施和存储设施的全盘掌控，一切都只能交给云服务提供商。分布式多租户的架构导致鸡蛋壳模型被打破。企业虽然通过在虚拟网络中构建云防火墙来防止一些外部威胁，但是云服务的本质是多租户、大规模分布式系统，企业托管在云上的数据分布于各个云产品的分布式系统中，无论是企业自身还是云服务提供商，均不能建立一个租户级别的“防火墙”把这些数据隔离起来。
所以企业要上云，对数据安全的需求会非常迫切。归根到底是环境的变化而导致了需求的优先级不一样。传统IT设施的数据安全，着重解决内部威胁（insider threat）和外部威胁（outsider threat），云上IT设施则还要解决数据托管在云厂商带来的安全与合规挑战，这并不是传统意义上的内外部威胁 - 从另一个角度看，可以被认为是云服务提供商如何提供一个可信、可控制的计算和存储托管环境。
解决方案：数据加密
那如何解决这个难题？
数据加密。
加密是一个古老的技术，有个叫潜伏的电视剧中，特务们发出的电报，在公共空间传播，谁都可以去把电波截获下来，但是他们有一个密码本，拿不到密码本，即便电波被截获下来也是枉然。
阿里云的大数据计算平台、云原生数据库、云服务器等，都支持云原生的数据加密能力，且阿里云给用户提供了密钥管理服务，通过密钥管理和云产品的数据加密功能，保证用户在云上使用这些产品时，数据都是可加密的。密钥管理服务的设计，正是为了保护好用户的“密码本”，并且安全的授权云服务或者企业自己的用户使用它来达成数据的加密保护。
1. 加密入门：可见的“默认加密”
为了更方便的让用户对低安全级别的数据进行加密保护，阿里云KMS提供了服务密钥，方便用户以最低成本实现可见的数据加密。
服务密钥
由云服务（云产品）托管在KMS的，归属于用户的密钥，这类密钥用户可见，但是其生命周期由用户授权的云产品托管。云产品使用服务密钥对数据进行加解密的过程，KMS记录在用户的ActionTrail中，用户可以对其使用进行审计。
打开“默认加密”
在已经支持的云产品中，用户可以选择对应的加密功能，如果用户不进一步指定加密密钥，那么云产品就会为用户创建一个服务密钥（一个云产品为一个用户仅创建一个服务密钥），并使用此服务密钥对用户数据进行加密保护。
举个栗子：用户创建ECS云盘时，可以打开加密功能，随后并不指定具体的加密密钥。此时ECS则会使用服务密钥。
查看服务密钥
用户可以在KMS控制台，或者通过CLI、SDK、OpenAPI Explorer等等等等方式去查看服务密钥。服务密钥特征明显：其别名为acs/${云产品代码}。
如下图中的别名为acs/oss的服务密钥，为OSS服务为用户创建的默认加密密钥。其生命周期由OSS服务为用户托管（例如用户不能禁用）
2. 加密进阶：可见可控的全托管加密
使用服务密钥，用户实际上是通过牺牲一定的自主性，换取更低的加密成本。
如果需要有更大的可控能力，则需要在云产品服务端加密时，选择由用户自己托管在KMS中的密钥。由于云产品并不是密钥托管者，对密钥的使用需要获得用户的显式授权。RAM服务是云产品和KMS之间的权限鉴别仲裁者，用户通过RAM服务配置权限策略，允许或者拒绝云产品使用特定的主密钥，云产品访问KMS时，KMS向RAM服务验证云产品是否具备使用特定主密钥的权限。
用户可以参考各个云产品的相关文档，获取进一步信息了解如何使用自选密钥加密的功能。官网文档链接：服务端集成KMS加密的云产品
3. 加密高阶：可见可控的半托管加密 - Bring Your Own Key
更高级的安全能力来自于业界普遍认可的一项技术：BYOK。简而言之，BYOK是指，通过安全的方式，将用户线下生成的密钥导入到云上的KMS托管的加密机中，并且保证加密机不能导出此密钥。而用户可以随时删掉云上的密钥，保留下一次导入同一个密钥的能力。
几乎所有的加密机生产商都会提供导入密钥，且设置密钥不可被导出的能力，KMS的BYOK功能提供了用户一项可信度非常高的保证，让用户几乎可以100%控制住云上的加密密钥，用于服务端的原生数据加密。参考官网文档链接：导入密钥材料
中途小结：云产品服务端加密技术框架
不同产品基于业务形态和客户需求，其加密的具体设计略有不同。通常，存储加密中密钥层次结构会至少分为两层，并通过信封加密的机制实现对数据的加密。
第一层为KMS中的用户主密钥（CMK），第二层为数据密钥（DK）。CMK对DK进行加解密操作和保护，DK对业务数据进行加解密操作和保护。在业务数据落盘存储时，云产品会将DK的密文（由KMS使用CMK加密）与业务数据的密文（由云产品使用DK加密）一同写入持久化存储介质中。信封加密中的“信封”是指在概念上DK的密文和业务数据的密文被打包在一个“信封”（Envelope）中。在读取加密数据时，DK的密文也会一同被读取，并先于业务数据进行解密。只有在DK被解密后，密文的业务数据才能够被正常解密读取。
在信封加密机制中，CMK受KMS提供的密钥管理基础设施的保护。云产品必须通过恰当的用户授权，才可以使用对应的主密钥来产生DK，用于业务数据的加密，也只有通过用户授权，才可以使用对应的主密钥来解密DK的密文，用于业务数据的解密。DK的明文仅会在您使用的云产品服务实例所在的宿主机的内存中使用，不会以明文形式存储在永久介质上。
4. 加密更高阶：自己写代码调用KMS
如果用户有更敏感的数据需要保护，或者为了满足GPDR或者其他法律法规要求，必须针对特定的数据实现主动加密保护，也可以直接调用KMS的API。KMS的API使用方式的常见实践有以下两种
当然用户也可以设计更复杂的密钥层次结构和密钥分区方式，完成复杂系统的数据加密。
5. 加密最高阶：自己管理HSM集群和写代码
最有可控力的方式，是使用阿里云加密服务的加密机（也叫HSM）。使用加密服务的HSM，用户可以有独享的HSM实例。相对而言，虽然KMS也支持使用HSM来托管用户的密钥，但是KMS的HSM设施是由多租户共享的。除此之外，加密服务的HSM是由用户自主管理和控制，而KMS的HSM则是由KMS托管。
由于加密服务提供的是HSM实例，用户需要考虑以下运维能力
- HSM的可用区分布：可用性
- HSM中密钥持久化的存储系统：可靠性
- HSM初始化安全参数的持久化：可靠性和安全性
- HSM集群搭建提供负载均衡的能力：可扩展性
除此之外，由于HSM的特殊性，一些HSM厂商并不提供服务端LB的能力，需要配套的客户端LB模块。当然，可以实现LB之前，用户需要将密钥从一个HSM实例上，同步到另一个HSM实例上，否则即便是基于客户端的LB也无法工作。
如果用户需要一些高级功能，则需要自建一些额外的管理能力，例如网络鉴权规则；资源管理，标签；密钥版本管理，自动轮转等。这实际上就是要自建一套KMI了。当然，换来的是最高的云上数据的安全和隐私。
6. 配合使用加密服务和KMS
如果有必要，用户也可以配合使用加密服务和KMS：用户可以在加密服务中自主管理HSM，并且管理密钥的产生；通过安全导入密钥到KMS的托管密码机中，用户可以获得以下好处
- 使得加密服务可以间接被用于云产品的服务端加密。
- 可以通过KMS的密钥别名功能，实现自主加密业务的同时支持人工轮转加密密钥。
