작아진 개발 작업 단위 = 많아진 보안 관리 대상
분리된 정책 적용, 통신 관리, 데이터의 암호화 갖춰야

[보안뉴스 문가용] 애플리케이션 개발의 환경이 ‘마이크로서비스’와 ‘컨테이너’ 위주로 돌아가고 있다. 마이크로서비스란 큰 애플리케이션을 기능에 따라 작은 ‘서비스’ 유닛으로 나누는 것이고, 컨테이너는 이런 마이크로서비스들의 가장 자연스러운 플랫폼으로 인식되고 있다. 수많은 마이크로서비스를 원활하게 돌리기 위해 여러 컨테이너를 사용하기도 한다.


말했다시피 각 마이크로서비스는 기능별로 독립되며, 전체 애플리케이션은 이 작은 서비스들의 상호작용으로 작동한다. 커다란 애플리케이션들은 10개에서 20개까지의 마이크로서비스로 구성되어 있다. 그러므로 애플리케이션들마다 물리적인 특성이 완전히 달라질 수밖에 없게 된다. 또한 보안에 대한 새로운 개념을 필요로 하게 된다.

개념 1 : 엔드포인트의 다량화
애플리케이션의 기능을 기능별로 나눠놓는 것은, 네트워크의 관점에서 보면 고유한 엔드포인트가 늘어난다는 뜻이 된다. 이전에는 애플리케이션에 가해지는 공격이 몇 개의 애플리케이션 서버를 통해서 들어왔다면 이제는 이 모든 엔드포인트들을 통해 공격이 들어올 수 있게 되었다는 뜻. 더 많은 포트들이 열려 있고, 더 많은 API들이 노출되어 있으며 더 많은 사용자들이 권한을 가지게 되었다.

개념 2 : 수명이 짧은 IP와 흐려진 경계선
컨테이너들은 수초 내에 생겼다가 사라진다. 전통적인 의미에서의 경계선은 사라지고 있다. 동적 주소와 마이크로서비스의 크기 조정이 자유로워지면서 IP 주소에 대한 통계를 낸다거나 네트워크 경계선을 보호한다는 개념이 더 이상 통하지 않게 되었다. 조닝(zoning)이나 VLAN처럼 애플리케이션들을 고립시키기 위한 여러 네트워크 구조 및 기능들 역시 활용도가 많이 떨어지고 있다.

개념 3 : 컨테이너의 자유로움과 비가시성
컨테이너 모델의 장점과 전통적인 보안 원리는 정면으로 충돌한다. 왜냐하면 컨테이너는 마이크로서비스들 사이 혹은 클라우드 사이에서 자유롭게 오가는 기반구조가 되기 때문이다. 그런 와중에 컨테이너의 IP 주소 또한 호스트 바깥에서는 포착하기 매우 어렵게 된다. 예를 들어 도커(Docker)라는 컨테이너는 마스커레이딩(masquerading)이나 네팅(natting) 이라는 걸 활용하는데, 이 때문에 도커 컨테이너는 호스트 외부에서는 전혀 시야에 잡히지 않게 된다. 즉, 외부 솔루션 및 기기로 보안 설정을 하는 게 불가능해진다.

개념 4 : 동-서 트래픽의 증가
마이크로서비스와 컨테이너 환경은 개발자들이 새로운 서비스와 결과물을 더 빠르고 효율적으로 출시할 수 있게 해주었다. 하지만 세상에 공짜는 없는 법. 그 대가로 보안이 이전보다 더 복잡해졌다. 한 마디로 관리자 입장에서는 관리할 게 더 많아졌는데, 무수한 마이크로서비스를 일일이 관리하는 건 불가능에 가까워졌기 때문이다. 클라우드와 데이터도 덩달아 늘어나고 있고, 이 때문에 보안의 눈으로 모든 것을 관찰하는 건 어려운 일이 되었다. 이런 것들이 늘어나면서 동-서 트래픽도 자연스럽게 늘어 일과 리스크가 동시에 가중되고 있다.

