資安稽核紀錄國際要求與實務

請問security audit log需要紀錄哪些內容才能符合國際要求, 有哪些國際要求需要特別遵循?

進行資安稽核紀錄（Security Audit Logging）時，重點不在於「記下所有事」，而在於「記下關鍵的事」。如果紀錄太少，發生事件時無法追蹤；紀錄太多，則會淹沒在雜訊中且增加儲存成本。

要符合國際標準（如 ISO 27001、NIST、SOC2 或 PCI DSS），你的日誌必須能夠還原人事時地物。

1. 稽核紀錄應包含的核心內容

無論在哪個標準下，一筆合格的稽核日誌通常需要包含以下欄位：

• 時間戳記 (Timestamp)： 必須精確（建議同步 NTP 全球標準時間）。
• 使用者識別 (User Identity)： 誰執行了這項動作？（包含帳號 ID、IP 位址）。
• 事件類型 (Event Type)： 發生了什麼事？（例如：登入、刪除、修改權限）。
• 物件識別 (Object Identity)： 哪個檔案或系統被存取了？
• 結果 (Success/Failure)： 動作成功還是失敗？（失敗的登入嘗試尤其重要）。
• 來源與目的地 (Source/Destination)： 請求從哪裡來，發往哪個端點。

建議紀錄的關鍵事件清單

2. 必須遵循的主要國際標準

不同的產業與地區，會有不同的合規要求：

ISO/IEC 27001 (資訊安全管理系統)

這是最通用的標準。其附錄 A (Control A.12.4) 明確要求：

• 應產生、保留並定期審查紀錄使用者活動、異常與資安事件。
• 防竄改： 必須保護日誌，防止管理員或駭客事後刪除自己的操作紀錄。

NIST SP 800-53 (美國國家標準)

常被視為資安實務的黃金標準（特別是 AU 家族：Audit and Accountability）：

• 要求紀錄的詳細程度必須足以支撐事後的「鑑識調查」。
• 強調日誌儲存空間管理，避免因硬碟滿了而導致紀錄中斷。

PCI DSS (支付卡產業資料安全標準)

如果你處理信用卡交易，這是強制性的：

• Section 10： 要求紀錄所有對持卡人資料環境 (CDE) 的存取。
• 時效： 日誌必須在線保存至少 3 個月，並離線備份至少 1 年。

GDPR (歐盟一般資料保護規則)

雖然 GDPR 沒寫明技術細節，但要求具備「問責制」(Accountability)：

• 當發生資料洩漏時，你必須有紀錄證明你曾採取防護措施，並能追蹤洩漏範圍。

3. 日誌管理的最佳實務

光有紀錄是不夠的，國際稽核員通常會檢查以下機制：

1. 集中化管理 (Centralization)： 使用 SIEM (如 Splunk, ELK, Azure Sentinel) 將各裝置日誌匯整，避免分散。
2. 唯讀與完整性： 確保日誌是「Append Only」（只能增加，不能修改）。
3. 定期審查： 稽核員會問：「你多久看一次這些 Log？」自動化告警機制是加分項。
4. 同步時鐘： 所有伺服器的時間必須一致，否則在還原攻擊鏈時會發生時序錯亂。

下一步建議： 您目前是為了準備特定的認證（如 ISO 27001），還是為了建立內部的資安監控中心 (SOC)？我可以根據您的目標，提供更具體的 Log 格式範例（例如 JSON 或 Syslog 格式）。

目標是建立內部的資安監控中心 (SOC), 請提供更具體的 Log 格式範例

建立內部的資安監控中心 (SOC) 時，最核心的挑戰在於「正規化」(Normalization)。如果各個設備各說各話（有的用 Syslog，有的用 XML），你的 SIEM（日誌分析系統）就無法進行有效的關聯分析。

目前的行業趨勢是優先使用 JSON 格式，因為它具備良好的結構化特徵，易於被 Splunk、Elasticsearch (ELK) 或 Azure Sentinel 解析。

1. 認證與授權日誌 (JSON 範例)

這是 SOC 監控「異常登入」或「暴力破解」最關鍵的資料。

