Log4j 취약점 위험

이 블로그 글의 AI 요약으로 바로 가기

2021년 12월을 기억하시나요? Log4Shell 취약점이 공개되자 전 세계 모든 엔지니어링 팀이 일제히 당황하며, 자사 시스템에 Log4j가 설치되어 있는지, 스택 내 어디에 숨어 있는지, 그리고 얼마나 빨리 패치를 적용할 수 있을지 확인하느라 분주했던 그 때를 말입니다.

대부분의 팀은 그 일이 2022년 초에 끝났다고 생각합니다. 그들은 애플리케이션에 패치를 적용하고, 종속성을 점검하고, 어쩌면 몇 가지 라이브러리를 업그레이드한 뒤, 그 일을 뒤로 한 채 넘어갔습니다. Log4j는 ‘그때가 기억나시나요?’라고 회상하게 되는 사건 중 하나가 되었습니다. 당시에는 스트레스가 컸지만, 이제는 해결된 문제인 셈이죠.

하지만 문제는 해결되지 않았다. 해결될 기미조차 보이지 않는다.

사실 Log4j 취약점의 위험은 초기 Log4Shell 대응 조치가 끝난 후에도 사라지지 않았습니다. 단지 표면적으로는 잠잠해졌을 뿐, 발견하기가 더 어려워졌을 뿐입니다. 2026년인 오늘날에도 취약한 Log4j 인스턴스는 여전히 운영 환경에 숨어 있으며, 팀들이 수년 전부터 더 이상 살펴보지 않는 곳에 파묻혀 있습니다. 이는 엔지니어링 팀이 부주의해서가 아닙니다. 소프트웨어 종속성이 작동하는 방식의 특성상, "한 번 패치를 적용했다"는 사실이 종종 잘못된 안심감으로 이어지기 때문입니다.

지금 Log4j의 진정한 위험 요소가 어디에 있는지, 왜 이 문제가 계속해서 재부상하는지, 그리고 숨겨진 종속성이 층층이 쌓여 있는 최신 소프트웨어 스택을 다룰 때 실제로 효과적인 완화 방안은 어떤 것인지에 대해 이야기해 봅시다.

Log4Shell을 넘어선 Log4j 취약점 현황

Log4Shell(CVE-2021-44228)은 당연히도 모든 이목을 집중시켰습니다. 자바 생태계의 절반이 사용하는 로깅 라이브러리의 원격 코드 실행 취약점은 그야말로 최악의 상황이라 할 수 있습니다. 하지만 Log4Shell에만 집중하는 것은 수면 위에 보이는 상어만 걱정하고 수면 아래를 맴도는 상어들은 무시하는 것과 같습니다.

Log4Shell 사건 이후, Log4j와 관련된 여러 추가 취약점이 발견되었습니다. CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 등 여러 취약점이 비교적 짧은 기간 내에 잇달아 보고되었습니다. 이들 각각은 즉각적인 대응이 필요했고, 패치를 적용해야 했으며, Log4j라는 구성 요소가 그 한 번의 주목할 만한 RCE(원격 코드 실행) 취약점뿐만 아니라 더 근본적인 보안 문제를 안고 있음을 입증했습니다.

특히 교묘한 점은, 이후 발견된 이러한 취약점들이 Log4Shell과 다른 버전 범위에 영향을 미치는 경우가 많다는 것입니다. Log4Shell 문제를 해결하기 위해 Log4j 2.14.1에서 2.15.0으로 업그레이드한 팀은 CVE-2021-45046에 취약했을 수 있습니다. 2.16.0으로 업그레이드하면 이 문제는 해결되었지만, 이전 버전들은 여전히 CVE-2021-44832에 대한 우려가 남아 있었습니다. 이러한 취약점과의 끝없는 싸움은 '안전한' 버전을 추적하는 일을 복잡하게 만들었고, 많은 조직이 어떤 시스템이 완전히 수정되었는지, 아니면 부분적으로만 패치되었는지 파악하지 못하게 되었습니다.

