零信托体系结构
简短摘要
Zero Trust（ZT）是安全模型，其中网络外围不再被视为可信区域。每个请求（user→app，service→service，device→network）都经过显式身份验证，授权和加密，同时考虑到上下文信号（身份，设备状态，位置，风险，行为）。目标是最小化爆炸射线，降低后期运动的风险并简化合规性。
零信任基本原则
1.没有明确的信任：信任不会从网络/VPN/ASN继承。
2.访问是最低要求：政策"仅提供现在需要的东西"。
3.持续验证：会话和令牌定期重新评估风险和上下文。
4.损害假设：细分，可观察性，快速约束和密钥旋转。
5.加密无处不在：TLS 1。2+/1.3和mTLS在数据平面内，由DNS保护，KMS/HSM中的秘密。
目标景观和控制域
身份：人（IdP：SSO，MFA，passkeys/FIDO2），机器（SPIFFE/SVID，x 509/mTLS）。
设备：策略合规性（MDM/EDR 、磁盘加密、补丁、跳线/root-禁止）。
网络：微分L3/L7，ZTNA/SDP网关，服务-mesh（Envoy/Istio/Linkerd）。
应用程序/API：mTLS，OIDC/JWT，查询签名（HMAC），限制等级，DLP/掩码。
数据：分类（公共/机密/限制），字段级别的令牌/加密。
可观察性：集中身份验证/授权逻辑，行为分析，SLO/SLA。
参考体系结构（在平面切口）
控制平面：IdP/CIAM，PDP/PEP（OPA/Envoy），策略目录，PKI/CA，设备认证。
数据平面：代理访问（ZTNA），用于mTLS的sidecar代理和L7策略，服务网关/GW API。
管理平台：服务目录，CMDB，CI/CD，秘密管理（Vault/KMS），集中审计。
1.识别（SSO+phishing-resistant MFA） → 2）设备评估（MDM posture） → 3） ZTNA代理将mTLS设置为附录→ 4） PDP（策略）根据属性（ABAC/RBAC） → 5）持续风险重新评估（时间、地理、地理、地理、地理等）。异常）。
身份和授权
IdP/SSO：OIDC/SAML，默认的MFA，最好FIDO2（passkeys）。
RBAC/ABAC：角色+上下文属性（设备状态、部门、风险配置文件）。
Just-In-Time （JIT）访问：具有自动召回的临时权限；破玻璃-严格监管。
机器的mTLS：SPIFFE/SVID或具有短寿命证书的内部PKI；自动旋转释放。
设备和上下文
合规性检查（posture）： OS/EDR版本,包括磁盘加密,firewall；非完成→访问最小化或块。
认证：device identity+signed attestations （MDM/Endpoint）。
网络限制：第三方隧道单元，强制企业DNS，DNS/WebRTC泄漏保护。
网络和微分段
放弃"平面"VLAN： 取而代之的是分段/VRF和L7上的策略。
Service Mesh： sidecar代理提供mTLS、策略授权（OPA/EnvoyFilter）、遥测。
ZTNA/SDP：访问特定应用程序而不是网络；kliyent↔broker↔app，PDP中的政策。
远程访问：用app代理替换"厚"VPN；落后隧道仅限于路线/端口。
策略和解决方桉引擎
PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
政策模型：声明性规则（Rego/Cedar），静态和上下文属性，风险评估。
Rego示例（简化）：rego package access. http
default allow = false
allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}解决方桉跟踪：为审核编写"输入"/"结果"/"解释"。
加密和默认信任
TLS 1.2+/1.3无处不在，严格的密码管，HSTS，OCSP stapling。
内部mTLS：仅通过互惠证书进行servis↔servis；钥匙简短（小时/日）。
秘密：KMS/HSM，动态秘密（Vault），短TTL，适用于应用程序的least-privilege。
可观察性、SLO和响应
度量（最小集）：- 认证和授权成功（%）,p95 PDP决策时间,p95 TLS-handshake。
- 策略阻止的请求百分比（异常/假）。
- ZTNA经纪人和Mesh控制器的可用性。
- 复合设备份额和趋势。
- "ZTNA可用性≥ 99。95%/多月；p95 authZ decision ≤ 50 мс».
- "使用mTLS的查询比例≥ 99。9%».
- "不超过0。1％的虚假访问/日拒绝。"
Alarting：deny爆发，p95握手降解，无效链，合成器件比例下降，地理/ASN异常。
从外围过渡到零信托： 路线图
1.库存：应用程序，数据流，消费者，敏感性（PII/卡/付款）。
2.身份和MFA：所有SSO和phishing-resistant MFA。
3.设备上下文：MDM/EDR，基本合规性策略，非合规性块。
4.优先路径的微分段：付款，后台，管理层；输入mTLS。
5.ZTNA用于用户访问：通过代理发布应用程序,清除"广泛VPN"。
6.ABAC策略：集中式PDP、声明性规则、审核。
7.扩展到服务-mesh：S2S mTLS，L7政策，遥测。
8.自动化和SLO： alerting,策略测试（政治CI）,游戏日"如果IdP不可用,该怎么办?».
iGaming/fintech的细节
硬域细分：付款/PII/反亲和力/内容-单独的周边和政策；仅通过ZTNA访问。
与PSP/银行的交互：在ASN/范围、 mTLS到PSP端点、Time-to-Wallet监视以及authZ上的故障。
内容提供商和合作伙伴：临时JIT访问API, TTL短令牌,集成审核。
合规性：PCI DSS/GDPR-数据最小化、DLP/别名化、敏感表访问日志。
供应链安全和CI/CD
工件签名（SLSA/Provenance）：容器签名（cosign）, K8s中的Admission策略。
SBOM和漏洞：SBOM生成（CycloneDX）, pipline中的策略门。
CI中的秘密：云层KMS的OIDC联盟；禁止使用静态密钥。
轮换：频繁自动轮换；在发生事件时强制报复。
典型错误和反模式
"ZTNA=新VPN"：发布网络而不是应用程序-不是Zero Trust。
没有设备检查：有MFA，但感染/旋转的设备可以访问。
一个超级用户：没有JIT和分开的角色。
服务代码中的策略：无法进行集中审计/更新。
mTLS部分：部分非mTLS服务→"漏水"路径。
零UX：MFA请求过多，没有SSO；结果是对团队的抵抗。
精选技术的迷你海德
用户访问：ZTNA/SDP经纪人+IdP（OIDC，FIDO2 MFA）。
服务内安全：服务-mesh（Istio/Linkerd）+OPA/Envoy authZ。
PKI：SPIFFE/SVID或具有短TTL的Vault PKI。
政客：OPA/Rego或Cedar；存储在Git中，检查CI（策略测试）。
逻辑和遥测：OpenTelemetry →集中分析，异常的细节。
配置示例（片段）
Envoy（服务之间的mutual-TLS）
yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: trueOPA/Rego： 在工作时间内只能从"财务"、综合设备访问报告
rego package policy. reports
default allow = false
allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}零信托实施支票清单
1.为所有用户和海军上将启用SSO和MFA FIDO2。
2.键入具有非完全锁定的设备posture（MDM/EDR）。
3.将用户访问转换为ZTNA（按应用）,仅为狭窄的S2S通道保留VPN。
4.内部-默认的mTLS+短寿命证书。
5.集中策略（PDP/OPA），存储在Git中，测试在CI中。
6.分段敏感域（付款/PII/后台）并限制东西方。
7.在auth/authZ、mTLS分量、posture信号上配置遥测、SLO和alerting。
8.进行"游戏日"（IdP故障，密钥泄漏，经纪人掉落）并记录SOP/回扣。
FAQ
Zero Trust是否完全取代VPN?
对于用户访问-是的,支持ZTNA。对于S2S主干,VPN/IPsec可能仍然存在,但mTLS的策略也很严格。
ZT能使UX恶化吗?
如果是无意识的。随着SSO+FIDO2，自适应MFA和按应用访问，UX通常得到改善。
是否必须实施Mesh服务?
并非总是如此。但是，对于大型微服务环境，mesh从根本上简化了mTLS/策略/遥测。
底线
Zero Trust不是产品，而是体系结构学科：身份为新外围，设备上下文，应用访问（ZTNA），微分区和mTLS无处不在，集中的策略和可衡量的可靠性。按照路线图和支票单，您将减少攻击表面，加快审计，并在没有"默认信任"的情况下获得可持续的安全性。