이 시리즈를 처음 접하신다면 처음부터 시작하는 것이 좋습니다:
컨테이너 보안 기초: 소개
컨테이너 보안 기초: 파이프라인
컨테이너 보안 기초: 오케스트레이션
워크로드는 비교적 최근에 등장한 용어로, 흔히 애플리케이션을 설명할 때 사용되지만 인프라 서비스를 가리키기도 합니다. 이는 중요한 의미를 갖습니다. 컨테이너 클러스터에서는 개발자가 제공한 것이 아닌 다양한 ‘워크로드’가 실행될 수 있기 때문입니다. 컨테이너 환경에서 여러 목적으로 무료 오픈 소스 서비스를 사용하는 사례가 늘고 있습니다. 실제로 이러한 추세는 IT 운영 전반에서도 나타나며, IT 운영은 지난 한 해 동안 무료 오픈 소스 소프트웨어 다운로드가 가장 많았던 분야입니다.
따라서 워크로드 보안이란 컨테이너 환경에 다운로드하거나 개발 또는 배포한 모든 소프트웨어의 보안을 의미합니다. 예를 들어 Consul이 있습니다. Kubernetes 자체도 마찬가지입니다. 또한 Prometheus와 Elasticsearch, NGINX와 istio도 해당합니다.
그리고 Kubernetes 환경을 지원하기 위해 배포한 모든 API 게이트웨이, 캐시, 인그레스 컨트롤러도 이 목록에 포함하세요. 이때 상세한 자재 명세서가 중요하며, 안전한 환경을 유지하려면 정기적으로 인벤토리를 작성하는 것이 필수적입니다.
목록을 작성했다면 이제 워크로드 보안의 주요 문제를 해결할 차례입니다.
- 1. 인증은 선택 사항이 아닙니다
이 시리즈를 처음부터 계속 읽어 오셨다면 이미 익숙한 내용일 것입니다. 이는 컨테이너 보안의 모든 측면에서 공통적으로 강조되는 주제 중 하나입니다. 즉, 진입점을 철저히 보호해야 합니다.
이러한 모든 서비스는 클러스터에서 워크로드로 실행됩니다. 따라서 API와 데이터에 액세스할 때 기본 자격 증명을 사용하거나 초기 구성이 ‘개방’ 상태인 경우가 많습니다. 워크로드 보안에는 애플리케이션의 기능 및 운영에 필요한 모든 구성 요소, 소프트웨어, 애플리케이션 서비스가 포함됩니다. - 2. 악성 콘텐츠는 악성입니다
자격 증명을 요구하고 액세스 제어를 적용해 문을 잠근 후에도 악성 콘텐츠를 경계해야 합니다. 이는 사용 중인 애플리케이션, 마이크로서비스 및 운영 서비스에도 해당합니다. 사용자(운영자든 소비자든)에게 인터페이스를 제공하는 모든 워크로드는 잠재적으로 위험에 노출될 수 있습니다. 따라서 반드시 스캔하고 조치를 취해야 합니다. HTTP 취약점이든 애플리케이션 로직의 취약점이든, 애플리케이션 계층에서 취약점을 찾는 것이 첫 번째 단계입니다. 취약점을 발견했다면 이제 조치를 취해야 합니다. 자체 개발 애플리케이션이라면 개발팀에 돌려보내고, 타사 구성 요소라면 패치 또는 업그레이드된 버전이 있는지 확인해야 합니다. 타사 구성 요소는 컨테이너 이미지로 제공되는 경우가 많으며, Snyk의 2019년 오픈 소스 보안 현황 보고서에 따르면 그중 44%에는 알려진 취약점이 있으며, 이러한 취약점에 대해 더 새롭고 안전한 베이스 이미지가 제공됩니다.
다시 한번 강조하겠습니다. 스캔을 실행해도 취약점을 해결하지 않으면 보안 개선에는 아무런 도움이 되지 않습니다.
잠긴 문을 쉽게 우회해 침입할 수 있는 구멍이 벽에 있다면 당연히 그 구멍을 막을 것입니다. 마찬가지로 가상의 벽에 난 가상의 구멍도 막아야 합니다.
개발자가 취약점을 즉시 해결할 수 없거나 타사 공급업체가 아직 해결하지 않은 경우, 웹 애플리케이션 방화벽이나 API 보안 게이트웨이를 사용하면 이를 완화할 수 있습니다.
이는 한마디로 "전화를 선별해서 받는 것"과 같습니다. 요청을 수락하기 전에 모든 워크로드로 들어오는 요청을 검사하고 평가하는 것이기 때문입니다. - 3. 리소스 공유는 위험 공유를 의미합니다
기존 가상화와 마찬가지로 컨테이너도 완전히 격리되어 있지는 않습니다. 컨테이너는 궁극적으로 동일한 물리적 OS를 공유합니다. 즉, 공유 OS의 취약점은 모든 컨테이너가 공유하는 취약점이 됩니다.
공격자가 OS 구성 요소의 취약점을 악용할 수 있다면 하나 이상의 워크로드를 침해할 수 있습니다. 이러한 취약점은 '문단속'이나 '호출 차단'에 실패해 노출될 수 있습니다. 이는 결코 비현실적인 시나리오가 아닙니다. 실제로 CVE-2019-5736에서는 OS 계층의 runc 취약점으로 인해 인터넷 전체가 공황에 빠졌습니다.
여기서 핵심 보안 원칙은 SELinux 및 Red Hat 컨테이너 보안 전문가인 댄 월시가 다음과 같이 유명하게 표현했습니다: "컨테이너는 완벽히 격리하지 못한다".
노드 외부의 서비스 및 사용자와 주고받는 모든 네트워크 트래픽은 호스트 OS를 거쳐야 한다는 점에 유의해야 합니다. 노드 내 포드와 컨테이너 간 네트워킹은 가상 브리지와 iptables를 적절히 활용하는 가상 네트워킹을 통해 이루어집니다. 하지만 결국 트래픽은 해당 물리적 노드를 벗어나야 하므로 호스트 OS에서 처리됩니다. 에이전트, 플러그인 및 기타 데몬이 보안 또는 가시성 확보를 위해 이 트래픽을 관찰하거나 캡처할 수 있습니다. 이러한 요소는 잠재적인 침해 지점이므로 파이프라인 보안에 대해 읽은 후 작성하기 시작한 인벤토리에 추가해야 합니다.
- 4. 민감한 세부 정보 로깅
컨테이너 보안에 관한 논의에 로그 관련 경고가 포함될 것이라고는 예상하지 못했을 수도 있습니다. 하지만 로그 파일에 민감한 정보가 기록되는 경우가 있기 때문에 반드시 다뤄야 합니다. 권한 부여 토큰, 암호화 공급자 키, 자격 증명 등이 이에 해당합니다. 이러한 정보는 모두 워크로드에 의해 의도치 않게 로그에 기록되거나 stderr에 표시될 수 있습니다. 이는 인증 오류로 인한 문제를 추적해야 할 때 흔히 발생합니다. 일반적으로 시스템에 비밀 정보를 로깅하지 않도록 권고하고, 가능하다면 금지해야 합니다.
개발자가 이러한 위험을 인지하도록 지원하려면 로깅 설계 가이드를 제공하고 로그에 기록해도 되는 내용과 기록해서는 안 되는 내용을 명시하는 것이 좋습니다.
컨테이너 환경에서의 워크로드 보안은 대부분 프로덕션 환경에서 실행되는 다른 애플리케이션 워크로드의 보안과 동일합니다. 액세스를 제어하고 강력한 인증을 요구하며, 악성 콘텐츠를 감시하고 공유 리소스 및 플랫폼 수준의 취약점에 유의해야 합니다.
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.