컴퓨토피아

통합 사용자 인증(SSO): 사용자를 우선적으로 고려해야 한다.

당신은 ID와 비밀번호를 입력하고 네트워크에 로그온 합니다. 자주 가는 몇 군데 웹사이트와 뉴스그룹을 둘러보고 나니, 이제 일할 시간입니다. 회사 로고로 된 아이콘을 클릭하니, 엄지손가락 지문이나 토큰 코드(token code)를 입력하라는 명령이 나옵니다. 사무실에 있으므로 태블릿을 눌러서 사용허가를 받습니다. 이제 당신은 팀룸(team room), 채팅, 다양한 애플리케이션 등을 사용할 수 있습니다. 게시판에는 당신 고객 중 한 명이 최종 배송품을 수령했다는 메시지가 올라와 있습니다. 그래서, 당신은 그 배송건에 대한 접근권한이 더 이상 없습니다. 그러다, 뭔가 못 보던 것을 발견합니다. 선정해둔 몇 군데 동호회가 당신의 프로필에 있는 이력과 관심사를 보고 당신에게 가입을 권유하고 있습니다. 그리고, 당신은 더 자세한 내용을 알아보기 위해 몇 군데 표시를 해 둡니다.

어떻게 이런 일이 가능한가.

비밀번호는 단순히 귀찮은 일 정도가 아니라 장애가 될 수 있습니다. 이런 사실은 긍정적일 수도 있고 부정적일 수도 있습니다. 비밀번호는 정확한 신원확인, 인증, 권한부여, 자원 할당을 보장한다는 점에서 긍정적이지만, 정보시스템 내에서 정보에 기여하고 정보를 필요로 하는 사람들의 적법한 참여를 막는다는 점에서 부정적입니다. 비밀번호 분실에서부터 시스템이 요구하는 특정 문자 조합에 대한 거부반응 등에 이르기 까지 오늘날 비밀번호 방식의 인증이 안고 있는 문제들은 비일비재합니다. 즉 많은 사람들이 무료 웹사이트에서 인증을 요구하면 그 사이트를 아예 피해 버리기도 하고, 인터넷 쇼핑몰에서 물건을 사려다가도 귀찮아서 그만두거나 그냥 일회성 구매면 친구나 가족의 ID를 빌리기도 합니다.

통합 사용자 인증(SSO) 기술은 보안을 유지하면서 이런 거부감을 줄이기 위한 시도에서 시작되었습니다. SSO는 사용자도 편할 뿐더러, 비밀번호를 알려달라는 고객 문의를 대폭 줄이고 미결제 고객이나 해고직원의 권한을 빠르고 간편하게 삭제할 수 있게 하여 관리상의 문제를 해결할 수 있습니다. SSO에 대한 접근 기법은 몇 가지 있으며 각각 나름대로의 장단점을 갖고 있습니다.

클라이언트 기반(Client-based) - Vince Sorensesn사의 쉐어웨어 소프트웨어인 Password Plus와 같은 비밀번호 관리 도구를 이용하면 사용자는 자체 시스템에 수많은 ID와 비밀번호를 '기억'시키고 PC에서 자동으로 입력하게 할 수 있습니다. 이 과정은 사용자가 설치하고 사용하기에 비교적 편리하지만, 새로운 애플리케이션이나 사이트, 또는 커뮤니티가 추가될 때마다 정보가 갱신되어야 합니다. 그러나, 비밀번호 조합에는 업계 표준이 없기 때문에 문제가 될 수 있습니다. 게다가, PC 중심의 솔루션이라 평소의 작업 장소가 아닌 경우(예를 들어 여행 중)에는 로그인하는 데 번거로워지는 등 사용자 입장에서는 융통성이 부족합니다. 그리고, 기업 네트워크 관리자에게는 조직 전체적으로 통제할 수 있는 방법이 없습니다.

서버 기반(Server-based) - 중앙 서버에서 각기 다른 모든 비밀번호를 관리할 수 있습니다. 이 기법을 이용하면, 사용자는 업데이트와 관련한 번거로운 작업(예를 들어, 직무가 변하면 새로운 권한을 인증받는 것)을 하지 않아도 되며, 다양한 PC에서 접근할 수 있습니다. 관리자는 비밀번호의 수준을 관리(예를 들어, 사소한 비밀번호의 삭제, 주기적 갱신, 필요시 접속 중단 등)할 수 있습니다. 또한 서버 기반 시스템의 경우에는 사용자가 여행 중이거나 다른 PC를 사용할 때에도 사용자가 편리하게 이용할 수 있습니다. 서버 기반 기법은 클라이언트 시스템에 대한 보안과 관리 문제뿐만 아니라 사용자와 서버 사이에 존재하는 전반적인 환경까지 처리해야 한다는 것이 제약이라고 할 수 있습니다. 현재 업계 표준이 없기 때문에 더 복잡합니다. 서버 기반 기법에서 사용자가 온라인에서 하는 모든 활동은 서버를 거치기 때문에, 서버는 항상 사용할 수 있어야 합니다

