Diegoservadio/azure-hub-spoke-lab

# Azure Hub-Spoke 网络实验室 生产级 Hub-Spoke 网络拓扑，构建于 Microsoft Azure 之上，完全通过 Terraform 进行配置部署。 演示企业级标准网络模式和三层安全微隔离。  ## 为什么做这个项目 Hub-Spoke 是企业 Azure 部署的参考网络拓扑 —— 几乎被所有意大利和欧盟云提供商（Aruba、Fastweb、Equinix、Claranet、NTT DATA）使用。本实验室端到端地实现了带有安全控制的这种模式，并全部编写为可复用的 Terraform 模块。 目标是：构建一个能够展示真实云基础设施技能的作品集项目 —— 而不是一个复制粘贴的教程。 ## 架构概述 | 组件 | 地址空间 | 用途 | |-----------|---------------|---------| | **Hub VNet** | `10.0.0.0/16` | 集中式共享服务及未来的混合连接 | | **Spoke VNet** | `10.1.0.0/16` | 带有 3 层子网布局的隔离工作负载网络 | | **VNet Peering** | 双向 | 启用了网关传输的 Hub <-> Spoke 路由 | | **NSGs** | 每层 | 微隔离：web -> app -> db | ### Hub VNet 子网 - `AzureBastionSubnet` (`10.0.1.0/26`) — 为 Azure Bastion 服务保留的名称 - `GatewaySubnet` (`10.0.2.0/27`) — 为 VPN/ExpressRoute 网关保留的名称（主动为未来的混合连接分配） - `snet-shared-services` (`10.0.10.0/24`) — DNS、监控、跳板机 ### Spoke VNet 子网（3 层模式） - `snet-web-workload` (`10.1.1.0/24`) — NSG 允许来自 Internet 的 HTTPS，以及仅来自 Bastion 的 SSH - `snet-app-workload` (`10.1.2.0/24`) — NSG 仅允许来自 Web 层的应用端口 (8080)；显式拒绝来自 Internet 的访问 - `snet-db-workload` (`10.1.3.0/24`) — NSG 仅允许来自应用层的数据库端口 (5432)；显式拒绝来自 Internet 和 Web 层的访问（纵深防御） ## 技术栈 - **Terraform** `>= 1.14` - **azurerm provider** `~> 4.0` - **Azure CLI** 用于身份验证 - 兼容 Azure **免费套餐** ## 项目结构 azure-hub-spoke-lab/ ├── terraform/ │ ├── modules/ │ │ ├── hub/ # 可复用的 hub VNet 模块 │ │ └── spoke/ # 可复用的 spoke VNet + NSGs 模块 │ └── environments/ │ └── dev/ # 开发环境组合 ├── diagrams/ │ └── architecture.svg # 架构图 └── docs/ # 架构决策记录 ## 快速开始 ### 前置条件 - Azure 订阅（免费套餐即可） - 已完成身份验证的 Azure CLI（`az login`） - Terraform 1.14+ ### 部署 ``` cd terraform/environments/dev cp terraform.tfvars.example terraform.tfvars # 使用你的 subscription_id 编辑 terraform.tfvars terraform init terraform plan terraform apply ``` ### 销毁 ``` terraform destroy ``` ## 设计决策 **为什么将 `hub` 和 `spoke` 分为不同的模块？** 每个环境中 hub 是唯一的；spokes 是可重复的。将它们保持为独立的模块，允许不同的 spoke（dev、prod、staging）共享同一个 hub，而无需代码重复。 **为什么对等互连在环境中定义，而不是在模块中？** 对等互连在两个模块之间创建了依赖关系。在环境级别定义它可以保持 `hub` 和 `spoke` 模块的独立性和可复用性。 **为什么在数据库 NSG 上有显式的 `Deny-From-WebTier` 规则？** 纵深防御。即使 spoke 的 web 和 db 子网位于同一个 VNet 中，显式的拒绝规则也能确保 db 不会被 web 层访问，即使未来的更改意外引入了路由也是如此。该规则也可作为审计文档。 **为什么在未创建实际网关的情况下创建了 `GatewaySubnet`？** 预先分配保留子网是最佳实践 —— 以后添加网关无需更改 VNet。根据 Microsoft 大小调整指南，CIDR 大小调整为 `/27`（32 个地址）。 ## 展示的技能 - Azure 网络：VNets、子网、对等互连、NSGs、地址空间规划 - 云采用框架命名规范 - Terraform：模块、变量、输出、依赖图 - 3 层安全架构和微隔离 - 纵深防御设计模式 - 基础设施即代码最佳实践：状态管理、机密处理、模块可复用性 ## 路线图 - [ ] 添加第二个 spoke（生产环境） - [ ] 在现有的 Bastion 子网中部署 Azure Bastion - [ ] 添加虚拟机工作负载（web、app、db 层） - [ ] 将状态迁移到远程后端（带状态锁定的 Azure 存储） - [ ] 添加 GitHub Actions，在 PR 时执行 `terraform fmt` / `validate` / `plan` - [ ] 用 Azure Firewall 替换简单的对等互连，以实现传递路由 ## 作者 **Diego Servadio** 云与安全工程学生 — ITS Tech Talent Factory，米兰

标签：Azure, Bastion, CISA项目, EC2, ECS, Hub-Spoke架构, IaC, NSG, SRE, Terraform, VNet Peering, VPN网关, 三层架构, 云计算, 企业网络, 偏差过滤, 微软云, 微隔离, 插件系统, 架构设计, 流量捕获, 混合云, 网络分段, 网络安全, 网络安全实验, 网络拓扑, 规则引擎, 隐私保护