2021.07.19

CI/CD 파이프라인을 보호하는 6가지 모범 사례

Ax Sharma | CSO
최근 지속적 통합/지속적 제공(Continuous Integration/ Continuous Delivery, CI/CD) 파이프라인과 개발자 도구의 약점을 이용하는 사이버 공격이 발생하면서 개발자 인프라의 보안을 강화할 필요성이 대두됐다. 특히 코드코브(Codecov) 공급망 공격은 아무리 안전한 환경이라 해도 CI/CD 환경 변수에 기밀을 저장하면 안 된다는 강력한 경고다.
 
ⓒ Getty Images Bank

코드코브 공격자들은 수많은 개발자가 사용하는 배시(Bash) 업로더를 침해하는 방법으로, 2개월 동안 발각되지 않은 채로 고객 환경에서 로그인 정보, 키, API 토큰을 빼냈다. 게다가 제한된 고객 네트워크 수백 개도 침해한 것으로 알려졌다.  

또한 젠킨스(Jenkins), 깃허브 액션(GitHub Actions)과 같은 자동화 도구와 클라우드 네이티브 컨테이너 환경을 대상으로 한 공격도 발생하고 있어 기업은 이런 도구를 위한 효과적인 방어를 구축해야 한다. 이번 기사에서는 CI/CD 파이프라인을 안전하게 보호하기 위한 몇 가지 모범 사례를 소개한다.

1. CI/CD 환경에 기밀을 저장하지 말 것
코드코브의 공급망 공격이 큰 성공을 거두게 된 원인은 공격자들이 유출한 환경 변수에 비밀번호, 토큰, 키를 포함한 하드코딩된 기밀 정보가 포함됐다는 데 있다. 공격자들은 이런 인증 정보 중 일부를 사용해 회사의 비공개 깃허브 리포지토리에도 접근했는데, 기밀로 유지되어야 하는 데이터가 포함된 이와 같은 비공개 리포지토리에서 추가적인 데이터 유출이 발생할 수 있었다.
 
해시코프(HashiCorp), 트윌리오(Twilio), 래피드7(Rapid7), 먼데이닷컴(Monday.com)을 비롯한 코드코브 고객은 이번 공급망 공격의 영향을 밝히지 않았지만, 현재까지 알려진 가장 중대한 데이터 유출은 일본의 전자상거래 대기업인 머카리(Mercar)에서 발생했다. 

코드코브 공격 이후 머카리 고객의 재무, 거래, 비즈니스 파트너, 회사 직원, 계약 업체 및 다양한 개체에 관한 2만 7,000개 이상의 레코드가 승인되지 않은 외부 행위자에 노출됐다.

이런 각각의 공격은 코드코브 침해로부터 시작됐을 가능성이 높다. 또한 일각에서는 애초에 고객 재무 기록과 같은 개인 식별 정보(PII)가 비공개 깃허브 리포지토리에 저장된 이유에 대한 의문도 제기됐다.

CI/CD 환경에 저장된 해시코프의 GPG 비공개 키와 관련해서도 비슷한 우려가 있다. GPG는 해시코프에 의해 게시되는 소프트웨어 릴리스의 서명 및 검증에 사용된 비밀 키다. 공격자는 유출된 키가 해지되기 전에 키를 악용해 악성 소프트웨어 릴리스에 해시코프의 서명을 집어넣었을 수 있다. 한 개발자는 트위터에서 “볼트(Vault)를 만든 해시코프가 자신의 서명 키를 ENV로 저장한 이유에 대해서는 왜 아무도 이야기하지 않는가? 나도 그것보다는 낫다”라고 말했다. 

조직은 CI/CD 도구, 환경 변수, 비공개 깃허브 리포지토리에 저장할 기밀 정보에 대해 다시 생각해야 한다. 애플리케이션의 동작을 위해 이런 위치에 인증 정보 또는 토큰을 저장해야 한다면 최선은 해당 작업을 수행하는 데 필요한 최소의 권한을 가진 계정이나 리소스에 인증 정보를 저장하는 것이다. 보통 최소 권한의 원칙이라고 한다. 이렇게 하면 예기치 못한 공격에서 기밀이 노출되더라도 피해를 억제할 수 있다.

