Databases contain some of an organization’s most sensitive data, so following database security best practices is critical for protecting that data from cyberattacks and insider data theft.
Effective database security encloses sensitive information within layers of controls that decrease the risk of a breach and reduce the potential harm from a successful breach. We’ll discuss seven best practices for database security that create overlapping controls, followed by seven additional best practices for related systems. The result is a rigorous defense in depth to minimize risk throughout the organization.
- What is Database Security?
- 7 Database Security Best Practices
- 7 Related System Security Best Practices
- Bottom Line: Database Security Best Practices
What is Database Security?
Database security consists of the controls organizations implement to prevent unauthorized access or data breaches from database files, database management systems (DBMS), and connected systems. Security controls consist of architecture techniques, application design, procedures, processes, and tools that make the data more difficult to access and use.
Database security done poorly will harm operations efficiency, application performance, and user experience. Security must be balanced against operations needs with the goal of reducing risk to an acceptable level while maintaining usability.
Database security best practices and controls apply specifically to databases. However, databases do not exist in pure isolation, so organizations must also defend the broader ecosystem. To be adequately defended, effective database security also requires the implementation of more general security best practices applied to related systems.
See the Top Database Security Solutions
7 Database Security Best Practices
To protect a database, it must reside in a secured environment, protected by its own perimeter security, and accessed by secured users. These seven best practices specifically secure databases and database data.
1. Separate Database Servers
By definition, web servers must be publicly accessible to be used, but this also paints web servers as a primary target for attack. A successful attack may grant an attacker access to the host server for the website or application, which allows an attacker to access anything else hosted on the server.
Databases should be segregated to a separate container, physical server, or virtual server to allow for additional hardening and to prevent access if the website or application is breached. Only the required ports on the separate server should be opened and, where possible, an organization should change the default communication ports to make attacks more challenging to execute.
Some recommend setting up an HTTPS proxy server between the database and the queries, but separating the web server and the database server functionally achieves the same result. However, a proxy server may be beneficial for internal-network databases that may be queried directly by authorized network users or devices.
To further secure the database, consider placing the database server on a separate physical or virtual network segment, with highly restricted access privileges. Microsegmentation of this type can prevent attackers that have gained more general network access from easily moving laterally to access a database server that might not appear on a compromised user’s network.
2. Use Database Firewalls
Databases only become useful if accessed, but that access must be protected. The first layer of defense comes from database-specific firewalls that deny access by default. The only traffic allowed through the firewall should come from specific applications, web servers, or users that need to access the data, and without a specific need, the firewall should deny the database from initiating outbound connections.
Direct access to the database should be limited or denied if the use-case will allow it. Firewall rule changes must be controlled by change management procedures and trigger alerts for security monitoring.
Organizations can deploy specialized database tools that include special firewalls such as the Oracle Audit Vault and Database Firewall, dedicated physical or virtual next generation firewall (NGFW), or web application firewall (WAF) solutions. Organizations with more limited resources may simply deploy a hardened version of the database server’s operating system firewall.
3. Secure Database User Access
The least possible number of users, applications, and application programming interfaces (APIs) should access the database. Any access should be granted only after network or application authorization and, even then, all access should be based on the principle of least privilege and granted for the least time possible. This best practice can be broken down into three sub-categories: user authorization, privileged access, and development and operations (DevOps) use of databases.
User Authorization
Access control to the database is managed by the system administrator, or admin. The admin grants permissions defined by roles and by adding user accounts to those database roles. For example, the role of row-level security (RLS) restricts read and write access to rows of data based on a user’s identity, role memberships, or query execution context.
Specialized database security solutions may allow for centralized management of identities and permissions, minimize password storage, and enable password rotation policies. Comprehensive access management might not be practical for smaller organizations, but it remains important to manage permissions via roles or groups instead of individual users.
Administrators also need to harden the database access rules:
- Null passwords should not be allowed
- Temporary installation files that may contain passwords should be deleted
- Default accounts should be deleted if not needed or else change passwords from default settings
- Require unique IDs for all users for tracking and logging
- Users and applications should use separate accounts
- Inactive users should be disabled or deleted on a schedule
- Elevated database privileges should be logged, reported, and potentially generate security alerts
- User groups and access rights should be reviewed on a periodic basis
- Accounts should automatically lock after a number of failed logins, usually recommended as six failed login attempts
Privileged Access
Admins should have only the bare minimum privileges needed to perform required tasks, and only for the duration they specifically need access. Privileged access should be granted temporarily and revoked continuously. Larger organizations automate access management using privileged access management (PAM) software. PAM provides authorized users with a temporary password, logs activities, and prevents sharing passwords.
DevOps Database Use
Although not typically considered users, DevOps teams need to create test environments to verify that applications can access and use databases correctly. Unfortunately, using live or production database data often leads to accidental data leaks.
To avoid issues, DevOps should use the following practices:
- Sensitive data should be limited to the production environment
- Test environments should be physically and logically separated from production environments
- Test environments should use separate roles and permissions than production environments
- Developers should not get access to production environments unless absolutely necessary
- Test environments should never contain real production data; synthetic or anonymized datasets should be used instead
4. Harden the Database
Just as the server must be hardened, the database should also be hardened to prevent simple attacks and exploits.
Database hardening varies according to the type of database platform, but the common steps include strengthening password protection and access controls, securing network traffic, and encrypting sensitive fields in the database.
All unused or unnecessary services or functions of the database should be removed or turned off to prevent unrecognized exploitation.
All database security controls provided by the database should be enabled. Some will be enabled by default and others may have specific reasons to be disabled, but each should be evaluated and all reasoning for disabled controls documented. Where possible admins can enable row-level security and dynamic data masking for sensitive data.
DevOps should design the database so that sensitive information remains in segregated tables. Admins should also continuously audit the data to discover sensitive data to determine if the segregated tables need to be modified or additional security applied. Some regulatory or compliance standards will mandate specific data discovery requirements that need to be implemented, followed, and documented to prove compliance.
Also read: Network Protection: How to Secure a Network
5. Audit And Continuously Monitor Database Activity
DevOps designs with certain expectations, but after integrating databases with applications and moving them into a production environment, some unexpected access, user queries, or data behavior may occur. Admins need to continuously monitor and audit database logs, data, and activity including:
- User login logs, especially attempted and failed logins
- Locked accounts (from excessive failed login attempts)
- Database privilege escalation
- Database data extraction, copying, or deletion (particularly large-scale changes or extractions)
- Access to sensitive or regulated data (may be required for compliance)
- New account creation
Audits often can detect anomalous activity, and security teams can establish security alerts on critical events to warn security teams or to enable security information and event management (SIEM) tool alerts. Database activity monitoring (DAM) and file integrity monitoring software can provide specialized security alerts independent of native database logging and audit functions.
6. Test Your Database Security
Although audits can catch malicious activity in progress, organizations should not wait for attacks to test their database deployments. Database vendors should be monitored for updates and patch management processes should update databases with minimal delay.
Yet patching only addresses publicly announced vulnerabilities. Some database vendors will offer security and configuration testing tools, such as Oracle’s Database Security Assessment Tool, that can help identify risks. However, these tools should not be assumed to provide 100% assurance and should be complemented by subsequent testing using vulnerability scans and penetration tests that simulate potential attacks to expose misconfigurations, inadvertently accessible data, and other issues.
7. Database Data Best Practices
Databases structure data, but the data contained within the database also needs to be protected. The first step requires an organization to store only the protected data required for the business function. Eliminating excessive data or purging unnecessary historical information can minimize risk exposure.
Next, the data must be intentionally controlled. Redundancy of protected data should be eliminated throughout the system, and shadowing of protected data outside the system of record must be avoided wherever possible. Hashing functions can be applied to protected data elements before storing data required for matching purposes outside of the system. Wherever possible, protected data such as health information or credit card numbers should be dissociated from personally identifiable information (PII).
Encryption should also be pursued for extra protection. Many vendors provide solutions to encrypt data at rest, data in transit, or even data in use. Within the database, DevOps can encrypt or use data masking to obscure data within tables. Some encryption tools even allow for data to be processed and searched without decryption so that the data always remains encrypted and protected.
Some cloud vendors, such as Oracle, will encrypt stored data by default or provide encryption key management tools, such as Azure Key Vault. However, organizations themselves bear the responsibility for ensuring adequate protection throughout the data storage and data transfer process.
7 Related System Security Best Practices
If a security practice does not apply specifically to databases, it cannot be considered solely a component of database security. However, this does not diminish the importance of these practices or that these security practices should be in place to ensure database security.
1. Physical Security Best Practices
Although it can sometimes be overlooked, physical security must not be assumed. An attacker’s physical access to a data center can undermine even the best cybersecurity practices and technology. Securing a physical environment containing servers and network equipment should be the first best practice for fundamental IT security.
Onsite data centers require physical security measures such as cameras, locks and staffed security personnel, and any physical access servers should be controlled, logged, and regularly reviewed. If regular access is not typical, then alerts should be generated.
Assets hosted in the cloud may fall outside of an organization’s direct physical control, but not outside of an organization’s responsibility. The organization still needs to confirm adequate physical security, which typically will be met by the cloud vendor’s compliance with the physical security standards within a compliance guideline such as:
- ISO 27001
- ISO 20000-1
- NIST SPs (SP 800-14, SP 800-23, and SP 800-53)
- Department of Defense Information Assurance Technical Framework
- SSAE 18 SOC 1 Type II, SOC 2 Type II and SOC 3
2. Use Web Application and Network Firewalls
Firewalls provide foundational protection for all IT assets. In addition to deploying a firewall for the database, organizations need to deploy next generation firewalls (NGFW) to protect their networks and web application firewalls to protect the websites and applications accessing the database.
These more general firewalls protect the organization as a whole against attacks that affect databases as well as other systems, such as SQL injection attacks and distributed denial of service (DDoS) attacks.
3. User Authentication
When databases authorize users for access, the inherent assumption is that the user has already been authenticated and proven their identity. Security best practices require the authentication or identity verification of all types of users such as guests, employees, customers, and administrators. User authentication security sub-categories include insider threat management, user verification, and privileged access management (PAM).
Insider Threat Management
Some data can be so valuable, criminal organizations will pay employees to leak the data or even place their own members into jobs under false pretenses to gain access to data. To minimize these insider threat issues, organizations should conduct background checks for programmers, contractors, security professionals, database administrators, and anyone who may be able to access or redirect sensitive information.
See the Top Data Loss Prevention (DLP) Solutions
Once employee identities are confirmed, organizations then implement user and entity behavior analytic (UEBA) tools, UEBA features on other security tools, and audit logs to look for signs of inappropriate or abnormal behavior. Keep in mind that stolen credentials used by a hacker will appear to most security tools as authorized access until unusual behavior is detected. Lastly, establish a policy for deactivating accounts or unnecessary access when employees switch to different roles or leave the company.
User Verification
To maintain the integrity of a proven identity, users must regularly or even constantly (in the case of zero trust) confirm their identity. Passwords remain the most commonly used method for identity; however, some organizations have begun to deploy passwordless authentication.
For administrator and other privileged accounts, organizations should always use multi-factor authentication (MFA). For the most important data organizations should consider using physical MFA such as magnetic cards, USB tokens and other methods that cannot be stolen or easily replicated by remote attackers.
For organizations using passwords, strong passwords and password management should be used:
- Password complexity (a mix of capitalization, numbers and special characters) or password phrases (much longer passwords) should be required
- Password length should be at least 8 characters, longer for privileged accounts
- Password hashes should be stored encrypted and salted
- Accounts should be locked after repeated and failed login attempts; as many as six for normal user accounts and as little as three for privileged or administrator accounts
- Passwords should expire
Organizations that deploy password managers can require more complexity and more frequent password expirations without worrying about users storing their passwords in unsecured or vulnerable locations. User access should be regularly renewed to prevent access from obsolete and forgotten users or devices.
Privileged Account Management
Administrator access abuse can cause enormous damage so admin credentials must be protected with extra measures. Not only should the password requirements be stronger, but organizations may also need to consider privileged access management (PAM) tools that generate temporary passwords with limited privileges so that authorized users must authenticate every time they access the database.
Whether using specialized tools or not, privileged access should enforce additional rules:
- No password sharing
- All sessions and activities are logged and regularly reviewed
- All user privilege escalation should be logged and regularly reviewed
4. Device Security
All devices that access the database, and the network in general, need to be verified and continuously monitored for potential compromise. Antivirus protection provides the minimum level of protection, but for more protection organizations often deploy endpoint detection and response (EDR) tools or extended detection and response (XDR) tools that provide more proactive detection.
Admin devices should be further constrained by the use of IP and MAC address constriction, whitelisting, or network access control (NAC). These measures limit the number of devices allowed to access sensitive areas to prevent stolen credentials from being as useful to a hacker.
For infrastructure related to the database (or other sensitive systems) the organization should document all devices, applications, and tools. Furthermore, configuration files and source code must be locked down, only accessible by protected admin accounts, and protected by change management policies and tools.
Lastly, all systems should be monitored. Networks should be monitored by XDR or intrusion detection and prevention systems (IDPS) tools. All security systems should feed alerts to security information and event monitoring (SIEM) tools, security operations centers (SOCs), or managed detection and response (MDR) teams.
5. Application and API Security
Applications and APIs connecting to the database or other IT resources must be secured. DevOps should begin by applying vulnerability scanning tools to internally developed websites and applications. Larger organizations will deploy application security tools and API security tools to further protect and monitor systems.
Also read: Application Security: Complete Definition, Types & Solutions
6. Regularly Update Your Operating System And Patches
The best security tools and strategies will be undermined by poor maintenance. All systems, applications, tools, and firmware should be monitored for newly released patches or disclosed vulnerabilities. Critical systems, such as those connecting to database systems, should be prioritized for regular patch management and vulnerability management. Software supply chain components, such as open source libraries, should also be tracked and addressed for vulnerabilities and updates.
7. Business Continuity Best Practices
Even the best plan runs into problems. Whether the issue stems from a disgruntled employee, a malicious hacker, a power failure, or a flood, the best practices of business continuity and disaster recovery design systems for resilience and rapid recovery.
Redundant architecture designs maintain uptime in the event of a system failure. Servers can be made more resilient by using active-passive redundancy for fail-over recovery or by using load balancing servers that split potential loads over multiple servers.
Data and system backups protect against complete system failure or malicious activity. Backups should be regular and highly protected. Best practices follow the 3-2-1 backup rule, with three copies of backup data, two types of storage, and at least one copy stored offsite and offline. There should be absolutely no public access to backups and backups should be encrypted and stored separately from encryption keys.
Backups should include not just data, but also the settings, software applications, and configurations of the supporting infrastructure to enable rapid recovery of affected systems. Backups for mission critical infrastructure should be tested on a regular basis to verify the effectiveness of the backup processes as well as to set benchmarks for recovery expectations.
Also read: Building a Ransomware Resilient Architecture
Bottom Line: Database Security Best Practices
Data breaches can lead to an array of fines, negative business impacts, and lawsuits. Unfortunately, accidents and security events can happen even to prepared companies, and that cost will be directly related to the risks an organization chooses to accept. A good database security practice will offset the increasing risk of data breaches even as attacks and the financial consequences increase. Organizations should review, adopt, and maintain as many best practices as possible to lower their breach risk and reduce the expected costs of future incidents.
Read next: Security Considerations for Data Lakes
This article was originally written by Paul Rubens and was updated by Chad Kime on April 21, 2023.
