sql >> データベース >  >> NoSQL >> MongoDB

ClusterControlサーバーを保護する方法

    以前のブログ投稿では、ClusterControlを使用してオープンソースデータベースを保護する方法を紹介しました。しかし、ClusterControlサーバー自体はどうでしょうか。どうすればそれを確保できますか?これが今日のブログのトピックになります。ホストはClusterControl専用であり、他のアプリケーションは実行されていないと想定しています。

    ファイアウォールおよびセキュリティグループ

    何よりもまず、不要なポートをすべて閉じて、ClusterControlで使用される必要なポートのみを開く必要があります。内部的には、ClusterControlとデータベースサーバーの間では、netcatポートのみが重要であり、デフォルトのポートは9999です。このポートを開く必要があるのは、ClusterControlサーバーにバックアップを保存する場合のみです。それ以外の場合は、これを閉じることができます。

    外部ネットワークからは、ClusterControl UIに対してHTTP(80)またはHTTPS(443)のいずれかへのアクセスのみを開くことをお勧めします。 「s9s」と呼ばれるClusterControlCLIを実行している場合は、CMON-TLSエンドポイントをポート9501で開く必要があります。HAProxy、Keepalived、ProxySQLなどのデータベース関連アプリケーションをClusterControlサーバーの上にインストールすることもできます。その場合、これらにも必要なポートを開く必要があります。各サービスのポートのリストについては、ドキュメントページを参照してください。

    ClusterControlノードでiptablesを介してファイアウォールルールを設定するには、次の手順を実行します。

    $ iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
    $ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
    $ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
    $ iptables -A INPUT -p tcp --dport 9501 -j ACCEPT
    $ iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

    上記は最も単純なコマンドです。たとえば、ネットワークインターフェイス、宛先アドレス、送信元アドレス、接続状態などを追加することで、セキュリティポリシーに従うようにコマンドを厳密にし、拡張することができます。

    クラウドでセットアップを実行するのと同様に、以下はAWS上のClusterControlサーバーのインバウンドセキュリティグループルールの例です。

    クラウドプロバイダーが異なれば、セキュリティグループの実装も異なりますが、基本的なルールは似ています。

    暗号化

    ClusterControlは、さまざまなレベルでの通信の暗号化をサポートし、自動化、監視、および管理タスクが可能な限り安全に実行されるようにします。

    HTTPSで実行

    インストーラースクリプト(install-cc.sh)は、デフォルトでHTTPSを使用するための自己署名SSL証明書を構成します。このアクセス方法をメインエンドポイントとして選択すると、ポート80で実行されているプレーンHTTPサービスを外部ネットワークからブロックできます。ただし、ClusterControlには、ローカルホストのポート80でデフォルトで実行されるCMONAPI(レガシーRest-APIインターフェイス)へのアクセスが必要です。 HTTPポート全体をブロックする場合は、クラスター登録でClusterControlAPIのURLを変更してください。 代わりにHTTPSを使用するページ:

    ClusterControlによって構成された自己署名証明書の有効期間は10年(3650日)です。次のコマンド(CentOS 7サーバーの場合)を使用して、証明書の有効性を確認できます。

    $  openssl x509 -in /etc/ssl/certs/s9server.crt -text -noout
    ...
            Validity
                Not Before: Apr  9 21:22:42 2014 GMT
                Not After : Mar 16 21:22:42 2114 GMT
    ...

    証明書ファイルへの絶対パスは、オペレーティングシステムによって異なる場合があることに注意してください。

    MySQLクライアントサーバー暗号化

    ClusterControlは、ClusterControlノードのMySQLデータベース内に監視および管理データを格納します。 MySQL自体がクライアントサーバーSSL暗号化をサポートしているため、ClusterControlはこの機能を利用して、データの書き込みおよび取得時にMySQLサーバーとの暗号化された通信を確立できます。

    この目的のために、次の構成オプションがサポートされています。

    • cmondb_ssl_key --CMONとCMONDB間のSSL暗号化用のSSLキーへのパス。
    • cmondb_ssl_cert --CMONとCMONDB間のSSL暗号化用のSSL証明書へのパス
    • cmondb_ssl_ca --CMONとCMONDB間のSSL暗号化用のSSLCAへのパス

    構成手順については、しばらく前にこのブログ投稿で説明しました。

    ただし、問題があります。執筆時点では、ClusterControl UIには、cmonユーザーを使用してSSLを介してCMONDBにアクセスする際の制限があります。回避策として、Cmonuiと呼ばれるClusterControlUIおよびClusterControlCMONAPI用の別のデータベースユーザーを作成します。このユーザーは、特権テーブルでSSLを有効にしません。

    mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
    mysql> FLUSH PRIVILEGES;

    clustercontrol/bootstrap.phpおよびcmonapi/config /database.phpにそれぞれあるClusterControlUIおよびCMONAPI構成ファイルを、新しく作成されたデータベースユーザーcmonuiで更新します:

    # <wwwroot>/clustercontrol/bootstrap.php
    define('DB_LOGIN', 'cmonui');
    define('DB_PASS', '<cmon password>');
    # <wwwroot>/cmonapi/config/database.php
    define('DB_USER', 'cmonui');
    define('DB_PASS', '<cmon password>');

    パッケージマネージャーを使用してアップグレードを実行しても、これらのファイルは置き換えられません。

    CLI暗号化

    ClusterControlには、「s9s」と呼ばれるコマンドラインインターフェイスも付属しています。このクライアントはコマンドラインオプションを解析し、ポート9500(CMON)または9501(TLSを使用したCMON)でリッスンしているコントローラーサービスに特定のジョブを送信します。後者が推奨されます。インストーラースクリプトは、デフォルトで、ClusterControlサーバーのエンドポイントポートとして9501を使用するようにs9sCLIを構成します。

    役割ベースのアクセス制御

    ClusterControlは、役割ベースのアクセス制御(RBAC)を使用して、クラスターへのアクセスと、それぞれの展開、管理、および監視機能を制限します。これにより、許可されたユーザー要求のみが許可されます。機能へのアクセスはきめ細かく、組織またはユーザーがアクセスを定義できます。 ClusterControlは、権限フレームワークを使用して、ユーザーが許可された後、管理および監視機能と対話する方法を定義します。

    RBACユーザーインターフェースには、 ClusterControl-> User Management-> Access Controlからアクセスできます。 :

    すべての機能は自明ですが、追加の説明が必要な場合は、ドキュメントページを確認してください。

    データベースクラスターの操作に複数のユーザーが関与している場合は、それに応じてユーザーのアクセス制御を設定することを強くお勧めします。複数のチーム(組織)を作成して、それらに0個以上のクラスターを割り当てることもできます。

    カスタムポートでの実行

    ClusterControlは、すべての依存サービスにカスタムポートを使用するように構成できます。 ClusterControlは、SSHをメインの通信チャネルとして使用してノードをリモートで管理および監視し、ApacheはClusterControl UIを提供し、MySQLは監視および管理データを保存します。これらのサービスをカスタムポートで実行して、攻撃ベクトルを減らすことができます。次のポートが通常のターゲットです:

    • SSH-デフォルトは22です
    • HTTP-デフォルトは80です
    • HTTPS-デフォルトは443です
    • MySQL-デフォルトは3306です

    ClusterControlが正しく機能するために、カスタムポートで上記のサービスを実行するには、いくつか変更する必要があります。これについては、ドキュメントページの「カスタムポートでの実行」で詳しく説明しています。

    許可と所有権

    ClusterControl構成ファイルは機密情報を保持しているため、慎重に保護する必要があります。ファイルは、他のユーザーへの読み取り権限なしで、ユーザー/グループルートのみに許可されている必要があります。権限と所有権が誤って設定されている場合、次のコマンドはそれらを正しい状態に復元するのに役立ちます。

    $ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
    $ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf
    

    MySQLサービスの場合、MySQLデータディレクトリのコンテンツが「mysql」グループに許可されていること、およびユーザーが「mysql」または「root」のいずれかであることを確認してください。

    $ chown -Rf mysql:mysql /var/lib/mysql

    ClusterControl UIの場合、所有権はApacheユーザーに許可されている必要があります。RHEL/ CentOSの場合は「apache」、DebianベースのOSの場合は「www-data」です。

    データベースホストに接続するためのSSHキーは、IDを保持し、適切な権限と所有権を保持する必要があるため、もう1つの非常に重要な側面です。さらに、SSHは、リモート呼び出しを開始するときに、セキュリティで保護されていないキーファイルの使用を許可しません。 /etc/cmon.d/ディレクトリの下に生成された構成ファイル内でクラスターによって使用されるSSHキーファイルが、 osuserに許可されるように設定されていることを確認します。 オプションのみ。たとえば、 osuserについて考えてみます。 は「ubuntu」で、キーファイルは/home/ubuntu/.ssh/id_rsa:

    $ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
    $ chmod 700 /home/ubuntu/.ssh/id_rsa

    強力なパスワードを使用する

    インストーラースクリプトを使用してClusterControlをインストールする場合は、インストーラーからのプロンプトが表示されたら、強力なパスワードを使用することをお勧めします。インストーラースクリプトで構成する必要のあるアカウントは最大2つあります(セットアップによって異なります):

    • MySQLcmonパスワード-デフォルト値は「cmon」です。
    • MySQLルートパスワード-デフォルト値は「password」です。

    これらの2つのアカウントで強力なパスワードを使用するのはユーザーの責任です。インストールウィザードで説明されているように、インストーラスクリプトは、パスワード入力用の一連の特殊文字をサポートしています。

    => Set a password for ClusterControl's MySQL user (cmon) [cmon]
    => Supported special password characters: [email protected]#$%^&*()_+{}<>?

    /etc/cmon.cnfおよび/etc/cmon.d/cmon_*.cnfの内容を確認し、可能な限り強力なパスワードを使用していることを確認してください。

    MySQLの「cmon」パスワードの変更

    構成されたパスワードがパスワードポリシーを満たさない場合、MySQL cmonパスワードを変更するには、実行する必要のあるいくつかの手順があります。

    1. ClusterControlのMySQLサーバー内でパスワードを変更します:

      $ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
      $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
      $ FLUSH PRIVILEGES;
    2. /etc/cmon.cnfおよび/etc/cmon.d/*.cnf内のコントローラーサービスの「mysql_password」オプションのすべての出現箇所を更新します。

      mysql_password=newPass
    3. /var/www/html/clustercontrol/bootstrap.phpおよび/var/www/html/cmonapi/config/database.php内のClusterControlUIの「DB_PASS」定数のすべての出現箇所を更新します。

      # <wwwroot>/clustercontrol/bootstrap.php
      define('DB_PASS', 'newPass');
      # <wwwroot>/cmonapi/config/database.php
      define('DB_PASS', 'newPass');
    4. ClusterControlによって監視されるすべてのMySQLサーバーのパスワードを変更します:

      $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
      $ FLUSH PRIVILEGES;
    5. CMONサービスを再起動して、変更を適用します。

      $ service cmon restart # systemctl restart cmon

    /var/log/cmon.logを確認して、cmonプロセスが正しく開始されているかどうかを確認します。以下のようなものがあることを確認してください:

    2018-01-11 08:33:09 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
    2018-01-11 08:33:09 : (INFO) Configuration loaded.
    2018-01-11 08:33:09 : (INFO) cmon 1.5.1.2299
    2018-01-11 08:33:09 : (INFO) Server started at tcp://127.0.0.1:9500
    2018-01-11 08:33:09 : (INFO) Server started at tls://127.0.0.1:9501
    2018-01-11 08:33:09 : (INFO) Found 'cmon' schema version 105010.
    2018-01-11 08:33:09 : (INFO) Running cmon schema hot-fixes.
    2018-01-11 08:33:09 : (INFO) Schema auto-upgrade succeed (version 105010).
    2018-01-11 08:33:09 : (INFO) Checked tables - seems ok
    2018-01-11 08:33:09 : (INFO) Community version
    2018-01-11 08:33:09 : (INFO) CmonCommandHandler: started, polling for commands.

    オフラインで実行する

    関連リソースClusterControl1.5.1の発表-MySQL、MongoDB、PostgreSQLのバックアップ暗号化機能ClusterControlを使用したMySQLとMariaDBのPCIコンプライアンスMySQL/MariaDBサーバーを保護する方法

    ClusterControlは、インターネットにアクセスできない環境でデータベースインフラストラクチャを管理できます。一部の機能はその環境では機能しません(クラウドへのバックアップ、パブリックリポジトリを使用した展開、アップグレード)。主要な機能はそこにあり、問題なく機能します。また、最初にすべてをインターネットで展開し、セットアップがテストされて本番データを提供する準備ができたらインターネットを切断することもできます。

    ClusterControlとデータベースクラスターを外界から隔離することで、重要な攻撃ベクトルの1つを取り除くことができました。

    概要

    ClusterControlは、データベースクラスターを保護するのに役立ちますが、それ自体では保護されません。運用チームは、セキュリティの観点から、ClusterControlサーバーも強化されていることを確認する必要があります。


    1. Redisと値のクエリ

    2. 同じステートメントでpopulateとaggregateを使用する方法は?

    3. MongoDB-ドキュメントを更新する

    4. ネストされたデータをMongoDBからPandasデータフレームに取得する