# 관리 안내서

# 서버 암호화 키 관리

이 장에서는 사용자 셀의 서버 암호화 키를 유지하는 방법에 대해 설명합니다. 이것은 AFS에서 안전 통신에 중요합니다.

## 명령 요약

이 장에서는 표시된 명령을 사용하여 다음 타스크를 수행하는 방법에 대해 설명합니다.

신규 서버 암호화 키 추가 | bos addkey 및 kas setpassword
인증 데이터베이스에서 키 체크섬 검토 | kas examine
KeyFile에서 키 체크섬 검토 | bos listkeys
이전 서버 암호화 키 제거 | bos removekey

## 서버 암호화 키 정보

암호화 키는 정보 패킷을 암호화하고 해제하는 데 사용되는 8진수 문자열입니다. AFS에서, 서버 암호화 키는 AFS 서버 프로세스 사이에서, 그리고 이들과 클라이언트 사이에서 전송되는 정보를 보호하는 데 사용되는 키입니다. 서버 암호화 키는 서버 프로세스에게는 필수적인 암호이며, 사용자 암호처럼 인증 데이터베이스에 저장됩니다.

셀의 서버 암호화 키를 적절하게 유지하는 것이 AFS 파일공간에 있는 정보를 무허가 사용자로부터 보호하는 가장 기본적인 방법입니다.

### 키 및 상호 인증: 검토

서버 암호화 키는 AFS에 있는 클라이언트와 서버 프로세스 사이에서의 상호 인증시 핵심적인 역할을 합니다. 상호 인증에 대한 자세한 설명은 상호 인증에 대한 상세한 설명의 내용을 참조하십시오.

클라이언트가 AFS 서버에 접속하려는 경우, 먼저 인증 서버의 티켓 부여 서비스(TGS) 모듈에 접속합니다. 클라이언트의 ID(클라이언트가 나타내는 사용자의 암호를 간접 참조하여)를 확인한 뒤, TGS는 클라이언트에게 서버 티켓을 제공합니다. 이 티켓은 서버의 암호화 키로 암호화됩니다(TGS는 서버와 클라이언트 간의 통신 에피소드에만 사용될 세션 키라는 보존 암호화 키도 생성합니다. 다른 정보와 함께 서버 티켓과 세션 키를 토큰이라고 합니다).

클라이언트는 서버 암호화 키를 알지 못하므로 서버 티켓이나 토큰을 읽을 수 없습니다. 그러나 클라이언트는 이를 서비스 요청과 함께 AFS 서버에 전송하며, 이것은 티켓이 이미 TGS로 인증받은 AFS 서버 서비스임을 증명하기 때문입니다. AFS 서버는 TGS를 믿고 유효한 클라이언트에만 티켓을 부여합니다. 클라이언트가 서버 암호화 키로 암호화된 티켓을 처리한다는 사실은 클라이언트가 유효함을 서버에게 증명합니다. 한편, 클라이언트는 진짜 AFS 서버만이 티켓을 해독하는 데 필요한 서버 암호화 키를 알고 있는 것으로 생각합니다. 티켓을 해독하고 그 내용을 이해하는 서버 능력은 서버가 합법적임을 클라이언트에게 증명합니다.

### AFS 서버 암호화 키 유지

셀의 서버 암호화 키를 유지하므로, 다음을 기억하십시오.

- 키를 자주 변경하면 셀의 보안성이 향상됩니다. 적어도 한달에 한번 키를 변경하는 것이 좋습니다.
- 현재 사용중인 AFS 서버 암호화 키는 두 장소에 저장됩니다. 새로운 키를 추가할 때, 두 장소 모두에서 이를 변경하고 서버 암호화 키 추가에서 설명한 것처럼 정확한 순서로 작성해야 합니다. 명령 실행에 실패하면 셀이 동작하는 데 심각한 영향을 줄 수 있으므로, 클라이언트와 서버는 통신할 수 없게 됩니다. 현재 서버 암호화 키에 대한 두 개의 기억영역 사이트는 다음과 같습니다.

  1. 모든 파일 서버 시스템의 로컬 디스크에 있는 /usr/afs/etc/KeyFile 파일. 파일은 하나 이상의 키를 나열할 수 있으며, 각각에는 연관된 숫자 식별자인 키 버전 번호 또는 kvno가 있습니다. 클라이언트 토큰은 이것을 증명하는 데 사용된 키의 키 버전 번호를 기록하며, 서버 프로세스는 클라이언트가 토큰을 표시할 때 이 파일에서 해당 키를 검색합니다.
  2. 인증 데이터베이스에 있는 afs 항목. 현재 서버 암호화 키는 각 사용자의 뒤엉킨 암호처럼 항목의 암호 필드에 있습니다. 인증 서버의 티켓 부여 서비스(TGS)는 이 키를 사용하여 클라이언트에게 제공하는 토큰을 암호화합니다. 항목에는 하나의 키만 있으며, 이는 TGS는 기본 토큰을 읽을 필요는 없지만, 현재 키를 사용하여 새로운 토큰을 생성해야 하기 때문입니다.

  셀의 첫번째 서버 시스템을 설치한 뒤 초기 afs 항목 및 KeyFile 파일을 작성하는 명령에 대해서는 AFS 빠른 시작의 내용을 참조하십시오.

