SQL Server 安全打击

Question

我作为一个城市的 SQL Server DBA 已经工作了 2 年。

我被带去支持现有的 DBA，所以我慢慢地接受了一切，并且已经工作了一段时间，试图在组织中获得信誉。是时候解决最棘手和最重要的问题了：安全。

我们的主服务器是一个故障转移集群，上面有 sql 2005。它拥有 166 个数据库。它为大多数应用程序提供 550 个左右的应用程序池连接，因此它可以轻松支持数千名用户。我们还为一个获得大量流量的公共网站提供服务。供应商应用程序、内部应用程序、访问后端 - 包含一些关键应用程序的种类繁多。

许多开发人员具有生产访问权限。更改是在 RFC 流程之外进行的，我们不知道开发人员正在更改哪些数据。他们还喜欢在系统实施期间获得生产访问权 - 我也想停止这样做。

由于运行了如此多的应用程序，任何理智的 DBA 都会锁定服务器。

您将如何将开发团队从广泛开放的安全过渡到更严格的环境？

我正在开发一个紧急请求系统，它可以让他们在有限的时间内访问他们的数据库。这将使我们能够审计访问和 ddl 更改。希望这不会被使用 - 因为这意味着我们没有响应页面。它将使用 HTTP、加密的 webconfig、屏幕上的登录/密码（不是电子邮件），请求限制为每 12 小时 3。我们也会在登录时被传呼。

有关此类系统的任何警告？

我可以看到的主要风险是，如果用户的 ntlogin 受到损害 - 他们的数据库也会受到损害。我们现在有这个漏洞，因为他们总是可以访问，但永远不会知道它是否发生。

---

编辑：开发和登台是具有 8 个内核和 8GB 内存的强大系统。计划实施 prd 到 stg 复制机制，如果他们的数据库不是很大并且不包含敏感信息，开发人员可以操作该机制。

管理层是支持的。如果我们能保证他们在紧急情况下的访问，他们最大的担忧就得到了解决。另一个问题可能是在实现过程中可以访问生产 - 我宁愿不提供。我们可以先练习转移到登台，然后在那里上线期间进行测试和修复 - DBA 迁移到 prd。

Answer 1

我在公司里也一直在做同样的事情。事实上，我发现大多数人比我想象的更容易接受这一点，但有几件事是关键：

• 提醒他们这样做的主要目的是为了防止发生事故。事故是每个人都可能遇到的事情。几乎没有人认为他们会被黑客攻击，而谈论内部黑客会让他们立即处于防御状态（“你不相信我吗？”）。
• 当请求遇到阻塞时快速响应。
• 愿意与他们合作。我们发现我最初锁定的一些东西是他们完成工作所必需的，如果稍微打开一点就不会造成问题。
• 始终如一。您必须普遍应用这些政策。如果可能的话，也将它们应用到自己身上。

我也一直在尝试以较小的增量来做到这一点，以减少破坏性。例如：

• 现在，所有新数据库从一开始就具有限制性权限。你不会怀念你从未拥有过的东西。
• 首先删除系统管理员和其他服务器级别权限（如果当前拥有这些权限）。大多数人都会同意他们不需要重新配置服务器，并且它消除了很多安全漏洞。一旦他们发现自己可以忍受这一点，就会为进一步的渐进紧缩奠定基础。
• 一次收紧一个应用程序的数据库。这使您更易于管理，而且使您能够随着时间的推移了解他们需要哪些权利，以便未来的紧缩更加顺利。

祝你好运！