문제 정의

필자가 여러번 겪어왔던 문제가 있습니다: 관리자들이 ufsdump 를 이용해서 파일 시스템 덤프를 원격 시스템에 연결된 테잎 드라이브에 저장해야 하는 일이 매우 잦다는 것입니다.

몇몇 사이트에서는 추가적인 요구사항으로 테잎에 덤프 데이타가 기록되기 전에 암호돠 되어야 한다는 것도 있었습니다. 덤프파일을 암호화 하는 것은 잘못 위치된 덤프파일이 중요하고 민감한 데이타들에 영향을 미치지 않도록 도와 줍니다. 어쨌든 암호화된 덤프파일을 포함하고 있는 테잎은 적절한 키 없이는 절대 복구가 가능하지 않습니다.

또 다른 자주 접하게 되는 이슈로는 오퍼레이터의 권한 입니다. 시스템 관리자는 보통 일간으로 수행하는 작업들을 보통 루트 권한을 가지고 있지 않은 오퍼레이터에게 맡깁니다. 어떻게 여러분은 비-루트, 그리고 낮은 권한의 유저 계정을 이용해서 적절한 파일 시스템 덤프를 진행 할 수 있을까요?

해결책 제안

이 글은 위의 모든 사항들을 오직 한번의 작업으로 만족시킬 수 있는 방법을 아무것도 필요 없이 오직 솔라리스에서 제공하는 유틸리티 만으로 할 수 있도록 하는 절차를 제시 합니다. 어떠한 써드파티 소프트웨어도 요구되지 않습니다.

• Role-based access control (RBAC)

  솔라리스의 RBAC 을 이용함으로써 선택적으로 오퍼레이터에게 파일 시스템 덤프를 관리할 수 있는 권한을 부여할 수 있음.

• Secure Shell (SSH) 공개 키 암호화 및 dd 커맨드

  By using 솔라리스 ssh 의 비대칭 인증을 사용함으로써 백업 스트림을 암호화 해서 네트워크를 통해서 전송할때 혹은 원격 테잎 드라이브의 제한된 접근 권한을 얻을때 사용할 수 있음.

  dd 커맨드는 이때 암호화된 데이타 스트림을 수락하고 이것을 적절한 백업 테잎 혹은 파일 디바이스로 리다이렉트 시키는데 사용됨.

  원격의 authorized_keys 파일 고급옵션을 사용하면 접근키가 유출됨으로써 발생될 수 있는 심각한 문제들을 줄일 수 있음.

• 솔라리스crypt 와 encrypt 유틸리티

  솔라리스 9의 9 crypt 커맨드 혹은 솔라리스10 encrypt 유틸리티를 이용해서 덤프가 테잎에 쓰여지기 전에 안전하게 암호화 시킬 수 있음.

  덤프를 암호화하는데 사용된 키는 테잎 서버와는 별도로 저장할 수 있음. 예를 들어 이것을 CD-R 에 구운 다음 CD-R 을 안전한 장소에 보관 하는 방법이 있을 수도 있음.

제안된 해결책을 실행하는 방법은 여러가지가 있을 수 있습니다. 다음 섹션에서 제공하는 기본 절차들을 살펴 볼것을 권장합니다.

절차 및 가정

기본 절차들은 다음의 3가지 단계로 나뉘어 집니다:

• 설정
• 백업
• 복구

가정

2개의 시스템을 가지고 있다고 가정합니다:

• 서버 A 는 덤프 혹은 백업이 필요한 파일 시스템을 가지고 있음.
• 서버 A 의 오퍼레이터 계정은 ubackup 임.
• 서버 B 는 직접 연결된 로컬 테잎 드라이브를 가지고 있음.
• 서버 B 의 오퍼레이터 계정은 uremote 임.
• 서버 B 와 서버 A 는 일반적인 TCP/IP 라우팅을 통해서 접근 가능.

우리의 목표는 ufsdump 를 사용해서 서버 A 의 파일 시스템을 암호화하여 덤프한 후 신뢰되지 않은 네트워크를 통해 서버 B 에 연결된 테잎 드라이브에 옮기는 것입니다. 서버 B 에 테잎 덤프의 결과물 또한 암호화되어 있을 것입니다.

설정

1. 서버 A 의 루트 권한으로 일반적이고 낮은 수준의 권한을 가진 사용자를 생성합니다 (ubackup).

  # groupadd -g 10000 backup
  # projadd -g 10000 group.backup
  # useradd -d /export/home/ubackup -m -g backup ubackup
  # passwd ubackup

2. 역시 서버 A 의 루트 권한으로 낮은 수준의 권한 을 가진 유저 (ubackup) 에게 적절한 RBAC "Media Backup" 프로파일 권한을 지정합니다.

  # usermod -P "Media Backup" ubackup

3. 서버 A 의 ubackup 이 적절한 RBAC 프로파일을 가지고 있는지 확인합니다.

