文章目录
- TLS 和 mTLS
-
* TLS 和 mTLS使用场景- TLS 加密通信的流程
- 终止 TLS
- 什么时候用 mTLS？
- 什么时候不用 mTLS？
- 流量加密
-
* 入口流量加密- 内部流量加密
-
* PeerAuthentication 为工作负载设置 mTLS- DestinationRule 为工作负载设置 mTLS
- 安全最佳实战
TLS 和 mTLS
TLS（Transport Layer Security）和 mTLS（mutual
TLS）都是用于加密通信的协议，用于保护数据在网络上的传输安全。它们在保护通信方面有一些区别：
- TLS（Transport Layer Security） ：
* TLS 是一种加密通信协议，用于在网络上安全地传输数据。它用于建立安全的通信通道，确保数据在传输过程中不被篡改或窃取。
* TLS 通常用于客户端和服务器之间的通信，并且只要求服务器端提供证书，客户端验证服务器身份。
* 在 Web 安全中，HTTPS（HTTP over TLS）就是使用 TLS 来加密 HTTP 通信的协议。 - mTLS（mutual TLS） ：
* mTLS 是 TLS 的一种扩展，也称为双向 TLS 或双向认证。它要求通信双方（客户端和服务器）都提供证书，进行相互验证身份。
* 在 mTLS 中，不仅服务器验证客户端的身份，客户端也验证服务器的身份。这种双向验证确保了通信的双方都是可信的，并且加强了通信的安全性。
主要区别在于 TLS 通常是单向验证，而 mTLS 是双向验证。mTLS
提供了更高级别的安全性，因为它不仅验证服务器的身份，还验证客户端的身份，确保了通信的完整性和安全性。
在网络安全领域，mTLS 通常用于要求更严格的安全标准的场景，如微服务之间的通信、API 访问控制等。通过使用
mTLS，可以确保通信双方的身份验证和通信数据的加密，提高了通信的安全性和可靠性。
TLS 和 mTLS使用场景
TLS（Transport Layer Security）和 mTLS（mutual
TLS）在网络通信中有不同的使用场景，根据安全需求和通信模型的不同，选择合适的加密方式非常重要：
TLS 使用场景 ：
- Web通信 ：TLS 在 Web 通信中广泛应用，用于加密 HTTP 通信，形成 HTTPS 协议，保护 Web 应用的数据传输安全。
- 客户端-服务器通信 ：在传统的客户端-服务器模型中，服务器通常会提供证书，客户端验证服务器的身份，确保通信的安全性。
- 加密数据传输 ：TLS 可用于保护数据在网络上的传输，确保数据在传输过程中不被篡改或窃取。
- 保护隐私数据 ：适用于需要保护用户隐私数据的应用场景，如登录、支付等敏感操作。
mTLS 使用场景 ：
- 微服务通信 ：在微服务架构中，各个服务之间的通信可能需要更严格的安全性要求，mTLS 可用于确保服务之间的双向身份验证和通信加密。
- API 访问控制 ：在 API 访问控制中，服务端可以要求客户端提供证书进行身份验证，确保只有授权的客户端可以访问 API。
- 云原生环境 ：在容器化和云原生环境中，mTLS 可用于保护容器间的通信，确保容器之间的安全通信。
- 内部通信 ：适用于内部系统或服务之间的通信，要求更高级别的安全性和身份验证。
总的来说，TLS 适用于大多数常规的加密通信场景，而 mTLS 则适用于对通信安全性要求更高、需要双向身份验证的场景，如微服务架构、API
访问控制等。选择合适的加密方式取决于您的安全需求和通信模型。
TLS 加密通信的流程
- 服务器向受信任的 CA（证书管理机构）申请并获得证书（X.509 证书）；
- 客户端向服务端发起请求，其中包含客户端支持的 TLS 版本和密码组合等信息；
- 服务器回应客户端请求并附上数字证书；
- 客户端验证证书的状态、有效期和数字签名等信息，确认服务器的身份；
- 客户端和服务器使用共享秘钥实现加密通信；
参考：[TLS 握手期间会发生什么？](https://www.cloudflare.com/zh-cn/learning/ssl/what-
happens-in-a-tls-handshake/)
[写给 Kubernetes 工程师的 mTLS 指南 | 云原生资料库](https://lib.jimmysong.io/blog/mtls-
guide/)
终止 TLS
TLS 终止（TLS Termination）指的是在将 TLS 加密流量传递给 Web 服务器之前对其进行解密的过程。将 TLS
流量卸载到入口网关或专用设备上，可以提高 Web 应用的性能，同时确保加密流量的安全性。一般运行在集群入口处，当流量到达入口处时实施 TLS
终止，入口与集群内服务器之间的通信将直接使用 HTTP 明文，这样可以提高服务性能。
Istio 默认在入口网关处终止 TLS，然后再为网格内的服务开启 mTLS。你也可以让流量直通（passthrough）到后端服务处理，例如：
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: sample-gateway
spec:
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: PASSTHROUGH
什么时候用 mTLS？
互联网客户端对 Web 服务的访问，一般使用单向 TLS，即只需要服务端提供身份证明，而不关心客户端的身份。当你需要验证客户端身份时，使用单向 TLS
可以使用密码、token、双因子认证等方式。不过这样的认证方式需要应用程序内部支持，而双向 TLS 是运行在应用程序之外的，不需要多应用逻辑进行修改。
- 实施 mTLS 的服务间需要交换证书，当服务数量变大时，就需要管理大量的证书，这需要消耗大量的精力，使用服务网格可以帮助你实现自动 mTLS，彻底解决证书管理的难题。
- 微服务通信 ：在微服务架构中，各个服务之间的通信可能需要更严格的安全性要求，mTLS 可用于确保服务之间的双向身份验证和通信加密。
- API 访问控制 ：在 API 访问控制中，服务端可以要求客户端提供证书进行身份验证，确保只有授权的客户端可以访问 API。
- 云原生环境 ：在容器化和云原生环境中，mTLS 可用于保护容器间的通信，确保容器之间的安全通信。
- 内部通信 ：适用于内部系统或服务之间的通信，要求更高级别的安全性和身份验证。
什么时候不用 mTLS？
虽然 mTLS 是确保云原生应用程序服务间通信安全的首选协议，但是应用 mTLS 需要完成复杂的对称加密、解密过程，这将非常耗时且消耗大量的 CPU 资源。
对于某些安全级别不高的流量，如果我们在流量入口处终止 TLS，并网格内部仅对针对性的服务开启 mTLS，就可以加快请求响应和减少计算资源消耗。
流量加密
Istio流量主要包含入口流量和内部流量，入口流量是需要TLS进行加密的，加密解密过程是需要消耗CPU资源的，若是集群规模比较大内部服务多，内部流量
- 外部入站流量 这是被 Sidecar 捕获的来自外部客户端的流量。 如果客户端在网格外面，该流量可能被 Istio 双向 TLS 加密。 Sidecar 默认配置 PERMISSIVE （宽容）模式：接受 mTLS 和 non-mTLS 的流量。 该模式能够变更为 STRICT （严格）模式，该模式下的流量流量必须是 mTLS；或者变更为 DISABLE （禁用）模式， 该模式下的流量必须为明文。mTLS 模式使用 PeerAuthentication资源配置。
- 内部入站流量 这是从 Sidecar 流出并引入您的应用服务的流量。流量会保持原样转发。 注意这并不意味着它总是明文状态，Sidecar 可能也通过 TLS 连接。 这只意味着一个新的 TLS 连接将不会从 Sidecar 中产生。
- 内部出站流量 这是被 Sidecar 拦截的来自您的应用服务的流量。 您的应用可能发送明文或者 TLS 的流量。 如果自动选择协议已开启，Istio 将能够自动地选择协议。 否则您可以在目标服务内使用端口名手动指定协议。
- 外部出站流量 这是离开 Sidecar 到一些外部目标的流量。流量会报错原样转发，也可以启动一个 TLS 连接（mTLS 或者标准 TLS）。 这可以通过 DestinationRule资源中的 trafficPolicy 来控制使用的 TLS 模式。 模式设置为 DISABLE 将发生明文，而 SIMPLE、MUTUAL 和 ISTIO_MUTUAL 模式将会发起一个 TLS 连接。
关键要点是：
- PeerAuthentication 用于配置 Sidecar 接收的 mTLS 流量类型。
- DestinationRule 用于配置 Sidecar 发送的 TLS 流量类型。
- 端口名，或者自动选择协议，决定 sidecar 解析流量的协议。
入口流量加密
[理解 TLS 配置](https://istio.io/latest/zh/docs/ops/configuration/traffic-
management/tls-configuration/)
作为入站请求的一部分，网关必须对流量进行解码才能应用路由规则。 网关根据
Gateway资源中的服务配置解码。
例如，如果入站连接是明文的 HTTP，则端口协议配置成 HTTP：
apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
servers:
- port:
number: 80
name: http
protocol: HTTP
同样，对于原始 TCP 流量，协议将设置为 TCP。
对于 TLS 连接，还有更多选项：
- 封装了什么协议？ 如果连接是 HTTPS，服务协议应该配置成 HTTPS。 反之，对于使用 TLS 封装的原始 TCP 连接，协议应设置为 TLS。
- TLS 连接是终止还是通过？ 对于直通流量，将 TLS 模式字段配置为 PASSTHROUGH：
apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: PASSTHROUGH
在这种模式下，Istio 将根据 SNI 信息进行路由并将请求按原样转发到目的地。
- 是否应该使用双向 TLS ？ 相互 TLS 可以通过 TLS 模式 MUTUAL 进行配置。配置后，客户端证书将根据配置的 caCertificates 或 credentialName 请求和验证：
apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: MUTUAL
caCertificates: ...
内部流量加密
[如何理解 Istio 中的 mTLS 流量加密？](https://jimmysong.io/blog/understanding-the-tls-
encryption-in-istio/#when-use-mtls)
tio 的对等认证默认使用 PERMISSIVE 模式，自动将 mTLS 流量发送到这些工作负载，将纯文本流量发送到没有 sidecar 的工作负载。在将
Kubernetes 服务纳入 Istio 网格后，为了防止服务无法通过 mTLS，我们可以先使用 PERMISSIVE 模式。当我想为某些服务开启严格的
mTLS 模式时，可以使用以下两种方式之一：
- 使用 PeerAuthentication 定义流量如何在 sidecar 之间传输；
- 使用 DestinationRule 定义流量路由策略中的 TLS 设置；
PeerAuthentication 为工作负载设置 mTLS
你可以使用 namespace 和 selector 指定某个命名空间下的某个工作负载开启严格的 mTLS。例如下面的配置：
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: foo-peer-policy
namespace: default
spec:
selector:
matchLabels:
app: reviews
mtls:
mode: STRICT
你也可以给安装 Istio 的命名空间 istio-system 设置严格的 mTLS，那样会为网格中的所有服务开启严格的 mTLS，详细步骤请参考
[Istio 文档](https://istio.io/latest/zh/docs/tasks/security/authentication/mtls-
migration/) 。
PeerAuthentication 中指定对目标工作负载实施的 mTLS 模式。对等认证支持以下模式：
- PERMISSIVE：默认值，工作负载可接受双向 TLS 或纯文本流量；
- STRICT：工作负载仅接受 mTLS 流量；
- DISABLE：禁用 mTLS。从安全角度来看，除非你有自己的安全解决方案，否则不应禁用 mTLS；
- UNSET：从父级继承，优先级为服务特定 > 命名空间范围 > 网格范围的设置；
DestinationRule 为工作负载设置 mTLS
DestinationRule 用于设置流量路由策略，例如负载均衡、异常点检测、TLS 设置等。其中 TLS
设置中包含[多种模式](https://istio.io/latest/docs/reference/config/networking/destination-
rule/#ClientTLSSettings-TLSmode) ，使用 ISTIO_MUTUAL 模式可以为工作负载开启 Istio 的自动
TLS，如下所示。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews
namespace: default
spec:
host: reviews
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
安全最佳实战
参考官网：安全最佳实践
[安全策略示例](https://istio.io/latest/zh/docs/ops/configuration/security/security-
policy-examples/)
安全中通常会匹配那些路径能访问，通常这些访问路径研发人员才知道，若全是交给技术设施人员比较吃力，此处小编建议使用SpringcloudGateway网关进行路由规则的配置。istio人员只需配置限制的域名，流量加密鉴权等。在内部服务对安全要求较高的服务上加mTLS，网关入口终止TLS。
接下来我将给各位同学划分一张学习计划表！
学习计划
那么问题又来了，作为萌新小白，我应该先学什么，再学什么？
既然你都问的这么直白了，我就告诉你，零基础应该从什么开始学起：
阶段一：初级网络安全工程师
接下来我将给大家安排一个为期1个月的网络安全初级计划，当你学完后，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web渗透、安全服务、安全分析等岗位；其中，如果你等保模块学的好，还可以从事等保工程师。
综合薪资区间6k~15k
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）
2、渗透测试基础（1周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础（1周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）
4、计算机网络基础（1周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固
6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
那么，到此为止，已经耗时1个月左右。你已经成功成为了一名“脚本小子”。那么你还想接着往下探索吗？
阶段二：中级or高级网络安全工程师（看自己能力）
综合薪资区间15k~30k
7、脚本编程学习（4周）
在网络安全领域。是否具备编程能力是“脚本小子”和真正网络安全工程师的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力。
零基础入门的同学，我建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习
搭建开发环境和选择IDE，PHP环境推荐Wamp和XAMPP，IDE强烈推荐Sublime；
Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，没必要看完
用Python编写漏洞的exp,然后写一个简单的网络爬虫
PHP基本语法学习并书写一个简单的博客系统
熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)
了解Bootstrap的布局或者CSS。
阶段三：顶级网络安全工程师
如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！
学习资料分享
当然，只给予计划不给予学习资料的行为无异于耍流氓，这里给大家整理了一份【282G】的网络安全工程师从入门到精通的学习资料包，可点击下方二维码链接领取哦。
扫一扫
7176
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
