Produkt mojej firmy to w zasadzie Linux-Box (Ubuntu) siedzący w czyjejś sieci z naszym oprogramowaniem. Do tej pory mieliśmy na wolności mniej niż 25 pudełek i korzystaliśmy z TeamViewer do zarządzania nimi.

Niedługo wyślemy 1000 takich pudeł, a TeamViewer nie jest już opcją. Moim zadaniem jest wymyślenie sposobu dostępu do tych skrzynek i aktualizacji na nich oprogramowania . To rozwiązanie powinno być w stanie przebić się przez zapory ogniowe i to, co masz.

Rozważyłem:

1. Domowe rozwiązanie (np. Usługa Linux), które ustanawia tunel zwrotny SSH do serwera w chmurze oraz inną usługę w chmurze, która śledzi je i pozwala się z nimi połączyć.

Jest to oczywiście pracochłonne i, szczerze mówiąc, wydaje się, że należy wynaleźć koło, ponieważ tak wiele innych firm musiało już napotkać ten problem. Mimo to nie jestem pewien, czy wykonamy w tym świetną robotę.

2. Narzędzia takie jak marionetka, szef kuchni lub OpenVPN

Próbowałem czytać tak dużo, jak to możliwe, ale nie jestem w stanie wniknąć wystarczająco głęboko w mowę marketingową, aby zrozumieć oczywisty wybór.

Nikt poza nami nie musi łączyć się z tymi skrzynkami. Czy jest ktoś z odpowiednim doświadczeniem, który może dać mi wskazówki?

Wyciągaj aktualizacje, nie naciskaj

W miarę skalowania wykonywanie wypychanych aktualizacji wszystkich produktów stanie się niewykonalne .

• Będziesz musiał śledzić każdego klienta, który może mieć inną konfigurację zapory.
• Będziesz musiał utworzyć połączenia przychodzące przez zaporę ogniową klienta, co wymagałoby przekierowania portów lub innego podobnego mechanizmu. Jest to zagrożenie bezpieczeństwa dla Twoich klientów

Zamiast tego spraw, aby Twoje produkty okresowo „pobierały” swoje aktualizacje, a następnie możesz dodać dodatkową pojemność po stronie serwera w miarę rozwoju.

W jaki sposób?

Ten problem został już rozwiązany, jak zasugerowałeś. Oto kilka podejść, które mogę wymyślić.

• using apt : Użyj wbudowanego systemu apt z niestandardową listą PPA i źródłami. Jak skonfigurować PPA?
  • Przeciw: Chyba że korzystasz z publicznej usługi hostingowej, takiej jak starter, konfiguracja własnego systemu pakowania apt PPA + nie jest dla osób o słabym sercu.
• using ssh : Wygeneruj klucz publiczny SSH dla każdego produktu, a następnie dodaj klucz tego urządzenia do serwerów aktualizacji. Następnie wystarczy mieć wymagane oprogramowanie rsync/ scppliki.
  • Przeciw: Musisz śledzić (i tworzyć kopie zapasowe!) Wszystkie klucze publiczne dla każdego wysyłanego produktu.
  • Pro : Bardziej bezpieczne niż surowe pobieranie, ponieważ jedynymi urządzeniami, które mogą uzyskać dostęp do aktualizacji, byłyby te z zainstalowanym kluczem publicznym.

• surowe pobieranie + sprawdzenie podpisu :

  • Opublikuj gdzieś podpisany plik aktualizacji (Amazon S3, serwer FTP itp.)
  • Twój produkt okresowo sprawdza, czy plik aktualizacji ma zostać zmieniony, a następnie pobiera / weryfikuje podpis.
  • Przeciw : W zależności od sposobu wdrożenia pliki mogą być publicznie dostępne (co może ułatwić przywracanie kodu i hakowanie produktu)

• ansible : Ansible to świetne narzędzie do zarządzania konfiguracjami systemu. Jest w sferze marionetek / szefów kuchni, ale jest bezagentowy (używa Pythona) i zaprojektowany tak, by był idempotentny. Jeśli wdrożenie oprogramowania wymagałoby skomplikowanego skryptu bash, użyłbym takiego narzędzia, aby uczynić wykonywanie aktualizacji mniej skomplikowanym.

Oczywiście są inne sposoby, aby to zrobić ... Ale to prowadzi mnie do ważnej kwestii.

Podpisz / sprawdź poprawność swoich aktualizacji!

Bez względu na to, co robisz, konieczne jest posiadanie mechanizmu gwarantującego, że aktualizacja nie zostanie zmieniona. Złośliwy użytkownik może podszyć się pod serwer aktualizacji w dowolnej z powyższych konfiguracji. Jeśli nie zatwierdzić aktualizację Twoja skrzynka jest znacznie łatwiej włamać i dostać.

Dobrym sposobem na to jest podpisanie plików aktualizacji. Będziesz musiał zachować certyfikat (lub zapłacić komuś za to), ale będziesz mógł zainstalować swój odcisk palca na każdym ze swoich urządzeń, zanim wyślesz je, aby mogły odrzucać aktualizacje, które zostały zmodyfikowane.

Bezpieczeństwo fizyczne

Oczywiście, jeśli ktoś ma fizyczny dostęp do wdrożenia klienta, może łatwo przejąć serwer. Ale przynajmniej nie mogą atakować innych wdrożeń! Bezpieczeństwo fizyczne jest prawdopodobnie odpowiedzialnością twojego klienta.

Jeśli byś choć przez chwilę, wyobraź sobie, co by się stało, gdybyś użył dużej sieci OpenVPN do aktualizacji ... Mogliby następnie użyć zainfekowanego serwera do zaatakowania każdej instancji w sieci VPN

Bezpieczeństwo

Cokolwiek robisz, zabezpieczenia muszą być wbudowane od samego początku. Nie rób tutaj zakrętów - w końcu będziesz tego żałować.

Pełne zabezpieczenie tego systemu aktualizacji jest poza zakresem tego postu i zdecydowanie polecam zatrudnienie konsultanta, jeśli ty lub ktoś z twojego zespołu nie ma wiedzy w tej dziedzinie. Jest wart każdego grosza.

Czy naprawdę potrzebujesz do nich dostępu?

Lub po prostu je zaktualizować? Ponieważ możesz sam je zaktualizować, podobnie jak apt apt samodzielnie.

Jeśli musisz się zalogować

Dlaczego nie demon OpenSSH nasłuchuje przez przekierowanie portów? Każdy klient może mieć osobny klucz dla bezpieczeństwa i będzie połączony tylko w razie potrzeby.

Do twoich klientów

Musisz również wziąć pod uwagę to, co klient jest skłonny zaakceptować. Mogą oni nie czuć się komfortowo z jakimkolwiek zdalnym dostępem do swojej sieci lub tylko z określonymi technologiami / konfiguracjami.

Proponuję narzędzie do aranżacji, takie jak Puppet lub Salt .

Sól to kolejka komunikatów i może nawiązywać trwałe połączenie wychodzące z urządzenia do serwera głównego. Możesz użyć tego do uruchamiania dowolnych poleceń na urządzeniach ... jak apt-get.

Inną opcją jest Puppet, gdzie nadal masz serwer główny, a klienci wykonują połączenia wychodzące z ich lokalizacji.

Używam obu tych narzędzi do podobnego celu, w którym mogę nie mieć kontroli administracyjnej zapory.