認証・アクセス制御・パスワード管理｜本人確認から漏えい対策まで

パスワードを正しく入力できた利用者でも、会社の全データを操作してよいわけではありません。また、通信を暗号化していても、保存したパスワードが平文ならDB漏えい時の危険は残ります。本人確認、操作の許可、パスワードの保存、攻撃時の制御を一続きの仕組みとして理解しましょう。

認証と認可は別の判断

ログイン成功は認証の結果です。認可はデータの所有者や所属、役割、操作の種類を用いて要求ごとに評価します。画面にボタンを表示しないだけでは、直接送られた要求を止められないため、サーバ側で認可を実施します。

事例：申請者と承認者が使う経費システム

架空のB社では、申請者は自分の申請を閲覧・修正でき、承認者は担当部署の申請を承認できます。運用管理者はアカウントを管理しますが、経費の承認権限は持ちません。本文の申請・部署・アカウント番号は教材用の番号です。

申請者Aがログイン後に別部署の申請番号を送ったとしても、その申請を読めてはいけません。認証済み利用者IDと申請の所有者・部署を照合してから応答します。操作対象の番号が推測しにくいことは、この検査の代わりにはなりません。

認証後のセッションは、後続要求を同じ利用者と結び付けるための仕組みです。セッションID自体は秘密の認証情報として扱い、漏えい・固定化を防ぎます。CookieとWeb攻撃の詳しい関係はWeb攻撃の記事で扱います。

MFA：異なる要素を組み合わせる

認証要素は、知識（覚えている秘密）、所持（持っている認証器）、生体（身体的特徴）に分けられます。MFAは異なる種類の要素を組み合わせる認証です。パスワードと秘密の質問はどちらも知識要素なので、質問を増やしてもMFAにはなりません。

ワンタイムパスワードは一度または短時間しか使えない値ですが、偽サイトへ入力させて即座に中継する攻撃には注意が必要です。MFAならすべてフィッシング耐性があるとは言えません。WebAuthnのように接続先との結び付きを検証する方式と、入力値を中継できる方式では性質が異なります。

生体で端末内の認証鍵を利用可能にする方式では、サーバへ生体画像を送るとは限りません。方式の仕組みを見て、何をどこで確認するかを説明します。端末の紛失時、認証器交換時、回復時の本人確認が弱ければ、通常ログインの強化を迂回されます。

オンライン試行とオフライン推測を分ける

オンライン攻撃はログイン窓口へ試行を送る攻撃です。試行回数制限、遅延、ロックアウト、MFAなどが対策になります。オフライン攻撃は盗んだ保存値を手元で計算して候補と比較する攻撃です。ログイン窓口を通らないため、その窓口のロックアウトでは計算を止められません。

同じアカウントへの連続試行だけを見ると、多数アカウントに少数回ずつ試すパスワードスプレーを見逃す場合があります。アカウント単位の制御に加え、送信元、全体の試行傾向、端末などを組み合わせます。ただし同じIPを共有する正規利用者もいるため、IPだけで本人を断定しません。

ロックアウトは正規利用者も締め出す可能性があります。復旧手順や通知、制限の粒度を設計し、攻撃者が意図的に多数のアカウントを停止させる影響も評価します。固定した回数だけを覚えるのでなく、事例の利用形態と要求から判断します。

ハッシュ、ソルト、ストレッチングの役割

ハッシュは入力から一定形式の値を計算する関数です。パスワード照合では元の秘密を復号して取り出すのでなく、入力した候補から同じ方式で値を計算して保存値と比較します。ただし高速な一般用途ハッシュだけでは候補を大量に試しやすく、パスワード保存専用の計算コストを持つ方式を使います。

ソルトはパスワードごとに付加する十分なランダム値です。同じパスワードでもソルトが違えば保存値は変わり、事前計算表の使い回しや多数アカウントへの計算共有を難しくします。ソルトは通常保存値とともに保存でき、秘密にすること自体が中心ではありません。

ストレッチングは計算コストを高め、各候補の検証に資源を必要とさせる考え方です。Argon2idなどの方式は時間だけでなくメモリ負荷も利用します。具体的なパラメータは実行環境で調整し、サーバのログイン処理を破綻させない範囲で設定します。

登録・変更：salt = 保存する秘密ごとのランダム値
保存：方式、コスト設定、salt、計算済みhash
照合：候補と保存saltから同じ設定で計算
判定：計算結果を保存hashと比較
更新：必要に応じログイン成功時に新設定へ移行

