IBM Tivoli Access Manager(TAM) WebSEAL 개요, junction에 대한 이해

 

>>> IBM Tivoli Access Manager WebSEAL 관리자 안내서 바로가기 <<<

 

 

IBM Tivoli Access Manager WebSEAL 개요

IBM^(R) Tivoli^(R) Access Manager for e-business(Tivoli Access Manager)는e-business 및 분산 어플리케이션을 위한 강력하고 안전한 중앙 집중식 policy 관리 솔루션입니다. IBM Tivoli Access Manager WebSEAL은 고성능의 다중 스레드 웹 서버로서, Tivoli Access Manager 보호 웹 오브젝트 공간에 세분화된 보안 policy를 적용합니다. WebSEAL은 단일 사인 온 솔루션을 제공하며 보안 policy에 백엔드 웹 어플리케이션 서버 자원을 통합할 수 있습니다.

이 장에서는 WebSEAL 서버의 주요 기능에 대해 소개합니다.

다음과 같이 구성되어 있습니다.

• IBM Tivoli Access Manager 및 WebSEAL 소개
• Tivoli Access Manager 보안 모델에 대한 이해
• WebSEAL로 웹 공간 보호
• 보안 policy 계획 및 구현
• WebSEAL 인증에 대한 이해
• WebSEAL junction에 대한 이해

IBM Tivoli Access Manager 및 WebSEAL 소개

IBM Tivoli Access Manager:

IBM Tivoli Access Manager는 지역적으로 분산된 인트라넷 및 엑스트라넷에 있는 자원을 철저하게 보호해 주는 완전한 권한 및 네트워크 보안 policy 관리 솔루션입니다.

Tivoli Access Manager는 최첨단의 보안 policy 관리 기능 외에도, 인증, 권한, 데이터 보안 및 중앙 집중식 자원 관리 기능을 제공합니다.Tivoli Access Manager를 표준 인터넷 기반 어플리케이션과 함께 사용하여 매우 안전하고 잘 관리되는 인트라넷을 빌드할 수 있습니다.

Tivoli Access Manager는 다음을 제공합니다.

• 인증 프레임워크

  Tivoli Access Manager는 광범위한 내장 인증자를 제공하고 외부 인증자를 지원합니다.

• 권한 프레임워크

  Tivoli Access Manager 권한 API를 통해 액세스되는 Tivoli Access Manager 권한 서비스는 보안 도메인에 있는 보호 자원 요청에 대한 허용 및 거부를 결정합니다.

Tivoli Access Manager를 사용하여 비즈니스에서는 공용 인터넷의 광범위한 연결 및 용이성을 활용하면서 개인용 내부 네트워크 기반 자원에 대한 액세스를 안전하게 관리할 수 있습니다. Tivoli Access Manager는 회사 방화벽 시스템과 결합하여 회사 인트라넷을 무단 액세스 및 침입으로부터 완전히 보호할 수 있습니다.

IBM Tivoli Access Manager WebSEAL:

IBM Tivoli Access Manager WebSEAL은 웹 기반 정보 및 자원을 관리하고 보호해야 하는 자원 관리자입니다.

WebSEAL은 고성능의 다중 스레드 웹 서버로서, Tivoli Access Manager 보호 웹 오브젝트 공간에 세분화된 보안 policy를 적용합니다. WebSEAL은 단일 사인 온 솔루션을 제공하며 보안 policy에 백엔드 웹 어플리케이션 서버 자원을 통합할 수 있습니다.

WebSEAL은 보통 웹 브라우저에서 HTTP/HTTPS 요청을 수신하고 자체 웹 서버 또는 연결된 백엔드 웹 어플리케이션 서버에서 내용을 전달하여 역방향 웹 프록시로서의 역할을 합니다.WebSEAL을 통해 전달된 요청은 Tivoli Access Manager의 권한 서비스가 평가하여 사용자에게 요청된 자원에 액세스할 권한이 있는지 여부를 판별합니다.

WebSEAL은 다음 기능을 제공합니다.

• 다중 인증 메소드 지원

  내장 및 플러그인 구조는 다양한 인증 메커니즘을 지원하는 데 있어서 융통성을 부여합니다.

• HTTP 및 HTTPS 요청 승인
• WebSEAL junction 기술을 통한 백엔드 서버 자원 통합 및 보호
• 로컬 및 백엔드 서버 웹 공간에 대한 세분화된 액세스 제어 관리

  지원되는 자원은 URL, URL 기반 정규 표현식,CGI 프로그램, HTML 파일, Java servlet 및 Java 클래스 파일 등입니다.

• 역방향 웹 프록시 역할 수행

  WebSEAL은 클라이언트에게는 웹 서버로 나타나며 보호하고 있는 연결된 백엔드 서버에는 웹 브라우저로 나타납니다.

• 단일 사인 온 기능 제공
  그림 1. WebSEAL로 웹 공간 보호

  

Tivoli Access Manager 보안 모델에 대한 이해