그리고 모두가 알고 있지만 누구도 언급하지 않는 문제, 바로 Log4j 1.x가 있습니다. 대중의 우려는 대부분 Log4j 2.x의 취약점에 집중되었지만, Log4j 1.x 역시 고유한 보안 문제를 안고 있으며 2015년에 이미 지원이 종료되었습니다. 하지만 여전히 Log4j 2.x로 마이그레이션하지 않은 운영 시스템에서 Log4j 1.x가 사용되고 있습니다. 이러한 시스템은 코드베이스가 더 이상 유지보수되지 않기 때문에 공식 패치를 받을 수 없는 취약점에 노출되어 있습니다.

취약점 현황 또한 정적이지 않습니다. 보안 연구원들은 여전히 로깅 라이브러리에서 문제를 발견하고 있습니다. Log4Shell 사태가 Log4j 및 유사 구성 요소에 대한 관심을 불러일으킨 덕분에, 이제 더 많은 이들이 문제점을 찾아내고 있습니다. 우리가 Log4j의 마지막 취약점을 발견했다고 가정하는 것은 순진한 생각일 것입니다.

현대적인 스택 내에서 Log4j가 숨어 있는 곳

Log4j의 보안 위험이 여전히 존재하는 이유는 개발팀이 이를 의도적으로 무시하기 때문이 아닙니다. 현대적인 애플리케이션 스택에서 Log4j가 사용된 모든 부분을 찾아내는 것이 실제로 매우 어렵기 때문입니다.

전달적 의존성 가장 흔한 숨겨진 원인이 바로 여기입니다. 여러분의 애플리케이션이 Log4j에 직접 의존하지는 않더라도, 의존성 중 하나가 Log4j에 의존할 수 있습니다. 혹은 그 의존성의 또 다른 의존성이 Log4j에 의존할 수도 있습니다. 아니면 의존성 트리에서 여러 계층 아래로 내려가다 보면, 3단계 아래 어딘가에 Log4j 2.14.0이 숨어 있을 수도 있습니다.

의존성 스캔 도구는 도움이 되지만 완벽하지는 않습니다. 이러한 도구는 프로젝트의 선언된 의존성 파일에 포함된 알려진 의존성에 대해서는 알려줄 수 있지만, 항상 모든 것을 포착하는 것은 아닙니다. 때로는 라이브러리가 의존성을 숨기기도 하는데, 표준 의존성 분석에서는 드러나지 않는 방식으로 내부적으로 묶어두는 경우가 있습니다. 또 어떤 경우에는 의존성이 바이너리 아티팩트 내에 존재하는데, 스캐너가 이를 충분히 깊이 검사하지 못하는 경우도 있습니다.

컨테이너화된 애플리케이션 는 그 나름의 문제를 안고 있습니다. Log4Shell이 알려지기 전인 몇 달 또는 몇 년 전에 빌드된 컨테이너 이미지를 실행하고 있을 수도 있습니다. 기본 이미지에는 취약한 Log4j 버전이 포함되어 있을 수 있습니다. 애플리케이션 레이어에서 취약점이 추가될 수도 있습니다. 이미지를 정기적으로 재빌드하고 재스캔하지 않는 한, 현재 소스 코드가 안전하더라도 이러한 취약점은 계속 남아 있게 됩니다.

타사 애플리케이션과 상용 소프트웨어는 종종 Log4j를 포함한 자체 종속성을 번들로 제공합니다. 2020년에 배포한 그 엔터프라이즈 모니터링 도구는 어떨까요? 내부적으로 Log4j 2.12.1을 실행 중일 수 있지만, 공급업체의 블랙박스이기 때문에 이를 파악할 수 없습니다. 공급업체가 패치된 버전을 출시했을 수도 있지만, 공급업체의 보안 권고 사항을 면밀히 추적하지 않거나 업그레이드에 상당한 테스트와 가동 중단 시간이 필요한 경우, 그 취약한 인스턴스는 그대로 남아 있게 됩니다.

