MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Como proteger o servidor ClusterControl


Em nossa postagem de blog anterior, mostramos como você pode proteger seus bancos de dados de código aberto com o ClusterControl. Mas e o próprio servidor ClusterControl? Como o garantimos? Este será o tema do blog de hoje. Assumimos que o host é exclusivamente para uso do ClusterControl, sem outros aplicativos sendo executados nele.

Grupo de firewall e segurança


Em primeiro lugar, devemos fechar todas as portas desnecessárias e abrir apenas as portas necessárias usadas pelo ClusterControl. Internamente, entre o ClusterControl e os servidores de banco de dados, apenas a porta netcat importa, onde a porta padrão é 9999. Esta porta só precisa ser aberta se você quiser armazenar o backup no servidor ClusterControl. Caso contrário, você pode fechar isso.

Na rede externa, é recomendável abrir apenas o acesso a HTTP (80) ou HTTPS (443) para a interface do usuário do ClusterControl. Se você estiver executando a CLI do ClusterControl chamada 's9s', o endpoint CMON-TLS precisa ser aberto na porta 9501. Também é possível instalar aplicativos relacionados ao banco de dados no servidor ClusterControl, como HAProxy, Keepalived, ProxySQL e outros. Nesse caso, você também deve abrir as portas necessárias para isso. Consulte a página de documentação para obter uma lista de portas para cada serviço.

Para configurar regras de firewall via iptables, no nó ClusterControl, faça:
$ 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

Os comandos acima são os mais simples. Você pode ser mais rigoroso e estender os comandos para seguir sua política de segurança - por exemplo, adicionando interface de rede, endereço de destino, endereço de origem, estado de conexão e outros.

Semelhante à execução da configuração na nuvem, veja a seguir um exemplo de regras de grupo de segurança de entrada para o servidor ClusterControl na AWS:

Diferentes provedores de nuvem fornecem diferentes implementações de grupos de segurança, mas as regras básicas são semelhantes.

Criptografia


O ClusterControl suporta a criptografia de comunicações em diferentes níveis, para garantir que as tarefas de automação, monitoramento e gerenciamento sejam executadas da forma mais segura possível.

Executando em HTTPS


O script do instalador (install-cc.sh) configurará por padrão um certificado SSL autoassinado para uso HTTPS. Se você escolher esse método de acesso como o endpoint principal, poderá bloquear o serviço HTTP simples em execução na porta 80 da rede externa. No entanto, o ClusterControl ainda requer um acesso ao CMONAPI (uma interface Rest-API herdada) que é executada por padrão na porta 80 no host local. Se você quiser bloquear toda a porta HTTP, certifique-se de alterar a URL da API ClusterControl em Registros de cluster página para usar HTTPS em vez disso:

