SASEとは？AWS・Django構築例とRPGレガシー環境の移行ポイント

はじめに

企業システムは、かつてのように本社やデータセンターの中だけで完結しなくなりました。

現在は、次のような接続が同時に存在します。

社員が自宅から業務システムを利用する
支店からAWS上のWebアプリケーションへ接続する
Microsoft 365などのSaaSを利用する
外部委託先が管理画面へ接続する
オンプレミスに古い基幹システムが残っている
IBM i／AS/400上でRPG資産を運用している
クラウドとレガシー環境を併用している

このような環境で、すべての通信をいったん本社へ集め、社内ファイアウォールやVPN装置を通してからインターネットへ出す方法には限界があります。

そこで使われる考え方が、**SASE（Secure Access Service Edge：サシー）**です。

本記事では、次の2つを独立した構築・移行例として解説します。

AWS上で稼働するDjango環境へSASEを適用する例
IBM i／AS/400のRPG環境など、レガシー環境をSASEへ段階的に移行する例

Djangoプロジェクトの中にRPGを組み込む構成ではありません。

SASEとは何か

SASEは、ネットワーク機能とセキュリティ機能をクラウド中心の基盤へ統合するアーキテクチャです。

GartnerはSASEを、SD-WANなどのネットワーク機能と、Web、クラウドサービス、プライベートアプリケーションへの安全なアクセス機能を統合して提供するものとして整理しています。利用者の場所、端末、アプリケーションの配置場所に依存せず、一貫した接続とセキュリティを提供することが中心です。

分かりやすく表すと、次のようになります。

SASE
├─ ネットワーク接続
│  └─ SD-WAN
│
└─ セキュリティ
   ├─ ZTNA
   ├─ SWG
   ├─ CASB
   ├─ DLP
   └─ FWaaS

ただし、これは概念を理解するための分類です。

すべてのSASE製品が同じ機能、同じ性能、同じ構成を持つわけではありません。また、SASEはAWSやDjangoのようなソフトウェア製品ではなく、ネットワークとセキュリティをどう配置するかという設計思想です。

従来型ネットワークとの違い

従来型

従来の企業ネットワークでは、社員をVPNで社内ネットワークへ接続し、本社やデータセンターのセキュリティ機器を通していました。

在宅勤務者
    │
    │ VPN
    ▼
本社・データセンター
    │
    ├─ ファイアウォール
    ├─ プロキシ
    ├─ IPS
    └─ Webフィルター
    │
    ▼
AWS・SaaS・インターネット

この方式では、AWS上のアプリケーションやSaaSを利用するだけでも、本社を経由する場合があります。

また、VPNへ接続した端末が広い社内ネットワークへ到達できる設計になっていると、認証情報の窃取や端末感染が発生した際に、内部探索や横展開を許す原因になります。

SASE型

SASEでは、利用者を近いSASE拠点へ接続し、そこで本人、端末、接続先、リスクなどを確認します。

社員・支店・委託先
        │
        ▼
┌──────── SASE基盤 ────────┐
│ ID・MFA確認                  │
│ 端末状態確認                 │
│ Web通信検査                  │
│ SaaS利用制御                 │
│ データ持ち出し制御           │
│ アプリ単位のアクセス制御     │
└──────────┬─────────────┘
           │
     ┌─────┼─────┐
     ▼     ▼     ▼
    AWS   SaaS  社内システム

重要なのは、社内ネットワークに接続させることではありません。

誰が、どの端末から、どのアプリケーションへ、どの条件で接続できるかを制御すること

これがSASEとゼロトラストの中心です。

NISTのゼロトラストアーキテクチャも、静的なネットワーク境界から、ユーザー、端末、資産、リソースを中心とした防御へ移行する考え方を示しています。

SASEを構成する主な機能

SD-WAN

SD-WANは、拠点、データセンター、クラウド間の通信経路をソフトウェアで制御する仕組みです。

例えば、次のように通信を振り分けます。

Microsoft 365
→ インターネットから直接接続

AWS業務システム
→ SASE経由で接続

基幹システム
→ 閉域網または専用経路

回線障害
→ バックアップ回線へ切り替え

単に通信を暗号化するだけではなく、通信先、アプリケーション、回線状態、優先度などに応じて経路を制御します。

ZTNA

ZTNAは、ネットワーク全体ではなく、許可されたアプリケーションやリソースだけへ接続させる仕組みです。