또한 Log4j 취약점 수정 사항을 적용하는 방법에 대한 기술 가이드를 참고하여 복잡한 스택 전반에 걸쳐 숨겨진 종속성을 파악할 수도 있습니다.

빌드 도구와 개발 환경 때로는 프로덕션 애플리케이션의 직접적인 구성 요소는 아니지만 여전히 위험 요소가 될 수 있는 취약한 Log4j 버전이 포함되어 있는 경우가 있습니다. Jenkins 플러그인, Maven 저장소, IDE 확장 프로그램 등에는 모두 Log4j가 포함되어 있을 수 있으며, 이러한 요소들은 프로덕션 환경에 초점을 맞춘 취약점 스캔에 항상 포함되는 것은 아닙니다.

레거시 시스템과 변경이 중단된 코드베이스 아마도 가장 큰 난관일 것입니다. 안정적이라서, 혹은 “아무도 건드리고 싶어 하지 않아서” 5년 동안 변경 없이 가동되어 온 그 중요한 자바 애플리케이션 말입니다. 아마도 그 안에는 취약한 Log4j가 포함되어 있을 것입니다. 하지만 이를 업그레이드하려면 최신 JDK 버전으로 테스트를 수행하고, 수년 동안 손대지 않은 통합 기능을 검증해야 하며, 심지어 중요한 종속성이 더 이상 유지 관리되지 않는다는 사실을 발견할 수도 있습니다.

임베디드 구성 요소와 어플라이언스 이 목록을 완성합니다. 네트워크 장치, 보안 어플라이언스, IoT 시스템 및 기타 임베디드 Java 애플리케이션은 내부적으로 Log4j를 사용하는 경우가 많습니다. 이러한 시스템은 일반적으로 패치 적용이 가장 어려운 편인데, 이는 업데이트가 공급업체를 통해 제공되어야 하고, 업그레이드 주기가 느리며, 때로는 공급업체 자체가 폐업했거나 제품 지원을 중단한 경우도 있기 때문입니다.

이 모든 시나리오의 공통점은 ‘보이지 않는다는 점’입니다. 이러한 Log4j 인스턴스는 메인 애플리케이션의 종속성 트리에는 나타나지 않습니다. 또한 일반적인 패치 프로세스의 적용 범위에도 포함되지 않습니다. 이들은 사용자가 실행하고 있다고 생각하는 것과 실제로 배포된 것 사이의 틈새에 존재합니다.

왜 “한 번 고쳤는데”라는 말이 통하지 않는가

2021년 말과 2022년 초에 철저한 보안 조치를 취했던 팀들조차도, 취약한 Log4j 인스턴스가 다시 환경으로 스며드는 것을 종종 발견합니다. 이는 패치 효과가 사라졌기 때문이 아니라, 소프트웨어 생태계가 끊임없이 변화하기 때문입니다.

