編集

次の方法で共有


Gatekeeper パターン

Azure Dedicated Host

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

コンテキストと問題

クラウド サービスは、クライアント アプリケーションが 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 パターンをワークロードの設計でどのように使用できるかを評価する必要があります。 次に例を示します。

重要な要素 このパターンが柱の目標をサポートする方法
セキュリティ設計の決定により、ワークロードのデータとシステムの機密性整合性、および可用性が確保されます。 要求フローにゲートウェイを追加すると、ウェブアプリケーションファイアウォール、DDoS 保護、ボット検出、要求操作、認証開始、認可チェックなどのセキュリティ機能を一元化できます。

- SE:06 ネットワーク制御
- SE:10 監視と脅威の検出
パフォーマンスの効率化は、スケーリング、データ、コードを最適化することによって、ワークロードが効率的にニーズを満たすのに役立ちます。 このパターンは、ノードレベルでレート チェックを実装するのではなく、ゲートウェイレベルでスロットリングを実装する方法です。 すべてのノード間でレートステートを調整することは、本質的にパフォーマンスではありません。

- PE:03 サービスの選択

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

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

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

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