클라우드를 위한 데이터 보안 아키텍처

카페 > 뉴딜코리아 홈페이지 | 뉴딜코리아
http://cafe.naver.com/rapid7/2329

 

클라우드를 위한 데이터 보안 아키텍처

프롤로그 - 무관심에서 관심으로

뭔 뜬구름 잡는 소리야?

‘클라우드’혹은‘클라우드 컴퓨팅’이라는 개념 이 최초 소개됐을 때, 대다수 IT종사자들의 반응은 ‘그게 뭔데?’였다. 이러한 반응은 기술 자체에 대한 이해가 부족해서 개념을 이해하지 못하겠다는 것이 라기보다는, 실제로 그러한 세상, 즉 클라우드가 IT 의 핵심 인프라로 자리 잡는 세상이 오지는 않을 것 이라는 추측이 내포된 반응이었다고 생각된다.

그런데 지금은 어떠한가? 빅데이터, IoT(사물인 터넷), AI(인공지능) 등 IT트렌드를 말해주는 대표 적인 키워드들이 있지만, 그 이면에‘클라우드’라 고 하는 인프라가 있음을 누구도 부인하기 어려운 세상이 오고야 말았다.

가긴 가야겠는데…

상황이 이러다보니 당장 클라우드를 도입함으로 써 이득을 얻을 수 있는 회사는 물론, 당장 필요함 을 느끼거나 비용절감 등의 이득에 대해 불투명한 회사까지도 시대의 흐름(?)에 뒤쳐지지 않기 위해, 그리고 앞으로의 경쟁력 강화를 위해 클라우드의 도입을 고민하고 있다.

그런데 막상 클라우드로의 전환을 구상하기 시작 하면 쉽게 결론 내리기 어려운 고민거리가 한두 가 지가 아니다. 클라우드를‘온프레미스(On- Premise, 사내 직접 설치 운영 환경)’의 대체 인프 라로 사용할 것인지 아니면 보완 인프라로 사용할 것인지와 같은 클라우드 도입의 근본적인 고민부 터, 가장 현실적인 문제인 비용효율성 문제(물론 클 라우드 도입의 핵심은 비용이 아닐 수 있는데, 이 글에서 다루기에는 너무 큰 내용이어서 추가적인 설명은 생략한다.), 그리고 도대체 클라우드를 믿을 수 있는가 하는‘보안’에 대한 고민까지 잠깐만 생 각해도 머리가 아파지는 문제를 여러 개 찾아낼 수 있다.

편리할 것이냐, 안전할 것이냐, 이것이 문제로다

조금 다른 얘기로 넘어가서, 세상에는 두 가지 목 적을 동시에 달성하기 어려운 것들이 꽤 있다. 대표 적으로 보안에 있어‘편리함’과‘안전함’이 그 중 하나가 아닐까 한다. ‘편리함’을 강조하다보면‘안 전함(보안성)’이 약해지고, ‘안전함(보안성)’을 강 조하다보면‘편리함’이 약해진다.

예를 들어 현관문의 물리적 보안을 생각해보자. 단순히 비밀번호 네 자리를 입력하도록 설정해놓은 보안장치는 숫자를 4번만 입력해 문을 열 수 있어 편리함이 뛰어나지만, 10,000번만 시도하면 누구 나 열 수 있는 취약점(?)도 갖고 있다. 즉, 편리한 만 큼 안전성은 떨어지는 것이다. 반대로, 비밀번호 8 자리와 지문인식을 결합한 보안장치를 갖추고 있는 현관문은 상당히 높은 수준의 안전성을 갖췄다고 할 수 있으나, 지문인식률이 떨어지거나 하는 경우 에는 굉장히 불편한 보안장치가 될 것이다.

두 마리 토끼, 잡을 수 있다

