컨테이너 보안 이미지 스캐닝, 접근 제어, 보안 감사 등의 기술을 활용하여 컨테이너화된 애플리케이션과 그 생태계를 위협 및 위험으로부터 방어하는 것을 포함합니다. 컨테이너화는 "내 컴퓨터에서만 작동한다"는 문제를 해결하고 애플리케이션 개발의 이동성을 높여줍니다. 소스 코드를 종속성 및 런타임과 함께 번들로 묶어 온프레미스나 클라우드 등 어떤 플랫폼에도 배포할 수 있습니다. 그러나 컨테이너화에는 도전 과제가 따르며, 그중 가장 악명 높은 것이 보안 문제입니다.
이 글에서는 컨테이너 보안 문제와 관련된 과제들을 논의하고 보안 조치 개선을 위한 몇 가지 팁을 공유하겠습니다.
일반적인 컨테이너 보안 문제
다음은 일반적인 컨테이너 보안 문제 목록입니다:
#1. 애플리케이션 취약점
컨테이너는 애플리케이션과 그 종속성을 패키징하지만, 애플리케이션에 취약점이 존재하면 컨테이너에 위험을 초래합니다. 위험 요소는 구식 라이브러리, 안전하지 않은 코드, 패치되지 않은 소프트웨어 등이 될 수 있습니다. 예를 들어, 공격자는 타사 라이브러리의 시스템 취약점을 악용하여 컨테이너 내부에서 코드를 실행하고 추가 공격을 수행할 수 있습니다.
#2. 취약한 컨테이너 이미지
이미지는 컨테이너의 구성 요소이며, 제한된 리소스와 최적화된 성능 때문에 베이스 이미지를 선택할 때 가벼운 옵션을 선택하는 경우가 많습니다. 그러나 크기만 고려해서는 충분하지 않습니다. 취약점이 있는 이미지를 선택하면 컨테이너가 손상될 수 있기 때문입니다. 따라서 항상 평판이 좋은 레지스트리에서 이미지를 선택하고 정기적으로 업데이트해야 합니다.
#3. 안전하지 않은 구성
안전하지 않은 구성에는 컨테이너나 기본 인프라를 잘못 설정하여 민감한 정보가 유출될 수 있는 경우가 포함됩니다. 잘못된 구성의 예로는 기본 설정 적용, 사용자에게 루트 권한 부여, 불필요한 포트 개방 유지 등이 있습니다. 개발자가 컨테이너를 루트 권한으로 실행하도록 잘못 구성하면 컨테이너가 호스트 시스템에 무제한 접근할 수 있게 됩니다. 프로덕션 환경에서 디버깅 포트를 노출하면 공격자가 내부 애플리케이션 프로세스 흐름을 파악할 수도 있습니다.
#4. 런타임 보안 위협
런타임 보안 위협은 운영 중인 컨테이너를 표적으로 삼습니다. 이 단계에서 공격자는 악성 코드를 주입하거나, 권한 상승 공격을 수행하거나, 리소스의 제어권을 장악할 수 있습니다. 공격자는 실행 중인 컨테이너의 파일 시스템을 변경하여 악성 코드를 삽입하거나 시스템 파일을 대체할 수 있습니다.
#5. 컨테이너 탈출 공격
컨테이너 탈출 공격은 공격자가 컨테이너 환경을 벗어나 호스트에 접근할 수 있을 때 발생합니다. 컨테이너 내에서 실행되는 애플리케이션은 호스트 OS 환경에서 작동하므로 OS 커널이 주요 위험 요소입니다. 해커는 특정 환경에 진입하면 컨테이너에서 호스트 수준으로 전환하여 다른 컨테이너와 잠재적으로 전체 시스템을 제어할 수 있습니다.
#6. 네트워크 보안 문제
컨테이너화된 환경에서는 컨테이너, 서비스 및 기타 네트워크 간의 상호 작용 지점이 많기 때문에 보안이 필수적입니다. 네트워크 트래픽을 잘 분할하고 제어해야 한다고 가정해 보십시오. 공격자는 이러한 열린 연결을 활용하여 한 컨테이너에서 다른 컨테이너로 이동하면서 자신의 권한을 확대하고 기밀 정보를 훔칠 수 있습니다. 부적절한 네트워크 정책 구성으로 인해 하나 이상의 컨테이너에서 유효하지 않은 트래픽이 속하지 않는 보안 경계에 액세스하여 데이터를 손상시킬 수 있습니다.
#7. 컨테이너 접근 제어 및 권한 부여
접근 제어와 권한 부여는 특정 사용자만 컨테이너 및 관련 자산에 접근할 수 있도록 보장합니다. 그러나 취약한 접근 제어는 무단 접근, 권한 상승, 심지어 컨테이너화된 환경의 완전한 악용으로 이어질 수 있습니다. 예를 들어, 취약한 RBAC 구성은 사용자가 특권 데이터에 접근하거나 무단 작업을 수행할 수 있는 권한을 부여하여 데이터 손실이나 서비스 중단으로 이어질 수 있습니다.
#8. 컨테이너 내 비밀 정보 관리 부실
비밀 정보 관리가 부실하면 데이터 유출, 무단 접근, 시스템 전체 침해로 이어집니다. 예로는 민감한 인증 정보를 컨테이너 이미지나 환경 변수에 직접 하드코딩하거나, 평문 구성 파일이나 암호화되지 않은 네트워크를 통해 컨테이너에 비밀 정보를 배포하는 등 안전하지 않은 방법을 사용하는 경우가 있습니다. 공격자는 해당 이미지나 런타임 환경에 접근할 수 있다면 이러한 시크릿을 쉽게 볼 수 있습니다.
#9. 안전하지 않은 API
API는 컨테이너화된 환경에서 서비스 간 통신을 가능하게 합니다. 안전하지 않은 API는 패치되지 않은 취약점을 악용하여 민감한 데이터나 시스템에 접근하려는 공격자의 진입점이 됩니다. 예를 들어, 적절한 인증 제어 없이 Kubernetes API 서버를 사용하는 경우, 권한이 없는 사용자가 중요한 구성 요소를 제어하거나 변경할 수 있습니다. 잘못 구성되었거나 취약한 API는 또한 SQL 인젝션 또는 크로스 사이트 스크립팅 공격에 취약합니다.
#10. 적절한 모니터링 및 로깅 부족
컨테이너 환경에서 로깅 및 감사 솔루션을 활용하지 않으면 보안 문제를 탐지하고 조사하며 대응하는 능력이 제한됩니다. 적절한 로깅이 없으면 취약점의 근원을 추적하는 데 어려움을 겪을 수 있습니다.
CNAPP 마켓 가이드컨테이너 보안을 위한 모범 사례
컨테이너에는 보안 문제가 있지만, 그 영향을 줄이기 위해 권장되는 몇 가지 방법이 있습니다.
1. 이미지 보안
취약점이 있는 이미지는 전체 컨테이너를 위협합니다. 따라서 항상 공식 레지스트리 또는 안전한 사설 저장소에서만 이미지를 실행하십시오. 레지스트리는 사용 중인 이미지가 보안 조치를 준수하도록 품질 및 보안 조치를 마련해 두고 있습니다. 컨테이너 이미지를 사용하거나 배포하기 전에 반드시 컨테이너 이미지 스캔을 통해 취약점을 검사해야 합니다. 또한, 큰 이미지는 의도하지 않은 보안 취약점을 유발할 수 있는 추가 패키지를 포함할 수 있으므로 작은 이미지를 사용하세요. 그러나 가장 중요한 것은 이미지가 최신 상태인지 확인하는 것입니다.
2. 컨테이너 런타임 보안 강화
컨테이너 런타임을 보호하는 한 가지 방법은 읽기 전용 파일 시스템을 사용하는 것입니다. 이는 런타임 중에 컨테이너에 가해지는 변경으로부터 컨테이너를 보호할 수 있기 때문에 중요합니다. 볼륨을 읽기 전용으로 마운트하거나 Docker를 —read-only 옵션과 함께 시작하는 것입니다. 예를 들어, 애플리케이션 컨테이너는 로그 및 임시 파일을 위한 디렉터리에 쓰기 권한이 필요하지만, 나머지 파일 시스템은 읽기 전용입니다. SELinux 및 AppArmor와 같은 다른 보안 기능을 활성화하면 애플리케이션의 리소스 사용에 대한 사용자 제약을 강제 적용함으로써 추가적인 방어선을 제공합니다. 이러한 도구는 컨테이너 내부의 프로세스가 수행할 수 있는 작업을 정의할 수 있으므로, 컨테이너가 침해되더라도 피해가 제한됩니다.
3. 정기적인 보안 감사 수행
견고한 보안 태세를 유지하려면 정기적인 보안 감사 수행이 필수적입니다. 이러한 감사는 이미지 보안, 런타임 구성, 네트워크 정책, 접근 제어 등 컨테이너 환경의 다양한 측면을 포괄해야 합니다. 예를 들어, 분기별 보안 감사에는 컨테이너화된 애플리케이션에 대한 침투 테스트, 의심스러운 활동을 위한 접근 로그 검토, 현재 보안 조치의 효과성 평가 등이 포함될 수 있습니다.
4. 최소 권한 원칙 구현
최소 권한 원칙은 컨테이너 보안을 유지하기 위한 중요한 규칙입니다. 이 원칙은 컨테이너와 사용자에게 최소한의 운영 권한만을 부여해야 함을 의미합니다. 예를 들어, 컨테이너를 루트 권한이 아닌 다른 권한으로 실행하는 등의 조치는 컨테이너 침해 시 발생할 수 있는 피해를 크게 줄일 수 있습니다. 마찬가지로, 컨테이너와 다른 서비스 간에 필요한 상호작용만 허용하도록 네트워크 정책을 정의해야 합니다.
법적 및 규정 준수 고려 사항
컨테이너 보안을 다룰 때 고려해야 할 주요 법적 및 규정 준수 사항은 다음과 같습니다:
컨테이너 내 데이터 프라이버시
컨테이너 내 데이터 보안은 GDPR 및 HIPAA와 같은 규정이 개인 데이터 처리를 제한하기 때문에 중요한 규정 준수 요소입니다. 컨테이너는 일시적이며 빠르게 복제될 수 있기 때문에, 저장 및 전송부터 폐기에 이르기까지 컨테이너 수명 주기의 다양한 단계에서 데이터를 보호하는 방법을 복잡하게 만듭니다. GDPR과 같은 법률 규정은 데이터를 특정 지역에 저장할 것을 요구합니다. 여러 클라우드에서 실행되는 컨테이너는 민감한 정보가 경계를 넘어 전송되는 것을 방지하기 위해 데이터 주권 규칙을 준수해야 합니다.
감사 준비 상태
감사 준비 상태란 조직이 관련 규제 기관이 적용하는 감사 요구 사항을 충족할 수 있는 역량을 입증할 준비가 되어 있는 상태를 의미합니다. 컨테이너는 유연성과 일시적인 특성으로 인해 이벤트 추적, 활동 관찰 또는 특정 로그 저장을 보장하기가 거의 불가능하기 때문에 어려울 수 있습니다.
규정을 준수하는 컨테이너 환경은 효과적인 로깅 및 모니터링 기능을 갖추어야 합니다. 여기에는 모든 보안 활동, 시스템 구성 변경 및 민감한 정보에 대한 접근이 포함되어야 합니다. 생성된 모든 컨테이너에서 로그가 수집 및 저장되도록 보장하기 위해 ELK(Elasticsearch, Logstash, Kibana) 및 Prometheus와 같은 도구가 있습니다.
"FAQs
SentinelOne은 AI 기반 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)으로, 컨테이너 내 실시간 위협 탐지 및 격리, 이미지 스캔, 쿠버네티스 클러스터 가시성 확보, 모니터링 기능을 제공합니다.
"위협 환경이 지속적으로 진화함에 따라 공격자들은 컨테이너 취약점을 악용하기 위한 새로운 기법을 개발합니다. 이러한 신종 위협에 대비하기 위해서는 컨테이너 보안에 대한 지속적인 관심이 필요합니다. 컨테이너는 일시적인 특성, 호스트와의 커널 공유, 잘못된 구성 가능성 등 고유한 보안 문제를 안고 있습니다. 컨테이너 환경에서의 보안 침해는 서비스 중단, 데이터 손실, 평판 손상으로 이어질 수 있습니다. 컨테이너 보안 문제를 완화하려면 SentinelOne과 같은 강력한 솔루션이 필요합니다.
"예, 제대로 관리 및 보안이 적용되지 않을 경우 위험합니다. 컨테이너화된 환경의 동적 특성은 공격자가 악용할 수 있는 취약점을 생성할 수 있습니다. 그러나 적절한 보안 관행과 도구를 통해 위험을 완화할 수 있습니다.
"적절히 구성 및 관리될 경우 기존 배포 방식보다 더 안전할 수 있습니다. 개발 및 운영 환경 전반에 걸쳐 향상된 격리성과 일관된 환경을 제공하는 등의 이점이 있습니다.
"