認証とは？ 仕組みなど押さえておきたい基本を徹底解説

認証とは、サービスやシステムを使おうとする人や端末が、想定した本人かどうかを確かめる仕組みです。IDとパスワードだけで済ませる運用は、フィッシング詐欺、パスワードリスト攻撃、辞書攻撃などに弱く、クラウドサービスや管理者アカウントでは限界が出やすくなります。見直しの優先順位は、重要アカウントから多要素認証を適用すること、ログイン後のセッション管理を含めて設計すること、認証だけでなく認可まで点検することです。

認証とは

認証とは、Webサービスやシステムを利用しようとする人物や端末が、正当な利用者本人であることを確認する行為です。まず「誰か」を確かめ、その後に利用を許可する流れになります。

ここで区別したいのは、認証とログインは同じ言葉ではないという点です。認証は本人確認の処理であり、ログインは認証が成功した結果としてサービスを利用できる状態になることを指します。ログアウトは、その認証済み状態を終了させる操作です。

認証が扱う対象

認証の対象は人だけとは限りません。APIクライアント、端末、サービス間通信なども認証の対象になります。ただし、利用者向けのサービスで問題になりやすいのは、人を対象にした認証です。本記事でも、人物の認証を中心に説明します。

認証が決めているのは「入れるかどうか」だけではない

実務では、認証は単にログインの可否を決めるだけではありません。どの程度の確からしさで本人とみなすか、どの場面で追加確認を求めるかまで含めて設計します。たとえば、通常利用と、管理画面での重要操作では、求める強度を同じにしないほうが安全なことがあります。

認証の仕組み

認証は、利用者が提示した情報と、サービス側が信頼できる根拠として保持している情報を使って、本人性を確かめる仕組みです。古典的な例はIDとパスワードですが、それだけではありません。ワンタイムパスワード、ICカード、デジタル証明書、生体認証、パスキー、FIDO2 なども認証の手段です。

サービス側は平文パスワードを前提にしない

パスワード認証で重要なのは、サービス側が平文のパスワードをそのまま保持しないことです。一般的には、パスワードそのものではなく、ハッシュ化などで得られる検証用の情報を保持し、入力された値から同じ手順で作った結果と一致するかを確認します。

ただし、保存方法だけでは不十分です。漏えい時に推測されにくい設計と、攻撃者が大量試行しにくい運用を組み合わせる必要があります。レート制限、異常検知、アカウント保護を一緒に考えないと、認証の強度は上がりません。

ログイン後のセッション管理まで含めて認証設計になる

ログイン後は、毎回パスワードを入力しなくても使えるよう、通常はセッションやトークンで認証済み状態を維持します。ここが弱いと、パスワードが破られなくてもセッショントークンの窃取で乗っ取られることがあります。

そのため、認証方式の選定だけでは足りません。セッションの有効期限、端末や接続条件が変わったときの再認証、ログアウト時の無効化、異常な利用の検知まで含めて設計する必要があります。

認証が必要な理由

認証が必要なのは、第三者によるなりすましを防ぐためです。PCへのログイン、社内システム、VPN接続、無線LAN接続、クラウドサービスなど、入口がある場所には認証が必要になります。

認証が弱いと、攻撃者は漏えいした資格情報や盗んだトークンを使って正規利用者として振る舞えます。特にクラウドの管理者アカウントや重要業務に接続できるアカウントは、侵害されたときの影響が大きくなります。

認証強化は「侵害後の被害範囲」にも効く

認証を強化する目的は、侵入の確率を下げることだけではありません。侵害が起きた場合でも、重要アカウントや高リスク操作で追加確認を要求していれば、到達できる範囲を狭めやすくなります。認証は、被害を受けにくくする設計であると同時に、被害を広げにくくする設計でもあります。

認証の代表的な分類

シングル要素認証と多要素認証

認証は、使う要素の数で大きく分けられます。

• シングル要素認証：1つの要素だけで認証する方式
• 多要素認証（MFA）：異なる要素を2つ以上組み合わせる方式

ここで重要なのは「異なる要素」であることです。たとえば、パスワードと秘密の質問はどちらも知識情報なので、厳密には多要素認証とは言えません。多要素認証として強度を出すには、知識、所有、生体のうち異なる種類を組み合わせる必要があります。

MFAでも強さは同じではない

MFAは有効ですが、方式によって耐性は変わります。偽サイトに誘導して入力を中継する手口では、パスワードだけでなくOTPまで盗まれることがあります。したがって、MFAを導入すれば終わりではなく、どの方式を使うか、どのアカウントから優先するかまで決める必要があります。

サービス自身で認証する方式と、連携結果を使う方式

認証は、どこで本人確認を行うかでも整理できます。

• サービス自身が認証する方式：サービスがIDとパスワード、OTP、パスキーなどを使って直接本人確認する
• 連携結果を使う方式：外部のIdPが行った認証結果をサービス側が受け取って利用する

企業のSSOでは後者がよく使われます。代表例としては SAML認証 や OpenID Connect による連携があります。利用者の入口を集約できる一方で、入口側の設計が弱いと影響も集約されるため、IdP側の保護が重要になります。

3種類の認証要素

認証要素は、一般に知識情報、所有情報、生体情報の3つに分けて考えます。MFAを検討するときの基礎になる分類です。

知識情報を用いた認証

