Sun Java 로고     이전      목차      색인      다음     

Sun 로고
Sun[TM] Identity Manager 8.0 관리 

12장
보안

이 장에서는 Identity Manager 보안 기능에 대한 내용과 보안 위험을 줄일 수 있는 추가 작업에 대한 자세한 내용에 대해 설명합니다.

Identity Manager를 사용하여 시스템 보안을 관리하는 방법을 알아보려면 다음 내용을 검토하십시오.

보안 기능

Identity Manager에서는 보안 위험을 줄일 수 있는 다음 기능을 제공합니다.

또한 시스템 구조는 가능한 경우 항상 보안 위험을 찾아 감소시킵니다. 예를 들어, 로그아웃한 후에는 브라우저의 뒤로 기능을 사용하여 이전에 방문한 페이지에 액세스할 수 없습니다.

동시 로그인 세션 제한

기본적으로 Identity Manager 사용자는 동시 로그인 세션을 가질 수 있습니다. 그러나 시스템 구성 객체를 열어((자세히...) ) security.authn.singleLoginSessionPerApp 구성 속성의 값을 편집하면 동시 세션을 로그인 응용 프로그램당 하나로 제한할 수 있습니다. 이 속성은 각 로그인 응용 프로그램 이름(예: 관리자 인터페이스, 사용자 인터페이스 또는 Identity Manager IDE)에 대한 속성 하나가 포함된 객체입니다. 이 속성 값을 true로 변경하면 각 사용자에 대해 단일 로그인 세션이 적용됩니다.

적용된 경우 사용자는 둘 이상의 세션에 로그인할 수 있지만 마지막 로그인 세션만 유효한 활성 상태로 유지됩니다. 사용자가 유효하지 않은 세션에서 작업을 수행하면 자동으로 세션에서 로그오프되고 세션이 종료됩니다.

비밀번호 관리

Identity Manager를 사용하면 여러 수준에서 비밀번호를 관리할 수 있습니다.

전달 경로 인증

전달 경로 인증을 사용하여 사용자와 관리자가 하나 이상의 서로 다른 비밀번호를 사용하여 액세스할 수 있도록 허용합니다. Identity Manager에서는 다음을 구현하여 인증을 관리합니다.

로그인 응용 프로그램 정보

로그인 응용 프로그램은 사용자가 Identity Manager에 로그인할 때 사용되는 로그인 모듈의 집합 및 순서를 자세히 정의하는 로그인 모듈 그룹 모음을 정의합니다. 각 로그인 응용 프로그램은 하나 이상의 로그인 모듈 그룹으로 이루어져 있습니다.

로그인할 때 로그인 응용 프로그램은 로그인 모듈 그룹 집합을 확인합니다. 로그인 모듈 그룹이 하나만 설정된 경우 이 로그인 모듈 그룹이 사용되며 여기에 포함된 로그인 모듈은 그룹에 정의된 순서로 처리됩니다. 로그인 응용 프로그램에 정의된 로그인 모듈 그룹이 둘 이상 있는 경우 Identity Manager는 각 로그인 모듈 그룹에 적용된 로그인 제약 규칙을 확인하여 처리할 그룹을 결정합니다.

로그인 제약 규칙

로그인 제약 규칙은 로그인 모듈 그룹에 적용됩니다. 로그인 응용 프로그램에 있는 각 로그인 모듈 그룹 집합 중에 한 집합에만 로그인 제약 규칙을 적용할 수 없습니다.

집합에서 처리할 로그인 모듈 그룹을 결정할 때 Identity Manager는 첫 번째 로그인 모듈 그룹의 제약 규칙을 검사합니다. 검사가 성공하면 해당 로그인 모듈 그룹을 처리합니다. 실패한 경우 제약 규칙이 성공하거나 제약 규칙이 없는 로그인 모듈 그룹을 검사할 때까지(그 다음에 사용됨) 각 로그인 모듈 그룹을 차례로 검사합니다.

주

로그인 응용 프로그램에 둘 이상의 로그인 모듈 그룹이 있는 경우 로그인 제약 규칙이 없는 로그인 모듈 그룹은 집합의 끝부분에 위치해야 합니다.

로그인 제약 규칙 예

다음은 위치 기반 로그인 제약 규칙의 예입니다. 이 규칙은 HTTP 헤더에서 요청자의 IP 주소를 가져온 다음 이 주소가 192.168 네트워크에 위치한 것인지 확인합니다. IP 주소에서 192.168이 확인되면 규칙은 true 값을 반환하며, 이 로그인 모듈 그룹이 선택됩니다.

