Microsoft Entra Server Principals and Server Roles for Azure SQL Database は、Azure SQL DatabaseでMicrosoft Entra IDのユーザーやアプリケーションを「サーバー単位のログイン」として扱い、固定サーバーロールを割り当てられるようにする機能です。管理者がまず確認すべき結論は、SQL認証に頼っていたサーバー管理・監視・プロビジョニング作業を、Microsoft Entra IDベースへ寄せやすくなったという点です。
2026年6月19日の公式発表をもとにすると、本件はGA、つまり一般提供として扱うべき更新です。従来はMicrosoft Entra IDのプリンシパルをデータベース単位の包含ユーザーとして作る運用が中心で、サーバー横断の権限委任、ログイン管理、無効化、監視用DMV参照などに制約がありました。今回のGAにより、Azure SQL Databaseの管理者は「誰に、どのサーバーロールを、どの範囲で付与するか」を再設計する必要があります。Azure SQL Blogでも、Entraログインをlogical master database上のfirst-class server principalとして扱えること、固定サーバーロール付与、CREATE USER ... FROM LOGIN、ALTER LOGIN ... DISABLEによる集中管理が主な変更点として説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra Server Principals and Server Roles for Azure SQL Databaseで変わる管理ポイント
今回の変更で重要なのは、「Microsoft Entra IDでログインできるようになった」という単純な話ではありません。Azure SQL Databaseの論理サーバー上で、Microsoft Entra IDのユーザー、アプリケーション、サービスプリンシパルをサーバープリンシパル、つまりログインとして扱い、そのログインに対してサーバーレベルのロールを割り当てられる点が実務上の変化です。
Microsoft Learnでは、Microsoft Entra server principalsはAzure SQL Database、Azure SQL Managed Instance、SQL Server 2022以降で一般提供と説明されています。Azure Synapse Analyticsの専用SQLプールでは、現時点でパブリックプレビューとして扱われます。(Microsoft Learn)
従来の包含データベースユーザーだけの運用では、データベースごとにユーザーを作成し、必要な権限を個別に付与する必要がありました。複数データベースを持つ論理サーバーでは、監視担当者、DevOps用アプリ、セキュリティ担当者の権限管理が分散しやすく、退職・異動・インシデント対応時の無効化も漏れが出やすい構造でした。
今回のGAでは、次のような運用に変えられます。
| 変更点 | 管理者にとっての意味 | 実務での活用例 |
|---|---|---|
| Microsoft Entraログインを作成できる | Entra IDのIDをサーバー単位で扱える | 監視用サービスプリンシパルをサーバー単位で管理する |
| 固定サーバーロールを割り当てられる | 管理者権限を渡さずに作業を委任できる | DMV参照だけを許可する、ログイン管理だけを委任する |
CREATE USER ... FROM LOGINを使える | データベースユーザーをサーバーログインに紐づけられる | 複数DBで同じIDを一貫して管理する |
ALTER LOGIN ... DISABLEで集中無効化できる | オフボーディングや緊急遮断がしやすい | 退職者や漏えい疑いのアプリIDを即時停止する |
| Entra-only認証へ移行しやすくなる | SQL認証依存を減らせる | パスワードレス化、監査統制、認証基盤統一を進める |
ただし、既存セッションへの反映、サーバーロールの伝播、グループ利用の制約、監査ログの見方には注意が必要です。ここを確認せずに本番導入すると、「権限を付けたのに効かない」「無効化したのに既存接続が残る」「SQL Auditに失敗ログインが出ない」といった誤解が起きます。
管理者向けチェックリスト
Azure管理者、DBA、セキュリティ担当者は、まず次の順番で確認すると抜け漏れを減らせます。
| 確認項目 | 確認する内容 | 判断基準 |
|---|---|---|
| 対象サーバー | Azure SQL Databaseの論理サーバーでMicrosoft Entra管理者が設定済みか | 未設定ならEntra認証・Entraログイン運用の前提が整っていない |
| 既存認証方式 | SQLログイン、Contained user、Entra認証の利用状況 | SQL認証依存が多いほど移行計画が必要 |
| 権限委任 | 監視、DB作成、ログイン管理を誰が行うか | 管理者権限ではなく固定サーバーロールで委任できるか検討 |
| 監査 | SQL Audit、Log Analytics、Event Hubs、Storageの設定 | ロール変更・ログイン作成・認証イベントを追える状態にする |
| オフボーディング | ユーザー・アプリ無効化手順 | ALTER LOGIN ... DISABLEと既存セッション切断の手順を分ける |
| 移行方針 | 既存SQLログインをEntra IDへ置き換えるか | 重要度の低い監視・自動化IDから段階移行する |
| 周知 | DBA、アプリ担当、SOC、ヘルプデスクへの説明 | 「Azure RBACではDB接続権限にならない」点を必ず共有 |
特に誤解されやすいのがAzure RBACとの違いです。Microsoft Entra IDでAzureリソースを管理できるロールを持っていても、それだけでAzure SQL Databaseへ接続してクエリを実行できるわけではありません。Microsoft Learnでも、SQL Server ContributorやSQL DB Contributorは管理操作用であり、データベース接続権限ではないと説明されています。(Microsoft Learn)
権限設計で確認すべきサーバーロール
Azure SQL Databaseでは、固定サーバーロールを使って論理サーバー単位の権限を管理します。Microsoft Learnでは、Azure SQL Databaseに7つの固定サーバーロールが用意され、ロール自体の権限は変更できず、固定ロールを別の固定ロールのメンバーにはできないと説明されています。(Microsoft Learn)
管理者が見るべきポイントは、「便利だから付与する」ではなく、職務に合わせて最小権限で付与することです。
| 固定サーバーロール | 主な用途 | 付与を検討する相手 | 注意点 |
|---|---|---|---|
##MS_DatabaseConnector## | すべてのデータベースへ接続可能にする | 共通接続が必要な運用ID | 接続許可の範囲が広いため、DB側のDENY設計も確認する |
##MS_DatabaseManager## | データベースの作成・削除 | DevOps、環境構築自動化アプリ | 作成したDBの所有者になり得るため、本番では承認フローが必要 |
##MS_DefinitionReader## | 定義情報の参照 | 監査、構成管理、棚卸し担当 | セキュリティ定義も広く見えるため、情報開示リスクを確認する |
##MS_LoginManager## | ログインの作成・削除 | ID管理担当、セキュリティ管理者 | ログイン管理の委任範囲を台帳化する |
##MS_SecurityDefinitionReader## | セキュリティ定義の参照 | SOC、監査担当 | 参照専用でも権限構造が見えるため、監査用途に絞る |
##MS_ServerStateReader## | DMVや状態情報の参照 | 監視ツール、性能分析担当 | 監視用途では最有力。管理権限を渡さず状態確認できる |
##MS_ServerStateManager## | サーバー状態の管理操作 | 限定されたDBA | DBCC FREEPROCCACHEなど影響の大きい操作につながるため慎重に付与 |
たとえば、監視サービスプリンシパルにパフォーマンス監視用の参照権限を与えたいだけなら、いきなり管理者にするのではなく、##MS_ServerStateReader##を候補にします。ログイン作成だけを委任したい場合は、##MS_LoginManager##を使います。データベース作成をCI/CDで自動化する場合は、##MS_DatabaseManager##を検討します。
一方で、固定サーバーロールのメンバーは同じロールへ他のログインを追加できる点に注意が必要です。これは権限委任の連鎖につながるため、誰がどのロールを付与できるかを監査対象に含めるべきです。(Microsoft Learn)
Microsoft Entraログイン作成時の権限と前提条件
Microsoft Entraログインを作成・利用するには、仮想masterデータベースで操作します。最初のMicrosoft EntraログインはMicrosoft Entra管理者だけが作成できます。その後は、Microsoft Entra管理者またはloginmanager系の権限を持つプリンシパルがログイン作成を担う形になります。Microsoft Learnでも、Microsoft Entra管理者権限またはloginmanagerサーバーロールのメンバーシップが必要であり、最初のMicrosoft EntraログインはMicrosoft Entra管理者のみ作成できると説明されています。(Microsoft Learn)
基本的な作成例は次の通りです。
-- 仮想 master データベースで実行
CREATE LOGIN [app-monitor-prod] FROM EXTERNAL PROVIDER;
GOデータベース側にログインベースのユーザーを作る場合は、対象データベースで次のように実行します。
CREATE USER [app-monitor-prod] FROM LOGIN [app-monitor-prod];
GO従来の包含ユーザーを作る構文も引き続き使えます。
CREATE USER [app-monitor-prod] FROM EXTERNAL PROVIDER;
GOただし、FROM LOGINで作成したユーザーと、FROM EXTERNAL PROVIDERで作成した包含ユーザーは意味が異なります。ログインベースのユーザーはサーバーログインに紐づき、サーバーレベルのロールや権限の影響を受けます。包含ユーザーはデータベース内に閉じたユーザーであり、同じ名前のログインが存在しても自動的に紐づくわけではありません。Microsoft Learnでも、ログインベースユーザーと包含データベースユーザーのSID構造の違い、同名プリンシパルによる混同リスクが説明されています。(Microsoft Learn)
既存環境の移行判断
すべての既存ユーザーをすぐにログインベースへ移行する必要はありません。移行対象は、サーバー横断で管理したいIDから優先するのが現実的です。
| 現在の状態 | 移行優先度 | 理由 |
|---|---|---|
| 監視ツールがSQLログインで接続している | 高 | パスワード管理を減らし、Entra ID・マネージドIDへ寄せやすい |
| CI/CDや運用アプリがDB作成・ログイン作成をしている | 高 | サーバーロールで最小権限化しやすい |
| 複数DBに同じContained userを手作業で作っている | 中 | CREATE USER ... FROM LOGINで管理を集約できる |
| 単一DBだけで完結する一般ユーザー | 低 | 包含ユーザーのままでも管理上問題ない場合がある |
| 一時的な外部ユーザー | 低〜中 | 有効期限、ゲスト管理、監査要件に応じて判断する |
移行時は、次の順で進めると安全です。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 既存SQLログインとContained userを棚卸しする | 使用中のアプリ、接続文字列、権限、最終利用状況を確認 |
| 2 | 対応するMicrosoft Entra IDを決める | ユーザー、グループ、サービスプリンシパル、マネージドIDを整理 |
| 3 | 仮想masterにEntraログインを作成する | 表示名重複がある場合はObject IDを確認 |
| 4 | 必要な固定サーバーロールだけを付与する | 管理者権限を代替するのではなく、職務別に絞る |
| 5 | 対象DBにFROM LOGINでユーザーを作成する | 既存の同名Contained userと混在しないか確認 |
| 6 | 接続テストを行う | 新規接続、ロール反映、アプリの認証方式を確認 |
| 7 | SQLログインを無効化または削除する | ロールバック手順を用意して段階的に実施 |
| 8 | Entra-only認証を検討する | SQL認証を完全に止める前に依存アプリを洗い出す |
Microsoft Entra-only authenticationを有効にすると、SQL Server管理者、SQLログイン、SQL認証ベースのユーザーなど、Microsoft Entra以外の認証方式は使えなくなります。これはセキュリティ強化に有効ですが、古い接続文字列、運用スクリプト、外部ツールがSQL認証に依存していると障害になります。(Microsoft Learn)
監査で見るべきポイント
Microsoft Entra Server Principals and Server Roles for Azure SQL Databaseを導入する場合、監査の焦点は「接続できたか」だけではありません。少なくとも次の操作を追跡できるようにします。
| 監査対象 | 見るべき理由 |
|---|---|
CREATE LOGIN | 新しいサーバープリンシパルが作成されたことを把握する |
ALTER LOGIN ... DISABLE | アカウント停止・復旧の証跡を残す |
ALTER SERVER ROLE ... ADD MEMBER | 権限昇格や委任の発生を確認する |
CREATE USER ... FROM LOGIN | DBユーザーとサーバーログインの紐づけを把握する |
| 認証成功・失敗 | 不審な接続試行、移行後の接続失敗を検知する |
DBCC FLUSHAUTHCACHEなど | 権限反映や緊急対応の操作証跡を残す |
Azure SQL Databaseの監査は、データベースイベントをAzure Storage、Log Analytics workspace、Event Hubsへ書き出せます。コンプライアンス対応、データベース活動の把握、不審なアクティビティ分析に使えますが、高負荷時には可用性と性能を優先し、監査対象イベントのすべてが記録されない可能性がある点も明記されています。(Microsoft Learn)
特にMicrosoft Entra認証の失敗ログインは注意が必要です。Microsoft Learnでは、Microsoft Entra認証の失敗ログインはSQL audit logに表示されず、Microsoft Entra admin center側で確認する必要があると説明されています。成功ログインはデータベースに到達するため監査されますが、失敗時はデータベースに到達する前に認証が終わるためです。(Microsoft Learn)
棚卸しに使える確認SQL
サーバーロールのメンバーを確認するには、仮想masterデータベースでsys.server_role_membersとsys.server_principalsを使います。Microsoft Learnでも、Microsoft Entraログインがサーバーロールに含まれているか確認する例が示されています。(Microsoft Learn)
-- 仮想 master データベースで実行
SELECT
member.principal_id AS MemberPrincipalID,
member.name AS MemberPrincipalName,
member.type_desc AS MemberType,
roles.principal_id AS RolePrincipalID,
roles.name AS RolePrincipalName
FROM sys.server_role_members AS srm
INNER JOIN sys.server_principals AS roles
ON srm.role_principal_id = roles.principal_id
INNER JOIN sys.server_principals AS member
ON srm.member_principal_id = member.principal_id
ORDER BY roles.name, member.name;Microsoft Entraログインだけを確認したい場合は、type_descを見ます。
SELECT
name,
type,
type_desc,
is_disabled
FROM sys.server_principals
WHERE type_desc LIKE 'EXTERNAL%';データベース側で、ログインベースユーザーか包含ユーザーかを確認したい場合は、SIDの形式を使って判別できます。
SELECT
name,
type_desc,
CASE
WHEN CONVERT(varchar(100), sid, 2) LIKE '%AADE'
AND LEN(sid) = 18
THEN 'login-based user'
ELSE 'contained database user'
END AS user_type
FROM sys.database_principals
WHERE type IN ('E', 'X');権限反映とキャッシュの注意点
サーバーロールの変更は、すぐに既存セッションへ反映されるとは限りません。Microsoft Learnでは、ロール割り当てが有効になるまで最大5分かかる場合があり、既存セッションでは接続を閉じて再接続するまで変更が反映されないと説明されています。必要に応じてDBCC FLUSHAUTHCACHEを実行する回避策も示されています。(Microsoft Learn)
権限変更後に「付与したのに見えない」「外したのにまだ使える」と見える場合は、次を確認します。
| 症状 | 主な原因 | 対応 |
|---|---|---|
| ロールを付与したのに権限が効かない | 既存接続のまま、またはキャッシュ反映待ち | 再接続し、必要に応じてキャッシュをクリア |
| 無効化したのに処理が続く | ALTER LOGIN ... DISABLEは新規接続を止める操作 | 既存セッションを特定し、必要ならKILLを検討 |
| 期待したDBで権限が効かない | DB側に対応するユーザーがない | CREATE USER ... FROM LOGINの有無を確認 |
| グループ経由で意図通り動かない | サーバーロール付与の制約やグループ解決の問題 | 個別プリンシパルまたはサービスプリンシパル単位で検証 |
| 監査ログに失敗ログインが出ない | Entra認証失敗はSQL Auditに出ない場合がある | Microsoft Entra admin centerのサインインログを確認 |
Microsoft Entraグループ利用時の注意点
Microsoft Entraグループは、アクセス管理を簡素化するうえで有効です。Microsoft Entra管理者をグループに設定すれば、グループメンバーが管理者として機能でき、サーバー側の個別変更を減らせます。Microsoft Learnでも、Microsoft Entra管理者は1つのIDとして設定され、グループを使うことで複数のIDに管理者権限を持たせやすいと説明されています。(Microsoft Learn)
ただし、固定サーバーロールの付与では制約があります。Microsoft Learnのチュートリアルでは、サーバーレベルロールはMicrosoft Entraグループにはサポートされないと記載されています。(Microsoft Learn)
そのため、実務では次のように使い分けると安全です。
| 用途 | 推奨設計 |
|---|---|
| Entra管理者を複数人で担う | Microsoft Entraグループを管理者に設定 |
| 監視アプリにDMV参照権限を付与 | サービスプリンシパルまたはマネージドIDへ必要ロールを直接付与 |
| ログイン管理を委任 | 個別の管理用IDに##MS_LoginManager##を付与し、変更を監査 |
| 一般利用者のDBアクセス | DBロールとEntraグループを組み合わせて管理 |
| 本番サーバー管理 | グループ管理、PIM、承認フロー、監査ログを併用 |
「グループで全部まとめる」方針にすると、サーバーロールの制約にぶつかることがあります。管理者権限、DBアクセス権限、サーバーロール委任は同じ設計で扱わず、用途ごとに分けて考えるべきです。
導入前に周知すべきこと
今回のGAは、DBAだけで完結する変更ではありません。アプリ担当、ID管理担当、SOC、監査担当、ヘルプデスクにも影響します。
周知では、次の内容を短く共有すると効果的です。
| 対象者 | 伝えるべき内容 |
|---|---|
| アプリ担当 | 接続方式をSQL認証からEntra認証、マネージドID、サービスプリンシパルへ移行できる可能性がある |
| DBA | サーバーロールで権限委任できるが、付与先と反映タイミングに注意が必要 |
| ID管理担当 | Entra IDのライフサイクル管理がDBアクセス停止にも直結しやすくなる |
| SOC・監査担当 | SQL AuditとEntraサインインログの両方を見る必要がある |
| ヘルプデスク | 「Azureの権限はあるがDBに入れない」は正常な切り分け観点である |
| 開発・DevOps | CI/CD用IDをパスワードレス化し、必要最小限のサーバーロールへ置き換えられる |
特に、SQL認証を廃止する計画がある場合は、いきなりEntra-only authenticationを有効化しないことが重要です。接続文字列、ジョブ、外部連携、監視ツール、緊急運用アカウントの依存関係を洗い出してから段階的に切り替えます。
本番導入の進め方
本番では、まず影響の小さい監視用途から始めるのが現実的です。たとえば、読み取り専用の監視サービスプリンシパルを作成し、##MS_ServerStateReader##を付与してDMV参照ができるか確認します。その後、ログイン管理、DB作成、CI/CD用途へ広げます。
おすすめの導入順は次の通りです。
| フェーズ | 内容 | 成功条件 |
|---|---|---|
| 検証 | 開発環境でEntraログイン作成、ロール付与、監査確認 | 作成・接続・無効化・監査が確認できる |
| 監視ID移行 | 監視用SQLログインをEntra IDへ移行 | SQLパスワードなしで監視が継続できる |
| 自動化ID移行 | CI/CDやDB作成用IDをEntra化 | 必要最小限のロールで処理が完了する |
| 管理委任 | ログイン管理や定義参照を職務別に委任 | 管理者権限を渡さず運用できる |
| SQL認証削減 | 不要なSQLログインを無効化 | 影響なくアプリ・運用が継続する |
| Entra-only検討 | SQL認証を完全に止めるか判断 | 依存がなく、緊急時手順も整備済み |
移行後は、少なくとも月次でサーバーロールメンバーを棚卸しします。特に##MS_DatabaseManager##、##MS_LoginManager##、##MS_ServerStateManager##は影響範囲が大きいため、付与理由、承認者、期限、最終利用状況を台帳化してください。
失敗しやすいポイント
Microsoft Entra Server Principals and Server Roles for Azure SQL Databaseは便利ですが、導入時に失敗しやすい箇所があります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| SQLログインを消したらアプリが停止した | 接続文字列がSQL認証のままだった | 事前に接続元、接続方式、認証ライブラリを棚卸しする |
| Entraログインを作ったのにDBに入れない | DBユーザーが未作成、または権限不足 | CREATE USER ... FROM LOGINとDBロールを確認 |
| 権限を外したのにまだ使える | 既存セッションが残っている | 再接続、キャッシュ、必要時のセッション切断を運用に含める |
| グループでサーバーロールをまとめようとして失敗 | サーバーロール付与の制約を見落とした | ロール付与対象を個別プリンシパルで検証する |
| SQL Auditだけ見て失敗ログインを見逃す | Entra認証失敗はSQL Auditに出ない場合がある | Entraサインインログも監視対象にする |
| 管理者権限の代替として広く付与した | 最小権限設計になっていない | 職務別に固定サーバーロールを分ける |
この機能は「管理を楽にする機能」であると同時に、「サーバー単位の権限をEntra IDへ広げる機能」でもあります。便利さだけを見て広く付与すると、権限委任の範囲が見えにくくなります。
管理者が次に取るべき行動
まず、Azure SQL Databaseの論理サーバーごとに、Microsoft Entra管理者の設定、SQLログインの利用状況、Contained userの棚卸し、固定サーバーロールの付与状況を確認してください。そのうえで、監視用ID、CI/CD用ID、ログイン管理担当の3種類から優先的にMicrosoft Entraログイン化を検討します。
本番導入では、次の3点を完了条件にすると安全です。
| 完了条件 | 内容 |
|---|---|
| 権限設計が文書化されている | どのロールを誰に付与するか、なぜ必要かが説明できる |
| 監査できる | ログイン作成、ロール変更、無効化、認証イベントを追える |
| 戻せる | SQL認証削減やEntra-only化の前にロールバック手順がある |
Microsoft Entra Server Principals and Server Roles for Azure SQL DatabaseのGAは、Azure SQL Databaseの認証・権限管理をEntra ID中心に整理する好機です。いきなり全面移行するのではなく、監視、管理委任、自動化、SQL認証削減の順に進めることで、実運用のリスクを抑えながらパスワードレス化と最小権限化を進められます。
コメント