Najlepsze praktyki dotyczące aktualizacji maszyn EC2 Ubuntu

12

Po ostatniej luce w zabezpieczeniach OpenSSL związanej z sercem , chciałbym regularnie aktualizować moje maszyny EC2. Naiwnym podejściem byłoby ustalanie godzinnego zadania CRON dla aktualizacji zabezpieczeń ( sudo apt-get update && sudo unattended-upgrade).

Czy istnieje jakieś ryzyko? Czy istnieje zalecany mechanizm aktualizacji dla maszyn EC2?

unattended-upgrades

— Adam Matan
źródło

13

Pakiet nienadzorowanej aktualizacji to standardowy sposób automatycznego stosowania ważnych poprawek błędów i poprawek bezpieczeństwa w Ubuntu.

Zalecam zainstalowanie tego na każdym systemie Ubuntu:

sudo apt-get update &&
sudo apt-get install unattended-upgrades

Nie musisz tworzyć własnego zadania cron. Pakiet instaluje jeden dla Ciebie.

Możesz edytować konfigurację domyślną, jeśli chcesz zmienić jej zachowanie: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

— Eric Hammond
źródło

Czy są jakieś przemyślenia na temat celowości robienia tego na serwerze produkcyjnym? Denerwuję się, że zmiany wprowadzam po cichu i ryzykuję możliwość niepowodzenia aktualizacji lub problemów.

— ianjs

3

Przez „każdy” rozumiałem także systemy produkcyjne. Automatycznie stosuję łatki bezpieczeństwa Ubuntu od wielu lat i nie pamiętam żadnych poważnych problemów. Denerwuję się, że mam tam serwer produkcyjny bez łatek znanych problemów bezpieczeństwa i ryzykuję możliwość ich wykorzystania. To powiedziawszy, każda sytuacja ma inne potrzeby, więc możesz lepiej przejść rygorystyczną fazę testowania dla każdej łatki. Pamiętaj jednak, że są one wypuszczane przez cały czas, więc będziesz zajęty.

— Eric Hammond

1

Ja nie radzę to chyba masz konfigurację zbędny / klastra. Procedury aktualizacji Ubuntu nie są zbyt trudne, kilkakrotnie zatrzymywałem usługi, a ostatnio nawet uszkodzony sektor rozruchowy ... I nie robimy nic specjalnego - tylko Apache jako odwrotne proxy i aplikacje Tomcat.

— podwójny

1

Używamy unattended-upgradesod 2015 do 2020 roku bez żadnych problemów. Mamy małą konfigurację (na DigitalOcean) z:

nginx
mysql-server
php5-fpm php5-curl php5-mysql

W oparciu o dobrą wydajność w przeszłości, przeprowadzanie aktualizacji w ten sposób jest bezpieczniejsze niż nie robienie tego. Ale to niekoniecznie gwarancja na przyszłość!

To może nie być tak dobry pomysł apache, na podstawie raportów innych użytkowników i moich wcześniejszych doświadczeń z apacheaktualizacjami. [Patrz wyżej i tutaj ]

Dzięki unattended-upgradesręczna interwencja będzie nadal wymagana, gdy wersja zbliży się do EOL .

(Poza pytaniem: z mojego doświadczenia z TWiki, WordPress i Jenkinsem, aktualizowanie tych aplikacji jest w rzeczywistości większym problemem niż sam system operacyjny, chociaż oczywiście powinniśmy naprawdę zrobić jedno i drugie. Dla spokoju ducha, można piaskownicować aplikacje internetowe jako procesy inne niż root działające w kontenerze Docker).

Ale ponieważ pytałeś o najlepsze praktyki , podstawowe podejście zalecane w dokumentacji AWS to:

Utwórz i uruchom nowe wystąpienia, aby zastąpić obecne wystąpienia online. Następnie usuń bieżące instancje.

Nowe instancje będą miały najnowszy zestaw poprawek bezpieczeństwa zainstalowany podczas instalacji.

(Luty 2020)

Można tego dokonać w ramach niebiesko-zielonej strategii wdrażania . Zaletą jest to, że możesz uruchomić testy na nowym serwerze przed przełączeniem ruchu. Jeśli Twoje testy są dokładne, teoretycznie Twoje aktualizacje mogą być w pełni zautomatyzowane, zweryfikowane przed uruchomieniem i bez przestojów.

Inne zalety:

Testy mogą dać ci zaawansowane ostrzeżenie, jeśli wymagana jest ludzka uwaga (w przeciwieństwie do sytuacji unattended-upgrades, gdy ostrzeżenia przychodzą od użytkowników dopiero po wystąpieniu problemu!)
Jeśli Twój system zostanie narażony na szwank lub zdecydujesz się zmienić dostawcę, takie podejście powinno ułatwić wdrożenie nowego wdrożenia. Twoja strategia wdrażania jest oparta na skryptach, a nie na starożytnej pamięci.

Ale oczywiście to podejście wymaga więcej konfiguracji niż zwykła instalacja unattended-upgradesi jest bardziej złożone, więc wciąż jest miejsce na błędy.

AWS wspomina również o wykonaniu polecenia „Aktualizacja stosu zależności zależności”, co wydaje się być ich oficjalnym sposobem wykonywania czegoś podobnego unattended-upgrades. Wygląda na to, że można je uruchomić z interfejsu instancji, ale nie jestem pewien, czy można to zautomatyzować.

— joeytwiddle
źródło