我正在开发一个多用户应用程序 Windows 桌面应用程序。 对于用户管理，我使用 DMBS(Oracle、MySQL、MSSQL、Postgre)。 所以每个用户都有一个数据库用户帐户。
我不希望用户直接连接数据库并读取/写入数据。 数据应该只能访问，连接只有在使用我的应用程序时才有效。
我找到了这个website by SQLDUDE他在其中描述了一些技术。
仅通过特定应用程序访问数据的一种方法是检查 application_name 的登录触发器。 不过，他还描述说，这种方法很容易被欺骗，因为用户一旦知道连接字符串中的 application_name，就可以指定它。 (detailed explanation here - see Solution for Scenario #2)
他还提到应用程序角色。
A more secure approach you could use for this is called "Application Roles". When connecting from an application you assume a particular role and only that role is granted privileges required in the database.
所以基本上用户使用他的登录凭据登录，但根本没有任何权限(只有连接)。
然后在应用程序内部，一旦建立连接，我就会使用密码调用 sp_setapprole，以便授予应用程序规则。
Once this call succeeds then the connection gets the privileges of the application role and loses privileges of the actual user, which is what we want. So if someone tried to connect to the database from SSMS or SQLCMD, they will access the DB using their credentials, which won’t have the required permissions on the tables, since only the application role has the rights on the tables. This is more secure & reliable approach, but one that requires application code change and as a DBA you will have to create the application role in SQL Server.
所以应用程序角色听起来是一个不错的选择。
我的问题是:
应用程序角色 DMBS 是标准的并且可用于大多数 DBMS 系统吗？
有没有办法跟踪 sp_setapprole 登录(例如使用 WireShark)？
当然，有人可以对应用程序进行逆向工程并获取应用程序角色的凭据 - 但我想这是不可避免的:)
最佳答案
我见过一种更简单的解决方案，而且效果很好。这是:
- 应用程序负责在数据库中创建用户
- 在创建用户之前，应用程序会对其密码进行哈希/加密，因此，如果您选择密码“123456”，它将被创建为“RRU2992191910”(仅作为示例)
- 如果用户尝试使用“123456”连接数据库，则不会成功
- 只有应用程序能够连接到数据库，因为它对用户告知的密码进行了哈希/加密
这不是世界上最安全的解决方案，但它非常简单并且可以满足您的要求。而且它可以移植到不同的 RDBMS，无需额外成本。
关于mysql - 仅允许通过特定应用程序连接 DBMS 用户，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35476068/