implementing-zero-trust-network-access

ゼロトラスト・ネットワークアクセスの実装

使用する場面

• 従来のVPNベースのリモートアクセスを、IDベースのアクセス制御に置き換える場合
• クラウドネットワーク内でのラテラルムーブメントを制限するマイクロセグメンテーションを実装する場合
• コンプライアンスやセキュリティ戦略でゼロトラストアーキテクチャの採用が求められる場合
• クラウドワークロードをパブリックインターネットに公開せず、安全なアクセスを提供する場合
• ユーザー ID、デバイスの健全性、場所に基づくコンテキスト認識型のアクセスポリシーを構築する場合

以下の用途には使用しないでください。ネットワークセキュリティ制御を完全に置き換える用途（ZTNA はファイアウォールやネットワーク ACL を補完しますが、置き換えるものではありません）、インターネットに公開されているパブリックアプリケーションを保護する用途（WAF を使用してください）、IDベースの認証が実現できない IoT デバイスへのアクセス。

前提条件

• MFA の適用が設定された ID プロバイダー（Entra ID、Okta、Google Workspace）
• クラウドネイティブのネットワーク機能（AWS PrivateLink、Azure Private Link、GCP IAP）
• デバイスのポスチャ評価用のデバイス管理ソリューション（Intune、Jamf、CrowdStrike）
• サービスメッシュまたはゼロトラストプロキシ（Cloudflare Access、Zscaler ZPA、またはクラウドネイティブの IAP）
• アクセス判断とポリシー適用のための一元化されたログ記録

ワークフロー

ステップ 1：アプリケーションアクセス用に GCP Identity-Aware Proxy（IAP）をデプロイする

VPN を使わずにウェブアプリケーションへの認証済みアクセスを提供できるよう、IAP を設定します。

# Enable IAP API
gcloud services enable iap.googleapis.com

# Configure OAuth consent screen
gcloud iap oauth-brands create \
  --application_title="Corporate Apps" \
  [email protected]

# 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:[email protected]" \
  --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

ステップ 2：ゼロトラストのために AWS Verified Access を実装する

内部アプリケーションへの IDベースのアクセスを提供するために、AWS Verified Access をデプロイします。

# 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"]
  }'

ステップ 3：Azure Private Link と条件付きアクセスを設定する

ネットワーク分離のために Azure Private Link を設定し、IDベースの制御のために条件付きアクセスを設定します。

# 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

# 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

ステップ 4：ネットワークポリシーでマイクロセグメンテーションを実装する

IDベースのアクセス制御を補完するために、ネットワークレベルのマイクロセグメンテーションをデプロイします。

# 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

ステップ 5：継続的な検証とログ記録を有効にする

一度限りの認証ではなく、継続的な信頼性検証を実装します。

# 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
  '

主要な概念

用語	定義
Zero Trust	ネットワーク上の場所にかかわらず、リソースにアクセスするすべての人とデバイスに厳格な ID 検証を求めるセキュリティモデル
ZTNA	Zero Trust Network Access の略で、アプリケーションへの ID 認識型かつコンテキストベースのアクセスを提供し、ゼロトラストの原則を実装する技術
Identity-Aware Proxy	バックエンドアプリケーションへのアクセスを許可する前にユーザー ID とデバイスのコンテキストを検証し、VPNベースのアクセスに置き換えるプロキシサービス
Micro-Segmentation	個々のワークロードやアプリケーションの周囲にきめ細かなセキュリティゾーンを作成し、ラテラルムーブメントを制限するネットワークセキュリティ技術
BeyondCorp	アクセス制御をネットワーク境界から個々のユーザーとデバイスへ移行する、Google によるゼロトラストアーキテクチャの実装
Continuous Verification	認証時だけでなく、セッション全体を通じてユーザー ID、デバイスの健全性、アクセスのコンテキストを継続的に評価すること

ツールとシステム

• GCP Identity-Aware Proxy：ウェブアプリケーションと VM へのコンテキスト認識型アクセスを提供する、Google の BeyondCorp 実装
• AWS Verified Access：ID とデバイスのポスチャ検証に基づき、アプリケーションへのゼロトラストアクセスを提供する AWS サービス
• Azure Conditional Access：ユーザー、デバイス、場所、リスクに基づいてコンテキストベースのアクセス制御を適用する、Microsoft のポリシーエンジン
• Cloudflare Access：内部アプリケーションへの ID 認識型アクセスを提供する、クラウド提供型の ZTNA ソリューション
• Zscaler ZPA：ID とコンテキストに基づくアプリケーションレベルのアクセスによって VPN に置き換える、エンタープライズ向け ZTNA プラットフォーム

一般的なシナリオ

シナリオ：クラウドアプリケーション向けのゼロトラストアクセスによる企業 VPN の置き換え

背景：従業員 2,000 人の組織が、従来型の VPN コンセントレーターを通じて 30 以上の社内クラウドアプリケーションにアクセスしています。VPN のパフォーマンス問題とセキュリティ上の懸念を受け、ZTNA の導入を決定しました。

アプローチ：

1. 現在 VPN 経由でアクセスしているすべてのアプリケーションを一覧化し、機密性に応じて分類します
2. ウェブベースの社内アプリケーション向けに GCP IAP または AWS Verified Access を導入します
3. すべてのアプリケーションで MFA とデバイスのコンプライアンスを必須とする条件付きアクセス ポリシーを設定します
4. セキュリティグループを使用してマイクロセグメンテーションを実装し、アプリケーション階層間のラテラルムーブメントを制限します
5. 機密性の高いアプリケーションについて、4 時間ごとの再認証による継続的な検証を設定します
6. リスクの低いアプリケーションからユーザーを段階的に移行し、問題がないかアクセスログを監視します
7. すべてのアプリケーションに ZTNA 経由で完全なログ記録を伴ってアクセスできるようになった後、VPN を廃止します

注意点：すべてのアプリケーションが ID 認識型プロキシとの統合に対応しているわけではありません。従来型のシッククライアントアプリケーションには、プロキシベースの方式ではなく、エージェントベースの ZTNA ソリューションが必要になる場合があります。デバイスのセキュリティ状態を評価するには、すべての社用デバイスにエンドポイント管理ソリューションを導入する必要があります。ID プロバイダーが利用できない場合に備え、緊急アクセスの手順を文書化する必要があります。

出力形式

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