資料庫安全

威脅模型與縱深防禦

資料庫是攻擊者的終極目標：它存著一切。常見攻擊面包括：暴露在網際網路的連接埠、弱或外洩的密碼、應用程式的 SQL injection、 權限過大的帳號（應用程式用 superuser）、未加密的備份與日誌、內部人員、以及未修補的已知漏洞。 沒有單一機制能擋住全部，縱深防禦讓每一層的失守都被下一層限制損害範圍：

兩個貫穿全章的原則：最小權限（每個主體只擁有完成工作所需的最少權限）與預設拒絕（沒有明確允許的都禁止）。

認證：pg_hba.conf

PostgreSQL 的主機式認證檔 決定「誰、從哪裡、連哪個資料庫、用什麼方法」，由上而下第一個符合的規則生效，順序至關重要：

# 本機維運：以 OS 使用者對應資料庫角色，不需密碼
local   all             postgres                                peer
# 應用程式：只允許來自應用子網、強制 TLS、SCRAM 密碼
hostssl appdb           app_rw          10.0.1.0/24             scram-sha-256
# 報表唯讀帳號：以客戶端憑證認證（CN 必須等於角色名）
hostssl appdb           reporting       10.0.2.0/24             cert clientcert=verify-full
# 複寫連線
hostssl replication     replicator      10.0.0.0/16             scram-sha-256
# 其他一律拒絕（明確寫出比依賴「沒有符合規則」更清楚）
host    all             all             0.0.0.0/0               reject

密碼管理：PostgreSQL 沒有內建複雜度規則（ 模組可加一點），到期以 設定； 的明文會出現在伺服器日誌與 歷史——改用 （客戶端先雜湊）或直接提供 SCRAM verifier。 雲端服務另提供 IAM 認證（短效 token 取代密碼，如 RDS IAM）。

傳輸加密：TLS

伺服器端 加上 、（可選 以驗證客戶端憑證）； 用 強制加密、 拒絕未加密連線。 客戶端的 決定實際安全程度：

PostgreSQL 17 的 省去明文的 往返； 建議 以上。 GSSAPI 也可提供加密（）。別忘了複寫連線與 PgBouncer 到後端的連線也要加密。

授權：角色與權限

PostgreSQL 統一以角色（role）表示使用者與群組（ 屬性區分）。角色可成為其他角色的成員並繼承權限（，PostgreSQL 16 起可逐成員設定），或以 切換。

-- 群組角色（NOLOGIN）承載權限；登入角色只是成員
CREATE ROLE app_readonly NOLOGIN;
CREATE ROLE app_readwrite NOLOGIN;
GRANT USAGE ON SCHEMA app TO app_readonly, app_readwrite;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_readonly;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_readwrite;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA app TO app_readwrite;
-- 未來建立的物件也套用（由執行遷移的角色 migrator 建立）
ALTER DEFAULT PRIVILEGES FOR ROLE migrator IN SCHEMA app
  GRANT SELECT ON TABLES TO app_readonly;
ALTER DEFAULT PRIVILEGES FOR ROLE migrator IN SCHEMA app
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_readwrite;
-- 登入角色：應用程式執行期、遷移、報表各自分開
CREATE ROLE app_rw LOGIN PASSWORD '...' IN ROLE app_readwrite CONNECTION LIMIT 200;
CREATE ROLE reporting LOGIN IN ROLE app_readonly;
-- 欄位層級：薪資欄只給 HR
GRANT SELECT (id, name, dept) ON app.employees TO app_readonly;
GRANT SELECT (salary) ON app.employees TO hr;

Row-Level Security

RLS 讓資料庫強制「哪個角色能看到／修改哪些列」，常見於多租戶 SaaS：所有租戶共用表，但每個查詢自動加上租戶條件。

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders FORCE ROW LEVEL SECURITY;      -- 連表的擁有者也受限制

CREATE POLICY tenant_isolation ON orders
  USING      (tenant_id = current_setting('app.tenant_id')::int)        -- 讀取／既有列的可見性
  WITH CHECK (tenant_id = current_setting('app.tenant_id')::int);       -- 寫入的新列必須符合

