성공적인 데브섹옵스를 위한 3가지 보안 베스트 프랙티스

베테랑 보안 전문가 섀넌 리츠가 IT 개발자 및 운영자와 함께 보안을 논의할 목적으로 ‘데브섹옵스(DevSecOps)’라는 용어를 처음 사용한 지 10년이 넘었다. 그 이후로 보안은 얼마나 발전했을까? 오늘날 데브섹옵스팀은 프로덕션 환경에 기술을 빠르고 안전하게 출시하는 데 필요한 문화와 관행, 도구를 충분히 갖추고 있을까?
 

최근 발표된 SANS의 데브섹옵스 설문조사(SANS DevSecOps Survey)는 주목할 만한 결과를 보여준다. 전체 응답자의 50% 이상은 심각한 보안 위험과 취약점을 7일 이내에 해결했다고 답했다. 하지만 프로덕션 환경에 시스템 변경 사항을 매주 배포한다고 밝힌 응답자는 전체의 약 30%에 불과했으며, 보안 취약점을 매주 평가/테스트한다고 답한 비율은 20%에 그쳤다. 가장 많이 채택된 데브섹옵스 관행은 자동화(61%)였으며, 지속적 통합(Continuous Integration, CI)이 뒤를 이었다(50%). 여전히 많은 조직이 성숙한 보안과 지속적 배포를 위해 고군분투하고 있는 것으로 나타났다. 

보안 베스트 프랙티스 3가지

많은 기술 리더와 데브섹옵스팀이 어떤 보안 관행을 우선순위에 둘지 결정하는 데 어려움을 겪는다. SANS의 설문조사에서는 응답자 50% 이상이 유용하다고 평가한 26개의 보안 테스트 관행 및 도구와 8가지 보안 테스트 자동화 도구에 관한 조사 결과를 확인할 수 있는데, 모든 도구를 통틀어 75% 이상의 코드베이스에 보안 테스트 자동화 도구를 사용하고 있는 조직은 30% 미만인 것으로 나타났다.

데브섹옵스 관행은 매우 다양하지만, 여러 보안 전문가는 일관된 메시지를 강조했다. 사이버보안 업체 에어스톤(Aerstone) CEO 프랭크 슈거는 “나중에 보안을 끼워 맞추려 하지 말고 처음부터 보안을 함께 구축해야 한다”라면서, “요구 사항 프로세스를 잘 수행하려면 기능적 요건뿐 아니라 보안 요건도 포함해야 한다”라고 말했다. 

접근 권한 관리 솔루션 업체 비리티브(Britive)의 CTO 존 모튼은 “시프트 레프트 전략을 도입하려면 데브섹옵스 노력에 방해되지 않고 마찰이 없어야 한다. 모든 실무자는 정책과 툴링에서 보안 가드레일과 보안 장애물을 구분해야 한다”라고 조언했다.

어떤 보안 관행에 집중할지 결정하려면 비즈니스 목표, 위험, 개발 속도, 기술 스택, 컴플라이언스 요구 사항 등을 고려해야 한다. 보안을 소프트웨어 개발 수명 주기와 데브섹옵스 관행에 통합하려는 팀을 위한 3가지 베스트 프랙티스를 살펴본다. 

1. 보안 우선 API 전략

아마존 설립자 제프 베이조스가 ‘베이조스 API 규정(The Bezos API Mandate)’을 만든 이후 개발팀은 API 우선 전략의 중요성을 알게 됐다. 많은 개발팀이 내부용 API를 구축한다. 마이크로서비스 아키텍처를 사용하는 팀은 API 게이트웨이를 통해 개발 및 운영 API 기능을 확장하고 지원한다. API는 데이터 제품 및 비즈니스 모델 구축의 근간이며, 차세대 개방형 ML과 LLM을 가능하게 한다. 

API 보안 솔루션 업체 월람(Wallarm)의 CEO 이반 노비코프는 “API 사양과 계약 정의부터 수많은 API 관리까지 이제 API는 데브옵스의 핵심이 됐다”라고 언급했다. 

월람의 API 위협 통계 보고서(API Threat Stats Report)에 따르면, 2023년 3분기 식별된 API 취약점은 총 239개이며, 이 가운데 33%가 권한 부여, 인증, 액세스 제어와 연관돼 있었다. 노비코프는 “데브옵스에서 API 보안의 중요성이 점점 더 커지고 있다. 안전한 소프트웨어 개발 프로세스를 보장하는 한편 원하는 비즈니스 성과를 달성하는 데 중요한 측면이다“라고 설명했다. 

