Three Overlooked Lessons about Container Security

지난주는 나에게 흥미 진진한 한 주였습니다. 저는 방금 컨테이너 보안 전문가 인 Aqua Security에 가입했으며 텔 아비브에서 며칠을 보내 팀과 제품을 알게되었습니다. 나는 노련한 보안 베테랑에게는 분명할 만한 것들을 배우고 있다고 확신하지만 나머지 사람들에게는 그렇게 분명하지 않을 것입니다! 이전에 컨테이너화 된 배포의 보안에 대해 실제로 생각해 보지 못했지만 다음과 같은 세 가지 측면이 흥미롭고 희망적이었습니다.

#1: Email Addresses in Container Images

우리 중 많은 사람들이 컨테이너 이미지 안에 연락 정보를 넣었습니다. Docker 파일의 MAINTAINER 지시문이 더 일반적인 LABEL을 사용하기 때문에 더 이상 사용되지 않을지라도 사용자가 이미지 작성자에게 연락하는 것이 도움이된다고 생각하는 것은 당연합니다.

대기업에서 일하거나 이전에 보안 업무를 수행 한 적이 있다면 개별 회사 이메일 주소를 게시하면 안되며 공개 컨테이너에서 찾을 때 아쿠아 팀과 마찬가지로 소름 끼칠 수도 있습니다. 이미지. 그러나 그것은 제가 생각한 어떤 것이 아닙니다. 오픈 소스 세계에서 우리는 우리의 이름 (또는 적어도 온라인 신분)을 우리가 하고 있는 일에 쏟아 부었습니다. 그렇게하는 것이 당연한 것처럼 보입니다.

문제는 다음과 같습니다. John Doe이 공용 컨테이너 이미지 안에 john.doe@giantcorp.com과 같은 개인 이메일 주소를 남기면 누구든지 John Doe라는 (가상의) Giant Corp에 누군가가 있음을 쉽게 알 수 있으며 그 특정 구성 요소. 이는 스피어 피싱 공격에 대한 잠재적 인 가능성을 창출합니다.

 

물론 우리는 오픈 소스 프로젝트를 수행 할 때 스피어 피싱(sphear-phishing)에 취약하지만 보안, 신뢰 및 평판 사이에는 타협이 있습니다. 개발자는 개인 개발자를 볼 수 있다면 주어진 프로젝트에 대한 신뢰도가 높아지고 개인은 자신이 작성한 코드에 공개적으로 이름을 붙여 명성을 쌓을 수 있습니다. 이러한 우려는 보안 위험보다 클 수 있습니다. 반면 Giant Corp의 브랜드 평판은 고객의 신뢰를 높이고 직원의 CV를 잘 보여 주므로 개인의 이름을 코드 나 컨테이너 이미지에 표시할 이유가 적습니다. 오픈 소스 코드로 작업하고 있다면 아마도 어쨌든 회사가 아닌 개인 이메일 주소를 사용하고 있을 것입니다. 맞습니까?

물론 해커들은 LinkedIn의 Giant Corp을 검색하여 John Doe에 대한 정보를 많이 찾을 수 있기 때문에 개인 이메일 주소를 제거한다고 해서 총 위험이 제거되는 것은 아니지만 공격 범위가 줄어 듭니다.

따라서 회사에서 일하고 있다면 개별 회사 이메일 주소가 아닌 공개 컨테이너 이미지에서 @ 또는 your-container-name @과 같은 일반적인 이메일 주소를 사용하는 방법에 대해 생각해야합니다.

#2: There’s More to Image Scanning Than Meets the Eye

컨테이너 이미지를 스캔하여 알려진 취약점이 있는지 알려주는 많은 제품이 있습니다. Aqua는 이것을 수행하지만 Docker, CoreOS의 Clair 및 여러 다른 기능도 수행합니다. 그들은 미국 표준 기술 연구소의 국가 취약성 데이터베이스 (National Vulnerability Database)와 같은 데이터베이스에 문서화되어있는 알려진 취약점을 찾아 이미지를 스캔하고 있습니다. 단순한 데요, 맞죠?

그러나 컨테이너 이미지에서 취약점이 발견되는 방식에는 상당히 세심한 부분이 있습니다.

CVE-999라는 취약점이 있는 허구 패키지 mypkg 버전 1.2.7이 있다고 가정 해 봅시다. mypkg의 관리자는이 취약점을 수정하여 mypkg 1.3.0 릴리스로 만들었습니다. 따라서 취약점 데이터베이스는 CVE-999가 1.3.0 이전의 모든 mypkg 버전에 존재한다고 알려줍니다.

 

이제 1.3.0 업스트림에 몇 가지 다른 수정 및 기능이 추가되었습니다. 스캔중인 이미지의 소유자가 모든 이미지를 필요로하지 않는다고 가정 해 봅시다. 대신 그녀는 CVE-999에 대한 픽스만 체리 피킹하기로 결정했습니다. 그녀는 자신의 mypkg 버전을 다시 빌드하고 1.2.7.12345라고했습니다.

