SQL Server ポート ガイド: ポート 1433 でのデータベース アクセス

SQL クライアントはサーバー リスナーに接続し、プロトコル設定をネゴシエートし、SQL 認証、Windows 認証、Entra ID、またはその他のサポートされている方法で認証して、クエリ、トランザクション、およびメタデータ要求を送信します。

ポートはリスナーに到達できることのみを確認します。実際のデータベース アクセスは、ログイン状態、データベースのアクセス許可、暗号化設定、インスタンス構成、接続文字列、DNS、および複数のレイヤーのファイアウォール ルールにも依存します。

デフォルトの SQL Server インスタンスは通常、TCP 1433 で待機します。静的ポートを構成しない限り、名前付きインスタンスは動的ポートを使用することがあります。 SQL Server Browser は、クライアントが名前付きインスタンスを検出するのに役立ちますが、多くの運用環境では、より明確なファイアウォール ポリシーのために静的ポートが好まれます。

接続文字列でサーバー,ポート構文を使用している場合は、正確なポートを確認してください。インスタンス名を使用している場合は、SQL Server 構成マネージャー、エラー ログ、またはサーバー設定を確認して、インスタンスが実際にリッスンしているポートを確認してください。

データベース接続を必要とするアプリケーション サーバー、管理ワークステーション、移行ツール、レポート サービス、または信頼できるネットワークからのみ Open SQL アクセスを実行します。非常に具体的な管理および監視の要件がない限り、パブリック アクセスは避けるべきです。

クラウド データベースの場合は、インターネット全体が 1433 に到達することを許可するのではなく、プライベート エンドポイント、VPC または VNet ピアリング、VPN、要塞パス、サービス ネットワーキング、またはプロバイダー ネイティブのファイアウォール ホワイトリストを優先します。

TCP 1433 を許可する前に、インスタンスが予想されるインターフェイスとポートでリッスンしていること、暗号化ポリシーがわかっていること、ログインのスコープが設定されていること、最小権限のデータベース ロールが設定されていること、バックアップが信頼できることを確認してください。

ポート チェッカーはネットワークの到達可能性を確認できますが、データベースが安全であることを証明することはできません。 sqlcmd、SQL Server Management Studio、Azure Data Studio、アプリケーションの正常性チェック、サーバー ログを使用して実際の接続文字列をテストします。

Windows Server で、SQL Server インスタンスの TCP/IP を有効にし、必要に応じて静的ポートを設定し、サービスを再起動して、信頼できるソースからのみ Windows Defender ファイアウォールで受信 TCP 1433 を許可します。

Linux SQL Server 展開では、mssql-server が目的のポートでリッスンしていることを確認し、そのポートを firewalld、ufw、nftables、iptables、またはクラウド セキュリティ グループで許可します。管理アクセスをアプリケーション アクセスとは別にしてください。

マネージド SQL サービスの場合は、プロバイダーのファイアウォール ルール、プライベート エンドポイント、および ID 制御を使用します。クラウド データベース エンドポイントを開くことが、単一の VM ポートを公開することと同じであると想定しないでください。プロバイダーレベルのアクセスポリシーも重要です。

クライアントが実行される場所に応じて、データベースのホスト名と TCP 1433 に対する外部ポートまたは内部ポートのチェックから開始します。ポートが開いている場合は、sqlcmd、SSMS、Azure Data Studio、またはアプリケーション接続文字列を使用して実際の接続をテストします。

TLS が必要な場合は、クライアントからの証明書の信頼性と暗号化設定を確認します。次に、サーバー ログでログインの失敗、ファイアウォールの拒否、データベース レベルの権限エラー、接続タイムアウト パターンを確認します。

ポート 1433 が閉じている場合は、SQL Server が実行されていない、TCP/IP が無効になっている、インスタンスが別のポートを使用している、またはホスト、クラウド、またはネットワーク ファイアウォールがパスをブロックしている可能性があります。実際の動的ポートがクライアントが期待するものと異なるため、名前付きインスタンスは失敗することがよくあります。

ポートは開いているがログインに失敗する場合は、認証モード、ユーザー名の形式、パスワードの状態、無効なログイン、データベース ユーザー マッピング、権限、暗号化要件、およびサーバー エラー ログを検査します。クエリは接続できるが遅い場合は、ロック、インデックス、CPU、メモリ、I/O、クエリ プランを確認してください。

可能な限り SQL Server を公共のインターネットから遠ざけてください。ソースを制限し、暗号化を要求し、エンジンにパッチを適用し、未使用のログインを無効にし、最小特権ロールを使用し、資格情報をローテーションし、失敗したログインと特権アクションを監査します。

データベースのバックアップ、復元のテスト、遅いクエリとレプリケーションの健全性の監視、管理アクセスをアプリケーション アクセスから分離します。データベース ポートは機密データへの直接パスであるため、ネットワークへの到達可能性を強力な ID およびデータ制御と組み合わせる必要があります。