Я настраиваю два виртуальных частных сервера Ubuntu для своей начинающей компании. «Публичный» сервер (назовем его www.example.com) должен содержать общедоступный веб-сайт компании и ограниченные, но (относительно менее важные) службы, такие как LDAP и почтовые серверы. Сервер "разработчиков" (dev.example.com) будет компанией Fort Knox, содержащей исходный код компании (GIT), артефакты (Artifactory) и инструменты разработчика (Atlassian). Доступ к www.example.com должен быть открыт для всех, в то время как сервер разработки должен быть очень защищенным, доступным только очень ограниченному числу авторизованных разработчиков, а остальная публика в идеале не должна даже догадываться о существовании сервера. Оба сервера будут размещены в хостинговой компании (у нас будет полный root-доступ).
Я планирую настроить веб-доступ, используя то же доменное имя и виртуальные хосты. example.com будет указывать на «публичный» сервер. nginx установленный на "публичном" сервере будет иметь www.example.com виртуальный хост (обслуживается нормально) и dev.example.com виртуальный хост, все запросы к этому хосту будут проксироваться на сервер "dev", на котором запущен другой nginx. Брандмауэр на сервере "dev" будет настроен на запрет всего входящего трафика, кроме HTTPS и SSH звонки, поступающие с «публичного» сервера. Так что не только прямые подключения к nginx Сервер, на котором запущены инструменты разработчика на сервере «dev», будет невозможен, но нам также необходимо сначала войти в систему на общедоступном сервере, чтобы затем иметь возможность подключиться по SSH к серверу «dev». Таким образом, потенциальный хакер не сможет получить прямой доступ к серверу "dev" без предварительного взлома общедоступного сервера.
Если это имеет значение, на серверах, вероятно, будет работать Ubuntu 16.04 (у нас есть выбор между 14.04, 16.04, 18.04 и другими версиями Linux, но Ubuntu 16.04 для меня звучит нормально). Я не специалист по безопасности и не системный администратор.
У меня два вопроса.
1) Звучит ли это как хорошая безопасная установка, подтверждающая «лучшие практики», или есть лучшие (более простые или более безопасные) способы достижения тех же целей?
2) [Главный вопрос]. Как я могу ограничить доступ HTTPS, чтобы только разработчики могли получить доступ к dev.example.com, в то время как другие пользователи вообще не видели этот виртуальный хост, даже если они угадали URL? У меня пока есть две идеи.
требуется туннель SSH. Виртуальный хост dev.example.com в nginx на «общедоступном» сервере будет настроен на прием запросов только с самого «общедоступного» IP-адреса сервера, поэтому разработчикам придется настроить SSH-туннель к «общедоступному» серверу для доступа dev.example.com. С такими инструментами, как MyEnTunnel (Window), легко настроить SSH-туннель, чтобы он автоматически устанавливался во время загрузки. Однако я вижу большой недостаток в том, что каждый разработчик должен определить, что "dev.example.com" относится к localhost в их файле hosts (или есть другие способы?)
Сертификаты клиентов. nginx на "общедоступном" сервере в основном потребуется сертификат клиента для доступа dev.example.com. У каждого разработчика будет свой собственный клиентский сертификат для доступа к dev.example.com в дополнение к обычному логину и паролю, которые они будут использовать для доступа к инструментам разработчика. Однако я не очень хорошо знаком с клиентскими сертификатами и не понимаю всех последствий. Один недостаток, который я вижу, заключается в том, что, вероятно, когда неавторизованный человек пытается получить доступ dev.example.com он / она получит ошибку «сертификат клиента», которая покажет, что сервер разработчика существует, в то время как при первом подходе они просто не смогут подключиться.
Что бы вы мне посоветовали? Идея состоит в том, чтобы сделать его простым, дешевым и в то же время максимально безопасным, пока компания не вырастет до такой степени, когда она сможет позволить себе системных администраторов и собственный центр обработки данных.
Часть 1:
Доступ к высокозащищенному серверу через вход на общедоступный не очень защищенный сервер вызывает у меня неприятные ощущения в животе, как будто я проехал верх на американских горках.
Если вы хотите иметь безопасный сервер разработки, защитите его. Устанавливайте только необходимые / полезные вещи. Безопасность ограничена тем, что вы контролируете - ваш хостинг-провайдер в любом случае имеет доступ, если хочет - у них есть физический доступ.
Если вы хотите скрыть свой сервер разработки, скройте его. Отбросьте любой входящий сетевой трафик. Может быть, вы хотите использовать стук порта, чтобы открыть свои личные двери. Но имейте в виду, что ваш провайдер все это видит.
Часть 2:
Да, если все службы вашего dev-сервера будут прослушивать только localhost, это простой и легкий способ одновременно скрыть и защитить ваш сервер.
Требовать от пользователей использования туннелей ssh - это нормально. Он работает, настраивается за несколько минут и может быть выполнен практически с любым бинарным файлом ssh. На мой взгляд, хорошая идея.
Если вы закроете все остальные двери, у вас останется дверь ssh, которая будет видна внешнему миру. Вы можете переместить его на задний двор, изменив порт 22 на случайный, например, 32109.
Клиентские сертификаты дополняют этот тип безопасности, на мой взгляд, более чем достаточно. Если потребуется больше, то отсутствие собственного физического форта, где ваш сервер защищен от несанкционированного физического доступа, было бы крайне небрежным.
Никто не получит ошибку «сертификат клиента», пока не установит свой туннель ssh, так что не беспокойтесь об этом.
Нет, ваши разработчики не будут определять, что dev.mydomain.com относится к localhost, иначе они не смогли бы использовать ssh для него. Они могут безопасно получить доступ к вашему серверу разработки через localhost или запись hosts "127.0.0.1 mydev" или как там вы его называете внутри. Для этого не требуется общедоступное имя.
На вашем Ubuntu 18.04 - вы опережаете время ;-) Если вы хотите использовать Ubuntu, используйте 16.04. Он выдержит фазу запуска вашей компании. Хотя и другие ароматы тоже подходят. Убедитесь, что обновления будут доступны хотя бы в течение нескольких лет, например, 04/2021 для вашей Ubuntu-16.04.
Кстати: если вы хотите скрыть свой сервер разработки, не указывайте ему запись службы имен, например dev.myserver.com; вам это не нужно, другим будет нужно меньше. Просто поместите его в файлы hosts вашего разработчика.
Радоваться, веселиться!
TomTomTom