前言

最近在项目合作中涉及到部分业务需要上公有云，但翻了一些公开材料没有发现很好的介绍业务上公有云安全应该怎么做，故整理一篇材料分享业务上公有云应该怎么实践，本人水平有限难免疏漏，当作抛砖引玉了，欢迎同仁交流。

一. 为什么要上云？

随着信息化的程度加深，一般来说客户上云有可能是基于以下几点考虑：

1. 敏捷性：IDC或者虚拟化环境下的IT资源交付流程过于冗长，希望加快资源交付的速度；
2. 高效利用IT资源：传统的IT架构由于虚拟化或者要应对业务峰值、冗余的要求，会造成比较多的成本浪费，在非业务繁忙时期，闲暇的资源比较难利用起来，超峰值后的快速扩容也比较困难，缺了IT资源要补难，多了成本高也难减少成本也难，希望寻找个可以有效平衡业务发展和IT资源投入的方式；
3. 降低企业在业务上的信息化试错成本：业务要求赶紧上个业务，需要一定的IT资源，但是业务没做起来很快就决定放弃了，需要已经采购的这部分IT资源释放了还没到弃用时间，考虑是不是可以复用起来。

二. 公有云和传统IDC的IT模式差异在哪里？

1. 资源的所有权归厂商，租户只有虚拟资源的使用权限
2. 功能服务化
3. 资源抽象化
4. 访问的路径和方式变化
5. IT资源变化更频繁

三. 基于差异，开展安全工作的变化在哪？

1. 资源所有权的变化导致用户对于服务商的信任成本增加：租户仅能使用部分物理资源虚拟化后的资源；租户之间互相的隔离、物理环境到虚拟化环境中的隔离能力由云厂商进行保障，一旦上了云就只能被迫信任云厂商能把隔离能力做好；
2. 功能的服务化+所有权的变化导致用户对于IT资源操作的自主性下降，被迫依赖云厂商提供的服务：头部云服务商在提供各类云服务时，不管是IaaS、PaaS、还是SaaS的云服务，基本都已经把客户需要的基本能力做了云产品服务化、IT人员希望对计算资源、网络资源、还是运维、监控、审计、安全等功能进行使用，基本都能在云上找到对应的云服务进行使用，同时由于云厂商维护了底层的物理资源，租户无法对物理资源进行管理，自然也没办法将原有IDC内的安全产品上云，所以在大部分运维、审计、资源分配等IT工作的开展时被迫依赖于云厂商提供的服务进行开展。
3. 由于云服务的抽象化，尽管租户使用的虚拟机可能具体的物理机资源有差异，但用户不再需要再关注几台虚拟机具体的物理机的物理位置、网络如何打通、云资源的网络之间的设计是否合理等问题，租户端对基础架构的关注下降，导致了更多的云上业务的数据交换走API的形式，也间接提升API调用过程中鉴权、服务调用审计、越权等安全的要求，业务依赖于云会变得更专注于应用层、攻防也面向应用层、云服务权限获取增加了更多的关注，
4. 访问路径和方式发生了变化，原本的idc中，运维走堡垒机接入、远程走vpn接入、内部员工通过应用访问，绝大部分数据和访问路径在IDC内网，并且基于网络的隔离可以相对有效的对角色访问路径进行分离，尽管清晰程度仍有优化的空间，但依然可以相对安全的开展IT的工作；但在idc上公有云后，运维可直接通过互联网访问云控制台开展业务，；研发、测试可以基于云账号对应的AKSK进行云服务的调用，对开发环境或者测试环境进行操作，与此同时租户在控制台界面、及API权限的靠用上依赖云服务商提供的权限管控能力，对虚拟的云服务组件的访问进行角色的控制，保证尽管是同一个主账号下的不同角色的子账号，访问同一个云控制台的时候，部分产品可见，部分产品不可见，但这种从网络区域划分的访问逻辑转变成云控制台/AKSK访问授权的变化，变相增加了租户对于角色的划分以及依赖云平台进行角色访问控制的成本。
5. 由于云服务让IT资源实现了即开即用的能力，业务在使用云资源的时候具有更低的犯错成本，所以上云的业务更敏捷后，也会让云上资源的变化更加频繁，在传统idc中依赖agent或主动扫描资产这两种方式进行资源监测管理的模式，在云上资源频繁变化的情况下已经比较难实现有效的资源安全管理，必须考虑安全能力如何在云资源持续变化的情况下实现落地。

四. 基于上述的变化，上云怎么做安全？

4.1 先想明白是否必要上，计划上什么云厂商？

1. 如果没有把半条命交给云厂商的决心，不要上公有云：在公有云的IT架构中，虚拟化能力、租户隔离能力、云服务产品自有的安全性、云安全服务的易用性和可靠性，在云责任主体中都由云厂商进行保证，租户在这些范畴基本无法做管控；
2. 如果非要上，不要上小公有云：如上描述，如果确认是需要上公有云，不建议上中小型公有云，因为在虚拟化、租户隔离、云服务产品可靠性、安全产品的可靠性、服务能力上，很难和头部云厂商一样有比较大的投入，也更难对客户有保障。