従来のVPN
利用者 → 社内ネットワークへ接続

ZTNA
利用者 → 許可された業務アプリだけへ接続

例えば、Django管理者にはDjango Adminだけ、監視担当者にはGrafanaだけを許可できます。

AWS Verified Accessも、VPNを必須とせず、ユーザーや端末などの信頼情報とポリシーを使ってアプリケーションへのアクセスを判定するサービスです。ポリシーが定義されるまでは、アプリケーションへの要求が既定で拒否されます。

ただし、AWS Verified AccessはSASE全体ではありません。

主に、AWS上のアプリケーションへゼロトラスト型アクセスを実装するための一要素です。

SWG

SWGは、利用者のWeb通信を検査するクラウド型のセキュアWebゲートウェイです。

主に次の制御を行います。

危険なURLの遮断
フィッシングサイトの遮断
マルウェアダウンロードの検査
Webカテゴリによる制御
ファイルアップロードの制限
HTTPS通信の検査

CASB

CASBは、SaaSやクラウドサービスの利用状況を可視化・制御します。

例えば、次のような制御です。

会社のMicrosoft 365
→ 利用許可

個人用オンラインストレージ
→ 顧客情報のアップロード禁止

未承認の生成AI
→ ファイル送信禁止

DLP

DLPは、機密データの持ち出しを検知または遮断する仕組みです。

対象には次のような情報があります。

個人情報
顧客番号
口座情報
契約書
ソースコード
認証情報
社内限定資料

FWaaS

FWaaSは、従来拠点ごとに設置していたファイアウォール機能を、クラウドサービスとして提供するものです。

IPアドレスやポートだけでなく、アプリケーション、利用者、端末、接続先などを含めた制御を行います。

SASEとAWSの関係

SASEとAWSは同じものではありません。

AWSはクラウドインフラストラクチャであり、SASEは利用者、拠点、クラウド、SaaSなどを安全に接続するためのアーキテクチャです。

AWSには、SASEまたはゼロトラスト構成を補完するサービスがあります。

目的	AWSのサービス例
アプリ単位のアクセス制御	AWS Verified Access
Webアプリケーション保護	AWS WAF
負荷分散	Application Load Balancer
VPC内の通信制御	Security Group
VPC間・拠点間の中継	Transit Gateway
オンプレミス接続	Site-to-Site VPN、Direct Connect
AWS管理者の認証統合	IAM Identity Center
操作履歴	CloudTrail
通信フロー記録	VPC Flow Logs
サーバー管理	Systems Manager

これらを組み合わせても、社員のすべてのWebアクセス、未承認SaaS、個人用ストレージ、外部生成AIなどの利用まで自動的に管理できるわけではありません。

一般的には、次のように役割を分けます。

SASE製品
├─ 社員端末のWebアクセス制御
├─ SaaS利用制御
├─ ZTNA
├─ DLP
├─ 拠点接続
└─ 統合ポリシー

AWS
├─ AWS内のネットワーク分離
├─ AWSアプリへの最終的なアクセス制御
├─ WAF
├─ IAM
├─ Security Group
└─ ログ・監視

AWS上のDjango環境へSASEを導入する構築例

前提

ここでは、次のような独立したDjango環境を想定します。

DjangoをEC2、ECSまたはEKSで稼働
PostgreSQLをAmazon RDSで運用
RedisをAmazon ElastiCacheで運用
静的ファイルをAmazon S3で保管
ALBをリバースプロキシとして使用
一般利用者向け画面と管理者向け画面がある
社員や管理者はSASEを経由する

このDjangoプロジェクトにRPGは含まれません。

一般公開サイトと社内管理画面を分離する

SASEを導入する際に重要なのは、一般ユーザーのアクセスと社員・管理者のアクセスを混同しないことです。

一般公開部分

一般顧客が閲覧するDjangoサイトは、通常、企業のSASEクライアントを経由しません。

一般利用者
    │
    ▼
CloudFront
    │
AWS WAF
    │
ALB
    │
Django

AWS WAFは、CloudFront、ALB、API Gateway、Verified Accessなどに関連付け、対象へ到達するHTTP／HTTPSリクエストを監視・制御できます。

社員・管理者向け部分

Django Adminや社内管理画面は、SASEまたはZTNA経由に限定します。

管理端末
    │
    │ ID・MFA・端末状態確認
    ▼
