sql >> Base de Datos >  >> NoSQL >> MongoDB

Cómo proteger el servidor ClusterControl

En nuestra publicación de blog anterior, le mostramos cómo puede proteger sus bases de datos de código abierto con ClusterControl. Pero, ¿qué pasa con el propio servidor ClusterControl? ¿Cómo lo aseguramos? Este será el tema del blog de hoy. Suponemos que el host es únicamente para el uso de ClusterControl, sin que se ejecuten otras aplicaciones en él.

Grupo de seguridad y cortafuegos

En primer lugar, debemos cerrar todos los puertos innecesarios y abrir solo los puertos necesarios utilizados por ClusterControl. Internamente, entre ClusterControl y los servidores de la base de datos, solo importa el puerto netcat, donde el puerto predeterminado es 9999. Este puerto debe abrirse solo si desea almacenar la copia de seguridad en el servidor ClusterControl. De lo contrario, puede cerrar esto.

Desde la red externa, se recomienda abrir solo el acceso a HTTP (80) o HTTPS (443) para la interfaz de usuario de ClusterControl. Si está ejecutando la CLI de ClusterControl llamada 's9s', el punto final de CMON-TLS debe abrirse en el puerto 9501. También es posible instalar aplicaciones relacionadas con la base de datos sobre el servidor de ClusterControl, como HAProxy, Keepalived, ProxySQL y similares. En ese caso, también debe abrir los puertos necesarios para estos. Consulte la página de documentación para obtener una lista de puertos para cada servicio.

Para configurar reglas de firewall a través de iptables, en el nodo ClusterControl, haga lo siguiente:

$ 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

Los anteriores son los comandos más simples. Puede ser más estricto y ampliar los comandos para seguir su política de seguridad, por ejemplo, agregando una interfaz de red, dirección de destino, dirección de origen, estado de conexión y demás.

Similar a ejecutar la configuración en la nube, el siguiente es un ejemplo de reglas de grupo de seguridad de entrada para el servidor ClusterControl en AWS:

Diferentes proveedores de nube proporcionan diferentes implementaciones de grupos de seguridad, pero las reglas básicas son similares.

Cifrado

ClusterControl admite el cifrado de las comunicaciones en diferentes niveles, para garantizar que las tareas de automatización, supervisión y gestión se realicen de la forma más segura posible.

Ejecución en HTTPS

La secuencia de comandos del instalador (install-cc.sh) configurará de forma predeterminada un certificado SSL autofirmado para el uso de HTTPS. Si elige este método de acceso como punto final principal, puede bloquear el servicio HTTP simple que se ejecuta en el puerto 80 desde la red externa. Sin embargo, ClusterControl aún requiere acceso a CMONAPI (una interfaz Rest-API heredada) que se ejecuta de manera predeterminada en el puerto 80 en el host local. Si desea bloquear todo el puerto HTTP, asegúrese de cambiar la URL de API de ClusterControl en Registros de clúster página para usar HTTPS en su lugar:

