리눅스를 사용한다면 맞춤 백업 솔루션을 만드는 데 필요한 굉장히 강력한 도구에 접근할 수 있다. 이 글에서 다룰 솔루션은 간단하면서 좀 더 진보적이고 안전한 네트워크 백업을 수행하는 데 도움이 될 것이다. 이 일을 하는 데는 거의 모든 리눅스 배포판의 일부로 들어 있는 오픈 소스 도구를 사용할 것이다.

간단한 백업

이 글은 단계별 접근 방식을 따를 것이다. 일단 기초 단계를 따라온다면 매우 수월할 것이다.

간단하지만 강력한 아카이브 메커니즘으로 시작해 좀 더 진보된 분산 백업 솔루션으로 나가 보자. 바로 쓸 수 있는 arc라는 스크립트를 시험해 보자. 이 스크립트를 이용해 리눅스 셸 프롬프트에서 백업 스냅샷을 만들 수 있다.

   #!/bin/sh
   tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1
   exit $?

arc 스크립트는 파일 하나 또는 디렉터리 이름을 매개변수로 받아 압축된 아카이브 파일을 만들고 그 결과로 만들어진 아카이브 파일 이름에 현재 날짜를 집어넣는다. 예를 들어 beoserver라는 디렉터리가 있고, 스크립트를 호출해 beoserver 디렉터리 이름을 전달하면 beoserver.20040321-014844.tgz라는 압축된 아카이브가 만들어진다.

date 명령을 쓰면 날짜가 삽입되는데 타임스탬프가 아카이브한 파일을 정리하는 데 도움이 된다. 날짜 형식은 일, 월, 일, 시, 분, 초다(초 필드는 별로 중요하지 않을지도 모른다). 다른 옵션에 대해 배우려면 date 명령의 man 페이지(man date)를 보라. 또 Listing 1에서 tar에 -v(verbose) 옵션을 넘겼다. 이렇게 하면 tar에서 압축하는 파일을 전부 보여준다. 백업을 조용히 진행하고 싶으면 -v 옵션을 빼면 된다.

   $ ls
   arc  beoserver
   $ ./arc beoserver
   beoserver/
   beoserver/bookl.dat
   beoserver/beoserver_ab_off
   beoserver/beoserver_ab_on
   $ ls
   arc  beoserver  beoserver.20040321-014844.tgz

위로

고급 백업

이 간단한 백업 예제도 유용하지만 여전히 수동 백업 과정이 들어있다. 업계 모범 사례에서는 매체 여러 개에, 별도 지역으로 나눠 자주 백업을 하라고 권장한다. 핵심 아이디어는 저장 매체 하나 또는 백업 장소 한 곳에 전적으로 의존하는 것을 피하는 것이다.

다음 예에서 이 도전에 부딪혀 보겠다. 그림 1에 나온 가상의 분산 네트워크를 시험해 볼 것이다. 그림 1은 원격 서버 두 대와 오프사이트 데이터 저장 서버 한 대에 접근할 수 있는 시스템 관리자를 보여준다.

서버 1과 2의 백업 파일은 오프사이트 저장 서버로 안전하게 전송되고 전체 분산 백업 과정은 사람이 개입하지 않고 정기적으로 실행될 것이다. tar(tape archiver)뿐만 아니라 OpenSSH(Open Secure Shell) 도구 스위트의 일부인 표준 도구 모음, cron 작업 스케줄링 서비스를 사용하겠다. 전체 계획은 스케줄링에는 cron을, 백업 과정에는 셸 프로그래밍과 tar 애플리케이션을, 원격 접근과 인증에는 OpenSSH 암호화를, 파일 전송 자동화에는 scp(secure shell copy)를 사용하는 것이다. 추가 정보는 각 도구의 man 페이지를 리뷰하라.

위로

공개/개인 열쇠를 사용하는 보안 원격 접근

