컨테이너에서 실행해도 취약한 것은 여전히 취약하다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

암호화된 악성 코드는 여전히 악성 코드라는 말이 있습니다. 이는 저만의 주장이 아닙니다. 암호화는 그 사실을 전혀 바꾸지 못하며, 다만 네트워크를 통해 전송되는 동안 보안 및 애플리케이션 인프라가 이를 탐지하지 못하게 할 가능성이 있을 뿐입니다.

컨테이너에서 실행되는 앱과 플랫폼도 마찬가지입니다. 앱에 취약점이 있다면 운영 체제에서 실행되든, 가상 머신에서 실행되든, 오늘날처럼 컨테이너에서 실행되든 여전히 취약합니다. 데이터 센터에서 취약한 앱은 클라우드에서도 취약하며, 그 반대도 마찬가지입니다.

컨테이너는 애플리케이션을 마법처럼 보호하도록 설계된 것이 아닙니다. 네트워크 계층에서 어느 정도 기본적인 보안을 제공하지만, 네트워크가 곧 애플리케이션인 것은 아닙니다. 애플리케이션에는 코드와 인터페이스(API), 프로토콜(HTTP, TCP), 그리고 애플리케이션에 필요한 앱 스택으로 구성된 고유한 공격 표면이 있습니다. IP 테이블에 항목을 추가하거나 컨테이너 환경의 인그레스에서 들어오는 요청만 허용하도록 인바운드 요청을 제한해도 이러한 요소는 전혀 달라지지 않습니다.

제가 이 문제를 언급하는 이유는 Sonatype의 2017년 DevSecOps 설문조사 때문입니다. 이 조사에서 2,200명이 넘는 응답자 중 88%가 컨테이너 보안이 중요하다고 답했지만, 컨테이너 내의 취약한 애플리케이션/OS/구성을 식별하기 위해 보안 제품을 활용하는 비율은 53%에 불과했습니다.

이 통계의 첫 두 항목인 애플리케이션과 OS가 특히 눈에 띄었습니다. 이 둘은 완전한 앱 스택을 구성하는 요소 중에서도 위치나 운영 모델(클라우드, 컨테이너, 가상화 등)에 따라 반드시 달라지는 것은 아니기 때문입니다. SQLi 또는 XSS 취약점이 있는 앱이나 API가 모델 간에 이동한다고 해서 마법처럼 보호 기능이 생기는 것은 아닙니다. 그 취약점은 코드에 존재합니다. 앱 보안 스택의 일부임이 분명한 플랫폼도 마찬가지입니다. Linux에서 실행되는 Apache의 HTTP 헤더 처리에 취약점이 있다면, 해당 앱을 기존의 OS 기반 모델에서 컨테이너 기반 모델로 이전하더라도 그 취약점은 여전히 존재합니다.

전체 애플리케이션 스택에서 취약점을 지속적으로 식별하는 것은 중요하며, 반드시 필요한 일입니다. 애플리케이션이 어디에 어떤 형태로 배포되든 상관없이 말입니다.

컨테이너로 전환할 때 기존 애플리케이션에 이미 적용 중인 애플리케이션 보호 조치를 그대로 유지하는 것 역시 매우 중요합니다. 웹 애플리케이션 방화벽은 기존 환경이나 클라우드에 배포된 애플리케이션뿐만 아니라 컨테이너에 배포된 애플리케이션에도 똑같이 유용합니다.

설문 조사 결과 응답자들이 사용하는 것으로 나타난 정적 및 실시간 스캐닝 솔루션(SAST, DAST, IAST 및 RASP)과 같은 다른 보안 도구도 마찬가지입니다. 웹 애플리케이션 방화벽(WAF)의 사용률이 다른 도구보다 높지만, SAST와 SCA(소스 코드 분석)도 널리 사용됩니다. SCA는 배포 전에 문제를 찾아내는 정적 분석 방식입니다. 제 연식이 드러나겠지만, lint 같은 도구도 SCA 도구 범주에 속합니다. 이러한 도구는 코드 간 상호작용(및 사용자와의 상호작용)으로 인해 발생하는 취약점을 실시간으로 찾아내지는 못하지만, 메모리 누수, 충돌 또는 악명 높은 버퍼 오버플로를 초래하는 개발자의 흔한 실수 중 일부를 발견할 수 있습니다.

