kakshaykumar/cloud-security-iaas

GitHub: kakshaykumar/cloud-security-iaas

对 Azure 和 GCP 的 IaaS 默认安全配置进行系统性对比评估,揭示两大平台在 IAM、存储、加密和日志方面的关键缺陷并提供基于 CIS 与 NIST 标准的加固建议。

Stars: 0 | Forks: 0

# 评估默认 IaaS 配置的安全态势:Azure vs Google Cloud *(云安全评估负责人 — IAM、网络安全与建议)* ## 概述 大多数云安全事件并非始于复杂的攻击——而是始于某人在部署资源时使用了默认设置,却不了解这些默认设置的实际含义。本项目旨在评估 Microsoft Azure 和 Google Cloud Platform (GCP) 中基础设施即服务 配置的默认安全态势,目的是准确找出这些默认设置的不足之处,以及需要采取哪些措施来修复它们。 我们的团队在两个平台上仅使用默认设置配置了虚拟机和云存储,然后从四个维度对每个平台进行了系统性评估:IAM 和网络控制、存储安全、日志记录与监控,以及加密。最终结果是基于直接证据的对比,展示了每个平台为你提供的初始安全状态——以及在你认为其足够安全之前,还需要自己做哪些工作。 这与真实的企业云部署息息相关。组织通常假设“云原生”意味着“默认安全”。本项目确切地展示了为什么这种假设在两个平台上都是错误的——并记录了需要更改的具体配置。 ## 仓库结构 ``` cloud-security-iaas/ │ ├── README.md ← You are here │ ├── docs/ │ ├── IaaS-Security-Posture-Azure-vs-GCP.pdf ← Full research report │ ├── IaaS-Security-Posture-Presentation.pdf ← Presentation deck (presented April 2025) │ ├── analysis/ │ ├── vm-configuration-comparison.md ← Azure vs GCP VM defaults side-by-side │ ├── storage-security-comparison.md ← Storage access, encryption, public access defaults │ ├── key-management-comparison.md ← PMK vs CMK/CMEK, Key Vault vs Cloud KMS │ └── logging-monitoring-gaps.md ← Default logging gaps and what they miss │ ├── recommendations/ │ └── hardening-checklist.md ← Actionable hardening steps for both platforms │ ├── references.md ← All sources and frameworks referenced └── CHANGELOG.md ← Version history and last-validated dates ``` ## 如何复现此评估 以下前置条件和步骤用于进行分析。随着 Azure 和 GCP 随时间更新其默认配置,结果可能会有所不同——有关本仓库中发现的验证日期,请参见 `CHANGELOG.md`。 **前置条件:** - 有效的 Azure 订阅(免费层即可——B1s VM 在免费层限制内) - 有效的 GCP 账户(免费层即可——e2-micro VM 在免费层限制内) **Azure 步骤:** 1. 登录 [portal.azure.com](https://portal.azure.com) 2. 在首选区域(例如 East US)创建新的 Resource Group 3. 使用 Azure Marketplace 默认的 Ubuntu 22.04 镜像部署 B1s VM——接受所有网络默认设置(这将自动创建一个 NSG) 4. 部署 Azure Blob Storage 账户——注意,公共访问默认是**启用**的 5. 导航到 Azure Monitor → NSG Flow Logs 并确认它们默认是**关闭**的 6. 导航到 Defender for Cloud 并记录在无自定义配置情况下的 Secure Score 基线 **GCP 步骤:** 1. 登录 [console.cloud.google.com](https://console.cloud.google.com) 2. 创建一个新项目 3. 通过 Compute Engine 使用默认 Debian 镜像部署 e2-micro VM——接受所有网络默认设置(注意默认的 service account 分配) 4. 部署 Cloud Storage 存储桶——注意,公共访问默认是**阻止**的 5. 导航到 VPC Network → Flow Logs 并确认它们默认是**关闭**的 6. 导航到 Security Command Center 并检查默认的发现结果态势 ## 关键发现 ### Azure — 默认配置缺陷 | 领域 | 默认状态 | 风险 | |---|---|---| | NSG Flow Logs | **已禁用** | 无网络流量可见性——横向移动无法被检测 | | Blob Storage 的公共访问 | **已启用** | 除非明确限制,否则存储容器可被公开访问 | | 双重加密 | **已禁用** | 仅限平台管理的密钥——默认无客户密钥控制 | | VM 监控 / 诊断 | **可选** | 启动诊断和性能指标需要手动激活 | | Managed Identity 权限 | **权限过高** | 默认角色分配超出了最小权限原则的要求 | | 日志保留 | 30 天 (Activity Logs),最长 90 天 (部分 Log Analytics 表) | 无法满足 PCI-DSS(12 个月)、HIPAA(6 年)要求 | ### GCP — 默认配置缺陷 | 领域 | 默认状态 | 风险 | |---|---|---| | VPC Flow Logs | **已禁用** | 与 Azure 相同的网络可见性盲区——异常流量不会被记录 | | Data Access Audit Logs | **已禁用** | 默认不记录谁读取或修改了存储数据的日志 | | 默认 Service Account 权限 | **Editor 级别** | 广泛的项目级权限——巨大的权限提升攻击面 | | CMEK (Customer-Managed Keys) | **未启用** | 默认使用 Google 管理的密钥——无客户密钥生命周期控制 | | 防火墙规则日志记录 | **已禁用** | 除非手动配置,否则不记录防火墙活动 | | 日志保留 | **默认 30 天** | 可以通过 Cloud Storage 路由进行扩展,但需要手动设置 | ### GCP 默认设置占优的方面 - Cloud Storage 的公共访问默认被**禁用**——而 Azure 是启用的 - IAM 原生支持对象级策略——无需 SAS token - 日志可以路由到 Cloud Storage,以实现经济高效的 30 天以上长期保留(Azure 路由到 Log Analytics Workspace 的每 GB 成本更高) - Workload Identity Federation 消除了长期有效的 service account 密钥 ### Azure 默认设置占优的方面 - 原生集成 Microsoft Sentinel SIEM——GCP 上的 Chronicle 需要额外设置 - Microsoft Entra ID + RBAC 提供深度的混合企业身份管理 - 双重加密选项(尽管默认未启用) - 与企业合规工具(Compliance Manager、Secure Score)紧密集成 ## 共担责任模型的实践 Azure 和 GCP 均遵循**共担责任模型**——这是云安全的一项基本原则,界定了云提供商负责保护的内容与客户自身责任的范围。在 IaaS 环境中,提供商负责处理物理基础设施、Hypervisor 安全和网络硬件。在此之上的所有内容——操作系统配置、IAM 策略、加密密钥管理、网络日志记录和应用程序安全——均由客户负责。 本项目本质上是对这一边界的深入探索。两个平台上的默认配置代表了提供商代表你执行的最低限度操作。本项目记录的每一个缺陷——禁用的流日志、权限过高的 service account、平台管理的加密密钥——都是客户责任开始的环节,也是组织经常因为假设云“默认安全”而未能做好的地方。 事实并非如此。默认设置只是一个起点,而非最终的防御态势。 ## 底线结论 在任何有意义的企业意义上,这两个平台都没有做到“默认安全”。默认设置是起跑线,而不是终点线。两者都需要执行相同的基本强化步骤: 1. 启用网络流日志(Azure 上的 NSG Flow Logs,GCP 上的 VPC Flow Logs) 2. 限制存储的公共访问 3. 将 service account 和 managed identity 的权限范围缩小到最小权限 4. 启用 Customer-Managed Encryption Keys 5. 配置 SIEM 集成并自定义警报阈值 6. 延长日志保留期以满足合规性要求 有关特定平台的完整检查清单,请参见 [`recommendations/hardening-checklist.md`](recommendations/hardening-checklist.md)。 ## 展示的技能与概念 - Azure 和 GCP 上的云基础设施开通 - IaaS 安全配置评估 - IAM 设计 — RBAC、ABAC、service account、managed identity - 静态和传输中的加密 — AES-256、CMEK、CSEK、密钥管理 - 云日志记录和监控 — Azure Monitor、Microsoft Sentinel、Cloud Logging、SCC - CIS Benchmarks (v3.0.0) 和 NIST 框架对齐 - 比较安全分析与风险记录文档化
标签:CIS Benchmarks, GCP, GitHub Advanced Security, Google Cloud Platform, IaaS安全, IAM安全, KMS, Microsoft Azure, NIST, 云计算, 云部署, 企业安全, 加密策略, 反取证, 基础设施即服务, 存储安全, 安全加固, 安全合规, 安全态势管理, 安全清单, 安全评估, 日志与监控, 网络代理, 网络安全审计, 网络访问控制, 网络资产管理, 虚拟机镜像, 规则引擎, 身份与访问管理, 配置基线, 错误配置, 默认配置