[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFFQXKTKC0MPTVKFH06VD9":3,"skill-same:01M6AFFQXKTKC0MPTVKFH06VD9":121},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":69,"ownerHtmlUrl":70,"ownerBlogUrl":71,"ownerDescription":72,"updatedAt":73,"install":74,"resources":87},"01M6AFFQXKTKC0MPTVKFH06VD9","implementing-zero-trust-in-cloud",null,"Guides zero trust implementation across AWS, Azure, and GCP per NIST SP 800-207 and BeyondCorp principles, covering identity-centric access, micro-segmentation, continuous verification, device trust assessment, and Identity-Aware Proxy deployment. Use when migrating from perimeter security to identity-centric access, removing VPN dependency, or designing micro-segmentation for multi-cloud workloads.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-zero-trust-in-cloud\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"ZeRO","implementing zero trust in cloud","cloud","gcp","cybersecurity","segmentation","beyondcorp","t1078","identity-aware","identity-aware-proxy","zero-trust","NIST","pr","security","cloud-security","identity","proxy","verification","deployment","assessment","2026-11-10 10:12:30",false,"---\nname: implementing-zero-trust-in-cloud\ndescription: Guides zero trust implementation across AWS, Azure, and GCP per NIST SP 800-207 and BeyondCorp principles, covering identity-centric access, micro-segmentation, continuous verification, device trust assessment, and Identity-Aware Proxy deployment. Use when migrating from perimeter security to identity-centric access, removing VPN dependency, or designing micro-segmentation for multi-cloud workloads.\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- zero-trust\n- beyondcorp\n- identity-aware-proxy\n- micro-segmentation\n- continuous-verification\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\n---\n\n# Implementing Zero Trust in Cloud\n\n## When to Use\n\n- When migrating from traditional perimeter-based security to identity-centric access controls\n- When eliminating VPN dependencies for remote workforce access to cloud applications\n- When implementing continuous verification for every access request regardless of network location\n- When designing micro-segmentation strategies for multi-cloud workloads\n- When regulatory requirements mandate zero trust architecture adoption (federal mandates, NIST guidelines)\n\n**Do not use** for simple VPN replacement without broader architectural changes, for network firewall rule management alone (see implementing-cloud-network-segmentation), or for identity provider initial setup (see managing-cloud-identity-with-okta).\n\n## Prerequisites\n\n- Identity provider capable of OIDC\u002FSAML integration (Okta, Azure AD, Google Workspace)\n- Device management solution for endpoint trust assessment (Intune, Jamf, Google Endpoint Verification)\n- Cloud workloads accessible via HTTPS with load balancer or reverse proxy infrastructure\n- SIEM platform for continuous monitoring of access decisions and anomaly detection\n\n## Workflow\n\n### Step 1: Define Zero Trust Principles and Architecture\n\nEstablish the core principles following NIST SP 800-207: never trust, always verify. Every access request must be authenticated, authorized, and encrypted regardless of origin.\n\n```\nZero Trust Architecture Components:\n+-------------------------------------------------------------------+\n|                        Policy Decision Point                       |\n|  +-------------------+  +------------------+  +-----------------+ |\n|  | Identity Provider |  | Device Trust     |  | Risk Engine     | |\n|  | (Okta\u002FAzure AD)   |  | (Intune\u002FJamf)    |  | (Continuous)    | |\n|  +-------------------+  +------------------+  +-----------------+ |\n+-------------------------------------------------------------------+\n                              |\n                    +--------------------+\n                    | Policy Enforcement |\n                    | Point (IAP\u002FProxy)  |\n                    +--------------------+\n                              |\n          +-------------------+-------------------+\n          |                   |                   |\n    +----------+        +----------+        +----------+\n    | App A    |        | App B    |        | App C    |\n    | (AWS)    |        | (Azure)  |        | (GCP)    |\n    +----------+        +----------+        +----------+\n```\n\n### Step 2: Deploy Identity-Aware Proxy\n\nConfigure Identity-Aware Proxy (IAP) to enforce identity and context-based access decisions before requests reach applications. Eliminate direct network access to application backends.\n\n```bash\n# GCP: Enable Identity-Aware Proxy for a backend service\ngcloud services enable iap.googleapis.com\n\n# Configure IAP for an App Engine application\ngcloud iap web enable --resource-type=app-engine\n\n# Set IAP access policy requiring specific user group\ngcloud iap web add-iam-policy-binding \\\n  --resource-type=app-engine \\\n  --member=\"group:engineering@company.com\" \\\n  --role=\"roles\u002Fiap.httpsResourceAccessor\"\n\n# Create Access Level requiring corporate device and MFA\ngcloud access-context-manager levels create corporate-device \\\n  --title=\"Corporate Device with MFA\" \\\n  --basic-level-spec='{\n    \"conditions\": [\n      {\n        \"devicePolicy\": {\n          \"requireScreenlock\": true,\n          \"allowedEncryptionStatuses\": [\"ENCRYPTED\"],\n          \"osConstraints\": [\n            {\"osType\": \"DESKTOP_CHROME_OS\", \"minimumVersion\": \"100.0\"},\n            {\"osType\": \"DESKTOP_MAC\", \"minimumVersion\": \"12.0\"},\n            {\"osType\": \"DESKTOP_WINDOWS\", \"minimumVersion\": \"10.0.19041\"}\n          ]\n        },\n        \"requiredAccessLevels\": [\"accessPolicies\u002FPOLICY_ID\u002FaccessLevels\u002Frequire-mfa\"]\n      }\n    ]\n  }'\n```\n\n```bash\n# AWS: Configure AWS Verified Access for zero trust application access\naws ec2 create-verified-access-instance \\\n  --description \"Zero Trust Access Instance\"\n\naws ec2 create-verified-access-trust-provider \\\n  --trust-provider-type user \\\n  --user-trust-provider-type oidc \\\n  --oidc-options '{\n    \"Issuer\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\",\n    \"AuthorizationEndpoint\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\u002Fv1\u002Fauthorize\",\n    \"TokenEndpoint\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\u002Fv1\u002Ftoken\",\n    \"UserInfoEndpoint\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\u002Fv1\u002Fuserinfo\",\n    \"ClientId\": \"verified-access-client-id\",\n    \"ClientSecret\": \"verified-access-client-secret\",\n    \"Scope\": \"openid profile groups\"\n  }'\n```\n\n### Step 3: Implement Continuous Verification\n\nConfigure real-time risk assessment that evaluates every access request based on identity, device posture, location, behavior patterns, and threat intelligence signals.\n\n```yaml\n# Azure Conditional Access Policy (JSON representation)\n{\n  \"displayName\": \"Zero Trust - Require MFA and Compliant Device\",\n  \"state\": \"enabled\",\n  \"conditions\": {\n    \"users\": {\"includeUsers\": [\"All\"]},\n    \"applications\": {\"includeApplications\": [\"All\"]},\n    \"locations\": {\n      \"includeLocations\": [\"All\"],\n      \"excludeLocations\": [\"AllTrusted\"]\n    },\n    \"signInRiskLevels\": [\"medium\", \"high\"],\n    \"deviceStates\": {\n      \"includeStates\": [\"All\"],\n      \"excludeStates\": [\"Compliant\", \"DomainJoined\"]\n    }\n  },\n  \"grantControls\": {\n    \"operator\": \"AND\",\n    \"builtInControls\": [\n      \"mfa\",\n      \"compliantDevice\"\n    ]\n  },\n  \"sessionControls\": {\n    \"signInFrequency\": {\"value\": 4, \"type\": \"hours\"},\n    \"persistentBrowser\": {\"mode\": \"never\"}\n  }\n}\n```\n\n### Step 4: Enforce Micro-Segmentation\n\nApply network-level zero trust by segmenting cloud workloads into isolated zones with explicit allow rules for each communication path.\n\n```bash\n# AWS: Create isolated VPC with no default routes\naws ec2 create-vpc --cidr-block 10.100.0.0\u002F16 --no-amazon-provided-ipv6-cidr-block\n\n# Create security groups implementing micro-segmentation\naws ec2 create-security-group \\\n  --group-name web-tier-sg \\\n  --description \"Web tier - accepts traffic from ALB only\" \\\n  --vpc-id vpc-abc123\n\naws ec2 authorize-security-group-ingress \\\n  --group-id sg-web123 \\\n  --protocol tcp --port 8080 \\\n  --source-group sg-alb123\n\naws ec2 create-security-group \\\n  --group-name app-tier-sg \\\n  --description \"App tier - accepts traffic from web tier only\"\n\naws ec2 authorize-security-group-ingress \\\n  --group-id sg-app123 \\\n  --protocol tcp --port 8443 \\\n  --source-group sg-web123\n```\n\n### Step 5: Implement Device Trust Assessment\n\nIntegrate endpoint verification to assess device security posture before granting access. Require encryption, OS patches, and endpoint protection.\n\n```bash\n# Google Endpoint Verification with BeyondCorp\ngcloud access-context-manager levels create managed-device \\\n  --title=\"Managed and Encrypted Device\" \\\n  --basic-level-spec='{\n    \"conditions\": [{\n      \"devicePolicy\": {\n        \"requireScreenlock\": true,\n        \"requireAdminApproval\": true,\n        \"allowedEncryptionStatuses\": [\"ENCRYPTED\"],\n        \"allowedDeviceManagementLevels\": [\"COMPLETE\"]\n      }\n    }]\n  }'\n\n# Apply access level to IAP-protected resource\ngcloud iap web set-iam-policy \\\n  --resource-type=backend-services \\\n  --service=web-app-backend \\\n  --condition='expression=accessPolicies\u002FPOLICY_ID\u002FaccessLevels\u002Fmanaged-device'\n```\n\n### Step 6: Monitor and Adapt with Continuous Analytics\n\nDeploy logging and analytics to monitor all access decisions, detect anomalies, and continuously refine zero trust policies based on real usage patterns.\n\n```bash\n# Export IAP access logs to BigQuery for analysis\ngcloud logging sinks create iap-access-logs \\\n  bigquery.googleapis.com\u002Fprojects\u002Fmy-project\u002Fdatasets\u002Fsecurity_logs \\\n  --log-filter='resource.type=\"gce_backend_service\" AND protoPayload.serviceName=\"iap.googleapis.com\"'\n\n# AWS Verified Access logs to CloudWatch\naws ec2 modify-verified-access-instance-logging-configuration \\\n  --verified-access-instance-id vai-abc123 \\\n  --access-logs '{\n    \"CloudWatchLogs\": {\"Enabled\": true, \"LogGroup\": \"\u002Faws\u002Fverified-access\u002Flogs\"},\n    \"S3\": {\"Enabled\": true, \"BucketName\": \"verified-access-logs\"}\n  }'\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Zero Trust | Security model that eliminates implicit trust by requiring continuous authentication, authorization, and encryption for every access request |\n| BeyondCorp | Google's implementation of zero trust that shifts access controls from network perimeter to individual users and devices |\n| Identity-Aware Proxy | Reverse proxy that verifies user identity and context before forwarding requests to backend applications, replacing VPN-based access |\n| Continuous Verification | Real-time assessment of identity, device posture, location, and behavior for every access request, not just at initial authentication |\n| Device Trust | Assessment of endpoint security posture including encryption status, OS version, patch level, and MDM compliance before granting access |\n| NIST SP 800-207 | National Institute of Standards and Technology publication defining zero trust architecture principles and deployment models |\n| Access Context Manager | GCP service for defining conditional access policies based on device attributes, IP ranges, and identity properties |\n| AWS Verified Access | AWS service providing zero trust application access based on identity and device trust signals without VPN |\n\n## Tools & Systems\n\n- **Google BeyondCorp Enterprise**: End-to-end zero trust platform with Identity-Aware Proxy, Access Context Manager, and Endpoint Verification\n- **AWS Verified Access**: Zero trust application access service integrating with identity providers and device trust services\n- **Azure Conditional Access**: Policy engine enforcing identity, device, location, and risk-based access controls for Azure AD applications\n- **Zscaler Private Access**: Zero trust network access platform replacing VPN with identity and context-based application access\n- **Cloudflare Access**: Zero trust proxy for securing internal applications with identity verification and device posture checks\n\n## Common Scenarios\n\n### Scenario: Eliminating VPN for Remote Engineering Access\n\n**Context**: An organization has 500 engineers accessing internal tools via VPN. The VPN concentrator is a single point of failure and recent credential theft incidents showed that VPN access grants excessive lateral movement capability.\n\n**Approach**:\n1. Inventory all internal applications accessed via VPN and classify by sensitivity level\n2. Deploy Identity-Aware Proxy (GCP) or Verified Access (AWS) in front of each application\n3. Configure OIDC integration with the corporate identity provider requiring MFA for all access\n4. Implement device trust policies requiring encrypted devices with current OS patches and endpoint protection\n5. Enable continuous session evaluation with 4-hour re-authentication for sensitive applications\n6. Gradually migrate teams from VPN to IAP access, monitoring for access failures and adjusting policies\n7. Decommission VPN after 100% migration and 30-day parallel operation period\n\n**Pitfalls**: Deploying zero trust without device management in place blocks legitimate users with personal devices. Setting re-authentication intervals too short disrupts developer productivity with excessive login prompts.\n\n## Output Format\n\n```\nZero Trust Architecture Assessment Report\n===========================================\nOrganization: Acme Corp\nCloud Providers: AWS, Azure, GCP\nAssessment Date: 2025-02-23\n\nMATURITY LEVEL: Level 2 (Advanced) - NIST ZTA Maturity Model\n\nIDENTITY PILLAR:\n  MFA Enforcement: 98% of users (target: 100%)\n  Phishing-Resistant MFA: 34% (target: 80%)\n  SSO Coverage: 87% of applications\n  Conditional Access Policies: 12 active policies\n\nDEVICE PILLAR:\n  MDM Enrollment: 92% of corporate devices\n  Encryption Enforcement: 95%\n  OS Patch Compliance: 78% (30-day window)\n  Endpoint Protection: 96%\n\nNETWORK PILLAR:\n  VPN Dependency: 3 applications remaining (target: 0)\n  IAP-Protected Applications: 47\u002F50\n  Micro-Segmented Workloads: 65%\n  East-West Traffic Encryption: 40% (mTLS adoption)\n\nAPPLICATION PILLAR:\n  Applications Behind Zero Trust Proxy: 94%\n  Session Re-Authentication: Configured for 85% of apps\n  Runtime Access Logging: 100%\n\nRECOMMENDATIONS:\n  1. [HIGH] Migrate remaining 3 VPN-dependent apps to IAP\n  2. [HIGH] Increase phishing-resistant MFA to 80% within 6 months\n  3. [MEDIUM] Expand micro-segmentation to remaining 35% of workloads\n  4. [MEDIUM] Deploy service mesh for east-west mTLS encryption\n```\n","# Implementing Zero Trust in Cloud\n\n## When to Use\n\n- When migrating from traditional perimeter-based security to identity-centric access controls\n- When eliminating VPN dependencies for remote workforce access to cloud applications\n- When implementing continuous verification for every access request regardless of network location\n- When designing micro-segmentation strategies for multi-cloud workloads\n- When regulatory requirements mandate zero trust architecture adoption (federal mandates, NIST guidelines)\n\n**Do not use** for simple VPN replacement without broader architectural changes, for network firewall rule management alone (see implementing-cloud-network-segmentation), or for identity provider initial setup (see managing-cloud-identity-with-okta).\n\n## Prerequisites\n\n- Identity provider capable of OIDC\u002FSAML integration (Okta, Azure AD, Google Workspace)\n- Device management solution for endpoint trust assessment (Intune, Jamf, Google Endpoint Verification)\n- Cloud workloads accessible via HTTPS with load balancer or reverse proxy infrastructure\n- SIEM platform for continuous monitoring of access decisions and anomaly detection\n\n## Workflow\n\n### Step 1: Define Zero Trust Principles and Architecture\n\nEstablish the core principles following NIST SP 800-207: never trust, always verify. Every access request must be authenticated, authorized, and encrypted regardless of origin.\n\n```\nZero Trust Architecture Components:\n+-------------------------------------------------------------------+\n|                        Policy Decision Point                       |\n|  +-------------------+  +------------------+  +-----------------+ |\n|  | Identity Provider |  | Device Trust     |  | Risk Engine     | |\n|  | (Okta\u002FAzure AD)   |  | (Intune\u002FJamf)    |  | (Continuous)    | |\n|  +-------------------+  +------------------+  +-----------------+ |\n+-------------------------------------------------------------------+\n                              |\n                    +--------------------+\n                    | Policy Enforcement |\n                    | Point (IAP\u002FProxy)  |\n                    +--------------------+\n                              |\n          +-------------------+-------------------+\n          |                   |                   |\n    +----------+        +----------+        +----------+\n    | App A    |        | App B    |        | App C    |\n    | (AWS)    |        | (Azure)  |        | (GCP)    |\n    +----------+        +----------+        +----------+\n```\n\n### Step 2: Deploy Identity-Aware Proxy\n\nConfigure Identity-Aware Proxy (IAP) to enforce identity and context-based access decisions before requests reach applications. Eliminate direct network access to application backends.\n\n```bash\n# GCP: Enable Identity-Aware Proxy for a backend service\ngcloud services enable iap.googleapis.com\n\n# Configure IAP for an App Engine application\ngcloud iap web enable --resource-type=app-engine\n\n# Set IAP access policy requiring specific user group\ngcloud iap web add-iam-policy-binding \\\n  --resource-type=app-engine \\\n  --member=\"group:engineering@company.com\" \\\n  --role=\"roles\u002Fiap.httpsResourceAccessor\"\n\n# Create Access Level requiring corporate device and MFA\ngcloud access-context-manager levels create corporate-device \\\n  --title=\"Corporate Device with MFA\" \\\n  --basic-level-spec='{\n    \"conditions\": [\n      {\n        \"devicePolicy\": {\n          \"requireScreenlock\": true,\n          \"allowedEncryptionStatuses\": [\"ENCRYPTED\"],\n          \"osConstraints\": [\n            {\"osType\": \"DESKTOP_CHROME_OS\", \"minimumVersion\": \"100.0\"},\n            {\"osType\": \"DESKTOP_MAC\", \"minimumVersion\": \"12.0\"},\n            {\"osType\": \"DESKTOP_WINDOWS\", \"minimumVersion\": \"10.0.19041\"}\n          ]\n        },\n        \"requiredAccessLevels\": [\"accessPolicies\u002FPOLICY_ID\u002FaccessLevels\u002Frequire-mfa\"]\n      }\n    ]\n  }'\n```\n\n```bash\n# AWS: Configure AWS Verified Access for zero trust application access\naws ec2 create-verified-access-instance \\\n  --description \"Zero Trust Access Instance\"\n\naws ec2 create-verified-access-trust-provider \\\n  --trust-provider-type user \\\n  --user-trust-provider-type oidc \\\n  --oidc-options '{\n    \"Issuer\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\",\n    \"AuthorizationEndpoint\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\u002Fv1\u002Fauthorize\",\n    \"TokenEndpoint\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\u002Fv1\u002Ftoken\",\n    \"UserInfoEndpoint\": \"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\u002Fv1\u002Fuserinfo\",\n    \"ClientId\": \"verified-access-client-id\",\n    \"ClientSecret\": \"verified-access-client-secret\",\n    \"Scope\": \"openid profile groups\"\n  }'\n```\n\n### Step 3: Implement Continuous Verification\n\nConfigure real-time risk assessment that evaluates every access request based on identity, device posture, location, behavior patterns, and threat intelligence signals.\n\n```yaml\n# Azure Conditional Access Policy (JSON representation)\n{\n  \"displayName\": \"Zero Trust - Require MFA and Compliant Device\",\n  \"state\": \"enabled\",\n  \"conditions\": {\n    \"users\": {\"includeUsers\": [\"All\"]},\n    \"applications\": {\"includeApplications\": [\"All\"]},\n    \"locations\": {\n      \"includeLocations\": [\"All\"],\n      \"excludeLocations\": [\"AllTrusted\"]\n    },\n    \"signInRiskLevels\": [\"medium\", \"high\"],\n    \"deviceStates\": {\n      \"includeStates\": [\"All\"],\n      \"excludeStates\": [\"Compliant\", \"DomainJoined\"]\n    }\n  },\n  \"grantControls\": {\n    \"operator\": \"AND\",\n    \"builtInControls\": [\n      \"mfa\",\n      \"compliantDevice\"\n    ]\n  },\n  \"sessionControls\": {\n    \"signInFrequency\": {\"value\": 4, \"type\": \"hours\"},\n    \"persistentBrowser\": {\"mode\": \"never\"}\n  }\n}\n```\n\n### Step 4: Enforce Micro-Segmentation\n\nApply network-level zero trust by segmenting cloud workloads into isolated zones with explicit allow rules for each communication path.\n\n```bash\n# AWS: Create isolated VPC with no default routes\naws ec2 create-vpc --cidr-block 10.100.0.0\u002F16 --no-amazon-provided-ipv6-cidr-block\n\n# Create security groups implementing micro-segmentation\naws ec2 create-security-group \\\n  --group-name web-tier-sg \\\n  --description \"Web tier - accepts traffic from ALB only\" \\\n  --vpc-id vpc-abc123\n\naws ec2 authorize-security-group-ingress \\\n  --group-id sg-web123 \\\n  --protocol tcp --port 8080 \\\n  --source-group sg-alb123\n\naws ec2 create-security-group \\\n  --group-name app-tier-sg \\\n  --description \"App tier - accepts traffic from web tier only\"\n\naws ec2 authorize-security-group-ingress \\\n  --group-id sg-app123 \\\n  --protocol tcp --port 8443 \\\n  --source-group sg-web123\n```\n\n### Step 5: Implement Device Trust Assessment\n\nIntegrate endpoint verification to assess device security posture before granting access. Require encryption, OS patches, and endpoint protection.\n\n```bash\n# Google Endpoint Verification with BeyondCorp\ngcloud access-context-manager levels create managed-device \\\n  --title=\"Managed and Encrypted Device\" \\\n  --basic-level-spec='{\n    \"conditions\": [{\n      \"devicePolicy\": {\n        \"requireScreenlock\": true,\n        \"requireAdminApproval\": true,\n        \"allowedEncryptionStatuses\": [\"ENCRYPTED\"],\n        \"allowedDeviceManagementLevels\": [\"COMPLETE\"]\n      }\n    }]\n  }'\n\n# Apply access level to IAP-protected resource\ngcloud iap web set-iam-policy \\\n  --resource-type=backend-services \\\n  --service=web-app-backend \\\n  --condition='expression=accessPolicies\u002FPOLICY_ID\u002FaccessLevels\u002Fmanaged-device'\n```\n\n### Step 6: Monitor and Adapt with Continuous Analytics\n\nDeploy logging and analytics to monitor all access decisions, detect anomalies, and continuously refine zero trust policies based on real usage patterns.\n\n```bash\n# Export IAP access logs to BigQuery for analysis\ngcloud logging sinks create iap-access-logs \\\n  bigquery.googleapis.com\u002Fprojects\u002Fmy-project\u002Fdatasets\u002Fsecurity_logs \\\n  --log-filter='resource.type=\"gce_backend_service\" AND protoPayload.serviceName=\"iap.googleapis.com\"'\n\n# AWS Verified Access logs to CloudWatch\naws ec2 modify-verified-access-instance-logging-configuration \\\n  --verified-access-instance-id vai-abc123 \\\n  --access-logs '{\n    \"CloudWatchLogs\": {\"Enabled\": true, \"LogGroup\": \"\u002Faws\u002Fverified-access\u002Flogs\"},\n    \"S3\": {\"Enabled\": true, \"BucketName\": \"verified-access-logs\"}\n  }'\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Zero Trust | Security model that eliminates implicit trust by requiring continuous authentication, authorization, and encryption for every access request |\n| BeyondCorp | Google's implementation of zero trust that shifts access controls from network perimeter to individual users and devices |\n| Identity-Aware Proxy | Reverse proxy that verifies user identity and context before forwarding requests to backend applications, replacing VPN-based access |\n| Continuous Verification | Real-time assessment of identity, device posture, location, and behavior for every access request, not just at initial authentication |\n| Device Trust | Assessment of endpoint security posture including encryption status, OS version, patch level, and MDM compliance before granting access |\n| NIST SP 800-207 | National Institute of Standards and Technology publication defining zero trust architecture principles and deployment models |\n| Access Context Manager | GCP service for defining conditional access policies based on device attributes, IP ranges, and identity properties |\n| AWS Verified Access | AWS service providing zero trust application access based on identity and device trust signals without VPN |\n\n## Tools & Systems\n\n- **Google BeyondCorp Enterprise**: End-to-end zero trust platform with Identity-Aware Proxy, Access Context Manager, and Endpoint Verification\n- **AWS Verified Access**: Zero trust application access service integrating with identity providers and device trust services\n- **Azure Conditional Access**: Policy engine enforcing identity, device, location, and risk-based access controls for Azure AD applications\n- **Zscaler Private Access**: Zero trust network access platform replacing VPN with identity and context-based application access\n- **Cloudflare Access**: Zero trust proxy for securing internal applications with identity verification and device posture checks\n\n## Common Scenarios\n\n### Scenario: Eliminating VPN for Remote Engineering Access\n\n**Context**: An organization has 500 engineers accessing internal tools via VPN. The VPN concentrator is a single point of failure and recent credential theft incidents showed that VPN access grants excessive lateral movement capability.\n\n**Approach**:\n1. Inventory all internal applications accessed via VPN and classify by sensitivity level\n2. Deploy Identity-Aware Proxy (GCP) or Verified Access (AWS) in front of each application\n3. Configure OIDC integration with the corporate identity provider requiring MFA for all access\n4. Implement device trust policies requiring encrypted devices with current OS patches and endpoint protection\n5. Enable continuous session evaluation with 4-hour re-authentication for sensitive applications\n6. Gradually migrate teams from VPN to IAP access, monitoring for access failures and adjusting policies\n7. Decommission VPN after 100% migration and 30-day parallel operation period\n\n**Pitfalls**: Deploying zero trust without device management in place blocks legitimate users with personal devices. Setting re-authentication intervals too short disrupts developer productivity with excessive login prompts.\n\n## Output Format\n\n```\nZero Trust Architecture Assessment Report\n===========================================\nOrganization: Acme Corp\nCloud Providers: AWS, Azure, GCP\nAssessment Date: 2025-02-23\n\nMATURITY LEVEL: Level 2 (Advanced) - NIST ZTA Maturity Model\n\nIDENTITY PILLAR:\n  MFA Enforcement: 98% of users (target: 100%)\n  Phishing-Resistant MFA: 34% (target: 80%)\n  SSO Coverage: 87% of applications\n  Conditional Access Policies: 12 active policies\n\nDEVICE PILLAR:\n  MDM Enrollment: 92% of corporate devices\n  Encryption Enforcement: 95%\n  OS Patch Compliance: 78% (30-day window)\n  Endpoint Protection: 96%\n\nNETWORK PILLAR:\n  VPN Dependency: 3 applications remaining (target: 0)\n  IAP-Protected Applications: 47\u002F50\n  Micro-Segmented Workloads: 65%\n  East-West Traffic Encryption: 40% (mTLS adoption)\n\nAPPLICATION PILLAR:\n  Applications Behind Zero Trust Proxy: 94%\n  Session Re-Authentication: Configured for 85% of apps\n  Runtime Access Logging: 100%\n\nRECOMMENDATIONS:\n  1. [HIGH] Migrate remaining 3 VPN-dependent apps to IAP\n  2. [HIGH] Increase phishing-resistant MFA to 80% within 6 months\n  3. [MEDIUM] Expand micro-segmentation to remaining 35% of workloads\n  4. [MEDIUM] Deploy service mesh for east-west mTLS encryption\n```\n",{"name":5,"tags":49,"author":52,"domain":28,"license":15,"version":53,"nist_csf":54,"subdomain":38,"description":7,"mitre_attack":59},[34,30,33,50,51],"micro-segmentation","continuous-verification","mahipal","1.0.0",[55,56,57,58],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01",[60,61,62,63],"T1078.004","T1530","T1537","T1580","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fimplementing-zero-trust-in-cloud",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":75,"prompt":85,"zipAvailable":86},[76,79,82],{"tool":77,"command":78},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-zero-trust-in-cloud",{"tool":80,"command":81},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-zero-trust-in-cloud",{"tool":83,"command":84},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-zero-trust-in-cloud","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-zero-trust-in-cloud\u002FSKILL.md",true,[88,94,98,102,107,111,115],{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"examples\u002Ffile-coordination.md","REFERENCE","参考文档",13184,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Fexamples\u002Ffile-coordination.md",{"path":95,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":96,"sourceHtmlUrl":97},"examples\u002Fparallel-research.md",10499,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Fexamples\u002Fparallel-research.md",{"path":99,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":100,"sourceHtmlUrl":101},"examples\u002Fsequential-build.md",15457,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Fexamples\u002Fsequential-build.md",{"path":103,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-zero-trust-in-cloud\u002FLICENSE",{"path":108,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":109,"sourceHtmlUrl":110},"reference.md",19253,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Freference.md",{"path":112,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fapi-reference.md",2845,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-zero-trust-in-cloud\u002Freferences\u002Fapi-reference.md",{"path":116,"resourceType":117,"resourceTypeDesc":118,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fagent.py","SCRIPT","脚本",10068,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-zero-trust-in-cloud\u002Fscripts\u002Fagent.py",[122,146,168,195,221,248],{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":44},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132,133,37,28,134,39,36,135,136,137,138,139,140,141,142,143,144,145],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":44},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[152],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[154,142,155,156,37,157,28,36,41,24,158,159,160,161,162,163,164,165,166,167],"boot","TPM","validating tpm measured boot attestation","policy","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":178,"publishedAt":44},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[174,177],{"categoryNo":175,"categoryName":176,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[162,179,180,181,182,28,183,184,41,185,186,187,188,189,190,31,191,192,193,194],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":44},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[201],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[203,204,205,28,206,207,208,209,210,211,212,213,214,215,216,217,159,218,219,220],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":228,"publishedAt":44},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[227],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[229,230,231,28,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":249,"name":250,"nameZh":6,"description":251,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":252,"categories":253,"keywords":255,"publishedAt":44},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[254],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[37,256,28,257,258,259,260,261,35,262,263,31,264,191,265,266,267,268,269,270],"triaging security incident","siem","file","ioc","soc","NIST-800-61","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]