2020.05.11

흔히 저지르는 컨테이너 보안 실수 6가지와 예방법

Bob Violino | CSO
클라우드로 데이터와 워크로드를 옮기는 조직이 늘어나면서 컨테이너에 대한 의존도도 높아지고 있다. 컨테이너는 애플리케이션을 다른 컴퓨팅 환경으로 옮기더라도 안정적으로 실행되도록 코드와 그 종속성을 패키지화한 소프트웨어 유닛이다. 미국 클렘슨대학 유전 및 생화학 학부 소속 클라우드 아키텍트인 콜 맥나이트는 컨테이너화는 애플리케이션과 서비스를 안전하게 배포하기 위한 견고한 기술로 부상했다고 말했다.
 
ⓒ Getty Images Bank

맥나이트는 도커(Docker), 싱귤러리티(Singularity)와 같은 컨테이너 엔진은 안전한 설치 책임을 개별 사용자에게 맡기는 대신 특정 애플리케이션을 위한 최선의 보안 정책을 구현하고 배포하는 수단을 제공한다면서 “쿠버네티스, 메소스, 도커 스웜과 같은 컨테이너 오케스트레이션 플랫폼은 컨테이너 배포와 실행에 특화된 보안 메커니즘을 통합했다. 그 결과, 쉽게 구성할 수 있는 컨테이너 개발 및 배포 생태계가 형성됐다”라고 말했다.

이와 같은 기술은 안전한 애플리케이션과 서비스를 제공하는 데 일반적으로 따르는 복잡성을 많은 부분 걷어내지만, 맥나이트는 개발팀이 이런 보안의 가능성을 보안을 보장하는 것으로 해석하는 경우가 있다고 지적했다. 문제는 컨테이너 구현 과정에서 실수를 할 수 있다는 것이다. 컨테이너를 사용하는 팀이 이러한 실수를 저지르면 보안 문제를 해결하는 게 아니라 오히려 유발하게 된다.
 

1. 컨테이너 자체에 지나치게 집중한다

맥나이트는 “안전한 컨테이너를 구현할 때 발생하는 가장 흔한 실수는 컨테이너 자체에 온전히 초점을 맞추는 것”이라고 말했다. 이미지의 보안을 위한 베스트 프랙티스를 유지하는 것도 중요하지만 개발자가 이미지가 실행되는 환경을 고려하지 않고 이미지의 보안에만 골몰하는 경우가 적지 않다.

맥나이트는 “컨테이너 내부의 보안이 아무리 강력해도 호스트의 컨테이너 악용으로부터 보호할 수는 없다. 컨테이너 엔진을 호스팅하는 각 시스템을 일반적으로 악용 가능한 취약점에 대비해 각 계층에서 보호해야 한다”고 강조했다.

특히 가능하다면, 컨테이너 엔진과 컨테이너 오케스트레이션 플랫폼에 통합된 컨테이너 보안 메커니즘을 적절히 사용하도록 구성해야 한다면서 “컨테이너 보안의 시작은 호스트의 운영체제와 네트워크”라고 덧붙였다.
 

2. 코드 라이브러리를 안전하다고 전제한다

컨테이너를 배포할 때 코드 라이브러리를 포함하면서 이 라이브러리가 안전하다고 전제하는 실수를 저지를 수 있다. 독립 사이버 보안 컨설턴트인 토니 애셔는 “여기에는 개발 제품군의 라이브러리도 포함된다. 특히 개발을 가속화할 목적으로 가져오는 서드파티 라이브러리에 대해 주의가 필요하다”고 말했다.

애셔는 이러한 애플리케이션 코드 라이브러리 내에 취약점이 존재할 가능성이 있다면서 “애플리케이션을 컴파일해서 프로덕션 컨테이너로 실행하면 취약점 악용을 통한 심각한 위험이 발생한다”라고 설명했다.

문제를 방지하려면 애플리케이션 컨테이너가 성공 조건을 충족하는 데 필수적인 라이브러리만 사용하고, 코드에서 취약점을 스캔하고, 서드파티 라이브러리를 가져올 때 보안 리뷰 프로세스를 적용해야 한다.

또한 조직은 공식적인 보안 아키텍처 리뷰 프로세스를 마련해야 한다. 애셔는 “이 프로세스에는 여러 사람으로 구성된 그룹이 리뷰하는, 위험 기준을 충족하는 컨테이너 리뷰가 포함되어야 한다”고 말했다. 이는 책임성을 부여해 위험을 확실히 짚고 넘어가도록 유도한다.
 

3. 컨테이너에 불필요한 권한을 부여한다