위에서‘편리함’과‘안전함’은 과거의 일반적인 상황에서 상 호 배타적인 것처럼 기술됐다. 그런데, 정말 이 두 가지가 상호 배타적인 것이어서 두 개의 장점을 한꺼번에 취할 수 있는 방 법이 없는 것일까? 필자는‘그렇지 않다’고 본다. IT에 있어 ‘편리함과 강력한 보안’이라는 두 마리 토끼를 함께 잡을 수 있 는 방법이 있으니, 그것은 클라우드를 도입하는 것이다.

정말 클라우드가 보안적으로 안전한 것일까? 만일 그렇다면 왜 클라우드를 도입하고자 하는 회사에서 그렇게까지 보안에 대해 고민하는 것일까? 물론 클라우드 제공업체의 상황에 따라 제공하는 보안의 정도가 달라서 그럴 수도 있겠으나, 그것보다 더 큰 이유는 클라우드 보안 자체에 대한‘믿음’이 없기 때문인 것으로 생각된다.

정말 믿어도 될까?

사실 클라우드를 보안적으로 정말 믿을 수 있는가 하는 내용 은 필자가 정의 내리기에는 너무 큰 것인지도 모른다. 다만, 다 음 정도는 얘기할 수 있을 것 같다. 스위스은행 금고에 돈을 맡 겨 두는 것과, 집안에 좋은 금고를 마련해 현금을 쌓아두는 것 중 어느 쪽이 안전할까? 적어도 필자는 스위스은행이 더 안전 하다고 본다. 비록 확률은 낮겠으나, 집에 있는 금고의 경우 화 재나 지진 등 천재지변에 의한 사고에 대한 대비가 어려울 수 밖에 없기 때문이다.

클라우드도 이와 유사하다고 본다. 최고 수준의 전문적인 서 비스를 제공하는 클라우드 업체라면, 온프레미스에서 자체적 으로 보안을 구축하고 운영하는 경우보다는 훨씬 더 높은 수준 의 보안을 제공할 것이라고 생각한다. 데이터센터의 안전성, 규제 준수, 내부자 관리 등‘전문성’의 우위로부터 오는 이점이 반드시 있을 것으로 보이기 때문이다.

클라우드 보안, 우선 고려사항은?

분명한 것은 클라우드 보안이 단편적인 특정 보안영역의 논 리로얘기될수는없다는것이다. 즉‘네트워크보안’,‘ 물리적 보안’,‘ 내부자보안’,‘ 데이터보안’등포괄적인보안제어를 고민해야 하기 때문이다.

그런데 만일 해커가 클라우드를 해킹해 뭔가를 얻고자 한다 면, 최종적인‘그것’은 무엇일까? 아마도 그것은‘개인정보’ 등을 포함하는 기업 데이터일 것이고, 보안을 이유로 클라우드 전환을 망설이는 회사들의 가장 큰 우려사항도‘데이터 유출’ 일 것이다. 결국 특정 회사가 클라우드로의 전환을 안심하고 추진할 수 있으려면, 클라우드 제공업체가‘데이터 안전성’을 확보할 수 있는 제대로 된‘데이터 보안’을 제공해야 한다.

데이터 보안은 클라우드 보안 전체로 보면 하나의 구성요소 지만, 데이터 보안 자체로도‘심층방어(Defense-In-Depth)’ 개념을 포함하도록 구성돼야 한다. 이러한 아키텍처를 구성하 는 대표적인 기술로는‘데이터 암호화’,‘ 권한제어 및 접근제 어’,‘ 표시제한’,‘ 데이터변조’등이있다. 데이터보안을위 한 세부항목들에 대해 좀 더 자세히 살펴보도록 하자.

클라우드 내 정적인 데이터 보안 - 데이터 암호화

만일 DB(데이터베이스)에 기록된 데이터가 암호화돼있지 않 으면, DB를 거치지 않고 DB에 있는 중요 데이터를 유출하는 것이 가능하게 돼 큰 위험을 초래할 수 있다. 거꾸로 말하면, DB에 기록된 데이터의 암호화만 제대로 하더라도 중요 데이터 유출의 큰 경로 하나를 차단하는 셈으로, 이 때문에 데이터암 호화는 클라우드 데이터 보안에 있어‘기본적이지만 가장 중요 한 요소’중 하나가 된다.