개념 5 : 더 빨리, 더 많이
이런 식의 애플리케이션 개발 환경이 대두되고 있는 건, 이렇게 해야 개발자들이 더 빨리 더 많은 상품을 내놓을 수 있기 때문이다. 이런 흐름 자체도 보안에 취약하다. 상품 하나하나의 보안성을 보장할 수 없는 상태인데, 결국 그런 불완전한 것들이 시장에 다량 쏟아지는 것이기 때문이다. 시한폭탄과 같은 것들이 사이버 공간 여기저기에 깔리고 있는 꼴. 아직 보안의 속도가 생산의 속도를 따라가고 있지 못하기에 이는 더욱 심각하다.


이런 상황에서 보안의 역할이 더욱 중요해질 것이라는 건 불 보듯 뻔한 일. 중요한 건 보안의 속도 역시 빨라져야 한다는 것이다. 위에 설명한 개발 프로세스를 한 마디로 아울러 데브옵스(DevOps)라고 하는데, 이것이 점점 중요한 개념이 되어가고 있고, 많은 기업들이 이 데브옵스 체제를 도입 중에 있다. 중요한 건 데브옵스를 따라 새로운 보안 체제도 들어서야 하는데, 먼저 쉽게 해볼 수 있는 보안 실천 사항들을 정리한다.

실천 사항 1 : 마이크로서비스 간 통신을 모니터링하라
보안 담당자들은 마이크로서비스들 사이에 일어나는 상호작용에 대해 잘 이해하지 못하고 있는 경우가 많다. 이는 비단 마이크로서비스들의 네트워크 상의 상호작용만 말하는 것이 아니라 개발자들 간의 소통도 아우른다. 부품을 나눠 쓰다보면 자연히 사용자들(이 경우는 개발자들) 사이에서 대화가 오가기 마련이고, 정보가 교환된다. 그러므로 여기엔 일정한 규칙이 필요하다. 트래픽과 소통 모두에 적절한 규칙만 부여해도 완성된 애플리케이션의 보안 수준을 크게 높일 수 있다.

실천 사항 2 : 애플리케이션과 서비스들을 분리하라
마이크로세그멘테이션(Micro-segmentation)이란 개념이 있다. 애플리케이션들을 아주 작은 보안 장치들로 만들어진 벽 안에 따로따로 가두고 일정한 정책에 기반을 두고 관리하는 것이다. 예를 들어 생산 환경을 개발 환경과 분리하는 등 굵직한 개념으로 가져갈 수도 있고 한 온라인 쇼핑몰 페이지에서 카탈로그 서비스와 주문 관리 서비스를 분리하는 등 세밀하게 가져갈 수도 있다. 이런 식의 분류 작업이 마이크로서비스로 구성된 애플리케이션에도 잘 통하게 하려면 서비스 인스턴스를 실행하는 모든 호스트의 클러스터 단계에서부터 정책을 강력하게 적용해야 한다.

실천 사항 3 : 데이터의 암호화는 필수다
애플리케이션들을 구성하는 세밀한 요소들이 늘어나면서, 그 요소들 간의 소통도 늘어났고, 그에 따라 데이터도 늘어나고 있다고 위에서 언급했다. 즉 트래픽이 엄청나게 증가하게 되는데, 이 트래픽이 대중 인터넷과 연결되어 있는 경우가 많을 수밖에 없다. 그렇다면 통신들과 데이터를 암호화하지 않는다는 건 보안을 하지 않겠다는 것이나 다름없다. 또한 인증서는 최신화를 반드시 시켜놓고 소프트웨 버전도 꼼꼼하게 관리해야 한다.

실천 사항 4 : 정책 관리와 환경설정 관리는 자동으로 처리한다
복잡한 구조의 네트워크와 다량의 데이터를 관리하려면 반복해야 하는 단순작업들도 상당히 늘어난다. 그리고 똑같은 작업을 대량으로 반복하다보면 인간적인 실수가 일어날 확률이 높다. 이런 작업들 중 하나가 환경설정과 정책 관리다. 이는 자동으로 처리하게 하는 편이 훨씬 높은 효율을 자랑한다. 사람도 쓸데없이 지치지 않을 수 있고, 사소한 업데이트 하나 깜빡해서 대형 사고가 터지는 걸 막을 수도 있다.

글 : 랑가 라자고팔란(Ranga Rajagopalan)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>