Azure Functions を使用すると、シークレット キーを使用して、関数エンドポイントへのアクセスをより困難にすることができます。 この記事では、Functions でサポートされるさまざまな種類のアクセス キーと、アクセス キーを操作する方法について説明します。
アクセス キーは、望ましくないアクセスに対してある程度の軽減策を提供しますが、運用環境内で HTTP エンドポイントをセキュリティで保護するには他のオプションを検討する必要があります。 たとえば、パブリック アプリ内で共有シークレットを配布することはお勧めしません。 その関数がパブリック クライアントから呼び出されている場合、次のまたはその他のセキュリティ メカニズムの実装を検討する必要があります。
アクセス キーは、HTTP によってトリガーされる関数内での HTTP 認可用の基礎を提供します。 詳細については、「認可レベル」を参照してください。
キーについて
アクセス キーのスコープとサポートされるアクションは、アクセス キーの種類によって異なります。
キー型 | キー名 | HTTP 認証レベル | 説明 |
---|---|---|---|
関数 |
default またはユーザー定義 |
function |
特定の関数エンドポイントへのアクセスのみを許可します。 |
ホスト |
default またはユーザー定義 |
function |
関数アプリ内のすべての関数エンドポイントへのアクセスを許可します。 |
マスター | _master |
admin |
関数アプリ内のランタイム REST API への管理アクセスも提供する特別なホスト キー。 マスター キーは関数アプリに昇格されたアクセス許可を許可するため、このキーをサード パーティと共有したり、ネイティブ クライアント アプリケーション内に配布したりしないでください。 |
システム | 拡張機能によって異なります | 該当なし | 特定の拡張機能では、Webhook エンドポイントにアクセスするために、システム マネージド キーが必要になる場合があります。 システム キーは、内部コンポーネントにより呼び出される拡張機能固有の関数エンドポイント向けに設計されています。 たとえば、Event Grid トリガーを使用するには、トリガー エンドポイントの呼び出し時にサブスクリプションでシステム キーを使用する必要があります。 また、Durable Functions でも、Durable Task 拡張機能 API の呼び出しにシステム キーを使用します。 システム キーは特定の拡張機能によってのみ作成可能であり、その値を明示的に設定することはできません。 他のキーと同様に、ポータルから、またはキー API を使用してキーの新しい値を生成することは可能です。 |
各キーには参照用の名前が付けられており、関数およびホストのレベルに既定のキー (default
という名前) があります。 関数キーが、ホスト キーよりも優先されます。 2 つのキーが同じ名前で定義されている場合は、関数キーが使用されます。
次の表に、さまざまなアクセス キーの使用方法を比較して示します。
アクション | 範囲 | キー型 |
---|---|---|
関数の実行 | 当該の関数 | 機能 |
関数の実行 | すべての関数 | 関数またはホスト |
admin エンドポイントの呼び出し |
関数アプリ | マスターのみ |
Durable Task 拡張機能 API の呼び出し | 関数アプリ* | システム |
拡張機能固有の Webhook の呼び出し (内部) | 関数アプリ* | システム |
*拡張機能によって決定されるスコープ。
主な要件
Functions 内では、アクセス キーはランダムに生成される 32 バイトの配列で、URL セーフな base-64 文字列としてエンコードされます。 独自のアクセス キーを生成して Functions で使用できますが、それよりも Functions ですべてのアクセス キーを生成できるようにすることを強くお勧めします。
Functions によって生成されるアクセス キーには、アクセス キーの種類と、それが Azure Functions によって生成されたことを示す特別な署名とチェックサムの値が含まれます。 これらの追加のコンポーネントをキー自体に含めた場合、セキュリティ スキャンやその他の自動化されたプロセス中に見つかったこれらの種類のシークレットのソースを、より簡単に特定できます。
Functions でキーを生成できるようにするには、キーの生成に使用できるすべての API で、value
キーを指定しないでください。
キー ストレージを管理する
キーは関数アプリの一部として Azure に格納され、保存中は暗号化されます。 既定では、キーは、AzureWebJobsStorage
設定によって指定されたアカウントの Blob Storage コンテナーに格納されます。
AzureWebJobsSecretStorageType
設定を使用して、この既定の動作をオーバーライドし、代わりに次のいずれかの別の場所の中にキーを格納できます。
場所 | 値 | 説明 |
---|---|---|
2 つ目のストレージ アカウント | blob |
Functions ランタイムで使用されているものとは異なるストレージ アカウント内の Blob Storage 内にキーを格納します。 使用される特定のアカウントとコンテナーは、AzureWebJobsSecretStorageSas 設定の中に設定された Shared Access Signature (SAS) URL によって定義されます。 SAS URL が変更された場合は、AzureWebJobsSecretStorageSas 設定をメンテナンスする必要があります。 |
Azure Key Vault | keyvault |
AzureWebJobsSecretStorageKeyVaultUri 内に設定されたキー コンテナーは、キーを格納するために使用されます。 |
ファイル システム | files |
キーはローカル ファイル システム上に保持されます。これは、Functions v1.x での既定です。 ファイル システム ストレージは推奨されません。 |
Kubernetes シークレット | kubernetes |
キーを格納するには、AzureWebJobsKubernetesSecretName で設定されているリソースが使われます。 関数アプリが Kubernetes に展開されている場合にのみサポートされます。 Azure Functions Core Tools を使用してアプリを Kubernetes クラスターに展開すると、この値が自動的に生成されます。 不変シークレットは サポートされていません |
Key Vault をキー ストレージに使用する場合、必要なアプリ設定は、どちらのマネージド ID の種類か (システム割り当てまたはユーザー割り当て) によって異なります。
設定の名前 | システム割り当て | ユーザー割り当て | アプリの登録 |
---|---|---|---|
AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Von Bedeutung
シークレットのスコープは、 AzureWebJobsSecretStorageKeyVaultUri
設定を通じて個々の関数アプリには適用されません。 同じ Key Vault を使用するように複数の関数アプリが構成されている場合、同じシークレットが共有され、キーの競合や上書きにつながる可能性があります。 意図しない動作を回避するには、関数アプリごとに個別の Key Vault インスタンスを使用することをお勧めします。
アクセス キーを使用する
HTTP によってトリガーされる関数は、https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>
という形式の URL を使用して呼び出すのが一般的です。 特定の関数の認可レベルが anonymous
以外の値に設定されている場合は、要求内にアクセス キーも指定する必要があります。 アクセス キーは、?code=
クエリ文字列を使用して URL 内に、または要求ヘッダー (x-functions-key
) 内に指定できます。 詳細については、「アクセス キーの認可」を参照してください。
ランタイム REST API (/admin/
の下) にアクセスするには、_master
要求ヘッダー内にマスター キー (x-functions-key
) を指定する必要があります。
サイト プロパティを使用してfunctionsRuntimeAdminIsolationEnabled
。
関数のアクセス キーを取得する
関数およびホストのキーは、次の Azure Resource Manager API を使用してプログラムで取得できます。
Azure Resource Manager API を呼び出す方法については、「Azure REST API リファレンス」を参照してください。
次の方法を使用すると、REST API を使用せずにアクセス キーを取得できます。
Azure portal にサインインし、"関数アプリ" を検索して選択します。
操作する関数アプリを選択します。
左側のペイン内で、[関数] を展開してから、[アプリ キー] を選択します。
[アプリ キー] ページが表示されます。 このページ上にはホスト キーが表示されます。これは、アプリ内の任意の関数にアクセスするために使用できます。 システム キーも表示されます。これは、すべての関数アプリ API への管理者レベルのアクセスを、どのユーザーに対しても付与します。
特定の関数用のキーを使用して、最小限の特権を実践することもできます。 関数固有のキーは、特定の HTTP によってトリガーされる関数の [関数キー] タブから取得できます。
アクセス キーを更新または作成する
アクセス キー値を更新または作成する場合は、その関数を呼び出すすべてのクライアントに更新後のキー値を手動で再配布する必要があります。
関数およびホストのキーは、プログラムで更新する、または次の Azure Resource Manager API を使用して新しく作成することができます。
Azure Resource Manager API を呼び出す方法については、「Azure REST API リファレンス」を参照してください。
次の方法を使用すると、REST API への呼び出しを手動で作成せずに、アクセス キーを取得できます。
Azure portal にサインインし、"関数アプリ" を検索して選択します。
操作する関数アプリを選択します。
左側のペイン内で、[関数] を展開してから、[アプリ キー] を選択します。
[アプリ キー] ページが表示されます。 このページ上にはホスト キーが表示されます。これは、アプリ内の任意の関数にアクセスするために使用できます。 システム キーも表示されます。これは、すべての関数アプリ API への管理者レベルのアクセスを、どのユーザーに対しても付与します。
更新するキーの横にある [キー値の更新] を選択してから、[更新して保存] を選択します。
特定の HTTP によってトリガーされる関数の [関数キー] タブ内で関数キーを更新することもできます。
アクセス キーを削除する
関数およびホストのキーは、次の Azure Resource Manager API を使用してプログラムで削除できます。
Azure Resource Manager API を呼び出す方法については、「Azure REST API リファレンス」を参照してください。