애플리케이션의 추상화로 ‘작은 용량 패키징’ 가능케 해주는 콘테이너
유지 보수와 관리 등 쉽게 되지만, 보안은 오히려 조금 더 어렵게
[보안뉴스 문가용 기자] 콘테이너는 애플리케이션의 추상화를 가능하게 해준다. 그렇기 때문에 개발자들은 콘테이너를 사용해 애플리케이션을 보다 작게 패키징 할 수 있게 된다. 작은 패키지이기 때문에 구축도 쉽고 다른 서버로 옮기는 것도 간단해진다. 당연히 유지, 보수, 업데이트 역시 그렇다.
그러나 아쉽게도 콘테이너화 된 애플리케이션의 보안만큼은 그렇게 간단해지지는 않는다. 또한 기존 애플리케이션 환경을 보호하는 것과도 개념이 다르다. 그 이유는 보안 취약점을 스캐닝하는 것이 조금 더 어렵고, 콘테이너 이미지들을 점검하거나 확인하는 절차가 없는 것과 마찬가지이기 때문이다. 콘테이너 기술 사용의 표준도 아직 마련되어 있지 않다. 무엇보다 콘테이너의 수명 주기가 짧다는 게 가장 큰 차이다.
리눅스 배포판을 제작하는 레드햇(Red Hat)의 수석 보안 담당자인 커스텐 뉴커머(Kirsten Newcomer)는 “콘테이너 기술 자체가 아직은 새롭고 낯설게 느껴지는 면이 있는데, 그 기본 개념 자체는 크게 어렵지 않다”라고 말한다. “또한 콘테이너는 리눅스의 보안 기능을 상당 부분 답습하고 있습니다. 그래서 리눅스에 익숙하다면 콘테이너가 그렇게까지 힘든 문제는 아닐 겁니다. 다만 몇 가지 콘테이너만의 독특한 유의 사항이 있긴 합니다.”
그러면서 뉴커머는 “콘테이너를 구축하기 전과 구축 후 생애주기 전체를 통해 보안을 고민해야 하는데, 중요한 건 ‘애플리케이션 스택’의 관점에서 보안을 다져야 한다는 겁니다. 이 말이 좀 어려울 수 있는데, 콘테이너를 사용하고자 하는 회사나 기관이라면 다음 몇 가지 체크리스트를 통해 보안을 점검하는 게 도움이 될 겁니다.”
1. 비밀 관리
비밀이라 함은 비밀번호, API 키, 토큰 등을 말한다. 이런 정보들에 대한 안전한 관리 체계는 어느 조직이라도 이미 갖추고 있다. 콘테이너 환경에서도 이러한 비밀 정보에 대한 관리 체계가 필요하다.
뉴커머는 “콘테이너화 된 애플리케이션들은 대부분 민감한 정보에 접근할 수 있어야 한다”며 “여기에는 사용자 이름과 비밀번호 등이 포함된다”고 말한다. “그러니 비밀 데이터를 자동으로 암호화 하고, 콘테이너가 구축되고 작동을 시작했을 때 비밀 정보를 자동으로 회수하거나 주입시키도록 해주는 플랫폼이 필요합니다. 또한 한 콘테이너의 앱이 다른 콘테이너의 비밀에 접근할 수 없도록 설정해주는 것도 중요하고요. 이런 식의 비밀 관리에 대해 생각하는 것이 첫 번째 일입니다.”
2. 이미지 출처
그 다음은 이미지다. 기본 바탕이 되는 이미지를 믿을 수 있어야, 그 위에다가 콘테이너 애플리케이션들을 쌓아 올릴 수 있다. 그렇다는 건 이미지의 출처를 분명히 알고 있어야 한다는 뜻이다. 어떤 코드로 만들어졌는지, 언제, 어떤 방식으로 누가 최초로 제작했는지도 알아야 하며, 어떤 소프트웨어와 연결되어 있는지도 파악해야 한다. 물론 관련된 보안 사항도 이해하고 있어야 한다.
“콘테이너 이미지는 생산이 되고 있는 애플리케이션들의 가장 기본이 되는 것”이라고 레드햇의 수석 콘테이너 연구원인 조 브록마이어(Joe Brockmeier)는 설명한다. “콘테이너를 사용하고자 하는 조직들이 가장 먼저 해야 하고, 가장 중요하게 생각해야 할 건 바로 이미지들이 신뢰를 받도록 하는 겁니다. 사용하고 있는 이미지를 확실하고 꼼꼼하게 점검해서, 이미지 단계에서는 어떤 문제도 발생하지 않도록 하는 게 나중을 위해서도 필수입니다.”
이미지의 코드에 관한 보안 문제들도 점검해야 한다. 과거에 문제가 발견된 적은 없었는지, 혹은 잠재적으로 문제가 생길 소지는 없는지를 다 확인해야 하는 것이다. “콘테이너 이미지는 생각보다 쉽게 다운로드가 가능합니다. 구하기가 크게 어렵지 않아요. 그래서 출처 확인을 반드시 해야 합니다.” 보안 업체 퀄리스(Qualys)의 수석 제품 관리자인 하리 스리니바산(Hari Srinivasan)의 설명이다. “내가 다운로드 받고 있는 이미지가 제대로 된 것인지, 중간에 무결성이 훼손되는 일이 없었는지도 모두 확인할 수 있어야 합니다.”
3. 콘테이너 워크플로우에 대한 가시성
콘테이너와 콘테이너 오케스트레이션 툴 때문에 애플리케이션 간 통신의 흐름을 추적하는 게 더 힘들어질 수 있다. 이 때문에 콘테이너만 아니었으면 일어나지 않았을 보안 사고가 발생할 가능성이 생기며, 애플리케이션을 위험에 노출시키는 결과가 만들어질 수도 있다.
“그래서 중요한 게 가시성”이라고 보안 업체 가디코어(GuardiCore)의 엔지니어링 디렉터인 데이브 클라인(Dave Klein)은 말한다. “콘테이너 내부는 물론 콘테이너 사이에서 발생하는 프로세스들에 대한 가시성을 제공하는 툴셋이 필요합니다. 가시성은 콘테이너화 된 애플리케이션들 사이에서 무슨 일이 일어나는지 이해하는 데 있어 필수적인 요소입니다.”
특히 콘테이너 오케스트레이션의 가시성이 중요하다는 게 클라인의 설명이다. “도커(Docker)나 큐버네티스(Kuberbetes), 혹은 오픈쉬프트(OpenShift)와 같은 툴셋 혹은 플랫폼을 말하는 겁니다. 이렇게 콘테이너를 통합하게 해주는 도구나 플랫폼의 가시성이 있어야 프로세스 간 상호 의존도를 매핑할 수 있게 되고, 정책도 만들 수 있게 되며, 정책을 고르게 적용시킬 수도 있게 되는 겁니다.”
4. 표준화된 설정과 구축
콘테이너의 환경설정 오류와 보안 구멍들이 뒤섞이게 되면 IT 환경 전체가 높은 위험에 노출되는 것은 물론, 민감한 데이터를 손실할 가능성도 높아진다. “그래서 중요한 게 표준화 작업입니다. 환경설정은 물론 구축 과정에 대한 표준화를 수립함으로써 일원화된 관리 체제를 만들어야 합니다.” 스리니바산의 설명이다.
“그래서 제가 권장하는 건 도커 호스트(Docker Host) 구축 시 인터넷보안센터(CIS) 표준이 지켜지도록 ‘컴플라이언스 코딩(compliance-as-code)’ 체제를 도입하는 겁니다.” 또한 데브옵스 팀과 개발자 사이를 연결시켜주는 안전한 API를 유통시키는 것 역시 중요하다고 스리니바산은 강조한다.
“한 가지 더 있습니다. 콘테이너를 안전하게 보호하고자 한다면 특정 콘테이너 환경에서의 메타데이터와 로그를 모으는 것이 중요합니다. 큐버네티스와 같은 새로운 오케스트레이션 환경에 대한 이해도를 높이는 것 역시 필요한 일입니다. 알면 알수록 더 안전하게 보호할 수 있습니다.”
5. 추적과 모니터링
콘테이너 환경을 안전하게 보호하려면 기업 내에서 콘테이너가 어떻게 사용되고 있는지 추적하고 찾아낼 수 있어야 한다. 잠재적으로 문제가 될 수 있을만한 부분을 찾아내는 것 역시 보안 담당자들의 통제 하에 있어야 한다. 예를 들어 자원이 병목 현상을 일으키는 부분이나 취약점이 발견되는 곳을 알아내고 조치를 취할 수 있어야 한다는 것이다.
스리니바산은 “콘테이너 자체에 있는 침입 탐지 및 방해 기능을 활용하는 것은 물론, 취약점 관리 및 컴플라이언스 확인에 관한 효율적인 체계를 마련하는 게 필요하다”고 말한다.
6. 콘테이너만을 위한 호스트 OS
콘테이너 환경에 대한 공격 가능성을 줄이고 싶다면, 일반 OS를 사용하지 말라고 NIST는 권장하고 있다. 콘테이너만을 위한 OS를 사용하는 게 낫다는 건데, 그 이유는 “불필요한 기능은 전부 제거해 공격 표면 자체가 작고, 콘테이너 내에서만 작동하도록 설계되었기 때문”이다. 공격자들 입장에서 찔러볼 만한 구석이 최소화 되어 있는 것이 콘테이너 전용 OS들이다.
7. 콘테이너의 위험 우선순위 매기기
콘테이너 환경에 있을 수 있는 다양한 위험 요소들의 순위를 매기는 것도 중요하다. 보안 업체 스택록스(StackRox)의 CEO 알리 골샨(Ali Golshan)은 “취약점 스캔에서 얻어낸 데이터, 비밀 관리, 오케스트레이션 환경설정, 서비스 환경설정, 사용자 권한 관리, 레지스트리 메타데이터를 통해 위협에 대한 많은 정보를 얻어낼 수 있다”고 설명한다.
“이런 데이터를 활용해 콘테이너 환경에서 가장 위험한 부분을 정확히 하나 짚어내세요. 그러면 개발자들이 이 부분에 집중해 문제를 해결하거나 그 부분을 유의해가면서 콘테이너 애플리케이션을 만들 겁니다. 이런 일을 반복하세요.” 골샨의 설명이다.
8. 그룹 콘테이너
다양한 위험 요소를 가진 여러 애플리케이션들을 한 개의 호스트 OS 커널에서 돌리면, 사실 그 위험의 총합적인 수위가 모든 애플리케이션에 적용된다. 그러므로 같은 목적과 중요도, 위험 수위를 가진 콘테이너들끼리 묶어서 그룹화하는 것이 좋다고 NIST는 설명한다. 즉 콘테이너를 세그멘테이션 하라는 것인데, 이 작업을 통해 ‘심층 방어’를 할 수 있다고 한다. “이렇게 되면 하나의 콘테이너를 침해하더라도, 다른 콘테이너를 보호할 수 있죠.”
[국제부 문가용 기자(globoan@boannews.com)]
유지 보수와 관리 등 쉽게 되지만, 보안은 오히려 조금 더 어렵게
[보안뉴스 문가용 기자] 콘테이너는 애플리케이션의 추상화를 가능하게 해준다. 그렇기 때문에 개발자들은 콘테이너를 사용해 애플리케이션을 보다 작게 패키징 할 수 있게 된다. 작은 패키지이기 때문에 구축도 쉽고 다른 서버로 옮기는 것도 간단해진다. 당연히 유지, 보수, 업데이트 역시 그렇다.
[이미지 = iclickart]
그러나 아쉽게도 콘테이너화 된 애플리케이션의 보안만큼은 그렇게 간단해지지는 않는다. 또한 기존 애플리케이션 환경을 보호하는 것과도 개념이 다르다. 그 이유는 보안 취약점을 스캐닝하는 것이 조금 더 어렵고, 콘테이너 이미지들을 점검하거나 확인하는 절차가 없는 것과 마찬가지이기 때문이다. 콘테이너 기술 사용의 표준도 아직 마련되어 있지 않다. 무엇보다 콘테이너의 수명 주기가 짧다는 게 가장 큰 차이다.
리눅스 배포판을 제작하는 레드햇(Red Hat)의 수석 보안 담당자인 커스텐 뉴커머(Kirsten Newcomer)는 “콘테이너 기술 자체가 아직은 새롭고 낯설게 느껴지는 면이 있는데, 그 기본 개념 자체는 크게 어렵지 않다”라고 말한다. “또한 콘테이너는 리눅스의 보안 기능을 상당 부분 답습하고 있습니다. 그래서 리눅스에 익숙하다면 콘테이너가 그렇게까지 힘든 문제는 아닐 겁니다. 다만 몇 가지 콘테이너만의 독특한 유의 사항이 있긴 합니다.”
그러면서 뉴커머는 “콘테이너를 구축하기 전과 구축 후 생애주기 전체를 통해 보안을 고민해야 하는데, 중요한 건 ‘애플리케이션 스택’의 관점에서 보안을 다져야 한다는 겁니다. 이 말이 좀 어려울 수 있는데, 콘테이너를 사용하고자 하는 회사나 기관이라면 다음 몇 가지 체크리스트를 통해 보안을 점검하는 게 도움이 될 겁니다.”
1. 비밀 관리
비밀이라 함은 비밀번호, API 키, 토큰 등을 말한다. 이런 정보들에 대한 안전한 관리 체계는 어느 조직이라도 이미 갖추고 있다. 콘테이너 환경에서도 이러한 비밀 정보에 대한 관리 체계가 필요하다.
뉴커머는 “콘테이너화 된 애플리케이션들은 대부분 민감한 정보에 접근할 수 있어야 한다”며 “여기에는 사용자 이름과 비밀번호 등이 포함된다”고 말한다. “그러니 비밀 데이터를 자동으로 암호화 하고, 콘테이너가 구축되고 작동을 시작했을 때 비밀 정보를 자동으로 회수하거나 주입시키도록 해주는 플랫폼이 필요합니다. 또한 한 콘테이너의 앱이 다른 콘테이너의 비밀에 접근할 수 없도록 설정해주는 것도 중요하고요. 이런 식의 비밀 관리에 대해 생각하는 것이 첫 번째 일입니다.”
2. 이미지 출처
그 다음은 이미지다. 기본 바탕이 되는 이미지를 믿을 수 있어야, 그 위에다가 콘테이너 애플리케이션들을 쌓아 올릴 수 있다. 그렇다는 건 이미지의 출처를 분명히 알고 있어야 한다는 뜻이다. 어떤 코드로 만들어졌는지, 언제, 어떤 방식으로 누가 최초로 제작했는지도 알아야 하며, 어떤 소프트웨어와 연결되어 있는지도 파악해야 한다. 물론 관련된 보안 사항도 이해하고 있어야 한다.
“콘테이너 이미지는 생산이 되고 있는 애플리케이션들의 가장 기본이 되는 것”이라고 레드햇의 수석 콘테이너 연구원인 조 브록마이어(Joe Brockmeier)는 설명한다. “콘테이너를 사용하고자 하는 조직들이 가장 먼저 해야 하고, 가장 중요하게 생각해야 할 건 바로 이미지들이 신뢰를 받도록 하는 겁니다. 사용하고 있는 이미지를 확실하고 꼼꼼하게 점검해서, 이미지 단계에서는 어떤 문제도 발생하지 않도록 하는 게 나중을 위해서도 필수입니다.”
이미지의 코드에 관한 보안 문제들도 점검해야 한다. 과거에 문제가 발견된 적은 없었는지, 혹은 잠재적으로 문제가 생길 소지는 없는지를 다 확인해야 하는 것이다. “콘테이너 이미지는 생각보다 쉽게 다운로드가 가능합니다. 구하기가 크게 어렵지 않아요. 그래서 출처 확인을 반드시 해야 합니다.” 보안 업체 퀄리스(Qualys)의 수석 제품 관리자인 하리 스리니바산(Hari Srinivasan)의 설명이다. “내가 다운로드 받고 있는 이미지가 제대로 된 것인지, 중간에 무결성이 훼손되는 일이 없었는지도 모두 확인할 수 있어야 합니다.”
3. 콘테이너 워크플로우에 대한 가시성
콘테이너와 콘테이너 오케스트레이션 툴 때문에 애플리케이션 간 통신의 흐름을 추적하는 게 더 힘들어질 수 있다. 이 때문에 콘테이너만 아니었으면 일어나지 않았을 보안 사고가 발생할 가능성이 생기며, 애플리케이션을 위험에 노출시키는 결과가 만들어질 수도 있다.
“그래서 중요한 게 가시성”이라고 보안 업체 가디코어(GuardiCore)의 엔지니어링 디렉터인 데이브 클라인(Dave Klein)은 말한다. “콘테이너 내부는 물론 콘테이너 사이에서 발생하는 프로세스들에 대한 가시성을 제공하는 툴셋이 필요합니다. 가시성은 콘테이너화 된 애플리케이션들 사이에서 무슨 일이 일어나는지 이해하는 데 있어 필수적인 요소입니다.”
특히 콘테이너 오케스트레이션의 가시성이 중요하다는 게 클라인의 설명이다. “도커(Docker)나 큐버네티스(Kuberbetes), 혹은 오픈쉬프트(OpenShift)와 같은 툴셋 혹은 플랫폼을 말하는 겁니다. 이렇게 콘테이너를 통합하게 해주는 도구나 플랫폼의 가시성이 있어야 프로세스 간 상호 의존도를 매핑할 수 있게 되고, 정책도 만들 수 있게 되며, 정책을 고르게 적용시킬 수도 있게 되는 겁니다.”
4. 표준화된 설정과 구축
콘테이너의 환경설정 오류와 보안 구멍들이 뒤섞이게 되면 IT 환경 전체가 높은 위험에 노출되는 것은 물론, 민감한 데이터를 손실할 가능성도 높아진다. “그래서 중요한 게 표준화 작업입니다. 환경설정은 물론 구축 과정에 대한 표준화를 수립함으로써 일원화된 관리 체제를 만들어야 합니다.” 스리니바산의 설명이다.
“그래서 제가 권장하는 건 도커 호스트(Docker Host) 구축 시 인터넷보안센터(CIS) 표준이 지켜지도록 ‘컴플라이언스 코딩(compliance-as-code)’ 체제를 도입하는 겁니다.” 또한 데브옵스 팀과 개발자 사이를 연결시켜주는 안전한 API를 유통시키는 것 역시 중요하다고 스리니바산은 강조한다.
“한 가지 더 있습니다. 콘테이너를 안전하게 보호하고자 한다면 특정 콘테이너 환경에서의 메타데이터와 로그를 모으는 것이 중요합니다. 큐버네티스와 같은 새로운 오케스트레이션 환경에 대한 이해도를 높이는 것 역시 필요한 일입니다. 알면 알수록 더 안전하게 보호할 수 있습니다.”
5. 추적과 모니터링
콘테이너 환경을 안전하게 보호하려면 기업 내에서 콘테이너가 어떻게 사용되고 있는지 추적하고 찾아낼 수 있어야 한다. 잠재적으로 문제가 될 수 있을만한 부분을 찾아내는 것 역시 보안 담당자들의 통제 하에 있어야 한다. 예를 들어 자원이 병목 현상을 일으키는 부분이나 취약점이 발견되는 곳을 알아내고 조치를 취할 수 있어야 한다는 것이다.
스리니바산은 “콘테이너 자체에 있는 침입 탐지 및 방해 기능을 활용하는 것은 물론, 취약점 관리 및 컴플라이언스 확인에 관한 효율적인 체계를 마련하는 게 필요하다”고 말한다.
6. 콘테이너만을 위한 호스트 OS
콘테이너 환경에 대한 공격 가능성을 줄이고 싶다면, 일반 OS를 사용하지 말라고 NIST는 권장하고 있다. 콘테이너만을 위한 OS를 사용하는 게 낫다는 건데, 그 이유는 “불필요한 기능은 전부 제거해 공격 표면 자체가 작고, 콘테이너 내에서만 작동하도록 설계되었기 때문”이다. 공격자들 입장에서 찔러볼 만한 구석이 최소화 되어 있는 것이 콘테이너 전용 OS들이다.
7. 콘테이너의 위험 우선순위 매기기
콘테이너 환경에 있을 수 있는 다양한 위험 요소들의 순위를 매기는 것도 중요하다. 보안 업체 스택록스(StackRox)의 CEO 알리 골샨(Ali Golshan)은 “취약점 스캔에서 얻어낸 데이터, 비밀 관리, 오케스트레이션 환경설정, 서비스 환경설정, 사용자 권한 관리, 레지스트리 메타데이터를 통해 위협에 대한 많은 정보를 얻어낼 수 있다”고 설명한다.
“이런 데이터를 활용해 콘테이너 환경에서 가장 위험한 부분을 정확히 하나 짚어내세요. 그러면 개발자들이 이 부분에 집중해 문제를 해결하거나 그 부분을 유의해가면서 콘테이너 애플리케이션을 만들 겁니다. 이런 일을 반복하세요.” 골샨의 설명이다.
8. 그룹 콘테이너
다양한 위험 요소를 가진 여러 애플리케이션들을 한 개의 호스트 OS 커널에서 돌리면, 사실 그 위험의 총합적인 수위가 모든 애플리케이션에 적용된다. 그러므로 같은 목적과 중요도, 위험 수위를 가진 콘테이너들끼리 묶어서 그룹화하는 것이 좋다고 NIST는 설명한다. 즉 콘테이너를 세그멘테이션 하라는 것인데, 이 작업을 통해 ‘심층 방어’를 할 수 있다고 한다. “이렇게 되면 하나의 콘테이너를 침해하더라도, 다른 콘테이너를 보호할 수 있죠.”
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
