아키텍처에서 취약성의 근본 원인 찾아내기

Dr. Carol Woody
CERT 부문 사이버 보안 엔지니어링 팀 관리자
복잡한 네트워크 시스템이나 시스템 오브 시스템의 보안 소프트웨어를 정의, 취득, 개발 및 관리하고 측정, 유지하는 작업 연구

Rick Kazman
하와이 대학 교수
소프트웨어 아키텍처, 소프트웨어 공학 경제학, 소프트웨어 시각화 연구

시스템에 구현된 아키텍처 설계 상의 약점은 다른 종류의 취약성에 비해 시간이 지나가면 갈수록 그 문제를 수정하기가 매우 어렵기 때문에 아키텍처 취약성에 좀 더 관심을 가져야 합니다. 아키텍처 설계 약점을 초기 단계에서 발견하여 수정할 수 있다면, 라이프사이클 기간 동안 더 편하게 시스템을 사용할 수 있습니다.

아키텍처에는 특정 패턴이 있는데 이 패턴은 필요한 요구사항에 따라 설계됩니다. 여러 종류의 아키텍처 패턴이 각각 보안에 어떤 영향을 주는지 이해하는 것이 매우 중요한데, 중요성을 아키텍처 커뮤니티나 설계 및 구현 커뮤니티에서 충분히 인식하지 못하고 있습니다. 단순한 패턴 상의 문제가 아니라 개발자들의 잘못된 인식 때문에 쓸모 있는 패턴이 문제를 일으키게 됩니다. 반드시 사용해야 하는 패턴을 사용하지 않는 개발자도 있고 사용하지 않았으면서 사용했다고 착각하는 개발자도 있습니다. 이런 이유로 아키텍처 패턴이 취약성의 주된 원인이 될 수 있습니다.

라이프사이클 초기의 취약점을 정확히 진단할 수 있는 도구가 없습니다. 초기 단계에는 각 시스템 조각이 어떻게 연결되고 설계되었는지 만 파악할 수 있을 뿐입니다. 설계 초기 단계에는 앞으로 문제가 될 소지가 있는 부분을 정확히 집어낼 수는 없지만, 관심을 두고 지켜봐야 하는 영역을 점차 좁혀 나가면서 문제를 찾아 내야만 노력과 시간을 줄일 수 있습니다.

시스템 진단 도구와 관련하여 Drexel 대학과 공동 연구를 진행하면서 좀 더 정확도가 높은 스트럭쳐를 얻어낼 수 있었습니다. 이 공동 작업으로 아키텍처 분석을 수행하면서 수많은 메소드를 개발했습니다. 잠재적인 리스크를 찾아내는 효과적인 방법을 개발하려 했지만, 발견한 리스크들의 범위가 너무나 넓었습니다. 좀 더 범위를 좁혀서 아키텍처 약점이나 오류를 찾아낼 수 있는 기능을 개발하고자 했습니다.

지난 5-6년 간 개발한 것은 기존 코드 베이스의 리버스 엔지니어링을 가능하게 하는 설계 재현(Design Representation)이었고 관련 도구도 개발했습니다. 아키텍처 정보, 설계 정보를 추출하고, 의미 있는 방식으로 정보를 조작한 다음 조작된 형태의 정보를 분석하여 아키텍처 오류를 찾아내는 것입니다. 과거에는 모든 리버스 엔지니어링이 전적으로 수작업을 통해 이루어졌기 때문에 매우 노동집약적이었지만, 지금은 이 모든 과정이 자동화 되어서 투입되는 비용과 시간을 크게 줄었습니다.

코드를 리버스 엔지니어링하기 위해 현재 Understand라는 상용 리버스 엔지니어링 툴을 주로 사용하고 있습니다. 엔터프라이즈 아키텍트 로부터 정보를 받아 들이면서 파일 간의 의존도를 발견할 수 있었고, A 파일, B 파일 그리고 두 파일 사이의 관계라는 3중 구조를 생각할 수 있게 되었습니다. 이 3중 구조를 바탕으로 거대한 매트릭스를 만들어 냈습니다. 바로 설계 스트럭처 매트릭스(DSM)입니다.

