Microsoft Entra Server Principals and Server Roles for Azure SQL Database は、Azure SQL Database で Microsoft Entra ID のユーザー、グループ、アプリケーションを「サーバーレベルのログイン」として扱えるようにする機能です。2026年6月19日の Azure SQL Blog 更新では、この機能と Azure SQL Database のサーバーロール割り当てが GA として案内されました。これにより、従来の「各データベースに contained user を作る」運用だけでなく、仮想 master データベースに Microsoft Entra ログインを作成し、サーバーロールで権限を管理する選択肢が現実的になります。(TECHCOMMUNITY.MICROSOFT.COM)
実務でまず確認すべきことは、Azure ポータル上で Microsoft Entra 管理者が設定されているか、対象サーバーが正しい Microsoft Entra テナントに紐づいているか、そして ##MS_LoginManager## や ##MS_DatabaseConnector## などのサーバーロールを誰に付与するかです。特に本番環境では、「便利だから広く付与する」のではなく、接続・ログイン作成・DB作成・監視閲覧といった役割ごとに分けて確認することが重要です。
Microsoft Entra Server Principals and Server Roles for Azure SQL Database とは
Microsoft Entra Server Principals は、Microsoft Entra ID のユーザー、グループ、アプリケーションを Azure SQL Database の仮想 master データベース上にログインとして作成できる仕組みです。Microsoft Learn では、Microsoft Entra ID 由来の server principal は Azure SQL Database と Azure SQL Managed Instance の仮想 master データベースに作成されるログインとして説明されています。(Microsoft Learn)
これまで Azure SQL Database で Microsoft Entra 認証を使う場合、多くのケースでは各データベースに CREATE USER ... FROM EXTERNAL PROVIDER で contained database user を作成していました。新しい運用では、仮想 master に Microsoft Entra ログインを作り、各データベースでは CREATE USER ... FROM LOGIN によってログインベースのユーザーを作成できます。公式ドキュメントでも、ログインベースのユーザーは CREATE USER [user_name] FROM LOGIN [login_name] で作成できると案内されています。(Microsoft Learn)
何が変わるのか
今回の実務上の変化は、「Microsoft Entra 認証が使えるようになった」という単純な話ではありません。Azure SQL Database で Microsoft Entra ID の主体をサーバーレベルの権限管理に組み込みやすくなった点が重要です。
| 確認項目 | 従来よく使われた運用 | 今回確認すべき新しい運用 |
|---|---|---|
| Entra ID ユーザーの作成単位 | 各データベースに contained user を作成 | 仮想 master にログインを作成し、各DBにログインベースの user を作成 |
| 権限管理 | DBごとのロール中心 | 固定サーバーロールとDBロールを組み合わせる |
| 自動化 | DB単位のユーザー作成が中心 | サービスプリンシパルのログインとロール付与で自動化しやすい |
| 管理対象 | 個別DBのアクセス権 | サーバー横断の接続、ログイン作成、DB作成、監視権限 |
| 注意点 | DBごとの設定漏れ | サーバーロールの過剰付与、Entra 管理者との重複、キャッシュ反映遅延 |
Azure SQL Database の「サーバー」は物理サーバーではなく論理サーバーです。Microsoft Learn でも、Azure SQL Database ではサーバーが論理的な概念であり、権限管理を簡素化するために固定サーバーレベルロールが提供されると説明されています。(Microsoft Learn)
GA で確認すべき対象範囲
今回のポイントは、Azure SQL Database における Microsoft Entra server principals が GA になったことです。Azure SQL Database の What’s new ページでも、Microsoft Entra identities の server principals、つまりログインを作成する機能が 2026年6月に GA になったと記載されています。(Microsoft Learn)
ただし、関連サービスすべてを同じ扱いにしないことが大切です。Microsoft Learn では、Microsoft Entra server principals は Azure SQL Database、Azure SQL Managed Instance、SQL Server 2022 以降では GA、Azure Synapse Analytics ではパブリックプレビューと説明されています。(Microsoft Learn)
| サービス | 状態 | 実務上の扱い |
|---|---|---|
| Azure SQL Database | GA | 本番導入の検討対象。既存のDB権限設計との整合性を確認する |
| Azure SQL Managed Instance | GA | MI側の Microsoft Graph / Directory Readers 周りも合わせて確認する |
| SQL Server 2022 以降 | GA | オンプレミスまたはIaaS構成との混在環境で設計を揃える |
| Azure Synapse Analytics | Public Preview | 本番標準として扱う前に制限事項とサポート条件を確認する |
記事や社内通知では、「Azure SQL Database で GA」と明記するのが安全です。Synapse Analytics まで同じく GA と書くと、誤った運用判断につながります。
Azure ポータルで最初に確認する設定場所
Microsoft Entra Server Principals を利用する前に、Azure ポータルで確認すべき場所は主に3つです。
Azure SQL Database の論理サーバーを確認する
Azure SQL Database の各データベースは、論理サーバーに紐づいています。設定確認はデータベース単体の画面だけで完結しません。まず Azure ポータルで対象の Azure SQL Database を開き、概要画面でサーバー名を確認します。Microsoft Learn でも、Azure SQL Database の概要ページにある server name フィールドから論理サーバー名を確認できると案内されています。(Microsoft Learn)
実務では、次のように確認します。
| 確認場所 | 見る項目 | 判断ポイント |
|---|---|---|
| Azure SQL Database の概要 | サーバー名 | 本番・検証・開発のどの論理サーバーか |
| SQL server リソース | Microsoft Entra ID | Entra 管理者が設定済みか |
| SQL server リソース | ID | サーバーのマネージド ID を使う設計か |
| SQL server リソース | ネットワーク | 認証以前に接続元が許可されているか |
| Microsoft Entra ID | ユーザー・グループ・アプリ | SQLログイン化する対象が正しいか |
よくある失敗は、データベース名だけを見て作業し、別の論理サーバーに対して Entra 管理者やログインを確認してしまうことです。特に同じ命名規則で prod-sql-01、stg-sql-01、dev-sql-01 のようなサーバーが並んでいる環境では、最初にサブスクリプション、リソースグループ、サーバー名を記録してから作業してください。
Microsoft Entra 管理者が設定されているか確認する
Microsoft Entra 認証を使うには、対象の Azure SQL リソースに Microsoft Entra 管理者が設定されている必要があります。公式ドキュメントでも、Azure SQL Database と Azure Synapse Analytics の論理サーバーでは、Microsoft Entra 管理者を設定することで Microsoft Entra 認証が有効になると説明されています。(Microsoft Learn)
Azure ポータルでの確認手順は次の通りです。
| 手順 | 操作 | 確認すること |
| -: | ————————————– | ——————- |
| 1 | Azure ポータルで対象の SQL server を開く | データベースではなく論理サーバーを開く |
| 2 | 左メニューの「Microsoft Entra ID」を開く | Entra 管理者の表示有無を確認する |
| 3 | 管理者名と Object ID / Application ID を確認する | 想定したユーザー、グループ、アプリか |
| 4 | 必要に応じて「Set admin」または変更操作を検討する | 変更前に影響範囲を確認する |
Microsoft Entra 管理者は個人ユーザーよりも管理用グループにするほうが、退職・異動・緊急対応に強い運用になります。ただし、グループを管理者にする場合は、メンバー変更の承認フローと監査ログの確認もセットで設計してください。
ディレクトリとテナントを確認する
Microsoft Entra server principals を作成するには、Azure SQL Database と同じディレクトリの Microsoft Entra ID に属している必要があります。公式ドキュメントでも、仮想 master データベースに Microsoft Entra ログインを作成・利用するには、Azure SQL Database と同じディレクトリの Microsoft Entra ID メンバーである必要があると説明されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
- Azure ポータル右上の「ディレクトリ + サブスクリプション」で、作業中のディレクトリが正しいか
- 対象ユーザーやグループが、Azure SQL Database と同じ Microsoft Entra テナントに存在するか
- 外部ユーザーやB2Bゲストを使う場合、表示名や UPN の扱いで混乱が起きないか
- サービスプリンシパルを使う場合、アプリの表示名が重複していないか
Microsoft Entra ID では表示名の重複が許容されますが、Azure SQL 側ではプリンシパル名の一意性が求められます。公式ドキュメントでも、Microsoft Entra ID と Azure SQL のユーザー管理設計の違いにより、表示名重複がユーザー作成エラーにつながる可能性があると説明されています。(Microsoft Learn)
T-SQL で確認する基本コマンド
管理画面で状態を確認したら、次に T-SQL で実際のプリンシパルとロールを確認します。作業は仮想 master データベースとユーザーデータベースを切り替えて行う点に注意してください。
Microsoft Entra ログインを確認する
仮想 master データベースに接続し、サーバープリンシパルを確認します。
SELECT
principal_id,
name,
type_desc,
create_date,
modify_date
FROM sys.server_principals
ORDER BY name;Microsoft Entra ログインを新規作成する場合の基本形は次の通りです。公式ドキュメントでは、CREATE LOGIN login_name FROM EXTERNAL PROVIDER により Microsoft Entra ID のユーザー、グループ、アプリケーションをログインとして作成できると説明されています。(Microsoft Learn)
CREATE LOGIN [user_or_app_name]
FROM EXTERNAL PROVIDER;ただし、最初の Microsoft Entra ログインを作成できるのは Microsoft Entra 管理者です。以後は、適切に loginmanager または ##MS_LoginManager## を付与した運用担当者に委任できます。公式ドキュメントでも、最初の Microsoft Entra ログインは Microsoft Entra 管理者のみが作成でき、その後は Microsoft Entra 管理者権限または loginmanager ロールのメンバーシップが必要とされています。(Microsoft Learn)
データベースユーザーを確認する
ユーザーデータベースに接続し、ログインベースのユーザーを確認します。
SELECT
principal_id,
name,
type_desc,
authentication_type_desc,
create_date,
modify_date
FROM sys.database_principals
WHERE type_desc <> 'DATABASE_ROLE'
ORDER BY name;ログインベースのユーザーを作成する場合は、次のようにします。
CREATE USER [user_or_app_name]
FROM LOGIN [user_or_app_name];ここで混同しやすいのが、FROM LOGIN と FROM EXTERNAL PROVIDER です。
| 構文 | 作成されるもの | 使う場面 |
|---|---|---|
CREATE LOGIN ... FROM EXTERNAL PROVIDER | 仮想 master の Microsoft Entra ログイン | サーバーレベルで Entra ID 主体を管理したい |
CREATE USER ... FROM LOGIN | ログインに紐づくDBユーザー | サーバーログインをDBに割り当てたい |
CREATE USER ... FROM EXTERNAL PROVIDER | contained database user | DB単位で独立した Entra ユーザーを作りたい |
すでに contained user で運用している環境では、すぐにすべてをログインベースへ置き換える必要はありません。まず新規アプリケーションや管理者ロールから適用し、既存DBは棚卸し後に段階移行するのが現実的です。
サーバーロールで確認すべき権限
Azure SQL Database では、固定サーバーロールを使って論理サーバー単位の権限を管理できます。Microsoft Learn では、Azure SQL Database が7つの固定サーバーロールを提供しており、固定ロールの権限は変更できず、サーバーレベルログインをメンバーとして追加できると説明されています。(Microsoft Learn)
実務で特に確認頻度が高いロールは次の通りです。
| ロール | 主な用途 | 付与の判断基準 |
|---|---|---|
##MS_DatabaseConnector## | すべてのDBへの接続を許可 | 運用監視や共通接続が必要な主体に限定 |
##MS_DatabaseManager## | DBの作成・削除 | DB作成を任せる運用担当や自動化アプリに限定 |
##MS_DefinitionReader## | 定義情報の閲覧 | スキーマ調査、監査、移行ツール向け |
##MS_LoginManager## | ログイン作成・変更 | ID管理担当や自動プロビジョニング用に限定 |
##MS_SecurityDefinitionReader## | セキュリティ定義の閲覧 | 監査・セキュリティレビュー用途 |
##MS_ServerStateReader## | DMVなど状態情報の閲覧 | 監視担当、パフォーマンス分析担当 |
##MS_ServerStateManager## | サーバー状態管理操作 | 高権限のDBAまたは限定された運用自動化に限定 |
公式ドキュメントでは、##MS_DatabaseConnector## はデータベース内のユーザーアカウントなしで任意のDBに接続できるロール、##MS_LoginManager## はログインの作成・削除ができるロールとして説明されています。(Microsoft Learn)
ロールメンバーを確認する
仮想 master データベースで、ロールメンバーを確認します。
SELECT
roles.name AS role_name,
members.name AS member_name,
members.type_desc AS member_type
FROM sys.server_role_members AS srm
JOIN sys.server_principals AS roles
ON srm.role_principal_id = roles.principal_id
JOIN sys.server_principals AS members
ON srm.member_principal_id = members.principal_id
ORDER BY roles.name, members.name;ロールにメンバーを追加する場合は、次のようにします。
ALTER SERVER ROLE ##MS_ServerStateReader##
ADD MEMBER [user_or_app_name];重要なのは、ロール付与を「作業できるか」ではなく「作業後に権限が残り続けてよいか」で判断することです。例えば一時的な移行作業のために ##MS_DatabaseManager## を付与する場合、作業完了後に削除する期限と担当者をチケットに残しておくべきです。
サーバーロールの過剰付与に注意する
固定サーバーロールは便利ですが、影響範囲は広くなります。特に ##MS_DatabaseConnector## は、接続可能なDBの範囲を広げるため、個別DBごとのアクセス制御と矛盾しないか確認が必要です。
Microsoft Learn では、##MS_DatabaseConnector## による CONNECT 権限は、対象DBに対応するユーザーを作成して DENY CONNECT することで上書きできると説明されています。(Microsoft Learn)
実務では、次のような判断をおすすめします。
| ケース | 推奨判断 |
|---|---|
| 監視ツールが全DBの状態を読む | ##MS_ServerStateReader## と必要DBのユーザー作成を検討 |
| アプリが特定DBだけに接続する | サーバーロールよりDB単位のユーザー・ロールを優先 |
| 自動化アプリがDBを作成する | ##MS_DatabaseManager## をサービスプリンシパルに限定付与 |
| ID管理ツールがログインを作る | ##MS_LoginManager## を専用アプリまたは管理グループに限定 |
| 開発者に一時的な調査権限を与える | 期限付き申請と削除確認をセットにする |
利用条件と前提条件
Microsoft Entra Server Principals and Server Roles for Azure SQL Database を有効に使うには、いくつかの前提条件があります。
Microsoft Entra 管理者が必要
最初に確認すべき条件は、Microsoft Entra 管理者の設定です。Microsoft Entra 管理者が設定されていない論理サーバーでは、Microsoft Entra 認証を前提とするログイン作成が進められません。
また、SQL Server 管理者と Microsoft Entra 管理者の役割は同じではありません。公式ドキュメントでは、SQL server admin は Microsoft Entra ログインやユーザーを作成できないと明記されています。(Microsoft Learn)
この点は運用現場で非常に間違えやすいポイントです。Azure ポータルで「SQL Server Contributor」や「SQL DB Contributor」を持っていても、それだけで Azure SQL Database 内に Microsoft Entra ユーザーとして接続できるわけではありません。Azure RBAC は Azure リソース管理の権限であり、データベース接続・SQL実行権限とは別に考える必要があります。
Microsoft Graph 権限を確認する
Microsoft Entra ID のユーザーやグループ、アプリケーションを SQL 側で扱うには、Microsoft Graph への参照権限が関係する場合があります。Microsoft Learn では、Azure SQL Database と Azure Synapse Analytics では User.Read.All、GroupMember.Read.All、Application.Read.All などのきめ細かい Microsoft Graph API 権限をサーバー ID に直接割り当てる方法が推奨され、Directory Readers はより広い代替手段として扱われています。(Microsoft Learn)
確認観点は次の通りです。
| 確認項目 | 内容 |
|---|---|
| サーバー ID | 論理サーバーにマネージド ID を使う設計か |
| Graph 権限 | 必要最小限の API 権限で足りるか |
| Directory Readers | 広範な権限として使う必要があるか |
| 承認者 | テナント管理者、Privileged Role Administrator など誰が承認するか |
| 監査 | 権限付与と変更履歴をどこで追跡するか |
開発環境では Directory Readers を広く使って問題が見えにくいことがありますが、本番環境では最小権限の原則に沿って、必要な Graph 権限だけを割り当てる設計を優先してください。
Microsoft Entra グループの制限を確認する
Microsoft Entra グループをサーバープリンシパルとして使う場合は、個人ユーザーやアプリケーションとは違う制限に注意が必要です。公式ドキュメントでは、Azure SQL Database と Azure Synapse Analytics において Microsoft Entra group logins には既知の制限があり、Azure SQL Database server roles は Microsoft Entra groups ではサポートされないと説明されています。(Microsoft Learn)
そのため、次のように使い分けると安全です。
| 対象 | 向いている使い方 | 注意点 |
|---|---|---|
| Entra ユーザー | DBAや管理者の明示的なログイン | 異動・退職時の棚卸しが必要 |
| Entra グループ | DB内ロールへのアクセス管理 | サーバーロール付与の制限を確認 |
| サービスプリンシパル | 自動化、CI/CD、管理ツール | 表示名重複、資格情報管理、監査が重要 |
| マネージド ID | Azure リソース間の認証 | Graph権限やSQL側のユーザー作成が必要 |
特に「Entra グループを作ってサーバーロールに入れれば一括管理できる」と考えると、制限にぶつかる可能性があります。サーバーロールを使う場合は、対象がユーザーなのか、グループなのか、アプリケーションなのかを事前に確認してください。
設定確認の実務チェックリスト
本番環境で Microsoft Entra Server Principals and Server Roles for Azure SQL Database を確認する場合は、次の順番で進めると抜け漏れを減らせます。
| 順番 | 確認項目 | 確認方法 | 完了基準 |
| -: | ——— | ————————————- | ————————- |
| 1 | 対象サーバーの特定 | Azure ポータルのDB概要から server name を確認 | サブスクリプション、RG、サーバー名が記録済み |
| 2 | GA対象か確認 | Azure SQL Database か確認 | Synapse などプレビュー対象と混同していない |
| 3 | Entra 管理者 | SQL server の Microsoft Entra ID 画面を確認 | 管理者または管理グループが設定済み |
| 4 | テナント | ディレクトリ + サブスクリプションを確認 | 対象IDが同じテナントに存在 |
| 5 | Graph 権限 | サーバー ID と API 権限を確認 | 必要最小限の権限が設計済み |
| 6 | ログイン | sys.server_principals を確認 | 作成済みログインと用途が一致 |
| 7 | サーバーロール | sys.server_role_members を確認 | 過剰なロール付与がない |
| 8 | DBユーザー | 各DBの sys.database_principals を確認 | 必要DBにだけユーザーが存在 |
| 9 | 接続テスト | 管理者・アプリ・監視アカウントで確認 | 想定DBに接続でき、不要DBへ接続できない |
| 10 | 周知 | 利用者・運用者へ変更点を共有 | 接続方法、申請方法、問い合わせ先が明確 |
チェックリストの目的は、設定を「できているか」だけでなく、「不要な権限が残っていないか」を確認することです。特に本番環境では、ログイン作成やDB作成の権限を持つ主体を月次または四半期ごとに棚卸しする運用をおすすめします。
よくある設定ミスと対処法
SQL 管理者で Entra ログインを作ろうとして失敗する
SQL server admin で接続できるからといって、Microsoft Entra ログインを作成できるとは限りません。Microsoft Entra ログインやユーザーの作成は、Microsoft Entra 管理者または適切なロールを持つ主体で行う必要があります。公式ドキュメントでも、SQL admin や SQL user は CREATE LOGIN ... FROM EXTERNAL PROVIDER や CREATE USER ... FROM EXTERNAL PROVIDER などの Microsoft Entra 操作を実行できないとされています。(Microsoft Learn)
対処法は、Azure ポータルで Microsoft Entra 管理者を確認し、その管理者で接続して初回ログインを作成することです。その後、必要に応じて ##MS_LoginManager## を委任先に付与します。
FROM LOGIN と FROM EXTERNAL PROVIDER を混同する
ログインベースのユーザーを作るつもりで CREATE USER ... FROM EXTERNAL PROVIDER を実行すると、contained user として作成されます。SSMS のスクリプト生成でも、同名の Microsoft Entra ログインが master に存在するかを確認せず、contained database user の作成スクリプトを生成する場合があると公式ドキュメントで説明されています。(Microsoft Learn)
対処法は、作業前に仮想 master でログインの存在を確認し、ユーザーデータベースでは明示的に FROM LOGIN を使うことです。
-- master でログイン確認
SELECT name, type_desc
FROM sys.server_principals
WHERE name = N'user_or_app_name';
-- user database でログインベースのユーザー作成
CREATE USER [user_or_app_name]
FROM LOGIN [user_or_app_name];権限変更がすぐ反映されない
Microsoft Entra ログインの無効化やロール変更をしても、既存の接続にはすぐ反映されない場合があります。公式ドキュメントでは、Microsoft Entra ログインの権限変更は通常、次回接続時に反映され、既存接続には影響しないと説明されています。即時反映が必要な場合は、認証キャッシュや TokenAndPermUserStore キャッシュのクリアが案内されています。(Microsoft Learn)
緊急時には、次のコマンドを検討します。
DBCC FLUSHAUTHCACHE;
DBCC FREESYSTEMCACHE('TokenAndPermUserStore') WITH NO_INFOMSGS;ただし、キャッシュクリアは影響範囲を理解したうえで実行してください。通常運用では、変更後に新規接続で検証し、既存接続が残るアプリケーションでは接続プールの再起動も検討します。
Entra 管理者とログインが重複する
Microsoft Entra 管理者としてアクセスできるアカウントに対して別途ログインを作成しても、期待したロール検証にならない場合があります。公式ドキュメントでは、Microsoft Entra 管理者はログインより優先され、同じアカウントにログインを作っても効果がない場合があると説明されています。(Microsoft Learn)
検証用には、Entra 管理者ではない別ユーザーまたは検証用サービスプリンシパルを使ってください。管理者本人で接続テストをすると、一般ユーザーの権限不足や過剰権限を見落としやすくなります。
ユーザー周知で伝えるべきポイント
この機能変更は、エンドユーザーにとっては「ログイン方法が少し変わる」程度に見えるかもしれません。しかし、管理者・開発者・アプリ運用者には影響があります。周知では、専門用語を並べるよりも、実際に何をすればよいかを伝えることが大切です。
管理者向けの周知内容
管理者には、権限申請と棚卸しの変更点を伝えます。
| 対象者 | 伝える内容 |
|---|---|
| DBA | 仮想 master に Microsoft Entra ログインを作成できること、サーバーロールの付与基準 |
| Azure管理者 | Entra 管理者、サーバー ID、Graph 権限の確認が必要なこと |
| セキュリティ担当 | サーバーロールの棚卸し対象が増えること |
| ヘルプデスク | 接続不可時に確認すべきサーバー名、テナント、認証方式 |
| 開発リーダー | アプリ接続にサービスプリンシパルやマネージド ID を使う場合の申請手順 |
特に ##MS_LoginManager## と ##MS_DatabaseManager## は、操作範囲が広いため、申請理由・有効期限・承認者を残す運用にしてください。
開発者・アプリ担当者向けの周知内容
開発者には、接続文字列やDBユーザー作成方法の違いを伝えると混乱が減ります。
| 変更点 | 開発者に伝える表現 |
|---|---|
| Microsoft Entra ログインの導入 | Entra ID のアカウントやアプリを、SQLのサーバーレベルログインとして扱える |
| DBユーザー作成 | 新規DBでは FROM LOGIN を使う可能性がある |
| 接続エラー時 | Azure RBAC があってもSQL接続権限があるとは限らない |
| 検証方法 | 本番相当のユーザー・アプリIDで接続テストする |
| 既存DB | すぐに全DBが新方式へ変わるとは限らない |
周知文の例は次の通りです。
Azure SQL Database で Microsoft Entra server principals が GA になったため、
今後は Microsoft Entra ID のユーザーやアプリケーションを仮想 master 上のログインとして作成し、
必要なデータベースにログインベースのユーザーを割り当てる運用を段階的に採用します。
既存のDBアクセスが直ちに変更されるわけではありません。
新規アプリケーション、運用自動化、監視アカウントから順に適用します。
接続エラーが発生した場合は、対象サーバー名、データベース名、認証方式、利用しているユーザーまたはアプリIDを添えて問い合わせてください。導入判断の考え方
Microsoft Entra Server Principals and Server Roles for Azure SQL Database は、すべての環境で即時導入すべき機能というより、権限管理をサーバー単位で整理したい環境に向いています。
導入を優先したい環境
次の条件に当てはまる場合は、早めに検証する価値があります。
- 複数DBを同じ論理サーバーで管理している
- 監視、移行、自動化ツールの権限管理が煩雑になっている
- SQL認証を減らし、Microsoft Entra 認証中心へ寄せたい
- サービスプリンシパルやマネージド ID でDB管理を自動化したい
- DBごとの contained user 管理が増えすぎて棚卸しが難しい
公式ドキュメントでも、Microsoft Entra server principals の利点として、Azure SQL Database server roles による権限管理、SQLログインと Microsoft Entra ログインの機能的な近さ、Microsoft Entra-only authentication、geo-replica 対応、自動化への活用などが挙げられています。(Microsoft Learn)
慎重に進めたい環境
一方で、次の環境ではいきなり本番標準にするのではなく、検証環境での確認を先に行ってください。
- 既存DBごとに細かい権限設計があり、サーバー横断の権限を増やしたくない
- Microsoft Entra グループ中心でサーバーロール管理をしようとしている
- 外部ユーザーや複数テナントのIDを多用している
- 接続プールや長時間接続が多く、権限変更の即時反映が重要
- 監査ルールやアクセス申請フローがまだ整っていない
特に本番DBでは、まず「確認だけ」を行い、ログイン作成やロール付与は変更管理プロセスに乗せるべきです。
まとめ：まずは設定確認と権限棚卸しから始める
Microsoft Entra Server Principals and Server Roles for Azure SQL Database の GA により、Azure SQL Database でも Microsoft Entra ID のユーザー、アプリケーション、サービスプリンシパルをサーバーレベルのログインとして扱い、固定サーバーロールで管理する運用が取りやすくなりました。
まず実施すべきことは、次の4点です。
- Azure ポータルで対象の論理サーバーと Microsoft Entra 管理者を確認する
- 仮想
masterで Microsoft Entra ログインとサーバーロールメンバーを棚卸しする - 各データベースで contained user と login-based user の混在状況を確認する
- 管理者、開発者、セキュリティ担当に新しい申請・確認手順を周知する
新機能を入れること自体が目的ではありません。SQL認証への依存を減らし、Microsoft Entra ID を中心に、誰がどのDBへ、どの権限で接続できるのかを説明できる状態にすることが本来の目的です。まずは検証環境で CREATE LOGIN ... FROM EXTERNAL PROVIDER、CREATE USER ... FROM LOGIN、ALTER SERVER ROLE の流れを確認し、本番環境では最小権限と棚卸しルールをセットで導入してください。
コメント