Руководство по порту SQL Server: доступ к базе данных через порт 1433

Клиент SQL подключается к прослушивателю сервера, согласовывает настройки протокола, проверяет подлинность с помощью аутентификации SQL, аутентификации Windows, Entra ID или другого поддерживаемого метода, а затем отправляет запросы, транзакции и запросы метаданных.

Порт только подтверждает, что прослушиватель доступен. Реальный доступ к базе данных также зависит от состояния входа в систему, разрешений базы данных, настроек шифрования, конфигурации экземпляра, строк подключения, DNS и правил брандмауэра на нескольких уровнях.

Экземпляр SQL Server по умолчанию обычно прослушивает TCP 1433. Именованные экземпляры могут использовать динамические порты, если вы не настроите статический порт. Браузер SQL Server может помочь клиентам обнаруживать именованные экземпляры, но многие производственные среды предпочитают статические порты для более четкой политики брандмауэра.

Если в строке подключения используется синтаксис сервера и порта, проверьте точный порт. Если он использует имя экземпляра, проверьте диспетчер конфигурации SQL Server, журнал ошибок или настройки сервера, чтобы узнать, какой порт на самом деле прослушивает экземпляр.

Доступ к открытому SQL возможен только с серверов приложений, рабочих станций администратора, инструментов миграции, служб отчетов или доверенных сетей, которым требуется подключение к базе данных. Публичного доступа следует избегать, за исключением случаев, когда существует очень конкретное управляемое и контролируемое требование.

Для облачных баз данных отдавайте предпочтение частным конечным точкам, пирингу VPC или виртуальной сети, VPN, бастионным путям, сервисной сети или собственным спискам разрешений брандмауэра поставщика вместо того, чтобы разрешать всему Интернету достигать 1433.

Прежде чем разрешить TCP 1433, убедитесь, что экземпляр прослушивает ожидаемый интерфейс и порт, известна политика шифрования, область входа в систему ограничена, роли базы данных с наименьшими привилегиями установлены и резервное копирование надежно.

Средство проверки портов может подтвердить доступность сети, но не может доказать безопасность базы данных. Проверьте реальную строку подключения с помощью sqlcmd, SQL Server Management Studio, Azure Data Studio, проверок работоспособности приложений и журналов сервера.

В Windows Server включите TCP/IP для экземпляра SQL Server, при необходимости установите статический порт, перезапустите службу и разрешите входящий TCP 1433 в брандмауэре Защитника Windows только из надежных источников.

В развертываниях Linux SQL Server убедитесь, что mssql-server прослушивает предполагаемый порт, и разрешите этот порт в firewalld, ufw, nftables, iptables или облачных группах безопасности. Разделите доступ к управлению и доступ к приложениям.

Для управляемых служб SQL используйте правила брандмауэра поставщика, частные конечные точки и средства управления идентификацией. Не думайте, что открытие конечной точки облачной базы данных эквивалентно предоставлению доступа к одному порту виртуальной машины; Политика доступа на уровне провайдера также имеет значение.

Начните с проверки внешнего или внутреннего порта по имени хоста базы данных и TCP 1433, в зависимости от того, где будет работать клиент. Если порт открыт, проверьте фактическое соединение с помощью sqlcmd, SSMS, Azure Data Studio или строки подключения приложения.

Если требуется TLS, проверьте параметры доверия сертификата и шифрования на клиенте. Затем проверьте журналы сервера на предмет ошибок входа в систему, отказов брандмауэра, ошибок разрешений на уровне базы данных и шаблонов таймаута соединения.

Если порт 1433 закрыт, возможно, SQL Server не работает, TCP/IP может быть отключен, экземпляр может использовать другой порт или путь может блокироваться хостом, облаком или сетевым брандмауэром. Именованные экземпляры часто терпят неудачу, поскольку фактический динамический порт отличается от ожидаемого клиентом.

Если порт открыт, но вход невозможен, проверьте режим аутентификации, формат имени пользователя, состояние пароля, отключенные входы в систему, сопоставление пользователей базы данных, разрешения, требования к шифрованию и журналы ошибок сервера. Если запросы подключаются, но выполняются медленно, обратите внимание на блокировки, индексы, ЦП, память, ввод-вывод и планы запросов.

По возможности не допускайте доступа SQL Server в общедоступный Интернет. Ограничивайте источники, требуйте шифрования, исправляйте движок, отключайте неиспользуемые входы в систему, используйте роли с наименьшими привилегиями, меняйте учетные данные и выполняйте аудит неудачных входов в систему и привилегированных действий.

Выполняйте резервное копирование баз данных, тестируйте восстановление, отслеживайте медленные запросы и работоспособность репликации, а также отделяйте административный доступ от доступа к приложениям. Порт базы данных — это прямой путь к конфиденциальным данным, поэтому доступность сети должна сочетаться с строгим контролем идентификации и данных.