sql >> Database >  >> NoSQL >> MongoDB

Hoe de ClusterControl-server te beveiligen

In onze vorige blogpost lieten we u zien hoe u uw open source databases kunt beveiligen met ClusterControl. Maar hoe zit het met de ClusterControl-server zelf? Hoe beveiligen we het? Dit wordt het onderwerp voor de blog van vandaag. We gaan ervan uit dat de host uitsluitend voor ClusterControl-gebruik is, zonder dat er andere applicaties op draaien.

Firewall &Beveiligingsgroep

Eerst en vooral moeten we alle onnodige poorten sluiten en alleen de noodzakelijke poorten openen die door ClusterControl worden gebruikt. Intern, tussen ClusterControl en de databaseservers, is alleen de netcat-poort van belang, waar de standaardpoort 9999 is. Deze poort hoeft alleen te worden geopend als u de back-up op de ClusterControl-server wilt opslaan. Anders kunt u dit afsluiten.

Vanaf het externe netwerk wordt aanbevolen om alleen toegang te openen tot HTTP (80) of HTTPS (443) voor de ClusterControl-gebruikersinterface. Als u de ClusterControl CLI met de naam 's9s' draait, moet het CMON-TLS-eindpunt worden geopend op poort 9501. Het is ook mogelijk om database-gerelateerde applicaties bovenop de ClusterControl-server te installeren, zoals HAProxy, Keepalived, ProxySQL en dergelijke. In dat geval moet je ook hiervoor de nodige poorten openzetten. Raadpleeg de documentatiepagina voor een lijst met poorten voor elke service.

Om firewallregels in te stellen via iptables, op het ClusterControl-knooppunt:

$ 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

Bovenstaande zijn de eenvoudigste commando's. U kunt strenger zijn en de opdrachten uitbreiden om uw beveiligingsbeleid te volgen, bijvoorbeeld door netwerkinterface, bestemmingsadres, bronadres, verbindingsstatus en wat niet toe te voegen.

Net als bij het uitvoeren van de installatie in de cloud, is het volgende een voorbeeld van regels voor inkomende beveiligingsgroepen voor de ClusterControl-server op AWS:

Verschillende cloudproviders bieden verschillende implementaties van beveiligingsgroepen, maar de basisregels zijn vergelijkbaar.

Encryptie

ClusterControl ondersteunt encryptie van communicatie op verschillende niveaus, om ervoor te zorgen dat de automatiserings-, monitoring- en beheertaken zo veilig mogelijk worden uitgevoerd.

Werkt op HTTPS

Het installatiescript (install-cc.sh) configureert standaard een zelfondertekend SSL-certificaat voor HTTPS-gebruik. Als u deze toegangsmethode als het hoofdeindpunt kiest, kunt u de gewone HTTP-service die op poort 80 draait vanaf het externe netwerk blokkeren. ClusterControl vereist echter nog steeds toegang tot CMONAPI (een legacy Rest-API-interface) die standaard op poort 80 op de localhost draait. Als u de HTTP-poort helemaal wilt blokkeren, moet u ervoor zorgen dat u de ClusterControl API-URL wijzigt onder Clusterregistraties pagina om in plaats daarvan HTTPS te gebruiken:

Het door ClusterControl geconfigureerde zelfondertekende certificaat heeft een geldigheid van 10 jaar (3650 dagen). U kunt de geldigheid van het certificaat controleren door de volgende opdracht te gebruiken (op de CentOS 7-server):

$  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
...

Houd er rekening mee dat het absolute pad naar het certificaatbestand kan verschillen, afhankelijk van het besturingssysteem.

MySQL Client-Server Encryptie

ClusterControl slaat monitoring- en beheergegevens op in MySQL-databases op het ClusterControl-knooppunt. Omdat MySQL zelf client-server SSL-codering ondersteunt, kan ClusterControl deze functie gebruiken om gecodeerde communicatie tot stand te brengen met de MySQL-server bij het schrijven en ophalen van de gegevens.

Hiervoor worden de volgende configuratie-opties ondersteund:

  • cmondb_ssl_key - pad naar SSL-sleutel, voor SSL-codering tussen CMON en de CMON DB.
  • cmondb_ssl_cert - pad naar SSL-certificaat, voor SSL-codering tussen CMON en de CMON DB
  • cmondb_ssl_ca - pad naar SSL CA, voor SSL-codering tussen CMON en de CMON DB