SASE／ZTNA
    │
AWS Verified Access
    │
Internal ALB
    │
Django管理画面

次のように、用途ごとにドメインや接続経路を分けます。

www.example.com
→ 一般公開サイト

mypage.example.com
→ 顧客向けマイページ

internal.example.com
→ 社員向け業務画面

admin.example.com
→ Django Admin

monitor.example.com
→ 運用監視画面

推奨する全体構成

【一般利用者】

Internet
   │
   ▼
CloudFront
   │
AWS WAF
   │
Public ALB
   │
Django公開機能


【社員・管理者】

管理端末
   │
SASE／ZTNA
   │
AWS Verified Access
   │
Internal ALB
   │
Django社内機能


【Django内部】

Django
├─ RDS PostgreSQL
├─ ElastiCache Redis
├─ S3
├─ CloudWatch
└─ Secrets Manager

公開系と管理系で、同じALBや同じセキュリティポリシーを使う必要はありません。

管理画面には、公開サイトよりも厳しい条件を設定します。

対象	認証	端末条件	接続元
公開サイト	不要または顧客認証	原則なし	全世界
マイページ	顧客認証・必要に応じMFA	原則なし	リスク判定
社内画面	SSO・MFA	管理端末	SASE経由
Django Admin	強固なMFA	管理端末・EDR正常	ZTNA経由
監視画面	管理者認証	管理端末	ZTNA経由

Django側で実施すべき設定

SASEだけに認可を任せない

SASEやVerified Accessが判断するのは、主に「この利用者をこのアプリケーションへ接続させてよいか」です。

Djangoでは、その後の業務権限を判断します。

IdP
→ 誰であるか

SASE／ZTNA
→ この端末から接続してよいか

Django
→ どの画面と機能を使えるか

業務ロジック
→ どのデータを操作できるか

例えば、Django管理画面へ接続できる利用者であっても、すべてのモデルを変更できる権限を与える必要はありません。

Django側では、次の制御を維持します。

グループ権限
モデル権限
オブジェクト単位の認可
テナント単位の分離
部署単位のデータ制限
重要操作時の再認証
操作監査ログ
セッション失効

リバースプロキシ経由の設定に注意する

SASE、CloudFront、ALBなどを経由すると、Djangoが直接TLSを終端しない構成があります。

代表的な設定例は次のとおりです。

ALLOWED_HOSTS = [
    "www.example.com",
    "internal.example.com",
    "admin.example.com",
]

CSRF_TRUSTED_ORIGINS = [
    "https://www.example.com",
    "https://internal.example.com",
    "https://admin.example.com",
]

SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

SECURE_PROXY_SSL_HEADER = (
    "HTTP_X_FORWARDED_PROTO",
    "https",
)

ただし、SECURE_PROXY_SSL_HEADERは無条件に設定してよいものではありません。

Django公式ドキュメントは、プロキシを管理しているか、対象ヘッダーを適切に設定・削除することが保証されている場合だけ使用するよう注意しています。

攻撃者がDjangoへ直接到達できる状態で転送ヘッダーを信頼すると、偽装されたヘッダーを受け入れる危険があります。

そのため、次の条件を満たす必要があります。

Djangoへ直接到達させない
        ＋
ALBなど正規経路以外をSecurity Groupで拒否する
        ＋
プロキシで外部入力の転送ヘッダーを上書き・除去する

また、DjangoはALLOWED_HOSTSによってHostヘッダーを検証します。Secure属性付きのセッションCookieとCSRF Cookieの利用も公式ドキュメントで推奨されています。

WebSocketを使用する場合

Django ChannelsなどでWebSocketを使用している場合は、通常のHTTP通信とは別に試験します。

Application Load BalancerはWebSocketをネイティブにサポートし、HTTP接続を永続的なWebSocket接続へアップグレードできます。

ただし、経路上にSASEやZTNAを追加した場合、次を確認する必要があります。

WebSocketのUpgradeヘッダーが維持されるか
長時間接続が切断されないか
SASE側のアイドルタイムアウト
ALBのアイドルタイムアウト
認証期限切れ後の既存接続
切断時の再接続
Redis障害時の動作
クライアントIPの記録方法
WAFルールによる誤遮断

通常画面が表示できるだけでは、WebSocketの移行試験は完了していません。

AWS・Django環境で起きやすい失敗

