블로그 릴레이 - AWS에서의 컨테이너 보안에 대해 2
2025.02.09안녕하세요! 클래스메소드의 이수재입니다.
본 블로그는 당사의 한국어 블로그 릴레이의 2025년 세 번째 블로그입니다.
이번 블로그의 주제는「AWS에서의 컨테이너 보안에 대해」그 두 번째 입니다.
1편은 아래입니다.
무엇을 확인해야하는가
컨테이너 보안에 대해서는 가이드라인이 되고 있는 애플리케이션 컨테이너 보안 가이드(NIST SP800-190)[1]라는 것이 있습니다.
해당 가이드라인에 따르면 컨테이너의 보안 리스크는 아래와 같이 분류되고 있습니다.
- 이미지에 대한 위험
- 레지스트리에 대한 위험
- 오케스트레이터에 대한 위험
- 호스트에 대한 위험
- 컨테이너에 대한 위험
저번 글에 이어서 오케스트레이터에 대한 위험부터 알아보겠습니다.
오케스트레이터에 대한 위험
제한되지 않은 관리자 접근
대부분의 오케스트레이터는 "오케스트레이터의 사용자는 모두 관리자이며, 관리자는 전체 환경에 대한 통제권을 가져야 한다" 라는 가정으로 설계되었습니다[1:1]
하지만 현재의 오케스트레이터는 각자 다른 앱이나 워크로드를 실행하는 경우가 많습니다.
따라서 관리자가 여러 명일 경우 각 환경에 대해 허용된 권한만을 가지도록 설정할 필요가 있습니다.
이미지에 불필요한 부분을 제거하여 이미지의 읽기 속도 및 보안 향상을 실현할 수 있습니다.
인가되지 않은 접근
오케스트레이터가 자체적인 인증 디렉터리 서비스를 가지고 있는 경우가 있습니다.
이미 조직에서 사용하고 있는 디렉터리 서비스가 외부 디렉터리 서비스이고 OAuth와 연계되어 있다면 오케스트레이터에서도 그대로 사용할 수 있는 경우가 있습니다.
하지만 오케스트레이터의 디렉터리 서비스와 연계가 되지 않아 기존 환경과 분리되어 관리되고 있는 경우 계정 관리가 취약해지거나 이로 인해 고아 계정(orphaned account) 등이 생길 수 있습니다.
컨테이너가 다양한 노드에서 실행될 수 있는 환경의 경우 컨테이너를 관리하기 위해 고아 계정의 역할이 생각보다 많은 권한을 가지고 있을 수 도 있습니다.
이러한 고아 계정은 오케스트레이터 관리의 취약점이 되기 때문에 이러한 관리 미흡이 발생하기 이전에 인증/인가를 관리할 필요가 있습니다.
따라서 조직에게 기존에 사용하고 있던 디렉토리 서비스에 대해 SSO를 구현하고 이를 통하여 오케스트레이터에도 인증이 되도록 구현하는 것이 좋습니다.
이를 위하여 기존 조직 환경과 오케스트레이터 양 측에서 사용할 수 있는 SSO 서비스를 이용하거나 AWS IAM Identity Center를 이용하여 이를 구현할 수 있습니다.
이 내용은 이전 글에서 설명하였던 레지스트리에 대한 인증 인가와 더불어 엄밀한 관리를 하는 것을 추천드립니다.
컨테이너 간 네트워크 트래픽 분리 미흡
컨테이너 환경에서 컨테이너 간의 트래픽은 가상 오버레이 네트워크에서 통신됩니다. 이러한 네트워크는 보통 오케스트레이터에서 관리합니다.
이러한 네트워크를 모니터링하기 위한 별도의 툴을 도입하여 활용하는 것 뿐만 아니라 중요도에 따라 네트워크 트래픽을 각각의 가상 네트워크로 분리하도록 설계하는 것도 가능합니다.
업무 중요도 혼합
보통 컨테이너 환경을 운용하는 경우에는 다양한 목적을 가진 컨테이너가 다수 존재하고, 서로 다른 목적을 가진 컨테이너가 하나의 호스트(혹은 노드)에서 실행되는 경우가 있습니다.
예로들면 퍼블릭한 환경에서 접속할 수 있는 컨테이너와 기밀성이 높은 데이터를 취급하는 프라이빗한 컨테이너가 같은 노드에서 실행될 수 있습니다.
만약 이 호스트에 보안 사고가 발생하면 프라이빗한 컨테이너까지 영향을 받아 사고 범위가 커질 수 있습니다.
따라서 컨테이너의 중요도에 따라서 운용하는 호스트를 나누어 실행하도록 설계하는 것이 중요합니다.
즉, 애플리케이션의 계층화와 네트워크 및 호스트의 분리를 앱 설계부터 염두해두는 것이 좋습니다.
대부분의 오케스트레이터션 툴에서는 이름/라벨/네임스페이스 등 이러한 기능을 지원하는 기능등이 있으므로 확인해보는 것을 추천합니다.
아래는 백서의 예시를 그대로 빌려온 내용입니다.
예시
예를 들어 재무 데이터베이스 컨테이너와 공개 블로그 컨테이너를 동일한 호스트에서 실행하고 있다고 가정하자.
컨테이너 런타임은 일반적으로 이러한 환경을 효과적으로 분리할 것이다.
하지만 DevOps팀은 담당하는 앱을 안전하게 운영하고 불필요한 위험을 제거해야 하는 책임이 있다.
블로그 앱이 공격자에 의해 침해된 경우, 두 가지 앱이 동일한 호스트에서 실행되고 있다면 재무 데이터베이스을 보호할 수 있는 방어 계층은 훨씬 적을 것이다.
오케스트레이터 신뢰
모든 앱을 실행하는 환경은 오케스트레이터가 관리 및 실행하기 때문에 오케스트레이터에 대한 신뢰가 유지될 수 있는 설계가 되어야합니다.
노드는 모든 클러스터를 안전하게 환경에 생성 및 추가해야하고 전체 생명 주기에서 고유한 ID를 가져야합니다.
또한 조직의 개별 노드에 보안 문제가 발생하여도 환경 정체에 영향이 발생하지 않도록 설계하여야 합니다.
그리고 클러스터 멤버 간 상호 인증 및 종단 간 암호화도 구현하는 것이 좋습니다.
이런 부분을 고려하지 못하고 오케스트레이터를 설정하는 경우 다음과 같은 문제가 발생할 수 있습니다.[2]
- 비인가된 호스트가 클러스터에 가입되고, 컨테이너를 실행한다.
- 클러스터의 한 호스트가 침해되는 것은 전체 클러스터가 침해되는 것을 의미한다. 예를 들어 인증에 사용되는 비밀키-공개키 쌍(key pair)을 모든 노드에서 공유한다면, 한 호스트의 침해가 전체 클러스터의 침해로 귀결될 것이다.
- 오케스트레이터, DevOps 담당자, 관리자, 호스트 사이의 통신이 암호화되지 않거나, 인증을 수행하지 않는다
컨테이너에 대한 위험
컨테이너 런타임 내의 취약점
Docker Container Escape(CVE-2019-5736, runC취약점)과 같은 컨테이너 이스케이프 취약점은 컨테이너 런타임에 위험합니다.
따라서 현재 사용하는 런타임에 어떤 취약점이 있는지 확인하고 패치 버전에서 문제가 있으면 바로 복구할 수 있는 등 해결할 수 있는 환경을 마련하여야 합니다.
보안 취약점이 발생하면 CVE에 등록되어 공개가 됩니다.
항상 체크할 수 없다면 자동으로 체크해주는 도구 등을 도입하는 것이 좋습니다.
한국인터넷진흥원에서는 CVE를 검색할 수 있는 사이트를 공개하고 있습니다.
제한되지 않은 접근
대부분의 컨테이너 런타임에서 컨테이너는 기본적으로 네트워크를 통해 다른 컨테이너 및 호스트 OS에 접근할 수 있습니다.
그런 취약점을 이용하여 악의적인 의도로 접근하여 컨테이너 환경을 조작하려는 시도가 있을 수도 있습니다.
이는 위에서 설명한 컨테이너 간 네트워크 트래픽 분리 부족과 관계가 있습니다.
따라서 컨테이너 간에 중요도에 따라서 네트워크 통신을 제한하는 것을 고려해볼 수 있습니다.
그리고 컨테이너 간에 전송되는 트래픽은 모니터링 하는 것이 좋습니다.
호스트 사이에 배치된 컨테이너 사이의 통신은 암호화된 네트워크를 사용하는 경우가 일반적이기 때문에 이러한 트래픽을 분석하고 관리할 수 있는 도구를 도입하는 것도 검토할 수 있습니다.
시중에 공개되어 있는 Datadog 등과 같은 서비스들은 대부분 대응하고 있는 기능입니다.
안전하지 않은 컨테이너 런타임 설정
관리자는 오케스트레이션 도구의 옵션을 설정하며 운용합니다.
변경한 설정에 따라 시스템의 보안이 상대적으로 불안정해질 수 있습니다.
예로 들면 컨테이너가 priviledged mode로 실행되면 호스트의 모든 디바이스에 접근할 수 있습니다.
따라서 컨테이너가 호스트 OS의 한 부분처럼 동작하며 호스트 OS에서 실행되고 있는 다른 모든 컨테이너에 영향을 줄 수 있습니다.
이러한 부분은 공격자에게 타겟이 되기 쉬우며 큰 피해가 발생할 수 있습니다.
이를 해결하기 위해 컨테이너 런타임 설정 표준에 대한 컴플라이언스를 자동화하는 것을 권장하고 있습니다.
인터넷 보안 센터(CIS)에서 제공하는 컨테이너 보안을 위한 권장사항인 CIS 컨테이너 벤치마크라는 것이 있습니다. 이는 컨테이너 최적화 OS(COS)를 사용하여 보안 상태를 강화하는 데 도움을 줍니다.
쿠버네티스의 kube-bench와 같이 사용하고 있는 오케스트레이션이 CIS Benchmark를 어느정도 따르고 있는지 검사하는 도구가 있으니 검토하는 것을 추천합니다.
이 외에 AWS Inspector를 이용하여 컨테이너 런타임의 보안을 모니터링 하는 방법 등도 있습니다.
AWS Inspector가 아니더라도 기존에 사용하는 다른 도구 등이 있다면 기능을 검토해보는 것이 좋습니다.
앱 취약점, 불량(rogue) 컨테이너 [3]
컨테이너에서 실행하는 앱 자체의 취약점에 의해 컨테이너 환경 전체가 공격받을 수도 있습니다.
따라서 소프트웨어를 설계할 때 다양한 취약점에 대하여 검사하는 취약점 검사 도구 등을 이용하여 안전한 애플리케이션을 구현하는 것이 중요합니다.
보통 개발 환경에서 많이 생성되는 로그 컨테이너 [4] 등도 관리가 되지 않기 때문에 공격의 표적이 될 수 있습니다.
이를 위해 컨테이너를 생성 및 관리할 때 역할을 기반으로 접근을 통제(RBAC)하도록 하는 등, 의식하지 않고 사용하더라도 기본적인 보안적인 대책이 적용되도록 환경을 구현하고 사용하는 것이 좋습니다.
호스트 OS에 대한 위험
공격 표면(attack surface)이 넓은 취약점
조직의 공격 표면은 해커가 네트워크 또는 민감한 데이터에 무단으로 액세스하거나 사이버 공격을 수행하는 데 사용할 수 있는 취약성, 경로 또는 방법(공격 벡터라고도 함)의 총합입니다. - IBM
공격 표면이 넓을수록 공격자가 취약점을 찾고 접근할 수 있는 가능성이 높아지며, 호스트 OS와 호스트 OS에서 실행 중인 컨테이너가 침해될 수 있습니다.
공격 표면을 줄이기 위해서는 컨테이너 전용 OS(Container Optimized OS)를 사용하는 것을 검토해볼 수 있습니다.
보통 컨테이너 전용 OS는 컨테이너를 호스팅하고 다른 서비스 및 기능이 비활성화되도록 특별하게 설계되었기 때문에 공격 표면이 좁아집니다.
AWS에서는 Bottlerocket이라는 전용 OS를 제공하고 있습니다.
사용 자체에는 별도의 비용이 발생하지 않으니 확인해보는 것을 권장합니다.
AWS의 Bottlerocket 이외에도 다양한 전용 OS 가 있으니 확인하는 것을 권장합니다.
만약 환경에 컨테이너 전용 OS를 사용할 수 없다면 NIST 800-123 보안 가이드를 준수하는지 확인하는 것이 좋습니다.
공유 커널
컨테이너 전용 OS라도 커널은 공유되기 때문에 하이퍼바이저보다 객체(컨테이너 및 호스트 OS) 사이의 공격 표면이 넓습니다. 즉, 컨테이너 런타임에 의한 분리의 수준은 하이퍼바이저만큼 높지 않습니다.
따라서 중요도에 따라 컨테이너 작업을 호스트로 그룹화해야 합니다. 그리고 컨테이너화된 작업과 컨테이너화 되지 않은 작업을 동일한 호스트에서 혼합하여 실행해서는 안됩니다.
백서의 예 발췌
호스트에서 웹 서버 컨테이너를 실행중이라면, 호스트 OS에 설치된 컴포넌트로 웹 서버 등의 앱을 실행해서는 안된다.
컨테이너화된 작업을 컨테이너 전용 호스트로 분리하면, 컨테이너 보호에 최적화된 보호 대책 및 방어를 더욱 간단하고 안전하게 적용할 수 있다.
호스트 OS 컴포넌트 취약점
컨테이너 전용 OS를 비롯한 모든 호스트 OS는 기본적인 시스템 컴포넌트를 제공합니다. 이러한 컴포넌트 에도 취약점이 있을 수 있습니다.
따라서 OS에 포함된 관리/기능 컴포넌트의 버전을 확인하기 위한 관리 활동 및 도구를 구현하는 것이 좋습니다.
또한 OS 제조사에서 제공하고 있는 시스템 업데이트 및 권장 보안 패치 등을 상시로 확인하여 적용하는 것이 중요합니다.
부적절한 사용자 접근 권한
사용자가 오케스트레이터를 통하지 않고 컨테이너를 관리하기 위해 호스트에 직접 로그온한다면 조직은 위험에 노
출됩니다.
조직에서는 호스트 OS에 대한 모든 인증을 감사하고, 비정상적인 로그인을 모니터링하며, 권한이 상승되는 모든 작업을 기록해야 합니다.
호스트 OS 파일 시스템 변조
컨테이너의 설정이 불안정하면 호스트 및 호스트에서 실행되는 다른 모든 컨테이너의 안정성과 보안에 영향을 줄 수 있습니다.
따라서 컨테이너는 파일 시스템 권한을 최소한으로 실행해야 한다. 컨테이너가 호스트의 로컬 파일 시스템을 마운트하는 경우는 거의 없어야 합니다.
파일을 호스트의 디스크에 보존해야 하더라도 별도로 할당된 볼륨을 이용하도록 하는 것이 좋습니다.
혹은 외부의 스토리지 서비스를 활용하는 것을 권장합니다.
당연하지만 어떠한 경우에도 호스트의 중요한 시스템에는 접근할 수 없어야 합니다.
마무리
이로써 컨테이너의 보안에 대해 고려해야 할 점을 알아보았습니다.
이상, 한국어 블로그 릴레이의 2025년 세 번째 블로그 「AWS에서의 컨테이너 보안에 대해」 편이었습니다. 다음 네 번째 블로그 릴레이는 2월 둘째 주에 공개됩니다.
긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.
이 외 참고 자료