코드 예 12-1 위치 기반 로그인 제약 규칙

 

<Rule authType='LoginConstraintRule' name='Sample On Local Network'>

  <match>

    <ref>remoteAddr</ref>

    <s>192.168.</s>

  </match>

  <MemberObjectGroups>

    <ObjectRef type='ObjectGroup' name='All'/>

  </MemberObjectGroups>

</Rule>

 

로그인 응용 프로그램 편집

메뉴 표시줄에서 보안을 선택한 다음 로그인을 선택하여 로그인 페이지에 액세스합니다.

로그인 응용 프로그램 목록에는 다음 항목이 표시됩니다.

로그인 페이지에서 다음 작업을 수행할 수 있습니다.

로그인 응용 프로그램을 편집하려면 목록에서 선택합니다.

Identity Manager 세션 제한 설정

로그인 응용 프로그램 수정 페이지에서 각 Identity Manager 로그인 세션에 대한 시간 초과 값(한계)을 설정할 수 있습니다. 시간, 분, 초를 선택한 다음 저장을 누릅니다. 설정한 시간 제한이 로그인 응용 프로그램 목록에 표시됩니다.

각 Identity Manager 로그인 응용 프로그램에 대해 세션 시간 초과를 설정할 수 있습니다. 사용자가 Identity Manager 응용 프로그램에 로그인하면 현재 구성된 세션 시간 초과 값이 사용되어 사용자 세션이 비활성으로 인하여 시간 초과될 때 미래 날짜와 시간을 계산합니다. 이 계산된 날짜는 요청될 때마다 확인할 수 있도록 사용자의 Identity Manager 세션에 저장됩니다.

로그인 관리자가 로그인 응용 프로그램 세션 시간 초과 값을 변경하면 해당 값은 이후의 모든 로그인에 적용됩니다. 기존 세션은 사용자가 로그인할 때 적용되는 값을 기준으로 시간 초과됩니다.

HTTP 제한 시간에 설정된 값은 모든 Identity Manager 응용 프로그램에 영향을 주고, 로그인 응용 프로그램 세션 시간 초과 값보다 우선적으로 적용됩니다.

응용 프로그램에 대한 액세스 비활성화

로그인 응용 프로그램 만들기 및 로그인 응용 프로그램 수정 페이지에서 비활성화 옵션을 선택하여 로그인 응용 프로그램을 비활성화하면 사용자가 로그인하지 못합니다. 사용자가 비활성화된 응용 프로그램에 로그인을 시도하면 현재 응용 프로그램을 사용할 수 없다는 메시지를 표시하는 대체 페이지로 리디렉션됩니다. 사용자 정의 카탈로그를 편집하여 이 페이지에 표시되는 메시지를 편집할 수 있습니다.

로그인 응용 프로그램은 옵션을 선택 취소할 때까지 사용할 수 없습니다. 보호 조치로써 관리자 로그인을 비활성화할 수 없습니다.

로그인 모듈 그룹 편집

로그인 모듈 그룹에는 다음 항목이 표시됩니다.

로그인 모듈 그룹 페이지에서 로그인 모듈 그룹을 만들거나 편집 및 삭제할 수 있습니다. 목록에서 로그인 모듈 그룹을 선택하여 편집합니다.

로그인 모듈 편집

다음과 같이 로그인 모듈에 대한 세부 사항을 입력하거나 선택합니다. 각 로그인 모듈에서 모든 옵션을 사용할 수 있는 것은 아닙니다.

저장을 눌러 로그인 모듈을 저장합니다. 모듈이 저장되면 해당 모듈을 로그인 모듈 그룹에서 다른 모든 모듈과 관련하여 적절하게 배치할 수 있습니다.

Caution

둘 이상의 시스템에 대해 인증하도록 Identity Manager 로그인이 구성된 경우, Identity Manager 인증 대상인 모든 시스템에서 계정의 사용자 ID와 비밀번호가 동일해야 합니다.

사용자 ID 및 비밀번호 조합이 다르면 사용자 ID 및 비밀번호가 Identity Manager 사용자 로그인 양식에 입력한 것과 일치하지 않는 시스템에서 로그인이 실패하게 됩니다.

시스템 중 일부는 계정을 잠그기 전에 시도할 수 있는 실패한 로그인 수를 제한하는 잠금 정책을 사용합니다. 이러한 시스템의 경우 Identity Manager를 통한 사용자 로그인이 계속 성공하더라도 결국 사용자 계정이 잠기게 됩니다.

로그인 모듈 처리 논리

