PrAw

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

Если авторизация чем-то мешает, то просто можно средствами веб-сервера блокировать доступ не с ип адресов разработчика (.htaccess, nginx.conf), либо организовать cookies, которая будет проверяться перед отдачей контента.

По дешману - не получится.

Варианты:
1. Доскональный шмон трафика с помощью систем, анализирующих потроха пакетов и поднимающие тревогу при любых отклонениях.
За копанию это подразумевает требование расшифровывать любой https трафик, то есть еще та немного веселая задачка. Если трафик не удалось расшифровать или внутри не то, что ожидалось - РЕЗАТЬ.
Очень дорогой вариант. Потребует железа и софта или бесплатного + крутого админа или платного и не очень крутого админа.

2. Белые списки - куда можно коннектиться.

на 6:
чаще всего это будет напоминать типичную работу системы, поэтому проблемно.

Да, небезопасно, альтернативы
1. поднять VPN, доступ к мускулю снаружи только по впн, не напрямую (резать в iptables)

2. (сам использую) пускать разрабов с пробросом портов по ssh. Себе настроил путти (батник):
putty.exe -ssh user@site.ru -L 3396:localhost:3306
в итоге на компе любой удобный и привычный софт можно использовать, указывая в качестве сервера БД
127.0.0.1:3396, со стороны сервера они выглядят как коннекты с localhost
На сервере завести отдельного юзера с минимальнейшими правами - ему даже входить не обязательно в шелл, только до локального сокета достучаться, плюс настроить авторизацию по сертификату для полного удобства.

дополнительный бонус - с использованием ключа "-C" будет еще и компрессия данных, что может приятно повлиять на скорость передачи хорошо сжимаемых данных.