[보안맨] 클라우드 환경에서의 체계적인 개발 테스트리뷰

안녕하세요,

본 기고글에서는 ‘클라우드 환경에서 체계적인 소스코드 검토/테스트 절차 수립’ 이라는 주제를 다루려고 합니다.

필자의 회사에서는 (지난 기고글 ‘SOX ITGC Outline’에서 다룬) SOX IT General Controls (이하 ‘ITGC’) 요건을 충족해야 했습니다. 요건 내 여러 통제 활동이 몇년 전 Information Security Management System (이하 ‘ISMS’) 인증심사 관련 요건과 비교적 유사했으며, 유관 부서에서 통제활동을 적절히 유지 관리하고 있었습니다.

SOX ITGC에서 언급하는 소스코드 관리 관련 주요 통제활동 중 하나는 아래와 같습니다.

“Only appropriately reviewed and tested changes are able to be deployed to production.”

ISMS 인증기준 중 소스 프로그램 관리 관련 큰 틀에서 아래와 같이 정의하고 있습니다.

“ 소스 프로그램은 인가된 사용자만이 접근할 수 있도록 관리하고, 운영환경에 보관하지 않는 것을 원칙으로 한다.”

필자의 부서에서는 ISMS 요건보다 조금 더 구체적인 ‘검토/테스트 automatic control’ 를 적용하기 위한 큰 목표를 가졌습니다.

두 통제 요건은 본질적인 부분이 크게 다르지 않았으므로, 적절한 Gap Analysis, 최신 현황 파악, 회사 관련 정책/지침과의 연계성 등을 고려, 보수적인 요구사항을 우선 채택하는 큰 방향성을 마련 했습니다.

다만, 담당 부서 (주로 개발 부서)와 미팅 등을 통해 현황을 파악하고 업무를 분석하기 쉽지 않았습니다. 클라우드 환경 내 대규모 서비스를 통해 발생하는 이슈/오류를 빠르게 조치해야 하는 개발 특성 상 (또는 Agile Software Development) 관련 최근 히스토리 기록, 문서를 확인하기 쉽지 않았습니다. 이는 개발자의 잦은 입퇴사도 원인이었습니다.

아래 본론을 통해 1) 개발 pipeline,  2) 문제, 3) 해결 측면에서 살펴 보겠습니다.  

• 1.클라우드 환경 내 개발 pipeline overview (예시)

가. 개발자에 의한 코드 생성 / 개발자 PC or local machine, etc.

나. 코드 리뷰 또는 커밋 / Github or other Code Repositories

다. 테스트 (단위/통합 등), 빌드 (Continuous Integration)

마. Artifact 저장 / Harbor or other docker repository

바. 운영환경 배포 / k8s(쿠버네티스) or other Continuous Deployment (이하 ‘CD’) tools

※ CI: 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식

※ CD:소프트웨어 기능이 자동화된 배포를 통해 자주 제공되는 소프트웨어 엔지니어링 접근 방식

※ Code Repository: 팀이 협업하고 프로젝트의 소스 코드 저장소("리포지토리"라고도 함)를 수정하는 데 도움이 되는 툴로, 시간의 경과에 따른 코드 저장소의 변경 사항을 추적하여 작동

※ k8s(또는 쿠버네티스): 컨테이너화된 애플리케이션의 자동 디플로이, 스케일링 등을 제공하는 관리시스템으로, 오픈 소스 기반

※ Docker: 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼, Docker는 소프트웨어를 컨테이너라는 표준화된 유닛으로 패키징하며, 이 컨테이너에는 라이브러리, 시스템 도구, 코드, 런타임 등 소프트웨어를 실행하는 데 필요한 모든 것이 포함

※ Harbor:Docker Registry이외에 Garbage Collection, Docker Image 취약점 점검 등의 부가 기능을 추가로 제공하여 관리해 용이성을 제공

※ 클라우드 내 개발 프로세스 전체적인 부분을 세부적으로 다루지는 않겠습니다. 주로, 코드 리뷰, 테스트 관련 필자가 겪은 pain points 를 기술하는데 치중하겠습니다.

• 2.문제

필자의 회사는 개발 관련 회사 상위 정책서가 존재했습니다. 개발 각 과정에 따른 peer review, 서비스 impact 에 따른 적절한 테스트 기준이 비교적 상세히 기술되어 있었습니다. 다만,  코드 리뷰를 시스템 설정을 통해 전 개발조직에 강제 적용할 수 없었습니다. 개발 조직/팀 특성 또는 서비스 특성에 따라 적용이 어려운 cases 도 존재했습니다. 이상향은 언제나 존재하지만 유한한 현실에서 모든 rules 을 강제화할 수는 없기 때문입니다.

또한 Github 내 각 서비스 개발 조직이 admin permission 을 가지고 있었는데, 관련 repository 내 setting rules 변경이 가능했습니다. 이는 code review 를 bypass 할 수 있으므로 risk point 로 인식 되었습니다.

테스트 관련 이슈로, CI (Continuous Integration) 툴이 전사 개발 조직에 적용되지 않았습니다. 단위 테스트, 코드 병합, 빌드 등 을 자동으로 처리하는 기능이 부재했으므로, 각 feature 별 별도 tool 로 운용되고 있는 실정이었습니다. 특히, 테스트 관련 툴의 경우, 테스팅 기록을 불과 최근 2개월만 보관하는 이슈가 있었습니다. 이는 SOX ITGC 측면에서 큰 문제이자 결함이 주어지는 상황이었습니다. 기본적으로 감사인이 감사 기간 1년에 대한 모집단 확보를 요청하기 때문 입니다.

Figure 1. Branch Protection Settings in Github (example)

또한, 상용 클라우드 환경에서 개발자들이 널리 사용하는 Code Repository Tool (이하 ‘Github’)관련 개발자들에게 IT compliance 요건으로 다른 tool로 전환해야 하는 까닭을 명확히 설명해야 하는 상황이었습니다.

• 3.해결

위 다양한 문제에 따라 주어진 기한 내 실현 가능한 목표, 집중해야 할 것, out of scope 은 무엇인지를 리스트업 했습니다. 특히, 서비스 impact 또는 예산 등에 따라 중/장기로 분류되는 issue cases 에 대한 명쾌한 위험 평가가 필요했습니다.

Figure 2. IT 개발 관련 개선 보고서 (예시)

필자의 회사는 큰 조직 구성에 따른 R&R 이 명확하여 아래와 같은 접근법을 채택했습니다.

• -목표 / 문제 / 범위 / 계획 등 관련 보고서 마련 및 유관부서와 업무 수행

/ AAA 팀 (필자 부서)

• -IT 위험평가에 따른 위험 관리

/ IT Risk 팀

제일 중요한 것은, 직원들의 개발 문화/습관인 것 같습니다. 통제 또는 보안 부서에서 지켜야 할 규칙을 수립하고, system을 통해 enforcement 해도, 이를 따르는 직원의 인식이 선행되지 않는다면, 단기간에 시행되거나, 유명무실한 규칙일 뿐입니다. 지속적인 IT development training for IT compliance, 단계적 system enforcement rules 캠페인 등에 따른 직원들의 반감이 아닌, 적극적으로 룰을 따르는 직원이 되도록 여러 events 를 마련할 필요가 있습니다.

회사 규모, 예산 등에 따라 다르겠지만 큰 IT 조직은 IT 감사부서와 별개로, IT 규칙을 따르도록 개발/인프라 조직을 돕는 컨설팅 부서가 별도로 존재합니다.