認証と認可、その実現手段について整理してみる

こんにちは、shibamです。

認証(Authentication)と認可(Authorization)、セキュリティに関して勉強していると頻出の単語ですが、混同しやすい概念でもあります。
今回はその２つの用語の再整理と、併せて認証・認可における代表的な手法の手順について解説していきます。

目次

1. 1. TL;DR
   2. 認証・認可とは
   3. 認証・認可は混同してはいけない？
   4. 認証・認可のプロトコル
   5. 認証の３要素と多要素認証について
   6. 認可のための権限管理
   7. 最後に

1.TL;DR

• 「認証(Authentication)」は、「手続きを行った人が本人かどうか検証する」こと。「認可(Authorization)」は、「手続きを行った人が、その手続きをして問題ないか検証する」こと。
• 認証は本人の実在性、同一性の検証、認可は行動の正当性の検証なので混同してはいけない。
• 認可のプロトコルとしてはOAuthが一般的。認証のプロトコルとしては、昨今ではOIDCが主流で、企業だとSAMLを扱う場合も多い。
• 認証要素としては、「知識(ID/PWなど)」、「所有(ワンタイムトークンなど)」、「生体(指紋など)」がある。これらのうち複数個の要素を組み合わせることが多要素認証。
• 適切な認可を行うためには適切な権限管理(Access Control)が必要。RBAC/ABACなどの権限管理手法を活用する。

2.認証・認可とは

認証とは

認証とは、「手続きを行った人が本人かどうかを検証すること」です。
現実世界における認証の例をいくつか挙げれば、

1. 電車に乗るために切符を購入し、自動改札機から駅構内に入場する → 切符の「所持」による認証
2. 暗証番号付きのロッカーを開ける → 「知識」による認証
3. 自分のスマホに顔認証でロック解除する → 「生体」による認証

などがあります。
ITの世界における認証も上記とほとんど同様であり、自身のサービスに対してログインしようとしている人物が、サービスに対して登録を行った人物と同一であるかどうかを検証しています。

認可とは

認可とは、「手続きを行った人が、その手続きを行う権限があるかどうか検証すること」です。
現実世界における認可の例をいくつか挙げれば、

1. 購入した切符を自動改札機に通し、退場する → 切符の金額から退場の可否を判断する
2. クレジットカードの発行を行う → 発行申請を行った人の属性情報(勤務先情報、財政情報、などなど…)をもとに発行の可否を判断する

などがあります。
ITの世界における認可も上記と同様に、主にログインした人物の持つ権限情報をもとに手続きの可否を判断します。

3.認証・認可は混同してはいけない？

上記の例で挙げたように、認証によって保証されるのはあくまで本人であることであり、手続きを行ってよい人物であることを保証しません。
クレジットカードの発行を行う際に、「申請者が本人であることの検証」（認証）は必須ですが、当然それだけで発行することはできず、「発行してよい人物かどうかの検証」（認可）も必須です。
認証はあくまで「本人の実在性・同一性の検証」であり、認可は「行動の正当性の検証」です。それぞれの役割を理解することが重要です。
現実世界とITでの認証・認可の役割の大きな違いは、「申し込んだ人物の実在性や属性情報を、申し込みを受けた側の主観で、ある程度担保できるか否か」にあり、このため現実世界では認証・認可をそこまで区別しないこともあります。
ITの世界では、なりすましが容易に実行可能であることから、それらの情報を担保することができないため、認証と認可はそれぞれ個別に実施する必要があります。

4.認証・認可のプロトコル

ITの世界において認証・認可を実現するためには、以下のプロトコル等を利用し認証・認可の機能を実現する必要があります。
（※代表的なもののみ記載しています）

認証

• • • OIDC(OpenID Connect)
      …近年では最も主流な認証プロトコルで、後述するOAuth2.0から拡張実装されたプロトコルとなります。
      Service Provider(サービスの提供者)はIdentity Provider(IDトークンの発行者)からユーザーの承認を得てIDトークンを受け取り、IDトークンをもとに認証を行います。
      IdPの役割は、本人であることを証明する第三者からの署名の提供、と考えるとわかりやすいかもしれません。
      現実においても、本人であることの証明のためには「公的機関が作成した身分証の提示」が求められます。
      これをITの世界で実現したものがIdPを介したIDトークンの発行となります。
      IDトークンはJWT(JSON Web Token)と呼ばれる形式でやりとりされ、第三者であるIdPが本人であることを、このトークンを発行することで保証し、ユーザは発行されたトークンを介して様々なサービスに認証を行うことができるようになります。これをSSO(シングルサインオン)と言います。
      （当然、サービス側がそのトークンを認証するための設定は必要ですが。）
      Google,XなどのSNSによるソーシャルログインが実現できるのは、OIDCプロトコルを通して各社がIDトークンをサービスに提供しているからですね。
      （技術的には「認証連携（Federation）」と呼ばれます。）
    • SAML(Security Assertion Markup Language)
      …OIDCがJWTを利用する一方で、SAMLはXMLを利用します。
      OIDCがtoCのサービス向けに比較的活用される一方で、安定性や秘匿性が求められる企業や政府機関において特に採用される認証プロトコルになります。
      基本的な認証の流れはOIDCと同一です。ただし、SAMLの場合のIdPは社内の（物理的、あるいは論理的な）環境上に置かれています。
      具体的にはAzure ADやOktaなどがSAML認証のIdPの役割を果たし、これらを介してサービスへのシングルサインオンを実現します。
      一方で、ソーシャルログインなどの実現はできないため、最近では多くの場合OIDCを採用することがほとんどです。
    • BASIC認証
      …webページ上にID/PWの認証ページを埋め込み、Base64などでやり取りするだけの認証をBASIC認証と言います。
      HTTPSであれば通信自体が暗号化されるため大きなリスクとはなりませんが、HTTPの場合は推奨できません。
      またHTTPS通信であったとしても、あくまでテスト用の環境で実装するものであり、BASIC認証を公開された環境で利用することは控えるべきです。