새로운 배포 과정에서 오래된 취약점이 유입됩니다. 개발자가 2020년 프로젝트 템플릿을 기반으로 새로운 마이크로서비스를 구축합니다. 이 템플릿에는 구형 종속성이 포함되어 있습니다. 종속성 관리가 매우 철저하지 않은 한, 조직에서 2년 전에 Log4j 취약점을 "수정"했더라도 해당 신규 서비스에는 취약한 Log4j가 포함된 채 배포될 수 있습니다.
의존성 업데이트로 인해 수정 사항이 되돌려질 수 있습니다. 관련 없는 라이브러리를 업그레이드하면, 해당 라이브러리가 의존성 중 하나를 더 오래된 버전으로 가져오게 되고, 이로 인해 취약점이 있는 Log4j 버전이 간접적으로 다시 사용되게 됩니다. 의존성 해결 규칙이 이를 방지하기에 충분히 엄격하지 않거나, 호환성 문제로 인해 버전 충돌 해결 알고리즘이 취약점이 있는 버전을 선택할 수 있습니다.
인수합병과 시스템 통합은 외부 코드를 가져옵니다. 귀사가 다른 회사를 인수하거나 파트너사의 시스템과 통합하게 됩니다. 그러면 갑자기 귀사는 상대방의 코드베이스에 대한 책임을 지게 되는데, 해당 코드베이스는 귀사의 코드베이스만큼 Log4j 취약점 해결에 신경을 쓰지 않았을 수도 있습니다.
섀도우 IT와 비공식 배포 표준 절차를 우회합니다. 팀이 서둘러 무언가를 배포하면서 일반적인 보안 검사 및 승인 절차를 생략하기도 합니다. 또는 누군가가 "임시"로 시작한 서비스가 영구적으로 운영되기도 합니다. 이러한 무단 배포에는 이미 제거되었다고 생각했던 취약점이 포함되어 있는 경우가 많습니다.
백업 복원 및 재해 복구 취약한 버전을 다시 활성화할 수 있습니다. Log4Shell이 알려지기 전에 생성된 백업에서 시스템을 복원하거나, 보관된 배포 아티팩트를 사용하여 서비스를 재구축할 수 있습니다. 이러한 복구 시나리오에서 Log4j를 특별히 확인하지 않는다면, 취약한 코드를 다시 운영 환경에 배포하게 될 수 있습니다.

근본적인 문제는 소프트웨어 보안이 달성해야 할 목표가 아니라 지속적으로 유지해야 할 과정이라는 점입니다. ‘패치 적용’은 영구적인 상태가 아닙니다. 이를 위해서는 지속적인 경계와 정기적인 재스캔이 필요할 뿐만 아니라, 실제로 실행 중인 프로그램과 실행되어야 한다고 생각하는 프로그램 간의 차이를 항상 파악하고 있어야 합니다.

현실 세계에서의 위험 평가

모든 Log4j 인스턴스가 동일한 수준의 위험을 내포하는 것은 아닙니다. 실제 위험 노출 정도를 파악하면 모든 상황을 똑같이 시급한 위기 상황으로 취급하기보다, 해결 조치를 현명하게 우선순위를 정할 수 있습니다.

노출 여부가 가장 중요합니다. 신뢰할 수 없는 사용자 입력을 처리하는 인터넷에 노출된 웹 애플리케이션 내의 취약한 Log4j 인스턴스는 고위험군에 속합니다. 반면, 신뢰할 수 있는 출처의 구조화된 데이터만 처리하는 내부 배치 처리 작업 내의 취약한 Log4j 인스턴스는 위험도가 낮습니다. 취약점 자체는 동일하지만, 실제 악용 가능성은 다릅니다.
데이터의 민감도가 높을수록 위험도 커집니다. 결제 정보, 개인 건강 기록 또는 기타 규제 대상 데이터를 처리하는 시스템은 Log4j 취약점으로 인해 더 큰 위험에 직면합니다. 보안 침해는 단순히 기술적 취약점을 의미하는 것이 아니라, 규정 위반, 법적 책임 및 규제 당국의 제재를 의미합니다.
네트워크 위치가 취약점 악용 가능성에 영향을 미칩니다. 내부 네트워크에서만 접근 가능한 시스템의 Log4j 취약점은 공용 인터넷에 노출된 취약점보다 당장 악용될 가능성이 낮습니다. 그렇다고 해서 안전하다는 뜻은 아니지만, 위협 모델과 대응의 시급성은 달라집니다.
취약점 악용 코드의 유무가 대응 일정에 영향을 미칩니다. 특정 Log4j 취약점에 대한 작동 가능한 익스플로잇이 공개되고 공격자들이 이를 적극적으로 활용하기 시작하면, 안전하게 문제를 해결할 수 있는 시간은 급격히 줄어듭니다. 익스플로잇 생태계가 이미 성숙한 기존 취약점은 아직 연구 단계에 있는 새로 발견된 문제보다 더 위험합니다.
보완 통제 수단은 실질적인 위험을 줄여줍니다. 취약한 Log4j 인스턴스가 JNDI 조회 패턴을 차단하도록 구성된 웹 애플리케이션 방화벽 뒤에 위치해 있거나, 런타임 애플리케이션 보호 도구가 악용 시도를 모니터링하고 있는 경우, 실질적인 위험은 완전히 보호되지 않은 배포 환경보다 낮습니다. 이러한 조치들은 패치 적용을 대체할 수는 없지만, 위험 평가에는 영향을 미칩니다.