O certificado autoassinado configurado pelo ClusterControl tem 10 anos (3650 dias) de validade. Você pode verificar a validade do certificado usando o seguinte comando (no servidor 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
...

Observe que o caminho absoluto para o arquivo de certificado pode ser diferente dependendo do sistema operacional.

Criptografia cliente-servidor MySQL


ClusterControl armazena dados de monitoramento e gerenciamento dentro de bancos de dados MySQL no nó ClusterControl. Como o próprio MySQL suporta criptografia SSL cliente-servidor, o ClusterControl é capaz de utilizar esse recurso para estabelecer comunicação criptografada com o servidor MySQL ao gravar e recuperar seus dados.

As seguintes opções de configuração são suportadas para esta finalidade:
  • cmondb_ssl_key - caminho para a chave SSL, para criptografia SSL entre o CMON e o CMON DB.
  • cmondb_ssl_cert - caminho para o certificado SSL, para criptografia SSL entre CMON e o CMON DB
  • cmondb_ssl_ca - caminho para SSL CA, para criptografia SSL entre CMON e o CMON DB

Cobrimos as etapas de configuração nesta postagem do blog há algum tempo.

Há uma captura embora. No momento da escrita, a UI do ClusterControl tem uma limitação no acesso ao CMON DB por meio de SSL usando o usuário cmon. Como solução alternativa, vamos criar outro usuário de banco de dados para o ClusterControl UI e o ClusterControl CMONAPI chamado cmonui. Este usuário não terá SSL habilitado em sua tabela de privilégios.
mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;

Atualize os arquivos de configuração ClusterControl UI e CMONAPI localizados em clustercontrol/bootstrap.php e cmonapi/config/database.php respectivamente com o usuário de banco de dados recém-criado, 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>');

Esses arquivos não serão substituídos quando você realizar uma atualização por meio do gerenciador de pacotes.

Criptografia CLI


O ClusterControl também vem com uma interface de linha de comando chamada 's9s'. Este cliente analisa as opções da linha de comandos e envia uma tarefa específica para o serviço do controlador que atende na porta 9500 (CMON) ou 9501 (CMON com TLS). Este último é o recomendado. O script do instalador, por padrão, configurará o s9s CLI para usar 9501 como a porta do terminal do servidor ClusterControl.

Controle de acesso baseado em função


O ClusterControl usa o controle de acesso baseado em função (RBAC) para restringir o acesso a clusters e seus respectivos recursos de implantação, gerenciamento e monitoramento. Isso garante que apenas solicitações de usuários autorizados sejam permitidas. O acesso à funcionalidade é refinado, permitindo que o acesso seja definido por organização ou usuário. O ClusterControl usa uma estrutura de permissões para definir como um usuário pode interagir com a funcionalidade de gerenciamento e monitoramento, após ter sido autorizado a fazê-lo.

A interface de usuário do RBAC pode ser acessada via ClusterControl -> User Management -> Access Control :

Todos os recursos são autoexplicativos, mas se você quiser alguma descrição adicional, consulte a página de documentação.

Se você tiver vários usuários envolvidos na operação do cluster de banco de dados, é altamente recomendável definir os controles de acesso para eles adequadamente. Você também pode criar várias equipes (organizações) e atribuí-las com zero ou mais clusters.

Executando em portas personalizadas


O ClusterControl pode ser configurado para usar portas personalizadas para todos os serviços dependentes. ClusterControl usa SSH como o principal canal de comunicação para gerenciar e monitorar nós remotamente, Apache para servir a UI ClusterControl e também MySQL para armazenar dados de monitoramento e gerenciamento. Você pode executar esses serviços em portas personalizadas para reduzir o vetor de ataque. As seguintes portas são os alvos usuais:
  • SSH - o padrão é 22
  • HTTP - o padrão é 80
  • HTTPS - o padrão é 443
  • MySQL - o padrão é 3306

Há várias coisas que você precisa alterar para executar os serviços acima em portas personalizadas para que o ClusterControl funcione corretamente. Cobrimos isso em detalhes na página de documentação, Executando na porta personalizada.

Permissão e propriedade


Os arquivos de configuração do ClusterControl contêm informações confidenciais e devem ser mantidos discretos e bem protegidos. Os arquivos devem ser permitidos apenas ao usuário/grupo root, sem permissão de leitura para outros. Caso a permissão e a propriedade tenham sido configuradas incorretamente, o comando a seguir ajuda a restaurá-las de volta ao estado correto:
$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf

Para o serviço MySQL, certifique-se de que o conteúdo do diretório de dados MySQL seja permitido ao grupo "mysql" e o usuário possa ser "mysql" ou "root":
$ chown -Rf mysql:mysql /var/lib/mysql

Para ClusterControl UI, a propriedade deve ser permitida ao usuário Apache, seja "apache" para RHEL/CentOS ou "www-data" para SO baseado em Debian.

A chave SSH para se conectar aos hosts do banco de dados é outro aspecto muito importante, pois mantém a identidade e deve ser mantida com a devida permissão e propriedade. Além disso, o SSH não permitirá o uso de um arquivo de chave não seguro ao iniciar a chamada remota. Verifique se o arquivo de chave SSH usado pelo cluster, dentro dos arquivos de configuração gerados no diretório /etc/cmon.d/, está definido como permitido para o osuser opção apenas. Por exemplo, considere o osuser é "ubuntu" e o arquivo de chave é /home/ubuntu/.ssh/id_rsa:
$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsa

Use uma senha forte


Se você usar o script do instalador para instalar o ClusterControl, é recomendável usar uma senha forte quando solicitado pelo instalador. Existem no máximo duas contas que o script do instalador precisará configurar (dependendo da sua configuração):
  • Senha do MySQL cmon - O valor padrão é 'cmon'.
  • Senha raiz do MySQL - O valor padrão é 'senha'.

É responsabilidade do usuário usar senhas fortes nessas duas contas. O script do instalador suporta vários caracteres especiais para sua entrada de senha, conforme mencionado no assistente de instalação:
=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?

Verifique o conteúdo de /etc/cmon.cnf e /etc/cmon.d/cmon_*.cnf e certifique-se de usar uma senha forte sempre que possível.

Mudando a senha 'cmon' do MySQL


Se a senha configurada não atender à sua política de senha, para alterar a senha do cmon do MySQL, há várias etapas que você precisa executar:

  1. Altere a senha dentro do servidor MySQL do ClusterControl:
    $ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
    $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
    $ FLUSH PRIVILEGES;

  2. Atualize todas as ocorrências das opções 'mysql_password' para o serviço do controlador dentro de /etc/cmon.cnf e /etc/cmon.d/*.cnf:
    mysql_password=newPass

  3. Atualize todas as ocorrências de constantes 'DB_PASS' para ClusterControl UI dentro de /var/www/html/clustercontrol/bootstrap.php e /var/www/html/cmonapi/config/database.php:
    # <wwwroot>/clustercontrol/bootstrap.php
    define('DB_PASS', 'newPass');
    # <wwwroot>/cmonapi/config/database.php
    define('DB_PASS', 'newPass');

  4. Altere a senha em cada servidor MySQL monitorado pelo ClusterControl:
    $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
    $ FLUSH PRIVILEGES;

  5. Reinicie o serviço CMON para aplicar as mudanças:
    $ service cmon restart # systemctl restart cmon

Verifique se o processo cmon foi iniciado corretamente olhando para /var/log/cmon.log. Certifique-se de ter algo como abaixo:
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.

Executando off-line

Recursos relacionados Anúncio do ClusterControl 1.5.1 - Com criptografia de backup para MySQL, MongoDB e PostgreSQL Conformidade PCI para MySQL e MariaDB com ClusterControl Como proteger servidores MySQL/MariaDB
ClusterControl é capaz de gerenciar sua infraestrutura de banco de dados em um ambiente sem acesso à Internet. Alguns recursos não funcionariam nesse ambiente (backup na nuvem, implantação usando repositórios públicos, atualizações), os principais recursos estão lá e funcionariam bem. Você também tem a opção de implantar tudo inicialmente com a Internet e, em seguida, cortar a Internet assim que a configuração for testada e estiver pronta para fornecer dados de produção.

Ao ter o ClusterControl e o cluster de banco de dados isolados do mundo exterior, você eliminou um dos vetores de ataque importantes.

Resumo


O ClusterControl pode ajudar a proteger seu cluster de banco de dados, mas ele não fica protegido sozinho. As equipes de operações devem certificar-se de que o servidor ClusterControl também esteja protegido do ponto de vista da segurança.