Microsoft Entra Server Principals and Server Roles for Azure SQL Database のGAで、Azure SQL Databaseでも Microsoft Entra ID のユーザーやアプリを「サーバー側のログイン」として扱いやすくなりました。結論から言うと、影響が大きいのは、SQL認証を減らしたい組織、複数データベースの権限管理をまとめたい管理者、CI/CDや運用自動化でAzure SQL Databaseを扱うチームです。
特に確認すべきなのは、Microsoft Entra管理者の設定、masterデータベース上のログイン作成権限、固定サーバーロールの割り当て、既存の contained database user との使い分けです。既存環境が自動的に壊れるタイプの変更ではありませんが、権限設計を見直すよいタイミングです。Azure SQL Blogでは、この機能がAzure SQL Database向けにGAとして案内されており、Microsoft LearnのAzure SQL Database更新情報でも2026年6月のGA項目として掲載されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra Server Principals and Server Roles for Azure SQL Database は何が変わった？
今回のポイントは、Azure SQL DatabaseでMicrosoft Entra IDのプリンシパルを、仮想masterデータベース上の「ログイン」として作成し、サーバーレベルの権限管理に使えるようになったことです。
従来、Microsoft Entra IDを使ったAzure SQL Databaseのアクセス管理では、データベースごとに contained database user を作成する運用が中心でした。これはデータベース単位では分かりやすい一方、複数データベースをまたぐ運用者、監視用ID、デプロイ用サービスプリンシパルの管理が散らばりやすいという課題がありました。
GA後は、CREATE LOGIN ... FROM EXTERNAL PROVIDERでMicrosoft Entra IDベースのログインを作成し、必要に応じてCREATE USER ... FROM LOGINで各データベースのユーザーに紐づけられます。Microsoft Learnでは、Microsoft Entra server principalsがAzure SQL Database、Azure SQL Managed Instance、SQL Server 2022以降でGA、Azure Synapse Analyticsではパブリックプレビューと説明されています。(Microsoft Learn)
-- 仮想 master データベースで実行する例
CREATE LOGIN [appName] FROM EXTERNAL PROVIDER;
-- 対象データベースで実行する例
CREATE USER [appName] FROM LOGIN [appName];この変更により、Azure SQL Databaseでも「Microsoft Entra IDを使いながら、SQL Serverに近いログインベースの考え方」で権限を整理しやすくなります。
何ができるようになるのか
主なメリットは、サーバー単位の権限管理、自動化、SQL認証の削減です。
| できること | 実務上の意味 |
|---|---|
| Microsoft Entra IDのユーザー、アプリ、サービスプリンシパルをログインとして作成 | 運用者やCI/CD用IDをAzure SQL Databaseのサーバー側で管理しやすくなる |
| Azure SQL Databaseの固定サーバーロールを利用 | 監視、DB作成、ログイン管理などの権限を役割別に分けやすい |
CREATE USER ... FROM LOGINでDBユーザーを作成 | contained database userだけに頼らず、ログインベースでDBアクセスを設計できる |
| Microsoft Entra-only authenticationと組み合わせやすい | SQL認証を減らし、ID管理をMicrosoft Entra ID側に寄せやすい |
| サービスプリンシパルによる自動化を設計しやすい | データベース作成、ユーザー作成、運用タスクの自動化に使いやすい |
Microsoft Learnでは、Microsoft Entra server principalsの利点として、Azure SQL Databaseサーバーロールによる権限管理、loginmanagerやdbmanagerなどの特殊ロール、SQLログインとの機能的な整合性、Microsoft Entra-only authentication、geo-replica対応、サービスプリンシパルによる自動化などが挙げられています。(Microsoft Learn)
影響を受けるAzure利用者
今回の変更で特に影響を受けるのは、次のようなチームです。
| 対象者 | 確認すべきこと |
|---|---|
| Azure SQL Database管理者 | Microsoft Entra管理者が設定済みか、誰がログイン作成・ロール付与できるか |
| セキュリティ担当者 | SQL認証を残す必要があるか、Microsoft Entra-only authenticationへ寄せられるか |
| DevOps担当者 | CI/CD用のサービスプリンシパルをログインとして管理できるか |
| DBA・運用担当者 | 監視用ID、障害調査用ID、DB作成権限を固定サーバーロールで分離できるか |
| 複数DBを持つSaaS運用チーム | データベースごとのユーザー作成とサーバーレベル権限の境界を整理できるか |
逆に、単一データベースだけを使い、すでにcontained database userで問題なく運用できている小規模環境では、すぐに移行しなければならない変更ではありません。まずは新規環境や運用自動化用IDから試すのが現実的です。
すぐ確認したい設定
最初に見るべきなのは、Microsoft Entra管理者、masterデータベース上のログイン、固定サーバーロールの3点です。
Microsoft Entra管理者が設定されているか
Microsoft Entra認証を使うには、対象のAzure SQL Database論理サーバーにMicrosoft Entra管理者が設定されている必要があります。Microsoft Learnでは、Azure SQL Databaseの論理サーバーにMicrosoft Entra管理者を設定すると、Microsoft Entra認証が有効になると説明されています。(Microsoft Learn)
Azureポータルでは、対象のSQL serverを開き、設定メニューの「Microsoft Entra ID」から確認します。未設定の場合、まずここを整備しないと、ログイン作成やMicrosoft Entra認証の設計が進みません。
誰が最初のMicrosoft Entraログインを作れるか
Microsoft Learnによると、仮想masterデータベースでMicrosoft Entraログインを利用または作成するには、Microsoft Entra管理者権限またはloginmanagerサーバーロールのメンバーシップが必要です。また、最初のMicrosoft EntraログインはMicrosoft Entra管理者だけが作成できます。(Microsoft Learn)
つまり、運用担当者にいきなり作業を任せるのではなく、最初はMicrosoft Entra管理者がログイン作成の起点を作り、その後に権限委任する流れが安全です。
固定サーバーロールを誰に付けるか
Azure SQL Databaseには、権限管理を簡略化するための固定サーバーレベルロールがあります。Microsoft Learnでは、Azure SQL Databaseの固定サーバーロールは7種類あり、サーバーレベルのログインをメンバーとして追加できると説明されています。(GitHub)
| ロール | 主な用途 | 使いどころ |
|---|---|---|
##MS_DatabaseConnector## | 任意のデータベースへの接続 | 監視・調査用ID。ただし接続範囲が広いので慎重に付与 |
##MS_DatabaseManager## | データベースの作成・削除・変更 | DB作成を自動化するCI/CDや運用ID |
##MS_LoginManager## | ログインの作成・変更 | DBAチームやID管理担当への限定的な委任 |
##MS_ServerStateReader## | サーバー状態の参照 | パフォーマンス監視、障害調査 |
##MS_ServerStateManager## | サーバー状態の管理操作 | キャッシュクリアなどを含むため、強い運用権限として扱う |
##MS_DefinitionReader## | 定義情報の参照 | スキーマ確認、棚卸し、監査 |
##MS_SecurityDefinitionReader## | セキュリティ定義情報の参照 | 権限レビュー、監査対応 |
注意したいのは、便利だからといって##MS_DatabaseConnector##や##MS_DatabaseManager##を広く付与しないことです。特に##MS_DatabaseConnector##は接続範囲が広がるため、必要なIDだけに限定し、ユーザーデータベース側でDENY CONNECTを使う設計も検討します。Microsoft Learnでも、ユーザーデータベースではDENYがサーバーロール由来の許可を上書きできると説明されています。(GitHub)
既存環境で確認する手順
本番環境でいきなり移行するのではなく、まず棚卸しから始めるのが安全です。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 対象のAzure SQL Database論理サーバーを洗い出す | 本番、検証、開発を分けて確認する |
| 2 | Microsoft Entra管理者の有無を確認 | 未設定なら先に管理者設定を整備する |
| 3 | SQL認証とMicrosoft Entra認証の利用状況を確認 | SQLログインを減らせる領域を探す |
| 4 | contained database userを棚卸し | DB単位で十分か、ログインベースにしたいかを判断 |
| 5 | 監視・CI/CD・DBA用IDを分類 | 固定サーバーロールの候補を決める |
| 6 | 検証環境でログイン作成とロール付与を試す | 接続、権限、監査ログを確認する |
| 7 | 本番適用時のロールバック手順を用意 | ロール削除、ログイン無効化、DBユーザー削除を手順化する |
棚卸しでは、「誰がどのデータベースに入れるか」だけでなく、「誰がログインを作れるか」「誰がデータベースを作れるか」「誰がサーバー状態を見られるか」まで分けて確認してください。ここを分けないと、せっかくMicrosoft Entra IDに寄せても、権限が大きすぎる運用IDが残ってしまいます。
運用上の注意点
SQL管理者だけではMicrosoft Entra操作ができない場面がある
Microsoft Learnでは、SQL server adminはMicrosoft Entraログインやユーザーを作成できず、SQL adminやSQLユーザーはCREATE LOGIN ... FROM EXTERNAL PROVIDERなどのMicrosoft Entra関連操作を実行できないと説明されています。(Microsoft Learn)
そのため、従来の「SQL管理者が全部対応する」運用から、Microsoft Entra管理者やID管理チームと連携する運用に変える必要があります。障害対応時に「権限があるはずなのにログインを作れない」とならないよう、作業者と権限を事前に決めておきましょう。
ロール変更がすぐ反映されないことがある
サーバーロールのメンバー変更やログインの無効化は、既存接続にすぐ反映されない場合があります。Microsoft Learnでは、サーバーロール割り当ては有効になるまで最大5分かかる場合があり、既存セッションでは再接続が必要になると説明されています。また、必要に応じてDBCC FLUSHAUTHCACHEやDBCC FREESYSTEMCACHE('TokenAndPermUserStore')を使う手順も案内されています。(GitHub)
緊急時の権限停止を想定する場合は、単にロールから外すだけでなく、アプリ側の接続プール再作成や接続切断の手順もセットで用意しておくべきです。
Microsoft Entraグループには制限がある
Microsoft Entraグループを使うと管理は楽になりますが、Azure SQL Databaseのサーバーロールでは制限があります。Microsoft Learnでは、Microsoft Entraグループログインに対する既知の制限として、Azure SQL DatabaseサーバーロールがMicrosoft Entraグループではサポートされないことなどが示されています。(Microsoft Learn)
実務では、グループを万能の委任先にせず、サーバーロールを付与する対象はユーザー、アプリ、サービスプリンシパル単位で設計できるか確認してください。特にDBAグループや運用グループにまとめて強いロールを付ける設計は、公式制限と監査要件の両方を確認してから進める必要があります。
表示名の重複に注意する
Microsoft Entra IDでは表示名が重複することがあります。一方、Azure SQLではサーバープリンシパルやデータベースプリンシパル名の一意性が求められるため、サービスプリンシパルやマネージドIDの表示名が重複していると、作成時にエラーになることがあります。Microsoft Learnでは、この問題に対する対応としてWITH OBJECT_IDに触れていますが、同ページではプレビューの強化として説明されています。(Microsoft Learn)
本番運用では、アプリ登録やマネージドIDの命名規則を先に整備してください。例として、app-prod-billing-sql、mi-prod-monitoring-sqlのように、環境、用途、対象を含めると重複や誤付与を減らせます。
どのように使い分けるべきか
contained database userをすべて置き換える必要はありません。むしろ、次のように使い分けると安全です。
| パターン | 推奨する考え方 |
|---|---|
| 特定DBだけにアクセスするアプリ | contained database userでも十分。ログインベース化は必須ではない |
| 複数DBを横断する監視ID | Microsoft Entraログインと固定サーバーロールを検討 |
| DB作成やユーザー作成を自動化するCI/CD | サービスプリンシパルのログイン化を検討 |
| SQL認証を削減したい環境 | Microsoft Entra-only authenticationと組み合わせて段階移行 |
| 監査や権限レビューを強化したい環境 | サーバーロールの棚卸しと最小権限設計を優先 |
重要なのは、「ログインベースにできるから全部変える」のではなく、「複数DBをまたぐ権限」「自動化に必要な権限」「人間の管理者権限」を分離することです。
まず実施すべきチェックリスト
本番環境に適用する前に、以下を確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| Microsoft Entra管理者が設定されている | AzureポータルまたはCLIで確認済み |
| SQL認証を使っているIDを棚卸しした | アプリ、運用、緊急用を分類済み |
| contained database userを棚卸しした | どのDBに誰がいるか把握済み |
| サーバーロールを付与する候補IDを決めた | 監視、DB作成、ログイン管理など用途別に整理済み |
| Microsoft Entraグループ利用時の制限を確認した | グループに直接サーバーロールを付ける前提にしていない |
| 権限変更後の反映遅延を手順化した | 再接続、キャッシュクリア、接続プール対応を明文化済み |
| 監査ログでログイン作成・ロール変更を追跡する | 誰がいつ権限を変更したか確認できる |
検証環境でCREATE LOGINとCREATE USER FROM LOGINを試した | 接続と権限の動作を確認済み |
このチェックリストを満たしてから本番に展開すれば、権限の付けすぎや反映タイミングの誤解を避けやすくなります。
まとめ：権限管理をMicrosoft Entra ID中心に整理する好機
Microsoft Entra Server Principals and Server Roles for Azure SQL DatabaseのGAは、Azure SQL Databaseの認証・権限管理をMicrosoft Entra ID中心に寄せたい組織にとって重要な更新です。
すぐに全環境を移行する必要はありません。まずは、Microsoft Entra管理者の設定、既存ユーザーとSQLログインの棚卸し、監視・CI/CD・DBA用IDの分類から始めてください。そのうえで、検証環境でCREATE LOGIN ... FROM EXTERNAL PROVIDERと固定サーバーロールの割り当てを試し、反映遅延やグループ制限を含めた運用手順を固めるのが現実的です。
最終的には、SQL認証を減らし、Microsoft Entra ID、最小権限、監査可能なロール設計を組み合わせることで、Azure SQL Databaseの運用をより安全で管理しやすい形にできます。
コメント