최근 다음 Heartbleed와의 OpenSSL에의 취약성, 나는 정기적으로 업데이트 내 EC2 기계를 유지하고 싶습니다. 순진한 접근 방식은 보안 업데이트를위한 시간당 크론 작업을 설정하는 것입니다 ( sudo apt-get update && sudo unattended-upgrade).
그렇게 할 위험이 있습니까? EC2 머신에 권장되는 업데이트 메커니즘이 있습니까?
최근 다음 Heartbleed와의 OpenSSL에의 취약성, 나는 정기적으로 업데이트 내 EC2 기계를 유지하고 싶습니다. 순진한 접근 방식은 보안 업데이트를위한 시간당 크론 작업을 설정하는 것입니다 ( sudo apt-get update && sudo unattended-upgrade).
그렇게 할 위험이 있습니까? EC2 머신에 권장되는 업데이트 메커니즘이 있습니까?
답변:
무인 업그레이드 패키지는 우분투에서 중요한 버그 수정 및 보안 패치를 자동으로 적용하는 표준 방법입니다.
모든 우분투 시스템에 이것을 설치하는 것이 좋습니다.
sudo apt-get update &&
sudo apt-get install unattended-upgrades
자신의 크론 작업을 만들 필요가 없습니다. 패키지가 자동으로 설치됩니다.
https://help.ubuntu.com/lts/serverguide/automatic-updates.html 의 동작을 변경하려면 기본 구성을 편집 할 수 있습니다.
우리가 사용하고있는 unattended-upgrades문제없이 2020 2015. 우리는 다음과 같은 작은 설정 (DigitalOcean)을 가지고 있습니다 :
nginxmysql-serverphp5-fpm php5-curl php5-mysql과거의 우수한 성능을 기준으로이 방법으로 업데이트를 수행하면 수행하지 않는 것보다 안전합니다. 그러나 이것이 반드시 미래를 보장하는 것은 아닙니다!
apache다른 사용자의 보고서와 과거의 apache업데이트 경험을 바탕으로하는 것은 좋지 않습니다 . [위와 여기 참조 ]
으로는 unattended-upgrades방출이 접근하면, 수동 개입이 여전히 필요합니다 EOL가 .
(질문을 제외하고 : TWiki, WordPress 및 Jenkins에 대한 나의 경험에서 이러한 앱을 최신 상태로 유지하는 것이 실제로 OS 자체보다 더 큰 관심사입니다. 물론 두 가지를 모두 수행해야합니다. 인터넷에 연결된 앱을 Docker 컨테이너 내에서 루트가 아닌 프로세스로 샌드 박스 할 수 있습니다.)
그러나 모범 사례 에 대해 물었 으므로 AWS 설명서 에서 권장되는 기본 접근 방식 은 다음과 같습니다.
현재 온라인 인스턴스를 대체 할 새 인스턴스를 작성하고 시작하십시오. 그런 다음 현재 인스턴스를 삭제하십시오.
새 인스턴스에는 설치 중에 최신 보안 패치 세트가 설치됩니다.
(2020 년 2 월)
이 작업은 청록색 배포 전략의 일부로 수행 할 수 있습니다 . 여기서 장점은 트래픽을 전환하기 전에 새 서버에 대해 테스트를 실행할 수 있다는 것입니다. 테스트가 철저하다면 이론적으로 업데이트가 완전히 자동화되고 가동되기 전에 다운 타임없이 확인할 수 있습니다.
다른 장점들 :
테스트는 사람의주의가 필요한 경우 고급 경고를 제공 할 수 있습니다 (와 반대로 unattended-upgrades, 문제가 발생하면 사용자로부터 경고가 온 경우 와 반대로 )!
시스템이 손상되거나 공급자를 전환하기로 결정한 경우이 방법을 사용하면 새로 배포 할 수 있습니다. 배포 전략은 고대 메모리가 아니라 스크립트입니다.
그러나 물론이 방법에는 단순히 설치하는 것보다 더 많은 설정이 필요 unattended-upgrades하며 더 복잡하므로 여전히 오류의 여지가 있습니다.
AWS는 "Update Dependencies stack 명령"수행에 대해서도 언급하고 있는데, 이는 공식적인 방식으로와 비슷합니다 unattended-upgrades. 인스턴스 인터페이스에서 트리거 될 수 있지만 자동화 할 수 있는지 확실하지 않습니다.