Microsoft Entra認証をAzure SQL Database、Azure SQL Managed Instance、Azure Synapse Analyticsで使う場合、最初に確認すべきポイントは「Microsoft Entra管理者の設定」「Microsoft Graph権限」「SQL上のプリンシパル作成」「接続方式」の4つです。特に2026年6月初旬の公式更新では、Microsoft Entraサーバープリンシパル、つまりログインの扱いが重要になっています。Azure SQL DatabaseとAzure SQL Managed Instanceでは一般提供として扱われ、Azure Synapse Analyticsでは引き続きパブリックプレビューとされています。(GitHub)
この記事では、Microsoft Entra認証の構成手順だけでなく、管理者・開発者が見落としやすい影響範囲、移行時の判断基準、展開前のチェック項目を実務目線で整理します。SQL認証からパスワードレス認証へ移行したい場合や、マネージドID・サービスプリンシパルでAzure SQLへ接続したい場合は、設定前に全体像を押さえておくことが重要です。
Microsoft Entra認証の更新で押さえるべき結論
Microsoft Entra認証は、Azure SQLへの接続をMicrosoft Entra IDのユーザー、グループ、サービスプリンシパル、マネージドIDで制御する仕組みです。従来のSQLユーザー名・パスワードに依存せず、条件付きアクセス、MFA、グループ管理、マネージドIDによるパスワードレス接続を活用できます。Microsoft Learnでは、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analyticsに対してMicrosoft Entra IDを使った認証方法が説明されています。(Microsoft Learn)
今回のポイントを実務向けにまとめると、次の通りです。
| 確認項目 | 管理者・開発者が見るべきポイント |
|---|---|
| Microsoft Entra管理者 | Azure SQLリソースごとに設定が必要。削除するとMicrosoft Entra認証接続が無効になる |
| Microsoft Entraサーバープリンシパル | Azure SQL DatabaseとAzure SQL Managed Instanceでは一般提供、Azure Synapse Analyticsではパブリックプレビュー |
| Microsoft Graph権限 | Azure SQL Database / Synapseは細かなGraph API権限の付与が推奨。SQL Managed InstanceはDirectory Readersロールまたは同等権限が必要 |
| SQL上のユーザー作成 | Azure RBACだけではデータベース接続権限にならない。SQL側にプリンシパルを作成する必要がある |
| アプリ接続 | マネージドIDやAzure Identityライブラリを使う構成では、接続文字列・権限・実行環境をセットで確認する |
特に誤解されやすいのは、Azure RBACの「SQL Server Contributor」や「SQL DB Contributor」があればデータベースに接続できる、という理解です。Microsoft Entra認証でクエリを実行するには、対象データベースにMicrosoft Entraプリンシパルを作成しておく必要があります。Azure RBACは管理操作の権限であり、データベース内の接続・クエリ実行権限とは別物です。(Microsoft Learn)
影響範囲はAzure SQL Database、SQL Managed Instance、Azure Synapse Analytics
対象になるのは、主に次の3つです。
| 対象サービス | 影響する主な設定 |
|---|---|
| Azure SQL Database | 論理サーバーのMicrosoft Entra管理者、サーバーID、Graph権限、データベースユーザー |
| Azure SQL Managed Instance | インスタンスのMicrosoft Entra管理者、Directory Readersロール、ログイン、SQL Agentやバックアップなどの運用権限 |
| Azure Synapse Analytics | Microsoft Entra管理者、Graph権限、データベースユーザー、ログイン機能のプレビュー扱い |
Azure SQL DatabaseとAzure Synapse Analyticsでは、論理サーバーにMicrosoft Entra管理者を設定するとMicrosoft Entra認証が有効になります。Azure SQL Managed Instanceでは、マネージドインスタンスにMicrosoft Entra管理者を設定することでMicrosoft Entra認証が有効になります。いずれもAzureポータル、PowerShell、Azure CLI、REST APIから設定できます。(Microsoft Learn)
本番環境で注意したいのは、Microsoft Entra管理者の設定が単なる「管理画面上の表示」ではなく、認証機能そのものの入口になる点です。論理サーバーやインスタンスからMicrosoft Entra管理者を削除すると、既存のMicrosoft Entraユーザーにデータベース権限が残っていても、Microsoft Entra認証ベースの接続はできなくなります。(Microsoft Learn)
今回の重要変更：Azure SQL DatabaseのMicrosoft Entraログインが一般提供扱いに
2026年6月初旬の公開履歴では、Microsoft Entraサーバープリンシパル、つまりMicrosoft Entraログインに関する記述が更新されています。変更前はAzure SQL DatabaseとAzure Synapse Analyticsがパブリックプレビューとして扱われていましたが、更新後はAzure SQL Database、Azure SQL Managed Instance、SQL Server 2022以降で一般提供、Azure Synapse Analyticsではパブリックプレビューという整理になっています。(GitHub)
これは、Azure SQL DatabaseでMicrosoft Entraログインを使った設計を本格的に採用しやすくなったことを意味します。たとえば、複数データベースにまたがる権限管理や、サーバーレベルの権限をMicrosoft Entra IDに紐づけたい構成では、従来の包含データベースユーザーだけでなく、ログインベースのユーザー設計も選択肢になります。
包含データベースユーザーとログインベースユーザーの違い
Microsoft Entra認証では、SQL側に作成するプリンシパルの考え方が重要です。大きく分けると、包含データベースユーザーとログインベースユーザーがあります。
| 種類 | 特徴 | 向いているケース |
|---|---|---|
| 包含データベースユーザー | masterデータベースのログインに依存しない。データベース単位で完結する | 単一DBアプリ、移行しやすさを重視するDB、最小構成 |
| ログインベースユーザー | サーバーまたはインスタンスのMicrosoft Entraログインに基づく。サーバーレベル権限を継承できる | 複数DB運用、サーバーレベル権限管理、SQL Managed Instanceに近い運用 |
| Microsoft Entraグループ | 個人ではなくグループに権限を付与する | 人事異動・チーム変更が多い組織、運用負荷を下げたい環境 |
包含データベースユーザーは、次のように作成します。
CREATE USER [[email protected]] FROM EXTERNAL PROVIDER;Microsoft Entraグループを使う場合は、グループの表示名で作成します。
CREATE USER [DBA_Group] FROM EXTERNAL PROVIDER;ログインベースユーザーの場合は、サーバー側のログインに基づいてデータベースユーザーを作成します。
CREATE USER [appName] FROM LOGIN [appName];公式ドキュメントでは、SQL DatabaseまたはAzure Synapse Analytics内のデータベースにMicrosoft Entra認証で接続するには、そのIDに対応するプリンシパルがデータベース上に構成され、少なくともCONNECT権限を持つ必要があるとされています。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft Entra認証の構成では、いきなりアプリの接続文字列を変更するのではなく、まず管理側の土台を確認します。順番を間違えると、ユーザー作成時にGraph権限エラーが出たり、フェールオーバー後に接続できなくなったりします。
Microsoft Entraテナントと対象リソースを確認する
前提として、ユーザーやグループが登録されたMicrosoft Entraテナントと、既存のAzure SQLリソースが必要です。オンプレミスActive Directoryと連携している環境では、同期・フェデレーション・ゲストユーザーの扱いも確認対象になります。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認項目 | 見る場所 | 失敗しやすいポイント |
|---|---|---|
| テナント | Azureポータルのディレクトリとサブスクリプション | 別テナントのユーザーを直接SQLユーザー化しようとする |
| SQLリソース | Azure SQL Database / SQL Managed Instance / Synapse | 論理サーバーとデータベースを混同する |
| 管理者候補 | Microsoft Entra IDのユーザー・グループ・アプリ | 表示名重複、退職者アカウント、個人アカウントへの依存 |
| 接続元 | 開発端末、CI/CD、App Service、Functionsなど | ローカルでは接続できるが本番のマネージドIDに権限がない |
外部テナントのユーザーを使う場合、Azureサブスクリプションに関連付けられたテナントとは異なるMicrosoft EntraテナントのIDを直接データベースユーザーとして作成することはできません。必要に応じて外部ユーザーとして取り込むか、Microsoft Entraグループ経由で権限を設計します。(Microsoft Learn)
Microsoft Entra管理者は個人ではなくグループを基本にする
Microsoft Entra管理者は、Azure SQLにおいて最初に他のMicrosoft Entraログインやユーザーを作成できる重要なIDです。管理者アカウントは各ユーザーデータベースでdb_ownerとなり、強い権限を持ちます。(Microsoft Learn)
実務では、個人ユーザーを直接Microsoft Entra管理者にするより、DBA用のMicrosoft Entraグループを設定する方が安全です。
たとえば、次のような設計です。
| 悪い例 | 推奨例 |
|---|---|
[email protected]を直接管理者にする | SQL-DBA-Adminsグループを管理者にする |
開発者個人に直接db_ownerを付ける | 開発・運用ロールごとのDBロールに割り当てる |
| 退職・異動時にSQL側を手作業で変更 | Microsoft Entraグループのメンバー管理で対応 |
グループをMicrosoft Entra管理者にすると、メンバー変更をMicrosoft Entra側で完結しやすくなります。Azure SQL側のデータプレーン操作に依存せず、ID管理の責任範囲を明確にできる点も大きな利点です。(Microsoft Learn)
Microsoft Graph権限の考え方
Microsoft Entra認証でつまずきやすいのが、Microsoft Graph権限です。SQL側でCREATE USER ... FROM EXTERNAL PROVIDERやCREATE LOGINを実行するとき、Azure SQLはMicrosoft Entra ID上のユーザー、グループ、アプリケーションを確認する必要があります。そのため、実行主体やSQLリソースのIDにGraph読み取り権限が必要になる場面があります。(Microsoft Learn)
Azure SQL DatabaseとAzure Synapse Analyticsは細かなGraph権限を優先する
Azure SQL DatabaseとAzure Synapse Analyticsでは、サーバーIDに対してUser.Read.All、GroupMember.Read.All、Application.Read.Allなどの細かなMicrosoft Graph API権限を割り当てる構成がサポートされ、最小特権の観点から推奨されています。Directory Readersロールも広めの代替手段として使えますが、まずは必要な操作に応じて細かく権限を付ける設計を検討します。(Microsoft Learn)
| 実行したい操作 | 最小限検討するGraph権限 |
|---|---|
Microsoft EntraユーザーのCREATE USERまたはCREATE LOGIN | User.Read.All |
Microsoft EntraグループのCREATE USERまたはCREATE LOGIN | GroupMember.Read.All |
サービスプリンシパルやマネージドIDのCREATE USERまたはCREATE LOGIN | Application.Read.All |
| SQL Managed InstanceでMicrosoft Entra認証を使う | Directory Readersロール、または同等の細かなGraph権限 |
この表は「とりあえずDirectory Readersを付ければよい」という運用から脱却するための判断材料になります。特に監査要件が強い組織では、誰に、どのIDに、どのGraph権限を付けたかを明確に残しておくべきです。
SQL Managed InstanceはDirectory Readersロールを確認する
SQL Managed Instanceでは、セキュリティグループ経由の認可や新しいユーザー作成などでMicrosoft Entra IDを読み取る必要があります。公式ドキュメントでは、Microsoft Entra認証を機能させるために、マネージドインスタンスIDをDirectory Readersロールに割り当てる必要があると説明されています。(Microsoft Learn)
Azureポータルでは、SQL Managed InstanceのMicrosoft Entra IDページにDirectory Readersロール付与を促すバナーが表示される場合があります。この操作を実行できるのは、テナント内の特権ロール管理者以上のロールです。バナーが表示されない場合は、すでに権限が付与されているか、操作ユーザーに必要なロールがない可能性があります。(Microsoft Learn)
実務では、次のように担当を分けて進めると安全です。
| 担当 | 作業 |
|---|---|
| Entra管理者 | Directory ReadersまたはGraph権限付与、条件付きアクセス確認 |
| Azure管理者 | SQLリソースのマネージドID、Microsoft Entra管理者設定 |
| DBA | SQLログイン、データベースユーザー、DBロール設計 |
| 開発者 | 接続方式、Azure Identity、マネージドIDの利用確認 |
開発者が確認すべき接続方式
Microsoft Entra認証を使うと、接続方法は「IDでトークンを取得してSQLへ接続する」形になります。人間のユーザーであればSSMSやAzure Data Studioなどの対話的サインイン、アプリケーションであればマネージドIDやサービスプリンシパルを使う構成が中心です。
Microsoft Learnでは、Microsoft Entra認証の構成後、SQL Server Management Studio、SQL Server Data Tools、クライアントアプリケーションからMicrosoft Entra IDを使ってSQLリソースへ接続できるとされています。(Microsoft Learn)
アプリケーションではマネージドIDを優先する
Azure App Service、Azure Functions、Azure VM、Azure Container AppsなどAzure上で動くアプリケーションからAzure SQLへ接続する場合は、可能であればマネージドIDを優先します。マネージドIDを使うと、アプリケーションコードやKey VaultにSQLパスワードを保持せずに済みます。
構成例は次の流れです。
| 手順 | 作業内容 |
|---|---|
| 1 | アプリ実行環境でシステム割り当て、またはユーザー割り当てマネージドIDを有効化 |
| 2 | Azure SQL側でMicrosoft Entra管理者を設定 |
| 3 | SQL上にマネージドIDのユーザーまたはログインを作成 |
| 4 | 必要なDBロールに追加 |
| 5 | アプリの接続設定をMicrosoft Entra認証方式に変更 |
| 6 | 本番相当の実行環境から接続テスト |
T-SQLの例です。
CREATE USER [my-app-managed-id] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-app-managed-id];
ALTER ROLE db_datawriter ADD MEMBER [my-app-managed-id];ただし、表示名が重複する環境では、意図したマネージドIDとは別のIDを参照してしまうリスクがあります。Microsoft Entra IDでは表示名の重複が可能ですが、Azure SQL側のプリンシパル名は一意である必要があります。公式ドキュメントでは、この問題に対応するため、Microsoft EntraのオブジェクトIDを指定できるWITH OBJECT_ID拡張がプレビューとして説明されています。(Microsoft Learn)
ローカル開発と本番実行環境のID差分に注意する
ローカルPCでは開発者のMicrosoft Entraアカウントで接続できても、本番のApp ServiceやFunctionsではマネージドIDが使われます。つまり、開発者ユーザーに権限があっても、アプリ本体のIDに権限がなければ本番では失敗します。
よくある失敗例は次の通りです。
| 症状 | 原因 | 対応 |
|---|---|---|
| ローカルでは接続できるが本番で失敗 | 本番アプリのマネージドIDにSQLユーザーがない | マネージドID用のCREATE USERを実行する |
CREATE USER時にエラー | Graph権限不足、条件付きアクセス、MFA未登録 | Graph権限と条件付きアクセスを確認する |
| グループ所属なのに一部DDLが失敗 | 暗黙ユーザーが作成されず、既定スキーマや所有者解決に失敗 | 個別ユーザー作成またはDEFAULT_SCHEMA設定を検討する |
| フェールオーバー後に接続不可 | セカンダリ側にMicrosoft Entra管理者がない | プライマリ・セカンダリ両方に管理者を設定する |
Azure SQL DatabaseとAzure Synapse Analyticsでは、Microsoft Entraグループ経由でログインしたユーザーに対して暗黙ユーザーが作成されないため、所有権やスキーマに関わる操作が失敗する場合があります。たとえば、db_ddladmin相当の権限があっても、スキーマを明示しないCREATE SCHEMAやオブジェクト作成で問題が起きることがあります。(Microsoft Learn)
移行時の判断基準：SQL認証を残すか、Microsoft Entra-onlyにするか
Microsoft Entra認証を導入するとき、すぐにSQL認証を完全停止するかどうかは慎重に判断します。Microsoft Entra-only authenticationを有効にすると、Azure SQLのSAやSQL認証ベースのアカウント、SQL Managed InstanceのWindows認証など、他の認証方法は使えなくなります。(Microsoft Learn)
段階移行が向いているケース
次のような環境では、いきなりMicrosoft Entra-onlyにせず、段階移行が現実的です。
| 状況 | 推奨アプローチ |
|---|---|
| 古いアプリがSQLユーザー名・パスワード接続を使っている | まずMicrosoft Entra認証を併用し、アプリ単位で切り替える |
| 外部ベンダー製品が接続方式を固定している | 製品の対応状況を確認してから切り替える |
| 緊急時の運用手順がSQL認証前提 | ブレイクグラス手順を再設計してから無効化する |
| CI/CDがSQLログインで初期化処理をしている | デプロイ用マネージドIDまたはサービスプリンシパルへ移行する |
Microsoft Entra-onlyはセキュリティ面で有効ですが、運用・監視・復旧手順も含めて切り替える必要があります。特に本番DBでは、切り替え前に「誰が、どの端末から、どのIDで、どの権限で復旧作業を行うか」まで確認しておくべきです。
移行前に棚卸しすべきSQLログイン
移行前には、既存のSQLログインとデータベースユーザーを棚卸しします。次のクエリで候補を確認し、不要なアカウント、アプリ用アカウント、運用用アカウントを分けます。
SELECT name, type_desc, create_date, modify_date
FROM sys.sql_logins
ORDER BY modify_date DESC;データベース側では、Microsoft EntraプリンシパルとSQLユーザーを確認します。
SELECT name, type_desc, authentication_type_desc
FROM sys.database_principals
WHERE type IN ('S', 'E', 'X')
ORDER BY name;移行時は「使われていないように見えるアカウント」をすぐ削除するのではなく、監査ログ、アプリ設定、ジョブ、保守スクリプトを確認してから無効化します。SQL Managed InstanceではSQL AgentジョブやDB Mail、Service Brokerなど、周辺機能も確認対象になります。SQL Managed InstanceではMicrosoft EntraログインによるSQL Agent管理やジョブ実行、バックアップ・リストア、監査、専用管理者接続などがサポートされる一方、PolyBaseはMicrosoft Entra認証に対応しない制限があります。(Microsoft Learn)
展開前チェックリスト
本番展開前には、設定項目を「ID」「SQL」「アプリ」「運用」の4つに分けて確認します。
| 分類 | チェック項目 | OKの判断基準 |
|---|---|---|
| ID | Microsoft Entra管理者が設定済み | 個人ではなく管理グループを設定している |
| ID | Graph権限またはDirectory Readers | 対象サービスに応じた最小権限が付与されている |
| SQL | データベースユーザーまたはログイン | 接続するユーザー、グループ、マネージドIDが作成済み |
| SQL | DBロール | 直接付与ではなくロール経由で権限管理している |
| アプリ | 接続方式 | 本番実行IDで接続テスト済み |
| アプリ | タイムアウト設定 | 接続タイムアウトを十分に確保している |
| 運用 | フェールオーバー | プライマリ・セカンダリ両方でMicrosoft Entra管理者を確認済み |
| 運用 | 緊急時手順 | Microsoft Entra障害・権限誤設定時の対応者と手順が明確 |
公式ドキュメントでは、Microsoft Entraユーザーやサービスプリンシパルが2,048を超えるMicrosoft Entraセキュリティグループに所属している場合、データベースへログインできない制限があるとされています。また、接続タイムアウトは30秒に設定することが推奨されています。(Microsoft Learn)
トラブルシューティングで見るべきポイント
Microsoft Entra認証のトラブルは、SQL権限だけでなく、Microsoft Entra、Microsoft Graph、条件付きアクセス、接続元環境が絡みます。エラーメッセージだけで判断せず、どの段階で失敗しているかを切り分けます。
CREATE USER ... FROM EXTERNAL PROVIDERで失敗する
CREATE USER ... FROM EXTERNAL PROVIDERでは、Azure SQLがMicrosoft Entra IDに問い合わせて対象IDを確認します。SQLエラー33134が発生する場合、アクセス拒否、MFA登録要求、条件付きアクセスの影響などが原因になることがあります。公式ドキュメントでは、Microsoft Graph APIのアプリケーションIDへのアクセスを条件付きアクセスで許可する対応が説明されています。(Microsoft Learn)
確認する順番は次の通りです。
| 順番 | 確認内容 |
|---|---|
| 1 | 実行ユーザーがMicrosoft Entra管理者、またはALTER ANY USERを持つか |
| 2 | 対象ユーザー・グループ・アプリの表示名やUPNが正しいか |
| 3 | Graph権限またはDirectory Readersが不足していないか |
| 4 | 条件付きアクセスでMicrosoft Graphへのアクセスがブロックされていないか |
| 5 | サービスプリンシパルで実行すべき操作か、ユーザーで実行すべき操作か |
表示名重複で別ユーザーと衝突する
Microsoft Entra IDでは表示名を重複できますが、Azure SQLのサーバープリンシパルやデータベースプリンシパルでは名前の一意性が必要です。Microsoft Entra管理者もmasterデータベースのユーザーとして格納されるため、同名ユーザーがすでに存在すると設定に失敗してロールバックされます。(Microsoft Learn)
実務では、次のルールを決めておくと安全です。
| 対象 | 命名ルール例 |
|---|---|
| 管理グループ | SQL-Admins-Prod、SQL-Admins-Dev |
| アプリ用マネージドID | mi-appname-prod-sql |
| サービスプリンシパル | sp-appname-deploy-sql |
| DBロール | role_app_readwrite、role_report_readonly |
表示名だけで管理すると、将来の運用で人間が誤認しやすくなります。ID棚卸しでは、表示名だけでなくObject ID、Application ID、用途、所有者も記録しておくべきです。
フェールオーバー後に接続できない
geoレプリケーションやフェールオーバーグループを使う場合、Microsoft Entra管理者はプライマリだけでなくセカンダリ側にも設定が必要です。設定されていないサーバーやインスタンスに切り替わると、Microsoft EntraログインやユーザーがCannot connectエラーになる可能性があります。(Microsoft Learn)
障害訓練では、SQL接続だけでなく、Microsoft Entra認証での接続、アプリケーションの再接続、運用者のSSMS接続まで確認します。
実務でおすすめの設計パターン
Microsoft Entra認証は柔軟ですが、自由に設定しすぎると運用が複雑になります。基本は「グループで管理し、アプリはマネージドID、権限はDBロール経由」です。
人間のアクセスはMicrosoft Entraグループで管理する
DBA、開発者、閲覧者をグループで分け、SQL側ではグループに対応するユーザーを作成します。
CREATE USER [SQL-DBA-Admins] FROM EXTERNAL PROVIDER;
CREATE USER [SQL-App-Developers] FROM EXTERNAL PROVIDER;
CREATE USER [SQL-Report-Readers] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [SQL-Report-Readers];開発者に直接db_ownerを付けるのではなく、作業内容に応じたロールを用意します。権限変更はMicrosoft Entraグループのメンバー変更で吸収できるようにすると、監査と棚卸しが楽になります。
アプリケーションはマネージドIDでパスワードレスにする
Azure上で動作するアプリケーションでは、SQLパスワードを廃止し、マネージドIDに移行する価値があります。漏えいする接続文字列を減らせるだけでなく、Key VaultやCI/CDのシークレット管理も簡素化できます。
ただし、マネージドIDを作っただけではSQLへ接続できません。SQL側にユーザーまたはログインを作成し、必要なDBロールへ追加する必要があります。
デプロイ用IDを明確にする
初期構築やマイグレーションでCREATE USERや権限付与を自動化する場合、デプロイ基盤のIDをMicrosoft Entra管理者にする構成が有効な場合があります。公式ドキュメントでも、Microsoft Entra管理者は最初に接続して他のMicrosoft Entraユーザーを作成する必要があるため、デプロイ基盤のIDを管理者に追加すると初期セットアップを自動化しやすいと説明されています。(Microsoft Learn)
ただし、デプロイ用IDに強い権限を恒久的に持たせる場合は、監査ログ、アクセスレビュー、所有者、緊急停止手順をセットで整備してください。
管理者・開発者が今日やるべきこと
Microsoft Entra認証は、単にログイン方式を変える設定ではありません。ID管理、Graph権限、SQLプリンシパル、アプリ接続、フェールオーバー運用まで影響します。
まずは次の順番で確認してください。
| 優先度 | やること |
|---|---|
| 高 | 対象のAzure SQL Database、SQL Managed Instance、SynapseでMicrosoft Entra管理者が設定されているか確認する |
| 高 | Azure SQL DatabaseでMicrosoft Entraログインを使う設計に移行できるか検討する |
| 高 | SQL Managed InstanceではDirectory Readersまたは同等Graph権限を確認する |
| 中 | SQL認証アカウント、アプリ接続、CI/CD接続を棚卸しする |
| 中 | マネージドIDで接続するアプリにSQLユーザー・DBロールを付与する |
| 中 | フェールオーバー先にもMicrosoft Entra管理者が設定されているか確認する |
| 低 | Microsoft Entra-only authenticationへの移行計画を作る |
最初の一歩としては、Azureポータルで対象SQLリソースのMicrosoft Entra ID設定を開き、管理者、マネージドID、Graph権限、フェールオーバー構成を確認します。その後、SQL側でMicrosoft Entraプリンシパルが適切に作成されているかを棚卸しし、個人ユーザーへの直接権限付与をグループ・ロール中心の設計に寄せていくのが現実的です。
コメント