説明
パブリックなデータベースエンドポイントで広いアドレス範囲を許可すると、接続が不要なクライアントも接続を試みられます。適切な範囲はアドレス数だけでは決められません。アプリケーションや管理ツールが実際に使う送信元と、すべてのファイアウォール規則を併せて確認する必要があります。
Azure SQL Databaseでstart_ip_addressとend_ip_addressを両方0.0.0.0に設定すると、Azureサービスからの接続を許可する例外になります。他の顧客のAzureリソースも含まれる場合があり、自分のサブスクリプションだけに限定されるわけではありません。例外の意味はサービスごとに確認してください。ネットワーク接続の許可は、認証やデータベース権限を置き換えるものではありません。
想定される影響
- 接続が不要な送信元や、広い範囲のサービスからデータベースへの接続を試みられます。
- アクセス経路が増えると、漏えいした認証情報や過剰なデータ権限が悪用される機会が増える可能性があります。
対処方法
- 承認済みのアプリケーションと管理ツールの実際の送信元を確認し、必要なアドレスだけを許可してください。パブリック経路ではNAT後のパブリックアドレスを使い、すべての規則を確認して不要なAzureサービスの例外を削除してください。範囲を複数の規則に分けるだけでは、許可するアクセスは減りません。
- パブリックアクセスが不要な場合は、そのサービスが対応するプライベート接続、DNS、クライアント経路を構成してテストしてから、パブリックアクセスを無効にしてください。
- AzureRMのバージョンに合う構文を使い、Terraformの状態と変更計画を確認してください。適用後は必要な接続、不要な送信元の遮断、認証、最小限のデータ権限を検証してください。
例
以下の部分的な例は、AzureRM v4.50.0のazurerm_mssql_firewall_ruleで広い範囲を一つのクライアントアドレスに絞る方法を示します。azurerm_mssql_server.exampleを定義し、文書用アドレスを実際の承認済み送信元に置き換えてください。旧リソースから移行する場合はTerraformの状態と計画を確認する必要があります。
変更前
hcl
resource "azurerm_mssql_firewall_rule" "wide_firewall_rule" {
name = "FirewallRule1"
server_id = azurerm_mssql_server.example.id
start_ip_address = "203.0.113.0"
end_ip_address = "203.0.113.255"
}
変更後
hcl
resource "azurerm_mssql_firewall_rule" "wide_firewall_rule" {
name = "FirewallRule1"
server_id = azurerm_mssql_server.example.id
start_ip_address = "203.0.113.10"
end_ip_address = "203.0.113.10"
}
説明:
- 変更前: 例示した範囲全体を許可しています。含まれるすべてのアドレスが必要かを確認する必要があります。
- 変更後: 送信元を
203.0.113.10だけに限定しています。ほかの規則やサービス例外を含めたアクセス範囲も確認してください。