定義
認証・権限などの確認に失敗したとき、確認できない操作を拒否・保留するアクセス制御の設計。業務全体の停止や、物理的な安全の保証を意味するものではない。
Fail OpenとFail Closedの違い
ここでは、認証・権限確認に失敗したときのアクセス制御として説明します。Fail Openは、確認できなくても操作を通す振る舞いです。Fail Closedは、確認できない操作を止める振る舞いです。「許可できない」と「判定できない」は理由が異なりますが、どちらも確認なしに権限を与える根拠にはなりません。
| 状態 | Fail Openの例 | Fail Closedの例 |
|---|---|---|
| 権限サービスが停止 | 応答がないので更新を許可する | 更新を保留し、再確認を案内する |
| 認証期限が切れた | 以前使えたので処理を続ける | 操作を止め、再認証を求める |
| 承認記録を取得できない | AIが承認済みと書いたので送信する | 正式な承認を確認するまで送信しない |
業務を全部止めるとは限らない
顧客への送信承認を確認できないなら、送信を止めます。一方、資料の入力・閲覧・下書き作成がそれぞれ別に許可されているなら、その範囲で作業を続ける設計は可能です。止める操作と続けられる操作を分けるには、操作ごとの権限と依存関係を明確にしておく必要があります。
また、アクセスを閉じることが、あらゆる分野の物理的な安全を意味するわけではありません。避難経路や機械制御などでは、障害時に人や設備をどの状態に置くべきかを別途設計します。「安全なら必ず閉じる」と分野をまたいで一般化しないでください。
AIエージェントでの確認項目
- 権限判定のタイムアウト・例外時に、拒否や保留が解除されないか。
- 再試行でも、利用者・対象・操作・認証期限を確認するか。
- 別のツールへ切り替えることで、制限を迂回できないか。
- HTTPのエラー応答だけでなく、データが変更されていないことも確認したか。
- 再開条件と、問い合わせ先を利用者へ示せるか。
例えば、権限サービスの障害時は503、期限切れは401、権限外の操作は403とする設計が考えられます。これは状況を分けるための例であり、HTTPコードだけで安全が保証されるわけではありません。実際のAPI仕様とクライアントの再試行動作を合わせて確認します。
関連する説明と検証
模擬APIでの権限検証結果では、権限判定サービスの障害時に更新が止まり、データが変わらないことを確認しています。対象・操作・利用者で決める権限設計、ガードレールも参照してください。
出典とこのページの位置づけ
CWE-636は、エラー時により緩い制限へ移る弱点を扱っています。業務例と確認項目はPAP Researchによる整理です。アクセス制御の動作と、業務・物理システムの安全状態は個別に評価する必要があります。