서비스 기반(Service-based) - 비밀번호 관리를 하나의 서비스로 제공할 수도 있습니다. 예를 들어, 마이크로소프트 패스포트(Microsoft Passport)는 기업들 가입의 비밀번호 잡무를 처리하기 위해 중앙집중 서버, 쿠키, 표준화된 구조를 이용합니다. 사용자 입장에서는 한번 마이크로소프트 서버에 접속하면 여러 웹사이트에 접속하거나 거래할 때 그 인증이 유지됩니다. 이 방식은 수많은 사이트들이 이 서비스의 제공업자와 제휴된 경우에만 사용자에게 편리합니다. 많은 기업들의 참여를 유도할 수 있는 장점으로는, 다양한 사이트에서 일어나는 사용자들의 활동을 포착할 수 있어서 더 심화된 고객 프로필로 연결될 수 있다는 점입니다. 그러나, 이런 기업측의 이점은 이미 개인정보 보호와 관련된 우려를 낳고 있습니다.

이 모든 방식의 경우, 비밀번호는 토큰이나 생체인식을 사용하여 보충 혹은 대체될 수 있습니다. 토큰은 필수적인 키(key)이며 임의로 생성되는 암호를 포함하기도 합니다. 그리고, 생체인식은 엄지손가락의 지문인식과 얼굴인식, 음성인식처럼 사용자의 신체적 특징을 이용합니다. 이 방식은 더 높은 수준의 보안을 보장하지만, 비용 상승, 시스템 간 호환성 문제, false positive(권한이 없는 사용자가 권한이 있다고 잘못 인식), false negative(권한이 있는 사용자가 권한이 없다고 잘못 인식)등의 문제도 일으킵니다.

전반적인 SSO의 약점은 일단 인증과정을 통과하게 되면 광범위하게 도용될 수 있기 때문에, 아무리 사소한 침해행위도 개인정보 도용과 맞먹게 된다는 점입니다. 생체인식은 계속 발전하고 있기 때문에 정확한 신원확인을 쉽게 보장할 수 있는 방법이 될 수 있습니다. 그러나, 보안과 접근 용이성 사이에는 쉽게 해결될 수 없는 기본적인 상충관계가 존재하므로 항상 문제는 발생할 것입니다.

더구나, SSO는 계속 변하는 사용자의 요구와 권한에 대해 빠르고 융통성 있게 대처할 수 없습니다. 직책이나 인구통계의 경우에서와 마찬가지로, 대부분의 시스템에는 자기 아이디를 숨기지 않고 다니는 사용자도 있고, 규정에만 집착하는 시스템 관리자도 있는 것입니다. 협업 필터링과 커뮤니티를 중요한 입력 수단으로 하면, 실제 신원과 전자적 신원을 긴밀하게 연계할 수도 있을 것입니다.

대부분의 SSO 애플리케이션의 전체 설계는 간단하며, 누가 지불하느냐에 따라 사용자나 관리자, 어느 한쪽에 편향되기도 합니다. 어느 누구도 아직까지 보안과 사용의 편의성간의 상충관계를 완벽하게 해결할 수 있는 정말로 혁신적인 SSO 기법을 만들어 내지는 못 했습니다.

시사점

기본적으로 통합 사용자 인증(single sign-on)은 획기적 요소나 눈에 띄는 혁신이 없는 기능성 기술입니다. 그러나, SSO는 사용자와 관리자에게 모두 호응을 얻고 있으며, 기존 사용자 및 그간 서비스에 만족하지 못했던 계층에 상당한 영향을 미칠 것으로 전망됩니다.

수많은 로그인으로 인한 문제가 계속 늘어나고 있어, IT 기업은 우수한 솔루션을 찾는데 노력을 경주하고 있습니다. 그러나, 이 문제에는 두 가지 면이 있습니다. 예를 들어, SSO 솔루션은 수많은 로그인 솔루션으로 전환되는 기능을 자체적으로 포함할 수 있습니다. 그렇게 되면 로그인 자체의 중요성이 감소됩니다. 분명하고 확실한 솔루션이 나타나지 않는다면, 기업은 솔루션의 장점보다도 마케팅에 좌우되어 솔루션을 구매할 것입니다.

