2018.08.21

데브섹옵스란? 기업이 관심 가질 이유는?

Tamlin Magee | Computerworld UK
데브섹옵스는 그저 하나의 트렌드가 아니다. 기업이 이를 근간부터 진지하게 고민해야 할 이유를 살펴본다.



꽤 축약된 용어인 '데브옵스(DevOps)'에 알파벳 3개가 더 붙은 것이 불편하겠지만 '데브섹옵스(Devsecops)'는 데브옵스 마인드셋에 있어 논리적이고 필수적인 연장선이다.

데브옵스는 조직 내의 '사일로'를 파괴하여 개발자와 운영팀이 협력하고 가능할 때마다 자동화를 활용할 수 있도록 하는 과정을 개괄적으로 정의한 것이다. 그 목적은 더욱 개선되고 안정적인 소프트웨어를 신속하게 공개하는 것이며, 그 과정에 처음부터 보안을 적용하는 것은 당연한 수순이다.

보안에 특수한 전문가가 필요한 경우가 많다. 이로 인해 데브옵스 전략에서 이런 인재들이 사전 공개 또는 심지어 공개 후 단계까지도 배제되는 위험이 종종 발생한다. 그 결과는 다소 짜증나는 것부터 잠재적으로 비극적인 것까지 다양하다.

레드햇의 수석 보안 아키텍트 마이크 버셀에 따르면 데브섹옵스의 진정한 핵심은 처음부터 데브옵스를 제대로 도입하는 것이다.

그는 "데브옵스를 실행하지만 그 과정의 핵심에 보안을 적용하지 않으면 데브옵스를 적절히 수행하는 것이 아니다. 그렇다고 해서 보안이 모든 것을 주물러야 한다는 뜻은 아니다. 왜냐하면 그렇게 되면 모든 것이 마비되기 때문이다. 데브옵스 사이클에 보안이 포함되도록 설계하면 된다. 그것이 데브섹옵스다"라고 말했다.

버셀은 이어 툴, 프로세스, 문화를 융합하는 것이 훌륭한 데브섹옵스 접근 방식이라고 말했다. "보안 전문가를 참여시키고 팀에 합류시키며 다양한 지식 영역을 프로세스에 적용하도록 하면 모두가 그들의 전문 지식을 이용할 수 있는 방식으로 데브옵스 모델의 보안을 자동화할 수 있다"라고 그는 덧붙였다.

시놉시스(Synopsys)의 수석 컨설턴트 미어라 라오는 버설의 의견에 동의하면서, 오늘날 많은 조직들이 툴 도입을 애자일 또는 데브옵스로의 주요 단계로 보고 있다고 지적했다.

라오는 "툴 자체가 만병통치약일 수 없다. 데브섹옵스는 일련의 툴 자동화를 통해 간단히 도입할 수 있는 존재가 아니다. 물론 툴 자동화가 잘 이행되면 그 가치는 대단하다. 적절히 수행하지 못하면 개발, 운영, 보안팀들이 시간, 노력, 예산을 낭비하게 된다"라고 말했다.

일부 개발자는 다양한 보안 방식에 익숙할 수도 있지만 개발자 대다수는 전반적으로 소프트웨어 작성과 시험에 중점을 두고 싶을 것이다. 그들이 보안을 인지하고 이를 일상 작업에서 고려한다면 좋은 일이겠지만 모두가 그렇게 하거나 그렇게 하고 싶지는 않을 가능성이 높다.

버셀은 "나는 보안을 중시한다. 그러나 모두가 그렇지는 않으며 모든 개발자에게 '보안 전문가가 되어야 한다'라고 말하고 싶지도 않다. 왜냐하면 그러기에는 대가가 너무 크고 현실화될 수 없기 때문이다"라고 말했다.

그는 이어 "하지만 프로세스 중 정책이 자동화되도록 하는 역할 또는 책임을 맡은 사람들이 있고 사람들이 프로세스를 따르도록 하며 예외에 따라 관리할 이유는 분명하다. 그래야 제대로 될 수 있다"라고 덧붙였다.

위험
기업들이 처음부터 보안을 배제하면 많은 위험에 노출된다. 가능한 3가지 시나리오는 다음과 같다.

- 보안팀이 한 릴리즈(Release)에 구멍이 많다는 사실을 발견하고 패치(Patch)를 위해 돌려보낸다.

