이 장에서는 사용자 셀의 서버 암호화 키를 유지하는 방법에 대해 설명합니다. 이것은 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 항목 및 KeyFile 파일을 작성하는 명령에 대해서는 AFS 빠른 시작의 내용을 참조하십시오.
그 키로 봉합된 토큰을 가진 클라이언트가 없는 것이 확실할 경우에만 기존 서버 암호화 키를 안전하게 삭제할 수 있습니다. 일반적으로, 적어도 셀에 있는 최대 토큰 주기동안 기다리십시오. 기본적으로, 사용자의 최대 토큰 주기는 25시간입니다(AFS 버전 3.0을 사용하여 인증 데이터베이스를 작성했던 사용자는 제외하고 기본값은 100시간입니다). kas setfields 명령에서 -lifetime 인수를 사용하여 이 기본값을 변경할 수 있습니다.
기존 키 제거 명령은 서버 암호화 키 제거에 있습니다.
AFS의 각국 언어판을 실행하는 경우, 갱신 서버를 사용하여 /usr/afs/etc 디렉토리의 내용, 특히 KeyFile 파일을 분배하지 마십시오. 파일에 있는 데이터는 암호화되지 않은 양식으로 전송하기에는 너무 민감하며, 미국 정부의 수출 규정으로 인해 AFS의 각국 언어판에는 갱신 서버가 사용할 수 있는 양식으로 된 필요한 암호화 루틴이 포함되지 않습니다. 대신 각 서버 시스템에 있는 파일을 수정해야 하며, 모든 서버 시스템에서 같은 키를 입력할 때에는 주의해야 합니다.
파일 서버 시스템에 있는 /usr/afs/etc/KeyFile 파일에서 서버 암호화 키를 표시하려면 bos listkeys 명령을 사용하십시오. kas examine 명령을 사용하여 인증 데이터베이스의 afs 항목에 있는 키를 표시하십시오.
기본적으로 명령에서는 키를 구성하는 실제 8진 문자열을 표시하지 않지만, 키로 상수를 암호화하여 얻은 십진수인 체크섬을 표시합니다. 이렇게 하면 허가없는 사용자가 실제 키에 쉽게 액세스할 수 없게 되며, 이 실제 키는 보호 통신에서 거짓을 말하거나 도청할 때 사용할 수 있습니다. bos listkeys 및 kas examine 명령은 제공된 키에 대해 같은 체크섬을 생성하므로, 실제 키 대신 체크섬을 표시하는 것으로 충분합니다. 체크섬이 알려지지 않는다는 점에서 키가 다르다고 생각되면, 셀 전체에서 인증 문제점을 경험하고 있을 것입니다. 가장 쉬운 해결 방법은 서버 암호화 키 추가 또는 서버 암호화 키 비상사태 처리 명령 다음에 새로운 서버 암호화 키를 작성하는 것입니다. bos listkeys 명령을 실행하는 또 다른 이유는 다음 버전 번호를 선택하기 위한 준비 단계로서 현재 사용하는 키 버전 번호를 표시하기 위한 것입니다. 여기서는 키 자체는 관계가 없으므로 체크섬으로 충분합니다.
실제 8진수를 표시하는 것이 중요한 경우, -showkey 인수를 bos listkeys 및 kas examine 명령 모두에 삽입하십시오.
% bos listusers <machine name>
% bos listkeys <machine name> [-showkey]
여기서
다음 예에서, 출력은 실제 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 토큰을 사용하지 않고 자신의 인증 프로세스를 수행합니다. 기본적으로 이것은 로컬(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
여기서
다음 예에서, 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는 별개의 두 장소에 서버 암호화 키를 기록합니다.
서버 프로세스와 TGS가 같은 AFS 서버 암호화 키를 공유하도록 하려면, 인터럽트없이 이 절에 있는 모든 단계를 실행하십시오.
다음 명령에는 모든 데이터베이스 서버 시스템에서 데이터베이스 서버 프로세스(인증, 백업, 보호 및 볼륨 위치 서버 프로세스)를 다시 시작하는 단계가 포함됩니다. 데이터베이스 서버 프로세스가 시작되면, KeyFile 파일에서 키 버전 번호가 가장 높은 서버 암호화 키를 읽어들이고, 이를 사용하여 데이터베이스를 동기화하고 정족수를 유지하기 위해 전송하는 메시지를 보호합니다. 확장된 기간이 될 수도 있는 주기 전체에서 KeyFile 파일에서 키를 제거하는 경우라도 같은 키를 사용합니다. 그러나 피어 데이터베이스 서버 프로세스 중 하나가 다시 시작되고 다른 것은 시작되지 않으면, 정족수와 데이터베이스 동기화는 프로세스들이 더 이상 같은 키를 사용하지 않으므로 중단됩니다. 다시 시작된 프로세스는 현재 가장 높은 키 버전 번호를 가진 키를 사용하며, 다른 프로세스들은 이들이 원래 시작될 때 읽어들인 키를 계속해서 사용합니다. 이 문제점을 예방하려면, 새로운 키를 추가할 때 모든 데이터베이스 서버 프로세스들을 다시 시작하는 것이 가장 안전합니다.
새로운 키를 추가한 뒤에는 더 이상 사용되지 않는 이전 키를 KeyFile 파일에서 제거하여 흩어지는 것을 막을 수 있습니다. 그러나 클라이언트나 서버 프로세스가 계속해서 사용하고 있는 키를 제거하지 않도록 조심해야 합니다. 설명과 명령에 대해서는 서버 암호화 키 제거의 내용을 참조하십시오.
% bos listusers <machine name>
% bos listkeys <machine name>
여기서
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
여기서
번호를 기억하십시오. 6 단계에서 이를 다시 사용해야 합니다. AFS 각국 언어판을 사용하는 경우, 이 명령을 실행할 때마다 같은 번호를 입력해야 합니다.
8진 문자열을 직접 입력하지 마십시오. BOS 서버는 문자열을 KeyFile 파일에 기록하기 전에 암호화 키로서 사용하도록 8진 문자열로 만듭니다.
모든 시스템이 같은 KeyFile 파일을 갖도록 하려면, 모든 파일 서버에 대해 bos listkeys 명령을 실행하고, 새로운 키에 대한 체크섬이 모든 시스템에서 같도록 하십시오.
% bos listkeys <machine name>
갱신 서버를 사용하지 않는 경우는 5분 내에 4 단계를 완료하도록 하십시오.
인증 서버는 기존 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
여기서
각각의 데이터베이스 서버 시스템에 대해 빠르게 이 명령을 반복하며, IP 주소가 가장 낮은 시스템에서 부터 시작합니다.
% bos restart <machine name> buserver kaserver ptserver vlserver
여기서
/usr/afs/etc/KeyFile 파일에서 이전 키를 주기적으로 제거하면 파일을 적합한 크기로 유지할 수 있습니다. 셀 기능이 방해되지 않도록 하려면, 키로 봉합되고 사용자나 클라이언트 프로세스가 보유하고 있는 모든 토큰이 만기될 때 까지는 이전 키를 제거하지 마십시오. 새로운 키를 추가한 다음에는, 적어도 셀에서 사용하는 가장 큰 토큰 주기동안 이전 키를 제거하도록 기다리십시오. AFS 버전 3.1 이상에서 작성된 인증 데이터베이스 사용자 항목의 경우, 기본 토큰 주기는 25시간이며, AFS 버전 3.0에서 작성된 항목의 기본 토큰 주기는 100시간입니다.
인증 데이터베이스에 있는 afs 항목에서 키를 제거하는 명령은 없습니다. 이 항목에 있는 키 필드는 비어 있어야 하기 때문입니다. kas setpassword 명령을 사용하여 새로운 서버 암호화 키 추가하기에서 설명한 완전한 프로시듀어의 일부로서만 afs 키를 대체하십시오.
현재 인증 데이터베이스의 afs 항목에 있는 키는 KeyFile 파일에서 제거하지 마십시오. AFS 서버 프로세스는 클라이언트가 제공하는 티켓을 해독할 수 없게 됩니다.
% bos listusers <machine name>
% bos listkeys <machine name>
% kas examine afs -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password
AFS 미국판을 사용하고 있고 갱신 서버를 사용하여 시스템 제어 시스템의 /usr/afs/etc 디렉토리 내용을 분배하는 경우, machine name 인수 대신 시스템 제어 시스템을 사용하십시오(시스템 제어 시스템이 어느 시스템인 지 잊어버린 경우는 시스템 제어 시스템을 찾으려면 내용을 참조하십시오).
AFS 각국 언어판을 사용하거나 갱신 서버를 사용하지 않는 경우, bos removekey 명령을 반복하여 machine name 인수를 셀에 있는 각 서버 시스템으로 대체하십시오.
% bos 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 프로그램을 사용하여), 이것은 빠르게 작업하는 데 중요하기 때문입니다. 완벽하게 보안을 유지하는 유일한 방법은 네트워크 통신량을 사용 불가능하게 설정하는 것이며, 이것은 많은 환경에서 사용할 수 없는 옵션입니다. 셀의 보안 향상에서 설명한 것처럼 일반적으로 언제든 서버 시스템에 원격으로 연결할 수 있는 사용자 수를 제한하여 보안을 향상시킬 수 있습니다.
갱신 서버를 사용하여 /usr/afs/etc 디렉토리 내용을 분배하는 경우, 발생할 수 있는 비상사태는 각 시스템에 있는 KeyFile 파일을 변경하는 것이 적합할 때입니다. 각 시스템 파일을 갱신하는 것은 불일치하는 키로 인해 시스템 제어 시스템의 upserver 프로세스가 다른 서버 시스템에 있는 upclientetc 프로세스와 상호 인증할 수 없도록 하기 때문에 필요합니다. 이 경우 upserver 프로세스는 KeyFile 파일을 다른 서버 시스템에 분배하지 않습니다.
갱신 서버가 제대로 동작하는 것처럼 보이는 경우라도, 시스템 제어 시스텝에 있는 키를 변경하고 upclientetc 프로세스가 키를 검색하는 지 보기 위해 표준 지연 기간동안 기다리는 것이 유일한 방법입니다. 비상사태 동안은 보통 표준 지연 기간을 기다려야 하는 지 감지하지 못합니다. 각 서버 시스템에 있는 파일을 개별적으로 갱신하는 것이 더 간단합니다. 또한 갱신 서버가 파일을 정확하게 분배할 수 있는 경우라도, 다른 프로세스들은 키 불일치로 인해 문제가 있을 수 있습니다. 다음 명령에서는 시스템 제어 시스템에 있는 파일에 먼저 새로운 키를 추가합니다. 갱신 서버가 작동하고 있으면, 각 서버 시스템에서 작성한 것과 같은 변경사항을 분배하는 것입니다.
셀이 갱신 서버를 사용하지 않거나 AFS 각국 언어판을 사용하면, 항상 서버 시스템에 있는 키들을 개별적으로 변경합니다. 다음 명령도 이에 적합합니다.
다음 명령에서 자주 사용되는 두 개의 서브 프로시듀어 즉, 권한부여 확인 사용불능 설정 및 다시 사용가능 설정이 있습니다. 투명성을 위해, 여기에는 프로시듀어에 대해 자세히 설명합니다. 명령에서는 필요한 대로 이들을 참조합니다.
% su root Password: root_password
# touch /usr/afs/local/NoAuth
# unlog
% su root Password: root_password
# rm /usr/afs/local/NoAuth
# klog <admin_user> Password: <admin_password>
# bos listkeys <machine name> -noauth
여기서
# bos addkey <machine name> -kvno <key version number> -noauth input key: afs_password Retype input key: afs_password
여기서
8진 문자열을 직접 입력하지 마십시오. BOS 서버는 문자열을 KeyFile 파일에 기록하기 전에 암호화 키로서 사용하도록 8진 문자열로 만듭니다.
# 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 제품 지원에 문의하십시오.
# kas setpassword -name afs -kvno <key version number> -noauth new_password: afs_password Verifying, please re-enter new_password: afs_password
여기서