SASEを迂回できる公開経路が残る

正規経路
管理者 → SASE → Verified Access → Django

迂回経路
攻撃者 → Public ALB → Django管理画面

Django AdminをZTNA化しても、同じ管理画面へパブリックALBから直接到達できれば意味がありません。

管理画面は、内部ALB、Security Group、DNS、ルーティングなどを使って、正規経路からしか到達できないようにします。

送信元IPだけで社員を判定する

SASE経由では、Djangoから見えるIPアドレスがSASE事業者の出口IPになる場合があります。

従来の次のような判定だけに依存してはいけません。

会社の固定IPだから管理画面を許可

利用者ID、MFA、端末状態、所属グループ、アプリケーション権限を組み合わせます。

WAFを入れればDjangoの認可が不要だと思う

AWS WAFはHTTPリクエストを検査できますが、業務データの所有者や操作権限までは判断できません。

例えば、次の攻撃はDjango側の認可不備です。

利用者AがURLのcustomer_idを変更
        ↓
利用者Bの情報を閲覧

WAFではなく、Djangoのオブジェクト単位認可で防ぐ必要があります。

RPGなどのレガシー環境へSASEを適用する例

ここからは、AWS・Django環境とは別の例です。

次のような既存環境を想定します。

本社・支店
    │
    │ 5250エミュレーター
    ▼
IBM i／AS/400
    │
    ├─ RPGプログラム
    ├─ Db2 for i
    ├─ バッチ処理
    └─ 帳票・印刷処理

SASE移行の目的は、RPGをDjangoへ組み込むことではなく、古い接続方式を安全に管理し、必要に応じて段階的にアプリケーション境界を作ることです。

RPG環境を一括してZTNA化してはいけない理由

Webアプリケーションは、多くの場合HTTPSを前提とします。

一方、レガシー環境では次のような通信が存在します。

5250端末
Telnet
Telnet over TLS
ODBC／JDBC
FTP／SFTP
プリンターセッション
固定IP通信
独自ポート
長時間接続
夜間バッチ
システム間連携

IBM iのTelnetは、通常接続でポート23、TLS接続でポート992を使用する構成が標準的です。IBMの資料でも、通常のTelnetが23、セキュアな接続が992として説明されています。

したがって、Webブラウザー向けのZTNA機能だけでは、5250をそのまま移行できない可能性があります。

製品選定時には、「ZTNA対応」という言葉だけで判断せず、対象プロトコルを確認します。

RPG環境の段階的な移行方法

フェーズ1：通信を棚卸しする

最初に、どの端末がどのポートへ接続しているかを確認します。

確認項目	内容
利用者	社員、委託先、運用管理者
接続端末	Windows端末、専用端末
プロトコル	5250、Telnet、TLS、ODBC、FTP
接続先	IBM iのIP、ホスト名、ポート
認証	個人ID、共有ID、サービスID
セッション	接続時間、切断時の動作
バッチ	実行時刻、接続元、依存処理
帳票	プリンター、スプール、転送先
障害時	代替経路、緊急ID

ポート番号だけでなく、その通信を止めた場合に、どの業務が停止するかを確認します。

フェーズ2：平文通信を減らす

5250で平文Telnetを使っている場合は、可能な範囲でTLS接続へ移行します。

従来
端末 → Telnet 23 → IBM i

改善
端末 → Telnet over TLS 992 → IBM i

ただし、TLS化とSASE化は同じではありません。

TLS化は通信内容の盗聴防止であり、SASEは利用者、端末、接続先、ポリシーを含めてアクセスを管理する考え方です。

フェーズ3：5250専用の限定経路を作る

最初からVPNを全面廃止する必要はありません。

レガシー環境では、次のような限定VPNまたは専用セグメントを残す方法があります。

管理端末
    │
MFA付きVPNまたはTCP対応ZTNA
    │
5250専用セグメント
    │
IBM iのポート992だけ許可

重要なのは、VPNへ接続した後にIBM i周辺のネットワーク全体を公開しないことです。

許可
IBM i：992/TCP

拒否
他サーバー
他ポート
管理ネットワーク
バックアップネットワーク

これは完全なレガシー脱却ではありませんが、接続範囲を狭めることでリスクを低減できます。

フェーズ4：TCP対応ZTNAを検証する

非Webアプリケーションを扱えるZTNA製品であれば、5250などのTCP通信をアプリケーション単位で公開できる可能性があります。

