sql >> Database teknologi >  >> NoSQL >> MongoDB

Sådan sikrer du ClusterControl-serveren

I vores tidligere blogindlæg viste vi dig, hvordan du kan sikre dine open source-databaser med ClusterControl. Men hvad med selve ClusterControl-serveren? Hvordan sikrer vi det? Dette bliver emnet for dagens blog. Vi antager, at værten udelukkende er til ClusterControl-brug, og ingen andre applikationer kører på den.

Firewall- og sikkerhedsgruppe

Først og fremmest bør vi lukke alle unødvendige porte og kun åbne de nødvendige porte, der bruges af ClusterControl. Internt, mellem ClusterControl og databaseserverne, er det kun netcat-porten, der betyder noget, hvor standardporten er 9999. Denne port skal kun åbnes, hvis du ønsker at gemme sikkerhedskopien på ClusterControl-serveren. Ellers kan du lukke denne ned.

Fra det eksterne netværk anbefales det kun at åbne adgang til enten HTTP (80) eller HTTPS (443) for ClusterControl UI. Hvis du kører ClusterControl CLI kaldet 's9s', skal CMON-TLS-endepunktet åbnes på port 9501. Det er også muligt at installere databaserelaterede applikationer oven på ClusterControl-serveren, som HAProxy, Keepalived, ProxySQL og sådan. I så fald skal du også åbne de nødvendige porte for disse. Se venligst dokumentationssiden for en liste over porte for hver tjeneste.

For at konfigurere firewall-regler via iptables, skal du på ClusterControl-noden gøre:

$ 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

Ovenstående er de enkleste kommandoer. Du kan være strengere og udvide kommandoerne for at følge din sikkerhedspolitik - for eksempel ved at tilføje netværksgrænseflade, destinationsadresse, kildeadresse, forbindelsestilstand og hvad ikke.

I lighed med at køre opsætningen i skyen, er følgende et eksempel på indgående sikkerhedsgrupperegler for ClusterControl-serveren på AWS:

Forskellige cloud-udbydere tilbyder forskellige sikkerhedsgruppeimplementeringer, men de grundlæggende regler er ens.

Kryptering

ClusterControl understøtter kryptering af kommunikation på forskellige niveauer for at sikre, at automatiserings-, overvågnings- og administrationsopgaverne udføres så sikkert som muligt.

Kører på HTTPS

Installationsscriptet (install-cc.sh) konfigurerer som standard et selvsigneret SSL-certifikat til HTTPS-brug. Hvis du vælger denne adgangsmetode som hovedslutpunktet, kan du blokere den almindelige HTTP-tjeneste, der kører på port 80 fra det eksterne netværk. ClusterControl kræver dog stadig adgang til CMONAPI (en ældre Rest-API-grænseflade), som kører som standard på port 80 på den lokale vært. Hvis du gerne vil blokere HTTP-porten over det hele, skal du sørge for at ændre ClusterControl API-URL'en under Klyngeregistreringer side for at bruge HTTPS i stedet:

Det selvsignerede certifikat konfigureret af ClusterControl har 10 års (3650 dage) gyldighed. Du kan bekræfte certifikatets gyldighed ved at bruge følgende kommando (på CentOS 7-serveren):

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

Bemærk, at den absolutte sti til certifikatfilen kan være anderledes afhængigt af operativsystemet.

MySQL Client-Server Kryptering

ClusterControl gemmer overvågnings- og administrationsdata inde i MySQL-databaser på ClusterControl-noden. Da MySQL i sig selv understøtter klient-server SSL-kryptering, er ClusterControl i stand til at bruge denne funktion til at etablere krypteret kommunikation med MySQL-serveren, når dens data skrives og hentes.

Følgende konfigurationsmuligheder understøttes til dette formål:

  • cmondb_ssl_key - sti til SSL-nøgle, til SSL-kryptering mellem CMON og CMON DB.
  • cmondb_ssl_cert - sti til SSL-certifikat, til SSL-kryptering mellem CMON og CMON DB
  • cmondb_ssl_ca - sti til SSL CA, til SSL-kryptering mellem CMON og CMON DB

