Guides Zero Trust architecture implementation in AWS, Azure, GCP per NIST SP 800-207 and BeyondCorp principles: identity access control, micro-segmentation, continuous verification, device assessment, IAP deployment. Useful for eliminating VPNs, multi-cloud segmentation, compliance.
npx claudepluginhub killvxk/cybersecurity-skills-zhThis skill uses the workspace's default tool permissions.
- 从传统边界安全迁移到以身份为中心的访问控制时
Guides implementing zero trust architecture in AWS, Azure, GCP per NIST SP 800-207 and BeyondCorp: identity-centric controls, micro-segmentation, continuous verification, device assessment, Identity-Aware Proxy. For VPN elimination and regulatory compliance.
Guides zero trust implementation in AWS, Azure, GCP using NIST SP 800-207 and BeyondCorp principles. Covers identity access controls, micro-segmentation, continuous verification, and Identity-Aware Proxy.
Implements zero-trust network access (ZTNA) in AWS, Azure, GCP via identity-aware proxies like IAP and Verified Access, micro-segmentation, and BeyondCorp-style policies replacing VPNs for secure cloud workloads.
Share bugs, ideas, or general feedback.
不适用于：仅替换 VPN 而不进行更广泛架构变更的场景、单纯的网络防火墙规则管理（参见 implementing-cloud-network-segmentation），或身份提供商初始设置（参见 managing-cloud-identity-with-okta）。
遵循 NIST SP 800-207 建立核心原则：永不信任，始终验证。每个访问请求无论来源如何，都必须经过认证、授权和加密。
零信任架构组件:
+-------------------------------------------------------------------+
| 策略决策点 (Policy Decision Point) |
| +-------------------+ +------------------+ +-----------------+ |
| | 身份提供商 | | 设备信任 | | 风险引擎 | |
| | (Okta/Azure AD) | | (Intune/Jamf) | | (持续评估) | |
| +-------------------+ +------------------+ +-----------------+ |
+-------------------------------------------------------------------+
|
+--------------------+
| 策略执行点 |
| (IAP/代理) |
+--------------------+
|
+-------------------+-------------------+
| | |
+----------+ +----------+ +----------+
| 应用 A | | 应用 B | | 应用 C |
| (AWS) | | (Azure) | | (GCP) |
+----------+ +----------+ +----------+
配置身份感知代理（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"
}'
配置实时风险评估，根据身份、设备态势、位置、行为模式和威胁情报信号评估每个访问请求。
# 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"}
}
}
在网络层应用零信任，将云工作负载分割为隔离区域，并为每条通信路径设置显式允许规则。
# 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
集成终端验证以在授权访问前评估设备安全态势。要求加密、操作系统补丁和终端保护。
# 使用 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'
部署日志记录和分析工具，监控所有访问决策、检测异常，并根据真实使用模式持续优化零信任策略。
# 将 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 |
场景背景：一个组织有 500 名工程师通过 VPN 访问内部工具。VPN 集中器是单点故障，近期的凭据窃取事件表明 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 加密