컨테이너에 과도한 권한을 부여하는 것도 흔한 실수다. 벤처 캐피털 업체 클리어스카이(ClearSky)의 파트너인 제이 리크는 공격자가 이 권한을 악용해서 컨테이너가 원래 액세스하면 안 되는 리소스에 접근할 수 있게 된다면서 “최소 권한 원칙을 적용하고 런타임 행동 모니터링을 통해 애플리케이션 권한의 오남용을 확실히 감지해야 한다”고 말했다.

맥나이트는 실행 환경 내에서 컨테이너를 높은 권한으로 실행하는 경우가 흔하다면서 “호스트의 소프트웨어 스택에 따라 이 관행은 여러가지를 의미할 수 있다. 그러나 호스트 환경 내에서 컨테이너에 불필요한 권한을 부여하면, 컨테이너뿐만 아니라 호스트 시스템까지 침해되는 결과로 이어질 수 있다”고 지적했다.

컨테이너 내부 보안이 아무리 강력해도 호스트에 의한 악용으로부터 보호할 수 없는 것과 마찬가지로, 호스트 내의 보안이 아무리 강력해도 권한이 높은 컨테이너에 의한 악용을 차단할 방도는 없다. 맥나이트는 “호스트 환경에서 컨테이너에 불필요한 권한을 제공하지 않도록 컨테이너를 설계하고 실행해야 한다”고 강조했다. 또 권한이 필요한 경우 세분화된 방식으로 절제해서 부여해야 한다면서 “최선의 방법은 호스트 환경 내의 광범위한 권한으로 컨테이너를 프로비저닝하지 않는 것”이라고 덧붙였다.
 

4. 컨테이너를 과도하게 노출한다

실행 시 공개 네트워크에 노출해야 하는 컨테이너 역시 같은 관점에서 설계해야 한다. 맥나이트는 “컨테이너를 잠재적 공격에 노출하는 광범위한 정책을 실행하면 안 되고, 절대적으로 필요한 채널만 열어야 한다”고 말했다.

컨테이너 자체를 구현할 때는 수많은 사항을 고려해야 한다. 맥나이트는 “컨테이너는 일련의 명령을 통해 만들어지는데, 이미지 사양에 정의된 이 명령은 이미지가 빌드될 때 루트 권한으로 실행된다. 개발자는 컨테이너가 배포되고 실행될 때 이와 같은 권한을 그대로 두는 실수를 흔히 저지른다”고 지적했다.



2020.05.11

흔히 저지르는 컨테이너 보안 실수 6가지와 예방법

Bob Violino | CSO
클라우드로 데이터와 워크로드를 옮기는 조직이 늘어나면서 컨테이너에 대한 의존도도 높아지고 있다. 컨테이너는 애플리케이션을 다른 컴퓨팅 환경으로 옮기더라도 안정적으로 실행되도록 코드와 그 종속성을 패키지화한 소프트웨어 유닛이다. 미국 클렘슨대학 유전 및 생화학 학부 소속 클라우드 아키텍트인 콜 맥나이트는 컨테이너화는 애플리케이션과 서비스를 안전하게 배포하기 위한 견고한 기술로 부상했다고 말했다.
 
ⓒ Getty Images Bank

맥나이트는 도커(Docker), 싱귤러리티(Singularity)와 같은 컨테이너 엔진은 안전한 설치 책임을 개별 사용자에게 맡기는 대신 특정 애플리케이션을 위한 최선의 보안 정책을 구현하고 배포하는 수단을 제공한다면서 “쿠버네티스, 메소스, 도커 스웜과 같은 컨테이너 오케스트레이션 플랫폼은 컨테이너 배포와 실행에 특화된 보안 메커니즘을 통합했다. 그 결과, 쉽게 구성할 수 있는 컨테이너 개발 및 배포 생태계가 형성됐다”라고 말했다.

이와 같은 기술은 안전한 애플리케이션과 서비스를 제공하는 데 일반적으로 따르는 복잡성을 많은 부분 걷어내지만, 맥나이트는 개발팀이 이런 보안의 가능성을 보안을 보장하는 것으로 해석하는 경우가 있다고 지적했다. 문제는 컨테이너 구현 과정에서 실수를 할 수 있다는 것이다. 컨테이너를 사용하는 팀이 이러한 실수를 저지르면 보안 문제를 해결하는 게 아니라 오히려 유발하게 된다.
 

1. 컨테이너 자체에 지나치게 집중한다

맥나이트는 “안전한 컨테이너를 구현할 때 발생하는 가장 흔한 실수는 컨테이너 자체에 온전히 초점을 맞추는 것”이라고 말했다. 이미지의 보안을 위한 베스트 프랙티스를 유지하는 것도 중요하지만 개발자가 이미지가 실행되는 환경을 고려하지 않고 이미지의 보안에만 골몰하는 경우가 적지 않다.

