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

문서 정보

머리말

제1부보안 개요

1.  보안 서비스(개요)

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

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

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

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

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

6.  기본 감사 보고 도구 사용(작업)

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

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

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

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

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

제4부암호화 서비스

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

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

13.  키 관리 프레임워크

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

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

보안 RPC 개요

NFS 서비스 및 보안 RPC

보안 NFS에서 DES 암호화

Kerberos 인증

Diffie-Hellman 인증 및 보안 RPC

Diffie-Hellman 인증 구현

보안 RPC에서 인증 관리(작업)

보안 RPC 관리(작업 맵)

보안 RPC 키 서버를 다시 시작하는 방법

NIS 호스트에 대한 Diffie-Hellman 키를 설정하는 방법

NIS 사용자에 대한 Diffie-Hellman 키를 설정하는 방법

Diffie-Hellman 인증을 사용하여 NFS 파일을 공유하는 방법

15.  PAM 사용

16.  SASL 사용

17.  Secure Shell 사용(작업)

18.  Secure Shell(참조)

제6부Kerberos 서비스

19.  Kerberos 서비스 소개

20.  Kerberos 서비스 계획

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

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

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

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

25.  Kerberos 서비스(참조)

제7부Oracle Solaris에서 감사

26.  감사(개요)

27.  감사 계획

28.  감사 관리(작업)

29.  감사(참조)

용어집

색인

보안 RPC 개요

보안 RPC(원격 프로시저 호출)는 인증 방식을 사용하여 원격 프로시저를 보호합니다. Diffie-Hellman 인증 방식은 서비스에 대해 요청하는 호스트 및 사용자를 모두 인증합니다. 인증 방식에서는 데이터 암호화 표준(DES) 암호화를 사용합니다. 보안 RPC를 사용하는 응용 프로그램에는 NFS 및 NIS 이름 지정 서비스가 포함됩니다.

NFS 서비스 및 보안 RPC

NFS를 사용하여 여러 호스트에서 네트워크를 통해 파일을 공유할 수 있습니다. NFS 서비스에서는 서버에 여러 클라이언트에 대한 데이터 및 리소스가 포함됩니다. 클라이언트는 서버가 클라이언트와 공유하는 파일 시스템에 대한 액세스 권한을 가집니다. 클라이언트 시스템에 로그인한 사용자는 서버에서 파일 시스템을 마운트하여 파일 시스템에 액세스할 수 있습니다. 클라이언트 시스템의 사용자에게는 파일이 로컬에 있는 것처럼 보입니다. NFS의 가장 일반적인 용도 중 하나는 시스템을 사무실에 설치하고, 모든 사용자 파일을 중앙 위치에 저장하는 것입니다. mount 명령에 대한 -nosuid 옵션과 같은 NFS 서비스의 기능을 사용하면 무단 사용자가 장치 및 파일 시스템을 열지 못하도록 할 수 있습니다.

NFS 서비스는 보안 RPC를 사용하여 네트워크를 통해 요청하는 사용자를 인증합니다. 이 프로세스를 보안 NFS라고 합니다. Diffie-Hellman 인증 방식 AUTH_DH에서는 DES 암호화를 사용하여 인증된 액세스를 확인합니다. AUTH_DH 방식은 AUTH_DES라고 부르기도 합니다. 자세한 내용은 다음을 참조하십시오.

보안 NFS에서 DES 암호화

데이터 암호화 표준(DES) 암호화 함수는 56비트 키를 사용하여 데이터를 암호화합니다. 두 자격 증명 사용자 또는 주체가 동일한 DES 키를 알고 있는 경우 키를 사용하여 텍스틀 암호화하고 해독함으로써 비밀 통신이 가능합니다. DES는 비교적 빠른 암호화 방식입니다.

DES 키만 사용할 경우 침입자가 동일한 키로 암호화된 암호화 텍스트 메시지를 충분히 수집하여 키를 알아내고 메시지를 해독할 수 있다는 위험이 있습니다. 이러한 이유로 보안 NFS와 같은 보안 시스템에서는 키를 자주 변경해야 합니다.

Kerberos 인증

Kerberos는 MIT에서 개발한 인증 시스템입니다. Kerberos의 일부 암호화는 DES를 기준으로 합니다. Kerberos V4 지원은 더 이상 보안 RPC의 일부로 제공되지 않습니다. 하지만 RPCSEC_GSS를 사용하는 Kerberos V5의 클라이언트측 및 서버측 구현은 이 릴리스에 포함되어 있습니다. 자세한 내용은 19 장Kerberos 서비스 소개를 참조하십시오.