2. 자동화된 풀 요청과 예약된 작업을 철저히 조사
깃허브 액션과 같은 CI/CD 자동화 도구는 개발자가 예를 들어 들어오는 풀 요청을 자동으로 심사하고 처리하는 등의 코드 리포지토리에 대한 예약된 작업을 설정할 수 있게 해준다. 그런데 오픈소스 프로젝트에 풀 요청을 보내는 기여자가 악의적인 의도를 갖고 있다면 어떻게 될까?

2021년 4월, 한 공격자들이 깃허브 인프라를 사용해 암호화폐를 채굴할 목적으로 수백 개의 리포지토리에 자동화된 풀 요청을 보내는 방식으로 깃허브 액션을 악용한 사건이 발생했다. 이 대규모 공격은 앞선 2월 깃허브 액션의 '결함'이 보고된 이후에 발생했다.

최소한 이런 풀 요청은 깃허브의 서버를 악용해 암호화폐를 채굴하거나 공격자의 악성코드를 실행할 수 있다. 프로젝트 소유자가 주의를 기울이지 않고 이러한 풀 요청을 병합할 경우 리포지토리, 그리고 더 폭넓은 소프트웨어 공급망에 악성코드가 유입된다. 깃랩(GitLab)도 지난 5월 자사 플랫폼에서 공격자들이 신규 계정에 할당되는 '무료 시간'을 악용한 비슷한 크립토마이닝(cryptomining) 공격이 발생했음을 보고했다.

깃허브 액션, 깃랩과 같은 CI/CD 자동화 도구의 속성 자체가 주요 작업을 손쉽게 자동화하는 것이므로 이를 보호하는 것은 그만큼 어렵다. 의도한 기능이 보안 결함이 되고 위협 행위자들에 의해 악용된다.

깃허브는 최근 크립토마이닝 공격자에 의한 액션 플랫폼 악용을 막는 새로운 기능을 발표했다. 깃허브 제품 관리자인 크리스 패터슨은 “첫 기여자의 풀 요청은 액션 워크플로우가 실행되기 전에 쓰기 접근 권한이 있는 리포지토리 협력자의 수동 승인이 필요하다. 첫 기여자는 풀 요청을 열면 관리자가 액션 워크플로우를 승인해야 하며 그 이후에 워크플로우 실행이 가능하다는 메시지가 표시된다”라고 설명했다.

3. 클라우드 네이티브 컨테이너를 강화하고 정기적으로 감사
프로덕션 컨테이너를 적절히 구성하고 일반적인 공격 벡터에 대비해 강화하는 것과 같은 표준적인 모범 사례를 따르는 것이 무엇보다 효과적이다. 여기에는 파이프라인 구성 보호도 포함된다.

그러나 단순한 구성 오류가 사람의 눈에 잘 띄지 않는 경우도 있다. 관건은 도커 기반 환경에 취약점이 없는지 확인하는 것이다. 컨테이너를 대상으로 정기적으로 취약점 보안 감사를 수행하고 컨테이너 이미지와 매니페스트 파일을 스캔해 일반적인 보안 문제를 찾는 것이 여전히 도움이 되는 이유다.

이 과정의 대부분을 자동화할 수 있는 신뢰할 만한 클라우드 네이티브 컨테이너 보안 솔루션에 투자하는 것이 좋다. 매년 보고되는 방대한 수의 보안 취약점을 한 사람이 일일이 추적하기란 사실상 불가능하기 때문이다.

또한 기업에서 쿠버네티스 프레임워크와 도커 컨테이너를 도입해 애플리케이션을 배포할 때 웹 애플리케이션 방화벽이 내장된 컨테이너 보안 솔루션은 수상한 네트워크 트래픽을 초기에 탐지해 차단할 수 있다. 이는 공격자가 컨테이너에 침투해 초기 접근 권한을 얻더라도 더 큰 침해를 방지하는 데 효과가 있다.