4.2 梳理需求

1. 是否涉及第三方接入：如果涉及第三方开发/运维的合作，如何允许第三方安全的接入
2. 是否涉及混合云架构：如果涉及原有IDC的数据交换，或涉及多云架构的数据交换，如何保证
3. 是否涉及非云原生产品的引入：如果涉及部分非原生产品部署，需要如何保证非云原生产品的安全性，以及该类产品的部署位置、并评估对租户使用和安全性的影响
4. 是否涉及租户安全责任的分担：如果总的系统体量上来了，涉及部分二级公司或系统/项目组，需要分发云资源的分配和二级管理员权限，需要考虑安全责任是否随着云资源进行分发。

4.3 整理安全架构

基于云上系统的业务需求，梳理上云后需要使用的安全服务，一般来说会涉及以下几块内容：

1. 生产、测试、开发等环境的分离：至少在主账号下划分不同地区，如生产区域在广州、上海两个地区，测试在深圳、开发在测试等方式，易于后续的管理；
2. 生产区域中是否涉及不同等级应用系统：VPC（虚拟网络）至少需要按不同的系统等级进行不同VPC的划分，如果运营成本充足，则建议以项目组的方式进行VPC的划分，更细化系统数据交换的清晰程度；
3. 生产系统是否需要对互联网开放：如果需要对互联网开放，至少配置抗DDOS服务、Web应用防火墙、云防火墙，实现基础的互联网暴露面的防护能力；
4. 涉及混合云架构数据回传IDC或非云原生服务部署的组件：单独划分公共区域及子网，承载具体的云上独立部署的公共服务；
5. 其余支撑性能力：如堡垒机、数据库审计、主机安全、kms等能力基本需要备齐；
6. 运营：soc、NTA等产品视实际需求情况进行建设。

假设：如果一个云上架构的业务，涉及生产环境、开发环境、涉及数据与IDC进行交换，并具有互联网资产暴露、云上同时具有应用服务及其对应的数据库，部分安全能力使用自有系统部署的公有云安全架构基本会如下图（图例以腾讯云为例）所示：

安全能力的隔离层级从小到大依次为：

• 安全组（主机与主机隔离）
• 子网隔离（网段与网段隔离）
• VPC隔离（虚拟网络与虚拟网络隔离）
• 子账号（租户）隔离 （子账号之间的隔离）
• 主账号隔离（租户与第三方开发商在主账号之间的隔离）

4.4 设计权限矩阵

由于云服务商把云上常用的IT能力封装成了云服务，故对于权限管控的设计主要着眼于：不同的子账号、不同的AKSK可以有什么权限访问业务所需访问的云服务。
一般来说建议将安全、网络、主机、数据库、监控等这些可以直接对IT资源进行操作的账号进行权限分离，避免单独账号或AKSK权限过大导致的外部入侵扩散或内部权限滥用，并在区域、系统、可操作模块实现细化控制，
如：基于腾讯云的提供的权限管控功能，可以大致实现以下的权限矩阵：
灰色部分为按需设计，
黄色格子为可读权限
蓝色格子为可写权限
绿色格子为读写权限

其中需要注意的两个点是：
1. 由于希望避免云服务之间调用的AKSK需要留存在本地导致的硬编码问题，基于凭证管理服务，使用三权分立的原则进行服务之间调用的AKSK的全生命周期管理；
2. 各个角色访问控制台基于云平台提供的【IP】、【标签】、【时间】、【请求资源】、【具体功能模块】进行细化的权限管控，并形成安全策略组进行默认策略分发

五. 后续

基于上述的云厂商提供的服务、安全服务的启用，并对权限矩阵进行设计后，基本可以实现公有云基础安全能力的保障以及账号和AKSK的权限分离，但在实际安全的落地中，仍然有很多安全性上的问题需要进一步，下面罗列一些以供后续实际落地中进行考虑：

1. 如果租户在云上引入了非云原生的安全组件，如何保障该非原生组件与云上服务的安全且有效的数据交换？
2. 目前的云服务由于大量客户从传统虚拟化转向云，从虚拟化资源的使用体验上很难直接从虚拟机的使用习惯转向真正的容器化，但云服务提供虚拟机而不是上到容器，本质仍然是割裂和封闭，并不能实现容器化，故容器化的是趋势，但目前云平台的安全服务能力基本是从IDC中IaaS层的安全能力演进而来，如果业务真的在一天统一到容器化后，容器化的安全该如何实现？
3. devops模式下的开发流程，该如何和云服务进行结合实现原生安全？
4. 由于目前国内的云上咱不具备原生的NTA的能力，如AWS、ali云支持vpc flow的方式进行流量镜像后用户的自主分析，腾讯云目前仍不支持vpc flow流量的镜像，在需要更细化的流量分析能力时需要如何实现？