2021.11.04

블로그 | '시스템 속 보안 취약점' 컨테이너가 악몽이 되는 순간

David Linthicum | InfoWorld
컨테이너, 특히 퍼블릭 클라우드에서 운영하는 컨테이너는 이제 오래전부터 보편화했다. 이들 셀프 컨테이너 방식의 가벼운 소프트웨어 패키지는 자체 런타임 환경을 포함하고 있어 여러 플랫폼을 옮겨 다니며 이식할 수 있다. 일반적으로는 이 과정에서 코드를 크게 수정할 필요도 없다. 실제로 컨테이너에는 애플리케이션은 물론 그 애플리케이션을 독립적으로 실행하는 데 필요한 라이브러리와 오래된 바이너리, 설정 파일 등이 모두 포함돼 있다.
 
ⓒ Getty Images Bank

컨테이너는 가장 널리 사용하는 애플리케이션 개발 방법론의 하나다. 컨테이너 내에 이미 존재하는 애플리케이션의 래핑도 지원한다. 문제는 컨테이너에 내재한 결점과 보안 취약점이다. 이는 곧 클라우드 보안 전문가에게 가장 두려운 것이고, 동시에 사이버 범죄자가 선호하는 공격 경로이기도 하다.

컨테이너 보안 취약점 문제의 핵심은 클라우드로 컨테이너를 공개하는 순간 컨테이너와 연결된 다른 시스템과 애플리케이션, 데이터 등이 함께 노출될 수 있다는 사실이다. 이들 컴포넌트를 식별할 수 있다는 것은 공격자에게 시스템 제어권은 물론 이 시스템이 다루는 민감한 데이터에 대한 통제권이 넘어갈 수 있다는 의미이기도 하다.

그렇다면 컨테이너 보안 취약점을 감지하는 가장 좋은 방법은 무엇일까. 더 근본적으로, 컨테이너를 꼭 사용해야 하는 이들이 보안 취약점 문제의 위험을 최소화하기 위해 무엇을 해야 할까.

이 물음에 대한 대답은 크게 2가지다. 보안 취약점을 스캔하고, 취약점을 피하는 개발방식을 활용해야 한다는 것이다.

먼저 스캐닝부터 살펴보자. 스캐닝은 가장 일반적인 보안 취약점 검출 방법이다. 지속적 통합/지속적 배포(CI/CD) 파이프라인에 포함된 과정이기도 하다. 스캐닝을 통해 코드를 만들어 테스트하고 리뷰하고 배치하는 것은 물론 운영할 때도 보안 문제를 찾을 수 있다. 자동화된 스캐닝 과정을 이용해 보안 취약점을 식별할 수 있고, 때에 따라서는 개발자 개입 없이 자동으로 수정까지 할 수 있다.

레지스트리 스캐닝 또는 여러 리포지토리 전체를 컬링하면 한 번에 많은 컨테이너 이미지를 확인할 수 있다. 클라우드이든 아니든 상관없이 레지스트리에서 프로덕션 시스템으로 배포할 때 이런 과정을 통해 실행 중인 컨테이너를 점검할 수 있다. 런타임 환경 스캐닝은 일반적인 스캐닝과 조금 다르다. 보안 측면에서 실행 중인 컨테이너를 스캐닝하는 모든 과정을 가리킨다.

이중 가장 좋은 것은 가능한 한 다양한 방식의 보안 취약점 스캐닝을 모두 활용하는 것이다. 이를 통해 컨테이너 기반 애플리케이션을 만들고 배포하는 위험을 완벽하지는 않다고 해도 상당히 줄일 수 있다.

두 번째는 보안 취약점을 피하는 개발 방식이다. 이는 종종 상식의 문제다. 예를 들면 신뢰할 수 없는 소스에서 구한 베이스 이미지를 사용하는 것 같은 어리석은 짓을 하지 않는 것이다. 보안 감사를 통과한 툴만 쓰는 것도 좋다. 확인된 레거시 코드만 사용하고, 개발자가 보안 컨테이너를 만들 때 올바른 선택을 할 수 있도록 특별한 교육을 제공하는 것도 필요하다.

결국, 컨테이너의 보안 취약점 문제를 해결하는 유일한 방법은 적절한 스캐닝 툴을 선택하고, 개발, 테스트, 스테이징, 배포할 때마다 지나칠 정도로 스캐닝하는 것이다. 이렇게 단계마다 보안을 확인한다고 전체 일정이 실제로 지연되는 것은 아니다. 위험을 줄어드는 순기능만 있을 뿐이다.

컨테이너 보안 취약점에 대한 우려는 허황한 이야기가 아니다. 많은 개발자가 이미 널리 사용하고 또 입증된 툴을 사용하는 것도 이 때문이다. 물론 동시에 여전히 많은 컨테이너 개발자가 가장 기본적인 보안 툴과 접근법을 외면하고 있다. 그러나 클라우드로 전환하는 IT팀 대부분이 컨테이너에 절대적으로 의존하고 있음을 고려하면 이제는 이런 위험한 상황을 바로잡을 때가 됐다. editor@itworld.co.kr



