AuthNとAuthZの違いは?

AuthNはauthentication(認証)、AuthZはauthorization(認可)の略です。この2つは別物ですが、IDおよびアクセス管理(IAM)の世界では密接に絡み合っている概念です。

学習目的

この記事を読み終えると、以下のことができるようになります。

  • AuthNとAuthZの対比
  • 一般的なAuthNの方法について説明する
  • いくつかのAuthZアプローチについて説明する

記事のリンクをコピーする

認可(AuthZ)と認証(AuthN)の対比

情報セキュリティにおいて、認証(AuthNと略す)と認可(AuthZ)は、関連はあるが概念は異なります。どちらも、IDおよびアクセス管理(IAM) の重要な要素です。

AuthNとAuthZの違いは?簡単に言うと、AuthNは本人確認、つまりある人が誰であるかに関係し、一方AuthZは権限、つまり誰かが何をすることを許可されているかに関係します。

認証(AuthN)とは?

認証とは、個人やデバイスが本人(または本物)であることを確認することです。イベントのチケットの受け取りの際、身分証明書の提示を求められる場合があります。同様に、アプリケーションやデータベースは、ユーザーのIDを確認することで、そのユーザーが正当であることを確認する場合があります。認証は、データが間違った人物に公開されないようにするためのものです。

一般的なAuthNの手法とは?

ユーザー名とパスワードの組み合わせ

認証の最も一般的な方法の1つは、ユーザーにユーザー名とパスワードの入力を求めることです。ジェシカがブラウザでメールアカウントを読み込むとき、メールサービスはまだ彼女が誰であるかを認識していません。しかし、彼女がユーザー名とパスワードをログインフォームに入力すると、サービスはそれらの資格情報を確認し、彼女をジェシカとして認証し、彼女はアカウントにログインすることができます。

多くの人はこのタイプの認証に慣れ親しんでいますが、ユーザー名とパスワードはユーザー認証以外にも使用することができます。例えば、APIのエンドポイントをこの方法で認証することができます。

多要素認証(MFA)

ユーザー名 - パスワードの認証の問題点は、パスワードが悪意のある人物に推測されたり、盗まれたりすることがよくあることです。認証の追加要素を要求することで、ユーザーのセキュリティを向上させることができます。このコンセプトは、多要素認証(MFA)と呼ばれています。MFAを使用する場合、攻撃者が正規のユーザーとして不正に認証するために必要なのは、パスワードだけではなくなります。

MFAは、二要素認証 (2FA)として最も多く実装されています。現在、多くのサービスは、発行されたトークンを持っていることを証明するようユーザーに求めることで、2FAを実装しています。トークンには、SMSやモバイルアプリでユーザーに送られるコードのような「ソフト」トークンと、USBキーのような「ハード」トークンの2種類があります。2FAとMFAでは、バイオメトリクス認証要素(後述)を使用することもできます。

公開鍵証明書

公開鍵認証は、これらの他の認証形式よりも若干複雑ですが、適切に実装すれば、より安全な認証が可能です。公開鍵暗号化を使用して、認証される側が正しい秘密鍵を持っているかどうかを確認します。

(公開鍵と秘密鍵の仕組みについては、公開鍵暗号化の仕組みとは?をご覧ください)。

公開鍵認証の最も一般的な使用法は、Transport Layer Security(TLS)で、Webサーバーを認証するために使用されます。ユーザーデバイスは、HTTPSを使用するWebサイトを読み込むたびに、このタイプの認証を実行します。

公開鍵認証は、相互認証にも使用されます。これは、クライアントがサーバーを認証したり、Webサービスがユーザーを認証したりするだけでなく、通信の両側がお互いを認証する際に使用されます。 Internet of Things(IoT)デバイスとAPIエンドポイントで、このタイプの認証が使用される場合があります。

生体認証

人間の認証にのみ使用可能なバイオメトリクス認証は、身体的特徴の一つとそれらが登録されたデータベースと照合することによって、個人の本人確認を行うものです。顔や網膜のスキャンは、このタイプの認証の一例です。

認可(AuthZ)とは?

認可は、認証されたユーザーが閲覧したり実行できる内容を決定するものです。銀行のお客様がオンラインで自分の口座にログインしたときのことを考えてみましょう。本人確認による認証が済んでいるため、自分の口座の残高や取引履歴を見ることはできますが、他者の情報の閲覧は認可されていません。逆に、銀行のマネージャーは、あらゆる顧客の財務データの閲覧が可能である可能性があります。

同様に、個人がある企業の正規の従業員であり、本人確認も済んでいる場合でも、その企業のすべてのファイルやデータにアクセスできるようにすべきとは言えません。例えば、人事部や経理部以外の従業員は、全員の報酬を閲覧することができないようにする必要があります。

ユーザーの権限レベルは、そのユーザーが何をする権限を持っているかを決定します。このように、許可されたアクションを示す一般的な用語は「権限」であり、この概念を表す別の用語は、「特権」です。

AuthZの仕組みは?

組織では、ユーザーの行動を許可またはブロックするために、ある種の認可ソリューションを採用しています。このソリューションは通常、ユーザーが誰であるかに基づいて、どのアクションを許可またはブロックするかを認識します。このため、認証は認可と密接に関連しています。ユーザーの権限を決定する方法には、以下のようないくつかの異なる方法があります:

ロールベースアクセス制御(RBACでは、すべてのユーザーに1つ以上の事前定義されたロールが割り当てられ、各ロールには特定の権限セットが与えられます。

属性ベースアクセス制御(ABAC)では、ユーザーは自分の属性または実行しようとしているアクションの属性に基づいて権限が割り当てられます。

ルールベースのアクセス制御(RBACとも略される)では、役割に関係なくすべてのユーザーに適用される一連のルールに基づいて、アクションが許可または拒否されます。

OAuthとは?

OAuthは、あるサービスから別のサービスへ認可を渡すための技術標準です。多くの場合、クラウドサービスやWebアプリケーションで使用されます。OAuthを使用すると、ユーザーはあるサービスで受けた認証を、別のサービスに渡すことができます。ユーザーの認証レベルは、通常、別のサービスであるIDプロバイダー(IdP)によって決定されます。

OAuthを使用することで、シングルサインオン(SSO)サービスを実現することができます。これにより、ユーザーは一度サインインすれば、すべてのクラウドアプリケーションにアクセスすることができます。OAuthを使用しない場合、ユーザーのアクセス許可は各アプリケーションで個別に設定する必要があります。

Cloudflareは、企業がAuthNとAuthZを実装するのにどのように役立つか?

Cloudflare Access は、オンプレミス、セルフホスティング、SaaSアプリケーションで行われるユーザーの操作を許可またはブロックする認可(AuthZ)ソリューションです。認証(AuthN)を行うあらゆるIdPと連携します。また、Cloudflare Accessはアクセスを許可する前にデバイスのセキュリティポスチャを評価します。これはZero Trustモデル(Zero Trustについての詳細はこちら )を実装する上で重要な機能です。