implementing-zero-trust-in-cloud

本技能指导组织按照 NIST SP 800-207 和 Google BeyondCorp 原则在云环境中实施零信任（Zero Trust）架构，涵盖以身份为中心的访问控制、微分段（Micro-Segmentation）、持续验证、设备信任评估，以及部署身份感知代理（Identity-Aware Proxy）以消除 AWS、Azure 和 GCP 环境中的隐式网络信任。

跳到安装

仓库: killvxk/cybersecurity-skills-zh
最近来源活动: 2026年3月17日 21:38
检测到的 SKILL.md 语言: 中文
星标: 42
分支: 9

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/killvxk/cybersecurity-skills-zh --skill implementing-zero-trust-in-cloud

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

文件资源管理器

4 个文件

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

name	implementing-zero-trust-in-cloud
description	本技能指导组织按照 NIST SP 800-207 和 Google BeyondCorp 原则在云环境中实施零信任（Zero Trust）架构，涵盖以身份为中心的访问控制、微分段（Micro-Segmentation）、持续验证、设备信任评估，以及部署身份感知代理（Identity-Aware Proxy）以消除 AWS、Azure 和 GCP 环境中的隐式网络信任。
domain	cybersecurity
subdomain	cloud-security
tags	["zero-trust","beyondcorp","identity-aware-proxy","micro-segmentation","continuous-verification"]
version	1.0.0
author	mahipal
license	Apache-2.0

在云中实施零信任架构

适用场景

从传统边界安全迁移到以身份为中心的访问控制时
为远程办公人员消除访问云应用的 VPN 依赖时
对每个访问请求实施持续验证，无论其网络位置如何时
为多云工作负载设计微分段策略时
合规要求强制采用零信任架构时（联邦法规、NIST 指南）

不适用于：仅替换 VPN 而不进行更广泛架构变更的场景、单纯的网络防火墙规则管理（参见 implementing-cloud-network-segmentation），或身份提供商初始设置（参见 managing-cloud-identity-with-okta）。

前置条件

支持 OIDC/SAML 集成的身份提供商（Okta、Azure AD、Google Workspace）
用于终端信任评估的设备管理解决方案（Intune、Jamf、Google Endpoint Verification）
通过 HTTPS 访问的云工作负载，具备负载均衡器或反向代理基础设施
用于持续监控访问决策和异常检测的 SIEM 平台

工作流程

步骤 1：定义零信任原则和架构

遵循 NIST SP 800-207 建立核心原则：永不信任，始终验证。每个访问请求无论来源如何，都必须经过认证、授权和加密。

零信任架构组件:
+-------------------------------------------------------------------+
|                        策略决策点 (Policy Decision Point)          |
|  +-------------------+  +------------------+  +-----------------+ |
|  | 身份提供商        |  | 设备信任          |  | 风险引擎        | |
|  | (Okta/Azure AD)   |  | (Intune/Jamf)    |  | (持续评估)      | |
|  +-------------------+  +------------------+  +-----------------+ |
+-------------------------------------------------------------------+
                              |
                    +--------------------+
                    | 策略执行点         |
                    | (IAP/代理)         |
                    +--------------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
    +----------+        +----------+        +----------+
    | 应用 A   |        | 应用 B   |        | 应用 C   |
    | (AWS)    |        | (Azure)  |        | (GCP)    |
    +----------+        +----------+        +----------+

步骤 2：部署身份感知代理

配置身份感知代理（Identity-Aware Proxy，IAP），在请求到达应用之前强制执行基于身份和上下文的访问决策。消除对应用后端的直接网络访问。

# GCP：为后端服务启用身份感知代理
gcloud services enable iap.googleapis.com

# 为 App Engine 应用配置 IAP
gcloud iap web enable --resource-type=app-engine

# 设置 IAP 访问策略，要求特定用户组
gcloud iap web add-iam-policy-binding \
  --resource-type=app-engine \
  --member="group:engineering@company.com" \
  --role="roles/iap.httpsResourceAccessor"

# 创建要求企业设备和 MFA 的访问级别
gcloud access-context-manager levels create corporate-device \
  --title="Corporate Device with MFA" \
  --basic-level-spec='{
    "conditions": [
      {
        "devicePolicy": {
          "requireScreenlock": true,
          "allowedEncryptionStatuses": ["ENCRYPTED"],
          "osConstraints": [
            {"osType": "DESKTOP_CHROME_OS", "minimumVersion": "100.0"},
            {"osType": "DESKTOP_MAC", "minimumVersion": "12.0"},
            {"osType": "DESKTOP_WINDOWS", "minimumVersion": "10.0.19041"}
          ]
        },
        "requiredAccessLevels": ["accessPolicies/POLICY_ID/accessLevels/require-mfa"]
      }
    ]
  }'

