用免费开源工具建立零信任网络！(访问用户网络资源都是)

SDP（Software Defined Perimeter，软件定义边界）是一种与零信任模型密切相关的技术（也是实现零信任模型的关键技术之一），它主要用于实现对资源的安全访问，通过动态验证、按需授权和连接等方式确保只有合法用户及设备才能够访问。

在我们聊 SDP 之前，还是要先讨论一下传统VPN的局限性。
虽然说截至目前，VPN 都是实现远程访问或者说从网络层保护内网数据的主流技术，但随着整体安全趋势的发展，VPN 的不足之处也开始慢慢暴露了。

第一个问题是 VPN 会隐式信任所有来自已知网络的流量，无论是企业自建的 VPN 还是商业化产品，他们一般都是采用“信任但核实”这种安全模型，这就意味着一旦用户通过身份验证，他们就能访问网络内几乎所有资源，对于想做恶的人来讲，这就是天大的攻击面对吧！

退一万步讲，就算你内网的服务各个都是铜墙铁壁，入侵者进来之后他们还是能“看见”网络结构，看见拓扑，看见各种服务的版本blabla；当然传统的 VPN 环境下，限制用户可见的网络结构也不是不能做，就是比较麻烦，可以通过做分段和子网控制、防火墙和ACLs、RBAC、VLAN等等。

第二个问题是 VPN 自身的中心化结构限制，VPN 一般都依赖于中心化的服务器架构，这是因为VPN的设计初衷是为了提供远程连接到一个中心网络（如企业内部网络）；这样的特点就会导致 VPN 在访问量比较高的时间段成为系统瓶颈。
当然 VPN 也能做分布式，多地 + 多云分布式，但问题还是麻烦且成本高。

VPN 还有一些其他的小问题，我这样说吧，VPN 在安全性、性能、可扩展性、管理复杂性以及用户体验等多个方面，相比 SDP 都略逊一筹，我们可以认为 SDP 提供了更为优秀的解决方案，因此我们可以粗暴的认为，SDP 是 VPN 的 Pro Max 版（当然还不够准确）。

这里还是要和 VPN 做对比，VPN 的设计主要是为了安全地将远程用户连接到一个内部网络，它做的都是基于网络层面的安全控制；而 SDP 是基于零信任安全模型，它会关注更细粒度的访问控制，其设计目标是在保证最小必要访问的前提下，动态地为每个请求授权。

所以我在前面说的 SDP 是 VPN 的 Pro Max 版并不准确，准确的说，可以认为 SDP 是在安全领域的一种技术演进。
而且我们没必要无脑上 SDP，SDP 并不是在所有情况下都比 VPN 更好，它们各有适用的场景。
例如，对于需要简单的、广泛的网络访问，VPN 仍然是一个很好的选择；对于需要严格访问控制和高安全标准的环境，SDP可能更加合适。

前面说了，SDP 的核心目标是实现细粒度的访问控制，以提高整体系统安全性并减少形形色色的安全问题，下面我简要说一下 SDP 的工作流程吧。

身份验证

和部分 VPN 的先连接后认证不同，我们在访问任何资源之前，SDP 系统需要验证我们的身份，这里会涉及到多因素认证（MFA），包括密码、验证码、指纹、人脸识别、智能卡或手机 Token 等。
SDP 还会检查我们登录设备的安全状态，例如是否安装了最新的安全补丁、是否安装了杀毒软件、EDR、是否设置锁屏和设备的密码策略等等。

授权和执行策略

一旦我们的身份验证通过，SDP 会根据预定义的安全策略来决定我们可以访问哪些资源，当然这里面具体的安全策略都是需要我们配置的，例如我们可以根据用户角色、资源类型、当前的安全状况、访问时间、IP 等因素综合评估，SDP 控制器也会动态地为每个会话创建访问权限，确保我们只能访问确实需要且已经被授权的资源。

创建安全连接

上面的授权过程完毕后，SDP 为我们和资源之间建立一个安全的加密通道，不过与 VPN 不同的是，SDP 建立的连接一般都是一对一的，即直接从我们的设备到目标应用或服务。