Tivoli Access Manager 보안 도메인의 보안 policy는 다음 두 가지 주요 보안 구조로 관리 및 제어됩니다.

• 사용자 레지스트리

  사용자 레지스트리(LDAP, Lotus Domino 또는 Microsoft Active Directory)에는 Tivoli Access Manager 보안 도메인에 참여할 수 있는 모든 사용자 및 그룹이 들어 있습니다.

• 마스터 권한(policy) 데이터베이스

  권한 데이터베이스에는 도메인(보호 오브젝트 공간)에 있는 모든 자원에 대한 표시가 들어 있습니다.보안 관리자는 ACL(Access Control List) policyPOP(Protected Object Policy)와 같은 규칙을 보호가 필요한 자원에 적용하여 어떤 레벨의 보안도 지시할 수 있습니다.

인증 프로세스는 WebSEAL에 사용자 ID를 증명하는 것입니다.사용자는 인증된 상태 또는 인증되지 않은 상태로 보안 도메인에 참여할 수 있습니다.사용자 레지스트리에 항목이 있는 사용자만 인증된 사용자가 될 수 있습니다.보안 관리자는 ACL 및 POP를 사용하여 인증되지 않은 사용자가 특정 공용 자원을 사용하게 할 수 있습니다.다른 자원은 인증된 특정 사용자만이 사용할 수 있습니다.

사용자가 WebSEAL에 정상적으로 인증되면, 사용자에 해당하는 알려진 식별 정보 세트가 권한 정보로 작성됩니다.권한 정보에는 사용자 ID, 그룹 구성원, 특수("확장") 보안 속성이 포함됩니다.

Tivoli Access Manager 권한 서비스는 사용자 인증 권한 정보를 요청된 자원에 지정된policy 권한과 비교하여 보안 policy를 실행합니다.결과로 나타나는 권장사항이 자원 관리자(예: WebSEAL)에 전달되어 원래의 요청에 대한 응답을 완료합니다. 사용자 권한 정보는 보안 도메인에 참여하기 위한 필수사항입니다.

보호 오브젝트 공간

보호 오브젝트 공간은 Tivoli Access Manager 보안 도메인에 속하는 자원의 계층 구조 표현입니다.계층 구조 오브젝트 공간에 나타나는 가상 오브젝트는 실제 물리 네트워크 자원을 나타냅니다.

• 시스템 자원 - 실제 물리 파일 또는 어플리케이션
• 보호 오브젝트 - 권한 서비스, Web Portal Manager, 기타 Tivoli Access Manager 관리 유틸리티에서 사용하는 실제 시스템 자원에 대한 논리적 표현

Policy 템플리트는 오브젝트 공간의 오브젝트에 첨부되어 자원을 보호할 수 있습니다. 권한 서비스는 해당 템플리트에 따라 권한을 결정합니다.

Tivoli Access Manager는 다음 오브젝트 공간 범주를 사용합니다.

• 웹 오브젝트

  웹 오브젝트는 HTTP URL이 처리할 수 있는 모든 것을 나타냅니다.여기에는 정적 웹 페이지 및 데이터베이스 쿼리 또는 일부 다른 유형의 어플리케이션으로 변환되는 동적 URL이 포함됩니다.WebSEAL 서버가 웹 오브젝트를 보호할 책임을 집니다.

• Tivoli Access Manager 관리 오브젝트

  관리 오브젝트는 Web Portal Manager를 통해 수행할 수 있는 관리 활동을 나타냅니다. 오브젝트는 사용자를 정의하고 보안 policy를 설정하는 데 필요한 태스크를 나타냅니다.Tivoli Access Manager는 관리 활동의 위임을 지원하며, 보안 policy를 오브젝트 공간의 서브 세트 관리자 능력을 제한할 수 있습니다.

• 사용자 정의 오브젝트

  사용자 정의 오브젝트는 Tivoli Access Manager 권한 API를 통해 권한 서비스를 사용하여 어플리케이션에서 보호하는 고객 정의 태스크 또는 네트워크 자원을 나타냅니다.

  그림 2. Tivoli Access Manager 보호 오브젝트 공간

  

ACL 및 POP policy 정의 및 적용

보안 관리자는 ACL 및 POP policy로 알려진 룰을 정의하고 이러한 policy를 보호 오브젝트 공간에 있는 해당 자원의 오브젝트 표시에 적용하여 Tivoli Access Manager 시스템 자원을 보호합니다.

Tivoli Access Manager 권한 서비스는 이러한 오브젝트에 적용된 policy에 따라 권한을 결정합니다. 보호 오브젝트의 요청된 조작이 허용되면, 자원을 담당하는 어플리케이션이 이 조작을 구현합니다.

한 policy가 여러 오브젝트의 보호 매개변수를 제어할 수 있습니다.룰이 변경되면 해당 템플리트가 첨부된 모든 오브젝트에 영향을 줍니다.

ACL(Access Control List)

