SASE（Secure Access Service Edge）の設計原則とゼロトラスト統合による段階的移行戦略

```html

なぜ今、SASEとゼロトラストが現場で求められるのか

「リモートワークになってからVPN経由のアクセスが重い」「クラウドへの移行が進んで、データセンター集中のネットワーク設計が限界になってきた」——そんな声、現場でよく聞きませんか？

従来のネットワーク設計は「社内＝安全、社外＝危険」という境界型セキュリティを前提にしていました。しかしSaaSやクラウドの普及で、トラフィックはデータセンターを経由せず直接インターネットに出ていく時代になりました。そこで登場したのが SASE（Secure Access Service Edge） です。SASEはネットワーキングとセキュリティをクラウド上で一体化させるアーキテクチャで、ゼロトラストの考え方と組み合わせることで真の意味での「場所を選ばないセキュアなアクセス」を実現します。

この記事では、SASEの設計原則から実際の段階的移行戦略まで、具体的な手順を交えて解説します。

SASEとゼロトラストの仕組みを理解する

SASEを構成する5つのコンポーネント

SASEはGartnerが2019年に提唱した概念で、以下の機能をクラウドサービスとして統合したものです。

SD-WAN：拠点間をインターネット経由でインテリジェントにルーティング
SWG（Secure Web Gateway）：Webアクセスのフィルタリング・マルウェア検知
CASB（Cloud Access Security Broker）：クラウドサービス利用の可視化・制御
ZTNA（Zero Trust Network Access）：ユーザー・デバイス単位の最小権限アクセス
FWaaS（Firewall as a Service）：クラウド型の次世代ファイアウォール

ゼロトラストとの統合フロー

ゼロトラストの核心は「Never Trust, Always Verify（決して信頼せず、常に検証せよ）」です。SASEにおけるアクセスフローを図解的に追うと以下のようになります。


[ユーザー端末]
     |
     | 1. IDプロバイダ（IdP）で認証 → MFA必須
     ↓
[SASEクラウドPoP（Point of Presence）]
     |
     | 2. デバイスポスチャチェック
     |    - OSパッチ適用済みか？
     |    - EDRエージェント起動中か？
     |    - 証明書は有効か？
     ↓
     | 3. ポリシーエンジンで評価
     |    ユーザー属性 × デバイス状態 × 接続元リスク
     ↓
     | 4. 最小権限でアプリケーションへ接続
     |    （IPアドレスではなくアプリIDレベルで制御）
     ↓
[SaaSアプリ or オンプレリソース]

従来のVPNはIPアドレスレベルで「ネットワークへの接続」を許可しますが、ZTNAは「特定のアプリへのアクセス」だけを許可します。この違いが横展開攻撃（ラテラルムーブメント）への耐性を大きく高めます。

段階的移行の設定例

Phase 1：既存SD-WANへのSASE機能の追加

既存のCisco Merakiを使っている環境であれば、Umbrella（SWG/CASB）との統合から始めるのが現実的です。


# Meraki Dashboard CLI相当の設定（APIベース）
# SD-WANトラフィックをUmbrellaへリダイレクト

curl -X POST https://api.meraki.com/api/v1/organizations/{orgId}/appliance/vpn/thirdPartyVPNPeers \
  -H "X-Cisco-Meraki-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "peers": [{
      "name": "Umbrella-SIG",
      "publicIp": "146.112.x.x",
      "privateSubnets": ["0.0.0.0/0"],
      "secret": "YOUR_IPSEC_SECRET",
      "ipsecPolicies": {
        "ikeCipherAlgo": ["aes256"],
        "ikeAuthAlgo": ["sha256"],
        "childCipherAlgo": ["aes256"],
        "childAuthAlgo": ["sha256"]
      }
    }]
  }'

Phase 2：ZTNAエージェントの展開

Zscaler Private Access（ZPA）を例にすると、App Connectorをオンプレに配置してアプリケーションを公開します。


# App Connector インストール（RHEL/CentOS系）
sudo rpm --import https://yum.zscaler.com/gpg-key.asc
sudo cat > /etc/yum.repos.d/zscaler.repo << EOF
[zscaler]
name=Zscaler Private Access Repository
baseurl=https://yum.zscaler.com/centos/8/x86_64
enabled=1
gpgcheck=1
EOF

sudo yum install zpa-connector -y

# プロビジョニングキーで初期設定
sudo /opt/zscaler/bin/zpa-connector --provision \
  --key "YOUR_PROVISIONING_KEY" \
  --cloud "zscaler.net"

# サービス起動・自動起動有効化
sudo systemctl enable --now zpa-connector
sudo systemctl status zpa-connector

現場でのベストプラクティス

移行フェーズの設計パターン

フェーズ	対象	主な施策	期間目安
Phase 1	インターネットトラフィック	SWG/CASBの導入、DNSセキュリティ	1〜3ヶ月
Phase 2	リモートアクセス	VPNからZTNAへの段階的切り替え	3〜6ヶ月
Phase 3	拠点間WAN	MPLS縮小とSD-WAN完全移行	6〜12ヶ月
Phase 4	統合・最適化	単一ポリシー管理、UEBA連携	12ヶ月以降

重要なのは「いきなり全部切り替えない」ことです。まずSWGをインラインに挿入してトラフィックを可視化するところから始め、影響範囲を把握してから次のフェーズへ進みましょう。

運用上のポイント

IdPとの連携を最初に固める：SASEの認証基盤はOkta・Azure ADなどのIdPが根幹。SSOとMFAを先に整備することが全体の前提になります。
Split Tunnelの設計：Microsoft 365などの主要SaaSはSASEのPoPを経由させず直接インターネットへ出すことでレイテンシを最適化できます。
PoP選定は遅延測定をもとに：各拠点から主要PoPへのRTTを事前に計測し、一番近いPoPを優先エントリーポイントに設定しましょう。

注意点・よくある落とし穴

デバイス証明書の管理を軽視しない：ZTNAのデバイスポスチャチェックはクライアント証明書の有効期限に依存します。期限切れで突然アクセス不能になる事故が現場では頻発しています。MDMと連携した自動更新の仕組みを必ず用意しましょう。
レガシーアプリケーションの例外処理：Kerberos認証や特定ポートに依存する古いオンプレアプリはZTNAと相性が悪いことがあります。移行前に全アプリケーションの認証方式とポート依存を棚卸ししておくことが必須です。
ベンダーロックインのリスク：SASEは単一ベンダーでの統合が管理しやすい反面、乗り換えコストが高くなります。APIの標準化状況や他製品との連携性を導入前に十分評価してください。
帯域コストの見直し：MPLS回線を残しつつSASEを追加すると一時的にコストが増加します。移行完了のマイルストーンを明確にしてMPLSの縮小計画とセットで経営層に説明しましょう。

まとめ

SASEとゼロトラストの統合は「一度で完成する」ものではなく、段階的に積み上げていくアーキテクチャです。まずインターネットトラフィックの可視化から始め、リモートアクセスのZTNA化、そして拠点間WANの最適化という順序で進めることで、現場への影響を最小化しながら着実に移行できます。

大切なのは「完璧な設計を目指してスタートを遅らせない」こと。SWG一つ入れるだけでも、これまで見えていなかったシャドーITや異常なトラフィックが可視化されます。その気づきが次のフェーズへの推進力になりますよ。まずは小さな一歩から、ぜひ現場で試してみてください。

```