针对你提到的这种无中间服务层、直接连接数据库的Windows桌面Java应用，我整理了几个实用的安全防护方案，来避免普通用户滥用数据库凭据或绕过应用直接访问数据库：

• 用Windows服务封装核心数据库交互逻辑
  这是最接近Linux setuid思路的方案：把Java程序里负责数据库连接、数据操作的核心部分抽出来，做成一个Windows服务，用专门的低权限本地账户（比如Local Service，或者自定义的专用受限账户）运行。桌面UI程序只负责和用户交互，通过命名管道、本地Socket这类IPC方式和服务通信，完全不接触数据库凭据。
  你可以通过Windows权限设置，禁止普通用户启动、停止或查看这个服务的进程信息，确保敏感的数据库连接逻辑和凭据完全隔离在普通用户的权限空间之外。

• 加密存储凭据，绑定Windows安全上下文
  绝对不能把明文凭据硬编码在代码里——哪怕是编译后的class文件，反编译后也能轻松拿到。建议用Windows的Data Protection API (DPAPI) 加密数据库凭据，这个API会把加密密钥绑定到当前系统的安全上下文（比如服务账户或者机器账户），普通用户的进程根本无法解密。
  加密后的凭据可以存在权限严格控制的地方：比如注册表的受限键（只给专用账户开读权限），或者一个只有专用账户能访问的配置文件。Java程序可以通过JNA/JNI调用DPAPI，也有现成的Java库封装了这个功能。

• 数据库账户权限最小化+连接来源限制
  给应用使用的数据库账户设置最小必要权限：比如只能对业务需要的表执行查询、插入操作，完全禁止修改Schema、删除数据或者访问无关表的权限。就算凭据不慎泄露，攻击者能做的破坏也非常有限。
  同时在数据库层面限制这个账户的连接来源：只允许从本地主机（应用所在的Windows机器）连接，禁止远程连接——这样就算凭据被拿到，也没法从其他机器直接访问数据库。

• 保护进程内存中的凭据
  Windows上可以开启进程的ASLR（地址空间布局随机化） 和DEP（数据执行保护），防止内存dump工具轻易读取到内存里的明文凭据。Java程序可以通过JVM参数或者JNI调用系统API来启用这些保护。
  另外，在代码里要注意：用完凭据后立即覆盖内存中的敏感数据——比如用Arrays.fill()覆盖存储密码的char数组（别用String存密码，因为String是不可变的，会在内存里残留）。

• 用应用控制策略限制非法访问
  借助Windows的AppLocker或者WDAC（Windows Defender应用控制） 配置规则：只允许你的签名后的Java应用连接目标数据库，禁止其他工具（比如SSMS、mysql.exe这类数据库客户端）访问数据库的端口或IP。这样就算用户拿到了凭据，也没法用其他程序直接连接数据库。

和Linux的setuid方案核心思路一致，都是把敏感操作和普通用户的进程隔离开，让敏感凭据和连接逻辑运行在普通用户无法触及的安全上下文里。Windows服务模式是最贴合这个思路的替代方案，能有效实现权限隔离。

备注：内容来源于stack exchange，提问作者Joigo