ユーザー認証とは、システムへアクセスしようとしている利用者が、登録済みのユーザー本人であることを確認する仕組みです。
ID・パスワード、ワンタイムパスワード、認証アプリ、生体認証、セキュリティキー、パスキーなどが使われます。
企業のシステム設計では、「認証」「本人確認」「認可」を分けて考える必要があります。
NIST SP 800-63-4は、デジタルアイデンティティを、本人確認（identity proofing）、認証（authentication）、フェデレーション（federation）などに分けています。認証は、登録済みアカウントに紐づく認証器を利用者が実際に制御していることを検証するプロセスです。
ログインできた後に「どのデータを読めるか」「管理者操作をできるか」を決めるのは認可です。
ユーザー認証とは
ユーザー認証は、利用者が「私はこのアカウントの本人です」と主張したときに、その主張が妥当かを検証する処理です。
代表例はID・パスワードです。
ただし、現在の企業環境ではパスワードだけに依存すると、フィッシング、パスワードリスト、インフォスティーラー、パスワードスプレーなどで突破される可能性があります。
そのため、MFAやパスキーなどを組み合わせます。
認証・本人確認・認可の違い
この3つを混同すると、セキュリティ設計が曖昧になります。
| 用語 | 確認すること | 例 |
|---|---|---|
| 本人確認・Identity Proofing | その人物が誰か | 身分証、マイナンバーカード、eKYC |
| 認証・Authentication | そのアカウントを使っているのが登録者か | パスワード、MFA、パスキー |
| 認可・Authorization | 認証後に何をしてよいか | 閲覧権限、管理者権限、承認権限 |
ログインに成功したからといって、すべてのデータへアクセスさせてよいわけではありません。
逆に、認可設定が正しくても、認証が弱ければ攻撃者が正規ユーザーとして入れます。
認証要素の3分類
MFAでは、認証要素を大きく3種類に分けます。
| 要素 | 内容 | 例 |
|---|---|---|
| 知識 | 本人が知っている | パスワード、PIN |
| 所有 | 本人が持っている | スマートフォン、セキュリティキー |
| 生体 | 本人自身の特徴 | 指紋、顔 |
異なる要素を2つ以上組み合わせるのが多要素認証です。
MFAについては、多要素認証(MFA)とは？メリットや必要性を解説で詳しく整理しています。
主なユーザー認証方式
パスワード
最も一般的ですが、漏えい・使い回し・フィッシングの影響を受けます。
パスワードマネージャー、MFA、漏えいパスワード検知を組み合わせます。
SMS・メールOTP
導入しやすい方式ですが、フィッシングでリアルタイムに入力させられると突破される場合があります。
認証アプリ
TOTPやPush認証があります。
Push疲労攻撃やAiTMへの対策として、番号一致やフィッシング耐性のある方式への移行を検討します。
ハードウェアセキュリティキー
FIDO2/WebAuthnを使う方式は、正規ドメインと認証器を結び付けるため、一般的なリアルタイムフィッシングへの耐性があります。
パスキー
パスキーは公開鍵暗号を使う認証方式で、パスワードをサーバーへ送信しません。
サイトが対応している場合、英国NCSCもパスキーを推奨しています。
詳しくはパスキーとは？メリットや概要を解説を参照してください。
NIST SP 800-63-4のAAL
NIST SP 800-63B-4は、認証の保証レベルをAAL（Authenticator Assurance Level）として3段階に整理しています。
企業がそのまま採用しなければならない基準ではありませんが、重要システムほど強い認証へ上げる考え方として参考になります。
- AAL1：単一要素でも可
- AAL2：複数要素を要求
- AAL3：より強いハードウェアベースのフィッシング耐性等を要求
すべてのシステムへ同じ認証方式を適用するのではなく、リスクに応じて強度を変えます。
SSOとユーザー認証
SSOは、一度の認証結果を複数サービスで利用する仕組みです。
認証処理をIdPへ集約すると、退職者アカウント停止やMFA適用を一元化しやすくなります。
一方、IdPが侵害されると複数SaaSへ影響が広がるため、特権管理者、MFA、ログ、リカバリー手順を強くする必要があります。
SSOについては、シングルサインオン（SSO）とは 概要や必要性を解説で整理しています。
認証と認可を混同すると起きる問題
認証は「誰か」、認可は「何をしてよいか」です。
例えば、ユーザーAが正しくログインできても、他人の顧客情報をURLのIDを書き換えるだけで見られるなら、認可の問題です。
逆に、管理者権限を適切に設定していても、管理者のパスワードが盗まれれば、認証の問題から管理者権限が悪用されます。
ユーザー認証の記事では、MFAだけでなく認可との境界を理解することが実装ミスを減らします。
2026年の個人情報保護委員会も「アクセス者の識別と認証」を指摘
個人情報保護委員会が2026年9月に公表した2026年度第1四半期の監視・監督状況では、「アクセス者の識別と認証」に関する不備も指導対象になっています。
既知脆弱性の放置だけでなく、容易に推測できるID・パスワードなどの基本的な認証不備が、実際の漏えい等事案につながっています。
実インシデントで見る認証の弱点
CAMPFIRE：認証情報流出からクラウド環境へ侵害拡大
CAMPFIREでは、従業員が発行したGitHub Personal Access Tokenが個人開発用サーバーへ意図せずアップロードされ、第三者に悪用されました。
認証情報は「パスワード」だけではありません。
- APIキー
- PAT
- セッショントークン
- 秘密鍵
- OAuthトークン
も、ユーザーやシステムを認証する秘密情報です。
関連記事：CAMPFIREの不正アクセス、従業員がGitHubの認証情報を個人開発サーバーへアップ
ShinyHunters：SSO資格情報とMFAコードをビッシングで窃取
Google/Mandiantが2026年に警告した活動では、攻撃者がIT担当者を装って従業員へ電話し、偽ログインページへ誘導してSSOのID・パスワードやMFAコードを窃取する手口が確認されています。
関連記事：Googleが警告、ShinyHuntersがボイスフィッシングを起点としてSaaSへ不正アクセス
AiTM：従来型MFAでも突破される場合がある
SMSやTOTPを使ったMFAでも、攻撃者が利用者と正規サービスの間に入って認証情報とセッションを中継すると突破される場合があります。
詳しくは中間者攻撃(AiTM攻撃)とは？多要素認証で防げない理由と対策を解説で整理しています。
認証設計では「ログイン時」だけ見ない
ユーザー認証はログイン画面だけの機能ではありません。
企業ではアカウントのライフサイクル全体を管理します。
登録
誰にアカウントを発行するか。本人確認は十分か。
認証器の登録
誰がMFAデバイスやパスキーを登録できるか。
利用中
異常な国・端末・時間帯のアクセスを検知できるか。
復旧
パスワードリセットやMFA再登録が、攻撃者に悪用されないか。
異動
権限が新しい役割に合っているか。
退職
アカウント、セッション、APIキー、共有リンクを停止できるか。
管理者アカウントは通常ユーザーと分ける
管理者アカウントは、一般ユーザーより強い認証を使います。
確認したい項目は次です。
- 日常業務アカウントと管理者を分離
- フィッシング耐性MFA
- 特権アクセス端末
- 条件付きアクセス
- セッション時間短縮
- 管理操作ログ
- 緊急用アカウントの保護
- MFA登録変更の監視
管理者の認証突破は、全社影響へ直結します。
委託先・外部ユーザーも認証ポリシーへ含める
委託先やゲストユーザーだけMFAの例外にすると、弱い経路が残ります。
委託先のセキュリティ管理では、外部ユーザーについても、
- MFA
- 接続元
- 利用時間
- 端末
- 権限
- 契約終了時の停止
を確認します。
認証は自社社員だけの話ではありません。
ユーザー認証を選ぶ基準
| システム | 推奨する考え方 |
|---|---|
| 一般社内SaaS | SSO＋MFA |
| 管理者 | フィッシング耐性MFA＋特権管理 |
| 顧客サービス | パスキー、リスクベース認証、回復手順 |
| VPN・リモートアクセス | MFA＋端末状態確認 |
| 開発環境 | SSO＋MFA＋短寿命トークン |
| API・CI/CD | 人のパスワードではなく専用ID・Secret管理 |
認証方式だけでなく、アカウント復旧や認証情報の保管まで含めて判断します。
情報システム部門が確認したいポイント
- MFA適用率だけでなく例外ユーザーを把握しているか
- 特権IDはフィッシング耐性MFAか
- パスワードリセットが弱い本人確認になっていないか
- MFAデバイス追加を監視しているか
- セッショントークンを失効できるか
- APIキー・PATの期限と権限を限定しているか
- 退職時にすべての認証器を無効化しているか
- 外部委託先にも同じ認証基準を適用しているか
- SSO障害時の緊急アカウントを管理しているか
- 認証成功後の認可が最小権限になっているか
ユーザー認証は「ログインできるか」の機能ではなく、IDライフサイクル管理の一部です。