해당 보고서에 의하면 주요 API 보안 위험은 인젝션, 인증 결함, 사이트 간 문제, API 유출, 액세스 제어 중단 등이 대표적이다. 

API 베스트 프랙티스를 채택했지만, 여전히 시프트 레프트 보안으로 완전히 전환하지 않고 API 개발 과정에 보안 관행을 적용하지도 않는 여전히 조직이 많다. 대규모 데브섹옵스팀이 API와 마이크로서비스를 개발하는 규모와 속도를 고려한다면 보안 우선 API 전략으로 업그레이드할 필요가 있다. 

2. 코드 스캔 자동화

코드에서 취약점을 스캔하는 작업은 한때 수작업으로 이뤄졌다. 주로 페어 프로그래밍으로 수행되거나 개발 과정의 후반 단계에서 진행됐다. 현재는 SAST(Static Application Security Testing) 도구라고도 하는 정적 코드 분석 도구가 사용된다. 

사이버보안 업체 딥 인스팅트(Deep Instinct)의 CIO 칼 프로겟은 오늘날 애플리케이션은 단순한 코드 그 이상이라고 강조했다. 프로겟은 “파일, 데이터, 코드, 구성 요소가 데브옵스 저장소에서 수집되고 사용되기 때문에 악성 콘텐츠가 있는지 검사해야 한다. 보안 스캔 서비스는 테스트용 릴리즈 전, 프로덕션 환경 또는 고객에게 출시하기 전 그리고 CI/CD 파이프라인의 전 과정에서 쉽게 사용할 수 있어야 한다. 위협을 조기에 발견할수록 수정하기 쉽고, 전체 파이프라인에 미치는 영향도 줄어든다”라고 덧붙였다. 

코드 스캔 도구는 흔하지만 심각한 보안 위험 중 하나인 ‘개발자의 실수’를 잡아낼 수 있다. 세일즈포스용 데브옵스 플랫폼을 제공하는 코파도(Copado)의 보안 및 정보 기술 책임자 카일 토베너는 “지난 수년간 기밀 소스코드가 실수로 유출되면서 많은 보안 사고가 발생했다. 데브옵스 파이프라인에서 기밀 스캔 기능을 활용하면 비밀번호와 API 키 등의 기밀 유출을 방지할 수 있다”라고 조언했다.

많은 기업이 비즈니스에서 생성형 AI를 사용하고 코파일럿 및 대규모 언어 모델이 소프트웨어 개발에 활용되면서 코드 스캔은 더욱 중요해질 전망이다. 데브섹옵스팀은 생성형 AI 기능을 지원하기 위해 지속적인 테스트 관행을 확장할 필요가 있다.

EDB의 CISO 댄 가르시아는 SAST가 배포 전 취약점 식별에 유용하지만, 동적 애플리케이션 보안 테스트(Dynamic Application Security Testing, DAST)도 추가하는 것이 좋다며 “DAST는 위협 행위자의 자동화 기술을 실행하는 런타임 환경을 테스트한다. 즉, 플랫폼 확장에 따라 팀이 테스트 범위를 넓힐 수 있도록 해준다”라고 덧붙였다.  

3. 데이터 관찰가능성 관행 표준화 

필자는 20년 가까이 기술, 데이터, 디지털 트랜스포메이션 베스트 프랙티스에 대한 글을 쓰고 있다. 스타트업 CTO로서 배운 것을 공유하기 위해 시작한 블로그는 이제 1,000번째 게시글을 맞이했다. 당시 필자는 개발자이자 사이트 신뢰성 엔지니어(SRE)였으며, IT 운영까지 맡고 있었다. 프로덕션 환경에서 발생한 문제를 해결하고 근본 원인을 파악하며, 애플리케이션 문제를 어떻게 해결할지 결정해야 했다. 당시에는 애플리케이션 로깅이 관찰가능성(observability) 데이터를 얻는 가장 쉬운 방법이었지만, 오늘날에는 개발자와 SRE가 프로덕션 환경에서 애플리케이션 성능을 파악할 수 있는 도구와 데이터 소스가 폭발적으로 증가하고 있다. 