Diffie-Hellman 인증 및 보안 RPC

Diffie-Hellman(DH) 사용자 인증 방식은 침입자가 알아내기가 쉽지 않습니다. 클라이언트와 서버는 각자 개인 키를 가지며, 공개 키와 함께 사용하여 공통 키를 만들어 냅니다. 개인 키는 비밀 키라고도 합니다. 클라이언트와 서버는 공통 키를 사용하여 서로 통신합니다. 공통 키는 DES와 같이 합의한 암호화 함수를 사용하여 암호화됩니다.

인증은 보내는 시스템에서 공통 키를 사용하여 현재 시간을 암호화할 수 있는 기능을 기준으로 합니다. 그런 다음 받는 시스템에서 해독하고 현재 시간과 비교하여 확인합니다. 클라이언트와 서버의 시간은 동기화되어야 합니다. 자세한 내용은 Oracle Solaris 관리: 네트워크 서비스의 NTP(Network Time Protocol) 관리(작업)를 참조하십시오.

공개 키와 개인 키는 NIS 데이터베이스에 저장됩니다. NIS는 키를 publickey 맵에 저장합니다. 이 파일에는 모든 잠재 사용자에 대한 공개 키 및 개인 키가 포함되어 있습니다.

시스템 관리자는 NIS 맵을 설정하고 각 사용자에 대한 공개 키 및 개인 키를 생성할 책임이 있습니다. 개인 키는 사용자의 암호를 사용하여 암호화된 형태로 저장됩니다. 이 프로세스는 개인 키를 사용자만 알도록 합니다.

Diffie-Hellman 인증 구현

이 절에서는 Diffie-Hellman 인증(AUTH_DH)을 사용하는 클라이언트-서버 세션에서 일련의 트랜잭션을 설명합니다.

보안 RPC에 대한 공개 키 및 개인 키 생성

트랜잭션 이전에 관리자는 newkey 또는 nisaddcred 명령을 실행하여 공개 키 및 비밀 키를 생성합니다. 각 사용자는 고유한 공개 키와 비밀 키를 가집니다. 공개 키는 공용 데이터베이스에 저장됩니다. 비밀 키는 동일한 데이터베이스에 암호화된 형태로 저장됩니다. chkey 명령은 키 쌍을 변경합니다.

보안 RPC에 대해 keylogin 명령 실행

대개 로그인 암호는 보안 RPC 암호와 동일합니다. 이 경우 keylogin 명령이 필요하지 않습니다. 하지만 암호가 다른 경우 사용자가 로그인한 다음 keylogin 명령을 실행해야 합니다.

keylogin 명령은 사용자에게 보안 RPC 암호를 물어봅니다. 그런 다음 명령은 암호를 사용하여 비밀 키를 해독합니다. 그런 다음 keylogin 명령은 해독된 비밀 키를 키 서버 프로그램에 전달합니다. 키 서버는 모든 컴퓨터의 로컬 인스턴스에 있는 RPC 서비스입니다. 키 서버는 해독된 비밀 키를 저장하고 사용자가 서버와 보안 RPC 트랜잭션을 시작할 때까지 기다립니다.

로그인 암호와 RPC 암호가 같을 경우 로그인 프로세스는 비밀 키를 키 서버에 전달합니다. 암호가 서로 달라야 하는 경우 사용자는 항상 keylogin 명령을 실행해야 합니다. keylogin 명령이 ~/.login, ~/.cshrc 또는 ~/.profile 파일과 같은 사용자의 환경 구성 파일에 포함된 경우 사용자가 로그인할 때마다 keylogin 명령이 자동으로 실행됩니다.

보안 RPC에 대한 컨버세이션 키 생성

사용자가 서버와 트랜잭션을 시작하면 다음이 발생합니다.

  1. 키 서버가 임의로 컨버세이션 키를 생성합니다.

  2. 커널은 컨버세이션 키 및 기타 정보를 사용하여 클라이언트의 시간 기록을 암호화합니다.

  3. 키 서버는 공개 키 데이터베이스에서 서버의 공개 키를 조회합니다. 자세한 내용은 publickey(4) 매뉴얼 페이지를 참조하십시오.

  4. 키 서버는 클라이언트의 비밀 키와 서버의 공개 키를 사용하여 공통 키를 만듭니다.

  5. 키 서버는 공통 키를 사용하여 컨버세이션 키를 암호화합니다.