클라우드의 데이터암호화를 위해 고려해야 할 사항은 어떤 것이 있을까? 첫째, 암호화를 적용하더라도 기존 DB성능 저하 를 최소한으로 유발해야 한다. 그래야 DB암호화 적용에 의한 아키텍처 변경 및 관련 작업이 최소화될 수 있다. 둘째, 구축이 쉬워야 한다. 만일 데이터암호화를 위해 애플리케이션의 전체 적인 수정 등이 필요하다면, 이는 집 열쇠를 새로 달기 위해 집 을 새로 짓는 것과 같은 결과가 되므로 말이 안 되는 상황이라 할 수 있다. 구축과정이 복잡하면 암호화의 실제 진행이 대단 히 어렵다는 얘기다. 셋째, 암호화의 가장 중요한 요소 중 하나 인 암호화 키를 클라우드 내 안전하게 보관할 수 있는 방법이 제공돼야 한다. 그리고 마지막으로는 국제표준 암호화 알고리 즘을 제공하고, DB에서 제공하는 여러 가지 도구들과의 통합 성이 지원돼야 한다.

클라우드 내 동적인 데이터 보안 -표시 제한 (실시간 데이터 변조)

정상적인 접근 권한 및 경로를 통해 클라우드 데이터에 접속 한 사용자들에 대해서도 데이터가 다르게 표시돼야 하는 경우 가 있다. 예를 들어 콜센터 애플리케이션의 경우에는 상담을 담당하는 직원과 과금을 담당하는 직원이 보는 정보의 내용이 달라야 하는 경우가 있을 수 있다. 좀 더 구체적으로 얘기하면, 고객의 카드번호정보는 상담직원이 알 필요 없는 정보지만 과 금담당에게는 필요한 정보이므로, 누가 어떤 애플리케이션 화 면에서 데이터를 조회하는가에 따라 데이터가 다르게 표현될 필요가 있는 것이다. 이러한 기능을 가리켜‘표시제한(실시간 데이터변조)’기능이라고 부른다.

클라우드 관리자 및 DBA 권한제어 통한 데이터 보안 -접근 제어

DB와 관련해 DBA의 권한은 실로 막강하다. 그런데 잘 생각 해보면 DBA는 DB가 잘 동작할 수 있도록 지원하는 사람일 뿐, DB에 저장된 모든 데이터를 자유롭게 조회하고 변경할 필 요가 있는 사람은 아니다. 즉 인사데이터는 인사업무를 관장하 는 사람만 볼 수 있어야 하고, 재무데이터는 재무업무를 관장 하는 사람만 볼 수 있어야 하는 것이다.

클라우드 관리자도 마찬가지다. 클라우드를 사용하는 고객 이 편리하고 안정적으로 모든 서비스를 사용하게 하는 것이 임 무일 뿐, 데이터 자체에 접근할 필요는 없는 사람이다. 그러므 로 데이터에 대한 접근을 통제하는 솔루션을 이용해 접근제어 를 실행하는 것이 클라우드 데이터 보안의 필수요소 중 하나가 된다.

특권사용자 권한제어를 위한 접근제어 솔루션은 특권사용자 (클라우드 관리자, DBA 등)가 인가되지 않은 데이터에 접근하 는 것을 막을 뿐 아니라, 특정 데이터에 접근할 수 있는 권한을 가진 사용자라 하더라도 클라우드 내의 DB에 접속한 IP나 애 플리케이션 또는 시간 등의 요소를 결합해 접근을 제어하거나 데이터에 대한 변경을 허용하지 않을 수 있는 기능도 제공한 다.

그럼 훌륭한 클라우드 데이터 접근제어 솔루션의 특징은 무 엇일까? 데이터암호화 솔루션과 마찬가지로, 접근제어를 적용 하더라도 큰 폭의 성능감소가 있어서는 안 된다. 그러나 이것 보다 더 중요한 한 가지 요소가 있으니, ‘접근제어’본연의 기 능을 제공하기 위해 어떠한 우회접속도 완벽하게 차단할 수 있 어야 한다는 것이다. 만일 접근제어 솔루션이 우회접속을 완벽 하게 차단할 수 없다면, 접근제어 솔루션의 무력화를 시도하는 해커의 움직임을 막아낼 수 없게 된다.

