資料安全儲存風險與防護措施

資料安全是現代數位環境的核心議題，資料洩露的風險日益增高，無論是資料函式庫被攻擊者下載，或是硬碟等儲存媒體被竊取，都會造成嚴重損失。因此，實施資料函式庫層級加密至關重要，它能有效防止資料被直接竊取，並為資料安全增加一道防線。選擇強健的加密演算法，例如 AES，並瞭解其潛在風險，才能有效降低資料洩露的機率。除了加密，驗證資料完整性也同樣重要，雜湊函式可以作為資料的數位指紋，用於檢測資料是否被篡改。

資料儲存的安全風險與防護措施

在現代數位環境中，資料的安全儲存至關重要。無論是硬碟還是其他形式的儲存裝置，其中的檔案和資料函式庫都可能因漏洞而導致機密資料被洩露。攻擊者可以輕易地下載整個資料函式庫，或者小偷可以直接竊取硬碟等儲存媒體，這些行為都會增加資料洩露的規模和影響。

資料靜態儲存的風險

當攻擊者取得資料函式庫時，他們能夠一次性檢查所有內容。這與動態資料洩露不同，後者需要攻擊者篩選多筆交易以找到有價值的資訊。靜態資料的洩露通常使攻擊者能夠大規模出售匯總資料。

資料函式庫層級加密的重要性

減少這種風險的主要方法是實施資料函式庫層級加密。與 SSL 和其他加密通訊手段類別似，靜態資料加密通常能夠阻止攻擊者直接取得資料。至少，加密可以作為一種延遲手段，讓攻擊者在破解資料內容時耗費更多時間。這需要使用足夠強壯的加密演算法，而非簡單的混淆或自行開發的加密方法。

加密演算法的選擇

使用標準的加密演算法，如進階加密標準（AES），仍然存在風險，因為可能存在已知的快速破解方法。雖然有傳聞指出某些國家級的攻擊者可能擁有後門，但目前缺乏實質證據。無論如何，擁有大量資源的攻擊者仍可能透過暴力破解來取得資料。

加密的實務應用

儘管存在上述風險，但這並不應該阻止我們在可能的情況下使用資料函式庫或檔案層級的加密。瞭解風險的存在並採取相應的防護措施是至關重要的。就像門鎖可以被竅鎖匠開啟並不代表我們應該讓門保持開啟狀態一樣，加密可以有效地保護我們的資料。

攻擊者的行為模式

試想一個危險的停車場場景。小偷隨機測試車門是否上鎖，如果車門未鎖，他們會直接放棄該車並轉向下一輛。這背後的邏輯是，如果車主沒有鎖車門，那麼車內很可能沒有值得偷的東西。相反，如果車門上了鎖，小偷會認為車內有值得偷的東西，從而嘗試解鎖或破壞車窗。

同樣地，當攻擊者發現加密檔案或資料時，他們可能會加大破解的力度，因為他們認為加密的資料內部一定有有價值的內容。兩者之間的關鍵區別在於，攻擊者已經獲得了一定的存取許可權以取得加密檔案。最終，如果加密足夠強壯，攻擊者意識到需要耗費大量資源來存取未加密的內容時，他們很可能會轉向下一個目標。

加密技術的侷限性

根本問題在於，隨著電腦運算能力的提升和加密演算法中的漏洞被發現，破解加密資料的成本會降低。對於時效性資料來說，這個問題較小，因為這些資料在 10 年後可能已經失去價值。然而，對於像社會保險號碼和醫療記錄等長期資料來說，這是一個嚴重的問題。

資料完整性的驗證

維護和驗證資料的完整性比維護機密性和可用性更加困難。為了維護完整性，需要有一個可驗證的原始真實資料來源。作為攻擊者，如果能夠同時修改資料的完整性和驗證來源，那麼就無法驗證資料的完整性。更糟糕的是，因為驗證來源與被惡意修改的資料相匹配，問題可能不會立即被發現。

校驗和的應用

校驗和或單向雜湊是一種常見的驗證完整性的方法。對電腦上的資料檔案或隨機字元串執行雜湊函式，傳回雜湊字串。傳回的字元串提供了輸入資料的指紋，本質上代表了輸入資料。假設原始檔案的指紋已經被安全儲存，這個指紋可以用來確定當前資料檔案是否被篡改。

# 使用 sha256sum 指令計算檔案的雜湊值
$ echo "file with super secret data" > test.txt
$ sha256sum test.txt

內容解密：

