[넋두리 3] 12. [판의 개혁] 개발보안의 미래

보안과 개발의 공존을 꿈꾸다

  DevOps라는 용어가 한창 IT업계의 뜨거운 감자로 언급되던 때가 있었다. 빠른 개발을 위한 Agile 방법론의 일환으로 개발(Development) 조직과 운영(Operation) 조직이 함께 개발의 초기부터 운영 단계까지 함께하며 신속하게 IT프로젝트를 진행하자는 개념으로 나온 용어다.

  얼마의 시간이 흐른 후 하나의 의미를 더한 DevSecOps라는 용어가 또 여기저기서 언급되기 시작했다. 기존의 용어에 Sec를 더해 개발조직, 보안(Security) 조직, 운영조직이 함께 힘을 모아 개발의 초기단계부터 보안까지 고려한 신속한 IT프로젝트를 진행하자는 개념이다. 기존 DevOps 방식이 보안에 취약하다는 의견을 반영한 것이다.

  이렇듯 보안은 IT개발자들이 모두 혀를 내두르며 진저리를 칠 정도로 IT사업 모든 영역에 꼭 요구되는 필수사항으로 자리 잡고 있다. 그걸로도 모자라 개발자들은 그냥 개발이 아닌 개발보안을 준수하도록 요구받고 있는 실정이다.

  개발보안. 말 그대로 개발과 보안의 합성어로 개발과정에서 보안에서 요구되는 요구사항들을 잘 지키면서 개발하라는 의미다. 그래야 취약점도 안 나오고 해커의 해킹으로부터 안전할 테니 문제 생기지 않게 하라는 개발자들에 대한 엄포성 의미도 내포하고 있다.

  문제는 이러한 요구가 온전히 개발자만을 향하고 있어 개발자들의 반발이 심하다는 것이다. 안 그래도 시시각각으로 빠르게 변화하고 있는 IT기술의 변화를 따라잡느라 힘든 개발자들에게 보안영역의 기술까지 습득하기를 강요하기 때문이다. 보안의 영역도 IT기술의 발전속도를 따라 빠르게 변화하고 있어 보안전문가들조차도 변화의 속도를 따라가느라 힘들어하는 판국인데, 비록 보안의 일부 영역이더라도 개발자들에게는 큰 부담이요 불만이 될 수밖에 없다. 그 결과 개발자들은 외치는 것이다. "개발자는 보안을 신경 쓰고 싶지 않다"라고, "보안은 보안담당자들이 책임져달라"라고 말이다.

  아직까지 뚜렷한 해결방안이 도출되지 못한 개발보안의 문제는 지금까지 삐걱거려 왔고, 앞으로도 계속 삐걱거리게 될 전망이다. 이 문제가 해결되지 않아서 새로운 개발사업이 진행되면 예전의 취약점이 반복되고 또 반복되는 악순환의 폐해를 겪었고, 그 결과가 침해사고로 이어지는 상황이 반복되고 있다.

  보안분야에 몸담은 사람으로서 이 문제에 대해 오랫동안 고민하고 또 고민해 왔다. 개발자가 보안을 신경 쓰지 않아도 되면서 보안을 유지할 수 있는 방법, 새로운 개발사업이 진행되어도 보안을 유지할 수 있는 방법, 개발보안 중 보안에 대한 부분을 보안조직이 담당할 수 있는 방법을. 그리고 나름의 방안으로 생각한 것이 바로 "API 기술을 활용한 개발보안 표준 정립"이다.

  돌이켜 생각해 보면, 나름 오랜 시간 동안 보안분야에서 활동해 왔지만, 기업서비스에 대한 모의해킹 과정에서 취약점이 존재해 해킹에 성공하는 부분은 일부 특이한 부분을 제외하고는 대체로 모든 기업에서 대등 소이하다. 예를 들면 로그인 화면, 파일 다운로드 화면, 회원정보 조회 화면, 게시판 화면 등이 대표적이다. 이런 부분에서 취약점이 나오고, 설사 조치하더라도 추가 개발과정에서 또 취약점이 나오는 순환이 반복되는 것이다. 취약점을 없애기 위해 조치된 프로그램 소스가 추가 개발과정에서 변경 또는 훼손되는 것이 원인이다. 따라서 그에 대한 해결 방안은 취약점에 대해 조치된 원본이 변경이나 훼손되지 않도록 하는 것이 중요하다.

  "API 기술을 활용한 개발보안 표준 정립"이 그 방안이 될 수 있다. 로그인 화면을 예로 들면, 각종 취약점에 대해 조치된 안전한 로그인 소스 프로그램을 API 기술을 통해 표준화하고, 기업(또는 그룹)에서 IT프로그램 개발 시 로그인 부분에는 해당 API 모듈을 사용하도록 하는 것이다. 이 방식에는 몇 가지 장점이 존재한다.

첫째, 개발자는 보안을 신경 쓰지 않아도 된다. API 모듈은 개발보안 표준을 담당하는 별도의 조직에서 관리하기 때문이다.

둘째, 보안은 보안담당자가 책임진다. 만약 취약점이 발견되면 보안담당자가 해결방안을 찾고, 수정은 개발보안 표준을 담당하는 조직에서 조치하고 API 모듈을 재배포한다.

  의외로 문제에 대한 해결방법은 단순하고 쉽다. 그리고 현실은 쉬울수록 실행하기 어렵다. 모든 작업에는 예산과 인력이 필요하기 때문이다. 어떤 부분들을 API모듈로 정립해야 하는지에 대한 사전조사, API모듈을 개발하는 작업, API모듈을 배포하고 적용해 나가는 과정, 사후관리까지 하나하나가 모두 투자이고 비용이다. 그리고 이 작업에는 제법 많은 예산이 소요된다.

  하지만 개발보안으로 인한 개발조직과 보안조직의 계속되어 온 반목을 불식시키고, 지속적인 IT서비스의 안전을 담보할 수 있다면 능히 감내해야 할 투자이자 비용이다. 이러한 모습이야말로 보안과 개발이 평화롭게 함께 나아가는 진정한 DevSecOps가 아닐까 싶다.

[넋두리 2] 8. 좋은 개발보안이란 무엇인가! https://brunch.co.kr/@sunwoodowoo/42