细粒度的网络访问控制

SDP 通过最小权限原则、细粒度访问控制，能限制我们的访问仅限于必要和已授权资源，这种控制方式可以大幅降低攻击面，还能抗横移，即使入侵者已经进来了，他们也难以进一步访问其他系统或数据。

监控和审计

SDP 系统会持续监控所有网络活动，并对任何用户的访问行为做记录和审计，VPN 的日志一般就是流量数据、登陆失败记录、证书错误记录等等，相比于 SDP 的日志来讲不够详细，SDP 一般会记录每次访问请求的具体应用或资源、访问时间、持续时间、设备信息等等，更重点的问题是，大部分情况下 SDP 都是作为零信任模型的一个组件，它会和零信任模型中的其他组件，例如身份验证、加密、动态响应、行为分析等结合起来协同工作。

适应性和自动化

SDP 系统可以动态调整安全策略。
例如，在检测到高风险活动或某些可能的威胁行为时，SDP 可以自动调整访问权限，甚至自动 ban 掉某些用户和连接，这种自动化和适应性是 SDP 相对于传统安全解决方案的一个重要优势。

前面铺垫了这么多原理，现在我们再说说 SDP 的核心组件吧！
先放上一张图，以便大家更好的理解：

1. 控制器（Controller）

SDP 控制器是整个架构的核心组件，它负责处理所有关于身份验证、授权、策略管理和访问控制的决策逻辑。
控制器的任务是接收来自客户端的连接请求，执行安全策略，判断是否允许访问特定的服务或资源；控制器还负责创建和管理安全信道，确保数据的加密传输；同时还负责监控网络活动，执行安全审计和实时分析等任务。

2. 主机（Host）

SDP 主机（SDP Host）指的是部署在网络中的，需要被保护的资源，如服务器、应用程序或服务啥的，这些资源接受来自经过认证和授权的客户端连接请求，大部分时候 SDP 主机和 SDP 网关是集成到一起的。

3. 网关（Gateway）

SDP 网关属于被保护的资源与用户之间的媒介，它负责在 SDP 控制器的指挥下，把用户请求路由到正确的内部服务和资源。
SDP 网关会加密所有传入和传出的数据，并确保只有经过授权的请求才能够到后端，规模大一点的 SDP 部署时，可能会存在多个网关，做一些多地负载均衡之类的功能。

4. 客户端（Client）

SDP 的 Client 安装在用户的设备上，负责初始化与 SDP 控制器的通信，请求访问资源等工作，客户端会在请求访问之前进行设备状态检查和身份验证数据的上传，从而辅助 SDP 控制器的认证和授权。

5. 策略引擎（Policy Engine）

策略引擎一般是集成在 SDP 控制器中，它负责解析和执行我们预设的安全策略，而这些策略定义了哪些用户和设备可以在什么条件下可以访问特定的网络资源。

6. 认证服务（Authentication Services）

认证服务是 SDP 中用于集成身份验证机制的组件，如多因素认证、单点登录之类。
这些服务可以我们自己开发，也可以是集成外部服务，如 LDAP、Active Directory 或支持标准协议（如 SAML、OAuth、OpenID Connect）的 IDP。

7. PKI（Public Key Infrastructure）

有些大型的 SDP 会有 PKI系统，用 PKI 管理证书和公钥。
PKI 支持强身份验证和加密通信，也是建立安全网络访问控制的基础。

SDP 的原理和组件我们了解清楚了，接下来我们来讨论一下 SDP 的优势吧：

基于零信任：SDP 事实上是实现了基于零信任的安全模型，不再假设网络内部是安全的，而是需要每一次访问都经过严格的验证和授权。

细粒度的访问控制：SDP 允许我们对资源访问进行非常细致的控制，仅允许用户访问授权资源，这种形式的控制有助于最小化攻击面，并防止横移。

动态和适应性强的安全策略：SDP 支持基于用户、设备状态、位置等大量数据因子动态调整安全策略，这种措施比较敏感，能有效发现可能的安全问题。

