7장 SEAM 참조 설명서

이 장에서는 SEAM 제품에 포함된 여러 파일과 명령, 데몬에 대해 설명합니다. 또한 Kerberos 인증 시스템의 작동 방법에 대해서도 자세히 설명합니다.

이 장의 주요 내용은 다음과 같습니다.

• "SEAM 파일"

• "SEAM 명령어"

• "SEAM 데몬"

• "SEAM 용어"

• "인증 시스템의 작동 방법"

• "SEAM을 사용하여 서비스 액세스 권한 획득"

• "gsscred 테이블 사용"

SEAM 파일

PAM 구성 파일

SEAM과 함께 제공된 기본 PAM 구성 파일에는 Kerboros 암호화를 지원하는 새로운 응용 프로그램을 관리하는 항목들이 있습니다. 새 파일에는 인증 서비스, 계정 관리, 세션 관리, 암호 관리 모듈에 해당하는 각 항목이 들어 있습니다.

인증 모듈의 경우 rlogin과 login, dtlogin, krlogin, ktelnet, krsh에 새로운 항목이 있습니다. 이 항목들에 대한 예는 아래에 나와 있습니다. 이들 서비스는 모두 새로운 PAM 라이브러리인 /usr/lib/security/pam_krb5.so.1을 사용하여 Kerberos 인증을 제공합니다.

첫 세 항목은 사용자의 초기 암호를 사용하여 인증을 요청하는 try_first_pass 옵션을 사용합니다. 초기 암호를 사용하면 여러 메커니즘이 표시될 경우에도 사용자가 다른 암호를 입력하지 않아도 됩니다.

다음 세 항목은 acceptor 옵션을 사용하여 PAM 모듈이 초기 티켓 부여 티켓을 얻는 단계를 수행할 수 없도록 합니다. Kerboros 암호화를 지원하는 서버 응용 프로그램의 경우, 응용 프로그램에서 이미 교환이 이루어졌기 때문에 PAM을 사용하여 이 단계를 수행할 필요가 없습니다. 이 외에 지정되지 않은 인증을 요구하는 모든 항목의 기본 항목으로서 other 항목이 있습니다.

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

계정 관리의 경우, dtlogin에 다음과 같이 Kerberos 라이브러리를 사용하는 새로운 항목과 기본 규칙을 제공하는 other 항목이 있습니다. 현재 other 항목에서 실행되는 작업은 없습니다.

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

/etc/pam.conf 파일의 마지막 두 항목은 아래에서 설명합니다. 세션 관리 모듈의 other 항목은 사용자 증명서를 폐기합니다. 암호 관리 모듈에서 새로운 other 항목은 Kerberos 라이브러리를 선택합니다.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM 명령어

이 절에서는 SEAM 제품에 포함된 명령어들에 대해 설명합니다.

share 명령변경 사항

SEAM 제품에는 새로운 SEAM 명령이 포함되었을 뿐 아니라 Solaris 2.6 과 Solaris 7 릴리스에서 제공된 share 명령이 변경되었습니다. 새로운 3개의 보안 모드가 share 명령에서 사용됩니다.

krb5

Kerberos 인증을 선택합니다.

krb5I

무결성을 사용한 Kerberos 인증을 선택합니다.

krb5p

무결성과 프라이버시를 사용한 Kerberos 인증을 선택합니다.

여러 모드가 share 명령으로 포함되었을 경우, 클라이언트가 보안 모드를 지정하지 않으면 기본적으로 첫번째로 표시된 모드가 사용됩니다. 그 외의 경우에는 클라이언트가 선택한 모드가 사용됩니다.

Kerberos 모드를 사용하는 마운트 요청이 실패할 경우 보안 모드로 none을 사용하여 마운트 작업이 완료됩니다. 이와 같은 상황은 주로 NFS 클라이언트에서 루트 주체가 인증을 받지 못할 경우 발생합니다. 마운트 요청이 성공할 수도 있지만 Kerberos를 통해 인증을 받지 못할 경우 사용자는 파일을 액세스할 수 없습니다. 파일 시스템이 Kerberos 보안 모드를 사용하여 마운트되지 않은 경우를 포함하여, 클라이언트와 서버 간의 모든 트랜잭션에는 Kerberos 인증이 필요합니다.

