説明
パブリックエンドポイントで0.0.0.0から255.255.255.255まで許可すると、送信元IPv4アドレスの制限がなくなります。接続が不要な外部クライアントも接続を試みられるため、承認済みの送信元に範囲を限定する必要があります。ネットワーク接続が許可されても、データベースの認証と権限は引き続き適用されます。
Azure SQL Databaseで開始と終了を両方0.0.0.0にすると、Azureサービスからの接続を許可する別の例外になります。他の顧客のAzureリソースも含まれる場合があり、必要なクライアントだけに限定する設定ではありません。この例外をIPv4全体の範囲と区別し、他のサービスでも同じ意味になるとは考えないでください。
想定される影響
- 不要な外部送信元からデータベースへの接続を試みられる範囲が広がります。
- 認証情報の漏えいや過剰なデータ権限が重なると、不正なデータの読み取り・変更のリスクが高まる可能性があります。
対処方法
- 承認済みのアプリケーションや管理ツールの実際のパブリック送信元を確認し、必要なアドレスだけを許可してください。NAT後のアドレスはクライアントのローカルアドレスと異なる場合があります。Azure SQLではサーバーレベルとデータベースレベルの両方のファイアウォール規則を確認してください。
- パブリック接続が不要な場合は、そのサービスが対応するプライベート接続、DNS、クライアント経路を構成してテストしてから、パブリックアクセスを無効にしてください。規則にプライベートIPを記述するだけでは、プライベート経路は作られません。
- AzureRMのバージョンとデータベースサービスに対応したリソースを使ってください。リソースの種類やアドレスを変える場合はTerraformの状態と計画を確認し、適用後に必要な接続と不要な送信元の遮断をテストしてください。認証と最小限のデータ権限も点検してください。
例
以下の部分的な例はAzureRM v4.50.0のazurerm_mssql_firewall_ruleを使います。参照先のazurerm_mssql_server.exampleを定義し、文書用アドレス203.0.113.10を承認済みクライアントの実際のパブリック送信元に置き換えてください。旧azurerm_sql_firewall_ruleから移行する場合は、Terraformの状態と変更計画も別途確認する必要があります。
変更前
hcl
resource "azurerm_mssql_firewall_rule" "public_firewall_rule" {
name = "FirewallRule1"
server_id = azurerm_mssql_server.example.id
start_ip_address = "0.0.0.0"
end_ip_address = "255.255.255.255"
}
変更後
hcl
resource "azurerm_mssql_firewall_rule" "public_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"
}
説明:
- 変更前: IPv4全体を許可しており、送信元アドレスを制限していません。
- 変更後: 一つのクライアントアドレスだけを許可しています。ほかのファイアウォール規則によって不要なアクセスが追加されていないかも確認してください。