障害時に許可する認可処理
文書のダウンロード可否を判定する次の関数をレビューした。認可サーバには，文書ごとにダウンロードを禁止する利用者の一覧が登録されている。
def can_download(user, doc_id):
try:
policy = authz_client.get_policy(doc_id) # 認可サーバに問合せ
return user.id not in policy.denied_users
except Exception:
logger.warning("authz lookup failed")
return Trueアクセス制御の設計原則に照らした指摘として，最も適切なものはどれか。
- ア認可サーバの障害時にも業務を継続できるように例外時に True を返しているので，可用性を確保する設計であり，アクセス制御の観点からも問題はない。
- イ禁止された利用者以外を全て許可し，判定できないときも許可している。許可された利用者の一覧に基づいて判定し，判定できないときは拒否するように改めるべきである。
- ウ認可サーバへの問合せ結果を利用者ごとに長時間キャッシュし，以後の要求では問い合わせないようにすれば，障害時の誤った許可を防げるので，判定方法は今のままでよい。
- エ例外の詳細なメッセージやスタックトレースを利用者の画面に表示し，認可サーバの障害が原因であることを利用者が把握できるようにすべきである。
正解と解説を見る
正解 イ
この問題の基礎知識
- フェールセーフ（安全側に倒す）の考え方では，障害や例外によってアクセスの可否を判定できないときは拒否する。障害時に許可すると，障害を起こさせるだけで認可を回避される。
- 許可リスト方式は明示的に許可したものだけを許可し，拒否リスト方式は明示的に禁止したもの以外を全て許可する。拒否リスト方式では，登録漏れがそのまま不正な許可になる。
- デフォルト拒否（deny by default）は，どの規則にも当てはまらない要求を拒否する原則である。また，エラーメッセージに内部の詳細を表示すると，攻撃者にシステムの情報を与える。
ア認可サーバの障害時にも業務を継続できるように例外時に True を返しているので，可用性を確保する設計であり，アクセス制御の観点からも問題はない。
障害時にも機能を止めないことを優先して許可に倒すと，認可サーバを停止させたり応答を妨げたりするだけで，禁止された利用者も含めて誰でもダウンロードできてしまう。アクセス制御では，判定できないときは拒否する（安全側に倒す）のが原則である。
イ禁止された利用者以外を全て許可し，判定できないときも許可している。許可された利用者の一覧に基づいて判定し，判定できないときは拒否するように改めるべきである。正解
一覧に載っていない者を許可する方式は，登録漏れがそのまま不正な許可になる。明示的に許可された場合だけ許可するデフォルト拒否（deny by default）とし，例外などで判定できないときも拒否して，認可を回避されない状態で処理を終えるべきである。
ウ認可サーバへの問合せ結果を利用者ごとに長時間キャッシュし，以後の要求では問い合わせないようにすれば，障害時の誤った許可を防げるので，判定方法は今のままでよい。
長時間のキャッシュは，禁止の追加などの変更が反映されず，要求ごとに権限を検証するという原則に反する。また，キャッシュにない要求で例外が起きれば許可される点も，禁止一覧に載っていなければ許可する点も変わらない。
エ例外の詳細なメッセージやスタックトレースを利用者の画面に表示し，認可サーバの障害が原因であることを利用者が把握できるようにすべきである。
エラーメッセージに内部の詳細を含めると，システムの構成などの情報を攻撃者に与えることになり，避けるべきである。また，表示を変えても例外時に許可するという問題は解消しない。
検証用の出典出典照合済み
OWASP Authorization Cheat Sheet（Deny by Default，Validate the Permissions on Every Request，Exit Safely when Authorization Checks Fail） ／ NIST SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems（Appendix E Protective Defaults，Protective Failure）照合の根拠（5 件）
- イ（正解）: 明示的な規則に当てはまらない要求は拒否するデフォルト拒否とすべきで，禁止一覧にない者を許可する方式は改めるべき
one should not rely entirely on explicitly defined rules for matching all possible requests. For security purposes an application should be configured to deny access by default.
OWASP Authorization Cheat Sheet · Deny by Default（新しいタブで開きます） - イ（正解）・ア（誤り）: 例外や認可の失敗時に認可の回避につながる状態にしてはならないので，例外時に True を返すのは誤り
Verify the handling of exceptions and authorization failures. Ensure that such failures, no matter how unlikely, do not put the software into an unstable state that could lead to authorization bypass.
OWASP Authorization Cheat Sheet · Exit Safely when Authorization Checks Fail（新しいタブで開きます） - ア（誤り）: 構成要素（認可サーバ）の障害が許容できない損失につながってはならない（障害時に許可に倒すのは不可）
A failure of a system element neither results in an unacceptable loss nor invokes another loss scenario.
NIST SP 800-160 Vol. 1 Rev. 1 · Appendix E.23 Protective Failure（新しいタブで開きます） - ウ（誤り）: 権限は要求ごとに検証すべきであり，長時間キャッシュして以後問い合わせない方式はこれに反する
Permission should be validated correctly on every request, regardless of whether the request was initiated by an AJAX script, server-side, or any other source.
OWASP Authorization Cheat Sheet · Validate the Permissions on Every Request（新しいタブで開きます） - エ（誤り）: エラーメッセージにデバッグ出力などの内部情報を表示してはならない
Ensure sensitive information, such as system logs or debugging output, is not exposed in error messages.
OWASP Authorization Cheat Sheet · Exit Safely when Authorization Checks Fail（新しいタブで開きます）