코드 예 12-2에는 Identity Manager에서 인증된 사용자 ID를 Identity Manager 사용자에게 매핑하기 위해 사용하는 단계를 기술하는 의사 코드가 포함되어 있습니다.

코드 예 12-2 로그인 모듈 처리 논리를 기술하는 의사 코드

 

if an existing IDM user's ID is the same as the specified user ID

   if that IDM user has a linked resource whose resource name matches the
   resource that was authenticated and whose accountId matches the resource
   accountId returned by successful authentication (e.g. dn), then we have
   found the right IDM user

   otherwise if there is a LoginCorrelationRule associated with the
   configured login module

      evaluate it to see if it maps the login credentials to a single IDM
      user

      otherwise login fails

   otherwise login fails

if the specified userID does not match an existing IDM user's ID

   try to find an IDM user that has a linked resource whose resource name
   matches the resource accountID returned by successful authentication

      if found, then we have found the right IDM user

      otherwise if there is a LoginCorrelationRule associated with the
      configured login module

         evaluate it to see if it maps the login credentials to a single
         IDM user

         otherwise login fails

      otherwise login fails

 

코드 예 12-2에서 시스템은 사용자의 연결된 자원(자원 정보)을 사용하여 일치하는 Identity Manager 사용자를 찾습니다. 하지만 자원 정보 접근 방법이 실패한 경우 loginCorrelationRule이 구성되어 있으면 loginCorrelationRule을 사용하여 일치하는 사용자를 찾게 됩니다.

공통 자원에 대한 인증 구성

논리적으로 동일한 자원(예: 신뢰 관계를 공유하는 여러 Active Directory 도메인 서버)이 여러 개 있거나 동일한 물리적 호스트에 상주하는 자원이 여러 개인 경우 이러한 자원을 공통 자원으로 지정할 수 있습니다.

Identity Manager가 하나의 자원 그룹에 한 번만 시도하여 인증해야 한다고 인식하도록 공통 자원을 선언해야 합니다. 이렇게 하지 않으면 사용자가 잘못된 비밀번호를 입력했을 때 Identity Manager가 각 자원에 대해 동일한 비밀번호를 시도하기 때문에 잘못된 비밀번호를 한 번만 입력해도 사용자의 계정에서 여러 차례 로그인 실패가 발생하여 계정이 잠길 수 있습니다.

공통 자원을 사용하면 사용자가 하나의 공통 자원으로 인증될 수 있으며 Identity Manager에서 자동으로 해당 사용자를 공통 자원 그룹의 나머지 자원에 매핑을 시도합니다. 예를 들어, Identity Manager 사용자 계정이 자원 AD-1에 대한 자원 계정에 연결되어 있는데 로그인 모듈 그룹에서 사용자가 자원 AD-2로 인증되어야 한다고 정의할 수 있습니다.

AD-1 및 AD-2가 공통 자원(이 경우 신뢰할 수 있는 같은 도메인에 있음)으로 정의된 경우 사용자가 AD-2에 성공적으로 인증되면 Identity Manager도 자원 AD-1에 대한 동일한 사용자 accountId를 찾아서 해당 사용자를 AD-1에 매핑할 수 있습니다.

주

공통 자원 그룹에 등록된 모든 자원은 로그인 모듈 정의에도 포함되어야 합니다. 로그인 모듈 정의에 전체 공통 자원 목록이 표시되지 않는 경우 공통 자원 기능이 올바르게 작동하지 않습니다.

공통 자원은 시스템 구성 객체((자세히...) )에서 다음 형식으로 정의할 수 있습니다.

코드 예 12-3 공통 자원에 대한 인증 구성

 

<Attribute name='common resources'>

    <Attribute name=°Ø× ¿ø ±Þ² ¿³ß°Ø>

        <List>

            <String>× ¿ø ¿³ß</String>

            <String>× ¿ø ¿³ß</String>

        </List

    </Attribute>

</Attribute>

 

X509 인증서 인증 구성

Identity Manager의 X509 인증서 인증을 구성하려면 다음 정보와 절차를 사용하십시오.

전제 조건

Identity Manager에서 X509 인증서 기반 인증을 지원하려면 양방향(클라이언트 및 서버) SSL 인증이 제대로 구성되어야 합니다. 즉, 클라이언트 관점에서 X509 호환 사용자 인증서를 브라우저로 가져오고(또는 스마트 카드 판독기를 통해 사용 가능해야 함), 사용자 인증서를 서명하는 데 사용되는 신뢰된 인증서를 웹 응용 프로그램 서버의 신뢰된 인증서 키 저장소로 가져와야 합니다.