認可

• • • OAuth2.0(Open Authorization2.0)
      認可に関しては、OAuth2.0を用いることが一般的です。
      アクセスしたいリソースを管理しているリソースオーナー（ユーザー）とリソースサーバー、クライアント、認可サーバーから構成されており、以下のような手順でリソースサーバーにあるリソースへアクセスします。
      1. リソースオーナーはクライアントを通して認可サーバーへ認可を要求します。
         これにより、認可サーバーはリソースオーナーに対して認可を行ってよいか確認します。
      2. リソースオーナーが許可した場合、認可サーバーは認可コードを発行し、クライアントに渡します。
      3. クライアントは認可コードを再度認可サーバーに渡すことで、認可サーバーからアクセストークンを受け取ります。
      4. クライアントは受け取ったアクセストークンをリソースサーバーへ渡し、リソースへのアクセスを行います。

5.認証の３要素と多要素認証について

「所持」「知識」「生体」
を認証の３要素と呼んでおり、このうちから２つ以上の要素の認証を組み合わせることをMFA(MultiFactorAuthentication,多要素認証)と呼んでいます。
例えば通常のID/PWでのログイン後、携帯のSMSにワンタイムパスワードが送付され、それを入力することでログインが成立する場合、「知識」と「所持」による二要素認証を行っています。
ここで気を付けたいのは、多「段階」認証と多「要素」認証の区別です。
多段階認証は、あくまで複数の認証フェーズが発生する認証を指しているため、例えばID/PW(知識)と秘密の質問(知識)のような認証は二段階認証となります。
多要素認証は、複数の認証要素を組み合わせる認証を指しており、上記のような例は二段階認証であっても二要素認証とはなりません。
二段階認証の方が指し示す範囲が広く、二要素認証を内包している、という形になります。

6.認可のための権限管理

認可を行うためには、「認可を行える状態」を作ることが大切です。
認可が行える状態とは、「各ユーザーに対する権限が、適切に付与・管理されていること」を指します。
権限が適切に管理されていない場合、認可における例外が多く発生し、結果として認可があってないようなものになってしまいます。
権限の管理においては、以下のような手法を取るケースが多いです。

1. ロールベースアクセスコントロール…RBAC
   各ユーザに「ロール」（役割）を付与し、ロールに対して権限を付与することでユーザのアクセス管理を行う手法です。
   ・「管理者」と「一般」
   ・「社長」と「課長」と「平社員」
   など、対象の組織図に紐付けた管理を行えることが特徴ですね。
   AWS IAMなどはRBACの代表例であり、ユーザごとに付与したIAMロールによってAWSへのアクセスを管理していきます。
   「役割」と「権限」が関連するため、企業において役職ごとの権限範囲が明確な場合などに扱われやすいですが、反面細かな調節を不得手としています。
   特に日本のような「役割に対する仕事の内容が曖昧」な文化においては、一時的なロールを作成する機会が多くなり、結果として管理が複雑になる可能性を含んでいます。
2. 属性ベースアクセスコントロール…ABAC
   事前にユーザに対して属性を付与し、その属性情報に基づいてそれぞれのリソースへのアクセスを管理する手法です。
   例えば、
   ・アクセスしたユーザの「年齢」「性別」
   ・ユーザがアクセスするときの「デバイス情報」
   など、個人のリアルタイムな情報をもとに判断することがABACの主目的になります。
   「ゼロトラスト」の実現のためには、ユーザの持つリアルタイムな属性情報をもとに権限を管理する必要があるため、ABACが必要不可欠となります。
   （ゼロトラストの話は以前書いた記事をご参照ください。）
   柔軟な権限管理が行える一方で、RBACと比べると運用面での負担が大きく、属性情報を適切に管理していく必要があります。
3. ポリシーベースアクセスコントロール…PBAC
   それぞれのリソースに対してアクセスポリシーを定めることで、より柔軟なアクセスコントロールを行う手法です。
   RBAC,ABACよりも更に柔軟な権限管理を行えるようになりますが、リソース単位での管理が要求されることから、管理もより複雑になりがちです。
   現状でPBACを実現しているマネージドサービスとしてはAWS Verified Permissionsが代表的でしょうか。
   AWSが独自に設計・開発した言語となる”Cedar”を利用してポリシーを作成し、管理を行います。

7.最後に

認証と認可、AuthenticationとAuthorization、混同しやすい表現ですが間違えないように整理をしていきましょう。
また、認証・認可におけるそれぞれの手法まで押えておくと、最近何かと話題になりやすいセキュリティの話題にもついていけるようになると思います。
特にOIDC,OAuth,権限管理手法などは押えておくとよいでしょう。