맥나이트는 “컨테이너 내부의 보안이 아무리 강력해도 호스트의 컨테이너 악용으로부터 보호할 수는 없다. 컨테이너 엔진을 호스팅하는 각 시스템을 일반적으로 악용 가능한 취약점에 대비해 각 계층에서 보호해야 한다”고 강조했다.

특히 가능하다면, 컨테이너 엔진과 컨테이너 오케스트레이션 플랫폼에 통합된 컨테이너 보안 메커니즘을 적절히 사용하도록 구성해야 한다면서 “컨테이너 보안의 시작은 호스트의 운영체제와 네트워크”라고 덧붙였다.
 

2. 코드 라이브러리를 안전하다고 전제한다

컨테이너를 배포할 때 코드 라이브러리를 포함하면서 이 라이브러리가 안전하다고 전제하는 실수를 저지를 수 있다. 독립 사이버 보안 컨설턴트인 토니 애셔는 “여기에는 개발 제품군의 라이브러리도 포함된다. 특히 개발을 가속화할 목적으로 가져오는 서드파티 라이브러리에 대해 주의가 필요하다”고 말했다.

애셔는 이러한 애플리케이션 코드 라이브러리 내에 취약점이 존재할 가능성이 있다면서 “애플리케이션을 컴파일해서 프로덕션 컨테이너로 실행하면 취약점 악용을 통한 심각한 위험이 발생한다”라고 설명했다.

문제를 방지하려면 애플리케이션 컨테이너가 성공 조건을 충족하는 데 필수적인 라이브러리만 사용하고, 코드에서 취약점을 스캔하고, 서드파티 라이브러리를 가져올 때 보안 리뷰 프로세스를 적용해야 한다.

또한 조직은 공식적인 보안 아키텍처 리뷰 프로세스를 마련해야 한다. 애셔는 “이 프로세스에는 여러 사람으로 구성된 그룹이 리뷰하는, 위험 기준을 충족하는 컨테이너 리뷰가 포함되어야 한다”고 말했다. 이는 책임성을 부여해 위험을 확실히 짚고 넘어가도록 유도한다.
 

3. 컨테이너에 불필요한 권한을 부여한다

컨테이너에 과도한 권한을 부여하는 것도 흔한 실수다. 벤처 캐피털 업체 클리어스카이(ClearSky)의 파트너인 제이 리크는 공격자가 이 권한을 악용해서 컨테이너가 원래 액세스하면 안 되는 리소스에 접근할 수 있게 된다면서 “최소 권한 원칙을 적용하고 런타임 행동 모니터링을 통해 애플리케이션 권한의 오남용을 확실히 감지해야 한다”고 말했다.

맥나이트는 실행 환경 내에서 컨테이너를 높은 권한으로 실행하는 경우가 흔하다면서 “호스트의 소프트웨어 스택에 따라 이 관행은 여러가지를 의미할 수 있다. 그러나 호스트 환경 내에서 컨테이너에 불필요한 권한을 부여하면, 컨테이너뿐만 아니라 호스트 시스템까지 침해되는 결과로 이어질 수 있다”고 지적했다.

컨테이너 내부 보안이 아무리 강력해도 호스트에 의한 악용으로부터 보호할 수 없는 것과 마찬가지로, 호스트 내의 보안이 아무리 강력해도 권한이 높은 컨테이너에 의한 악용을 차단할 방도는 없다. 맥나이트는 “호스트 환경에서 컨테이너에 불필요한 권한을 제공하지 않도록 컨테이너를 설계하고 실행해야 한다”고 강조했다. 또 권한이 필요한 경우 세분화된 방식으로 절제해서 부여해야 한다면서 “최선의 방법은 호스트 환경 내의 광범위한 권한으로 컨테이너를 프로비저닝하지 않는 것”이라고 덧붙였다.
 

4. 컨테이너를 과도하게 노출한다

실행 시 공개 네트워크에 노출해야 하는 컨테이너 역시 같은 관점에서 설계해야 한다. 맥나이트는 “컨테이너를 잠재적 공격에 노출하는 광범위한 정책을 실행하면 안 되고, 절대적으로 필요한 채널만 열어야 한다”고 말했다.

컨테이너 자체를 구현할 때는 수많은 사항을 고려해야 한다. 맥나이트는 “컨테이너는 일련의 명령을 통해 만들어지는데, 이미지 사양에 정의된 이 명령은 이미지가 빌드될 때 루트 권한으로 실행된다. 개발자는 컨테이너가 배포되고 실행될 때 이와 같은 권한을 그대로 두는 실수를 흔히 저지른다”고 지적했다.



X