- 안전하지 못한 릴리즈가 대중에 공개되고 보안팀이 여기에 구멍이 많다는 사실을 발견하여 시험을 위해 돌려보낸다.

- 안전하지 못한 버전이 공개되고 공격자들이 해당 기업 또는 그 고객의 네트워크를 해킹하여 데이터 유출이 발생하고 시스템이 고장 나고 기업 전체가 바로잡을 수 없는 명예 실추, 대규모 벌금을 겪게 된다.

마지막 시나리오는 분명 과장되긴 했지만 처음부터 보안을 적용하기 위해 작업하는 방식을 재구성하는 상대적으로 적은 노력이 위험을 감수하는 것보다 낫다.

데브섹옵스를 적절히 수행하기
그렇다면 데브섹옵스를 '적절히 수행'하려면 어떻게 해야 할까? 애석하게도 이 여정에는 끝이 없다. 절대로 끝나지 않는다. 비관적으로 들릴 수 있겠지만 사실이 그렇다. 고려해야 할 것들로는 다음과 같은 것들이 있다. :

모든 관련된 당사자들 사이에서 개방된 의사소통 채널을 개설한다. 프로젝트들의 단계를 보여주는 협업 툴을 통해 모두가 알고 있도록 하면, 팀들 사이의 마찰을 완화하는데 도움이 될 것이다.

시놉시스의 미어라 라오는 "그 과정에서 애플리케이션 보안팀은 긴밀한 협업을 지원하는 가장 적절한 툴, 기술, 프로세스를 선택해야 한다"고 말하면서 이런 단계를 적절히 수행하면 개발, 운영, 보안팀들 사이의 전통적인 사일로를 무너뜨리는데 도움이 될 것이라고 전했다.

강력한 감사 툴과 프로세스도 마련해야 하며 어떤 지점으로 신속하게 롤백(Roll Back)할 수 있으려면 포괄적인 체인지로그(Changelog)와 변경사항 캡처가 필요하다.

라오는 "반복 가능하고 감사 가능한 프로세스 수립은 데브섹옵스팀이 의지하고 이를 중심으로 예산을 수립하는데 중요하다"라며 "변화하는 비즈니스 목표와 지속적으로 발전하는 위협을 충족시키기 위해 신속하게 적응하는 보안 활동을 가능하게 하면 데브섹옵스 프로그램 내에서의 협업 변화가 쉬워진다"라고 전했다.

451 리서치의 연구 책임자 다니엘 케네디는 애플리케이션 보안 프로그램이 효과가 있다면 소프트웨어 개발 라이프 사이클 중 결함이 "좀더 '왼쪽으로 치우쳐짐으로써 해결될 수 있다”라고 말했다.

그는 "SAST형 역량을 개발자들에게 제공하고 식별된 코드 문제와 관련된 개발자 교육 구성 요소를 제공한다면 덜 취약한 코드가 빌드(Build)에 적용될 것이다"라며 "차후의 회귀 시험 또는 보안 감사 시 보안 결함의 수가 감소할 것”이라고 설명했다.

케네디는 이어 "명백한 장점은 애플리케이션 보안 툴이 식별하는 보안 결함이 감소한다는 점이다. 하지만 연속적인 개선은 결함이 낮은 비율로 적용되고 SDLC에서 조기에 해결할 수 있는 경우에만 가능하다. 이를 통해 사이클 초기에 더 적은 사람에게 영향을 끼치고 영향/해결 비용이 최소화되는 것이다"라고 덧붙였다.

한편 조직이 변화 프로그램의 성공을 측정하기 위해 살펴볼 수 있는 일부 지표가 있다. 분기별 검토는 기업이 적절한 경로를 유지하고 있는지 확인하는데 도움이 된다. 라오는 다음의 질문들을 자문할 것을 제안했다.

-현재 데브섹옵스 이행의 어느 단계인가?

-지금 직면한 문제는 무엇이며 이를 어떻게 극복할 수 있을까? 

- 무엇이 효과적이며 부족분을 어떻게 해결할 수 있을까?

이런 것들은 단기 및 장기 진행 상황의 맥락에서 고려할 수 있다.

물론, 100% 안전한 것은 없지만 다른 모든 사람에게 보안이 적용되도록 하면 조기에 중요한 문제가 해결되어 차후에 발생할 문제가 줄어들 가능성이 높아진다.