パスワード、PIN、秘密の質問など、本人しか知らないことを前提にした方式です。導入しやすい一方で、漏えい、推測、使い回しに弱く、単独運用では安全性が不足しやすくなります。

知識情報は強くしても盗まれる

長く複雑なパスワードは一定の効果がありますが、フィッシングやマルウェアで盗まれれば、それだけでは防げません。知識情報は単独で守るより、MFAや異常検知と組み合わせて、盗まれてもそのまま成立しにくい設計にしたほうが現実的です。

所有情報を用いた認証

スマートフォン、ICカード、ハードウェアトークンなど、本人しか持っていないものを使う方式です。代表例には、認証アプリで生成するOTPや、プッシュ通知による承認があります。

所有情報は回復手順まで設計しないと崩れる

所有要素は強力ですが、端末紛失、故障、機種変更は必ず起こります。そこからどう回復させるかの手順が甘いと、攻撃者に悪用される余地が生まれます。方式の選定では、導入のしやすさだけでなく、再登録、再発行、本人確認まで含めた運用が必要です。

生体情報を用いた認証

指紋、顔、虹彩、声など、その人自身の特徴を使う方式です。利便性は高い一方で、生体情報そのものは変更しにくいため、一般的にはサーバーへ直接送らず、端末内で照合する設計が採られます。

生体認証は端末保護と代替手段が前提になる

生体認証だけを見て安全と判断するのは不十分です。端末ロック、暗号化、紛失時対策、失敗時の代替手段まで含めて考えないと、利用性と安全性の両立が崩れます。

代表的な認証方式の例

多要素認証（MFA）

MFAは、異なる認証要素を組み合わせて、不正ログインを成立しにくくする方式です。重要アカウント、管理者、外部公開サービスから優先して適用するのが現実的です。

導入時に先に決めるべきこと

どのアカウントから適用するか、回復手順をどうするか、例外を認める条件をどうするかを先に決めておくと、導入後の混乱を減らしやすくなります。

ワンタイムパスワード（OTP）

一定時間だけ有効なコードを使う方式です。SMS、認証アプリ、メール送付など実装はさまざまです。

OTPは方式ごとに注意点が違う

SMSは導入しやすい一方で、番号移行や端末紛失時の論点があります。認証アプリは通信に依存しにくい反面、端末移行やバックアップの手順が必要です。メールOTPは、メールアカウント自体が侵害されていれば突破されやすくなります。

証明書認証

デジタル証明書を使って端末や利用者を認証する方式です。条件が整えば強固な認証を実現しやすい一方で、発行、配布、更新、失効といったライフサイクル管理が前提になります。

強さを左右するのは秘密鍵の保護

証明書認証は、証明書そのものではなく、対応する秘密鍵を正しい利用者が保持していることが前提です。端末内で秘密鍵を保護し、紛失や退職時に失効させる運用までそろって初めて強度が出ます。

パスワードレス（パスキー／FIDO2 など）

パスワード入力を前提にせず、端末のロック解除と公開鍵暗号を使って認証する考え方です。フィッシング耐性が高い方式として注目されており、パスワード管理の負担も減らしやすくなります。

移行計画がないと定着しにくい

パスワードレスは有力ですが、すべてのサービスや利用者が一度に移行できるとは限りません。対応サービス、端末環境、回復手順、例外ユーザーを整理し、段階的に移す設計が必要です。

シングルサインオン（SSO）

シングルサインオンは、一度のログインで複数サービスにアクセスできる仕組みです。利用者の負担を減らしつつ、退職や異動時の無効化をまとめて行いやすくなります。

入口を集約するなら、入口を強くする必要がある

SSOは便利ですが、入口が単一になるため、その入口が弱いと影響も広がります。IdP側のMFA、管理者保護、ログ監査、回復手順の厳格化を一緒に進める必要があります。

認証と認可の違い

認証と似た言葉に認可があります。この2つは役割が異なります。

• 認証：誰であるかを確かめる
• 認可：何をしてよいかを決める

本人確認ができていても、不要な権限まで持っていれば情報漏えいや内部不正は起こります。したがって、認証だけ強くしても十分ではありません。

認可は最小限に保つ必要がある

認可の基本は、業務に必要な範囲だけ権限を与えることです。異動、兼務、例外対応で権限は増えやすいため、定期的な棚卸しと、重要操作に対する承認や監査を組み合わせる必要があります。

見直しで優先したいポイント

1. 重要アカウントからMFAを適用する：管理者、外部公開、重要業務の入口を先に見直す
2. ログイン後のセッション管理を点検する：有効期限、再認証、ログアウト無効化、異常検知を確認する
3. 回復手順を弱点にしない：端末紛失や再発行の本人確認を明確にする
4. SSOや連携認証を使う場合はIdP側を強化する：入口集約の利便性と引き換えに、入口保護の責任が重くなる
5. 認可を棚卸しする：認証強化だけで終わらせず、権限の過不足を見直す

まとめ

認証は、利用者や端末が想定した本人かどうかを確かめる仕組みです。いまはIDとパスワードだけでは不十分な場面が多く、MFA、証明書、パスワードレス、SSOなどを使い分ける必要があります。

ただし、認証方式だけを強くしても、セッション管理、回復手順、認可設計が弱ければ事故は起こります。見直しでは、重要アカウントからMFAを適用し、ログイン後の状態管理と権限設計まで含めて点検することが重要です。

FAQ