Azure SQL Database の IP ファイアウォール規則が突然グレーアウトして削除できない――権限は Owner のはずなのに操作できず、T‑SQL で消そうとしてもエラーになる。この記事では、このよくあるハマりポイントの原因と、Microsoft Entra 管理者の設定による具体的な解決手順、運用の注意点まで詳しく解説します。
Azure SQL Server の IP ファイアウォール規則が削除できない現象とは
Azure Portal で Azure SQL Server（論理サーバー）を開き、「ネットワーク」や「ファイアウォールと仮想ネットワーク」の画面に移動すると、サーバーレベルの IP ファイアウォール規則が一覧表示されます。本来はここから規則の追加・変更・削除ができるはずですが、以下のような現象に遭遇することがあります。
- 既存の IP ファイアウォール規則の行がグレーアウトしていて編集できない
- ゴミ箱アイコン（削除ボタン）が無効化されている、または押してもエラーになる
- Azure リソースの RBAC では 所有者（Owner） ロールを持っているのに操作できない
- T‑SQL の
sp_delete_firewall_ruleを実行しても削除できない、権限エラーになる
見た目は単純な「権限がないだけ」の問題ですが、Azure 特有の 「RBAC（Azure リソース）と SQL サーバー内部の権限の二重構造」 によって、原因が分かりにくいケースが多いです。特に、過去に構築したサーバーを引き継いだ場合や、サーバー作成当時の管理者アカウントが不明な場合にハマりやすいポイントです。
結論：Microsoft Entra 管理者かサーバー管理者でないと既存のサーバーレベル規則は削除できない
まず結論から整理します。
- Azure リソースとしての SQL Server に対して Owner（またはそれに準じるロール）を持っていても、SQL サーバー内部のサーバーレベル権限 を持っていなければ、既存のサーバーレベル IP ファイアウォール規則を削除できない場合があります。
- サーバーレベルの IP ファイアウォール規則を自由に操作できるのは、原則として以下の主体です。
- サーバー作成時に指定した SQL Server 管理者ログイン
- Microsoft Entra 管理者（旧 Azure AD 管理者） に設定されたユーザーまたはグループ
- 今回の事例では、Microsoft Entra 管理者が未設定であり、引き継いだ担当者がサーバー内部の管理者権限を持っていなかったため、Portal 上のサーバーレベル規則がグレーアウトして削除できない状態になっていました。
- Azure Portal から Microsoft Entra 管理者を新たに設定したあと、その管理者アカウントでサインインし直すことで、問題のファイアウォール規則を削除できるようになりました。
つまり、「Owner なのに削除できない」のではなく、「Owner だけでは足りない」が正解です。Azure SQL Database のセキュリティモデルを理解しておくと、同様のトラブルを事前に避けられます。
Azure SQL の権限モデルとファイアウォール規則の関係
この問題を正しく理解するには、Azure SQL の権限モデルとファイアウォール規則の種類をセットで押さえておく必要があります。
RBAC と SQL サーバー内部権限の二重構造
Azure SQL Server（論理サーバー）には、次のような二種類の「権限レイヤー」が存在します。
| レイヤー | 代表的な権限 | 何を制御するか | ファイアウォールへの影響 |
|---|---|---|---|
| Azure リソース（ARM / RBAC） | Owner, Contributor, SQL Server Contributor など | サーバーやデータベースの作成 / 削除、構成変更、Entra 管理者の設定など | 「ネットワーク」画面を開くこと自体や、Entra 管理者を設定することができる |
| SQL サーバー内部（データ プレーン） | サーバーレベルプリンシパル（サーバー管理者）、Microsoft Entra 管理者、DB オーナーなど | ログイン、ユーザー、ロール、サーバーレベル / DB レベル設定、T‑SQL による操作 | サーバーレベル IP ファイアウォール規則の追加・変更・削除を行う |
Portal のファイアウォール設定画面でサーバーレベル規則を削除しようとすると、内部的には サーバーレベルでの T‑SQL 実行 に相当する操作が走ります。そのため、RBAC 上で Owner であっても、内部的なサーバーレベル権限がなければ操作が拒否される、という構図です。
サーバーレベル規則とデータベースレベル規則
Azure SQL Database には大きく分けて次の 2 種類のファイアウォール規則があります。
| 項目 | サーバーレベル ファイアウォール規則 | データベースレベル ファイアウォール規則 |
|---|---|---|
| 適用範囲 | 該当サーバー上のすべてのデータベース | 特定の 1 つのデータベースのみ |
| 管理方法（Portal） | SQL Server（論理サーバー）の「ネットワーク」画面 | 基本的に Portal からは個別に表示されない（T‑SQL 管理がメイン） |
| 管理方法（T‑SQL） | master DB で sp_set_firewall_rule / sp_delete_firewall_rule | 対象 DB で sp_set_database_firewall_rule / sp_delete_database_firewall_rule |
| 権限要件 | サーバーレベルプリンシパル、Microsoft Entra 管理者 など | 対象 DB の db_owner など適切な DB 権限 |
| 今回の「グレーアウト」問題の主役 | こちら（サーバーレベル規則） | 今回の事象では直接関係しないが、誤解しやすい |
Portal 上でグレーアウトしているのは、このうち サーバーレベル ファイアウォール規則です。データベースレベル規則は Portal にほとんど姿を見せないため、T‑SQL で直接確認・管理することになります。
なぜ Owner なのに削除できないのか：典型的な原因
現場でよく見かける原因を整理すると、次のようになります。
Owner だが Microsoft Entra 管理者 / サーバー管理者ではない
最も多いのは、「Azure RBAC の Owner ではあるが、サーバー内部の管理者ではない」パターンです。
- サーバーを最初に作成した担当者が退職・異動しており、SQL Server 管理者ログインのパスワードが不明
- Microsoft Entra 管理者がそもそも設定されていない
- Portal からはリソースの設定変更ができるが、ファイアウォールだけはなぜか触れない
この状況では、Portal で規則を削除しようとしても、内部的にはサーバーレベル権限が不足しているため、グレーアウトしたり、エラーが返されます。
sp_delete_firewall_rule を誤ったコンテキストで実行している
もう一つありがちな原因は、sp_delete_firewall_rule を次のような誤った条件で実行しているケースです。
- master 以外のデータベースで実行している
- 削除したい規則が実は データベースレベル規則なのに、サーバーレベル用のストアドプロシージャを使っている
- SQL ログイン / ユーザーに、サーバーレベル規則を変更するための十分な権限がない
この場合、エラー メッセージだけを見ると「権限不足」か「該当する規則が見つからない」程度にしか見えないため、原因の切り分けに時間がかかってしまいます。
最短ルートの解決策：Microsoft Entra 管理者を設定する
今回のようなケースで最も早く確実に解決できるのは、Microsoft Entra 管理者を正しく設定し、そのアカウントでサーバーに接続して操作する方法です。
前提：Entra 管理者を設定するために必要な RBAC
Microsoft Entra 管理者の設定・変更は、Azure RBAC で以下のような権限を持っている主体であれば行えます。
- サブスクリプションまたはリソース グループの Owner
- SQL Server Contributor など、
Microsoft.Sql/servers/administrators/*の書き込み権限を含むカスタムロール
すでに Owner ロールを持っているなら、そのまま Portal から Entra 管理者を設定可能です。
ポータルから Microsoft Entra 管理者を設定する手順
- Azure Portal に管理者アカウントでサインインします。
- 対象の SQL Server（論理サーバー） を開きます。
- 「SQL データベース」ではなく、「SQL サーバー」を選択する点に注意してください。
- 左側メニューから 「Microsoft Entra ID」 または「Active Directory 管理者」に相当するメニューをクリックします。
- 「管理者の設定」 ボタンを押し、管理者として設定したいユーザーまたはグループを検索します。
- 運用上は、個人ユーザーではなく「DB 管理者グループ」などの グループ を指定しておくと管理が楽です。
- 対象のユーザー / グループを選択し、保存します。
設定が完了すると、そのユーザー / グループは Azure SQL サーバーの Microsoft Entra 管理者として扱われ、サーバーレベルのファイアウォール規則も含めて幅広い操作が可能になります。
Azure CLI で Entra 管理者を設定する例
Infrastructure as Code や自動化を重視する環境では、Portal ではなく CLI で管理者を設定することも多いです。Azure CLI の例を示します。
az sql server ad-admin create \
--resource-group <リソースグループ名> \
--server <サーバー名> \
--display-name "<ユーザーまたはグループ名>" \
--object-id <対象ユーザー/グループの ObjectId>
既存の管理者を確認・更新したい場合は、以下のコマンドも使えます。
# 現在の Entra 管理者の確認
az sql server ad-admin show \
--resource-group <リソースグループ名> \
--server <サーバー名>
# 管理者の更新（置き換え）
az sql server ad-admin update \
--resource-group <リソースグループ名> \
--server <サーバー名> \
--display-name "<新しいユーザーまたはグループ名>" \
--object-id <新しい ObjectId>
管理者設定後は必ず「サインインし直す」
Entra 管理者を設定・更新した直後は、既存のログイン セッションには新しい権限が反映されていないことがあります。Portal / SSMS / Azure Data Studio いずれの場合も、次の点に注意してください。
- 一度サインアウトしてから、Entra 管理者に設定したアカウントで再度サインインする
- SSMS / Azure Data Studio などでは、一度接続を切断してから再接続する
- トークンキャッシュの影響で反映が遅れる場合もあるため、ブラウザのシークレット ウィンドウで再ログインしてみるのも有効
これを忘れると、「設定したはずなのにまだ削除できない」という二重のハマりポイントに陥りやすくなります。
ファイアウォール規則を削除する具体的な手順
Microsoft Entra 管理者としてサインインできるようになったら、いよいよ不要な IP ファイアウォール規則を削除します。Portal と T‑SQL の両方の方法を確認しておきましょう。
Portal からサーバーレベル規則を削除する
- Azure Portal で、Entra 管理者としてサインインします。
- 対象の SQL Server（論理サーバー） を開きます。
- 左メニューから 「ネットワーク」（または「ファイアウォールと仮想ネットワーク」） を選択します。
- 「ファイアウォール規則」一覧から、削除したい規則の行を選択します。
- ゴミ箱アイコン（削除）をクリックします。
- 以前はグレーアウトしていた場合も、Entra 管理者としてサインインしていれば削除可能になっているはずです。
- 画面右上の 「保存」 ボタンを押し、設定を確定します。
削除後に接続テストを行い、意図したアクセス制御になっているかを確認してください。
T‑SQL でサーバーレベル規則を削除する
サーバーレベル規則を T‑SQL で削除する場合は、次のポイントを必ず守ります。
- 接続先データベースは必ず
masterにする - Microsoft Entra 管理者またはサーバーレベルプリンシパルとして接続する
- 削除したい規則名を正確に指定する
-- サーバーレベル ファイアウォール規則の削除例
USE master;
GO
EXEC sp_delete_firewall_rule N'AllowOfficeIPRange';
GO
念のため、削除前後で現在のサーバーレベル規則を確認しておくと安心です。
-- 現在のサーバーレベル規則の確認
USE master;
GO
SELECT name, start_ip_address, end_ip_address
FROM sys.firewall_rules
ORDER BY name;
GO
データベースレベル規則の場合は別のストアドプロシージャを使う
もし削除したい規則が データベースレベル ファイアウォール規則であれば、サーバーレベル用の sp_delete_firewall_rule ではなく、次のストアドプロシージャを使用します。
-- データベースレベル ファイアウォール規則の削除例
USE SampleDb;
GO
EXEC sp_delete_database_firewall_rule N'DBOnlyRule01';
GO
事前に、対象データベースで現在の規則を確認しておくとよいでしょう。
USE SampleDb;
GO
SELECT name, start_ip_address, end_ip_address
FROM sys.database_firewall_rules
ORDER BY name;
GO
うまくいかないときに確認すべきチェックリスト
Microsoft Entra 管理者としてサインインしても、まだ削除できない／エラーになる場合は、次のチェックリストを順番に確認してみてください。
サーバーレベル規則か、データベースレベル規則か
- Portal に表示されるのは基本的に サーバーレベル規則です。
- 「T‑SQL で削除できない」と感じる場合、実はその規則が データベースレベル規則であるケースも少なくありません。
sys.firewall_rules（master）とsys.database_firewall_rules（各 DB）をそれぞれ確認し、どのレベルの規則なのかを明確に切り分けましょう。
実行しているデータベースが master になっているか
- サーバーレベル規則の削除は
masterデータベースでのみ有効です。 - 別 DB に接続したまま
sp_delete_firewall_ruleを実行すると、エラーや予期しない動作の原因になります。
Azure Policy / ARM / Bicep / Terraform による「自動復活」がないか
企業環境では、セキュリティ標準を維持するために、次のような仕組みでファイアウォール規則を自動的に作成・維持している場合があります。
- Azure Policy による強制構成
- Blueprint、ARM テンプレート、Bicep のデプロイ パイプライン
- Terraform や他の IaC ツールによる自動適用
- 定期実行の自動化スクリプト（Azure Functions / Logic Apps / Runbook など）
このような環境で手動で規則を削除すると、次の構成適用タイミングで自動的に復活することがあります。Portal 上では一瞬削除できたように見えても、しばらくすると元に戻ってしまう場合は、IaC / Policy 周りを疑いましょう。
リソースロック（読み取り専用）が設定されていないか
対象の SQL Server やリソース グループに対して、リソースロック（ReadOnly ロック） が設定されていると、構成の更新がブロックされる場合があります。次の点を確認してください。
- SQL Server リソースの「ロック」設定に ReadOnly ロックがないか
- リソース グループ レベルでロックがかかっていないか
ロックが原因であれば、一時的にロックを解除してから規則を削除し、作業完了後に再度ロックを設定する運用とするのが一般的です。
「Allow Azure services and resources to access this server」の扱い
サーバーレベル ファイアウォール設定には、特別な項目として 「Azure サービスおよびリソースにこのサーバーへのアクセスを許可する」 のチェックボックスがあります。これも内部的には IP 規則として扱われますが、Portal 上の挙動が通常の規則と異なるため、誤解の原因になることがあります。
- この項目を OFF にすることで、Azure 内部の広い範囲からのアクセスをまとめて拒否できます。
- セキュリティ ポリシー上、組織として必ず ON にする／必ず OFF にする、と定めている場合もあります。
- Azure Policy などで強制されていると、手動で OFF にしても元に戻されることがあります。
グレーアウトしていて変更できないように見える場合は、この特別ルールの扱いとポリシー設定を合わせて確認しましょう。
Entra 管理者の権限がまだ反映されていない
- Entra 管理者の設定後に、同じブラウザ セッション / アプリ セッションを使い続けていると、古いトークンが残っていることがあります。
- その場合は、ブラウザのシークレット ウィンドウや別ブラウザで再度ログインし、権限が正しく反映されているか確認します。
- SSMS / Azure Data Studio では、接続プロファイルを作り直すか、再ログインを試してみてください。
トラブルを防ぐための運用ベストプラクティス
今回のような「グレーアウトして削除できない」トラブルは、一度対処方法が分かればそこまで難しいものではありません。しかし、根本的には 権限設計と運用ルール の問題でもあります。再発防止の観点から、次のようなベストプラクティスを検討してみてください。
サーバー作成時に必ず Microsoft Entra 管理者を設定する
- SQL Server を新規作成するタイミングで、「DB 管理者グループ」などの Entra グループを管理者としてセットしておきます。
- 個人ユーザーを管理者にすると、退職・異動時に権限の引き継ぎが煩雑になります。
- 管理者グループのメンバーシップを人事異動に合わせて見直すことで、運用の可視性とガバナンスを高められます。
ファイアウォール規則は可能な限り IaC で管理する
- Portal や T‑SQL からの「手作業の変更」は、どうしても履歴が追いづらくなります。
- ARM テンプレート / Bicep / Terraform などでサーバーレベル規則を定義し、CI/CD パイプラインで展開する形にすると、構成の「再現性」と「説明責任」が確保しやすくなります。
- どうしても一時的な開放が必要な場合は、有効期限を決めた運用ルールを設ける（例：開発者のグローバル IP を 24 時間だけ開放する）など、削除漏れを防ぐ工夫が重要です。
RBAC ロールの設計と SQL 内部権限の設計を分けて考える
Azure の RBAC と SQL サーバー内部の権限は、それぞれ別物として設計する必要があります。
- RBAC は「リソースを誰が作れるか・消せるか」などのインフラ寄りの権限
- SQL 内部権限は「どの DB に接続して、どの操作を行えるか」といったデータ寄りの権限
この 2 つを混同すると、今回のような「Owner なのに削除できない」といった混乱が発生しやすくなります。設計ドキュメント上も、権限の責任分界を明示しておくとよいでしょう。
監査ログで「誰が」「どの規則を」変更したかを追えるようにする
- Azure SQL では、監査ログを Log Analytics ワークスペースやストレージに送信することで、ファイアウォール規則変更の履歴を追跡できます。
- 問題発生時に「いつ」「誰が」「どの IP を開放 / 削除したのか」をすぐに確認できるようにしておくと、トラブルシューティングの時間を大きく短縮できます。
まとめ：Azure SQL Server の IP ファイアウォール規則がグレーアウトしたら
この記事のポイントを最後に整理します。
- Azure Portal で Azure SQL Server の IP ファイアウォール規則がグレーアウトして削除できない場合、単なる Portal 不具合ではなく、権限モデルの問題であることがほとんどです。
- Azure リソースの Owner ロールだけでは不十分で、Microsoft Entra 管理者 または サーバーレベルプリンシパル としてサインインしていないと、既存のサーバーレベル規則は削除できません。
- サーバーレベル規則を T‑SQL で操作する場合は、必ず
masterデータベースでsp_delete_firewall_ruleを実行し、データベースレベル規則との混同に注意します。 - それでもうまくいかない場合は、Azure Policy / IaC による自動再適用、リソースロック、トークンの反映遅延などをチェックします。
- 再発防止のためには、サーバー作成時に Microsoft Entra 管理者（できればグループ）を設定し、ファイアウォール規則を IaC で一元管理することが有効です。
「Owner なのに操作できない」という状況は一見理不尽に見えますが、Azure のデータ プレーンとコントロール プレーンを切り分けて理解すれば、原因と対処方法は明確になります。今回の整理をベースに、自身の環境の権限設計とファイアウォール運用を見直してみてください。
コメント