El certificado autofirmado configurado por ClusterControl tiene 10 años (3650 días) de validez. Puede verificar la validez del certificado usando el siguiente comando (en el 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
...

Tenga en cuenta que la ruta absoluta al archivo del certificado puede ser diferente según el sistema operativo.

Cifrado cliente-servidor MySQL

ClusterControl almacena datos de monitoreo y administración dentro de bases de datos MySQL en el nodo ClusterControl. Dado que MySQL admite el cifrado SSL cliente-servidor, ClusterControl es capaz de utilizar esta función para establecer una comunicación cifrada con el servidor MySQL al escribir y recuperar sus datos.

Las siguientes opciones de configuración son compatibles para este propósito:

  • cmondb_ssl_key - ruta a la clave SSL, para el cifrado SSL entre CMON y CMON DB.
  • cmondb_ssl_cert - ruta al certificado SSL, para el cifrado SSL entre CMON y CMON DB
  • cmondb_ssl_ca - ruta a SSL CA, para cifrado SSL entre CMON y CMON DB

Cubrimos los pasos de configuración en esta publicación de blog hace algún tiempo.

Sin embargo, hay una trampa. En el momento de escribir este artículo, la interfaz de usuario de ClusterControl tiene una limitación para acceder a la base de datos de CMON a través de SSL con el usuario cmon. Como solución temporal, vamos a crear otro usuario de base de datos para la interfaz de usuario de ClusterControl y la CMONAPI de ClusterControl denominada cmonui. Este usuario no tendrá habilitado SSL en su tabla de privilegios.

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

Actualice la interfaz de usuario de ClusterControl y los archivos de configuración de CMONAPI ubicados en clustercontrol/bootstrap.php y cmonapi/config/database.php respectivamente con el usuario de base de datos recién creado, 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>');

Estos archivos no se reemplazarán cuando realice una actualización a través del administrador de paquetes.

Cifrado CLI

ClusterControl también viene con una interfaz de línea de comandos llamada 's9s'. Este cliente analiza las opciones de la línea de comandos y envía un trabajo específico al servicio del controlador que escucha en el puerto 9500 (CMON) o 9501 (CMON con TLS). Este último es el recomendado. La secuencia de comandos del instalador configurará de forma predeterminada la CLI de s9s para usar 9501 como el puerto de punto final del servidor ClusterControl.

Control de acceso basado en roles

ClusterControl utiliza el control de acceso basado en roles (RBAC) para restringir el acceso a los clústeres y sus respectivas funciones de implementación, administración y supervisión. Esto garantiza que solo se permitan las solicitudes de usuarios autorizados. El acceso a la funcionalidad es detallado, lo que permite que la organización o el usuario definan el acceso. ClusterControl usa un marco de permisos para definir cómo un usuario puede interactuar con la funcionalidad de administración y monitoreo, después de haber sido autorizado para hacerlo.

Se puede acceder a la interfaz de usuario de RBAC a través de ClusterControl -> Administración de usuarios -> Control de acceso :

Todas las funciones se explican por sí mismas, pero si desea una descripción adicional, consulte la página de documentación.

Si tiene varios usuarios involucrados en la operación del clúster de la base de datos, se recomienda encarecidamente establecer controles de acceso para ellos en consecuencia. También puede crear varios equipos (organizaciones) y asignarles cero o más grupos.

Ejecución en puertos personalizados

ClusterControl se puede configurar para usar puertos personalizados para todos los servicios dependientes. ClusterControl usa SSH como el principal canal de comunicación para administrar y monitorear nodos de forma remota, Apache para servir la interfaz de usuario de ClusterControl y también MySQL para almacenar datos de monitoreo y administración. Puede ejecutar estos servicios en puertos personalizados para reducir el vector de ataque. Los siguientes puertos son los objetivos habituales:

  • SSH:el valor predeterminado es 22
  • HTTP:el valor predeterminado es 80
  • HTTPS:el valor predeterminado es 443
  • MySQL:el valor predeterminado es 3306

Hay varias cosas que debe cambiar para ejecutar los servicios anteriores en puertos personalizados para que ClusterControl funcione correctamente. Hemos cubierto esto en detalle en la página de documentación, Ejecución en puerto personalizado.

Permiso y propiedad

Los archivos de configuración de ClusterControl contienen información confidencial y deben mantenerse discretos y bien protegidos. Los archivos deben estar permitidos solo para el usuario/grupo raíz, sin permiso de lectura para otros. En caso de que el permiso y la propiedad se hayan configurado incorrectamente, el siguiente comando ayuda a restaurarlos al estado correcto:

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

Para el servicio MySQL, asegúrese de que el contenido del directorio de datos de MySQL esté permitido para el grupo "mysql", y el usuario podría ser "mysql" o "root":

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

Para la interfaz de usuario de ClusterControl, la propiedad debe ser permisible para el usuario de Apache, ya sea "apache" para RHEL/CentOS o "www-data" para el sistema operativo basado en Debian.

La clave SSH para conectarse a los hosts de la base de datos es otro aspecto muy importante, ya que mantiene la identidad y debe conservarse con el permiso y la propiedad adecuados. Además, SSH no permitirá el uso de un archivo de clave no seguro al iniciar la llamada remota. Verifique que el archivo de clave SSH utilizado por el clúster, dentro de los archivos de configuración generados en el directorio /etc/cmon.d/, esté configurado como permitido por osuser opción solamente. Por ejemplo, considere el osuser es "ubuntu" y el archivo clave es /home/ubuntu/.ssh/id_rsa:

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

Utilice una contraseña segura

Si utiliza la secuencia de comandos del instalador para instalar ClusterControl, le recomendamos que utilice una contraseña segura cuando se lo solicite el instalador. Hay como máximo dos cuentas que la secuencia de comandos del instalador deberá configurar (dependiendo de su configuración):

  • Contraseña cmon de MySQL:el valor predeterminado es 'cmon'.
  • Contraseña raíz de MySQL:el valor predeterminado es 'contraseña'.

Es responsabilidad del usuario utilizar contraseñas seguras en esas dos cuentas. La secuencia de comandos del instalador admite un montón de caracteres especiales para la entrada de su contraseña, como se menciona en el asistente de instalación:

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

Verifique el contenido de /etc/cmon.cnf y /etc/cmon.d/cmon_*.cnf y asegúrese de utilizar una contraseña segura siempre que sea posible.

Cambiar la contraseña 'cmon' de MySQL

Si la contraseña configurada no cumple con su política de contraseñas, para cambiar la contraseña cmon de MySQL, hay varios pasos que debe realizar:

  1. Cambie la contraseña dentro del servidor MySQL de 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. Actualice todas las apariciones de las opciones 'mysql_password' para el servicio del controlador dentro de /etc/cmon.cnf y /etc/cmon.d/*.cnf:

    mysql_password=newPass

  3. Actualice todas las apariciones de constantes 'DB_PASS' para la interfaz de usuario de ClusterControl dentro de /var/www/html/clustercontrol/bootstrap.php y /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. Cambie la contraseña en cada servidor MySQL monitoreado por ClusterControl:

    $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;

  5. Reinicie el servicio CMON para aplicar los cambios:

    $ service cmon restart # systemctl restart cmon

Verifique si el proceso de cmon se inició correctamente consultando /var/log/cmon.log. Asegúrate de tener algo como lo siguiente:

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.

Ejecutarlo sin conexión

Recursos relacionados Anuncio de ClusterControl 1.5.1:con cifrado de copia de seguridad para MySQL, MongoDB y PostgreSQL Cumplimiento de PCI para MySQL y MariaDB con ClusterControl Cómo asegurar servidores MySQL/MariaDB

ClusterControl puede administrar su infraestructura de base de datos en un entorno sin acceso a Internet. Algunas funciones no funcionarían en ese entorno (copia de seguridad en la nube, implementación mediante repositorios públicos, actualizaciones), las funciones principales están ahí y funcionarían bien. También tiene la opción de implementar inicialmente todo con Internet y luego desconectar Internet una vez que la configuración esté probada y lista para servir datos de producción.

Al tener ClusterControl y el clúster de la base de datos aislados del mundo exterior, ha eliminado uno de los vectores de ataque importantes.

Resumen

ClusterControl puede ayudar a proteger el clúster de su base de datos, pero no se protege por sí solo. Los equipos de operaciones deben asegurarse de que el servidor ClusterControl también esté reforzado desde el punto de vista de la seguridad.