최첨단 개발 부서는 테스트 자동화를 통해 CI/CD 파이프라인을 완전히 자동화하고, 인프라를 코드로 배치한다. 이들은 변화 관리 및 돌발 상황 관리 워크플로우를 애자일 개발 도구와 연계하고 AI옵스(AIops) 플랫폼을 사용하여 생산 문제의 기저 원인을 더 신속하게 찾는다.
하지만 소프트웨어 개발의 보안 문제는 여전하다. ESG의 ‘현대 애플리케이션 개발 보안(Modern Application Development Security)’ 연구에서는 응답자 중 36%만이 자신의 애플리케이션 보안 프로그램에 9~10점을 부여했으며 66%는 애플리케이션 보안 도구가 코드베이스의 75%도 보호하지 못한다고 말했고, 48%는 취약한 코드를 주기적으로 생산에 투입한다고 인정했다.
보안 결점은 기술, 컨설팅, 보안서비스 제공자의 부재 때문이 아니다. ‘사이버 보안 알마낙 2020(Cybersecurity Almanac 2020)’에서는 3,500곳 이상의 보안 업체를 대상으로 소프트웨어 개발 시 보안 위험을 최소화하면서 비즈니스 가치를 제공할 때의 핵심은 보안 원칙을 명확히 정의하여 소프트웨어 개발 부서에게 전달하는 것임을 확인했다.
CIO와 IT 리더가 집중해야 하는 6가지 위험과 이를 해결하는 방법을 알아보자.
위험 1 : 보안을 가장 중요한 데브옵스 구성요소로 대우하지 않는 것
조직이 보안을 우선시한다고 말하기는 쉽다. 애자일 및 데브옵스 모범 보안 사례를 따르는 기업도 많다. 하지만 개발 부서의 수와 비교해 인포섹(Infosec)의 인력이 부족한 경우가 많기 때문에 다른 비즈니스 및 기술 부채 우선순위가 애자일 부서 백로그(Backlog)를 지배하는 방식이나 조직 전반에 걸쳐 보안 관례가 고르게 도입되지 않는 이유를 쉽게 알 수 있다.ESG 연구가 이 결론을 뒷받침한다. 응답자 중 78%는 보안 분석가가 개발자와 직접 소통한다고 말했지만 개별 기능과 코드를 검토하는 것은 31%뿐이다. 이 격차는 상당하다. 대부분의 조직이 충분한 보안 전문가를 고용하여 애자일 개발 부서에 영구적으로 배치할 가능성은 매우 낮다. 그러나 다음의 변화를 가져올 수는 있을 것이다.
• 소프트웨어 개발 부서 전체에 대한 지속적인 보안 교육을 요구한다.
• 인포섹에 아틀라시안 컨플루언스(Atlassian Confluence)나 마이크로소프트 팀즈(Teams) 같은 도구에 보안 수용 기준 표준을 문서화하도록 요구하고 애자일 부서에 이를 사용자 스토리에 참조하도록 요구한다.
• 인포섹이 위험이 더 높은 기능과 사용자 스토리를 개발 프로세스 초기에 확인할 수 있도록 애자일 계획 및 릴리즈 관리에 대한 협업을 공식화한다.
• 인포섹이 더 많이 확인하고 위험한 구현을 파악할 수 있도록 스프린트 검토를 기록하고 공개한다.
• 새로 개발된 모든 API, 마이크로서비스, 통합, 애플리케이션 기기가 CI/CD 파이프라인에서 필요한 보안 테스트를 거치도록 요구한다.
원칙 정의, 팀간 협업 확보, 문화 개선, 팀 행복도 개선 등이 CIO가 소프트웨어 보안 개선에 기여하는 가장 중요한 방법일 수 있다. 2020 데브섹옵스(DevSecOps) 커뮤니티 설문조사에서 행복 지수가 높은 개발자는 보안에 신경 쓸 확률이 3.6배나 높았다.
위험 2 : 전매 특허 기술 구현 개발하기
소프트웨어 개발 부서는 코딩 및 개발 솔루션을 좋아한다. 조직은 묘기, 혁신, 기술을 통해 어려운 비즈니스 문제를 해결해야 한다. 하지만 때로는 개발 부서가 서드파티 소스에서 도입할 가능성이 있는 어려운 기술 문제와 구현을 해결할 때 요구조건이 중요하다.로우코드(Low-code)와 노코드(No-code)로 솔루션이 더 안전해질 때가 있다. 그 이유는 최소 2가지다. 첫째, 애자일 제품 소유자가 항상 주요 기능의 보안 구현을 잘 아는 것은 아니다. 둘째, 많은 사람이 솔루션의 요소를 지시하지 않고 요구조건만 만드는데, 부서들이 코드 집약적인 솔루션을 구현하면서 보안 위험이 발생할 수 있기 때문이다.
애자일 개발 부서는 우선 제품 소유자에게 기능 우선순위에 관해 질문한 후 범위와 요구조건을 협상해야 한다. 그 과정에서 대립을 피하는 방법은 사용자 스토리 작성 및 예측 시 엄격하게 하여 코딩이 시작되기 전에 복잡성이 노출되도록 하는 것이다.
부서가 우선순위와 기능 범위에 대해 동의하면 개발 부서는 구현 시 서드파티 업체의 기술을 활용할 수 있는 곳을 고려해야 한다. 검토에는 로우코드 및 노코드 플랫폼, 오픈소스 라이브러리, 상용 프레임워크, 공공 클라우드 서비스, SaaS(Software as a Service) 도구가 포함되어야 한다.
물론, 세상에 공짜는 없다. 서드파티 솔루션을 사용하면 그에 따른 위험이 있다.
위험 3 : 오픈소스 및 상용 구성 요소에 대한 부실한 거버넌스와 관리
개발 부서가 스스로 도구를 선택하기 위한 가장 좋은 준비는 무엇일까? 최근에는 고급 개발 부서에서 이런 이야기를 하는 경우가 많고, 여러 유명 개발 서적에서도 이 원칙을 강조하고 있다.하지만 많은 CIO, IT리더, CISO는 개발 부서에 도구 및 구성 요소 선택에 대한 백지 의사결정 권한을 제공하는 것을 경고하고 있다. 이와 동시에 제한이 너무 많고, 승인 과정이 복잡해 혁신이 느려지고 재능 있는 개발자들이 불만을 갖게 된다는 점에 동의하는 리더가 다수다. CIO, IT리더, CISO는 기술 선택, 업그레이드, 패치에 관한 명확하고 쉽게 따를 수 있는 규칙과 합리적인 거버넌스를 정의해야 한다.
최근의 설문조사에서 위험의 징조가 나타났다. 1,500명의 IT 전문가를 대상으로 데브섹옵스와 오픈소스 관리에 관해 진행한 설문조사에서 응답자 중 72%만이 오픈소스 사용 정책을 만들었다고 보고했으며 64%는 오픈소스 거버넌스 위원회가 있다고 보고했다. 이것은 문제의 일부에 불과하다. 응답자 중 16%는 중요한 오픈소스 취약성이 확인되면 해결할 수 있다고 생각했다.
오픈소스 구성 요소와 관련하여 보고된 유출 건수를 고려하면 우려할 만한 결과다. 2020 데브섹옵스 커뮤니티 설문조사에서 응답자 중 21%는 오픈소스 구성 요소와 관련된 유출을 인정했다. 이것은 단순히 오픈소스 문제가 아니며, 어느 상용 시스템에나 API 보안 취약성 또는 기타 소프트웨어 구성 요소 취약성이 있을 수 있다.
오픈소스 사용, 도구 선택, 기술 라이프 사이클 관리에 관한 명확하게 정의된 정책, 거버넌스, 관리 사례가 있어야 위험을 완화할 수 있다. 하지만 조직의 모범 사례는 저마다 다르다. 추가적인 개방성에 의존하는 곳도 있고 낮은 위험은 허용하거나 더 엄격한 절차에 의존하는 곳도 있다. 보안과 혁신의 균형을 맞춘 정책을 수립하기 위해 CIO는 다학제적 팀을 구성하여 거버넌스 절차, 활동 기준, 도구, 지표를 정의해야 한다.
개발자 역량과 보안 모범 사례를 통합하는 도구가 있으면 오픈소스 구성 요소 선택의 문제 중 일부를 완화할 수 있다. 퀵 베이스(Quick Base)의 CPTO(Chief Product and Technology Officer) 제이 재미슨은 오픈소스를 통한 혁신에 대한 퀵 베이스의 접근방식에 관한 인사이트를 공유했다.
“깃허브 어드밴스드 시큐리티(GitHub Advanced Security) 얼리 어답터이기 때문에 그 플랫폼에서 관리되는 오픈소스 프로젝트의 취약성을 더 쉽게 찾아낼 수 있다. 이것은 소단 개발 라이프사이클 초기에 보안을 움직이는 중요한 단계이며, 개발자 사이에서는 ‘시프트 레프트(Shift Left)’로 알려져 있다.”
위험 4 : 무제한 소스 코드 저장소 및 CI/CD 파이프라인 액세스
자체 소프트웨어 보안 방법은 버전 관리 저장소 잠그기, 코드의 취약성 스캔, 배치 지원을 위한 최소 권한 정의, 연결 암호화, 침투 테스트 실시 등이었다. 네트워크와 인프라를 잠그는 것은 완전히 이질적인 보안 영역이었으며 별도의 도구와 규칙을 IT 운영에서 관리해야 했다.현재, 위험과 도구가 더 많지만 통합 방식도 발전했다. 필자는 셔웰(Cherwell)의 엔지니어링 VP 조쉬 메이슨과 코드 보안에 대한 셔웰의 접근방식에 관해 이야기했다. 메이슨은 “셔웰에서는 자동화된 정적 분석 보안 테스트(SAST), 동적 애플리케이션 보안 테스트, 인간 주도 침투 테스트를 복합적으로 시행하며, 이로 인해 생산성이 개선되는 경향이 있다. CI/CD 파이프라인의 일환으로 SAST를 구현하면 소프트웨어 개발 라이프사이클에서 발견 프로세스가 더 왼쪽으로 이동하여 더 빠르고 저렴하게 해결할 수 있다”라고 말했다.
또한 메이슨은 버전 관리 저장소를 잠그라고 조언했다. “제로트러스트 모델과 최소 권한의 원칙을 따르는 것이 소스 관리 저장소와 그 기능에 대한 액세스를 제한하는 좋은 방법이다. 애저 데브옵스, 깃허브, 비트버킷(Bitbucket) 등의 소스 관리 저장소 솔루션은 세분화된 사용자 권한을 제공하므로, 개발자(또는 개발 부서 전체)를 업무와 관련된 더욱 작은 코드베이스 영역으로 제한할 수 있다.”
델 테크놀로지스의 사업부 부미(Boomi)의 엔지니어링 책임자 라제쉬 라헤자는 개발 부서가 책임을 져야 하는 여러 보안 규칙을 제안했다. 소프트웨어가 제대로 개발되지 않으면 보안 위험이 개별 시스템이 해킹된 것보다 훨씬 큰 규모로 확대된다. CI/CD 파이프라인을 보호하고 최소 권한 원칙을 통해 시스템을 잠그며 다중 요소 인증으로 자동화에 대한 안전한 우회책을 구현하고 팀원의 보안 인식 제고를 유도하며 안전한 코딩 활동을 개발함으로써 위험을 완화할 수 있다.
위험 5 : 민감한 데이터 보호와 관리
보안 부서나 팀원도 애플리케이션 개발, 테스트, 배치를 위한 보안 활동을 잘 알고 있지만, 그럼에도 데이터 관리와 데이터옵스(Dataops)를 중심으로 하는 보안 활동도 추가해야 한다.데이터키친(DataKitchen)의 CEO 크리스 버그는 더 많은 데이터 운영 보안 자동화에 대한 문제와 접근방식을 설명했다. “데이터 프라이버시 및 문제로 인해 기업은 데이터로 수익을 창출하여 경쟁 우위를 점하지 못한다. 수동 프로세스는 이 문제를 해결할 수 없으며, 너무 많은 데이터가 너무 빠르게 흐르기 때문에 처리하기도 어렵다. 데이터섹옵스(Datasecops)는 데이터 프라이버시 및 보안을 자동화하는 방법론이며 프라이버시, 보안, 거버넌스를 데이터 분석 개발, 배치, 운영에 따라 실시되는 자동화된 워크플로로 통합한다.”
CIO와 IT리더의 주된 데이터옵스 문제는 선제적인 데이터 거버넌스 도입, 민감한 데이터 식별, 수용 가능한 데이터 활동에 관한 개발자와 데이터 사이언티스트 교육이다. ID 관리 중앙 집중화, 역할 기반 권한 정의, 개발 환경에서 민감한 데이터 감추기는 중요한 데이터 보안 및 데이터 프라이버시 활동이다.
민감한 데이터를 관리하는 것은 데이터 보안의 수준을 넘어서는 것이다. 예를 들어, 많은 기업이, 특히 규제를 받는 산업에 속한 기업이 데이터 혈통을 포착하여 누가, 언제, 어디에서, 어떻게 데이터를 변경하는지 보여주어야 한다. 이런 기업은 데이터 혈통 기능이 내장된 데이터 통합 및 데이터 관리 플랫폼을 활용하는 경우가 많다.
위험 6 : DIY 보안 전문지식과 솔루션
위험 및 보안 관리에 대한 필자의 접근방식은 항상 다양한 전문가의 조언을 구하는 것이다. 보안 위협의 강도와 복잡성이 증가하고 있으며, 대부분의 조직이 필요한 모든 전문지식을 갖추고 있을 가능성은 낮다. 또한 보안 문제가 발생하면 위험 감소, 문제 해결, 포렌식 수집, 취약성 강화에 관해 상의할 수 있는 인적자원 확보가 영향 최소화에 필수적이다.도구와 활동은 CIO가 현재의 문제를 해결하는 데 도움이 된다. 하지만 새로운 보안 문제를 짚고 지원할 수 있는 전문가의 필요성도 절실하다. editor@itworld.co.kr