MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

MySQL vs MariaDB vs Percona Server:porównanie funkcji bezpieczeństwa

Bezpieczeństwo danych ma kluczowe znaczenie dla każdej organizacji. To ważny aspekt, który może mieć duży wpływ na projekt środowiska bazy danych. Decydując, który rodzaj MySQL użyć, należy wziąć pod uwagę funkcje bezpieczeństwa oferowane przez różnych dostawców serwerów. W tym poście na blogu przedstawimy krótkie porównanie najnowszych wersji MySQL Community Edition firm Oracle, Percona Server i MariaDB:

mysqld  Ver 5.7.20-19 for Linux on x86_64 (Percona Server (GPL), Release 19, Revision 3c5d3e5d53c)
mysqld  Ver 5.7.21 for Linux on x86_64 (MySQL Community Server (GPL))
mysqld  Ver 10.2.12-MariaDB for Linux on x86_64 (MariaDB Server)

Zamierzamy użyć Centos 7 jako systemu operacyjnego - pamiętaj, że wyniki, które tutaj prezentujemy, mogą się nieznacznie różnić w innych dystrybucjach, takich jak Debian czy Ubuntu. Chcielibyśmy również skupić się na różnicach i nie będziemy omawiać podobieństw — Percona Server i MariaDB są odmianami MySQL, więc niektóre funkcje bezpieczeństwa (np. jak wyglądają uprawnienia dostępu do plików MySQL) są między nimi współdzielone.

Początkowe zabezpieczenia

Użytkownicy

Zarówno Percona Server, jak i MySQL Community Server są dostarczane z losowo wygenerowanym tymczasowym hasłem dla użytkownika root. Aby go znaleźć, musisz sprawdzić zawartość dziennika błędów MySQL:

2018-01-19T13:47:45.532148Z 1 [Note] A temporary password is generated for [email protected]: palwJu7uSL,g

Po zalogowaniu wymuszana jest zmiana hasła:

[[email protected] ~]# mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.21

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from mysql.user;
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

Hasło musi być wystarczająco silne, jest to wymuszane przez wtyczkę validate_password:

mysql> alter user [email protected] identified by 'password123.';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
mysql> alter user [email protected] identified by 'password123.A';
Query OK, 0 rows affected (0.00 sec)

MariaDB nie generuje losowego hasła roota i zapewnia bezhasłowy dostęp do konta root z (i tylko z) hosta lokalnego.

[[email protected] ~]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 10.2.12-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| [email protected] |
+----------------+
1 row in set (0.00 sec)

Nie jest to duży problem w początkowej fazie wdrażania, ponieważ DBA ma później skonfigurować i zabezpieczyć dostęp do bazy danych (na przykład uruchamiając mysql_secure_installation). Większym problemem jest to, że MariaDB nie wymusza dobrych praktyk. Jeśli nie musisz ustawiać silnego hasła dla użytkownika root, może się zdarzyć, że nikt go później nie zmieni i pozostanie dostęp bez hasła. Wtedy stałoby się to poważnym zagrożeniem bezpieczeństwa.

Kolejnym aspektem, któremu chcielibyśmy się przyjrzeć, jest anonimowy dostęp bez hasła. Anonimowi użytkownicy pozwalają każdemu wejść, nie musi to być predefiniowany użytkownik. Jeśli taki dostęp jest bez hasła, oznacza to, że każdy może połączyć się z MySQL. Zazwyczaj takie konto ma tylko uprawnienie USAGE, ale nawet wtedy można wydrukować status ('\s'), który zawiera informacje takie jak wersja MySQL, zestaw znaków itp. Dodatkowo, jeśli dostępny jest schemat 'test', taki użytkownik ma możliwość napisz do tego schematu.

Zarówno MySQL Community Server, jak i serwer Percona nie mają żadnych anonimowych użytkowników zdefiniowanych w MySQL:

mysql> select user, host, authentication_string from mysql.user;
+---------------+-----------+-------------------------------------------+
| user          | host      | authentication_string                     |
+---------------+-----------+-------------------------------------------+
| root          | localhost | *EB965412B594F67C8EB611810EF8D406F2CF42BD |
| mysql.session | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
| mysql.sys     | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
+---------------+-----------+-------------------------------------------+
3 rows in set (0.00 sec)