Access Control List policy(또는 ACL policy)는 해당 자원에 대해 특정 조작을 수행하는 데 필요한 조건을 지정하는 룰(권한) 세트입니다. ACL policy 정의는 보안 도메인에 대해 확립된 보안 policy의 중요한 구성요소입니다.모든 policy와 마찬가지로 ACL policy는 조직의 보안 요구사항을 보호 오브젝트 공간에 표시된 자원에 각인하는 데 사용됩니다.

ACL policy는 특히 다음을 제어합니다.

1. 자원에 대해 수행할 수 있는 조작
2. 이러한 조작을 수행할 수 있는 사용자

ACL policy는 사용자 및 그룹 지정과 해당 특정 권한을 포함하는 하나 이상의 항목으로 구성됩니다.ACL에는 인증되지 않은 사용자에게 적용되는 룰이 포함될 수도 있습니다.

그림 3. ACL policy

POP(Protected object policies)

ACL policy는 보호 오브젝트에 대한 액세스 요청에서 "yes" 또는 "no"로 응답하기 위한 정보를 권한 서비스에 제공하고 해당 오브젝트에 대한 일부 조작을 수행합니다.

POP policy에는 권한 서비스로부터 "yes" ACL policy 결정과 함께 Tivoli Access Manager Base 및 자원 관리자(예: WebWEAL)로 다시 전달된 요청에 대한 추가 조건이 들어 있습니다. POP 조건을 실행하는 것은 Tivoli Access Manager 및 자원 관리자의 책임입니다.

다음 표에는 POP에 사용 가능한 속성이 나열되어 있습니다.

Tivoli Access Manager Base에서 실행
POP 속성	설명
이름	policy 이름. pdadmin pop 명령의 <pop-name>이 됩니다.
설명	policy에 대한 설명 텍스트. pop show 명령에 표시됩니다.
경고 모드	관리자에게 ACL 및 POP policy를 테스트할 방법을 제공합니다.
감사 레벨	감사 유형(모두, 없음, 성공적인 액세스,거부된 액세스, 오류)을 지정합니다.
액세스 시간	보호 오브젝트에 액세스할 날짜 및 시간 제한사항

자원 관리자(예: WebSEAL)가 실행
POP 속성	설명
보호 수준	데이터 보호 수준(없음, 무결성, 프라이버시)를 지정합니다.
IP 엔드포인트 인증 메소드 Policy	외부 네트워크 구성원이 액세스하기 위한 인증 요구사항을 지정합니다.
문서 캐시 제어	특정 문서 처리를 위한 캐싱 지시사항을 지정합니다.

명시 및 상속 policy

Policy는 명시적으로 적용되거나 상속될 수 있습니다.Tivoli Access Manager 보호 오브젝트 공간은 ACL 및 POP policy 속성을 상속합니다.이는 오브젝트 공간을 관리하는 보안 관리자에게 있어 중요한 고려사항입니다.관리자는 룰이 변경되어야 하는 계층 구조의 지점에서 명시 policy를 적용하기만 하면 됩니다.

그림 4. 명시 및 상속 policy

Policy 관리: Web Portal Manager

Web Portal Manager는 Tivoli Access Manager 보안 도메인의 보안 policy를 관리하는 데 사용되는 웹 기반 그래픽 어플리케이션입니다.pdadmin 명령행 유틸리티는 Web Portal Manager와 동일한 관리 기능과 Web Portal Manager가 지원하지 않는 일부 명령을 제공합니다.

Web Portal Manager(또는 pdadmin)를 통해, 사용자 레지스트리,마스터 권한 policy 데이터베이스 및 Tivoli Access Manager 서버를 관리할 수 있습니다. 또한 사용자/그룹을 추가 및 삭제하고 ACL 및 POP policy를 네트워크 오브젝트에 적용할 수도 있습니다.

WebSEAL로 웹 공간 보호

WebSEAL이 보안 도메인에서 보안을 실행할 때,각 클라이언트는 해당 ID를 증명해야 합니다. 그 다음 Tivoli Access Manager 보안 policy는 클라이언트가 요청된 자원에 대한 조작을 수행할 있는지 여부를 판별합니다. 보안 도메인의 모든 웹 자원에 대한 액세스는 WebSEAL에서 제어하므로, WebSEAL의 인증 및 권한에 대한 요구는 포괄적인 네트워크 보안을 제공할 수 있습니다.

보안 시스템에서 권한은 인증과 구별됩니다.권한은 인증된 클라이언트가 보안 도메인의 특정 자원에 대한 조작을 수행할 수 있는지 여부를 판별합니다. 인증은 클라이언트 ID의 유효성을 검증할 수 있지만,보호 자원에 대한 조작을 수행하기 위한 클라이언트 권한에 대해서는 아무것도 알려주지 않습니다.