ただし、本番移行前に次を検証します。

5250エミュレーターが正常に接続できるか
クライアント追加ソフトが必要か
アイドルタイムアウトが業務に合うか
再認証でセッションが切断されないか
経路切り替え時に画面が維持されるか
印刷セッションが利用できるか
DNS名が正しく解決されるか
固定IP前提の制御が壊れないか
障害時に元の経路へ戻せるか

「TCPに対応している」だけで、5250のすべての利用形態に対応するとは限りません。

フェーズ5：必要な機能だけAPI化する

RPGプログラムをすべて書き直す必要はありません。

IBM iのIntegrated Web Servicesでは、ILEプログラムやサービスプログラムをREST Webサービスとして展開できます。IBMの公式資料には、ILEプログラムをRESTサービスとして公開する構成と手順が示されています。

これはDjangoとの統合を意味するものではありません。

APIの呼び出し元は、Java、.NET、別のクラウドアプリケーション、モバイルアプリケーションなど、業務要件に応じて選択できます。

新しい業務アプリ
      │
      │ HTTPS／REST
      ▼
API管理基盤
      │
      ▼
IBM i Integrated Web Services
      │
      ▼
既存RPGプログラム

IBMも、RPGやILEプログラムをREST Webサービスとしてクラウドアプリケーションと連携させる例を公開しています。

ただし、既存プログラムをそのまま外部公開してはいけません。

API境界で次を実装します。

認証
認可
入力値検証
レート制限
タイムアウト
監査ログ
エラーの変換
二重実行防止
接続元制限
TLS

RPGをAPI化する際の注意点

プログラム名をそのままAPIにしない

悪い例：

POST /api/CUSTCHG01

これでは、内部プログラムの都合が外部仕様へ漏れ出します。

良い例：

POST /api/v1/customers/{customer_id}/address-change

APIは、既存プログラム単位ではなく、業務機能単位で設計します。

更新処理の二重実行を防ぐ

ネットワークがタイムアウトしても、IBM i側では処理が完了している場合があります。

その状態で再送すると、二重登録が発生する可能性があります。

1回目
API呼び出し
   ↓
IBM iでは登録完了
   ↓
応答だけタイムアウト

2回目
同じ要求を再送
   ↓
二重登録

対策として、要求ごとに一意なIDを付与します。

{
  "request_id": "BRANCH01-20260725-000123",
  "customer_id": "100001",
  "new_address": "..."
}

同じrequest_idが再送された場合は、新しい処理を実行せず、前回の結果を返します。

レガシー環境移行で特に注意すべきポイント

共有ID

古い基幹システムでは、部署単位の共有ユーザーが残っていることがあります。

共有IDを使うと、IBM iのログだけでは実際の操作者を特定できません。

すぐに個人IDへ変更できない場合は、まずSASEまたはZTNA側で個人を認証し、次のログを関連付けます。

SASE利用者ID
    ↓
接続時刻
    ↓
接続先IBM i
    ↓
5250共有ID
    ↓
IBM i操作ログ

最終的には、個人単位の識別へ移行することが望まれます。

TLS復号

SASEのHTTPS検査では、通信をいったん復号して検査する場合があります。

古いクライアント、クライアント証明書、証明書固定、独自TLS実装では、復号によって通信できなくなる可能性があります。

そのため、次の順で導入します。

検知のみ
  ↓
対象アプリを分類
  ↓
互換性試験
  ↓
復号対象を限定
  ↓
問題のある通信は例外化

DNS

レガシー端末では、hostsファイル、古いDNSサフィックス、固定IPなどに依存している場合があります。

SASE移行時には、次を確認します。

内部DNSをSASE経由で利用できるか
IBM iのホスト名を解決できるか
DNS障害時の動作
固定IPからFQDNへの変更可否
Split DNSの設計
名前解決先が拠点ごとに異ならないか

サービスアカウント

夜間バッチやシステム間連携に、人間用のMFAを要求してはいけません。

人間
→ SSO、MFA、端末状態確認

システム
→ mTLS、短期トークン、署名、
   サービスアカウント、秘密情報管理

人間とシステムでは、認証方式を分けます。

AWS・DjangoとRPG環境を同時に保有する企業の場合

両方の環境を保有していても、DjangoとRPGを直接結合する必要はありません。

