Azure SQL DatabaseのTLS 1.2対応は、設定が正しくても「本当にTLS 1.2で接続できているか」が見えづらいのが課題です。Azureポータルで迷いやすい論理サーバーの場所から、最小TLSバージョンの確認、メトリック・監査ログでの実接続の裏取りまで手順をまとめます。
まず結論：確認は「サーバー設定」＋「実接続の裏取り」の2段階
Azure SQL DatabaseをTLS 1.2に対応させるとき、やるべきことは大きく2つです。
- サーバー側で「TLS 1.2未満を拒否する」設定になっているか（= 最小TLSバージョンの確認）
- 実際の接続がTLS 1.2で行われているか（= メトリックや監査ログで裏取り）
「設定はしたはずだけど自信がない」という不安は、だいたいこの2つのどこかが曖昧なときに起きます。
| 確認レベル | 目的 | 見る場所 | 非エンジニア向け | 安心感 |
|---|---|---|---|---|
| 最低限 | サーバーがTLS 1.2未満を拒否する状態か | 論理サーバーの「最小TLSバージョン」 | ◎ | 中 |
| 現実的におすすめ | 今どのTLSで接続が来ているかを俯瞰する | データベースの「メトリック（Successful connections）」 | ○ | 高 |
| 最も確実 | どのクライアントがどのTLSで接続したかを特定する | 監査（Auditing）ログ（Log Analytics / Storage） | △（設定は可能、解析は支援推奨） | 最高 |
「TLS 1.2にアップグレード」の誤解が生まれやすいポイント
Azure SQL Databaseでよくある誤解は「DBをアップグレードする」感覚でTLSを捉えてしまうことです。実際には、論理サーバー（logical server）で最小TLSバージョンを指定し、古いTLSでの接続を拒否するのが中心です。
- 最小TLSバージョンをTLS 1.2にすると、TLS 1.2/1.3の接続は通り、TLS 1.1以下は拒否されます。
- 設定は即時反映されるため、古いクライアントが混ざっていると接続断が起きます。
- Azure SQL Databaseでは最小TLSとしてTLS 1.2が下限で、TLS 1.0/1.1は廃止扱いです。
- 一度「最小TLSバージョン」を強制すると、元の“既定（全部許可）”に戻せない点に注意が必要です（運用上は「影響が出るか」を先に確認してから強制がおすすめ）。
論理サーバー（logical server）が分かりづらい理由と、迷わない見つけ方
Azure SQL Databaseは、ポータル上で「SQL データベース（子）」と「SQL サーバー（親＝論理サーバー）」が別リソースとして表示されます。TLSの最小バージョンは論理サーバー側で設定します。
| よく見る表示 | 実体 | TLS最小バージョン設定 | 迷いやすい点 |
|---|---|---|---|
| SQL データベース （SQL databases） | 単一DB/エラスティックプール配下のDB | ×（基本はサーバー側） | 「ここで設定できそう」に見える |
| SQL サーバー （SQL servers） | 論理サーバー（logical server） | ◎（ここが本丸） | 「どれが対象のサーバー？」となりがち |
迷わない最短ルート：データベースの概要から「サーバー名」をクリック
- Azureポータル上部の検索で「SQL データベース」を開く
- 対象のDBをクリックして「概要」を開く
- 概要内にあるサーバー名（リンク）をクリックする
- 遷移先が「論理サーバー」の画面
「サーバー名のリンクを踏む」動線に気付けると、論理サーバー迷子になりづらくなります。
別ルート：検索ボックスで「SQL サーバー」を検索して直接開く
複数DBを運用している場合、DBから辿るよりSQL サーバー（論理サーバー）を先に開く方が早いことがあります。特に「同じ論理サーバーに複数DBが載っている」構成では、サーバー側の設定が一括で効きます。
Azureポータルで「最小TLSバージョン」をTLS 1.2にする（確認・設定）
ここが最重要ポイントです。Azure SQL Databaseの最小TLSバージョンは、論理サーバーの「Networking（ネットワーク）」にあります。
- Azureポータルにサインイン
- 対象の論理サーバーを開く（前章の手順でOK）
- 左メニューで Security（セキュリティ） 配下の Networking（ネットワーク） を選択
- 画面上部のタブから Connectivity（接続性） を開く
- Minimum TLS Version（最小TLSバージョン） を 1.2 にする
- Save（保存） をクリック
この手順自体はMicrosoft Learnにも掲載されている、いわば公式の導線です。
設定後に知っておくべき「影響」
- 設定は即時反映されるため、TLS 1.2未満で接続していたクライアントは切断・接続失敗になる可能性があります。
- TLSバージョンが原因で弾かれると、Error 47072（invalid TLS version） で失敗するケースがあります。
- また、最低TLSを1.3に上げた場合は、ドライバーやOSによっては接続が崩れることがあるため、むやみに上げずに検証が推奨です。
「保存したのに不安」が残るときのチェックポイント
| よくある不安 | 原因になりやすいこと | 確認のコツ |
|---|---|---|
| 設定した画面が本当に正しい場所か分からない | データベース側を見ている／別サーバーを見ている | DB概要の「サーバー名リンク」から開き直す |
| 設定が反映されていない気がする | 保存（Save）忘れ／権限不足で保存できていない | 保存後にページ更新し、値が保持されるか確認 |
| そもそもプルダウンが少ない／選べない | 既にTLS 1.2以上しか選べない状態 | 表示が「1.2固定」でも、目的（1.2以上）を満たす |
非エンジニアでもできる：メトリックで「TLS 1.0/1.1の接続が来ていない」ことを確認
「設定値が1.2」だけだと、実際に誰かがTLS 1.0/1.1で接続しようとしていないかは分かりません。ここで便利なのが、データベースのメトリック（監視）です。Microsoft Learnでも、メトリックでTLS 1.0/1.1の接続を確認できる旨が案内されています。
- 対象のSQL データベースを開く
- 左メニューの Monitoring（監視） → Metrics（メトリック） を開く
- メトリックで Successful connections（成功接続）を選択
- フィルターや分割（Split）で TLS version を指定し、1.0 と 1.1 が出ていないかを見る
ここでTLS 1.0/1.1の成功接続がゼロなら、「少なくとも直近の実運用で古いTLSでつながっているクライアントは見当たらない」という判断材料になります。
メトリック確認の注意点
- 確認期間（過去何時間・何日）を短くすると、たまたま現れないだけの可能性があります。
- 「成功接続」だけでなく、「失敗接続」系のメトリックも合わせて見ると、古いTLSで弾かれていないか推測しやすくなります。
最も確実：監査（Auditing）ログで「どのクライアントがどのTLSで接続したか」を裏取り
「本当にTLS 1.2で接続できているか」を強い根拠で示したい場合、監査ログが最も確実です。Azure SQL Auditingでは、接続に使われたTLSバージョンを示す情報（例：client_tls_version_n）を確認できることが案内されています。
監査ログの出力先は3つ（迷ったらLog Analytics）
Auditingは、Log Analytics / Event Hubs / Azure Storage に出力できます。
| 出力先 | 向いている用途 | メリット | 注意点 |
|---|---|---|---|
| Log Analytics | すぐ検索・集計して調べたい | 画面で検索しやすい／KQLで集計できる | ログ量に応じてコストが増える |
| Azure Storage | ログを保管したい／後からまとめて解析 | 長期保存に向く／ファイル単位で扱える | 見るには手順が増える（Storage Explorer等） |
| Event Hubs | SIEM連携・リアルタイム基盤へ流したい | ストリーミングしやすい | 受け側の構築が必要 |
Auditingを有効化する手順（ポータル）
Auditingはサーバー単位／DB単位で設定できます。サーバー単位にすると、その論理サーバー配下のDBに広く効きます。
- 対象のSQL データベースまたは論理サーバーを開く
- Security（セキュリティ） → Auditing（監査） を開く
- Auditing を ON にする
- 出力先に Log Analytics または Storage を選んで設定
- Save（保存）
Log AnalyticsやEvent Hubsに監査ログを送る構成では、裏側で診断設定（Diagnostic Setting）が作られ、SQLSecurityAuditEventsカテゴリが有効になります。
Log Analyticsで監査ログを見る方法
ポータル上では、DBのAuditingページ上部から「View audit logs」で直近データを確認し、Log Analyticsビューへ遷移して時間範囲や検索をカスタマイズできます。
また、監査ログはLog Analytics側では AzureDiagnostics テーブルに入り、カテゴリが SQLSecurityAuditEvents になるのが一般的です。
KQL例：TLS 1.2未満の接続があるかを探す（壊れにくい書き方）
ワークスペースや設定の違いで列名が少し変わることがあります。そこで、column_ifexists() を使い、列が無い場合でもクエリが落ちにくい形にします。
AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| extend ClientTlsVersion = toint(column_ifexists("client_tls_version_n", int(null)))
| extend ClientTlsName = tostring(column_ifexists("client_tls_version_name_s", ""))
| project TimeGenerated,
Database = tostring(column_ifexists("database_name_s","")),
Login = tostring(column_ifexists("server_principal_name_s","")),
App = tostring(column_ifexists("application_name_s","")),
ClientIP = tostring(column_ifexists("client_ip_s","")),
ClientTlsVersion,
ClientTlsName
| where isempty(ClientTlsName) == false or isnotnull(ClientTlsVersion)
| order by TimeGenerated desc上のクエリでTLSバージョン情報が取れたら、次に「TLS 1.0/1.1が混ざっていないか」を絞り込みます。
AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| extend v = toint(column_ifexists("client_tls_version_n", int(null)))
| extend name = tostring(column_ifexists("client_tls_version_name_s", ""))
| where name in ("TLS 1.0","TLS 1.1") or v in (769, 770)
| project TimeGenerated,
Database = tostring(column_ifexists("database_name_s","")),
Login = tostring(column_ifexists("server_principal_name_s","")),
App = tostring(column_ifexists("application_name_s","")),
ClientIP = tostring(column_ifexists("client_ip_s","")),
v,
name
| order by TimeGenerated desc数値の 769/770/771/772 はTLSのバージョンを10進表現した値として扱われることがあり、771がTLS 1.2、770がTLS 1.1、769がTLS 1.0の目安になります。
| 表記 | 意味 | 判断 |
|---|---|---|
| 771 / TLS 1.2 | TLS 1.2で接続 | OK |
| 772 / TLS 1.3 | TLS 1.3で接続 | OK（ただし強制は要検証） |
| 770 / TLS 1.1 | TLS 1.1で接続 | 要対応 |
| 769 / TLS 1.0 | TLS 1.0で接続 | 要対応 |
Storage（監査ファイル）で確認したい場合
AuditingをStorageに出している場合、ログは sqldbauditlogs コンテナ配下に .xel 形式で保存されます。
Azureポータル上の「View audit logs」でも確認できますし、より踏み込むなら sys.fn_get_audit_file でテーブル形式にして検索できます。
-- 例：監査ファイルからTLSバージョン関連を探す（パスは環境に合わせて）
SELECT TOP 200
event_time,
action_name,
server_principal_name,
client_ip,
client_tls_version_name,
statement
FROM sys.fn_get_audit_file(
'https://<storage-account>.blob.core.windows.net/sqldbauditlogs/<ServerName>/<DatabaseName>/*/*.xel',
NULL,
NULL
)
WHERE action_name LIKE '%AUTHENTICATION%'
ORDER BY event_time DESC;上の例のように、ログイン系（AUTHENTICATION）のイベントを中心に追うと、「どの接続がどのTLSだったか」を追いやすくなります。
大量のサーバーがあるなら：Azure Resource Graphで「最小TLSが1.2ではない」サーバーを棚卸し
「うちはサーバーが複数ある」「設定漏れが怖い」という場合、Azure Resource Graphで棚卸しをすると効率が上がります。Microsoftのブログでも、最小TLS設定をResource Graphで確認する例が紹介されています。
// Azure Resource Graph（例）：最小TLSが1.2ではないSQLサーバーを抽出
resources
| where type == 'microsoft.sql/servers'
| where properties.minimalTlsVersion != "1.2"
| project subscriptionId, resourceGroup, name, minimalTlsVersion = properties.minimalTlsVersionこの棚卸し結果と、実接続（メトリック／監査ログ）の結果をセットで持つと、「設定も実態もOK」を説明しやすくなります。
クライアント側の注意点：サーバーを1.2にしても“古い接続ツール”は止まる
サーバー側の最小TLSを1.2にしても、クライアント（アプリや管理ツール）のTLS対応が弱いと、当然つながりません。特に古いODBC/OLE DB/旧ADO系を使っている環境では注意が必要です。SQL Server向けの公式情報でも、TLS 1.2対応のためにクライアントドライバー更新が重要であることが整理されています。
| 接続元 | 見直すポイント | よくある落とし穴 |
|---|---|---|
| Windowsサーバー上の業務アプリ | OS更新、.NET/ランタイム、利用ドライバー | OSは新しいのに、ドライバーが古い |
| SSMSなどの管理ツール | ツール自体の更新 | 管理者PCだけ古くて接続できない |
| Javaアプリ（JDBC） | JDKのTLS設定、JDBCドライバー | 古いJDKでTLS 1.2が無効になっている |
| Linuxコンテナ/VM | OpenSSL/CA証明書、ドライバー、OS | ベースイメージが古くTLS 1.2が不安定 |
「接続テスト」で運用影響を最小にする考え方
- 本番でいきなり強制するのではなく、可能ならステージングで最小TLS 1.2を適用し、主要アプリの接続確認をしてから本番へ。
- 本番で切り替える場合は、切替直後に「接続エラー（47072など）」が出ていないか、アプリの監視と合わせて見る。
よくある質問（現場で詰まりやすいポイント）
Q：論理サーバーが見つからない。SQL Databaseしか出てこない
A：DBの概要にある「サーバー名」のリンクから辿るのが一番確実です。それでも見えない場合は、権限（ロール）がDBのみ付与されていてサーバーが見えていない可能性があります。社内のAzure管理者に「対象サーバーのNetworking（Connectivity）を見られる権限が必要」と伝えると話が早いです。
Q：最小TLSバージョンを1.2にしたのに、外部ツールで調べると他のTLSが出る
A：最小TLSの強制はアプリケーション層で行われ、プロトコル層での単純なスキャンでは「最小以外も出る」ように見える場合がある、という注意が案内されています。混乱しやすいので、メトリックや監査ログでの確認を優先するのが安全です。
Q：非エンジニアとして最低限どこまで確認すればよい？
A：次の2点ができれば、説明可能なレベルに持っていけます。
- 論理サーバーの「最小TLSバージョン」が1.2になっていることをポータルで確認（スクリーンショット保管推奨）。
- メトリックでTLS 1.0/1.1の接続が出ていないことを確認（期間はできれば数日～1週間程度）。
さらに厳密にやるなら、監査ログで「どのクライアントがTLS 1.0/1.1か」を抽出し、該当システムの改修につなげます。
そのまま使える：社内報告向け「TLS 1.2対応」チェックシート
| 項目 | 確認方法 | 結果の書き方例 |
|---|---|---|
| 最小TLSバージョン | 論理サーバー → Networking → Connectivity → Minimum TLS Version | 「Minimum TLS Version = 1.2 を確認」 |
| TLS 1.0/1.1の実接続有無 | DBメトリック（Successful connections）でTLS 1.0/1.1をフィルタ | 「直近7日でTLS 1.0/1.1の成功接続は検出されず」 |
| 必要に応じた裏取り | Auditingログ（Log Analytics/Storage）でclient TLSを抽出 | 「監査ログ上もTLS 1.0/1.1の接続なし」 |
| 影響把握 | アプリ側のエラーログ、接続失敗（47072等） | 「切替後の接続エラー増加なし」 |
Azure SQL DatabaseのTLS 1.2対応は、論理サーバーの設定だけで終わらせず、実接続（メトリック／監査ログ）で裏取りすることで、安心して「対応完了」と言える状態になります。
コメント