Gatekeeper パターン

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

コンテキストと問題

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

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

ソリューション

この問題の解決策の 1 つは、パブリック エンドポイントを実装するコードを、要求を処理してストレージにアクセスするコードから分離することです。 クライアントと対話し、承認された要求を内部エンドポイント、キュー、またはブローカーを介してビジネス操作を処理するワークロード コンポーネントにルーティングするファサード層を使用して、コードを分離します。 この図では、このパターンの概要を示します。

ゲートキーパー パターンの概要を示す図。

Gatekeeper パターンを使用してストレージを保護することも、アプリケーションのすべての機能を保護するためのより包括的なファサードとして使用することもできます。 重要な要素は次のとおりです。

  • 制御された検証: ゲートキーパーはすべての要求を検証し、検証要件を満たしていない要求を拒否します。

  • 限られたリスクと露出: ゲートキーパーは、信頼されたホストがストレージとサービスへのアクセスに使用する資格情報またはキーにアクセスしないため、リスクと露出が軽減されます。 ゲートキーパーが侵害された場合、攻撃者はこれらの資格情報またはキーにアクセスできません。

  • 適切なセキュリティ: ゲートキーパーは制限付き特権モードで実行され、残りのアプリケーションはストレージとサービスにアクセスするために必要な完全信頼モードで実行されます。 Gatekeeperは、侵害された場合、アプリケーション サービスまたはデータに直接アクセスできません。

このパターンは、標準的なネットワーク構成におけるファイアウォールのように動作します。 従来のファイアウォールとは異なり、ゲートキーパーは要求を詳細に調べ、必要なタスクを実行する信頼されたホストに要求を渡すかどうかについてアプリケーション主導の決定を行うことができます。 通常、この決定では、ゲートキーパーが要求コンテンツを検証してサニタイズしてから、信頼されたホストに渡す必要があります。 Gatekeeper は、要求の承認、予期しないまたは無効なペイロード コンテンツの検索、レート制限の実行、その他のさまざまなチェックの実行を行う場合があります。

問題と考慮事項

このパターンを実装する方法を決定するときは、次の点を考慮してください。

  • 信頼されたホストが、ゲートキーパーのみが使用する内部または保護されたエンドポイントのみを公開していることを確認します。 信頼されたホストは、外部エンドポイントまたはインターフェイスを公開してはなりません。

  • ゲートキーパーは、制限付き特権モードで実行する必要があります。 実際には、ゲートキーパーと信頼されたバックエンドを別々のコンピューティング境界でホストし、バックエンド エンドポイントをプライベートに保ちます。

  • ゲートキーパーは、アプリケーションまたはサービスに関連する処理やデータへのアクセスを実行しないでください。 その関数は、要求の検証とサニタイズのみを目的とします。 信頼されたホストは追加の要求検証を実行する必要がある場合がありますが、ゲートキーパーはコア検証を実行する必要があります。

  • 可能な場合は、ゲートキーパーと信頼されたホストまたはタスクの間で、HTTPS、Secure Sockets Layer (SSL)、トランスポート層セキュリティ (TLS) などのセキュリティで保護された通信チャネルを使用します。 ただし、一部のホスティング環境は、内部エンドポイントで HTTPS をサポートしていません。

  • ゲートキーパー パターンを実装するためにレイヤーを追加すると、追加の処理とネットワーク通信が必要になるため、パフォーマンスに影響する可能性があります。

  • ゲートキーパーは単一障害点 (SPoF) にすることができます。 障害の影響を最小限に抑えるには、冗長インスタンスをデプロイし、自動スケール メカニズムを使用して容量を確保し、可用性を維持することを検討してください。

このパターンを使用する場合

このパターンは次の状況で使用します。

  • 機密情報を処理します。

  • 悪意のあるトラフィックから強力な保護を必要とするサービスを公開します。

  • バックエンド サービスの直接的な公開を許容できないミッション クリティカルな操作を実行します。

  • 要求の検証とサニタイズをコア ビジネス処理から分離する必要があります。

このパターンは、次の場合に適さない場合があります。

  • 専用のゲートキーパー 層を追加することなく、バックエンド サービスの組み込みのプラットフォーム制御を使用して、セキュリティと検証の要件を満たすことができます。

  • 追加されたネットワーク ホップと検証待機時間は、厳密なエンドツーエンドの待機時間要件に違反しています。

ワークロード設計

ワークロードの設計で Gatekeeper パターンを使用して、Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。

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

