🔒 零信任网络访问实现与评估实验室

以身份为中心的安全  ·  WireGuard 微分段  ·  OPA 策略执行  ·  攻击面量化

📌 概述  ·  🏗️ 架构  ·  🔧 技术栈  ·  📁 结构  ·  ⚡ 快速开始  ·  🔑 Keycloak  ·  🔨 WireGuard  ·  📜 OPA  ·  📊 评估  ·  ⚠️ 道德与法律  ·  🤝 贡献  ·  📜 许可证

## 📌 项目概述 本项目在虚拟实验室网络中完全使用开源工具设计、实现并正式评估了一种**零信任网络访问 (ZTNA)** 架构。该实现摒弃了传统的“城堡护城河”边界模型，执行核心零信任原则：**从不信任，始终验证** —— 针对每个用户、设备和每个服务请求，无论其网络位置如何。 实验室结合了用于集中身份和访问管理的 **Keycloak**、用于网段加密微分的 **WireGuard**，以及用于细粒度基于属性策略执行的 **Open Policy Agent (OPA)**。项目以一份正式的**安全评估报告**结束，量化了零信任实施前后的攻击面缩减情况。 ### 为什么本项目很重要 | 受众 | 价值 | |---|---| | **企业安全工程师** | 使用生产级开源工具实现 ZTNA 的蓝图 | | **SOC 分析师** | 演示零信任如何减少横向移动的爆炸半径 | | **网络安全研究员** | 量化的攻击面对比，以及可衡量的安全改进 | | **云安全架构师** | 商业 ZTNA 产品 (Zscaler, Cloudflare Access) 的开源替代方案 | | **学生及有志于安全行业的工程师** | 动手实践实验室，演示 NIST SP 800-207 零信任原则的实际应用 | ### 实施的核心零信任原则 - ✅ **显式验证** — 使用 Keycloak 身份 + OPA 策略对每个请求进行身份验证和授权 - ✅ **使用最小权限访问** — 基于角色、设备、时间和风险信号的动态访问范围 - ✅ **假设已遭入侵** — 即使在失陷后，微分段网络也能限制横向移动 - ✅ **持续验证** — 短期 JWT token，在出现可疑信号时重新评估会话 - ✅ **设备信任** — WireGuard peer 证书将访问绑定到特定的受信任设备 ## 🏗️ 架构 ``` +------------------------------------------------------------------+ | IDENTITY PLANE | | | | +------------------+ +------------------+ | | | Keycloak IdP | | OPA Policy | | | | (OIDC / OAuth2) | | Engine | | | | JWT issuance | | Rego policies | | | | MFA enforcement | | ABAC decisions | | | +--------+---------+ +--------+---------+ | | | | | +------------+-----------------------+----------------------------+ | JWT token | policy decision (allow/deny) +------------v-----------+ +-----------v-----------+ | Policy Enforcement | | Application Gateway | | Point (PEP) | | (reverse proxy) | | Validates JWT + | | Enforces OPA result | | calls OPA for decision| +-----------+-----------+ +------------------------+ | | Authorized traffic only +---------------------------------------v--------------------------+ | DATA PLANE (WireGuard Mesh) | | | | +------------+ +------------+ +------------+ | | | Segment A | | Segment B | | Segment C | | | | Web Tier | | App Tier | | Data Tier | | | | 10.0.1.0/24| | 10.0.2.0/24| | 10.0.3.0/24| | | +------+------+ +------+------+ +------+------+ | | | | | | | +-------WireGuard Encrypted Tunnels-+ | | (cryptographic isolation between segments) | +------------------------------------------------------------------+ | OBSERVATION PLANE | | Suricata IDS . Zeek (network logs) . Wazuh SIEM | | OPA audit log . Keycloak event log . Prometheus metrics | +------------------------------------------------------------------+ BEFORE Zero Trust: Flat network, lateral movement possible AFTER Zero Trust: Each segment cryptographically isolated, every request identity-verified + policy-checked ``` ## 🔧 技术栈 | 层级 | 工具 | 版本 | 用途 | |---|---|---|---| | **身份提供者** | Keycloak | 24.x | OIDC/OAuth2, MFA, 用户联邦, JWT 签发 | | **微分段** | WireGuard | Kernel module | 加密网络分段, 点对点隧道 | | **策略引擎** | Open Policy Agent (OPA) | 0.63.x | 在每个访问点执行基于 Rego 的 ABAC 策略 | | **策略网关** | Nginx + OPA sidecar | Latest | 执行 OPA 策略决策的反向代理 | | **网络监控** | Suricata IDS | 7.x | 网络入侵检测, 基于规则的告警 | | **流量分析** | Zeek | 6.x | 详细的网络流日志和行为分析 | | **SIEM** | Wazuh | 4.x | 日志聚合, 关联, 告警管理 | | **指标** | Prometheus + Grafana | Latest | 实时网络和安全指标仪表板 | | **自动化** | Ansible | 2.16+ | 可复现的基础设施配置 | | **编排** | Docker + Docker Compose | Latest | 服务容器化 | | **实验室 VM** | VirtualBox / Proxmox | Latest | 多 VM 实验室拓扑 | | **脚本** | Python 3.10+ / Bash | — | 攻击面分析, 评估脚本 | | **操作系统** | Ubuntu Server 22.04 LTS | — | 所有实验室节点 | ## 📁 仓库结构 ``` zero-trust-network-lab/ | +-- infrastructure/ # Lab network provisioning | +-- ansible/ | | +-- playbooks/ | | | +-- provision_nodes.yml # Provision all lab VMs | | | +-- deploy_wireguard.yml # WireGuard mesh configuration | | | +-- deploy_keycloak.yml # Keycloak IdP deployment | | | +-- deploy_opa.yml # OPA sidecar deployment | | +-- inventory/ | | +-- lab_hosts.ini # Lab VM inventory | +-- terraform/ # Optional cloud lab variant | +-- main.tf | +-- identity/ # Keycloak configuration | +-- realm-export.json # Keycloak realm export (users, roles, clients) | +-- clients/ # OIDC client configurations | +-- mfa_policy.md # MFA enforcement policy docs | +-- network/ # WireGuard micro-segmentation | +-- configs/ | | +-- wg-segment-a.conf # Segment A (web tier) config | | +-- wg-segment-b.conf # Segment B (app tier) config | | +-- wg-segment-c.conf # Segment C (data tier) config | +-- topology.md # Network topology documentation | +-- firewall_rules/ | +-- nftables_baseline.conf # Host-level firewall rules | +-- policies/ # OPA Rego policies | +-- authz/ | | +-- access_control.rego # Core ABAC access control policy | | +-- device_trust.rego # Device posture evaluation | | +-- time_based_access.rego # Time-of-day access restrictions | | +-- risk_score.rego # Dynamic risk-based access decisions | +-- tests/ | | +-- access_control_test.rego # OPA policy unit tests | +-- policy_docs.md # Plain-language policy documentation | +-- gateway/ # Policy enforcement point | +-- nginx.conf # Reverse proxy with OPA integration | +-- opa_sidecar.yml # OPA sidecar Docker config | +-- monitoring/ # Observation plane | +-- suricata/ | | +-- suricata.yaml | | +-- custom_rules/ztna_rules.rules # Custom Suricata ZTNA detection rules | +-- zeek/ | | +-- local.zeek | +-- wazuh/ | | +-- custom_decoders.xml | | +-- ztna_rules.xml | +-- grafana/ | +-- dashboards/ztna_overview.json # Grafana Zero Trust metrics dashboard | +-- evaluation/ # Security evaluation research | +-- pre_zt_assessment/ | | +-- network_scan_results/ # Nmap scans of flat network | | +-- attack_path_analysis.md # Lateral movement paths before ZT | | +-- attack_surface_metrics.csv # Quantified attack surface baseline | +-- post_zt_assessment/ | | +-- network_scan_results/ # Post-implementation scans | | +-- attack_path_analysis.md # Residual attack paths after ZT | | +-- attack_surface_metrics.csv # Post-implementation metrics | +-- attack_simulations/ | | +-- lateral_movement_test.md # Lateral movement test methodology | | +-- credential_stuffing_test.md # Credential attack simulation | +-- evaluation_report/ | +-- zero_trust_evaluation.pdf # Formal IEEE-format security evaluation | +-- zero_trust_evaluation.md # Source markdown | +-- scripts/ # Automation and analysis scripts | +-- attack_surface_analyzer.py # Quantify open ports / exposed services | +-- opa_policy_tester.py # Automated OPA policy test runner | +-- jwt_validator.py # Keycloak JWT token validator | +-- docker-compose.yml # Full lab stack (Keycloak + OPA + Nginx + Monitoring) +-- config.yml # Central lab configuration +-- .env.example # Environment variable template +-- CONTRIBUTING.md +-- LICENSE +-- README.md ``` ## ⚡ 快速开始 ### 前置条件 - 支持虚拟化的 **Linux 主机** (推荐 Ubuntu 22.04) - 用于多 VM 实验室拓扑的 **VirtualBox** 或 **Proxmox** - **Docker & Docker Compose v2** - **Python 3.10+** 和 **Ansible 2.16+** - **WireGuard** 内核模块 (包含在 Linux 内核 >= 5.6 中) - 最低硬件要求：**16 GB RAM**, **4 CPU 核心**, **60 GB 磁盘** ### 步骤 1 — 克隆仓库 ``` git clone https://github.com/ChandraVerse/zero-trust-network-lab.git cd zero-trust-network-lab ``` ### 步骤 2 — 配置环境 ``` cp .env.example .env nano .env ``` ``` # Keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD= KEYCLOAK_REALM=zero-trust-lab # OPA OPA_ADDR=http://localhost:8181 # 网络分段 SEGMENT_A_CIDR=10.0.1.0/24 SEGMENT_B_CIDR=10.0.2.0/24 SEGMENT_C_CIDR=10.0.3.0/24 # 监控 WAZUH_MANAGER_IP=10.0.10.10 ``` ### 步骤 3 — 启动全栈 ``` # 启动 Keycloak、OPA、Nginx gateway 和 monitoring stack docker-compose up -d # 验证所有服务健康状况 docker-compose ps # 访问 Keycloak admin console open http://localhost:8080/admin ``` ### 步骤 4 — 导入 Keycloak Realm ``` # 导入预配置的 realm（包含 users、roles 和 OIDC clients） docker exec -it keycloak /opt/keycloak/bin/kc.sh import \ --file /opt/keycloak/data/import/realm-export.json ``` 这将创建： - **Realm:** `zero-trust-lab` - **Roles:** `analyst`, `engineer`, `admin`, `auditor` - **OIDC Client:** `ztna-gateway` (用于 OPA JWT 验证) - **MFA Policy:** 所有用户必须使用 TOTP ### 步骤 5 — 配置 WireGuard 网段 ``` # 为每个 segment 应用 WireGuard 配置 sudo wg-quick up network/configs/wg-segment-a.conf sudo wg-quick up network/configs/wg-segment-b.conf sudo wg-quick up network/configs/wg-segment-c.conf # 验证 tunnel 是否处于活动状态 sudo wg show ``` ### 步骤 6 — 加载 OPA 策略 ``` # 将 access control policies 加载到 OPA curl -X PUT http://localhost:8181/v1/policies/access_control \ --data-binary @policies/authz/access_control.rego curl -X PUT http://localhost:8181/v1/policies/device_trust \ --data-binary @policies/authz/device_trust.rego # 测试 policy decision curl -X POST http://localhost:8181/v1/data/authz/allow \ -H 'Content-Type: application/json' \ --data '{ "input": { "user": {"role": "analyst", "mfa_verified": true}, "resource": "/api/logs", "method": "GET" } }' # Expected: {"result": true} ``` ### 步骤 7 — 运行攻击面评估 ``` # 基线攻击面扫描（全面 ZT 强制执行之前） python scripts/attack_surface_analyzer.py --mode pre-zt --output evaluation/pre_zt_assessment/ # 全面部署后，运行 post-ZT scan python scripts/attack_surface_analyzer.py --mode post-zt --output evaluation/post_zt_assessment/ # 生成 comparison report python scripts/attack_surface_analyzer.py --mode compare \ --pre evaluation/pre_zt_assessment/attack_surface_metrics.csv \ --post evaluation/post_zt_assessment/attack_surface_metrics.csv ``` ## 🔑 Keycloak 身份提供者 Keycloak 充当**策略信息点 (PIP)** 和**认证机构**，签发下游服务 (OPA, Nginx gateway) 用于做出访问决策的 JWT token。 ### 关键配置 | 功能 | 配置 | |---|---| | **协议** | OpenID Connect (OIDC) + OAuth 2.0 | | **MFA** | 所有角色强制使用 TOTP (基于时间的一次性密码) | | **Token 生命周期** | Access token: 5 分钟 (短期，减少横向移动时间窗口) | | **Claims 映射** | JWT 中的 `role`, `department`, `device_id`, `mfa_verified`, `risk_score` | | **会话策略** | 检测到可疑活动时要求重新认证 | | **用户联邦** | 支持用于企业部署的 LDAP 集成 | ### JWT Token 结构 (示例) ``` { "sub": "analyst@ztlab.local", "realm_access": { "roles": ["analyst"] }, "department": "security_operations", "device_id": "laptop-wg-peer-A3F2", "mfa_verified": true, "risk_score": 2, "iat": 1717257600, "exp": 1717257900, "iss": "http://keycloak:8080/realms/zero-trust-lab" } ``` ## 🔨 WireGuard 微分段 WireGuard 将实验室网络划分为**三个加密隔离的网段**，实现最小权限网络模型。只有经过显式 WireGuard peer 配置授权，网段之间的流量才被允许 —— 不存在隐式的网段间路由。 ### 网段设计 | 网段 | CIDR | 服务 | 允许的 Peers | |---|---|---|---| | **Segment A — Web 层** | `10.0.1.0/24` | Nginx gateway, 面向公网的 APIs | 仅管理网段 | | **Segment B — 应用层** | `10.0.2.0/24` | 应用服务器, 内部 APIs | Segment A (仅限已授权) | | **Segment C — 数据层** | `10.0.3.0/24` | 数据库, 敏感数据存储 | Segment B (仅限已授权) | | **Management** | `10.0.10.0/24` | Keycloak, OPA, Wazuh, Prometheus | 仅 Admin peers | ### 为什么 WireGuard 适用于零信任？ - **加密 Peer 认证** — 只有拥有有效私钥的节点才能加入网段 - **最小的内核攻击面** — 约 4,000 行代码，相比之下 OpenVPN 约有 100,000 行 - **无隐式路由** — 必须为每个 Peer 显式配置 `AllowedIPs` - **自 Linux 内核 5.6 起内置** — 无需额外的内核模块或驱动程序 ## 📜 OPA 策略执行 Open Policy Agent 在每个请求处执行**基于属性的访问控制 (ABAC)**，消费来自 Keycloak 的 JWT claims 并应用 Rego 策略以返回 `allow` 或 `deny` 决策。 ### 核心访问策略 (Rego) ``` package authz import future.keywords.if import future.keywords.in # 默认拒绝：Zero Trust 要求显式允许 default allow := false # 如果满足所有条件则允许 allow if { token_valid role_permitted device_trusted not risk_too_high time_permitted } # 验证 JWT（Keycloak public key） token_valid if { io.jwt.verify_rs256(input.token, data.jwks) [_, payload, _] := io.jwt.decode(input.token) payload.iss == "http://keycloak:8080/realms/zero-trust-lab" payload.exp > time.now_ns() / 1e9 payload.mfa_verified == true } # Role 必须被允许访问请求的 resource + method role_permitted if { allowed_roles := data.resource_permissions[input.resource][input.method] input.claims.role in allowed_roles } # Device 必须具有活动的 WireGuard peer registration device_trusted if { data.trusted_devices[input.claims.device_id] } # 阻止超过 risk threshold 的请求 risk_too_high if { input.claims.risk_score > 7 } # 基于时间的访问限制（仅限 business hours 访问敏感数据） time_permitted if { not sensitive_resource(input.resource) } time_permitted if { sensitive_resource(input.resource) hour := time.clock(time.now_ns())[0] hour >= 8 hour < 18 } sensitive_resource(resource) if { startswith(resource, "/api/data") } ``` ## 📊 攻击面评估 正式评估比较了实验室网络在两种状态下的情况： ### 评估方法 **第一阶段 — 零信任实施前基线** - 传统扁平网络：所有服务位于共享 L2，无身份验证 - 攻击面量化方法：Nmap 端口扫描、攻击路径分析 (Bloodhound 风格的横向移动映射)、可访问服务计数 **第二阶段 — 零信任实施后** - 相同的服务部署在 Keycloak + OPA + WireGuard 分段之后 - 应用相同的量化方法 **第三阶段 — 正式评估报告** - NIST SP 800-207 合规性评估 - 针对每个零信任组件的 STRIDE 威胁模型 - 包含百分比改进的量化指标表 ### 评估结果示例 | 指标 | ZT 实施前 | ZT 实施后 | 改进 | |---|---|---|---| | 暴露端口 (外部) | 47 | 3 | **−93.6%** | | 未认证的服务端点 | 23 | 0 | **−100%** | | 横向移动路径 | 18 | 2 | **−88.9%** | | 网段间路由 (开放) | 12 | 0 | **−100%** | | 无需凭据的访问路径 | 8 | 0 | **−100%** | | 策略决策点 | 0 | 6 | **+6 个执行点** | ### 研究成果 `evaluation/evaluation_report/zero_trust_evaluation.pdf` 包含一份完整的 IEEE 格式论文，涵盖： 1. 引言与动机 2. 相关工作 (NIST SP 800-207, BeyondCorp) 3. 系统设计与实现 4. 评估方法 5. 结果与分析 6. 结论与未来工作 **目标发表 venue：** - IEEE Security & Privacy Magazine - ACM CCS Workshop on Zero Trust Security - USENIX LISA - arXiv cs.CR (开放获取预印本) ## 🔄 复现此环境 1. 克隆仓库并安装前置条件 2. 启动堆栈：`docker-compose up -d` 3. 导入 Keycloak realm：`realm-export.json` 4. 配置 WireGuard 网段：为每个配置运行 `wg-quick up` 5. 通过 REST API 加载 OPA 策略 6. 运行实施 ZT 前的攻击面扫描 7. 在 Nginx gateway 中启用完整的策略执行 8. 运行实施 ZT 后的攻击面扫描 9. 使用 `attack_surface_analyzer.py --mode compare` 对比结果 10. 查看 `evaluation/evaluation_report/zero_trust_evaluation.pdf` ## ⚠️ 道德与法律 | 原则 | 详情 | |---|---| | **仅限实验室环境** | 所有攻击模拟均在无外网访问的隔离 VM 上执行 | | **禁止生产环境测试** | 未经明确授权，切勿在生产环境或真实网络上运行评估脚本 | | **CVE 负责任的漏洞披露** | 在 Keycloak/OPA/WireGuard 中发现的任何漏洞均通过官方渠道报告 | | **合规说明** | 本实现参考了 NIST SP 800-207，但不构成经认证的合规性评估 | ## 📜 许可证 - **源代码** — [MIT License]() - **研究成果** (评估报告, 数据集) — [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) ``` @misc{chakraborty2025zerotrust, author = {Chakraborty, Chandra Sekhar}, title = {Zero Trust Network Access Implementation and Evaluation Lab}, year = {2025}, publisher = {GitHub}, howpublished = {\url{https://github.com/ChandraVerse/zero-trust-network-lab}} } ```

由 Chandra Sekhar Chakraborty 用 🔒 制作
安全运营  ·  零信任研究员  ·  有志于 SOC 分析师

🌐 作品集  ·  💻 GitHub  ·  🔗 LinkedIn

如果这个实验室对您有帮助，请考虑给它一个 ⭐

标签：DevSecOps, Keycloak, Metaprompt, NIST SP 800-207, OPA, Python, Streamlit, VPN, WireGuard, 上游代理, 单点登录, 安全合规, 安全实验室, 安全评估报告, 微分段, 攻击面评估, 无后门, 策略即代码, 系统提示词, 网络代理, 网络安全, 网络隔离, 聊天机器人安全, 自定义请求头, 访问控制, 请求拦截, 逆向工具, 隐私保护, 零信任架构, 靶场