안녕하세요, 정보 보안 담당자님. DevOps 팀을 보호하기 위해 어떤 조치를 취하고 계신가요?

DevOps, 서버리스 애플리케이션, 컨테이너는 개발자 도구 상자에 추가된 최신 기술 중 일부에 불과합니다. 개발팀에게 이는 제품 출시 기간(TTM)이 단축된다는 것을 의미하며, 특히 애자일 팀의 경우 더욱 그렇습니다. 그렇다면 보안 운영팀은 이러한 빠른 개발 속도에 발맞춰 보안을 유지하기 위해 어떤 노력을 기울이고 있을까요? 대부분의 기업은 개발팀 내에 보안 엔지니어를 배치하는 방식을 시도하고 있는데, 이는 훌륭한 첫걸음입니다. 하지만 소스 코드 외에도 조직을 보호하기 위해 필요한 여러 계층의 보안 조치가 존재합니다.

DevOps 또는 DevSecOps는 큰 진전이지만, 많은 조직에서 DevOps의 도입(및 구현)은 여전히 어려운 과제입니다. 조직이 DevSecOps를 이미 구현했더라도 모든 보안 팀이 인지해야 할 주요 문제점들이 여전히 존재합니다.

소규모 기술 스타트업부터 글로벌 기업에 이르기까지 조직 규모에 관계없이, 신속한 배포는 경쟁 우위를 유지하는 데 핵심입니다. 보안팀은 개발팀이 업무를 수행하는 데 필요한 권한을 제공해야 합니다. 개발자와 보안팀 모두 필요할 때 언제든지 도구, 라이브러리 등을 설치할 수 있어야 합니다.

여러분은 들어보셨을 겁니다. NPM이 손상됨 그렇죠? 그럼 어때요? Arch Linux? 파이썬귀사에서는 이러한 상황을 탐지하고 예방하기 위해 어떤 보안 조치를 시행하고 있습니까?

모든 환경을 모니터링하세요

보안 팀은 타사 패키지의 손상부터 프로덕션 시스템에 이르기까지 매일 수많은 문제에 직면합니다. 하지만 배포 환경은 어떻습니까? QA 환경은요? 프로덕션 환경만큼 QA 환경도 제대로 모니터링하고 있습니까? 당연히 그래야 합니다.

많은 경우(반드시 최선의 방법은 아니지만), 개발 또는 QA 환경은 이미 검증된 안정적인 환경(예: 프로덕션 환경)을 복제한 것입니다. 즉, 이러한 환경은 기존 환경과 동일한 조건을 충족해야 합니다. 있을 수도 있습니다 생산 보안 팀이 알아야 할 데이터입니다. 이러한 개발 환경은 프로덕션 환경과 동일하거나 유사한 보안 제어를 갖추어야 하며, 모든 프로덕션 시스템과 마찬가지로 모니터링(및 로깅)되어야 합니다.

추가할 수 있는 제어 기능은 많지만, 핵심은 팀이 이러한 환경을 정확하게 모니터링하고 모든 환경에 대한 변경 사항을 파악할 수 있도록 해야 한다는 것입니다.

개발 환경이나 QA 환경에 프로덕션 환경과 무관한 데이터가 가득하다면, 여전히 주의해야 할 위험 요소들이 존재합니다.

키, 토큰, CI/CD, 맙소사!

개발자들이 CI/CD(지속적 통합 및 지속적 배포) 빌드 및 배포 환경에 접근할 수 있습니까? 또한 로컬 환경이나 AWS/Azure/GCP 등의 개발 환경에 접근할 수 있습니까?

만약 "예"라고 답하셨다면, 개발자들의 활동(특히 로컬 시스템에서의 활동)을 면밀히 모니터링해야 합니다! 악성 사이트를 방문하거나 피싱 이메일에 속는 것만으로도 심각한 위험에 처할 수 있습니다.

개발자가 클라우드 기반 리소스에 액세스하려면 일반적으로 자격 증명이나 액세스/비밀 키를 사용하여 해당 환경에 접근합니다. 이러한 자격 증명이나 키는 어디에 저장될까요? 네, 바로 개발자의 로컬 시스템입니다. 다음은 자격 증명이나 키를 찾을 수 있는 주요 위치 목록입니다.

