【问题标题】:Process for changing database passwords and avoiding website downtime更改数据库密码和避免网站停机的过程
【发布时间】:2017-11-19 19:47:54
【问题描述】:

老板说我们需要更频繁地更改我们的 SQL Server 帐户密码,嗯,从来没有。在我们发现我们的一个 web.config 文件可能在一个多月前遭到入侵后,他昨天做出了这个决定。它包含三个数据库的凭据,并且所有三个密码都有几年的历史(根据密码中包含的年份来判断)。

所以如果我有两个不同的 DBA 需要处理,每个都需要一个耗时的票证过程来更改密码,而一个 Web 服务器管理器需要一个类似的耗时过程,似乎没有办法全部更改三个 SQL Server 帐户密码,无需大量停机时间,我就可以更新我的站点的 web.config。他希望我们现在每 3 个月做一次。

所以我向 DBA 建议,在这个示例中,我们应该为每个数据库设置两个帐户,一个在 99% 的情况下处于活动状态,一个处于禁用状态。然后每 3 个月,对于每个数据库,我可以请求 DBA 启用备用帐户并给他们新的密码。然后我可以请求指向新帐户的 web.config 更新。网站更新后,DBA 可以禁用不再使用的三个帐户。

这是一种常见的做法吗?它有一个术语吗?有更好的主意吗?因为这个想法在这里得到了一些反击。最后,为什么 SQL Server(或任何类似技术)不允许旧密码在短时间内(可能是一个小时)在更改帐户密码后继续存在,以在我们想要的情况下提供帮助避免停机?

感谢您到此为止!

【问题讨论】:

  • 做最适合您团队的事情。
  • 这听起来是个好主意!虽然变更过程需要将关键变更与维护和开发变更区分开来,但拥有一个备份帐户对于减轻灾难非常有用。
  • 我会找出企业对您系统上的数据的重视程度,并从有助于您的老板看起来更好的角度来论证您的案例。希望我有时间更全面地回答您的所有问题。
  • 如果 dba 或其他支持人员给您带来困难,请上报给您的老板,然后老板应根据需要上报给支持人员的主管。他们会解决的。这不是技术问题,而是需要通过对话解决的问题
  • 谢谢大家!这肯定需要一些技巧,但并没有我说的那么糟糕!

标签: asp.net sql-server database security


【解决方案1】:

web.config 文件可能在一个多月前就被泄露了

这似乎是问题的根源,所以恕我直言,这是应该解决的主要问题(即使回收 pwds 很有意义 - 相比之下,它是唾手可得的果实)。

建议employ encryption for sensitive web.config sections 来缓解这种情况。

Hth.

【讨论】:

  • 感谢您的链接!背景故事:4 月份的一次安全审计发现了一个容易被路径遍历的下载 url。巧合的是,我在一周后实施了我的新版本网站,它没有这样的漏洞。 6 周后,他们打电话询问为什么不能再下载我们的 web.config 文件,这是我们第一次听说!无论如何,在这种情况下,加密肯定有助于减轻担忧。但据我了解(我还没有深入阅读),这只会掩盖任何有权访问我的 PC 或网络服务器的人的密码,对吗?
【解决方案2】:

我最近通过以下顺序解决了这个问题。

  1. 将授予个人登录名/用户的所有权限转换为基于角色的权限(详情如下)。
  2. 使用与第一个不同的密码创建第二个登录名/用户(按照您的建议);将他们添加到该角色。
  3. 让您的应用程序转换到第二次登录。
  4. 确认您在第一次登录时看不到任何登录事件。
  5. 更改首次登录的密码(如果您希望尽可能小地保持安全范围,则可以完全删除密码)。

至于“创建角色并将权限转移给它”位,这是我使用的脚本:


declare @user sysname = '<your user here>',
    @role sysname = '<your role here>';

-- no changes should be necessary below here

select concat('CREATE ROLE ', quotename(@role), ' AUTHORIZATION [dbo];') AS [grant], '' AS [revoke], '' AS [permission_name], NULL AS [class_desc]
union all
select concat('ALTER ROLE ', quotename(@role), ' ADD MEMBER ', QUOTENAME(@user), ';'), '', '', null
UNION all
select concat('GRANT ', permission_name collate database_default, ' ON ',

        CASE class_desc
            when 'OBJECT_OR_COLUMN' then 'OBJECT::'
            when 'TYPE' then 'TYPE::'
        END,

    QUOTENAME(
    CASE class_desc
            when 'OBJECT_OR_COLUMN' then OBJECT_SCHEMA_NAME(major_id)
            when 'TYPE' then (SELECT SCHEMA_NAME([schema_id]) FROM sys.[types] WHERE [user_type_id] = [major_id])
    END), '.',

    quotename(
        CASE class_desc
            when 'OBJECT_OR_COLUMN' then object_name(major_id)
            when 'TYPE' then TYPE_NAME(major_id)
        END
    ),
    ' TO ', QUOTENAME(@role), ';'
), 

CONCAT('REVOKE ', permission_name collate database_default, ' ON ',

        CASE class_desc
            when 'OBJECT_OR_COLUMN' then 'OBJECT::'
            when 'TYPE' then 'TYPE::'
        END,

    QUOTENAME(
    CASE class_desc
            when 'OBJECT_OR_COLUMN' then OBJECT_SCHEMA_NAME(major_id)
            when 'TYPE' then (SELECT SCHEMA_NAME([schema_id]) FROM sys.[types] WHERE [user_type_id] = [major_id])
    END), '.',

    quotename(
        CASE class_desc
            when 'OBJECT_OR_COLUMN' then object_name(major_id)
            when 'TYPE' then TYPE_NAME(major_id)
        END
    ),
    ' FROM ', QUOTENAME(@user), ';'
), [permission_name], [class_desc]
from sys.database_permissions
where grantee_principal_id = user_id(@user)
    AND [permission_name] <> 'CONNECT'
ORDER BY [permission_name];

就我而言,我只需要担心对象和用户定义的类型权限;如果你有更多,你将不得不考虑他们。但是上面会生成一个四列的结果集。 grant 列将是创建角色的 SQL,将您指定的用户添加到角色中,然后授予角色该用户当前拥有的所有权限。 revoke 列将是从用户那里获取相同权限的 SQL。另外两列只是为了我的理智,因为我正在开发脚本以确保我没有遗漏任何内容。

一旦您运行了上述所有操作(请在投入生产之前在非生产环境中对其进行测试!),您的应用程序将利用该角色获得 它的权限。之后,您应该能够满怀信心地以适合您需求的节奏推进上述计划的其余部分。

【讨论】:

  • 谢谢,本!这很有帮助,因为您可能已经猜到了,不喜欢这个想法的 dba 继承了一个没有角色和非常复杂的用户权限的数据库。我让他复制的帐户在这里返回了 600 多行与您的查询,这只是它映射到的数据库之一。我什至不确定他知道谁和什么都在使用这个帐户,所以这将是一场巨大的考验,但毫无疑问,它需要重新组织,希望这将有助于立案并最终遵循概述的顺序。再次感谢!
  • 没问题!上面查询的好处是它显示了显式授予该用户的所有权限。因此,只需一步即可创建具有相同权限的角色。之后,您可以摆脱那些明确授予的权限。你会到达那里的!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-05-11
  • 2019-05-10
  • 1970-01-01
  • 2013-02-06
  • 2015-03-09
  • 2011-01-05
相关资源
最近更新 更多