- 특정 시간에, 인증 서버의 티켓 부여 서비스가 클라이언트에게 제공한 토큰은 서버 암호화 키 중 하나로 증명되며, 보통 이 키는 인증 데이터베이스에 있는 afs 항목에 저장된 것입니다.
- 새로운 서버 암호화 키를 추가할 때, 모든 AFS 서버 시스템의 로컬 디스크에 있는 /usr/afs/etc/KeyFile 파일에서 이전 키를 즉시 제거할 수는 없습니다. 새로운 키를 추가할 때에는 언제든지, 몇몇 클라이언트들이 이전 키로 증명된 유효하고 만기되지 않은 토큰을 가질 수 있습니다. 서버 암호화 키를 자주 변경하면, 좀 더 많은 티켓을 가질 수 있습니다. 그러한 토큰을 가진 클라이언트에게 적합한 서비스를 제공할 수 있도록 하려면, AFS 서버 프로세스가 이를 봉합하는 데 사용된 서버 암호화 키에 액세스할 수 있어야 합니다.

  그 키로 봉합된 토큰을 가진 클라이언트가 없는 것이 확실할 경우에만 기존 서버 암호화 키를 안전하게 삭제할 수 있습니다. 일반적으로, 적어도 셀에 있는 최대 토큰 주기동안 기다리십시오. 기본적으로, 사용자의 최대 토큰 주기는 25시간입니다(AFS 버전 3.0을 사용하여 인증 데이터베이스를 작성했던 사용자는 제외하고 기본값은 100시간입니다). kas setfields 명령에서 -lifetime 인수를 사용하여 이 기본값을 변경할 수 있습니다.

  기존 키 제거 명령은 서버 암호화 키 제거에 있습니다.

- 일반 사용자가 암호를 변경하는 것과 같은 방식으로, 암호화 키로 자동 변환된 문자열을 제공하여 새로운 AFS 서버 암호화 키를 작성합니다. 서버 암호화 키 추가를 참조하십시오.
- 클라이언트와 통신할 때 서버 암호화 키를 사용하는 것뿐만 아니라, 서버 프로세스는 이들을 사용하여 다른 서버 프로세스와의 통신을 보호합니다. 그러므로 셀에 있는 모든 서버 시스템에는 같은 버전의 KeyFile 파일이 있어야 합니다. 일관성을 유지하는 가장 빠른 방법은(AFS의 미국판을 실행하는 경우) 갱신 서버를 사용하여 시스템 제어 시스템의 /usr/afs/etc 디렉토리 내용을 다른 서버 시스템 모두에 분산시키는 것입니다. 두 가지 의미가 있습니다.
  - 시스템 제어 시스템에서는 upserver 프로세스를 실행하고, 시스템 제어 시스템을 참조하는 다른 모든 서버 시스템에서는 upclientetc 프로세스를 실행해야 합니다. AFS 빠른 시작에서는 이 두 프로세스를 설치하는 방법에 대해 설명합니다. 갱신 서버 프로세스가 실행되는 지 확인하는 명령은 프로세스 상태와 BosConfig 파일의 정보 표시하기의 내용을 참조하십시오.
  - 시스템 제어 시스템에서만 KeyFile 파일을 변경하십시오(서버 암호화 키 비상사태 처리에서 설명한 비상 유형시는 제외). 기타 서버 시스템에서의 변경사항은 다음번에 upclientetc 프로세스가 시스템 제어 시스템의 /usr/afs/etc 디렉토리 내용을 검색할 때 변경됩니다. 기본적으로 이것은 매 5분마다 발생합니다.

  AFS의 각국 언어판을 실행하는 경우, 갱신 서버를 사용하여 /usr/afs/etc 디렉토리의 내용, 특히 KeyFile 파일을 분배하지 마십시오. 파일에 있는 데이터는 암호화되지 않은 양식으로 전송하기에는 너무 민감하며, 미국 정부의 수출 규정으로 인해 AFS의 각국 언어판에는 갱신 서버가 사용할 수 있는 양식으로 된 필요한 암호화 루틴이 포함되지 않습니다. 대신 각 서버 시스템에 있는 파일을 수정해야 하며, 모든 서버 시스템에서 같은 키를 입력할 때에는 주의해야 합니다.

- 문서 편집기로 KeyFile을 직접 편집하지 마십시오. 대신 항상 서버 암호화 키 추가 및 서버 암호화 키 제거에서 설명한 것처럼 해당 bos 명령을 사용하십시오.

## 서버 암호화 키 표시

파일 서버 시스템에 있는 /usr/afs/etc/KeyFile 파일에서 서버 암호화 키를 표시하려면 bos listkeys 명령을 사용하십시오. kas examine 명령을 사용하여 인증 데이터베이스의 afs 항목에 있는 키를 표시하십시오.

기본적으로 명령에서는 키를 구성하는 실제 8진 문자열을 표시하지 않지만, 키로 상수를 암호화하여 얻은 십진수인 체크섬을 표시합니다. 이렇게 하면 허가없는 사용자가 실제 키에 쉽게 액세스할 수 없게 되며, 이 실제 키는 보호 통신에서 거짓을 말하거나 도청할 때 사용할 수 있습니다. bos listkeys 및 kas examine 명령은 제공된 키에 대해 같은 체크섬을 생성하므로, 실제 키 대신 체크섬을 표시하는 것으로 충분합니다. 체크섬이 알려지지 않는다는 점에서 키가 다르다고 생각되면, 셀 전체에서 인증 문제점을 경험하고 있을 것입니다. 가장 쉬운 해결 방법은 서버 암호화 키 추가 또는 서버 암호화 키 비상사태 처리 명령 다음에 새로운 서버 암호화 키를 작성하는 것입니다. bos listkeys 명령을 실행하는 또 다른 이유는 다음 버전 번호를 선택하기 위한 준비 단계로서 현재 사용하는 키 버전 번호를 표시하기 위한 것입니다. 여기서는 키 자체는 관계가 없으므로 체크섬으로 충분합니다.