개인정보 보호 문제가 SSO의 주요 사안이 되고 있습니다. 일정한 제약이 정보 공유를 통제하기 때문에 이 문제는 더욱 복잡해질 것입니다. 궁극적으로 개인 정보와 프로필의 소유권은 해결 되지 않은 사회문제로 남아 SSO의 가치와 도입에 있어 제약이 될 것입니다. 이상적인 솔루션만이 편의성과 보안 사이에 존재하는 근본적인 상충관계를 해결할 수 있을 것입니다.

두 가지 산업: 정부와 금융업 정부와 산하단체간의 다양한 상호작용과 IT 역량으로 인해, SSO는 공공부문에서 확고한 지지기반을 갖고 있습니다. 사실, 여러 단체가 개별적으로 복잡한 이용 제한을 관리할 수 밖에 없다면 여러 면에서 불리합니다. 긍정적인 측면에서 보면 광범위하게 채용된 SSO 애플리케이션은 사용자 요구를 예측하는 데 이용될 수 있으며, 예측된 사용자 요구는 서비스가 제공되는 속도, 그리고 계획과 예산의 기준인 정보를 개선할 수 있을 것입니다.

금융업은 보안과 정보 이용 문제가 완전히 상이한 다양한 상품과 서비스를 제공합니다. 예를 들어, 자녀가 부모의 신용카드를 사용하는 것은 허용되지만, 부모의 주식을 파는 것은 허용되지 않습니다. 제 삼자가 대출을 승인한다면, 그 제삼자를 통해 자산 상태가 확인되어야 합니다. 정부는 의무조항과 법률 준수를 위해서 금융기관의 정보 이용이 필요합니다. 내부적으로 금융기관은 다양한 계좌를 관리해야겠지만, 다른 계좌나 특정 정보(신용카드의 구매 성향 등)의 이용할 수 있는 정당한 근거를 갖고 있지 않을 것입니다. SSO는 보안과 정보이용에 관한 다양한 기법들이 각기 다른 수준의 보안 및 복잡한 문제들에 기반한 한 가지 기법으로 모아져 가는 데 필요한 기본 골격(표준 포함)을 제공합니다. 정보의 새로운 결합이 촉진됨에 따라 자금의 움직임과 새로운 제품의 개발이 가능해질 것입니다.

SSO 모델

일반적으로 사용되는 SSO 시스템은 두 가지 모델로 구분된다.

SSO 대상 애플리케이션에서 사용되는 사용자 인증 방법을 별도의 SSO 에이전트가 대행해주는

Delegation(인증 대행) 방식과

SSO 시스템과 신뢰관계를 토대로 사용자를 인증한 사실을 전달받아 SSO를 구현하는

Propagation(인증정보 전달) 방식으로 구분된다.

△Delegation 방식:

대상 애플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용된다.

 대상 애플리케이션의 인증 방식을 전혀 변경하지 않고, 사용자의 대상 애플리케이션 인증 정보를 에이전트가 관리해 사용자 대신 로그온 해주는 방식이다. 즉 Target Server 1을 로그온 할 때 User1이 alice/alice라는 ID/

PWD가 필요하다면, 에이전트가 이 정보를 가지고 있고, User1이 Target Service 1에 접근할 때 에이전트가 대신 alice/alice ID/PWD 정보를 전달해서 로그온 시켜준다.

△Propagation 방식:

통합 인증을 수행하는 곳에서 인증을 받아 대상 애플리케이션으로 전달할 토큰(Token)을 발급 받는다.

대상 애플리케이션에 사용자가 접근할 때 토큰을 자동으로 전달해 대상 애플리케이션이 사용자를 확인할 수

있도록 하는 방식이다.

웹 환경에서는 쿠키(Cookie)라는 기술을 이용해 토큰을 자동으로 대상 애플리케이션에 전달할 수 있다.

이러한 웹 환경의 이점으로 웹 환경에서의 SSO는 대부분 이 모델을 채택하고 있다.

△Delegation & Propagation 방식:

웹 환경이라고 하더라도 Propagation 방식이 모두 적용될 수는 없다.

특히 웹 애플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우 Delegation 방식을 사용하게 된다. 또한 대상 애플리케이션들이 많이 있고 애플리케이션의 특성들이 다양한 경우 각 애플리케이션에 D

elegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO을 구성한다.

싱글사인온'이란 무엇인가?

