olmidej-a11y/layicorp-platform-governannce

# LayiCorp 云治理与 Landing Zone ## 概述 本项目实现了一个具有真实治理、安全网络和受控工作负载部署的 Azure Landing Zone。它使用 Azure Bicep、Azure Policy 和用于 RBAC 审计的 PowerShell 自动化构建。 该环境旨在反映真实的 Azure 平台模式，包括： - Hub and spoke（中心辐射）网络架构 - 集中式防火墙和共享服务 - 部门级 Spoke（IT, HR, SM） - 通过 Azure Policy 进行标记和安全强制执行 - 工作负载 VM 加入到受监管的 Spoke 中 - 备份和 RBAC 审计自动化 Landing Zone 从平台层向下强制执行安全和运营标准，确保部署到环境中的任何工作负载自动继承治理、分段和访问控制。 ## 为什么这很重要 如果没有受监管的 Landing Zone，Azure 环境会变得不一致、难以保护且难以扩展。 本项目展示了如何将网络、策略执行、安全工作负载加入和 RBAC 审计结合到一个结构化的 Azure 平台基础中。 ## 架构 平台遵循 Hub and Spoke（中心辐射）拓扑。Hub 托管共享安全服务。每个 Spoke 代表一个拥有独立地址空间和子网的部门。 每个 Spoke 都可以独立扩展，但所有检查、路由和共享服务仍集中在 Hub 中，这符合 Microsoft 的 Cloud Adoption Framework Landing Zone 标准。 ``` flowchart LR subgraph Hub["Hub VNet (Shared Services)"] FW["Azure Firewall"] end subgraph ITSpoke["IT Spoke VNet"] ITFE["Frontend Subnet"] ITBE["Backend Subnet"] ITDB["Database Subnet"] VM["Workload VM (vm-it-app01)"] end subgraph HR["HR Spoke VNet"] HRFE["Frontend Subnet"] HRBE["Backend Subnet"] HRDB["Database Subnet"] end subgraph SM["SM Spoke VNet"] SMFE["Frontend Subnet"] SMBE["Backend Subnet"] SMDB["Database Subnet"] end ITFE --> VM VM --> ITBE ITBE --> ITDB Hub <--> ITSpoke Hub <--> HR Hub <--> SM ``` 选择 Hub-and-spoke 架构是因为它在 Hub 中集中了安全性、路由和共享服务，同时将每个部门隔离在其自己的 Spoke 中。这符合多团队或多租户环境的企业最佳实践。 这提供了： - 部门之间的隔离 - 安全和检查的中心阻塞点 - 东西向和南北向流量的清晰路径 ## 网络基础 网络使用位于 infra/networking 的 Bicep 模板进行部署。 网络架构作为 Landing Zone 的骨干。它确保工作负载的分段、集中的安全检查以及通过 Hub 的一致路由。此结构限制了横向移动，确保了跨部门职责的清晰分离，并通过防火墙实现可预测的路由以进行检查和日志记录。 ### 典型结构： ``` infra/ networking/ hub.bicep spoke-hr.bicep spoke-it.bicep spoke-sm.bicep peerings.bicep modules/ vnet.bicep nsg.bicep subnet.bicep firewall.bicep parameters/ hub.parameters.json spoke-hr.parameters.json spoke-it.parameters.json spoke-sm.parameters.json ``` 首先执行 Hub 部署以建立共享服务（如 Azure Firewall）。然后独立部署每个 Spoke，并将其与 Hub 对等互连，以保持 HR、IT 和 SM 工作负载之间的隔离。 网络部署负责： - Hub 虚拟网络 - IT、HR 和 SM Spoke 虚拟网络 - 用于前端、后端和数据库的子网 - Hub 和 Spoke 之间的 VNet 对等互连 - Hub 中的 Azure Firewall 这符合常见的 Azure Landing Zone 模式，可以在其他订阅或环境中重用。 ## 工作负载部署 IT 部门有一个工作负载 VM，使用 Bicep 部署到 IT Spoke 中。 ### 示例结构： ``` infra/ workload/ it-vm.bicep it-vm.parameters.json ``` 该 VM 具有： - 仅私有 IP - 位于 IT Spoke 前端子网中的网络接口 - 仅允许来自 Azure Bastion 的 RDP 的 NSG - 无面向互联网的 RDP 或 SSH - 作为参数传递的凭据 这种工作负载部署模式成为进入平台的所有未来应用程序的蓝图，确保一致的安全态势和集中的治理。 ## 治理 治理在网络基础部署后应用。在基础部署后应用治理是本项目的有意安排。它允许环境显示不合规的资源，以用于演示和审计目的，这在面试、演示和教育场景中非常有用。在真实的生产 Landing Zone 中，这些策略通常会在工作负载部署之前应用，以尽早阻止违规。 ### 标记强制执行 资源上需要以下标记。如果缺少或为空，则拒绝部署： - Owner - Environment - CostCenter ### 网络和安全控制 - 禁止将 RDP、SSH 或 WinRM（端口 3389、22、5985、5986）暴露给互联网的 NSG 规则。 - 公共 IP 使用仅限于批准的服务，如 Firewall、Bastion、VPN Gateway、Load Balancer 和 Application Gateway。 - 除非策略明确允许，否则 VM NIC 不能接收公共 IP 地址。 ### 资源组和资源因缺少标记而被审计 这些策略确保 Landing Zone 持续应用元数据，限制开放的管理端口，并清晰地查看不合规资源。 一旦应用，这些策略将在整个环境中强制执行操作纪律。 ## 备份和恢复 配置了一个 Recovery Services Vault 以保护 IT 工作负载 VM。 配置包括： - 每日备份策略 - 工作负载 VM 注册为受保护项 - 至少一个成功的备份作业 - 证明在需要时可以恢复的证据 这表明平台不仅已部署，而且在操作上已准备就绪。 ## RBAC 审计自动化 使用基于 PowerShell 的审计脚本审查和导出基于角色的访问控制。这确保了特权访问被记录，并且不会无意中授予过多的权限。 文件 scripts/rbac-audits.ps1 对订阅运行 RBAC 审计。 它生成： - 所有角色分配的 CSV - 高特权角色（如 Owner、Contributor 和 Security Admin）的 CSV - 直接用户分配的 CSV - 来宾用户分配的 CSV - 导出文件写入 exports 文件夹，该文件夹被 git 排除，以避免泄露任何特定于租户的数据。 这为治理团队提供了一种可重复的审查访问权限的方法，并支持合规性审计。 ## 影响 - 实施了具有 Hub-and-spoke 分段和集中安全控制的受监管 Azure Landing Zone - 使用 Azure Policy 强制执行标记、网络安全和公共访问限制 - 实现了将安全工作负载加入到受控 Spoke 环境中 - 通过 VM 备份和 RBAC 审计自动化增加了操作就绪性 - 展示了如何将云治理和平台控制从基础层构建到 Azure 环境中 ## 仓库结构 ``` infra/ networking/ hub.bicep peerings.bicep spoke-hr.bicep spoke-it.bicep spoke-sm.bicep modules/ firewall.bicep nsg.bicep subnet.bicep vnet.bicep parameters/ hub.parameters.json spoke-hr.parameters.json spoke-it.parameters.json spoke-sm.parameters.json workloads/ it-vm.bicep it-vm.parameters.json policy/ require-tag-owner.json require-tag-environment.json require-tag-costcenter.json deny-open-nsg.json audit-rg-missing-tags.json initiative-baseline.json scripts/ rbac-audits.ps1 exports/ (gitignored) README.md ``` 这种结构将治理、网络和工作负载关注点分开，允许每一层独立演进。它还反映了企业模式，即团队维护独立的模块，但通过标准化的管道进行部署。每个文件夹都设计为可重用、模块化且易于集成到 CI/CD 工作流中。 其意图是明确分离基础设施、治理和自动化。 ## 部署 部署遵循分阶段方法，反映了本项目使用的实际顺序。网络和工作负载先部署，之后再应用治理，以便为了演示目的仍然可以部署不合规的资源。 ### 1. 创建资源组 ``` az group create --name RG-LayiCorp-Network --location westeurope az group create --name RG-LayiCorp-IT --location westeurope ``` ### 2. 部署 Hub VNet 和防火墙 ``` az deployment group create \ --resource-group RG-LayiCorp-Network \ --template-file ./infra/networking/hub.bicep \ --parameters @./infra/parameters/hub.parameters.json ``` ### 3. 部署三个 Spoke VNet IT Spoke： ``` az deployment group create \ --resource-group RG-LayiCorp-Network \ --template-file ./infra/networking/spoke-it.bicep \ --parameters @./infra/parameters/spoke-it.parameters.json ``` HR Spoke： ``` az deployment group create \ --resource-group RG-LayiCorp-Network \ --template-file ./infra/networking/spoke-hr.bicep \ --parameters @./infra/parameters/spoke-hr.parameters.json ``` SM Spoke： ``` az deployment group create \ --resource-group RG-LayiCorp-Network \ --template-file ./infra/networking/spoke-sm.bicep \ --parameters @./infra/parameters/spoke-sm.parameters.json ``` ### 4. 在 Hub 和 Spoke 之间部署 VNet 对等互连 ``` az deployment group create \ --resource-group RG-LayiCorp-Network \ --template-file ./infra/networking/peerings.bicep ``` 部署 Hub 和 Spoke 后，您应该看到： - 1 个带有防火墙和共享子网的 Hub 虚拟网络 - 3 个 Spoke VNet（HR、IT、SM） - 成功的 VNet 对等连接（仅 Spoke 到 Hub） - 与部门特定 IP 范围匹配的子网 ### 5. 将 IT 工作负载 VM 部署到 IT Spoke 中 ``` az deployment group create \ --resource-group RG-LayiCorp-IT \ --template-file ./infra/workloads/it-vm.bicep \ --parameters @./infra/workloads/it-vm.parameters.json ``` 这会将 vm-it-app01 放置在 vnet-spoke-it-layicorp 前端子网中，并配备私有 NIC 和仅允许来自 Bastion 的 RDP 的 NSG。 ### 6. 从仓库定义创建计划策略 ``` az policy set-definition create \ --name layicorp-baseline-governance \ --definition ./policy/initiative-baseline.json ``` 然后将其分配在订阅范围： ``` az policy assignment create \ --name layicorp-baseline-governance-assignment \ --policy-set-definition layicorp-baseline-governance \ --scope /subscriptions/ ``` ### 7. 运行 RBAC 审计脚本 从仓库根目录： ``` ./scripts/rbac-audits.ps1 -SubscriptionId ``` 这将把 CSV 写入 exports 文件夹。 ## 验证 验证步骤证明 Landing Zone 不仅已部署，而且受到治理、保护并完全运行。 为此项目收集的证据包括： - 资源组概览 - Hub 和 Spoke VNet 配置 - Azure Firewall 部署 - VNet 对等互连状态 - 策略计划和策略定义视图 - 显示不合规资源的策略合规性视图（由于部署顺序，这是预期的） - VM 概览和网络，显示无公共 IP - 证明管理端口受到限制的 NSG 入站规则 - VM 的 Recovery Services Vault 和备份状态 - 按资源组分组的成本分析 - RBAC 审计脚本的终端输出和导出的 CSV 文件 这些验证点表明平台已部署、受治理且可运行，而不仅仅是理论上的。 ## 总结 本项目展示了如何构建 Azure Landing Zone，并将治理、分段和操作控制从平台层向下嵌入。它将网络、策略执行、工作负载加入、备份和 RBAC 审计结合到一个可重用的 Azure 基础中。

标签：AI合规, Azure, Azure Firewall, Azure Policy, Azure虚拟网络, Bicep, CAF, EC2, Hub-and-Spoke, IaC, IPv6, IT运维, Landing Zone, PowerShell, RBAC审计, Socks5代理, 云治理, 云采用框架, 企业云架构, 基础架构即代码, 备份自动化, 安全合规, 混合云, 网络代理, 网络安全, 虚拟机入驻, 资源标签, 身份与访问管理, 隐私保护