我被引进来支持现有的DBA,所以我慢慢地把所有东西都拿进来并且已经工作了一段时间,试图在组织中获得可信度.现在是解决最棘手和最重要问题的时候了：安全性.
我们的主服务器是一个带有sql 2005的故障转移群集.它拥有166个数据库.它为大多数应用程序提供550个左右的应用程序池连接,因此它可以轻松支持数千个用户.我们还提供一个获得相当数量流量的公共网站.供应商应用程序,内部应用程序,访问后端 – 与一些关键应用程序相当多种.
许多开发人员都有生产权限在RFC流程之外进行了更改,我们不知道开发人员正在更改哪些数据.他们还喜欢在系统实施过程中获得生产访问权限 – 我也想停下来.
有这么多应用程序在运行,任何理智的DBA都会锁定服务器.
您如何将开发团队从广泛的安全性转变为更具限制性的环境？
我正在开发一个紧急请求系统,可以让他们在有限的时间内访问他们的数据库.这将使我们审核访问和ddl更改.希望这不会被使用 – 因为这意味着我们没有回复页面.它将在屏幕上使用HTTP,加密的webconfig,login / pwd(而不是电子邮件),每12小时请求限制3次.我们也会在发布登录时被分页.
有关此类系统的任何警告吗？
我可以看到的主要风险是,如果用户的ntlogin遭到入侵 – 他们的数据库就是如此.我们现在有这个漏洞,因为他们总是可以访问,但永远不会知道它是否发生.
编辑：
开发和升级是具有8核和8GB内存的强大系统.计划实现prd到stg复制机制,如果他们的db不是庞大且不包含敏感信息,开发人员可以操作.
管理层支持.如果我们能够保证他们在紧急情况下能够访问,他们最大的担忧就是照顾.另一个问题可能是在实施期间访问生产 – 我宁愿不给予.我们可以首先进行升级,然后在上线期间进行测试和修复 – DBA将迁移到prd.
解决方法
>提醒他们,这样做的主要目的是防止事故发生.事故是每个人都可以联系到的事情.几乎没有人认为他们会被黑客入侵,而谈论内部黑客会立即让他们处于守势(“你不相信我吗？”).
>当他们遇到障碍时,快速响应请求.
>愿意和他们一起工作.我们发现,我最初锁定的一些东西是他们完成工作所需要的,如果他们稍稍打开就不会引起问题.
>保持一致.您必须普遍应用这些政策.如果可能,也可以将它们应用到自己身上.
我也一直试图以较小的增量来做这件事,以减少破坏性.例如：
>所有新数据库从一开始就具有限制性权限.你不要错过你从未有过的东西.
>首先删除sysadmin和其他服务器级权限,如果他们当前拥有它们.大多数人都会同意他们不需要重新配置服务器,它会消除很多安全漏洞.一旦他们看到他们可以忍受这种情况,就会为更多的紧缩政策创造条件.
>一次关闭一个应用程序的数据库.这使得它更易于管理,而且可以让您随着时间的推移了解他们需要什么样的权利,以便将来的紧缩更顺利.
祝好运！