실제 8진수를 표시하는 것이 중요한 경우, -showkey 인수를 bos listkeys 및 kas examine 명령 모두에 삽입하십시오.

### KeyFile 파일 표시하기

1. /usr/afs/etc/UserList 파일에 나열된 사용자로서 인증받았는 지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. bos listkeys 명령을 실행하여 한 시스템의 /usr/afs/etc/KeyFile 파일 내용을 표시하십시오.

          %
       bos listkeys <machine name> [-showkey]

   여기서

   listk
     listkeys의 축약형입니다.

   machine name
     파일 서버 시스템의 이름입니다. 일반적인 경우, 셀이 정확하게 동작하려면 KeyFile 파일이 모든 시스템에서 동일해야 하므로 임의 시스템에 이름을 지정할 수 있습니다.

   -showkey
     각 키를 구성하는 8진수를 표시합니다.

다음 예에서, 출력은 실제 8진수가 아닌 각 서버 암호화 키에 대한 체크섬을 표시합니다. 두 번째 라인에서는 관리자가 마지막으로 파일을 변경했던 시기를 나타내며, 마지막 라인에서는 출력이 완벽한 지 확인합니다.

       % bos listkeys fs1.abc.com
       key 0 has cksum 972037177
       key 1 has cksum 2825165022
       Keys last changed on Wed Jan 13 11:20:29 1999.
       All done.

### 인증 데이터베이스에서 afs 키 표시하기

1. kas examine 명령을 실행하여 인증 데이터베이스에서 afs 항목을 표시하십시오.

   인증 서버는 기존 AFS 토큰을 사용하지 않고 자신의 인증 프로세스를 수행합니다. 기본적으로 이것은 로컬(UNIX) ID를 인증하며, AFS가 특권을 부여한 관리자에 해당되지 않을 수 있습니다. -admin 인수를 삽입하여 인증 데이터베이스 항목에 `ADMIN` 플래그가 있는 ID의 이름을 지정하십시오. 항목에 플래그가 있는 지 확인하려면, ADMIN 플래그가 설정되어 있는지 확인하려면에서 설명한 것처럼 kas examine 명령을 실행하십시오.

          % kas examine afs
       [-showkey]  \
                        -admin  <admin principal to use for authentication>
          Administrator's (admin_user) password: admin_password

   여기서

   e
     examine의 축약형입니다.

   afs
     afs 항목을 지정합니다.

   -showkey
     키를 구성하는 8진수를 표시합니다.

   -admin
     인증 데이터베이스에서 `ADMIN` 플래그로 지정한 관리 계정의 이름입니다. 예를 들면 admin. 암호 프롬프트는 이를 admin_user로 에코합니다. admin_password로서 적합한 암호를 입력하십시오.

다음 예에서, admin 사용자는 플래그를 사용하지 않고 afs 항목을 표시합니다. 두 번째 행에서는 괄호내에 있는 키 버전 번호와 키의 체크섬을 보여줍니다. `last mod` 문자열로 시작되는 행은 표시된 관리자가 키를 변경했던 날짜를 알려줍니다. 이 날짜와, bos listkeys 명령으로 알려진 날짜 사이에 관계는 필요하지 않습니다. 나중의 날짜는 키를 추가할 때가 아닌 KeyFile 파일의 변경 유형에 따라 변경됩니다. kas examine명령 출력에 있는 다른 행에 대한 설명은 AFS Administration Reference에 있는 참조 페이지를 참조하십시오.

       % kas examine afs  -admin admin
       Administrator's (admin) password: admin_password
       User data for afs
        key (1) cksum is 2825165022, last cpw: no date
        password will never expire.
        An unlimited number of unsuccessful authentications is permitted.
        entry expires on never. Max ticket lifetime 100.00 hours.
        last mod on Wed Jan 13 11:21:36 1999 by admin
        permit password reuse

## 서버 암호화 키 추가

앞에서 설명한 것처럼, AFS는 별개의 두 장소에 서버 암호화 키를 기록합니다.

1. 각 서버 시스템의 로컬 디스크에 있는 /usr/afs/etc/KeyFile 파일, 기계에서 실행중인 AFS 서버 프로세스가 사용합니다.
2. 인증 데이터베이스내의 afs 항목, 토큰 작성시 티켓 부여 서비스(TGS)가 사용합니다.

서버 프로세스와 TGS가 같은 AFS 서버 암호화 키를 공유하도록 하려면, 인터럽트없이 이 절에 있는 모든 단계를 실행하십시오.

다음 명령에는 모든 데이터베이스 서버 시스템에서 데이터베이스 서버 프로세스(인증, 백업, 보호 및 볼륨 위치 서버 프로세스)를 다시 시작하는 단계가 포함됩니다. 데이터베이스 서버 프로세스가 시작되면, KeyFile 파일에서 키 버전 번호가 가장 높은 서버 암호화 키를 읽어들이고, 이를 사용하여 데이터베이스를 동기화하고 정족수를 유지하기 위해 전송하는 메시지를 보호합니다. 확장된 기간이 될 수도 있는 주기 전체에서 KeyFile 파일에서 키를 제거하는 경우라도 같은 키를 사용합니다. 그러나 피어 데이터베이스 서버 프로세스 중 하나가 다시 시작되고 다른 것은 시작되지 않으면, 정족수와 데이터베이스 동기화는 프로세스들이 더 이상 같은 키를 사용하지 않으므로 중단됩니다. 다시 시작된 프로세스는 현재 가장 높은 키 버전 번호를 가진 키를 사용하며, 다른 프로세스들은 이들이 원래 시작될 때 읽어들인 키를 계속해서 사용합니다. 이 문제점을 예방하려면, 새로운 키를 추가할 때 모든 데이터베이스 서버 프로세스들을 다시 시작하는 것이 가장 안전합니다.