a. 서버 A 에 유저 ubackup 으로 로그인 합니다:

  $ profiles

b. 프로파일에서 "Media Backup" 이 있는지 확인합니다:

  Media Backup
  Basic Solaris User
  All

4. 서버 A 의 ubackup 유저로 SSH 공개-개인 키를 생성합니다.

주의: 만약 암호를 공백으로 지정하길 원한다면 이 과정 중에 ssh-agent 와 ssh-add 단게를 생략하시기 바랍니다. 암호를 공백으로 지정하길 원치 않는다면 적절한 암호구문을 아래의 커맨드를 실행할때 입력하시기 바랍니다.

  $ ssh-keygen -b 1024 -t rsa
  Generating public/private rsa key pair.
  Enter file in which to save the key
(/export/home/ubackup/.ssh/id_rsa):
  Created directory '/export/home/ubackup/.ssh'.
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in
/export/home/ubackup/.ssh/id_rsa.
  Your public key has been saved in
/export/home/ubackup/.ssh/id_rsa.pub.
  The key fingerprint is:
  09:aa:ed:b7:24:31:69:64:fa:f1:50:dd:87:52:d0:d7
operator@ServerA

5. 서버 B 의 루트 권한으로 일반적이고 낮은 수준의 권한을 가진 사용자를 생성합니다 (uremote):

  # groupadd -g 10000 backup
  # projadd -g 10000 group.backup
  # useradd -d /export/home/uremote -m -g backup uremote
  # passwd uremote

6. 서버 B 의 uremote 사용자를 위해 SSH authorized_keys 파일을 적절하게 설정하시기 바랍니다.

a. 서버 A ubackup 유저의 ~/ssh/id_rsa.pub 파일을 서버 B uremote 유저의 ~/ssh/authorized_keys 로 복사하시기 바랍니다.

b. authorized_keys 파일은 그룹 혹은 다른 유저에 대해 쓰기 혹은 실행 권한이 없음을 확인하시기 바랍니다.

c. 서버 B uremote 사용자의 ~/.ssh 디렉토리가 퍼미션 값 700으로 지정되어 있는지 확인하시기 바랍니다.

7. (선택사항!) 키의 제약사항을 좀 더 상세하게 지정하도록 서버 B uremote 유저의 ~/ssh/authorized_keys 파일을 수정해서 아래와 같은 문장을 ssh-rsa 바로 이전에 추가시킵니다 (라인의 제일 처음에):

원본:

  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2j2o...<rest of key>

수정:

  from="<Server A hostname or IP>",no-pty,no-port-forwarding,
no-X11-forwarding,no-agent-forwarding ssh-rsa ...<rest of key>

이전의 수정은 키가 오직 서버 A ubackup 유저에 의해서만 사용될 수 있도록 합니다. 또한 키가 노출 되었더라고 제한적인 기능만을 사용할 수 있도록 해 줍니다.

키의 제약을 좀 더 자세히 지정할 수 있습니다. 예를 들어 command= 를 이용해서 실제 커맨드를 명시적으로 지정해서 작업특수한 키를 생성함으로써 좀 더 자세히 제약사항을 지정할 수 있습니다.

좀 더 자세한 정보는 BigAdmin 에 올라와 있는 Amy Rich 의 Secure Shell: Part 2 를 참고하시기 바랍니다.

8. 서버 A 유저 ubackup 권흔으로 ssh-agent 를 로딩하고 개인 키를 추가 함으로써 보안 비대칭 로그인을 활성화 시킵니다. 또한 단계 4에서 지정한 암호구문을 입력합니다.

  $ ssh-agent ksh
  $ ssh-add
  Enter passphrase for /export/home/steven/.ssh/id_rsa:
  Identity added: /export/home/steven/.ssh/id_rsa
(/export/home/steven/.ssh/id_rsa)

9. ssh 로그인이 자동으로 이루어 질수 있는지 확인 하기 위해 서버 A 의 유저 ubackup 권한으로 아래의 커맨드를 실행시킵니다:

  # ssh uremote@ServerB "ls -al"

이전의 커맨드가 원격 서버에서 간단한 ls -al 명령을 실행 시킨후에 리턴되어야 합니다. 처음 시도할때에는 다음과 같은 메세지를 받을 것입니다:

  The authenticity of host '10.10.10.10 (10.10.10.10)' can't
be established.
  RSA key fingerprint is c1:dd:c9:ca:dd:c0:b4:d6:5d:12:ad:
2c:8c:c7:4a:f8.
  Are you sure you want to continue connecting (yes/no)? yes

그렇다면 간단힌 yes 로 대답합니다. 동일한 커맨드를 두번째 실행하면 더이상 동일한 메세지가 나타나지 않을 것입니다.

10. 서버 B 에 uremote 사용자로 로그인한후 ufsdump 암호화를 위해 사용할 적절한 랜덤-키 파일을 생성합니다:

  $ dd if=/dev/random of=/export/home/uremote/.ssh/encrypt-key
