Назад | Перейти на главную страницу

Безопасный удаленный доступ к SQL Server в мультитенантной среде с использованием туннелей TLS

На аналогичный вопрос был дан ответ Вот, и возможность открытия SSH-туннеля была слегка затронута, но консенсус заключался в том, что VPN-туннели будут самым простым решением, что верно, если клиент является «внутренним» пользователем. Этот вопрос немного более конкретен для внешних клиентов. Некоторые проблемы с решением VPN:

Все эти проблемы можно исправить, но это оказалось неудобным решением.

Самый очевидный вариант - обернуть весь доступ к базе данных в вызовы API или использовать Сторонний драйвер ODBC. Я ищу решение, использующее туннели TLS (SSL устарел) так же, как устанавливаются подключения к базе данных Azure.

Я ранее использовал netsh в Windows, чтобы изменить порт локальной службы. Можно ли аналогичным образом добавить туннелирование TLS?

На стороне клиента уже есть встроенная поддержка, добавив Encrypt=True к строке подключения. Это снимок экрана с параметрами клиента SSMS:

Итак, мои основные вопросы:

таким же образом устанавливаются подключения к базе данных Azure

По сути, Azure (при условии, что вы имеете в виду Azure SQL, а не SQL Server, установленный на виртуальной машине Azure или других опциях) открывает адрес интерфейса виртуального SQL-сервера для всего мира, и вы управляете доступом с помощью настроек в разделе безопасности / брандмауэра портала (или связанные вызовы API).

Чтобы имитировать это с помощью локального SQL-сервера, установите правило переадресации портов на пограничном брандмауэре, чтобы разрешить подключения к TCP-порту экземпляра SQL (1433 для экземпляра по умолчанию, если вы его не изменили), с правилами, разрешающими только подключения с определенных адресов источника (для имитации правил, установленных в Azure). Если у вас несколько экземпляров, вы захотите, чтобы они были на фиксированных портах, или вам нужно будет проверять / перенастраивать правила переадресации портов каждый раз при перезапуске экземпляров. Если у вас есть несколько общедоступных IP-адресов, вы можете настроить каждый экземпляр на стандартный порт 1433, если хотите, разместив каждый на другом адресе или имитируя ту же внутреннюю нумерацию портов.

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

SSH устарел

Что ты имеешь в виду? Исключены политикой вашей компании? Сам SSH не является устаревшим и фактически получает более широкую поддержку, поскольку MS включает собственный порт OpenSSH в будущие версии Windows Server, поэтому нет необходимости использовать другие варианты (Cygwin, Linux или другие unix-a- например, виртуальная машина, подсистема Windows для Linux, отдельная машина, похожая на unix), если они вам не нужны по другим причинам.

Можно ли добавить SSH-туннелирование

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

Чтобы использовать SSH-туннели вручную вместо стороннего драйвера, вам просто нужен SSH-сервер, работающий в той же сети, настроенный для разрешения туннелирования, и порт SSH, открытый через ваш брандмауэр так же, как вы бы сделали для разрешения прямых подключений к SQL Server из снаружи. Затем вам нужно будет управлять учетными записями / паролями / ключами в этой службе SSH. Доступ к экземпляру (-ам) SQL через туннель становится таким же простым, как ssh user@111.111.111.111 -L1433:222.222.222.222:1433 где 111.111.111.111 - соответствующий публичный адрес (или DNS-имя для него), а 222.222.222.222 - внутренний адрес SQL-сервера. Затем клиент подключается к localhost (127.0.0.1). Если у них есть локальный экземпляр, прослушивающий порт 1433, им нужно будет изменить спецификацию туннеля на что-то другое, например -L12345:222.222.222.222:1433 тогда они подключатся к locathost:12345.

Я не буду вдаваться в подробности, поскольку мы не относимся к теме вашего вопроса «с использованием туннелей TLS», поскольку SSH не основан на TLS.

мультитеннантная среда

Возможно, вам придется конкретизировать свой вопрос, чтобы включить то, что вы имеете в виду, поскольку фраза может относиться к одному или нескольким из нескольких вещей (несколько клиентов, использующих одни и те же БД, использующие разные БД в одних и тех же экземплярах, использующие разные экземпляры на одном и том же серверы / сеть, ...).

TLS-туннелирование через прокси (что касается обновленного вопроса)

Простые прокси TLS для простых сервисов существуют, я слышал о ряде в прошлом, но я не эксперт, так как у меня никогда не было необходимости их использовать (используя SSH или VPN вместо этого для не веб-трафика и инструментов, специфичных для HTTP. для HTTPS). При таком решении вам потребуется половина прокси-сервера, установленная на клиентских машинах, а также половина сервера внутри брандмауэра (с отображением портов на него) на стороне сервера. Клиентская сторона принимает простое соединение, создает зашифрованную ссылку на свою серверную сторону, через которую передаются передачи, а серверная сторона устанавливает реальное (простое) соединение с сервером.

https://github.com/square/ghostunnel это первый пример, полученный при быстром поиске «прокси TLS». Вы, несомненно, найдете других более глубоким поиском.

Но необходимость установки на стороне клиента может сделать такое решение непопулярным для ваших клиентов.

Встроенная поддержка шифрования

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

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine предлагает настроить его для использования настоящего подтвержденного сертификата. Это несложно (требование «Проверка подлинности сервера» покрывается сертификатами, которые обычно выдаются для HTTPS). SSL-сертификаты для одиночных имен в наши дни дешевы, на самом деле другой быстрый поиск показывает, что использовать бесплатные сертификаты LE несложно: https://sqlsunday.com/2017/11/22/encrypting-tds-with-letsencrypt/

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

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