どんな場面で検討するか
社内Webアプリや協力会社のアクセスを、ネットワーク内外だけで判定せず、ID・端末条件・アプリ単位で制御したい場合。
組織で使う条件
許可/拒否ポリシーとアプリ側認可を別に管理し、退職・委託終了時の失効を試す。 IdP/トンネル障害時に誰がどう復旧するかを記録し、アクセスログを確認する。
採用前に試すこと
- 合成アプリに社員役A・外部役B・無権限役Cを用意し、アプリごとのAccessポリシーを作る。
- 許可/拒否/未ログインを試し、オリジン直アクセスで保護を迂回できないか確認する。
- Bのグループを失効させ、再ログイン/既存セッション/ログを照合する。
合格と判断する条件
- 必要な役だけが許可され、端末条件を使う場合は条件差を説明できる。
- Cと未ログインは保護対象へ到達できず、直接経路の対策が成立する。
- 合意した失効時間以内にBが拒否され、担当者と復旧経路が決まる。
見落としたくない点
- Accessを導入しただけでアプリ内部の役割権限やオリジン直接アクセスが解決するとみなさない。 端末配布・IdP連携ができない場合はブラウザアクセス等の適用範囲を絞って比較する。
- Accessを導入しただけでアプリ内部の役割権限やオリジン直接アクセスが解決するとみなさない。
- 端末配布・IdP連携ができない場合はブラウザアクセス等の適用範囲を絞って比較する。