Azure Functionsのアクセスキーは、HTTPトリガー関数を呼び出すための共有シークレットです。今回まず押さえるべき結論は、アクセスキーの仕組みそのものが突然置き換わるわけではなく、キーの種類、保存先、取得・更新方法、特にAzure Container Appsでのキー保存方法を管理者と開発者が明確に確認すべきという点です。
「Work with access keys in Azure Functions」は、Azure Functionsのアクセスキーをどう取得し、どう更新し、HTTPエンドポイントの呼び出し時にどう使うかを整理した公式情報です。運用環境では「関数キーを付ければ安全」と考えるのではなく、公開範囲、呼び出し元、キーの保存先、ローテーション手順まで含めて設計する必要があります。Microsoft Learnでも、アクセスキーは不要なアクセスを軽減する手段の一つであり、公開クライアント向けにはApp Service認証、API Management、仮想ネットワーク、分離環境なども検討すべきと説明されています。 (Microsoft Learn)
Azure Functionsの「Work with access keys」は何を整理した情報か
この公式情報で整理されているのは、Azure FunctionsのHTTPトリガー関数で使うアクセスキーの扱いです。主な対象は、AuthorizationLevel.Function や AuthorizationLevel.Admin を使っているHTTPトリガー関数、Webhook受信、バックエンド間通信、Durable FunctionsやEvent Gridなどの拡張機能を含む構成です。
実務上の確認ポイントは次の4つです。
| 確認ポイント | 管理者・開発者が見るべき内容 |
|---|---|
| キーの種類 | Function、Host、Master、Systemの違いを理解する |
| 呼び出し方法 | ?code= か x-functions-key でキーを渡しているか |
| 保存先 | Blob Storage、Key Vault、Kubernetes、Azure Container Apps secretsなどの設定を確認する |
| 更新・削除 | キー更新後に呼び出し元へ安全に再配布できるか |
特に重要なのは、アクセスキーが「ユーザー単位の認証」ではなく「共有シークレット」である点です。誰がそのキーを使ったかを細かく識別する仕組みではないため、ユーザーごとの認可、監査、権限分離が必要なAPIではMicrosoft Entra ID、OAuth 2.0、API Managementなどを組み合わせて設計するべきです。
アクセスキーの基本：HTTPトリガーの認可を支える共有シークレット
Azure FunctionsのHTTPトリガーでは、認可レベルによってアクセスキーが必要かどうかが変わります。公式ドキュメントでは、HTTPトリガーの認可レベルとして anonymous、function、admin が説明されています。anonymous はキー不要、function は関数キーまたはホストキーが必要、admin はマスターキーが必要です。明示的に設定しない場合の既定値はモデルや言語により異なるため、コードや function.json の authLevel を確認することが大切です。 (Microsoft Learn)
| 認可レベル | キー要否 | 主な用途 | 注意点 |
|---|---|---|---|
anonymous | 不要 | 公開Webhook、ヘルスチェック、一時的な検証 | 誰でも呼び出せるため、本番利用では別の制御が必要 |
function | 必要 | 一般的なHTTPトリガー、バックエンド間通信 | キーの漏えい・ローテーション対策が必要 |
admin | マスターキーが必要 | 管理系API、ランタイムREST API | 最小権限の観点では通常の呼び出しに使わない |
関数を呼び出すとき、アクセスキーはURLの ?code=<API_KEY> クエリ文字列、またはHTTPヘッダーの x-functions-key に指定できます。プログラムから呼び出す場合は、URLにキーを含めるとログや履歴に残りやすいため、可能であれば x-functions-key ヘッダーを使う方が扱いやすくなります。公式情報でも、この2つの指定方法が案内されています。 (Microsoft Learn)
curl "https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>" \
-H "x-functions-key: <FUNCTION_KEY>"4種類のアクセスキーを用途で使い分ける
Azure Functionsのアクセスキーは、スコープと権限によって種類が分かれます。ここを誤ると、特定の関数だけを呼び出せばよいクライアントに、関数アプリ全体を呼び出せるホストキーを渡してしまう、といった過剰権限が起きます。
| キーの種類 | スコープ | 使う場面 | 運用上の判断基準 |
|---|---|---|---|
| Function key | 特定の関数 | 1つのHTTP関数だけを呼び出すクライアント | 最小権限を重視するなら基本はこちら |
| Host key | 関数アプリ全体 | 同じアプリ内の複数関数を呼び出す内部サービス | 影響範囲が広いため配布先を限定する |
| Master key | 関数アプリ全体と管理API | /admin/ 配下の管理API呼び出し | 第三者やクライアントアプリへ配布しない |
| System key | 拡張機能ごと | Event Grid、Durable Functionsなど | 拡張機能が管理するため、手動運用を前提にしない |
公式情報では、Function keyは特定の関数エンドポイント、Host keyは関数アプリ内のすべての関数エンドポイント、Master keyはランタイムREST APIへの管理アクセスも提供する特別なキー、System keyは拡張機能固有のエンドポイント向けと説明されています。さらに、同じ名前のFunction keyとHost keyがある場合はFunction keyが優先されます。 (Microsoft Learn)
2026年5月時点で特に注意したい変更点：Azure Container Appsでのキー保存
2026年5月時点で実務上とくに確認したいのは、Azure Container Apps上でAzure Functionsを動かす場合のホストキー保存です。関連する公式情報では、Container AppsのFunctionsホストキー保存先として、Container Apps secret store、Azure Key Vault、Azure Blob Storageを選択できること、またContainer Apps secret storeではホストがキーを自動生成せず、Container Apps secretsとしてキーを用意してボリュームマウントする必要があることが説明されています。 (Microsoft Learn)
| 保存先 | 設定値の例 | キー自動生成 | 向いている構成 |
|---|---|---|---|
| Container Apps secret store | containerapp | しない | Azure Container Apps上の多くのFunctions構成 |
| Azure Key Vault | keyvault | 手動トリガーが必要 | 監査、統制、集中管理を重視する環境 |
| Azure Blob Storage | blob | する | 既存のAzureWebJobsStorageを使うレガシー構成 |
Container Apps secret storeを使う場合、Functionsホストは /run/secrets/functions-keys/ にマウントされたファイルからキーを読み取ります。ここで失敗しやすいのが、Container Appsのシークレット名は小文字英数字とハイフンを使う一方、Functionsホストが期待するファイル名は host.master や host.function.default のようにドット区切りである点です。公式情報では、secretRef: host-master に対して path: host.master を明示する必要があり、自動変換は行われないと説明されています。 (Microsoft Learn)
Container Appsで最低限必要な設定例
Container Apps secret storeを使う場合は、まず保存先を設定します。
az containerapp update \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--set-env-vars "AzureWebJobsSecretStorageType=containerapp"次に、少なくともマスターキーと既定のホストキーをContainer Apps secretsとして作成します。
MASTER_KEY=$(openssl rand -hex 32)
HOST_DEFAULT_KEY=$(openssl rand -hex 32)
az containerapp secret set \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--secrets "host-master=$MASTER_KEY" "host-function-default=$HOST_DEFAULT_KEY"そのうえで、シークレットボリュームを /run/secrets/functions-keys/ にマウントし、host-master は host.master、host-function-default は host.function.default のように、Functionsホストが期待するパスへ明示的に対応付けます。キーを更新した場合はContainer Apps secretを更新し、対象リビジョンを再起動して反映を確認します。 (Microsoft Learn)
通常のAzure Functionsで確認すべきキー保存設定
通常のAzure Functionsでは、アクセスキーは関数アプリの一部としてAzureに保存され、既定では AzureWebJobsStorage で指定されたストレージアカウントのBlob Storageコンテナーに保存されます。AzureWebJobsSecretStorageType を使うことで、別のBlob Storage、Azure Key Vault、ファイルシステム、Kubernetes Secrets、Azure Container Apps secretsなどに変更できます。 (Microsoft Learn)
運用で見直すべき設定は次の通りです。
| 設定・項目 | 確認内容 | 判断基準 |
|---|---|---|
AzureWebJobsSecretStorageType | キー保存先が意図した値か | 既定のBlobでよいか、Key VaultやContainer Apps secretsにすべきか |
AzureWebJobsStorage | 既定のキー保存先として使われていないか | ストレージアカウントの権限が広すぎないか確認する |
AzureWebJobsSecretStorageKeyVaultUri | Key Vault保存時の参照先 | 複数Function Appで同じKey Vaultを共有していないか |
functionsRuntimeAdminIsolationEnabled | /admin/ エンドポイントを無効化するか | 管理APIを使わない本番環境では有効化を検討する |
| HTTPS/TLS | HTTP接続が許可されていないか | 本番ではHTTPS強制とTLS設定を確認する |
Key Vaultをアクセスキー保存先に使う場合は、複数のFunction Appで同じKey Vaultを共有すると、シークレットの衝突や上書きにつながる可能性があります。公式情報でも、意図しない挙動を避けるため、関数アプリごとに個別のKey Vaultインスタンスを使うことが推奨されています。 (Microsoft Learn)
また、/admin/ 配下のランタイム管理APIは、既定ではマスターキーを提示したリクエストを受け付けます。functionsRuntimeAdminIsolationEnabled を true にすると、マスターキーがあっても /admin/ エンドポイントにアクセスできなくなります。管理APIを使わない本番環境では、攻撃面を減らす設定として検討する価値があります。 (Microsoft Learn)
アクセスキーの取得・更新・削除で押さえる実務手順
アクセスキーはAzure portal、Azure CLI、Azure PowerShell、Azure Resource Manager APIなどで取得・更新できます。公式情報では、Azure CLIで既定のホストキーを取得する例として、次のコマンドが紹介されています。出力は機密情報なので、ログやCI/CDの標準出力に残さないよう注意が必要です。 (Microsoft Learn)
az functionapp keys list \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--query functionKeys.default \
--output tsvキーを更新または新規作成した場合、そのキーを使って関数を呼び出すすべてのクライアントに、更新後のキー値を安全に再配布する必要があります。公式情報でも、更新・作成後のキー値は手動で再配布が必要と説明されています。 (Microsoft Learn)
安全にローテーションするなら、いきなり既定キーを更新するより、次の流れが現実的です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 新しいカスタムキーを作成 | 既存クライアントを止めずに新旧キーを並行利用する |
| 2 | 呼び出し元の設定を新キーへ変更 | アプリ、Webhook、API Gateway、CI/CD変数を更新する |
| 3 | Application Insightsやログで成功を確認 | 旧キー利用が残っていないか確認する |
| 4 | 旧キーを削除または更新 | 漏えいリスクを減らす |
特にWebhookや外部SaaSにFunction URLを登録している場合、URL末尾の ?code= を差し替え忘れると、更新直後から 401 Unauthorized が発生します。外部サービス側にヘッダー指定機能がない場合は、Function URL全体を再登録する必要があります。
移行・展開時に失敗しやすいポイント
anonymous から function に変えると呼び出し元の変更が必要
開発中に AuthorizationLevel.Anonymous で動かしていたHTTP関数を、本番前に AuthorizationLevel.Function へ変更するケースはよくあります。この場合、エンドポイントのコードだけでなく、呼び出し元がアクセスキーを渡すように変更されているかを確認してください。Azure上では authLevel が適用され、キーなしのリクエストは拒否されます。なお、ローカル実行時は指定した認可レベルにかかわらず認可が無効化されるため、ローカルテストだけで本番の認可挙動を判断しない方が安全です。 (Microsoft Learn)
マスターキーを通常のAPI呼び出しに使わない
マスターキーは管理者レベルの権限を持つため、通常のHTTP関数呼び出しに使うべきではありません。外部サービスやモバイルアプリ、フロントエンドにマスターキーを配布すると、漏えい時の影響が関数アプリ全体に及びます。特定の関数だけを呼び出すならFunction key、複数の関数をまとめて呼び出す内部サービスならHost keyを使い、マスターキーは厳格に分離してください。
URLにキーを含める場合はログ露出に注意する
?code= は簡単に使えますが、URLはリバースプロキシ、アプリケーションログ、ブラウザー履歴、監視ツールに残る可能性があります。サーバー間通信や自社アプリからの呼び出しでは、x-functions-key ヘッダーの利用を優先すると、ログ管理とマスキングがしやすくなります。
Container Appsでfilesを使わない
Azure Container Apps上ではファイルシステムが一時的な性質を持つため、AzureWebJobsSecretStorageType=files によるキー保存は避けるべきです。公式情報では、スケールゼロ、再起動、新しいリビジョンのデプロイ時にキーが失われる可能性があるため、Container Apps secret store、Key Vault、Blob Storageのいずれかを使うよう警告されています。 (Microsoft Learn)
Functions生成キーと手動キーの違いを理解する
通常のAzure Functionsでは、アクセスキーはランダムな32バイト配列をURLセーフなBase64文字列としてエンコードしたもので、Functionsが生成したキーには種類や生成元を示す署名・チェックサム値が含まれます。公式情報では、キー生成APIに value を指定せず、Functionsにキーを生成させることが推奨されています。 (Microsoft Learn)
一方、Container Apps secret storeではホストがキーを自動生成しないため、公式手順に従ってランダムな値をContainer Apps secretsとして用意します。この違いを理解せずに「どの環境でもFunctionsが自動で作るはず」と考えると、Container Apps移行時にキーが見つからない、呼び出しが認可されない、といった問題につながります。
管理者と開発者が今すぐ確認すべきチェックリスト
| 対象 | 確認すること | 対応の目安 |
|---|---|---|
| HTTPトリガー | authLevel が意図通りか | 本番公開APIで anonymous のままになっていないか確認 |
| 呼び出し元 | ?code= または x-functions-key を渡しているか | 可能ならヘッダー指定へ寄せる |
| キー種類 | Function keyとHost keyを使い分けているか | 外部連携には最小スコープのFunction keyを優先 |
| マスターキー | アプリや外部サービスに配布していないか | 管理用途以外では使わない |
| 保存先 | AzureWebJobsSecretStorageType が適切か | Container Appsでは個別手順を確認 |
| Key Vault | 複数Function Appで共有していないか | 関数アプリごとに分離を検討 |
| Container Apps | secret名とvolume mount pathが一致しているか | host-master → host.master のように明示 |
| ローテーション | 更新後の再配布手順があるか | 新旧キー併用期間を作る |
| CI/CD | キー値をログ出力していないか | 出力のマスク、Secret変数化を徹底 |
| 管理API | /admin/ エンドポイントが必要か | 不要なら functionsRuntimeAdminIsolationEnabled を検討 |
アクセスキーだけに頼らない設計にする
Azure Functionsのアクセスキーは便利ですが、万能な認証基盤ではありません。共有シークレットである以上、キーを持っている相手を「誰か」までは識別できず、流出時にはそのキーのスコープ内で呼び出しが可能になります。
次のようなケースでは、アクセスキーだけで済ませない設計を検討してください。
| ケース | 推奨される追加対策 |
|---|---|
| ブラウザーやモバイルアプリから直接呼び出す | Microsoft Entra ID、OAuth 2.0、API Managementを使う |
| ユーザーごとの権限判定が必要 | アプリ側で認証・認可を実装する |
| 社外公開APIとして提供する | APIMで認証、レート制限、監査ログを設計する |
| 社内ネットワークからのみ呼び出す | VNet統合、Private Endpoint、IP制限を組み合わせる |
| 管理APIを使わない | /admin/ エンドポイントの分離・無効化を検討する |
Microsoft Learnのセキュリティガイドでも、HTTPSの強制、App Service認証、API Management、ネットワーク分離などがAzure Functionsを保護する選択肢として案内されています。特にHTTPSについては、既定ではHTTPとHTTPSの両方で接続できるため、HTTPをHTTPSへリダイレクトし、TLSバージョンも確認することが推奨されています。 (Microsoft Learn)
まずは棚卸し、次に保存先とローテーションを決める
今回の「Work with access keys in Azure Functions」で確認すべきポイントは、単に「キーの取得方法を知る」ことではありません。実務では、どの関数がどの認可レベルで公開され、どの種類のキーを誰に配布し、どこに保存し、どの手順で更新するかまでを決める必要があります。
まずはFunction AppごとにHTTPトリガーを棚卸しし、anonymous、function、admin の設定を確認してください。次に、Function keyとHost keyの使い分け、マスターキーの保護、AzureWebJobsSecretStorageType の設定、Container AppsやKey Vault利用時の保存先を見直します。最後に、キー更新時の再配布手順をドキュメント化し、CI/CDや監視ログにキーが残らないように整備することが、管理者と開発者の次のアクションです。
コメント