零信托體系結構
簡短摘要
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無處不在，集中的策略和可衡量的可靠性。按照路線圖和支票單，您將減少攻擊表面，加快審計，並在沒有「默認信任」的情況下獲得可持續的安全性。