이 설계 스트럭처 매트릭스(DSM)는 분석과 조작이 가능합니다. 개발한 알고리즘을 통해 설계 규칙 계층 알고리즘이라 부르는 클러스터를 만듭니다. 설계 규칙은 시스템의 중요한 인터페이스나 중요한 클래스와 비슷합니다. 예를 들면, 시스템에서 Abstract Factory를 사용하는 경우, 그 abstraction에 의존하는 많은 다른 파일이 생성됩니다. Abstract Factory 인터페이스를 구현하고, 인터페이스에서 상속 받고, 인터페이스에 의존하고, 인터페이스를 사용하고 종합하는 클래스가 생깁니다. 이 abstract factory 재현은 설계 규칙이고 많은 파일이 그 설계 규칙에 의존하게 됩니다. 의존 관계에 따라 아키텍처를 클러스터로 묶어야 하는데, 최상위에는 시스템에서 가장 중요한 설계 규칙인 선두 클래스가 위치합니다.

시스템의 다른 많은 파일들이 의존하는 파일이나 클래스가 바로 선두 클래스인데요. 파일들을 묶어 계층으로 만들면, 최상위 파일에 의존하는 파일들이 하위 계층이 됩니다. 이런 식으로 계층 구조(Hierarchy)가 이루어집니다. 매우 간단한 예로 의존 관계 주기도 찾아낼 수 있습니다. A 파일이 B 파일을 호출하고, B 파일이 C 파일을 호출하고, C 파일이 A 파일을 호출하는 경우는 100% 잘못된 프로그래밍입니다. 그 이유는 세 파일 중 하나를 변경했을 때 일어날 수 있는 파급 효과를 예측할 수 없기 때문입니다. 하나의 파일을 수정했을 때 발생할 미묘한 변화를 알아내는 것도 쉽지 않습니다. 프로그래머는 수백만 줄의 코드를 확인해야 하기 때문에 이러한 미묘한 문제를 쉽게 찾아낼 수 없습니다.

요약 더보기       

솔루션 개발 사례 연구 - Apple

글로벌 솔루션 개발 회사의 특징을 살펴보는 마지막으로 애플(Apple)을 살펴보도록 한다. 애플은 미국 뿐 만 아니라 전세계적에서 가장 잘 알려진 회사 중 하나로, 개인용 컴퓨터를 생산하던 전자제품 회사였다. 이후, 아이팟을 비롯해서 아이폰, 아이패드 등을 개발하여 독자적인 스마트 디바이스 군을 만들었고, 디바이스에서 사용되는 솔루션을 만들면서 소프트웨어 회사로도 최고로 인정받고 있다. 이번 회에서는 애플의 추구하는 사업 특징과 그에 따른 솔루션 관점의 의미를 살펴보도록 한다. 획기적인 기술과 기획력으로도 어려움을 겪는 다른 솔루션 개발 회사와 비교해보며 솔루션 개발에 필요한 인사이트를 찾기를 기대한다.


애플의 사업 분야 변화

애플은 글로벌 혁신기업으로 잘 알려져 있다. 기존에 경직된 생각에서 벗어나 일반 사람들이 생각하지 못하는 부분을 리딩하고 있다. 애플의 시작은 애플과 매킨토시라는 이라는 PC(개인용 컴퓨터)에서 시작했다. 90년대 당시에는 PC(개인용 컴퓨터) 시장의 벽이 낮지 않았기 때문에 매킨토시는 디자인에 특화되었다는 특징으로 사용자들에게 접근하였다. 이후 사용성에 대한 고민이 많이 반영되면서 아이맥, 아이팟을 출시하였고 제품의 디자인을 특성화 시킨 디바이스들을 만들기 시작했다. 이후, 아이팟에 휴대폰 기능을 추가한 아이폰, 매킨토시나 아이맥에서 사용하던 것에 휴대성을 보완한 아이패드가 나왔고 현재는 스마트 디바이스의 생산 라인업을 갖춘 상태다.