클라우드 원천데이터 유출 차단 통한 데이터 보안 -데이터 변조(Masking)

대다수 회사들이 운영, 개발 및 테스트 환경을 분리해서 운 영하고 있다. 이러한 환경을 구성하는 방법은 모든 것(운영, 개 발, 테스트)을 클라우드로 이관하거나, 일부만 클라우드로 이 관하거나, 전체를 다 온프레미스에 그대로 두는 것 등이다. 어 떤 경우든 운영 데이터의 일부 또는 전체가 개발 및 테스트 환 경으로 넘어가야 하는 상황이 있는데, 과연 개발 및 테스트를 위해서 운영DB에 있는 주민등록번호나 신용카드번호 등 민감 한 개인정보가 실제 그대로 사용돼야만 하는 것일까?

거의 모든 경우의 대답은‘그렇지 않다’이다. 예외적으로 반 드시 실제 데이터가 사용돼야 하는 경우가 있다고 하더라도, 운영DB에 있는 데이터의 극히 일부 데이터만을 사용하면 충분 히 개발 및 테스트를 진행할 수 있을 것이다. 그렇다면 실제 데 이터는 아니지만 실제 데이터와 동일한 형태 및 규칙을 가진, ‘정말 실제 같은’데이터는 어떻게 확보할 수 있을까? 데이터 마스킹 솔루션을 이용해 변조된 데이터를 사용하면 이러한 데 이터를 확보할 수 있다.

데이터 마스킹을 사용해 생성한 테스트 데이터는 원본 데이 터의 모든 특징을 그대로 갖게 돼, 변조된 데이터임에도 불구 하고 원본 데이터가 필요한 개발 및 테스트에 문제없이 사용할 수 있다. 이를 통해 극히 일부 사람만이 접근 가능한 운영DB의 데이터가 다수의 개발 및 테스트 담당자들에게 전달되지 않게 되고, 결론적으로 데이터가 온프레미스 내부, 클라우드 내부, 또한 온프레미스와 클라우드를 오가는 경우에도 데이터 유출 을 원천적으로 예방할 수 있게 된다.

 

에필로그 - 관심에서 적용으로

비록 연어는 강을 거꾸로 거슬러 올라갈 수 있을지 모르나, 강물 자체는 거꾸로 흐를 수 없다. 조금 다를 수 있겠으나, 현 재 흐름을 볼 때 전체냐 부분이냐의 문제일 뿐, 클라우드로의 전환은 피할 수 없는 일이 된 것으로 보인다. 클라우드로 가야 한다면 현명하고 효율적으로 전환해야 할 것이고, 이를 위한 첫걸음은 완벽한 클라우드 보안을 구축하기 위한 항목들을 살 펴보는 일이 될 것이다.

위에서 언급한 대로, 클라우드 보안은‘포괄적 보안 제어’와 ‘계층화된 보안 방어’라는 두 가지 측면이 고려돼야 한다. 조금 다른 성격의 이들을 구성하는 내용 가운데 하나를 고르는 식의 단편적인 접근은, 클라우드 보안에 대한 올바른 접근법이 아님 은 분명하다. 그러나 데이터 보안이 클라우드 보안의 필수항목 중 하나임은 분명해 보인다.

단편적으로 완료될 수 없는 클라우드 보안의 가장 안쪽에 있 는 데이터 보안을 제대로 구축하기 위한 아키텍처를 고민하고, 그 아키텍처의 핵심을 이루는 암호화, 표시제한, 권한제어, 데 이터변조 등을 완료해나가면, 쉽지 않은 클라우드 보안의 완벽 한 구축도 불가능한 일만은 아님을 강조하며 이 글을 마친 다

출처 : 디비가이드넷