SEAM 데몬

다음 표에는 SEAM 제품에서 사용되는 데몬이 나열되어 있습니다.

SEAM 용어

다음 절에서는 모든 SEAM 설명서에서 사용되는 용어와 그 정의를 설명합니다. 이들 용어를 알면 설명서의 내용을 이해하기 쉽습니다.

인증 전문 용어

다음은 인증 프로세스를 이해하는 데 필수적인 용어에 대한 설명입니다. 프로그래머와 시스템 관리자는 이러한 용어를 잘 알고 있어야 합니다.

클라이언트는 사용자의 워크스테이션에서 실행되는 소프트웨어입니다. 클라이언트에서 실행 중인 SEAM 소프트웨어는 이 프로세스가 진행되는 동안 여러 가지 요청을 하게 되며, 이 소프트웨어의 작업과 사용자를 구별하는 것이 중요합니다.

서버와 서비스라는 용어는 서로 혼용되는 경우가 많습니다. 명확히 정의하면 서버는 SEAM 소프트웨어가 실행되는 물리적 시스템이고, 서비스는 서버에서 지원되는 특정 기능을 가리킵니다(예: ftp또는nfs 등). 설명서에서 서버는 흔히 서비스의 일부로 표현되지만 이런 경우 용어의 본래 의미가 흐려집니다. 서버는 물리적 시스템을, 서비스는 소프트웨어를 각각 의미합니다.

SEAM 제품에는 세 종류의 키가 있습니다. 개인 키는 각 사용자 주체에게 주어지며 단지 주체의 사용자와 KDC만이 알 수 있습니다. 사용자 주체의 키는 사용자 암호에 따라 지정됩니다. 서버 및 서비스에 해당하는 키는 서비스 키라고 합니다. 이 키의 목적은 개인 키와 동일하지만 서버 및 서비스에 사용됩니다. 세 번째 키 유형은 세션 키입니다. 이 키는 인증 서비스나 티켓 부여 서비스에 의해 생성되며, 클라이언트와 서비스 간의 안전한 트랜잭션을 제공합니다.

티켓은 사용자의 ID를 서버 또는 서비스에 안전하게 전달하기 위해 사용되는 정보 패킷입니다. 티켓은 한 개의 클라이언트 및 특정 서버의 특정 서비스에만 사용할 수 있으며, 서비스 주체 이름, 사용자 주체 이름, 사용자 호스트 IP 주소, 타임스탬프, 티켓 수명 정의 값이 포함됩니다. 클라이언트와 서비스에서 사용될 티켓은 임의의 세션 키로 작성되며, 작성된 티켓은 유효 기간이 만료될 때까지 재사용할 수 있습니다.

증명서는 티켓과 해당 세션 키가 포함된 정보 패킷입니다. 증명서는 해독에 사용될 키 종류에 따라 개인키나 서비스 키로 암호화됩니다.

인증자는 또 다른 유형의 정보입니다. 인증자를 티켓과 함께 사용하면 사용자 주체를 인증할 수 있습니다. 인증자에는 사용자 주체 이름, 사용자 호스트 IP 주소, 타임스탬프 등의 정보가 포함됩니다. 티켓과 달리 인증자는 서비스 사용 요청이 있을 때 단 한 번만 사용할 수 있으며, 해당 클라이언트와 서버의 세션 키를 사용하여 암호화됩니다.

티켓 유형

티켓에는 티켓 사용 방법을 결정하는 속성이 있습니다. 이 속성은 티켓을 작성할 때 지정하며 나중에 변경할 수도 있습니다. 예를 들어, 티켓의 속성을 전송 가능에서 전송됨으로 변경할 수 있습니다. 티켓 속성을 보려면 klist 명령을 사용합니다("티켓 보는 방법" 참고).

티켓에는 다음과 같은 속성이 있습니다.

전송 가능/전송됨