4. 심층 코드 스캔을 통합해 코드 품질 검사를 자동화
코드 커밋이 프로덕션에 도달하기 전에 코드 품질 문제, 보안 취약점, 그리고 메모리 누출이나 경합 조건과 같은 버그를 자동으로 찾는 도구를 사용하는 것은 CI/CD 파이프라인을 시작부터 보호하는 효과적인 전략이다. 

초점은 사이버 공격을 막는 데 있지만 악의없는 버그도 공격 못지않게 광범위한 영향을 미칠 수 있다. 최근 전 세계 주요 사이트의 중단을 초래한 패스틀리(Fastly) 사고가 이를 입증한다.

깃허브 코드 스캐너 또는 소나타입(Sonatype)의 리프트(Lift)와 같은 솔루션은 기존 코딩 워크플로우에 매끄럽게 통합되며, 비용 없이 개발자에게 기본적인 안전 장치를 제공한다. 궁극적으로 조직의 목표는 개발자가 최선의 작업을 할 수 있도록 지원하면서 애플리케이션에 버그 또는 보안 취약점의 유입을 최대한 차단하는 것이다. 이 과정에서 개발 팀과 보안 팀 간의 마찰도 최소화해야 한다. 개발자가 코딩하는 중에 놓쳤을 가능성이 있는 부분을 실시간으로 알려주는 기능이 있으면 모두의 시간을 절약하고 전체적인 CI/CD 워크플로우를 시작부터 보호할 수 있다.

5. 최신 CI/CD 도구 취약점에 대한 빠른 패치
2021년 3월, 공격자들이 z0Miner라는 크립토마이닝 봇넷으로 취약한 젠킨스 및 일래스틱서치(ElasticSearch) 서버에서 모네로(Monero) 암호화폐를 채굴했다. 공격자들은 인터넷에 접한 서버의 원격 코드 실행(RCE) 취약점을 악용해 인프라를 감염시키고 점유해 악의적인 활동에 이용하려고 했다.

마찬가지로, 지난해 보고된 바와 같이 젠킨스 서버 역시 공격자에 의해 악용되어 빠르게 분산 서비스 거부(DDoS)를 유발할 수 있다. 이는 CVE-2020-2100이라는 코드로 분류되는 UDP 증폭 반사 DoS 취약점에 따른 공격으로, 젠킨스 v2.219 미만, 그리고 젠킨스 LTS 2.204.1 미만의 버전에 영향을 미친다.

자동화 도구와 파이프라인에서 이와 같은 심각한 취약점이 발견되는 즉시 최대한 빠르게 패치하는 것은 CI/CD 인프라의 보안을 확보하기 위해 여전히 중요하다.

6. 업데이트를 적용하기 전에 무결성 검사
최신 업데이트와 패치 적용은 좋은 조언이지만, 받는 업데이트가 변조되지 않았음을 어떻게 확신할 수 있을까? 수십년 동안 보안 전문가들이 신조로 삼아온 '부단히 최신 버전으로 업데이트하라'는 조언은 솔라윈즈(SolarWinds) 공급망 공격 이후 흔들리고 있다.

솔라윈즈 사고에서 공격자들은 오리온(Orion) IT 제품에 잠입한 악성 업데이트를 통해 1만 8,000곳 이상의 고객사에 악성코드를 배포할 수 있었다. 또한 패스워드스테이트(Passwordstate) 비밀번호 관리자의 '인플레이스 업그레이드 기능'이 침해되어 패스워드스테이트 사용자들에게 악성 업데이트가 배포되는 사건도 발생했다. 따라서 제품 업데이트를 무작정 적용하는 것도 피해야 한다.

코드코브 사례에서는 간단한 무결성 검사가 2개월 동안 이어진 침해의 발견으로 이어졌다. 한 고객이 서버에 호스팅된 배시 업로더의 체크섬(해시)과 코드코브의 깃허브 리포지토리에 등록된 정상 체크섬이 일치하지 않는 것을 인지하고 즉시 코드코브에 연락해 문제를 수정하도록 했다.

따라서 업데이트와 패치의 무결성을 보장하고 다운로드를 검사해서 교묘한 공급망 공격을 차단할 수 있는 심층 방어(defense in depth) 접근 방법이 필요하다. editor@itworld.co.kr 


