기술 지원
문서
로그인
문의하기
Lifecycle이 다한 운영 체제 관리를 위한 전략
2023년 1월 30일 TuxCare 홍보팀
Lifecycle이 다한 소프트웨어는 빠르게 변화하는 기술 생활의 일부일 뿐입니다. 기술 팀은 소프트웨어 Lifecycle를 관리해야 한다는 것을 알고 있습니다. 또한 어떤 대가를 치르더라도 지원 기간이 만료된 소프트웨어를 실행하지 않아야 한다는 것도 알고 있습니다.
그럼에도 불구하고 조직은 때때로 Lifecycle이 다한 소프트웨어로 인해 곤란한 상황에 처하기도 하고, 때로는 자신의 잘못이 아닌 이유로 곤란한 상황에 처하기도 합니다.
이 글에서는 운영 체제를 중심으로 Lifecycle이 다한 소프트웨어를 처리하는 전략에 대해 설명하지만, 하드웨어나 소프트웨어 등 모든 Lifecycle이 다한 기술에 대해서도 조언이 적용됩니다.
Lifecycle 종료란 무엇을 의미하나요?
기술 변화에 발맞추기 위해 대부분의 소프트웨어 솔루션은 2년마다 대대적인 업데이트가 이루어집니다. 사용자는 최신 버전의 소프트웨어로 마이그레이션해야 하지만, 특히 운영 체제와 같은 소프트웨어의 경우 마이그레이션을 완료하는 데 시간이 필요합니다.
그렇기 때문에 최신 버전으로 대체된 소프트웨어 릴리스는 테스트 및 마이그레이션에 필요한 시간을 확보할 수 있는 지속적인 지원을 받을 수 있습니다.
하지만 어느 시점이 되면 소프트웨어 공급업체는 이전 버전의 소프트웨어에 대한 지원을 중단해야 합니다. 예를 들어 30년 된 운영 체제를 계속 지원하는 것은 현실적이지 않습니다.
단종(EOL)은 공급업체에서 더 이상 지원하거나 유지 보수하지 않는 이러한 유형의 소프트웨어를 설명하는 용어입니다. 이는 제조업체가 더 이상 업데이트, 버그 수정 또는 기술 지원을 제공하지 않으며, 대부분의 경우 중요한 보안 업데이트도 제공하지 않는다는 것을 의미합니다.
따라서 Lifecycle이 다한 운영 체제에서 심각한 보안 결함이 발견되더라도 공급업체의 패치를 기대하지 마세요. 대신 공급업체는 지금쯤이면 사용자와 같은 사용자가 지원되는 버전의 OS로 전환했을 것으로 예상합니다.
결과적으로 공급업체의 지원 없이 Lifecycle이 다한 소프트웨어에 의존하는 사람은 새로 발견된 취약점으로부터 보호하기 위해 공급업체가 제공하는 패치를 적용할 수 없기 때문에 보안 침해에 노출될 수 있습니다.
EOL 소프트웨어가 문제가 되는 이유는 무엇인가요?
"Lifecycle이 다했다"는 말만 들어도 시스템 관리자는 더 늦기 전에 최신 버전의 운영 체제로 업그레이드해야 한다는 동기를 부여받을 필요가 없습니다. 게다가 실제로는 소프트웨어 공급업체가 지원 일정을 오래 전에 게시하기 때문에 기술팀은 충분한 사전 통지를 받습니다.
그렇다면 무엇이 문제일까요? Lifecycle이 다한 소프트웨어가 위험함에도 불구하고 여전히 널리 사용되는 이유는 무엇일까요?
몇 가지 이유가 있습니다. Lifecycle이 다한 소프트웨어는 믿을 수 없을 정도로 안정적이기 때문에 결국 모든 것이 여전히 작동합니다. 보안에 대한 우려 때문에 목적에 완벽하게 부합하는 솔루션을 왜 쫓아내야 할까요?
서버를 차세대 운영 체제로 업데이트하는 것은 번거로운 일이기 때문에 많은 관리자가 이 과정을 미루는 경우가 많습니다. 마이그레이션할 직원 리소스가 너무 부족한 경우도 있습니다.
현재 버전이 원활하게 실행된다고 해서 최신 버전이 문제 없이 실행된다는 의미는 아닙니다. 현재 설치된 소프트웨어가 최신 버전에서 작동하지 않을 수 있으며 구성 변경으로 인해 중단이 발생할 수 있습니다.
그럼에도 불구하고 지원되고 패치가 적용된 OS 릴리스로 마이그레이션하는 것은 기술팀의 주요 책임이며, 대부분의 경우 제시간에 마이그레이션할 수 있고 해야 합니다.
주의 사항으로서의 CentOS
"대부분의 경우"라고 한 이유는 EOL 소프트웨어에 문제가 발생하는 것이 반드시 과로하거나 부주의한 시스템 관리자의 잘못은 아니기 때문입니다. Lifecycle이 다한 소프트웨어 실행의 실질적인 영향에는 공급업체의 결정을 포함하여 다양한 이유가 있을 수 있습니다.
CentOS가 바로 그런 경우입니다. CentOS는 널리 사용되는 Linux 배포판으로, Red Hat Enterprise Linux(RHEL)를 기반으로 합니다. CentOS는 데이터 센터 및 기타 엔터프라이즈급 애플리케이션에 적합한 RHEL의 무료 오픈 소스 대안으로 유명세를 탔습니다.
2021년 12월, Red Hat은 갑자기 CentOS에 대한 지원을 종료한다고 발표하여 일부 CentOS 배포판의 Lifecycle이 종료되는 절벽을 만들었습니다.
공급업체의 지원을 다시 받으려면 상당한 비용을 지불하고 RHEL을 사용하거나 AlmaLinux 또는 RockyLinux와 같은 대체 운영 체제로 전환해야 했기 때문에 많은 조직이 CentOS에 대한 갑작스러운 지원 종료 발표로 인해 안정적이고 신뢰할 수 있는 운영 체제를 갖추지 못했습니다.
그 결과 상당수의 조직이 공급업체의 지원 없이 Lifecycle이 다한 CentOS 6 또는 CentOS 8 머신을 실행하고 있습니다. 그리고 Lifecycle이 다한 소프트웨어에 대한 전략이 제대로 수립되지 않은 조직은결국 매우 어려운 상황에 처하게 됩니다..
중요한 이유: 보안
이제 지원 종료 OS를 실행하는 것이 왜 그렇게 큰 문제인지 자세히 살펴봅시다. EOL 운영 체제 사용의 가장 큰 위협은 지원 만료일 이후에 발견되는 취약점입니다. 왜 그럴까요? 공급업체가 패치를 릴리스하지 않기 때문입니다.
예를 들어, Linux Kernel 2.6.32는 이미 오래 전에 폐기되었지만, Lifecycle이 다한 이후에도 최근인 2019년에 이르기까지 많은 취약점이 발견되었습니다. 이전 Kernel 기반 배포판을 실행하는 모든 Linux 서버는 서비스 거부 공격에 취약할 수 있습니다.
EOL 운영 체제를 설치한 채로 두면 더 이상 보안 패치가 제공되지 않으므로 모든 공개 취약점 발표가 서버를 공격 대상으로 삼게 됩니다. 패치가 없다는 것은 관리자가 인프라를 보호할 수 없다는 뜻입니다.
공격 가능성도 생각보다 높습니다. 많은 서버가 공개적으로 사용 가능하고 공격자가 자동화된 검색 도구를 사용하기 때문에 공격자는 결국 서버가 취약하다는 것을 알아낼 위험이 있습니다.
공격자는 기본적으로 24시간 연중무휴로 아키텍처를 핑거프린팅하고 있으며, 지원되지 않고 취약한 운영 체제를 공격할 것입니다. 그 결과는 끔찍할 수 있습니다.
중요한 이유: 규정 준수 위험
금융 및 의료 정보를 둘러싼 규제 표준은 고객 데이터를 보호하는 특정 사이버 보안 절차를 의무화하고 있습니다. 지원되지 않고 패치가 적용되지 않은 소프트웨어를 실행하는 것은 이러한 여러 규정 준수 표준의 의무에 정면으로 위배되는 행위입니다.
여기에는 정해진 기간 내에 중요한 취약점을 패치하는 것도 포함됩니다. 하지만 패치를 받을 수 없다면 어떻게 해야 할까요? 마찬가지로 규정 준수 규정에 따라 해당 조직은 공급업체 또는 타사 지원이 제공되지 않는 소프트웨어를 사용하는 것이 금지됩니다.
예를 들어 PCI DSS 요건은 결제 카드 데이터를 취급하는 기업을 대상으로 하며 중요한 취약점을 30일 이내에 패치해야 한다는 구체적인 요구 사항이 포함되어 있습니다. 이 기한을 지키지 못하는 조직은 PCI DSS를 준수하지 않는 것으로 간주됩니다.
오래된 소프트웨어는 데이터 유출 후 수년 동안 계속될 수 있는 막대한 벌금과 잔여 소송으로 이어질 수 있습니다. 예를 들어, 2013년에 발생한 Target 데이터 유출에 대한 4천만 달러 규모의 소송은 2016년이 되어서야 해결되었습니다.
중요한 이유: 나머지 중 최고
Lifecycle이 다한 소프트웨어 실행과 관련된 사이버 보안 및 규정 준수 문제가 충분히 우려스럽지 않다면 다음과 같은 이유도 고려해 보시기 바랍니다:
- 호환되지 않는 소프트웨어: 운영 체제가 더 이상 지원되지 않으면 타사 애플리케이션 개발자도 이전 시스템에 대한 지원을 중단합니다. 현재 애플리케이션에 대한 업데이트로 인해 이전 OS에서 문제가 발생하거나 소프트웨어가 더 이상 EOL 운영 체제에서 작동하지 않을 수 있습니다.
- 성능 저하: 오래된 소프트웨어가 오래된 하드웨어에서 실행되는 것은 드문 일이 아닙니다. 이는 네트워크의 오래된 인프라로 인해 병목 현상이 발생할 수 있음을 의미합니다. 오래된 OS에 의존하면 최신 버전의 OS에 내재된 성능 개선 효과도 상실하게 됩니다.
- 신뢰성: 오래된 애플리케이션은 더 이상 지원되지 않기 때문에 충돌과 버그도 패치되지 않습니다. 소프트웨어에 장애가 발생하면 서버가 더 이상 부팅되지 않을 수 있으며, 이는 SLA 및 가동 시간에 영향을 미칩니다.
- 높은 비용: 공급업체에서 더 이상 지원하지 않는 소프트웨어를 수정하고 유지하기 위해 임시방편으로 계속 반창고를 붙이면 비용이 많이 들고, 예기치 않은 결함이 언제 발생할지 알 수 없습니다. EOL 소프트웨어 개발자는 디바이스당 지원 프리미엄을 청구하므로 대규모 조직에서는 비용이 많이 들 수 있습니다.
따라서 EOL 운영 체제가 잘 작동하는 것처럼 보일 수 있습니다, 하지만 진실은 훨씬 더 불길하며 조만간 벽에 부딪힐 가능성이 높습니다.. Lifecycle이 다한 소프트웨어가 어디에 노출되어 있는지 파악하는 것이 시작입니다.
현상 유지로 시작하기
아직 인벤토리 전략이 없다면 이제 인벤토리 전략을 수립해야 할 때입니다. 소프트웨어뿐만 아니라 하드웨어도 폐기해야 할 시점에 도달할 수 있습니다. 인벤토리 관리는 어떤 인프라와 소프트웨어를 업그레이드해야 하고 어떤 인프라를 폐기해야 하는지 파악하는 데 도움이 됩니다.
인벤토리 프로세스는 Lifecycle이 다한 소프트웨어를 강조 표시하여 IT 부서에서 공급업체가 더 이상 지원하지 않는 소프트웨어가 있는 경우 이를 빠르고 쉽게 식별하고 최대한 빨리 업그레이드 또는 교체 계획을 세울 수 있도록 지원합니다.
인벤토리를 기반으로 Lifecycle이 다한 OS를 실행하는 머신이나 노드, 그리고 EOL을 처리할 시간이 충분한 머신이나 노드를 식별할 수 있습니다. 또한 인벤토리 프로세스를 통해 Lifecycle이 다한(또는 거의 다한) OS 인스턴스 중 가장 중요한 인스턴스를 식별하여 인스턴스 제거, 폐기 또는 교체와 관련된 작업의 우선순위를 정할 수 있어야 합니다.
인벤토리 프로세스를 구축하면 Lifecycle이 다한 소프트웨어의 효율적인 교체 또는 업그레이드를 계획하여 예기치 않은 다운타임이나 보안 침해의 위험을 줄일 수 있습니다.
가능한 한 빠르게 마이그레이션 - 가능한 경우
소프트웨어와 운영 체제를 최신 버전으로 업데이트하는 작업은 빠르게 눈덩이처럼 불어날 수 있습니다. 업데이트 지연으로 인한 연쇄 반응을 피하고 급하게 마이그레이션을 진행하여 문제가 발생하지 않도록 하려면 가능한 한 빨리 마이그레이션을 완료해야 합니다.
따라서 계획이 중요합니다. 기술팀은 철저한 인벤토리를 확보하고 공급업체의 EOL 일정과 협력하여 부담을 줄이면서도 제시간에 작업을 완료할 수 있는 방식으로 마이그레이션 명단을 작성할 수 있어야 합니다.
미션 크리티컬 인프라를 업데이트해야 하지만 새 운영 체제는 항상 먼저 테스트해야 합니다. 스테이징 환경의 프로덕션 미러는 마이그레이션 중에 예상치 못한 문제를 제거하는 데 도움이 될 수 있습니다.
서버를 폐기하는 것도 옵션입니다. 결국 서버를 업그레이드하지 않는다면 서버를 폐기해야 할 때가 올 수 있습니다. 다른 대안으로는 폐기 장비를 클라우드로 이전하고 가상화 환경으로 마이그레이션하는 것입니다.
연장 지원 구매 고려하기
제시간에 마이그레이션하는 것이 항상 가능한 것은 아닙니다. 마이그레이션 계획을 철저하게 테스트하는 데 몇 달만 더 있으면 되는 경우도 있습니다. 다행히도 많은 경우 공급업체의 연장 지원 또는 타사 지원을 이용할 수 있습니다.
이 가격은 일반적으로 디바이스당이며 비용이 많이 들 수 있습니다. 예를 들어 Windows 7의 EOL은 2020년 1월이며 첫해 지원은 디바이스당 $25, 두 번째 해는 디바이스당 $100입니다. Linux 배포판의 경우 Ubuntu 및 Red Hat Enterprise Linux를 비롯한 공급업체에서 연장 지원을 제공하지만 포괄적인 엔터프라이즈 플랜에 가입한 고객에게만 상당한 비용을 지불해야 합니다.
타사 공급업체도 또 다른 옵션입니다. 신뢰할 수 있는 공급업체를 찾았다면 매우 합리적인 가격으로 연장 지원을 구매할 수 있습니다. 예를 들어TuxCare의 Lifecycle 연장 지원 의 Lifecycle 종료 버전에 대한 Lifecycle 연장 지원은 서버당 월 4.25달러부터 시작합니다.
이러한 연장 지원 서비스는 공급업체와 타사 제공업체가 연장 지원 기간을 4년 또는 5년으로 제한하기 때문에 결국 소진될 것입니다. 즉, Lifecycle 연장 지원은 계획이 제대로 진행되지 않은 경우에 많은 시간을 벌어줍니다..
최후의 수단 옵션
따라서 때로는 마이그레이션이 제대로 되지 않을 수도 있습니다. 마이그레이션 속도가 충분히 빠르지 않거나, 연장 지원이 제공되지 않거나, 어떤 이유로든 워크로드에 따라 Lifecycle이 다한 운영 체제를 원하든 원하지 않든 현재 상태로 실행해야 하는 경우가 있습니다.
지원되지 않고 패치가 적용되지 않은 잠재적으로 취약한 OS를 반드시 실행해야 하는 경우, 격리 및 위험 관리 관점에서 생각해야 합니다:
- 네트워크 격리별도의 네트워크를 사용하여 지원되지 않는 OS를 실행하는 시스템이 외부 시스템과 상호 작용하지 못하도록 차단합니다. 네트워크와 인터넷에서 다른 디바이스에 대한 액세스를 차단함으로써 네트워크 세분화는 때때로 잠재적인 위협으로부터 EOL 디바이스를 보호할 수 있지만, 완벽한 솔루션은 아니며 효율성에 대한 대가가 따릅니다.
- 격리를 위한 가상화가상화된 환경에서 단종 운영 체제를 호스팅하면 이러한 자산에 대한 제어가 향상되어 보안 사고가 발생했을 때 이미지 재구축이 쉬워지는 동시에 EOL 시스템이 외부 환경에 노출되는 것을 제한할 수 있습니다. 또한 대상 자산을 신속하게 격리하고 다시 초기화할 수 있습니다.
- 애플리케이션 제어 및 화이트리스트: 이전 제안과 마찬가지로 이 전략은 알려진 "정상" 애플리케이션만 실행하고 상호 작용할 수 있도록 허용하여 취약한 OS를 격리합니다. 기본적으로 액세스를 거부하고 사전 승인된 연결만 허용하는 모델입니다.
그럼에도 불구하고 지원되지 않는 OS를 분리하여 실행하지 않으려는 시도는 의심할 여지없이 위험한 전략입니다. - 공격 벡터는 무수히 많으며 교묘한 공격자가 측면으로 조금만 움직여도 격리 노력이 무산될 가능성이 있습니다.
결론
충분한 계획을 세운다면 지원되지 않는 운영 체제를 실행하는 컴퓨터를 격리하는 등의 극단적인 조치를 취하지 않아도 됩니다. 이상적으로는 팀이 제때 마이그레이션하고 쉽게 액세스할 수 있는 공급업체 패치를 통해 항상 안전하게 유지되는 지원되는 OS를 실행해야 합니다.
그러나 CentOS의 예에서 보았듯이 공급업체의 성급한 결정을 포함하여 기술 생활이 방해가 될 수 있습니다.
이러한 경우 타사 지원을 받으면 많은 시간을 벌 수 있습니다.. 원래 공급업체의 지원 계획으로 작업을 수행할 수 있지만 비용이 많이 듭니다. 하지만 Lifecycle이 다한 CentOS, Oracle Linux 또는 Ubuntu를 실행하는 경우 배포 공급업체보다 훨씬 저렴한 비용으로 지속적인 보안 업데이트를 제공하는 TuxCare와 같은 전문가로부터 연장 지원을 구매하는 것을 고려해야 합니다.
