MariaDB best practices for user and permissions management, secrets storage, SSL, encryption at rest, and more. Includes an overview of MariaDB most advanced security features. Webinar organised in December 2023.

1. MariaDB Security Best Practices

2. ● This talk is about security best practices that should be used
with MariaDB
● It is not:
○ A tutorial
○ A discussion on MariaDB specific features
Agenda

3. Restricting
hosts and ports

4. ● Access to MariaDB should be allowed from:
○ Replicas / masters / galera nodes
○ Proxies
○ Monitoring
○ Service discovery
○ …potentially other tools…
○ Jumphosts (SSH)
Restricting access

5. ● Proxies, service discovery need to be reachable from the
applications
● Monitoring needs be reachable from the world, via HTTPS
port
● MariaDB should not be reachable from other nodes
● Jumphost should be reachable from the world, only SSH port
Restricting access

6. ● On cloud platforms this can usually be achieved with security
groups
● As a general rule, hosts in the same SG can communicate to
each other
● If you don't run your databases in the cloud, consider using
a VPN
Restricting access

7. ● Access should only be permitted using the proper ports
● This can be achieved with SG rules, too
● But if security is paramount, don't fear redundancy
○ For example, use both SG rules and IPTables
Restricting access

8. ● Up to version 10.11, Galera had no protection for this case:
○ A malicious user attaches a new Galera node to an
existing cluster
○ The new node obtains an SST with a method that doesn't
require authentication
● So, before that version, Galera needed to run in a VPN or
security group with strict rules
Restricting access

9. ● Now, you can whitelist nodes that are supposed to be part of
the cluster:
wsrep_allowlist=10.10.10.10,20.20.20.20,30.30.30.30
● This variable is not dynamic
● To add a new node, restart the nodes one by one
Restricting access

10. Users

11. ● Instead of MariaDB users we should say accounts
● An account is:
username@'host'
MariaDB Users

12. A host can be:
● A hostname
● An IPv4 or IPv6
● A LIKE pattern
○ eg: 'app__.mywebsite.com'
● A netmask
○ eg: '10.0.1.1/255.255.255'
○ '10.0.1.1/24'
MariaDB Users

13. ● root should only connect from localhost
○ No password, after connecting to the OS via SSH
○ Can be done with UNIX_SOCKET authentication plugin
○ This is the default
● Don't let root connect from anywhere else
MariaDB Users

14. ● Each application of microservice should have a different user
● Ensure they connect from the proper subnet mask
● Or from the proper hostname
ms_authentication@10.0.1.1/24
ms_authentication@auth-__.myapp.com
MariaDB Users

15. ● Users can connect from several places
● And even have different permissions depending on where
they connect from
● I don't recommend this practices (usually)
● Use prefixes like app- or ms- to distinguish
apps/microservices from human users
MariaDB Users

16. Permissions

17. Permissions can be granted at several levels:
● Global (read everything)
GRANT SELECT ON *.* TO user@host;
● Database (any table from a DB)
GRANT SELECT ON db.* TO user@host;
● Table (single table)
GRANT SELECT ON db.tab TO user@host;
● Column (only read certain columns)
GRANT SELECT *(id, col_a, col_b) ON db.tab
TO user@host;
MariaDB Permissions

18. ● Normally, an application/microservice user should have
permissions on a single database:
GRANT SELECT, INSERT, UPDATE, DELETE ON auth.*
TO ms_auth@host;
● Typically, you also want to have a read-only user to scale
reads to replicas:
GRANT SELECT ON auth.*
TO ms_auth_ro@host;
● Migrations should be done by a separate user:
GRANT CREATE, CREATE VIEW, ALTER, INDEX, DROP, DROP
HISTORY, TRIGGER ON auth.*
TO ms_auth_migrations@host;
MariaDB Permissions

19. ● Human users are typically:
○ Data analysts
○ Business analysts
○ Managers
…who know SQL
MariaDB Permissions

20. ● Human users should only have SELECT permission, and
optionally CREATE TEMPORARY TABLES
● But they shouldn't have any permission on columns that
contain PII (personal identifiable information)
● Which means:
○ Private data: name, email, phone, etc
○ Information that allows to identify a user: user id, etc
This is required by GDPR and other regulations
MariaDB Permissions

21. How to do this? Here's an idea:
● Keep a table with the list of PII columns:
{db, table, column}
● A script should query the information_schema.COLUMNS
table, and get a list of columns that are not in the
pii_column table
● Grant SELECT permission on those columns
MariaDB Permissions

22. ● But even in this way:
○ Permissions might not be strict enough to prevent certain
queries that should be forbidden
○ A user could be granted too many permissions by
mistake
○ A MariaDB bug could allow a user to perform critical
operations
● So I recommend to turn the Audit Log on
MariaDB Roles

23. Roles

24. ● Human users shouldn't be granted permissions directly
● Each human users should be assigned one or more roles:
CREATE ROLE business_analyst;
GRANT SELECT ON *.* TO business_analyst;
GRANT business_analyst TO briard_laure@host;
MariaDB Roles