2021.11.04

블로그 | '시스템 속 보안 취약점' 컨테이너가 악몽이 되는 순간

David Linthicum | InfoWorld
컨테이너, 특히 퍼블릭 클라우드에서 운영하는 컨테이너는 이제 오래전부터 보편화했다. 이들 셀프 컨테이너 방식의 가벼운 소프트웨어 패키지는 자체 런타임 환경을 포함하고 있어 여러 플랫폼을 옮겨 다니며 이식할 수 있다. 일반적으로는 이 과정에서 코드를 크게 수정할 필요도 없다. 실제로 컨테이너에는 애플리케이션은 물론 그 애플리케이션을 독립적으로 실행하는 데 필요한 라이브러리와 오래된 바이너리, 설정 파일 등이 모두 포함돼 있다.
 
ⓒ Getty Images Bank

컨테이너는 가장 널리 사용하는 애플리케이션 개발 방법론의 하나다. 컨테이너 내에 이미 존재하는 애플리케이션의 래핑도 지원한다. 문제는 컨테이너에 내재한 결점과 보안 취약점이다. 이는 곧 클라우드 보안 전문가에게 가장 두려운 것이고, 동시에 사이버 범죄자가 선호하는 공격 경로이기도 하다.

컨테이너 보안 취약점 문제의 핵심은 클라우드로 컨테이너를 공개하는 순간 컨테이너와 연결된 다른 시스템과 애플리케이션, 데이터 등이 함께 노출될 수 있다는 사실이다. 이들 컴포넌트를 식별할 수 있다는 것은 공격자에게 시스템 제어권은 물론 이 시스템이 다루는 민감한 데이터에 대한 통제권이 넘어갈 수 있다는 의미이기도 하다.

그렇다면 컨테이너 보안 취약점을 감지하는 가장 좋은 방법은 무엇일까. 더 근본적으로, 컨테이너를 꼭 사용해야 하는 이들이 보안 취약점 문제의 위험을 최소화하기 위해 무엇을 해야 할까.

이 물음에 대한 대답은 크게 2가지다. 보안 취약점을 스캔하고, 취약점을 피하는 개발방식을 활용해야 한다는 것이다.

먼저 스캐닝부터 살펴보자. 스캐닝은 가장 일반적인 보안 취약점 검출 방법이다. 지속적 통합/지속적 배포(CI/CD) 파이프라인에 포함된 과정이기도 하다. 스캐닝을 통해 코드를 만들어 테스트하고 리뷰하고 배치하는 것은 물론 운영할 때도 보안 문제를 찾을 수 있다. 자동화된 스캐닝 과정을 이용해 보안 취약점을 식별할 수 있고, 때에 따라서는 개발자 개입 없이 자동으로 수정까지 할 수 있다.

레지스트리 스캐닝 또는 여러 리포지토리 전체를 컬링하면 한 번에 많은 컨테이너 이미지를 확인할 수 있다. 클라우드이든 아니든 상관없이 레지스트리에서 프로덕션 시스템으로 배포할 때 이런 과정을 통해 실행 중인 컨테이너를 점검할 수 있다. 런타임 환경 스캐닝은 일반적인 스캐닝과 조금 다르다. 보안 측면에서 실행 중인 컨테이너를 스캐닝하는 모든 과정을 가리킨다.

이중 가장 좋은 것은 가능한 한 다양한 방식의 보안 취약점 스캐닝을 모두 활용하는 것이다. 이를 통해 컨테이너 기반 애플리케이션을 만들고 배포하는 위험을 완벽하지는 않다고 해도 상당히 줄일 수 있다.

두 번째는 보안 취약점을 피하는 개발 방식이다. 이는 종종 상식의 문제다. 예를 들면 신뢰할 수 없는 소스에서 구한 베이스 이미지를 사용하는 것 같은 어리석은 짓을 하지 않는 것이다. 보안 감사를 통과한 툴만 쓰는 것도 좋다. 확인된 레거시 코드만 사용하고, 개발자가 보안 컨테이너를 만들 때 올바른 선택을 할 수 있도록 특별한 교육을 제공하는 것도 필요하다.

결국, 컨테이너의 보안 취약점 문제를 해결하는 유일한 방법은 적절한 스캐닝 툴을 선택하고, 개발, 테스트, 스테이징, 배포할 때마다 지나칠 정도로 스캐닝하는 것이다. 이렇게 단계마다 보안을 확인한다고 전체 일정이 실제로 지연되는 것은 아니다. 위험을 줄어드는 순기능만 있을 뿐이다.

컨테이너 보안 취약점에 대한 우려는 허황한 이야기가 아니다. 많은 개발자가 이미 널리 사용하고 또 입증된 툴을 사용하는 것도 이 때문이다. 물론 동시에 여전히 많은 컨테이너 개발자가 가장 기본적인 보안 툴과 접근법을 외면하고 있다. 그러나 클라우드로 전환하는 IT팀 대부분이 컨테이너에 절대적으로 의존하고 있음을 고려하면 이제는 이런 위험한 상황을 바로잡을 때가 됐다. editor@itworld.co.kr

X