Zero Trustでは、アプリケーション、ユーザー、デバイスごとにきめ細かな制御と認可ポリシーを定義することが基本となります。このためには、規制要件とセキュリティ要件の両方を満たすため、十分な粒度を持つシステムを用意することが重要になります。しかし、制御が多くなれば、潜在的にデメリットが増えることになります。ユーザーの問題のトラブルシューティングにおいて、管理者はアプリケーション、ユーザー ID、およびデバイス情報全体の変数の複雑な組み合わせを考慮することが必要になり、ログを丹念にふるいにかける必要が出てくることになります。
当社では、この点が改善されるべきと考えました。そして、この度Cloudflare Oneポリシーで使用されるすべてのアクティブなユーザーセッションと関連データを管理者が簡単に監査できるようにしました。これにより、単一のシンプルなコントロールパネルでZero Trustの実装におけるトラブルシューティングと診断を行う性能を維持しながら、非常にきめ細かな制御を実現し、両方の長所が活きることとなりました。以前はユーザーのブラウザに存在していた情報や動的に変更されていた情報が、エンドユーザーを煩わしたりログを掘り下げたりすることなく、管理者に利用できるようになったのです。
アプリケーションの認証と認可に関する簡易的説明
_認証_と_認可_は、Zero Trustポリシーにおいてリソースへのユーザーアクセスを許可する前に評価される2つのコンポーネントです。
認証は、ユーザー、デバイス、またはシステムの識別を検証するプロセスです。一般的な認証の方法には、ユーザー名とパスワードの入力、デジタル証明書の提示、さらには指紋や顔スキャンなどの生体認証などがあります。多要素認証（MFA）では、セキュリティ強化のため、ハードウェアキーとパスワードの組み合わせなど、2つ以上の個別の認証方法が必要になります。
認可は、エンティティが正常に認証された後に、特定のリソースまたはアクセスの許可または拒否を行うプロセスです。ここでは、認証されたエンティティがシステム内でできることとできないことを定義します。
アプリケーションの認証/認可メカニズム
この項で取り上げるWebアプリケーションでは、通常、次のようにHTTP Cookieを使用して認証と認可の両方を処理します。
認証：
ログイン：ユーザーがユーザー名とパスワードを入力してWebアプリケーションにログインすると、アプリケーションはこれらの資格情報をデータベースまたはIDプロバイダー（IDP）と照合して検証します。追加の認証形式を適用し、複数の認証要素を設けることもできます。これらが一致した場合、サーバーまたは外部セキュリティサービス（Cloudflare Accessなど）は、ユーザーが認証されたと見なします。
**Cookie/トークンの作成：**次に、サーバーがCookieまたはJSON Webトークンの形式でユーザーのセッションを作成します。Cookieは、ユーザーが再認証を行う必要があるタイミングまで、一定期間有効となります。
**Cookieの送信と保存：**サーバーは、セッションIDとCookie内のユーザーに関するその他の識別情報を含む応答をユーザーのブラウザに送り返します。その後、ブラウザはこのCookieを保存します。このCookieは、後に続く要求でユーザーを認識する際に用いられることになります。
認可：
**以降の要求：**Web アプリケーションに対し以降発生するすべての要求について、ユーザーのブラウザは自動的に要求にCookie（セッション ID およびその他の識別情報を含む）を含めます。
**サーバー側の検証：**サーバーはCookieからユーザーデータを取得し、セッションが有効かどうかを確認します。有効な場合、サーバーはユーザーの詳細とそのセッションIDに関連付けられているアクセス許可も取得します。
**認可の判断：**サーバーは、ユーザーのアクセス許可に基づき、要求された操作の実行または要求されたリソースへのアクセスをユーザーに許可するかどうかを決定します。
こうして、ユーザーはログイン後、セッションの有効期限が切れるかログアウトするまで、以降続くすべての要求に対し認可されたまま（および毎回承認が確認される）になります。
最新のWebアプリケーションでは、このセッション状態はJSON Webトークン（JWT）の形式で格納されるのが最も一般的です。
JWTベースの認証のデバッグ
多くの最新のWebアプリやCloudflare AccessなどのZero Trustネットワークアクセス（ZTNA）ソリューションでは、JWTが認証と認可に用いられています。JWTには、ユーザーに関する情報やその他のデータをエンコードする悪意のあるペイロードが含まれており、改ざんを防ぐためにサーバーによって署名されます。JWTはステートレスな方法で使用されることが多く、サーバーは各JWTのコピーを保持するのではなく、リクエストが届いたときに検証してデコードするだけで済みます。JWTのステートレスな性質は、ユーザーセッション管理の処理のために中央システムに依存する必要がないことを意味し、システムにアクセスするユーザーの数が増えてもスケーラビリティの問題の発生を回避できます。
ただし、このJWTのステートレスな性質により、ユーザーから特定のJWTを取得しない限りJWTベースの認証のデバッグは難しくなります。その理由は、次のとおりです:
**1. トークンの特異性：**各JWTは、ユーザーとセッションに固有となっています。ユーザー、発行権限者、トークン発行時刻、有効期限、および場合によってはその他のデータに関する情報（要求）がここに含まれます。したがって多くの場合、問題をデバッグする際に問題の原因となっている正確なJWTが必要となります。
**2. サーバー側のレコードの不在：**JWTはステートレスであるため、サーバーはデフォルトでセッションを保存しません。過去のトークンや関連する状態についての情報は、ログに記録するように特別に設計されていない限り、検索できません。さらに、プライバシーとデータ最小化の目的により、通常は実現しません。
**3. 一時的な問題：**JWTに関する問題は一時的なものとなる場合があり、トークンが使用された特定の瞬間にのみ関連するものとなり得ます。たとえば、ユーザーがトークンを使用しようとしたときにトークンの有効期限が切れていた場合、問題をデバッグするにはその特定のトークンが必要になります。
**4. プライバシーとセキュリティ：**JWTには機密情報が含まれている可能性があるため、取り扱いには注意が必要です。ユーザーからJWTを取得すると、問題をデバッグしているユーザーに個人情報やセキュリティ資格情報が公開される可能性があります。さらに、ユーザーが安全でないチャネルを介して開発者やITヘルプデスクにJWTを送信すると、傍受される可能性があります（Cloudflareは最近、この懸念の軽減を目的に無料でご利用いただけるHARサニタイザーをリリースしています)。
これらの要因により、問題となる特定のトークンがないと、JWTベースの認証に関する問題のトラブルシューティングが困難になります。
識別における問題をデバッグするためのより優れた方法
当社では、JWTやHARファイルをやり取りすることなく、Cloudflare Zero Trustでユーザー識別に関連する問題のデバッグにおけるより優れた方法の構築に着手しました。これにより、ユーザーのレジストリID（Gatewayポリシーに使用）とすべてのアクティブなアクセスセッションを管理者が確認できるようになりました。
このセッション情報には、IdP要求、デバイスポスチャー情報、ネットワークコンテクストなどZero Trustによる完全識別評価が含まれます。この情報は、Cloudflare Workers KVを活用し、Acessの認証ロジックで一切付加的な負荷をかけずに小袿できます。ユーザーがAccessで認証する時点で、関連する識別情報は即座にWorkers KVのKey/Valueペアに保存されます。これらはすべて、ユーザーの認証イベントのコンテクスト内で行われ、遅延の影響または外部サービスへの依存が最小限となることを意味しています。
この機能は、すべてのZero Trustプランのすべてのお客様が利用できます。Cloudflare Zero Trustを使い始めるには、最大50ユーザーまで利用できる無料アカウントにサインアップしてください。または、Cloudflareのエキスパートとともに貴社のSSEまたはSASEについてレビューを行い、貴社のZero Trustのユースケースに合わせ一歩ずつ進めていくことも可能です。