Enige tijd geleden hebben we de configuratiestappen in deze blogpost besproken.

Er is wel een vangst. Op het moment van schrijven heeft de gebruikersinterface van ClusterControl een beperking voor toegang tot CMON DB via SSL met behulp van de cmon-gebruiker. Als tijdelijke oplossing gaan we een andere databasegebruiker maken voor de ClusterControl UI en ClusterControl CMONAPI, genaamd cmonui. Deze gebruiker heeft SSL niet ingeschakeld in zijn privilegetabel.

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

Werk de ClusterControl UI- en CMONAPI-configuratiebestanden bij respectievelijk clustercontrol/bootstrap.php en cmonapi/config/database.php bij met de nieuw aangemaakte databasegebruiker 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>');

Deze bestanden worden niet vervangen wanneer u een upgrade uitvoert via pakketbeheerder.

CLI-codering

ClusterControl wordt ook geleverd met een opdrachtregelinterface genaamd 's9s'. Deze client parseert de opdrachtregelopties en stuurt een specifieke taak naar de controllerservice die luistert op poort 9500 (CMON) of 9501 (CMON met TLS). De laatste is de aanbevolen. Het installatiescript zal standaard s9s CLI configureren om 9501 te gebruiken als de eindpuntpoort van de ClusterControl-server.

Op rollen gebaseerde toegangscontrole

ClusterControl gebruikt Role-Based Access Control (RBAC) om de toegang tot clusters en hun respectievelijke implementatie-, beheer- en monitoringfuncties te beperken. Dit zorgt ervoor dat alleen geautoriseerde gebruikersverzoeken worden toegestaan. Toegang tot functionaliteit is fijnmazig, waardoor de toegang kan worden gedefinieerd door de organisatie of gebruiker. ClusterControl gebruikt een permissieframework om te definiëren hoe een gebruiker mag omgaan met de beheer- en monitoringfunctionaliteit, nadat hij daartoe geautoriseerd is.

De RBAC-gebruikersinterface is toegankelijk via ClusterControl -> Gebruikersbeheer -> Toegangscontrole :

Alle functies spreken voor zich, maar als je een aanvullende beschrijving wilt, bekijk dan de documentatiepagina.

Als u meerdere gebruikers hebt die betrokken zijn bij de bewerking van de databasecluster, wordt het ten zeerste aanbevolen om de toegangscontrole voor hen dienovereenkomstig in te stellen. U kunt ook meerdere teams (organisaties) maken en deze toewijzen met nul of meer clusters.

Werkt op aangepaste poorten

ClusterControl kan worden geconfigureerd om aangepaste poorten te gebruiken voor alle afhankelijke services. ClusterControl gebruikt SSH als het belangrijkste communicatiekanaal om knooppunten op afstand te beheren en te bewaken, Apache om de gebruikersinterface van ClusterControl te bedienen en ook MySQL om bewakings- en beheergegevens op te slaan. U kunt deze services uitvoeren op aangepaste poorten om de aanvallende vector te verminderen. De volgende poorten zijn de gebruikelijke doelen:

  • SSH - standaard is 22
  • HTTP - standaard is 80
  • HTTPS - standaard is 443
  • MySQL - standaard is 3306

Er zijn verschillende dingen die u moet wijzigen om de bovenstaande services op aangepaste poorten uit te voeren zodat ClusterControl correct werkt. We hebben dit in detail besproken op de documentatiepagina, Draait op aangepaste poort.

Toestemming en eigendom

ClusterControl-configuratiebestanden bevatten gevoelige informatie en moeten discreet en goed beschermd worden bewaard. De bestanden moeten alleen toegestaan ​​zijn voor gebruiker/groep root, zonder leesrechten voor anderen. In het geval dat de toestemming en eigendom verkeerd zijn ingesteld, helpt de volgende opdracht om ze terug te brengen naar de juiste staat:

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

Zorg er voor de MySQL-service voor dat de inhoud van de MySQL-gegevensmap is toegestaan ​​voor de "mysql"-groep, en dat de gebruiker ofwel "mysql" of "root" kan zijn:

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

