MySQLデータのセキュリティを確保するための提案

データは企業の中核資産であり、企業にとって最も重要なタスクの 1 つです。注意しないと、データが意図せず漏洩したり、ハッカーによって悪意を持って盗まれたりするリスクが高くなります。毎年、業界では有名企業や無名の企業がハッキングされる（データベース全体がハッカーに盗まれることを意味する「拖库」の同音異義語）などの重大な事件が数件発生しています。

データセキュリティの観点からは、外部ネットワークセキュリティと内部運用セキュリティに分けることもできます。これについては後述します。

内部運用セキュリティポリシー

1. すべてのDBA権限を取り消すかどうか

DBA に権限がない場合、日常的な DB の運用と保守作業、および緊急時のトラブルシューティングをどのように実行できるでしょうか?したがって、成熟した自動運用保守プラットフォームが確立されるまでは、DBA の権限を乱暴に取り消さないことが推奨されます。そうしないと、作業効率が低下し、DBA が不信感を抱くという否定的な感情を抱く可能性があります。

2. MySQLレイヤーのセキュリティ戦略

• ビジネス アカウントはイントラネット経由でのみリモート ログインでき、パブリック ネットワーク経由でリモート接続することはできません。
• 専用の管理プラットフォーム サーバーからのリモート接続を許可する運用保守プラットフォーム アカウントを追加します。もちろん、管理プラットフォームが展開されているサーバーには、セキュリティ対策と必要なセキュリティ監査戦略を実装する必要があります。
• データベース監査機能を有効にすることをお勧めします。これには、MySQL Enterprise Edition または Percona/MariaDB ブランチ バージョンを使用する必要があります。MySQL Community Edition ではこの機能はサポートされていません。
• WHERE 条件なしでテーブル全体が変更されるのを防ぐには、safe-update オプションを有効にします。
• アプリケーションで DELETE を使用してデータを直接削除するのではなく、フラグを設定するだけにしてください。削除が本当に必要な場合は、誤ってすべてのデータを削除しないように、まず DBA にデータをバックアップさせてから物理的に削除してもらいます。
• トリガーは、ハッカーによる悪意のあるデータの改ざんを防ぐなどの補助機能を実行するためにも使用できます。
  

3. MySQLアカウントの権限ルール

• ビジネス アカウントの場合、権限は最小限に抑えられており、DROP 権限と TRUNCATE 権限は厳しく禁止されています。
• デフォルトでは、ビジネス アカウントには、選択、更新、挿入、削除、実行などの通常の DML に必要な権限のみが付与され、その他の権限は付与されません。
• MySQL が初期化されたら、不要なアカウントと匿名テスト データベースを削除します。

mysql> mysql.user から削除 (user!='root' または host!='localhost'); 権限をフラッシュします。mysql> データベース テストを削除します。

• SELECT 権限のみを持つ専用のバックアップ アカウントを作成し、ローカル コンピューターからのログインのみを許可します。
• 長さや複雑さなど、MySQL アカウントのパスワード セキュリティ ポリシーを設定します。
  

4. データのバックアップについて

システムがクラッシュして修復できない場合は、完全なデータ バックアップを作成することが最後の手段であることを忘れないでください。

バックアップ データは、データ監査やデータ ウェアハウスからデータ ソースを取得するためにも使用できます。

一般的に言えば、バックアップ戦略は次のようになります。1 日に 1 回完全バックアップを実行し、定期的に binlog の追加バックアップを実行するか、binlog サーバー メカニズムを直接使用して binlog を他のリモート ホストに転送します。フルバックアップ + binlog を使用すると、必要に応じて任意の時点に復元できます。

特別な注意: xtrabackup ストリーミング バックアップを使用する場合は、バックアップ データが悪意を持って傍受されるのを防ぐために、暗号化された送信を使用することを検討してください。

外部ネットワークセキュリティ戦略

実際、オペレーティング システムのセキュリティとアプリケーションのセキュリティは、データベース自体のセキュリティ ポリシーよりも重要です。同様に、アプリケーションとそのサーバーのシステム セキュリティも非常に重要です。多くのデータ セキュリティ インシデントは、コードの脆弱性を介してアプリケーション サーバーに侵入し、データベースを調査し、最終的にデータベースを削除することによって引き起こされます。

1. オペレーティング システムのセキュリティに関する推奨事項