2021.07.19

CI/CD 파이프라인을 보호하는 6가지 모범 사례

Ax Sharma | CSO
최근 지속적 통합/지속적 제공(Continuous Integration/ Continuous Delivery, CI/CD) 파이프라인과 개발자 도구의 약점을 이용하는 사이버 공격이 발생하면서 개발자 인프라의 보안을 강화할 필요성이 대두됐다. 특히 코드코브(Codecov) 공급망 공격은 아무리 안전한 환경이라 해도 CI/CD 환경 변수에 기밀을 저장하면 안 된다는 강력한 경고다.
 
ⓒ Getty Images Bank

코드코브 공격자들은 수많은 개발자가 사용하는 배시(Bash) 업로더를 침해하는 방법으로, 2개월 동안 발각되지 않은 채로 고객 환경에서 로그인 정보, 키, API 토큰을 빼냈다. 게다가 제한된 고객 네트워크 수백 개도 침해한 것으로 알려졌다.  

또한 젠킨스(Jenkins), 깃허브 액션(GitHub Actions)과 같은 자동화 도구와 클라우드 네이티브 컨테이너 환경을 대상으로 한 공격도 발생하고 있어 기업은 이런 도구를 위한 효과적인 방어를 구축해야 한다. 이번 기사에서는 CI/CD 파이프라인을 안전하게 보호하기 위한 몇 가지 모범 사례를 소개한다.

1. CI/CD 환경에 기밀을 저장하지 말 것
코드코브의 공급망 공격이 큰 성공을 거두게 된 원인은 공격자들이 유출한 환경 변수에 비밀번호, 토큰, 키를 포함한 하드코딩된 기밀 정보가 포함됐다는 데 있다. 공격자들은 이런 인증 정보 중 일부를 사용해 회사의 비공개 깃허브 리포지토리에도 접근했는데, 기밀로 유지되어야 하는 데이터가 포함된 이와 같은 비공개 리포지토리에서 추가적인 데이터 유출이 발생할 수 있었다.
 
해시코프(HashiCorp), 트윌리오(Twilio), 래피드7(Rapid7), 먼데이닷컴(Monday.com)을 비롯한 코드코브 고객은 이번 공급망 공격의 영향을 밝히지 않았지만, 현재까지 알려진 가장 중대한 데이터 유출은 일본의 전자상거래 대기업인 머카리(Mercar)에서 발생했다. 

코드코브 공격 이후 머카리 고객의 재무, 거래, 비즈니스 파트너, 회사 직원, 계약 업체 및 다양한 개체에 관한 2만 7,000개 이상의 레코드가 승인되지 않은 외부 행위자에 노출됐다.

이런 각각의 공격은 코드코브 침해로부터 시작됐을 가능성이 높다. 또한 일각에서는 애초에 고객 재무 기록과 같은 개인 식별 정보(PII)가 비공개 깃허브 리포지토리에 저장된 이유에 대한 의문도 제기됐다.

CI/CD 환경에 저장된 해시코프의 GPG 비공개 키와 관련해서도 비슷한 우려가 있다. GPG는 해시코프에 의해 게시되는 소프트웨어 릴리스의 서명 및 검증에 사용된 비밀 키다. 공격자는 유출된 키가 해지되기 전에 키를 악용해 악성 소프트웨어 릴리스에 해시코프의 서명을 집어넣었을 수 있다. 한 개발자는 트위터에서 “볼트(Vault)를 만든 해시코프가 자신의 서명 키를 ENV로 저장한 이유에 대해서는 왜 아무도 이야기하지 않는가? 나도 그것보다는 낫다”라고 말했다. 

조직은 CI/CD 도구, 환경 변수, 비공개 깃허브 리포지토리에 저장할 기밀 정보에 대해 다시 생각해야 한다. 애플리케이션의 동작을 위해 이런 위치에 인증 정보 또는 토큰을 저장해야 한다면 최선은 해당 작업을 수행하는 데 필요한 최소의 권한을 가진 계정이나 리소스에 인증 정보를 저장하는 것이다. 보통 최소 권한의 원칙이라고 한다. 이렇게 하면 예기치 못한 공격에서 기밀이 노출되더라도 피해를 억제할 수 있다.