새로운 키를 추가한 뒤에는 더 이상 사용되지 않는 이전 키를 KeyFile 파일에서 제거하여 흩어지는 것을 막을 수 있습니다. 그러나 클라이언트나 서버 프로세스가 계속해서 사용하고 있는 키를 제거하지 않도록 조심해야 합니다. 설명과 명령에 대해서는 서버 암호화 키 제거의 내용을 참조하십시오.

### 새로운 서버 암호화 키 추가하기

1. /usr/afs/etc/UserList 파일에 나열된 사용자로서 인증받았는 지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. 새로운 키에 대한 키 버전 번호를 선택하는 첫번째 단계로서 bos listkeys 명령을 실행하여 이미 사용하고 있는 키 버전 번호를 표시하십시오.

          % bos listkeys <machine name>

   여기서

   listk
     listkeys의 축약형입니다.

   machine name
     파일 서버 시스템의 이름입니다.
3. 2 단계의 출력과 다음 요구조건을 근거로 새로운 키에 대한 키 버전 번호를 선택하십시오.
   - 키 버전 번호는 Kerberos 표준에 적합한 0 - 255 이내의 정수여야 합니다. 키 버전 번호를 연속해서 유지하려는 경우 기존에 있는 있는 번호 중 가장 큰 번호보다 하나 더 큰 키 버전 번호를 선택하는 것이 가장 간단합니다.
   - 현재 KeyFile 파일에 있는 키 버전 번호는 다시 사용하지 마십시오. 특히, 인증 데이터베이스 afs 항목에도 있는 경우에는 사용하지 마십시오. 클라이언트 프로세스는 원래 그 버전 번호를 가지고 있던 키로 봉합된 티켓을 계속해서 가질 수도 있지만, 서버 프로세스는 그 키 버전 번호로 표시된 새로운 키를 사용하여 시작됩니다. 키가 일치하지 않으므로, 서버 프로세스는 적법한 토큰을 가지고 있는 클라이언트로부터의 요청을 거부합니다.
4. bos addkey 명령을 실행하여 KeyFile 파일에서 새로운 AFS 서버 암호화 키를 작성하십시오.

   AFS 미국판을 사용하고 있고 갱신 서버를 사용하여 시스템 제어 시스템의 /usr/afs/etc 디렉토리 내용을 분배하는 경우, machine name 인수 대신 시스템 제어 시스템을 사용하십시오(시스템 제어 시스템이 어느 시스템인 지 잊어버린 경우는 시스템 제어 시스템을 찾으려면 내용을 참조하십시오).

   각국 언어판 AFS를 사용하거나 갱신 서버를 사용하지 않는 경우, bos addkey 명령을 반복하여 machine name 인수를 셀에 있는 각 서버 시스템으로 대체하십시오.

   새로운 키에 해당하는 문자열이 에코되는 것이 보이지 않도록 하려면, 명령 행에서 -key 인수를 누락하십시오. 대신 이를 생략할 때 나타나는 프롬프트에서 다음 구문 스펙에서 표시된 바와 같은 문자열을 입력하십시오.

          % bos addkey  -server <machine name> -kvno <key version number>
          input key: afs_password
          Retype input key: afs_password

   여기서

   addk
     addkey의 축약형입니다.

   -server
     갱신 서버를 사용하는 경우는 셀의 시스템 제어 시스템을, 사용하지 않는 경우는 각각의 서버 시스템의 이름입니다.

   -kvno
     새로운 키의 키 버전 번호를 0 - 255 이내의 정수로 지정합니다.

     번호를 기억하십시오. 6 단계에서 이를 다시 사용해야 합니다. AFS 각국 언어판을 사용하는 경우, 이 명령을 실행할 때마다 같은 번호를 입력해야 합니다.

   afs_password
     사용자 암호와 비슷한 문자 스트링으로, 길이는 1 - 1,000자 이내입니다. 보안을 향상시키기 위해, 영문자 이외의 문자를 포함하고 가능한 길게 문자를 작성하십시오(이 단계와 6 단계에서만 입력해야 합니다). AFS 각국 언어판을 사용하는 경우, 이 명령을 살행할 때마다 같은 문자열을 입력해야 합니다.

     8진 문자열을 직접 입력하지 마십시오. BOS 서버는 문자열을 KeyFile 파일에 기록하기 전에 암호화 키로서 사용하도록 8진 문자열로 만듭니다.

5. 갱신 서버를 사용하는 경우는 갱신 서버가 새로운 KeyFile 파일을 모든 서버 시스템에 분배하는 동안 잠시 기다리십시오. 필요한 최대 대기 시간은 서버 시스템에서 사용된 upclientetc 프로세스의 초기설정 명령에 있는 -t 인수에 제공된 값 중 가장 큰 값입니다. 기본 시간은 5분입니다.

   모든 시스템이 같은 KeyFile 파일을 갖도록 하려면, 모든 파일 서버에 대해 bos listkeys 명령을 실행하고, 새로운 키에 대한 체크섬이 모든 시스템에서 같도록 하십시오.

          % bos listkeys <machine name>

   갱신 서버를 사용하지 않는 경우는 5분 내에 4 단계를 완료하도록 하십시오.