AWS CLI: ls ~/.aws ~/.aws/credentials ~/.aws/config Azure CLI: $HOME/.azure (*nix 및 macOS) %USERPROFILE%\.azure (Windows)

개발자 컴퓨터의 자격 증명이 유출될 경우 조직에 치명적인 결과를 초래할 수 있습니다. 악의적인 공격자는 컴파일된 바이너리나 라이브러리에서 감지되지 않고 CI/CD 환경을 수정하고 코드베이스를 변경할 수 있습니다.

또한 개발자가 실수로 비밀 정보를 저장소에 커밋하는 것을 방지해야 합니다. 이를 감지하는 방법은 여러 가지가 있지만, 한 가지 방법은 다음과 같습니다. git-secrets AWS에서 제공합니다.

보안팀이 비밀 정보가 어디에 보관되는지, 어떻게 사용되는지, 그리고 이러한 자격 증명의 오용 가능성을 모니터링하거나 경고하지 않을 경우 어떤 결과가 발생하는지 정확히 이해하고 있는지 확인하십시오.

컨테이너화

조직이 컨테이너, 서버리스 및 코드형 인프라(IaC)로 전환함에 따라 정보 보안 팀은 개발 팀과 협력하여 보안 팀이 지속적으로 모니터링하는 내부 컨테이너 저장소를 구축해야 합니다. 새로운 패키지나 라이브러리가 필요한 경우, 개발 팀의 보안 엔지니어가 마스터 브랜치에 병합하기 전에 코드를 검토하도록 해야 합니다. 또한 커밋에 남아 있을 수 있는 잠재적인 비밀 정보를 식별하고 제품에서 가져오거나 사용하는 취약한 타사 라이브러리를 찾아내기 위해 저장소에 대한 자동 스캔을 구현해야 합니다.

개발팀 + 보안

개발팀에 소속되어 있다고 상상해 보세요. 다른 부서의 누군가가 와서 당신의 코드가 형편없고 보안 취약점이 곳곳에 있다고 말합니다. 어떻게 반응하시겠습니까? 아마도 좋은 반응을 보이지는 못할 겁니다. 특히 자신이 작성한 코드가 꽤 괜찮다고 생각한다면 더욱 그렇겠죠!

개발팀과의 이러한 유형의 상호작용은 항상 발생하며, 우리는 이 문제를 다른 방식으로 접근해야 합니다. 바로 이러한 이유로 보안 엔지니어를 개발팀에 배치해야 합니다. 이 엔지니어는 보안 문제를 식별하고, 백로그 항목(티켓)을 생성하고, 해당 백로그 항목을 코딩할 수 있어야 합니다. 이 핵심 인력은 개발팀 내에서 개발자이면서 동시에 보안 전문가이기도 합니다.

이제 팀 동료로부터 피드백을 받는다고 상상해 보세요. 나머지 개발팀은 더 이해심 있는 반응을 보일 것이고, 개발자와 보안팀 간의 장기적인 관계 구축을 포함하여 직접적인 소통 채널을 갖게 될 것입니다. 팀원들이 편안해지면, 나머지 개발자들은 동료에게 추가적인 업무를 맡기고 싶어 하지 않을 것입니다. 그렇다면 그들이 구현 과정에 대해 시간을 갖고 다시 생각해 볼까요? 저는 그렇게 생각합니다.

또한, 보안 엔지니어는 제품 관리자/소유자 및 아키텍트와 초기 단계부터 논의에 참여해야 합니다. 이들은 사실상의 보안 담당자이며, 제품의 보안 처리 방식(인증, 공유 비밀, 통신 등)에 영향을 미칠 수 있는 초기 설계 결정에 참여해야 합니다.

마무리

모든 보안 전문가들은 매우 바쁩니다. 너무 많은 경고가 발생하는데 하루는 너무 짧습니다. 모든 경고에 대응할 수는 없더라도, 보안 운영 센터(SOC) 팀 구성원들은 조직의 임무가 무엇인지, 핵심 자산이 어디에 있는지, 그리고 끊임없이 진화하는 위협 환경 속에서 무엇을 경계해야 하는지 이해해야 합니다. 개발 팀과 협력함으로써 우리는 각자의 조직을 보호하고 개발 수명 주기 전반에 보안을 내재화할 수 있습니다.