데브섹옵스 전문 용어:
CI/CD - 지속적 통합, 지속적 전달(Continuous Integration, Continuous Delivery)은 성공적인 데브옵스 프로그램에 필수적이라는 의견에는 이견이 드물다. 이는 지속적 통합과 지속적 전달이 안정적인 코드를 더욱 신속하게 제공하려는 목적과 결합시키는 것을 의미한다.

지속적 통합은 코드 변경사항을 메인 코드 브랜치(Branch)에 빈번하게 적용하는 것을 의미하며, 이를 자동화를 통해 시험할 수 있다. 아틀라시안(Atlassian)은 개발자들이 모든 코드를 릴리즈 브랜치에 병합하기 위해 공개 날짜까지 기다릴 때 발생하는 "통합 지옥"(integration hell )을 방지하는데 도움이 된다고 강조하고 있다.

지속적 전달은 개발과 시험 등 다양한 인프라 환경에 대해 애플리케이션 코드를 자동화하는 것을 의미한다.

IDE - 통합 개발자 환경(Integrated Developer Environment)은 앱 개발을 돕는 애플리케이션이며 일반적으로 지루한 작업을 자동화하기 위한 코드 편집기, 컴파일러(Compiler), 디버거(Debugger), 빌드 자동화 툴이 포함된다.

SDLC - 소프트웨어 개발 라이프사이클(Software Development Life Cycle)은 몇 개의 단계로 구성되며 일반적으로 원형 차트로 표현된다. 일반적으로 분석, 즉 애플리케이션의 용도, 디자인, 이행, 시험, 평가 단계로 구성된다.

정적 애플리케이션 보안 시험(Static application security testing, SAST) - 가트너는 이것들을 "보안 취약성을 보여주는 코딩 및 디자인 조건을 위한 애플리케이션 소스 코드, 바이트(Byte) 코드, 바이너리(Binary)를 분석하기 위해 개발된 일련의 기술"로 정의한다. 즉, 애플리케이션의 디자인에서 잠재적인 버그(Bug), 구멍, 취약성 등을 찾는 것이다. ciokr@idg.co.kr 



2018.08.21

데브섹옵스란? 기업이 관심 가질 이유는?

Tamlin Magee | Computerworld UK
데브섹옵스는 그저 하나의 트렌드가 아니다. 기업이 이를 근간부터 진지하게 고민해야 할 이유를 살펴본다.



꽤 축약된 용어인 '데브옵스(DevOps)'에 알파벳 3개가 더 붙은 것이 불편하겠지만 '데브섹옵스(Devsecops)'는 데브옵스 마인드셋에 있어 논리적이고 필수적인 연장선이다.

데브옵스는 조직 내의 '사일로'를 파괴하여 개발자와 운영팀이 협력하고 가능할 때마다 자동화를 활용할 수 있도록 하는 과정을 개괄적으로 정의한 것이다. 그 목적은 더욱 개선되고 안정적인 소프트웨어를 신속하게 공개하는 것이며, 그 과정에 처음부터 보안을 적용하는 것은 당연한 수순이다.

보안에 특수한 전문가가 필요한 경우가 많다. 이로 인해 데브옵스 전략에서 이런 인재들이 사전 공개 또는 심지어 공개 후 단계까지도 배제되는 위험이 종종 발생한다. 그 결과는 다소 짜증나는 것부터 잠재적으로 비극적인 것까지 다양하다.

레드햇의 수석 보안 아키텍트 마이크 버셀에 따르면 데브섹옵스의 진정한 핵심은 처음부터 데브옵스를 제대로 도입하는 것이다.

그는 "데브옵스를 실행하지만 그 과정의 핵심에 보안을 적용하지 않으면 데브옵스를 적절히 수행하는 것이 아니다. 그렇다고 해서 보안이 모든 것을 주물러야 한다는 뜻은 아니다. 왜냐하면 그렇게 되면 모든 것이 마비되기 때문이다. 데브옵스 사이클에 보안이 포함되도록 설계하면 된다. 그것이 데브섹옵스다"라고 말했다.

