2026年5月21日に公開・更新情報として扱われている「Microsoft Entra documentation update: Adding support for Entra Service Principal auth」は、Microsoft Entraの認証基盤を大きく変える“強制移行”ではありません。結論から言うと、VS CodeのMSSQL拡張機能とSQL Tools Serviceで、Microsoft Entraのサービスプリンシパル認証を接続方式として扱えるようにする更新です。
管理者や開発者が今すぐ確認すべきことは、サービスプリンシパルのクライアントIDとシークレットを安全に扱えるか、接続先データベースに最小権限のユーザーを作成できているか、利用中のMSSQL拡張機能にこの変更が反映されたバージョンを展開しているかの3点です。特に、今回の実装では証明書認証はサポートされず、クライアントIDとシークレットによる認証が前提になるため、シークレット管理とローテーション設計が重要になります。(GitHub)
Microsoft Entra Service Principal auth更新の要点
今回の更新は、VS CodeでSQL Server、Azure SQL、SQL Database in Fabricなどに接続する際の認証選択肢を広げるものです。GitHub上の公式リポジトリでは、microsoft/vscode-mssqlのPR #22141が2026年5月20日にマージされ、依存先のmicrosoft/sqltoolsserviceのPR #2690は2026年5月19日にマージされています。PRの説明では、ユーザーがサービスプリンシパルのクライアントIDとシークレットを入力して認証できるようにする変更であり、証明書はSSMSと同様にサポートしないとされています。(GitHub)
この更新で押さえるべきポイントは、次のとおりです。
| 観点 | 変更内容 | 実務上の意味 |
|---|---|---|
| 認証方式 | ActiveDirectoryServicePrincipalが接続認証タイプとして追加 | ユーザー個人ではなくアプリケーションIDでSQLに接続できる |
| 入力情報 | クライアントIDとクライアントシークレットを使用 | シークレットの保管・更新・漏えい対策が必須 |
| VS Code側 | 接続ダイアログ、接続プロファイル、認証選択肢、入力検証が更新 | 開発者がGUIからサービスプリンシパル認証を選びやすくなる |
| SQL Tools Service側 | 認証定数、接続文字列ビルダー、接続オプション、単体テストが更新 | 拡張機能のUIだけでなく接続処理そのものが対応する |
| 非対応 | 証明書によるサービスプリンシパル認証は未対応 | 証明書ベース運用を前提にしている組織は代替策を検討する |
ここで重要なのは、「Microsoft Entraのサービスプリンシパル認証そのものが新しく登場した」のではなく、「VS CodeのMSSQL拡張機能でその方式を扱いやすくする更新」という点です。Microsoft.Data.SqlClientでは、サービスプリンシパルのクライアントIDとシークレットを使うActive Directory Service Principal認証モードが以前から提供されています。(Microsoft Learn)
どの環境に影響するのか
影響が大きいのは、VS CodeのMSSQL拡張機能を使ってAzure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics、SQL Database in Fabricなどに接続している開発者・管理者です。特に、SQL認証を禁止または制限し、Microsoft Entra認証を標準にしている組織では、接続手段の選択肢が増えることになります。
Microsoftのドキュメントでは、Azure SQLリソースはMicrosoft Entra IDのサービスプリンシパルやマネージドIDを使ったアプリケーションのプログラムアクセスをサポートすると説明されています。また、Azure SQLにサービスプリンシパルで接続する場合は、アプリ登録、データベース側のユーザー作成、Active Directory Service Principalを指定した接続文字列が必要です。(Microsoft Learn)
一方で、すべての管理者が即日対応しなければならない破壊的変更ではありません。現時点では、主に「MSSQL拡張機能でサービスプリンシパル認証を使いたい利用者」に関係する機能追加として捉えるのが適切です。
対応すべきユーザーと優先度
今回の更新は、組織内の役割によって確認ポイントが変わります。
| 対象者 | 優先度 | 確認すべきこと |
|---|---|---|
| Microsoft Entra管理者 | 高 | アプリ登録、サービスプリンシパル、シークレット有効期限、権限付与の方針 |
| Azure SQL管理者・DBA | 高 | データベースユーザーの作成、ロール付与、最小権限、監査ログ |
| VS Code利用者・開発者 | 中〜高 | MSSQL拡張機能のバージョン、接続プロファイル、ローカルのシークレット保存方法 |
| CI/CD管理者 | 中 | GitHub ActionsやAzure DevOpsでのシークレット管理、ローテーション手順 |
| セキュリティ担当者 | 高 | 個人アカウント接続からアプリケーションID接続へ移行する場合の統制 |
優先度が高いのは、SQLログインを無効化している環境、共有ユーザーで接続している環境、Fabric SQLなど個人認証やSQL認証では運用しづらい環境です。GitHubの機能要望でも、MSSQL拡張機能がSSMSのようにMicrosoft Entraサービスプリンシパル接続をサポートすべきだという要望があり、背景としてFabric SQLがSQLログインをサポートしない点が挙げられていました。(GitHub)
管理者が確認すべきMicrosoft Entra側の設定
アプリ登録とサービスプリンシパルの関係を確認する
サービスプリンシパルは、Microsoft Entraテナント内でアプリケーションを表すIDです。Microsoftの説明では、Microsoft Entra IDでアプリを登録すると、そのアプリ登録に対応するサービスプリンシパルが作成され、サービスプリンシパルに割り当てたロールによってアクセスできるリソースと権限範囲を制御できます。(Microsoft Learn)
確認する項目は次のとおりです。
| 確認項目 | 見る場所 | 注意点 |
|---|---|---|
| アプリケーションID | Microsoft Entra管理センターのアプリ登録 | 接続時に使うのは通常このクライアントID |
| オブジェクトID | エンタープライズアプリケーションまたはアプリ登録 | クライアントIDと混同しやすい |
| クライアントシークレット | 証明書とシークレット | 作成時に表示される値を安全に保管する |
| 有効期限 | シークレットの期限 | 期限切れは突然の接続失敗につながる |
| 所有者 | アプリ登録の所有者 | 退職者や個人だけに依存しない |
特に多い失敗は、接続設定に「オブジェクトID」を入力してしまうケースです。サービスプリンシパル認証で接続文字列やMSSQL拡張機能に入力するのは、基本的にアプリケーションID、つまりクライアントIDです。
シークレット運用を最初に決める
今回のMSSQL拡張機能の変更では、証明書認証はサポート対象外です。そのため、実運用ではクライアントシークレットをどう保管し、誰が更新し、いつローテーションするかを先に決める必要があります。(GitHub)
最低限、次のルールを決めてください。
| ルール | 推奨される運用 |
|---|---|
| 保存場所 | Azure Key Vault、組織のシークレット管理基盤、CI/CDのSecrets機能などを使う |
| ローカル保存 | 個人PCの平文メモ、共有ドキュメント、チャット投稿は禁止 |
| ローテーション | 有効期限の30〜60日前に更新できる運用を作る |
| 権限 | シークレットを閲覧・再作成できる担当者を限定する |
| 棚卸し | 使われていないアプリ登録や古いシークレットを定期的に削除する |
開発用に短期シークレットを発行する場合でも、本番用と同じアプリ登録を使い回すのは避けた方が安全です。開発、検証、本番でサービスプリンシパルを分けると、誤接続や権限過多を抑えやすくなります。
データベース側で確認すべき設定
サービスプリンシパル用のデータベースユーザーを作成する
Microsoft EntraサービスプリンシパルでAzure SQLに接続するには、接続先データベースに対応するユーザーを作成し、必要なロールだけを付与します。Microsoftの例では、アプリ登録の表示名に対応するユーザーをCREATE USER ... FROM EXTERNAL PROVIDERで作成し、必要に応じてdb_datareaderなどのロールを付与しています。(Microsoft Learn)
例として、読み取り専用の接続を許可する場合は次のような流れになります。
CREATE USER [my-sql-app] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-sql-app];ただし、これはあくまで例です。実務では、いきなりdb_ownerを付与しないでください。データ参照だけならdb_datareader、特定テーブルへの更新だけなら対象スキーマやテーブル単位の権限付与を検討します。
権限は「接続目的」から逆算する
サービスプリンシパルは人ではなくアプリケーションIDです。そのため、「誰が使うか」ではなく「何の処理に使うか」で権限を決めます。
| 利用シーン | 推奨される権限設計 |
|---|---|
| 開発者の手動クエリ確認 | 検証DBのみ、読み取り中心、期限付き |
| CI/CDのスキーマ検証 | 対象DB限定、必要なDDL権限のみ |
| レポート生成 | 参照スキーマ限定、書き込み不可 |
| バッチ処理 | 対象テーブルへの実行権限・更新権限に限定 |
| 管理作業 | 通常運用とは別の高権限サービスプリンシパルを用意し、利用を記録 |
重要なのは、サービスプリンシパルを「便利な共有アカウント」にしないことです。共有ユーザーより監査しやすくなる一方、1つのサービスプリンシパルに多くの用途を詰め込むと、侵害時の影響範囲が大きくなります。
開発者が確認すべき接続設定
VS CodeのMSSQL拡張機能で確認すること
PR #22141では、MSSQL拡張機能の接続ダイアログ、接続プロファイル、認証選択肢、入力検証、ローカライズ文字列、Object ExplorerのURI識別処理などが変更対象になっています。つまり、単に接続文字列を受け取るだけでなく、VS Code内の接続体験全体でサービスプリンシパル認証を扱うための変更です。(GitHub)
ただし、PRがマージされたことと、利用中のVS Code拡張機能にすでに反映されていることは同じではありません。GitHubのリリース一覧では、2026年5月4日公開のv1.42.2が確認でき、これは今回のPRマージ日より前のリリースです。組織展開時は、実際に利用するMSSQL拡張機能のリリースノートまたはMarketplaceのバージョンで、サービスプリンシパル認証が含まれているか確認してください。(GitHub)
接続文字列の基本形
SqlClientでMicrosoft Entraサービスプリンシパル認証を使う場合、Microsoftの例ではAuthentication=Active Directory Service Principalを指定し、User IdにアプリID、Passwordにシークレットを指定します。(Microsoft Learn)
Server=tcp:<server-name>.database.windows.net,1433;
Authentication=Active Directory Service Principal;
Encrypt=True;
Database=<database-name>;
User Id=<application-client-id>;
Password=<client-secret>;VS CodeのMSSQL拡張機能では、UI上の項目名が「Client ID」「Client Secret」のように表示される可能性があります。実装上は、クライアントIDがユーザー識別子、クライアントシークレットがパスワード相当の資格情報として扱われるため、通常のパスワードと同じか、それ以上に慎重に管理してください。
JDBCやアプリケーションコードとは表記が違う場合がある
JavaアプリケーションでMicrosoft JDBC Driver for SQL Serverを使う場合、接続プロパティのauthenticationにはActiveDirectoryServicePrincipalを指定します。MicrosoftのJDBCドキュメントでは、userNameプロパティにクライアントID、passwordプロパティにシークレットを指定すると説明されています。(Microsoft Learn)
SqlClientとJDBCでは、認証方式の表記にスペースの有無などの違いがあります。設定をコピーする際は、使用しているドライバーのドキュメントに合わせてください。
| 利用環境 | 認証指定の例 | IDの指定 | シークレットの指定 |
|---|---|---|---|
| Microsoft.Data.SqlClient | Active Directory Service Principal | User Id=<client-id> | Password=<secret> |
| JDBC Driver | ActiveDirectoryServicePrincipal | userName=<client-id> | password=<secret> |
| VS Code MSSQL拡張機能 | UIの認証方式で選択 | Client ID相当の入力欄 | Client Secret相当の入力欄 |
移行・展開時のチェックリスト
SQL認証や個人アカウント接続から切り替える場合
既存のSQLログインや個人アカウント接続をサービスプリンシパル認証へ切り替える場合は、いきなり本番接続を変更せず、検証環境で接続、権限、監査ログを確認します。
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 事前調査 | 現在の接続方式を棚卸しする | SQLログイン、個人Entra認証、共有接続を分類 |
| ID作成 | 用途別にアプリ登録を作る | 開発・検証・本番を分ける |
| 権限設計 | DBユーザーとロールを設定 | 必要最小限の権限にする |
| 接続テスト | VS Codeと必要なツールで接続 | Object Explorer、クエリ実行、DB選択を確認 |
| ログ確認 | サインインログ・SQL監査ログを確認 | どのアプリIDで接続されたか追跡できるか |
| 展開 | 対象ユーザーへ手順を共有 | シークレットを平文共有しない |
| 運用化 | ローテーションと無効化手順を作る | 期限切れ前に更新できる体制にする |
展開前に見落としやすいポイント
特に注意すべきなのは、バージョン、IDの取り違え、シークレット期限の3つです。
| 見落とし | 起きる問題 | 対策 |
|---|---|---|
| 拡張機能が未対応バージョン | 認証方式が選べない、接続できない | 対応バージョンを確認してから展開 |
| クライアントIDではなくオブジェクトIDを入力 | トークン取得や接続に失敗 | アプリケーションIDを使うと明記する |
| シークレットの値ではなくシークレットIDを入力 | 認証失敗 | 作成時に表示されるシークレット値を保管 |
| DBユーザー未作成 | 認証は通ってもDBに入れない | CREATE USERとロール付与を確認 |
| 証明書認証を前提にしている | VS CodeのMSSQL拡張機能では使えない | シークレット方式か別ツールを検討 |
| 高権限を付けすぎる | 漏えい時の被害が大きい | 用途別IDと最小権限に分ける |
セキュリティ面での注意点
マネージドIDを使える環境では優先候補にする
サービスプリンシパル認証は、ユーザー個人の資格情報や非推奨のパスワード認証から離れるうえで有効です。ただし、Azure上で稼働するアプリケーションやワークロードであれば、クライアントシークレットを管理しなくてよいマネージドIDの方が望ましい場合があります。Microsoftのドキュメントでも、Azureリソース上でコードが実行され、対象リソースがMicrosoft Entra認証をサポートする場合は、マネージドIDをより良い選択肢として検討するよう案内されています。(Microsoft Learn)
判断基準は次のように整理できます。
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| サービスプリンシパル | ローカル開発、外部CI/CD、オンプレミスの自動化、VS Code接続 | シークレット管理が必要 |
| マネージドID | Azure VM、App Service、Functions、Azure上のワークロード | Azure外では使いづらい |
| 対話型認証 | 開発者本人が一時的に操作する場合 | 自動化には向かない |
| Active Directory Password | 既存の暫定運用 | Microsoftドキュメント上で非推奨扱いのため移行候補 |
Microsoft.Data.SqlClientのドキュメントでも、ユーザーコンテキストがないアプリがAzureインフラ上で実行される場合はマネージドID、マネージドIDを使えない場合はサービスプリンシパル認証を使う流れが示されています。(Microsoft Learn)
サービスプリンシパルを共有アカウント化しない
サービスプリンシパルは便利ですが、1つのIDを複数チーム・複数用途で使い回すと、誰が何をしたかを追跡しにくくなります。たとえば、開発者の手動確認、CI/CD、レポート生成、本番運用を同じサービスプリンシパルで実行すると、権限が過大になり、監査ログの意味も薄くなります。
実務では、次のように分けるのが安全です。
| 分け方 | 例 |
|---|---|
| 環境別 | app-sql-dev、app-sql-stg、app-sql-prod |
| 用途別 | app-sql-readonly-report、app-sql-deploy、app-sql-batch |
| 権限別 | 読み取り用、DDL実行用、管理作業用 |
| 所有部門別 | データ基盤チーム用、アプリA用、アプリB用 |
名前だけで用途が分かるようにしておくと、後から棚卸しや削除判断がしやすくなります。
よくあるトラブルと対処法
認証は成功しているのにデータベースへ入れない
Microsoft Entraでトークンを取得できても、SQL側に対応するユーザーや権限がなければ接続後の操作に失敗します。まず、対象DBにサービスプリンシパル用のユーザーが存在するか、適切なロールに所属しているかを確認してください。
接続ダイアログにサービスプリンシパル認証が表示されない
利用中のMSSQL拡張機能が、今回のPRを含むバージョンではない可能性があります。PRがマージ済みでも、Marketplaceや組織内配布版に反映されるまで時間差がある場合があります。管理者は、展開前にバージョンとリリースノートを確認してください。
シークレットを更新したら接続できなくなった
古いシークレットを削除する前に、新しいシークレットで接続テストを行う必要があります。CI/CD、開発端末、接続プロファイル、シークレット管理基盤のどこに旧シークレットが残っているかも確認してください。
証明書認証で接続したい
今回のMSSQL拡張機能のPRでは、証明書はサポートされないと明記されています。証明書ベースのサービスプリンシパル認証を必須としている組織では、別の接続方法、別ツール、または将来の対応状況を確認する必要があります。(GitHub)
Microsoft Entra IDとAzure ADの表記が混在している
Microsoft Entra IDはAzure Active Directoryの新しい名称ですが、既存環境との互換性のため、UIや接続プロバイダー、エラーコード、コマンドレットなどにAzure AD表記が残ることがあります。設定画面やログで名称が混在していても、同じ文脈を指している場合があります。(Microsoft Learn)
まず実施すべき対応
今回の更新に対して、最初に行うべきことは大きく3つです。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | 利用中のMSSQL拡張機能のバージョンと対応状況を確認する | 使える機能かどうかを判断する |
| 高 | サービスプリンシパル、シークレット、DB権限を検証環境で確認する | 本番展開前に失敗要因を潰す |
| 中 | 既存のSQLログイン・個人認証接続を棚卸しする | 移行対象と優先順位を決める |
管理者は、サービスプリンシパル認証を「新しい接続方法」として追加するだけでなく、シークレット管理、最小権限、監査、ローテーションまで含めて運用設計する必要があります。開発者は、接続時に入力するクライアントIDとシークレットの扱いを理解し、接続プロファイルやローカル設定ファイルに機密情報を残さないようにしてください。
Microsoft Entra Service Principal authの今回の更新は、SQL接続をより組織的に管理するための前向きな変更です。まずは検証環境で、MSSQL拡張機能の対応バージョン、サービスプリンシパルの接続、データベース権限、ログの追跡性を確認し、その結果をもとに本番展開の手順を整備しましょう。
コメント