전송 티켓은 호스트 간에 전송이 가능하며 클라이언트가 재인증 받을 필요가 없습니다. 예를 들어, 사용자 david가 jennifer의 컴퓨터에서 전송 티켓을 얻은 경우 새 티켓을 얻어 재인증 받지 않아도 자신의 컴퓨터에 로그인할 수 있습니다. 전송 티켓의 예는 "예 - 티켓 작성"을 참고하십시오. 전송 티켓을 아래의 프록시 가능 티켓과 비교하십시오.

초기

초기 티켓은 티켓 부여 티켓과 상관없이 직접 발행된 티켓입니다. 응용 프로그램에서 암호를 변경할 경우와 같이 일부 서비스에서는 클라이언트가 비밀 키를 확실히 알고 있다는 것을 확인하기 위해, 초기 티켓을 요구할 수 있습니다. 초기 티켓은 클라이언트가 최근에 인증받았음을 나타내므로, 장기간 사용되었을 수도 있는 티켓 부여 티켓을 사용하는 대신 초기 티켓을 사용합니다.

유효하지 않은

유효하지 않은 티켓은 아직 사용할 수 없도록 날짜를 늦춰 적은 티켓입니다. 아래의 날짜를 늦춰 적은 티켓을 참고하십시오. 티켓이 유효해질 때까지 응용 프로그램 서버에서는 이 티켓을 거부합니다. 티켓이 유효해지려면 유효 기간의 시작 시간이 지난 후 VALIDATE 플래그 설정을 사용하여 클라이언트의 TGS 요청에서 티켓을 KDC에 제출해야 합니다.

날짜를 늦출 수 있는/날짜를 늦춰 적은

날짜를 늦춰 적은 티켓은 작성 후 지정된 시간까지 유효하지 않은 티켓입니다. 이 티켓은 밤 늦게 실행되는 일괄 처리 작업 등에 유용합니다. 티켓을 분실해도 일괄 처리 작업이 실행되기 전에는 사용할 수 없기 때문입니다. 날짜를 늦춰 적은 티켓은 발행 시 유효하지 않은 티켓으로 발행되며, 시작 시간이 지나고 클라이언트에서 KDC에 유효화를 요청할 때까지 이러한 상태가 유지됩니다. 위에서 설명한 유효하지 않은 티켓을 참고하십시오. 날짜를 늦춰 적은 티켓은 일반적으로 티켓 부여 티켓의 만기 시간까지 유효하지만, 갱신 표시가 있을 경우에는 티켓 부여 티켓의 최대 유효 기간과 동일하게 설정됩니다. 아래의 갱신 티켓을 참고하십시오.

프록시 가능/프록시

주체는 서비스가 대신 작업을 수행하도록 요청할 경우가 있습니다. 예를 들어, 주체는 서비스에게 제3의 호스트에서 인쇄 작업을 실행하도록 요청할 수 있습니다. 이 때 서비스는 해당 작업에 대해 클라이언트의 ID를 사용할 수 있어야 합니다. 이런 경우 서버가 클라이언트의 프록시로서 작동한다고 말합니다. 프록시의 주체 이름은 티켓이 작성될 때 지정해야 합니다.

프록시 가능 티켓은 전송 가능 티켓과 유사하지만 단지 한 종류의 서비스에 대해서만 유효하고, 전송 가능 티켓은 서비스에게 클라이언트 ID의 전체 사용권을 부여한다는 점이 다릅니다. 따라서 전송 가능 티켓은 일종의 슈퍼 프록시로 생각할 수 있습니다.

갱신

유효 기간이 매우 긴 티켓은 보안상 위험이 있기 때문에 갱신 티켓을 지정할 수 있습니다. 갱신 티켓에는 두 개의 만료 기간이 있습니다. 즉, 현재의 티켓 인스턴스가 만료되는 시간과 모든 티켓에 적용되는 최대 유효 기간입니다. 클라이언트는 티켓을 계속 사용하려면 첫번째 만기일 전에 갱신해야 합니다. 예를 들어, 현재 티켓 인스턴스의 유효 기간은 1시간이고 모든 티켓의 최대 유효 기간은 10시간일 경우, 해당 티켓을 클라이언트가 1시간 이상 보유하려면 이를 1시간 내에 갱신해야 합니다. 최대 유효 기간(10시간)이 지나면 티켓이 자동으로 만기되며 갱신할 수 없습니다.