Tivoli Access Manager 권한 모델에서, 권한 policy는 사용자 인증에 사용되는 메커니즘과는 별도로 구현됩니다.사용자는 공용-개인 키, 비밀 키 또는 사용자 정의 메커니즘을 사용하여 ID를 인증할 수 있습니다.

인증 프로세스의 일부는 클라이언트의 ID를 설명하는 권한 정보의 작성과 관련이 있습니다.권한 서비스는 사용자 권한 정보에 따라 권한을 결정합니다.

보안 도메인의 자원은 도메인의 보안 policy가 지시하는 보호 레벨을 수신합니다.보안 policy는 보안 도메인의 적절한 관계자,보호를 요하는 각 자원 주변의 보호 수준을 정의합니다.

권한 프로세스는 다음 기본 구성요소로 구성됩니다.

• 자원 관리자는 권한이 부여될 때 요청된 조작을 구현해야 합니다.WebSEAL은 자원 관리자입니다.

  자원 관리자의 구성요소는 처리를 위해 권한 서비스로 요청을 지정하는policy 실행자입니다.

  주:
  종래의 어플리케이션은 policy실행자 및 자원 관리자를 하나의 프로세스로 번들합니다.이러한 구조의 예로는 WebSEAL 및 서드파티(third-party) 어플리케이션이 있습니다.
• 권한 서비스는 요청에 대한 의사 결정 조치를 수행합니다.

다음 다이어그램에서는 전체 권한 프로세스를 보여줍니다.

그림 5. Tivoli Access Manager 권한 프로세스

1. 자원에 대해 인증된 클라이언트 요청이 자원 관리자로 지정되어policy 실행자 프로세스가 인터셉트합니다.

   자원 관리자는 WebSEAL(HTTP, HTTPS 액세스용) 또는 서드파티(third-party) 어플리케이션입니다.

2. policy 실행자 프로세스는 Tivoli Access Manager 권한 API를 사용하여 권한 결정을 위한 권한 서비스를 호출합니다.
3. 권한 서비스는 보호 오브젝트 공간의 오브젝트로 표시되는 자원에 대한 권한을 점검합니다.기본 POP policy를 먼저 점검합니다. 그 다음 클라이언트 권한 정보에 대해 오브젝트에 첨부된 ACL policy를 점검합니다.그런 후 자원 관리자가 실행하는 POP policy를 점검합니다.
4. 요청을 선택 또는 거부할 것인지에 대한 결정이 자원 관리자에게 권장사항으로 리턴됩니다(policy 실행자를 통해).
5. 요청이 최종적으로 승인되면, 자원 관리자는 자원을 담당하는 어플리케이션으로 요청을 전달합니다.
6. 클라이언트는 요청된 조작에 대한 결과를 수신합니다.

보안 policy 계획 및 구현

기업 보안 policy는 다음을 식별합니다.

• 보호가 필요한 웹 자원
• 보호 레벨

Tivoli Access Manager는 보호 오브젝트 공간이라는 이러한 웹 자원의 가상 표시를 사용합니다. 보호 오브젝트 공간에는 네트워크의 실제 자원을 표시하는 오브젝트가 포함됩니다.

보호가 필요한 오브젝트에 적합한 보안 메커니즘을 적용하여 보안 policy를 구현합니다.

보안 메커니즘에는 다음이 있습니다.

• ACL(Access Control List) policy

  ACL policy는 액세스하는 사용자 유형을 식별하고 오브젝트에서 허용된 조작을 지정합니다.

• POP(Protected Object Policy)

  POP는 보호 오브젝트(예: 프라이버시, 무결성, 감사 및 액세스 시간)로의 액세스를 관리하는 추가 조건을 지정합니다.

• 확장된 속성

  확장된 속성은 서드파티(third-party) 어플리케이션(예: 외부 권한 서비스)에 의해 읽혀지고 해석될 수 있는 오브젝트, ACL 또는 POP에 배치되는 추가 값입니다.

Tivoli Access Manager의 핵심 구성요소는 사용자의 권한 정보 및 오브젝트에 있는 액세스 제어에 따라 보호 오브젝트(자원)에 대한 액세스를 허용하거나 거부하는 Tivoli Access Manager 권한 서비스입니다.

보안 policy를 구현하려면 서로 다른 내용 유형(내용 유형 및 보호 레벨 식별에서 설명한 대로)을 논리적으로 구성하고 적합한 ACL 및 POP policy를 적용해야 합니다. 액세스 제어 관리는 매우 복잡하지만 내용 유형을 잘 분류하면 훨씬 쉬워집니다.

내용 유형 및 보호 레벨 식별

웹 공간의 보안 관리자는 다양한 유형의 사용자에 대해 사용 가능한 내용의 유형을 정확하게 식별해야 합니다. 일부 내용은 보안을 강화하여 특정 사용자만 사용 가능하도록 해야 합니다. 다른 내용은 일반 공용 보기가 가능합니다. 보안 시나리오마다 서로 다른 보호 요구사항 및 연관된 WebSEAL 구성이 필요합니다.

