Event Hubs を使用した Azure Functions のセキュリティ保護

  • [アーティクル]

Azure でリソースへのアクセスを構成する場合、リソースへのアクセス許可をきめ細かく制御する必要があります。 これらのリソースへのアクセスは、クライアントが自身に許可された一連の限定されたアクションのみ実行できるように、"知る必要性" と "最小特権" というセキュリティ原則に基づいている必要があります。

Event Hubs へのアクセスの承認

Azure Event Hubs のリソースへのアクセスを承認するには、次のセキュリティ コンストラクトを使用します。

  • Microsoft Entra ID: Microsoft Entra ID が提供するロールベースのアクセス制御 (RBAC) を使って、クライアントによる Event Hubs リソースへのアクセスをきめ細かく制御することができます。 Microsoft Entra ID は、付与されたロールとアクセス許可に基づいて、OAuth 2.0 アクセス トークンを使って要求を認可します。

  • Shared Access Signature: Shared Access Signature (SAS) は、承認規則に基づいて Event Hubs リソースを保護する機能を提供します。 承認ポリシーを定義するには、メッセージの送信、メッセージのリッスン、名前空間内のエンティティの管理など、1 つ以上のポリシー規則を選択します。

Shared Access Signature に関する考慮事項

Shared Access Signature を Azure Functions および Event Hubs とともに使用する場合は、次の考慮事項を確認する必要があります。

  • 管理権限を回避する: 管理権限は、Event Hubs 名前空間内のエンティティを管理できるだけでなく、送信権限とリッスン権限の両方を含んでいます。 関数アプリには、実行するアクションに基づいて、送信権限とリッスン権限の組み合わせのみを付与することをお勧めします。

  • 既定の管理規則は使用しない: 関数アプリで必要な場合 (これは一般的なシナリオではありません) を除き、RootManageSharedAccessKey という名前の既定のポリシー規則は使用しないようにしてください。 また、この既定の規則は名前空間レベルで作成され、基になるすべてのイベント ハブにアクセス許可を付与する点にも注意してください。

  • 共有アクセス ポリシーのスコープを確認する: 共有アクセス ポリシーは、名前空間レベルでイベント ハブごとに作成できます。 クライアントごとに調整された詳細なアクセス ポリシーを作成して、その範囲とアクセス許可を制限することを検討してください。

マネージド ID

Active Directory の ID は、関数アプリや Web アプリなど、Azure の管理対象リソースに割り当てることができます。 ID が割り当てられると、サービス プリンシパルと同様に、認可に Microsoft Entra ID を使う他のリソースを処理できるようになります。

関数アプリにマネージド ID を割り当てて、サービスのサブセット (Event Hubs を含む) に対して ID ベースの接続を利用することができます。 ID ベースの接続では、トリガーと出力の両方のバインド拡張機能のサポートが提供され、サポートのために Event Hubs 拡張機能 5.x 以降を使用する必要があります。

ネットワーク

既定では、要求が有効な認証と承認を受けている限り、Event Hubs 名前空間にはインターネットからアクセスできます。 Event Hubs 名前空間へのネットワーク アクセスを制限するには、次の 3 つのオプションがあります。

すべてのケースで、名前空間に対して少なくとも 1 つの IP ファイアウォール規則または仮想ネットワーク規則が指定されている点に注意することが重要です。 IP アドレスも仮想ネットワーク規則も指定されていない場合、パブリック インターネット経由で (アクセス キーを使用して) 名前空間にアクセスできます。

Azure Functions は、イベント ハブからイベントを使用したり、イベント ハブにイベントを発行するように構成できます。これらのイベント ハブは、サービス エンドポイントまたはプライベート エンドポイントを使用して設定されます。 関数アプリがサービス エンドポイントまたはプライベート エンドポイントを使用してイベント ハブに接続するには、リージョンでの仮想ネットワーク統合が必要です。

Functions を仮想ネットワークと統合し、vnetRouteAllEnabled を有効にすると、関数アプリからのすべての送信トラフィックが仮想ネットワーク経由で強制されます。 これは、Azure サービスへのトラフィックを含むすべてのトラフィックが、検査と制御のために仮想ネットワークを通過するようにして、関数アプリをセキュリティで保護するシナリオで特に重要です。 関数アプリを完全にロックダウンする場合は、ストレージ アカウントを制限する必要もあります。

仮想ネットワーク環境でイベントをトリガー (使用) するには、関数アプリを Premium プラン、Dedicated (App Service) プラン、または App Service Environment (ASE) でホストする必要があります。

さらに、Azure Functions Premium プランで実行し、仮想ネットワークの制限付き Event Hub からイベントを使用するには、仮想ネットワーク トリガーのサポート (ランタイム スケールの監視とも呼ばれます) が必要です。 ランタイム スケールの監視は、Azure portal、Azure CLI、その他のデプロイ ソリューションを使用して構成できます。 関数が Dedicated (App Service) プランまたは ASE で実行されている場合は、ランタイム スケールの監視は使用できません。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • David Barkol | プリンシパル ソリューション スペシャリスト (GBB)

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

続行する前に、次の関連記事を確認してください。

可観測性

「サーバーレスなイベント処理」は、この種類の一般的なアーキテクチャを詳述する参照アーキテクチャです。コード サンプルと重要な考慮事項について説明しています。