-- 應用程式在每筆交易開始時設定（transaction-scoped，連線池安全）
BEGIN;
SET LOCAL app.tenant_id = '42';
SELECT * FROM orders;      -- 自動只回傳 tenant 42 的列
COMMIT;

• Policy 可指定命令（）與角色（）；多個 permissive policy 以 OR 結合，restrictive policy（）以 AND 疊加。

• 沒有任何 policy 符合時預設拒絕（看到空表）。Superuser 與具 的角色不受限制；表擁有者除非 也不受限。

• USING 條件會被加進每個查詢計畫，確保 有索引（通常是複合索引的前導欄）；policy 中的子查詢要留意效能。

• 比在應用程式每個查詢手寫 可靠得多——漏寫一次就是跨租戶資料外洩。Supabase 等平台的 API 授權即建立在 RLS 上。

SQL Injection

機制：程式把使用者輸入拼接進 SQL 字串，使資料被當成程式碼執行。

# Python（錯誤示範）
query = f"SELECT * FROM users WHERE name = '{name}' AND password = '{pw}'"
# 輸入 name = "admin' --"  →  SELECT * FROM users WHERE name = 'admin' --' AND password = ''
# 輸入 pw = "' OR '1'='1"  →  條件恆真
# 輸入 name = "' UNION SELECT usename, passwd FROM pg_shadow --"  →  讀出密碼雜湊（若權限足夠）
# Blind / time-based： name = "' AND (SELECT pg_sleep(5) WHERE substr(current_user,1,1)='p') --"

防禦（依重要性）：

1. 參數化查詢（prepared statement / bind parameters）：SQL 結構與資料走協定的不同通道（第 17 章的 Parse/Bind），資料永遠不會被解析成 SQL。 所有主流驅動與 ORM 都支援；識別字（表名、欄名）與 方向不能參數化，必須白名單。

2. 動態 SQL 必須正確引用：PL/pgSQL 用 （識別字）、（字面值）與 ； 應用層用 ／ 或驅動的 identifier 類別（如 psycopg 的 ）。

3. 最小權限：即使注入成功，一個只有 DML 權限、受 RLS 限制、不能讀檔案的帳號能造成的損害有限。

4. 輸入驗證與輸出編碼是輔助（防止邏輯錯誤與 XSS），不能取代前三項；WAF 只能攔截已知樣式。

5. 不要把資料庫錯誤訊息原樣回給使用者（洩漏 schema），並對 等延時函數的呼叫保持警覺。

CREATE FUNCTION count_rows(tbl text, col text, val text) RETURNS bigint
LANGUAGE plpgsql SECURITY INVOKER SET search_path = pg_catalog, pg_temp AS $$
DECLARE n bigint;
BEGIN
  EXECUTE format('SELECT count(*) FROM %I WHERE %I = $1', tbl, col) INTO n USING val;
  RETURN n;
END $$;

靜態加密

• 密碼永遠不儲存明文，也不儲存可逆加密：以 bcrypt／scrypt／Argon2 等慢雜湊加鹽（應用層，或 的 ）。

• 金鑰管理是加密的核心難題：金鑰與資料分離、定期輪替、以 KMS/HSM 保管、稽核金鑰使用。Crypto-shredding（刪除金鑰即等同刪除資料）是實作 GDPR「被遺忘權」於備份中的常用技巧。

• 備份、WAL 封存、日誌、 輸出與正式資料同等敏感，必須同樣加密並控管存取。

• 開發／測試環境應使用去識別化的資料（PostgreSQL Anonymizer 擴充套件可做靜態或動態遮罩）。

稽核與監控

• 內建日誌：、、（或 ； 的量與敏感資料風險很高）、、 含使用者、資料庫、來源位址、應用程式名稱。

• pgaudit：符合稽核需求的結構化記錄——session audit（依類別 READ/WRITE/DDL/ROLE/FUNCTION/MISC）與 object audit（針對特定表，透過授權給稽核角色來標記）；記錄的是實際執行的語句（含 prepared statement 的參數，若開啟）。

• 日誌要送出資料庫主機（SIEM／集中式日誌），本機日誌可被同一個攻擊者刪除；設定保留期限與完整性保護。

• 監控異常：非上班時間的 superuser 登入、大量 的匯出行為、失敗登入暴增、來自新 IP 的連線、 中突然出現的新查詢樣板。