사용자가 수행해야 할 일은 다음과 같습니다.

• 웹 내용을 알아야 합니다.
• 이 내용에 액세스하려는 사용자의 유형을 식별해야 합니다.
• 이 내용을 보호하기 위해 사용 가능한 WebSEAL 구성 옵션의 장점 및 단점을 알고 있어야 합니다.

웹 내용 보호는 크게 다음의 세 가지 범주로 나눌 수 있습니다.

1. 공용 내용 - 액세스에는 보호가 필요없습니다.
   • HTTP를 사용하여 인증되지 않은 클라이언트 액세스
   • 자원에 대한 액세스 제어에 사용되는 인증되지 않은 권한 정보
   • 기본 WebSEAL 구성 요구사항
2. 공용 내용 - 액세스하려면 프라이버시(암호화)가 필요합니다.
   • HTTPS를 사용하여 인증되지 않은 클라이언트 액세스
   • 어플리케이션 서버에서 요구하는 중요한 데이터를 보호하기 위해 암호화가 필요함(예: 신용 카드 번호 또는 사용자 계정 정보)
   • 자원에 대한 액세스 제어에 사용되는 인증되지 않은 권한 정보
   • WebSEAL 구성은 프라이버시를 보장해야 함
3. 개인 내용 - 액세스하려면 인증이 필요합니다.
   • HTTP 또는 HTTPS를 사용하여 인증된 클라이언트 액세스
   • 관리자가 암호화의 필요성 결정
   • 자원에 대한 액세스 제어에 사용되는 인증된 권한 정보. 클라이언트는 사용자에게 레지스트리에 정의된 계정이 있어야 함
   • WebSEAL 구성은 복잡하므로 모든 옵션을 신중히 고려하여 보안 policy의 영향을 판별해야 함

WebSEAL 인증에 대한 이해

인증은 보안 도메인에 로그인하려고 시도하는 개별 프로세스 또는 엔티티를 식별하는 방법입니다. 서버 및 클라이언트에 모두 인증이 필요할 경우, 이 교환을 상호 인증이라고 합니다.

그림 6. 상호 인증

WebSEAL은 각 클라이언트가 ID를 증명하도록 보안 도메인에서 높은 수준의 보안을 시행할 수 있습니다.

다음 조건은 WebSEAL 인증에 적용됩니다.

• WebSEAL은 인증 메소드의 표준 세트를 지원함

  WebSEAL을 사용자에 맞게 정의하여 다른 인증 메소드를 지원할 수 있음

• WebSEAL 서버 프로세스는 인증 메소드에 독립적임
• WebSEAL은 클라이언트 ID를 요청함. 이 ID에서 WebSEAL은 Tivoli Access Manager 권한 서비스가 자원에 대한 액세스를 허용하거나 거부하는 데 사용할 수 있는 인증된(또는 인증되지 않은) 권한 정보를 빌드합니다.

인증에 대한 이러한 유연한 접근은 보안 policy가 실제 네트워크 토폴로지가 아닌 비즈니스 요구사항에 기반을 두도록 합니다.

인증의 목표

WebSEAL은 인증 프로세스에서 독립적이지만 인증의 결과인 클라이언트 ID를 필요로 합니다. 인증 프로세스에는 다음 조치가 필요합니다.

1. 인증 메소드로 인해 클라이언트 ID가 작성됩니다.

   사용자가 Tivoli Access Manager 사용자 레지스트리에 정의된 계정을 갖고 있거나 CDAS(Cross-domain Authentication Service)에서 정상적으로 처리되는 경우에만 클라이언트 인증에 성공합니다. 그렇지 않으면 사용자는 인증되지 않은 것으로 지정됩니다.

   메소드 특정 ID 정보(예: 암호, 토큰 및 인증서)는 사용자의 실제 ID 특성을 표시합니다. 이 정보는 서버와의 보안 세션을 확립하는 데 사용됩니다.

2. WebSEAL은 ID를 사용하여 해당 클라이언트에 대한 권한 정보를 확보합니다.

   WebSEAL은 클라이언트 ID를 등록된 Tivoli Access Manager 사용자와 일치시킵니다. 그런 다음 WebSEAL은 이 사용자에게 적합한 권한 정보를 빌드합니다.이를 권한 정보 획득이라고 합니다.

   권한 정보는 보안 도메인에서의 사용자의 권한을 나타내며, 특정 컨텍스트에서 사용자에 대해 설명하고, 해당 세션의 유효기간 동안에만 유효합니다.권한 정보 데이터에는 사용자 이름,그룹 구성원, 특수("확장") 보안 속성이 포함됩니다.

   사용자가 사용자 레지스트리의 구성원이 아닌 경우("익명"),WebSEAL은 해당 사용자에게 대해 인증되지 않은 권한 정보를 빌드합니다.ACL은 인증되지 않은 사용자를 관리하는 특수 룰을 포함할 수 있습니다.

   이 권한 정보는 WebSEAL 보호 오브젝트 공간에서 요청된 오브젝트에 대한 액세스를 허용하거나 거부하는 권한 서비스에서 사용할 수 있습니다.

