데브섹옵스(DevSecOps)는 개발(Dev), 보안(Sec), 운영(Ops)을 합친 말이다.
기존 널리 알려진 데브옵스(DevOps)에 ‘보안'(Sec)이 더해진 것이다. 데브옵스는 소프트웨어 개발 사이클과 배포·운영 사이클이 자연스럽게 연계됨으로써 개발에서 배포까지의 전 과정에 걸쳐 시간을 단축하고자 하는 취지에서 도입되었다.
데브옵스에 대한 오해 중의 하나는 개발자가 배포·운영까지 모두 담당하는 것으로 이해하는 것이다. 물론 이 역시 데브옵스 범주에 포함될 수는 있지만, 데브옵스의 진정한 의미는 소프트웨어 개발자와 IT 운영 전문가 간의 협업, 소통, 통합이 원활하게 이루어지도록 하는 것에서 찾을 수 있다.
ITSM
전통적인 방식에서의 IT 운영을 대표하는 것으로 ITSM(IT Service Management)을 들 수 있다. ITSM을 기반으로 하는 IT 운영 방식에서도 개발자와 IT 운영 전문가 간의 소통과 협업은 당연히 필요하다. 개발이 완료되어 배포 단계에 다다르면 개발자는 ITSM을 통해 배포를 위한 서버 요청 및 기타 운영에 필요한 제반 서비스를 요청한다. IT 서비스 지원이 필요할 때마다 개발자는 소위 ‘티켓’을 발부하고, IT 서비스 담당자는 이 티켓을 처리함으로써 배포 등 IT 운영 제반에 필요한 지원을 한다. 이러한 과정이 체계적으로 진행될 수 있도록 마련된 절차와 시스템이 ITSM이다.
티켓을 발부하고 이를 처리하는 과정에서 ITSM을 통한 협업이 이루어지기는 하나 개발과 운영이 물 흐르듯 연결되는 것이 아닌 ‘단절’이 있게 마련이다. 이를 극복하고자 나온 개념이 데브옵스다.
데브옵스, 핵심은 자동화
소프트웨어 개발은 코딩, 단위 빌드, 단위 테스트, 통합, 통합 테스트로 좀 더 세분화할 수 있다. 통합 테스트가 끝나면 배포 및 운영 단계로 넘어간다. IT 운영 서비스는 최종 통합 테스트 이후가 아닌 개발 단계에서도 필요하다. 통합 테스트를 위해 적정한 컴퓨팅 자원이 확보되어 있어야 할 뿐 아니라 개발 중인 상태에서도 개발 결과물을 임시로 배포하는 ‘스테이징’ 서버 할당 등 IT 운영 서비스는 늘 필요하다. 즉, 개발부터 최종 배포 운영 전 단계에서 IT 운영 서비스가 필요하다.
매번 ‘티켓팅’을 통해 IT 서비스를 받을 경우, 지연을 최소화하기 위해서는 미리 필요한 IT 자원 수요에 대한 정밀한 예측이 필요하다. 개발 단계에서는 정확한 수요 예측이 쉽지 않고, 따라서 필요 이상의 자원을 할당받는 등 효율적인 IT 자원 운용이 사실상 어렵다. 게다가, 한 번이라도 자원 배분이 늦어지는 경우가 발생하면 전반적인 개발 사이클에 영향을 미칠 수도 있다. 따라서 이런 전 과정에 걸쳐 IT 운영과 관련된 서비스가 적절한 시점에 자동으로 이루어지도록 하는 것이 데브옵스의 핵심이다.
데브옵스 각 단계는 각각 다음 단계와 연결되어 전체가 마치 하나의 체인(chain)을 구성하는 모습으로 동작한다. 이러한 동작이 자동으로 이루어지기 위해서 다양한 도구가 활용되며 이를 일컬어 데브옵스 툴체인(DevOps Toolchain)이라고 부른다.
계획(기획), 코딩, 빌드, 테스트의 데브(Dev) 단계와 릴리즈, 배포, 운영, 모니터링을 포함하는 옵스(Ops) 단계로 구분되지만, 이들 각 단계가 하나의 순환구조로 연결되어 있어 각 단계의 실행은 이전 단계의 완료와 함께 자동으로 넘어간다. 예를 들어 코딩이 완료되어 소스 저장소(repository)에 반영되면(commit & push) 자동으로 통합 및 빌드가 실행되고, 이후 자동화된 테스트를 거쳐 배포 이미지가 최종 릴리즈된다. 이는 역시 자동 배포 도구를 활용하여 서비스로 배포되며 이후 운영 및 모니터링이 이루어진다. 모니터링 결과에 따른 수정, 혹은 새로운 버전으로의 업그레이드가 있게 되면 이 그림과 같은 툴체인이 반복적으로 동작한다.
이 과정에서 다양한 도구들이 활용된다. 소스 저장소 관리 및 협업을 위한 대표적인 도구로 깃(Git)이 있고, 이에 기반한 깃랩(GitLab) 또는 깃헙(GitHub)이 대표적인 소스 관리 및 협업 서비스이다. 저장소와 연계되는 자동 통합도구로는 젠킨스(Jenkins), 트라비스(Travis) 등을 예로 들 수 있다. 배포 도구는 실제 최종 서비스가 운영되는 서버와 직접 연동된다. 아마존 AWS의 경우 코드디플로이(AWS Code Deploy)를 대표적인 예로 들 수 있다. 다른 도구들도 온-프레미스 혹은 클라우드에 설치하여 사용할 수 있다. 앞서 통합도구로 언급한 젠킨스는 통합 뿐만 아니라 배포용으로도 설치하여 활용되는 매우 인기가 많은 도구이다. 이 밖에도 최신 배포 도구들이 존재한다.
흔히 데브옵스라 하면 CI/CD라는 용어를 떠올리게 된다. CI(Continuous Integration)/CD(Continuous Deployment)를 직역하면 연속통합/연속배포이지만, 여기에는 ‘자동’이라는 말이 내포되어 있다. 즉, 앞서 언급한 도구들을 연계하여 코딩부터 배포까지 ‘자동으로’ 데브옵스 툴체인에서 동작하는 것으로 이해하면 된다.
데브옵스에서 데브섹옵스로
데브섹옵스는 데브옵스에 보안(Sec)을 더한 용어다. 그렇다면 왜 데브옵스섹(DevOpsSec)이 아니라 왜 굳이 데브섹옵스일까? 데브옵스의 경우 전통적으로 개발이 순서상 앞에 오고 그 이후 배포 운영이 이루어지기에 “데브”가 앞에 오는 것이 자연스럽다.
[divide style=”2″]
그렇다면 보안(Security)은 어느 단계에 있다고 보는 것이 타당할까?
[divide style=”2″]
보통 시스템 운영관점에서의 보안 전문가들은 IT 운영 서비스에 소속된 경우가 많다. 따라서, ‘전통적’인 관점에서 개발보다는 운영에 가깝다고 볼 수 있다. 최근 많은 기업이 회사 전체 차원에서의 보안책임자를 두고 있다. 특히 개인정보보호와 같은 분야는 거의 예외 없이 전사 차원의 책임자를 두는 추세다. 그만큼 회사 업무 프로세스 및 서비스 전반에 걸쳐 ‘보안’을 강조하는 것이다.
다시 데브옵스로 돌아와 보면, 결국 ‘보안’은 ‘데브’ 또는 ‘옵스’ 어느 단계에 속하거나 혹은 이들 단계 앞/뒤에 있는 것이 아니고 데브옵스 전반에 걸쳐 필요한 것으로 볼 수 있다. 이런 이유로 “데브옵스섹” 보다는 “데브섹옵스”라는 용어가 적합해 보인다. 보안이 개발과 운영 사이에 있다는 얘기는 물론 아니다. 그보다는 데브옵스 툴체인 전체를 ‘보안’이 커버하는 모습이 데브섹옵스의 실제 모습이다.
가트너가 2018년 발표한 10대 전략기술 트렌드에는 “연속/적응형 위기 및 신뢰 평가(Continuous Adaptive Risk and Trust Assesment)”가 포함돼 있다. 기존의 특정 담당자에게 책임과 권한이 부여되어있는 인프라 운영 수준에서의 보안으로는 가속화되는 디지털 전환 시대의 보안 요구 사항을 충족시킬 수 없으며, 결국 사람 중심으로 모든 스테이지에서의 보안이 필요하다고 강조하고 있다. 이를 위해서는 데브옵스에 보안을 얹어 개발 전 사이클에서의 지속적이며 계속 진화할 수 있는 보안 프레임워크가 있어야 하며 이것이 데브섹옵스라고 설명한다.
또 다른 가트너의 보고서인 ‘2020-2021 가장 중요한 10대 보안 프로젝트’에서도 데브섹옵스가 언급된다. 클라우드를 활용하는 조직에서 IaaS와 PaaS에 대한 보안을 담보할 수 있는 제어장치가 필요하며 특히 자동화된 평가·검증과 문제해결이 중요하다는 것이다. 클라우드에서 실행되는 애플리케이션이 동적이기 때문에 자동화된 데브섹옵스 프레임워크를 바탕으로 한 보안장치를 강조한 것이다. 클라우드 전체에 걸쳐 일관성 있는 보안 정책을 유지하기 수단으로 데브섹옵스를 든 것이다.
데브옵스의 전 라이프사이클에서 보안을 다루어야 한다는 것은 모든 관계되는 사람이 각자 담당하고 있는 업무에서 일정 수준의 보안 요구 사항을 충족시킬 수 있어야 함을 의미한다. 개발 및 배포 모든 단계에서 보안에 필요한 요소를 일정 수준 구현함으로써 사이버 공격이나 데이터 누출과 같은 보안사고에 대비하는 것이다. 데브옵스에서와 마찬가지로 적절한 도구를 사용함으로써 데브옵스의 자동화된 사이클을 유지할 수 있다. 애플리케이션 개발 단계에서부터 보안 요구 사항이 철저하게 검증되어야 한다는 사실이 데브섹옵스의 핵심이기도 하다.
데브섹옵스는 어떻게 동작하는가?
데브섹옵스의 가장 큰 장점은 소프트웨어 개발에서 배포/운영까지의 전 과정에 걸쳐 향상된 자동화 방식을 적용함으로써 외부로부터의 공격을 줄이고, 보안사고로 인한 서비스 중단을 최소화할 수 있다는 것이다. 기존 데브옵스 프레임워크 안에서 올바른 데브섹옵스 도구를 적절히 활용함으로써 전체 프로세스를 데브섹옵스 기반으로 확장할 수 있다. 전반적인 워크플로우를 간략히 살펴보면 다음과 같다.
- 코드 작성을 완료한다.
- 완료된 코드를 버전 관리 기능도 함께 있는 협업용 저장소(repository)에 등록한다.(Commit)
- 다른 개발자는 저장소로부터 이 코드를 받아 코드 품질을 분석한다. 이때 자동화된 도구를 활용하여 코딩 컨벤션 등 일반적인 품질 체크뿐만 아니라 보안에 위협이 될 만한 요소는 없는지, 눈에 띄는 버그는 없는지 등을 함께 분석한다. 주로 정적분석(Static Analysis)을 통해 이뤄진다.
- 이제 실행환경을 생성하여 애플리케이션을 배포하고 동시에 보안을 위해 필요한 구성 요소(configuration)가 시스템에 적용된다. 실행환경 자동 생성을 위해 IaC(Infrastructure as code) 도구가 사용된다.
- 새로 배포된 애플리케이션에 대해 테스트를 수행한다. 테스트케이스를 모아 자동으로 수행할 수 있는 도구를 활용하는데, 백 엔드에서 수행되는 비즈니스 로직뿐만 아니라 UI, 그리고 보안 및 API 테스트가 수행된다.
- 애플리케이션이 테스트를 통과하면 자동화된 배포 도구를 이용해 프로덕션 환경에서 실 배포한다.
- 실 배포한 애플리케이션을 계속 모니터링하며 시스템에 대한 보안 위협요소를 탐지한다.
테스트 주도형 개발(TDD: Test-Driven Development), CI/CD, 테스트 자동화와 함께 자동화된 보안 분석이 전반적인 소프트웨어 개발 파이프라인에 적용됨으로써 좀 더 향상된 코드 품질을 보장할 수 있다. 이는 곧 시스템에 대한 보안 위협을 최소화하며 컴플라이언스 요건을 충족시키는 데에도 기여한다. 그러나 이러한 일련의 과정은 많은 자동화 과정을 수반한다. 예를 들어 통합 후 테스트를 위한 인프라를 갖추는 과정에서 IaC(Infrastructure as Code)가 활용된다.
IaC는 인프라스트럭처 구성을 위해 필요한 환경을 코드 형태로 작성하여 필요한 컴퓨팅 환경을 유연하게 제공할 수 있도록 하는 프로세스를 말한다. 즉 물리적으로 하드웨어를 구성하거나 형상관리 도구를 활용해 일일이 구성요소를 정의하는 대신 프로그래밍 언어로 작성된 코드를 이용해 필요한 인프라를 제공(Provision)할 수 있도록 하는 것이다.
IaC의 좀 더 진화된 방식인 ‘연속적인 구성 자동화(CCA: Continuous Configuration Automation)’ 도구들이 실제 데브섹옵스 툴체인에서 많이 사용된다. IaC를 위해 작성된 코드는 일반 애플리케이션 코드와 마찬가지로 버전 관리시스템을 통해 저장·관리되며, CI/CD와 연계되어 배포 자동화에 활용된다. IaC 코드는 해커들의 주요 타겟이 될 수 있다는 점에서 일반 애플리케이션 코드보다 더 높은 수준으로 보호되어야 한다. 대표적인 IaC 도구로 셰프(Chef), 테라폼(Terraform) 등을 들 수 있다.
일반적으로 데브섹옵스 도구는 데브옵스 도구를 포함한다. 소프트웨어 개발 파이프라인 자동화를 위해 함께 쓰이기 때문이다. 특별히 보안과 관련된 부분만 따로 떼면 몇 가지 카테고리로 분류될 수 있다.
- 경고 알림: 개발자에게 비정상적인 상태를 경고해 주는 도구
- 자동화: 스캔 후 문제가 발견될 경우 이를 수정해 주는 도구로, 특정 조건이나 이벤트가 발생하면 그에 따라 개발자가 지정한 보안 관련 작업을 자동으로 수행
- 대시보드: 개발 프로세스상에서 보안 위협 가시성을 확보
- 보안 위협 모델링: 애플리케이션 리스크를 식별하고 분석
- 테스팅: 프로덕션 배포 전 보안 약점을 발견하기 위한 테스팅 도구
- 코드 분석: 정적분석을 통해 코드 품질 점수를 매기거나 오픈소스 관련 지적 재산권 침해 요소를 확인하고, 또한 향후 문제의 소지가 있는 코드 냄새(code smell) 등을 탐지
보안과 연관된 데브섹옵스 도구 상세 리스트는 아래 링크를 참조하기 바란다.
- 28 DevSecOps tools for baking security into the development process (CSO, May 29, 2019)
- Top 31 Best DevSecOps Tools (IdedoBlog, Aug 5, 2019)
AWS, 애저(Azure)에서의 데브섹옵스
클라우드에서의 데브섹옵스는 온-프레미스 컴퓨팅에서보다 더욱 중요한 의미를 지닌다. 퍼블릭 IaaS 위에서 또는 PaaS 기반으로 배포되는 애플리케이션의 경우 온-프레미스로 관리하는 인프라만큼 충분한 제어장치를 갖지 못하기 때문에 예상치 못한 보안 위협에 노출될 가능성이 크다. 특히 클라우드 네이티브 기반 애플리케이션 배포의 경우 개발, 통합, 빌드, 테스트, 패키징, 배포, 운영 과정이 모두 데브옵스 기반으로 자동화되기 때문에 보안 위협으로부터 애플리케이션과 시스템을 보호하기 위해서는 데브섹옵스가 필수다.
AWS에서는 코드 파이프라인을 이용하여 데브섹옵스를 구현할 수 있다. AWS와 서드 파티 솔루션을 조합하여 데브옵스 전 과정에서의 보안 관련 작업을 자동화하는 방식이다. IaC(Infrastructure as Code)로는 AWS 클라우드포메이션(CloudFormation)를 활용한다. 코드 커밋, 테스트, 프로덕션 스테이지마다 보안 그룹에 의한 검증이 이루어진다. 이 검증을 통과하지 못하면 전체 파이프라인은 멈추게 된다.
AWS 람다(Lambda) 함수가 검증 자동화 과정에서 중요한 역할을 한다. 예를 들어, 클라우드포메이션 템플릿이 생성되어 스토리지에 저장되면 자동으로 이를 정적으로 분석하는 람다 함수가 실행되는 것이다. 데브옵스 과정에서 새로운 코드 커밋이 발생할 경우, 역시 마찬가지로 해당 코드를 정적으로 분석하는 람다 함수가 실행될 수도 있다. 코드 파이프라인을 이용한 데브섹옵스 예는 다음과 같다.
마이크로소프트 애저(Azure)에서도 AWS와 유사하게 애저 솔루션 혹은 서드 파티 솔루션을 활용하여 데브섹옵스를 구현할 수 있다. 개발자가 깃헙(GitHub) 엔터프라이즈에 커밋 하면 자동으로 코드에 대한 보안 검증이 이루어진다. 검증을 통과하면 애저 파이프라인에서 CI 빌드를 통해 컨테이너 이미지가 만들어져 애저 쿠베네티스를 통해 배포된다. 컨테이너 이미지가 생성되어 애저 컨테이너 레지스트리에 등록되면 애저 보안센터(Azure Security Center)는 이 이미지의 취약점 및 컴플라이언스 여부를 검증한다. 컨테이너 실행환경을 자동으로 구성하기 위해 테라폼(Terraform)과 같은 IaC 도구가 활용될 수도 있다. 한편 쿠버네티스 서비스를 통해 배포되어 실행되는 동안 애저 모니터가 보안 로그를 수집하며 의심스러운 동작을 경고할 수 있다. 이러한 과정을 아래 그림에서 설명하고 있다.
AWS와 애저에서는 자체 도구뿐만 아니라 서드파티 도구를 활용하여 다양한 방식으로 데브섹옵스를 구현할 수 있다. 데브옵스 파이프라인 각 단계 전후, 또는 배포 후 전반적인 모니터링을 통해 보안에 위협이 되는 요소를 연속적으로, 그리고 자동으로 탐지하며 때로는 수정도 가능하다. 고객의 개발환경과 사용되는 도구의 다양성을 수용하기 위해 AWS나 애저와 같은 대형 클라우드 서비스 공급자는 지원 가능한 도구를 계속 확장하고 있다.
데브섹옵스는 선택이 아니라 필수
데브섹옵스는 데브옵스의 일반화와 함께 대두되는 보안 이슈를 다루기 위해 나온 확장된 데브옵스 개념이다. 소프트웨어개발 파이프라인 각 단계에서 보안 이슈가 해결되지 않는 한, 전체 프로세스를 자동화하는 것은 불가능하다. 데브옵스의 핵심은 곧 소프트웨어개발 파이프라인 자동화이므로, 자연스럽게 다양한 보안 도구가 데브옵스에 통합 운영될 수밖에 없다.
‘데브섹옵스’는 곧 사라질 것이라 말하는 사람들도 있다. 이는 데브옵스와 보안을 따로 떼어 낼 수 없음을 우회적으로 표현한 것으로 볼 수 있다. 주요 퍼블릭 클라우드 벤더의 경우 개발자 수요에 부합하는 다양한 솔루션들을 조합한 데브섹옵스를 지원하고 있고, 앞으로 더 많은 다양한 도구들을 수용할 것이다. 개발자 관점에서 이런 추세는 매우 반가운 일이지만, 한편 너무 많은 선택지로 인해 사용성을 떨어뜨릴 수도 있다.
앞서 소개한 마이크로소프트 애저의 데브섹옵스 구현 예에서 볼 수 있듯이, 쿠버네티스를 활용한 클라우드 네이티브 컴퓨팅에서 데브섹옵스는 특히 중요하다. 분산환경에서 동적으로 배포되는 컨테이너 이미지를 누군가 무단으로 변조하거나 엉뚱한 이미지로 대체하는 일이 발생한다면 이는 매우 끔찍한 결과를 초래한다. 개발부터 배포까지 전 데브옵스 파이프라인에 걸친 보안 및 컴플라이언스 검증이 제대로 이루어지지 않는다면 언제든 최악의 보안사고가 발생할 수 있다. 특히 이런 검증이 자동으로 이루어져야 데브옵스 파이프라인이 제대로 동작할 수 있다.
데브섹옵스는 선택이 아니라 필수다.
[divide style=”2″]
[box type=”note”]
본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다.
[/box]