6. kas setpassword 명령을 실행하여 인증 데이터베이스에 있는 afs 항목에 같은 키를 입력하십시오.

   인증 서버는 기존 AFS 토큰을 사용하지 않고 자신의 인증 프로세스를 수행합니다. 기본적으로 이것은 로컬(UNIX) ID를 인증하며, AFS가 특권을 부여한 관리자에 해당되지 않을 수 있습니다. -admin 인수를 삽입하여 인증 데이터베이스 항목에 `ADMIN` 플래그가 있는 ID의 이름을 지정하십시오. 항목에 플래그가 있는 지 확인하려면, ADMIN 플래그가 설정되어 있는지 확인하려면에서 설명한 것처럼 kas examine 명령을 실행하십시오.

          % kas setpassword -name afs -kvno <kvno>  \
                            -admin  <admin principal to use for authentication>
          Administrator's (admin_user) password: admin_password
          new_password: afs_password
          Verifying, please re-enter new_password: afs_password

   여기서

   sp
     setpassword의 별명입니다(setp는 축약형입니다).

   -name afs
     afs 항목에서 새로운 키를 작성합니다.

   -kvno
     4 단계에서처럼 같은 키 버전 번호를 지정합니다.

   -admin
     인증 데이터베이스에서 `ADMIN` 플래그로 지정한 관리 계정의 이름입니다. 예를 들면 admin. 암호 프롬프트는 이를 admin_user로 에코합니다. admin_password로서 적합한 암호를 입력하십시오.

   afs_password
     4 단계에서 입력했던 것과 동일한 문자 스트링입니다.
7. (선택적) KeyFile 파일 및 인증 데이터베이스 afs 항목에서 방금 작성한 키가 같고 같은 키 버전 번호를 가지고 있는 지 확인하려는 경우, 서버 암호화 키 표시 명령을 실행하십시오.
8. bos restart 명령을 실행하여 모든 데이터베이스 서버 시스템에서 데이터베이스 서버 프로세스를 다시 시작하십시오. 이렇게 하면 현재 가장 높은 키 버전 번호를 가지고 있는 KeyFile 파일에 들어있는 키를 사용하여 데이터베이스 서버 프로세스를 다시 시작하도록 합니다.

   각각의 데이터베이스 서버 시스템에 대해 빠르게 이 명령을 반복하며, IP 주소가 가장 낮은 시스템에서 부터 시작합니다.

          % bos restart  <machine name> buserver kaserver ptserver vlserver

   여기서

   res
     restart의 축약형입니다.

   machine name
     각 데이터베이스 서버 기계의 이름입니다.

   buserver kaserver ptserver vlserver
     백업 서버, 인증 서버, 보호 서버 및 볼륨 위치(VL) 서버를 각각 지정합니다.

## 서버 암호화 키 제거

/usr/afs/etc/KeyFile 파일에서 이전 키를 주기적으로 제거하면 파일을 적합한 크기로 유지할 수 있습니다. 셀 기능이 방해되지 않도록 하려면, 키로 봉합되고 사용자나 클라이언트 프로세스가 보유하고 있는 모든 토큰이 만기될 때 까지는 이전 키를 제거하지 마십시오. 새로운 키를 추가한 다음에는, 적어도 셀에서 사용하는 가장 큰 토큰 주기동안 이전 키를 제거하도록 기다리십시오. AFS 버전 3.1 이상에서 작성된 인증 데이터베이스 사용자 항목의 경우, 기본 토큰 주기는 25시간이며, AFS 버전 3.0에서 작성된 항목의 기본 토큰 주기는 100시간입니다.

인증 데이터베이스에 있는 afs 항목에서 키를 제거하는 명령은 없습니다. 이 항목에 있는 키 필드는 비어 있어야 하기 때문입니다. kas setpassword 명령을 사용하여 새로운 서버 암호화 키 추가하기에서 설명한 완전한 프로시듀어의 일부로서만 afs 키를 대체하십시오.

현재 인증 데이터베이스의 afs 항목에 있는 키는 KeyFile 파일에서 제거하지 마십시오. AFS 서버 프로세스는 클라이언트가 제공하는 티켓을 해독할 수 없게 됩니다.

### KeyFile 파일에서 키 제거하기

1. /usr/afs/etc/UserList 파일에 나열된 사용자로서 인증받았는 지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. bos listkeys 명령을 실행하여, 제거할 각 키의 키 버전 번호를 표시하십시오. 출력에서는 새로운 키가 KeyFile 파일에 있었던 이후 적어도 25시간이 지났음을 알려줍니다. bos listkeys 명령에 대한 완전한 명령은 KeyFile 파일 표시하기의 내용을 참조하십시오.

          %
       bos listkeys <machine name>

3. kas examine 명령을 실행하여 현재 인증 데이터베이스의 afs 항목에 있는 키가 KeyFile 파일에서 제거하고 있는 키와 같은 키 버전 번호를 갖지 않도록 하십시오. kas examine 명령에 대한 자세한 설명은 인증 데이터베이스에서 afs 키 표시하기의 내용을 참조하십시오.

          % kas examine afs  -admin <admin principal to use for authentication>
          Administrator's (admin_user) password: admin_password

