JavaScript is required to for searching.
탐색 링크 건너뛰기
인쇄 보기 종료
Oracle Solaris 11.1 관리: 보안 서비스     Oracle Solaris 11.1 Information Library (한국어)
search filter icon
search icon

문서 정보

머리말

제1부보안 개요

1.  보안 서비스(개요)

제2부시스템, 파일 및 장치 보안

2.  시스템 보안 관리(개요)

3.  시스템에 대한 액세스 제어(작업)

4.  바이러스 검사 서비스(작업)

5.  장치에 대한 액세스 제어(작업)

6.  BART를 사용하여 파일 무결성 확인(작업)

7.  파일에 대한 액세스 제어(작업)

제3부역할, 권한 프로파일 및 권한

8.  역할 및 권한 사용(개요)

9.  역할 기반 액세스 제어 사용(작업)

10.  Oracle Solaris의 보안 속성(참조)

제4부암호화 서비스

11.  암호화 프레임워크(개요)

12.  암호화 프레임워크(작업)

13.  키 관리 프레임워크

제5부인증 서비스 및 보안 통신

14.  플러그 가능한 인증 모듈 사용

15.  Secure Shell 사용

16.  Secure Shell(참조)

17.  단순 인증 및 보안 계층 사용

18.  네트워크 서비스 인증(작업)

제6부Kerberos 서비스

19.  Kerberos 서비스 소개

Kerberos 서비스란?

Kerberos 서비스의 작동 방식

초기 인증: TGT(티켓 부여 티켓)

후속 Kerberos 인증

Kerberos 원격 응용 프로그램

Kerberos 주체

Kerberos 영역

Kerberos 서버

Kerberos 보안 서비스

여러 Kerberos 릴리스의 구성 요소

Kerberos 구성 요소

이 릴리스의 Kerberos 정보

20.  Kerberos 서비스 계획

21.  Kerberos 서비스 구성(작업)

22.  Kerberos 오류 메시지 및 문제 해결

23.  Kerberos 주체 및 정책 관리(작업)

24.  Kerberos 응용 프로그램 사용(작업)

25.  Kerberos 서비스(참조)

제7부Oracle Solaris에서 감사

26.  감사(개요)

27.  감사 계획

28.  감사 관리(작업)

29.  감사(참조)

용어집

색인

Kerberos 서비스의 작동 방식

다음은 Kerberos 인증 시스템에 대한 개요입니다. 자세한 설명은 Kerberos 인증 시스템의 작동 방식을 참조하십시오.

사용자의 관점에서 Kerberos 서비스는 Kerberos 세션이 시작되면 대개 눈에 띄지 않습니다. ssh 또는 ftp 등의 명령도 동일하게 작동합니다. Kerberos 세션을 초기화하면 더 이상 로그인하거나 Kerberos 암호를 제공할 필요가 없습니다.

Kerberos 시스템은 티켓이라는 개념에 중점을 둡니다. 티켓은 사용자나 서비스(예: NFS 서비스)를 식별하는 전자 정보 세트입니다. 운전 면허증이 사용자의 신원을 확인해 주고 소지하고 있는 운전 면허를 나타내듯이, 티켓은 사용자와 사용자의 네트워크 액세스 권한을 식별합니다. Kerberos 기반 트랜잭션을 수행하는 경우(예: 다른 시스템에 원격 로그인하는 경우) 티켓에 대한 요청이 투명하게 KDC(키 배포 센터)로 전송됩니다. KDC는 데이터베이스에 액세스하여 사용자의 신원을 인증하고 다른 시스템에 액세스할 수 있는 권한을 부여하는 티켓을 반환합니다. “투명하게”란 명시적으로 티켓을 요청할 필요가 없음을 의미합니다. 요청은 rlogin 명령의 일부로 수행됩니다. 인증된 클라이언트만 특정 서비스에 대한 티켓을 가져올 수 있으므로 사용 중인 ID로는 다른 클라이언트가 rlogin을 사용할 수 없습니다.

티켓은 특정 속성과 연관됩니다. 예를 들어 티켓이 전달 가능 티켓일 수 있습니다. 이는 새 인증 프로세스 없이도 다른 시스템에서 티켓을 사용할 수 있음을 의미합니다. 또한 후일자 티켓일 수도 있습니다. 이는 지정된 시간까지 티켓이 유효하지 않음을 의미합니다. 예를 들어 티켓을 어떻게 사용하여 어떤 사용자가 어떤 유형의 티켓을 얻을 수 있는지는 정책에 의해 설정됩니다. 정책은 Kerberos 서비스가 설치되거나 관리될 때 결정됩니다.


주 - 자격 증명티켓이라는 용어를 자주 접하게 될 것입니다. 보다 넓은 Kerberos 관점에서 이 둘은 서로 바꿔 사용할 수 있습니다. 그러나 기술적인 측면에서 자격 증명은 티켓과 해당 세션에 대한 세션 키가 추가된 것입니다. 이 차이는 Kerberos를 사용하여 서비스에 대한 액세스 권한 얻기에 더 자세히 설명되어 있습니다.


