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つのキーが同じ名前の場合は、常にファンクションキーが使われます。
次の表に、さまざまなアクセス キーの使用方法を比較して示します。
| アクション | Scope | キー型 |
|---|---|---|
| 関数の実行 | 特定の関数 | 機能 |
| 関数の実行 | すべての関数 | 関数またはホスト |
admin エンドポイントの呼び出し |
関数アプリ | マスター |
| Durable Task 拡張機能 API の呼び出し | 関数アプリ* | システム |
| 拡張機能固有のウェブフック(内部)を呼び出す | 関数アプリ* | システム |
*拡張機能によって決定されるスコープ。
アクセスキーの要件
Functions 内では、アクセス キーはランダムに生成される 32 バイトの配列で、URL セーフな base-64 文字列としてエンコードされます。 自分でアクセスキーを生成してFunctionsで使うことはできますが、代わりにデフォルトのアクセスキー生成プロセスを使いましょう。
関数によって生成されるアクセス キーには、アクセス キーの種類と Azure Functions によって生成されたアクセス キーを示す特別な署名とチェックサムの値が含まれます。 これらのキー内の追加要素により、セキュリティスキャンやその他の自動化プロセス中にこれらの秘密の出所を特定することが容易になります。
Functionsにキーを生成させるには、キーを生成するために使えるAPIにキー value を提供しないでください。
アクセスキーの保管
Azureの関数アプリはキーを保存し、静止状態で暗号化しています。 デフォルトでは、 AzureWebJobsStorage 設定は提供されたアカウント内のBlobストレージコンテナに鍵を保存します。
AzureWebJobsSecretStorageType設定を使ってこのデフォルトの動作を上書きし、キーを以下の代替場所のいずれかに保存してください:
| 場所 | 値 | 説明 |
|---|---|---|
| 2 つ目のストレージ アカウント | blob |
Functionsランタイムで使うものとは異なるストレージアカウントに鍵をBlobストレージに保存します。 使用される特定のアカウントとコンテナーは、 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 クラスターに展開すると、この値が自動的に生成されます。
不変シークレット はサポートされていません。 |
| Azure Container Apps のシークレット | containerapps |
キーは、Container Apps の内部シークレット管理システムである Azure Container Apps シークレット ストアに格納されます。 関数アプリが Azure Container Apps にデプロイされている場合にのみサポートされます。 詳細は「 コンテナアプリの秘密ストアの設定」を参照してください。 |
キーストレージにKey Vaultを使う場合、必要なアプリ設定は、システム割り当て管理ID、ユーザー割り当て管理ID、またはアプリの登録など、Key Vault認証方法によって異なります。
| 設定の名前 | システム割り当て | ユーザーによって割り当てられた | アプリの登録 |
|---|---|---|---|
AzureWebJobsSecretStorageKeyVaultUri |
対象 | 対象 | 対象 |
AzureWebJobsSecretStorageKeyVaultClientId |
対象外 | 対象 | 対象 |
AzureWebJobsSecretStorageKeyVaultClientSecret |
対象外 | 対象外 | 対象 |
AzureWebJobsSecretStorageKeyVaultTenantId |
対象外 | 対象外 | 対象 |
Von Bedeutung
シークレットのスコープは、 AzureWebJobsSecretStorageKeyVaultUri 設定を通じて個々の関数アプリには適用されません。 同じ Key Vault を使用するように複数の関数アプリが構成されている場合、同じシークレットが共有され、キーの競合や上書きにつながる可能性があります。 意図しない動作を回避するために、関数アプリごとに個別の Key Vault インスタンスを使用することをお勧めします。
アクセスキーを持つエンドポイントへの通話
HTTPトリガー関数は、関数名を含むURLを使うことで呼び出せます。 関数の認可レベルを anonymous以外の値に設定した場合、リクエスト時にアクセスキーも提供しなければなりません。 アクセスキーは ?code= クエリ文字列またはリクエストヘッダー(x-functions-key)にURLに含めることができます。 詳細については、「アクセス キーの認可」を参照してください。
ランタイム REST API (/admin/ の下) にアクセスするには、_master 要求ヘッダー内にマスター キー (x-functions-key) を指定する必要があります。
管理エンドポイントは、functionsRuntimeAdminIsolationEnabledサイトプロパティを設定することで無効にできます。
関数のアクセス キーを取得する
関数およびホストのキーは、次の Azure Resource Manager API を使用してプログラムで取得できます。
Azure Resource Manager API を呼び出す方法については、「Azure REST API リファレンス」を参照してください。
Note
関数アプリをAzure Container AppsにデプロイしAzureWebJobsSecretStorageType=ContainerAppsを使う場合、ファンクションキーを取得するにはコンテナアプリ固有の方法を使わなければなりません。 詳細については、コンテナアプリのドキュメントにある 「アクセスキーの管理 」をご覧ください。
これらの方法を使って、REST APIを使わずにアクセスキーを取得しましょう。
Azureポータルにサインインし、「Function App」を検索して選択してください。
操作する関数アプリを選択します。
左側のメニューで、[ 関数] を展開し、[ アプリ キー] を選択します。
[アプリ キー] ページが表示されます。 このページにはホストキーが表示されており、アプリのあらゆる機能にアクセスすることができます。 システム キーも表示されます。これは、すべての関数アプリ API への管理者レベルのアクセスを、どのユーザーに対しても付与します。
特定の関数用のキーを使用して、最小限の特権を実践することもできます。 関数固有のキーは、特定の HTTP によってトリガーされる関数の [関数キー] タブから取得できます。
ヒント
また、Azure Functions Core Toolsコマンドfunc azure functionapp list-functionsの--show-keysオプションを使って、自分の機能のアクセスキーを取得することもできます。 詳細については、 Azure Functions Core Tools リファレンスを参照してください。
アクセス キーを更新または作成する
アクセス キー値を更新または作成する場合は、その関数を呼び出すすべてのクライアントに更新後のキー値を手動で再配布する必要があります。
関数およびホストのキーは、プログラムで更新する、または次の Azure Resource Manager API を使用して新しく作成することができます。
Azure Resource Manager API を呼び出す方法については、「Azure REST API リファレンス」を参照してください。
次の方法を使用すると、REST API への呼び出しを手動で作成せずに、アクセス キーを取得できます。
Azureポータルにサインインし、「Function App」を検索して選択してください。
操作する関数アプリを選択します。
左側のメニューで、[ 関数] を展開し、[ アプリ キー] を選択します。
[アプリ キー] ページが表示されます。 このページにはホストキーが表示されており、アプリのあらゆる機能にアクセスすることができます。 システム キーも表示されます。これは、すべての関数アプリ API への管理者レベルのアクセスを、どのユーザーに対しても付与します。
更新したいキーの隣にある 「Renew」キー値 を選択し、「 Renew and Saving」を選択してください。
特定の HTTP によってトリガーされる関数の [関数キー] タブ内で関数キーを更新することもできます。
アクセス キーを削除する
関数およびホストのキーは、次の Azure Resource Manager API を使用してプログラムで削除できます。
Azure Resource Manager API を呼び出す方法については、「Azure REST API リファレンス」を参照してください。