Database Reference
In-Depth Information
Physical security is also important. If an attacker can simply walk in and take the
server or computer our MariaDB database is present and walk out with it, none
of our network and other security measures will mean anything. It's trivial for an
attacker to gain access to our data if they have physical access to the machine.
The next ring is the
Server
on which MariaDB is running. Who can log in? Where
can they log in from? Who has administrative rights? Does it have monitoring and
backup systems in place so we can keep an eye on it? The answers to these questions
depend on factors that are out of the scope of this topic. We should ind out the
answers though.
For example, if you know that only three other people have login access to the server,
we could tighten up security to a level—such as requiring SSH keys to login—that
might be unacceptable on a server that has hundreds of users or is shared with other
departments. Knowing who are the administrators of the server is useful because
we want to know who to call if something goes wrong. It's the same for backup
and monitoring systems; we need to know where they are and how to access them
because if we don't they won't be of much use to us when a problem occurs.
Now we're inside the server and have come to the center of the rings — the MariaDB
database itself. If it looks like MariaDB is sitting right at the center of a bullseye,
that's because it is. Security starts here and there's no better time to secure our
MariaDB installation than right now. We'll begin by working our way from the
inside out.
Securing MariaDB in ten seconds
The first thing we need to do after we install MariaDB is to run the
mysql_secure_
installation
script. This useful script ships with MariaDB and its sole purpose
is to quickly and easily set up some basic security. To run it, open a command line
and enter:
mysql_secure_installation
The script will ask several questions. For nearly all of them, it's best to answer yes
(
y
). The only question we might want to answer no to is when the script asks us to
set a root user password. If we've already set a root password we can safely skip this
question (the script is helpful enough to tell us when it is safe).
The other questions include removing the
test
database, removing the default
anonymous user, and disallowing remote root user logins. The anonymous user and
test database are included in the default MariaDB installation for testing purposes,
but there's almost never a reason to keep them. We can always create a new test user
and database, or several, for our testing needs.