다음 절에서는 Kerberos 인증에 대해 추가로 설명합니다.

초기 인증: TGT(티켓 부여 티켓)

Kerberos 인증은 모든 후속 인증에 대해 허용되는 초기 인증과 후속 인증 자체의 두 단계로 구성됩니다.

다음 그림은 초기 인증이 이루어지는 방식을 보여줍니다.

그림 19-1 Kerberos 세션에 대한 초기 인증

image:이 플로우 다이어그램은 KDC로부터 TGT를 요청한 다음 KDC가 클라이언트로 반환하는 TGT를 암호화하는 클라이언트를 보여줍니다.
  1. 클라이언트(사용자 또는 NFS 등의 서비스)는 KDC(키 배포 센터)에서 TGT(티켓 부여 티켓)를 요청하여 Kerberos 세션을 시작합니다. 이 요청은 대개 로그인 시 자동으로 수행됩니다.

    TGT(티켓 부여 티켓)는 특정 서비스의 다른 티켓을 얻는 데 필요합니다. TGT(티켓 부여 티켓)는 여권과 비슷하다고 생각하십시오. TGT(티켓 부여 티켓)는 여권처럼 사용자의 신원을 확인하며 여러 개의 "비자"를 얻을 수 있도록 해줍니다. 여기서 "비자"(티켓)는 외국에 사용하기 위한 것이 아니라 원격 시스템 또는 네트워크 서비스에 사용하기 위한 것입니다. 여권과 비자처럼 TGT(티켓 부여 티켓) 및 기타 여러 티켓의 수명은 제한되어 있습니다. 차이점이라면 "Kerberos화된" 명령은 사용자에게 여권이 있음을 알고 있어 자동으로 비자를 얻는다는 것입니다. 즉, 사용자가 트랜잭션을 직접 수행할 필요가 없습니다.

    TGT(티켓 부여 티켓)가 네 곳의 스키 리조트에서 3일 동안 사용할 수 있는 스키 패스라고 생각해 볼 수도 있습니다. 방문하려는 리조트의 패스를 보여 주면 패스 유효 기간 동안에는 해당 리조트의 리프트 티켓을 받을 수 있습니다. 리프트 티켓이 있으면 해당 리조트에서 원하는 만큼 스키를 탈 수 있습니다. 다음 날 다른 리조트를 방문한 경우 다시 패스를 보여 주면 새 리조트의 리프트 티켓을 추가로 얻을 수 있습니다. 차이점이라면 Kerberos 기반 명령은 사용자에게 주말용 스키 패스가 있음을 알고 있어 자동으로 리프트 티켓을 얻는다는 점입니다. 따라서 사용자가 트랜잭션을 직접 수행할 필요가 없습니다.

  2. KDC는 TGT(티켓 부여 티켓)를 만들어 암호화된 형태로 다시 클라이언트로 보냅니다. 클라이언트는 클라이언트의 암호를 사용하여 TGT(티켓 부여 티켓)를 해독합니다.

  3. 이제 유효한 TGT(티켓 부여 티켓)가 생겼으므로, 클라이언트에서는 TGT(티켓 부여 티켓)가 유효한 동안 모든 종류의 네트워크 작업(예: rlogin 또는 telnet)에 대한 티켓을 요청할 수 있습니다. 이 티켓은 보통 몇 시간 동안만 지속됩니다. 클라이언트에서는 고유 네트워크 작업을 수행할 때마다 KDC로부터 해당 작업에 대한 티켓을 요청합니다.

후속 Kerberos 인증

클라이언트가 초기 인증을 받은 후 후속 인증이 수행될 때마다 다음 그림에 표시된 패턴을 따릅니다.

그림 19-2 Kerberos 인증을 사용하여 서비스에 대한 액세스 권한 얻기

