IPv4 全体を指定した Azure SQL サーバーのファイアウォール

説明

ARM または Bicep の Microsoft.Sql/servers/firewallRules リソースで、startIpAddress を 0.0.0.0、endIpAddress を 255.255.255.255 にすると、IPv4 アドレス全体を許可します。この範囲をパブリックエンドポイントに適用すると、ファイアウォールでクライアントの送信元を制限できなくなります。

実際の接続可否は、サーバーのネットワーク設定にも左右されます。publicNetworkAccess が無効なら、このファイアウォールルールだけで公開接続が可能になることはありません。接続できる場合も、データベースの認証と権限は別途必要です。

開始・終了アドレスをともに 0.0.0.0 にする設定は、ほかの顧客のサブスクリプションを含む Azure リソースからの接続を許可する別の例外です。IPv4 全体の範囲とは異なりますが、内部専用の接続として扱わないでください。

想定される影響

パブリック接続が有効で IPv4 全体のルールが適用されると、ファイアウォールはインターネット上の IPv4 送信元アドレスを制限できません。
ネットワーク経路が許可された外部クライアントは、データベース認証を試行できます。データへのアクセスには有効な認証と権限が必要ですが、広い許可範囲は漏えいした認証情報が悪用される機会を増やすおそれがあります。

対処方法

パブリック接続が必要な場合は、実際のクライアントの送信元 IPv4 アドレスだけを許可してください。NAT を使う場合は、サーバーが認識するパブリック送信元を基準にします。startIpAddress と endIpAddress には、CIDR ではなく個別の IPv4 アドレスを昇順で指定してください。
IPv4 全体を許可するルールを削除し、ほかのサーバーレベルおよびデータベースレベルのファイアウォールルールとパブリックネットワーク設定も確認してください。
プライベートエンドポイントを使う構成では、必要なプライベート接続を検証したうえでパブリックネットワークアクセスを無効にしてください。VNet や踏み台ホストを使用しているだけでは、パブリック経路はなくなりません。認証とデータベースの権限も別途管理してください。

例

以下は、IPv4 全体の範囲と限定した範囲を比較する抜粋です。最初の例にある管理者名とパスワードの文字列を実際の認証情報に使わないでください。デプロイ前に、プレビュー版の API バージョンとリソーススキーマも確認する必要があります。2 番目の例は既存の sample サーバーを前提とした一部の構成であり、完全なデプロイ用テンプレートではありません。

IPv4 全体の範囲

bicep

resource sqlServer1 'Microsoft.Sql/servers@2021-02-01-preview' = {
  name: 'sqlServer1'
  location: resourceGroup().location
  properties: {
    administratorLogin: 'adminUsername'
    administratorLoginPassword: 'adminPassword'
  }
}

resource sqlServer1AllowAll 'Microsoft.Sql/servers/firewallRules@2021-02-01-preview' = {
  parent: sqlServer1
  location: resourceGroup().location
  name: 'AllowAll'
  properties: {
    endIpAddress: '255.255.255.255'
    startIpAddress: '0.0.0.0'
  }
}

限定したアドレス範囲