권한 정보는 클라이언트에 관한 정보가 필요한 모든 Tivoli Access Manager 서비스에서 사용할 수 있습니다. 권한 정보를 사용하여 Tivoli Access Manager는 권한, 감사 및 위임 등의 다수의 서비스를 안전하게 수행할 수 있습니다.

Tivoli Access Manager는 사용자의 인증을 권한 정보의 획득과 구별합니다. 사용자의 ID는 항상 일정합니다. 그러나 사용자가 참여하는 그룹 또는 역할을 정의하는 권한 정보는 일정하지 않습니다.상황별 권한 정보는 시간이 지남에 따라 변할 수 있습니다. 예를 들면, 어떤 사람이 승진하면 권한 정보는 새로운 책임 레벨을 반영해야 합니다.

특정 인증 메소드 지원에 대한 자세한 정보는 WebSEAL 인증을 참조하십시오.

자원에 대한 인증된 액세스 및 인증되지 않은 액세스

Tivoli Access Manager 보안 도메인 환경에서, 사용자 ID는 인증 프로세스를 통해 WebSEAL로 증명됩니다.일반적으로, 사용자는 인증된 상태 또는 인증되지 않은 상태로 보안 도메인에 참여할 수 있습니다.

어느 경우에나 Tivoli Access Manager 권한 서비스는 보안 도메인에 있는 자원에 대한 요청에 따라 권한을 결정할 때 사용자 권한 정보를 필요로 합니다.WebSEAL은 인증된 사용자 권한 정보를 인증되지 않은 사용자 권한 정보와 다르게 처리합니다.

인증되지 않은 사용자의 권한 정보는 단순히 사용자가 보안 도메인에 참여하고 인증되지 않은 사용자가 사용할 수 있는 자원에 액세스할 수 있는 일반 패스포트입니다.

인증된 사용자의 권한 정보는 Tivoli Access Manager 사용자 레지스트리에 속하는 특정 사용자(또는 CDAS를 통해 처리되는)를 설명하는 고유 패스포트입니다. 인증된 사용자 권한 정보에는 사용자 ID, 그룹 구성원, 특수("확장") 보안 속성이 포함됩니다.

인증된 사용자의 프로세스 플로우는 다음과 같습니다.

• 사용자가 WebSEAL이 보호하는 자원을 요청합니다.자원 보호에는 사용자 인증이 필요합니다.WebSEAL은 사용자에게 로그인하라는 프롬프트를 표시합니다.
• 사용자가 Tivoli Access Manager 사용자 레지스트리의 구성원이거나CDAS 조작으로 처리되는 경우에만 인증에 성공할 수 있습니다.
• 해당 사용자에게 WebSEAL 세션 ID가 작성됩니다.
• 이 사용자에 대한 레지스트리에 포함된 정보를 통해 이 사용자에 대한 권한 정보가 빌드됩니다(예: 그룹 구성원).
• 세션 ID 및 권한 정보, 기타 데이터가WebSEAL 세션/권한 정보 캐시의 한 항목으로 저장됩니다.
• WebSEAL이 이러한 요청(및 해당 세션 동안의 추가 요청)을 처리하는 동안 권한 정보는 그대로 유지됩니다.
• 권한 점검이 필요할 때마다, Tivoli Access Manager 권한 서비스는 의사 결정 프로세스에서 권한 정보를 사용합니다.
• 사용자가 로그오프하면, 해당 사용자에 대한 캐시 항목이 제거되고 세션이 종결됩니다.

인증되지 않은 사용자의 프로세스 플로우는 다음과 같습니다.

• 사용자가 WebSEAL이 보호하는 자원을 요청합니다.자원 보호에는 사용자 인증이 필요하지 않습니다.WebSEAL은 사용자에게 로그인하라는 프롬프트를 표시하지 않습니다.
• WebSEAL은 사용자에 대한 인증되지 않은 권한 정보를 빌드합니다.
• WebSEAL 세션/권한 정보 캐시에 항목이 작성되지 않습니다.
• 사용자는 인증되지 않은 사용자 유형 범주에 대해 올바른 권한을 포함하는 자원에 액세스할 수 있습니다.
• 인증되지 않은 사용자가 사용할 수 없는 자원에 액세스해야 할 경우,WebSEAL은 사용자에게 로그인하라는 프롬프트를 표시합니다.
• 로그인하면 사용자 상태가 인증된 상태로 변경됩니다.
• 로그인에 실패하면 403 "금지" 메시지가 리턴됩니다.사용자는 여전히 인증되지 않은 사용자가 사용할 수 있는 다른 자원에 액세스할 수 있습니다.

WebSEAL 세션/권한 정보 캐시 구조