버셀은 이어 툴, 프로세스, 문화를 융합하는 것이 훌륭한 데브섹옵스 접근 방식이라고 말했다. "보안 전문가를 참여시키고 팀에 합류시키며 다양한 지식 영역을 프로세스에 적용하도록 하면 모두가 그들의 전문 지식을 이용할 수 있는 방식으로 데브옵스 모델의 보안을 자동화할 수 있다"라고 그는 덧붙였다.

시놉시스(Synopsys)의 수석 컨설턴트 미어라 라오는 버설의 의견에 동의하면서, 오늘날 많은 조직들이 툴 도입을 애자일 또는 데브옵스로의 주요 단계로 보고 있다고 지적했다.

라오는 "툴 자체가 만병통치약일 수 없다. 데브섹옵스는 일련의 툴 자동화를 통해 간단히 도입할 수 있는 존재가 아니다. 물론 툴 자동화가 잘 이행되면 그 가치는 대단하다. 적절히 수행하지 못하면 개발, 운영, 보안팀들이 시간, 노력, 예산을 낭비하게 된다"라고 말했다.

일부 개발자는 다양한 보안 방식에 익숙할 수도 있지만 개발자 대다수는 전반적으로 소프트웨어 작성과 시험에 중점을 두고 싶을 것이다. 그들이 보안을 인지하고 이를 일상 작업에서 고려한다면 좋은 일이겠지만 모두가 그렇게 하거나 그렇게 하고 싶지는 않을 가능성이 높다.

버셀은 "나는 보안을 중시한다. 그러나 모두가 그렇지는 않으며 모든 개발자에게 '보안 전문가가 되어야 한다'라고 말하고 싶지도 않다. 왜냐하면 그러기에는 대가가 너무 크고 현실화될 수 없기 때문이다"라고 말했다.

그는 이어 "하지만 프로세스 중 정책이 자동화되도록 하는 역할 또는 책임을 맡은 사람들이 있고 사람들이 프로세스를 따르도록 하며 예외에 따라 관리할 이유는 분명하다. 그래야 제대로 될 수 있다"라고 덧붙였다.

위험
기업들이 처음부터 보안을 배제하면 많은 위험에 노출된다. 가능한 3가지 시나리오는 다음과 같다.

- 보안팀이 한 릴리즈(Release)에 구멍이 많다는 사실을 발견하고 패치(Patch)를 위해 돌려보낸다.

- 안전하지 못한 릴리즈가 대중에 공개되고 보안팀이 여기에 구멍이 많다는 사실을 발견하여 시험을 위해 돌려보낸다.

- 안전하지 못한 버전이 공개되고 공격자들이 해당 기업 또는 그 고객의 네트워크를 해킹하여 데이터 유출이 발생하고 시스템이 고장 나고 기업 전체가 바로잡을 수 없는 명예 실추, 대규모 벌금을 겪게 된다.

마지막 시나리오는 분명 과장되긴 했지만 처음부터 보안을 적용하기 위해 작업하는 방식을 재구성하는 상대적으로 적은 노력이 위험을 감수하는 것보다 낫다.

데브섹옵스를 적절히 수행하기
그렇다면 데브섹옵스를 '적절히 수행'하려면 어떻게 해야 할까? 애석하게도 이 여정에는 끝이 없다. 절대로 끝나지 않는다. 비관적으로 들릴 수 있겠지만 사실이 그렇다. 고려해야 할 것들로는 다음과 같은 것들이 있다. :

모든 관련된 당사자들 사이에서 개방된 의사소통 채널을 개설한다. 프로젝트들의 단계를 보여주는 협업 툴을 통해 모두가 알고 있도록 하면, 팀들 사이의 마찰을 완화하는데 도움이 될 것이다.

시놉시스의 미어라 라오는 "그 과정에서 애플리케이션 보안팀은 긴밀한 협업을 지원하는 가장 적절한 툴, 기술, 프로세스를 선택해야 한다"고 말하면서 이런 단계를 적절히 수행하면 개발, 운영, 보안팀들 사이의 전통적인 사일로를 무너뜨리는데 도움이 될 것이라고 전했다.

강력한 감사 툴과 프로세스도 마련해야 하며 어떤 지점으로 신속하게 롤백(Roll Back)할 수 있으려면 포괄적인 체인지로그(Changelog)와 변경사항 캡처가 필요하다.