티켓의 속성을 확인하는 방법에 대한 자세한 내용은 "티켓 보는 방법"을 참고하십시오.

티켓 유효 기간

티켓 부여 티켓을 포함하여 주체가 티켓을 얻으면 티켓의 유효 기간은 다음 유효 기간 중 최소값으로 설정됩니다.

• kinit 명령의 -l 옵션으로 지정된 유효 기간 값(티켓을 얻기 위해 kinit 명령을 사용할 경우)

• kdc.conf 파일에 지정된 최대 유효 기간 값(max_life)

• 티켓을 제공하는 서비스 주체의 Kerberos 데이터베이스에 지정된 최대 유효 기간 값(kinit 명령의 경우 서비스 주체는 krbtgt/ 영역임.)

• 티켓을 요청한 사용자 주체의 Kerberos 데이터베이스에 지정된 최대 유효 기간 값

그림 7-1에서는 TGT의 유효 기간 결정 방법과 네 가지 유효 기간 값의 계산 방법을 설명합니다. 그림 7-1에 설명된 TGT의 유효 기간 결정 방법에 따르면 모든 주체는 티켓을 얻을 때 기본적으로 동일한 방법으로 유효 기간이 결정됩니다. 유일한 차이점은 kinit는 유효 기간 값을 제공하지 않으며 티켓을 제공하는 서비스 주체( krbtgt/ 영역 주체 대신)가 최대 유효 기간 값을 제공한다는 점입니다.

그림 7-1 TGT의 유효 기간 결정 방법

갱신 티켓의 유효 기간도 다음 네 가지 유효 기간 중 최소값으로 결정되지만 대신에 갱신 가능 유효 기간 값이 사용됩니다.

• kinit 명령의 -r 옵션으로 지정된 갱신 가능 유효 기간 값( kinit 명령을 사용하여 티켓을 얻거나 갱신한 경우)

• kdc.conf 파일에 지정된 최대 갱신 가능 유효 기간 값(max_renewable_life)

• 티켓을 제공하는 서비스 주체의 Kerberos 데이터베이스에 지정된 최대 갱신 가능 유효 기간 값(kinit 명령의 경우 서비스 주체는 krbtgt/영역임.)

• 티켓을 요청하는 사용자 주체의 Kerberos 데이터베이스에 지정된 최대 갱신 가능 유효 기간 값

주체 이름

각 티켓은 주체 이름에 의해 구별되며, 주체 이름은 사용자나 서비스를 나타냅니다. 다음은 몇 가지 주체 이름의 예입니다.

인증 시스템의 작동 방법

응용 프로그램에서 ID를 증명하는 티켓과 해당 세션 키를 제공하면 원격 시스템에 로그인할 수 있습니다. 세션 키에는 액세스 중인 사용자와 서비스에 해당하는 정보가 포함됩니다. 티켓과 세션 키는 사용자가 처음으로 로그인할 때 KDC에 의해 작성되며, 증명서는 티켓과 해당 세션 키로 구성됩니다. 여러 네트워크 서비스를 사용하는 과정에서 사용자는 많은 증명서를 갖게 됩니다. 사용자는 특정 서버에서 실행 중인 각 서비스마다 증명서가 필요합니다. 예를 들어, boston 서버의 ftp 서비스에 액세스하려면 하나의 증명서가 필요하고 또 다른 서버의 ftp 서비스에 액세스하려면 새로운 증명서가 필요합니다.

증명서를 작성하고 저장하는 프로세스는 사용자가 인식할 수 없도록 수행됩니다. 증명서는 KDC에 의해 작성되어 요청자에게 전송됩니다. 증명서가 수신되면 증명서 캐시에 저장됩니다.

SEAM을 사용하여 서비스 액세스 권한 획득