{
  "timestamp": "2026-03-02T14:30:05.123Z",
  "log_source": "Active Directory",
  "event_id": 4625,
  "event_type": "Authentication",
  "status": "Failure",
  "user": {
    "name": "admin_backup",
    "domain": "CORP",
    "source_ip": "203.0.113.42"
  },
  "reason": "Invalid password",
  "severity": "Medium"
}

SOC 監控點： 如果同一個 source_ip 在一分鐘內產生 50 筆 status: Failure，應立即觸發告警。

2. 網路防火牆/流量日誌 (CEF 格式範例)

許多網通設備（如 Palo Alto, Fortinet）支援 CEF (Common Event Format)，這是專為 SOC 整合設計的標準格式。

CEF:0|Vendor|Product|Version|ID|Name|Severity|[Extension]

範例： CEF:0|Fortinet|FortiGate|6.0|0001|Traffic Denied|6|src=10.0.0.5 dst=8.8.8.8 dpt=53 proto=UDP msg=Blocked by blacklisted IP

• src/dst: 來源與目的 IP。
• dpt: 目的地連接埠（DNS 53）。
• msg: 被封鎖的原因。

3. 端點偵測與回應 (EDR) 日誌 (JSON 範例)

用於追蹤惡意程式在主機上的行為（例如 PowerShell 執行異常指令）。

{
  "timestamp": "2026-03-02T15:00:20Z",
  "host": "WORKSTATION-01",
  "action": "Process_Created",
  "process": {
    "name": "powershell.exe",
    "command_line": "powershell.exe -ExecutionPolicy Bypass -File C:\\temp\\payload.ps1",
    "parent_process": "explorer.exe"
  },
  "user": "marketing_staff_01"
}

SOC 監控點： command_line 中出現 -ExecutionPolicy Bypass 或 EncodedCommand 通常是攻擊徵兆。

4. 雲端服務日誌 (AWS CloudTrail 範例)

若公司使用雲端環境，API 的呼叫紀錄是稽核重點。

{
  "eventTime": "2026-03-02T16:20:00Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateUser",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "root_account"
  },
  "sourceIPAddress": "1.2.3.4",
  "userAgent": "aws-cli/2.0.0"
}

5. SOC 日誌收集架構圖

為了確保這些 Log 能被有效處理，您的 SOC 架構應如下圖所示：

總結：SOC 日誌的「黃金五項」

在建立 SOC 時，請確保你的 Log 接收器能解析出以下欄位，這被稱為 ECS (Elastic Common Schema) 或類似的標準：

下一步建議： 建立 SOC 的第一步通常是選擇 SIEM 平台（如開源的 ELK/Wazuh 或商用的 Splunk/Sentinel）。您是否已經決定了要使用哪套工具？我可以針對該工具提供更精確的解析規則 (Parsing Rules) 設定建議。

比較SIEM平台, 並且說明如何選擇

建立內部的資安監控中心 (SOC)，選擇 SIEM 平台就像選車：你要的是一台改裝空間極大的賽車（Splunk），還是一台整合完善的豪華休旅車（Sentinel），或者是一台需要自己動手組裝的經濟型房車（Wazuh）？

以下是 2026 年主流 SIEM 平台的對比與選擇指南。

1. 主流 SIEM 平台大比拼

2. 核心選手深剖

Splunk：資安界的瑞士刀

• 優點： 幾乎能吃進任何格式的 Log。它的生態系極其龐大，隨便找個防火牆都有現成的 App 可以用。
• 缺點： 貴，而且需要專業的 Splunk 管理員來維護和調優。

Microsoft Sentinel：雲端原生的懶人包

• 優點： 只要你是 Azure 使用者，按幾個鈕就能開始收 Log。它結合了 Security Copilot (AI)，能用自然語言幫你寫查詢語句。
• 缺點： 跨雲（如 AWS/GCP）或地端設備的整合成本較高，且容易被微軟生態系綁死。

Wazuh：預算守護者

• 優點： 它是目前最受歡迎的開源選擇，不只是 SIEM，還能直接當 EDR 用（監控端點檔案變更、漏洞掃描）。
• 缺點： 你需要一個懂 Linux 和正規表達式 (Regex) 的工程師來維護它，否則它的警報會讓你崩潰。

3. 如何選擇？（決策框架）

