承接上篇網路協定、驗證模式、sa 帳戶與審計設定，本文聚焦作業系統層面的權限收斂、網路邊界隔離、檔案系統安全與安裝痕跡清理——這些往往被忽視，卻是駭客取得初始立足點後進行提權與橫向移動的關鍵路徑。
SQL Server (MSSQLSERVER) 與 SQL Server Agent (SQLSERVERAGENT) 均作為 Windows 服務運行，其安全上下文完全繼承自啟動帳戶。一旦資料庫引擎被攻破（如透過 SQL 注入觸發緩衝區溢位），攻擊者將獲得該服務帳戶的完整系統權限。
| 服務 | 建議帳戶類型 | 具體配置 | 禁止配置 |
|---|---|---|---|
| Database Engine (MSSQLSERVER / MSSQL$InstanceName) | 專用網域使用者帳戶 | • 僅具「標準使用者」權限 • 獲授「作為服務登入」 • 獲授「替換進程層級令牌」 • 資料/記錄/備份目錄具修改權限 | Local System Local Administrators Domain Admins |
| SQL Server Agent (SQLSERVERAGENT / SQLAgent$InstanceName) | 專用網域使用者帳戶 | 同上，若無 Agent 作業可直接「停用」服務 | 同上 |
sysadmin 角色成員擁有的 CmdExec 或 ActiveX Script 作業步驟對策：盡可能避免上述場景；若業務強制需求，請將該實例物理隔離於 DMZ 或獨立 VLAN，並啟用嚴格出站防火牆規則。
sc config 指令變更帳戶！這將導致註冊表 ACL、NTFS 權限、使用者權限指派大量缺失，服務無法啟動。
Enterprise Manager 會自動完成：
HKLM\SOFTWARE\Microsoft\MSSQLServer 等的 ACL 重設變更生效需重啟服務；雙服務需分別操作。
| 協定 | 埠號 | 用途 | 處置 |
|---|---|---|---|
| TCP | 1433 | 預設執行個體 TDS 通訊 | 邊界防火牆 拒絕所有入站 |
| UDP | 1434 | SQL Server Browser 解析命名執行個體 | 邊界防火牆 拒絕所有入站 |
| SQL 版本 | 安裝類型 | 敏感檔案路徑 | 風險內容 |
|---|---|---|---|
| SQL Server 2000 | 預設執行個體 | %ProgramFiles%\Microsoft SQL Server\MSSQL\Install\ | sqlstp.log、sqlsp.log、setup.iss 可能含明文/弱加密 sa 密碼、服務帳戶憑證、授權金鑰 |
| 命名執行個體 | %ProgramFiles%\Microsoft SQL Server\MSSQL$InstanceName\Install\ | ||
| SQL Server 7.0 升級 | — | %Windir%\setup.iss%Temp%\sqlsp.log |
setup.iss 回應檔，同樣可能洩露密碼| # | 檢核項目 | 驗證方式 | 責任人 | 狀態 |
|---|---|---|---|---|
| 6.1 | 資料庫引擎服務帳戶為專用網域使用者 | services.msc / Enterprise Manager | DBA | ☐ |
| 6.2 | Agent 服務帳戶同標準或已停用 | 同上 | DBA | ☐ |
| 6.3 | 帳戶變更皆透過 Enterprise Manager | 審計變更記錄 | DBA | ☐ |
| 7.1 | 邊界防火牆封鎖 TCP 1433 / UDP 1434 入站 | 防火牆規則審查 / nmap 掃描 | NetAdmin | ☐ |
| 7.2 | 命名執行個體採固定埠並僅開放應用伺服器 IP | 組態管理器 + 防火牆規則 | DBA/NetAdmin | ☐ |
| 8.1 | 資料/記錄/備份磁碟皆為 NTFS | fsutil fsinfo volumeinfo X: | SysAdmin | ☐ |
| 8.2 | EFS 已啟用且憑證備份離線保存 | 檔案屬性 → 進階 → 加密內容 | SysAdmin | ☐ |
| 9.1 | Install 目錄下無殘留 .log/.iss 或已跑 Killpwd | 目錄掃描 / 關鍵字搜尋 | DBA | ☐ |
| 9.2 | 安裝介質與回應檔已銷毀或加密保存 | 實體/邏輯盤點 | SecOps | ☐ |
安全非一次設定，乃持續過程。上述九大項（含上篇）構成 SQL Server 2000 纏深防御基線。建議每季執行一次完整檢核，重大變更（補丁、遷移、架構調整）後必須複驗。隨著 SQL Server 2000 早已結束延伸支援 (2013/04/09)，規劃升級至支援中版本（SQL Server 2019/2022 或 Azure SQL）才是根本之道——舊版本無法獲得新發現漏洞的修補，上述所有努力終將面臨零日風險的挑戰。