4. bos removekey 명령을 실행하여 KeyFile 파일에서 하나 이상의 서버 암호화 키를 제거하십시오.

   AFS 미국판을 사용하고 있고 갱신 서버를 사용하여 시스템 제어 시스템의 /usr/afs/etc 디렉토리 내용을 분배하는 경우, machine name 인수 대신 시스템 제어 시스템을 사용하십시오(시스템 제어 시스템이 어느 시스템인 지 잊어버린 경우는 시스템 제어 시스템을 찾으려면 내용을 참조하십시오).

   AFS 각국 언어판을 사용하거나 갱신 서버를 사용하지 않는 경우, bos removekey 명령을 반복하여 machine name 인수를 셀에 있는 각 서버 시스템으로 대체하십시오.

          % bos removekey <machine name> <key version number>

   여기서

   removek
     removekey의 축약형입니다.

   machine name
     갱신 서버를 사용하는 경우는 셀의 시스템 제어 시스템을, 사용하지 않는 경우는 각각의 서버 시스템의 이름입니다.

   key version number
     제거할 각 키의 키 버전 번호를 지정합니다.

## 서버 암호화 키 비상사태 처리

아주 드문 경우이긴 하지만, AFS 서버 프로세스는 클라이언트나 피어 서버 프로세스가 제공하는 서버 티켓을 해석할 수 없게 될 수 있습니다. 셀에서의 활동도 정지되며, 서버 프로세스는 티켓이 위조되었거나 만기된 것으로 믿으므로 모든 조치의 실행을 거부합니다. 이것은 한 시스템 또는 여러 시스템에서 발생할 수 있습니다. 여러 시스템이 포함되는 경우는 그 효과가 좀 더 심각합니다.

서버 암호화 키 문제점이 발생하는 한가지 원인은 클라이언트 티켓이 서버 프로세스가 모르는 키로 암호화되기 때문입니다. 보통 이것은 서버 시스템에 있는 /usr/afs/etc/KeyFile에 afs 인증 데이터베이스 항목에 있는 키가 포함되지 않음을 의미하며, 여기서 인증 서버의 티켓 부여 서비스(TGS) 모듈이 서버 티켓을 암호화하는 데 사용됩니다.

또 다른 원인은 다른 시스템에 있는 KeyFile 파일에 같은 키가 들어있지 않은 것입니다. 이런 경우 서버 프로세스간의 통신은 불가능합니다. 예를 들어 AFS의 복제 데이터베이스 메카니즘은 다른 데이터베이스 서버 시스템에 있는 데이터베이스 서버 프로세스가 같은 키를 사용하고 있지 않은 경우 중단됩니다.

로컬 셀에 있는 파일 서버 시스템에 bos 명령을 지시할 때 다음 오류 메시지가 나타나는 것은 서버 암호화 키가 불일치한다는 징후입니다(그러나 외부 셀에 있는 파일 서버 시스템에 bos 명령을 지시할 때 -cell 인수를 포함시키는 것을 잊어버리면 이 메시지가 표시될 수도 있음을 기억하십시오).

       bos: failed to contact host's bosserver (security object was passed a bad ticket).

서버 암호화 키 비상사태의 해결방법은 인증 데이터베이스와, 모든 서버 시스템상의 KeyFile 파일 모두에 새로운 AFS 서버 암호화 키를 두어, TGS와 모든 서버 프로세스가 다시 같은 키를 공유할 수 있도록 하는 것입니다.

키 비상사태를 처리하려면 몇가지 특별한 조치가 필요합니다. 이들 조치를 수행하는 이유는 다음 절에서 설명합니다. 실제 프로시듀어는 후속 명령에서 나타납니다.

### 상호 인증 예방

서버 프로세스는 사용자 토큰을 해석할 수 없으므로 사용자가 키 비상사태를 처리한 뒤 서버 프로세스들이 상호 인증하지 않도록 해야 합니다. 서로 인증하지 않으면, 서버 프로세스는 사용자에게 anonymous ID를 지정합니다. 상호 인증하지 않도록 하기 위해, unlog 명령을 사용하여 토큰을 버리고 가능한 모든 명령에 -noauth 플래그를 포함하십시오.

### 직접 권한부여 점검 사용 불가능 설정

서버 프로세스는 사용자가 상호 인증하지 않을 때 사용자를 사용자 anonymous로 인식하므로, 권한부여 확인을 오프로 설정해야 합니다. 권한부여 확인을 사용 불가능으로 설정해야만 서버 프로세스가 anonymous 사용자에게 키 작성과 같은 특권이 부여된 조치를 수행하도록 허용할 수 있습니다.

비상사태시, 직접 /usr/afs/local/NoAuth 파일을 작성하여 권한부여 확인을 사용 불가능으로 설정하십시오. 일반 상황에서는 대신 bos setauth 명령을 사용하십시오.

### 각 시스템에서 빠르게 작업하기

권한부여 확인을 사용 불가능으로 설정하는 것은 심각한 보안 노출을 야기하며, 이는 영향을 받은 시스템상의 서버 프로세스가 임의 조치를 수행하기 때문입니다. 필요한 경우에만 권한부여 확인을 사용 불가능으로 설정하여 인터럽트되지 않은 세션에서 가능한 빨리 모든 단계를 완료하십시오.

### 콘솔에서의 작업

권한부여 확인을 사용 불가능으로 설정한 각 서버 시스템의 콘솔에서 작업하면 사용자가 콘솔에 있는 동안은 어느 누구도 콘솔에 로그온할 수 없습니다. 다른 사용자가 원격으로 시스템에 연결하지 못하도록 하는 것은 아니며(예를 들면 telnet 프로그램을 사용하여), 이것은 빠르게 작업하는 데 중요하기 때문입니다. 완벽하게 보안을 유지하는 유일한 방법은 네트워크 통신량을 사용 불가능하게 설정하는 것이며, 이것은 많은 환경에서 사용할 수 없는 옵션입니다. 셀의 보안 향상에서 설명한 것처럼 일반적으로 언제든 서버 시스템에 원격으로 연결할 수 있는 사용자 수를 제한하여 보안을 향상시킬 수 있습니다.

