等保2.0时代最受关注的变化，莫过于其保护范围的大大扩展，此外，在原有的基础上，等保2.0细化扩展了诸多细分安全领域的要求和标准，既与时俱进提高了保障的要求门槛，也让工作开展的依据更加清晰和可操作。

云等保是在原等保框架下对新事物的扩展，云计算架构之下，等级保护依然需要落地，包括定级、备案、建设整改、等级测评、监督检查五个规定动作。不同的是等保框架下新增加的元素需要对原有等级保护相关工作的具体内容进行扩充并统一。

首先是租户和平台的责任划分问题。在云计算条件下，目前采取的是云平台和租户的责任共担机制，而从IaaS到PaaS再到SaaS模式，云租户所需要承担的责任是越来越少的，但无论如何，对于云租户而言，数据安全始终是最核心的安全问题，不可松懈。

其次是定级备案的问题。传统的信息系统其架构是随着业务变化而变化的，实际上是以物理网络和安全设备为边界的；而对于云环境而言，则是以虚拟边界作为系统定级的边界，采用原有的思路无法体现出业务应用系统的逻辑关系，需要从业务应用的角度出发，梳理业务应用和对应的模块。

原则上，定级、备案工作是由用户单位自己填写定级备案表交给公安网监部门去进行备案工作，但考虑到实际情况，绝大多数情况下都是用户单位在测评机构的协助下完成这些工作。系统安全建设和等级测评的工作不一定要严格按照这个顺序开展，可以先测评再整改，也可以先建设再测评，具体还是根据自身实际情况来办。

选择的测评机构很重要，测评机构的权威性，测评质量直接关系到单位信息系统后期整改内容，提前发现问题提前整改，可以有效降低被攻击的风险，提高信息安全防护能力。

在定级当中还存在着两个重要误区：

1、已经托管的云系统是否需要等保？

根据“谁运营谁负责，谁使用谁负责，谁主管谁负责”的原则，该系统责任主体还是属于网络运营者自己，所以还是得承担相应的网络安全责任，该进行系统定级的还是得定级，该做等保的还是得做等保。

系统上云或托管后，并不是安全责任主体转移，只是系统所在机房地址的变更，当然在公有云模式下，Iaas、Paas、Saas不同模式相应的安全责任会有些区别，但是并不是没有责任。

2、系统定级越低越好？

最终定级是根据受侵害的客体以及对客体侵害的程度来确定的，以事实为根据，而不是主观随意定级。定级低了，表面上要求更容易满足，但相应的防护措施也相对不足，一旦遭受攻击，反而得不偿失。

再次是备案的问题。传统的系统备案很简单，IT基础设施、运维地点、工商注册地基本上都是一致的，直接去所在地市局、网安或者是分局即可；然而上云的系统由于部署在各类云平台上面，而云平台的实际物理地址往往和云系统网络运营者不在同一地址，大型云平台还有许多物理节点，很难确定云平台的具体物理地址，因此从方便属地公安机关监管的角度出发，应该在系统实际运维团队所在地市网安部门进行系统备案。

再就是如何建设整改的问题。云计算已经深刻的影响到了IT架构、业务系统部署方式，以及服务模式，一方面它可以让用户快速、弹性、按需、随时随地的获取到IT资源和服务，实现IT即服务的转变，是重要的一次信息化变革，另一方面这种新型的IT架构也带来了新的安全挑战和安全需求。

边界、通信和计算的安全均需要考虑在内，而重中之重的则是云数据安全的建设，依据客户实际需求和相关安全合规标准，进行数据创建、传输、存储、使用、共享和销毁在内的全生命周期的云环境下的数据安全设计，以及数据安全体系建设，从而保障用户数据在云环境下的安全使用，保护云环境中的数据的机密性、可用性、完整性。

最后是测评的问题。云计算系统保护措施通常是以系统整体能力体现，云计算安全扩展要求作为全局对待，在报告结构上等同于全局测评，各测评项不再重复对应一个或多个测评对象。等保工作是一个持续的工作，等保测评也是一个周期性的工作，三级系统要求每年做一次，四级系统每半年做一次，二级系统部分行业明确要求每两年做一次，没有明确要求的行业一般是建议两年做一次测评。