「正しい利用者としてログインできた」と「その情報を見てよい」は別の判断です。アクセス制御を扱う文章を読むとき、この二つを一緒にすると、権限の問題に認証強化だけを答えてしまいます。本記事では、学習用の架空事例を使い、主体・対象・操作を切り分ける方法を紹介します。実際の試験問題の転載や出題予測、公式の採点基準ではありません。
認証は誰かの確認、認可は操作を許す判断
利用者が提示した認証情報などを検証するのが認証です。特定の対象への操作を許すか判断するのが認可です。ここでは、認証済みの利用者に対する認可を扱います。ログインが成功しても、他部署の資料や管理機能まで使えるとは限りません。
| 観点 | 読み取るもの | 架空の例 |
|---|---|---|
| 主体 | 誰が操作するか | 営業担当A |
| 対象 | 何を操作するか | 担当外の顧客の見積書 |
| 操作 | 何をしようとするか | 閲覧、更新、承認 |
| 条件 | 何に基づき許可するか | 担当顧客、役割、承認状態 |
「社員だから閲覧可能」とだけ整理すると、担当や役割に応じた制限を落とします。対象を文書全体とするか、文書の一部とするかも本文の条件で確認します。
架空事例：ログインは正しくても、閲覧範囲が広すぎる
次は説明用に作成した事例です。実際の組織・試験問題・検証結果ではありません。
ある見積システムでは、営業担当は自分が担当する顧客の見積書だけを閲覧できます。Aは自分のアカウントでログインしました。しかし、担当外の顧客の見積書もシステムから返されました。
この条件では「Aが誰かを確認できない」ことよりも、「Aにその見積書を返してよいか」という判断に注目します。追加の認証を導入しても、担当関係の確認が欠けたままでは閲覧範囲の問題は残ります。
学習上の対策案は「サーバー側で、認証された利用者と対象の担当関係を照合し、権限がない要求には見積書を返さない」です。実際の設問では、問われた実装箇所や制約に合わせて説明を調整します。画面のボタンを隠すだけで十分か、要求を処理する側にも判定があるかを分けて読みましょう。
「閲覧できる」から「承認できる」を推測しない
同じ対象でも、操作ごとに権限は変わります。閲覧を許した利用者に、更新・削除・承認まで許しているとは限りません。役割名だけで判断せず、役割に割り当てられた操作を確認します。
| 学習用の役割例 | 閲覧 | 更新 | 承認 |
|---|---|---|---|
| 営業担当 | 担当分のみ | 下書きのみ | 不可 |
| 承認担当 | 承認対象分 | 不可 | 承認対象分 |
これは権限設計を考えるための例で、すべての業務へ適用する標準設定ではありません。利用者が複数の役割を持つ場合や、一時的な代理権限がある場合は、その条件も追加します。
演習で使う確認手順
- 不正な操作をした主体と、影響を受ける対象を特定する。
- 認証の失敗・認証情報の悪用と、認可判断の欠落を分ける。
- 許可される操作と、実際に行われた操作を並べる。
- 判定に必要な情報がどこにあり、どの処理で照合するかを読む。
- 対策を書いたら、同じ事例を当てはめて問題が残らないか考える。
復習ノートには「認証を強化する」とだけ残さず、「Aが担当外の見積書を取得できた。対象との担当関係の判定を確認する」のように書くと、次の演習でも論点を再現できます。
本文から根拠を拾う手順は科目Bの根拠読み、演習全体の位置付けは支援士ロードマップへ進んで確認してください。
参照資料
IPAのSCシラバスではアクセス制御やアクセス権の管理が扱われています。制度・資料の更新は試験要綱・シラバスの案内で確認してください。本記事の表と事例は編集部が作成した学習補助です。