除了以上优点，SDP 支持动态连接和零客户端（更轻量）形式的连接，也就是说对于某些敏感级别不高的应用或资源，用户可以用浏览器直接访问，无需像 VPN 一样安装客户端连接；同时无论是实时监控能力，还是异常检测、自动化响应和合规性支持等方面，SDP 相比 VPN 都是有显著优势的。

假设我们想在内部做一次零信任的落地，除了找乙方要 Demo 这种选项之外，还可以基于开源自建，我也更建议大家自建，这样才能更深入的理解零信任理念的内核。
说说开源方案吧，OpenZiti 是一款开源的零信任网络访问解决方案，由 NetFoundry 开发，其目标是通过 SDP 来提供高效、安全且灵活的网络访问控制。
作为一个开源项目，OpenZiti 受到了超级多的社区支持和关注，而持续的反馈、改进和扩展等都让它越来越完善了！

OpenZiti 的核心功能

OpenZiti 的核心功能包括 MFA 和 SSO 在内的身份验证和授权、端到端加密和动态加密隧道的加密通道、细粒度的访问策略的网络访问控制、资源隐藏和安全访问网关、安全的应用访问、实时监控和异常行为检测的实时监控和响应、API 和 SDK 支持及多平台兼容的集成和互操作性等等，总之，如果想用开源零信任解决方案，选 OpenZiti 就行了，非常好用。

OpenZiti 安装和配置简介

本文以 Docker 启动为例：

curl -so docker-compose.yaml https://get.openziti.io/dock/docker-compose.ymlcurl -so .env https://get.openziti.io/dock/.envdocker compose up -d

还需要启动一下 Ziti 管理控制台：

git clone https://github.com/openziti/ziti-console.git "${ZITI_HOME}/ziti-console"cd "${ZITI_HOME}/ziti-console"npm installng build ziti-console-libng build ziti-console-nodeln -s "${ZITI_PKI}/${ZITI_CTRL_EDGE_NAME}-intermediate/certs/${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}-server.chain.pem" "${ZITI_HOME}/ziti-console/server.chain.pem"ln -s "${ZITI_PKI}/${ZITI_CTRL_EDGE_NAME}-intermediate/keys/${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}-server.key" "${ZITI_HOME}/ziti-console/server.key"

接下来就能可视化的操作了。

假设我们希望配置一个简单的访问控制策略，只允许特定用户访问某个应用，我们首先需要在配置文件中，定义用户和相应的角色：

users: - name: "user1" roles: - "role1"

设置访问控制策略，限制“role1”角色的用户仅能访问指定的资源：

policies: - name: "policy1" roles: - "role1" resources: - "app1"

重启OpenZiti服务以应用新的配置：

docker-compose restart

Web UI 长这样：

项目链接

最后放上项目链接吧！

https://openziti.io/ # 主页https://openziti.io/docs/learn/introduction/ # docshttps://github.com/openziti/ziti # 项目链接https://github.com/openziti/ziti-console # Web UI后记

SDP 的核心价值在于它几乎消除了内外网的边界，通过确保所有网络资源对未经授权的用户维持不可见（无论是虚拟机还是任何对外暴露的服务），实现了严格的访问控制；在用户完成身份验证和授权之前，这些资源对他们来说都是不可达的“黑盒”。
通过这种方式，SDP不仅在用户首次访问时进行严格的身份检查和授权，而且持续验证用户的会话和状态，确保全时段的安全性。
这样，SDP 才能在不断变化的安全威胁环境中，有效地缩小潜在的攻击面，增强企业的整体网络安全防护。

可你说 VPN 不是也行嘛？确实，不连 VPN 的话内网资源也是不可见，但 VPN 的模式的原则有点像“默认允许”，一旦攻击者绕过了初始的防御，他们就能访问大量的内部资源，而在 SDP 中，所有资源在没有明确授权的情况下均默认不可见和不可访问，这才能在入侵者渗透入内网时显著缩小了潜在的攻击面。