사용자가 특정 서버의 특정 서비스에 액세스하려면 두 가지가 필요합니다. 먼저 티켓 부여 티켓(TGT)의 증명서를 얻어야 합니다. 티켓 부여 서비스에서 이 증명서를 해독하면 사용자가 액세스를 요청한 서버에 필요한 두 번째 증명서를 작성해 줍니다. 이 두 번째 증명서를 사용하여 해당 서버의 서비스에 액세스를 요청할 수 있습니다. 서버가 두 번째 증명서를 완전히 해독한 후에 사용자에게 액세스가 부여됩니다. 아래에서 이 프로세스에 대해 자세히 설명합니다.

티켓 부여 서비스에 대한 증명서 획득

1. 인증 프로세스를 시작하려면 클라이언트에서 특정 사용자 주체의 인증 서버에 요청을 보냅니다. 이 요청은 암호화되지 않고 전송됩니다. 이 요청에는 보안에 문제되는 정보가 없으므로 암호화할 필요가 없습니다.

2. 인증 서비스에 의해 요청이 접수되면 KDC 데이터베이스에서 사용자의 주체 이름을 찾습니다. 주체가 일치할 경우 인증 서비스는 해당 주체의 개인 키를 얻어 클라이언트가 사용할 세션 키, 티켓 부여 서비스(세션 키 1), 티켓 부여 서비스의 티켓(티켓 1)을 생성합니다. 이 티켓을 티켓 부여 티켓(TGT)이라고도 합니다. 세션 키와 티켓은 사용자의 개인 키로 암호화되어 클라이언트에게 전송됩니다.

3. 클라이언트는 이 정보와 사용자 주체의 개인 키를 사용하여 세션 키 1과 티켓 1을 해독합니다. 개인 키는 사용자와 KDC 데이터베이스만 알고 있으므로 패킷의 정보는 안전합니다. 클라이언트는 증명서 캐시에 이 정보를 저장합니다.

이 과정에서 보통 사용자의 암호를 입력하라는 메시지가 나타납니다. 입력한 암호가 KDC 데이터베이스에 저장된 개인 키 작성 시 사용된 것과 동일할 경우, 클라이언트는 인증 서비스가 전송한 정보를 해독할 수 있습니다. 이제 클라이언트는 티켓 부여 서비스에서 사용될 증명서가 있으므로 서버에 필요한 증명서를 요청할 수 있습니다.

그림 7-2 티켓 부여 서비스에 대한 증명서 획득

서버에 대한 증명서 획득

1. 클라이언트가 특정 서버에 액세스를 요청하려면 먼저 인증 서비스로부터 서버에 대한 증명서를 얻어야 합니다("티켓 부여 서비스에 대한 증명서 획득" 참고). 그런 다음 서비스 주체 이름, 티켓 1, 세션 키 1로 암호화된 인증자를 포함한 요청을 티켓 부여 서비스로 전송합니다. 티켓 1은 원래 인증 서비스에 의해 티켓 부여 서비스의 서비스 키로 암호화됩니다.

2. 티켓 부여 서비스는 티켓 부여 서비스의 서비스 키를 알고 있으므로 티켓 1을 해독할 수 있습니다. 또한 티켓 1에는 세션 키 1에 대한 정보가 포함되어 있으므로 티켓 부여 서비스에서 인증자를 해독할 수 있습니다. 이 시점에서 사용자 주체는 티켓 부여 서비스의 인증을 받습니다.

3. 인증에 성공하면 티켓 부여 서비스는 사용자 주체와 서버에 대한 세션 키(세션 키 2)와 서버에 대한 티켓(티켓 2)을 생성합니다. 세션 키 2와 티켓 2는 세션 키 1로 암호화됩니다. 세션 키 1은 클라이언트와 티켓 부여 서비스만 알고 있으므로 네트워크에서 안전하게 전송될 수 있습니다.

4. 정보 패킷을 수신하면 클라이언트는 증명서 캐시에 저장되었던 세션 키 1을 사용하여 정보를 해독합니다. 이와 같이 클라이언트는 서버에서 사용될 증명서를 얻음으로써 해당 서버의 특정 서비스에 액세스할 수 있습니다.

그림 7-3 서버에 대한 증명서 획득

특정 서비스의 액세스 권한 획득