위험 평가의 목적은 무대응을 정당화하기 위한 것이 아닙니다. 이는 제한된 보안 대응 자원을 실제 보안 상태에 가장 큰 영향을 미칠 수 있는 분야에 효과적으로 배분할 수 있도록 돕기 위함입니다.

실용적인 완화 전략

자, 이제 여러분의 환경에서 Log4j 취약점을 확인하셨습니다. 일부는 쉽게 해결할 수 있지만, 다른 일부는 복잡합니다. 실제로 효과적인 대응 방안은 다음과 같습니다.

종합적인 탐색 우선

찾지 못한 문제는 해결할 수 없습니다. 임시방편으로 해결하기 전에 철저한 원인 파악에 투자하십시오.

다양한 스캔 방식을 활용하십시오: 소스 코드 종속성 분석, 컨테이너 이미지 스캔, 배포된 아티팩트의 바이너리 분석, 런타임 탐지 등이 있습니다. 각 방식은 서로 다른 요소를 포착합니다. 소스 코드 스캔은 명시된 종속성을 찾아냅니다. 컨테이너 스캔은 베이스 이미지의 취약점을 포착합니다. 바이너리 분석은 숨겨진 종속성을 찾아냅니다. 런타임 탐지는 프로덕션 환경에 실제로 로드된 요소를 식별합니다.

스캔 범위를 운영 환경에만 국한하지 마십시오. 개발 환경, 빌드 시스템, 스테이징 환경 및 코드가 실행되는 모든 곳을 점검하십시오. 개발자의 노트북에 있는 취약한 Log4j는 당장 운영 환경에 직접적인 위험을 초래하지는 않을 수 있지만, 기술적 부채이자 향후 잠재적인 위험 요인이 될 수 있습니다.

발견한 내용을 구체적으로 기록하십시오. 어떤 시스템인지, 어떤 Log4j 버전인지, 어떤 코드 경로에서 실제로 로깅 기능을 사용하는지, 그리고 취약점이 어떤 형태로 나타나는지 등을 명시하십시오. 이 목록은 향후 문제 해결을 위한 로드맵이 될 것입니다.

실제 위험도를 기준으로 우선순위를 정하십시오

가장 위험이 높은 사례를 우선적으로 해결하십시오. 즉, 인터넷에 노출된 시스템, 민감한 데이터를 처리하는 시스템, 그리고 현재 악용되고 있는 것으로 알려진 패턴이 있는 모든 시스템을 의미합니다.

중간 위험 등급의 시스템에 대해서는 적절한 개선 방안을 마련하는 동안 보완적 통제 조치를 시행하십시오. WAF 규칙을 적용하고, 런타임 모니터링을 활성화하며, 네트워크 접근을 제한하고, 추가적인 인증 단계를 도입하십시오. 이러한 완화 조치를 통해 서두르지 않고 체계적으로 업그레이드를 진행할 수 있는 시간을 확보할 수 있습니다.

위험도가 낮은 시스템의 경우, 일정을 좀 더 여유 있게 잡을 수는 있지만, ‘위험도가 낮다’는 이유로 ‘영원히 수정하지 않는’ 상황이 되어서는 안 됩니다. 구체적인 마감일을 정하고 이를 철저히 준수하십시오.