2. 자동화된 풀 요청과 예약된 작업을 철저히 조사
깃허브 액션과 같은 CI/CD 자동화 도구는 개발자가 예를 들어 들어오는 풀 요청을 자동으로 심사하고 처리하는 등의 코드 리포지토리에 대한 예약된 작업을 설정할 수 있게 해준다. 그런데 오픈소스 프로젝트에 풀 요청을 보내는 기여자가 악의적인 의도를 갖고 있다면 어떻게 될까?

2021년 4월, 한 공격자들이 깃허브 인프라를 사용해 암호화폐를 채굴할 목적으로 수백 개의 리포지토리에 자동화된 풀 요청을 보내는 방식으로 깃허브 액션을 악용한 사건이 발생했다. 이 대규모 공격은 앞선 2월 깃허브 액션의 '결함'이 보고된 이후에 발생했다.

최소한 이런 풀 요청은 깃허브의 서버를 악용해 암호화폐를 채굴하거나 공격자의 악성코드를 실행할 수 있다. 프로젝트 소유자가 주의를 기울이지 않고 이러한 풀 요청을 병합할 경우 리포지토리, 그리고 더 폭넓은 소프트웨어 공급망에 악성코드가 유입된다. 깃랩(GitLab)도 지난 5월 자사 플랫폼에서 공격자들이 신규 계정에 할당되는 '무료 시간'을 악용한 비슷한 크립토마이닝(cryptomining) 공격이 발생했음을 보고했다.

깃허브 액션, 깃랩과 같은 CI/CD 자동화 도구의 속성 자체가 주요 작업을 손쉽게 자동화하는 것이므로 이를 보호하는 것은 그만큼 어렵다. 의도한 기능이 보안 결함이 되고 위협 행위자들에 의해 악용된다.

깃허브는 최근 크립토마이닝 공격자에 의한 액션 플랫폼 악용을 막는 새로운 기능을 발표했다. 깃허브 제품 관리자인 크리스 패터슨은 “첫 기여자의 풀 요청은 액션 워크플로우가 실행되기 전에 쓰기 접근 권한이 있는 리포지토리 협력자의 수동 승인이 필요하다. 첫 기여자는 풀 요청을 열면 관리자가 액션 워크플로우를 승인해야 하며 그 이후에 워크플로우 실행이 가능하다는 메시지가 표시된다”라고 설명했다.

3. 클라우드 네이티브 컨테이너를 강화하고 정기적으로 감사
프로덕션 컨테이너를 적절히 구성하고 일반적인 공격 벡터에 대비해 강화하는 것과 같은 표준적인 모범 사례를 따르는 것이 무엇보다 효과적이다. 여기에는 파이프라인 구성 보호도 포함된다.

그러나 단순한 구성 오류가 사람의 눈에 잘 띄지 않는 경우도 있다. 관건은 도커 기반 환경에 취약점이 없는지 확인하는 것이다. 컨테이너를 대상으로 정기적으로 취약점 보안 감사를 수행하고 컨테이너 이미지와 매니페스트 파일을 스캔해 일반적인 보안 문제를 찾는 것이 여전히 도움이 되는 이유다.

이 과정의 대부분을 자동화할 수 있는 신뢰할 만한 클라우드 네이티브 컨테이너 보안 솔루션에 투자하는 것이 좋다. 매년 보고되는 방대한 수의 보안 취약점을 한 사람이 일일이 추적하기란 사실상 불가능하기 때문이다.

또한 기업에서 쿠버네티스 프레임워크와 도커 컨테이너를 도입해 애플리케이션을 배포할 때 웹 애플리케이션 방화벽이 내장된 컨테이너 보안 솔루션은 수상한 네트워크 트래픽을 초기에 탐지해 차단할 수 있다. 이는 공격자가 컨테이너에 침투해 초기 접근 권한을 얻더라도 더 큰 침해를 방지하는 데 효과가 있다.