또한 사용되는 클라이언트 인증서가 클라이언트 인증에 대해 활성화되어야 합니다.

클라이언트 인증서의 클라이언트 인증 옵션이 선택되었는지 확인하려면 다음 단계를 수행합니다.

  1. Internet Explorer에서 도구를 선택한 다음 인터넷 옵션을 선택합니다.
  2. 내용 탭을 선택합니다.
  3. 인증서 영역에서 인증서를 누릅니다.
  4. 클라이언트 인증서를 선택하고 고급을 누릅니다.
  5. 인증서 용도 영역에서 클라이언트 인증 옵션이 선택되었는지 확인합니다.

Identity Manager의 X509 인증서 인증 구성

X509 인증서 인증에 대해 Identity Manager를 구성하려면 다음 단계를 수행합니다.

  1. 관리자 인터페이스에 구성자(또는 이와 동등한 사용 권한을 가진 사용자)로 로그인합니다.
  2. 구성을 선택한 다음 로그인을 선택하여 로그인 페이지를 표시합니다.
  3. 로그인 모듈 그룹 관리를 눌러 로그인 모듈 그룹 페이지를 표시합니다.
  4. 목록에서 로그인 모듈 그룹을 선택합니다.
  5. 로그인 모듈 할당... 목록에서 Identity Manager X509 인증서 로그인 모듈을 선택합니다. Identity Manager에 로그인 모듈 수정 페이지가 표시됩니다.
  6. 로그인 성공 조건을 설정합니다. 사용 가능한 값은 다음과 같습니다.
    • 필수 - 로그인 모듈이 성공해야 합니다. 성공 또는 실패 여부에 관계 없이 목록의 다음 로그인 모듈에 대한 인증을 계속 수행합니다. 해당 모듈이 유일한 로그인 모듈인 경우 관리자가 성공적으로 로그인됩니다.
    • 선행 조건 - 로그인 모듈이 성공해야 합니다. 성공한 경우 목록의 다음 로그인 모듈에 대한 인증을 계속 수행합니다. 실패하면 인증이 중단됩니다.
    • 충분 - 로그인 모듈이 반드시 성공해야 할 필요는 없습니다. 성공할 경우 다음 로그인 모듈에 대한 인증을 계속 수행하지 않으며 관리자가 성공적으로 로그인됩니다. 실패할 경우 목록의 다음 로그인 모듈에 대한 인증을 계속 수행합니다.
    • 선택 - 로그인 모듈이 반드시 성공해야 할 필요는 없습니다. 성공 또는 실패 여부에 관계 없이 목록의 다음 로그인 모듈에 대한 인증을 계속 수행합니다.
  7. 로그인 상호 관계 규칙을 선택합니다. 기본 제공되는 규칙 또는 사용자가 정의한 상호 관계 규칙을 선택할 수 있습니다. (사용자 정의 상호 관계 규칙 만들기에 대한 내용은 다음 절을 참조하십시오.)
  8. 저장을 눌러 로그인 모듈 그룹 수정 페이지로 돌아갑니다.
  9. 원하는 경우 로그인 모듈의 순서를 다시 지정하고(로그인 모듈 그룹에 둘 이상의 로그인 모듈이 할당된 경우) 저장을 누릅니다.
  10. 아직 할당되지 않은 경우 로그인 모듈 그룹을 로그인 응용 프로그램에 할당합니다. 로그인 모듈 그룹 페이지에서 로그인 응용 프로그램으로 돌아가기 버튼을 누른 다음 로그인 응용 프로그램을 선택합니다. 로그인 모듈 그룹을 해당 응용 프로그램에 할당한 후 저장을 누릅니다.

    11. 주

    allowLoginWithNoPreexistingUser 옵션이 waveset.properties 파일에서 true 값으로 설정되어 있으면 Identity Manager X509 인증서 로그인 모듈을 구성할 때 새 사용자 이름 규칙을 선택하라는 메시지가 나타납니다. 이 규칙은 연결된 로그인 상호 관계 규칙으로 사용자를 찾지 못한 경우 새로 만든 사용자의 이름 지정 방법을 결정하는 데 사용됩니다.

    새 사용자 이름 규칙에서는 로그인 상호 관계 규칙과 동일한 입력 인수를 사용할 수 있습니다. 이 규칙은 user name used to create the new Identity Manager user account라는 단일 문자열을 반환합니다.

    새 사용자 이름 규칙 예제는 idm/sample/rules에 NewUserNameRules.xml이라는 이름으로 포함되어 있습니다.

