네트워크의 어떤 누구도, 어떤 기기도 신뢰하지 않는 개념의 제로 트러스트 사이버 보안 전략이 점점 더 많은 관심을 끌고 있다. 다른 관점으로 설명하면 모든 주체와 자원들 사이에 ‘명시적’인 신뢰 관계를 반드시 확인할 수 있어야 한다는 것이다.
이를 위해서는 수많은 사용자와 기기, 서버 등 다양하고 방대한 엔드포인트에 대한 실시간 모니터링 및 관리가 필요하다. 그만큼 관리의 대상과 계층이 다양하며, 그 복잡도 역시 매우 높아질 수밖에 없는 것이 제로 트러스트 전략을 구현하는데 넘어야 할 벽이다.
데브섹옵스(DevSecOps)는 개발(Dev), 보안(Sec), 운영을 합친 말이다. 기존 널리 알려진 데브옵스에 “보안”이 더해진 것이다. 데브옵스는 소프트웨어개발 파이프라인과 배포·운영 파이프라인이 자연스럽게 연계됨으로써 개발에서 배포까지의 전 과정에 걸쳐 시간을 단축하고자 하는 취지에서 도입되었다.
데브섹옵스는 데브옵스 체인의 단계마다 보안과 관련된 활동이 포함된 것으로 볼 수 있다. 즉, 데브옵스 상의 운영과 같은 특정 단계에 보안이 들어가는 것이 아니라 기획, 개발, 테스트 등 파이프라인 전반에 걸쳐 적절한 보안 조처를 수행해야 하는 것을 의미한다.
데브옵스에서 전체 파이프라인의 자동화를 위한 다양한 도구들이 활용될 수 있다. 이런 일련의 도구들, 즉 툴체인은 제로 트러스트 기반의 보안과 통합됨으로써 자연스럽게 데브섹옵스로 확장될 수 있다. 특히 온-프레미스컴퓨팅과 클라우드컴퓨팅이 혼용되는 하이브리드컴퓨팅 환경에서의 데브섹옵스 전략은 제로 트러스트 모델과 매우 궁합이 잘 맞는다.
제로 트러스트 모델은 데이터 패킷부터 사용자 애플리케이션 또는 서비스까지 필요한 모든 다양한 계층에 적용될 수 있다. 이러한 다양한 계층에서의 보안이 곧 데브옵스 파이프라인과 밀접하게 연결되면 자연스럽게 데브섹옵스로 확장된다.
예를 들면 작성된 코드를 소스 저장소에 보낼 때 보내는 사람과 이 코드를 리뷰한 사람의 신원 확인, 빌드 작업을 수행하는 기기의 적합성, 배포 시 배포 주체 혹은 기기의 안전성을 검증하는 것은 제로 트러스트 기반 보안과 그 궤를 같이한다.
배포되어 실행 중인 애플리케이션을 지속적으로 모니터링하고 인가되지 않은 접속을 차단하는 역할 역시 제로 트러스트 모델에서 매우 중요한 기능이다. 따라서 제로 트러스트 모델은 데브섹옵스 파이프라인을 구현하는데 단지 적합한 것을 넘어 꼭 필요하다고 볼 수 있다.
데브섹옵스 라이프사이클에서의 제로 트러스트 보안
데브섹옵스의 파이프라인(라이프사이클) 각 스테이지별 다양한 보안 옵션이 필요하다. 개발 조직이나 운영 형태, 조직의 미션 등에 따라 다양한 툴체인 도입이 가능하다. 아래 도식은 미국 국방성에서 펴낸 데브섹옵스 레퍼런스 디자인 문서에서 제시한 데브섹옵스 라이프사이클이다. 이는, 국방부뿐만 아니라 일반 기업에서도 그대로 적용할 수 있는 필요한 보안 관련 활동을 제시하고 있다.
위 도식에는 일반적인 데브섹옵스 파이프라인에 ‘딜리버’와 ‘피드백’ 단계가 추가되어 있다. 릴리스와 딜리버 단계를 하나로, 그리고 모니터와 피드백 단계를 합치면 두 그림은 사실상 동일한 여덟 단계로 볼 수 있다. 이 여덟 개 단계별로 필요한 보안 옵션을 정리하면 다음과 같다.
데브섹옵스의 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인 자동화의 특징은 하루에도 수십 또는 수백 번 코드 수정 및 빌드, 그리고 배포가 계속 이루어진다는 것이다. 그만큼 빈번한 협업이 새로운 프로세스와 도구를 활용하여 이루어지게 된다.
이런 새로운 수준의 협업 자동화에서 가장 큰 도전은 이 모든 것을 안전하게 오케스트레이션 하는 것이다. 변경된 코드가 제대로 테스트를 거쳐 안전하게 동작하는 올바른 버전으로 필요한 곳에 정확하게 배포되어야 한다. 이 일련의 파이프라인을 어떻게 안전하게 보호할 것인가가 데브섹옵스 성공의 관건이다.
또한, 데브섹옵스 라이프사이클에 관여하는 사람들 사이의 상호 접근 권한을 부여하고 이를 추적하는 문제도 매우 복잡해진다. 일부 개발자는 기밀 데이터를 수반하는 미션 크리티컬한 트랜잭션이 빈번히 발생하는 백엔드 코드를 다루는 반면, 또 다른 개발자는 기밀성이 필요 없는 사용자 인터페이스 코드만 다루기도 한다.
이렇게 다른 유형의 개발자에 대한 접근 수준은 각기 다르지만, 이들 모두가 데브섹옵스 라이프사이클에서 긴밀한 협업을 유지해야 한다. 실행되는 코드에 대한 보안 모니터링 수준이 각기 달라도 다른 사람이 만든 모듈에 접근해야 할 필요가 있다.
데브섹옵스의 보안 과제를 제로 트러스트 모델로 해결하는 접근 방식에 대해서는 이미 다양하게 논의되고 있다. 마이크로서비스 아키텍처에서의 제로 트러스트 보안 모델의 중요성, 데브섹옵스와 제로 트러스트를 통합했을 때 각 데브옵스 스테이지에서의 상세한 제로 트러스트 가이드 등을 예로 들 수 있다.
클라우드 네이티브 컴퓨팅, 데브섹옵스, 제로 트러스트
컨테이너 단위의 통합 및 배포 방식은 데브옵스와 아주 잘 어울린다. 따라서 데브옵스를 도입하는 경우 자연스럽게 컨테이너 기반의 클라우드 네이티브 컴퓨팅 환경으로 전환하게 된다. 특히 온-프레미스, 프라이빗 클라우드, 퍼블릭 클라우드를 혼용하는 하이브리드 컴퓨팅이 보편화하며 클라우드 네이티브 컴퓨팅과 잘 맞는 마이크로 서비스가 점차 주류를 이루어 가고 있다. 마이크로 서비스의 장점은 외부 서비스와의 연계를 통해 서비스 확장이 쉽다는 점이다. 또한, 내 서비스에 대해서도 외부에서 접근하게 할 수 있게 함으로써 다양한 서비스에 활용될 수 있다.
이러한 유연성은 대규모의 새로운 서비스를 애자일하게 개발하고 데브옵스를 활용하여 자동화할 수 있다는 강점을 제공하지만, 한편, 서로 복잡하게 API로 연결된 비즈니스 로직의 흐름이 모호하고 유동적이라는 문제점의 원인이기도 하다. 즉, 모든 동작 과정의 가시성 확보가 쉽지 않아 결국, 보안 및 안정성 사각지대를 만들 수밖에 없다. 마이크로 서비스 자체가 태생적으로 보안 취약점이 있다는 뜻이다. 이러한 취약점은 API 연결 시 엄격한 인증 및 권한 부여를 통해 해결해야 한다.
데브섹옵스는 데브옵스 사이클과 이를 둘러싸 끊임없이 모니터링하는 보안 활동으로 구성되어 있다. 어떤 누구도 이러한 사이클을 우회하여 프로덕션 배포를 절대 할 수 없다. 이는 결국 데브옵스 사이클 전반에 걸쳐 제로 트러스트 개념의 보안 수준을 요구하는 것으로 해석될 수 있다. 왜냐하면, 가장 확실한 접근 제어는 제로 트러스트에 기반하는 것이기 때문이다. 세분화된 권한을 바탕으로 모든 접근 요청 요청에 대한 제어가 자동으로 이루어진다.
제로 트러스트 기반 모델을 적용하면 모든 API 연결 시도를 보안 침해 의도로 간주하고 이에 대한 철저한 인증 및 접근 권한 제어를 강제하게 된다. 데브섹옵스에서의 보안 활동을 정리한 위 표에서 릴리스와 배포 단계에서는 디지털 서명과 체크섬(Checksum)을 이용하여 배포 단위의 유효성을 확인하고, 각 마이크로서비스의 접근 권한 체크 및 모니터링을 하게 되어있다. 제로 트러스트 모델에서는 이와 같은 보안 활동이 자동으로 이루어진다. 승인되지 않은 개발자가 자신의 권한 범위를 넘어선 접근 권한을 갖는 ‘슈퍼’ 마이크로서비스를 배포할 수 없도록 하는 것이다.
데브섹옵스 및 마이크로 서비스와 같이 빠르고 유연함이 강조되면 될수록 철저한 보안은 더욱 어려워진다. 특히 전통적인 보안 운영팀이 기존의 방식으로 취약점을 탐지하고 침해사고에 대응하는 것은 사실상 불가능하다. 세분화된 보안 정책을 자동화된 인프라 환경에서 구현하는 것이 답이다. 제로 트러스트는 현재 이렇게 끊임없이 빠르게 변화하는 보안 위협에 실질적으로 대응할 수 있는 가장 유력한 개념이라고 볼 수 있다.
[divide style=”2″]
[box type=”note”]
본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다.
[/box]