### 각 KeyFile 파일 변경

갱신 서버를 사용하여 /usr/afs/etc 디렉토리 내용을 분배하는 경우, 발생할 수 있는 비상사태는 각 시스템에 있는 KeyFile 파일을 변경하는 것이 적합할 때입니다. 각 시스템 파일을 갱신하는 것은 불일치하는 키로 인해 시스템 제어 시스템의 upserver 프로세스가 다른 서버 시스템에 있는 upclientetc 프로세스와 상호 인증할 수 없도록 하기 때문에 필요합니다. 이 경우 upserver 프로세스는 KeyFile 파일을 다른 서버 시스템에 분배하지 않습니다.

갱신 서버가 제대로 동작하는 것처럼 보이는 경우라도, 시스템 제어 시스텝에 있는 키를 변경하고 upclientetc 프로세스가 키를 검색하는 지 보기 위해 표준 지연 기간동안 기다리는 것이 유일한 방법입니다. 비상사태 동안은 보통 표준 지연 기간을 기다려야 하는 지 감지하지 못합니다. 각 서버 시스템에 있는 파일을 개별적으로 갱신하는 것이 더 간단합니다. 또한 갱신 서버가 파일을 정확하게 분배할 수 있는 경우라도, 다른 프로세스들은 키 불일치로 인해 문제가 있을 수 있습니다. 다음 명령에서는 시스템 제어 시스템에 있는 파일에 먼저 새로운 키를 추가합니다. 갱신 서버가 작동하고 있으면, 각 서버 시스템에서 작성한 것과 같은 변경사항을 분배하는 것입니다.

셀이 갱신 서버를 사용하지 않거나 AFS 각국 언어판을 사용하면, 항상 서버 시스템에 있는 키들을 개별적으로 변경합니다. 다음 명령도 이에 적합합니다.

### 두 개의 구성요소 프로시듀어

다음 명령에서 자주 사용되는 두 개의 서브 프로시듀어 즉, 권한부여 확인 사용불능 설정 및 다시 사용가능 설정이 있습니다. 투명성을 위해, 여기에는 프로시듀어에 대해 자세히 설명합니다. 명령에서는 필요한 대로 이들을 참조합니다.

#### 비상사태시 권한부여 체크 사용 불가능 설정

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. 권한부여 체크를 사용 불가능으로 설정하도록 /usr/afs/local/NoAuth 파일을 작성하십시오.

          # touch /usr/afs/local/NoAuth

3. 토큰을 버리십시오. 이 경우 호환될 수 없는 키로 토큰이 봉합되었으므로 몇몇을 실행할 수 없게 합니다.

          # unlog

#### 비상사태시 권한부여 체크 사용가능으로 재설정

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. /usr/afs/local/NoAuth 파일을 제거하십시오.

          #
       rm /usr/afs/local/NoAuth

3. system:administrators 그룹에 속하는 관리 ID로서 인증하고 /usr/afs/etc/UserList 파일에 나열됩니다.

          # klog <admin_user>
          Password: <admin_password>

4. 해당되면, unlog 명령을 실행하여 토큰을 버린 뒤 콘솔에서 로그아웃하십시오(또는 사용하는 원격 연결을 닫으십시오).

### 비상사태시 새로운 서버 암호화 키 작성하기

1. 시스템 제어 시스템에서, 비상사태시 권한부여 체크 사용 불가능 설정에서 설명한 것처럼 권한부여 체크를 사용 불가능으로 설정하십시오.
2. 새로운 키의 키 버전 번호를 선택하는 첫번째 단계로서 bos listkeys 명령을 실행하여 이미 KeyFile 파일에서 사용하고 있는 키 버전 번호를 표시하십시오.

          # bos listkeys <machine name>
       -noauth

   여기서

   listk
     listkeys의 축약형입니다.

   machine name
     파일 서버 시스템을 지정합니다.

   -noauth
     BOS 서버와의 상호 인증을 통과합니다. 키 비상사태로 인해 성공적인 상호 인증을 수행할 수 없는 경우 이를 포함하십시오.
3. 2 단계에서 배운 내용과 다음 요구조건을 근거로 새로운 키에 대한 키 버전 번호를 선택하십시오.
   - 기존에 있는 번호 중 가장 큰 번호보다 하나 더 큰 키 버전 번호를 선택하여 키 버전 번호를 연속적으로 보존하는 것이 가장 좋습니다.
   - 키 버전 번호는 KerBeros 표준에 적합하도록 0 - 255 이내의 정수여야 합니다.
   - KeyFile 파일에 현재 나열된 키 버전 번호는 다시 사용하지 마십시오.
4. 시스템 제어 시스템에서, bos addkey 명령을 실행하여 KeyFile 파일에서 새로운 AFS 서버 암호화 키를 작성하십시오.

          #
       bos addkey <machine name> -kvno <key version number> -noauth
          input key: afs_password
          Retype input key: afs_password

   여기서

   addk
     addkey의 축약형입니다.

   machine name
     KeyFile 파일에서 새로운 키를 정의하는 파일 서버 시스템의 이름입니다.

   -kvno
     3 단계에서 선택한 키 버전 번호를 지정하며, 0 - 255 이내의 정수여야 합니다. 7, 8 및 13 단계에서 같은 번호를 지정해야 합니다.

   -noauth
     BOS 서버와의 상호 인증을 통과합니다. 키 비상사태로 인해 성공적인 상호 인증을 수행할 수 없는 경우 이를 포함하십시오.

   afs_password
     사용자 암호와 비슷한 문자 스트링으로, 길이는 1 - 1,000자 이내입니다. 보안을 향상시키기 위해, 문자열을 가능한 길게 작성하고 영문자 이외의 문자를 포함시키십시오.

     8진 문자열을 직접 입력하지 마십시오. BOS 서버는 문자열을 KeyFile 파일에 기록하기 전에 암호화 키로서 사용하도록 8진 문자열로 만듭니다.

     문자열을 기억하십시오. 7, 8, 및 13 단계에서 다시 사용해야 합니다.