가능한 경우 업그레이드하십시오

Log4j 취약점을 제대로 해결하려면 패치된 버전으로 업그레이드해야 합니다. Log4j 2.x의 경우, 2022년 초까지 발견된 모든 주요 취약점을 해결한 버전 2.17.1 이상으로 업데이트해야 합니다.

업그레이드를 철저히 테스트하십시오. Log4j 버전이 변경되면, 특히 구성 및 성능 측면에서 동작상의 차이가 발생할 수 있습니다. 정식 배포 전에 프로덕션 환경을 그대로 반영한 스테이징 환경에서 검증하십시오.

상위 종속성 제약으로 인해 Log4j를 직접 업그레이드할 수 없는 경우, Log4j를 포함하는 종속성을 업그레이드해 보십시오. 문제를 완전히 해결하려면 종속성 트리의 여러 계층을 업데이트해야 할 때도 있습니다.

Log4j 1.x에서 마이그레이션하기

아직도 Log4j 1.x를 사용하고 있다면, 지원이 중단되고 유지보수가 이루어지지 않는 코드베이스를 사용하고 있는 것입니다. 올바른 조치는 Log4j 2.x, Logback 또는 기타 유지보수가 이루어지는 최신 로깅 프레임워크로 마이그레이션하는 것입니다.

이는 종종 상당한 작업이 됩니다. 구성 형식이 다르고, API도 변경되었으며, 종속성 업데이트가 필요할 수도 있습니다. 하지만 이는 수년 전에 이미 완료되었어야 할 필수적인 작업이며, 더 이상 미룰 수 없는 일입니다.

마이그레이션을 단계별로 계획하십시오. 우선 중요도가 낮은 시스템부터 시작하여 진행 패턴을 파악하고 문제점을 확인하십시오. 내부 문서와 마이그레이션 가이드라인을 마련하십시오. 그런 다음 운영 시스템을 체계적으로 처리해 나가십시오.

공급업체 및 제3자 구성 요소 처리

상용 소프트웨어 및 공급업체가 제공하는 구성 요소의 경우, 보안 권고 사항과 업데이트 일정을 확인하십시오. 많은 공급업체가 Log4j 패치를 배포했으나, 이를 고객의 배포 환경에 자동으로 적용하지는 않습니다.

공급업체가 소프트웨어 패치를 적용하지 않았다면 상급 부서로 문제를 보고하십시오. 지원 티켓을 등록하고 담당 계정 관리자를 참여시키며, 이 문제가 서비스 지속 이용에 있어 필수적인 해결 사항임을 분명히 하십시오. 공급업체는 고객의 압박에 반응하며, 특히 여러 고객이 동시에 압력을 가할 때 더욱 그렇습니다.

업데이트가 불가능한 핵심 공급업체 소프트웨어의 경우, 네트워크 격리 및 추가적인 보안 조치를 적용하십시오. 소프트웨어에 패치를 적용할 수 없다고 해서 그 위험 노출을 제한할 수 없는 것은 아닙니다.

정화 작업이 난관에 부딪혔을 때

최선을 다했음에도 불구하고, 일부 Log4j 인스턴스는 수정 조치가 불가능한 경우가 있습니다. 쉽게 업그레이드할 수 없는 지원이 중단된 레거시 시스템, 더 이상 패치를 제공받지 못하는 벤더 소프트웨어, 혹은 최신 Log4j 버전으로 전환하려면 대대적인 수정이 필요한 맞춤형 애플리케이션 등을 다루고 계실 수 있습니다.

이러한 경우, 확장 보안 지원 옵션이 대안이 될 수 있습니다. TuxCare의 Log4j용 Endless Lifecycle Support 와 같은 서비스는 공식 업데이트를 받을 수 없는 레거시 Log4j 인스턴스를 포함하여, 지원이 종료된 구형 소프트웨어 버전에 대한 보안 패치를 제공할 수 있습니다.

