生産中のMySQL/PHPアプリケーションのバックアップとセキュリティに関する考慮

Question

1）最も重大なセキュリティ上の考慮事項は何ですか？私は、暗号化/ https、アクセスする必要のない機密データを暗号化してデータを安全に保管したり、phpmyadminにアクセスするためのファイアウォールを設定したり、ルートパスワードを変更したりなど、私は「すべての箱をチェックした」ということを確信していません。 mysql/phpアプリケーションをどこかに確保するための堅牢なガイドがありますか？おそらくペンテストはある程度の自信を得るための唯一の方法でしょうか？

2）バックアップの考慮事項を教えてください。 2つの異なるデータセンターにあるmysqlデータベースと、本番サーバー自体の毎週のバックアップに、マスター/スレーブの関係が設定されています。コードはすべてソース管理されていますが、バックアップ後に6日目にすべてがクラッシュした場合に失うと思われるアップロード済みのドキュメントがいくつかあります。そのアイデアは何ですか？ドキュメントストレージを別のサーバーに移動して夜間にバックアップすること、または最初のアップロード時にドキュメントを2つの別々のサーバーに非同期で保存することを検討してください。彼らは大きなドキュメントではなく、ボリュームはまだ高くはありませんが、それはスケーラブルですか？

Answer 1

は、私は、暗号化/ HTTPS

それはあなたが行っているどこまでこのことから、本当にはっきりしていないと輸送中のデータを確保してきたように感じるので、あなたはすでに次のように対処している場合は、私を許して。

明らかに、httpsはクライアントとウェブサーバーの間のデータ転送を確実にしますが、アプリケーションとデータベース間の暗号化された接続と混同しないでください。確かに、ここで傍受されるデータのリスク要因ははるかに低いですが、データの機密性によって異なります。暗号化されたデータベース接続の設定に関する情報はhereです。データセンター間で複製する場合は、setting up replication to use encrypted connectionsも考慮する必要があります。

レプリケーションとバックアップは同じではありません。マスターからスレーブにデータをレプリケートしたら、スレーブをバックアップする必要があります。 mysqldumpを使用することができますが、警告はmysqldumpです。物理的なものではなく論理的なバックアップを作成するので、復元機能が遅く、スケーラビリティには向いていません。代わりに、物理バックアップを作成するためのソリューションを提供する良い投稿hereがあります。

• は、その機能を実行するために必要なアクセス許可の 最小レベルのプロセスごとに別々のユーザーアカウントを作成して割り当てます。別にあなたが任意のシステムで実装する必要がありますセキュリティ対策の通常の種類があることから、

  。

• 一般的な管理者タイプのユーザー名で管理者アカウントを作成します。 rootアカウントとあなたは再びそれを解読できるようにする必要がある場合にのみ、データの暗号化などadmin
• よう をpwned取得する可能性がある他のものを削除します。塩 とハッシュに敏感なデータは、確認のためにのみ必要です （パスワードなど）と結果の値をデータベースに保存します。ハッシュに対してユーザー入力を検証します。
  • /etc/mysql/my.cnfであなたに bind-address = 127.0.0.1
  • 無効にロードするファイルを追加することにより、ローカルマシン以外の場所から の接続を禁止することができますのmysqldセクション内：あなたも考えるかもしれあなたのユースケースによっては

  MySQLはローカルファイルシステムから ファイルレベルの特権なしで追加することによってlocal-infile=0

• 一般的なデータベース作業のための。これらは、 にはいくつかの利点がありますが、いくつかの欠点もありますが、 のセキュリティの観点からは、 ストアドプロシージャのユーザーアカウントのアクセス許可を与えることができ、利用するテーブル にアクセス許可を付与する必要はありません。
• database viewsを使用して、 テーブル内の一部のカラムへのアクセスを制限しながら、同じ テーブル内の他のカラムへのアクセスを許可します。ストアドプロシージャと同様に、ビューの長所と短所があります。

MySQLを理解している人が私よりもずっと優れていると思う人がいるかもしれませんが、考えていなくてもあなたはそれを感じることができます。