• MySQL を実行する Linux は内部ネットワークでのみ実行し、パブリック ネットワークに直接公開することは許可されません。パブリック ネットワークから接続する必要がある場合は、ジャンプ サーバーを介してポート転送を行う必要があります。また、前述のように、データベース アカウントの権限レベルは厳密に制限する必要があります。
• すべてのシステム アカウントは SSH キー ベースの認証に変更されており、リモート パスワード ログインは許可されておらず、相対的なセキュリティを確保するために SSH キーのアルゴリズムと長さに関する要件があります。この方法では、個人の秘密鍵が盗まれない限り、パスワードが失われるリスクはありません。
• さらに、すべてのサーバーに対して PAM 認証を有効にして、より便利で安全な統合アカウント管理を実現することもできます。
• 不要なシステム サービスをシャットダウンし、mysqld、sshd、ネットワーク、crond、syslogd などの必要なプロセスのみを実行し、その他はすべてシャットダウンします。
• root アカウントによるリモート ログインは禁止されています。
• mysqld などの一般的なビジネス サービス プロセスを開始するために root アカウントを使用することは禁止されています。
• sshd サービスのポート番号を 10000 以上に変更することをお勧めします。
• パフォーマンスに影響を与えずに、MySQL サービス ポートのファイアウォール ポリシーを有効にしてみてください (同時実行性が高い場合、iptables の使用はパフォーマンスに影響を与える可能性があるため、代わりに ip route ポリシーを使用することをお勧めします)。
• GRUB にパスワードを設定する必要があり、物理サーバー上の Idrac/imm/ilo などのアカウントのデフォルト パスワードも変更する必要があります。
• システムにログインする必要があるすべての従業員は、パブリック アカウントではなく独自のプライベート アカウントを使用します。
• システムレベルの操作監査を有効にしてすべての ssh ログを記録するか、bash を使用して対応する操作コマンドを記録してリモート サーバーに送信し、対応するセキュリティ監査を実行して安全でない操作をタイムリーに検出する必要があります。
• MySQL およびその他のデータベース サービスのディレクトリ権限を正しく設定します。すべての権限を 755 に設定しないでください。通常は 750 で十分です。
• 要塞ホストの導入を検討できます。リモート サーバーへのすべての接続は、まず要塞ホストを経由する必要があり、すべての操作記録と監査機能は要塞ホストで実装できます。
• スクリプトの暗号化は、セキュリティの向上にはあまり役立ちません。経験豊富なハッカーであれば、システムログイン権限を持っている限り、権限の昇格などの方法で簡単にルート権限を取得できます。

2. アプリケーションセキュリティの推奨事項

• Web サーバーの自動インデックス設定を無効にします。
• 組織の観点から、内部 IP、アカウント、パスワードの漏洩のリスクが高いため、従業員が外部の GitHub にコードをアップロードすることは禁止されています。コードをアップロードする必要がある場合は、まずセキュリティ レビューを受ける必要があります。
• コード セキュリティ監査を実施したり、事前にセキュリティ戦略を準備したりしていない限り、パブリック インターネット上のオープン ソース CMS、ブログ、フォーラム、その他のシステムを使用しないでください。このようなシステムは通常、ハッカーの研究の焦点となっており、ハッキングされやすいです。
• Web サーバー層では、nginx の WAF モジュールなどのセキュリティ モジュールを使用できます。
• アプリ サーバー レイヤーでは、コード セキュリティ監査とセキュリティ スキャンを実行して、XSS 攻撃、CSRF 攻撃、SQL インジェクション、ファイル アップロード攻撃、Cookie 検出のバイパスなどのセキュリティ脆弱性を防ぐことができます。
• JDBC 接続文字列の構成など、アプリケーションでアカウント パスワードが関係する場合は常に、プレーン テキスト パスワードを暗号化された形式で保存し、使用前に内部のプライベート復号化ツールを使用して復号化するようにしてください。あるいは、アプリケーションが最初に中間アカウントを使用してプロキシ レイヤーに接続し、次にプロキシを使用して MySQL に接続できるようにすることで、アプリケーション レイヤーが MySQL に直接接続することを回避することもできます。
  

最後に、どんな優れたセキュリティ戦略も、社内の従業員のセキュリティ意識ほど重要ではないということを申し上げたいと思います。過去には、社員のパソコンが誤って感染し、イントラネットのデータが盗まれたという事例もありました。

安全は軽視できない問題であり、誰もがそれを念頭に置く必要があります。データ セキュリティに関しては、利便性をある程度犠牲にすることはできますが、犠牲にしすぎると、得られる利益が損失を上回らない可能性があります。

上記は、MySQL データのセキュリティを確保するためのいくつかの提案の詳細です。MySQL セキュリティの提案の詳細については、123WORDPRESS.COM の他の関連記事をご覧ください。