Voor de gebruikersinterface van ClusterControl moet het eigendom zijn toegestaan ​​voor de Apache-gebruiker, ofwel "apache" voor RHEL/CentOS of "www-data" voor op Debian gebaseerd besturingssysteem.

De SSH-sleutel om verbinding te maken met de database-hosts is een ander zeer belangrijk aspect, omdat deze de identiteit bevat en met de juiste toestemming en eigendom moet worden bewaard. Bovendien staat SSH het gebruik van een onbeveiligd sleutelbestand niet toe bij het starten van de externe oproep. Controleer of het SSH-sleutelbestand dat door het cluster wordt gebruikt, in de gegenereerde configuratiebestanden onder de map /etc/cmon.d/, is ingesteld op de toegestane waarde voor de osuser alleen optie. Denk bijvoorbeeld aan de osuser is "ubuntu" en het sleutelbestand is /home/ubuntu/.ssh/id_rsa:

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

Gebruik een sterk wachtwoord

Als u het installatiescript gebruikt om ClusterControl te installeren, wordt u aangeraden een sterk wachtwoord te gebruiken wanneer het installatieprogramma daarom vraagt. Er zijn maximaal twee accounts die het installatiescript moet configureren (afhankelijk van uw instellingen):

  • MySQL cmon-wachtwoord - Standaardwaarde is 'cmon'.
  • MySQL root-wachtwoord - Standaardwaarde is 'password'.

Het is de verantwoordelijkheid van de gebruiker om sterke wachtwoorden te gebruiken in die twee accounts. Het installatiescript ondersteunt een aantal speciale tekens voor uw wachtwoordinvoer, zoals vermeld in de installatiewizard:

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

Controleer de inhoud van /etc/cmon.cnf en /etc/cmon.d/cmon_*.cnf en zorg ervoor dat u waar mogelijk een sterk wachtwoord gebruikt.

Het MySQL 'cmon'-wachtwoord wijzigen

Als het geconfigureerde wachtwoord niet voldoet aan uw wachtwoordbeleid, moet u verschillende stappen uitvoeren om het MySQL cmon-wachtwoord te wijzigen:

  1. Wijzig het wachtwoord in de MySQL-server van 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. Werk alle gevallen van 'mysql_password'-opties voor controllerservice bij in /etc/cmon.cnf en /etc/cmon.d/*.cnf:

    mysql_password=newPass

  3. Werk alle exemplaren van 'DB_PASS'-constanten voor ClusterControl UI bij in /var/www/html/clustercontrol/bootstrap.php en /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. Wijzig het wachtwoord op elke MySQL-server die door ClusterControl wordt gecontroleerd:

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

  5. Start de CMON-service opnieuw om de wijzigingen toe te passen:

    $ service cmon restart # systemctl restart cmon

Controleer of het cmon-proces correct is gestart door naar /var/log/cmon.log te kijken. Zorg ervoor dat je iets hebt zoals hieronder:

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.

Offline draaien

Gerelateerde bronnen Aankondiging van ClusterControl 1.5.1 - Met back-upversleuteling voor MySQL, MongoDB en PostgreSQL PCI-compliance voor MySQL en MariaDB met ClusterControl Hoe MySQL/MariaDB-servers te beveiligen

ClusterControl kan uw database-infrastructuur beheren in een omgeving zonder internettoegang. Sommige functies zouden niet werken in die omgeving (back-up naar de cloud, implementatie met openbare repo's, upgrades), de belangrijkste functies zijn aanwezig en zouden prima werken. Je hebt ook de keuze om in eerste instantie alles met internet te implementeren en vervolgens internet af te sluiten zodra de installatie is getest en klaar is om productiegegevens te leveren.

Door ClusterControl en het databasecluster van de buitenwereld te isoleren, hebt u een van de belangrijke aanvalsvectoren uitgeschakeld.

Samenvatting

ClusterControl kan helpen bij het beveiligen van uw databasecluster, maar het wordt niet vanzelf beveiligd. Ops-teams moeten ervoor zorgen dat de ClusterControl-server ook uit veiligheidsoogpunt wordt versterkt.


  1. hoe je onderliggende objecten in mongodb kunt opvragen

  2. mongodb TTL verwijdert geen documenten

  3. MongoDB $dayOfWeek

  4. Hoe plaats je een document in mongodb met behulp van mangoest en krijg je de gegenereerde id?