重要な操作を再確認するステップアップ認証の設計
SSOログイン後も、管理者変更やデータ出力などの高リスク操作を守るステップアップ認証の基準とSaaSへの適用方法を解説します。
SSOに成功したからといって、その後のすべての操作を同じ信頼レベルで許可してよいとは限りません。ログイン後にセッションが盗まれたり、利用者が席を離れた間に端末が悪用されたりする可能性があります。近年のIAMで重視される継続的な検証とは、「誰がログインしたか」だけでなく、「これから行う操作に十分な認証を経たか」を確認する考え方です。
ステップアップ認証は、通常時にはSSOの利便性を保ち、リスクの高い操作の直前だけMFAや再認証を追加で要求します。すべての画面で繰り返し認証させる方法より利用者の負担を抑えながら、重要な境界へ統制を集中できます。
どの操作にステップアップ認証が必要か
まず、事故が起きた場合の影響が大きい操作を分類します。SaaSでは次のような操作が代表的です。
- 管理者ロールの付与と権限ポリシーの変更
- SSO、ドメイン、MFA、SCIM設定の変更
- 顧客データの大量閲覧やエクスポート
- APIキー、リカバリーコード、請求情報へのアクセス
- アカウント復旧と緊急用アカウントの利用
単純な閲覧や日常的な編集まで高リスクにすると、認証疲れや回避運用を招きます。データの機密性、変更を元に戻せるか、テナント全体への影響を基準に対象を絞りましょう。権限範囲の考え方は認証と認可の違いも参考にしてください。
SSOセッションと追加認証を分けて設計する
認証時刻と強度を記録する
アプリケーションはログイン済みかどうかだけでなく、最後の認証時刻と利用した認証手段も判断材料にします。たとえば管理設定の変更には直近10分以内のMFAを求め、条件を満たさなければIdPへ再認証を要求できます。ただし、時間だけでリスクがなくなるわけではありません。新しい端末、不審な場所、権限昇格などのシグナルもポリシーの検討対象にします。
再認証後は元の操作へ安全に戻れるようにし、重要操作の承認トークンは短時間に限定して通常セッションと分離します。セッションの有効期限と強制ログアウトはSSOセッション管理ガイドで確認できます。
復旧経路も同じ強度で守る
攻撃者は強固なログインより、弱いパスワード再設定やMFAリセットを狙う場合があります。ヘルプデスクがMFAを解除したり、管理者権限を代理で付与したりする際にも、本人確認、二重承認、監査記録を適用します。運用基準はMFAリセットのセキュリティガイドを参考にしてください。
監査できるポリシーとして運用する
ポリシーには対象操作、要求する認証手段、有効時間、失敗時の処理、例外の承認者を明記します。ログには利用者とテナント、要求した操作、追加認証の結果、ポリシーのバージョンを残します。導入後は成功率、離脱率、例外利用数を確認し、セキュリティと使いやすさのバランスを調整しましょう。
AxiPassを利用すると、顧客ごとのテナントでOIDC/SAML SSOとMFAを一元化し、SCIMでアカウントのライフサイクルを管理しながら、SSO非対応アプリをSWAで接続できます。ログイン統合を出発点として重要操作ごとに必要な信頼レベルを定義し、SaaSの認証境界をより精密に設計しましょう。