디지털 보안이라는 문맥에서 열쇠는 데이터를 암호화하거나 해독하는 데 쓰이는 데이터다. 공개/개인 열쇠 스킴은 흥미로운 것이다. 공개 열쇠로 암호화한 데이터는 연관된 개인 열쇠로만 해독할 수 있기 때문이다. 다른 사람들이 여러분에게 보내는 메시지를 암호화할 수 있게 자신의 공개 열쇠를 자유롭게 배포할 수 있다. 공개/개인 열쇠 스킴이 디지털 보안에 혁명을 일으킨 이유 중 하나는 보내는 사람과 받는 사람이 공통 패스워드를 공유할 필요가 없기 때문이다. 무엇보다도 공개/개인 열쇠 암호 덕분에 전자 상거래와 기타 안전한 매매가 가능해졌다. 이 글에서는 매우 안전한 분산 백업 솔루션을 만드는 데 공개/개인 열쇠를 만들어 사용할 것이다.

백업 과정에 참여하는 각각의 기계는 중간 방화벽을 통해 접근할 수 있는 sshd(OpenSSH secure shell service, 22번 포트 사용)를 반드시 실행중이어야 한다. 원격 서버에 접근할 수 있다면 이미 보안 셸을 실행하고 있는 것이다.

우리의 목표는 수동으로 패스워드를 제공할 필요 없이 안전한 접근을 기계에 제공하는 것이다. 몇몇 사람들은 이렇게 하는 가장 쉬운 방법은 패스워드 없는 접근을 세팅하는 것이라고 생각한다. 이러면 안 된다. 안전하지 않기 때문이다. 대신 이 글에서 쓸 접근 방식은 한 시간 정도 걸려 패스프레이즈 없는 계정의 모든 편리함을 제공하지만 매우 안전하다고 인식되는 시스템을 세팅하는 것이다.

OpenSSH가 설치되어 있는지 확인하고 OpenSSH 버전 번호를 점검하자. 이 글을 쓸 때 OpenSSH 최신판은 2004년 2월 24일 발표된 3.8이었다(역주: 2008년 7월 21일 5.1p1 출시). 최신 안정판을 사용하는 것을 고려해 보라. 최소한 2.x 버전 이상을 써야 한다. OpenSSH 보안 페이지에 가서 옛 버전에 한정된 취약성과 관련된 세부 내용을 확인해 보라(링크는 이 글 나중에 나오는 참고자료를 보라). 현재 OpenSSH는 매우 안정적이고 다른 SSH 도구에서 보고되는 여러 취약성에 안전한 것으로 입증됐다.

셸 프롬프트에서 ssh라 입력하면서 대문자 V 옵션을 주어 버전 번호를 확인한다.

$ ssh -V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

ssh에서 2.x 이상의 버전 번호를 돌려주면 비교적 좋은 상태다. 하지만 모든 소프트웨어의 최신 안정판을 사용하기를 권한다. 그리고 이는 보안 관련 소프트웨어에 특히 중요하다.

첫 단계는 오프사이트 저장 서버 기계에 계정을 사용해 로그인하는 것이다. 이 계정은 서버 1과 2에 접근할 수 있는 권한을 가질 것이다(그림 1).

$ ssh accountname@somedomain.com

오프사이트 저장 기계에 로그인하면 ssh-keygen 프로그램을 사용해 -t dsa 옵션으로 공개/개인 열쇠 쌍을 만든다. -t 옵션이 필요한데 생성하려는 암호 열쇠를 지정하는 데 쓰인다. 우리는 DSA(Digital Signature Algorithm)를 사용할 것인데 DSA는 더 새로운 SSH2 프로토콜을 이용할 수 있다. 좀 더 자세한 내용은 ssh-keygen man 페이지를 보라.

ssh-keygen을 실행하는 동안 패스프레이즈에 대한 질문을 받기 전 ssh 열쇠를 저장할 위치를 물어볼 것이다. 열쇠를 어디에 저장할지 물어볼 때 그냥 엔터를 누르면 ssh-keygen 프로그램이 공개/개인 열쇠 파일이 들어있는 .ssh라는 숨겨진 디렉터리를 만들 것이다(아직 없을 경우).

ssh-keygen의 흥미로운 특징은 패스프레이즈를 물어볼 때 그냥 엔터만 눌러도 된다는 것이다. 패스프레이즈를 제공하지 않으면 ssh-keygen은 암호화되지 않은 열쇠를 만들어낸다. 이것이 좋은 아이디어가 아님을 알 것이다. 패스프레이즈를 물어볼 때 단순한 패스워드 문자열이 아니라 알파벳과 숫자가 들어간, 알맞게 긴 문자열 메시지를 꼭 넣어야 한다.

   [offsite]:$ ssh-keygen -t dsa
   Generating public/private dsa key pair.
   Enter file in which to save the key (/home/accountname/.ssh/id_dsa):
   Enter passphrase (empty for no passphrase): (enter passphrase)
   Enter same passphrase again: (enter passphrase)
   Your identification has been saved in /home/accountname/.ssh/id_dsa.
   Your public key has been saved in /home/accountname/.ssh/id_dsa.pub.
   The key fingerprint is:
   7e:5e:b2:f2:d4:54:58:6a:fa:6b:52:9c:da:a8:53:1b accountname@offsite