SASEの管理対象として並列に扱います。

社員・支店
    │
    ▼
SASE
├─ ZTNA → AWS上のDjango業務画面
│
├─ TCP制御 → IBM iの5250
│
├─ SWG → インターネット
│
└─ CASB → Microsoft 365などのSaaS

SASEは、複数の接続先へ共通のID、端末、ログ、ポリシーを適用する役割を持ちます。

DjangoとRPGのアプリケーション構造を混ぜるものではありません。

現実的な移行ロードマップ

第1段階：可視化

利用者を整理
端末を整理
通信先を整理
ポートを整理
SaaSを整理
共有IDを整理
障害時経路を整理

第2段階：ID統合

IdP導入
MFA必須化
管理者ID分離
委託先IDの期限管理
退職者IDの停止
端末状態確認

第3段階：WebアプリケーションのZTNA化

Django Admin
社内管理画面
Grafana
運用ポータル
チケット管理画面

HTTPSアプリケーションから先に移行します。

第4段階：Web・SaaS通信をSSEへ移行

SWG
CASB
DLP
未承認SaaS検知
生成AIへのデータ送信制御

最初は遮断せず、ログ取得から開始します。

第5段階：拠点をSD-WAN化

回線冗長化
アプリケーション別経路制御
インターネットブレイクアウト
AWS向け経路
基幹システム向け経路

第6段階：レガシー通信を限定

平文Telnetを縮小
5250専用経路
TCP対応ZTNAの検証
不要ポートの閉鎖
共有IDの縮小

第7段階：必要なRPG機能をAPI化

利用頻度が高い機能
外部連携が必要な機能
仕様が明確な機能
更新が頻繁な機能

すべてのRPG資産を同時に移行する必要はありません。

導入時のチェックリスト

SASE全体

SASEへ移行する対象を明確にした
一般公開アクセスと社員アクセスを分けた
IdPとMFAを設計した
端末状態の判定条件を決めた
障害時の経路を決めた
フェイルオープン／クローズを決めた
SASEを迂回する経路を確認した
ログの保存先と保存期間を決めた

AWS・Django

Django Adminを一般公開していない
ALBの受信元を制限した
AWS WAFを設定した
RDSをプライベートサブネットへ配置した
Djangoの認可を維持した
ALLOWED_HOSTSを限定した
転送ヘッダーの信頼範囲を確認した
Secure Cookieを設定した
WebSocketを試験した
監査ログを取得した

RPG・レガシー環境

5250の利用者を確認した
利用ポートを確認した
平文Telnetを確認した
プリンター通信を確認した
バッチ通信を確認した
共有IDを確認した
長時間セッションを試験した
TCP対応ZTNAの互換性を試験した
APIの二重実行対策を実装した
切り戻し手順を作成した

まとめ

SASEは、DjangoやRPGを作り替えるためのアプリケーションフレームワークではありません。

ネットワーク接続とセキュリティをクラウド中心に統合し、利用者、端末、接続先、データに応じてアクセスを制御するアーキテクチャです。

AWS上のDjango環境では、一般公開部分と社員・管理者向け部分を分離し、管理系アクセスをSASE、ZTNA、AWS Verified Accessなどで保護します。

一般利用者
→ CloudFront → AWS WAF → ALB → Django

社員・管理者
→ SASE／ZTNA → Verified Access → Internal ALB → Django

一方、RPGなどのレガシー環境では、5250や独自TCP通信を考慮し、VPNの即時廃止や一括ZTNA化を避けます。

第1段階
通信を可視化する

第2段階
暗号化と接続範囲を改善する

第3段階
限定VPNまたはTCP対応ZTNAへ移行する

第4段階
必要な業務機能だけAPI化する

第5段階
古い接続方式を段階的に縮小する

重要なのは、すべての環境を同じ方法で移行しないことです。

AWS・DjangoはHTTPSとアプリケーション単位のアクセス制御を中心に設計し、RPGなどのレガシー環境は既存プロトコルと業務継続を守りながら段階的に移行する。

この分離こそが、SASE移行を安全に成功させるための基本方針です。

出典・最終確認（2026年7月31日）

AWSのSASE解説

SASEは特定製品ではなく、ネットワーク機能とセキュリティ機能をクラウド側で統合するアーキテクチャ概念です。ゼロトラストは同義語ではなく、SASEで採用し得る設計原則として区別します。