什么是SQL Server身份验证和Windows身份验证之间的区别?
每种身份验证类型是否有特定的用例?
什么是SQL Server身份验证和Windows身份验证之间的区别?
每种身份验证类型是否有特定的用例?
SQL Server内置了自己的安全系统,包括登录和角色。这与Windows用户和组是分开且并行的。您可以仅使用SQL安全性,然后所有管理都将在SQL服务器内进行,并且这些登录和Windows用户之间没有连接。如果使用混合模式,则Windows用户被视为SQL登录。
每种方法都有一些特点 -
如果要使用连接池,则必须使用SQL登录,或者所有用户共享同一个Windows用户-这不是一个好主意。
如果要跟踪特定用户的操作,则使用Windows身份验证是有意义的。
使用Windows工具来管理用户比使用SQL更强大,但两者之间的链接不可靠,例如,如果删除Windows用户,则SQL中相关的数据不会更新。
SQL身份验证
SQL身份验证是各种数据库系统中通常使用的身份验证方式,由用户名和密码组成。显然,一个SQL Server实例可以有多个这样的用户帐户(使用SQL身份验证),具有不同的用户名和密码。在共享服务器中,不同的用户应该访问不同的数据库,应该使用SQL身份验证。此外,当客户端(远程计算机)连接到运行SQL Server的计算机以外的计算机的SQL Server实例时,需要使用SQL Server身份验证。即使您没有定义任何SQL Server用户帐户,在安装时会添加一个根帐户-sa,其密码为您提供的密码。就像任何SQL Server帐户一样,这可以用于本地或远程登录,但如果应用程序是进行登录的应用程序,并且它只能访问一个数据库,则强烈建议您不要使用sa帐户,而是创建一个具有有限访问权限的新帐户。总的来说,SQL身份验证是主要要使用的身份验证方法,而下面我们要介绍的Windows身份验证则更多的是一种方便。
Windows身份验证
当您从安装SQL Server的计算机上访问SQL Server时,不应提示您输入用户名和密码。如果使用Windows身份验证,这是不必要的。使用Windows身份验证,SQL Server服务已经知道有人使用正确的凭据登录到操作系统中,并使用这些凭据允许用户进入其数据库。当然,只要客户端与SQL Server位于同一计算机上,或连接的客户端匹配服务器的Windows凭据,就可以工作。 Windows身份验证通常用作更方便的方式,以无需键入用户名和密码的方式登录到SQL Server实例,但是当涉及更多用户或建立与SQL Server的远程连接时,应该使用SQL身份验证。
即使您设法纠正了SQL方法中的这些安全漏洞,您也将是在重新发明轮子。考虑到Windows身份验证提供的安全性优势,包括密码策略和遵循POLP,在与SQL身份验证相比时,它是更好的选择。因此,强烈建议使用Windows身份验证选项。
理想情况下,在企业内部网络环境中应使用Windows身份验证。
而在其他类型的情况下,可以使用SQL Server身份验证。
这里有一个链接可能会有所帮助。
SQL Server身份验证模式
SQL Server 2008提供两种身份验证模式选项:
Windows身份验证模式要求用户提供有效的Windows用户名和密码才能访问数据库服务器。在企业环境中,这些凭据通常是Active Directory域凭据。
混合身份验证允许使用Windows凭据,但同时补充了本地SQL Server用户帐户,管理员可以在SQL Server中创建和维护这些帐户。
认证是确认用户或计算机身份的过程。该过程通常包括四个步骤: 用户提供身份声明,通常通过提供用户名来实现。例如,我可以通过告诉数据库我的用户名是“mchapple”来进行此声明。 系统向用户发出挑战以证明其身份。最常见的挑战是请求输入密码。 用户通过提供所需的证据来回应挑战。在这个例子中,我会向数据库提供我的密码。 系统通过检查本地密码数据库或使用集中式认证服务器等方式验证用户是否已经提供了可接受的证据。
我认为主要的区别在于安全性。
Windows身份验证是指身份作为Windows握手的一部分来处理,没有密码被拦截。
SQL身份验证意味着您必须自己存储(或提供)用户名和密码,这使得攻击变得容易得多。已经花费了大量精力使Windows身份验证非常强大和安全。
我建议如果您实施Windows身份验证,请使用组和角色进行管理。在Windows中使用组,在SQL中使用角色。在SQL中设置大量用户非常麻烦,而您可以只设置组并将每个用户添加到该组中。(我认为大多数安全性都应该以这种方式完成)。
如果可能的话,强烈建议使用Mssql身份验证。它允许您符合工作场所已经使用的现有Windows域,并且您不必知道用户的密码。
然而,如果服务器的机器没有通过本地工作场所的内部网络进行身份验证,则似乎无法使用。
如果您使用SQL身份验证,则安全性完全由您负责。
如果您使用Microsoft身份验证,则安全性基本上已经为您处理好了,但您将面临额外的限制。