# AWS：配置 AWS Verified Access 实现零信任应用访问
aws ec2 create-verified-access-instance \
  --description "Zero Trust Access Instance"

aws ec2 create-verified-access-trust-provider \
  --trust-provider-type user \
  --user-trust-provider-type oidc \
  --oidc-options '{
    "Issuer": "https://company.okta.com/oauth2/default",
    "AuthorizationEndpoint": "https://company.okta.com/oauth2/default/v1/authorize",
    "TokenEndpoint": "https://company.okta.com/oauth2/default/v1/token",
    "UserInfoEndpoint": "https://company.okta.com/oauth2/default/v1/userinfo",
    "ClientId": "verified-access-client-id",
    "ClientSecret": "verified-access-client-secret",
    "Scope": "openid profile groups"
  }'

步骤 3：实施持续验证

配置实时风险评估，根据身份、设备态势、位置、行为模式和威胁情报信号评估每个访问请求。

# Azure 条件访问策略（JSON 格式）
{
  "displayName": "零信任 - 要求 MFA 和合规设备",
  "state": "enabled",
  "conditions": {
    "users": {"includeUsers": ["All"]},
    "applications": {"includeApplications": ["All"]},
    "locations": {
      "includeLocations": ["All"],
      "excludeLocations": ["AllTrusted"]
    },
    "signInRiskLevels": ["medium", "high"],
    "deviceStates": {
      "includeStates": ["All"],
      "excludeStates": ["Compliant", "DomainJoined"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": [
      "mfa",
      "compliantDevice"
    ]
  },
  "sessionControls": {
    "signInFrequency": {"value": 4, "type": "hours"},
    "persistentBrowser": {"mode": "never"}
  }
}

步骤 4：强制执行微分段

在网络层应用零信任，将云工作负载分割为隔离区域，并为每条通信路径设置显式允许规则。

# AWS：创建没有默认路由的隔离 VPC
aws ec2 create-vpc --cidr-block 10.100.0.0/16 --no-amazon-provided-ipv6-cidr-block

# 创建实现微分段的安全组
aws ec2 create-security-group \
  --group-name web-tier-sg \
  --description "Web tier - accepts traffic from ALB only" \
  --vpc-id vpc-abc123

aws ec2 authorize-security-group-ingress \
  --group-id sg-web123 \
  --protocol tcp --port 8080 \
  --source-group sg-alb123

aws ec2 create-security-group \
  --group-name app-tier-sg \
  --description "App tier - accepts traffic from web tier only"

aws ec2 authorize-security-group-ingress \
  --group-id sg-app123 \
  --protocol tcp --port 8443 \
  --source-group sg-web123

步骤 5：实施设备信任评估

集成终端验证以在授权访问前评估设备安全态势。要求加密、操作系统补丁和终端保护。

# 使用 BeyondCorp 进行 Google Endpoint Verification
gcloud access-context-manager levels create managed-device \
  --title="Managed and Encrypted Device" \
  --basic-level-spec='{
    "conditions": [{
      "devicePolicy": {
        "requireScreenlock": true,
        "requireAdminApproval": true,
        "allowedEncryptionStatuses": ["ENCRYPTED"],
        "allowedDeviceManagementLevels": ["COMPLETE"]
      }
    }]
  }'

# 将访问级别应用于受 IAP 保护的资源
gcloud iap web set-iam-policy \
  --resource-type=backend-services \
  --service=web-app-backend \
  --condition='expression=accessPolicies/POLICY_ID/accessLevels/managed-device'

步骤 6：通过持续分析进行监控和自适应

部署日志记录和分析工具，监控所有访问决策、检测异常，并根据真实使用模式持续优化零信任策略。

# 将 IAP 访问日志导出到 BigQuery 进行分析
gcloud logging sinks create iap-access-logs \
  bigquery.googleapis.com/projects/my-project/datasets/security_logs \
  --log-filter='resource.type="gce_backend_service" AND protoPayload.serviceName="iap.googleapis.com"'

# AWS Verified Access 日志输出到 CloudWatch
aws ec2 modify-verified-access-instance-logging-configuration \
  --verified-access-instance-id vai-abc123 \
  --access-logs '{
    "CloudWatchLogs": {"Enabled": true, "LogGroup": "/aws/verified-access/logs"},
    "S3": {"Enabled": true, "BucketName": "verified-access-logs"}
  }'

核心概念