1. 클라이언트가 특정 서비스에 액세스를 요청하려면 먼저 인증 서버로부터 티켓 부여 서비스에 대한 증명서를 얻은 다음, 티켓 부여 서비스에서 서버 증명서를 얻어야 합니다("티켓 부여 서비스에 대한 증명서 획득"과 "서버에 대한 증명서 획득" 참고). 클라이언트는 티켓 2와 다른 인증자가 포함된 요청을 서버에 보낼 수 있으며, 인증자는 세션 키 2로 암호화됩니다.

2. 티켓 2는 티켓 부여 서비스에 의해 서비스 키로 암호화됩니다. 서비스 주체는 서비스 키를 알고 있으므로 티켓 2를 해독하고 세션 키 2를 얻습니다. 그런 다음 세션 키 2를 사용하여 인증자를 해독할 수 있습니다. 인증자가 해독되면 클라이언트에게 서비스의 액세스 권한이 부여됩니다.

그림 7-4 특정 서비스의 액세스 권한 획득

gsscred 테이블 사용

NFS 서버는 SEAM 사용자를 확인할 때 gsscred 테이블을 사용합니다. NFS 서비스는 UNIX ID를 사용하여 사용자를 확인하는데 이 ID는 사용자 주체나 증명서에 포함되지 않습니다. gsscred 테이블은 주체 이름과 UNIX UID(암호 파일로부터)에 대한 매핑을 제공합니다. KDC 데이터베이스에 데이터를 입력한 후 이 테이블을 작성하고 관리해야 합니다.

클라이언트 요청이 들어오면 NFS 서비스는 주체 이름을 UNIX ID에 매핑하는데, 매핑이 실패할 경우 gsscred 테이블을 참고합니다. kerberos_v5 메커니즘을 사용하여 root/hostname주체는 자동으로 UID 0에 매핑되며 gsscred 테이블을 참고하지 않습니다. 이것은 gsscred 테이블을 통해 root를 특별히 재매핑할 방법이 없기 때문입니다.

어떤 메커니즘 선택gsscredTable

gsscred 테이블에 적합한 메커니즘을 선택하려면 다음과 같은 몇 가지 요인을 고려해야 합니다.

• 찾기 속도를 향상시키고 싶습니까?

• 데이터 액세스 시 보안을 강화하고 싶습니까?

• 파일을 빠른 시간 내에 작성해야 합니까?

다음 목록에는 선택할 수 있는 모든 후위 메커니즘과 해당 메커니즘의 장점이 나와 있습니다.

파일

gsscred 테이블이 파일 시스템에 저장됩니다. 공유되지 않는 로컬 파일 시스템은 테이블이 작성된 후 네트워크에서 전송되지 않으므로 가장 안전한 후위 메커니즘입니다. 이 경우 파일을 가장 빠른 시간 내에 작성할 수 있습니다.

xfn_files

gsscred 테이블이 /var/fn 파일 시스템에 저장됩니다. 이 파일 시스템은 공유할 수도 있고 공유하지 않을 수도 있습니다. 모든 xfn 파일은 작성하는 데 시간이 오래 걸립니다.

xfn_nis

gsscred 테이블이 NIS 이름 공간에 저장됩니다. 이 파일 시스템에서는 찾기 작업을 안전하게 수행할 수 없습니다. 모든 xfn 파일은 작성하는 데 시간이 오래 걸립니다.

xfn_nisplus

gsscred 테이블이 NIS+ 이름 공간에 저장됩니다. 이 파일 시스템에서는 찾기 작업을 안전하게 수행할 수 없습니다. 모든 xfn 파일은 작성하는 데 시간이 오래 걸립니다.

xfn

gsscred 테이블이 xfn의 기본 시스템에 저장됩니다. 모든 xfn 파일은 작성하는 데 시간이 오래 걸립니다.

파일 후위 메커니즘의 경우 초기 찾기 작업 속도가 느릴 수 있으며, 다른 메커니즘에서는 이름 서비스를 사용하여 초기 찾기 작업을 빠르게 수행할 수 있습니다. 데이터가 캐시된 후 모든 메커니즘의 검색 시간은 거의 비슷합니다.