上述指令使用 sha256sum 計算 test.txt 檔案的 SHA-256 雜湊值，並輸出雜湊值。這個雜湊值可以用來驗證檔案內容是否被修改。如果檔案內容發生變化，雜湊值將會完全不同。

# 修改檔案內容並重新計算雜湊值
$ echo "File with super secret data" > test.txt
$ sha256sum test.txt

內容解密：

當檔案中的任何內容發生變化時（例如，將 “file” 中的 “f” 改為 “F”），雜湊值將會發生顯著變化。這種特性使得雜湊值可以用來檢測檔案是否被篡改。

  graph LR
    A[原始檔案] -->|雜湊函式|> B[雜湊值]
    B --> C[儲存雜湊值]
    A --> D[檔案內容變化]
    D -->|雜湊函式|> E[新的雜湊值]
    B -->|比較|> E
    E -->|不同|> F[檔案被篡改]

圖表翻譯： 此圖示展示了使用雜湊函式驗證檔案完整性的流程。首先，對原始檔案計算雜湊值並儲存。隨後，如果檔案內容發生變化，再次計算雜湊值並與原始雜湊值進行比較。如果兩個雜湊值不同，則表明檔案已被篡改。

驗證完整性與電子郵件驗證技術

在資訊安全領域中，驗證資料的完整性以及來源的真實性是至關重要的。本章節將探討如何使用雜湊函式驗證檔案完整性，以及如何利用特定技術驗證電子郵件的來源。

使用雜湊函式驗證檔案完整性

雜湊函式是一種單向函式，能夠將任意大小的資料轉換成固定長度的字串，通常被稱為雜湊值或數位指紋。常見的雜湊函式包括SHA256和MD5等。以SHA256為例，當對一個檔案執行sha256sum命令時，會輸出一個64位元的十六進位字串。

圖3-3：檔案雜湊值對比

  graph LR
    A[原始檔案] -->|sha256sum|> B[原始雜湊值]
    C[修改後檔案] -->|sha256sum|> D[新雜湊值]
    B --> E[比較]
    D --> E
    E -->|不同|> F[檔案被修改]

圖表翻譯： 此圖示展示了原始檔案與修改後檔案的雜湊值比較過程。當檔案內容發生變化時，其對應的雜湊值會完全不同，從而表明檔案完整性遭到破壞。

內容解密：

1. 雜湊函式能夠檢測檔案是否被修改，即使是微小的變化也會導致雜湊值的巨大差異。
2. 雖然雜湊值變化表明檔案被修改，但這並不一定意味著惡意行為，也可能是正常使用或磁碟錯誤導致的。
3. 將修改後的檔案還原原狀，其雜湊值也會還原到原始狀態，這是雜湊函式的一個特性。

雜湊函式的侷限性與攻擊

儘管雜湊函式能夠提供資料完整性驗證，但它們並非完美無缺。理論上，不同的檔案可能會產生相同的雜湊值，這種情況被稱為碰撞。此外，攻擊者可能會替換正常的雜湊函式程式，使惡意檔案透過驗證。

許多軟體供應商提供雜湊值以供使用者驗證下載檔案的完整性。然而，如果攻擊者能夠存取關鍵基礎設施，他們不僅可以替換原始檔案，還可以替換正確的雜湊值，從而繞過驗證機制。

演進中的雜湊函式

隨著計算能力的提升和攻擊手段的進步，雜湊函式也在不斷演進。早期的訊息摘要（Message Digest）演算法逐漸被安全雜湊演算法（SHA）取代。目前，SHA256是常見的選擇，但未來可能會轉向SHA512或其他更安全的演算法。

根據金鑰和憑證的身份驗證

除了密碼驗證外，根據金鑰和憑證的身份驗證能夠有效防止密碼被猜測或暴力破解。以SSH協定為例，OpenSSH實作支援金鑰和憑證兩種驗證方式。在憑證驗證模式下，需要建立一個憑證授權單位（CA），並由該CA簽發伺服器信任的憑證。金鑰驗證則需要在伺服器上組態信任關係，接受特定的金鑰。

在DevSecOps流程中，無論採用金鑰還是憑證驗證，金鑰分發過程都可以實作自動化。憑證驗證的優勢在於能夠在環境建立時分發必要的OpenSSH組態，從而簡化管理工作。

驗證電子郵件來源

有多種技術可以幫助驗證電子郵件來源，包括SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）和DMARC（Domain-based Message Authentication, Reporting, and Conformance）。