术语	定义
零信任（Zero Trust）	通过对每个访问请求要求持续认证、授权和加密来消除隐式信任的安全模型
BeyondCorp	Google 的零信任实现，将访问控制从网络边界转移到个人用户和设备
身份感知代理（Identity-Aware Proxy）	反向代理，在将请求转发到后端应用前验证用户身份和上下文，替代基于 VPN 的访问
持续验证（Continuous Verification）	对每个访问请求进行身份、设备态势、位置和行为的实时评估，不仅限于初始认证
设备信任（Device Trust）	在授权访问前评估终端安全态势，包括加密状态、操作系统版本、补丁级别和 MDM 合规性
NIST SP 800-207	美国国家标准与技术研究院定义零信任架构原则和部署模型的出版物
Access Context Manager	GCP 服务，基于设备属性、IP 范围和身份属性定义条件访问策略
AWS Verified Access	AWS 服务，基于身份和设备信任信号提供零信任应用访问，无需 VPN

工具与系统

Google BeyondCorp Enterprise：端到端零信任平台，包含 Identity-Aware Proxy、Access Context Manager 和 Endpoint Verification
AWS Verified Access：零信任应用访问服务，与身份提供商和设备信任服务集成
Azure Conditional Access：策略引擎，为 Azure AD 应用实施基于身份、设备、位置和风险的访问控制
Zscaler Private Access：零信任网络访问平台，通过基于身份和上下文的应用访问替代 VPN
Cloudflare Access：零信任代理，通过身份验证和设备态势检查保护内部应用

常见场景

场景：消除远程工程师访问的 VPN 依赖

场景背景：一个组织有 500 名工程师通过 VPN 访问内部工具。VPN 集中器是单点故障，近期的凭据窃取事件表明 VPN 访问赋予了过多的横向移动能力。

方法：

梳理通过 VPN 访问的所有内部应用，并按敏感程度分类
在每个应用前部署身份感知代理（GCP）或 Verified Access（AWS）
配置与企业身份提供商的 OIDC 集成，要求所有访问使用 MFA
实施设备信任策略，要求已加密且安装了最新操作系统补丁和终端保护的设备
为敏感应用启用持续会话评估，每 4 小时重新认证
逐步将团队从 VPN 迁移到 IAP 访问，监控访问失败情况并调整策略
完成 100% 迁移并经过 30 天并行运行期后停用 VPN

常见陷阱：未部署设备管理就实施零信任，会阻止使用个人设备的合法用户。重新认证间隔设置过短会因频繁登录提示影响开发人员的工作效率。

输出格式

零信任架构评估报告
===========================================
组织: Acme Corp
云提供商: AWS, Azure, GCP
评估日期: 2025-02-23

成熟度级别: Level 2（高级）- NIST ZTA 成熟度模型

身份支柱:
  MFA 实施率: 98% 用户（目标: 100%）
  抗钓鱼 MFA: 34%（目标: 80%）
  SSO 覆盖率: 87% 应用
  条件访问策略: 12 个活跃策略

设备支柱:
  MDM 注册率: 92% 企业设备
  加密实施率: 95%
  操作系统补丁合规率: 78%（30 天窗口）
  终端保护: 96%

网络支柱:
  VPN 依赖: 剩余 3 个应用（目标: 0）
  IAP 保护的应用: 47/50
  微分段工作负载: 65%
  东西向流量加密: 40%（mTLS 采用率）

应用支柱:
  位于零信任代理后的应用: 94%
  会话重新认证: 已为 85% 的应用配置
  运行时访问日志: 100%

建议:
  1. [高] 将剩余 3 个 VPN 依赖应用迁移到 IAP
  2. [高] 在 6 个月内将抗钓鱼 MFA 提升至 80%
  3. [中] 将微分段扩展到剩余 35% 的工作负载
  4. [中] 部署服务网格实现东西向 mTLS 加密

implementing-zero-trust-in-cloud

来源信息

安装方式

检查来源文件

同仓库更多 Skills

在云中实施零信任架构

适用场景

前置条件

工作流程

步骤 1：定义零信任原则和架构

步骤 2：部署身份感知代理

步骤 3：实施持续验证

步骤 4：强制执行微分段

步骤 5：实施设备信任评估

步骤 6：通过持续分析进行监控和自适应

核心概念

工具与系统

常见场景

场景：消除远程工程师访问的 VPN 依赖

输出格式

同仓库更多 Skills

在云中实施零信任架构

适用场景

前置条件

工作流程

步骤 1：定义零信任原则和架构

步骤 2：部署身份感知代理

步骤 3：实施持续验证

步骤 4：强制执行微分段

步骤 5：实施设备信任评估

步骤 6：通过持续分析进行监控和自适应

核心概念

工具与系统

常见场景

场景：消除远程工程师访问的 VPN 依赖

输出格式