Frank2024-08-21 来自四川在公网容易被攻击。还有其他风险吗？作者回复: 1. 被攻击。 2. 数据被窃取。 如果网络传输没加密，客户端和数据库之间的TCP流量如果被抓取了，可以解析出客户端执行的SQL语句、服务端返回的数据。
Amosヾ2024-08-21 来自广东非专业回答： 风险一：任意来源访问，数据库被爆破登录 规避方案：授权尽量不使用 %，越精确越好 风险二：数据传输过程中被拦截捕获 规范方案：SSL 加密传输作者回复: 这两点确实是数据库放公网最大的风险。 不过对于风险一，我个人更倾向用网络访问策略、防火墙等方式来限制。一是如果用mysql内部机制来限制登录主机，如果白名单长了，需要创建和维护很多个用户。二是端口如果在外部能访问，黑客可能会使用你意想不到的各种方式来攻击数据库。 风险二用SSL 加密传输来解决。还可以限制用户必须提供满足条件的证书才能访问数据库。
Geek_5343912024-08-21 来自浙江1.网络防火墙做好端口放行策略。 2.使用单独的账号，并给予最小权限 3.传输加密1
1232024-08-21 来自浙江老师，权限赋值哪一块是否和用户登录的逻辑是一致（为什么会出现这样的问题呢？大概是因为 MySQL 只使用了库名为 'db\_1' 的这条授权记录。），具备一定的优先级，若存在指定表就不会去匹配通配符？ +-------------------------------------------------------------------------------------------+ | Grants for u03@% | +-------------------------------------------------------------------------------------------+ | GRANT PROCESS ON *.* TO `u03`@`%` | | GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `db01`.* TO `u03`@`%` | | GRANT SELECT, INSERT, UPDATE, DELETE ON `db\_1`.* TO `u03`@`%` | | GRANT CREATE, DROP, INDEX, ALTER ON `db__`.* TO `u03`@`%` | +-------------------------------------------------------------------------------------------+ 对u03赋权DDL：grant create,alter,index,drop on `db\_1`.* to 'u03'@'%'; +--------------------------------------------------------------------------------------------+ | Grants for u03@% | +--------------------------------------------------------------------------------------------+ | GRANT PROCESS ON *.* TO `u03`@`%` | | GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `db01`.* TO `u03`@`%` | | GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `db\_1`.* TO `u03`@`%` | | GRANT CREATE, DROP, INDEX, ALTER ON `db__`.* TO `u03`@`%` | +--------------------------------------------------------------------------------------------+ 因为对于同一个表，DDL和DML是在同一行，匹配到对应表的数据项后就直接返回了展开