Sql server 向我们的SQL Server添加安全层（目前可从远程SQL management studio访问）

我们有一个运行着数千用户的大系统（一些来自android应用程序，另一些来自web应用程序，等等）

该系统是分布式的，数据库位于两个位置（在同一个国家内）。在一个位置，同一网络中有5台服务器，每台服务器都有一份数据库副本（通过复制）

在软件开发人员中，少数人可以直接访问生产数据库。有时，由于用户要求技术支持修改系统本身无法执行的某些操作，开发人员/支持团队必须直接访问数据库并修改某些记录

我们知道这不是理想的工作方式。但多年来一直是这样

最近我们发现了一些问题。一天，一个人错误地更新了表中的数百条记录

从那时起，我们正在分析如何改进这种访问

我们正在寻找改善安全的方法。我们希望有一个两阶段的认证系统。在从Sql Server Management Studio访问时要求用户输入两个密码的内容

可能吗？或者我们是否可以使用其他方法来提高安全性，但仍然允许开发人员/支持团队在必要时访问生产数据库

用户还（当前）可以通过远程桌面访问所有服务器

---

至少我们想知道何时完成此访问。

为这些用户设置对PROD的只读访问。允许他们编写自己的脚本，然后至少将其提交审查，并在可能的情况下像任何其他可部署的脚本一样进行测试。然后与具有访问权限的人一起遵循标准部署流程。

如果我的其他答案不可行，并且这些更新总是相同类型的修复程序…您可以创建支持存储的进程来执行修复程序，并且只对这些进程授予权限…但这在很大程度上取决于正在进行的修复程序的通用性，而不是太多比我的另一个答案更可取

---

我自己没有使用过它，但可能会允许您授予用户只读权限，而进程将在具有更高访问权限的凭据下执行。

您当前使用的是Windows身份验证还是混合模式身份验证？您如何处理应用程序中用户的权限？您认为询问两次密码将如何防止一天一个人错误地更新表中的数百条记录。@ArthurD是的，它启用了混合模式。@游戏的想法是第一个密码只对两个人可用。所以他们会出现在开发人员的身后，看着他们。但是要限制在删除语句中忘记where子句的损害是正确的，但我并不希望IT团队“多年”运行一个拥有数千用户的应用程序没有数据库更改控制机制…也许这可以成为一个更理想的解决方案的垫脚石…一个野生西部的逐渐文明嗨@SMM，我喜欢你的解决方案。我们正在考虑将存储库（SVN）与Jenkins混合使用。例如，支持人员希望更新某些行或表。因此，他编写了一个脚本（SQL），在我们的开发服务器上运行该脚本（该服务器每晚对生产系统进行一次非常新的备份，并从中重新创建自己的数据库）。一旦支持人员对脚本感到满意，他就会将其提交到一个特殊的SVN存储库（称为支持）。一旦发生这种情况，具有DB写入权限的人将检查脚本并在Jenkins上启动作业。此作业在生产环境中运行脚本。因此，这些更改将通过Jenkins进行（没有人可以直接访问）。只有在詹金斯身上执行任务的权利。但是，我们担心这种方式对于编写sQL脚本的用户来说可能太有限了。因为使用特定软件（如EMS SQL Manager for SQL Server）修改屏幕上具有可视行表示的值非常容易。为此使用SVN存储库是一个疯狂的想法吗？是否已经有其他类型的软件用于我们缺少的特定工作？感谢在我们所处的环境中，我们离数据库自动化还不远。我们仍然构建由DBA运行的部署脚本，但它们将首先在预生产环境中进行测试，然后QA和/或UAT将对结果进行测试，以确保没有任何问题。然而…这是我们在不久的将来开始调查的地方…这可能会有部分帮助-同样取决于您编写的脚本：和。