ゲートキーパー パターン

専用のホスト インスタンスを使用して、アプリケーションとサービスを保護します。このホスト インスタンスは、クライアントとアプリケーションまたはサービスの間でブローカーとして機能し、要求を検証して不要部分を削除し、クライアントとアプリケーションまたはサービスの間で要求とデータを渡します。 セキュリティの追加の層を提供し、システムの攻撃対象領域を制限することができます。

コンテキストと問題

アプリケーションは、要求を受信し処理することで、クライアントに機能を公開します。 クラウド ホスト型のシナリオでは、アプリケーションはクライアントが接続するエンドポイントを公開し、通常は、クライアントからの要求を処理するコードを含みます。 このコードは、認証と検証、一部またはすべての要求処理を実行し、クライアントに代わってストレージおよびその他のサービスにアクセスする可能性があります。

悪意のあるユーザーがシステムを侵害しアプリケーションがホストしている環境にアクセスできると、資格情報とストレージ キー、アクセスするサービスとデータなどの、システムが使用するセキュリティ メカニズムが公開されてしまいます。 その結果、悪意のあるユーザーは、機密情報やその他のサービスに無制限にアクセスできることになります。

解決策

クライアントが機密情報やサービスへのアクセスを取得するリスクを最小限に抑えるには、パブリック エンドポイントを公開するホストまたはタスクを、要求を処理し記憶域にアクセスするコードから切り離します。 これを実現するには、要求を処理するホストまたはタスクに、クライアントと対話してから要求を渡す—おそらく分離インターフェイスを通じて—ファサード (専用タスク) を使用します。 図では、このパターンの大まかな概要を説明しています。

このパターンの大まかな概要

ゲートキーパー パターンは、単なる記憶域の保護に使用したり、あるいは、アプリケーションのすべての関数を保護するためにより包括的なファサードとして使用できます。 重要な要因は次のとおりです。

  • 制御された検証。 ゲートキーパーは、すべての要求を検証し、検証要件を満たしていないものを拒否します。
  • 制限付きのリスクと公開。 ゲートキーパーには、記憶域およびサービスへのアクセスのため信頼されたホストが使用する資格情報またはキーへのアクセスはありません。 ゲートキーパーが侵害された場合、攻撃者はこれらの資格情報またはキーへのアクセスは取得しません。
  • 適切なセキュリティ。 ゲートキーパーが限られた特権モードで実行される一方、残りのアプリケーションは、記憶域およびサービスへのアクセスに必要な完全信頼モードで実行されます。 ゲートキーパーは、侵害された場合、アプリケーション サービスまたはデータに直接アクセスできません。

このパターンは、標準的なネットワーク構成におけるファイアウォールのように動作します。 これによりゲートキーパーは、要求をチェックし、必要なタスクを実行する信頼されたホストに要求を渡すかどうかを決定することができます。 通常この決定には、信頼されたホストに渡す前にゲートキーパーが要求のコンテンツを検証して不要部分を削除する必要があります。

問題と注意事項

このパターンの実装方法を決めるときには、以下の点に注意してください。

  • ゲートキーパーが要求を渡す信頼されたホストが、内部のまたは保護されたエンドポイントのみを公開し、ゲートキーパーだけに接続することを確認してください。 信頼されたホストは、外部エンドポイントまたはインターフェイスを公開してはなりません。
  • ゲートキーパーは、限られた特権モードで実行する必要があります。 通常これは、ゲートキーパーと信頼されたホストを別々のホステッド サービスまたは仮想マシンで実行することを意味します。
  • ゲートキーパーは、アプリケーションやサービスに関連する処理を実行したり、データにアクセスしたりしてはいけません。 その機能は純粋に、要求を検証し不要部分を削除することです。 信頼されたホストが追加で要求の検証を実行しなければならない場合がありますが、中核となる検証はゲートキーパーが実行するものです。
  • 可能な場合、ゲートキーパーと信頼されたホストやタスクの間では、セキュリティで保護された通信チャネル (HTTPS、SSL または TLS) を使用します。 ただし、一部のホスティング環境は、内部エンドポイントで HTTPS をサポートしていません。
  • ゲートキーパー パターンを実装するためにアプリケーションに追加レイヤーを加えると、必要となる追加の処理とネットワーク通信のため、パフォーマンスになんらかの影響を与える可能性があります。
  • ゲートキーパー インスタンスは、単一障害点になる可能性があります。 障害の影響を最小限に抑えるには、可用性を維持する容量を確保するために、追加のインスタンスを展開して、自動スケール メカニズムを使用することを検討してください。

このパターンを使用する状況

このパターンは次の目的に役立ちます。

  • 機密性の高い情報を処理するアプリケーションが、悪意のある攻撃について高度の保護が必要であるサービスを公開している、または中断してはいけないミッション クリティカルな操作を実行している。
  • 分散アプリケーションで、メインのタスクとは別に要求の検証を実行する、または、メンテナンスと管理の簡略化のためにこの検証を集中管理する必要がある。

クラウド ホスト型のシナリオでは、ゲートキーパー ロールまたは仮想マシンを、アプリケーションの信頼されたロールとサービスから分離することで、このパターンを実装することができます。 これを行うには、内部エンドポイント、キュー、または記憶域を中間通信メカニズムとして使用します。 図は、内部エンドポイントの使用を示しています。

Cloud Services Web とワーカー ロールを使用したパターンの例

ゲートキーパー パターンを実装する場合、バレット キー パターンも関連する可能性があります。 ゲートキーパーと信頼されたロールとの間で通信するときは、リソースへのアクセス許可を制限するキーまたはトークンを使用してセキュリティを強化することをお勧めします。 このパターンでは、クライアントが特定のリソースまたはサービスへの限定的な直接アクセスを行えるようにするトークンまたはキーの使用方法を記述します。