1 認証情報の概要
1.1 認証と認可の違い
認証（authentication）は、本人または主体が誰（何）であるかを確かめる働きを指す。認可（authorization）は、認証された主体がどの操作や資源にアクセスできるかを決める働きである。両者は別の工程として扱う必要があり、認証だけでは権限管理は成立しない。
1.2 認証情報の役割と目的
認証情報は、利用者やシステムの正当性を判定するために用いられる材料である。目的は、なりすましの防止、アクセス制御の前提条件の成立、利用履歴の追跡可能化であり、適切な設計により攻撃耐性や障害時の影響範囲が左右される。
1.3 認証方式における位置づけ
認証方式は、照合に使うデータの形（秘密を知っている、所持している、生体特徴が一致する、署名できる等）と検証手順で構成される。認証情報はその中核となる要素であり、方式が異なれば管理方法、漏えい時の被害、運用負荷も変化する。
2 認証情報の種類
2.1 知識に基づく認証情報
2.1.1 パスワード
パスワードは、利用者が知っている秘密文字列を提示し、サーバ側または検証機構が照合する方式である。実装や運用が比較的容易である一方、推測攻撃や漏えい後の悪用に対する設計が不可欠となる。
2.1.1.1 パスワードの生成と管理の基本
生成面では、短い語彙語の単純な選択を避け、推測可能性を下げることが基本となる。管理面では、平文の保存を避け、強度要件は組織のリスク許容度に合わせて段階化し、入力支援や自動生成の仕組みを併用すると運用の継続性が高まる。さらに、変更頻度の単純な義務化よりも、攻撃兆候に応じた見直しや再設定手順の整備が重視される。
2.1.2 秘密の質問や追加コード
秘密の質問は、利用者が答えを知っている形式で追加の証明を行う。追加コードは、登録済み手段への送信やアプリ生成により一時的な値を求める方式である。いずれも推測可能性、復旧経路の弱点、再利用の有無により効果が大きく変わる。
2.2 所持に基づく認証情報
2.2.1 ワンタイムパスワード
ワンタイムパスワード（OTP）は、一定の条件で短時間だけ有効な値を用いる認証情報である。漏えいしても同時期に無効化されやすい点が利点だが、利用タイミングのズレや通信の妨害が弱点になる。
2.2.1.1 時刻同期型とイベント同期型
時刻同期型は、現在時刻から値を導出し、クライアントとサーバで時刻の整合を取る。イベント同期型は、利用ごとのカウント進行に基づくため、途中での利用漏れや並列端末があるとズレが生じやすい。運用では、許容される時刻誤差やカウンタ再同期手順を明示しておくことが重要である。
2.2.2 セキュリティキー
セキュリティキーは、ハードウェアや同等の保護環境上で認証情報を保持し、署名や安全なチャレンジ応答を行う。フィッシング耐性を高めやすく、従来型の知識要素より攻撃面が限定されることがある。鍵の保管が鍵そのものになるため、紛失・破損に備えたバックアップ設計が求められる。
2.3 生体に基づく認証情報
2.3.1 指紋・顔などの特徴情報
指紋や顔などの生体特徴は、採取したデータから特徴量を抽出し、照合のために利用される。生体は本人性を示しやすい一方、完全に再生成できない性質があるため、漏えい時の取り返しが困難になりうる。認証システム側では、再試行回数や閾値設定、なりすまし耐性を調整する必要がある。
2.3.2 生体情報の取り扱い上の考慮点
保存形態は、特徴量を保持するか、端末内処理に寄せるかでリスクが変わる。加えて、同意取得、プライバシー配慮、代替手段（回復経路）の整備が運用上の重要論点になる。誤受入れと誤拒否のバランスを誤ると、利便性と安全性の双方に影響が及ぶ。
2.4 所有物・状態に依存する方式
2.4.1 セッション情報と再認証
セッション情報は、ログイン後の有効期間中にアクセスを許す状態を表す。再認証は、一定条件（操作の重要度、時間経過、リスク検知等）で認証を更新する仕組みである。セッションの長さと更新頻度は、利便性だけでなく攻撃機会の広がりを左右する。
2.4.2 デバイスバインド
デバイスバインドは、認証後の利用を特定の端末や環境と結びつける考え方である。端末の変更や乗り換えには手間が増える可能性があるが、不正な再利用を抑える効果がある。バインドの根拠となる情報の保護度合いや、端末交換時の安全な移行手順がポイントになる。
2.5 署名・鍵に基づく認証情報
2.5.1 公開鍵・秘密鍵
公開鍵と秘密鍵の組を用いる方式では、秘密鍵で生成した情報を公開鍵で検証できる。秘密鍵は露出すると防御力が大きく低下するため、保管場所とアクセス制御が設計の中心になる。公開鍵は配布されることが前提だが、誰の鍵かの裏付け（後述の証明書等）が重要となる。
2.5.2 証明書
証明書は、公開鍵が特定の主体に結び付くことを第三者が署名して示す文書である。信頼連鎖と失効情報の扱いにより、鍵の真正性を運用で担保する。正しい発行元の選定や、更新を取りこぼさない体制がなければ、期限切れ時に認証が停止する。
2.5.3 デジタル署名
デジタル署名は、メッセージの内容に対して署名者の鍵で計算を行い、検証側が整合性と署名者性を確認できるようにする。認証に用いる場合、チャレンジなどと結び付けて、リプレイ（再送）を防ぐ設計が一般的である。署名の検証方法はアルゴリズム選定と実装品質に依存する。
3 認証情報のライフサイクル
3.1 作成と初期登録
3.1.1 初期パス設定と安全な受け渡し
初期パスの設定では、本人性確認と安全な受け渡し経路の確保が必要になる。仮パスワードを一時的に配布する場合は、最初のログイン後に即時変更させ、配布チャネルの漏えい耐性を評価する。端末やブラウザのキャッシュ保存など、周辺環境の挙動も考慮すべき要素である。
3.1.2 鍵ペア生成と証明書発行
鍵ペアの生成は、強度の確保と乱数品質の維持が前提となる。生成後は、証明書の発行手続きによって公開鍵と主体の結び付きを確立する。発行時の本人確認や、登録情報の正確さが誤った認証につながるため、入力ミスの検知機構も検討対象になる。
3.2 保管と秘匿
3.2.1 ハッシュ化とソルト
パスワードを保管する場合、ハッシュ化は基本である。単純なハッシュではなく、ソルト（追加値）と、計算コストを調整できる方式を用いることで、攻撃者が事前計算しにくくなる。さらに、パラメータ更新に備えた移行計画を用意すると、長期運用での耐性低下を抑えられる。
3.2.2 暗号化と鍵管理
認証情報そのものや復元用データを暗号化する場合、鍵管理が別のリスク要素になる。暗号化鍵の保管場所、アクセス制御、ローテーション、バックアップの整合性を設計しないと、暗号化の効果が損なわれる。特に復元可能性と監査の両立を意識して方針を定めることが重要である。
3.2.3 ハードウェア保護（概要）
ハードウェア保護は、秘密鍵やトークン生成に関わる要素を、専用デバイスや安全な実行環境に寄せる考え方である。盗難やマルウェア感染の影響を減らす狙いがあるが、物理紛失時の手当や、デバイス交換時の移行手順が運用の要になる。導入形態によって互換性やコストも変わる。
3.3 利用と照合の流れ
3.3.1 サーバ側検証の考え方
サーバ側では、提示された認証情報を受け取り、検証手順に従って整合性を確認する。攻撃対策としては、試行回数制限、レート制御、異常検知、失敗時の応答抑制（情報漏えいの抑制）が重要である。検証が重い場合は、負荷平準化や段階的判定を考慮する。
3.3.2 クライアント側での扱い
クライアント側では、認証情報をどこに保持するか、入力や送信の際に不要な漏えいが起きないかを評価する。自動入力機能やログ出力、例外メッセージへの混入など、周辺の挙動が事故を招くことがある。安全な送信経路の使用と、保存方針の明確化が基本となる。
3.4 失効・更新・ローテーション
3.4.1 期限付き認証と失効
期限付きの仕組みでは、一定の時点で有効性が切れる。失効の運用には、期限到来だけでなく、漏えい疑い時の即時無効化も含める必要がある。失効情報の配布遅延や、キャッシュの扱いが不正継続を許す場合があるため、設計段階で整合性要件を定める。
3.4.2 ローテーション計画
ローテーションは、認証情報の定期更新や鍵入替を行う活動である。影響範囲を小さくするために、旧情報の段階的受容、同時対応期間、移行手順をあらかじめ定義する。特に複数サービスで共通利用している場合、同時一斉更新は障害につながり得るため、依存関係の洗い出しが前提になる。
3.5 監査と記録
3.5.1 認証イベントのログ設計
認証イベントのログは、成功・失敗・例外・更新などの出来事を追跡できるようにする。ただし、認証情報そのものや復元可能な形の秘密を記録しない設計が必須である。ログ粒度は、調査に必要な最小限に絞り、相関に使う識別子は匿名化やマスキングを検討する。
3.5.2 監査目的と保存期間
監査では、運用の妥当性確認、不正行為の検知、インシデント対応の証跡確保が目的になる。保存期間は法令や社内規程、データ保護の方針と整合させる。長期保管は価値と同時に漏えいリスクも高めるため、暗号化やアクセス制御、削除手順まで含めて管理する。
4 認証情報を守るための実務
4.1 パスワード管理の実践
4.1.1 強度要件の設定方針
強度要件は、攻撃者モデルと利用者負担のバランスで決める。長さ重視や、共通パターンの禁止、入力補助の設計などを組み合わせると、単なる複雑性ルールより運用が安定しやすい。要件は一度決めたら終わりではなく、漏えい状況や攻撃手法の変化に合わせて見直す。
4.1.2 リスト型攻撃への対策
リスト型攻撃は、過去に漏れた資格情報の組合せを使って試す手法である。対策としては、レート制限、アカウントロックの扱い（サービス妨害への配慮）、追加の検証段階（危険度に応じた多要素化）、そして漏えい照合に基づく警告や再設定誘導が挙げられる。検知後の対応フローがないと、技術的防御が効果を持ちにくい。
4.1.3 パスワード再利用の防止
再利用は被害を連鎖させるため、別サービスでの漏えいが即座に悪用される。禁止方針に加え、既存利用者への段階的移行、変更時の誘導、教育的サポートが必要になる。パスワードマネージャの利用推奨など、実現可能な代替手段を同時に提示すると受容性が上がる。
4.2 マルチファクタ認証
4.2.1 代表的な組み合わせ
組み合わせの例としては、知識要素と所持要素の併用（パスワード＋ワンタイムコード）、あるいは所持要素＋鍵による署名（セキュリティキー等）がある。生体を含める場合もあるが、回復手段やプライバシー面を同時に設計する必要がある。組合せは技術だけでなく運用の成熟度に合わせるべきである。
4.2.2 回復手段の設計
回復（リセット）は攻撃経路になり得るため、本人性確認を強め、段階的にアクセスを制御する。バックアップコードや予備端末の管理方針を明確にし、回復操作のログも監査可能にする。回復の容易さと不正耐性はトレードオフであり、組織のリスク許容度を反映させる。
4.3 侵害を前提とした設計
4.3.1 最小権限と被害封じ込め
万一の資格情報漏えいを想定し、認証後に付与する権限を最小化する。特権操作は追加の検証を挟み、被害範囲が広がらないように分離する。利用者単位、端末単位、リソース単位で権限を切り分けると、侵害後の継続性が下がる。
4.3.2 セッション管理と不正検知
セッションは攻撃者にとって現実的な足場になりうる。短い有効期間、厳格な失効処理、再認証のタイミング調整により悪用余地を抑える。異常検知では、地域や端末の急変、失敗パターン、同一資格情報の多重利用などの兆候を用いる。ただし誤検知で業務が止まらないよう、救済と説明可能性も要件になる。
4.4 鍵・トークンの取り扱い
4.4.1 トークンの寿命と権限付与
トークンは期限とスコープが重要である。短寿命化により再利用の時間窓を狭め、権限は必要最小限に絞る。長期有効のものは利便性が高くても被害が拡大しやすく、運用の中でローテーションと失効確認を確実に行う設計が求められる。
4.4.2 スコープ設計の基本
スコープはトークンが許す操作範囲を明確にする要素である。過度に広い権限は不正時の影響が大きくなるため、用途別に分割する。さらに、読み取り専用と書き込み、管理操作と通常操作の区別を設けると調査と封じ込めが容易になる。
4.4.3 盗用時の手当て
盗用が疑われる場合、即時の無効化と影響調査が必要になる。アカウントの強制再認証、関連セッションの失効、権限の見直しを段階的に実施する。原因究明のために、いつ・どこで・どの経路から不正が成立したかをログから追える形にしておくことが重要である。
4.5 よくある誤り
4.5.1 認証情報のログ混入
パスワードやトークンをデバッグ出力に含める事故は代表的である。マスク処理やログ方針の統一、レビュー観点の明確化により回避できる。ログ保管基盤が侵害された場合の二次被害も大きいため、初期段階から禁止ルールを設ける。
4.5.2 平文保管や不適切な配布
平文保管やメール等による不適切な配布は、漏えい時の被害を直接増幅させる。安全な保管、暗号化、短寿命化、チャネル保護を組み合わせることでリスクを下げられる。配布経路は実装だけでなく運用手続き（誰が、いつ、どの経路で）まで含めて評価する。
4.5.3 実装依存の設定ミス
誤ったパラメータ、期限の設定漏れ、失効チェックの省略などは、理論上の安全性を損なう。さらに、ライブラリの更新忘れや互換性確保のための例外指定が穴になることがある。設計書と実装の対応を検証するテスト観点（境界条件、エラー経路、並行実行）を用意することが実務上の要点になる。
5 ユーザー体験と運用のバランス
5.1 使いやすさの設計（例：段階的な強化）
段階的な強化は、リスク状況に応じて要求する認証レベルを調整する考え方である。通常時は負担を抑えつつ、不審な操作や端末変化があったときだけ追加要素を要求する。これにより安全性の向上と離脱率の抑制を同時に狙える。
5.2 リセット・回復フローの安全性
回復は「使いやすいこと」が攻撃者にとっても都合になりうる。本人確認の強さ、回復に用いるチャネル、再設定までの制限を組み合わせて安全性を確保する。さらに、回復イベントを監査ログに残し、必要に応じて追加の確認を挟む運用が望ましい。
5.3 ユーザー教育とサポート導線
教育は、単なる注意喚起よりも、具体的な行動指針として提供されるべきである。正しい回復手順、認証情報の扱い、偽サイトや誘導への警戒を、サポート導線と接続して伝えると効果が出やすい。案内は短く明確にし、問い合わせ先の判断材料も用意する。
6 ケーススタディ（一般化された例）
6.1 アプリケーションでの認証設計例
ある業務アプリでは、ユーザー登録時にメール確認を行い、その後にパスワード設定と多要素化を段階的に導入する。ログイン失敗が一定回数を超えた場合は追加認証へ切り替え、セッションは短い有効期間と定期更新で管理する。パスワードはハッシュ化し、関連イベントは監査可能な形式で記録する。
6.2 API認証（概要）とトークン運用例
APIでは、クライアントにトークンを発行し、スコープを操作単位で分ける。アクセス時は有効期限と失効状態を確認し、不正の兆候があればトークン単位で無効化する。トークンを更新する際は、段階的移行期間を設けて通信断を抑えつつ、鍵・署名の方式を可能な範囲で統一する。
6.3 組織での統制（概要）と監査例
組織では、認証情報の種類ごとに責任分界と手順書を整備し、管理者権限の付与や回復操作を承認フローと連動させる。監査では、ログイン成功失敗の分布、失効・更新の実施率、設定の逸脱（記録漏れ、期限未チェック）を点検し、是正計画を追跡する。技術対策と手続きの両面で統制を維持することが狙いである。