Users, Roles, Privileges, Security Hardening, and Auditing Practices
Protect MariaDB with proper user management, least privilege design, secure access patterns, and operational discipline.
Inside this chapter
- Security Starts with User Design
- Creating Limited Users
- Hardening Checklist
- Security as an Ongoing Process
Series navigation
Study the chapters in order for the smoothest path from relational foundations to production-level MariaDB operations. Use the navigation at the bottom of each page to move chapter by chapter through the full series.
Security Starts with User Design
Database security is not only about strong passwords. It is about separating administrative accounts from application accounts, granting only required privileges, controlling remote access, rotating credentials, auditing changes, and ensuring backups are protected just as carefully as live systems.
Creating Limited Users
CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong-password';
GRANT SELECT, INSERT, UPDATE, DELETE
ON appdb.* TO 'app_user'@'localhost';
FLUSH PRIVILEGES;An application usually does not need global administrative access. Giving it only the privileges it needs reduces risk if credentials are exposed or code behaves incorrectly.
Hardening Checklist
- Use distinct users for admin, app runtime, migrations, and reporting jobs.
- Restrict host access and prefer private networking where possible.
- Review privilege grants periodically.
- Protect credentials in secret stores or secure environment variables.
- Audit risky changes such as privilege escalation or schema modifications.
Security as an Ongoing Process
Advanced teams treat security as continuous work. They review authentication setup, patch levels, TLS configuration, log access, and backup exposure. A secure production MariaDB deployment is the result of many small disciplined decisions, not a single configuration flag.