ssh-keygen이 만든 .ssh 디렉터리는 숨겨진 '마침표(.)' 디렉터리이기 때문에 ls 명령에 -a 옵션을 주어야 새로 만든 디렉터리를 볼 수 있다.

[offsite]$ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

숨겨진 .ssh 디렉터리에 들어가 내용을 보자.

[offsite]$ cd .ssh
[offsite]$ ls -lrt
id_dsa id_dsa.pub

이제 개인 열쇠(id_dsa)와 공개 열쇠(id_dsa.pub)가 숨겨진 .ssh 디렉터리에 있다. 각 열쇠 파일의 내용을 vi나 이맥스 갈은 텍스트 편집기 또는 less나 cat 명령으로 열어볼 수 있다.base64로 인코드된 알파벳과 숫자로 조합된 문자로 구성되어 있음을 알 수 있을 것이다.

다음으로 공개 열쇠를 서버 1과 2에 복사, 설치해야 한다. ftp는 사용하지 말라. 대신 scp를 사용해 각각의 원격 기계에 공개 열쇠를 전송한다.

   [offsite]$ scp .ssh/id_dsa.pub accountname@server1.com:offsite.pub
   accountname@server1.com's password: (enter password, not new
   passphrase!)
   id_dsa.pub 100% |*****************************| 614 00:00

   [offsite]$ scp .ssh/id_dsa.pub accountname@server2.com:offsite.pub
   accountname@server2.com's password: (enter password, not new
   passphrase!)
   id_dsa.pub 100% |*****************************| 614 00:00

새 공개 열쇠를 설치한 후 공개/개인 열쇠를 만들 때 지정한 패스프레이즈를 사용해 각각의 기계에 로그인할 수 있다. 이제 각각의 기계에 로그인해 offsite.pub 파일의 내용을 authorized_keys라는 파일에 덧붙인다. authorized_keys 파일은 각각의 원격 기계의 .ssh 디렉터리에 저장되어 있다. 텍스트 편집기나 간단히 cat 명령으로 offsite.pub 파일의 내용을 authorized_keys 파일에 덧붙인다.

   [offsite]$ ssh accountname@server1.com
   accountname@server1.com's password: (enter password, not new
   passphrase!)
   [server1]$ cat offsite.pub >> ./ssh/authorized_keys

다음 단계는 추가 보안과 관련되어 있다. 먼저 소유자만 읽고 쓰고 실행할 수 있는 권한을 갖도록 .ssh 디렉터리의 접근 권한을 바꾼다. 그 다음에는 authorized_keys 파일에 소유자만 접근할 수 있게 해야 한다. 그리고 마지막으로 앞서 올린 offsite.pub 열쇠 파일을 지운다. 더 이상 필요하지 않기 때문이다. 접근 허가권이 적절하게 세팅되어 있는지 확인하는 것이 중요하다. OpenSSH 서버가 안전하지 않은 접근 권한을 가진 열쇠를 사용하는 것을 거부할지도 모르기 때문이다.

   [server1]$ chmod 700 .ssh
   [server1]$ chmod 600 ./ssh/authorized_keys
   [server1]$ rm offsite.pub
   [server1]$ exit

서버 2에서 같은 과정을 마치면 오프사이트 저장 기계로 돌아가 새 패스프레이즈 형식 접근을 테스트해 볼 준비가 된 것이다. 오프사이트 서버에서 다음과 같이 입력한다.

[offsite]$ ssh -v accountname@server1.com

-v 옵션을 쓰면 여러분의 계정이 원래 패스워드 대신 새 패스프레이즈로 원격 서버에 접근할 수 있는지 검증하는 동안 디버깅 정보가 표시된다. 디버깅 출력은 -v 옵션을 쓰지 않았으면 보지 못했을 중요한 정보를 표시하고 또 인증 과정이 어떻게 이뤄지는지 고수준 뷰를 제공한다. 다음 번 연결에서도 -v 플래그를 지정할 필요는 없다. 그러나 연결을 테스트하는 동안 그렇게 하면 꽤 유용하다.