bs=192 count=1

파일이 uremote 에 의해 읽기 전용인지를 확인 하시기 바랍니다. 절대 이 키 파일을 잃어 버리지 마십시오!

이 키 파일을 안전하게 보관하기 위해 키 파일을 CD-ROM 으로 굽고 이 CD-ROM 을 안전한 곳에 보관할 수도 있습니다.

성공적인 복구작업을 위해서는 서버 B 의 CD-ROM 트레이에 CD-ROM 을 위치시켜야 할 것입니다.

백업

1. 서버 A 에 ubackup 사용자로 로그인 한후에 덤프 작업을 시작합니다.

솔라리스10 의 encrypt 유틸리티를 사용하는 예제 입니다:

$ pfexec ufsdump 0bf 256 - /dev/md/rdsk/d5 | ssh uremote@ServerB \
"encrypt -a 3des -k /export/home/uremote/.ssh/encrypt-key | \
dd of=/dev/rmt/0n obs=128k conv=sync"

솔라리스9 에서는 좀 더 간단한 crypt 커맨드를 사용해야 합니다:

$ pfexec ufsdump 0bf 256 - /dev/md/rdsk/d5 | ssh uremote@ServerB \
"crypt password | dd of=/dev/rmt/0n obs=128k conv=sync"

주의

매우 중요한 사항으로 여러분은 반드시 ufsdump 블럭 사이즈와 dd 블럭 사이즈를 기록해 두어야 합니다. 왜냐하면 첫번째 복구 프로세스는 복구 섹션에서 알 수 있듯이 각각의 적절한 블럭사이즈를 요구하기 때문입니다. 이상적으로 블럭 사이즈는 서로 매치 될 것입니다. 즉 ufs dump 블럭 사이즈 256 은 512 bytes 의 256 블럭을 의미 할 것입니다.(256 * 512 / 1024 = 128K)

2. 백업 프로세스를 prstat 를 통해 모니터링 합니다.

서버 B 에서 prstat 프로젝트 설비를 통해서 관련된 프로세스를 쉽게 모니터링 할 수 있습니다:

$ prstat -Jj group.backup

프로세스 트리를 보기 위해서는 간단히 다음의 명령을 입력합니다:

$ ptree `pgrep dd`

복구

어떻게 이전에 암호화해서 원격 덤프로 저장했던 것을 복구시킬 수 있을까요?

서버 A 에서 루트 권한으로 다음을 입력합니다:

  # /usr/bin/ssh -n uremote@ServerB "dd bs=128k files=1
if=/dev/rmt/0n | \
  decrypt -a 3des -k /export/home/uremote/.ssh/encrypt-key" | \
  (cd /tmp; ufsrestore rvbf 256 - <files>)

uremote 의 사용자 패스워드를 입력합니다.

아마 다음과 같은 출력을 볼 수 있을것입니다.

  # ssh -n admin@10.10.10.10 \
  "dd bs=128k files=1 if=/dev/rmt/1n | crypt testkey" | \
  ufsrestore bxvf 256 - /etc/apache2

  Verify volume and initialize maps
  admin@10.10.10.10's password:
  read: Not enough space
  0+0 records in
  0+0 records out
  Volume is not in dump format
  root@SunU60 # ssh -n admin@10.10.10.10 "dd bs=128k
files=1 if=/dev/rmt/1n | c>
  Verify volume and initialize maps
  admin@10.10.10.10's password:
  Note: doing byte swapping
  Dump   date: Thu Feb 01 09:54:45 2007
  Dumped from: the epoch
  Level 0 dump of / on fujitsu:/dev/dsk/c0d0s0
  Label: none
  Extract directories from tape
  Initialize symbol table.
  Make node ./etc
  Make node ./etc/apache2
  Extract requested files
  extract file ./etc/apache2/httpd.conf-example
  extract file ./etc/apache2/highperformance-std.conf
  extract file ./etc/apache2/highperformance.conf
  extract file ./etc/apache2/httpd-std.conf
  extract file ./etc/apache2/magic
  extract file ./etc/apache2/mime.types
  extract file ./etc/apache2/ssl-std.conf
  extract file ./etc/apache2/ssl.conf
  Add links
  Set directory mode, owner, and times.
  set owner/mode for '.'? [yn] y
  41837+0 records in
  41837+0 records out

만약 잘못된 crypt 키가 사용되었따면 다음과 같은 메세지를 볼 수 있습니다:

  root@SunU60 # ssh admin@10.10.10.10 "dd bs=128k files=1
if=/dev/rmt/1n | crypt wrongkey" | ufsrestore bxvf 256 -
  Verify volume and initialize maps
  admin@10.10.10.10's password:
  Volume is not in dump format
  41837+0 records in
  41837+0 records out

이 컨텐츠의 영문 원본 컨텐츠 보기
http://www.sun.com/bigadmin/content/submitted/secure_ufsdumps.jsp