보안 RPC에서 서버와 처음 연결

그러면 암호화된 시간 기록 및 암호화된 컨버세이션 키를 포함하는 전송이 서버로 보내집니다. 전송에는 자격 증명 및 검증기가 포함됩니다. 자격 증명에는 세 가지 구성 요소가 포함됩니다.

창은 서버의 시계와 클라이언트의 시간 기록 사이에 허용되어야 한다고 클라이언트가 요구하는 시간 차이입니다. 서버의 시계와 시간 기록 사이의 차이가 창보다 클 경우 서버는 클라이언트의 요청을 거부합니다. 클라이언트가 RPC 세션을 시작하기 전에 먼저 서버와 동기화하므로 일반적인 상황에서 이러한 거부는 발생하지 않습니다.

클라이언트의 검증기에는 다음이 포함됩니다.

창 검증기는 누군가 사용자를 가장하고자 하는 경우 필요합니다. 가장하는 사람은 자격 증명 및 검증기의 암호화된 필드를 채우는 대신 임의의 비트를 삽입하는 프로그램을 작성할 수 있습니다. 서버는 컨버세이션 키를 임의의 키로 해독합니다. 그런 다음 서버는 키를 사용하여 창 및 시간 기록 해독을 시도합니다. 결과는 임의의 숫자입니다. 하지만 수천 번의 시도 후 임의의 창/시간 기록 쌍은 인증 시스템을 통과할 수 있습니다. 창 검증기는 가짜 자격 증명을 인증할 수 있는 가능성을 줄입니다.

보안 RPC에서 컨버세이션 키 해독

서버가 클라이언트로부터 전송을 수신하면 다음이 발생합니다.

  1. 서버에 로컬인 키 서버가 공개 키 데이터베이스에서 클라이언트의 공개 키를 조회합니다.

  2. 키 서버는 클라이언트의 공개 키와 서버의 비밀 키를 사용하여 공통 키를 추론합니다. 공통 키는 클라이언트에서 계산된 동일한 공통 키입니다. 계산을 위해서는 비밀 키 중 하나를 알아야 하므로 서버와 클라이언트만 공통 키를 계산할 수 있습니다.

  3. 커널은 공통 키를 사용하여 컨버세이션 키를 해독합니다.

  4. 커널은 키 서버를 호출하고 해독된 컨버세이션 키를 사용하여 클라이언트의 시간 기록을 해독합니다.

보안 RPC에서 서버에 정보 저장

서버에서 클라이언트의 시간 기록을 해독한 후 서버는 4가지 정보 항목을 자격 증명 테이블에 저장합니다.

서버는 처음 3가지 항목을 나중에 사용을 위해 저장합니다. 서버는 재생을 막기 위해 클라이언트의 시간 기록을 저장합니다. 서버는 마지막 시간 기록보다 시간상으로 이후의 시간 기록만 수락합니다. 결과적으로 재생된 트랜잭션은 반드시 거부됩니다.


주 - 이러한 인증에서는 호출자의 이름이 어떠한 방식으로든 암시적으로 인증되어야 합니다. 키 서버에서 DES를 사용하면 교착 상태가 발생하므로 키 서버는 DES 인증을 사용하여 호출자를 인증할 수 없습니다. 교착 상태를 피하기 위해 키 서버는 사용자 ID(UID)별로 비밀 키를 저장하고 로컬 root 프로세스에만 요청을 허용합니다.


보안 RPC에서 클라이언트에 검증기 반환

서버는 클라이언트에 검증기를 반환하며, 여기에는 다음이 포함됩니다.

클라이언트의 시간 기록에서 1을 빼는 이유는 시간 기록이 오래되었음을 확인하기 위함입니다. 오래된 시간 기록은 클라이언트 검증기로 재사용할 수 없습니다.

보안 RPC에서 서버 인증

클라이언트는 검증기를 받고 서버를 인증합니다. 클라이언트는 서버만 클라이언트가 보낸 시간 기록을 알고 있으므로 서버만 검증기를 보낼 수 있다는 사실을 알 수 있습니다.

보안 RPC에서 트랜잭션 처리

첫번째 트랜잭션 이후 모든 트랜잭션에서 클라이언트는 인덱스 ID를 서버에 반환합니다. 또한 클라이언트는 다른 암호화된 시간 기록을 보냅니다. 서버는 컨버세이션 키로 암호화된 클라이언트의 시간 기록 빼기 1을 돌려 보냅니다.