平文Telnetを縮小
5250専用経路
TCP対応ZTNAの検証
不要ポートの閉鎖
共有IDの縮小
利用頻度が高い機能
外部連携が必要な機能
仕様が明確な機能
更新が頻繁な機能
すべてのRPG資産を同時に移行する必要はありません。
SASEへ移行する対象を明確にした
一般公開アクセスと社員アクセスを分けた
IdPとMFAを設計した
端末状態の判定条件を決めた
障害時の経路を決めた
フェイルオープン／クローズを決めた
SASEを迂回する経路を確認した
ログの保存先と保存期間を決めた
Django Adminを一般公開していない
ALBの受信元を制限した
AWS WAFを設定した
RDSをプライベートサブネットへ配置した
Djangoの認可を維持した
ALLOWED_HOSTSを限定した
転送ヘッダーの信頼範囲を確認した
Secure Cookieを設定した
WebSocketを試験した
監査ログを取得した
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移行を安全に成功させるための基本方針です。
AWSのSASE解説
SASEは特定製品ではなく、ネットワーク機能とセキュリティ機能をクラウド側で統合するアーキテクチャ概念です。ゼロトラストは同義語ではなく、SASEで採用し得る設計原則として区別します。