image:이 플로우 다이어그램은 TGT를 사용하여 KDC로부터 티켓을 요청한 다음 반환된 티켓을 사용하여 서버에 액세스하는 클라이언트를 보여줍니다.
  1. 클라이언트는 KDC에 신원 증명서로 TGT(티켓 부여 티켓)를 전송하여 KDC로부터 다른 시스템에 대한 원격 로그인용 특정 서비스에 대한 티켓을 요청합니다.

  2. KDC는 특정 서비스에 대한 티켓을 만들어 클라이언트로 보냅니다.

    예를 들어 joe라는 사용자가 필요한 krb5 인증과 공유된 NFS 파일 시스템에 액세스하려 한다고 가정합시다. 이 사용자는 이미 인증을 받았기 때문에 즉, 이미 TGT(티켓 부여 티켓)가 있으므로 파일에 액세스하려고 하면 NFS 클라이언트 시스템이 자동으로 그리고 투명하게 KDC로부터 NFS 서비스에 대한 티켓을 얻습니다.

    예를 들어 joe라는 사용자가 boston 서버에서 rlogin을 사용한다고 가정합시다. 이 사용자는 이미 인증을 받았기 때문에 즉, 이미 TGT(티켓 부여 티켓)가 있으므로 자동으로 그리고 투명하게 rlogin 명령의 일부로 티켓을 얻습니다. 이 티켓이 있으면 만료될 때까지 원하는 만큼 boston에 원격으로 로그인할 수 있습니다. joedenver 시스템에 원격 로그인하고 싶은 경우 1단계에서처럼 또 다른 티켓을 얻습니다.

  3. 클라이언트가 티켓을 서버로 보냅니다.

    NFS 서비스를 사용할 경우 NFS 클라이언트가 자동으로 그리고 투명하게 NFS 서비스에 대한 티켓을 NFS 서버로 보냅니다.

  4. 서버에서 클라이언트 액세스를 허용합니다.

이러한 단계에서 서버는 KDC와 통신하지 않습니다. 그렇지만 첫번째 클라이언트와 마찬가지로 서버 자체는 KDC에 등록되어 있습니다. 간단히 나타내기 위해 이 부분은 생략했습니다.

Kerberos 원격 응용 프로그램

joe와 같은 사용자가 사용할 수 있는 Kerberos 기반(또는 “Kerberos화된”) 명령은 다음과 같습니다.

이러한 응용 프로그램은 같은 이름의 Solaris 응용 프로그램과 같습니다. 그러나 Kerberos 주체를 사용하여 트랜잭션을 인증하도록 확장되었으므로 Kerberos 기반 보안을 제공합니다. 주체에 대한 자세한 내용은 Kerberos 주체를 참조하십시오.

이러한 명령은 Kerberos 사용자 명령에 자세히 설명되어 있습니다.

Kerberos 주체

Kerberos 서비스의 클라이언트는 주체로 식별됩니다. 주체는 KDC가 티켓을 지정할 수 있는 고유 ID입니다. 주체는 사용자(예: joe) 또는 서비스(예: nfs 또는 telnet)일 수 있습니다.

관례상 주체 이름은 기본 요소, 인스턴스, 영역이라는 세 개의 구성 요소로 구분됩니다. 예를 들면 일반적인 Kerberos 주체는 joe/admin@ENG.EXAMPLE.COM입니다. 위 예에서 각 요소의 역할은 다음과 같습니다.

다음은 모두 유효한 주체 이름입니다.

Kerberos 영역

영역은 도메인과 유사한 논리적 그룹으로, 동일한 마스터 KDC 아래에 있는 시스템 그룹을 정의합니다. 그림 19-3은 영역 간의 관계를 보여줍니다. 일부 영역은 계층형으로, 한 영역이 다른 영역의 수퍼 세트입니다. 또 다른 영역은 비계층형(또는 “직접”)으로, 두 영역 간의 매핑을 정의해야 합니다. Kerberos 서비스의 특징은 영역 간 인증을 허용한다는 점입니다. 각 영역에는 KDC에 있는 다른 영역에 대한 주체 항목만 있으면 됩니다. 이 Kerberos 기능을 영역 간 인증이라고 합니다.

그림 19-3 Kerberos 영역

image:이 다이어그램은 ENG.EXAMPLE.COM 영역이 SEAMCO.COM과는 비계층형 관계이고, EXAMPLE.COM과는 계층형 관계임을 보여줍니다.

Kerberos 서버

각 영역에는 주체 데이터베이스의 마스터 복사본을 유지 관리하는 서버가 있어야 합니다. 이 서버를 마스터 KDC 서버라고 합니다. 또한 각 영역에는 주체 데이터베이스의 복제 복사본을 포함하는 슬레이브 KDC 서버도 한 개 이상 있어야 합니다. 마스터 KDC 서버와 슬레이브 KDC 서버 모두 인증을 설정하는 데 사용되는 티켓을 만듭니다.

영역에는 Kerberos 애플리케이션 서버가 포함될 수도 있습니다. 이 서버는 Kerberos화된 서비스(예: ftp, telnet, ssh 및 NFS)에 대한 액세스를 제공합니다. SEAM 1.0 또는 1.0.1을 설치한 경우 영역에 Kerberos 네트워크 애플리케이션 서버가 포함되어 있을 수 있지만, 이 소프트웨어는 이 릴리스와 함께 제공되지 않습니다.

다음 그림은 가상 영역에 포함될 수 있는 요소를 보여줍니다.

그림 19-4 일반 Kerberos 영역

image:이 다이어그램은 일반 Kerberos 영역인 EXAMPLE.COM이 마스터 KDC, 세 개의 클라이언트, 두 개의 슬레이브 KDC 및 두 개의 애플리케이션 서버로 구성됨을 보여줍니다.