데브옵스 파이프라인이 공격을 받는 이유와 대처 방안

2. 적절한 툴과 컨트롤을 사용하라

엔소노는 개발자가 적절한 결정을 내리고 이를 보호하는 다양한 보안 컨트롤을 마련했다. 예를 들어, 다중인증을 도입해 외부자가 데브옵스 파이프라인에 액세스하지 못하도록 했다. 또한 개발자가 이미 검토되고 승인된 코드를 선택할 수 있도록 자체 코드 라이브러리를 사용한다. 배포한 모든 것을 최신 상태로 유지하는 시스템 패치 전담팀도 마련했다. 고처노어는 “환경 전체를 주기적으로 스캔해 취약점을 찾는다”라고 설명했다.

놓치고 지나치는 개발 파이프라인을 통제하기 위해 다른 방법을 사용하기도 한다. 컨설팅업체 캡제미니 아메리카(Capgemini Americas)의 데브옵스 아키텍트 벤키 첸나프라가다에 따르면, 기업은 비생산 시연 환경과 생산을 위한 별도의 파이프라인을 구축하고 2가지 시스템에 액세스하는 직원을 제한해야 한다. 기업은 액세스를 추가로 차단하기 위해 액티브 디렉토리(Active Directory)나 LDAP(Lightweight Directory Access Protocol)와 같은 기업용 액세스 관리 시스템을 사용한다. 

많은 기업이 소프트웨어 개발팀을 위한 별도의 사용자 데이터베이스를 운영하거나 내장된 사용자 관리 툴을 사용한다. 별도의 시스템을 확보하는 쪽이 훨씬 쉽다. 첸나프라가다는 “예를 들어 엑티브 디렉토리나 LDAP를 통합할 때는 보안 감사를 실시해야 한다. 일부 엔지니어는 설치를 적절히 하지 않은 것을 감추기 위해 보안 감사를 우회하고 싶을 수 있다”라고 말했다.

역할 기반 액세스는 개발자가 번거롭게 여기는 대표적인 컨트롤이다. 첸나프라가다는 “완전한 액세스를 제공하고 사용자 그룹 및 역할을 생성하지 않는 것은 언제나 쉽지만, 잘못된 관행이다”라고 지적했다. 

또한 기업은 오픈소스 라이브러리를 포함해 소프트웨어에 적용되는 모든 구성요소를 신중하게 추적해야 한다. 첸나프라가다는 “개발자는 소프트웨어에 오픈소스 코드를 포함하는 경향이 있으나 오픈소스 코드에는 버그와 보안 취약점이 있을 수 있다”라고 말했다. 외부 라이브러리는 보안 스캔과 코드 검토를 반드시 거쳐야 하며, 인증된 의존성만 사용하도록 제한해야 한다.

라이브러리뿐 아니라 다른 버전의 운영체제나 플러그인도 개발자가 사용하려고 하는 매력적인 툴이다. 대표적으로 리눅스에는 수백만 가지의 배포판이 있으며, 오픈소스 자동화 서버이자 인기 개발툴인 젠킨스는 다양한 플러그인을 제공한다. 첸나프라가다는 “기업이 사용하는 버전은 보안이 강화된 최신 상태여야 한다. 또 공격자는 시스템을 장악할 수 있는 플러그인에 악성코드를 심을 수 있으므로 플러그인도 매우 취약할 수 있다”라고 조언했다. 

기업이 사용할 수 있는 보안 컨트롤과 프로세스는 다양하다. 비용이 많이 들지 않고 오버헤드가 너무 많이 발생하지도 않는다. 다만 신중한 계획 또는 훈련이 필요하다. 보안업체 이뮤니웹(ImmuniWeb) CEO 리아 롤로첸코는 “AWS는 내장형 보안 컨트롤 및 툴을 저렴하거나 심지어 무료로 제공한다. 하지만 많은 사람이 이런 사실을 모르거나, 필요성을 느끼지 못하거나, 자세히 조사하고 활용하기가 너무 어렵다는 이유로 사용하지 않는다”라고 말했다.

클라우드를 활용하면 지속적인 보안 모니터링 및 사고 대응과 같은 툴을 더 쉽게 배포할 수 있다. 롤로첸코는 “의심스러운 활동을 감지하고 즉시 차단하며 깨끗한 이미지로 대체해 오프라인 상태 없이 운영을 지속할 수 있다. 이처럼 클라우드는 지속적인 보안 모니터링과 사고 대응을 자동화하는 기회를 제공하지만, 이를 활용하는 사람이 없다”라고 지적했다.

3. SBOM을 요청하되 취약점도 점검하라

많은 기업이 SBOM(Software Bill of Materials) 관리를 추진하고 있다. 2021년 5월, 미국 바이든 행정부는 소프트웨어 제공업체가 연방 정부에 소프트웨어에 대한 SBOM을 제출하도록 행정 명령을 내렸다. 이에 따라 CNCF(Cloud Native Computing Foundation)는 모든 소프트웨어 제공업체가 의존성에 대한 명확하고 직접적인 링크와 함께 가급적 SBOM을 제공하는 것을 권장하는 모범 사례 백서를 공개했다. 

SBOM은 기업이 취약한 구성요소의 인스턴스를 찾는 데 도움이 된다. 예컨대 Log4j는 2021년 12월 패치되었지만, 현재까지 전체 다운로드의 40%는 여전히 취약한 버전이었다. 

IEEE(Institute of Electrical and Electronics Engineers)의 사이버보안 전략가 케인 맥글래드리는 “구매한 빵 옆에 재료 목록을 기입한 것과 같다. 소프트웨어 구성요소에 대한 목록이 있으면 기업은 해당 정보에 기초해 위험 결정을 내릴 수 있다”라고 설명했다. 앞으로 이런 목록을 원하는 기업이 늘어날 것이므로 맥글래드리는 미래지향적인 소프트웨어 제공업체가 SBOM 관리를 본격화할 것이며, 나아가 소프트웨어의 작동방식에 대한 정보도 제공해야 한다고 조언했다.

맥글래드리는 “소프트웨어 제공업체가 소프트웨어의 정상적인 동작에 대한 목록을 제공하면 ‘이 소프트웨어의 이런 부분이 허용되지 않은 서버에 연결하고 있기 때문에 이상하게 작동하고 있다’라고 원인을 파악할 수 있다”라고 설명했다.

SBOM 의무화와는 별개로 기업은 소프트웨어의 알려진 취약점과 발생할 수 있는 다른 보안 문제를 점검해야 한다. 보안업체 NTT 애플리케이션 시큐리티(NTT Application Security)의 레이 켈리에 따르면, 이제 모든 주요 점검 소프트웨어가 취약한 Log4j 패키지를 점검한다. 하지만 점검 소프트웨어를 사용하는 기업은 드물다. 켈리는 “2개월 전에 패치가 제공됐지만 기업은 여전히 오래된 버전의 Log4j를 사용한다. 코드 보안과 관련해 기업이 얼마나 뒤처져 있는지 알 수 있다”라고 지적했다.
editor@itworld.co.kr