Після недавнього heartbleed уразливості OpenSSL, я хотів би, щоб мої EC2 машини оновлюються на регулярній основі. Наївним підходом було б встановлення погодинної задачі cron для оновлень безпеки ( sudo apt-get update && sudo unattended-upgrade).
Чи є ризики зробити це? Чи є рекомендований механізм оновлення машин EC2?
Відповіді:
Пакет без нагляду оновлень - це стандартний спосіб автоматичного застосування важливих виправлень помилок та патчів безпеки в Ubuntu.
Я рекомендую встановити це в кожній системі Ubuntu:
sudo apt-get update &&
sudo apt-get install unattended-upgrades
Вам не потрібно створювати власну роботу cron. Пакет встановлює один для вас.
Ви можете змінити конфігурацію за замовчуванням, якщо хочете змінити її поведінку: https://help.ubuntu.com/lts/serverguide/automatic-updates.html
Ми використовуємо unattended-upgradesз 2015 по 2020 роки без проблем. У нас є невелике налаштування (на DigitalOcean) з:
nginxmysql-serverphp5-fpm php5-curl php5-mysqlСпираючись на хороші минулі показники, робити оновлення таким чином почувається безпечнішим, ніж цього не робити. Але це не обов'язково є гарантією на майбутнє!
Це може бути не такою вдалою ідеєю на apacheоснові звітів інших користувачів та мого минулого досвіду apacheоновлень. [Дивіться вище, і тут ]
З цим unattended-upgrades, ручне втручання все ж буде потрібно, коли випуск наблизиться до EOL .
(Окрім питання: З мого досвіду роботи з TWiki, WordPress та Jenkins, оновлення цих додатків насправді викликає велике занепокоєння, ніж сама ОС, хоча, звичайно, ми повинні дійсно робити і те й інше. Для спокою, ви можете переглядати Інтернет-програми, що переглядають Інтернет, як некореневі процеси, що працюють у контейнері Docker.)
Але оскільки ви запитували про найкращу практику , основним підходом, який рекомендується в документації AWS, є:
Створюйте та запускайте нові екземпляри, щоб замінити поточні онлайн-екземпляри. Потім видаліть поточні екземпляри.
Нові екземпляри матимуть останній набір патчів безпеки, встановлених під час налаштування.
(Лютий 2020 р.)
Це можна зробити як частину синьо-зеленої стратегії розгортання . Перевага тут полягає в тому, що ви можете запускати тести на своєму новому сервері, перш ніж перемикати трафік. Якщо ваші тести ґрунтовні, то теоретично ваші оновлення можуть бути повністю автоматизовані, перевірені перед початком роботи та без простоїв.
Інші переваги:
Тести можуть надати вам розширене попередження, якщо потрібна увага людини (на відміну від тих випадків unattended-upgrades, коли попередження надходять від ваших користувачів лише після появи проблеми!)
Якщо ваша система дійсно скомпрометована або ви вирішили переключитися на провайдерів, такий підхід повинен полегшити розгортання нового розгортання. Ваша стратегія розгортання - це сценарій, а не старовинна пам'ять.
Але, звичайно, для цього підходу потрібно більше налаштування, ніж просто встановлення unattended-upgrades, і більш складна, тому помилки ще є.
AWS також згадує про виконання команди "Стек стеку оновлення залежностей", що, здається, є їх офіційним способом робити щось подібне unattended-upgrades. Здається, що це може бути викликано їх інтерфейсом інстанцій, але я не впевнений, чи можна його автоматизувати.