Vi dækkede konfigurationstrinnene i dette blogindlæg for noget tid tilbage.

Der er dog en fangst. I skrivende stund har ClusterControl UI en begrænsning i at få adgang til CMON DB via SSL ved hjælp af cmon-brugeren. Som en løsning vil vi oprette en anden databasebruger til ClusterControl UI og ClusterControl CMONAPI kaldet cmonui. Denne bruger vil ikke have SSL aktiveret på sin privilegietabel.

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

Opdater ClusterControl UI- og CMONAPI-konfigurationsfilerne på henholdsvis clustercontrol/bootstrap.php og cmonapi/config/database.php med den nyoprettede databasebruger, 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>');

Disse filer vil ikke blive erstattet, når du udfører en opgradering via pakkehåndtering.

CLI-kryptering

ClusterControl kommer også med en kommandolinjegrænseflade kaldet 's9s'. Denne klient analyserer kommandolinjeindstillingerne og sender et specifikt job til controllertjenesten, der lytter på port 9500 (CMON) eller 9501 (CMON med TLS). Sidstnævnte er den anbefalede. Installationsscriptet vil som standard konfigurere s9s CLI til at bruge 9501 som slutpunktsporten på ClusterControl-serveren.

Rollebaseret adgangskontrol

ClusterControl bruger rollebaseret adgangskontrol (RBAC) til at begrænse adgangen til klynger og deres respektive implementerings-, administrations- og overvågningsfunktioner. Dette sikrer, at kun autoriserede brugeranmodninger er tilladt. Adgang til funktionalitet er finmasket, så adgang kan defineres af organisation eller bruger. ClusterControl bruger en tilladelsesramme til at definere, hvordan en bruger kan interagere med administrations- og overvågningsfunktionaliteten, efter at de er blevet autoriseret til at gøre det.

RBAC-brugergrænsefladen kan tilgås via ClusterControl -> Brugerstyring -> Adgangskontrol :

Alle funktionerne er selvforklarende, men hvis du ønsker en yderligere beskrivelse, så tjek venligst dokumentationssiden.

Hvis du har flere brugere involveret i databaseklyngedriften, anbefales det stærkt at indstille adgangskontrol for dem i overensstemmelse hermed. Du kan også oprette flere teams (organisationer) og tildele dem nul eller flere klynger.

Kører på brugerdefinerede porte

ClusterControl kan konfigureres til at bruge brugerdefinerede porte til alle de afhængige tjenester. ClusterControl bruger SSH som den vigtigste kommunikationskanal til at styre og overvåge noder eksternt, Apache til at betjene ClusterControl UI og også MySQL til at gemme overvågnings- og administrationsdata. Du kan køre disse tjenester på brugerdefinerede porte for at reducere den angribende vektor. Følgende porte er de sædvanlige mål:

  • SSH - standard er 22
  • HTTP - standard er 80
  • HTTPS - standard er 443
  • MySQL - standard er 3306

Der er flere ting, du skal ændre for at køre ovenstående tjenester på brugerdefinerede porte, for at ClusterControl fungerer korrekt. Vi har dækket dette i detaljer på dokumentationssiden, Running on Custom Port.

Tilladelse og ejerskab

ClusterControl-konfigurationsfiler indeholder følsomme oplysninger og bør holdes diskrete og godt beskyttede. Filerne skal kun være tilladt for brugeren/gruppens root uden læsetilladelse til andre. Hvis tilladelsen og ejerskabet er blevet forkert indstillet, hjælper følgende kommando med at gendanne dem tilbage til den korrekte tilstand:

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

For MySQL-tjenester skal du sikre dig, at indholdet af MySQL-databiblioteket er tilladt for "mysql"-gruppen, og at brugeren kan være enten "mysql" eller "root":

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