데이터베이스에 따르면 1.2.7.12345는 수정본이 적용된 것으로 알려진 1.3.0보다 낮기 때문에이 취약점이 여전히 존재하는 것으로 보입니다. 하지만 거짓 긍정입니다.

컨테이너 이미지라는 사실은 위양성에 영향을 미치지 않습니다.하지만 컨테이너 레이어를 생각할 때 비슷한 문제가 있습니다.

mypkg 1.2.7 (수정본 없음)을 포함하는 기본 이미지가 있다고 가정하여 취약성을 알 수 있습니다. 스캐너가 계층별로 취약점을 단순히보고하는 경우 패키지가 다른 계층에서 버전 1.3.0으로 대체 되더라도 모든 하위 이미지에 문제가있는 것처럼 보입니다. 또 다른 위양성.


세 번째 유형의 오 탐지는 배포하는 코드에 취약점이 있을 때 발생할 수 있지만 다른 구성 요소와 상호 작용할 때만 발생합니다. 해당 구성 요소를 사용하지 않으면 취약점이 실제로 배포에 영향을 줄 수 없습니다. 예를 들어, 네트워크 액세스를 통해 악용되는 취약점을 고려하십시오. 컨테이너에 네트워크 인터페이스가없는 경우 취약점이 존재하는지 여부는 중요하지 않습니다.

이러한 위양성은 단지 성가신 것만은은 아니며, 사람들이 생산 방식의 코드가 진정으로 문제가 있는지 여부를 이해하는 것을 혼란스럽게합니다. 사람들이 오탐 (false positive)을 무시하는 것에 익숙해 질수록, 상당한 양의 긍정적 인 결과가 나타 났을 때주의를 기울이고 반응 할 가능성이 줄어든다.

#3: Detection as Well as Prevention

정의에 따르면, 제로 데이 익스플로잇 도입과 발견 사이에는 시간차가 있습니다. 이 틈에서 취약점을 알 수는 없지만 이미지 검색은 취약점을 배포하는 것을 피할 수 없습니다. Donald Rumsfeld의 말을 바꾸려면 알려진 미지의 통제하에 있어야하지만, 우리가 정말로 걱정해야 할 알려지지 않은 미지의 것입니다.

어느날 가장 엄격한 정책을 사용하는 경우에도 문제가 있다는 것을 알지 못하는 무언가의 배포를 막을 수 없으므로 프로덕션 환경에 취약점이 배치됩니다. 이 취약점이 악용되면 코드의 동작이 비정상적인 파일에 기록되거나 예기치 않은 네트워크 트래픽이 전송되는 등의 방식으로 변경됩니다.

"정상적인"동작을 구성하는 것이 중요하지는 않지만 컨테이너화 된 마이크로 서비스 아키텍처가 실제로 여기에서 도움이됩니다. 컨테이너의 기능성이 적을수록 수행해야 할 작업에 대한 제한을 정의하는 것이 쉬워집니다. 그러면 보안이 강화됩니다.


예를 들어 컨테이너 내부에서 실행되는 마이크로 서비스는 일반적으로 소수의 포트만 사용하여 소수의 다른 서비스와 통신합니다. 동일한 코드가 완전히 다른 포트에서 요청을 보내려고 한다는 것을 관찰하기 시작했다면 의심스러운 것으로 생각되어 중단하고 조사해야합니다. 마찬가지로 일반적으로 마이크로 서비스가 액세스해야하는 파일 또는 실행 파일 집합을 예측할 수 있습니다. 그 밖의 어떤 것도 총을 뽑을 수 있습니다.

비정상적인 행동을 감지하면 문제가 있음을 발견 할 수 있으며 예기치 않은 행동이 일어나지 않도록 조치를 취할 수 있습니다.

Conclusion

콘테이너 보안에서 흥미로운 개념의 표면을 처음부터 짚어보기 시작했습니다. 우리의 컨테이너 화 된 배치가 가능한 한 안전하다는 것을 확인하기 위해 우리가 생각해야 할 중요한 것들이 있습니다. 내가 알 필요가 있다고 말하는 각도가 있거나, 더 자세히 알고 싶은 질문이 있다면, 당신의 의견을 듣고 싶습니다.


Comments

Category
글이 없습니다.
글이 없습니다.
반응형 구글광고 등
State
  • 현재 접속자 2 명
  • 오늘 방문자 125 명
  • 어제 방문자 192 명
  • 최대 방문자 420 명
  • 전체 방문자 84,642 명
  • 전체 게시물 331 개
  • 전체 댓글수 2 개
  • 전체 회원수 26 명
Facebook Twitter GooglePlus KakaoStory NaverBand