Продукт моєї компанії, по суті, є вікном Linux (Ubuntu), який сидить у чужій мережі, де працює наше програмне забезпечення. На даний момент у нас було менше 25 коробок у дикій природі, і ми використовували TeamViewer для управління ними.

Зараз ми збираємося доставити 1000 таких скриньок, і TeamViewer більше не є можливим. Моя робота - розібратися у способі доступу до цих скриньок та оновлення програмного забезпечення на них . Це рішення повинно мати можливість пробиватися через брандмауэры та що у вас є.

Я вважав:

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

Це, очевидно, трудомістке і, чесно кажучи, відчуває, як винаходити колесо, оскільки так багато інших компаній, мабуть, вже стикалися з цією проблемою. Тим не менш, я не впевнений, що ми зробимо велику роботу в цьому.

2. Інструменти, такі як лялька, шеф-кухар або OpenVPN

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

Ніхто інший, крім нас, не потребує підключення до цих скриньок. Хтось із відповідним досвідом може дати мені деякі вказівки?

Потягніть оновлення, не натискайте

Як масштабувати, це стане неможливим , щоб зробити поштовх оновлення всіх ваших продуктів.

• Вам доведеться відстежувати кожного клієнта, який може мати іншу конфігурацію брандмауера.
• Вам доведеться створити вхідні з'єднання через брандмауер замовника, що вимагатиме переадресації портів чи іншого подібного механізму. Це ризик для безпеки для ваших клієнтів

Натомість, припускайте, щоб ваші продукти періодично "витягували" свої оновлення, і тоді ви можете додавати додаткову потужність на стороні сервера під час зростання.

Як?

Ця проблема вже вирішена, як ви запропонували. Ось декілька підходів, про які я можу придумати.

• using apt : Використовуйте вбудовану систему apt зі спеціальним списком PPA та джерелами. Як налаштувати PPA?
  • Кон: Якщо ви не користуєтесь публічним хостинговим сервісом, таким як стартовий панель, налаштування власної вподобаної системи упаковки PPA + не для слабкого серця.
• за допомогою ssh : Створіть відкритий ключ SSH для кожного продукту, а потім додайте ключ цього пристрою до своїх серверів оновлення. Потім просто замовте програмне забезпечення rsync/ scpпотрібні файли.
  • Con: Необхідно відстежувати (і створювати резервну копію!) Усіх відкритих ключів кожного продукту, який ви надсилаєте.
  • Pro : Більш захищена, ніж нестандартне завантаження, оскільки єдиними пристроями, які мають доступ до оновлень, були б ті, у яких встановлений відкритий ключ.

• завантаження в неробочому порядку + перевірка підпису :

  • Опублікувати десь підписаний файл оновлення (Amazon S3, FTP-сервер тощо)
  • Ваш продукт періодично перевіряє, чи потрібно змінити файл оновлення, а потім завантажує / перевіряє підпис.
  • Con : Залежно від способу розгортання файлів, ці файли можуть бути загальнодоступними (це може полегшити процес інженерії та злому продукту)

• ansible : Ansible - це чудовий інструмент для управління конфігураціями системи. Це в царині лялькових / шеф-кухарів, але без агентів (використовує пітон) і призначений бути безсильним. Якщо для розгортання програмного забезпечення потрібен складний скрипт bash, я б скористався таким інструментом, щоб зробити його менш складним у виконанні оновлень.

Звичайно, є й інші способи зробити це .. Але це підводить мене до важливого моменту.

Підпишіть / підтвердіть свої оновлення!

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

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

Фізична безпека

Звичайно, якщо хтось має фізичний доступ до розгортання клієнта, він може легко перейняти сервер. Але принаймні вони не можуть атакувати інші розгортання! Фізична безпека, ймовірно, відповідальність вашого клієнта.

Якщо б ви на хвилину, уявіть, що буде, якби ви використовували велику мережу OpenVPN для оновлень ... Вони могли б потім використовувати компрометований сервер для нападу на кожен екземпляр VPN.

Безпека

Що б ви не робили, безпеку потрібно вбудовувати з самого початку. Тут не зрізайте кутів - зрештою ви пошкодуєте про це.

Повна безпека цієї системи оновлень виходить за межі цієї посади, і я настійно рекомендую найняти консультанта, якщо ви або хтось із вашої команди не обізнаний у цій галузі. Варто кожної копійки.

Вам дійсно потрібно отримати доступ до них?

Або просто оновити їх? Тому що ви можете їх оновлювати самостійно, як і те, як доречні оновлення власноруч без нагляду.

Якщо вам потрібно увійти

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

До ваших клієнтів

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

Я пропоную такий інструмент для оркестрації, як лялька чи сіль .

Сіль - це черга повідомлень і може зробити постійне вихідне з'єднання від вашого пристрою до головного сервера. Ви можете використовувати це для запуску довільних команд на пристроях ... як apt-get.

Інший варіант - Ляльковий, де ви все ще маєте головний сервер, і клієнти здійснюють вихідні з'єднання зі своїх місць.

Я використовую обидва ці інструменти для подібних цілей, якщо я, можливо, не маю адміністративного контролю над брандмауером.