implementing-zero-trust-in-cloud

What this skill does

# Implementing Zero Trust in Cloud

## When to Use

- When migrating from traditional perimeter-based security to identity-centric access controls
- When eliminating VPN dependencies for remote workforce access to cloud applications
- When implementing continuous verification for every access request regardless of network location
- When designing micro-segmentation strategies for multi-cloud workloads
- When regulatory requirements mandate zero trust architecture adoption (federal mandates, NIST guidelines)

**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).

## Prerequisites

- Identity provider capable of OIDC/SAML integration (Okta, Azure AD, Google Workspace)
- Device management solution for endpoint trust assessment (Intune, Jamf, Google Endpoint Verification)
- Cloud workloads accessible via HTTPS with load balancer or reverse proxy infrastructure
- SIEM platform for continuous monitoring of access decisions and anomaly detection

## Workflow

### Step 1: Define Zero Trust Principles and Architecture

Establish the core principles following NIST SP 800-207: never trust, always verify. Every access request must be authenticated, authorized, and encrypted regardless of origin.

```
Zero Trust Architecture Components:
+-------------------------------------------------------------------+
|                        Policy Decision Point                       |
|  +-------------------+  +------------------+  +-----------------+ |
|  | Identity Provider |  | Device Trust     |  | Risk Engine     | |
|  | (Okta/Azure AD)   |  | (Intune/Jamf)    |  | (Continuous)    | |
|  +-------------------+  +------------------+  +-----------------+ |
+-------------------------------------------------------------------+
                              |
                    +--------------------+
                    | Policy Enforcement |
                    | Point (IAP/Proxy)  |
                    +--------------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
    +----------+        +----------+        +----------+
    | App A    |        | App B    |        | App C    |
    | (AWS)    |        | (Azure)  |        | (GCP)    |
    +----------+        +----------+        +----------+
```

### Step 2: Deploy Identity-Aware Proxy

Configure Identity-Aware Proxy (IAP) to enforce identity and context-based access decisions before requests reach applications. Eliminate direct network access to application backends.

```bash
# GCP: Enable Identity-Aware Proxy for a backend service
gcloud services enable iap.googleapis.com

# Configure IAP for an App Engine application
gcloud iap web enable --resource-type=app-engine

# Set IAP access policy requiring specific user group
gcloud iap web add-iam-policy-binding \
  --resource-type=app-engine \
  --member="group:[email protected]" \
  --role="roles/iap.httpsResourceAccessor"

# Create Access Level requiring corporate device and 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"]
      }
    ]
  }'
```

```bash
# AWS: Configure AWS Verified Access for zero trust application 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"
  }'
```

### Step 3: Implement Continuous Verification

Configure real-time risk assessment that evaluates every access request based on identity, device posture, location, behavior patterns, and threat intelligence signals.

```yaml
# Azure Conditional Access Policy (JSON representation)
{
  "displayName": "Zero Trust - Require MFA and Compliant Device",
  "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"}
  }
}
```

### Step 4: Enforce Micro-Segmentation

Apply network-level zero trust by segmenting cloud workloads into isolated zones with explicit allow rules for each communication path.

```bash
# AWS: Create isolated VPC with no default routes
aws ec2 create-vpc --cidr-block 10.100.0.0/16 --no-amazon-provided-ipv6-cidr-block

# Create security groups implementing micro-segmentation
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
```

### Step 5: Implement Device Trust Assessment

Integrate endpoint verification to assess device security posture before granting access. Require encryption, OS patches, and endpoint protection.

```bash
# Google Endpoint Verification with BeyondCorp
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"]
      }
    }]
  }'

# Apply access level to IAP-protected resource
gcloud iap web set-iam-policy \
  --resource-type=backend-services \
  --service=web-app-backend \
  --condition='expression=accessPolicies/POLICY_ID/accessLevels/managed-device'
```

### Step 6: Monitor and Adapt with Continuous Analytics

Deploy logging and analytics to monitor all access decisions, detect anomalies, and continuously refine zero trust policies based on real usage patterns.

```bash
# Export IAP access logs to BigQuery for analysis
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 logs to CloudWatch
aws ec2 modify-verified-access-instance-logging-configuration \
  --verified-access-instance-id vai-abc123 \
  --access