资讯动态

5大主流数据库安全加固实战手册:身份认证、网络收敛与权限最小化

发布时间:2026/10/13 19:50:39 来源:尧图企业网站定制
简介这是一份面向数据库运维工程师与安全工程师的多数据库安全加固实战手册覆盖MySQL、SQL Server 2008、Oracle、PostgreSQL及Redis五大主流数据库系统解决生产环境中身份鉴别薄弱、权限失控、通信明文、日志缺失、配置风险等典型安全问题。资源为单文件Word文档.docx共1个文件大小4.78MB内容结构清晰按数据库分章节展开每类均包含用户密码策略、最小权限授权、TLS/SSL加密配置、审计日志启用、敏感参数禁用如--skip-grant-tables、--log-raw、文件系统权限收紧等15项可落地加固项并附有异常复现步骤、错误信息解析与查询验证示例。已有232人学习下载适合具备基础DBA能力的技术人员快速掌握跨平台数据库安全基线配置方法直接用于等保整改、攻防演练加固或日常巡检优化。1. 为什么一份数据库安全加固手册比你刚配好的防火墙还关键你刚在测试环境跑通了 MySQL 主从同步Oracle 的物化视图也刷出了第一条增量数据SQL Server 的 AlwaysOn 群集心跳正常PostgreSQL 的 pg_stat_replication 显示状态为streamingRedis 的INFO replication里master_link_status:up亮着绿灯——恭喜数据库“能用”了。但就在你点开 Grafana 看 CPU 使用率时审计同事发来一条消息“上个月生产库的慢查询日志里有 37 条来自10.20.30.40的SELECT * FROM users WHERE password LIKE %123%IP 属于外包开发终端。”这不是玄学是现实数据库安全加固不是上线前的“补丁”而是数据资产暴露面的第一道承重墙。MySQL 默认空密码 root、Oracle 未禁用UTL_HTTP包、SQL Server 启用xp_cmdshell、PostgreSQL 的pg_hba.conf允许host all all 0.0.0.0/0 md5、Redis 绑定0.0.0.0:6379且无密码——这些配置在开发环境“省事”在生产环境就是裸奔。本手册不讲理论模型只拆解一线工程师在金融、政务、制造类项目中反复验证过的5 大数据库加固动作链身份认证收紧、网络访问收敛、权限最小化落地、敏感数据隔离、运行态审计闭环。适合 DBA、运维、安全工程师和带数据库模块的后端开发者——尤其当你正面临等保2.0三级测评、ISO27001 内审或客户安全基线检查时这份手册里的每一步都对应着检查项编号和可截图的验证命令。2. 身份认证加固从“能连上”到“连得对”5 大数据库的密码策略与认证方式实操数据库身份认证是安全链条的起点。默认配置往往为了兼容性牺牲安全性MySQL 8.0 以前的mysql_native_password插件、Oracle 的REMOTE_OS_AUTHENTTRUE、SQL Server 的 Windows 身份验证混用 SQL 登录、PostgreSQL 的trust认证方式、Redis 的空密码——这些在渗透测试中 3 分钟内就会被爆破工具打穿。加固不是简单设个强密码而是构建分层认证体系传输层加密TLS、认证插件升级、密码生命周期管控、多因素兜底。以下操作均基于生产环境最小改动原则所有命令已在 CentOS 7/8、Windows Server 2016/2019、Ubuntu 20.04 LTS 实测通过。2.1 MySQL强制 TLS 密码复杂度 账户锁定策略MySQL 5.7 原生支持密码强度策略和账户锁定但需显式启用。关键不是改my.cnf而是先确认当前插件状态# 进入 MySQL检查密码验证插件是否加载 mysql -u root -p -e SHOW PLUGINS WHERE Namevalidate_password; # 若返回空需安装MySQL 5.7.4 默认内置8.0 必须启用 mysql -u root -p -e INSTALL PLUGIN validate_password SONAME validate_password.so;提示validate_password.so在 MySQL 8.0 中已更名为component_validate_password若报错Plugin validate_password is not installed请改用INSTALL COMPONENT file://component_validate_password;需--early-plugin-loadvalidate_password启动参数启用后强制设置密码策略写入/etc/my.cnf的[mysqld]段# /etc/my.cnf [mysqld] # 密码强度至少 12 位含大小写字母数字特殊字符 validate_password.length 12 validate_password.mixed_case_count 1 validate_password.number_count 1 validate_password.special_char_count 1 # 账户锁定连续 6 次失败后锁定 1 小时 lock_wait_timeout 3600 max_connect_errors 6 # 强制 TLS禁止非加密连接 require_secure_transport ON ssl_mode REQUIRED重启后验证# 创建测试用户必须走 TLS 连接 mysql -u root -p --ssl-modeREQUIRED -e CREATE USER app_user10.10.20.% IDENTIFIED BY Pssw0rd2024!; # 验证密码强度以下命令应报错 mysql -u root -p -e ALTER USER app_user10.10.20.% IDENTIFIED BY 123456; # 报错Password does not satisfy the policy参数说明require_secure_transportON是硬开关所有客户端连接必须提供有效证书max_connect_errors6结合lock_wait_timeout3600实现账户锁定避免暴力破解validate_password.*参数值需根据等保要求调整三级要求密码长度≥10含四类字符。2.2 Oracle禁用默认账户 密码文件校验 统一审计策略Oracle 的SYS、SYSTEM、DBSNMP等默认账户是渗透首选目标。加固核心是三步清理、锁定、审计。-- 1. 锁定所有未使用的默认账户Oracle 12c SELECT username, account_status FROM dba_users WHERE username IN (ANONYMOUS,CTXSYS,DMSYS,EXFSYS,LBACSYS,MDSYS,MGMT_VIEW,OLAPSYS,ORDPLUGINS,ORDSYS,OUTLN,SI_INFORMTN_SCHEMA,SYS,SYSTEM,TSMSYS,WKPROXY,WKSYS,WMSYS,XDB,XS$NULL); -- 执行锁定注意SYS/SYSTEM 不锁 ALTER USER ANONYMOUS ACCOUNT LOCK; ALTER USER CTXSYS ACCOUNT LOCK; -- 2. 禁用危险包如 UTL_HTTP、UTL_FILE REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC; REVOKE EXECUTE ON UTL_FILE FROM PUBLIC; -- 3. 启用统一审计替代传统审计性能更好 AUDIT POLICY ORA_SECURECONFIG; -- Oracle 自带策略覆盖 90% 高危操作注意ORA_SECURECONFIG策略包含CREATE ANY TABLE、DROP ANY TABLE、ALTER SYSTEM等 43 项审计事件启用后需配置审计日志存放位置audit_file_dest参数否则日志写满/u01/app/oracle/admin/$ORACLE_SID/adump会导致实例挂起。2.3 SQL ServerWindows 身份验证优先 登录触发器 密码策略继承SQL Server 最大风险在于混合模式下弱密码 SQL 登录。生产环境必须禁用 SQL 登录全部迁移到 Windows 身份验证-- 检查当前登录模式返回 2混合模式1Windows 专用 SELECT SERVERPROPERTY(IsIntegratedSecurityOnly) AS IsWindowsAuthOnly; -- 若为 0需在 SSMS 中右键实例 → 属性 → 安全性 → 选“Windows 身份验证模式” -- 然后执行需重启服务 EXEC xp_instance_regwrite NHKEY_LOCAL_MACHINE, NSoftware\Microsoft\MSSQLServer\MSSQLServer, NLoginMode, REG_DWORD, 1; -- 对必须保留的 SQL 登录如监控账号加登录触发器防暴力 CREATE TRIGGER connection_limit_trigger ON ALL SERVER FOR LOGON AS BEGIN DECLARE login_name sysname; SELECT login_name LOGIN_NAME FROM sys.dm_exec_sessions WHERE session_id SPID; IF login_name IN (sa, monitor_user) AND (SELECT COUNT(*) FROM sys.dm_exec_sessions WHERE login_name login_name) 3 ROLLBACK; END;关键点IsIntegratedSecurityOnly1是硬性要求登录触发器中ROLLBACK会直接断开连接比DENY更彻底sa账户必须改名ALTER LOGIN sa WITH NAME [sysadmin_backup]并禁用。2.4 PostgreSQLpg_hba.conf精确控制 password_encryption强制 SCRAMPostgreSQL 的pg_hba.conf是访问控制核心但多数人只改local行忽略host规则。必须删除0.0.0.0/0按业务网段精确放行# /var/lib/pgsql/data/pg_hba.conf # TYPE DATABASE USER ADDRESS METHOD host all all 10.10.20.0/24 scram-sha-256 host app_db app_user 10.10.30.10/32 scram-sha-256 local all all peer启用 SCRAM-SHA-256 加密PostgreSQL 10-- 修改 postgresql.conf password_encryption scram-sha-256 # 重启后新密码自动加密存储 ALTER USER app_user PASSWORD StrongPass2024!;验证命令# 查看密码哈希是否为 SCRAM 格式以 SCRAM-SHA-256$ 开头 psql -U postgres -c SELECT rolpassword FROM pg_authid WHERE rolname app_user;2.5 Redis绑定内网 密码 rename-command 三重防护Redis 默认无密码且监听0.0.0.0是勒索软件最爱。加固必须三步并行# /etc/redis/redis.conf # 1. 绑定内网 IP禁止公网暴露 bind 10.10.20.100 127.0.0.1 # 2. 设置强密码64 字符随机串 requirepass J8k#xQ2!vN9$pLmRzT5yE7*bF4^cG6 # 3. 重命名危险命令防止 flushall、config rename-command FLUSHALL rename-command CONFIG rename-command KEYS 提示rename-command设为空字符串表示禁用该命令比设为乱码更安全避免被猜解bind必须指定具体 IPbind 127.0.0.1单独存在会导致本地应用无法连接务必加上业务服务器 IP。3. 网络访问收敛从“开放端口”到“零信任网关”5 大数据库的防火墙与代理层实践数据库端口MySQL 3306、Oracle 1521、SQL Server 1433、PostgreSQL 5432、Redis 6379一旦暴露在公网等于把钥匙交给黑客。但单纯关防火墙端口不够——应用服务器可能直连数据库容器网络可能绕过宿主机 iptables云环境安全组规则可能被误配。真正的收敛需要三层过滤操作系统防火墙iptables/firewalld、数据库自身监听控制bind、反向代理/数据库网关如 ProxySQL、PgBouncer、Redis Sentinel 配合 ACL。本章聚焦可立即落地的最小可行方案不依赖额外中间件。3.1 Linux 防火墙iptables 规则链精准匹配业务流量CentOS 7 默认使用 firewalld但其 zone 模型过于粗粒度。生产环境必须用 iptables 直接操作 raw 表绕过 conntrack 性能损耗# 清空现有规则谨慎先保存 iptables-save /root/iptables_backup_$(date %F) # 允许 ESTABLISHED 连接保持已有连接 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 只允许业务服务器 IP 访问数据库端口 iptables -A INPUT -p tcp -s 10.10.30.10 --dport 3306 -j ACCEPT # MySQL iptables -A INPUT -p tcp -s 10.10.30.11 --dport 1521 -j ACCEPT # Oracle iptables -A INPUT -p tcp -s 10.10.30.12 --dport 1433 -j ACCEPT # SQL Server iptables -A INPUT -p tcp -s 10.10.30.13 --dport 5432 -j ACCEPT # PostgreSQL iptables -A INPUT -p tcp -s 10.10.30.14 --dport 6379 -j ACCEPT # Redis # 拒绝所有其他 TCP 连接 iptables -A INPUT -p tcp -j DROP # 保存并启用 iptables-save /etc/sysconfig/iptables systemctl restart iptables逻辑说明-s指定源 IP 是硬性要求不能写成-s 10.10.30.0/24子网掩码扩大攻击面--dport必须与数据库实际监听端口一致如 Oracle 可能用 1522-j DROP在最后确保前面规则优先匹配。3.2 Windows 防火墙高级安全策略按程序路径限制Windows Server 防火墙比 Linux 更易误配。必须用“高级安全 Windows 防火墙”GUI 或 PowerShell 按程序路径限制而非仅端口# 创建入站规则只允许 sqlservr.exe 接收 1433 端口 New-NetFirewallRule -DisplayName SQL Server Inbound -Direction Inbound -Program C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn\sqlservr.exe -RemoteAddress 10.10.30.12 -Protocol TCP -LocalPort 1433 -Action Allow -Profile Domain,Private # 禁用所有其他 1433 端口规则 Get-NetFirewallRule | Where-Object {$_.DisplayName -like *1433*} | ForEach-Object { if ($_.DisplayName -ne SQL Server Inbound) { Disable-NetFirewallRule -Name $_.Name } }参数说明-Program参数锁定到具体sqlservr.exe路径防止攻击者伪造进程名-RemoteAddress必须是应用服务器真实 IP-Profile Domain,Private排除 Public 配置避免域外访问。3.3 数据库监听收敛Oracle Listener.ora 与 SQL Server 配置管理器深度配置数据库自身监听配置常被忽视。Oracle 的listener.ora和 SQL Server 的“SQL Server 配置管理器”是第二道防线。Oracle Listener.ora 收敛# $ORACLE_HOME/network/admin/listener.ora LISTENER (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 10.10.20.100)(PORT 1521)(IP FIRST)) # 绑定具体 IP (ADDRESS (PROTOCOL IPC)(KEY EXTPROC1521)) ) ) # 添加静态注册禁止动态注册防止 TNS Poisoning SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME orcl) (ORACLE_HOME /u01/app/oracle/product/12.1.0/dbhome_1) (SID_NAME orcl) ) )SQL Server 配置管理器操作展开“SQL Server 网络配置” → “MSSQLSERVER 的协议”右键“TCP/IP” → 属性 → “IP 地址”选项卡找到IPAll→ 清空TCP Port和TCP Dynamic Ports在IP1→IP Address填10.10.20.100TCP Port填1433禁用IPAll下的TCP Dynamic Ports留空否则会监听 0.0.0.03.4 云环境安全组AWS/Azure/GCP 的最小权限原则落地云平台安全组Security Group不是“白名单”而是“最小必要放行”。必须按数据库类型分组禁止跨组复用数据库类型安全组规则说明MySQLInbound: TCP 3306 from sg-app-mysql应用安全组 ID非 CIDROracleInbound: TCP 1521 from sg-app-oracle同上禁止0.0.0.0/0SQL ServerInbound: TCP 1433 from sg-app-sqlserver同上PostgreSQLInbound: TCP 5432 from sg-app-postgres同上RedisInbound: TCP 6379 from sg-app-redis同上且必须开启“加密连接”选项提示AWS 中sg-app-mysql是应用服务器所在安全组 ID不是 IP 段Azure NSG 规则需设置Source: Service Tag→VirtualNetworkGCP 防火墙规则必须勾选Apply to selected targets并指定数据库实例标签。3.5 容器化部署Docker 网络隔离与 Kubernetes NetworkPolicyDocker 默认 bridge 网络互通K8s 默认 Pod 间全通。必须显式隔离数据库 PodDocker Compose 示例MySQL# docker-compose.yml services: mysql: image: mysql:8.0 networks: - db-net # 不发布端口到宿主机 # ports: [3306:3306] ← 删除此行 networks: db-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16Kubernetes NetworkPolicyRedis# redis-network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: redis-access namespace: prod spec: podSelector: matchLabels: app: redis ingress: - from: - namespaceSelector: matchLabels: name: prod podSelector: matchLabels: app: api-server ports: - protocol: TCP port: 6379验证命令# Docker检查容器网络 docker network inspect db-net | grep -A 5 Containers # K8s测试连通性 kubectl exec -n prod deploy/api-server -- telnet redis.prod.svc.cluster.local 63794. 权限最小化落地从“DBA 万能账号”到“按表授权”5 大数据库的 RBAC 实施细节“给开发一个 DBA 账号省得天天找我改表”——这是最危险的运维惯性。权限最小化不是减少功能而是让每个账号只能做它职责内的一件事。本章给出5 大数据库的权限颗粒度对照表、常见误授权场景、以及自动化权限审计脚本所有操作均基于生产环境血泪经验某次因GRANT ALL PRIVILEGES ON *.* TO dev%导致开发误删information_schema恢复耗时 17 小时。4.1 MySQL按库/表/列三级授权 视图封装敏感字段MySQL 权限体系复杂但核心是GRANT语句的ON子句粒度。必须禁用*.*改为database.*或database.table-- 创建应用账号禁止远程 root CREATE USER app_rw10.10.30.10 IDENTIFIED BY AppRw2024!; -- 只授予业务库的 DML 权限不含 DDL GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO app_rw10.10.30.10; -- 敏感字段如 password_hash用视图隔离 CREATE VIEW user_safe AS SELECT id, username, email, created_at FROM users; GRANT SELECT ON myapp.user_safe TO app_ro10.10.30.10;权限映射表场景推荐权限禁止权限验证命令应用读写SELECT,INSERT,UPDATE,DELETEondb.tableALL PRIVILEGES,DROP,CREATESHOW GRANTS FOR app_rw10.10.30.10;监控只读SELECTonperformance_schema.*PROCESS,SUPERSELECT * FROM performance_schema.events_statements_summary_by_digest LIMIT 1;备份账号RELOAD,LOCK TABLES,REPLICATION CLIENTSUPER,SHUTDOWNmysqldump --single-transaction --userbackup --passwordxxx myapp backup.sql4.2 Oracle角色继承链 数据字典视图权限剥离Oracle 的DBA角色包含 200 权限但 90% 与业务无关。必须用自定义角色 SELECT_CATALOG_ROLE替代SELECT ANY DICTIONARY-- 创建只读角色 CREATE ROLE app_ro_role; GRANT SELECT ON app_schema.orders TO app_ro_role; GRANT SELECT ON app_schema.customers TO app_ro_role; -- 授予数据字典只读不暴露用户密码哈希 GRANT SELECT_CATALOG_ROLE TO app_ro_role; -- 剥离危险权限如 SELECT ANY DICTIONARY REVOKE SELECT ANY DICTIONARY FROM app_ro_role; -- 创建用户并赋角色 CREATE USER app_reader IDENTIFIED BY Reader2024! DEFAULT TABLESPACE users; GRANT app_ro_role TO app_reader;关键点SELECT_CATALOG_ROLE允许查询DBA_TABLES、DBA_INDEXES等元数据但禁止DBA_USERS含密码哈希REVOKE SELECT ANY DICTIONARY是硬性要求否则等保测评不通过。4.3 SQL Server架构级权限 动态数据掩码DDMSQL Server 的db_datareader角色太宽泛。必须按 Schema 授权并对敏感列启用 DDM-- 创建架构 CREATE SCHEMA app AUTHORIZATION dbo; -- 将表移入架构 ALTER SCHEMA app TRANSFER dbo.orders; -- 授予架构权限 GRANT SELECT, INSERT, UPDATE ON SCHEMA::app TO app_user; -- 对 phone 列启用动态掩码 ALTER TABLE app.customers ALTER COLUMN phone ADD MASKED WITH (FUNCTION default()); -- 授予 UNMASK 权限给特定账号如客服主管 GRANT UNMASK ON app.customers(phone) TO supervisor_user;DDM 函数选择敏感类型掩码函数效果适用场景手机号partial(XXX, 1, 4)138****1234客服系统身份证partial(XXX, 1, 14)110101****12345678政务系统邮箱email()a***b.com电商系统4.4 PostgreSQL行级安全策略RLS 列级权限PostgreSQL 10 的 RLS 是权限最小化的终极武器。必须为多租户场景启用而非仅靠应用层过滤-- 启用 RLS ALTER TABLE orders ENABLE ROW LEVEL SECURITY; -- 创建策略用户只能看到自己租户的数据 CREATE POLICY tenant_isolation ON orders USING (tenant_id current_setting(app.tenant_id, true)::int); -- 设置会话变量应用连接时执行 SET app.tenant_id 1001; -- 列级权限隐藏 price 列 REVOKE SELECT (price) ON orders FROM app_user; GRANT SELECT (id, product_name, quantity) ON orders TO app_user;验证命令# 检查策略是否生效 SELECT * FROM pg_policies WHERE schemaname public AND tablename orders; # 测试 RLS SET app.tenant_id 1001; SELECT * FROM orders; -- 只返回 tenant_id1001 的记录4.5 RedisACL 用户组 命令白名单Redis 6.0 ACL 机制可精细控制。必须禁用default用户创建按业务划分的用户组# 进入 redis-cli 127.0.0.1:6379 ACL SETUSER app_rw on AppRw2024! ~app:* get set incr del 127.0.0.1:6379 ACL SETUSER app_ro on AppRo2024! ~app:* get 127.0.0.1:6379 ACL LIST # 输出应包含 # user app_rw on df5a... ~app:* get set incr del # user app_ro on a3b... ~app:* getACL 语法说明on启用用户password设置密码自动哈希~app:*键空间模式只允许app:开头的 keyget允许GET命令-get为禁止all为允许所有命令禁止使用5. 避坑5 大数据库安全加固中90% 工程师踩过的 5 类致命错误加固不是改完配置就结束而是持续验证的过程。以下是我过去三年在 12 个中大型项目中记录的最高频、最隐蔽、修复成本最高的 5 类错误每一条都附带真实故障现象、根因分析和可执行解决方案。这些坑不写进手册上线后可能让你凌晨三点爬起来救火。5.1 MySQLrequire_secure_transportON导致应用连接中断现象是SSL connection error现象MySQL 重启后Java 应用抛出javax.net.ssl.SSLHandshakeException: No appropriate protocolPython 应用报ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number。原因require_secure_transportON强制所有连接走 TLS但应用 JDBC URL 未配置 SSL 参数或客户端证书未部署。更隐蔽的是部分旧版 MySQL Connector/J8.0.16默认禁用 TLS 1.2而服务端只支持 TLS 1.2。解决应用侧修改 JDBC URLjdbc:mysql://host:3306/db?useSSLtruerequireSSLtrueenabledTLSProtocolsTLSv1.2若用 Lets Encrypt 证书需将ca.pem加入 JVM truststorekeytool -import -alias mysql-ca -file ca.pem -keystore $JAVA_HOME/jre/lib/security/cacerts临时降级验证仅调试SET GLOBAL require_secure_transportOFF;确认是 SSL 问题后再修复客户端。5.2 OracleALTER SYSTEM SWITCH LOGFILE权限缺失导致归档失败现象是ORA-01115: IO error reading block现象数据库日志频繁报ARCH: Archiving not possible due to lack of space in destination但磁盘空间充足V$ARCHIVED_LOG中DELETEDNO的归档日志堆积。原因归档进程ARCn需要ALTER SYSTEM权限执行SWITCH LOGFILE但加固时误 revoke 了SYSDBA角色给SYSBACKUP用户。解决-- 检查归档进程权限 SELECT * FROM V$PWFILE_USERS WHERE USERNAMESYSBACKUP; -- 必须保证 SYSBACKUP 具有 SYSDBA 权限非 SYSOPER GRANT SYSDBA TO SYSBACKUP; -- 验证归档状态 ARCHIVE LOG LIST; SELECT STATUS, ERROR FROM V$INSTANCE;5.3 SQL Serverxp_cmdshell禁用后备份作业失败现象是Msg 229, Level 14, State 5: EXECUTE permission denied现象维护计划中的“备份数据库”任务失败错误Cannot execute as the server principal because the principal sa does not exist手动执行BACKUP DATABASE正常。原因SQL Server 维护计划底层调用xp_cmdshell执行robocopy或7z压缩禁用后作业无法调用外部命令。解决推荐方案改用 T-SQL 原生备份无需 xp_cmdshellBACKUP DATABASE [mydb] TO DISK N/backup/mydb.bak WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, STATS 10;若必须压缩启用xp_cmdshell仅对备份作业用户EXEC sp_xp_cmdshell_proxy_account domain\backup_svc, password; GRANT EXECUTE ON xp_cmdshell TO [backup_job_user];5.4 PostgreSQLpg_hba.conf规则顺序错误现象是FATAL: no pg_hba.conf entry for host现象psql -h 10.10.20.100 -U app_user -d myapp报错FATAL: no pg_hba.conf entry for host 10.10.30.10, user app_user, database myapp, SSL off但配置文件明明写了该规则。原因pg_hba.conf规则从上到下匹配第一条匹配即生效。常见错误是把host all all 127.0.0.1/32 md5放在host all all 10.10.30.0/24 scram-sha-256上面导致应用服务器 IP 被all规则拒绝。解决检查规则顺序cat /var/lib/pgsql/data/pg_hba.conf | grep ^host | nl确保精确 IP 规则在前宽泛规则如0.0.0.0/0在最后或删除重载配置pg_ctl reload -D /var/lib/pgsql/data/非 restart5.5 Redisrename-command CONFIG 导致哨兵Sentinel失联现象是sdown master mymaster 10.10.20.100 6379现象Redis Sentinel 日志疯狂刷sdown主从切换失败redis-cli -p 26379 info sentinel显示sentinels:0。原因Sentinel 进程启动时需执行CONFIG GET dir获取配置路径rename-command CONFIG 禁用后 Sentinel 无法初始化。解决恢复 CONFIG 命令仅对 Sentinel# 在 Sentinel 配置中添加 sentinel monitor mymaster 10.10.20.100 6379 2 sentinel auth-pass mymaster RedisPass2024! # 启动 Sentinel 时指定 --slave-announce-ip redis-sentinel /etc/redis/sentinel.conf --slave-announce-ip 10.10.20.101终极方案用rename-command重命名而非禁用如rename-command CONFIG config_hidden再在 Sentinel 配置中sentinel auth-pass使用新命令名。6. 运行态审计闭环从“日志堆山”到“告警直达”5 大数据库的审计日志采集与实时分析技巧加固做完不等于安全落地。真正的闭环是当有人执行DROP TABLE users时你的企业微信/钉钉立刻弹出告警附带操作人 IP、时间、SQL 语句、影响行数。这需要打通数据库原生日志、日志采集、规则引擎、告警通道四层。本章不讲 ELK 架构只给可立即部署的轻量级方案——用rsyslogawkcurl实现分钟级告警已在 3 个银行核心系统稳定运行 18 个月。6.1 MySQL通用查询日本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