穿吊带衫的和尚
这种问题，个人给你的建议是：
1.如果你懂IPSEC来做一下端口限制，比如只允许访问服务器指定的1433端口，以及软件必须的端口和你远程的端口外，其他都不允许访问。
2.使用的SQL版本尽量打上所有安全补丁，同时SA密码尽量复杂化，大小写字母加数字全用上，再一个SQL的GUEST客户访问权限也要设置好，不要给他多权限，除了基本的读取和写入就不要再给了。
3.如果客户端访问是固定IP，可以ipsec，只允许这个IP访问，这样效果是最好的。
4.如果有软件允许还可以云服务器架设VPN服务器来进行访问这种就更安全了。
3.
桃妹谈美食
一：保证客户端密码安全
1. 通过dll/so/dylib对密码加密也就是说客户链接1433端口的密码并不是实际密码，提升破解成本；
2. 增大密码复杂度防止猜解；
3. 增加密码错误次数，如超过则锁定ip；
4. 使用动态密码通过一定算法获取；
二：服务（器）层防御
5. 修改默认端口，增加入侵成本；
6. 防火墙策略白名单限制防止其他ip攻击；
7. 服务器口令与数据库口令不要设置一样，增加侵入者入侵服务器的成本；
三：保证数据安全
8. 给内网客户使用的数据库用户权限尽可能小；
9. 数据库做好日志记录以及定期备份，被删等意外情况下紧急恢复
10. 对数据操作进行审计，发现异常操作进行告警，及早干预防止损失扩大
以措施基本是用来增加入侵成本的。最佳方式就是实时风控和审计，发现异常请求立即终止，但此类成本较高。
对于内网用户从成本和难度方面考虑除了审计/风控外其他都可以
一只蚂蚁爬墙上
安全也算是运维人员老生常谈的话题。针对你的问题，建议如下
1.改端口，不使用默认的1433端口。更换为1024-65535的非默认端口
2.不使用弱口令。设置复杂密码，包含大小写，数字，特殊字符组合
3.防火墙设置过滤规则，或者只允许固定IP段访问
5.加强服务器本身防护，避免木马病毒的恶意入侵
6.……
极客潇
运维的角度看，这么做是一票否决的！但这是在云上，本质上运维方不是你们公司的任何人，而是云服务商，但数据却不是云服务商的。所以造成主管的不负责，负责的不主管。
公司的运维仅剩下建议权，那就不建议这么做，如果项目组非要这么做，则签安全责任书，项目负责人签字确认，那么他们爱怎么干就怎么干。
乖乖已不在
云服务器开端口给“非公网用户”访问？“非公网用户”是什么用户？你的“云服务器”是“公有云”还是“私有云”？“非公网用户”是怎么访问的？需要什么级别的权限？是全数据库服务器的访问？特定数据库的访问？特定表的访问？特定字段的访问？增、删、改、查全要有？还是部分？你为什么不能把他要的数据推送过去？为什么非要他进来访问呢？
七星无相
1 改1433端口号为其它端口号。 2 禁止sql执行操作系统命令 3 打上所有补丁 4 用户密码有多复杂就多复杂
app开发者
把数据库暴露给外部用户是个荒唐的主意，应把数据或服务以Api的方式提供给外部，且所有数据要加密以防止劫包。非得如此，还是用vpn吧。
天涯特困生
限制访问IP，或者在内网访问 ，数据库尽量不要开放公网直接访问，可以说说你的应用场景，便于针对性提出更好方案
隔壁老邻
不要开放1433 最佳办法是写个服务。
媉歨埘蘹
vpn访问安全。