For ClusterControl UI skal ejerskabet være tilladt for Apache-brugeren, enten "apache" for RHEL/CentOS eller "www-data" for Debian-baseret OS.

SSH-nøglen til at oprette forbindelse til databaseværterne er et andet meget vigtigt aspekt, da den holder identiteten og skal opbevares med korrekt tilladelse og ejerskab. Desuden tillader SSH ikke brugen af ​​en usikret nøglefil, når fjernopkaldet startes. Kontroller, at SSH-nøglefilen, der bruges af klyngen, inde i de genererede konfigurationsfiler under mappen /etc/cmon.d/, er indstillet til tilladt for osuser kun mulighed. Overvej f.eks. osuser er "ubuntu", og nøglefilen er /home/ubuntu/.ssh/id_rsa:

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

Brug en stærk adgangskode

Hvis du bruger installationsscriptet til at installere ClusterControl, opfordres du til at bruge en stærk adgangskode, når du bliver bedt om det af installationsprogrammet. Der er højst to konti, som installationsscriptet skal konfigurere (afhængigt af din opsætning):

  • MySQL cmon-adgangskode - Standardværdien er 'cmon'.
  • MySQL root-adgangskode - Standardværdien er 'adgangskode'.

Det er brugerens ansvar at bruge stærke adgangskoder på disse to konti. Installationsscriptet understøtter en masse specialtegn til din adgangskodeinput, som nævnt i installationsguiden:

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

Bekræft indholdet af /etc/cmon.cnf og /etc/cmon.d/cmon_*.cnf, og sørg for, at du bruger en stærk adgangskode, når det er muligt.

Ændring af MySQL 'cmon'-adgangskoden

Hvis den konfigurerede adgangskode ikke opfylder din adgangskodepolitik, er der flere trin, du skal udføre for at ændre MySQL cmon-adgangskoden:

  1. Skift adgangskoden inde i ClusterControls MySQL-server:

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

  2. Opdater alle forekomster af 'mysql_password'-indstillinger for controllerservice inde i /etc/cmon.cnf og /etc/cmon.d/*.cnf:

    mysql_password=newPass

  3. Opdater alle forekomster af 'DB_PASS' konstanter for ClusterControl UI inde i /var/www/html/clustercontrol/bootstrap.php og /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. Skift adgangskoden på hver MySQL-server, der overvåges af ClusterControl:

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

  5. Genstart CMON-tjenesten for at anvende ændringerne:

    $ service cmon restart # systemctl restart cmon

Bekræft om cmon-processen er startet korrekt ved at se på /var/log/cmon.log. Sørg for, at du har noget som nedenfor:

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.

Køre det offline

Relaterede ressourcer annoncering af ClusterControl 1.5.1 – Med sikkerhedskopieringskryptering til MySQL, MongoDB og PostgreSQL PCI-overholdelse for MySQL og MariaDB med ClusterControl Sådan sikrer du MySQL/MariaDB-servere

ClusterControl er i stand til at administrere din databaseinfrastruktur i et miljø uden internetadgang. Nogle funktioner ville ikke fungere i det miljø (backup til skyen, udrulning ved hjælp af offentlige reposer, opgraderinger), de vigtigste funktioner er der og ville fungere fint. Du har også et valg om først at implementere alt med internettet og derefter afbryde internettet, når opsætningen er testet og klar til at betjene produktionsdata.

Ved at have ClusterControl og databaseklyngen isoleret fra omverdenen, har du fjernet en af ​​de vigtige angrebsvektorer.

Oversigt

ClusterControl kan hjælpe med at sikre din databaseklynge, men den bliver ikke sikret af sig selv. Ops-teams skal sørge for, at ClusterControl-serveren også er hærdet ud fra et sikkerhedssynspunkt.


  1. Mongodb concat int og streng

  2. Forskellen mellem Find og FindAsync

  3. Sådan erstatter du eksisterende dokumenter, når du importerer en fil til MongoDB

  4. Robust meddelelsesserialisering i Apache Kafka ved hjælp af Apache Avro, del 1