3 authentication security sql-server windows
先介绍一下背景：
如果所讨论的数据库是按照 DBA 的思维方式构建的，则下面描述的问题根本不存在：
仅通过视图和存储过程访问数据 --> 用户无需对表具有任何权限即可使用该应用程序.
但问题的数据库是一个“开发商的心态”制作的，所以应用程序发送INSERT，UPDATE并DELETE查询到服务器- >它需要有足够的权限的帐户才能够访问数据库。
显然每个人都同意 Windows 身份验证比 SQL Server 身份验证更安全，例如这里：
我的问题：
当数据库是以开发人员的心态构建时，这仍然有效，如上所述？（当用户需要INSERT/ UPDATE/DELETE对表的权限）
为什么我问这个：
我们的主要应用程序是一个带有 SQL Server 数据库的 MS Access 前端。目前，我们正在使用 Windows 身份验证，但我正在考虑切换到 SQL 身份验证。
我看到的问题：
每个人都使用自己的 Windows 帐户连接到数据库。
因此，为了使应用程序工作时，Windows帐户所有人和他们的狗需要有INSERT/ UPDATE/DELETE该表的权限。
这意味着这里的每个人都可以创建一个新的 Access 数据库，从我们的主数据库中链接几个表并编辑（或删除）它们。
是的，我们有一些真正知道如何做到这一点的高级用户。
从这个角度来看，我很难理解为什么在推荐 Windows 身份验证而不是 SQL 身份验证时显然没有考虑这种安全威胁。
对我来说，任何人都可以使用他的 Windows 帐户编辑或删除表的可能性是不安全的。
另一方面，IT 部门以外的人可以从配置文件中获得明文 SQL Server 身份验证密码的假设危险是不太可能的。
（鉴于用户的机器上没有明文配置文件 - 我们公司就是这种情况）
正如我在开头所说的-我知道，因为我们的应用程序是用一种方式，使用户这个问题只存在需要 INSERT/ UPDATE/DELETE该表的权限。
但是，有很多这样的数据库......我仍然只看到 Windows 身份验证总是比 SQL Server 身份验证更安全的建议。
IMO，答案应该是（一如既往）“视情况而定”，因为如果不了解有关数据库的更多信息，您就无法确定。
那么，没有其他人看到这个问题还是我错过了什么？
或者有没有办法在所有用户都无法删除数据的情况下使用 Windows 身份验证？
（除了更改对存储过程的所有数据访问）
小智 6
在我看来，Windows 身份验证仍然更安全。只是。
通过 Windows 身份验证，您可以允许一组人（通过 Windows 组）访问数据库。只有那些用户可以使用应用程序，任何应用程序，连接到数据库。
如果您使用 SQL Server 帐户，那么任何知道凭据（并且这些凭据总是会泄漏）的人都可以连接到您的数据库。再次使用任何应用程序。
您完全正确，使用 Windows 身份验证可以直接连接到数据库并发出他们认为合适的任何查询 - 由于您的应用程序需要模型。
在这种情况下，我建议使用应用程序角色：http : //msdn.microsoft.com/en-us/library/ms190998.aspx
您在这里遇到的问题是您必须能够对应用程序进行编码才能使用应用程序角色 - 这并不总是那么容易。恐怕我不是 Access 专家，无法在这里专门提供建议。
应用程序角色的优点是您可以限制哪些应用程序可以执行某些命令。它类似于数据库角色，但分配了一个密码，在继承角色的权限之前需要该密码。将应用程序角色与 Windows 组一起使用，您可以限制可以连接到数据库的用户以及他们可以用来查询数据库的应用程序。
| 归档时间： |
|
| 查看次数： |
1642 次 |
| 最近记录： |