Z drugiej strony MariaDB jest otwarta na anonimowy dostęp bez hasła.

MariaDB [(none)]> select user,host,password from mysql.user;
+------+-----------------------+----------+
| user | host                  | password |
+------+-----------------------+----------+
| root | localhost             |          |
| root | localhost.localdomain |          |
| root | 127.0.0.1             |          |
| root | ::1                   |          |
|      | localhost             |          |
|      | localhost.localdomain |          |
+------+-----------------------+----------+
6 rows in set (0.00 sec)

Oprócz tego dostępny jest schemat „testowy”, który umożliwia anonimowym użytkownikom dokonywanie zapisów w bazie danych.

[[email protected] ~]# mysql -umyanonymoususer
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 14
Server version: 10.2.12-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use test;
Database changed
MariaDB [test]> CREATE TABLE mytab (a int);
Query OK, 0 rows affected (0.01 sec)

MariaDB [test]> INSERT INTO mytab VALUES (1), (2);
Query OK, 2 rows affected (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 0

MariaDB [test]> SELECT * FROM mytab;
+------+
| a    |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

Stanowi to poważne zagrożenie i wymaga rozwiązania. W przeciwnym razie można go łatwo wykorzystać do próby przeciążenia serwera zapisami.

Dane w bezpieczeństwie transportu

MySQL Community Server i oba jego forki obsługują użycie SSL do szyfrowania przesyłanych danych. Jest to niezwykle ważne w przypadku sieci rozległych, ale nie powinno być również pomijane w sieci lokalnej. SSL może być używany zarówno po stronie klienta, jak i serwera. Jeśli chodzi o konfigurację po stronie serwera (na przykład w celu szyfrowania ruchu od urządzenia nadrzędnego do urządzenia podrzędnego), wygląda ona identycznie na całej planszy. Istnieje jednak różnica, jeśli chodzi o szyfrowanie SSL po stronie klienta, wprowadzone w MySQL 5.7. Przed wersją 5.7 trzeba było generować klucze SSL i CA oraz definiować je w konfiguracjach zarówno serwera, jak i klienta. Tak wygląda konfiguracja protokołu SSL 10.2 MariaDB. Zarówno w MySQL Community Server 5.7, jak iw Percona Server 5.7 (opartym na MySQL 5.7) nie ma potrzeby wstępnego generowania kluczy. Wszystko odbywa się automatycznie, w tle. Wszystko, co musisz zrobić, to włączyć SSL na swoim kliencie, ustawiając poprawny „--ssl-mode”. W przypadku klienta CLI MySQL nie jest to nawet potrzebne, ponieważ domyślnie włącza SSL:

[[email protected] ~]# mysql -p -h127.0.0.1
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.21 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> \s
--------------
mysql  Ver 14.14 Distrib 5.7.21, for Linux (x86_64) using  EditLine wrapper

Connection id:        6
Current database:
Current user:        [email protected]
SSL:            Cipher in use is DHE-RSA-AES256-SHA
Current pager:        stdout
Using outfile:        ''
Using delimiter:    ;
Server version:        5.7.21 MySQL Community Server (GPL)
Protocol version:    10
Connection:        127.0.0.1 via TCP/IP
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    utf8
Conn.  characterset:    utf8
TCP port:        3306
Uptime:            2 days 21 hours 51 min 52 sec

Threads: 1  Questions: 15  Slow queries: 0  Opens: 106  Flush tables: 1  Open tables: 99  Queries per second avg: 0.000
--------------

Z drugiej strony MariaDB wymagałaby dodatkowej konfiguracji, ponieważ protokół SSL jest domyślnie wyłączony:

[[email protected] ~]# mysql -h127.0.0.1
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 18
Server version: 10.2.12-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> \s
--------------
mysql  Ver 15.1 Distrib 10.2.12-MariaDB, for Linux (x86_64) using readline 5.1

Connection id:        18
Current database:
Current user:        [email protected]
SSL:            Not in use
Current pager:        stdout
Using outfile:        ''
Using delimiter:    ;
Server:            MariaDB
Server version:        10.2.12-MariaDB MariaDB Server
Protocol version:    10
Connection:        127.0.0.1 via TCP/IP
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    utf8
Conn.  characterset:    utf8
TCP port:        3306
Uptime:            2 days 22 hours 26 min 58 sec

Threads: 7  Questions: 45  Slow queries: 0  Opens: 18  Flush tables: 1  Open tables: 12  Queries per second avg: 0.000
--------------

Szyfrowanie danych w spoczynku

Przede wszystkim kopie zapasowe - dostępne są bezpłatnie narzędzia do tworzenia kopii zapasowych, takie jak xtrabackup czy MariaDB Backup (która jest rozwidleniem xtrabackup). Pozwalają one na tworzenie zaszyfrowanych kopii zapasowych wszystkich trzech smaków MySQL, które omawiamy w tym poście na blogu.

Wszystkie trzy smaki obsługują szyfrowanie działającej bazy danych, ale istnieją różnice w tym, jakie fragmenty danych są szyfrowane.

Serwer społeczności MySQL obsługuje tylko szyfrowanie obszarów tabel InnoDB. Klucze używane do szyfrowania są przechowywane w plikach (co jest niezgodne z przepisami – klucze powinny być przechowywane w sejfie – coś, co obsługuje MySQL Enterprise). Percona Server jest oparty na MySQL Community Server, więc obsługuje również szyfrowanie obszarów tabel InnoDB. Ostatnio w Percona Server 5.7.20 dodano obsługę szyfrowania ogólnych obszarów tabel (w porównaniu do pojedynczych w poprzednich wersjach i MySQL Community Edition). Dodano również obsługę szyfrowania logów binarnych. Percona Server jest dostarczany z wtyczką keyring_vault, której można używać do przechowywania kluczy na serwerze Hashicorp Vault, dzięki czemu Percona Server 5.7.20 jest zgodny z wymogami prawnymi dotyczącymi szyfrowania danych w spoczynku.

MariaDB 10.2 ma bardziej zaawansowaną obsługę szyfrowania danych w spoczynku. Oprócz szyfrowania w przestrzeni tabel i logów binarnych/przekaźnikowych, obsługuje szyfrowanie logów przeróbek InnoDB. Obecnie jest to bardziej kompletne rozwiązanie dotyczące szyfrowania danych.

Rejestrowanie audytu

Wszystkie trzy wersje MySQL obsługują rejestrowanie audytu. Ich zakres jest prawie porównywalny:zdarzenia łączenia i rozłączania, wykonywane zapytania, dostęp do tabel. Logi zawierają informacje o tym, który użytkownik brał udział w takim zdarzeniu, z jakiego hosta się zalogował, kiedy to się stało i podobne informacje. Takie zdarzenia mogą być również rejestrowane przez syslog i przechowywane na zewnętrznym serwerze logów, aby umożliwić analizę i parsowanie logów.

Maskowanie danych, zapora SQL

Wszystkie omawiane warianty MySQL współpracują z jakimś narzędziem, które pozwoliłoby na implementację maskowania danych i byłoby w stanie blokować ruch SQL w oparciu o pewne reguły. Maskowanie danych to metoda zaciemniania niektórych danych poza bazą danych, ale zanim dotrą do klienta. Przykładem mogą być dane karty kredytowej, które są przechowywane w postaci zwykłego tekstu w bazie danych, ale gdy programista chce zapytać o takie dane, zobaczy „xxxxxxxx...” zamiast liczb. Narzędzia, o których tutaj mówimy, to ProxySQL i MaxScale. MaxScale jest produktem MariaDB Corporation i jest oparty na subskrypcji. ProxySQL to darmowy serwer proxy bazy danych. Oba proxy mogą być używane z dowolnymi smakami MySQL.

To wszystko dla dzisiejszych ludzi. Aby dowiedzieć się więcej, zapoznaj się z 10 wskazówkami dotyczącymi zabezpieczania baz danych MySQL i MariaDB.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jak SYS_GUID() działa w MariaDB

  2. Przegląd MariaDB Xpand (dawniej ClustrixDB)

  3. Nowe zarządzanie użytkownikami i LDAP w ClusterControl 1.8.2

  4. Ogłaszamy obsługę MariaDB 10.2 — ClusterControl 1.5

  5. MariaDB RTRIM() vs RTRIM_ORACLE():Jaka jest różnica?