本控制项和旧标准中的网络安全类似，主要关注网络架构通信传输及可信验证，相比较而言简化了一些，属于三重防护之一。
标准原文 8.1.2 安全通信网络 8.1.2.1 网络架构
a) 应保证网络设备的业务处理能力满足业务高峰期需要；b) 应保证网络各个部分的带宽满足业务高峰期需要；c) 应划分不同的网络区域，并按照方便管理和控制的原则为各网络区域分配地址；d) 应避免将重要网络区域部署在边界处，重要网络区域与其他网络区域之间应采取可靠的技术隔离手段；e) 应提供通信线路、关键网络设备和关键计算设备的硬件冗余，保证系统的可用性。
8.1.2.2 通信传输
a) 应采用校验技术或密码技术保证通信过程中数据的完整性；
b) 应采用密码技术保证通信过程中数据的保密性。
8.1.2.3 可信验证
可基于可信根对通信设备的系统引导程序、系统程序、重要配置参数和通信应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。
主要检查点
网络架构
对于高峰期带宽保障是要在当初规划设计网络时就需要考虑好，同时也要考虑安全域以及IP段的分配和预留。国外对这方面，通常还会做业务影响分析（BIA，Business Impact Analysis），不过公司越大做起来越复杂，能做得起BIA的往往都不是普通企业。此外，要进行压力测试，做好带宽的冗余。对于如今的企业来说，无论是带宽还是性能，基本都能够完全满足高峰期的需求，可能有问题的是没有做好SLA或业务优先级资源分配。在高峰期，某些部门的资源存在无法保障的情况，这点需要引起注意。
关键业务区（生产网）和管理区，要避免划分在网络边界，现在大多情况下都不会这样部署。安全域间的隔离，或者用防火墙、网闸，或者ACL来做即可。此外线路冗余、关键节点冗余，都是说了很多年的基本操作，该做的还是要做，不能偷懒。总体来看，通传统安全要求差不多，没有提出某些新的要求，大部分A类机房的网络结构基本可以满足。
通信传输
本控制点的完整性校验没有提到是要达到怎样的水平，那么采用最基本的CRC和奇偶校验是不是也算完整性校验，传输后利用哈希校验文件是否也是可以。测评要求中没有明确给出定论。通常的HTTPS、VPN这类加密传输协议中自带加密和完整性校验，所以通常传输加密和完整性校验是一体的。
Tip：完整性-哈希校验
哈希是一种不可逆的映射，可以将数据经过哈希算法计算得到一个哈希值，而无法再将该哈希值反映射得到原始的数据。一般来说，不同的数据得到的哈希值是不同的，但也有极少的可能会出现碰撞，但这种概率极小。在网络数据完整性校验中使用的哈希算法通常包括：MD5、SHA。
数据完整性校验
数据完整性校验一般使用哈希算法和密钥对数据进行哈希得到数据的一个哈希值，然后将该哈希值和数据一块发送给对方，对方收到数据之后，对数据使用相同的哈希算法和密钥进行哈希得到哈希值，如果得到的哈希值和对方发过来的相同，那么就说明数据没有经过篡改。（Sha256+RSA）
有人可能会想，常用的哈希算法就几类，假设窃听者截获了数据，修改了数据区的某些字节，然后再用哈希算法进行再一次哈希得到新的哈希值，放入数据包中哈希值的位置传给接收者，接收者收到之后，对数据进行哈希，得到的哈希值就是窃听者发过来的那个哈希值。从而窃听者实现了虽然没有获取信息，但是破坏了信息的目的。这就是为什么需要在哈希的时候使用密钥：通信双方进行身份认证之后，交换密钥，包括对称性加密的密钥，哈希算法的密钥，还有其他…. 在哈希的时候用上哈希密钥，而窃听者没有哈希的密钥，因此他最后伪造的哈希值是无法通过检验的。
Tip：保密性-HTTPS
HTTPS其实由两部分组成：HTTP + SSL / TLS，即在HTTP 上添加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，如下图。
1. 客户端发起HTTPS请求
用户在浏览器里输入一个https网址，然后连接到server的 443端口。
2. 服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别在于自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书就是一对公钥和私钥。
3. 传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等。
4. 客户端解析证书
这部分工作由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。正如上面所述，把随机值加密，这样除非有私钥，不然看不到被加密的内容。
5. 传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过该值来进行加密解密。
6. 服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是：将信息和私钥通过某种算法混合在一起，这样除非知道私钥，否则无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够强大，私钥够复杂，数据就足够安全。
7. 传输加密后的信息
信息是服务端用私钥加密后的信息，可以在客户端被还原。
8. 客户端解密信息
客户端用之前生成的私钥解密服务端传来的信息，获取解密后的内容。整个过程第三方即使监听到了数据，也无法获取内容。
SSL的位置
SSL介于应用层和TCP层之间（之前特意研究过，各有各的说法，最后把SSL 归为在应用层和传输层之间比较恰当，而不是只工作在某一层）。应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头。
RSA性能是非常低的，原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期，所以一般的HTTPS 连接只在第一次握手时使用非对称加密，通过握手交换对称加密密钥，在之后的通信采用对称加密方式。
HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品， TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下：
1. 浏览器将自己支持的一套加密规则发送给网站。
2. 网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3. 浏览器获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
4. 网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。
5. 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256
总结一下
服务器 用RSA生成公钥和私钥；
把公钥放在证书里发送给客户端，私钥自己保存；
客户端首先向一个权威的服务器检查证书的合法性，如果证书合法，客户端产生一段随机数，这个随机数就作为通信的密钥，我们称之为对称密钥，用公钥加密这段随机数，然后发送到服务器；
服务器用密钥解密获取对称密钥，然后，双方以对称密钥进行加密解密通信。
总之，HTTPS、TLS、VPN都可以，通常加密传输协议都会校验文件的完整性，完整性与保密性校验兼备.
可信验证
可基于可信根对通信设备的系统引导程序、系统程序、重要配登参数和通信应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。
本控制项总得来说偏向于网络的架构设计，主要在前期需求和设计阶段，相比旧标准简化了一部分内容。属于运维方向的安全要求，对象主要是甲方和第三方运维。
最后
等保2.0三级安全通信网络部分内容相比以前的网络安全有大幅减少，一方面删除了重复的要求向，一方面分散到其他的控制项中，实际上系统整体安全要求并没有减少。从总体来看，个人感觉管理层面加强了，技术层面有略微的削弱，但对于新技术，新流程提出要求，主要讲求技术与管理相结合来做好企业安全。