SSO(Single Sign On)

SSO(Single Sign On)의 약자 입니다.
단일화면에서 단일 ID와 암호로 한번의 로그인만으로 기업의 각종 업무 시스템이나 인터넷 서비스에 접속할 수 있게 해주는 보안 응용 솔루션으로, 최근 각 기업들의 인트라넷 시스템과 웹서비스가 대폭 확장됨에 따라 급속히 시장이 확대되고 있다.
SSO를 도입하면 각각의 시스템마다의 인증 절차를 밟지 않고도 사용자에 부여된 1개의 계정만으로 다양한 시스템에 접근할 수 있어 사용자 편의가 대폭 높아지고, 관리자 입장에서도 인증정책의 변경이나 권한 설정을 편리하게 적용할 수 있어 비용 절감 및 업무 효율을 높일 수 있다.
특히 최근의 SSO기술은 인증된 사용자에게 시스템 정보 및 자원에 접근할 수 있는 권한은 물론 중요 접근제어 권한까지 부여하는 권한체계관리기반구조(PMI)로 발전되는 추세입니다.

1, 단일 아이디 사용으로 편리성 증대
2. 업무간 이동의 편리성
3. 프로그램 자동인스톨기능으로 사용의 편리
4. 어플리케이션및 시스템관리자의 업무감소
5. 패스워드관리 담당자의 업무 감소

완벽한 보안을 제공하며, id, password에 대한 암기 부담이 감소하며
id, password 기록해 놓을경우, 노출될 수있으나 SSO를 통해 관리할 경우 이러한 위험부담이 감소됩니다.

또 각 어플리케이션간의 이동에 각각의 로그인을 할 필요가 없으므로 클릭만으로 사용하고자 하는 프로그램으로의 이동이 편리해집니다.

여기에 Pass-Ni는 프로그램 자동인스톨 기능이 추가되어 프로그램이 없을경우
프로그램을 다운받아 자동 설치를 지원하므로 사용자뿐만 아니라 시스템이나 프로그램 관리자의 일손을 덜어 줄수 있습니다.

사내 인트라넷 프로그램이나 c/s프로그램의 경우도 아이디 패스워드를 관리하는 담당자의 업무가 대폭 감소합니다.

 

 하나의 아이디로 여러 사이트를 이용할 수 있는 시스템으로 'single sign on'의 첫글자를 따서 SSO라고도 한다. 여러 개의 사이트를 운영하는 대기업이나 인터넷 관련 기업이 각각의 회원을 통합 관리할 필요성이 생김에 따라 개발된 방식으로, 1997년 IBM이 개발하였으며 우리나라에는 2000년 코리아닷컴이 처음 도입하였다. 이후 삼성전자(주)와 SK 등이 도입하며 활성화되어, 애니패스와 오케이캐쉬백·롯데타운 등 다양한 사이트와 네티그리티·다우기술 등 솔루션 공급업체도 많이 설립되었다.

개인의 경우, 사이트에 접속하기 위하여 아이디와 패스워드는 물론 이름·전화번호 등 개인정보를 각 사이트마다 일일이 기록해야 하던 것을 한 번의 작업으로 끝나므로 불편함이 해소되며, 기업에서는 회원에 대한 통합관리가 가능해 마케팅을 극대화시킬 수 있다는 장점이 있다. 특히 권한관리시스템(EAM)과 함께 사용할 경우 보안성과 효율성을 함께 갖춘 통합인증시스템으로 활용할 수 있어 향후 더욱 인기를 끌 것으로 전망된다.

 

 

