認証と認可の違い

アカウント乗っ取り (ATO) やデータ侵害などの執拗なサイバー脅威は、オンラインで事業を展開するすべての企業にとって重大な脅威であり、壊滅的影響をもたらす可能性があります。2023年には、ATO により約130億 USD に上る損失が発生し、米国企業はデータ侵害1件あたり平均948万 USD のコストに直面しました。侵害の16%がフィッシングに起因し、認証情報の不正使用が15%を占め、フィッシングによる侵害1件あたりの平均被害額は472万 USD に上ります。このようにサイバー攻撃や詐欺がますます巧妙化する中、どうすればビジネスを保護できるでしょうか？

認証 (AuthN) と認可 (Authz) を、あらゆる攻撃防止戦略の中心に据える必要があります。認証は認証情報の検証を通じてユーザーの ID を確認し、認可は認証されたユーザーのアクセス権限を決定します。

以下では、認証と認可の主な違いを確認し、これらが連携してユーザーを認証し、システムへのアクセスを管理する方法をご紹介します。

認証とは？

認証 (英語では「AuthN」と略されることがよくあります) は、保護された情報にアクセスする必要があるユーザーの ID を確認するプロセスを意味します。認証の主な機能は、許可されたユーザーだけがシステムにアクセスし、機密データを閲覧できるようにすることです。

一般的な認証方法として以下が挙げられます。

• パスワード

• 指紋や顔認識などの生体認証

• 複数のチェックを組み合わせた多要素認証

このプロセスでは、以下を含む、関係者間の安全な通信を確保するさまざまなプロトコルが使用されます。

• OAuth と OpenID Connect により、ログイン詳細を共有することなく、プライベートリソースにアクセスできる権限をアプリケーションに安全に付与できます。

• SAML により、一度サインインするだけでさまざまな Web プログラムやオンラインサービスへのアクセスが可能になります。

このようなアプローチは以下を含む課題を伴います。

• アカウント間でのパスワードの再利用により盗難のリスクが高まる

• 身体的生体認証が盗まれた場合、変更が複雑になる可能性がある

• 顧客の利便性と保護のバランスを考えてプロトコルを使用する必要がある

• 大量のユーザーをサポートすると技術的なハードルが上がる可能性がある

認可とは？

認可 (英語では「AuthZ」と略されることがよくあります) は、認証されたユーザーがアクセスまたは使用できるアクションまたはリソースを決定します。認可の役割は、さまざまなユーザーに対して適切なポリシーと権限を適用することです。

主な認可モデルとして以下が挙げられます。

• 役割と責任に基づいてユーザーをグループ化するロールベースのアクセス制御 (RBAC)

• ユーザー名や時刻、場所などのさまざまな属性によってアクセスが決定される属性ベースのアクセス制御（ABAC）

以下は一般的な認可メカニズムです。

• 誰がどのリソースにアクセスできるかを指定するアクセス制御リスト (ACL)

• 暗号的に検証された権限がユーザーに与えられる機能ベースのシステム

認可の粒度を細かくすることも粗くすることも可能です。粒度が細かい認可ではアクセスできるリソースの部分を正確にコントロールできますが、粒度の粗い認可ではリソースに対するすべてのアクションを許可するなど、より広範な権限が提供されます。

認証と認可の主な違い

認証と認可はいずれも重要なセキュリティ機能ですが、アクセス制御のさまざまな段階で異なる役割を果たします。これらの違いを理解することで、適切な保護を確実に実装できるようになります。ソフトウェアを開発する場合でも、ユーザーアクセスを管理する場合でも、これらの機能を効果的に使用することで、プライバシーと生産性の両方をサポートすることが可能になります。それぞれの特徴を見てみましょう。

• 目的 : 認証はユーザーの ID を確認し、認可は役割などの要素に基づいてアクセス可能なアクションとリソースを決定します。

• タイミング : 認証はユーザーが誰であるかを確認するために事前に実行され、認可はその特定のセッションでユーザーが実行できる操作をコントロールします。

• ユーザーエクスペリエンス : 認証はユーザーと対話してユーザーを識別しますが、認可は通常、アクセスポリシーに従ってバックグラウンドで実行されます。

• 使用されるデータ : 認証ではパスワードなどの識別情報が使用され、認可では機密性のレベルなど、リソースの属性が考慮されます。

• 失敗のシナリオ : 認証では識別に失敗するとアクセスが拒否されます。一方、認可では一部のリソースへのアクセスのみがブロックされ、他のリソースへのアクセスが許可されます。

• カスタマイズ : 認証は識別方法に依存し、これはユーザーによってコントロールされます。一方、管理者は特定のシステムのユーザーロールや属性に合わせて認可ポリシーをカスタマイズできます。

• プロトコルと標準 : 認証には OAuth などのプロトコルがあり、認可は RBAC といったモデルやアクセス制御リストをはじめとするメカニズムに従います。

認証と認可の連携の仕組み

認証と認可はサイバーセキュリティにおいて重要な協力関係を形成し、それぞれがシステムや情報へのアクセスを保護するために独立しながらも補完的な役割を果たします。したがって、社内で社員のログインを管理する場合、これらのプロセスがどのように連携して機能するかを理解することが、リソースとデータのプライバシーを強力に保護する上で不可欠です。以下は、認証と認可がどのように連携するかを示しています。 

