今日、IT全体でセキュリティが最も重要です。時折、セキュリティで保護されていないデータベースやITインフラストラクチャに起因するランサムウェア攻撃やデータ漏洩について耳にします。あなたは疑問に思うかもしれません：あなたがあなたのデータについて安全であると感じることができるようにMySQL環境を設計する際のベストプラクティスは何ですか？もしそうなら、このブログはあなたのためです。このトピックについては完全には取り上げないことに注意してください。これは、ブログよりもホワイトペーパーに収まります。 MySQLデータベースを保護するための最も重要な側面について言及するために最善を尽くします。このブログの背後にある考え方は、読者が自分の知らないことを知り、さらなる調査のためにトピックとキーワードを特定するのに役立つようにすることです。これを、データベースセキュリティに関する機能を含む、膨大な機能セットを備えた当社の製品であるClusterControlのスクリーンショットで説明します。
まず、MySQLをどこかにデプロイする必要があります。スタンドアロンインスタンス、プライマリ-レプリカ非同期レプリケーション、またはGaleraやInnoDBClusterなどのより高度な同期レプリケーショントポロジの1つです。それが何であれ、ネットワークレベルで保護する必要があります。データベースには、非常に一般的に、組織全体の最も価値のある資産であるデータが含まれています。
もちろん、それはすべて正確な設定に依存しますが、アプリケーション、プロキシ、キャッシュ、データベースの各レイヤーがある最も一般的なケースでは、最も一般的な設定はプロキシのみが可能である必要がありますデータベースにアクセスします。他のすべてのエンティティは、プロキシ層を介してのみデータベースにアクセスするように構成する必要があります。このデザインは多くの点で優れています。セキュリティの強化に加えて、データベース層の複雑さをアプリケーションから隠すのにも役立ちます。
プロキシ層はデータベーストポロジに従う必要があり、データベースノードの障害とトポロジの変更を処理する必要があります。プロキシ層に接続するアプリケーションは、要求のタイプに関連する動作中のデータベースノードに常に到達できる必要があります。キャッシュレイヤーについても同様です。プロキシレイヤーに実装できます。ProxySQLなどの一部のプロキシではプロキシ内でのキャッシュリクエストが許可されますが、memcacheやRedisなどの独立したレイヤーである場合は、常にプロキシレイヤーを介してデータベースにアクセスする必要があります。
データベース層に直接アクセスする必要があるもう1つのタイプのノードは、管理ノードです。これは、運用チームがデータベースを管理するために使用するノードです。理由は単純です。一部の保守タスクでは、データベースへの直接アクセスが必要になる場合があります。それは、タスク自動化スクリプト、データベースフリート全体にわたるAnsibleプレイブックのローリング、またはその他のタスクである可能性があります。その場合、明らかに、アクセス権を持つユーザーだけがそのような管理ノードにログインできるようにするためのセキュリティ対策を講じる必要があります。
データベースへのアクセスを必要とする可能性のある別の可能なタイプのノード（管理ノードも使用できます）は、メトリックの収集とユーザーへの提示に関与するノードです。ここでは、監視について説明しています。およびアラートアクティビティ。
VPN
複数のデータセンターにまたがるあらゆる種類のデータベース層については、VPNを使用してそれらを接続することを検討する必要があります。 WANネットワークを介したオープンで暗号化されていない接続は、決して発生してはならないものです。 SSL暗号化を設定することでさえ、データベース層とWAN間のアクセスを開く必要があるため、最善のオプションではありません。データベースノード間のSSL接続では、直接接続できる必要があります。 VPNは、データベース層ネットワークのセグメントを接続する安全な方法を作成する仲介者を追加することで、この問題を解決します。
VPNは、ワークステーションと本番ネットワークの間に安全な接続を実装するため、組織のネットワークへのあらゆる種類のユーザーアクセスにも必須です。
もちろん、ネットワークを保護する際には、ファイアウォールの使用を検討する必要があります。一般的に、すべてのデータベースノードは、定義されたソースのセット（ホスト名とポート）からの接続のみを受信する必要があります。 「必要な」ネットワークセグメントでさえ、データベースネットワークへのフルアクセスではなく、必要なポートへのアクセスのみを持つ必要があります。プロキシがデータベースポートに接続するだけでよい場合、データベースノード上の他のポートにアクセスできる理由はありません。また、デフォルトのポートは使用しないでください。明らかに、隠すことによるセキュリティです。結局のところ、ポートはどこかで開いていますが、自動化されたスクリプトを使用するセキュリティ侵入の少なくとも一部に対処するのに役立ちます。アクセスを取得しようと決心した人を防ぐことはできませんが、自動攻撃の成功を防ぎながら、（ポートスキャンの検出とアンチスキャン対策と組み合わせて）速度を落とす可能性があります。
ネットワークは防御の最前線であり、セキュリティをさらに向上させるために使用できる他のセキュリティ対策とグッドプラクティスがあります。それらのいくつかは、データベース自体に実装できます。
データベース自体を使用して、アクセス制御と制限を実装できます。手始めに、ホストベースのアクセス制御を実装して、ノードの短いリスト以外のホストがデータベースにログインするのを防ぐことができます。もちろん、ファイアウォールを使用してアクセスを制限した場合、これは重複しているように聞こえるかもしれませんが、データベース自体へのアクセスを制限することをお勧めします。誤ってファイアウォールが無効になる時期はわかりません。このような場合でも、第2層の保護があります。
ここで実装するのは、データベースへのアクセスを許可されているデータベースユーザーとホストのリストです。ほとんどの場合、最終的に必要なのは、プロキシ層にあるホストからのアクセスを許可された1人以上のユーザーです。どの程度詳細なアクセス制御を使用できるかは、使用しているデータベースシステムによって異なります。たとえば、MySQLでは、ネットワークマスクを詳細に制御することはできません。使用するのは、/ 32、/ 24、/ 16、または/8だけです。一方、PostgreSQLでは、あらゆる種類のネットワークマスクを使用できます。
これがデータベースで許可されている場合は、各ユーザーに一連の付与を定義する必要があります。ユーザーに割り当てられた権限が、ユーザーが実行する必要のあるアクションを実行するために最低限必要なものであることを確認してください。 。データベースシステムには、さまざまな特権のセットとさまざまなレベルの特権がある場合があります。通常、いくつかのレベルの特権があります-グローバル、データベースサーバー全体に影響を与える、スキーマレベル-与えられたユーザーは、異なるスキーマに異なる特権を割り当てることができます。テーブルレベルまたは列レベルでさえ特権を持つことができます。前に述べたように、目標はすべてのユーザーに最小限の特権のセットを作成することです。おそらく、高い特権を持つユーザーが少なくとも1人は必要になるでしょう。これは、データベースの管理に使用されます。このようなユーザーは、接続に関しては厳しく制限する必要があります。どの場所からでも接続を許可しないでください（実際にはどちらのユーザーも許可しないでください）。データベースでの操作の実行専用のローカルホストまたは特定の管理ノードである必要があります。
データベース内のすべてのユーザーには、パスワードを定義する必要があります。これは簡単です。パスワードはハッシュ形式で保存する必要があります。パスワードを保存するために、データベースが提供する最も安全なハッシュアルゴリズムを使用していることを確認する必要があります。パスワードは簡単に推測できるものであってはならず、辞書攻撃に対して脆弱であってはなりません。 MySQLなどの一部のデータベースシステムでは、パスワードを使用するためにパスワードが満たす必要のある要件を正確に定義できます。小文字と大文字、数字、特殊文字、パスワードの長さ-これらすべてが重要であり、パスワードの強度に関するポリシーを適用できる場合は、それを実行する必要があります。もう1つの重要な点は、パスワードのローテーションです。パスワードは一度作成しないでください。データベースの存続期間中は、パスワードローテーションポリシーを設定する必要があります。繰り返しになりますが、一部のデータベースシステムでは、これを強制できます。管理ユーザーは、パスワードローテーションを適用して新しいユーザーアカウントを作成できる場合があります。また、特定のユーザーにパスワードローテーションを適用できる場合もあります。
一部のデータベースシステムは監査ログを提供します。アイデアは、データベース内のアクティビティに関するできるだけ多くの情報を収集することです。誰がいつ何をしましたか？どのクエリが誰によって実行されましたか？ログインしようとしたが失敗したのは誰ですか？どのホストから？理想的には、そのような情報を含むログはデータベースノードの外部に保存されます。それらを中央のログサーバーにストリーミングして、保管、さらなる処理、およびより優れた検索機能を実現できます。
SQLセキュリティ
ユーザーとホストについて説明しましたが、攻撃は別のソースから発生する可能性もあります。アプリケーションが適切に保護されておらず、入力が正しく検証されていない場合、Webサイトから発信された攻撃に直面している可能性があります。ここではSQLインジェクションについて話しています。このような場合、クエリが有効なソース（Webサーバー、次にプロキシノード）から発信されていることを考えると、ファイアウォールはあまり役に立ちません。助成金を割り当てることは、実際にはこの種の攻撃の一部を防ぐのに役立つ場合がありますが、理想的な解決策ではありません。すべてのアプリケーションでは、ほとんどの場合、データベースのコンテンツを削除または変更できるユーザーが必要になります。このようなユーザーは、悪用されると、危害を加えるために使用される可能性があります。御馳走に対抗するために試みることができるいくつかの方法があります。
SQLファイアウォール
これを行う最も簡単な方法は、SQLファイアウォールを実装することです。それは、さまざまなレベルでさまざまな場所で達成できます。オプションの1つは、そのためにロードバランサーを使用することです。それらのいくつかは、まだ実装されていない場合でも、少なくとも簡単に達成できるこの機能を備えています。その背後にある考え方は、アプリケーションが実行するクエリのリストを作成し、この種類のトラフィックのみを通過するようにプロキシを構成することです。新しいクエリを追加したり、使用されなくなった古いクエリを削除したりする必要があるため、理想的ではありません。一方、このような一連のルールは、許可されていないクエリがデータベースに到達するのを防ぎます。
SQLインジェクションの検出
もう1つの可能なオプションは、プロキシ層にSQLインジェクション検出を実装することです。いくつかのソリューションがあります。特にProxySQLは、それらを通過するトラフィックでSQLインジェクションを検出するように構成できます。もちろん、すべてヒューリスティックに基づいているため、誤検知が発生する可能性がありますが、SQLファイアウォールに追加することもできます。
これまで、ClusterControlからデプロイできるロードバランサーであるProxySQLを使用してSQLファイアウォールとSQLインジェクション検出を実装する方法について説明しました。
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
最後に、データのセキュリティ。これまで、データベースを強化する方法、データベースへのアクセスを制限する方法、およびアプリケーション自体からのさまざまな種類の攻撃を防ぐ方法について説明してきました。それでも、データ自体の保護を検討する必要があります。これは複数のレイヤーを持つことができます。物理的セキュリティ-データセンターを所有している場合は、適切にロックダウンされていることを確認してください。外部ISPまたはクラウドプロバイダーを使用する場合は、ハードウェアへのアクセスに関して、適切なセキュリティプロトコルが設定されていることを確認してください。次に、サーバー、VM、または使用している方法があります。データはディスク上にあり、サーバーにローカルに保存されます。データは、アプリケーション、プロキシ、およびデータベース間で転送されています。データは、レプリケーションによってデータベースノード間で転送されます。データはバックアップとしてオフサイトに保存されています。このデータは保護する必要があります。
最後に、データベースノードに保存されているデータ自体。また、暗号化する必要があります。このトピックに取り組むときに使用できる方法がいくつかあります。まず、ホストレベルでの暗号化。データベースにデータディレクトリがあるボリュームは、暗号化（および起動時に復号化）できます。データベースには暗号化機能も備わっている傾向があります。暗号化できるものは、正確なソリューションとデータベースのタイプとバージョンによって異なりますが、場合によっては、オプションが非常に広範囲に渡ります。テーブルスペースの暗号化、ログの暗号化、場合によってはメモリ内構造の暗号化。適切に行うと、データベースノードにアクセスするだけではデータにアクセスできなくなります。
前述のように、このブログはデータベースセキュリティの実践的なガイドを目的としたものではありませんが、データベース環境を設計する際に考慮すべき側面の大部分に触れました。このガイドが役立ちます。