Initial commit - 611 cybersecurity skills across all subdomains

2026-07-11 10:03:42 +03:00 · 2026-02-25 10:47:44 +01:00
commit 22a7ab1462
1765 changed files with 280648 additions and 0 deletions
@@ -0,0 +1,348 @@
+---
+name: implementing-zero-trust-network-access
+description: >
+  Implementing Zero Trust Network Access (ZTNA) in cloud environments by configuring
+  identity-aware proxies, micro-segmentation, continuous verification with conditional
+  access policies, and replacing traditional VPN-based access with BeyondCorp-style
+  architectures across AWS, Azure, and GCP.
+domain: cybersecurity
+subdomain: cloud-security
+tags: [cloud-security, zero-trust, ztna, beyondcorp, identity-aware-proxy, micro-segmentation]
+version: "1.0"
+author: mahipal
+license: MIT
+---
+
+# Implementing Zero Trust Network Access
+
+## When to Use
+
+- When replacing traditional VPN-based remote access with identity-based access controls
+- When implementing micro-segmentation to limit lateral movement within cloud networks
+- When compliance or security strategy requires zero trust architecture adoption
+- When providing secure access to cloud workloads without exposing them to the public internet
+- When building context-aware access policies based on user identity, device health, and location
+
+**Do not use** as a complete replacement for network security controls (ZTNA complements but does not replace firewalls and network ACLs), for protecting internet-facing public applications (use WAF), or for IoT device access where identity-based authentication is not feasible.
+
+## Prerequisites
+
+- Identity provider (Entra ID, Okta, Google Workspace) with MFA enforcement
+- Cloud-native networking capabilities (AWS PrivateLink, Azure Private Link, GCP IAP)
+- Device management solution (Intune, Jamf, CrowdStrike) for device posture assessment
+- Service mesh or zero trust proxy (Cloudflare Access, Zscaler ZPA, or cloud-native IAP)
+- Centralized logging for access decisions and policy enforcement
+
+## Workflow
+
+### Step 1: Deploy GCP Identity-Aware Proxy (IAP) for Application Access
+
+Configure IAP to provide authenticated access to web applications without VPN.
+
+```bash
+# Enable IAP API
+gcloud services enable iap.googleapis.com
+
+# Configure OAuth consent screen
+gcloud iap oauth-brands create \
+  --application_title="Corporate Apps" \
+  --support_email=security@company.com
+
+# Enable IAP on an App Engine application
+gcloud iap web enable \
+  --resource-type=app-engine \
+  --oauth2-client-id=CLIENT_ID \
+  --oauth2-client-secret=CLIENT_SECRET
+
+# Enable IAP on a backend service (GCE/GKE)
+gcloud compute backend-services update BACKEND_SERVICE \
+  --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
+  --global
+
+# Set IAP access policy (who can access)
+gcloud iap web add-iam-policy-binding \
+  --resource-type=app-engine \
+  --member="group:engineering@company.com" \
+  --role="roles/iap.httpsResourceAccessor"
+
+# Configure access levels based on device and context
+gcloud access-context-manager levels create corporate-device \
+  --title="Corporate Managed Device" \
+  --basic-level-spec=level-spec.yaml \
+  --policy=POLICY_ID
+```
+
+### Step 2: Implement AWS Verified Access for Zero Trust
+
+Deploy AWS Verified Access to provide identity-based access to internal applications.
+
+```bash
+# Create a Verified Access trust provider (OIDC)
+aws ec2 create-verified-access-trust-provider \
+  --trust-provider-type user \
+  --user-trust-provider-type oidc \
+  --oidc-options '{
+    "Issuer": "https://login.microsoftonline.com/TENANT_ID/v2.0",
+    "AuthorizationEndpoint": "https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/authorize",
+    "TokenEndpoint": "https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token",
+    "UserInfoEndpoint": "https://graph.microsoft.com/oidc/userinfo",
+    "ClientId": "CLIENT_ID",
+    "ClientSecret": "CLIENT_SECRET",
+    "Scope": "openid profile email"
+  }'
+
+# Create a Verified Access instance
+aws ec2 create-verified-access-instance \
+  --description "Zero Trust Access Instance"
+
+# Attach trust provider to instance
+aws ec2 attach-verified-access-trust-provider \
+  --verified-access-instance-id vai-INSTANCE_ID \
+  --verified-access-trust-provider-id vatp-PROVIDER_ID
+
+# Create a Verified Access group with policy
+aws ec2 create-verified-access-group \
+  --verified-access-instance-id vai-INSTANCE_ID \
+  --policy-document '{
+    "Version": "2012-10-17",
+    "Statement": [{
+      "Effect": "Allow",
+      "Principal": "*",
+      "Action": "verified-access:AllowAccess",
+      "Condition": {
+        "StringEquals": {
+          "verified-access:user/groups": "engineering"
+        }
+      }
+    }]
+  }'
+
+# Create endpoint for an internal application
+aws ec2 create-verified-access-endpoint \
+  --verified-access-group-id vag-GROUP_ID \
+  --endpoint-type load-balancer \
+  --attachment-type vpc \
+  --domain-certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERT_ID \
+  --application-domain app.internal.company.com \
+  --endpoint-domain-prefix app \
+  --load-balancer-options '{
+    "LoadBalancerArn": "arn:aws:elasticloadbalancing:REGION:ACCOUNT:loadbalancer/app/internal-app/xxx",
+    "Port": 443,
+    "Protocol": "https",
+    "SubnetIds": ["subnet-xxx"]
+  }'
+```
+
+### Step 3: Configure Azure Private Link and Conditional Access
+
+Set up Azure Private Link for network isolation and conditional access for identity-based controls.
+
+```bash
+# Create Private Endpoint for an Azure service
+az network private-endpoint create \
+  --name app-private-endpoint \
+  --resource-group production-rg \
+  --vnet-name production-vnet \
+  --subnet private-endpoint-subnet \
+  --private-connection-resource-id /subscriptions/SUB_ID/resourceGroups/RG/providers/Microsoft.Web/sites/internal-app \
+  --group-ids sites \
+  --connection-name app-connection
+
+# Configure private DNS zone for the service
+az network private-dns zone create \
+  --resource-group production-rg \
+  --name privatelink.azurewebsites.net
+
+az network private-dns link vnet create \
+  --resource-group production-rg \
+  --zone-name privatelink.azurewebsites.net \
+  --name production-link \
+  --virtual-network production-vnet \
+  --registration-enabled false
+```
+
+```powershell
+# Create Conditional Access policy requiring compliant device + MFA
+Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
+
+$params = @{
+    DisplayName = "Zero Trust - Require MFA and Compliant Device"
+    State = "enabled"
+    Conditions = @{
+        Applications = @{
+            IncludeApplications = @("All")
+        }
+        Users = @{
+            IncludeUsers = @("All")
+            ExcludeGroups = @("BreakGlass-Group-ID")
+        }
+        Locations = @{
+            IncludeLocations = @("All")
+            ExcludeLocations = @("AllTrusted")
+        }
+    }
+    GrantControls = @{
+        Operator = "AND"
+        BuiltInControls = @("mfa", "compliantDevice")
+    }
+    SessionControls = @{
+        SignInFrequency = @{
+            Value = 4
+            Type = "hours"
+            IsEnabled = $true
+        }
+    }
+}
+
+New-MgIdentityConditionalAccessPolicy -BodyParameter $params
+```
+
+### Step 4: Implement Micro-Segmentation with Network Policies
+
+Deploy network-level micro-segmentation to complement identity-based access controls.
+
+```bash
+# AWS: Create security groups for micro-segmentation
+aws ec2 create-security-group \
+  --group-name web-tier-sg \
+  --description "Web tier - only HTTPS from ALB" \
+  --vpc-id vpc-PROD
+
+aws ec2 authorize-security-group-ingress \
+  --group-id sg-WEB \
+  --protocol tcp --port 443 \
+  --source-group sg-ALB
+
+aws ec2 create-security-group \
+  --group-name app-tier-sg \
+  --description "App tier - only from web tier"
+
+aws ec2 authorize-security-group-ingress \
+  --group-id sg-APP \
+  --protocol tcp --port 8080 \
+  --source-group sg-WEB
+
+# Kubernetes NetworkPolicy for pod-level segmentation
+cat << 'EOF' | kubectl apply -f -
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: api-allow-web-only
+  namespace: production
+spec:
+  podSelector:
+    matchLabels:
+      app: api-server
+  policyTypes:
+    - Ingress
+  ingress:
+    - from:
+        - podSelector:
+            matchLabels:
+              app: web-frontend
+      ports:
+        - protocol: TCP
+          port: 8080
+EOF
+```
+
+### Step 5: Enable Continuous Verification and Logging
+
+Implement continuous trust verification rather than one-time authentication.
+
+```bash
+# Configure CloudWatch to monitor access decisions
+aws logs create-log-group --log-group-name /verified-access/access-logs
+
+# Enable Verified Access logging
+aws ec2 modify-verified-access-instance-logging-configuration \
+  --verified-access-instance-id vai-INSTANCE_ID \
+  --access-logs '{
+    "CloudWatchLogs": {
+      "Enabled": true,
+      "LogGroup": "/verified-access/access-logs"
+    }
+  }'
+
+# Query access logs for denied requests
+aws logs start-query \
+  --log-group-name /verified-access/access-logs \
+  --start-time $(date -d "24 hours ago" +%s) \
+  --end-time $(date +%s) \
+  --query-string '
+    fields @timestamp, identity.user, http_request.url, decision
+    | filter decision = "deny"
+    | sort @timestamp desc
+    | limit 50
+  '
+```
+
+## Key Concepts
+
+| Term | Definition |
+|------|------------|
+| Zero Trust | Security model that requires strict identity verification for every person and device accessing resources, regardless of network location |
+| ZTNA | Zero Trust Network Access, the technology that implements zero trust principles by providing identity-aware, context-based access to applications |
+| Identity-Aware Proxy | Proxy service that verifies user identity and device context before allowing access to backend applications, replacing VPN-based access |
+| Micro-Segmentation | Network security technique that creates fine-grained security zones around individual workloads or applications to limit lateral movement |
+| BeyondCorp | Google's implementation of zero trust architecture that shifts access controls from the network perimeter to individual users and devices |
+| Continuous Verification | Ongoing assessment of user identity, device health, and access context throughout a session rather than only at authentication time |
+
+## Tools & Systems
+
+- **GCP Identity-Aware Proxy**: Google's BeyondCorp implementation providing context-aware access to web applications and VMs
+- **AWS Verified Access**: AWS service for zero trust access to applications based on identity and device posture verification
+- **Azure Conditional Access**: Microsoft's policy engine for enforcing context-based access controls based on user, device, location, and risk
+- **Cloudflare Access**: Cloud-delivered ZTNA solution providing identity-aware access to internal applications
+- **Zscaler ZPA**: Enterprise ZTNA platform replacing VPN with application-level access based on identity and context
+
+## Common Scenarios
+
+### Scenario: Replacing Corporate VPN with Zero Trust Access for Cloud Applications
+
+**Context**: An organization with 2,000 employees accesses 30+ internal cloud applications through a traditional VPN concentrator. VPN performance issues and security concerns drive the decision to implement ZTNA.
+
+**Approach**:
+1. Inventory all applications currently accessed through VPN and classify by sensitivity
+2. Deploy GCP IAP or AWS Verified Access for web-based internal applications
+3. Configure conditional access policies requiring MFA and device compliance for all applications
+4. Implement micro-segmentation using security groups to limit lateral movement between application tiers
+5. Set up continuous verification with re-authentication every 4 hours for sensitive applications
+6. Migrate users in phases, starting with low-risk applications, monitoring access logs for issues
+7. Decommission VPN after all applications are accessible through ZTNA with full logging
+
+**Pitfalls**: Not all applications support identity-aware proxy integration. Legacy thick-client applications may require agent-based ZTNA solutions instead of proxy-based approaches. Device posture assessment requires an endpoint management solution deployed to all corporate devices. Break-glass access procedures must be documented for scenarios where the identity provider is unavailable.
+
+## Output Format
+
+```
+Zero Trust Network Access Implementation Report
+==================================================
+Organization: Acme Corp
+Implementation Date: 2026-02-23
+Applications Migrated: 24 / 30
+
+ZTNA ARCHITECTURE:
+  Identity Provider: Microsoft Entra ID
+  Access Proxy: AWS Verified Access + GCP IAP
+  Device Management: Microsoft Intune
+  MFA: FIDO2 + Authenticator App
+
+ACCESS POLICY COVERAGE:
+  Applications requiring MFA:          30 / 30 (100%)
+  Applications requiring compliant device: 24 / 30 (80%)
+  Applications with continuous verification: 18 / 30 (60%)
+  Applications with location restrictions:  12 / 30 (40%)
+
+SECURITY IMPROVEMENTS:
+  VPN-related incidents (before):      12/month
+  ZTNA-related incidents (after):       2/month
+  Mean time to detect unauthorized access: 4 min (was 2 hours)
+  Lateral movement paths eliminated:   85%
+
+MIGRATION STATUS:
+  Phase 1 (low-risk apps):     12/12 complete
+  Phase 2 (medium-risk apps):  12/12 complete
+  Phase 3 (high-risk apps):     0/6  in progress
+  VPN decommission:            Scheduled after Phase 3
+```