이는 장기적인 해결책도 아니고, 필요한 업그레이드를 미루기 위한 핑계도 아닙니다. 하지만 기술적으로 즉각적인 대응이 불가능한 상황에서 활용할 수 있는 실용적인 대안이 될 수 있습니다. 마이그레이션에만 18개월이 소요되는 변경이 불가능한 레거시 애플리케이션에서 Log4j 1.x를 계속 사용해야 하는 경우, 확장 지원 서비스를 통해 마이그레이션 계획을 실행하는 동안 해당 인스턴스에 알려진 취약점에 대한 패치를 지속적으로 적용할 수 있습니다.

이를 패치가 전혀 적용되지 않은 소프트웨어를 사용함으로써 발생하는 모든 위험을 감수하지 않으면서 시간을 벌 수 있는 방법이라고 생각하십시오. 결국에는 해당 시스템을 현대화해야 할 책임은 여전히 남아 있지만, 새로운 문제를 야기하거나 업무에 차질을 빚을 수 있는 성급한 마이그레이션을 강행할 필요는 없습니다.

핵심은 전략을 명확히 하는 것입니다. 연장된 지원은 적절한 문제 해결을 대신할 수 없습니다. 이는 위기에 쫓겨 서두르기보다는 합리적인 일정에 따라 문제를 해결할 수 있도록 해주는 가교 역할을 합니다.

지속 가능한 보안 관행 구축

Log4j 사태에서 얻을 수 있는 진정한 교훈은 이 특정 라이브러리에 관한 것이 아닙니다. 이는 소프트웨어 종속성의 본질과 현대 애플리케이션의 보안을 관리하기 위해 필요한 지속적인 경계심에 관한 것입니다.

의존성 관리 체계 의존성 관리는 위기가 닥쳤을 때나 떠올리는 것이 아니라, 핵심 엔지니어링 관행이 되어야 합니다. 즉, 정기적인 의존성 감사, CI/CD 파이프라인 내 자동화된 스캔, 허용 가능한 의존성 버전에 대한 정책, 그리고 의존성을 지속적으로 평가하고 업데이트하는 프로세스가 필요합니다.
보안 스캔은 특정 시점에만 수행되는 활동이 되어서는 안 됩니다. 취약점은 끊임없이 발견됩니다. 따라서 개발 단계, CI/CD, 운영 환경은 물론 그 사이의 모든 환경에서 스캔을 지속적으로 수행해야 합니다. 어제까지 안전했던 시스템도 오늘은 취약점이 발견될 수 있습니다.
공급업체 리스크 관리 공급업체 리스크 관리를 위해서는 적극적인 감독이 필요합니다. 사용 중인 타사 소프트웨어를 추적하고, 공급업체의 보안 권고 사항을 모니터링하며, 조달 전에 공급업체의 보안 관행을 평가하고, 공급업체 계약서에 보안 업데이트에 대한 명확한 SLA를 명시해야 합니다.
사고 대응 프로세스 의존성 취약점을 시나리오에 포함시켜야 합니다. 다음 Log4Shell 수준의 취약점이 발생할 때(분명히 또 발생할 것입니다), 영향을 받은 시스템을 얼마나 빨리 식별할 수 있습니까? 수정 작업의 우선순위는 어떻게 정합니까? 허용 가능한 위험 수준과 일정에 대한 결정은 누가 내립니까?
아키텍처 선택 취약점의 영향을 제한할 수 있습니다. 종속성이 격리된 마이크로서비스는 방대한 종속성 트리를 가진 모놀리식 애플리케이션보다 업데이트하기가 더 쉽습니다. 정기적으로 이미지를 재빌드하는 컨테이너화된 애플리케이션은 장기간 실행되는 VM보다 보안 업데이트를 더 자연스럽게 적용할 수 있습니다. 불변 인프라를 사용하면 취약점이 노출되는 기간을 단축할 수 있습니다.