WebSEAL 세션 캐시는 WebSEAL 권한 정보 캐시로도 알려져 있습니다.캐시는 WebSEAL이 인증된 사용자가 확립한 모든 세션에 대한 정보를 저장하는 내부 테이블로 표시될 수 있습니다.

그림 7. WebSEAL 세션/권한 정보 캐시

각 사용자 세션은 캐시 테이블의 항목으로 표시됩니다.

각 캐시 항목에는 다음 유형의 정보가 들어 있습니다.

• 세션 ID

  세션 ID는 해당 사용자가 요청할 때마다 송신되는 고유 ID입니다.세션 ID는 해당 사용자의 특정 캐시 항목을 식별합니다.

• 캐시 데이터

  캐시 항목에 저장되는 가장 중요한 데이터는사용자 권한 정보입니다.사용자가 보호 자원을 요청할 때마다 권한 정보가 필요합니다.권한 서비스는 권한 정보를 사용하여 자원에 대한 액세스를 허용하거나 거부합니다.

  WebSEAL은 캐시 항목을 표시하거나 "플래그"하여 특정 기능을 지원할 수 있습니다.예를 들어 세션 비활동 재인증을 사용하면, 세션 비활동 값이 만료되었을 때 캐시 항목이 "플래그"됩니다.

• 시간 소인

  캐시 항목의 작성 시간 소인은 세션 유효기간 값의 참조 시점이 됩니다.캐시 항목의 "최종 활성" 시간 소인은 세션 비활동 타이머의 참조 시점이 됩니다.

사용자 권한 정보에는 다음이 포함됩니다.

• 사용자 이름
• 그룹 구성원
• 확장된 속성

  확장된 속성을 사용하면 사용자 권한 정보에 사용자 정의 데이터를 저장할 수 있습니다.권한 정보 확장된 속성의 예로는 tagvalue_user_session_id 속성이 있습니다. 이 속성 값을 HTTP 헤더에 삽입하여 백엔드 연결된 서버가 사용자와의 세션 상태를 유지할 수 있습니다.

WebSEAL junction에 대한 이해

Tivoli Access Manager는 네트워크에 대한 인증, 권한 및 관리 서비스를 제공합니다. 웹 기반 네트워크에서 이들 서비스는 백엔드 웹 서버에 있는 웹 지원 및 어플리케이션을 통합하고 보호하는 WebSEAL 서버가 제공하는 것이 가장 좋습니다.

WebSEAL 서버와 백엔드 웹 어플리케이션 서버 간의 연결을 WebSEAL junction이라고 합니다. WebSEAL junction은 프론트엔드 WebSEAL 서버와 백엔드 서버 간의 TCP/IP 연결입니다.

백엔드 서버는 다른 WebSEAL 서버이거나 보다 일반적으로 서드파티(third-party) 웹 어플리케이션 서버일 수 있습니다. 백엔드 서버 웹 공간은 WebSEAL 웹 공간에 특별히 지정된 junction(마운트) 포인트에서 WebSEAL 서버에 "연결"됩니다.

그림 8. junction은 WebSEAL과 백엔드 서버를 연결

junction을 통해 WebSEAL은 백엔드 서버 대신 보호 서비스를 제공할 수 있습니다.WebSEAL은 백엔드 서버에 전달하기 전에 모든 요청에 대해 인증 및 권한을 점검할 수 있습니다.백엔드 서버가 오브젝트에서 세분화된 액세스 제어를 요구하면 추가 구성 단계를 수행하여 서드파티(third-party) 웹 공간을 Tivoli Access Manager 보안 서비스에 설명해야 합니다(서드파티(third-party) 서버에서 query_contents 사용 참조).

junction은 로드 밸런싱, 고가용성 및 상태 관리 기능(모두 클라이언트에 투명하게 수행됨)을 허용하는 크기 조정이 가능한 보안 환경을 제공합니다. 이러한 웹 공간의 중앙 집중식 관리는 관리자에게 도움이 됩니다.

WebSEAL junction은 백엔드 서버의 웹 공간을 WebSEAL 서버의 웹 공간과 논리적으로 결합하여 가치를 높입니다. 협력 서버 간의 junction을 통하여 완전하고 사용자에게 투명한 하나의 단일화된 분산 웹 공간이 만들어집니다.

클라이언트는 웹 자원의 물리적 위치를 알 필요가 없습니다.WebSEAL은 논리적 URL 주소를 백엔드 서버가 예상하는 물리적 주소로 변환합니다. 클라이언트가 웹 오브젝트에 액세스하는 방법에 영향을 주지 않으면서 서버에서 서버로 웹 오브젝트를 이동시킬 수 있습니다.

통합된 웹 공간은 시스템 관리자를 위해 모든 자원의 관리를 단순화시킵니다. 추가 관리의 장점으로는 확장성, 로드 밸런싱 및 고가용성이 있습니다.

그림 9. WebSEAL junction을 통해 단일화된 웹 공간

