Azure SQLで「Server-Level Roles – SQL Server」の更新内容を確認するうえで重要なのは、単にロール名を覚えることではありません。特に見るべきポイントは、##MS_DatabaseManager## の説明が実態に合わせて明確化され、Azure SQL Databaseでは従来の master データベース内の dbmanager ではなく、サーバーレベルロールを使う方向がより分かりやすくなった点です。公式リポジトリの更新では、##MS_DatabaseManager## が「データベースを作成でき、所有するデータベースを削除できる」ロールとして整理され、割り当て時には最小権限と監視が必要であることも強調されています。(GitHub)
Azure SQLの管理者や開発者は、既存のログインに過剰な権限を与えていないか、CI/CDや移行スクリプトが古い dbmanager 前提になっていないか、監視・ログイン管理・データベース作成の権限を適切に分離できているかを確認する必要があります。
Server-Level Rolesとは何か
Server-Level Rolesは、SQL ServerやAzure SQLの権限管理で使われるサーバー単位のロールです。ロールは複数のプリンシパル、つまりログインやアカウントをまとめて管理するための仕組みで、個別ユーザーに権限を直接付与するよりも管理しやすくなります。SQL Serverの公式ドキュメントでは、server-level rolesはサーバー全体に及ぶ権限スコープを持つセキュリティプリンシパルとして説明されています。(Microsoft Learn)
ただし、Azure SQLではサービスの種類によって前提が異なります。Azure SQL Databaseでは「サーバー」は論理的な概念であり、通常のSQL Serverと同じ意味でサーバーレベル権限を自由に付与できるわけではありません。その代わり、Azure SQL Databaseでは権限管理を簡素化するために、##MS_ で始まり ## で終わる固定サーバーレベルロールが用意されています。(Microsoft Learn)
一方、Azure SQL Managed InstanceはSQL Serverに近い管理モデルを持ち、固定またはカスタムのサーバーレベルロールを使ってインスタンス単位の権限管理を行えます。Azure SQL DatabaseとManaged Instanceを同じ「Azure SQL」として扱うと、ロールの可否や権限範囲を誤解しやすいため、まず利用中のサービスを切り分けることが重要です。(Microsoft Learn)
今回の更新で押さえるべき変更点
今回の更新は、既存環境に対して突然新しい権限が自動付与されるような変更というより、##MS_DatabaseManager## の権限説明が実態に即して明確化されたものと捉えるのが自然です。公式GitHubの履歴では、##MS_DatabaseManager## の説明を「実際の動作の影響を反映するために書き換えた」と記録されており、差分はこのロールの説明行に集中しています。(GitHub)
| 確認項目 | 更新後に意識すべき点 | 実務上の影響 |
|---|---|---|
##MS_DatabaseManager## | データベースを作成でき、所有するデータベースを削除できるロールとして説明が明確化 | デプロイ用ログインや運用担当者への付与範囲を見直す |
| データベース所有者 | このロールのメンバーが作成したデータベースでは、そのメンバーが所有者になり、dbo として接続できる | 作成後の権限が想定以上に強くならないか確認する |
dbmanager との関係 | Azure SQL Databaseでは master の dbmanager より ##MS_DatabaseManager## の利用が推奨される方向 | 古い移行手順や社内手順書を更新する |
| 最小権限 | 権限昇格につながる可能性があるため、付与対象を絞り監視する | 人間用アカウントと自動化用アカウントを分ける |
特に注意したいのは、##MS_DatabaseManager## が単なる「データベース作成係」ではないことです。作成したデータベースの所有者になれるため、そのデータベース内では非常に強い権限を持ちます。公式ドキュメントでも、作成者は dbo ユーザーとして接続でき、dbo はデータベース内のすべての権限を持つと説明されています。(GitHub)
Azure SQL Databaseで使える主な固定サーバーレベルロール
Azure SQL Databaseでは、サーバーレベルロールとして7つの固定ロールが提供されています。SQL Server 2022には追加の ##MS_ ロールがありますが、Azure SQL Databaseで利用できるものは同一ではありません。公式ドキュメントでは、Azure SQL Databaseで提供される固定サーバーロールは7つとされています。(Microsoft Learn)
| ロール | 主な用途 | 割り当て時の判断基準 |
|---|---|---|
##MS_DatabaseConnector## | すべてのデータベースへ接続できるようにする | 複数DBを横断して作業する管理・監視用途に限定する |
##MS_DatabaseManager## | データベース作成、所有するデータベースの削除 | CI/CD、DB作成担当、検証環境の管理などに限定する |
##MS_LoginManager## | ログインの作成・変更・削除 | ユーザー管理担当に限定し、データ操作権限とは分ける |
##MS_ServerStateReader## | DMVなどサーバー状態の参照 | パフォーマンス監視や調査担当に向く |
##MS_ServerStateManager## | サーバー状態の参照に加え、一部管理操作を実行 | キャッシュクリアなど影響の大きい操作を理解した管理者向け |
##MS_DefinitionReader## | 定義情報やカタログビューの参照 | スキーマ把握、移行調査、レビュー用途に向く |
##MS_SecurityDefinitionReader## | セキュリティ関連定義の参照 | 監査・セキュリティレビュー用途に限定する |
ここで避けたいのは、「読めるだけだから安全」と考えることです。定義情報やセキュリティ定義を参照できるロールは、攻撃者にとっても有益な情報を含む場合があります。たとえば、テーブル構造、権限設計、ログイン情報の一部が見えることで、次の攻撃経路を推測しやすくなる可能性があります。監視ツールや開発者に付与する場合も、業務上必要なロールだけを選ぶべきです。
SQL Serverの従来ロールとAzure SQL Databaseの違い
SQL Serverの固定サーバーロールには、sysadmin、serveradmin、securityadmin、dbcreator、bulkadmin などがあります。しかし、SQL Server 2022より前から存在するこれらの固定サーバーレベルロールは、Azure SQL Databaseでは利用できません。Azure SQL Databaseでは、それらに相当する権限管理のために特別なサーバーロールが用意されています。(Microsoft Learn)
そのため、オンプレミスSQL ServerからAzure SQL Databaseへ移行する場合、次のような置き換えを検討します。
| 旧環境での考え方 | Azure SQL Databaseでの考え方 |
|---|---|
sysadmin を使って何でも実行する | サーバー管理者またはMicrosoft Entra管理者を最小限にする |
dbcreator でDB作成を任せる | ##MS_DatabaseManager## を検討する |
securityadmin でログイン管理も権限付与も行う | ##MS_LoginManager## とDB内ロールを分離する |
| 監視担当に広い管理者権限を付ける | ##MS_ServerStateReader## など参照系ロールに絞る |
master の dbmanager を使う | 新規設計では ##MS_DatabaseManager## を優先して検討する |
特に securityadmin 相当の考え方には注意が必要です。SQL Serverの公式ドキュメントでは、securityadmin は多くのサーバー権限を割り当てられるため、実質的に sysadmin と同等に扱うべきだとされています。SQL Server 2022以降では、より限定的な ##MS_LoginManager## の利用が選択肢として示されています。(Microsoft Learn)
管理者が確認すべき設定
Azure SQLの管理者は、まず「誰が何をできる状態か」を棚卸しする必要があります。特に確認すべきなのは、master データベースでのログイン、サーバーレベルロールのメンバー、各ユーザーデータベース内のユーザーとロールです。
Azure SQL Databaseでは、サーバーレベルロールのメンバー確認や変更は仮想 master データベースで実行します。公式ドキュメントでも、ALTER SERVER ROLE によるメンバー追加は仮想 master データベースで実行する例が示されています。(Microsoft Learn)
-- 仮想 master データベースで実行
SELECT
roles.name AS role_name,
members.name AS member_name
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;##MS_DatabaseManager## へメンバーを追加する場合は、次のように実行します。
-- 仮想 master データベースで実行
ALTER SERVER ROLE ##MS_DatabaseManager##
ADD MEMBER [deploy_login];ただし、付与して終わりでは不十分です。付与後は、対象ログインで実際にデータベースを作成できるか、不要な既存データベースへアクセスできないか、作成したデータベースを削除できる範囲が想定通りかを検証してください。
確認の順序は次の流れが実務的です。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 現在のサーバーロールメンバーを一覧化 | master 以外で確認して結果が不足する |
| 2 | dbmanager など旧来の管理ロールを確認 | 古い移行手順のまま残っている |
| 3 | 人間用・アプリ用・CI/CD用ログインを分類 | アプリ実行ログインに管理権限が混在する |
| 4 | 必要なロールだけを付与 | 「念のため」で広い権限を付ける |
| 5 | 付与後に再接続して動作確認 | 既存セッションに変更が反映されず誤判定する |
| 6 | 監査ログや変更履歴を確認 | 誰がロールを追加したか追跡できない |
開発者とDevOps担当者が注意すべき移行・展開ポイント
開発者やDevOps担当者にとって重要なのは、アプリケーションの実行ログインとデプロイ用ログインを分けることです。
悪い例は、アプリケーションの接続文字列で使うログインに ##MS_DatabaseManager## を付与し、そのログインでマイグレーション、テーブル作成、通常のデータ読み書きをすべて行わせる設計です。この状態では、アプリケーションの脆弱性やシークレット漏えいが起きたときに、データベース作成や削除まで影響が広がる可能性があります。
望ましい設計は、次のように役割を分けることです。
| 用途 | 推奨される考え方 |
|---|---|
| アプリ実行ログイン | 必要なDB内権限だけを付与する。原則としてサーバーレベルロールは付けない |
| マイグレーション用ログイン | スキーマ変更に必要な権限に限定し、恒久的な強権限を避ける |
| DB作成用ログイン | ##MS_DatabaseManager## を検討するが、利用者と利用時間を限定する |
| 監視用ログイン | ##MS_ServerStateReader## など参照系ロールを検討する |
| ログイン管理用ログイン | ##MS_LoginManager## を検討し、データ操作権限とは分離する |
CI/CDでAzure SQL Databaseを展開している場合は、パイプライン内のSQLスクリプトを確認してください。特に、次のような記述が残っている場合は見直し対象です。
-- 古い手順で使われている可能性がある例
ALTER ROLE dbmanager ADD MEMBER [deploy_login];新しい設計では、Azure SQL Databaseのサーバーレベルロールとして ##MS_DatabaseManager## を使えるかを確認し、次のような形へ整理します。
-- 仮想 master データベースで実行
ALTER SERVER ROLE ##MS_DatabaseManager##
ADD MEMBER [deploy_login];ただし、単純に置き換えるだけでは不十分です。dbmanager と ##MS_DatabaseManager## は管理単位が異なります。移行時は、対象ログインがどのデータベースを作成し、どのデータベースを所有し、どのデータベースへ接続できる必要があるのかをテスト環境で確認してから本番へ反映してください。
ロール変更が反映されないときの注意点
Azure SQL Databaseでは、サーバーレベルロールの割り当て変更がすぐに見えないことがあります。公式ドキュメントでは、ロール割り当てが有効になるまで最大5分かかる場合があり、既存セッションでは接続を閉じて再接続するまで変更が反映されないと説明されています。(Microsoft Learn)
そのため、権限変更後の動作確認では次の点を守るとトラブルを避けやすくなります。
- 権限付与後、対象ユーザーで必ず再接続する
- 接続プールを使うアプリでは、古い接続が残っていないか確認する
- 自動テストでは、権限付与直後のテスト失敗を「権限不足」と即断しない
- 必要に応じて管理者が対象DBで
DBCC FLUSHAUTHCACHEを検討する - 本番反映前に、待ち時間を含めたデプロイ手順にする
また、IS_SRVROLEMEMBER() はAzure SQL Databaseの master データベースではサポートされないとされています。ロール確認用のスクリプトをオンプレミスSQL Serverから流用している場合、Azure SQL Databaseでは sys.server_role_members などのカタログビューを使う設計にしておくと安全です。(Microsoft Learn)
権限設計でよくある失敗
Azure SQLのServer-Level Rolesで失敗しやすいのは、ロールを「便利な管理者権限」として広く配ってしまうケースです。特に次のパターンは見直しが必要です。
| 失敗例 | なぜ危険か | 改善策 |
|---|---|---|
開発者全員に ##MS_DatabaseManager## を付与 | 誰でもDB作成や所有DB削除ができ、責任範囲が曖昧になる | DB作成担当または申請制にする |
| アプリログインにサーバーレベルロールを付与 | アプリ侵害時の影響範囲が広がる | アプリにはDB内の最小権限だけを付与する |
| 監視ツールに管理系ロールを付与 | 参照だけでよいのに操作権限まで持つ | ##MS_ServerStateReader## など参照系に絞る |
master の古いロールだけを見て判断 | サーバーレベルロールのメンバーを見落とす | sys.server_role_members も確認する |
| 権限変更直後に既存接続でテスト | 反映待ちやセッションキャッシュで誤判定する | 再接続してから確認する |
| ログイン管理とデータ管理を同じ人に集中 | 職務分掌が崩れ、監査しにくい | ##MS_LoginManager## とDB内権限を分離する |
実務では、権限を「人」ではなく「作業」にひも付けて考えると整理しやすくなります。たとえば「本番DBを作成する」「ログインを追加する」「クエリ性能を調査する」「スキーマをレビューする」は、それぞれ必要なロールが異なります。1人が複数作業を担当する場合でも、常時すべての権限を持つ必要があるとは限りません。
既存環境で今すぐ確認すべきチェックリスト
Azure SQL環境を運用している場合は、次の順番で確認すると効率的です。
| チェック項目 | 確認内容 |
|---|---|
| 利用サービス | Azure SQL Databaseか、Azure SQL Managed Instanceか |
| 管理者アカウント | サーバー管理者、Microsoft Entra管理者が最小限か |
| サーバーロール | ##MS_ ロールのメンバーが業務上必要な範囲か |
| 旧ロール | master の dbmanager や loginmanager に不要なメンバーが残っていないか |
| デプロイ用ログイン | CI/CDのログインに過剰な権限がないか |
| アプリ用ログイン | サーバーレベルロールが付いていないか |
| 監視用ログイン | 参照権限だけで足りる設計になっているか |
| 反映確認 | 権限変更後に再接続して検証しているか |
| 監査 | ロール変更やログイン作成を追跡できるか |
特に ##MS_DatabaseManager## は、検証環境では便利ですが、本番環境では付与対象を慎重に選ぶべきロールです。データベース作成が必要な担当者や自動化アカウントに限定し、不要になったら外す運用にしておくと、権限の肥大化を防げます。
まとめ：Azure SQLのServer-Level Rolesは「最小権限」で見直す
Server-Level Roles – SQL Serverの更新で最も重要なのは、Azure SQLの権限管理をより細かく、実態に即して設計することです。特に ##MS_DatabaseManager## は、データベース作成だけでなく、作成したデータベースの所有や削除に関わるため、安易に付与すると影響範囲が大きくなります。
まずは、Azure SQL DatabaseとAzure SQL Managed Instanceのどちらを使っているかを確認し、次に master と各ユーザーデータベースのロールメンバーを棚卸ししましょう。そのうえで、dbmanager など旧来の手順を使っているスクリプトを見直し、##MS_DatabaseManager##、##MS_LoginManager##、##MS_ServerStateReader## などを作業内容ごとに使い分けるのが現実的です。
管理者は「誰に権限を与えるか」ではなく、「どの作業にどの最小権限が必要か」を基準に整理してください。開発者やDevOps担当者は、アプリ実行ログインとデプロイ用ログインを分け、権限変更後は再接続を含めて検証することが次の具体的なアクションになります。
コメント