你可以透過以下五個維度來做最後決定：

第一步：檢視資料來源 (Where is your data?)

• 全在雲端 (Azure/M365)： 優先選 Sentinel。
• 地端機房為主： Splunk 或 QRadar 較穩健。
• 混合雲且大量 Linux： Elastic 或 Wazuh。

第二步：評估技術團隊能力 (Skillset)

• 你有專門的資安工程師可以寫程式與調優嗎？
• Yes: Elastic, Wazuh。
• No: Sentinel, Splunk (Managed version)。

第三步：計算成本模型 (Budget)

• 固定預算： 避開按資料量計費的 Splunk，改選按節點計費的 Elastic 或免費的 Wazuh。
• 隨業務波動： Sentinel 的用多少付多少最合適。

第四步：反應速度要求 (Performance)

• 如果你需要在幾秒內從 PB 等級的資料中搜尋某個駭客 IP，Elastic 的搜尋引擎效能通常是首選。

第五步：合規與自動化 (SOAR)

• 如果你的 SOC 需要「自動化封鎖 IP」，請確認該平台是否包含 SOAR（安全編排與自動化響應）功能。Sentinel 與 Splunk 在這方面領先。

我的真心建議： 如果您是 「初創 SOC」且預算有限，先架一套 Wazuh 跑跑看，感受一下處理日誌的痛苦與樂趣；如果您是 「企業級需求」且希望下週就開張，直接開 Microsoft Sentinel 是風險最低的路。

下一步建議： 您目前公司的環境主體是哪一種？（例如：全微軟環境、大量 Linux 伺服器、還是混合雲環境？）我可以針對您的環境推薦最適合的資料匯入工具 (Log Forwarder)。

請教如果資料庫使用PostgreSQL, audit log是先寫入PostgreSQL, 然後再透過Log Forwarder寫到專門處理的平台, 還是直接寫, 比較其優缺點

在 PostgreSQL 的環境中，關於稽核紀錄（Audit Log）的傳輸路徑，資安專家通常會給出一個非常明確的建議：千萬不要把稽核紀錄「長期」儲存在資料庫本身的資料表中。

以下為您詳細分析「先寫入 DB 表格再轉發」與「直接寫入檔案/串流並轉發」的優缺點比較，這對您建立 SOC 監控中心至關重要。

1. 方案比較：寫入 Table vs. 寫入 File/Stream

2. 為什麼 SOC 實務上偏好「方案 B」？

在建立 SOC 時，我們追求的是 「職責分離」(Separation of Duties, SoD)。

1. 不可否認性： 稽核日誌的生命週期應該獨立於資料庫。如果日誌存在 Table 裡，DBA 有權限動它；如果日誌是寫進作業系統檔案並立即被 Forwarder 抓走，DBA 就很難在不留痕跡的情況下修改紀錄。
2. 避免死鎖與崩潰： 當資料庫因為效能壓力或是 Transaction 鎖定時，寫入 Table 的稽核機制可能會跟著失敗或變慢，導致整個系統掛掉。寫入檔案（或是透過 pgaudit 擴充套件輸出）則相對穩健許多。

3. 推薦的架構建議 (PostgreSQL 最佳實務)

對於要對接 SOC 的 PostgreSQL，最專業的作法是：

第一步：安裝 pgaudit 擴充套件

PostgreSQL 內建的日誌比較簡陋。pgaudit 是專門為稽核設計的，它可以詳細記錄誰對哪個物件做了什麼（如 SELECT, INSERT, GRANT）。

第二步：設定輸出至本地檔案 (CSV 格式)

將 pgaudit 的內容輸出到本地磁碟的 log 目錄，並建議使用 CSV 格式，因為它結構清晰，方便解析。

第三步：部署 Log Forwarder (例如 Filebeat 或 Vector)

在資料庫伺服器上安裝一個輕量級的 Agent（Sidecar 模式）：

1. Filebeat/Fluent-bit 讀取該 CSV 檔案。
2. 即時傳送 到您的 SIEM 平台（如 Splunk, Sentinel, 或 Wazuh）。

4. 具體的 Log 內容範例 (pgaudit 格式)

當您透過 Forwarder 轉發到 SOC 時，您的 Log 看起來會像這樣，這才是符合國際稽核要求的細節：

