针对你提出的SQL Server 2014 sa账号登录审计需求，我推荐这套经过实践验证的最优方案，既能严格管控sa账号的使用，又能完整记录审计信息：

核心思路 #

利用SQL Server自带的登录触发器拦截sa账号的登录请求，强制收集操作人ID、使用原因，再将这些信息与时间戳、客户端IP等上下文数据一同存入审计表。这种方案无需额外第三方工具，完全依托SQL Server原生功能，性能开销低且可靠性高。

具体实现步骤 #

1. 创建审计记录表 #

首先在数据库中创建专门存储sa登录审计数据的表，建议放在单独的审计数据库或者系统数据库中：

CREATE TABLE Audit_SALogins (
    AuditID INT IDENTITY(1,1) PRIMARY KEY,
    OperatorUserID NVARCHAR(50) NOT NULL,  -- 操作人自身用户ID
    SAUsageReason NVARCHAR(255) NOT NULL, -- 使用sa账号的原因
    LoginTimestamp DATETIME DEFAULT GETDATE(), -- 登录时间戳
    ClientIP NVARCHAR(50), -- 客户端IP地址
    SessionID INT, -- 登录会话ID
    HostName NVARCHAR(100) -- 客户端主机名
);

为了保证数据安全性，记得给这个表设置权限：仅允许管理员修改，普通用户仅可查看（若需开放查询权限）。

2. 编写登录触发器 #

创建服务器级别的登录触发器，当检测到sa账号登录时，验证是否传入了操作人ID和原因，若未传入则拒绝登录，若传入则记录审计信息：

CREATE TRIGGER trg_Audit_SALogin
ON ALL SERVER FOR LOGON
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        -- 仅拦截sa账号的登录请求
        IF ORIGINAL_LOGIN() = 'sa'
        BEGIN
            DECLARE @AppName NVARCHAR(100) = APP_NAME();
            DECLARE @OperatorID NVARCHAR(50), @UsageReason NVARCHAR(255);

            -- 检查连接字符串的应用程序名称是否包含所需信息
            IF CHARINDEX('OperatorID:', @AppName) = 0 OR CHARINDEX('Reason:', @AppName) = 0
            BEGIN
                RAISERROR('使用sa登录必须提供操作人ID和原因，请在连接属性的「应用程序名称」中按格式填写：OperatorID:你的ID|Reason:使用原因', 16, 1);
                ROLLBACK; -- 拒绝登录
                RETURN;
            END

            -- 解析应用程序名称中的操作人ID和原因
            SET @OperatorID = SUBSTRING(@AppName, CHARINDEX('OperatorID:', @AppName) + 11, CHARINDEX('|', @AppName) - CHARINDEX('OperatorID:', @AppName) - 11);
            SET @UsageReason = SUBSTRING(@AppName, CHARINDEX('Reason:', @AppName) + 7, LEN(@AppName) - CHARINDEX('Reason:', @AppName) - 6);

            -- 插入审计记录到指定表（假设审计表在master库，可根据实际调整）
            INSERT INTO master.dbo.Audit_SALogins (OperatorUserID, SAUsageReason, ClientIP, SessionID, HostName)
            VALUES (
                @OperatorID,
                @UsageReason,
                CONVERT(NVARCHAR(50), CONNECTIONPROPERTY('client_net_address')),
                @@SPID,
                HOST_NAME()
            );
        END
    END TRY
    BEGIN CATCH
        -- 触发器异常时避免阻塞所有sa登录，可记录错误到日志
        INSERT INTO master.dbo.Audit_SALogins (OperatorUserID, SAUsageReason, LoginTimestamp)
        VALUES ('系统错误', '登录触发器执行异常', GETDATE());
        -- 若需严格管控，可取消下面的注释，拒绝异常情况下的登录
        -- ROLLBACK;
    END CATCH
END;

3. 用户登录方式 #

用户使用sa登录时，必须在连接参数中指定操作人ID和原因：

• SSMS登录：在「连接到服务器」窗口点击「选项」，切换到「连接属性」页，在「应用程序名称」中填写OperatorID:你的工号|Reason:紧急修复数据库权限，再登录。
• SQLCMD登录：使用命令行传入参数，示例：

sqlcmd -S 你的服务器名 -U sa -P 你的sa密码 -d master -v OperatorID='001' Reason='备份核心数据库' -A

进阶优化方案（企业级管控） #

如果需要更严格的安全管控，避免sa密码直接暴露给用户，可以开发一个轻量的登录入口：

• 用C#或Python开发桌面/Web应用，用户先以自身AD账号或SQL账号登录应用
• 应用界面要求用户填写使用sa的原因，内部使用存储的sa密码连接SQL Server，并将操作人ID和原因通过连接字符串的应用程序名称传入
• 登录触发器验证并记录审计信息

这种方式完全隔离了用户与sa密码，所有sa操作都经过统一入口，审计粒度更细。

技术选型总结 #

• 核心技术：SQL Server 2014自带的服务器级登录触发器（T-SQL），这是实现该需求的最优选择，无需额外依赖，性能损耗极低。
• 客户端工具：运维人员临时使用推荐SSMS+连接属性配置或SQLCMD；企业级长期管控推荐C#/Python开发自定义登录应用。
• 补充监控：可结合SQL Server的扩展事件或SQL Server Audit功能，实现更全面的数据库操作审计，但登录触发器已能满足核心需求。

内容的提问来源于stack exchange，提问作者Hanna Vasilenka