- SE:06 ネットワーク制御
- SE:10 監視と脅威の検出
パフォーマンス効率 は、スケーリング、データ、およびコードの最適化を通じて、ワークロード の需要を効率的に満たすのに役立ちます。 このパターンを使用すると、ノード レベルでレート チェックを実装するのではなく、ゲートキーパー レベルで調整を実装できます。 すべてのノード間のレート状態の調整は、本質的にパフォーマンスが高いわけではありません。

- PE:03 サービスの選択

このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。

Example

ゲートキーパー パターンは通常、階層化された要求パスを実装します。各レイヤーには、特定の責任と制限された信頼スコープがあります。

レイヤード ゲートキーパー パターンを示す図。

このアーキテクチャのVisio ファイルをダウンロードしてください。

この設計では、Azure Application Gateway with Azure Web Application Firewall が外部のゲートキーパーです。 インターネットに接続されたトラフィックを検査し、トラフィックが API 層に到達する前にセキュリティ制御を適用します。 Azure API Management は内部ゲートキーパーです。 API 固有の制御を適用し、承認されたトラフィックのみをプライベート バックエンドに転送します。

たとえば、Azure Web Application Firewallは、SQL インジェクションとクロスサイト スクリプティング パターンを検出してブロックし、プロトコルと要求サイズの規則を適用し、要求が API Management またはプライベート バックエンドに到達する前にボットと IP ベースのフィルター処理を適用できます。

内部レイヤーで API Management を使用すると、ゲートウェイ パイプラインの受信要求と送信応答にポリシーが適用されます。 API Management が要求と応答を処理する方法の詳細については、「 API Management のポリシー」を参照してください。 JSON Web トークン (JWT) の検証、レート制限、ヘッダー変換、応答整形などのポリシー オプションについては、 API Management ポリシー リファレンスを参照してください。

このパスのサービス間認証では、Azure リソースの管理 ID を一貫して使用します。 たとえば、API Management では、マネージド ID ポリシーで authenticate を使用して、シークレットを格納せずにバックエンド呼び出しのMicrosoft Entra トークンを取得できます。

バックエンドはプライベートのままです。 たとえば、バックエンドは Azure App Service アプリで、private エンドポイント を使用できるため、アプリはプライベートにアクセスできます。

コンテナー化されたワークロードの場合は、API Management と App Service の内部パスをイングレス ベースのコンピューティングに置き換えることができます。

  • Azure Kubernetes Service (AKS)。イングレス コントローラーの選択、Kubernetes ポリシー、ネットワーク トポロジ、クラスター操作をより詳細に制御できます。

  • Azure Container Apps。ingress 機能を提供しインフラストラクチャ管理を削減するサーバーレス マネージド コンテナー プラットフォームです。

これらの代替手段では、イングレスはホストまたはパスによるルーティング、TLS の終了、および内部専用サービスの公開を行うことができます。 要求の制限や許可または拒否規則などの特定の機能は、選択したイングレス実装によって異なります。 いずれの場合も、ゲートキーパーの境界を維持します。入力時に検証とポリシーの適用を適用し、そのゲートキーパー パス経由でのみバックエンド サービスに到達可能な状態を維持します。

このパスの各レイヤーは、一元化する必要があるログとメトリックを出力します。 Azure Web Application Firewall診断ログは、要求ごとに一致したルールとブロックされたルールを記録します。 API Management は、要求の期間、応答コード、およびポリシーの結果をキャプチャするゲートウェイ ログを出力します。 バックエンド サービスは、アプリケーション レベルのテレメトリを出力します。 Azure Monitor でこれらのログとメトリックを収集し、それらをLog Analytics ワークスペースにルーティングして、統合クエリを実行します。 エッジで関連付け ID を生成または転送し、API Management とバックエンド サービス (要求ヘッダーや分散トレース コンテキストなど) を介して伝達することで、エンド ツー エンドの要求の相関関係を標準化し、1 つのトランザクションをすべてのレイヤーにわたって追跡できるようにします。 Microsoft Defender for Cloud を使用して、ゲートキーパー コンポーネント全体のセキュリティに関する推奨事項を表示します。 異常なAzure Web Application Firewallブロック率または API Management エラーの急増に関するアラートを構成して、プライベート バックエンドに到達する前に脅威を検出します。

次のステップ

このパターンを実装する場合、次のガイダンスが関連する場合があります。

次のクラウド 設計パターンは、多くの場合、ゲートキーパー パターンと共に使用されます。

  • Last updated on