アカウント乗っ取り（ATO）やデータ侵害などの執拗なサイバー脅威は、オンラインで事業を展開するすべての企業にとって重大な脅威であり、その影響は壊滅的なものになりかねません。2023年には、ATO により約 $ 13 billion の損失が発生し、米国企業はデータセキュリティ侵害1件あたり平均 $ 9.48 million のコストに直面しました。セキュリティ侵害の16％がフィッシングに起因し、認証情報の不正使用が15％を占め、フィッシングによるセキュリティ侵害1件あたりの平均被害額は $ 4.72 million に上ります。このようにサイバー攻撃や詐欺師がますます巧妙化する中、どうすればビジネスを保護できるでしょうか？
認証（AuthN）と認可（Authz）は、あらゆる防止戦略の中核に据える必要があります。認証は認証情報の検証を通じてユーザーの ID を確認し、認可は認証されたユーザーのアクセス権限を決定します。
以下では、AuthN と AuthZ の主な違いを確認し、これらがどのように連携してユーザーを認証し、システムへのアクセスを管理するのかをご紹介します。
認証（AuthN）とは？
認証（AuthN と略されることがよくあります）は、保護された情報にアクセスする必要がある際に、その人の ID を確認します。その主な機能は、許可されたユーザーだけがシステムにアクセスし、機密データを閲覧できるようにすることです。
一般的な認証方法として以下が挙げられます。
パスワード
指紋や顔認識などの生体認証
複数のチェックを組み合わせた多要素認証
このプロセスでは、関係者間の安全な通信を確保するために、さまざまなプロトコルが使用されます。以下はその例です。
OAuth と OpenID Connect により、ログイン詳細を共有することなく、プライベートリソースにアクセスできる権限をアプリケーションに安全に付与できます。
SAML により、一度サインインするだけでさまざまな Web プログラムやオンラインサービスへのアクセスが可能になります。
このアプローチの課題には、以下が含まれます。
アカウント間でのパスワードの再利用により盗難のリスクが高まります。
物理的な生体認証情報は、盗まれた場合に変更が複雑になる可能性があります
プロトコルは、顧客の利便性と保護のバランスを取る必要があります。
大量のユーザーをサポートすると、技術的なハードルが増える可能性があります。
認可とは？
認可（AuthZ）は、認証されたユーザーがアクセスまたは使用できるアクションまたはリソースを決定します。その役割は、さまざまなユーザーに対して適切なポリシーと権限を適用することです。
主な認可モデルとして以下が挙げられます。
役割と責任に基づいてユーザーをグループ化するロールベースのアクセス コントロール（RBAC）
ユーザー名や時刻、場所などのさまざまな属性によってアクセスが決定される属性ベースのアクセス制御（ABAC）
以下は一般的な認可メカニズムです：
誰がどのリソースにアクセスできるかを指定するアクセス制御リスト（ACL）
暗号的に検証された権限がユーザーに付与される機能ベースのシステム
認可の粒度を細かくすることも粗くすることも可能です。粒度が細かいアクセスではリソースの一部を正確にコントロールできますが、粒度の粗いアクセスでは、リソースに対するすべてのアクションを許可するなど、より広範な権限が提供されます。
認証と認可の主な違い
認証と認可はいずれも重要なセキュリティ機能ですが、アクセスコントロールのさまざまな段階で異なる役割を果たします。これらの違いを理解することで、適切な保護を確実に実装できるようになります。ソフトウェアを開発する場合でも、ユーザーアクセスを管理する場合でも、これらの機能を効果的に使用することで、プライバシーと生産性の両方をサポートできます。それぞれの特徴を見てみましょう。
目的：AuthN は個人の身元を確認し、AuthZ は役割などの要素に基づいて、その個人がアクセスできるアクションとリソースを決定します。
タイミング: 認証はユーザーが誰であるかを確認するために事前に実行され、認可はその特定のセッションで実行できることをコントロールします。
ユーザーエクスペリエンス： 認証はユーザーと対話してユーザーを識別しますが、認可は通常、アクセスポリシーに従ってバックグラウンドで実行されます。
関連するデータ：AuthN はパスワードなどの識別情報に依存する一方、AuthZ は機密性レベルなどのリソース属性を考慮します。
障害シナリオ: 認証では、識別に失敗するとアクセスが拒否されます。一方、AuthZ は一部のリソースへのアクセスのみをブロックし、他のリソースへのアクセスは許可します。
カスタマイズ：AuthN は識別方法に依存しており、これはユーザーによってコントロールされます。一方、管理者は特定のシステムのユーザー・ロールや属性に合わせて AuthZ ポリシーをカスタマイズできます。
プロトコルと標準：認証には OAuth などのプロトコルがあり、認可は RBAC といったモデルやアクセス制御リストをはじめとするメカニズムに従います。
認証と認可の連携の仕組み
認証と認可はサイバーセキュリティにおいて重要な協力関係を形成し、それぞれがシステムや情報へのアクセスを保護するために独立しながらも補完的な役割を果たします。したがって、社内で社員のログインを管理する場合、これらのプロセスがどのように連携して機能するかを理解することが、リソースとデータプライバシーを強力に保護する上で不可欠です。以下は、それらがどのように連携して機能するかを示しています。
ユーザーによる開始：ユーザーが保護されたリソースにアクセスする必要がある場合、認証プロセスが開始されます。
認証リクエスト： ユーザーの ID を確認するため、詳細が認証サーバーに送信されます。
認証情報の送信: ユーザーは、自分が誰であるかを証明するために、ユーザーネームやパスワードなどの認証情報を送信します。
本人確認：認証サーバーは、認証情報が保存されている識別情報と一致することを確認します。
セッションの作成: 検証が成功すると、設定された期間内に個人が認可された機能を使用できるセッションが作成されます。
認可チェック： 同時に、認可サーバーはアクセスポリシーを検証し、役割や場所などの ID にリンクされた属性に基づき、ユーザーが利用できるアクションまたはリソースを決定します。
ポリシーの適用: 認可のレスポンスによってアクセスルールが適用され、それに応じて特定のリクエストがブロックまたは許可されます。
リソース・アクセス: 認可されたリクエストは現在処理され、認可されていないものへのアクセスはすべて拒否されます。
継続的な検証：ユーザーセッションが継続している間、定期的なチェックによって認証が有効であることが確認されます。
セッションの終了：完了時またはタイムアウト後にセッションは終了し、その記録はサーバーメモリから消去されます。
認証と認可における一般的な課題
認証と認可にはそれぞれ固有の課題があり、単一のソリューションですべてに完全に対処することはできません。これらの障害を認識することで、技術の進歩、プロセスの改善、またはユーザー教育を通じて、弱い領域の強化に集中できるようになります。プロアクティブで多面的なアプローチを採用することで、時間の経過とともにセキュリティ体制を強化できます。
以下は、直面する可能性がある一般的な制約の一部です。
複数のシステムにまたがるユーザー ID の管理： ユーザーがさまざまなアプリケーションやシステムにアクセスするのに伴い、一貫した認証詳細を維持することがますます困難になります。
セキュリティとユーザーの利便性のバランス：厳格なセキュリティプロトコルはユーザーの負担となる摩擦を生む可能性がある一方で、緩いアクセスコントロールは脆弱性を増大させます。適切なバランスを実現することは、繊細でありながら不可欠な課題です。
マイクロサービスアーキテクチャでの認可の処理： アプリケーションが独立したコンポーネントに分割されると、それらの間で認可ポリシーを調整することで複雑さが生じます。
モノのインターネット（IoT）デバイスの保護：センサー、家電製品、その他の "smart" テクノロジーの普及により、攻撃対象領域が拡大します。進化する脅威に対して認証および認可プロセスのレジリエンスを維持するには、多大なリソースと投資が必要です。
データ保護規制への準拠を確保する： GDPR などの規則ではプライバシーと同意の強制に厳格なアプローチが取られているため、認証システムはこれらの要件を確実に満たす必要があり、そのためには一貫した協調的な取り組みが求められます。
Fastly を使用して認証と認可を強化
Fastlyのglobal edge cloud platformは、エッジコンピューティングを活用してレイテンシを削減し、セキュリティを強化することで、認証プロセスと認可プロセスの両方における特有の課題に対処します。このアプローチにより、厳格なアクセスコントロールを維持しながら、高速かつ信頼性の高いユーザーエクスペリエンスを実現します。
Fastly では以下を通じてセキュリティ戦略を強化できます。
エッジ認証： Fastly は、ユーザーに近いグローバルネットワークエッジで認証リクエストを処理するため、自社サーバーに過負荷をかけることなく、より高速な ID 検証が可能になります。
柔軟な認可ポリシー：Fastly ではエッジでカスタマイズ可能なアクセスコントロールを提供しており、セントラルサーバーと通信することなく、ポリシー主導の認可決定をリアルタイムで行えます。
トークンベースの認証：このソリューションは、OAuth 2.0 や OpenID Connect などの一般的な標準とスムーズに統合し、ユーザーとアプリケーション・プログラミング・インターフェイス（API）向けの安全なトークン交換をサポートします。
API セキュリティ：Fastly's edge services は認証情報を確認し、API リクエストの認可を検証して、無効なリクエストがバックエンドに到達する前にブロックします。このアプローチにより、サービスとデータが最初から保護されます。
リアルタイムのポリシー更新：認可の変更を Fastly ネットワーク全体に即座にプッシュできます。場所に関係なく、すべてのユーザーに対して変更はすぐに有効になります。
ログ機能と分析：Fastly のログ機能と分析ツールは、認証や認可のアクティビティに関する貴重なインサイトを提供し、パターンの監視、異常の検出、経時的なプロセスの最適化に役立ちます。
ID プロバイダーとの容易な統合：このプラットフォームは既存の ID ソリューションに迅速に接続し、現在のシステムを置き換えることなく、スケーラブルで安全な認証フレームワークを構築できます。
今すぐ無料デモをリクエストして、Fastly が認証と認可の機能をどのように強化できるかをご覧ください。