因此，当前的问题是，我们继承了许多总共有大约 500 个应用程序 exe 的机器。我们正在进行物理迁移，并意识到有人没有保存源代码，而且有太多应用程序需要识别和重写。
问题陈述：数百台机器正在向带有用户sa和BLANK PASSWORD:( 的 SQL Server 发送请求，并且为了移动，我们正在 Azure Cloud 中设置一切。 Azure SQL 在 VM（IaaS）等上强制执行密码策略。我想拦截和转换任何尝试使用某种类型的代理层进行连接的应用程序。
我正在查看 Node Proxy 和 SQL 服务器别名等，但似乎我想要做的是这个
代理服务器
--> 500 incoming SQL Server connections
--> Server \\XSQL2
--> User "sa"
--> Password ""
所以
<add key="conn" value="data source=XSQL2; initial catalog=SomeDB;uid=sa;pwd=" />
但随后代理将处理委托给 Azure 的翻译，并发送（替换）为
<add key="conn" value="data source=myclouddbs.westus.cloudapp.azure.com,1433; initial catalog=SomeDB;uid=myUser;pwd=MyPassword123" />
我说的话有道理吗？
答案1
您面临的问题比仅仅使用代理更大。
数百台机器正在使用用户 sa 和空白密码向 SQL Server 发送请求
如果您必须使用带有空白密码的 SQL SA 帐户，则应不惜一切代价避免将您的 SQL 服务器暴露给互联网。在代理后面运行不会使情况变得更好，您的更好选择是使用 VPN 站点到站点或使用网络安全组（NSG）过滤对 VPN 的 IP 地址访问。
Azure SQL 在 VM (IaaS) 上强制实施密码策略
您可以通过安装 VM 和 SQL 副本来绕过此问题。通过安装所需的扩展，您可以获得具有 SQL 功能的大多数 Azure VM。
参考：
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-site-to-site-create https://docs.microsoft.com/en-us/azure/virtual-machines/windows/nsg-quickstart-portal https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-server-agent-extension