1. SPF：允許網域管理員指定哪些IP位址被允許傳送代表該網域的電子郵件。如果來自某個網域的電子郵件源自未授權的IP位址，則該郵件可能被視為無效。

2. DKIM：使用公開金鑰密碼學為電子郵件新增數位簽章，接收方可以透過驗證簽章來確認郵件是否由聲稱的發件人傳送。

這些技術共同構成了電子郵件驗證的重要手段，有助於防止電子郵件欺詐和網路釣魚攻擊。

電子郵件驗證流程圖

  sequenceDiagram
    participant Sender as "寄件者"
    participant EmailServer as "電子郵件伺服器"
    participant Receiver as "收件者"
    Sender->>EmailServer: 傳送電子郵件
    EmailServer->>Receiver: 轉發電子郵件
    Note over Receiver: 檢查SPF記錄
    Note over Receiver: 驗證DKIM簽章
    Receiver->>Receiver: 處理郵件（接收/拒絕）

圖表翻譯： 此圖示描述了電子郵件傳輸過程中的驗證步驟，包括檢查SPF記錄和驗證DKIM簽章，以確保電子郵件來源的真實性。

確保電子郵件安全：SPF、DKIM 與 DMARC 的應用

在現代網路環境中，電子郵件的安全性至關重要。為了防止電子郵件欺騙和網路釣魚攻擊，企業通常會採用 SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail） 和 DMARC（Domain-based Message Authentication, Reporting, and Conformance） 等技術來驗證電子郵件的真實性。

SPF：寄件者策略框架

SPF 是一種用於驗證電子郵件寄件者身份的技術。透過在 DNS 記錄中設定 SPF，網域名稱擁有者可以指定哪些 IP 地址被授權傳送以該網域名稱為寄件者的電子郵件。這樣可以有效防止攻擊者偽造電子郵件寄件者。

#### SPF 紀錄範例：
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all"

內容解密：

上述範例中，example.com 的 SPF 記錄指定了允許傳送電子郵件的 IP 範圍 (ip4:192.0.2.0/24)，並包含了另一個 SPF 記錄 (include:_spf.example.net)。最後的 -all 表示拒絕所有未被明確授權的來源。

DKIM：網域名稱金鑰識別郵件

DKIM 是一種數位簽章技術，用於驗證電子郵件的完整性和寄件者身份。透過在電子郵件標頭中加入 DKIM 簽章，收件者可以驗證該郵件是否在傳輸過程中被篡改。

#### DKIM 簽章範例：
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=selector1; h=from:to:subject:date;
    bh=4T...; b=dK...;

內容解密：

上述範例中，DKIM 簽章包含了簽章版本 (v=1)、簽章演算法 (a=rsa-sha256)、雜湊值 (bh=4T...) 和簽章值 (b=dK...)。收件者可以使用寄件者的公鑰來驗證簽章的真實性。

DMARC：根據網域名稱的訊息認證、報告和一致性

DMARC 結合了 SPF 和 DKIM，提供更全面的電子郵件驗證和報告功能。透過設定 DMARC 記錄，網域名稱擁有者可以指定如何處理未透過驗證的電子郵件，並接收相關的報告。

#### DMARC 紀錄範例：
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc_aggregate@example.com"

內容解密：

上述範例中，DMARC 記錄指定了處理未透過驗證的電子郵件的策略 (p=quarantine)，並設定了接收匯總報告的郵件地址 (rua=mailto:dmarc_aggregate@example.com)。

圖表翻譯：電子郵件驗證流程

  graph LR
    A[寄件者] -->|傳送電子郵件|> B[收件者]
    B -->|驗證SPF|> C{SPF驗證結果}
    C -->|透過|> D[繼續驗證DKIM]
    C -->|失敗|> E[根據DMARC策略處理]
    D -->|驗證DKIM|> F{DKIM驗證結果}
    F -->|透過|> G[郵件透過驗證]
    F -->|失敗|> E

圖表翻譯： 此圖示描述了電子郵件驗證的流程。首先，收件者會驗證電子郵件的 SPF 是否透過。如果透過，則繼續驗證 DKIM。如果任何一項驗證失敗，則根據 DMARC 的策略進行處理。

服務水平協定（SLA）與服務水平目標（SLO）

為了確保系統的可用性，企業通常會與供應商簽訂服務水平協定（SLA），或在內部制定服務水平目標（SLO）。SLA 和 SLO 的目的是定義系統的可用性和效能標準。

定義 SLA 的步驟：