근본적으로 싱글사인온 인증이 의미하는 것은 인증 데이터의 공유이다. 예를 들어 웨어하우징 회사의 많은 사원들은 엔터프라이즈 리소스(데이터베이스 테이블 등)에 접근하여 그들의 업무에 필요한 것을 수행해야 한다.

동시에 다른 사원들도 작업 내용에 따라 다양한 리소스가 필요하다. 회계 담당자는 회계 관련 데이터베이스 테이블에 접근해야 하는 반면 판매 담당자는 판매 관련 데이터베이스 테이블에 접근해야 한다. CEO라면 기업의 데이터베이스 어디에나 접근이 필요할 것이다.

분명한 것은, 이 기업은 무엇보다도 제대로 된 인증 메커니즘이 필요하다. 어떤 사원이 특정 리소스에 접근을 시도했는지 결정할 수 있도록 말이다. 일단 기업 인증 모듈이 사원의 존재를 알면 엔터프라이즈 구현 안의 인증 모듈은 인증이 있는 사용자가 적절한 권한을 갖고 리소스에 접근했는지의 여부를 검사할 수 있다.

사원들이 인증용 유저네임과 패스워드를 사용한다고 가정해보자. 이 기업의 인증 모듈은 당연히 유저네임과 패스워드의 데이터베이스를 갖고 있을 것이다. 들어오는 인증 요청은 유저네임-패스워드 쌍으로 동반될 것이다. 이 인증 모듈은 내부 데이터베이스의 쌍과 비교를 하게 된다.

이제 우리의 웨어하우징 회사는 이 범위안에서 실행되는 여러 애플리케이션들을 갖고있다. 다양한 애플리케이션들이 같은 엔터프라이즈의 다른 모듈을 형성한다. 각각의 애플리케이션은 그 자체로 완벽하다. 이것 나름대로 사용자 기반의 여러 다른 티어(백엔드 데이터베이스, 비지니스 로직, 사용자용 GUI)를 갖고있다는 것을 의미한다. 엔터프라이즈 애플리케이션 통합(EAI)는 이와 같은 독립된 애플리케이션들을 하나의 엔터프라이즈에 통합하는 프로젝트를 일반적으로 가르킨다.

EAI 프로젝트에서 인증 프로세스에 두드러지는 하나의 일반적인 요소가 있다. 특정 애플리케이션의 사용자는 그 엔터프라이즈 내의 또 다른 애플리케이션에 액세스 해야한다. 예를 들어 판매 데이터베이스를 사용하고 있는 판매 담당자가 특정 부품을 검색하기 위해 재고 데이터베이스에 액세스 해야 할 경우도 있다. 이러한 유형의 크로스-애플리케이션 인증을 실현시킬 수 있을까?

두 가지 선택이 있다:

• 두 애플리케이션에서 유저네임과 패스워드 데이터베이스를 중복시킬 수 있다. 따라서 이러한 두 개의 애플리케이션들이 웨어하우징 회사의 모든 사원들을 위해 인증 요청을 효율적으로 처리할 수 있도록 하는 것이다. 사용자는 두 개의 애플리케이션에서 개별적으로 인증을 처리하게 된다. 다시 말해서 자신의 유저네임과 패스워드로 들어가면서 두 애플리케이션 중 하나에 액세스하고 그 애플리케이션은 모든 인증 단계를 수행하게 된다. 유저네임과 패스워드 데이터베이스를 중복할 뿐만 아니라 인증 프로세스 오버헤드까지 중복하는 것이다. 이 솔루션에서 중복의 양은 명확해진다.

• 두 번째 선택은 판매 애플리케이션과 재고 애플리케이션 간 싱글사인온을 통한 인증 데이터 공유를 가능하게 하는 것이다. 만일 사용자가 한 애플리케이션 인증을 갖고 있다면 그의 인증 정보는 다른 것에 전달 될 수 있다. 이 두 번째 애플리케이션은 그 모든 인증 단계를 거치지 않고도 인증 정보를 수락한다. 이 솔루션에는 중복이 없다. 두 개의 애플리케이션이 서로 신뢰하여 각 애플리케이션이 서로의 인증 데이터를 수락할 수 있도록 하는 것이 유일한 필요조건이다.

일반적으로 SSO는 개별 인증 모듈로서 구현된다. 사용자 인증이 필요한 모든 애플리케이션들은 SSO 기반의 인증 모듈에 의지하여 사용자를 확인한다. 이 인증 정보에 따라 다양한 애플리케이션들은 각자의 인증 정책을 발효한다.