본문 바로가기

EAM/SSO

EAM/SSO 기술과 통향 2

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

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 & Progation 방식
: 웹 환경이라고 하더라도 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 시스템의 보안 레벨에 따라 다음과 같이 두가지 방식으로 서비스될 수 있다.

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


[그림] SSO Progation Model


[그림] One Token for All Multi Cookie Domain

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


[그림] One Token for each domain & One Token for Master Agent


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 시스템 도입을 결정하는데 도움이 될 것이다.


출처 : 경영과 컴퓨터 2004년 3월호

'EAM/SSO' 카테고리의 다른 글

EAM/SSO 기술과 통향 1  (0) 2005.04.07
EAM/SSO 기술과 통향 3  (0) 2005.04.07