"2026-03-02 10:00:01 UTC","admin_user","my_db","10.0.5.20","SESSION","READ","SELECT","TABLE","employees","SELECT name, salary FROM employees;"

• 這筆紀錄清楚顯示了：時間、人員、資料庫、來源 IP、動作類型（讀取）、執行指令、受影響的物件（員工表）以及原始 SQL。

下一步建議： 您是否需要我提供針對 pgaudit 的具體安裝指令，或是如何撰寫 Log Forwarder (如 Filebeat) 的配置檔來解析 PostgreSQL 的日誌？

如果在API中間層寫audit log到File/或是stream, 但是因為有多台API server, 使用pgaudit不會有分散的問題, 但是File/Scream是否會有同時多台寫入Forwarder的問題, 請比較這兩個的優缺點

這是一個非常專業的架構問題。在分散式系統中，「在哪個層級紀錄」以及「如何匯流而不塞車」是建立 SOC 的兩大技術挑戰。

首先要澄清一個觀念：pgaudit 其實也有分散問題，因為如果你有 Read Replicas（唯讀副本），每一台資料庫伺服器都會產生自己的 Log。

以下針對 API 中間層紀錄 與 資料庫層 (pgaudit) 紀錄 進行深度對比，並回答您關於「同時寫入 Forwarder」的疑慮。

1. API 中間層 vs. 資料庫層 (pgaudit) 比較

2. 關於「多台同時寫入 Forwarder」的疑慮

您擔心的「多台 API Server 同時寫入會不會出問題」，在 SOC 架構中通常有兩種解決方案，取決於您所謂的「寫入」是指哪一種：

情況 A：多台 API 同時寫入「同一個檔案」 (Network Share/NFS)

• 強烈建議：不要這樣做。
• 多台伺服器同時爭奪一個檔案的寫入鎖（File Lock），會導致嚴重的效能瓶頸，甚至導致 Log 遺失或檔案毀損。

情況 B：多台 API 各自寫入「各自的本地檔案」，再由 Forwarder 傳送

• 這是標準作法。 每台 API Server 都有自己的 audit.log，各自跑自己的 Forwarder (如 Filebeat)。
• 優點： 完全分散式，沒有競爭問題，且具備本地緩衝（若網路斷線，Log 還在硬碟裡）。

情況 C：多台 API 透過 Stream 直接打向「中心收集器」 (Logstash/Fluentd)

• 這確實會產生您擔心的 「漏斗效應」 (Fan-in Problem)。
• 解決方法： 在收集器前面擋一個 訊息佇列 (Message Queue)，例如 Kafka 或 Redis。

3. 解決分散與併發問題的標準架構 (SOC Best Practice)

為了符合國際資安要求，建議採用 「Agent-Aggregator」 架構：

1. 分散端 (Edge)： 每台 API Server 與 DB Server 都安裝輕量級 Agent (如 Vector 或 Filebeat)。
2. 緩衝層 (Buffer)： 所有 Agent 將 Log 推送到 Kafka。Kafka 具備極高的併發處理能力，能承受數萬台伺服器同時寫入而不丟失資料。
3. 處理層 (Processor)： 您的 SIEM (如 ELK/Splunk) 從 Kafka 慢慢抓資料出來解析。

4. 最終建議：我該選哪一個？

在成熟的 SOC 環境中，通常是 「兩者都要」，但分工不同：

• API 中間層 Log： 用來滿足 「業務合規」（例如：誰看過這筆客戶個資？）。

• 作法： 寫入本地 File，由 Agent 非同步送走。

• Database pgaudit Log： 用來滿足 「系統安全稽核」（例如：DBA 有沒有私下改動權限表？）。

• 作法： 使用 pgaudit 輸出至 DB 伺服器本地，再由 Agent 送走。

這兩份 Log 最後會在 SIEM 平台透過 Request ID 或 Timestamp 進行「關聯分析」(Correlation)。

下一步建議： 您的 API Server 是部署在 Kubernetes (K8s) 環境中，還是獨立的 虛擬機 (VM)？這會決定 Forwarder（Agent）的部署方式（Sidecar 模式 vs. 原生安裝），我可以提供相對應的配置範例。