• ユーザーによる開始 : ユーザーが保護されたリソースにアクセスする必要がある際に認証プロセスが開始されます。

• 認証リクエスト : ユーザーの ID を確認するため、詳細が認証サーバーに送信されます。

• 認証情報の送信 : 自分の ID を証明するためにユーザーネームやパスワードがユーザーによって送信されます。

• ID の検証 : 認証サーバーは、提出された認証情報が、保存されている識別情報と一致することを確認します。

• セッションの作成 : 検証が成功すると、設定された期間内に個人が認可された機能を使用できるセッションが作成されます。

• 認可の確認 : 同時に、認可サーバーはアクセスポリシーを検証し、役割や場所などの ID にリンクされた属性に基づき、ユーザーが利用できるアクションまたはリソースを決定します。

• ポリシーの適用 : 認可のレスポンスによってアクセスルールが適用され、それに応じて特定の要求がブロックまたは許可されます。

• リソースへのアクセス : リクエストが認可されてリソースへのアクセスが可能になり、認可されていないリソースへのアクセスはすべて拒否されます。

• 継続的な検証 : ユーザーセッションが継続している間、定期的なチェックによって認証が有効であることが確認されます。

• セッション終了 : 設定された期間が過ぎるとセッションが終了し、その記録はサーバーメモリから削除されます。

認証と認可における一般的な課題

認証と認可にはそれぞれ固有の課題があり、単一のソリューションですべてを解決することはできません。これらのハードルを認識することで、より先進的なテクノロジーの利用やプロセスの改善、ユーザーの教育を通じて弱い領域の強化に集中できるようになります。プロアクティブで多面的なアプローチの採用により、時間と共にセキュリティ体制を強化できます。

以下は、直面する可能性がある一般的な制約の一部です。

• 複数のシステムにわたるユーザー ID の管理 : ユーザーがさまざまなアプリケーションやシステムにアクセスするのに伴い、一貫した認証詳細を維持することがますます困難になります。

• セキュリティとユーザー利便性のバランス : 厳格なセキュリティプロトコルにより摩擦が増え、ユーザーに負担がかかる可能性がある一方、アクセス制御が緩いと脆弱性が増大します。適切なバランスの達成は慎重を要する重要な作業です。

• マイクロサービスアーキテクチャでの認可の処理 : アプリケーションが独立したコンポーネントに分割されている場合、それらの間で認可ポリシーを調整するのが複雑になります。

• モノのインターネット (IoT) デバイスの保護 : センサー、家電製品、その他のスマートテクノロジーの普及により、攻撃対象領域が拡大します。進化する脅威に対して認証および認可プロセスのレジリエンスを維持するには、多大なリソースと投資が必要です。

• データ保護規制への準拠の確保 : GDPR などの規則ではプライバシーの保護と同意の取得を強制する厳格なアプローチが取られているため、認証システムはこれらの要件を確実に満たす必要があり、一貫した協調的な取り組みが求められます。

Fastly で認証と認可を強化

Fastly のグローバルエッジクラウドプラットフォームにより、エッジコンピューティングを活用して認証プロセスと認可プロセス両方の特定の課題に取り組み、レイテンシを削減しつつセキュリティを強化できます。このアプローチにより、厳格なアクセス制御を維持しながら、高速かつ信頼性の高いユーザーエクスペリエンスが保証されます。

Fastly では以下を通じてセキュリティ戦略を強化できます。 

• エッジ認証 : Fastly は、ユーザーに近いグローバルネットワークのエッジで認証リクエストを処理するため、自社サーバーに過負荷をかけることなく、より高速な ID 検証が可能になります。

• 柔軟な認可ポリシー : Fastly ではエッジでアクセス制御をカスタマイズして実行できるため、セントラルサーバーと通信することなく、ポリシー主導の認可決定をリアルタイムで行えます。

• トークンベースの認証 : Fastly のソリューションは OAuth 2.0 や OpenID Connect などの一般的な標準をスムーズにサポートし、ユーザーとアプリケーション・プログラミング・インターフェイス (API) の安全なトークン交換を実現します。

• API セキュリティ : Fastly のエッジサービスは認証情報を確認し、API リクエストの認可を検証して無効なリクエストがバックエンドに到達する前にブロックします。このアプローチにより、サービスとデータが最初から保護されます。

• リアルタイムのポリシー更新 : 認可の変更を Fastly ネットワーク全体に即座にプッシュできます。変更は場所に関係なく、すべてのユーザーに対してすぐに有効になります。

• ログと分析 : Fastly のログ機能と分析ツールは、認証や認可のアクティビティに関する貴重なインサイトを提供し、パターンの監視、異常の検出、経時的なプロセスの最適化に役立ちます。

• ID プロバイダーとの容易な統合 : Fastly プラットフォームは既存の ID ソリューションに迅速に接続し、使用しているシステムを置き換えることなく、スケーラブルで安全な認証フレームワークを構築できます。

早速、無料デモをリクエストし、Fastly を利用して認証と認可の機能を強化する方法をご覧ください。