認証と認可の違いとは?セキュリティの基本「誰か」と「何ができるか」を整理する

IT用語

システムやWebサービスを安全に運用する上で、避けて通れないのが「認証(Authentication)」と「認可(Authorization)」という2つの概念です。これらは英語でも日本語でも言葉が似ているため、IT現場や資格試験(基本情報技術者試験など)でも非常に混同されやすい項目です。

しかし、以前解説したデジタル証明書による「身元の証明」や、電子署名による「本人の意思」を実務に落とし込む際、この2つの違いを正しく理解していないと、重大な権限設定ミスや情報漏洩を招く恐れがあります。

今回は、これら2つの役割の違いを、具体的なビジネスシーンや身近な例を交えて体系的に解説します。

認証(Authentication)とは:「あなたは誰か」の確認

認証は、システムにアクセスしようとしているユーザーが「自称している本人であること」を客観的に確認するプロセスです。

認証の役割

認証の最大の目的は、「なりすまし」を防ぐことにあります。アクセスしてきた人が、あらかじめ登録されているユーザーリストの「誰」に該当するのかを特定する、いわば「身分証明」の段階です。

認証の三要素

認証の信頼性を高めるために、以下の3つの要素を組み合わせる「多要素認証(MFA)」が現代のスタンダードとなっています。

  • 知識要素(Something you know): 本人だけが「知っている」こと(パスワード、PINコード、秘密の質問など)。
  • 所持要素(Something you have): 本人だけが「持っている」もの(スマートフォンへのSMS通知、ハードウェアトークン、デジタル証明書を格納したICカードなど)。
  • 生体要素(Something you are): 本人「自身」であること(指紋、顔、虹彩、声紋など)。

これらを複数組み合わせることで、たとえパスワードが流出しても、第3者による不正ログインを防ぐことが可能になります。

認可(Authorization)とは:「何ができるか」の決定

認可は、認証されたユーザーに対して「特定のリソースへのアクセスや、操作の実行を許可する」プロセスです。

認可の役割

「誰であるか」が判明した後に、そのユーザーに与えられている「権限(権限セット)」をチェックします。認証が成功したからといって、システム内のすべてのデータを見たり操作したりできるわけではありません。

実務における認可の例

  • 役職による制限: 一般社員は自分の勤怠データのみ閲覧できるが、課長職は課員全員のデータを閲覧・承認できる。
  • 会員ランクによる制限: 無料会員はニュース記事のリード文のみ読めるが、有料会員は全文の閲覧と動画の視聴ができる。
  • ファイル操作の制限: 特定のフォルダに対して、Aさんは「読み取りのみ」、Bさんは「編集・削除も可能」といった権限を割り当てる。

認証が「建物の入り口を通すこと」であれば、認可は「入館した後の各部屋への入室許可」を制御することに相当します。

ホテルのチェックインに例えた「認証」と「認可」

この2つの概念の違いは、ホテルの宿泊プロセスに例えると非常に明確になります。

  1. 認証(フロントでの手続き): ホテルのフロントで予約名を告げ、身分証明書を提示して、間違いなく「予約者本人」であることを確認します。これが認証です。確認が取れると、フロントから「ルームキー」が渡されます。
  2. 認可(ルームキーの使用): 渡されたルームキーをドアにかざすと、自分の部屋には入れますが、他の宿泊客の部屋や従業員専用エリアには入れません。ルームキーに設定された「権限」によって、立ち入り可能な場所が制限されています。これが認可です。

もし認証だけで認可がなければ、一度ホテルに入った人はすべての部屋に自由に出入りできてしまうことになり、プライバシーもセキュリティも崩壊してしまいます。

セキュリティ設計上の重要ポイント

システムの脆弱性を語る上で、「認証の突破」と同じくらい深刻なのが「認可の不備」です。

壊れたアクセス制御(Broken Access Control)

例えば、WebサイトのURLが example.com/user/view?id=123 となっているとき、ログイン後に数字を書き換えて id=124 にアクセスしただけで他人の情報が見えてしまうケースがあります。 これは、ログイン(認証)は正常に行われていますが、リクエストされたデータに対して「そのユーザーに閲覧権限があるか(認可)」のチェックをプログラム側で怠っているために発生する致命的な脆弱性です。

第32回で解説したメール認証(SPF/DKIM/DMARC)が、送信元の身元を証明する(=認証に近い役割)のに対し、システム内部では「認証されたユーザーが、許された範囲内でのみ行動しているか」を常に監視する認可の仕組みが不可欠です。

まとめ

認証と認可は、セキュリティを支える両輪です。

  • 認証(Authentication)は、ログインによって「本人」を特定するプロセス。
  • 認可(Authorization)は、アクセス制御によって「実行可能な範囲」を限定するプロセス。

この切り分けを正確に理解しておくことは、今後解説するソーシャルログイン(OAuth 2.0 / OpenID Connect)の仕組みを学ぶ上で非常に重要な土台となります。なぜなら、OAuth 2.0は「認可」のためのプロトコルであり、OpenID Connectはそこに「認証」の機能を加えたものだからです。

コメント