Продукт моей компании - это, по сути, Linux-система (Ubuntu), находящаяся в чужой сети, в которой работает наше программное обеспечение. До сих пор у нас было менее 25 ящиков в дикой природе, и для управления ими мы использовали TeamViewer.
Сейчас мы собираемся отправить 1000 таких коробок, и TeamViewer больше не подходит. Моя работа - найти способ доступ к этим ящикам и обновление программного обеспечения на них. Это решение должно иметь возможность пробивать брандмауэры и то, что у вас есть.
Я рассмотрел:
1. Домашний раствор (например, служба Linux), которая устанавливает Обратный туннель SSH к серверу в облаке и другой облачной службе, которая отслеживает их и позволяет вам подключаться к ним.
Очевидно, что это трудозатратно, и, честно говоря, похоже на изобретение велосипеда, поскольку многие другие компании уже столкнулись с этой проблемой. Тем не менее, я не уверен, что мы хорошо с этим справимся.
2. Такие инструменты, как марионетка, повар или OpenVPN.
Я пытался читать как можно больше, но, похоже, мне не удалось вникнуть в маркетинговые разговоры настолько, чтобы понять очевидный выбор.
Никто, кроме нас, не должен подключаться к этим ящикам. Есть ли кто-нибудь с соответствующим опытом, который может дать мне несколько советов?
По мере того, как вы масштабируете, это станет невозможным От себя обновления для всех ваших продуктов.
Вместо этого пусть ваши продукты периодически «вытягивают» свои обновления, а затем вы можете добавлять дополнительную емкость на стороне сервера по мере своего роста.
Как вы и предлагали, эта проблема уже решена. Вот несколько подходов, которые я могу придумать.
rsync / scp необходимые файлы. необработанная загрузка + проверка подписи:
анзибль: Ansible - отличный инструмент для управления конфигурациями системы. Он относится к сфере puppet / chef, но без агентов (использует python) и разработан как идемпотентный. Если для развертывания вашего программного обеспечения потребуется сложный сценарий bash, я бы использовал такой инструмент, чтобы упростить выполнение ваших обновлений.
Конечно, есть и другие способы сделать это ... Но это подводит меня к важному моменту.
Независимо от того, что вы делаете, это императив что у вас есть механизм, гарантирующий, что ваше обновление не было изменено. Злоумышленник может выдать себя за ваш сервер обновлений в любой из указанных выше конфигураций. Если вы не подтвердите свое обновление, ваш ящик много легче взломать и попасть внутрь.
Хороший способ сделать это - подписать файлы обновлений. Вам придется поддерживать сертификат (или кому-то за это платить), но вы сможете установить свой отпечаток пальца на каждое из своих устройств перед их отправкой, чтобы они могли отклонять обновления, которые были подделаны.
Конечно, если кто-то имеет физический доступ к развертыванию клиента, он легко может взять на себя управление сервером. Но, по крайней мере, они не могут атаковать другие развертывания! Физическая безопасность, скорее всего, является обязанностью вашего клиента.
Если бы вы на мгновение представили, что произошло бы, если бы вы использовали большую сеть OpenVPN для обновлений ... Затем они могли бы использовать скомпрометированный сервер для атаки каждый экземпляр в VPN
Что бы вы ни делали, безопасность должна быть встроенный с начала. Не срезайте углы здесь - вы в конце концов пожалеете, если сделаете это.
Полная защита этой системы обновлений выходит за рамки этого поста, и я настоятельно рекомендую нанять консультанта, если вы или кто-то из вашей команды не осведомлен в этой области. Это стоит каждой копейки.
Вам действительно нужен доступ к ним?
Или просто обновить их? Потому что вы можете сделать так, чтобы они обновлялись сами по себе, подобно тому, как apt обновляется самостоятельно без присмотра.
Если вам нужно авторизоваться
Почему демон OpenSSH не слушает через переадресацию портов? У каждого клиента может быть отдельный ключ для безопасности, и он будет подключаться только при необходимости.
До ваших клиентов
Вы также должны учитывать то, что покупатель готов принять. Им может быть неудобно какой-либо удаленный доступ к своей сети, или им могут быть удобны только определенные технологии / конфигурации.
Я предлагаю инструмент оркестровки, например Кукольный или Поваренная соль.
Salt - это очередь сообщений, которая может установить постоянное исходящее соединение от вашего устройства к главному серверу. Вы можете использовать это для запуска произвольных команд на устройствах ... например, apt-get.
Другой вариант - Puppet, где у вас все еще есть главный сервер, а клиенты устанавливают исходящие соединения из своего местоположения.
Я использую оба этих инструмента для одинаковых целей, когда у меня может не быть административного контроля над брандмауэром.