4. 심층 코드 스캔을 통합해 코드 품질 검사를 자동화
코드 커밋이 프로덕션에 도달하기 전에 코드 품질 문제, 보안 취약점, 그리고 메모리 누출이나 경합 조건과 같은 버그를 자동으로 찾는 도구를 사용하는 것은 CI/CD 파이프라인을 시작부터 보호하는 효과적인 전략이다. 

초점은 사이버 공격을 막는 데 있지만 악의없는 버그도 공격 못지않게 광범위한 영향을 미칠 수 있다. 최근 전 세계 주요 사이트의 중단을 초래한 패스틀리(Fastly) 사고가 이를 입증한다.

깃허브 코드 스캐너 또는 소나타입(Sonatype)의 리프트(Lift)와 같은 솔루션은 기존 코딩 워크플로우에 매끄럽게 통합되며, 비용 없이 개발자에게 기본적인 안전 장치를 제공한다. 궁극적으로 조직의 목표는 개발자가 최선의 작업을 할 수 있도록 지원하면서 애플리케이션에 버그 또는 보안 취약점의 유입을 최대한 차단하는 것이다. 이 과정에서 개발 팀과 보안 팀 간의 마찰도 최소화해야 한다. 개발자가 코딩하는 중에 놓쳤을 가능성이 있는 부분을 실시간으로 알려주는 기능이 있으면 모두의 시간을 절약하고 전체적인 CI/CD 워크플로우를 시작부터 보호할 수 있다.

5. 최신 CI/CD 도구 취약점에 대한 빠른 패치
2021년 3월, 공격자들이 z0Miner라는 크립토마이닝 봇넷으로 취약한 젠킨스 및 일래스틱서치(ElasticSearch) 서버에서 모네로(Monero) 암호화폐를 채굴했다. 공격자들은 인터넷에 접한 서버의 원격 코드 실행(RCE) 취약점을 악용해 인프라를 감염시키고 점유해 악의적인 활동에 이용하려고 했다.

마찬가지로, 지난해 보고된 바와 같이 젠킨스 서버 역시 공격자에 의해 악용되어 빠르게 분산 서비스 거부(DDoS)를 유발할 수 있다. 이는 CVE-2020-2100이라는 코드로 분류되는 UDP 증폭 반사 DoS 취약점에 따른 공격으로, 젠킨스 v2.219 미만, 그리고 젠킨스 LTS 2.204.1 미만의 버전에 영향을 미친다.

자동화 도구와 파이프라인에서 이와 같은 심각한 취약점이 발견되는 즉시 최대한 빠르게 패치하는 것은 CI/CD 인프라의 보안을 확보하기 위해 여전히 중요하다.

6. 업데이트를 적용하기 전에 무결성 검사
최신 업데이트와 패치 적용은 좋은 조언이지만, 받는 업데이트가 변조되지 않았음을 어떻게 확신할 수 있을까? 수십년 동안 보안 전문가들이 신조로 삼아온 '부단히 최신 버전으로 업데이트하라'는 조언은 솔라윈즈(SolarWinds) 공급망 공격 이후 흔들리고 있다.

솔라윈즈 사고에서 공격자들은 오리온(Orion) IT 제품에 잠입한 악성 업데이트를 통해 1만 8,000곳 이상의 고객사에 악성코드를 배포할 수 있었다. 또한 패스워드스테이트(Passwordstate) 비밀번호 관리자의 '인플레이스 업그레이드 기능'이 침해되어 패스워드스테이트 사용자들에게 악성 업데이트가 배포되는 사건도 발생했다. 따라서 제품 업데이트를 무작정 적용하는 것도 피해야 한다.

코드코브 사례에서는 간단한 무결성 검사가 2개월 동안 이어진 침해의 발견으로 이어졌다. 한 고객이 서버에 호스팅된 배시 업로더의 체크섬(해시)과 코드코브의 깃허브 리포지토리에 등록된 정상 체크섬이 일치하지 않는 것을 인지하고 즉시 코드코브에 연락해 문제를 수정하도록 했다.

따라서 업데이트와 패치의 무결성을 보장하고 다운로드를 검사해서 교묘한 공급망 공격을 차단할 수 있는 심층 방어(defense in depth) 접근 방법이 필요하다. editor@itworld.co.kr 


X