先部署在VM, 之後會擴展到K8s, 請兩種都提供並比較

不論是在 VM 還是 K8s 環境中，建立 SOC 的核心目標都是「日誌不丟失、不被竄改、即時傳輸」。

以下為您分析這兩種環境的部署方式、具體配置範例以及深度對比。

1. VM 環境部署：系統服務模式 (Standard Agent)

在 VM 中，Log Forwarder（如 Filebeat 或 Vector）通常作為 Systemd 服務 運行，直接監控磁碟上的日誌檔。

架構與實作

• API / DB: 將日誌寫入 /var/log/app/audit.log。
• Forwarder: 安裝 Filebeat，它具備「背壓處理」(Back-pressure handling)，如果後端 SOC 平台塞車，它會暫緩讀取。

Filebeat 配置範例 (filebeat.yml)：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/audit.log
    - /var/log/postgresql/audit.csv
  fields:
    env: production
    log_type: audit
  # 確保日誌被標記，方便 SOC 關聯分析
  fields_under_root: true

output.kafka: # 建議先打入 Kafka 緩衝
  hosts: ["kafka-broker:9092"]
  topic: "audit-logs"

2. K8s 環境部署：動態編排模式 (DaemonSet / Sidecar)

在 K8s 中，日誌處理有兩種主流作法：

A. DaemonSet 模式 (推薦：標準做法)

在每個 Node 部署一個 Forwarder 實例，收集該節點上所有 Pod 的 stdout（標準輸出）。

• 優點： 節省資源（一個節點只需一個 Agent）。
• 缺點： 如果應用程式將稽核日誌寫入「檔案」而非 stdout，則需要額外掛載磁碟。

B. Sidecar 模式 (推薦：高安全性/稽核專用)

在 API Pod 內多塞一個 Forwarder 容器，專門盯著該 API 產生的稽核檔。

• 優點： 日誌隔離性最強，可以對特定 API 進行細部過濾，適合「高敏感稽核」。
• 缺點： 資源消耗較大（每個 Pod 都要多跑一個 Container）。

K8s Sidecar 配置範例 (Deployment.yaml)：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
      - name: api-container
        image: my-api:latest
        volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app
      - name: filebeat-sidecar # Sidecar 容器
        image: docker.elastic.co/beats/filebeat:8.x
        volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app
      volumes:
      - name: shared-logs
        emptyDir: {} # 共享記憶體或磁碟

3. VM vs. K8s 部署對比

4. 關鍵決策與轉換路徑建議

如果您打算從 VM 遷移到 K8s，這裡有幾個 SOC 建立的「地雷」要避開：

1. 時間同步 (NTP)：
2. VM： 必須確保所有機器的 chronyd 或 ntp 服務正常，否則 SOC 的事件關聯會失效。

3. K8s： 通常依賴 Node 的時間，但建議在容器啟動時強制設定 TZ (時區) 環境變數。

4. 日誌切割 (Log Rotation)：

5. VM： 務必設定 logrotate，否則磁碟會被稽核日誌塞滿，導致服務崩潰。

6. K8s： 如果寫入 stdout，Docker/Containerd 會幫你切割；如果是 Sidecar 寫入檔案，則需要在 Sidecar 內自行處理切割。

7. 從 VM 擴展到 K8s 的「過渡橋樑」：

8. 建議選用 Vector (vector.dev) 或 Fluent-bit 作為您的 Forwarder。
9. 這兩者都同時支援 VM 安裝與 K8s 部署，且配置語法高度統一。這樣您在遷移時，SOC 端的解析規則 (Parsing Rules) 完全不需要重寫。

我的最終建議：

• 現階段 (VM)： 採用 Filebeat/Vector + Kafka + SIEM。將 API 稽核與 pgaudit 統一寫入檔案，由 Agent 轉發。
• 未來 (K8s)： 對於 PostgreSQL，建議使用 CloudNativePG 等 Operator，它們內建了日誌流向 Prometheus/Loki 或外部 SIEM 的機制。對於 API，採用 Sidecar 模式處理高敏感稽核日誌，確保日誌與業務流量分離。