애플의 사업 전략 중 가장 큰 특징은 일반적인 PC(개인용 컴퓨터)로 알려진 윈도우 기반의 PC가 아닌 독자적인 하드웨어를 생산했다는 점이다. 이 것은 애플이 독자적인 디바이스 생태계 뿐 만 아니라 독자적인 소프트웨어 생태계를 구축할 수 있는 이유이기도 하다. 독자적인 디바이스에는 독자적인 소프트웨어나 컨텐츠를 제공해야 하기 때문이다.

그림1에서 보는 것처럼, 애플의 부흥은 스티브 잡스가 CEO로 취임한 이후부터 이다. 스티브 잡스로 인해 애플의 제품이 구축되고 이 제품들이 전세계 스마트 디바이스 시장을 주도한 것은 의심할 여지가 없이 사실이지만 이 것 외에 또 다른 애플의 전략이 있었다고 볼 수 있다. 초기의 애플은 비전과 조직관리를 스티브 잡스, 개발을 스티브 워즈니악, 마케팅에 마이크 마큘라가 맡아 성장을 이루었다. 이후 80년대 중반 이후, 스티브 잡스가 회사를 나가면서 역할 분담이 깨지게 된다. 그리고, 1997년 스티브 잡스가 다시 돌아오면서 지금의 애플 시대를 맞이하게 된다. 밖으로는 스티브 잡스의 카리스마나 팀쿡의 개발 능력 등이 애플의 성공 요소로 보고 있지만, 안으로는 철저한 역할 분담으로 최적의 판단을 하게 되고, 적절한 시점에 필요한 제품이 나오게 되는 효과를 가져왔다.

 애플의 의사결정 역할 분담

더보기      

소프트웨어 운영에 필요한 유지보수 품질 확보 방안

소프트웨어 개발 프로젝트가 끝나고 나면 유지보수에 대한 고민이 시작된다. 어디까지 무상으로 해줘야 하는지, 상주 인원은 어느 정도 투입해야 하는지, 문서 작업의 범위는 어디까지 인지 등 많은 항목들을 확인해야 한다. 이와 함께, 완성된 소프트웨어를 운영하기 위해 준비해야 하는 품질 방안 수립에도 많은 시간을 할애한다. 이번 회에서는 소프트웨어 개발 프로젝트 종료 후 운영과 유지보수에 필요한 품질 확보 방안에 대해 로만소프트 이영환 대표를 만나 자세한 사항을 들어본다.

Q: 본격적인 이야기 전에 유지보수 품질 방안에 대해 설명을 부탁 드립니다. 
개발자들에게 개발 프로젝트의 종료는 매우 기다려지는 일이지만, 유지보수라는 프로젝트가 다시 기다리고 있죠. 많은 개발자들은 너무 힘들었던 개발 프로젝트 때문에 유지보수 프로젝트는 하지 않으려 하지만 쉽지 않은 것이 사실입니다. 안타까운 얘기이지만, 소프트웨어가 고객들에게 납품될 때는 항상 결함을 안고 있습니다. 소프트웨어 자체의 오류도 있겠지만, 무엇보다 고객이 원하는 요구사항이 잘못 동작하거나 제대로 반영되지 않은 경우도 결함이라고 얘기합니다. 그림1을 보시면, 2000년 전후의 개발과 유지보수 프로젝트의 비율을 나타내고 있는데 유지보수의 비율이 더 높아진 것을 볼 수 있고 지금은 더 줄어드는 추세입니다.

 <그림1> 개발과 유지보수 프로젝트의 비율 

출처: Roger S. Pressman의 Software Engineering

위 그림이 나타내는 것은, 유지보수의 중요성이 점점 높아진다는 것입니다. 흔히, 유지보수는 만들어진 소프트웨어를 운영하면서 오류가 발생하면 일부 수정해주고 새로운 요구사항을 추가로 개발하는 정도로 이해하는 경우가 많습니다. 

더보기