レベル: 中級 Carlos Justiniano, Software Architect, Ecuity Inc.
2004年 7月 08日
2008年 7月 03日 更新 重要なデータの損失は壊滅的な結果をもたらす可能性があります。にもかかわらず何百万人もの専門家が、自分たちのデータをバックアップしていません。個々の理由は異なりますが、最も一般的な理由として、日常的にバックアップを行うのは大仕事になってしまうことが挙げられます。バックアップにつきものの単調作業と先延ばしにしたがる人間の性向を回避するための鍵は、無味乾燥な繰り返し作業に優れた機械を使ってバックアップを自動化することです。
Linux を使っている人には、すぐ手の届く所にカスタム・バックアップ・ソリューションを作成するための非常に強力なツールがあります。この記事で紹介するソリューションを使えば、ほとんどの Linux ディストリビューションに含まれているオープンソースのツールを使って、簡単なバックアップから高度でセキュアなバックアップまで、ネットワーク経由で行えるようになります。
簡単なバックアップ
この記事ではバックアップ手順について順を追って説明します。基本的な手順を踏みさえすれば、ごく簡単なものです。
より高度な分散バックアップ・ソリューションについて説明するにあたり、まずは単純かつ強力なアーカイブ機構の説明から始めましょう。最初に arc と呼ばれる手軽なスクリプトを調べてみます。これを使うと、Linux のシェル・プロンプトからバックアップ・スナップショットを作ることができます。
リスト 1. arc シェル・スクリプト
#!/bin/sh
tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1
exit $?
|
arc スクリプトは単一のファイル名またはディレクトリー名をパラメーターとして受け取り、ファイルの名前に現在の日付が埋め込まれた圧縮アーカイブ・ファイルを作成します。例えば beoserver というディレクトリーがあるとすると、arc スクリプトを呼び出して beoserver ディレクトリー名を渡せば、beoserver.20040321-014844.tgz のような圧縮されたアーカイブ・ファイルが作成されます。
date コマンドを使って日付とタイムスタンプを埋め込むと、アーカイブしたファイルを整理しやすくなります。日付のフォーマットは、年、月、日、時、分、秒ですが、秒のフィールドまで使うのはちょっとやりすぎかもしれません。date コマンドの他のオプションについては man ページを見て下さい (man date)。またリスト 1 では、tar に -v (verbose) オプションを渡しています。このオプションを指定すると、バックアップ中に tar がアーカイブしているファイルがすべて表示されるようになります。バックアップ中にファイルを表示したくない場合は、-v オプションを削除してください。
リスト 2. beoserver ディレクトリーをアーカイブする
$ 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 に示す架空の分散ネットワークを使って、この課題に挑戦します。この例では、システム管理者が 2 つのリモート・サーバーとオフサイトのデータ・ストレージ・サーバーにアクセスできるようになっています。
図 1. 分散ネットワーク
サーバー 1 (Server #1) とサーバー 2 (Server #2) にあるバックアップ・ファイルは、オフサイトのストレージ・サーバーにセキュアに転送され、分散バックアップ・プロセス全体が人間の介在なしに定期的に行われます。ここでは Open Secure Shell ツール・スイート (OpenSSH) の一部である一連の標準ツールとテープ・アーカイブ (tar)、それに cron タスク・スケジューリング・サービスを使います。全体的な計画としては、cron をスケジューリングに使い、シェル・プログラミングと tar アプリケーションをバックアップ・プロセスに使い、OpenSSH セキュア・シェル (ssh) 暗号化をリモート・アクセスと認証に使い、セキュア・シェル・コピー (scp) をファイル転送の自動化に使うというものです。詳しい情報は、必ず各ツールの man ページで調べてください。
公開鍵/秘密鍵を使ったセキュアなリモート・アクセス
デジタル・セキュリティーにおいて、鍵とは他のデータの暗号化または復号化のために使われる一片のデータです。公開鍵と秘密鍵の方式は興味深いもので、公開鍵を使って暗号化されたデータは、対となる秘密鍵を使わないと復号できません。秘密鍵を持つ人は公開鍵を自由に配布することができ、データを送信してくる人がその公開鍵を使って、送るべきメッセージを暗号化できるようにします。公開鍵/秘密鍵方式がデジタル・セキュリティーに革命をもたらした理由の一つは、送信者と受信者が共通のパスワードを持つ必要がない、という点です。e コマースやその他のセキュアな取引が可能になったのは、なによりも公開鍵/秘密鍵暗号化によるものです。この記事では公開鍵と秘密鍵を使って、極めてセキュアな分散バックアップ・ソリューションを作成します。
バックアップ・プロセスに関係する各マシンでは、OpenSSH セキュア・シェル・サービス (sshd) を実行している必要があり、中間に介在するどのファイアーウォールを経由してもポート 22 にアクセスできる必要があります。もしリモート・サーバーにアクセスできているのであれば、既にセキュア・シェルが使われている可能性が高いと言えます。
この記事の目標は、手動でパスワードを入力することなく、セキュア・アクセスができるマシンを提供することです。そのために一番簡単なのは、パスワード無しのアクセスを設定することだと考える人もいるかもしれません。しかし絶対にそんなことをすべきではありません。パスワード無しのアクセスはセキュアではありません。この記事で説明する方法は、おそらく一時間くらい皆さんの時間を使って、「パスフレーズの無い」アカウントが持つあらゆる便利さを提供してくれるシステム (しかも非常にセキュアであると認識されているシステム) のセットアップを行います。
まず OpenSSH がインストールされていることを確認し、そのバージョン番号をチェックするところから始めましょう。この記事の執筆時点で最新の OpenSSH のバージョンは、2004年2月24日にリリースされた 3.8 です。最新の安定リリースを使うようにし、最低限、バージョン 2.x よりは新しいものを使ってください。古いバージョンに固有の脆弱性の詳細については、OpenSSH のセキュリティー・ページを見てください (「参考文献」にリンクがあります)。この記事の執筆時点では OpenSSH は非常に安定しており、他の SSH ツールに関して報告されている多くの脆弱性とは無縁となっています (訳注: この段落の内容は、記事の初稿が執筆された時点での情報です)。
以下のようにシェル・プロンプトで、バージョン番号チェックのための、大文字の V オプションとともに ssh と入力します。
$ 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) を使います。これを使うと新しい SSH2 プロトコルが使えるのです。詳細については ssh-keygen の man ページを見てください。
ssh-keygen を実行していると、パスフレーズの入力を求められる前に、ssh 鍵を保存する場所を指定するように促されます。ここで単純に enter を押すと、ssh-keygen プログラムは公開鍵ファイルと秘密鍵ファイルの 2 つのファイルと共に、.ssh という隠しディレクトリーを (まだ存在していなければ) 作成します。
ssh-keygen では興味深い機能として、パスフレーズを入力するように促された時に単純に enter を押すことが可能になっています。パスフレーズを与えないと、ssh-keygen は暗号化していない鍵を生成するのです！ご想像の通り、これは良い考え方とは言えません。パスフレーズを要求されたらば、単純なパスワード文字列ではなく、英数字を含んだ適切な長さの文字列メッセージを入力するようにします。
リスト 3. 常に適切なパスフレーズを選択する
[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 ディレクトリーは「ドットの付いた」隠しディレクトリーなので、新しく作られたディレクトリーを見るには、-a オプションを付けて ls コマンドを実行します。
[offsite]$ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh
隠し .ssh ディレクトリーにカレント・ディレクトリーを変更し、ディレクトリーの内容を表示します。
[offsite]$ cd .ssh
[offsite]$ ls -lrt
id_dsa id_dsa.pub
これで隠し .ssh ディレクトリーに秘密鍵 (id_dsa) と公開鍵 (id_dsa.pub) を用意できました。各鍵ファイルの内容は、vi や emacs のようなテキスト・エディターを使うか、あるいは単純に less や cat コマンドを使って調べることができます。内容を見ると、base64 でエンコードされた英数字から成っていることに気が付くでしょう。
次にサーバー 1 とサーバー 2 に公開鍵をコピーして、インストールする必要があります。ftp は使ってはいけません。リモート・マシンそれぞれに公開鍵を送るには、ftp ではなく、scp を使います。
リスト 4. リモート・サーバーに公開鍵をインストールする
[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 ファイルの内容を、各リモート・マシンの .ssh ディレクトリーにある authorized_keys というファイルに追加します。それには、テキスト・エディターを使うか、または以下のように単純に cat コマンドを使います。
リスト 5. offsite.pub を許可された鍵のリストに追加する
[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 サーバーはセキュアでないアクセス権限を持つ鍵の使用を拒否するかも知れないので、アクセス許可が適切に設定されていることを確認しておくことが重要です。
リスト 6. chmod でアクセス許可を変更する
[server1]$ chmod 700 .ssh
[server1]$ chmod 600 ./ssh/authorized_keys
[server1]$ rm offsite.pub
[server1]$ exit
|
サーバー 1 と同じプロセスをサーバー 2 でも終えると、オフサイトのストレージ・マシンに戻って新しいパスフレーズ・タイプのアクセスをテストすることができます。それには、オフサイトのサーバーから次のように入力します。
[offsite]$ ssh -v accountname@server1.com
元のパスワードではなく新しいパスフレーズを使ってリモート・サーバーにアクセスできることを確認しながら、-v、つまり詳細フラグ・オプションを使ってデバッグ情報を表示します。デバッグ出力は、認証プロセスがどのように動作するかを示す上位レベルのビューに加えて、他の方法では見ることもないような重要な情報を表示します。これから後の接続では -v フラグを指定する必要はありませんが、接続のテスト中には -v フラグを指定しておくと非常に便利です。
ssh-agent を使ってマシン・アクセスを自動化する
ssh-agent プログラムはゲートキーパーのように動作し、必要に応じて、セキュリティー・キーへのアクセスをセキュアに提供します。ssh-agent は起動されるとバックグラウンドに常駐され、ssh や scp といったプログラムなどの他の OpenSSH アプリケーションから利用できるようになります。これによって ssh プログラムは、秘密鍵が要求される度に秘密鍵のパスフレーズを要求するのではなく、既に復号化された鍵を要求できるようになります。
では ssh-agent をもう少し詳しく見てみましょう。ssh-agent が実行されている時には ssh-agent がシェル・コマンドを出力します。
リスト 7. 動作中の 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` という文を実行すると、エージェントの PID (process identifier: プロセス識別子) が返され、裏では 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 の両変数が常に確実に登録されるように eval `ssh-agent` という文を ~/.bash_profile に記載しておきます。
これで ssh-agent はバックグラウンド・プロセスとなり、top と ps コマンドを使って見ることができます。
ssh-agent とパスフレーズを共有する準備ができたので、ssh-add というプログラムを使って共有します。このプログラムによって、実行中の ssh-agent プログラムにパスフレーズを追加 (送信) するのです。
リスト 8. スムーズなログインのための ssh-add
[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':
keychain を使ってキーアクセスを単純化する
ここまででいくつかの OpenSSH プログラム (ssh、scp、ssh-agent、そして ssh-add) について学ぶと同時に、セキュアな自動ログイン・プロセスが可能となる秘密鍵と公開鍵を作成してインストールしました。すでにお気づきかもしれませんが、ここまでの設定作業の大部分は一度だけ行えばよいものです。例えば、鍵の作成やインストールのプロセス、そして .bash_profileを通じて ssh-agent を実行するプロセスなどは、マシン毎に一度だけ行えばよいのです。これは非常に嬉しいことです。
若干理想的でないのは、オフサイトのマシンにサインオンする度に ssh-add を呼び出す必要があることと、バックアップを自動化するために必要となる cron スケジューリング・プロセスに ssh-agent が直接対応していないことです。cron プロセスが ssh-agent と通信できない理由は、cron ジョブが cron によって子プロセスとして実行され、そのため $SSH_AUTH_SOCKK シェル変数を継承していないためです。
幸い解決手段はあり、この手段を使えば ssh-agent や ssh-add に関連した制限が無くなるだけでなく、他のマシンに対してセキュアでパスワード不要のアクセスを必要とする、あらゆる種類のプロセスを cron で自動化できるようになります。その手段とは、2001年に developerWorks に掲載された 3 回シリーズの記事『OpenSSHキー(鍵)の管理』(記事へのリンクは「参考文献」を参照) で Daniel Robbins が説明した、keychain と呼ばれるシェル・スクリプトです。keychain は ssh-add や ssh-agent のフロントエンドで、これを使うことでパスワード不要プロセス全体を単純化することができるのです。その後 keychain スクリプトにはいくつかの改善がなされ、現在は Aron Griffis が維持管理しています。最新のリリースである 2.3.2-1 が公開されたのは 2004年6月17日です。(訳注: この段落の内容は、記事の初稿が執筆された時点での情報です)
keychain シェル・スクリプトは、しっかりと作成されたスクリプトであり、数多くのエラーチェック、また豊富な資料とクロス・プラットフォームのためのコードが惜しげもなく用意されているのですが、この記事に掲載するには少し大きすぎます。ただし keychain は、このプロジェクトの Web サイト (この Web サイトへのリンクは「参考文献」を参照) からすぐにダウンロードすることができます。
一旦 keychain をダウンロードしてインストールすれば、使うのは驚くほど簡単です。各マシンにログインして、次の 2 行を各 .bash_profile に追加するだけです。
keychain id_dsa
. ~/.keychain/$HOSTNAME-sh
再度各マシンに戻って初めてログインすると、keychain はパスフレーズを入力するように促します。ただし keychain は、その後のログインではマシンが再起動されない限りパスフレーズの入力は要求しません。何よりも良いのは、cron タスクがパスフレーズのやり取りをすることなく、OpenSSH コマンドを使ってリモート・マシンにセキュアにアクセスできることです。これによって、セキュリティーの強化と使いやすさという最高の組み合わせが実現できたのです。
リスト 9. 各マシンの keychain を初期化する
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 インポート・ファイルにエクスポートします。
リスト 10. サーバー 1 用の dbbackup.sh シェル・スクリプト
#!/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 スクリプトを呼び出すシェル・スクリプトを作ります。
リスト 11. オフサイトのデータ・サーバーで使用する backup_remote_servers.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 シェル・スクリプトの実行をスケジューリングすることです。cron スケジューリング・サーバーに 2 つのエントリーを追加し、バックアップ・スクリプトを 1 日 2 回、3:34 am と 8:34 pm に実行するように要求します。オフサイトのサーバーでは、編集 (-e) オプションを付けて crontab プログラムを呼び出します。
[offsite]:$ crontab -e
crontab は、VISUAL または EDITOR シェル環境変数を使って指定されたように、デフォルトのエディターを呼び出します。次に 2 つのエントリーを入力し、ファイルを保存し、ファイルを閉じます。
リスト 12. オフサイトのサーバーでの crontab エントリー
34 3 * * * /home/backups/remote_db_backup.sh
34 20 * * * /home/backups/remote_db_backup.sh
|
crontab 行には、タイム・スケジュールのセクションと、それに続くコマンドセクション、という 2 つの主なセクションがあります。タイム・スケジュールは、いつコマンドを実行するかを指定するフィールドに分けられています。
リスト 13. crontabフォーマット
+---- minute
| +----- hour
| | +------ day of the month
| | | +------ month
| | | | +---- day of the week
| | | | | +-- command to execute
| | | | | |
34 3 * * * /home/backups/remote_db_backup.sh
|
バックアップを検証する
プロセスが正しく動作していることを確認するため、バックアップを定期的にチェックするべきです。自動プロセスによって、余計な単調作業をなくすことができますが、適正な注意を避けるための手段とすべきではありません。データがバックアップに値するものであれば、時々スポット・チェックをかけるだけの価値もあるはずです。
少なくとも月に 1 度はバックアップのチェックを思い出せるように、cron ジョブを追加することを考えてください。また、時々セキュリティー・キーを変更するのも賢明なことで、それも思い出せるように cron ジョブをスケジュールすることもできます。
さらなるセキュリティー対策
さらにセキュリティーを強化するためには、各マシンに Snort のような侵入検知システム (IDS: Intrusion Detection System) をインストールして設定しておくことを考えてください。IDSは、不正侵入が発生している場合、あるいは最近発生した場合におそらく知らせてくれるはずです。IDS を設定しておくことによって、デジタル署名やバックアップの暗号化など、別レベルのセキュリティーをかけることができます。
また GnuPG (GNU Privacy Guard) や OpenSSL、それに ncrypt など、普及しているオープンソースのツールを使うと、シェル・スクリプトを通じてアーカイブ・ファイルをセキュアなものにすることができます。ただし IDS が提供するような保護レベルの強化を講じることなく、これらのオープンソースのツールを使うのはお勧めできません (Snort の詳細については「参考文献」を参照してください)。
まとめ
この記事では、リモート・サーバー上でスクリプトを実行する方法と、自動化されたセキュアなファイル転送の方法を説明しました。貴重なデータの保護や、OpenSSH や Snort のようなオープンソースのツールを使った新しいソリューションの構築について、皆さんが真剣に考え始められたのであれば幸いです。
参考文献
著者について  | 
| | Carlos JustinianoはEcuity, Incのソフトウェア・アーキテクトです。関心領域は通信や分散コンピューティングで、いくつかの技術雑誌にも寄稿しています。またLinuxベースのChessBrainプロジェクトの設立者兼アーキテクトでもあります。このプロジェクトは分散コンピューティングに関して、2005年のギネス世界記録に認定されています。連絡先はcarlos.justiniano@ecuityinc.comです。 |
記事の評価
| 
