Question

问题

早上好！我在一个应用程序团队工作，该团队支持一些利用SQL Authentication进行数据存储的应用程序。最近，我们的数据库支持团队决定不再允许Windows Authentication（出于安全和日志记录的原因），因此我的团队被迫将所有连接转换为Windows Authentication，包括我们的应用程序已经使用的几个专用服务ID利用数据检索。

首先，请允许我说，转移到Windows Authentication肯定是有利的，我并不是想对此提出质疑。但是这种变化给我们带来了一个巨大的问题......通过将我们的服务ID切换到MS Access，我们现在已经为每个具有前端应用程序访问权限的内部业务用户开放了我们的后端数据库。

SSMS被推送到每个用户桌面，一些超级用户甚至可以访问DML。此时，我们完全依赖用户无知来阻止内部用户直接访问后端数据库。鉴于某些角色具有提升SQL Authentication权限，这可能会产生一些令人讨厌的数据后果。

这个新的企业标准让我的团队在这一点上陷入困境，因此我们寻找任何数据库，帐户或架构解决方案，这些解决方案只允许我们限制用户访问前端。

问题

还有其他人遇到过这个问题吗？我们缺少哪种架构解决方案可以让我们在不暴露数据库的情况下消除SQL Server？
有没有人知道如何将ODBC数据库的访问权限仅限于某些连接方法？我想知道是否有办法将特定ID（或角色）指定为仅允许通过前端进行连接（并完全消除{{1}}个连接）。
有没有人有任何聪明的解决方法？

------------- EDIT ---------------

有几个人对角色访问提出了一个很好的观点，所以我想澄清我们以前和当前的解决方案......以前，所有角色访问都在前端进行管理，数据检索完全由私有系统SQL进行处理最终用户无法看到的ID。

当我们被迫消除这些SQL Auth ID时，我们在后端数据库上创建了一个类似的基于角色的设置，就像前端存在一样。创建Active Directory组以容纳不同的用户组，并在数据库中为这些组分配特定的角色权限。所以目前访问受到角色的限制尽可能多。

问题是即使是最低特权的角色也有一些表的INSERT，UPDATE和DELETE访问权限（访问通常通过代码控制）。因此，虽然我们能够通过利用数据库角色来降低风险，但我们仍然可以通过直接登录数据库来绕过前端保护。

Answer 1

编辑：问题澄清使这个答案过时，但由于一些评论讨论它，所以请将其作为参考。

假设您必须（基于您的体系结构）允许访问每个Windows用户帐户的数据库，一个选项是使用数据库角色。

您禁用对数据库的公共访问，然后根据您的用例定义一组数据库角色。每个角色都被授予权限，以便该角色的成员能够操纵他们需要的数据并使用他们需要的对象。然后将用户映射到他们需要的角色。连接到数据库时，将根据用户所属的角色授予用户权限。

例如，我们在一个名为MyAppUser的数据库中有一个角色（我们的名称实际上与使用数据库的应用程序相关），该数据库专为最终用户读取和插入数据而设计。这些可以简单地创建如下：

CREATE ROLE [MyAppUser]

该角色只被授予对相关模式或表的权限（假设我们所有的＆＃34; public＆＃34;表现在都在dbo模式中）。

GRANT SELECT ON SCHEMA::[dbo] TO [MyAppUser] 
GRANT INSERT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT DELETE ON SCHEMA::[dbo] TO [MyAppUser]

然后，应该具有此公共读写访问权限的每个用户都将映射到相关角色。

ALTER ROLE [MyAppUser] ADD MEMBER [UserName]

这将数据库中的用户和角色/权限分开，并允许您使用单一入口点来控制谁有权访问数据库中的内容。

通过＆＃34;查看定义＆＃34;默认情况下拒绝许可（对最终用户），他们无法探索＆＃34;数据库/视图表定义等使用访问，甚至是SSMS。

注意：SSMS提供了用于管理和查看权限和成员资格的向导，这些向导非常便于初始设置/测试/摆弄。

Windows身份验证 - 限制SQL Server后端访问

1 个答案: