为什么数据库安全至关重要
数据库是企业最核心的资产之一，存储着用户个人信息、交易记录、业务数据等敏感内容。一旦数据库遭到攻击，不仅会造成直接的经济损失，还会严重损害企业声誉和用户信任。根据IBM的《数据泄露成本报告》，全球数据泄露的平均成本已超过400万美元。
数据库安全并非单一措施，而是一个覆盖多个层面的系统性工作，包括身份认证、访问控制、数据加密、漏洞管理和安全审计。
访问控制与最小权限原则
最小权限原则（Principle of Least Privilege）是数据库安全的基石。每个用户或应用程序应当只获得完成其工作所必需的最小权限，绝不多给一分。
-- 为只读报表用户创建专用角色
CREATE ROLE readonly_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
-- 为应用程序用户仅授权必要操作
CREATE ROLE app_user;
GRANT SELECT, INSERT, UPDATE ON orders, users TO app_user;
GRANT USAGE ON SEQUENCE orders_id_seq TO app_user;
-- 明确拒绝DROP权限（即使通过public继承也不例外）
REVOKE DELETE ON users FROM app_user;
-- 创建具体用户并绑定角色
CREATE USER report_service WITH PASSWORD 'strong_password_here';
GRANT readonly_user TO report_service;
除角色管理外，还应定期审查并回收不再需要的权限，尤其是离职员工的账号要及时禁用或删除。
SQL注入防护
SQL注入（SQL Injection）是最常见、危害最大的数据库攻击方式之一。攻击者通过在输入字段中嵌入恶意SQL代码，绕过认证或窃取数据。
脆弱的代码示例（绝对避免）：
-- 危险！直接拼接用户输入
SELECT * FROM users WHERE email = '${userInput}' AND password = '${passInput}';
-- 攻击者输入 email = ' OR '1'='1'-- 即可绕过密码验证
安全的参数化查询：
-- PostgreSQL使用$1, $2占位符
SELECT * FROM users WHERE email = $1 AND password_hash = $2;
-- 存储过程进一步隔离业务逻辑
CREATE OR REPLACE FUNCTION authenticate_user(
p_email VARCHAR,
p_password_hash VARCHAR
) RETURNS TABLE(id UUID, name VARCHAR) AS $$
BEGIN
RETURN QUERY
SELECT u.id, u.name FROM users u
WHERE u.email = p_email
AND u.password_hash = p_password_hash
AND u.deleted_at IS NULL;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
始终在应用层使用ORM或预处理语句（Prepared Statements），永远不要将用户输入直接拼接进SQL字符串。
数据加密策略
数据加密分为传输中加密和静态加密两种。
传输中加密：强制使用TLS/SSL连接数据库，禁止明文传输。在PostgreSQL中可通过以下配置实现：
-- 查看当前SSL状态
SHOW ssl;
-- 在pg_hba.conf中要求SSL连接
-- hostssl all all 0.0.0.0/0 scram-sha-256
敏感字段加密：对于特别敏感的数据（如身份证号、信用卡号），应在应用层加密后再存储：
-- 使用pgcrypto扩展进行列级加密
CREATE EXTENSION IF NOT EXISTS pgcrypto;
-- 插入加密数据
INSERT INTO user_sensitive (user_id, id_number_encrypted)
VALUES ($1, pgp_sym_encrypt($2, $3));
-- $3为应用程序持有的加密密钥，不存储在数据库中
-- 查询时解密
SELECT user_id, pgp_sym_decrypt(id_number_encrypted, $1) AS id_number
FROM user_sensitive WHERE user_id = $2;
密码存储：永远不要存储明文密码，应使用bcrypt或Argon2等自适应哈希算法，并加盐处理。
审计日志与异常监控
完整的审计日志是发现安全事件和满足合规要求的必要条件。
-- 创建审计日志表
CREATE TABLE audit_logs (
id BIGSERIAL PRIMARY KEY,
table_name VARCHAR(100) NOT NULL,
operation VARCHAR(10) NOT NULL, -- INSERT/UPDATE/DELETE
user_name VARCHAR(100) NOT NULL,
changed_at TIMESTAMP NOT NULL DEFAULT NOW(),
old_values JSONB,
new_values JSONB,
ip_address INET
);
-- 通用审计触发器函数
CREATE OR REPLACE FUNCTION audit_trigger_func()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO audit_logs(table_name, operation, user_name, old_values, new_values)
VALUES (
TG_TABLE_NAME,
TG_OP,
current_user,
CASE WHEN TG_OP != 'INSERT' THEN row_to_json(OLD) END,
CASE WHEN TG_OP != 'DELETE' THEN row_to_json(NEW) END
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
-- 为敏感表附加审计触发器
CREATE TRIGGER users_audit
AFTER INSERT OR UPDATE OR DELETE ON users
FOR EACH ROW EXECUTE FUNCTION audit_trigger_func();
建议将审计日志存储在独立的数据库或只追加（append-only）存储中，防止攻击者在入侵后篡改日志。
使用Erdmates可视化安全设计
在Erdmates中设计数据库时，可以直观地规划敏感表的权限结构、审计日志的关联关系，以及加密字段的标注。清晰的ERD不仅帮助开发团队理解数据流向，也便于安全评审人员快速识别高风险区域。
数据库安全是一项持续的工程，需要定期进行安全审计、及时更新补丁、模拟渗透测试，以及对全体人员的安全意识培训。防护不是一次性的工作，而是贯穿整个数据库生命周期的持续实践。