Skip to content

Database Security Cheat Sheet / 数据库安全速查表

Introduction / 介绍

This cheat sheet provides guidance for securely configuring SQL databases such as MySQL, PostgreSQL, MariaDB, and Microsoft SQL Server. It is designed primarily for application developers and system administrators responsible for managing or interacting with relational databases.

本速查表提供了安全配置 SQL 数据库（如 MySQL、PostgreSQL、MariaDB 和 Microsoft SQL Server）的指导。它主要面向负责管理或与关系型数据库交互的应用程序开发人员和系统管理员。

For application-layer injection defenses, see the SQL Injection Prevention Cheat Sheet. For guidance on non-relational systems (e.g., MongoDB, Redis, Cassandra, DynamoDB), refer to the NoSQL Security Cheat Sheet

有关应用层注入防御，请参阅SQL 注入预防速查表。有关非关系型系统（例如 MongoDB、Redis、Cassandra、DynamoDB）的指导，请参考NoSQL 安全速查表

Protecting the Backend Database / 保护后端数据库

The application's backend database should be isolated from other servers and only connect with as few hosts as possible. This task will depend on the system and network architecture. Consider these suggestions:

应用程序的后端数据库应与其他服务器隔离，并且只与尽可能少的宿主机连接。这项任务将取决于系统和网络架构。请考虑以下建议：

  • Disabling network (TCP) access and requiring all access is over a local socket file or named pipe.
    中文：禁用网络（TCP）访问，并要求所有访问都通过本地套接字文件或命名管道进行。
  • Configuring the database to only bind on localhost.
    中文：配置数据库只绑定到 localhost。
  • Restricting access to the network port to specific hosts with firewall rules.
    中文：通过防火墙规则限制对网络端口的访问，仅允许特定宿主机访问。
  • Placing the database server on a dedicated internal network segment that is isolated from the application server.
    中文：将数据库服务器放置在专用内部网络段，该网络段与应用服务器隔离。
  • Protect any web-based management tools (e.g., phpMyAdmin, pgAdmin) with authentication, HTTPS, and network restrictions.
    中文：使用身份验证、HTTPS和网络限制来保护任何基于Web的管理工具（例如phpMyAdmin、pgAdmin）。

When an application is running on an untrusted system (such as a thick-client), it should always connect to the backend through an API that can enforce appropriate access control and restrictions. Direct connections should never be made from a thick client to the backend database.

当应用程序在不受信任的系统（例如肥客户端）上运行时，它应始终通过可以执行适当访问控制和限制的API连接到后端。肥客户端不应直接连接到后端数据库。

Implementing Transport Layer Protection / 实施传输层保护

Most database default configurations start with unencrypted network connections, though some do encrypt the initial authentication (such as Microsoft SQL Server). Even if the initial authentication is encrypted, the rest of the traffic will be unencrypted and all kinds of sensitive information will be sent across the network in clear text. The following steps should be taken to prevent unencrypted traffic:

大多数数据库默认配置以未加密的网络连接开始，尽管一些配置加密了初始身份验证（例如Microsoft SQL Server）。即使初始身份验证已加密，其余流量仍将未加密，所有敏感信息将以明文形式通过网络发送。应采取以下步骤来防止未加密的流量：

  • Configure the database to only allow encrypted connections.
    中文：配置数据库以仅允许加密连接。
  • Install a trusted digital certificate on the server.
    中文：在服务器上安装受信任的数字证书。
  • The client application should connect using TLSv1.2+ with modern ciphers (e.g, AES-GCM or ChaCha20).
    中文：客户端应用程序应使用TLSv1.2+和现代加密算法（例如AES-GCM或ChaCha20）进行连接。
  • The client application should verify that the digital certificate is correct.
    中文：客户端应用程序应验证数字证书是否正确。

The Transport Layer Security Cheat Sheet contains further guidance on securely configuring TLS.

传输层安全性速查表 包含有关安全配置 TLS 的进一步指导。

Configuring Secure Authentication / 配置安全身份验证

The database should always require authentication, including connections from the local server. Database accounts should be:

数据库应始终要求身份验证，包括来自本地服务器的连接。数据库账户应：

  • Protected with strong and unique passwords.
    中文：使用强密码和唯一密码进行保护。
  • Used by a single application or service.
    中文：仅由单个应用程序或服务使用。
  • Configured with the minimum permissions required as discussed in the permissions section below.
    中文：配置为所需的最小权限，如以下权限部分所述。

As with any system that has its own user accounts, the usual account management processes should be followed, including:

与任何具有其自身用户账户的系统一样，应遵循常规账户管理流程，包括：

  • Regular reviews of the accounts to ensure that they are still required.
    中文：定期审查账户以确保其仍然需要。
  • Regular reviews of permissions.
    中文：定期审查权限。
  • Removing user accounts when an application is decommissioned.
    中文：在应用程序停用时删除用户账户。
  • Changing the passwords when staff leave, or there is reason to believe that they may have been compromised.
    中文：当员工离职或存在理由相信其可能已被泄露时更改密码。

For Microsoft SQL Server, consider the use of Windows or Integrated-Authentication, which uses existing Windows accounts rather than SQL Server accounts. This also removes the requirement to store credentials in the application, as it will connect using the credentials of the Windows user it is running under. The Windows Native Authentication Plugins provides similar functionality for MySQL.

