Question

在我们的生产环境中，Sql server有一些应用程序用来访问sql server的通用帐户（sql server accounts）。用户自己拥有Windows登录，只读或根据用户编写。我们想要添加一个限制，该限制只允许源自生产应用程序服务器的那些通用帐户（sql server accounts）连接。用户自己可以从非prod服务器连接，因此我们无法阻止prod中的sql端口进行非prod服务器的连接。

我们是否有针对此的行业广泛解决方案？

我们可以在防火墙中进行某种过滤，过滤连接。如果查询每个连接的api，数据库解决方案可能会太慢。

是否有一种很酷的方法可以阻止uat环境中的应用程序使用错误的配置设置（prod设置）连接到我们的生产数据库

Answer 1

你可以应用this中提出的不同解决方案之一，所以回答但是你必须首先更好地定义你的要求和背景。

如果您想阻止这些用户访问其他＆＃39;主机但允许其他用户从任何地方自由访问，然后您必须在数据库级别执行操作，因为只有数据库知道谁正在尝试登录：logon trigger是可选的。

如果数据库专门用于向这些主机提供信息，那么您可以在防火墙上运行（可能是一个性能更高的解决方案，根据负载，连接数，主机数量，许多其他变量进行评估）和删除从未知机器启动的所有连接。

如果您的环境没有定义边界＆＃39; （我的意思是数据库服务器也被其他主机使用，仅供应用程序服务器使用）也许可以评估新的专用数据库服务器的创建;这将允许应用防火墙解决方案（我更喜欢的那个）。

Answer 2

您可能会创建一个登录触发器来检查client_net_address的{{1}}字段，但这会将安全性与网络设置紧密结合，而这很容易被遗忘。如果IT小组进行了更改并且对此不了解，则登录触发器可能会过多或过少; - ）。

防火墙可能稍微好一点，因为至少所有对网络设置和访问的控制都在IT组内维护。但这很可能过于复杂，特别是如果有其他帐户可以从质量保证和/或UAT到生产有效。

我见过的设置在这种情况下运行良好是使用特定于环境的服务帐户。所以你会有DEV-App，QA-App，UAT-App和Prod-App。这将允许您在环境之间更精细地控制网络访问的其他方面（例如文件共享等）。你可能应该这样做，因为你想知道是否存在配置错误并且Prod-App帐户试图连接到DEV SQL Server或文件共享。

Answer 3

这个怎么样...... Network Service Account

Answer 4

正如所建议的那样，您可以使用动态管理视图来识别登录期间的登录和IP地址，并结合登录触发器来限制非prod应用程序访问prod数据库。在我这样做之前（再次，正如其他人所建议的那样），我会考虑使用替代方案：

防止非产品盒到达产品盒的防火墙规则
确保prod密码与非prod帐户不匹配（特别适合保存prod密码，如源代码控制或可能不一定需要prod访问的开发人员）

话虽如此，这是一个数据库驱动的解决方案，让您可以通过一个可以在服务器上任何地方生活的表来控制限制。

CREATE TABLE SampleDB.dbo.LoginRestrictions (
    RestrictionId INT NOT NULL PRIMARY KEY,
    LoginName VARCHAR(500) NOT NULL,
    IpAddress VARCHAR(50) NOT NULL,
    Notes VARCHAR(500) NULL
)

INSERT SampleDB.dbo.LoginRestrictions VALUES
    ('app1', '10.1.1.125', 'Deny app1 from QA'),
    ('app1', '10.1.1.%', 'Deny app1 from DEV') -- Notice '%' so you can match general subnets
    -- ... Any other rules

然后，您可以创建一个登录触发器，如果用户登录（在这些情况下可以是SQL帐户，但如果您愿意，也可以使用域登录来限制任何域帐户）。另请注意，触发器使用LIKE，因此您可以利用IP地址中的通配符，以防您可以通过子网进行匹配。

CREATE TRIGGER tg_Logon_Blocker
ON ALL SERVER FOR LOGON AS
BEGIN
    SET NOCOUNT ON

    -- Rollback if restricted
    IF EXISTS (
        SELECT *
        FROM SampleDB.dbo.LoginRestrictions R
            INNER JOIN sys.server_principals P
                ON P.name = R.LoginName
            INNER JOIN sys.dm_exec_connections c
                ON c.session_id = @@SPID
                    AND c.client_net_address LIKE R.IpAddress
        WHERE p.name = ORIGINAL_LOGIN()
        )
        ROLLBACK

END
GO

Answer 5

Sounds like Application Roles could be a good solution for this.

Basically you would set up some application roles with appropriate permissions for the apps in question, and allow appropriate users to make the initial DB connection, with no other privileges. I recommend Windows authentication via AD group for this.

Your apps would then call sp_setapprole immediately after connection, at which point the connection assumes the permission of the application role.

The big advantage of this is that it remains within the standard SQL Server security model.

Of course you would still need to take some care that your app configs are correct.

允许从源自特定计算机的通用帐户访问Sql Server

5 个答案: