컨테이너에서 실행되는 취약한 것 여전히 취약한 것

암호화된 악성 코드는 여전히 악성 코드라고 말하는 사람이 있습니다. 나 혼자만 그런 것은 아닙니다. 암호화는 네트워크를 통한 전송에 대한 보안 및 앱 인프라를 제외하고는 이를 변경할 수 있는 아무것도 없습니다.

컨테이너에서 실행되는 앱과 플랫폼에도 마찬가지입니다. 앱이 취약하다면 OS에서 실행되든, 가상 머신에서 실행되든, 요즘은 컨테이너에서 실행되든 취약합니다. 데이터 센터에서 앱이 취약하다면 클라우드에서도 취약합니다. 그리고 그 반대도 마찬가지.

컨테이너는 마법처럼 애플리케이션을 보호하도록 설계된 것이 아닙니다. 이들은 네트워크 계층에서 기본적인 보안을 제공하지만, 네트워크 자체는 애플리케이션이 아닙니다. 애플리케이션에는 코드와 인터페이스(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는 해석되므로 이 모든 버퍼 오버플로우와 메모리 누수 문제는 C/C++로 코딩하던 옛날의 나쁜 기억일 뿐입니다."

단, JavaScript와 기타 최신 해석 언어는 궁극적으로 C/C++와 같이 회로 기판에 더 가까운 언어로 구현됩니다. 그리고 과거에도 보여졌 듯이, 만약 누군가가 충분히 똑똑하다면, 그는 그 사실을 이용해 시스템을 악용할 수 있습니다.

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

요점은 모든 코드에 취약점이 포함될 가능성이 있다는 것입니다. 그리고 코드는 오늘날 비즈니스의 얼굴인 앱의 구성 요소이므로 어디에 어떻게 배포하든 앱을 스캔하고 보호하는 것이 중요합니다.

컨테이너 또는 클라우드. 전통적인 것과 가상적인 것. 모든 애플리케이션은 취약점을 검사하여 플랫폼 및 프로토콜 악용으로부터 보호해야 합니다. 기간.

앱은 개발 중에 철저히 검사하고 테스트한 후, 프로덕션 단계에서 다시 테스트해야 합니다. 둘 다 필요한데, 분해의 오류 에 따르면 새로운 구성 요소를 도입하면 기준선이 바뀌기 때문입니다. 새로운 상호작용으로 인해 이전에 발견되지 않았던 취약점이 표면화될 수 있습니다.

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

• 개발에 코드와 앱 분석 도구를 활용하세요. 가능하다면 CI/CD 파이프라인에 빌드하세요.
• 다른 구성 요소/앱과의 상호작용에서 문제가 발생하는 경우 프로덕션에서 다시 테스트합니다.
• 사용할 수 있는 타사 라이브러리에서 발견된 프로토콜 및 플랫폼 취약점 과 취약점을 항상 인지하십시오.
• 아키텍처에 웹 앱 방화벽을 통합하세요. 차단 모드로 사용하지 않더라도 프로토콜/플랫폼 제로데이 또는 라이브러리 취약점이 발견되는 경우 매우 귀중한 리소스입니다.

안전히 계세요!