SQL Server 安全打击

SQL Server 安全打击

我已在一个城市担任 SQL Server DBA 两年了。

我被聘请来为一位现任 DBA 提供支持,因此我慢慢地适应了一切,并且已经工作了一段时间,试图在组织中赢得信誉。现在是时候解决最棘手、最重要的问题了:安全。

我们的主要服务器是一个故障转移群集,上面装有 SQL 2005。它拥有 166 个数据库。它为大多数应用程序提供大约 550 个连接,并具有应用程序池,因此它可以轻松支持数千名用户。我们还为一个流量相当大的公共网站提供服务。供应商应用程序、内部应用程序、访问后端 - 种类繁多,有几个关键应用程序。

许多开发人员都有生产访问权限。更改是在 RFC 流程之外进行的,我们不知道开发人员更改了哪些数据。他们还喜欢在系统实施期间拥有生产访问权限 - 我也希望停止这种情况。

由于有这么多的应用程序在运行,任何理智的 DBA 都会锁定服务器

如何让开发团队从完全开放的安全性转变为更加严格的环境?

我正在开发一个紧急请求系统,该系统将允许他们在有限时间内访问他们的数据库。这将使我们能够审核访问和 ddl 更改。希望这不会被使用 - 因为这意味着我们没有响应页面。它将使用 HTTP、加密的 webconfig、屏幕上的登录名/密码(不是电子邮件)、每 12 小时请求限制为 3 次。当发出登录时,我们也会被分页。

关于这种类型的系统有什么警告吗?

我认为最大的风险是,如果用户的 ntlogin 被攻破,那么他们的数据库也会被攻破。我们现在有这个漏洞,因为他们总是可以访问,但永远不会知道是否发生了这种情况。


编辑:开发和准备阶段是具有 8 个内核和 8GB 内存的强大系统。计划实施 prd 到 stg 的复制机制,如果开发人员的数据库不大且不包含敏感信息,开发人员可以对其进行操作。

管理层很支持。如果我们能保证他们在紧急情况下可以访问,他们最大的担忧就解决了。另一个问题可能是在实施期间访问生产环境 - 我宁愿不这样做。我们可以先练习转移到临时环境,然后在上线期间进行测试和修复 - DBA 迁移到 prd。

答案1

我在公司也做过同样的事情。实际上,我发现大多数人对此的接受程度比我想象的要高,但有几件事是关键:

  • 提醒他们这样做的主要目的是为了防止发生事故。事故是每个人都会遇到的事情。几乎没有人会想到自己会遭到黑客攻击,而谈论内部黑客会让他们立即采取防御措施(“你不相信我吗?”)。
  • 当请求确实遇到阻碍时,能够快速做出响应。
  • 愿意与他们合作。我们发现,我最初锁定的一些东西是它们完成工作所必需的,如果稍微打开一点也不会造成问题。
  • 始终如一。你必须普遍应用这些政策。如果可能的话,也把它们应用到你自己身上。

我也一直在尝试以较小的增量进行此操作,以减少干扰。例如:

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

祝你好运!

答案2

首先放置一个 DDL 触发器来获取发生的任何架构更改。只需记录通过的每个 DDL 命令,查看执行人员和时间。

您可能会发现事情并没有看上去那么糟糕。找出谁在推动大多数变化,并让他们参与进来。之后,您应该能够更好地控制事情。

另外 - 进行跟踪以找出那些不是您正确应用程序的应用程序正在运行的内容。查看跟踪中的 ApplicationName 和/或 HostName 字段。这将帮助您获得一个用于临时查询的字段。然后您应该能够找出谁经常跳出来窃取数据。

我总是首先监控这种情况。尽快锁定它,但现在就开始监控,以了解问题有多严重。

答案3

这是一项严肃的任务。这些人可能已经非常固执己见,需要上级的大力支持才能改变这种状况。他们已经有测试环境了吗?我猜他们有,但如果没有,那应该是第一步。另外,确保测试环境达到标准。如果测试环境陈旧且运行缓慢,他们会不愿意被迫使用它。你需要准备在其他领域(例如测试)给他们一点好处,以便从外交上让他们摆脱这种习惯。

答案4

你说你在某个城市工作,但由此我无法确定你是政府雇员、合同公司雇员,甚至无法确定你在哪个国家。

如果你想做出这种改变(实际上,开发人员不应该任何访问实时环境 [顺便说一下,我是一名高级开发人员]),那么你需要管理层的支持,以使你的业余开发人员遵守规定(即,生产数据库用于生产用途,而不是让你通过运行随机查询来弄清楚为什么你的半吊子代码无法工作以“看看会发生什么”)

我强烈建议您检查以下情况是否适用于您的组织:

SOX(萨班斯-奥克斯利法案,适用于美国上市公司)
198 号法案(安大略省,并通过 CSA 规则间接适用于加拿大其他地区)
CLERP-9(澳大利亚)
J-SOX(日本)

所有这些都在做同样的事情,确保向股东报告的财务状况尽可能没有欺诈行为。其中一个要素是职责分离——在 IT 领域,这意味着开发人员应该绝不可以直接访问生产数据的读取或写入。所有操作都必须通过服务器管理员,并书面以及已签署的请求(实施表格),必须保留以供审计目的。

在所有情况下,管理层都会很快站到你这边 - 根据 SOX管理如果没有适当的“控制措施”,谁将被追究责任(监禁!)。

相关内容