多數人做網站備份，在意的是有沒有排程成功、雲端硬碟空間夠不夠；很少人回頭想過，這份備份檔案本身裝了什麼東西，一旦外流會有什麼後果。
一份完整的 WordPress 備份，通常是兩塊東西打包在一起：資料庫傾印檔，裡面躺著會員名單與密碼雜湊；還有站台程式檔案，裡面藏著寫死資料庫帳密與登入金鑰的 wp-config.php。這兩塊只要有一塊外流，對攻擊者來說，等於省掉找漏洞、猜密碼的所有工夫，連國際大型企業都曾因為備份沒加密而整批資料外洩。備份檔案加密，說的正是替這份打包好的複本再上一道鎖，而不是把它丟進看起來安全的雲端硬碟就算了事。
完整備份藏著駭客入侵所需的全部鑰匙
一份完整的 WordPress 備份，不是只有你發表過的文章和上傳的圖片，而是把整個網站原封不動地複製一份。這份複本通常分成兩塊：一塊是資料庫傾印檔，把留言、訂單、會員資料整個倒出來存成一個檔案；另一塊是站台程式檔案，裡面藏著一支叫做 wp-config.php 的檔案，寫死了連進資料庫要用的帳號密碼。
這兩塊各自看起來都只是工程作業的一環，合在一起卻是完全不同的東西。攻擊者想入侵一個網站，通常得先找程式漏洞、再猜密碼、再想辦法繞過登入驗證，每一關都要花時間。但如果他拿到的是這兩塊沒加密的備份檔案，前面提到的每一關幾乎都能直接跳過，資料庫帳密讓他能夠直連資料庫，登入金鑰讓他能夠偽造出一組看起來合法的登入憑證。沒加密的備份，等於把闖進一個網站需要的全部材料，主動打包好交出去。
資料庫傾印裡的會員密碼雜湊與個資
資料庫傾印檔裝的不只是你自己打的文章草稿。WordPress 把每個帳號（包含管理員）的密碼雜湊，存在 wp_users 這張資料表裡，只要備份的是整個資料庫，這張表就會整個跟著被複製一份。如果網站上還有會員系統或 WooCommerce 訂單功能，連帶會員的姓名、Email、收件地址、電話這些個資，也都會一起被打包進同一份 SQL 檔案。
這代表一份沒加密的資料庫傾印檔外流，受影響的不會只有網站內容被亂改這麼單純，連帶會員的個資也一併曝光。備份外掛廠商 UpdraftPlus 的官方文件，就明確把使用者密碼、使用者清單、金鑰列為資料庫裡需要保護的敏感資訊，還為此提供付費版的加密功能；同一家廠商另外還有個資匿名化功能，可以把使用者名稱、Email、IP 位址、自訂欄位裡的個資做匿名化處理，訴求正是符合 GDPR 這類個資保護規範的要求。連做備份工具的廠商自己都把這些資料當成敏感內容看待，一般站長更沒有理由掉以輕心。
wp-config.php 存放著資料庫帳密、四組驗證金鑰
wp-config.php 本來是一支藏起來才安全的檔案，平常不會對外公開，也不會出現在任何前台頁面。根據 WordPress 官方開發文件，這支檔案裡存放著資料庫名稱、資料庫使用者帳號與密碼、資料庫主機位址，另外還有 AUTH_KEY、SECURE_AUTH_KEY、LOGGED_IN_KEY、NONCE_KEY 這 4 組驗證金鑰與對應的 SALT 值。官方文件說明，這些金鑰的作用是替登入驗證用的 cookie 加入隨機元素，讓網站更難被攻破；文件也提到，只要更改這些金鑰，就會讓所有現有的登入憑證失效，所有使用者都得重新登入，反過來說明這些金鑰正是登入狀態驗證的核心材料。
同一支檔案裡還有個常被忽略的設定，叫做 $table_prefix，預設值是 wp_。官方文件提到，這個前綴通常在同一個資料庫要安裝多個 WordPress 站台時才需要更改。對攻擊者來說，拿到 wp-config.php 不只拿到資料庫帳密和金鑰，連資料表的命名規則都一併到手，原本可能要花時間摸索的環節，直接省掉。這支本來就該藏好的檔案，只要備份沒加密，就會整支被完整包進備份檔案裡，等於把原本藏起來的東西重新攤開在外人面前。
舊版 WordPress 的密碼雜湊禁不起現代顯卡暴力破解
上一節提到，資料庫傾印檔裡藏著會員的密碼雜湊。密碼被雜湊過，不代表讀不出來就沒事，雜湊只是把密碼轉換成另一串看起來像亂碼的字串，理論上還是可以靠暴力破解一組一組去湊，差別只在於破解成本有多高。WordPress 在密碼雜湊演算法上，最近才做過一次關鍵升級，升級前後的破解難度，差距相當大。
根據 WordPress 核心開發團隊的官方部落格公告，WordPress 從 6.8 版（2025 年）起，把使用者密碼雜湊的演算法，從舊有的 phpass 可攜式雜湊，換成 bcrypt。官方原文說明，採用 bcrypt 能大幅提高破解一組密碼雜湊所需要的運算成本，這正是密碼雜湊演算法的核心價值，運算成本越高，攻擊者用顯卡跑暴力破解要花的時間跟電費就越可觀。因為 bcrypt 本身有 72 位元組的長度限制，官方在這次升級裡，先加上一道 SHA-384 預先雜湊處理，確保原本比較長的密碼，也能相容於 bcrypt 的規則。
不過這個升級解決的是新產生的密碼雜湊，不是舊備份裡已經存在的密碼雜湊。如果一個站台在升級前就已經有使用者帳號，或者手上留著升級前的舊備份，這些密碼雜湊多半還停留在 phpass 演算法，並沒有因為核心版本升級就自動變成 bcrypt。換句話說，舊站台與舊備份的風險，不會因為 WordPress 本身變安全就跟著消失，對這些舊資料而言，加密備份檔案本身依然是必要的一道防線。WordPress 官方的安全強化指南，也把加密備份列為維持備份資料完整性與可信度的具體建議之一，官方文件提到，替備份加密、替每個備份檔案保留獨立的 MD5 雜湊紀錄、或是把備份放在唯讀媒體上，都能提高對這份資料沒被竄改過的信心。
雲端硬碟的預設加密，擋不住連結外流與帳號被盜
把備份下載下來以後，大多數人的下一步是丟上雲端硬碟存放，順手安心的理由通常是反正雲端硬碟供應商本來就會加密。這個想法只對了一半。雲端服務講的預設加密，術語上叫做 encryption at rest，防護的情境是實體層級的意外，像是機房硬碟被偷走、儲存裝置損壞或報廢，這種情況下，沒有金鑰的人拿到硬體也讀不出內容。
問題出在金鑰是誰持有。以 Google Cloud 為例，官方文件明確說明，預設加密使用的金鑰由 Google 自己擁有並管理。這代表只要有人拿到你分享出去的連結，或是登入了你的雲端硬碟帳號，預設加密完全不構成任何阻礙，因為對方根本不需要碰金鑰，直接透過帳號權限或分享連結就能把檔案內容整個打開來看。這才是備份檔案放上雲端硬碟後，最常見的實際外洩路徑，不是硬碟被駭客攻破加密演算法，而是存取權限本身出了漏洞。Google 官方文件也提到，若要另外取得金鑰本身的邏輯隔離，可以啟用 Cloud Key Management Service、改用客戶自管金鑰；但這解決的是金鑰控制權歸屬的問題，帳號被盜用或分享連結外流這類存取權限層面的風險，終究得靠存取控管本身來擋，不是換一種加密金鑰就能一併解決。
國際企業的外洩案例，問題都出在存取權限而非硬碟本身
這個原理不是理論，兩起近年公開揭露的案例可以直接對照。國際資安媒體 Security Affairs 報導，會計師事務所安永的一份 4TB 的 SQL Server 備份檔案，格式是 .BAK，在 Microsoft Azure 上被設成可以公開存取，內容包含結構描述、使用者資訊、API 金鑰、憑證與驗證權杖。這份備份是資安研究單位 Neo Security 在做被動網路分析時發現的，研究人員透過 DNS SOA 查詢比對檔案內容，確認這份備份歸屬於安永，多次嘗試聯繫未果後，最終透過安永的資安應變小組完成通報。安永隨即完成修補，並確認沒有客戶或機密資料遭到外部存取。
另一起案例是全球最大的信用合作社 Navy Federal Credit Union。金融資安媒體 CUToday 報導，資安研究人員 Jeremiah Fowler 發現一個沒有加密、可以公開存取的 Amazon S3 儲存桶，裡面放著 378GB 的內部備份檔案，包含 14 個 .gz、.sql、.twbx 格式的檔案，內容有使用者名稱、Email、密碼雜湊、金鑰，以及看起來屬於內部系統的商業邏輯與財務績效資料。研究人員沒有看到明碼存放的會員資料，桶內最近一次的 SQL 傾印檔案標記日期是 5 月 29 日，顯示這批資料曝露的時間並非只有一天。收到通報以後，Navy Federal 在幾小時內就限制了這個儲存桶的存取權限。
這兩起案例有一個共通點，外洩的起點都不是加密演算法被攻破，而是存取權限被設得太寬鬆，不管是公開可讀的雲端儲存空間，還是分享連結沒有設限，只要設定一出錯，裡面的內容就直接可讀。連資源充足、資安團隊完整的大型機構都會犯這種疏失，一般中小型網站的備份管理通常更鬆散，風險只會更高，不會更低。就算備份的地點選對了、備份也確實做了，只要檔案本身沒加密，一旦存取設定出錯，內容還是會整包曝光。
備份外掛內建的加密選項，預設大多是關閉的
知道了風險在哪，接下來的問題是怎麼加密。最直覺的做法是看備份外掛本身有沒有內建加密功能，不過老實說，多數熱門外掛的資料庫加密，通常是要另外設定、甚至得升級付費版本才會出現的功能，不是裝好外掛、按下備份鍵就自動套用。
以 UpdraftPlus 為例，官方文件說明，要替資料庫加密，得先到外掛的 Settings 分頁，輸入一組只有自己知道的密語。這項加密功能屬於付費的 Premium 版本，涵蓋的範圍是資料庫傾印檔，像是使用者密碼、金鑰這些內容，但不一定涵蓋整包備份檔案，例如上傳的媒體檔案或 wp-config.php，就不見得在加密範圍之內。還原或下載時，同樣得回到設定分頁，輸入同一組密語才能解密還原。這組密語只有使用者自己知道，連外掛廠商都無法幫忙找回，這既是它的優點，別人拿不到就打不開，也是它的風險，自己弄丟這組密語，備份一樣救不回來。
沒有內建加密時，要自行為備份檔案加上密碼保護
如果外掛沒有付費加密功能，或者用的外掛本身就沒有這項設計，還有一條退路可走，就是把下載下來的備份檔案，自己用通用的壓縮工具再包一層密碼。開放原始碼、免費的壓縮軟體大多支援 AES-256 這種強加密演算法，只要選用支援這種演算法的工具替備份檔案上鎖，就算外掛本身不加密，壓縮檔的內容一樣讀不出來。
這個做法正好補上外掛加密範圍涵蓋不到的部分，像前面提過的 wp-config.php，或是站台上傳的媒體檔案，這些通常不在資料庫加密的涵蓋範圍裡，卻可以整包放進同一個加密壓縮檔裡一起上鎖。設定密碼的時候，要用一組夠長、而且跟登入密碼不同的密碼，理由很直接，如果壓縮檔的密碼跟你的 WordPress 登入密碼一樣，對方只要破解其中一組，兩邊都會失守。
加密金鑰不能和備份檔案放在同一個位置
加密只解決了檔案內容讀不讀得出來這一件事，沒有解決密語本身要放在哪裡保管這件事。實務上最常見的失誤，是把備份密語也存進同一個雲端資料夾裡的一個文字檔，理由多半只是圖方便，想著哪天要還原時容易找到。問題是，只要對方拿到雲端資料夾的存取權，連同備份檔案和寫著密語的文字檔會一起到手，加密這道鎖形同虛設。
正確的做法，是讓密語跟被加密的檔案分開存放，例如放進密碼管理工具裡，或至少換一個跟備份檔案不同的帳號和資料夾保管。這組密語本身就是一把獨立的鑰匙，如果鑰匙跟被鎖住的箱子擺在同一個地方，鎖等於沒上。密語遺失等於備份救不回來，所以最好再多留一道備援，比如同時交由團隊裡另外一個人保管一份，而不是只有一個人知道這組密語，萬一那個人請假或離職，整批加密備份可能就此打不開。
限定特定人員才能開啟資料夾，是加密之外的另一道防線
前面提到雲端硬碟的預設加密，擋不住連結外流跟帳號被盜；加密之外，還有另一道防線，就是存取權限本身怎麼設定。雲端資料夾的分享設定，通常有 2 種選項，一種是知道連結的人都能開啟，一種是限定特定帳號才能存取。前者方便分享，卻代表連結一旦外流，不管是被轉貼、被截圖，還是不小心貼到公開的地方，任何人都能直接打開內容；後者雖然每次要開新的存取權限得多花幾步，卻能確保只有指定的帳號能看到檔案。
除了限定存取帳號，替雲端儲存服務的帳號本身開啟兩步驟驗證，也是同一道防線的一部分。加密與存取控管是兩件互補的事，不是二選一。加密處理的是檔案內容被打開之後讀不讀得懂，存取控管處理的是誰有資格打開這個檔案，兩件事都做到，才真正把備份檔案的風險壓到最低，只做其中一件，另一件沒處理的漏洞還是留在那裡。
加密後的備份，要定期驗證真的能還原
前面幾節談的都是該不該加密跟怎麼加密，還有一個很容易被忽略的實務問題，加了密碼保護的備份檔案，會不會反而讓真正需要復原網站的那一天，自己也打不開。備份檔案的目的，終究是網站出狀況時能夠救回來，如果密語設定錯誤、加密的檔案本身已經損壞，或者密語根本已經遺失，那麼這份加了密的備份，實際上跟沒有備份是一樣的結果。
要避免這種情況，最直接的做法是定期做一次完整的還原測試，不只是看備份有沒有正常產生，而是真的把檔案下載下來，實際解密、實際還原一次，確認密語還有效，加密的內容也沒有損壞。比較好的測試時機，是每次調整加密設定或更換密語之後，馬上驗證一次，而不是等到真的要用的那天才第一次嘗試解密。萬一密語真的不慎遺失，提早在測試階段發現，遠比等到網站真的出事、手忙腳亂的時候才發現，處理起來從容得多。這也呼應了文章開頭提到的那件事，一份完整的備份等於整個網站的複本，而複本本身，同樣需要定期確認自己還堪用。
備份要不要加密，不是多一道麻煩不麻煩的問題，而是那份備份檔案外流之後，對方能不能直接拿去闖進你的網站，能不能拿去讀懂你會員的個資。資料庫怎麼藏著雜湊與個資、wp-config.php 怎麼藏著金鑰、雲端硬碟的預設加密防不住什麼、密語又該放在哪裡保管，拼起來其實只有一個共同的邏輯，加密解決檔案本身讀不讀得懂，存取控管解決誰能碰到這個檔案，兩件事都做到，備份才真正只是備份，不會變成另一個開著門的入口。