통합 사용자 인증(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는 보안과 정보이용에 관한 다양한 기법들이 각기 다른 수준의 보안 및 복잡한 문제들에 기반한 한 가지 기법으로 모아져 가는 데 필요한 기본 골격(표준 포함)을 제공합니다. 정보의 새로운 결합이 촉진됨에 따라 자금의 움직임과 새로운 제품의 개발이 가능해질 것입니다.

 

주목해야 할 기술

 

암호화(Encryption)

개인 맞춤화(Personalization)

협업 필터링(Collaborative filtering)

XML (Extensible Markup Language)

퍼베이시브 컴퓨팅(Pervasive computing

 

 

 

 

EAM·SSO 기술과 표준화 동향 ①

EAM 시스템과 요구 사항

연·재·목·차

제1회 EAM 시스템과 요구 사항
제2회 SSO 모델과 보안 기술
제3회 SSO·RBAC 표준화 동향

기업의 IT 인프라와 자산에 대한 통합화 및 관리 그리고 통제에 대한 관심이 증대되고 있다. 단순한 사내망에 불과하던 기업 IT 인프라가 직원, 고객, 파트너 등으로 사용자가 확대되면서 다양한 서비스를 요구받기 때문이다. 모든 기업들은 회사의 자원을 보호하고 자원에 대한 접근 권한을 관리함으로써 이러한 복잡한 문제들을 해결하길 바라고 있다. 이러한 기업의 요구에 부합하는 기술적 트렌드를 3회에 걸쳐 연재한다.

강신범 | 소프트포럼 기반기술개발실장

EAM(Extranet Access Management) 시스템은 인트라넷·익스트라넷 서비스를 동시에 수행하는 현재의 기업 IT 인프라 시스템을 안전하게 구성하고 효율적인 관리를 수행할 수 있는 환경 제공을 목적으로 한다.

EAM 시스템에 대한 이해를 돕기 위해 먼저 기업 내 IT 인프라를 EAM 시스템으로 통합하는 시나리오를 간단히 기술하고, 이 시나리오에 근거해서 EAM 시스템의 요구사항을 보안 a기술 측면에서 살펴본다.

EAM 시스템

현재 그룹웨어, 인사관리(HR) 시스템 그리고 전사적자원관리(ERP) 시스템을 운영하고 있는 회사의 경우 각 애플리케이션 별로 각각의 사용자 계정과 권한 관리를 위한 자원이 투입돼 운영된다. 이는 부가적인 관리를 필요로 함은 물론이고 획일적이고 통합되지 않은 상태의 시스템 운영으로 인한 다양한 부작용 및 보안적 결함을 드러내게 된다. 이와 같은 고민에 빠진 회사는 규모의 증대와 IT 인프라 확산에 비례해 보안적 결함이 점차 증가하게 된다. 또한 일정 시일 이후에는 EAM 시스템 도입 비용을 상회하는 기존 시스템의 운영비용으로 인한 손실분을 안게 되는 최악의 상황에까지 몰리게 된다.

이같은 회사가 EAM 시스템을 도입하게 되었을 경우에 회사 내부에서 사용되는 그룹웨어, HR, ERP를 EAM 시스템으로 통합하고 각 애플리케이션별로 개별적으로 관리되던 사용자 계정, 권한관리시스템까지도 단일화된 EAM 시스템에서 통합 관리하게 된다. 이 작업으로 인한 회사의 IT 인프라는 다음과 같이 변경된다.

우선 사내 직원은 사용자 인증을 최초로 한번 받고, 각 애플리케이션을 SSO(Single Sign-On) 기술에 의해 추가 인증없이 사용할 수 있다. 또한 각 애플리케이션은 개인화 서비스를 통해 인증된 사용자의 정보를 얻어 동작에 적용한다.

개별 애플리케이션은 통합된 인가·접근제어 정책에 따라 사용자의 접근을 제어한다. 사내 IT 인프라 관리자는 EAM 관리시스템을 통해 각 애플리케이션별로 접근권한을 사용자에게 제어할 수 있다. 사용자가 통합 인증을 받고 각 애플리케이션에 접근하는 모든 감사정보를 EAM 시스템이 관리해 개별적으로 관리되던 감사정보를 통합해 관리할 수 있게 된다.

EAM 시스템의 요구사항

EAM 시스템은 적어도 다음과 같은 6가지 요구사항 항목을 가진다.

△인증(Authentication):

시스템에 접근하는 사용자를 확인한다. 일반적으로 ID/PWD 방식이 가장 널리 사용되며 보안성을 강화하기 위해 암호, PKI 기술들이 이용된다.

△SSO:

통합 인증된 사용자가 개별 애플리케이션에 추가적인 인증 요구 없이 사용할 수 있어야 한다.

△인가·접근제어(Authorization):

개별 애플리케이션의 각 자원 및 서비스에 대한 인가·접근제어 권한을 관리 툴로 설정하고, 설정된 인가·접근제어 권한이 개별 애플리케이션 동작에 적용이 돼야 한다.

△개인화(Personalization):

통합 인증된 사용자가 개별 애플리케이션에 접근할 때, 접근하는 사용자의 아이덴티티(Identity)와 사용자의 정보를 확인할 수 있는 기술이 제공돼야 한다.

△관리(Administration):

통합 인증을 위한 사용자 계정, 개별 애플리케이션의 인가·접근제어, 개인화를 위한 정보제공의 범위, 감사기능 등을 편리하게 관리할 수 있는 기능이 제공돼야 한다.

△감사(Auditing):

전체 시스템에 접근해 통합 인증을 받고 SSO으로 개별 애플리케이션에 접근, 인가·접근제어가 수행되는 모든 과정이 감사 기록으로 남아야 한다.

<그림> Extranet Computing 환경

인증(Authentication)

EAM 시스템의 요구사항에서 사용자 인증에 관련된 보안 기술은 전체 시스템의 보안성에 매우 중요한 부분을 차지한다. 이와 관련해 EAM 시스템에서 사용될 수 있는 다양한 인증방법 기술에 대해서 소개한다.

인증방법은 기본적인 ID/PWD 방식과 보안성이 상대적으로 높은 X.509 인증서, OTP(One Time Password), 생체인식으로 나뉘어 진다. 아래에서 설명하고 있는 인증 방법들은 일반적인 EAM 시스템에서 웹 환경에 적용하기 적합한 기술들이다.

△Basic ID/PWD:

HTTP/HTTPS 프로토콜의 BASIC Authentication 방법을 이용해 ID와 패스워드로 사용자를 인증한다. 이 인증 방법은 HTTP 프로토콜을 사용하는 경우 사용자가 입력한 ID와 패스워드가 네트워크를 통해 암호화되지 않고 전송된다. HTTPS 프로토콜을 이용하는 경우에는 암호화돼 전달된다.

△Digest Authentication:

HTTP/HTTPS 프로토콜의 Digest Authentica-tion 방법을 이용해 ID와 패스워드로 사용자를 인증한다. 이 인증방법은 패스워드가 평문으로 전달되지 않아 Basic ID/PWD 인증보다 향상된 보안 서비스를 제공하지만, 패스워드가 저장될 때 반드시 패스워드 원본 혹은 복호화될 수 있는 정보로 저장돼야 하기 때문에 서버에서의 패스워드 관리에 각별한 주의가 요구된다.

△Form Based Authentication:

Customized Form(HTML/JSP/ASP etc.)을 이용해 사용자를 확인한다. 폼에 입력되는 인증 정보는 사용자 ID/PWD 만으로 구성될 수도 있고 사용자 ID/PWD 이외의 다른 정보, 예를 들어 사용자 주민등록번호 등을 추가적으로 포함해 사용할 수 있다. 전달되는 정보의 암호화를 위해서는 HTTPS 프로토콜이나 기타 암호 제품을 사용할 수 있다.

△X.509 Client Certificate over SSL:

HTTPS 프로토콜의 사용자 인증서 인증 프로토콜을 이용해 인증한다. 인증서의 폐기 여부 확인을 위해 CRL 검증과 OCSP 검증 방법을 사용할 수 있다.

△One Time Password 인증:

한 번만 사용될 수 있는 패스워드를 이용해 사용자를 인증한다. 사용자에게 미리 전달된 OTP Token을 이용하여 사용자를 인증한다.

△생체 인식:

사용자의 지문이나 홍채 등을 이용해 사용자를 인증한다. 아직은 널리 사용되고 있지 않으나 지문 인식의 경우 그 영역이 확대되고 있는 추세이다.

지금까지 기업의 IT 인프라 관리를 위해 효율성과 보안성을 모두 만족시킬 수 있는 EAM 시스템에 대한 개념과 요구사항을 살펴봤다. 기업의 다양한 IT 시스템 운영에 있어서 보다 안전하고 저비용의 운영 방식을 원한다면 각 애플리케이션 별로 분산돼 있는 인증과 권한 관리 부분을 통합시켜 전사적인 관리가 가능한 EAM 시스템 도입을 고려해 봐야 한다.

---

연재/EAM·SSO 기술과 표준화 동향 ②

SSO 모델과 보안 기술

강신범
소프트포럼 기반기술개발실장

연·재·목·차

제1회 EAM 시스템과 요구 사항
제2회 SSO 모델과 보안 기술
제3회 SSO·RBAC 표준화 동향

SSO 모델

일반적으로 사용되는 SSO 시스템은 두 가지 모델로 구분된다. SSO 대상 애플리케이션에서 사용되는 사용자 인증 방법을 별도의 SSO 에이전트가 대행해주는 Delegation(인증 대행) 방식과 SSO 시스템과 신뢰관계를 토대로 사용자를 인증한 사실을 전달받아 SSO를 구현하는 Propagation(인증정보 전달) 방식으로 구분된다.

<그림 1> SSO Delegation Model

△Delegation 방식: 대상 애플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용된다. 대상 애플리케이션의 인증 방식을 전혀 변경하지 않고, 사용자의 대상 애플리케이션 인증 정보를 에이전트가 관리해 사용자 대신 로그온 해주는 방식이다. 즉 Target Server 1을 로그온 할 때 User1이 alice/alice라는 ID/ PWD가 필요하다면, 에이전트가 이 정보를 가지고 있고, User1이 Target Service 1에 접근할 때 에이전트가 대신 alice/alice ID/PWD 정보를 전달해서 로그온 시켜준다. △Propagation 방식: 통합 인증을 수행하는 곳에서 인증을 받아 대상 애플리케이션으로 전달할 토큰(Token)을 발급 받는다. 대상 애플리케이션에 사용자가 접근할 때 토큰을 자동으로 전달해 대상 애플리케이션이 사용자를 확인할 수 있도록 하는 방식이다. 웹 환경에서는 쿠키(Cookie)라는 기술을 이용해 토큰을 자동으로 대상 애플리케이션에 전달할 수 있다. 이러한 웹 환경의 이점으로 웹 환경에서의 SSO는 대부분 이 모델을 채택하고 있다.

<그림 2> SSO Propagation Model

△Delegation & Propagation 방식: 웹 환경이라고 하더라도 Propagation 방식이 모두 적용될 수는 없다. 특히 웹 애플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우 Delegation 방식을 사용하게 된다. 또한 대상 애플리케이션들이 많이 있고 애플리케이션의 특성들이 다양한 경우 각 애플리케이션에 Delegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO을 구성한다.

△Web 기반 One Cookie Domain SSO: SSO 대상 서비스와 응용 애플리케이션들이 하나의 Cookie Domain안에 존재할 때 사용된다. 일반적인 기업 내부의 컴퓨팅 환경이다. 통합인증을 받은 사용자는 토큰을 발급받게 되고, 이 토큰은 Cookie Domain에 Cookie로 설정되어 Cookie Domain 내의 다른 서비스로 접근할 때 자동으로 토큰을 서비스에 제공하게 된다. 서비스에서 동작되는 SSO 에이전트는 토큰으로부터 사용자 신원을 확인하고 요청된 자원에 대한 접근을 허가 해준다.

Web 기반 Multi Cookie Domain SSO

SSO 대상 서비스와 응용 애플리케이션들이 여러 도메인으로 분산돼 있을 경우다. Multi Domain 환경인 경우에는 사용자 인증 및 토큰의 발행을 위한 마스터 에이전트가 존재한다.
마스터 에이전트는 각 서비스 에이전트의 사용자 인증을 위임받아 수행한다. 인증된 사용자에게는 토큰을 발급하고 각 서비스 에이전트에게 안전하게 전달한다. 또한 에이전트가 해당 토큰을 자신의 Domain에서 Cookie로 저장해 사용할 수 있도록 한다. 각 서비스 에이전트의 신뢰도 및 SSO 시스템의 보안 레벨에 따라 다음과 같이 두 가지 방식으로 서비스될 수 있다.

<그림 3> One Token for All Multi Cookie Domain

△One Token for All Multi Cookie Domain: 모든 도메인이 하나의 토큰을 공유한다. 모든 시스템은 서로 신뢰관계를 가져야 한다. 토큰이 하나만 사용되므로, 마스터 에이전트는 사용자 인증 및 각 도메인에 대한 토큰 제공에 대해서만 수행하게 돼 에이전트들의 관리 및 구성이 매우 간단하다. 하지만 모든 도메인들이 서로 신뢰관계를 가져야 한다는 제약사항으로 인해 적용대상이 제한적이다. 일반적으로 하나의 기업에서 운영하는 다중 도메인 서비스들을 SSO로 구성할 때 많이 사용된다.

<그림 4> One Token form each cookie domain & One Token for Master Agent

△One Token for each cookie domain & One Token for Master Agent: 마스터 에이전트와 각 도메인들이 각각 토큰을 가진다. 마스터 에이전트는 각 도메인의 에이전트들과 신뢰관계를 가지며, 각 도메인의 에이전트들 사이는 신뢰관계를 가지지 않는다. 마스터 에이전트는 각 도메인의 에이전트에게 전달할 사용자 토큰을 발행하므로, 에이전트들의 레벨이나 속성에 따라 토큰에 저장되는 사용자 정보의 양을 조절할 수 있다. 토큰이 각 도메인 별로 발행되므로, 도메인별 Replay Attack 등에 대한 취약성이 전체 시스템에 영향을 주지 않는다.

SSO 보안 기술

토큰은 쿠키를 통해 전달되므로 외부에 노출되는 정보이다. 완벽한 보안을 위해서는 토큰이 네트워크에서 노출되어서는 안되지만, 비용 및 관리상의 이유로 허용되고 있다. 하지만 토큰을 통해 토큰이 포함하고 있는 정보까지 외부에 노출하는 것은 심각한 결함을 제공한다. 토큰의 네트워크 구간에서의 정보 노출 및 위·변조를 방지하기 위해 다음과 같은 보안기술이 사용된다.

△Data Confidentiality: 토큰은 주요 암호 알고리즘(AES, SEED)과 128bit 이상의 키로 암호화돼 보호되어야 한다. △Data Integrity: 토큰은 MAC

(Message Authentication Code) 등을 포함해 데이터의 무결성을 보장해야 한다. △Replay Attack Protection: 토큰은 사용자와 대상 애플리케이션 사이에 전달되는 인증 정보이다. 일반적으로 토큰은 네트워크에 노출되며, 노출된 토큰을 사용해 다른 사용자가 인증을 받고 들어올 수 있다(Replay Attack). 특히 웹 환경에서 이러한 문제점이 중요한 이슈로 등장하고 있다. 이러한 문제점을 근본적으로 해결하기 위해서는 토큰을 네트워크에 노출시키지 않아야 한다.
토큰을 네트워크에 노출시키지 않기 위해서는 항상 사용자와 대상 애플리케이션 사이에 암호 채널을 형성해야 하며, 이 채널을 통해 토큰을 전달해야 한다. 그러나 SSL과 같은 채널 암호를 사용하는 데에는 매우 많은 비용이 요구되어 실제로 많이 사용되고 있지는 않다.
SSL과 같은 암호채널을 사용하지 않으면서 Replay Attack이 발생할 수 있는 상황을 줄일 수 있도록 다음과 같은 보안 기술들이 사용된다.

△사용자 주소 제한: 토큰이 발행될 때 접속한 사용자 주소 정보를 토큰 내부나 토큰을 발행한 서버에서 기억함으르써 Token이 제출된 사용자 주소와 최초 발행시 기억된 주소를 비교하여 접속한 곳 이외에서의 접속을 제한할 수 있다. 사용자 주소가 업무진행 중에 자주 변경되지 않는 시스템일 경우 유효하다. 예를 들어 회사내의 인터넷 환경일 경우 사용될 수 있다. 인터넷 환경의 경우에는 사용자 주소가 특정 범위에서 자주 바뀔 수 있는 환경도 있기 때문에 불특정 다수를 위한 일반적인 인터넷 서비스에 사용하기에는 부적합하다.

△유효시간 제한: 토큰의 유효시간을 매우 짧게 줌으로써 Replay Attack에 사용될 수 있는 시간을 제한한다. 유효시간내에 임계시간(예: 유효시간의 1/2)을 넘으면 자동으로 토큰을 재 발행하여 사용자는 의식하지 못하고 서비스를 계속 사용하게 한다. 지금까지 사용자가 각 애플리케이션별로 별도의 인증을 받지 않고, 한번의 통합 인증만으로 각 애플리케이션들을 사용할 수 있도록 하는 SSO 기술에 대해 살펴보았다. 대상 애플리케이션의 수정을 최소화할 수 있는 Delegation 모델과 토큰을 생성해 통합 인증 서비스를 제공하는 Propagation 모델 그리고 양자의 장점을 조합한 Delegation & Propagation 방식을 이해한다면 현재 도입 대상 기업의 IT 인프라와 진행중인 서비스 및 애플리케이션의 특성에 적합한 EAM 시스템 도입을 결정하는데 도움이 될 것이다.

EAM·SSO 기술과 표준화 동향

제3회 SSO·RBAC 표준화 동향

강신범
소프트포럼 기반기술개발실장

연·재·목·차
제1회 EAM 시스템과 요구 사항
제2회 SSO 모델과 보안 기술
제3회 SSO·RBAC 표준화 동향

SSO 표준화 동향

네트워크 아이텐티티 관리에 대한 오픈 표준안을 개발하는 Liberty Alliance 프로젝트와 SAML(Security Assertion Markup Language) 표준안을 개발하는 OASIS Security Services TC의 활동을 통해 EAM 보안 기술의 동향을 살펴보자.

Liberty Alliance Project

Liberty Alliance Project는 2001년 9월 연합 네트워크 아이텐티티 관리와 아이텐티티 기반 서비스를 위한 오픈 표준안을 개발하기 위해서 구성됐다. 주된 목표는 상호운영성을 보증하고 개인의 사적자유를 지원하며, 이 스펙과 가이드라인 그리고 실행이 최대한 될 수 있도록 진행하는 것이다. 이 연합은 전 세계의 교육 기관과 정부기관에서부터 서비스 제공자와 금융 기관, 기술관련 회사들과 무선 서비스 제공자들까지 1백50여 멤버 이상으로 구성돼 있다.
Liberty Alliance Project는 오픈 스펙을 개발하는 것으로 특정한 제품이나 서비스에는 제공하지 않는다. 연합의 목적은 다른 현존하는 산업 표준들을 지원하는 스펙을 개발하고, 연합의 멤버들과 다른 기관들이 상호 운영될 수 있는 제품과 서비스를 개발하는데 필요한 수단을 개발하는 것이다. 또한 비용을 감소하면서 안전한 연합 아이텐티티 관리도 진행한다.

Security Services TC(SSTC)

Security Services TC는 OASIS(Organization for the Advancement of Structured Information Standards) 표준안인 Security Assertion Markup Language(SAML) 표준안을 마련하는 그룹이다. OASIS는 시장에서의 상호 운영성을 중심으로 보안, 웹서비스, XML 표준, 상거래, 전자 출판 등의 세계 표준안을 만든다.
SAML은 인증 및 인가 정보를 교환하는 XML 프레임워크다. 2002년 11월 SAML 1.0 스펙이 OASIS 표준안으로 인정됐으며, 지난해 9월 SAML 1.1 스펙이 표준안으로 인정됐다. 현재는 SAML 2.0 스펙을 위한 작업이 진행 중이다.

RBAC 표준화 동향

한편 미국 NIST RBAC 그룹의 활동을 중심으로 현재 제안중인 NIST RBAC Standard 문서의 내용에 기초해 RBAC 보안기술 동향을 살펴보자.
Role Based Access Control 모델은 1992년 David Ferraiolo와 Rick Kuhn에 의해서 소개됐다. 이후 소프트웨어 개발 업체들이 자신들의 제품과 데이터베이스 관리시스템, 보안 관리 및 네트워크 관리시스템 등에 RBAC의 기능들을 구현하기 시작했다. 그러나 표준화된 기능 정의가 없이 구현돼 RBAC의 유용성과 의미가 불확실하고 혼돈을 초래하게 됐다. 이러한 문제들과 미국 정부와 산업체들의 RBAC 기능에 대한 명확한 정의 요구를 받아들여 미국 National Institue of Standard and Technology(NIST)에서 RBAC(Role Based Access Control) 표준안을 개발하게 됐다.
첫번째 RBAC 표준안 드래프트는 2000년 ACM Workshp on Role Based Access Control에서 제안됐다. 두번째 버전은 2001년 InterNational Com-mittee for Information Technology Standards(INCITS)에 제출됐다. INCITS BSR 359의 공개 리뷰는 INCITS Technical Committee T4로부터 비평을 받았고, 이에 근거해서 이후 작은 변화들이 있어 왔다. 현재는 표준안 문서(NIST-RBAC-STD DRAFT)로 변화됐다.
RBAC Model & Specification
NIST-RBAC-STD DRAFT 문서는 RBAC Reference Model과 RBAC System and Administrative Functional Specification으로 구성돼 있다.

▲RBAC Reference Model

RBAC Reference Model은 기본 RBAC 요소들(USER, ROLE, PER-MISSION, OPERATION, OBJECT)과 표준안에 포함돼 있는 각 TYPE 및 함수들의 관계를 정의한다. 이 표준안은 RBAC Reference Model로 다음과 같은 네 가지 모델을 정의한다.
CORE RBAC: Core RBAC은 RBAC 시스템이 완전히 구성되기 위한 RBAC 요소들, 요소 집합과 관계들의 최소한의 모음을 정의한다. RBAC 시스템에서 기본적으로 고려되는 USER-ROLE 할당, PERMISSION-ROLE 할당 관계를 포함한다. 여기에 ROLE 활성화 개념도 포함하고 있다.
Hierarchical RBAC: Hierarchical RBAC은 ROLE 계층을 지원하는 관계들을 추가한다. 계층은 수학적으로 Partial Order 관계로서 Role 사이의 상속 관계를 다음과 같이 정의한다. 상위 Role은 하위 Role들의 PERMISSION을 가지고, 하위 Role들은 상위 Role의 사용자들을 가진다. 여기에 더해서 Authorized User와 Authorized Permission 개념을 도입해서 상속 관계로 인한 추가적인 정보를 얻을 수 있는 기능을 포함한다.
Static Separation of Duty Relations: Static Separation of Duty 관계는 사용자 할당과 관련해서 Role 사이의 배타적인 관계를 지원한다. Static Separation of Duty와 Role 계층과는 중요한 불일치성이 발생하기 때문에 SSD 관계는 Role 계층이 있을 때와 없을 때의 관계에 대해서 따로 정의한다.
Dynamic Separation of Duty Relations: Dynamic Separation of Duty 관계는 사용자세션의 일부로서 활성화된 Role 들에 대해서 배타적인 관계를 설정한다.

▲RBAC System and Administrative Functional Specification

RBAC System and Administrative Functional Specification은 RBAC 시스템이 요구하는 기능들을 명기하고 있다. 이들 기능들은 administrative operations, administrative reviews, system level functionality 세 부분으로 분류된다.
Administrative Operations: RBAC 요소들과 관계들을 생성, 삭제, 그리고 관리하는 기능을 제공하는 함수들을 정의한다.
Administrative Review: RBAC 요소들과 관계들에 대한 질의를 수행하는 기능을 제공하는 함수들을 정의한다.
System level functionality: ROLE 활성화·비활성화를 포함한 사용자 세션 생성, Role 활성화를 위한 제약조건, 그리고 접근 결정 연산을 위한 기능들을 정의한다.
지금까지 EAM·SSO 시스템을 구성하기 위한 기본적인 요소들과 각종 보안기술, 그리고 표준화 동향에 대해 살펴봤다.
EAM·SSO 시스템은 웹 환경이 발전해 가면서 상업 솔루션들을 중심으로 개별 회사·서비스 별로 구축돼 왔다. 또한 각 기술들이 제품 별로 구현되면서 같은 개념으로부터 출발한 기술들이 점점 다른 점을 갖게돼 상호운영성 문제나 개념의 혼돈 상황을 맞이하게 됐다.
이러한 점을 표준화를 통해 해결하고자 상업적으로 독립된 기관과 각 솔루션 업체들이 공동으로 참여해 표준화 노력이 진행되고 있다. 이 문서에서 소개한 Liberty Alliance, SAML, RBAC 모두 표준안의 제시와 함께 솔루션 적합성 테스트를 위한 방안을 제시하고 있다.

[출처] [본문스크랩] SSO(Single Sign On)|작성자 퍼니코더