1. 識別相關利益者：確定需要系統可用性的相關人員。
2. 識別可用性需求：瞭解系統的可用性需求。
3. 定義可用性：明確定義系統的可用性指標。
4. 估計成本：計算提供所需可用性所需的成本。

圖表翻譯：SLA 定義流程

  graph LR
    A[識別相關利益者] --> B[識別可用性需求]
    B --> C[定義可用性]
    C --> D[估計成本]
    D --> E[制定SLA]

圖表翻譯： 此圖示描述了定義 SLA 的流程。首先，需要識別相關利益者，接著瞭解他們的可用性需求。然後，定義系統的可用性指標，並估計提供所需可用性所需的成本。最終，制定 SLA 以確保系統的可用性。

系統可用性定義與成本估算

在評估系統可用性時，瞭解使用者的需求至關重要。無論是透過訪談還是觀察，收集系統使用日誌中的補充資訊也是必要的。這可能包括網路相關的流量日誌或 Web 伺服器的請求日誌。透過訪談和觀察收集的資訊可能會在系統日誌中發現新的線索，需要進行另一輪訪談。

系統可用性的定義

系統的可用性是從使用者的角度出發的。但「可用性」究竟意味著什麼？是對 ping 的回應就足以證明可用性，還是服務需要在協定層面做出回應，例如回應 HTTP 請求？可以接受的回應時間間隔是多少——是毫秒、秒還是分鐘？答案取決於系統和流程。

監控軟體的評估準則

監控軟體可以檢查各種指標來確定可用性。一些軟體，如 Prometheus，需要在被監控的裝置上安裝軟體。其他軟體，如 Zabbix 和 Icinga，可以使用 SSH 在客戶端裝置上執行命令。還有一些專有的監控解決方案。在考慮監控軟體解決方案時，可以使用表3-2中的準則。

表3-2. 監控軟體的評估準則

定義可用性與成本估算的關聯

定義可用性直接導致系統監控的增強，以及中間系統和單點故障的識別。單點故障是指如果缺失或不可用，將導致整個系統當機的元件。例如，具有三個 Web 伺服器的負載平衡組態為 Web 請求提供了冗餘。如果 Web 伺服器1發生故障，Web 伺服器2和3可以處理負載，而 Web 伺服器1正在修復。然而，在圖3-4中所示的組態中，只有一個負載平衡器。因此，負載平衡器本身代表了一個單點故障。如果負載平衡器出現問題，則所有請求都將停止。

圖3-4. 負載平衡器作為單點故障

成本估算可以透過多種方式完成，具體取決於組織如何處理諸如建築和設施等間接成本。對於一些組織來說，建築物的每平方英尺都會在內部進行核算，並與其相關聯一個成本因子。例如，如果行銷部門使用了建築物中30%的空間，那麼與經營建築物相關的成本的30%將被分配為市場預算的成本。在考慮冗餘和SLA/SLO時，如果需要額外的空間來建立冗餘資料中心，那麼就需要考慮相關的成本。

  graph LR;
    A[使用者請求] -->|HTTP 請求|> B[負載平衡器];
    B --> C[Web 伺服器1];
    B --> D[Web 伺服器2];
    B --> E[Web 伺服器3];

圖表翻譯：

此圖示展示了一個典型的負載平衡組態，其中使用者請求透過負載平衡器分配到多個 Web 伺服器。負載平衡器的作用是將請求均勻分配到各個伺服器，以提高系統的可用性和效能。

內容解密：

上述Mermaid圖表描述了一個簡單的負載平衡架構。使用者請求首先到達負載平衡器，然後由負載平衡器根據一定的演算法將請求分配到後端的 Web 伺服器。這種架構可以提高系統的可用性，因為即使某個 Web 伺服器出現故障，其他伺服器仍然可以繼續處理請求。

import random

class LoadBalancer:
    def __init__(self, servers):
        self.servers = servers

    def get_server(self):
        # 簡單的輪詢演算法
        return random.choice(self.servers)

# 示例用法
servers = ['Web 伺服器1', 'Web 伺服器2', 'Web 伺服器3']
load_balancer = LoadBalancer(servers)
selected_server = load_balancer.get_server()
print(f"選中的伺服器是：{selected_server}")

內容解密：

這段Python程式碼實作了一個簡單的負載平衡器。LoadBalancer 類別接受一個伺服器列表作為輸入，並使用 get_server 方法根據簡單的隨機選擇演算法傳回一個伺服器。這種實作方式模擬了負載平衡器將請求分配到後端伺服器的過程。