对于Microsoft SQL Server，考虑使用Windows或集成身份验证，它使用现有的Windows账户而不是SQL Server账户。这还消除了在应用程序中存储凭证的需求，因为它将使用运行其下的Windows用户的凭证进行连接。MySQL的Windows原生身份验证插件提供了类似的功能。

Storing Database Credentials Securely / 安全存储数据库凭证

Database credentials should never be stored in the application source code, especially if they are unencrypted. Instead, they should be stored in a configuration file that:

数据库凭证不应存储在应用程序源代码中，尤其是如果它们未加密。相反，它们应存储在配置文件中，该文件：

  • Is outside of the web root.
    中文：位于Web根目录之外。
  • Has appropriate permissions so that it can only be read by the required user(s).
    中文：具有适当的权限，以确保只能由所需的用户读取。
  • Is not checked into source code repositories.
    中文：未检查到源代码仓库中。

Where possible, these credentials should also be encrypted or otherwise protected using built-in functionality, such as the web.config encryption available in ASP.NET.

在可能的情况下，还应使用内置功能（如ASP.NET中可用的web.config加密）对凭证进行加密或以其他方式保护。

Creating Secure Permissions / 创建安全权限

When developers are assigning permissions to database user accounts, they should employ the principle of least privilege (i.e, the accounts should only have the minimal permissions required for the application to function). This principle can be applied at a number of increasingly granular levels depending on the functionality available in the database. You can do the following in all environments:

当开发者为数据库用户账户分配权限时，应采用最小权限原则（即，账户应仅具有应用程序运行所需的最小权限）。这一原则可以根据数据库中可用的功能在多个越来越细粒度的级别上应用。在所有环境中，您可以执行以下操作：

  • Do not use the built-in root, sa or SYS accounts.
    中文：不要使用内置的root、sa或SYS账户。
  • Do not grant the account administrative rights over the database instance.
    中文：不要授予账户对数据库实例的行政权限。
  • Make sure the account can only connect from allowed hosts. This would often be localhost or the address of the application server.
    中文：确保账户只能从允许的主机连接。这通常是localhost或应用程序服务器的地址。
  • The account should only access the specific databases it needs. Development, UAT and Production environments should all use separate databases and accounts.
    中文：账户应仅访问其所需的特定数据库。开发、UAT 和生产环境都应使用独立的数据库和账户。
  • Only grant the required permissions on the databases. Most applications would only need SELECT, UPDATE and DELETE permissions. The account should not be the owner of the database as this can lead to privilege escalation vulnerabilities.
    中文：仅在数据库上授予所需的权限。大多数应用程序只需要 SELECT、UPDATE 和 DELETE 权限。账户不应成为数据库的所有者，因为这可能导致权限提升漏洞。
  • Avoid using database links or linked servers. Where they are required, use an account that has been granted access to only the minimum databases, tables, and system privileges required.
    中文：避免使用数据库链接或链接服务器。如果需要，请使用仅被授予访问所需的最小数据库、表和系统权限的账户。

Most security-critical applications, apply permissions at more granular levels, including:

大多数安全关键型应用程序，应在更细粒度的级别上应用权限，包括：

  • Table-level permissions.
    中文：表级权限。
  • Column-level permissions.
    中文：列级权限。
  • Row-level permissions
    中文：行级权限
  • Blocking access to the underlying tables, and requiring all access through restricted views.
    中文：阻止对底层表的访问，并要求所有访问都通过受限的视图进行。

Database Configuration and Hardening / 数据库配置和加固

The database server's underlying operating system should be hardened by basing it on a secure baseline such as the CIS Benchmarks or the Microsoft Security Baselines.

数据库服务器的底层操作系统应基于安全基线进行加固，例如CIS基准或微软安全基线。

The database application should also be properly configured and hardened. The following principles should apply to any database application and platform:

数据库应用程序也应进行适当的配置和加固。以下原则应适用于任何数据库应用程序和平台：

  • Install any required security updates and patches.
    中文：安装所有必需的安全更新和补丁。
  • Configure the database services to run under a low privileged user account.
    中文：将数据库服务配置为以低权限用户账户运行。
  • Remove any default accounts and databases.
    中文：删除任何默认账户和数据库。
  • Store transaction logs on a separate disk to the main database files.
    中文：将事务日志存储在主数据库文件之外的独立磁盘上。
  • Configure a regular backup of the database. Ensure that the backups are protected with appropriate permissions, and ideally encrypted.
    中文：配置数据库的定期备份。确保备份受到适当的权限保护，并且最好进行加密。

The following sections give some further recommendations for specific database software, in addition to the more general recommendations given above.

以下部分提供了一些针对特定数据库软件的进一步建议，除了上述更通用的建议之外。

Hardening a Microsoft SQL Server / 加固微软SQL服务器

Hardening a MySQL or a MariaDB Server / 加固 MySQL 或 MariaDB 服务器

  • Run the mysql_secure_installation script to remove the default databases and accounts.
    中文：运行 mysql_secure_installation 脚本以移除默认数据库和账户。
  • Disable the FILE privilege for all users to prevent them reading or writing files.
    中文：禁用所有用户的FILE权限，以防止他们读取或写入文件。
  • See the Oracle MySQL and MariaDB hardening guides.
    中文：参阅Oracle MySQL和MariaDB的安全加固指南。

Hardening a PostgreSQL Server / 加固 PostgreSQL 服务器

MongoDB

Redis

References / 参考