セキュリティは、データベースを実行する上で最も重要な側面の1つです。開発者であろうとDBAであろうと、データベースを管理している場合は、データを保護し、あらゆる種類の不正アクセスからデータを保護する責任があります。残念なことに、2017年9月のMongoDBランサムウェア攻撃の新しい波からわかるように、多くの組織がデータを保護していません。以前、MongoDBデータベースを保護する方法に関するブログを公開しました。
このブログ投稿では、ClusterControlを使用してデータベースを保護する方法について説明します。ここで説明するすべての機能は、ClusterControlのバージョン1.5.1（2017年12月23日にリリース）で利用できます。一部の機能は特定のデータベースタイプでのみ使用できることに注意してください。
バックアップ暗号化
ClusterControl 1.5.1では、バックアップ暗号化と呼ばれる新機能が導入されました。暗号化されたすべてのバックアップには、横に鍵のアイコンが付いています：
この機能は、ClusterControlでサポートされているすべてのバックアップ方法（mysqldump、xtrabackup、mongodump、pg_dump）で使用できます。暗号化を有効にするには、バックアップをスケジュールまたは作成するときに[暗号化を有効にする]スイッチをオンにするだけです。 ClusterControlは、バックアップを暗号化するためのキーを自動的に生成します。 AES-256（CBC）暗号化アルゴリズムを使用し、ターゲットサーバーでオンザフライで暗号化を実行します。次のコマンドは、ClusterControlがmysqldumpバックアップを実行する方法の例を示しています。
$ mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --no-create-info --no-data --triggers --routines --events --single-transaction --skip-comments --skip-lock-tables --skip-add-locks --databases db1 | gzip -6 -c | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-094508-e0bc6ad658e88d93.tmp | socat - TCP4:192.168.55.170:9999'最初に適切なキーで復号化せずに暗号化されたバックアップを解凍しようとすると、次のエラーが表示されます。
$ gunzip mysqldump_2018-01-03_175727_data.sql.gz
gzip: mysqldump_2018-01-03_175727_data.sql.gz: not in gzip formatキーはClusterControlデータベース内に保存され、特定のバックアップセットのcmon_backup.metadataファイルから取得できます。これは、復元を実行するときにClusterControlによって使用されます。バックアップを暗号化することを強くお勧めします。特に、バックアップをクラウドにアーカイブするなど、オフサイトで保護する場合はそうです。
MySQL/PostgreSQLクライアントサーバー暗号化
展開中に推奨されるセキュリティ手順に従う以外に、クライアントサーバーSSL暗号化を使用してデータベースサービスの信頼性を高めることができます。 ClusterControlを使用すると、簡単なポイントアンドクリックでこの操作を実行できます：
次に、生成されたキーと証明書を
データベースレプリケーションの暗号化
ガレラクラスター内のレプリケーショントラフィックは、ワンクリックで有効にできます。 ClusterControlは、ClusterControlノードで生成された2048ビットのデフォルトキーと証明書を使用します。これは、すべてのGaleraノードに転送されます。
クラスタの再起動が必要です。 ClusterControlは、一度に1つのノードを使用して、ローリングリスタート操作を実行します。暗号化を有効にすると、[概要]ページの[ホスト]グリッドのデータベースサーバーの横に緑色のロックアイコンが表示されます（GaleraはGalera Replication暗号化を示し、SSLはクライアントサーバー暗号化を示します）。
さらに下で説明するように、すべてのキーと証明書はキー管理の下で直接管理できます。
キー管理
生成されたすべてのキーと証明書は、ClusterControlUIから直接管理できます。キー管理を使用すると、クラスターにプロビジョニングできるSSL証明書とキーを管理できます。
証明書の有効期限が切れている場合は、UIを使用して、適切なキーと認証局（CA）を使用して新しい証明書を生成するか、既存のキーと証明書をClusterControlホストにインポートできます。
セキュリティアドバイザー
アドバイザは、ClusterControlで実行されるミニプログラムです。特定のタスクを実行し、パフォーマンス、セキュリティ、ログ管理、構成、ストレージスペースなどの領域の問題に対処する方法についてアドバイスを提供します。各アドバイザはcronジョブのようにスケジュールでき、ClusterControlUI内でスタンドアロンの実行可能ファイルとして実行できます。 ClusterControlの「s9s」コマンドラインクライアントを介して実行することもできます。
ClusterControlは、MySQLベースのシステムに対して2つのセキュリティアドバイザーを有効にします。
- 任意のホストからのアクセス（'％'）-mysqlシステムテーブルからワイルドカードホストを使用するすべてのユーザーを識別し、サーバーに接続できるホストをより詳細に制御できるようにします。
- パスワードなしのアカウント数を確認する-mysqlシステムテーブルにパスワードを持たないすべてのユーザーを識別します。
MongoDBには、次のアドバイザーがいます。
- MongoDB認証が有効になっている-MongoDBインスタンスが認証モードを有効にして実行されているかどうかを確認します。
- 承認チェック-MongoDBユーザーがアクセス制御に対して許容度の高い役割で承認されているかどうかを確認します。
ClusterControlがセキュリティチェックを実行する方法の詳細については、
複数のネットワークインターフェース
データベースホストに複数のNICを配置すると、データベーストラフィックを管理トラフィックから分離できます。 1つのネットワークは、相互に通信するためにデータベースノードによって使用され、このネットワークはパブリックネットワークに公開されません。もう1つのネットワークは、管理目的でClusterControlによって使用されます。 ClusterControlは、このようなマルチネットワーク設定を展開できます。次のアーキテクチャ図を検討してください。
上記のデータベースクラスターをClusterControlにインポートするには、データベースホストのプライマリIPアドレスを指定します。次に、データネットワークだけでなく管理ネットワークも選択できます。
ClusterControlは、データベースがパブリックネットワークから完全に分離されているため、インターネットにアクセスできない環境でも機能します。機能の大部分は問題なく動作します。 ClusterControlホストがインターネットで構成されている場合は、インターネットのないデータベースサーバー用にデータベースベンダーのリポジトリのクローンを作成することもできます。
ミラーリングには、インターネット接続によっては約10〜20分かかる場合があります。新しいアイテムは、後でリストに表示されます。その後、データベースホストがインターネットに接続していなくても、新しいクラスターをスケーリングまたはデプロイするときに、代わりにこのリポジトリを選択できます（オペレーティングシステムのオフラインリポジトリも配置する必要があることに注意してください）。
MySQLユーザー管理
MySQL特権システムにより、すべてのユーザーが許可されている操作のみを実行できるようになります。すべてのユーザーにデータベースへの完全なアクセスを許可したくないため、付与は重要ですが、クエリを実行して日常のタスクを実行するために必要な権限をユーザーに付与する必要があります。
ClusterControlは、データベーススキーマと特権を管理するためのインタラクティブなユーザーインターフェイスを提供します。クラスタ内のすべてのMySQLサーバーのアカウントを統合し、付与プロセスを簡素化します。データベースユーザーを簡単に視覚化できるため、間違いを防ぐことができます。
上のスクリーンショットでわかるように、データベース（shopdb）にユーザーを付与するだけの場合、ClusterControlは不要な特権をグレー表示します。 「SSLが必要ですか？」特定のデータベースが定義されている場合、管理者権限のチェックボックスが完全に無効になっているときに、クライアント/サーバーのSSL暗号化が有効になっている場合にのみ有効になります。ウィザードの下部で生成されたGRANTステートメントを調べて、ClusterControlがこのユーザーを作成するために実行するステートメントを確認することもできます。このヘルパーは非常に単純に見えますが、ユーザーの作成と特権の付与はエラーが発生しやすい可能性があります。
ClusterControlは、クラスター内のすべてのデータベースノードの非アクティブなユーザーのリストも提供し、最後のサーバーの再起動以降に使用されていないアカウントを示します。
これは、サーバーに害を及ぼす可能性のある不要なアカウントが存在することを管理者に警告します。次のステップは、アカウントがアクティブでなくなったかどうかを確認することです。アカウントを削除するには、[選択したユーザーを削除]オプションを使用するだけです。 ClusterControlによって生成されたリストが正確であることを確認するために、十分なデータベースアクティビティがあることを確認してください。サーバーの稼働時間が長いほど、優れています。
常に最新の状態に保つ
本番環境で使用する場合は、ベンダーのリポジトリからデータベース関連のパッケージをインストールすることを強くお勧めします。パッケージが通常古くなっているデフォルトのオペレーティングシステムリポジトリに依存しないでください。 Galera ClusterやMySQLレプリケーションなどのクラスター環境で実行している場合は、常に最小限のダウンタイムでシステムにパッチを適用することができます。
ClusterControlは、シングルクリックでMySQL/MariaDBの自動マイナーバージョンローリングアップグレードをサポートします。
メジャーバージョンのアップグレード（たとえば、MySQL5.6からMySQL5.7へ）は意図的に自動化されていません。メジャーアップグレードでは通常、既存のパッケージをアンインストールする必要がありますが、これは自動化するのにリスクの高い作業です。このような種類のアップグレードには、慎重な計画とテストが必要です。
データベースのセキュリティは、データベースを本番環境で実行する上で重要な側面です。私たちがニュースで頻繁に読んだすべての事件から（そしておそらく公表されていない他の多くの事件があります）、悪意を持って忙しいグループがそこにあることは明らかです。したがって、データベースが十分に保護されていることを確認してください。