Ivos1991/network-security-automation-framework

# 网络安全自动化框架 本仓库演示了一种以网络安全为重点的自动化方法，用于通过两条协调的路径验证一个小型零信任实验室： - 用于管理平面加固的模拟实时验证路径 - 用于分段意图的真实 Batfish 支持的离线验证路径 该架构有意保持精简。它明确区分了 service/API/request，使用共享的实验室资产来关联这两条路径，并将范围限制在几个对于作品集仓库而言可信的确定性场景。 ## 项目摘要 已实现的验证切片： - 通过模拟的 Scrapli 风格后端进行实时设备加固验证 - 通过真实的 Batfish `testFilters` 查询进行离线分段验证 - 混合合规性关联，用于对比预期策略、离线评估和实时态势 - 用于混合合规性报告的紧凑套件级聚合 已验证的离线分段场景： - `user_subnet -> restricted_subnet = deny` - `admin_subnet -> restricted_subnet = allow` 已验证的混合结果： - 一致的预期/离线/实时快乐路径 - 确定性的离线侧不匹配 - 确定性的实时侧不匹配 ## 架构概览 ``` network-security-automation-framework/ |-- docs/ |-- labs/ | |-- current_lab.yaml | `-- snapshots/ |-- src/ | |-- framework/ | | |-- config/ | | |-- models/ | | `-- reporting/ | |-- integration/ | |-- live/ | |-- offline/ | `-- validators/ |-- tests/ | |-- integration_tests/ | |-- live_tests/ | `-- offline_tests/ |-- conftest.py |-- pytest.ini `-- README.md ``` ### 分层模型 - `*_service.py` 编排请求构建、后端执行和验证器调用。 - `*_service_api.py` 仅拥有面向后端的执行细节。 - `*_service_request.py` 构建请求负载和过滤条件。 - validators 对规范化证据断言含义，而不是原始运行时输出。 - tests 拥有套件元数据、Allure 附件和场景断言。 这保持了当前架构的小巧、可读性，并在实时、离线和混合切片中保持一致。 ## 双路径验证模型 ### 实时路径 目的： - 验证管理平面加固预期 - 在不需要真实网络硬件的情况下生成确定性证据 当前状态： - 后端是模拟的 - 运行配置从配置默认值或显式覆盖中加载 - 加固检查验证 SSH 的存在、Telnet 的不存在以及登录横幅的存在 ### 离线路径 目的： - 在实时部署之前验证预期的分段行为 - 从仓库安全的快照中证明策略意图 当前状态： - 后端使用真实的 PyBatfish - 快照存储在 `labs/snapshots/zero_trust_lab/` 中 - 两个已实现的场景使用 Batfish `testFilters` ### 混合合规性模型 混合切片关联： - 来自共享实验室资产的预期访问规则 - 来自 Batfish 支持路径的离线分段结果 - 来自模拟实时路径的实时管理平面态势 这些输入被规范化为 `HybridComplianceStatus`，它支持： - 通过/失败合规性结果 - 显式的不匹配类型 - 简洁的 Allure 报告 - 小型套件级聚合摘要 ## 什么是真实的 vs 模拟的 本仓库中真实的部分： - Batfish 支持的离线分段验证 - 检入到 `labs/snapshots/` 的 Batfish 快照资产 - 用于自动回归和报告的 GitHub Actions 执行形态 设计上模拟的部分： - 实时设备连接 - Scrapli/Nornir 执行 - 更广泛的基础设施编排 - 大型拓扑扩展 这是有意为之。该仓库展示了面向后端的 QA 自动化设计，而不假装端到端地自动化生产基础设施。 ## 共享实验室资产 [labs/current_lab.yaml](labs/current_lab.yaml) 中的当前实验室资产驱动： - 分段名称和 CIDR - 预期的管理平面态势 - 用于混合验证的预期访问规则 - 离线分段预期 - 用于真实离线路径的 Batfish 场景元数据 该共享模型在实时、离线和混合报告中保持标识符一致。 ## 技术栈 - Python 3 - `pytest` - `allure-pytest` - `pydantic` - `pyyaml` - `pybatfish` - 用于本地 Batfish 运行时的 Docker ## 设置 安装依赖： ``` python -m pip install -r requirements.txt ``` [.env.example](.env.example) 中提供了示例环境默认值。 ## 运行测试 运行整个仓库： ``` python -m pytest -q ``` 仅运行离线切片： ``` python -m pytest tests/offline_tests -q ``` 仅运行集成切片： ``` python -m pytest tests/integration_tests -q ``` 重要的运行时说明： - 离线路径在测试执行期间启动并重用本地 `batfish/allinone` Docker 容器 - 实时路径保持模拟状态，不需要设备访问 ## Allure 报告 生成结果： ``` python -m pytest -q --alluredir=allure-results ``` 打开本地报告： ``` allure serve allure-results ``` 生成静态输出： ``` allure generate allure-results --clean -o allure-report ``` 当前报告形态保持紧凑： - 共享实验室上下文 - 实时验证证据 - 离线可达性和 Batfish 摘要 - 混合合规性证据 - 套件级混合聚合摘要 ## CI/CD 概览 包含的工作流： - `PR Validation` 为针对 `main` 的 pull request 和推送运行精简的 pytest 套件。 - `Manual Run` 允许您使用自定义 pytest 目标和参数手动触发仓库测试套件。 - `Run Suite` 可重用工作流，用于安装依赖、拉取 Batfish、运行 pytest 并上传 Allure 结果。 流水线行为： - 从 `requirements.txt` 安装 Python 依赖 - 预拉取 `batfish/allinone` 以便离线验证可以快速启动 - 运行与本地相同的 pytest 套件 - 将 Allure 结果作为构建产物上传 ## 本仓库演示了 - 面向后端的自动化设计，而不是繁重的 UI 覆盖 - 文档优先的工程纪律 - 具有明确范围控制的确定性测试策略 - 通过 Batfish 进行真实的离线策略验证 - 用于跨路径比较的规范化合规性建模 - 适合大规模 CI 执行的简洁报告 - 模拟基础设施与真实基础设施之间的诚实分离 ## 支持文档 - [实施计划](docs/implementation-plan.md) - [目标架构](docs/target-architecture.md) - [实时 vs 离线验证](docs/live-vs-offline-validation.md) - [报告和 CI](docs/reporting-and-ci.md) - [编码标准](docs/coding-standards.md)

标签：Allure, Batfish, DevSecOps, JSONLines, pytest, Python, Scrapli, Service-Oriented Architecture, SOA, 上游代理, 在线验证, 意图验证, 无后门, 模块化架构, 混合合规报告, 离线分析, 策略验证, 管理平面加固, 网络分段, 网络安全框架, 网络安全测试, 网络安全自动化, 自动化运维, 请求拦截, 逆向工具, 零信任