위로

ssh-agent를 사용해 기계 접근 자동화

ssh-agent 프로그램은 문지기처럼 동작하며 필요할 때 보안 열쇠에 접근을 제공한다. ssh-agent가 시작되면 백그라운드에서 ssh와 scp 프로그램 같은 기타 OpenSSH 애플리케이션에서 사용 가능하게 한다. 이렇게 되면 ssh 프로그램이 필요할 때마다 개인 열쇠의 보안 패스프레이즈를 요청하기보다는 이미 해독된 열쇠를 요청할 수 있게 된다.

ssh-agent를 자세히 들여다 보자. ssh-agent가 실행되면 셸 명령을 출력한다.

   [offsite]$ ssh-agent
   SSH_AUTH_SOCK=/tmp/ssh-XX1O24LS/agent.14179; export SSH_AUTH_SOCK;
   SSH_AGENT_PID=14180; export SSH_AGENT_PID;
   echo Agent pid 14180;

셸의 eval 명령을 사용해 ssh-agent가 표시하는 출력 명령을 실행하도록 셸에 지시할 수 있다.

[offsite]$ eval `ssh-agent`
Agent pid 14198

eval은 ssh-agent 프로그램이 생성한 명령을 평가(실행)하라고 셸에 알린다. 작은 따옴표가 아니라 꼭 ` 문자를 지정해야 한다는 점에 주의한다. 일단 실행되면 eval `ssh-agent` 문장은 에이전트의 프로세스 아이디를 돌려줄 것이다. 그 뒤에서는 SSH_AUTH_SOCK과 SSH_AGENT_PID 셸 변수가 익스포트되고 사용할 수 있게 된다. 셸 콘솔에 변수들을 표시해 그 값을 볼 수 있다.

[offsite]$ echo $SSH_AUTH_SOCK
/tmp/ssh-XX7bhIwq/agent.14197

$SSH_AUTH_SOCK(SSH Authentication Socket의 줄임말)은 애플리케이션이 ssh-agent와 통신하기 위해 사용할 수 있는 로컬 소켓의 위치다. SSH_AUTH_SOCK과 SSH_AGENT_PID 변수가 항상 등록되는지 확실하게 하려면 ~/.bash_profile에 eval `ssh-agent` 문장을 넣는다.

ssh-agent는 이제 백그라운드 프로세스가 되어 top과 ps 명령으로 볼 수 있다.

이제 ssh-agent로 패스프레이즈를 공유할 준비가 됐다. 그렇게 하려면 ssh-add라는 프로그램을 사용해야만 한다. ssh-add는 실행중인 ssh-agent 프로그램에 패스프레이즈를 추가한다(보낸다).

   [offsite]$ ssh-add
   Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase)
   Identity added: /home/accountname/.ssh/id_dsa
   (/home/accountname/.ssh/id_dsa)

이제 서버 1에 접근할 때 패스프레이즈를 물어보지 않는다.

[offsite]$ ssh accountname@server1.com
[server1]$ exit

확실하지 않으면 ssh-agent 프로세스를 죽이고(kill -9) 서버 1에 다시 연결해 보라. 이번에는 서버 1에서 .ssh 디렉터리의 id_dsa 파일에 저장된 개인 열쇠에 대한 패스프레이즈를 요청함을 볼 수 있을 것이다.

[offsite]$ kill -9 $SSH_AGENT_PID
[offsite]$ ssh accountname@server1.com
Enter passphrase for key '/home/accountname/.ssh/id_dsa':

위로

열쇠 사슬로 열쇠 접근 단순하게 하기

지금까지 몇 가지 OpenSSH 프로그램(ssh, scp, ssh-agent, ssh-add)을 배웠고 안전하고 자동화된 로그인 과정을 쓸 수 있게 하기 위해 공개/개인 열쇠를 만들고 설치했다. 셋업 작업 대부분은 한 번만 하면 된다는 것을 알게 됐을 것이다. 예를 들어 열쇠를 만들고 설치하고 ssh-agent가 .bash_profile을 통해서만 실행되게 하는 과정은 기계 당 한 번만 실행하면 된다.정말 좋은 소식이다.

좀 덜 이상적인 소식은 ssh-add가 오프사이트 기계에 로그인할 때마다 호출되어야 하고 ssh-agent가 백업 자동화에 필요한 cron 스케줄링 과정과 바로 호환되지 않는다는 것이다. cron 프로세스가 ssh-agent와 통신할 수 없는 이유는 cron 작업이 cron의 자식 프로세스로 실행되므로 $SSH_AUTH_SOCK 셸 변수를 상속하지 않기 때문이다.

다행히도 ssh-agent와 ssh-add에 관련된 제한을 없앨 뿐만 아니라 다른 기계에 패스워드 없는 보안 접근을 요청하는 모든 과정을 자동화하는 데 cron을 사용할 수 있게 되는 해법이 있다. 2001년에 3부에 걸쳐 연재된 OpenSSH key management(링크는 참고자료를 보라)에서, Daniel Robbins가 keychain이라는 셸 스크립트를 선보였다. 이 스크립트는 ssh-add와 ssh-agent의 프런트엔드이며 전체 무패스워드 과정을 단순하게 해준다. 시간이 지나 keychain 스크립트는 몇 차례 개선됐고 지금은 Aron Griffis가 유지 보수한다. 2004년 6월 17일 2.3.2-1이 공개됐다.

keychain 셸 스크립트는 이 글에서 보여주기에는 너무 크다. 잘 짠 스크립트에는 오류 점검, 충분한 문서, 크로스 플랫폼 코드를 위한 풍부한 배려 등이 들어있다. 하지만 keychain은 프로젝트 웹 사이트에서 빨리 다운로드할 수 있다(링크는 참고자료를 보라).

keychain을 다운로드하고 설치하면, 사용하는 것은 매우 쉽다. 그냥 각각의 기계에 로그인해 각각의 .bash_profile에 다음 두 줄을 추가하면 된다.

keychain id_dsa
. ~/.keychain/$HOSTNAME-sh

각 기계에 다시 로그인하면 처음에 keychain이 패스프레이즈를 물어본다. 하지만 keychain은 기계가 재시작하지 않는 한 이어지는 로그인 시도에서 패스프레이즈를 다시 넣으라고 요청하지 않는다. 무엇보다도 cron 작업이 OpenSSH 명령을 사용해 패스프레이즈 사용 요청 없이 원격 기계에 안전하게 접근할 수 있게 된다. 이제 보안과 쓰기 쉬움이라는 두 세계의 가장 좋은 점을 가졌다.

   KeyChain 2.3.2; http://www.gentoo.org/projects/keychain
   Copyright 2002-2004 Gentoo Technologies, Inc.; Distributed under the
   GPL

   * Initializing /home/accountname/.keychain/localhost.localdomain-sh
   file...
   * Initializing /home/accountname/.keychain/localhost.localdomain-csh
   file...
   * Starting ssh-agent
   * Adding 1 key(s)...
   Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase)

위로

백업 과정 스크립팅

다음 작업은 셸 스크립트를 만드는 것이다. 이 셸 스크립트는 필요한 백업 작업을 수행할 것이다. 목표는 서버 1과 2의 완전한 데이터베이스 백업을 수행하는 것이다. 예제에서 각 서버는 MySQL 데이터베이스 서버를 실행중이고 mysqldump 명령행 유틸리티를 사용해 데이터베이스 테이블 몇 개를 SQL 임포트 파일로 익스포트할 것이다.

   #!/bin/sh

   # change into the backup_agent directory where data files are stored.
   cd /home/backup_agent

   # use mysqldump utility to export the sites database tables
   mysqldump -u sitedb -pG0oDP@sswrd --add-drop-table sitedb --tables
   tbl_ccode tbl_machine tbl_session tbl_stats > userdb.sql

   # compress and archive
   tar czf userdb.tgz userdb.sql

서버 2에는 그 사이트 데이터베이스의 유일한 테이블을 백업하는 스크립트를 둘 것이다. 각 스크립트에 다음과 같이 실행 가능 플래그를 붙인다.

[server1]:$ chmod +x dbbackup.sh

서버 1과 2의 dbbackup.sh 파일을 가지고 오프사이트 데이터 서버로 돌아가자. 오프사이트 데이터 서버에서 압축된(.tgz) 데이터 파일 전송을 초기화하기 전에 각각의 원격 dbbackup.sh 스크립트를 호출하는 셸 스크립트를 만들 것이다.

   #!/bin/sh

   # use ssh to remotely execute the dbbackup.sh script on server 1
   /usr/bin/ssh backup_agent@server1.com "/home/backup_agent/dbbackup.sh"

   # use scp to securely copy the newly archived userdb.tgz file
   # from server 1.  Note the use of the date command to timestamp
   # the file on the offsite data server.
   /usr/bin/scp backup_agent@server1.com:/home/backup_agent/userdb.tgz
   /home/backups/userdb-$(date +%Y%m%d-%H%M%S).tgz

   # execute dbbackup.sh on server 2
   /usr/bin/ssh backup_agent@server2.com "/home/backup_agent/dbbackup.sh"

   # use scp to transfer transdb.tgz to offsite server.
   /usr/bin/scp backup_agent@server2.com:/home/backup_agent/transdb.tgz
   /home/backups/transdb-$(date +%Y%m%d-%H%M%S).tgz

backup_remote_servers.sh 셸 스크립트는 ssh 명령을 사용해 원격 서버의 스크립트를 실행한다. 패스워드 없는 접근을 세팅했으므로 ssh 명령은 오프사이트 서버로부터 원격으로 서버 1과 2의 명령을 실행할 수 있다. 전체 인증 과정은 현재 자동으로 처리된다. keychain 덕이다.

위로

스케줄링

마지막 작업은 오프사이트 데이터 저장 서버에서 backup_remote_servers.sh 셸 스크립트를 실행하는 스케줄을 잡는 것이다. 백업 스크립트를 하루에 두 번, 오전 3:34, 오후 8:34에 실행을 요청하도록 cron 스케줄링 서버에 엔트리 두 개를 추가할 것이다. 오프사이트 서버에서 편집(-e) 옵션으로 crontab 프로그램을 호출하라.

[offsite]:$ crontab -e

crontab이 VISUAL 또는 EDITOR 셸 환경 변수에 지정된 기본 편집기를 호출한다. 다음으로 두 엔트리를 입력하고 파일을 저장하고 닫는다.

   34 3 * * * /home/backups/remote_db_backup.sh
   34 20 * * * /home/backups/remote_db_backup.sh

crontab 행에는 두 가지 주요 부분이 있다. 먼저 시간 일정 부분과 그 다음에 나오는 명령 부분이다. 시간 일정은 명령이 실행될 시간을 지정하는 필드로 나뉜다.

          +---- minute
          | +----- hour
          | | +------ day of the month
          | | | +------ month
          | | | | +---- day of the week
          | | | | | +-- command to execute
          | | | | | |
         34 3 * * * /home/backups/remote_db_backup.sh

위로

백업 검증하기

백업을 정기적으로 점검해 백업 과정이 정확히 작동하는지 확인해야 한다. 과정 자동화는 불필요한 고역을 없앨 수 있으나 실사(due diligence)를 피하는 방법이 되어서는 안 된다. 데이터가 백업할 가치가 있다면 때때로 점검할 가치도 있는 것이다.

한 달에 최소한 한 번씩 백업을 점검하도록 알려주는 cron 작업을 추가하는 것을 고려해 보라. 그 외에 보안 열쇠를 이따금 바꾸는 것도 좋은 생각이다. 그리고 그 일을 하도록 자신에게 알려주는 cron 작업 일정을 잡으라.

위로

추가적인 보안 주의 사항

보안을 더하기 위해 각각의 기계에 스노트(Snort) 같은 IDS(Intrusion Detection System)를 설치하고 설정하는 것을 고려해 보라. 아마 IDS가 침입 시도가 최근에 발생했거나 일어나는 중일 때 알려줄 것이다. IDS가 제대로 동작하면 백업에 디지털 사인을 하고 암호화하는 것 같은 기타 보안 조치를 추가할 수 있을 것이다.

GnuPG(GNU Privacy Guard), OpenSSL, ncrypt 같은 유명한 오픈 소스 도구를 이용하면 셸 스크립트를 통해 파일을 안전하게 아카이브할 수 있으나 IDS가 제공하는 추가 보호(shielding) 없이 그렇게 하는 것은 권하지 않는다(스노트에 관한 더 자세한 정보는 참고자료를 보라).

위로

결론

이 글에서는 스크립트를 원격 서버에서 실행하고 안전하고 자동화된 파일 전송을 수행하는 방법을 보여주었다. 독자들이 자신의 귀중한 데이터를 보호하고 OpenSSH와 스노트 같은 오픈 소스 도구를 이용하는 새로운 솔루션을 구축하는 것에 대해 영감을 받았기를 바란다.

참고자료

• 공식 OpenSSH 홈페이지와 OpenSSH 보안 페이지에서 다운로드와 문서를 찾아 보라.
  
  
• Read Daniel Robbins의 훌륭한 3부 IBM developerWorks 연재, "OpenSSH 키 관리"(developerWorks, 2001년)를 읽고 keychain 애플리케이션을 다운로드하라.
  
  
• SSH에 대해 더 배우려면, Carlos가 오라일리의 SSH, The Secure Shell: The Definitive Guide (O'Reilly & Associates, 2001년)를 추천한다.
  
  
• 스노트(Snort) IDS(Intrusion Detection System)는 허가받지 않은 접근이나 의심스러운 행동을 탐지하고 보고하기 위해 디자인된 최고의 오픈 소스 제품이다. 아카이브 파일 사인과 암호화를 자동화할 계획이라면 IDS를 꼭 사용하라.
  
  
• 셸 스크립트에서 GnuPG(GNU Privacy Guard), OpenSSL, ncrypt를 이용해 아카이브 백업 파일을 사인하고 암호화할 수 있다.
  
  
• TCP wrappers와 xinetd 팁.
  
  
• 펄(Perl)에 경도된 사람들은 Ted Zlatanov가 쓴 "펄을 이용하여 UNIX 시스템 관리 자동화하기"(developerWorks, 2001년), "시스템 관리를 위한 cfengine"(developerWorks, 2002년), "펄로 애플리케이션 구성 "(developerWorks, 2000년)에 흥미가 있을 것이다.
  
  
• developerWorks 기사 "Windows-to-Linux roadmap: Part 8. Backup and recovery"(developerWorks, 2003년)에서 백업 전략에 관한 팁을 제공한다.
  
  
• IBM의 Tivoli Storage Manager for Linux는 맞춤 일정에 따라 리눅스 컴퓨터와 서버를 위한 신뢰할 만한 백업, 아카이브, 중앙 데이터 관리를 자동화한다. 그 외에 Tivoli 제품군은 사용자 관리, 접근 제어, 네트워크 모니터링 등을 단일화한 환경과 인터페이스로 제공한다.
  
  
• IBM developerWorks Tivoli 존에서 Tivoli 솔루션에 대해 더 배우라.
  
  
• developerWorks 리눅스 존에서 리눅스 개발자를 위한 참고자료를 찾아보라.
  
  
• 이 주제와 기타 기술 주제에 관한 책을 찾아보라.
  
  
• developerWorks에 가입해 최신 IBM 도구와 미들웨어를 이용해 리눅스 애플리케이션을 개발하고 테스트하라
  
  
• Speed-start your Linux app에서 WebSphere Studio Site Developer, WebSphere SDK for Web services, WebSphere Application Server, DB2 Universal Database Personal Developers Edition, Tivoli Access Manager, Lotus Domino Server 등 리눅스에서 동작하는 무료 시험판을 다운로드하라.
  
  

필자소개

Carlos Justiniano는 Ecuity, Inc.의 소프트웨어 아키텍트이며 통신과 분산 컴퓨팅에 관심이 있다. Carlos는 기술 저널을 여러 편 썼고 리눅스 기반 ChessBrain 프로젝트의 창시자이자 아키텍트이기도 하다. ChessBrain 프로젝트는 분산 컴퓨팅 관련 2005 Guinness World Record에서 상을 받았다.

아티클 순위

의견

위로

목차

• 간단한 백업
• 고급 백업
• 공개/개인 열쇠를 사용하는 보안 원격 접근
• ssh-agent를 사용해 기계 접근 자동화
• 열쇠 사슬로 열쇠 접근 단순하게 하기
• 백업 과정 스크립팅
• 스케줄링
• 백업 검증하기
• 추가적인 보안 주의 사항
• 결론
• 참고자료
• 필자소개
• 의견