관찰가능성 솔루션 제공업체 옵저브(Observe)의 CEO 제레미 버튼은 오늘날의 과제가 바로 여기에 있다고 지적했다. 버튼은 “최신 분산 애플리케이션 문제를 해결하는 데 사용되는 대부분 도구는 사일로화돼 있다. 원래는 로그 분석, 메트릭 모니터링 또는 추적 시각화용이었으므로 현재의 방대한 데이터양을 처리하도록 설계되지 않았다”라고 설명했다. 

애플리케이션 관찰가능성, 안정성 향상, 성능 개선이 목표인 데브섹옵스팀은 많은 도구와 사례를 찾을 수 있다. 관찰가능성 솔루션에는 애플리케이션 모니터링 도구, AI옵스 플랫폼, 서비스 수준 목표 관리용 SRE 도구 등이 대표적이다. 

데브섹옵스팀은 2가지 영역에서 관찰가능성 범위를 확장해야 한다. 우선 애플리케이션, 통합, 클라우드 인프라를 포함한 전체 스택을 포괄하는 보안 관찰가능성(security observability)이다. 보안 관찰가능성은 네트워크 로그, 엔드포인트 보안 솔루션, SIEM(Security Information and Event Management) 플랫폼 등 다양한 보안 도구와 시스템에서 데이터를 수집한 다음, 이들 데이터를 사용해 잠재 위협에 관한 인사이트를 얻는 것을 포괄하는 개념이다. 

또한 데브섹옵스는 관찰가능성 관행을 데이터옵스(DataOps) 및 ML옵스(MLOps) 영역으로 확장해야 한다. 이런 영역의 문제가 안정성, 성능, 보안에도 영향을 미칠 수 있기 때문이다. 

데이터 관찰가능성 플랫폼 제공업체 액셀데이터(Acceldata)의 CEO 로히트 초우다리는 “시프트 레프트 보안으로 전환해 데이터 관찰가능성을 확보한다는 것은 초기 단계에서 데이터 문제를 선제적으로 해결하고 잠재적 영향과 비용을 최소화한다는 의미다. 아울러 사용자가 소비하는 데이터의 신뢰성과 정확성뿐 아니라 다운스트림 프로세스 및 의사결정의 무결성과 신뢰성을 보장할 수 있다”라고 설명했다. 

ML옵스는 ML 모델을 위한 배포 파이프라인이다. 애플리케이션의 CI/CD, 클라우드 아키텍처의 IaC(Infrastructure-as-Code)와 유사하다. ML옵스에 관찰가능성을 도입하면 위협 행위자가 파이프라인을 트리거하거나 데이터를 조작하는 등의 보안 문제를 추적할 수 있다. 

사이어보안 업체 넷SPI(NetSPI)의 전무 필 모리스는 “전통적으로 데브옵스라는 용어를 구성해 온 작업, 프로세스, 변경 제어가 ML옵스의 목표와 패러다임을 고려하지 않는다”라면서 데브옵스를 ML옵스 관행으로 확장하라고 조언했다. 

이때 핵심은 표준이다. 모든 애플리케이션, 데이터 파이프라인, ML 모델이 서로 다른 관찰가능성 명명 규칙, 관행, 도구를 사용한다면 SRE와 SOC(Security Operation Center)가 보안 문제를 신속하게 식별하고 해결하기 어렵기 때문이다. 

3가지 베스트 프랙티스 그 이상

여기까지 데브섹옵스팀에 영향을 미칠 가능성이 높고 지속적인 투자와 표준을 통해 보안 위험 상당수를 해결할 수 있는 3가지 베스트 프랙티스를 살펴봤다. 

이뿐 아니라 SANS 보고서는 서드파티 침투 테스트, 보안 교육, WAF(Web Application Firewall) 구축 등 IT 조직에서 이미 보편화했어야 할 다른 애플리케이션 보안 관행도 강조했다. 컨테이너 보안 스캔 및 클라우드 네이티브 애플리케이션 보안 플랫폼 도입 등도 최신 아키텍처에서 데브섹옵스를 구현할 때 중요하다.

어떤 보안 영역에 집중할지 선택하는 일이 점점 더 어려워지고 있다. 하지만 IT가 보안을 소홀히 하면 더 큰 위험이 따른다. 따라서 IT는 지속적인 데브섹옵스 보안 관행에 우선순위를 둬야 한다.
editor@itworld.co.kr