Gatekeeper パターン

クライアントとアプリケーションまたはサービスとの間のブローカー要求に対する専用ホスト インスタンスを使用して、アプリケーションとサービスを保護します。 ブローカーは要求を検証してサニタイズし、セキュリティの追加の層を提供してシステムの攻撃面を制限できます。

コンテキストと問題

クラウド サービスは、クライアント アプリケーションが API を呼び出せるようにするエンドポイントを公開します。 API の実装に使用されるコードは、認証、認可、パラメーター検証、一部またはすべての要求処理など、いくつかのタスクをトリガーまたは実行します。 API コードは、クライアントに代わって記憶域やその他のサービスにアクセスする可能性があります。

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

解決策

この問題の解決策の 1 つは、パブリック エンドポイントを実装するコードと、要求を処理して記憶域にアクセスするコードを分離することです。 分離を実現するには、要求を処理するホストまたはタスクに、クライアントと対話してから要求を渡す (おそらく分離インターフェイスを通じて) ファサード (専用タスク) を使用します。 図では、このパターンの大まかな概要を説明しています。

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

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

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

問題と注意事項

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

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

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

このパターンは、次のようなアプリケーションに役立ちます。

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

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、Gatekeeper パターンをワークロードの設計でどのように使用できるかを評価する必要があります。 次に例を示します。

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

例

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

関連リソース

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