Article
今さら聞けない認証と認可の違い ゼロトラストセキュリティ対策
サイバーセキュリティにおいて、「認証」と「認可」は重要な要素です。「認証」と「認可」は似たような言葉で混同されて同じ意味のように使われることがありますが、明確に概念が異なります。
日本では、「認証」を意識し、対策を始めた企業は多いです。しかし、同時に「認可」を検討しないとセキュリティ対策としては不十分です。
では、「認証」と「認可」の違いは何でしょうか。また、「認可」機能を利用しないとどのようなリスクがあるのでしょうか。
本記事では「認証」と「認可」の違いと、「認可」機能を利用しないとどのようなセキュリティリスクがあるかについて解説します。
「認証」と「認可」の違いとは？
認証とは、アプリケーションが利用者本人であるかを検証するプロセスを意味するのに対し、認可とは、認証後にITリソースへのアクセスを権限に応じて許可するプロセスのことを意味します。
身近な例で例えると、航空会社が搭乗を許可すべき人物を特定するために、搭乗者が名乗った通りの人物なのか身元を確認します。これが認証です。搭乗者の本人確認ができたら、ビジネスクラスやVIPラウンジなど、利用できる特別なサービスがないかを確認します。これが認可です。
デジタルの世界では、ログイン時におけるユーザーIDとパスワードの確認が「認証」を、アクセス可能なシステムや権限管理が「認可」を意味します。
「認証」と「認可」は混同され同じような意味だと思われがちですが、明確に概念が異なります。セキュリティ対策においても使い分けながら行う必要があります。どちらか一方を強化するだけではセキュリティ対策にはならず、「認証」と「認可」は合わせて検討し、強化する必要があります。
「認証」とは？
認証は、本人確認のプロセスのことです。
例えば、銀行で新規口座を開設するときに、運転免許証などで本人確認を行います。この本人確認が「認証」に該当します。
アプリケーションにおける認証には、ログイン時にユーザーIDとパスワードで利用者本人かを確認する機能が該当します。
認証の3つの要素
認証には3つの要素があります。
1. 知識要素
1つ目は「知識要素」です。知識要素とは「その人の頭の中にある情報」です。具体的には「パスワード」「PINコード」「秘密の質問」などが該当します。一度だけの利用を許可する「ワンタイムパスワード」の場合もあります。
2. 所持要素
2つ目は「所持要素」です。所有要素とは「その人のみが所有しているもの」です。具体的には「モバイル端末のSMS認証」「ワンタイムパスワードの生成端末」「デジタルIDカード」「セキュリティトークン」等が挙げられます。
3. 生体要素
3つ目は「生体要素」です。生体要素とは「その人固有の身体的特徴」です。具体的には「顔認証」「指紋認証」等の要素です。
従来、認証のプロセスにおいては単一の知識要素としてのパスワードが用いられてきました。しかしながら、セキュリティリスクの高まりを踏まえて、多くの場合、認証プロセスを強化する目的でこれらの情報は組み合わせて使用されます。
例えば、ユーザーがオンライン購入をする際、ユーザー名とパスワードが求められます。それらの情報が確認されると、第2のセキュリティ層としてワンタイムパスワードがユーザーの携帯電話に送信されます。
一貫した認証プロトコルに従って複数の認証方法を組み合わせることで、組織はセキュリティ強化とシステム間の互換性を確保できます。
「認可」とは？
認可とは、ユーザーに付与された権限の範囲で特定のアプリケーション、ファイル、データにアクセスを許可し、利用させるプロセスのことです。
例えば、お酒やタバコは20歳以上でなければ購入できません。コンビニをはじめとした店舗では、購入者が20歳以上かどうかを確認し、20歳以上と確認できた人のみが購入できます。
アプリケーションにおける認可には、端末や場所などに制限をかけて管理者が許可したリソースに限定し、サービスを利用できる機能が該当します。
具体的な使用例としては以下の通りです。
・会社で支給された端末のみでサービスを利用できる（私用の端末ではアクセスできない）・特定の部署のユーザーのみがアプリケーションやフォルダにアクセスできる（それ以外の部署のユーザーはアクセスできない）・課金したユーザーのみがコンテンツを参照できる（無料ユーザーはコンテンツを参照できない）
認可で可能となること
では、ITリソースにおける認可の機能にはどのようなものがあるのでしょうか？ここでは認可で可能となることを3つ紹介します。
1. アクセス可能な端末の限定
1つ目は「アクセス可能な端末の限定」です。
テレワークが普及し、自宅で作業を行うというケースが増えました。業務においてクラウドサービスを利用する機会は増え、所定のURLでサイトにアクセスし、ログインIDとパスワードを入力すれば、私用の端末からでも業務で利用しているサービスにログイン可能です。
とはいえ、会社支給の端末と異なり、私用の端末の場合は社内基準を満たしたセキュリティ対策が施されていないことがほとんどです。このため、ウイルスや不正アクセスをはじめとしたセキュリティリスクが高いのが現状です。
「認可」機能を利用することでアクセス可能な端末を限定できます。サービスにアクセスできる端末は会社支給のものに限り、私用の端末によるログインを許可しないという制御をかけます。このような対応を行うことで、情報漏洩や不正アクセスなどのセキュリティリスクを低減できます。
2. アクセス可能な場所の限定
2つ目は「アクセス可能な場所の限定」です。
「認可」機能でアクセス可能な場所を制限した場合、許可した場所以外はサービスにアクセスできないようにすることができます。具体的には許可したIPアドレス以外はサービスへのアクセスを許可しません。
「認可」機能を利用することでIPアドレスの制御で所定のIPアドレス以外のアクセスを防ぐなど、不正アクセスを防ぐことができます。
3. 必要な権限の付与
3つ目は「必要な権限の付与」です。
「認可」機能を利用することでユーザーごとに必要な権限を付与することができます。
アクセス可能な範囲をユーザーの属性によって区別し、「メニュー表示で管理者には表示されるが一般ユーザーには表示されない」、「該当部署のユーザーはアクセスできるが、それ以外のユーザーはアクセスできない」など設定することが可能です。
認可手法は、一般的に以下の2種類が挙げられます。
ロールベースアクセス制御（RBAC）
RBACは、組織内でユーザーに割り当てられたロールに基づき、情報へのアクセス権を付与します。
例えば、給与、休暇日数、および確定拠出型年金に関するデータなどの個人情報は、社内の全従業員が各自の情報を確認できるようにしながら、変更は許可しないようにする場合があります。一方で、人事管理者に対しては、全従業員の人事情報についてデータを追加、削除、変更することができるアクセス権を付与することも考えられます。
各個人のロールに従って権限を割り当てることで、組織はユーザーの生産性を維持しながら機密性の高い情報へのアクセスを制限できます。
属性ベースアクセス制御（ABAC）
ABACは、一連の指定属性を使用することでRBACよりも詳細なレベルで権限をユーザーに付与します。これにはユーザーの名前、ロール、所属部門、ID、セキュリティクリアランスなどのユーザー属性が含まれます。また、アクセス時間やデータの場所、組織が現在置かれている脅威レベルなどの環境属性を含むこともあるほか、リソースの所有者、ファイル名、データの機密性といったリソース属性を含む場合もあります。ABACはRBACよりも複雑な認可プロセスであり、アクセス権の制限をより強化できるよう設計されています。
例えば、従業員の人事データに関する変更を組織に所属するすべての人事管理者に許可するのではなく、アクセス権を特定の地理的ロケーションや時間帯に制限することで、厳格なセキュリティ制限を維持できます。
「認可」機能を利用しないセキュリティリスク
では、「認可」機能を利用しないことのデメリットには何があるのでしょうか？ここでは「認可」機能を利用しないリスクを3つ紹介します。
不正アクセスによる情報漏洩のリスク
1つ目は不正アクセスによる情報漏洩のリスクです。
「認可」機能でアクセス可能な場所や範囲を制御しない場合、不正アクセスが発生する可能性が高まり、どこからでもアクセスできる状態となります。
例えば、「認可」機能で利用できる端末の制御をかけておらず、私用の端末が情報を吸い上げるウイルスに感染しており、その端末でサービスにログインしたとします。そのウイルスが起動し、機密情報にアクセスした場合、情報漏洩につながります。「認可」機能を利用しない場合、機密情報漏洩のリスクにさらされることになります。
なりすましのリスク
2つ目はなりすましのリスクです。
ユーザーIDやパスワードをURLに埋めて制御するWebサービスがあるとします。この場合、一度ログインできてしまえば別のユーザーIDとパスワードをURLに埋め込んでサービスにアクセスすれば、他人へのなりすましができます。
過剰な権限付与のリスク
3つ目はユーザーに対する過剰な権限付与のリスクです。
本来、社員が情報への閲覧権限しか持つべきでないケースにおいて、変更権限まで所持していたとします。本人は閲覧権限しか所持していないつもりでも、実際には変更できてしまうため、操作ミスなどにより思わぬ事故のリスクが生じます。
また、社員が異動や退職したにも関わらず以前の権限を維持した状態が続くと、悪意を持った社員や元社員が企業の機密情報を外部に持ち出すリスクが高まります。特に異動の場合には、異動前の業務に必要な権限を所持し続けると、コンプライアンス上のリスクの生じるケースもあります。
例えば、1人のユーザーが取引業者の登録権限と、代金等の支払い権限の両方を持つ場合、金銭詐取のリスクが生じます。
認可を司るアイデンティティ・ガバナンス/管理とは
「認可」は通常、アプリケーションごとに備わっている機能です。それぞれのアプリケーションで個別に管理することは可能ですが、アプリケーションの数が多いと、業務として非常に煩雑です。また、不正取得されたIDを用いたアクセスは、システム上、正常なログインと区別がつきません。すべてのアプリケーションのID管理を効率的かつ集約的に行い、不要な権限を排除し、認可のための情報を適切に管理することが重要です。そこで必要になるのが、企業全体で整合性のとれたIDとシステム利用権限を統制する、アイデンティティ・ガバナンス/管理(IGA)という仕組みです。
アイデンティティ・ガバナンス/管理を導入することで、社員の異動や昇進、退職などの属性変更に伴うすべてのアプリケーションでのアクセス権限の変更作業を自動化し、適切な人に適切な権限付与を行うとともに、過剰な権限が付与された状態を抑制します。
これにより、企業は業務効率化を実現しながらセキュリティリスクを低減し、コンプライアンスの向上が図れます。
まとめ
この記事では「認証」と「認可」の違いと「認可」機能を利用しないセキュリティリスクについて解説しました。
「認証」と「認可」の概念は明確に異なります。サイバーセキュリティ対策においては「認証」と「認可」の両方を利用してセキュリティを強化する必要があります。
「認証」を導入し満足して終わるのでなく、「認可」を活用して適切なセキュリティ対策を行いましょう。「認証」と「認可」は機密性の高いデータが悪意のある人の手に渡らないようにする第一の防衛線となります。両者はあらゆる企業のセキュリティ戦略全体で重視されるべき要素です。
企業は「認証」と「認可」により本人確認と権限を一貫性をもって確認できるようになり、重大な脅威をもたらす不正行為を防止できます。すべてのユーザーを正しく識別して必要なリソースにのみアクセス権を持たせるよう徹底することで、情報侵害によって企業の収益と評判が失われることなく、生産性を最大化しながらセキュリティを強化できます。
よくある質問
関連コンテンツ
SailPointについての問い合わせ
*必須フィールド