暗号化と違ってハッシュ値から元のパスワードを復号する手順はありません。それでも候補の推測は可能です。「不可逆だから漏えいしても安全」とは言えません。漏えい時には影響調査、変更・無効化、関連セッションや認証器の確認などが必要です。ハッシュ一般と暗号の詳細は暗号・PKI・TLSの記事へつなげます。

パスワードの選択と変更の方針

十分な長さと推測しにくさに加え、漏えい済み・よく使われるパスワードを選ばせないこと、他サービスからの使い回しを減らすことが重要です。文字種を増やすだけでは、同じ秘密の再利用や偽サイトへの入力を解決しません。変更が必要な事象と回復手順を利用者へ分かりやすく示します。

保存する秘密を登録・変更する際は新しいランダムソルトを生成します。照合では保存した方式・コスト・ソルトを用い、専用ライブラリの検証機能を使います。失敗時の応答でアカウントの存在や内部の保存方式を不用意に知らせないようにし、秘密をデバッグログへ出力しません。

権限は付与から削除まで管理する

最小権限は、その役割に必要な操作だけを許す考え方です。異動・退職後も古い権限が残ると、ログイン方式を強化しても不要なデータへアクセスできます。申請・承認・設定を分け、定期的な棚卸しで現状の職務と一致しているか確認します。

職務分掌は不正や誤りを一人だけで完結させにくくする役割分離です。B社の運用管理者が自分に承認権限を与えられる設計では、役割を名目上分けても統制が弱くなります。特権付与の承認者と設定者、記録の確認者を事例に合わせて定めます。

ログイン成功だけでは、不正なデータ閲覧があったとは分かりません。対象の操作ログとつなぐ必要があります。機器の時刻と記録範囲の確認も必要です。ログ分析と初動対応の詳細は公開済みのインシデント対応記事で学べます。

演習1：認証と認可

条件：Aは正しくログインしたが、申請番号を変えると他部署の内容も読める。

問い：不足している制御は何か。

解答例：サーバで利用者の権限と対象申請の所属・所有者を照合する認可制御。

根拠と誤答の確認：ログインの本人確認は成立していても対象データへの許可は別です。「MFAを追加」だけでは対象の照合漏れを直せません。

演習2：MFAの要素

条件：ログインにはパスワードと秘密の質問を入力する。

問い：MFAと言えるか。

解答例：言えない。両方とも知識要素で、異なる種類の要素を組み合わせていないため。

根拠と誤答の確認：入力項目や段階の数と要素の種類は異なります。

演習3：ソルトの目的

条件：同じパスワードの2人に別々のランダムソルトを使う。

問い：この設計の目的を説明する。

解答例：同一パスワードでも保存値を変え、事前計算や候補計算の共有を難しくする。

根拠と誤答の確認：「ソルトを秘密にするため」では主目的を説明できません。

演習4：攻撃経路の違い

条件：攻撃者は保存hash・saltを取得し、手元で候補を計算する。

問い：ログイン5回失敗のロックアウトで止められるか。

解答例：止められない。候補の検証がログイン窓口を通らないため。

根拠と誤答の確認：この条件で直接効くのは保存方式の計算コスト等です。

演習5：回復経路

条件：通常ログインはMFAだが、電話で氏名だけを伝えると認証器を再登録できる。

問い：問題点を述べる。

解答例：弱い本人確認の回復手順から認証器を置換でき、通常ログインのMFAを迂回される。

根拠と誤答の確認：正常時の要素数だけを見ても、認証器登録の権限が乗っ取られる経路を見落とします。

演習6：職務と権限

条件：営業部から総務部に異動したAに、営業部の承認権限が残っている。

問い：必要な処置を述べる。

解答例：新しい職務に合わせて権限を変更し、不要になった営業部の承認権限を削除する。

根拠と誤答の確認：パスワード変更は本人確認の秘密を変えるだけで、不要な許可は残ります。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。技術仕様とIPAの公開資料を照合し、特定年度の問題本文を前提にせず学べる構成にしています。

IPA APシラバスVer.7.2

IPA 2024年秋期AP午後 採点講評

NIST SP800-63B-4 認証器

OWASP パスワード保存

OWASP 認可

関連テーマを続けて学ぶ

AP科目Bの記述式｜設問・本文根拠・条件から短い答案を作る

脆弱性とサプライチェーン対策｜更新・配布・委託先の信頼を点検する

Web攻撃と対策｜SQLインジェクション・XSS・CSRFを処理の場所で理解する

暗号・署名・PKI・TLS｜鍵と証明書の役割を通信の流れで理解する

インシデント対応：証拠・封じ込め・復旧