무슨 생각을 하시는지 알아요. 아마 이렇게 생각하시겠죠. “로리, 방금 Stack Overflow의 2017년 개발자 설문조사 결과를 읽었는데, JavaScript는 개발자들이 단연 가장 선호하는 언어잖아요. 게다가 JavaScript는 인터프리터 언어니까, 버퍼 오버플로와 메모리 누수 같은 문제는 예전에 C/C++로 코딩하던 시절의 안 좋은 기억일 뿐이죠.”

하지만 JavaScript를 비롯한 현대의 인터프리터 언어도 결국에는 C/C++처럼 회로 기판에 더 가까운 언어로 구현됩니다. 그리고 과거에 입증된 바와 같이, 충분히 영리하다면 이 사실을 이용해 시스템을 공격하는 익스플로잇을 만들어낼 수 있습니다.

설령 그것이 문제가 되지 않더라도, 어떤 코드든 사용된 라이브러리나 잘못 사용된 시스템 호출로 인해 서버 측 보안이 침해되는 등 수많은 다른 취약점이 존재합니다. 최근 조사에 따르면 앱의 80%가 오픈 소스 구성 요소로 이루어져 있습니다. Sonatype의 조사에서는 오픈 소스 구성 요소와 관련해 확인되었거나 의심되는 보안 침해가 2014년부터 2017년까지 50% 증가했다고도 밝혔습니다. 이러한 구성 요소 중 상당수는 통제가 덜하고 해당 언어에 능숙한 개발자도 점점 줄어들고 있어, 더 심각한 실수가 발생하기 쉬운 언어로 작성되어 있습니다.

요점은 어떤 코드든 취약점을 포함할 수 있다는 것입니다. 또한 코드는 오늘날 비즈니스의 얼굴이라 할 수 있는 애플리케이션의 구성 요소이므로, 어디에 어떤 방식으로 배포되든 반드시 검사하고 보호해야 합니다.

컨테이너든 클라우드든, 기존 환경이든 가상 환경이든 상관없습니다. 모든 애플리케이션은 취약점을 검사하고 플랫폼 및 프로토콜 익스플로잇으로부터 보호해야 합니다. 예외는 없습니다.

애플리케이션은 개발 과정에서 철저히 스캔하고 테스트한 후, 프로덕션 환경에서 다시 테스트해야 합니다. 두 과정 모두 필요합니다. 왜냐하면 분해의 오류에 따르면 새로운 구성 요소를 도입하면 기준선이 달라지기 때문입니다. 새로운 상호작용으로 인해 이전에는 발견되지 않았던 취약점이 드러날 수 있습니다.

앱을 보호하려면 다음 사항을 고려하세요:

• 개발 과정에서 코드 및 앱 분석 도구를 활용하세요. 가능하면 CI/CD 파이프라인에 통합하세요.
• 다른 구성 요소나 앱과의 상호 작용으로 문제가 발생할 수 있으므로 프로덕션 환경에서 다시 테스트하세요.
• 항상 주의를 기울이세요: 프로토콜 및 플랫폼의 취약점뿐만 아니라 사용 중인 타사 라이브러리에서 발견된 취약점도 확인하세요.
• 웹 애플리케이션 방화벽을 아키텍처에 통합하세요. 차단 모드로 사용하지 않더라도 프로토콜/플랫폼의 제로데이 취약점이나 라이브러리 취약점이 발견될 경우 매우 유용한 리소스가 됩니다.

안전에 유의하세요!

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물