로그인 상호 관계 규칙 만들기 및 가져오기

로그인 상호 관계 규칙은 인증서 데이터를 해당 Identity Manager 사용자에 매핑하는 방법을 결정하기 위해 Identity Manager X509 인증서 로그인 모듈에 의해 사용됩니다. Identity Manager는 X509 인증서 subjectDN을 통해 Correlate라는 상호 관계 규칙을 기본으로 제공합니다.

사용자가 직접 상호 관계 규칙을 추가할 수도 있습니다. 예를 보려면 idm/sample/rules 디렉토리의 LoginCorrelationRules.xml을 참조하십시오. 각 상호 관계 규칙은 다음 지침을 따라야 합니다.

로그인 상호 관계 규칙에 전달되는 인수는 다음과 같습니다.

로그인 상호 관계 규칙에 전달되는 인증서 인수의 이름 지정 규칙은 다음과 같습니다.

cert.field name.subfield name

다음은 규칙에 사용할 수 있는 인수 이름의 예입니다.

로그인 상호 관계 규칙은 전달 인수를 사용하여 하나 이상의 AttributeConditions 목록을 반환합니다. 이들은 연결된 Identity Manager 사용자를 찾기 위해 Identity Manager X509 인증서 로그인 모듈에 의해 사용됩니다.

예제 로그인 상호 관계 규칙은 idm/sample/rules에 LoginCorrelationRules.xml이라는 이름으로 포함되어 있습니다.

사용자 정의 상호 관계 규칙을 만든 후 이를 Identity Manager로 가져와야 합니다. 관리자 인터페이스에서 구성을 선택한 다음 교환 파일 가져오기를 선택하여 파일 가져오기 기능을 사용합니다.

SSL 연결 테스트

