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
    ├─ バッチ処理
    └─ 帳票・印刷処理