По сути, продукт моей компании - Linux box (Ubuntu), который находится в чужой сети и работает под нашим программным обеспечением. До сих пор у нас было менее 25 коробок в дикой природе и мы использовали TeamViewer для управления ими.

Сейчас мы собираемся отправить 1000 таких коробок, и TeamViewer больше не является опцией. Моя работа состоит в том, чтобы выяснить способ доступа к этим блокам и обновления программного обеспечения на них . Это решение должно быть в состоянии пробить через брандмауэры и что у вас.

Я рассмотрел:

1. Домашнее решение (например, служба Linux), которое устанавливает обратный туннель SSH к серверу в облаке и другую службу в облаке, которая отслеживает их и позволяет вам подключаться к ним.

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

2. Инструменты, такие как кукольный, шеф-повар или OpenVPN

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

Никто, кроме нас, не должен подключаться к этим коробкам. Есть ли кто-нибудь с соответствующим опытом, который может дать мне несколько советов?

Потяните обновления, не нажимайте

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

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

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

Как?

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

• using apt : используйте встроенную систему apt с пользовательским PPA и списком источников. Как мне настроить PPA?
  • Против: Если вы не используете публичный хостинг, такой как панель запуска, настройка собственной системы упаковки apt PPA + не для слабонервных.
• using ssh : создайте открытый ключ SSH для каждого продукта, а затем добавьте ключ этого устройства на серверы обновлений. Тогда просто имейте свое программное обеспечение rsync/ scpнеобходимые файлы.
  • Против: Необходимо отслеживать (и делать резервные копии!) Все открытые ключи для каждого отправляемого вами продукта.
  • Pro : Более безопасная, чем необработанная загрузка, поскольку единственными устройствами, которые могут получить доступ к обновлениям, будут устройства с установленным открытым ключом.

• сырая загрузка + проверка подписи :

  • Разместите подписанный файл обновления где-нибудь (Amazon S3, FTP-сервер и т. Д.)
  • Ваш продукт периодически проверяет наличие изменений в файле обновления, а затем загружает / проверяет подпись.
  • Против : В зависимости от того, как вы это внедряете, файлы могут быть общедоступными (что может облегчить ваш продукт для обратного проектирования и взлома)

• ansible : Ansible - отличный инструмент для управления конфигурациями системы. Он находится в сфере марионеток / шеф-поваров, но без агентов (использует python) и предназначен для идемпотентности. Если для развертывания вашего программного обеспечения потребуется сложный сценарий bash, я бы использовал такой инструмент, чтобы сделать ваши обновления менее сложными.

Конечно, есть и другие способы сделать это .. Но это подводит меня к важному вопросу.

Подпишите / подтвердите ваши обновления!

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

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

Физическая охрана

Конечно, если кто-то имеет физический доступ к развертыванию клиента, он может легко захватить сервер. Но, по крайней мере, они не могут атаковать другие развертывания! Физическая безопасность, скорее всего, является обязанностью вашего клиента.

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

Безопасность

Что бы вы ни делали, безопасность должна быть встроена с самого начала. Не срезайте здесь углы - вы пожалеете об этом в конце, если это сделаете.

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

Вам действительно нужно получить к ним доступ?

Или просто обновить их? Потому что вы можете сделать так, чтобы они сами обновлялись, подобно тому, как они обновляются самостоятельно.

Если вам нужно войти

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

До ваших клиентов

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

Я предлагаю инструмент для оркестровки, такой как Puppet или Salt .

Соль - это очередь сообщений, которая может установить постоянное исходящее соединение между вашим устройством и главным сервером. Вы можете использовать это для запуска произвольных команд на устройствах ... как apt-get.

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

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