Database Security: Access Controls, Encryption, and Hardening
Part of the Cybersecurity Skills Guide — This article is one deep-dive in our complete guide series.
By HADESS Team | February 28, 2026 | Updated: February 28, 2026 | 5 min read
Databases hold the data that attackers want — credentials, personal information, financial records, intellectual property. A misconfigured database is often the difference between a minor incident and a breach that makes headlines. Securing databases requires attention to access controls, encryption, logging, and defense against injection attacks.
Access Controls
Apply least privilege at every level. Application database accounts should have only the permissions their queries require — SELECT, INSERT, UPDATE on specific tables. Never grant DBA or superuser privileges to application accounts.
Role-based access in PostgreSQL:
“sql CREATE ROLE app_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;
CREATE ROLE app_readwrite; GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_readwrite;
CREATE USER webapp WITH PASSWORD 'strong_password'; GRANT app_readwrite TO webapp; `
Separate read and write accounts. Your reporting system does not need write access. Your backup service does not need to read application data — it needs filesystem or replication access.
For MySQL, restrict accounts to specific source hosts. ‘webapp’@’10.0.1.%’ limits connections to your application subnet. ‘webapp’@’%’ accepts connections from anywhere.
Disable or rename default accounts. Remove sa access in SQL Server, lock the postgres superuser for remote access, and delete anonymous accounts in MySQL. Default accounts with known names are the first thing attackers try.
Encryption
Encryption at rest protects data on disk. Enable Transparent Data Encryption (TDE) in SQL Server, Oracle, and MySQL Enterprise. For PostgreSQL, use filesystem-level encryption (LUKS) or pgcrypto for column-level encryption of sensitive fields.
Encryption in transit uses TLS between applications and databases. Configure your database to require TLS connections and reject plaintext. In PostgreSQL, set ssl = on and ssl_min_protocol_version = ‘TLSv1.2’. In MySQL, use require_secure_transport = ON.
Column-level encryption protects specific sensitive fields — social security numbers, credit card numbers, health records. The application encrypts before storing and decrypts after retrieving. Use envelope encryption with keys stored in a KMS (AWS KMS, HashiCorp Vault, Azure Key Vault), not in the application config.
Audit Logging
Log all authentication attempts (successful and failed), schema changes, privilege modifications, and access to sensitive tables. Store audit logs separately from the database they monitor — an attacker who compromises the database should not be able to delete the evidence.
PostgreSQL: Use pgaudit extension for detailed session and object-level audit logging.
MySQL: Enable the audit log plugin. Configure it to log connections, queries on sensitive tables, and administrative operations.
SQL Server: Use SQL Server Audit with server and database-level specifications. Send audit logs to a secure file share or Windows Security event log.
Set up alerts for anomalous patterns: bulk data exports, after-hours access to production databases, new accounts created, and privilege escalation.
SQL Injection Defense
Parameterized queries are the primary defense. Every database driver supports them. There is no valid reason to concatenate user input into SQL strings.
Beyond parameterized queries, add defense in depth:
- Web Application Firewalls filter obvious SQL injection patterns
- Stored procedures with input validation add a layer between the application and raw SQL
- Database permissions limit what a successful injection can access — if the account cannot read the users table, injecting into an unrelated query cannot extract credentials
Monitor for SQL injection attempts in database logs. Queries containing UNION SELECT, OR 1=1, SLEEP(), or BENCHMARK()` are common indicators.
Hardening Checklist
- Remove sample databases and unnecessary stored procedures
- Disable remote root/sa access
- Change default ports (not security, but reduces noise from automated scanners)
- Apply patches promptly — database CVEs frequently enable remote code execution
- Restrict network access to database ports using firewall rules
- Disable unnecessary features: xp_cmdshell (SQL Server), file_priv (MySQL), untrusted PL languages (PostgreSQL)
Related Career Paths
Database security is a core skill for Security Engineer and Application Security Expert career paths. Both roles need to assess, harden, and monitor database deployments.
Next Steps
- Test your database security knowledge with the skills assessment
- Explore the skills library for related data protection and application security topics
- Plan your career with the certificate roadmap
Related Guides in This Series
Take the Next Step
Browse 80+ skills on HADESS. Go to the browse 80+ skills on hadess on HADESS.
See your certification roadmap. Check out the see your certification roadmap.
Get started free — Create your HADESS account and access all career tools.
Frequently Asked Questions
How long does it take to learn this skill?
Most practitioners build working proficiency in 4-8 weeks of dedicated study with hands-on practice. Mastery takes longer and comes primarily through on-the-job experience.
Do I need certifications for this skill?
Certifications validate your knowledge to employers but are not strictly required. Hands-on experience and portfolio projects often carry more weight in technical interviews. Check the certification roadmap for relevant options.
What career paths use this skill?
Explore the career path explorer to see which roles require this skill and how it fits into different cybersecurity specializations.
—
HADESS Team consists of cybersecurity practitioners, hiring managers, and career strategists who have collectively spent 50+ years in the field.