25. ● Roles can be assigned to other roles:
-- all analysts can run certain stored procedures
CREATE ROLE analyst;
-- some analysts can see sales information
CREATE ROLE analyst_sales;
GRANT analyst TO analyst_sales;
-- some analysts can see employees information
CREATE ROLE analyst_employee;
GRANT analyst TO analyst_employee;
MariaDB Roles

26. Good practices for creating a tree of roles:
● Only do it if your permissions logic is sufficiently complex
● It should be a tree, not a graph (only 1 parent)
● Only "leaf roles" are assigned to users
MariaDB Roles

27. Authentication
Plugins

28. ● Authentication plugins determine how users log into MariaDB
● Each user can be assigned one or more authentication
plugins
● Some plugins are pre-installed
● Others are in the plugin_dir. They can be installed:
INSTALL SONAME 'auth_ed25519';
● Some authentication plugins need support in the client
● Non-official MariaDB connectors and GUIs might not support
a plugin you need
Authentication Plugins

29. Default authentication plugins:
● mysql_native_password - default
● mysql_old_password - for backward compatibility
● unix_socket - default for root
● named_pipe - Windows
Authentication Plugins: GSSAPI

30. ● PAM is a framework for multiple authentication methods, used on
Linux / UNIX
● Each authentication method is implemented as a PAM module:
○ pam_google_authenticator
○ pam_ldap
○ MS Active Directory
○ pam_unix: use /etc/shadow
○ pam_ssh: Log in via SSH keys
○ pam_time: Restrict login based on time
○ pam_user_map: Maps multiple PAM users to the same
MariaDB user
It's possible to use multiple modules for the same user
Authentication Plugins: PAM

31. SSL

32. ● Starting from MariaDB 11.3, SSL is enabled by default
● However, it's hardly useful if you don't require clients to
connect via SSH
Backup security

33. As a minimum, you should do this:
CREATE USER xyz REQUIRE SSL;
But in this way, a self-signed certificate is accepted
Backup security

34. You can require:
● an issuer
● a subject
● a cipher
● or any combination of these
REQUIRE SUBJECT '/CN/Federico/O=Vettabase Ltd/C=UK'
AND ISSUER '...'
AND CIPHER 'SHA-DES-CBC3-EDH-RSA';
Backup security

35. SQL Encryption

36. MariaDB has several SQL functions for encrypting data
INSERT INTO user (pwd, …) VALUES (
CRYPT('Hello, world!', 'zzXf')
);
Problem:
The clear password will be sent over a network and possibly
logged
Encryption in SQL

37. ● MariaDB 11.2 improved AES_ENCRYPT() and
AES_DECRYPT():
AES_ENCRYPT(str, key, [, iv [, mode]])
● And introduced KDF(), that can generate good keys:
AES_ENCRYPT(
str,
KDF('foo', 'bar', 'infa', 'hkdf'),
[, iv
[, mode]]
)
Encryption in SQL

38. ● Not knowing the key makes it harder to brute-force the
encrypted secret
● So the results of KDF() and AES_ENCRYPT() should be
stored on different database servers
Encryption in SQL

39. Encryption at rest

40. ● Encryption at rest means that clear data is sent and received
by applications, but it's encrypted on disk
● This protects you by whoever gains access to:
○ the OS
○ the physical disk
● Hard disk thefts are possible and, for certain data sets,
they can make a person rich
Encryption at rest

41. ● MariaDB can encrypt:
○ InnoDB .ibd files
○ InnoDB ibdata and ib_logfile* files
○ Aria .MAD and .MAI files (including temporary tables)
○ Binary log
○ Relay log
○ Temporary files: long transactions, filesort
Encryption at rest

42. ● MariaDB does not encrypt:
○ Galera cache
○ Slow and general logs
○ Audit log
○ Error log
○ Aria log (only relevant for non-temporary tables)
○ Other storage engines
● Other files not encrypted, but not critical:
○ .frm files (table definitions)
Encryption at rest

43. ● It is vital that:
○ The key is not stored on the same disk as data, but
ideally it shouldn't be stored on the same server
○ The keys are rotated
● Encryption key management plugins take care of this:
○ File Key Management Plugin
○ Hashicorp Key Management Plugin (Vault)
○ Eperi Key Management Plugin
○ AWS Key Management Plugin
Encryption at rest

44. File Key Management Plugin
● Multiple keys are supported
● But no key rotation
● Keys stored on the same server
● Keys can be manually crypted
Encryption at rest

45. Hashicorp Key Management Plugin
● Multiple keys are supported
● Key rotation is supported
● Keys are stored in Hashicorp Vault
● Vault authentication is done via a token
Encryption at rest

46. ● Encryption at rest is an interesting example of how MariaDB
is enriched by community contributions:
○ Originally implemented by eperi
○ Tablespace encryption by Google
Encryption at rest

47. Backup security

48. ● Physical backups of encrypted data are encrypted
● Consider encrypting other backup types
● But keep in mind that decrypting a backup can take time, and
when you do it your servers might be down
● So you need a wise balance between security and speed
● If you encrypt AND compress backups, first encrypt them,
then compress them
Backup security

49. ● If you send backups to other locations, make sure you use
secure connections
● If you keep backups on local physical devices, make sure
they are stored securely
Backup security