Azure FunctionsでTLS 1.0／TLS 1.1を許可している環境は、2027年5月31日までにTLS 1.2以上へ移行する必要があります。Microsoftの公式情報では、Azure App Service、Azure Functions、Azure Logic Apps Standard、App Service Environmentへの受信接続について、2027年5月31日以降TLS 1.0／TLS 1.1のハンドシェイクを受け付けなくなると案内されています。(Microsoft Learn)
特にAzure Functionsでは、公開API、Webhook、古い業務アプリ、IoT機器、CI/CDからのデプロイ経路が影響を受けやすいポイントです。単にFunction App本体の設定を見るだけでなく、SCM（Kudu）サイト、デプロイスロット、呼び出し元クライアントまで含めて確認することが重要です。
Azure FunctionsのTLS 1.0／TLS 1.1廃止で何が変わるのか
今回の変更は、Azure Functionsそのものの実行モデルやランタイムの廃止ではありません。対象は、Azure Functionsを含むApp Serviceプラットフォームへの受信TLS接続です。
2027年5月31日以降、TLS 1.0またはTLS 1.1でAzure Functionsへ接続しようとするクライアントは、TLSネゴシエーションの段階で接続できなくなります。HTTPトリガー関数のURL、カスタムドメイン、*.azurewebsites.net のエンドポイント、SCM（Kudu）エンドポイントが確認対象です。Microsoft Learnでは、アプリ側の minTlsVersion や scmMinTlsVersion の設定値に関係なく、プラットフォームのフロントエンドでTLS 1.0／1.1の受け入れが停止されると説明されています。(Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 対象サービス | Azure App Service、Azure Functions、Azure Logic Apps Standard、App Service Environment |
| 対象通信 | サービスへの受信接続 |
| 廃止されるTLSバージョン | TLS 1.0、TLS 1.1 |
| 期限 | 2027年5月31日 |
| 推奨対応 | TLS 1.2以上へ移行 |
| Azure Functionsで特に見る設定 | minTlsVersion、scmMinTlsVersion、デプロイスロットの設定 |
重要なのは、「今の設定がTLS 1.0でも動いているから大丈夫」ではない点です。廃止日以降は、古いTLSを受け付ける設定のままにしていても、プラットフォーム側で接続が拒否される可能性があります。
影響を受けるAzure Functionsの典型例
Azure Functionsはサーバーレスで手軽に公開できるため、想定外の古いクライアントから呼び出されていることがあります。特に次のような構成では、期限前の棚卸しが必要です。
| 影響を受けやすい構成 | 確認すべきポイント |
|---|---|
| HTTPトリガーのFunction App | 呼び出し元のアプリ、端末、スクリプトがTLS 1.2以上に対応しているか |
| Webhook受信用のFunction App | SaaSや外部サービス側のTLS対応状況 |
| 古い社内システムから呼び出すAPI | .NET Framework、Java、OS、ミドルウェアのバージョン |
| IoT・組み込み機器からの送信先 | ファームウェアがTLS 1.2以上をサポートしているか |
| CI/CDでFunctionsへデプロイしている環境 | SCM（Kudu）サイトへの接続がTLS 1.2以上か |
| ステージングスロットを使っている環境 | 本番スロットだけでなく各スロットのTLS設定 |
たとえば、Function Appの本番URLは問題なくTLS 1.2でアクセスできても、古いセルフホステッドエージェントが yourapp.scm.azurewebsites.net へTLS 1.0で接続していると、将来デプロイだけが失敗する可能性があります。
Azure Functions管理者が最初に確認すべき設定
Azure Functionsには、TLSに関する設定が大きく2つあります。
| 設定 | 対象 | 見落としやすい影響 |
|---|---|---|
| 最小受信TLSバージョン | Function App本体へのアクセス | HTTPトリガー、API、Webhook、カスタムドメイン |
| SCMの最小受信TLSバージョン | Kudu／デプロイ用エンドポイント | Zip Deploy、ログストリーミング、高度なツール、CI/CD |
Microsoft Learnでは、Azure Functionsを完全に保護するには、サイト本体とSCMの両方をTLS 1.2以上に設定する必要があると説明されています。(Microsoft Learn)
Azureポータルでは、対象のFunction Appを開き、設定 > 構成 > 全般設定から、次の値を確認します。
- 最小受信TLSバージョン
- SCMの最小受信TLSバージョン
どちらか一方だけを変更しても不十分です。特にSCM側は、通常のアプリ動作では気づきにくく、デプロイや運用作業のタイミングで初めて問題化しやすい設定です。
Azure CLIでAzure FunctionsのTLS設定を確認する
複数のFunction Appを管理している場合は、AzureポータルだけでなくAzure CLIで確認すると効率的です。
az functionapp show \
--name <app-name> \
--resource-group <resource-group> \
--query "siteConfig.{siteTls:minTlsVersion, scmTls:scmMinTlsVersion}" \
--output table出力結果で、siteTls と scmTls がどちらも 1.2 以上になっているか確認します。
例として、次のような状態なら対応が必要です。
| siteTls | scmTls | 判断 |
|---|---|---|
| 1.2 | 1.2 | 基本的には廃止要件を満たす |
| 1.0 | 1.2 | Function App本体の受信設定を変更する |
| 1.2 | 1.0 | SCM側の設定を変更する |
| 1.0 | 1.0 | 本体・SCMの両方を変更する |
| 空欄または不明 | 1.2未満の可能性を確認 | ポータルまたはCLIで再確認する |
PowerShellでも確認できますが、Microsoft Learnでは一部のリソース種類で ScmMinTlsVersion が空の値を返す場合があるため、サイトとSCMの両方を確実に確認するにはAzure CLIの利用が案内されています。(Microsoft Learn)
TLS 1.0／TLS 1.1の実トラフィックを確認してから変更する
設定上TLS 1.0／1.1を許可していても、実際には古いTLSの通信が来ていない場合があります。一方で、深夜バッチ、月次処理、古い端末、外部Webhookなど、普段見えにくい通信が残っているケースもあります。
Azureポータルでは、対象のApp Service、Functions、Logic Apps Standardに対して、問題の診断と解決から「最小TLSバージョンチェッカー」を検索し、過去24時間のTLSバージョン別リクエスト概要や、TLS 1.0／1.1を使ったクライアントを確認できます。(Microsoft Learn)
ただし、この検出結果は過去24時間のスナップショットです。次のようなシステムでは、1日分だけで判断しない方が安全です。
| システムの種類 | 確認タイミング |
|---|---|
| 月次締め処理で呼ばれるFunction App | 月末・月初の処理日に確認 |
| 夜間バッチの受け口 | 深夜帯を含めて確認 |
| 外部サービスのWebhook | 実際にイベントが発生するタイミングで確認 |
| IoT機器からの定期送信 | 全拠点・全デバイスが送信する周期を含める |
| 災害時・障害時だけ動く処理 | 設定値とクライアント仕様を別途確認 |
「24時間見て問題なし」ではなく、「業務上発生し得る通信パターンを網羅したか」で判断しましょう。
Azure FunctionsのTLS最小バージョンを1.2以上に変更する手順
クライアントがTLS 1.2以上に対応していることを確認したら、Function App本体とSCMの両方を更新します。Microsoft Learnでは、2027年5月31日より前に、サイトとSCMのTLS最小バージョンを両方とも更新する必要があると案内されています。(Microsoft Learn)
Azureポータルで変更する場合
Azureポータルで作業する場合は、次の流れです。
| 手順 | 操作 |
|---|---|
| 1 | Azureポータルで対象のFunction Appを開く |
| 2 | 左メニューから「設定」>「構成」を開く |
| 3 | 「全般設定」タブを選択する |
| 4 | 「最小受信TLSバージョン」を 1.2 以上に設定する |
| 5 | 「SCMの最小受信TLSバージョン」を 1.2 以上に設定する |
| 6 | 適用して、必要に応じて動作確認する |
TLS 1.3を選べる環境では、より高い最小バージョンとしてTLS 1.3を検討できます。ただし、古いクライアントとの互換性が下がるため、まずは利用者・連携先・運用ツールの対応状況を確認することが前提です。App ServiceではTLS 1.3がサポートされており、TLS 1.2より強化されたセキュリティや高速なハンドシェイクなどの利点が説明されています。(Microsoft Learn)
Azure CLIでFunction App本体を変更する場合
Function App本体の最小TLSバージョンは、次のコマンドで設定できます。
az functionapp config set \
--name <app-name> \
--resource-group <resource-group> \
--min-tls-version 1.2このコマンドはFunction App本体の minTlsVersion を更新します。
SCM側の最小TLSバージョンを変更する場合
SCM側の scmMinTlsVersion は、az functionapp config set のパラメーターだけでは更新できない点に注意が必要です。Microsoft Learnでは、SCMの最小TLSバージョン更新には az resource update を使うよう案内されています。(Microsoft Learn)
az resource update \
--ids "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<app-name>/config/web" \
--set properties.scmMinTlsVersion=1.2本体だけを更新して安心してしまうと、CI/CDやKuduを使った運用経路が残ります。Azure FunctionsのTLS対応では、minTlsVersion と scmMinTlsVersion をセットで扱うのが基本です。
デプロイスロットを使っている場合の注意点
Azure Functionsでデプロイスロットを使っている場合、本番スロットだけを更新しても十分ではありません。Microsoft Learnでは、各デプロイスロットに独立した minTlsVersion と scmMinTlsVersion があるため、スロットごとに確認・更新が必要とされています。(Microsoft Learn)
よくある失敗は次のパターンです。
| 失敗例 | 起きる問題 |
|---|---|
| productionだけTLS 1.2にした | stagingスロットの検証URLが古いTLSを許可したまま残る |
| Function App本体だけ変更した | SCM側へのデプロイ経路が古いTLS設定のままになる |
| スワップ後に確認していない | スロット固有の設定差分に気づきにくい |
| 一部の環境だけ更新した | 開発・検証・本番で挙動が変わる |
本番、ステージング、検証、災害対策用など、すべてのスロットを一覧化し、同じ観点で確認しましょう。
開発者が確認すべきクライアント側のポイント
Azure Functions側をTLS 1.2以上にしても、呼び出し元が古いTLSしか使えない場合は接続できません。開発者は、Function Appを呼び出しているすべてのクライアントを洗い出す必要があります。
特に注意したいのは、次のようなクライアントです。
| クライアント | 確認内容 |
|---|---|
| 古い.NET Frameworkアプリ | OS既定のTLSを使っているか、TLS 1.0を明示指定していないか |
| 古いJavaアプリ | 実行環境がTLS 1.2をネゴシエートできるか |
| PowerShellスクリプト | 古い実行環境でTLS 1.0固定になっていないか |
| curlや独自バッチ | 実行サーバーのOS、OpenSSL、ライブラリのバージョン |
| モバイルアプリ | 古いOSバージョンをサポート対象に含めていないか |
| IoT機器 | ファームウェア更新でTLS 1.2以上に対応できるか |
| 外部SaaSのWebhook | ベンダーがTLS 1.2以上で送信しているか |
特に危険なのは、コード内でTLSバージョンを固定しているケースです。たとえば「古いサーバーに合わせるためにTLS 1.0を指定した」実装が残っていると、Azure Functions側の設定変更後に接続エラーになります。
可能であれば、TLSバージョンをアプリコードで固定せず、OSやランタイムの安全な既定値に任せる設計へ寄せる方が保守しやすくなります。
移行前にやっておきたいテスト
TLS 1.2以上への移行は、設定変更自体は数分で終わることがあります。しかし、実際に安全に切り替えるには、呼び出し元・デプロイ経路・監視まで含めたテストが必要です。
| テスト項目 | 確認すること |
|---|---|
| HTTPトリガーの疎通 | 主要クライアントから正常に呼び出せるか |
| カスタムドメイン経由のアクセス | 独自ドメインでも問題なくTLS 1.2以上で接続できるか |
*.azurewebsites.net 経由のアクセス | 直接URLを使う古いバッチが残っていないか |
| Webhook受信 | 外部サービスからイベントを受け取れるか |
| CI/CD | GitHub Actions、Azure DevOps、Jenkinsなどからデプロイできるか |
| ログ確認 | 接続エラー、TLS関連エラー、5xx増加がないか |
| ロールバック手順 | 期限前の検証段階で問題が出た場合の戻し方を決めているか |
なお、2027年5月31日以降は、TLS 1.0／1.1を許可する設定へ戻しても、プラットフォーム側で受け付けられない前提で考える必要があります。ロールバックはあくまで期限前の検証期間に使える安全策です。
大規模環境ではAzure Policyと廃止ワークブックを使う
Function Appが数個であれば手作業でも確認できますが、複数サブスクリプションや多数のリソースを管理している場合は、Azure PolicyやAzureサービスの廃止ワークブックを使った棚卸しが現実的です。
Microsoft Learnでは、Azureサービスの廃止ワークブックを使うと、受信TLS 1.0／1.1を許可するように構成されているリソースを確認できると説明されています。ただし、このビューは構成ベースであり、実際にTLS 1.0／1.1の通信が発生しているかどうかは、各アプリの最小TLSバージョンチェッカーで確認する必要があります。(Microsoft Learn)
Azure Policyについては、Function AppやFunction Appスロットが最新のTLSバージョンを使用しているか監査する組み込みポリシーが案内されています。一方で、組み込みポリシーは主にメインサイト側の minTlsVersion を監査し、SCM側の scmMinTlsVersion は別途CLIなどで確認する必要がある点に注意してください。(Microsoft Learn)
TLS 1.2とTLS 1.3のどちらを選ぶべきか
今回の廃止対応として最低限必要なのは、TLS 1.2以上への移行です。新しいApp Service系アプリでは、既定の最小TLSバージョンはTLS 1.2であり、この既定値は廃止要件を満たします。(Microsoft Learn)
TLS 1.3を選べる場合は、セキュリティ強化やハンドシェイク高速化のメリットがあります。ただし、すべてのクライアントがTLS 1.3に対応しているとは限りません。特に古い業務端末、組み込み機器、レガシーな連携先がある場合、いきなりTLS 1.3のみを許可すると影響範囲が広がる可能性があります。
実務上は、次の判断が現実的です。
| 方針 | 向いている環境 |
|---|---|
| TLS 1.2を最小にする | 多様なクライアントから呼ばれるAPI、外部連携が多いFunctions |
| TLS 1.3を最小にする | クライアントを完全に管理でき、対応確認が済んでいる社内専用API |
| 段階的にTLS 1.2へ移行し、その後TLS 1.3を検討 | 古い連携先が残っているが、長期的にセキュリティを高めたい環境 |
まずはTLS 1.2以上で確実に廃止対応を完了し、その後にTLS 1.3化を別プロジェクトとして検討すると、障害リスクを抑えやすくなります。
変更時に発生しやすいトラブルと対策
Azure FunctionsのTLS移行で起きやすいトラブルは、Function App側よりも「周辺」にあります。
| トラブル | 原因 | 対策 |
|---|---|---|
| 一部の古いクライアントだけ接続できない | TLS 1.0／1.1しか使えない | OS、ランタイム、ライブラリ、ファームウェアを更新する |
| デプロイだけ失敗する | SCM側のTLS設定やCI/CDエージェントが古い | scmMinTlsVersion とエージェント環境を確認する |
| 本番では動くがステージングで失敗する | デプロイスロットの設定差分 | 全スロットのTLS設定を個別に確認する |
| 外部Webhookが届かない | 送信元サービスのTLS対応状況が不明 | ベンダーにTLS 1.2以上対応を確認する |
| 監査では問題なしだが実通信で失敗 | 監査は構成ベースで実トラフィックを見ていない | 最小TLSバージョンチェッカーやログで実通信を確認する |
設定変更の前に、影響範囲を「Azure Functions単体」ではなく「呼び出し元、デプロイ元、監視、外部サービス」まで広げて洗い出すことが成功のポイントです。
期限までの実務的な進め方
Azure FunctionsのTLS 1.0／TLS 1.1廃止対応は、次の順番で進めると安全です。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | 対象Function App、スロット、SCM設定を一覧化する | minTlsVersion と scmMinTlsVersion の状態が分かる |
| 実通信確認 | 最小TLSバージョンチェッカーやログでTLS 1.0／1.1の利用有無を確認する | 古いTLSを使うクライアントが特定できる |
| クライアント対応 | 古いOS、アプリ、スクリプト、IoT、外部連携を更新する | 主要な呼び出し元がTLS 1.2以上で接続できる |
| 設定変更 | Function App本体とSCMをTLS 1.2以上にする | 本番・スロット・検証環境で設定完了 |
| 動作確認 | API、Webhook、CI/CD、監視を確認する | 通常運用に支障がない |
| 継続監査 | Azure Policyなどで新規・既存リソースを監査する | TLS 1.0／1.1許可設定が再発しない |
廃止日直前にまとめて対応すると、外部ベンダーや古い端末の更新が間に合わない可能性があります。特にIoT機器や取引先システムが関わる場合は、技術対応より調整に時間がかかることがあります。
Azure Functions利用者が今すぐやるべきこと
Azure FunctionsでTLS 1.0／TLS 1.1廃止の影響を避けるには、まず対象Function Appの minTlsVersion と scmMinTlsVersion を確認し、TLS 1.0／1.1を使う実トラフィックがないか調べましょう。
最初の一手はシンプルです。
- すべてのFunction Appとデプロイスロットを一覧化する
minTlsVersionとscmMinTlsVersionを確認する- TLS 1.0／1.1の実トラフィックを確認する
- 呼び出し元クライアントをTLS 1.2以上へ更新する
- Function App本体とSCMの両方をTLS 1.2以上に設定する
今回の変更は、セキュリティ強化として避けられない対応です。2027年5月31日を待たず、検証環境から順にTLS 1.2以上へ切り替え、外部連携やCI/CDを含めて早めに動作確認を済ませておきましょう。
コメント