5. 셀에 있는 모든 데이터베이스 서버 시스템에서(시스템 제어 시스템 이외), 비상사태시 권한부여 체크 사용 불가능 설정에서 설명한 것처럼 권한부여 체크를 사용 불가능하게 설정하십시오. 시스템 제어 시스템이 데이터베이스 서버 시스템인 경우는 사용자가 이미 1 단계에서 권한부여 체크를 사용불가능으로 설정했으므로 이 프로시듀어를 반복하지 마십시오(데이터베이스 서버 시스템이 어느 시스템인 지 알아야 하는 경우는 데이터베이스 서버 시스템을 찾으려면에서 설명한 바와 같이 bos listhosts 명령을 사용하십시오).
6. 5 단계를 완료한 뒤 적어도 90초 동안 기다려, 데이터베이스 서버 프로세스(인증, 백업, 보호 및 볼륨 위치 서버) 각각이 새로운 동기 사이트를 선택하도록 하십시오. 그런 다음 udebug 명령을 실행하여 선택이 적합했는 지 확인하십시오. 다음 명령을 실행하여 각 데이터베이스 서버 이름을 server machine 대신 사용하십시오. 데이터베이스 서버 시스템인 경우는 시스템 제어 시스템을 포함하십시오.

          # udebug <server machine> buserver
          # udebug <server machine> kaserver
          # udebug <server machine> ptserver
          # udebug <server machine> vlserver

   각 프로세스에서, 모든 데이터베이스 서버 시스템의 출력은 프로세스에 대한 동기 사이트에 동의해야 합니다. 그러나 4개 프로세스 각각에 대한 동기 사이트로서 같은 시스템을 제공할 필요는 없습니다. 각 프로세스에서, 한 시스템의 출력에는 다음 문자열이 포함되어야 합니다.

          I am sync site ...

   대신 다른 시스템의 출력에는 다음 행이 포함됩니다.

          I am not sync site

   이후 행은 `Sync host` 문자열로 시작되고, 동기 사이트가 되도록 요청하는 시스템의 IP 주소를 지정합니다.

   출력이 이러한 요구조건이 맞지 않거나 다른 방법에서는 비정상으로 보이면, AFS 제품 지원에 문의하십시오.

7. 셀에 있는 모든 데이터베이스 서버 시스템에서(시스템 제어 시스템 이외), 4 단계에서 설명한 bos addkey 명령을 실행하십시오. 이 단계에서 사용한 것과 같은 값을 afs_password 및 kvno에서 사용하도록 하십시오.
8. kas setpassword 명령을 실행하여 인증 데이터베이스의 afs 항목에서 새로운 키를 정의하십시오. 4 단계 및 7 단계에서 작성한 키가 일치해야 합니다.

          # kas setpassword  -name afs  -kvno <key version number>
       -noauth
          new_password: afs_password
          Verifying, please re-enter new_password: afs_password

   여기서

   sp
     setpassword의 별명입니다(setp는 축약형입니다).

   -kvno
     4 단계에서 지정한 것과 같은 키 버전 번호입니다.

   afs_password
     4 단계에서 afs_password로서 지정했던 것과 동일한 문자 스트링입니다. 시각적으로 에코되지 않습니다.
9. 셀에 있는 모든 데이터베이스 서버 시스템에서(데이터베이스 서버 시스템인 경우는 시스템 제어 시스템도 포함), 비상사태시 권한부여 체크 사용가능으로 재설정에서 설명한 것처럼 권한부여 체크를 다시 사용가능으로 설정하십시오. 시스템 제어 시스템이 데이터베이스 서버 시스템이 아니면, 11 단계까지 이 프로시듀어를 수행하지 마십시오.
10. 6 단계를 반복하여 각 데이터베이스 서버 프로세스가 9에서 다시 시작된 뒤 동기 사이트를 제대로 선택했는 지 확인하십시오.
11. 시스템 제어 시스템에서는(데이터베이스 서버 시스템이 아닌 경우), 비상사태시 권한부여 체크 사용가능으로 재설정에서 설명한 바와 같이 권한부여 체크를 다시 사용가능으로 설정하십시오. 데이터베이스 서버 시스템인 경우는 이미 9 단계에서 프로시듀어를 수행했습니다.
12. 나머지 모든 (단일) 파일 서버에서는, 비상사태시 권한부여 체크 사용 불가능 설정에서 설명한 바와 같이 권한 부여 체크를 사용 불가능으로 설정하십시오.
13. 나머지 모든 (단일) 파일 서버 시스템에서는, 4 단계에서 설명한 bos addkey 명령을 실행하십시오. 이 단계에서 사용한 것과 같은 값을 afs_password 및 kvno에서 사용하도록 하십시오.
14. 나머지 모든 (단일) 파일 서버 시스템에서는, 비상사태시 권한부여 체크 사용가능으로 재설정에서 설명한 바와 같이 권한 부여 체크를 사용 가능으로 다시 설정하십시오.

[ 페이지의 맨 위 | 이전 페이지 | 다음 페이지 | 목차 | 색인 ]

© IBM Corporation 2000. All Rights Reserved