この現在のプロジェクトでは、DBをダンプし、暗号化して、s3にプッシュする必要があります。そのようなタスクの「ベストプラクティス」は何でしょうか。今のところ、私はかなり単純な方法を使用していますが、セキュリティが関係するいくつかのより良いアイデアが欲しいです。これが私のスクリプトの始まりです:
mysqldump -u root --password="lepass" --all-databases --single-transaction > db.backup.sql
tar -c db.backup.sql | openssl des3 -salt --passphrase foopass > db.backup.tarfile
s3put backup/db.backup.tarfile db.backup.tarfile
# Let's pull it down again and untar it for kicks
s3get surgeryflow-backup/db/db.backup.tarfile db.backup.tarfile
cat db.backup.tarfile | openssl des3 -d -salt --passphrase foopass |tar -xvj
明らかに問題は、このスクリプトが攻撃者が地獄を上げるために必要なすべてのものであるということです。
このタスクについての考え、批評、提案はありがたいです。
まず、攻撃者がバックアップスクリプトにアクセスした場合に、問題のデータベースに対する読み取り専用のアクセス許可を持つ「ユーザー」をmysqlに作成できます。これにより、潜在的な破壊的損害が軽減されます。
次に、バックアップを圧縮する前または後に、バックアップでgpg
またはpgp
暗号化を使用できます。これは、公開鍵を使用して、パスワードを入力しなくても実行できます。
そしてもちろん、あなたはchmod 700 backupscript.sh
他人があなたのパスワードを読まないようにするため。
パスワードなしのデータベーススナップショットを作成する方法は他にもあるかもしれませんが、頭から離れていることに気づいていません。
gpg
またはpgp
は、パスワードなしで実行できるため、前述のopenssl
メソッドの優れた代替手段のようです。
#!/bin/sh
touch db.backup.sql.gz
chmod 600 db.backup.sql.gz
mysqldump -u nonprivuser --password="pass" --all-databases --single-transaction | gzip > db.backup.sql.gz
gpg -e -r [email protected] db.backup.sql.gz && rm -f db.backup.sql.gz
s3put backup/db.backup.sql.gz.gpg db.backup.sql.gz.gpg
スクリプト内でパスワードを使用することは、ps aux
で確認でき、すべてのシステムユーザーが読み取ることができるため、非常に悪い考えです。
mysqldump-secure を調べることをお勧めします。これは、公開鍵と秘密鍵の暗号化に基づいてopenssl
暗号化を実行するシェルスクリプトであり、gpgよりもはるかにパフォーマンスが高くなります。