您目前是否有偏好的 Log Forwarder 工具（如 Filebeat、Fluent-bit 或 Vector）？我可以為您針對該工具提供 VM 轉 K8s 的「無縫遷移配置」。

在API server寫audit log如何避免被竄改的風險, 如何確保audit log是原始log, 無變更疑慮, 是否每個環節都需要注意這些問題?

確保稽核日誌（Audit Log）的不可竄改性（Immutability）與原始性（Integrity），是資安監控中心（SOC）能否在法律或數位鑑識中站得住腳的關鍵。

這在資安領域被稱為「證據連續性」(Chain of Custody)。是的，每一個環節都需要注意，因為只要有一個斷點，日誌的真實性就會受到質疑。

以下是從「產生」到「存儲」各個環節的防護策略：

1. 產生端（API Server / DB）：減少滯留時間

日誌留在伺服器硬碟裡的時間越長，被竄改的風險就越高。

• 即時轉發 (Immediate Offloading)： 不要等日誌檔案積累到 100MB 才轉傳。使用 Log Forwarder（如 Filebeat 或 Vector）採取「近乎即時」的串流轉發，讓攻擊者在入侵後沒有時間去編輯 /var/log/audit.log。
• 數位簽章與雜湊 (Hashing & Signing)： 在 API 層級產生 Log 時，立即計算該行 Log 的 SHA-256 雜湊值，甚至使用應用程式的私鑰進行簽章。這樣即使檔案被改動，雜湊值也對不起來。
• 使用系統級稽核： API 日誌可能被應用程式漏洞繞過，但 pgaudit（資料庫層）或 Auditd（Linux 核心層）紀錄的是底層動作，較難從應用程式層級進行竄改。

2. 傳輸端（Network）：防止中間人攻擊

日誌在網路流動時，可能被攔截、修改或刪除。

• TLS 加密傳輸： Forwarder 與 SIEM 之間必須強制使用 TLS 1.2+ 加密。
• 雙向認證 (mTLS)： 確保只有合法的 API Server 能把 Log 傳進 SOC，防止駭客偽造大量垃圾 Log（Log Injection）來淹沒真實的攻擊紀錄。
• 使用緩衝層 (Kafka/Redis)： 緩衝層可以防止因為網路斷線導致的「日誌丟失」。日誌一旦進入 Kafka，通常會有多個副本（Replicas），增加刪除難度。

3. 儲存端（SIEM / Log Storage）：WORM 原則

這是最重要的環節。日誌存放的地方必須是「唯寫一次，讀取多次」(Write Once Read Many, WORM)。

• 職責分離 (Separation of Duties)： * DBA（資料庫管理員）不應該有權限進入 SIEM 刪除 Log。

• SOC 管理員不應該有權限進入資料庫修改資料。

• S3 Object Lock / Immutable Storage： 如果日誌備份在雲端（如 AWS S3），開啟 Object Lock 功能。這能保證在設定的時間內（例如 1 年），連 Root 帳號都無法刪除或修改這些檔案。

• 多因素驗證 (MFA)： 刪除任何日誌檔案的操作，必須要求 MFA 授權且記錄在案。

4. 進階防護：日誌鏈結 (Log Chaining)

模仿區塊鏈的概念，每一筆 Log 都包含前一筆 Log 的雜湊值（Hash）。

• Hash Chain： Log #2 = Hash(內容 + Hash of Log #1)。
• 效果： 攻擊者如果想刪除其中一行，後面的所有 Log 雜湊值都會失效，SOC 會立即發現「日誌鏈斷裂」。

5. 各環節注意事項總結表

我的建議：

1. 優先實施「即時轉發」與「WORM 存儲」： 這是投資報酬率最高的做法。
2. 定期進行日誌對帳： 每天比對「API 發出的 Log 總數」與「SIEM 收到的 Log 總數」。如果數量對不起來，就代表有人在中間動手腳。
3. 不信任本地日誌： 永遠假設本地端的日誌是不可靠的，只有進入集中式、受保護的 SIEM 平台後的日誌才是真正的「金標紀錄」。

您目前在考慮這類問題，是否是為了滿足特定的合規（如 PCI DSS 的 10.5 條款要求保護日誌不可竄改）？如果是，我可以直接提供符合該合規標準的具體檢核清單。