보안이 접목된 데브옵스, 조직 입장에서는 꿈만 같은 일
공포 분위기 조성하는 건 효과 짧아...보안도 개발 이해해야
[보안뉴스 문가용 기자] 소프트웨어 데브옵스와 정보보안이 제대로 만나면 기업으로서는 그보다 더 큰 축복이 없을 것이다. 하지만 이게 회사에게만 좋은 일은 아니다. 보안 구멍이 하나도 없으면서 속도도 나는 코딩이란, 개발자들도 늘 바라왔던 것이기 때문이다.
.jpg)
하지만 변화란 것이 그리 쉽지만은 않다. 데브옵스가 곧바로 적용될 것도 아니고 개발자들이 바라기만 한다고 적응되는 것도 아니다. 개발자들이나 보안 담당자나 사고방식, 기존에 일하던 습관, 소통 방법 등을 전부 바꾸기 위해 노력해야 한다. 이에 대해 보안 아키텍트인 미셸 슈비르카(Michele Chubirka)와 데브섹옵스 및 클라우드 전문가인 트로이 마샬(Troy Marshall)이 만나 이야기를 나눴다.
완벽할 수 없지만, 발전할 수는 있다
데브옵스의 핵심은 코드를 작은 단위로, 자주 활용하고 추가 및 수정해 소프트웨어를 점진적으로 발전시키는 것이다. 그런데 이런 식의 소프트웨어 개발론은 오래된 보안 전문가들에게 굉장히 낯선 것이다. 그들은 리스크 수위에 근거하여 소프트웨어를 가다듬고 분석해 보완하는 것에 더 익숙하다.
그래서 마샬은 “완벽을 기하려는 마음이 방해가 된다”고 말한다. “완성된 코드를 받아든 보안 전문가들은 구멍과 취약점을 하나라도 더 찾으려고 했거든요. 시간을 최대한 많이 쓰고 싶어하죠. 그러니 조금씩 조금씩 자꾸만 바뀌는 데브옵스의 각 단계가 성에 찰 수가 없어요. 하지만 그런 수정 과정이 계속 반복된다는 걸 기억해야 합니다. 한 번에 많은 시간을 할애하는 것에서부터 탈피하고, 조각난 시간들을 최대한 활용하는 것에 익숙해져야 하죠.”
마찰이 생기는 부분을 최대한 제거하라
IT 전문가들의 60%는 보안이 데브옵스의 억제제라고 여긴다. 보안이 점점 더 중요해지는 앱 경제 체제에서 이는 개선이 되어야 할 부분이다. “보안 담당자들의 역할은 리스크를 최소화하는 것이지, 모든 사람에게 ‘보안의 좁은 관점’을 장착시키려는 게 아닙니다. 안전이 중요하긴 하지만 그것이 전부인 건 아니죠.” 슈비르카의 설명이다.
또 슈비르카는 “데브섹옵스로 전환하려면 인력이 많이 필요한 수동적인 게이팅 과정들을 포기해야 한다”며 “비즈니스의 기존 워크플로우에 많은 ‘마찰’을 가져와야 할 필요가 있다”고 말한다. “마비에 가까운 장애나 혼란이 사내에 일어날지 모릅니다. 그야 말로 리스크가 크게 일어나는 것이죠,. 그런 환경에서라면 마찰이 일어나는 부분들을 깎아나가는 게 보안 담당자의 몫이 됩니다. 데브섹옵스를 통해 오히려 억제제가 윤활유가 되는 것이죠.”
개발자의 입장이 되어보라
데브옵스에 보안을 끼얹으려고 할 때 가장 문제가 되는 것 중 하나는 보안 전문가들이 소프트웨어 개발 과정을 제대로 이해하고 있지 못하다는 것이다. “정보보안 업계의 단골 멘트 중에 이런 게 있죠. 개발자들 아무리 가르쳐도 보안을 이해하지 못한다는 거요. 그런데 이건 반대로도 성립됩니다. 개발자와 보안 전문가가 같은 말을 쓰고 서로를 이해하는 게 너무 어려워요.” 슈비르카의 설명이다.
시큐어 코딩, 시큐어 코딩, 강조하는 게 요즘 대세지만, 개발 초기 단계에서부터의 ‘시큐어 코딩’을 하려면 전체 개발 프로세스에 대한 이해도가 뒷받침되어야 한다. 그러니 사실 시큐어 코딩 하라고 강조하는 보안 담당자들도 정확히 어떻게 해야 보안이 구축되는지 잘 이해하지 못할 때가 많다. 보안을 강조하기 전에, 개발자들의 업무를 얼마나 잘 이해하고 있는지 돌아볼 필요가 있다.
정책은 코드로 번역한다
현재 데브옵스 팀들의 가장 큰 화두는 자동화다. 자동화 기술을 공부하는 걸 넘어, 그걸 자기들 일상의 업무에 적용시키는 걸 계속해서 연구하고 있다는 뜻이다. 보안 역시 그래야 한다. 데브섹옵소를 진정으로 도입하고 싶다면, 그들만큼 신기술에 대해 잘 알고, 업무의 효율성을 높이기 위한 자동화 연구에 동참해야 한다.
보안과 관련된 각종 정책을 코드로 만들어보는 것이 보안 담당자들의 좋은 참여 방법 중 하나다. “보안의 입장에서 반드시 지켜야 할 것, 각 담당자 및 전문가들이 활동할 수 있는 안전의 영역을 정책으로 정해줘야 합니다. 그리고 이렇게 결정한 걸 자동화 시스템으로 정착시켜야 하죠. 이 정책을 일일이 가르쳐줘봐야 마찰만 또 생길 뿐입니다.”
툴도 데브옵스와 어울리지 않는다는 걸 이해하라
개발자를 대상으로 한 보안 훈련이 큰 효과를 나타내지 못하는 이유는, 결국 보안 툴들이 데브옵스 개념을 좇아오지 못하고 있기 때문이다. 정책도 좋고, 사람들도 데브옵스를 잘 이해하고 있어도 현장 툴이 기존 시스템에 부합한 것이라면 어떻게 변화가 일어나겠는가.
마샬은 “사용하기 편하고 손에 익은 툴을 포기하는 걸 훈련해야 한다”고 지적한다. “데브섹옵스라는 게 언급되기 전에는 DAST 툴이 큰 인기를 끌었었죠. 많은 기업들이 이에 적잖은 투자를 하기도 했고요. 하지만 이런 투자 때문에 데브섹옵스로의 전환이 가로막혀요. 예산 여유가 없다면 다양한 오픈소스 툴을 사용해보는 것도 도움이 될 것입니다.”
겁주기식 보안은 이제 그만
취약점에 대한 공포와 불확실성은 데브섹옵스와 잘 맞지 않는다. 슈비르카는 “보안 사고를 막는다면서 다른 부서 직원들에게 겁을 주는 행위를 멈춰야 한다”고 주장한다. “너 이거 안 지키면 감옥간다, 는 식으로 강조해봤자 장기적으로 보안에 대한 좋은 인상을 심어줄 수 없습니다. 그러면 보안 실천 수칙들을 기꺼워서 지키는 사람이 없어지죠.”
“보안 취약점이나 일반 소프트웨어 버그나 비슷하게 해결하는 게 가능합니다. 그러니 보안 취약점이라고 해서 괜히 일을 더 시끄럽게 만들지 마세요. 특히 공포 분위기 조성하는 건 정말 좋지 않습니다. 하나하나 부드럽고 쉽게 해결해나가는 편이 장기적으로는 훨씬 효과가 좋습니다. 공포 마케팅은 단기적은 효과만 있을 뿐입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
공포 분위기 조성하는 건 효과 짧아...보안도 개발 이해해야
[보안뉴스 문가용 기자] 소프트웨어 데브옵스와 정보보안이 제대로 만나면 기업으로서는 그보다 더 큰 축복이 없을 것이다. 하지만 이게 회사에게만 좋은 일은 아니다. 보안 구멍이 하나도 없으면서 속도도 나는 코딩이란, 개발자들도 늘 바라왔던 것이기 때문이다.
하지만 변화란 것이 그리 쉽지만은 않다. 데브옵스가 곧바로 적용될 것도 아니고 개발자들이 바라기만 한다고 적응되는 것도 아니다. 개발자들이나 보안 담당자나 사고방식, 기존에 일하던 습관, 소통 방법 등을 전부 바꾸기 위해 노력해야 한다. 이에 대해 보안 아키텍트인 미셸 슈비르카(Michele Chubirka)와 데브섹옵스 및 클라우드 전문가인 트로이 마샬(Troy Marshall)이 만나 이야기를 나눴다.
완벽할 수 없지만, 발전할 수는 있다
데브옵스의 핵심은 코드를 작은 단위로, 자주 활용하고 추가 및 수정해 소프트웨어를 점진적으로 발전시키는 것이다. 그런데 이런 식의 소프트웨어 개발론은 오래된 보안 전문가들에게 굉장히 낯선 것이다. 그들은 리스크 수위에 근거하여 소프트웨어를 가다듬고 분석해 보완하는 것에 더 익숙하다.
그래서 마샬은 “완벽을 기하려는 마음이 방해가 된다”고 말한다. “완성된 코드를 받아든 보안 전문가들은 구멍과 취약점을 하나라도 더 찾으려고 했거든요. 시간을 최대한 많이 쓰고 싶어하죠. 그러니 조금씩 조금씩 자꾸만 바뀌는 데브옵스의 각 단계가 성에 찰 수가 없어요. 하지만 그런 수정 과정이 계속 반복된다는 걸 기억해야 합니다. 한 번에 많은 시간을 할애하는 것에서부터 탈피하고, 조각난 시간들을 최대한 활용하는 것에 익숙해져야 하죠.”
마찰이 생기는 부분을 최대한 제거하라
IT 전문가들의 60%는 보안이 데브옵스의 억제제라고 여긴다. 보안이 점점 더 중요해지는 앱 경제 체제에서 이는 개선이 되어야 할 부분이다. “보안 담당자들의 역할은 리스크를 최소화하는 것이지, 모든 사람에게 ‘보안의 좁은 관점’을 장착시키려는 게 아닙니다. 안전이 중요하긴 하지만 그것이 전부인 건 아니죠.” 슈비르카의 설명이다.
또 슈비르카는 “데브섹옵스로 전환하려면 인력이 많이 필요한 수동적인 게이팅 과정들을 포기해야 한다”며 “비즈니스의 기존 워크플로우에 많은 ‘마찰’을 가져와야 할 필요가 있다”고 말한다. “마비에 가까운 장애나 혼란이 사내에 일어날지 모릅니다. 그야 말로 리스크가 크게 일어나는 것이죠,. 그런 환경에서라면 마찰이 일어나는 부분들을 깎아나가는 게 보안 담당자의 몫이 됩니다. 데브섹옵스를 통해 오히려 억제제가 윤활유가 되는 것이죠.”
개발자의 입장이 되어보라
데브옵스에 보안을 끼얹으려고 할 때 가장 문제가 되는 것 중 하나는 보안 전문가들이 소프트웨어 개발 과정을 제대로 이해하고 있지 못하다는 것이다. “정보보안 업계의 단골 멘트 중에 이런 게 있죠. 개발자들 아무리 가르쳐도 보안을 이해하지 못한다는 거요. 그런데 이건 반대로도 성립됩니다. 개발자와 보안 전문가가 같은 말을 쓰고 서로를 이해하는 게 너무 어려워요.” 슈비르카의 설명이다.
시큐어 코딩, 시큐어 코딩, 강조하는 게 요즘 대세지만, 개발 초기 단계에서부터의 ‘시큐어 코딩’을 하려면 전체 개발 프로세스에 대한 이해도가 뒷받침되어야 한다. 그러니 사실 시큐어 코딩 하라고 강조하는 보안 담당자들도 정확히 어떻게 해야 보안이 구축되는지 잘 이해하지 못할 때가 많다. 보안을 강조하기 전에, 개발자들의 업무를 얼마나 잘 이해하고 있는지 돌아볼 필요가 있다.
정책은 코드로 번역한다
현재 데브옵스 팀들의 가장 큰 화두는 자동화다. 자동화 기술을 공부하는 걸 넘어, 그걸 자기들 일상의 업무에 적용시키는 걸 계속해서 연구하고 있다는 뜻이다. 보안 역시 그래야 한다. 데브섹옵소를 진정으로 도입하고 싶다면, 그들만큼 신기술에 대해 잘 알고, 업무의 효율성을 높이기 위한 자동화 연구에 동참해야 한다.
보안과 관련된 각종 정책을 코드로 만들어보는 것이 보안 담당자들의 좋은 참여 방법 중 하나다. “보안의 입장에서 반드시 지켜야 할 것, 각 담당자 및 전문가들이 활동할 수 있는 안전의 영역을 정책으로 정해줘야 합니다. 그리고 이렇게 결정한 걸 자동화 시스템으로 정착시켜야 하죠. 이 정책을 일일이 가르쳐줘봐야 마찰만 또 생길 뿐입니다.”
툴도 데브옵스와 어울리지 않는다는 걸 이해하라
개발자를 대상으로 한 보안 훈련이 큰 효과를 나타내지 못하는 이유는, 결국 보안 툴들이 데브옵스 개념을 좇아오지 못하고 있기 때문이다. 정책도 좋고, 사람들도 데브옵스를 잘 이해하고 있어도 현장 툴이 기존 시스템에 부합한 것이라면 어떻게 변화가 일어나겠는가.
마샬은 “사용하기 편하고 손에 익은 툴을 포기하는 걸 훈련해야 한다”고 지적한다. “데브섹옵스라는 게 언급되기 전에는 DAST 툴이 큰 인기를 끌었었죠. 많은 기업들이 이에 적잖은 투자를 하기도 했고요. 하지만 이런 투자 때문에 데브섹옵스로의 전환이 가로막혀요. 예산 여유가 없다면 다양한 오픈소스 툴을 사용해보는 것도 도움이 될 것입니다.”
겁주기식 보안은 이제 그만
취약점에 대한 공포와 불확실성은 데브섹옵스와 잘 맞지 않는다. 슈비르카는 “보안 사고를 막는다면서 다른 부서 직원들에게 겁을 주는 행위를 멈춰야 한다”고 주장한다. “너 이거 안 지키면 감옥간다, 는 식으로 강조해봤자 장기적으로 보안에 대한 좋은 인상을 심어줄 수 없습니다. 그러면 보안 실천 수칙들을 기꺼워서 지키는 사람이 없어지죠.”
“보안 취약점이나 일반 소프트웨어 버그나 비슷하게 해결하는 게 가능합니다. 그러니 보안 취약점이라고 해서 괜히 일을 더 시끄럽게 만들지 마세요. 특히 공포 분위기 조성하는 건 정말 좋지 않습니다. 하나하나 부드럽고 쉽게 해결해나가는 편이 장기적으로는 훨씬 효과가 좋습니다. 공포 마케팅은 단기적은 효과만 있을 뿐입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