대부분의 상용 웹 서버에는 논리적 웹 오브젝트 공간을 정의하는 기능이 없습니다.대신 액세스 제어는 물리 파일과 디렉토리 구조에 연결됩니다.WebSEAL junction은 표준 웹 서버에서 자주 발견되는 디렉토리 구조와 물리적 시스템 대신 조직의 구조를 반영하는 오브젝트 공간을 투명하게 정의할 수 있습니다.

WebSEAL junction을 통해 단일 사인 온 솔루션을 작성할 수도 있습니다. 단일 사인 온 구성은 사용자가 자원의 위치에 상관없이 하나의 초기 로그인만을 사용하여 자원에 액세스할 수 있게 합니다. 백엔드 서버의 계속적인 로그인 요구사항은 사용자에게 투명하게 처리됩니다.

WebSEAL junction은 웹 사이트를 크기 조정이 가능하도록 만들어 주는 중요한 도구입니다.junction은 추가 서버를 증설하여 웹 사이트에서 증가하는 요구에 응답할 수 있게 합니다.

WebSEAL junction 및 웹 사이트 크기 조정 가능

WebSEAL junction은 크기 조정이 가능한 웹 사이트를 작성하는 데 사용됩니다. 웹 사이트에서의 요구가 증가함에 따라 서버를 쉽게 추가하여 사이트의 기능을 확장할 수 있습니다.

다음과 같은 경우 서버를 추가할 수 있습니다.

• 내용이 추가되어 사이트를 확장하는 경우
• 로드 밸런싱, 오류 복구 기능 및 고가용성을 위해 기존의 내용을 중복시키는 경우

복제된 프론트엔드 WebSEAL 서버

백엔드 서버에 대한 junction 지원은 최소한 하나의 프론트엔드 WebSEAL 서버에서 시작합니다. 복제된 프론트엔드 WebSEAL 서버는 상당히 많은 요구가 있을 때 사이트에 로드 밸런싱을 제공합니다. 로드 밸런싱 메커니즘은 메커니즘(예: IBM Network Dispatcher 또는 Cisco Local Director)에서 처리됩니다.

프론트엔드 복제는 사이트에 오류 복구 기능도 제공합니다. 서버가 어떠한 이유로 인해 실패하면 나머지 복제본 서버가 사이트에 대한 액세스를 계속해서 제공합니다. 성공적인 로드 밸런싱 및 오류 복구 기능은 사이트의 사용자에게 고가용성을 제공합니다.

그림 10. 복제된 프론트엔드 WebSEAL 서버

프론트엔드 WebSEAL 서버를 복제하면 각 서버에는 웹 공간 및junction 데이터베이스의 정확한 사본이 포함되어야 합니다.

인증을 위한 계정 정보는 사용자 레지스트리에 있으며 이는 프론트엔드 서버에 독립적입니다.

백엔드 서버 지원

웹 사이트의 내용은 WebSEAL 서버 자체, 백엔드 서버 또는 이 둘의 조합으로 제공될 수 있습니다. 백엔드 서버에 대한 WebSEAL junction은 내용 및 자원의 추가를 통해 웹 사이트의 크기를 조정할 수 있게 합니다.

각 고유 백엔드 서버는 별도의 junction(마운트) 포인트에 연결되어야 합니다.추가 내용에 대한 요구가 증가할수록 보다 많은 서버가 junction을 통해 추가됩니다.이 시나리오에서는 서드파티(third-party) 웹 서버를 많이 포함하고 있는 네트워크에 대한 솔루션을 제공합니다.

그림 11. 백엔드 서버 junction

다음 다이어그램에서는 junction이 통합된 논리적 오브젝트 공간을 제공하는 방법을 보여줍니다.이 웹 공간은 사용자에게 투명하며 중앙 집중식 관리를 가능하게 합니다.

그림 12. 통합된 웹 공간

복제된 백엔드 서버는 다음 절에서 설명하는 것처럼 동일한 연결 포인트에 junction됩니다.

복제된 백엔드 서버

확장성 기능을 백엔드 서버 구성에까지 확대하려면 백엔드 서버를 복제하면 됩니다. 복제된 프론트엔드 서버의 경우와 마찬가지로, 복제된 백엔드 서버에는 서로의 미러 이미지인 웹 공간이 포함되어야 합니다.

WebSEAL은 "최소 사용" 스케줄링 알고리즘을 사용하여 복제된 서버에 대해 로드 밸런스를 유지합니다.이 알고리즘은 이미 진행 중인 연결 수가 가장 적은 서버로 새로운 요청을 전달합니다.

또한 WebSEAL은 서버가 다운될 경우 정확하게 오류를 복구하며, 서버가 다시 시작되면 해당 서버를 다시 사용하기 시작합니다.

백엔드 어플리케이션이 몇 페이지에 걸쳐서 유지보수되는 상태를 요구하는 경우, 각 세션이 동일한 백엔드 서버로 리턴되도록 하기 위해 상태 정보 junction을 사용할 수 있습니다.

그림 13. 복제된 백엔드 서버