アクセス制御の試験問題への適用
「ログインできる」と「その操作をしてよい」は別です。部署、環境、期限、グループ、直接のAPI要求などを含む事例から、実際に許可される範囲を確かめます。
この単元で学ぶこと
- 主体・資源・操作・条件を分けて権限を表す
- 最小権限と職務分離を事例へ適用する
- 役割や属性、グループ経由の権限を理解する
- 異動・退職・期限終了時に権限を回収する
本文解説
権限表を読む 売上表を、営業員は閲覧だけ、主任は閲覧と更新、管理担当は削除も可とします。営業員の更新は拒否します。同じ売上表にアクセスする人でも操作範囲は異なり、所属が同じというだけで主任の権限を使えることにはなりません。
環境を区別する 試験環境の更新権限は、本番環境の更新権限を意味しません。同名のAPIでも対象が違います。許可を記述するときは操作名だけでなく対象の識別子や環境も定め、試験用認証情報が本番で動かないことを拒否側の試験で確認します。
グループと継承を追う 個別には閲覧しか許していなくても、所属グループや親フォルダーの継承によって更新や削除ができる場合があります。直接設定の画面だけでなく、権限の合成規則を調べて実効権限を確認します。許可と拒否の優先順位を全製品共通と決め付けてはいけません。
属性条件を確認する 経理部所属AND管理端末という条件なら、経理部員でも私物端末からは許可されません。部署、端末状態、情報区分、時刻などを使うときは、属性を誰が更新し、どの時点の値を判断するかも重要です。古い部署情報が残れば不要な権限につながります。
共有リンクの事例 リンクを知る全員が閲覧できる設定は、リンクが転送されると部署外へ広がります。閲覧だけでも顧客情報は漏えいします。対象者や所属を制限し、有効期限、再共有、失効の動作を確認します。暗号化通信を使っていても受信者の制限とは別の問題です。
画面を経由しない要求 ボタンを隠してもAPIが無条件に処理すれば操作できます。自分の申請だけを読める要件なら、要求された申請と要求者の関係をサーバー側で検証します。識別子を推測しにくくするだけで認可の代わりにせず、他人の対象を指定した要求を拒否できるか確認します。
例外権限と自動処理 障害対応の臨時権限は、承認、対象、期限、操作記録、回収方法を定めます。夜間バッチも必要な入力の参照と出力の保存へ絞ります。人ではない処理だから無制限でよいとはせず、用途別のアカウントと責任者を管理します。
終了時と変更後の確認 退職や作業終了時はアカウントだけでなくキーやセッション等の入口を確認します。権限変更後は必要な操作の成功と禁止操作の拒否を両方試します。操作ログを保護して、申請した権限と実際の動作にずれがないか追えるようにします。
図解
重要ポイント
- 主体・資源・操作・条件を明確にする。
- 認証済みでも操作の許可は別に判断する。
- 直接付与以外の経路を含む実効権限を確認する。
- 異動や終了時の回収と定期棚卸しを行う。
間違えやすい点
- 読み取りだけなら誰に許可しても安全とは考えない。
- ロールの名前だけで職務分離が成立したとしない。
- 画面の非表示をAPIの権限制御と同一視しない。
用語解説
- 最小権限
- 担当する仕事に必要な対象と操作へアクセス権を限定する原則。
- RBAC
- 職務などに対応する役割へ権限をまとめ、その役割を利用者へ割り当てるアクセス制御。
- ABAC
- 主体・資源・操作・環境等の属性をポリシーに照らして許可を判断するアクセス制御。
- 実効権限
- 個別設定、グループ、継承等と適用規則を合わせ、実際に利用できる操作の範囲。
- 職務分離
- 申請と承認などの職務を分け、一人で不適切な処理を完結しにくくする管理。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。