我已经读过,最好不要让用户直接使用sa登录,而是使用Windows身份验证并允许这些帐户(或帐户组)的sysadmin权限.
>这基本上不是一回事吗？有什么优点/缺点？
>最佳实践如何提高sql Server实例的安全性？
>这仅适用于生产实例,还适用于我们的内部开发实例？
解决方法
“我已经读过,而是使用Windows身份验证”
您在这里混合了两件事：SA的概念,以及sql身份验证和Windows身份验证的概念.
sql身份验证是存储在每个sql Server中的用户名和密码的列表.它存储在sql中的事实是第一个问题.如果您需要更改登录密码,则必须在每台服务器上更改密码(或在不同服务器上维护不同的密码).使用Windows身份验证,您可以集中禁用登录,更改密码,设置策略等.
如果您选择使用sql身份验证,那么SA只是一个sql身份验证登录.它是默认的管理员用户名,就像管理员在Windows身份验证中一样.它在一个实例上有本地超级大国,但不是所有实例中的全球超级大国.
“……并允许这些帐户(或帐户组)使用sysadmin权限.”
无论您选择哪种身份验证方法,理想情况下您都要遵循最小权限原则：为人们提供完成工作所需的最低权限,而不是更多.
不要认为它们只是登录 – 他们是可以让你解雇的人.如果他们丢弃数据库或意外地禁用备份作业,他们就不会被解雇,因为默认情况下,sql不会跟踪谁做了什么.你是那个会被解雇的人,因为它会发生,而你却无法说出是谁做的.
“最佳实践如何提高sql Server实例的安全性？”
你想做两件事：
>阻止人们破坏服务器
>当他们打破服务器时,能够确切地确定是谁做的
第一个是使用最小权限原则完成的：只给人们所需的权限,仅此而已.
第二个是通过给每个人自己的登录,不允许共享登录(比如让每个人使用相同的用户名/密码),理想情况下审核登录来完成的.你可能不会马上做那个最后一部分,因为它有点痛苦,但是让我们先把这些部分放到位,这样你就可以在有人丢弃数据库之后添加审计,而你的老板想知道原因.
我知道你在想什么：“但我们正在编写应用程序,应用程序需要登录.”是的,给应用程序提供自己的登录名,开发人员需要知道该密码,但是该登录名应该被剥夺权限,以至于没有人会想要使用它.例如,它可能需要单独位于db_datareader和db_datawriter角色中,而不是其他任何内容.这样它就可以插入,更新,删除和选择数据,但不一定会更改模式,添加索引,更改存储过程等.
“这仅适用于生产实例,还适用于我们的内部开发实例？”
我认为它同样适用于开发实例,因为我经常担心人们会破坏事物.人们只是喜欢打破服务器的开发.当然,当需要将变更列表捆绑到迁移到生产时,我需要知道某个特定索引是否对应用程序至关重要,或者某个骨头是否只运行了数据库调优顾问并告诉它应用所有更改.适当的权限有助于减轻这种痛苦.
