보안의 기본은 어디부터 생각해야 할까?
보안은 무언가를 막고, 무언가를 확인하며, 문제점이 발견되면, 이를 다시 보완하는 것으로 많이 생각할 것이다. 이번 칼럼에서는 중요하지만, 너무나 당연하게 생각하고 있는 ID(Identity, 혹자들은 계정)에 대한 이야기를 하고자 한다.
조직은 개인에 대한 신분 확인 및 이메일과 같은 업무 시스템과의 연계를 위해 계정을 조직원에게 발급한다. 해당 계정을 이용해 사용자는 시스템 이용시 자신을 증명하는 절차를 밟게 되고, 인증 절차에는 일반적으로 암호 입력, 스마트 카드, 또는 지문 확인과 같은 생체 정보가 추가적으로 사용된다.
IT 관리자는 이러한 계정 정보에 대한 관리를 디렉토리 서비스와 같은 형태로 중앙에서 관리할 것인지, 개별 사용자들이 직접 계정 정보를 관리하게 할 것인지에 대해 고민하기도 하며, 추가적인 시스템 인증 정보를 개별 시스템에 저장할 것인지, 아니면 중앙 디렉토리 서비스와 연계할 것인지를 고민해왔다.
물론 조직 규모와 시스템 종류에 따라 어떤 방식으로 계정 정보 관리할지는 달라지지만, 관리 효율성이나 보안 측면에선 중앙 디렉토리 서비스를 이용하는게 낫다는 것은 의심할 여지가 없다.
현업 현장을 살펴보면, IT 관리자가 계정으로 인해 발생할 수 있는 업무나 문제점은 어렵지 않게 찾을 수 있다. 앞서 언급한 바와 같이 이용 시스템에 따라 계정 정보를 사용하는 형태가 틀리기 때문에, 이러한 계정 정보를 일관성 있게 관리하는 것이 바로 그것이다.
사내 시스템의 숫자가 늘어가면 갈수록, 연결해 관리해야할 계정 숫자는 늘게 되고, 업무량 증가에 따라 당연히 계정 정보를 통한 문제점 발생은 늘어가게 된다. A라는 사용자가 퇴사할 경우, 이메일 시스템 계정, 사내 그룹웨어 접속 계정이 동시에 다 사용 정지되어야 하는 경우, 승진 발표 후, 사용자 정보를 일괄적으로 업데이트해야 필요가 있는 경우가 좋은 예이다.
중앙 집중적인 디렉토리 서비스를 이용하고 있지 않거나, 시스템간 연결이 잘 되어 있지 않기 때문에 계정 정보 관리에 대한 일관성이나 빠른 업데이트가 되지 않는다면, 이를 통한 보안 문제 발생은 불보듯 뻔한 일이다. 직원은 이미 퇴사했는데, 접근 가능한 서버를 통해 정보를 가져갔다는 사례는 어렵지 않게 찾을 수 있다.
이러한 이유로 규모가 큰 조직일수록, 사내 사용자 계정 정보 데이터베이스간 동기화를 중요하게 생각해야 한다. 데이터베이스 구조와 연결 방식에 대해서는 유수의 IT업체들이 이미 공개를 해놓았으므로, 자체적인 개발 작업을 통해 이들을 연동하거나, 시장에 존재하는 기술을 적용할 필요가 있다는 의미다.
클라우드라는 단어가 나오기 전이었다면, 이 정도로 계정 관리에 대한 이야기는 종지부를 찍어야 했었다. 그러나 클라우드(Cloud) 기술의 유행은 IT 관리자에게 또 다른 생각을 요구하게 한다. 클라우드까지 가지 않고도, 이해할 수 있는 일이다. 바로 B2B(Business-to-Business) 시나리오다. 비즈니스 요구에 따라 많은 기업들이 서로 파트너 관계를 맺고 있다. 예를 들어 자동차 회사는 주기적으로 부품을 납품하는 기업에서 제품 수량을 확인하고, 차후 납기일을 예측하거나, 정산을 계산할 수도 있다. 이 경우, 확인을 위한 시스템은 자동차 회사에서 가지고 있는데, 이 시스템을 사용하기 위해서는 어디에서 계정을 관리해야 할까?
지금까지는 사용하고자 하는 자원를 가진(위의 예에서는 자동차 회사) 회사에서 계정을 생성해 파트너에게 제공하는 것이 대부분이었다. 부품을 납품하는 기업내 조직원은 자사 계정과 타사 시스템을 접근하기 위한 계정, 총 2개를 사용하게 된다. 그러나 회사 규모가 커지고, 비즈니스 관계가 많아지면, 이 계정에 대한 사용 부담은 늘어나게 된다. 인터넷에 무수히 많은 다양한 사이트의 계정과 암호를 모두 기억하는 것이 어렵다는 것은 이미 잘 아는 사실이다. 자원을 사용하는 사람도 사람이지만, 실제 자원과 계정을 제공한 회사도 해당 계정이 제대로 사용되고 있는지 알 수가 없다.
단순히 로그를 통해 언제 접근했고, 어떤 형태로 이용했냐는 확인할 수 있겠지만, 정말로 파트너 회사 직원이 사용했는지, 그 직원이 정상적으로 해당 회사에 있는지는 알 수 없다는 것이다. 여기도 또 하나의 보안 이슈가 발생할 수 있다. 그렇다고 상호간 계정 인증 인프라를 상호 연동하기 위한 기존 기술들은 네트워크 요구 사항이 꽤 복잡하다는 것이 문제다.
다시 클라우드로 돌아가보자. 클라우드 트렌드에 발맞추어, 다양한 서비스들이 등장하고 있고, 이러한 서비스들을 조직 인프라와 연계해 사용하려는 움직임이 일고 있다. 이에 따라 인프라는 시스템 형태에 따라 사내와 클라우드로 구분될 것이고, 위와 같은 형태로 계정 정보를 관리한다면, 일괄적인 시스템 이용 및 계정 관리는 불가능해진다.
일상의 예를 통해 시각을 좀 바꿔보자. 해외 여행을 할 때, 방문하는 나라마다 본인의 신분증을 만들어야 하는가? 여권이 본인을 증명하기 위한 신분증이며, 여권은 우리나라에서 발급받아 간다. 방문국에서는 여권의 여러 사항을 확인 후, 입국 허가를 하게 된다. 이를 IT에 적용해보자.
계정에 대한 관리는 계정을 가진 조직에서 하고, 자원을 제공하는 곳은 인증된(AuthN) 사용자를 확인만 하고, 허가에만(AuthZ) 치중한다면 어떨까? 상호 비즈니스 조직간 모든 교신은 공개키기반구조(PKI) 기반 표준 프로토콜을 통해 무결성(Integrity)을 확인하고, 암호화(Encryption) 후 안전하게 전송하게 한다면 어떨까?
2000년대 초반부터 위와 같은 기술에 대한 토론 및 움직임은 시작되었고, 이미 다양한 기술 플랫폼 벤더에서 페더레이션(Federation)이란 이름으로, 클레임 기반 ID(Claim-Based ID)를 이용할 수 있는 기술이 제공되고 있다. 클레임 기반 ID는 웹서비스(WS) 표준 기술을 기반으로 한다. WS 표준에는 WS-Federation, WS-Trust, 그리고 WS-Security가 대표적으로 포함되어 있으며, SAML(Security Assertion Markup Language)을 통해 이기종간 인증 및 허가 정보를 교환할 수 있게 한다.
클레임 기반 ID 기술은 사용자의 계정 정보를 표준 SAML에 담을 수 있게 하고, 상호 조직내 페더레이션 서버간 표준 통신을 통해, 사용자 정보 확인 및 자원을 가진 조직에서의 허가가 가능하게 한다. 특정 업체 기술만으로 구성되는 것이 아닌, 표준 기술을 기반으로 하고 있기에, 당연히 클라우드 트렌드에 맞춰 다양한 서비스와 연계도 가능하다.
마이크로소프트, 구글, 야후, 페이스북에서는 이미 클레임 기반 ID 기술을 지원하고 있고, 마이크로소프트의 경우 온라인 서비스와 윈도애저가 사내 시스템과 상호 연동시킬 수 있다. 이러한 플랫폼 기반의 응용 프로그램을 만드는 개발자의 경우, 자신이 어떠한 형태로 인증을 받을지를 매번 만들어내는 것이 아니라, 프레임워크에서 제공하는 형태만 잘 이용한다면, 인증에 대한 복잡성에서 벗어날 수 있다.
언제나 보안의 기본은 계정에 대한 고민에서 시작한다. 그리고 기술이 발전함에 따라 이러한 고민은 점점 범위를 확장될 것이라고 생각한다. 조직내 중앙 집중적인 계정 관리 인프라와 더불어, 비즈니스 확장 및 요구에 따라 유연한 확장이 가능한 기술을 이미 알거나, 적용시켜 놓았다면, IT가 조직의 비즈니스 가치를 상승시키는데 일조한다고 생각해도 되지 않을까?
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