SSL 연결을 테스트하려면 SSL을 통해 구성된 응용 프로그램 인터페이스의 URL로 이동합니다(예: https://idm007:7002/idm/user/login.jsp). 보안 사이트에 들어가고 있다는 메시지가 나타난 후 웹 서버로 전송할 개인 인증서를 지정하라는 메시지가 표시됩니다.

문제 진단

X509 인증서를 통해 인증하는 동안 발생한 문제는 로그인 양식에 오류 메시지로 보고되어야 합니다. 더욱 자세한 진단을 위해 다음 클래스와 수준에서 Identity Manager 서버에 대한 추적 기능을 사용합니다.

HTTP 요청에서 클라이언트 인증서 속성이 javaxservlet.request.X509Certificate가 아닌 다른 이름으로 지정된 경우 이 속성을 HTTP 요청에서 찾을 수 없다는 메시지가 나타납니다.

이를 수정하려면 다음과 같이 수행합니다.

  1. SessionFactory에 대한 추적을 사용하여 HTTP 속성의 전체 목록을 확인하고 X509Certificate의 이름을 결정합니다.
  2. Identity Manager 디버그 기능 ((자세히...) )을 사용하여 LoginConfig 객체를 편집합니다.
  3. Identity Manager X509 인증서 로그인 모듈의 <LoginConfigEntry>에서 <AuthnProperty>의 이름을 올바른 이름으로 변경합니다.
  4. 저장한 다음 다시 시도합니다.

로그인 응용 프로그램에서 Identity Manager X509 인증서 로그인 모듈을 제거한 다음 다시 추가해야 하는 경우도 있습니다.

암호화 사용 및 관리

암호화는 서버와 게이트웨이 사이에 전송되는 모든 데이터 외에도 메모리 및 저장소의 서버 데이터의 기밀성과 무결성을 확인하는 데 사용됩니다.

다음 절에서는 Identity Manager 서버 및 게이트웨이에서 암호화가 사용되고 관리되는 방법에 대한 자세한 정보를 제공하고 서버 및 게이트웨이 암호화 키에 대한 질문을 해결합니다.

암호화로 보호되는 데이터

다음 표에서는 각 데이터 유형의 보호에 사용되는 암호화를 포함하여 Identity Manager 제품에서 암호화를 통해 보호되는 데이터 유형을 나타냅니다.

표 12-1 암호화로 보호되는 데이터 유형 

데이터 유형

RSA
MD5

NIST
Triple DES
168비트 키
(DESede/ECB/NoPadding)

PKCS#5
비밀번호 기반 암호화
56비트 키
(PBEwithMD5andDES)

서버 암호화 키

 

기본값

구성 옵션1

게이트웨이 암호화 키

 

기본값

구성 옵션1

정책 사전 단어

예

 

 

사용자 비밀번호

 

예

 

사용자 비밀번호 내역

 

예

 

사용자 응답

 

예

 

자원 비밀번호

 

예

 

자원 비밀번호 내역

예

 

 

서버와 게이트웨이 사이의 모든 페이로드

 

예

 

1pbeEncrypt 속성이나 서버 암호화 관리 작업을 사용하여 시스템 구성 객체((자세히...) )를 통해
구성합니다.

서버 암호화 키 질문 및 응답

서버 암호화 키 소스, 위치, 유지 보수 및 사용에 대해 자주 묻는 질문에 대한 답변은 다음 절을 참조하십시오.

서버 암호화 키 출처

서버 암호화 키는 대칭, triple-DES 168비트 키입니다. 다음 두 유형의 키가 서버에서 지원됩니다.

서버 암호화 키가 유지되는 위치

서버 암호화 키는 저장소에 유지되는 객체입니다. 모든 주어진 저장소에 여러 데이터 암호화 키가 있을 수 있습니다.

암호화된 데이터의 암호 해독 및 재암호화에 사용할 키를 서버가 인식하는 방법

저장소에 저장된 암호화된 각 데이터에는 암호화에 사용된 서버 암호화 키의 아이디가 접두어로 지정됩니다. 암호화된 데이터가 포함된 객체가 메모리로 읽혀지면 Identity Manager는 암호화된 데이터의 아이디 접두어와 연관된 서버 암호화 키를 사용하여 암호 해독한 다음, 데이터가 변경된 경우 동일한 키를 사용하여 다시 암호화합니다.

서버 암호화 키를 업데이트하는 방법

Identity Manager는 서버 암호화 관리 작업을 제공합니다. 인증된 보안 관리자는 이 작업을 통해 다음을 포함하여 몇 가지 키 관리 작업을 수행할 수 있습니다.

이 작업을 사용하는 방법에 대해서는 이 장의 서버 암호화 관리를 참조하십시오.

"현재" 서버 키가 변경된 경우 기존 암호화 데이터에 미치는 영향

아무 영향이 없습니다. 기존 암호화 데이터는 암호화된 데이터의 아이디 접두어가 참조하는 키를 사용하여 암호 해독되거나 재암호화됩니다. 새 서버 암호화 키가 생성되어 "현재" 키로 설정된 경우 암호화될 새 데이터는 모두 새 서버 키를 사용합니다.

더 높은 수준의 데이터 무결성을 유지하면서 다중 키 문제를 방지하려면, 서버 암호화 관리 작업을 사용하여 기존의 모든 암호화된 데이터를 "현재" 서버 암호화 키로 다시 암호화합니다.

암호화 키를 사용할 수 없는 암호화된 데이터를 가져오면 어떻게 됩니까?

암호화된 데이터를 포함하는 객체를 가져오는데, 해당 데이터를 가져오는 저장소에 없는 키로 데이터가 암호화된 경우에는 데이터를 가져오지만 암호가 해독되지 않습니다.

서버 키 보호 방법

서버가 암호 기반 암호화(PBE) - PKCS#5 암호화(pbeEncrypt 속성 또는 서버 암호화 관리 작업을 통해 시스템 구성 객체에서 설정)를 사용하도록 구성되지 않은 경우, 서버 키의 암호화에 기본 키가 사용됩니다. 기본 키는 모든 Identity Manager 설치에 대해 동일합니다.

서버가 PBE 암호화를 사용하도록 구성된 경우, 서버가 시작될 때마다 PBE 키가 생성됩니다. PBE 키는 서버별 비밀에서 생성된 암호를 PBEwithMD5andDES 암호화 도구에 제공하여 생성됩니다. PBE 키는 메모리에만 유지되며 영구적이지 않습니다. 또한 PBE 키는 공통 저장소를 공유하는 모든 서버에 대해 동일합니다.

서버 키의 PBE 암호화를 활성화하려면 암호화 PBEwithMD5andDES를 사용할 수 있어야 합니다. Identity Manager는 기본적으로 이 암호화를 패키징하지 않지만, 이는 Sun 및 IBM에서 제공하는 것과 같은 여러 JCE 제공 업체의 구현에서 사용 가능한 PKCS#5 표준입니다.

안전한 외부 저장을 위해 서버 키 내보내기 가능 여부

그렇습니다. 서버 키가 PBE 암호화된 경우 내보내기 전에 기본 키로 암호 해독되고 재암호화됩니다. 이로써 로컬 서버 PBE 키와는 독립적으로 나중에 다른 서버 또는 같은 서버로 가져올 수 있습니다. 서버 키가 기본 키로 암호화된 경우 내보내기 전에 사전 처리가 수행되지 않습니다.

키를 서버로 가져올 때 서버가 PBE 키에 대해 구성되어 있고 서버가 PBE 키 암호화에 대해 구성된 경우 키는 로컬 서버의 PBE 키를 사용하여 암호 해독되고 재암호화됩니다.

서버와 게이트웨이 사이에서 암호화되는 데이터

서버와 게이트웨이 사이에 전송되는 모든 데이터(페이로드)는 임의로 생성되는 서버-게이트웨이 세션간 대칭 168비트 키를 사용하여 triple-DES 암호화됩니다.

게이트웨이 키 질문과 대답

게이트웨이 소스, 저장소, 분배 및 보호에 대해 자주 묻는 질문(FAQ)에 대한 대답에 대해서는 다음 절을 참조하십시오.

데이터 암호화 또는 암호 해독을 위한 게이트웨이 키의 출처

Identity Manager 서버가 게이트웨이에 연결될 때마다 초기 핸드셰이크는 임의의 새로운 168비트 triple-DES 세션 키를 새로 생성합니다. 이 키는 해당 서버 및 해당 게이트웨이 사이에 전송되는 모든 후속 데이터의 암호화 또는 암호 해독에 사용됩니다. 각 서버/게이트웨이 쌍에 대해 생성되는 고유한 세션 키가 있습니다.

게이트웨이 키가 게이트웨이로 분배되는 방법

세션 키는 서버에 의해 임의로 생성된 다음 초기 서버 대 게이트웨이 핸드셰이크의 일부로서 공유 비밀 마스터 키를 사용하여 암호화되어 서버와 게이트웨이 사이에 안전하게 교환됩니다.

초기 핸드셰이크 시 서버는 게이트웨이를 쿼리하여 지원되는 모드를 확인합니다. 게이트웨이는 다음 두 모드에서 작동할 수 있습니다.

서버 대 게이트웨이 페이로드의 암호화 또는 암호 해독에 사용되는 게이트웨이 키 업데이트

Identity Manager는 인증된 보안 관리자가 "현재" 게이트웨이 키를 새로 생성하고 "현재" 게이트웨이 키를 사용하여 모든 게이트웨이를 업데이트하는 등과 같은 몇 가지 키 관리 작업을 수행할 수 있도록 하는 서버 암호화 관리 기능을 제공합니다. 이는 서버와 게이트웨이 사이에 전송되는 모든 페이로드를 보호하는 데 사용되는 세션별 키의 암호화에 사용되는 키입니다. 새로 생성되는 게이트웨이 키는 시스템 구성((자세히...) )의 pbeEncrypt 속성 값에 따라 기본 키 또는 PBE 키를 사용하여 암호화됩니다.

서버 및 게이트웨이의 게이트웨이 키 저장 장소

서버에서는, 게이트웨이 키가 서버 키와 마찬가지로 저장소에 저장됩니다. 게이트웨이에서는 게이트웨이 키가 로컬 레지스트리 키에 저장됩니다.

게이트웨이 키 보호 방법

게이트웨이 키는 서버 키와 같은 방법으로 보호됩니다. 서버가 PBE 암호화를 사용하도록 구성된 경우, 게이트웨이 키는 PBE가 생성된 키를 사용하여 암호화됩니다. 옵션이 false인 경우 기본 키를 사용하여 암호화됩니다. 자세한 내용은 이전 절 서버 키 보호 방법을 참조하십시오.

안전한 외부 저장을 위해 게이트웨이 키 내보내기 가능 여부

게이트웨이 키는 서버 키와 마찬가지로 서버 암호화 관리 작업을 통해 내보낼 수 있습니다. 자세한 내용은 이전 절 안전한 외부 저장을 위해 서버 키 내보내기 가능 여부를 참조하십시오.

서버 및 게이트웨이 키 삭제 방법

서버 및 게이트웨이 키는 서버 저장소에서 삭제하면 삭제됩니다. 서버 데이터가 해당 키를 사용하여 암호화되거나 게이트웨이가 아직 해당 키를 사용하는 경우에는 키를 삭제해서는 안됩니다. 서버 암호화 관리 작업을 사용하여 현재 서버 키로 모든 서버 데이터를 재암호화하고 현재 게이트웨이 키를 모든 게이트웨이에 동기화하여 이전 키가 삭제되기 전에 더 이상 사용되지 있지는 않는지 확인합니다.

서버 암호화 관리

다음 그림과 같이 Identity Manager 서버 암호화 기능을 사용하여 새 3DES 서버 암호화 키를 만들고 3DES 또는 PKCS#5 암호화를 사용하여 이 키를 암호화할 수 있습니다. 보안 관리자 기능이 있는 사용자만 서버 암호화 관리 작업을 실행할 수 있으며, 이 작업은 서버 작업 탭에서 액세스됩니다.

그림 12-1 서버 암호화 관리 작업

관리자 알림에서 알림 수신자 지정

작업 실행을 선택한 다음 목록에서 서버 암호화 관리를 선택하여 작업에 대하여 이 정보를 구성합니다.

보안 객체에 인증 유형 사용

일반적으로 AdminGroup 기능에 지정된 권한을 사용하여 구성, 규칙 또는 TaskDefinition 등의 Identity Manager 객체 유형에 대한 액세스 권한을 부여합니다. 그러나 하나 이상의 제어된 조직에서 Identity Manager 객체 유형의 모든 객체에 대한 액세스 권한을 일일이 부여하는 일이 너무 광범위한 경우가 발생합니다.

인증 유형(AuthType)을 사용하면 이러한 액세스에 대해 추가로 범위를 정하거나 제한하여 지정된 Identity Manager 객체 유형에 대한 객체 하위 집합에 액세스하도록 할 수 있습니다. 예를 들어, 사용자 양식에서 선택되는 규칙을 구성할 때 사용자에게 제어 범위에 속한 일부 규칙에 대한 액세스 권한만 부여하려는 경우가 있습니다.

새 인증 유형을 정의하려면 Identity Manager 저장소에 있는 AuthorizationTypes 구성 객체를 편집하여 새 <AuthType> 요소를 추가합니다. 이 요소에는 두 가지 등록 정보가 필요합니다.

예를 들어, Rule로 확장되는 Marketing Rule이라는 새 규칙 인증 유형을 추가하려면 다음을 정의합니다.

<AuthType name='Marketing Rule' extends='Rule'/>

그 다음은 사용할 인증 유형을 활성화하기 위해 두 곳에서 해당 인증 유형을 참조해야 합니다.

다음은 이 두 참조의 예입니다.

첫 번째 예는 Marketing Rules에 대한 액세스 권한을 부여하는 AdminGroup 기능 정의입니다.

코드 예 12-4

<AdminGroup name='Marketing Admin'>

<Permissions>

<Permission type='Marketing Rule' rights='View,List,Connect,Disconnect/>

</Permissions>

<AdminGroups>

<ObjectRef type='AdminGroup' id='#ID#Account Administrator'/>

</AdminGroups>

</AdminGroup>

다음 예는 Rule 또는 Marketing Rule에 대한 액세스 권한이 부여되었기 때문에 사용자에게 객체에 대한 액세스를 허용하는 Rule 정의입니다.

<Rule name='Competitive Analysis Info' authType='Marketing Rule'>

...

</Rule>

주

상위 인증 유형 또는 인증 유형이 확장되는 정적 유형에 대한 권한이 부여된 모든 사용자는 모든 하위 인증 유형에 대해 동일한 권리를 갖습니다. 따라서 앞의 예에서 Rule에 대한 권한이 부여된 사용자는 Marketing Rule에 대한 권한도 가집니다. 그러나 그 반대는 성립하지 않습니다.

보안 사례

Identity Manager 관리자는 설정 시뿐만 아니라 그 이후에도 다음의 권장 사항을 따라 보호된 계정 및 데이터에 대한 보안 위험을 더욱 줄일 수 있습니다.

설정 시

작업:

사용 시

작업:

응용 프로그램이 Servlet 2.2와 호환되는 경우 Identity Manager 설치 프로세스가 HTTP 세션 시간 초과를 기본값인 30분으로 설정합니다. 해당 등록 정보를 편집하여 이 값을 변경할 수 있으나, 보안을 강화하려면 이 값을 더 낮은 값으로 설정해야 합니다. 값을 30분 이상으로 설정하면 안 됩니다.

세션 시간 초과 값을 변경하려면 다음 단계를 수행합니다.

  1. web.xml 파일을 편집합니다.이 파일은 응용 프로그램 서버 디렉토리 트리의
    idm/WEB-INF 디렉토리에 있습니다.
  2. 다음 줄의 숫자 값을 변경합니다.

    3. <session-config>
    <session-timeout>30</session-timeout>
    <session-config>



이전      목차      색인      다음     

부품 번호: 820-5434.   Copyright 2008 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.