라오는 "반복 가능하고 감사 가능한 프로세스 수립은 데브섹옵스팀이 의지하고 이를 중심으로 예산을 수립하는데 중요하다"라며 "변화하는 비즈니스 목표와 지속적으로 발전하는 위협을 충족시키기 위해 신속하게 적응하는 보안 활동을 가능하게 하면 데브섹옵스 프로그램 내에서의 협업 변화가 쉬워진다"라고 전했다.

451 리서치의 연구 책임자 다니엘 케네디는 애플리케이션 보안 프로그램이 효과가 있다면 소프트웨어 개발 라이프 사이클 중 결함이 "좀더 '왼쪽으로 치우쳐짐으로써 해결될 수 있다”라고 말했다.

그는 "SAST형 역량을 개발자들에게 제공하고 식별된 코드 문제와 관련된 개발자 교육 구성 요소를 제공한다면 덜 취약한 코드가 빌드(Build)에 적용될 것이다"라며 "차후의 회귀 시험 또는 보안 감사 시 보안 결함의 수가 감소할 것”이라고 설명했다.

케네디는 이어 "명백한 장점은 애플리케이션 보안 툴이 식별하는 보안 결함이 감소한다는 점이다. 하지만 연속적인 개선은 결함이 낮은 비율로 적용되고 SDLC에서 조기에 해결할 수 있는 경우에만 가능하다. 이를 통해 사이클 초기에 더 적은 사람에게 영향을 끼치고 영향/해결 비용이 최소화되는 것이다"라고 덧붙였다.

한편 조직이 변화 프로그램의 성공을 측정하기 위해 살펴볼 수 있는 일부 지표가 있다. 분기별 검토는 기업이 적절한 경로를 유지하고 있는지 확인하는데 도움이 된다. 라오는 다음의 질문들을 자문할 것을 제안했다.

-현재 데브섹옵스 이행의 어느 단계인가?

-지금 직면한 문제는 무엇이며 이를 어떻게 극복할 수 있을까? 

- 무엇이 효과적이며 부족분을 어떻게 해결할 수 있을까?

이런 것들은 단기 및 장기 진행 상황의 맥락에서 고려할 수 있다.

물론, 100% 안전한 것은 없지만 다른 모든 사람에게 보안이 적용되도록 하면 조기에 중요한 문제가 해결되어 차후에 발생할 문제가 줄어들 가능성이 높아진다.

데브섹옵스 전문 용어:
CI/CD - 지속적 통합, 지속적 전달(Continuous Integration, Continuous Delivery)은 성공적인 데브옵스 프로그램에 필수적이라는 의견에는 이견이 드물다. 이는 지속적 통합과 지속적 전달이 안정적인 코드를 더욱 신속하게 제공하려는 목적과 결합시키는 것을 의미한다.

지속적 통합은 코드 변경사항을 메인 코드 브랜치(Branch)에 빈번하게 적용하는 것을 의미하며, 이를 자동화를 통해 시험할 수 있다. 아틀라시안(Atlassian)은 개발자들이 모든 코드를 릴리즈 브랜치에 병합하기 위해 공개 날짜까지 기다릴 때 발생하는 "통합 지옥"(integration hell )을 방지하는데 도움이 된다고 강조하고 있다.

지속적 전달은 개발과 시험 등 다양한 인프라 환경에 대해 애플리케이션 코드를 자동화하는 것을 의미한다.

IDE - 통합 개발자 환경(Integrated Developer Environment)은 앱 개발을 돕는 애플리케이션이며 일반적으로 지루한 작업을 자동화하기 위한 코드 편집기, 컴파일러(Compiler), 디버거(Debugger), 빌드 자동화 툴이 포함된다.

SDLC - 소프트웨어 개발 라이프사이클(Software Development Life Cycle)은 몇 개의 단계로 구성되며 일반적으로 원형 차트로 표현된다. 일반적으로 분석, 즉 애플리케이션의 용도, 디자인, 이행, 시험, 평가 단계로 구성된다.

정적 애플리케이션 보안 시험(Static application security testing, SAST) - 가트너는 이것들을 "보안 취약성을 보여주는 코딩 및 디자인 조건을 위한 애플리케이션 소스 코드, 바이트(Byte) 코드, 바이너리(Binary)를 분석하기 위해 개발된 일련의 기술"로 정의한다. 즉, 애플리케이션의 디자인에서 잠재적인 버그(Bug), 구멍, 취약성 등을 찾는 것이다. ciokr@idg.co.kr 

X