Azure SQL：审计触发器和所有权链

Question

我有两个表，T1 和 T2，分别位于两个不同的模式 S1 和 S2 中。我在 T1 上编写了一个触发器 TR1（没有 EXECUTE AS 子句），它将插入 (I)、更新 (U) 和删除 (D) 记录到 T2 中，它具有与 T1 相同的模式，但有一些额外的元数据列. S1、T1、S2、T2 和 TR1 都归 dbo 所有。

我创建了角色 R1，它对 S1（因此对 T1）具有 S、I、U 和 D 权限。该角色还允许 S 在 S2 上（因此在 T2 上），但拒绝 I、U 和 D。我创建了一个用户 U1，并将角色 R1 分配给该用户。

在 U1 的用户上下文下，如果我尝试在 T2 上进行 I、U 或 D，正如预期的那样，会被拒绝。但是，如果将 I I、U 或 D 插入到 T1 中，审计行将成功插入到 T2 中。这是我想要的行为，但想知道这样做的原因，因为 U1 已被明确拒绝这些特权。

这是因为所有权链接，这样当 TR1 运行时 U1 的权限从不在 T2 上检查，还是其他原因？

--

已添加触发代码：

CREATE TRIGGER TRG ON dbo.T1
FOR INSERT, UPDATE, DELETE
AS
BEGIN;

DECLARE @Operation CHAR(1);

SET @Operation =    (
                        CASE
                            WHEN EXISTS(SELECT 1 FROM INSERTED) AND EXISTS(SELECT 1 FROM DELETED) THEN 'U'
                            WHEN EXISTS(SELECT 1 FROM INSERTED) THEN 'I'
                            WHEN EXISTS(SELECT 1 FROM DELETED) THEN 'D'
                            ELSE NULL
                        END
                    );

IF @Operation = 'I'
    BEGIN;
        INSERT INTO     adt.T1(Operation, ID, C1)
        SELECT          @Operation, ID, C1
        FROM            INSERTED;
    END;

IF @Operation = 'D'
    BEGIN;
        INSERT INTO     adt.T1 (Operation, ID, C1)
        SELECT          @Operation, ID, C1
        FROM            DELETED;
    END;

IF @Operation = 'U'
    BEGIN;
        INSERT INTO     adt.T1 (Operation, ID, C1)
        SELECT          @Operation, i.ID, i.C1
        FROM            INSERTED i
        INNER JOIN      DELETED d
        ON              i.ID = d.ID
                        -- Hash indicated columns of INSERTED and DELETED to determine if there are any real changes.
        WHERE           (SELECT HASHBYTES('MD5', (SELECT i.ID, i.C1 FROM (SELECT NULL AS X) t FOR XML AUTO)))
                        <>
                        (SELECT HASHBYTES('MD5', (SELECT d.ID, d.C1 FROM (SELECT NULL AS X) t FOR XML AUTO)));
    END;

END;

Answer 1

好的，是的，这是实际的所有权链，因为您在架构级别进行保护。

Understanding SQL Server Ownership Chaining
When there’s an ownership chain, security is ignored on the object being referenced.

在这种情况下，有一个 权力链 因为两个模式具有相同的所有者，这意味着特权 NOT re -在访问假定的 secured 模式时评估触发器执行。

To be clear, the execution context has not changed, there is no EXECUTE AS or impersonation going on. The operations against table T2 are still operating within the context of the original caller, but the ownership chaining rules means that access rules are simple not re-evaluated, it doesn't even try to check.

所有权链接是 SQL 服务器的一项优化功能，在许多情况下，它通过允许对访问规则进行一次评估而不是重新评估引擎仅重新评估的每个可能的安全上下文来提高查询吞吐量当上下文由不同的所有者保护时。

这是架构的所有者很重要的主要原因，也是您可以指定专门为不同架构创建的不同任意所有者的主要原因。

在 Audit/Change 日志记录的情况下，我们可以利用此行为通过阻止故意尝试修改审计记录的用户来维护我们的数据的完整性，同时仍然允许这些用户执行查询以及可能具有副作用的命令，这些副作用会将行插入到审计表中。

由于用户上下文没有被篡改，我们仍然可以捕获和记录有关当前用户上下文的信息，并将其包含在您可能正在记录的有关操作的元数据中。

For strictly non-audit based scenarios you need to be aware that ownership chaining can expose your secured tables to updates you might not have been expecting.

Azure SQL：审计触发器和所有权链

Azure SQL: Audit Triggers and Ownership Chaining

audit

triggers

azure-sql-database