귀하의 실행 계획

이 글을 읽고 계신 분들 중 자신의 환경에 아직 Log4j 취약점이 숨어 있는지 궁금하신 분들을 위해, 다음과 같이 조치하시기 바랍니다:

다양한 스캔 방식을 활용하여 모든 환경에 걸쳐 포괄적인 스캔을 수행하십시오. 주요 애플리케이션뿐만 아니라 빌드 시스템, 벤더 소프트웨어, 컨테이너화된 워크로드, 레거시 시스템까지 꼼꼼히 점검하십시오.

발견한 내용을 위험을 평가하고 대응책을 수립할 수 있을 만큼 충분히 상세하게 기록하십시오. 단순히 “Log4j 2.14.1 발견”이라고만 적는 것이 아니라, “고객용 API 서비스에서 발견되었으며, 결제 처리를 담당하고, 인터넷에 노출되어 있음”과 같이 구체적으로 기술해야 합니다.

실제 위험도를 기준으로 냉철하게 우선순위를 정하십시오. 위험한 문제는 즉시 해결하십시오. 중간 위험도의 사례에 대해서는 신중한 개선 계획을 수립하십시오. 저위험 사례도 무시해서는 안 되지만, 이들이 우선순위가 높은 업무를 방해하게 해서는 안 됩니다.

즉시 해결할 수 없는 문제에 대해서는 보완적인 통제 조치를 마련하십시오. WAF 규칙, 네트워크 분할, 런타임 모니터링 등, 실제 악용 가능성을 줄이기 위해 사용할 수 있는 모든 도구를 활용하십시오.

정말 난관에 봉착한 상황이라면, 장기적인 지원을 일시적인 해결책으로 고려해 보십시오. 하지만 그 지원이 무엇을 포함하고 무엇을 포함하지 않는지 솔직하게 밝히고, 궁극적으로 문제를 제대로 해결하기 위한 명확한 일정을 유지해야 합니다.

불편한 진실

Log4j 취약점 위험은 한 번 해결하면 끝나는 문제가 아닙니다. 이는 지속적인 관심과 정기적인 스캔, 그리고 꾸준한 대응 노력이 필요한 지속적인 보안 문제입니다.

사각지대는 사라지지 않을 것입니다. 의존성 문제 때문에 취약한 버전이 예상치 못한 곳에 계속 숨어 있을 것입니다. 레거시 시스템은 여전히 간편한 업그레이드를 거부할 것입니다. 새로운 Log4j 취약점이 여전히 발견될 수도 있습니다. 이 작업은 결코 완전히 끝나는 일이 아닙니다.

하지만 그렇다고 해서 절망하거나 무기력해질 이유는 없습니다. 오히려 이러한 위험을 예외적인 상황이 아닌 일상적인 업무로 관리할 수 있는 지속 가능한 체계를 구축해야 할 이유입니다. 의존성 보안을 주기적인 위기 상황이 아닌 지속적인 업무로 여기는 팀일수록 이러한 상황을 훨씬 더 효과적으로 처리합니다.

완벽을 추구할 필요는 없습니다. 중요한 것은 가시성을 유지하고, 위험을 현명하게 관리하며, 꾸준히 발전해 나가는 것입니다. 이것이 바로 지속 가능한 보안이 실제로 어떤 모습인지 보여주는 것입니다.

Log4Shell 사태는 이미 오래전에 끝났습니다. 하지만 Log4j 취약점 문제는 여전히 진행 중입니다. 계속해서 주의를 기울이시기 바랍니다.

지원 종료일 이후에도 오랫동안 보안을 유지할 수 있는 장기 보안 업데이트를 원하신다면, 다음을 확인해 보세요 Log4j를 위한 무제한 라이프사이클 지원를 확인해 보세요.

요약