雲端備份及核心功能部署資安合規性問答集

1. 前言

1.A 目的

依據行政院 112 年 12 月 13 日院臺科字第 1125025142 號函核定「行政部門關鍵民生系統精進雲端備份及回復計畫」，各執行機關使用公有雲服務，應依據國家資通安全研究院(以下簡稱資安院)「政府機關雲端服務應用資安參考指引」，辦理資安強化事宜。

參酌「行政部門關鍵民生系統精進雲端備份及回復計畫」各執行機關導入雲端服務，辦理雲端備份加密分持、雲端部署應急核心系統與簡易備份功能等作業經驗，彙整相關問答集。爰依機關導入雲端加密分持備份機制的共通性問題、主流解決方案，綜整機關適用情境之資通安全合規性與組態設定相關問答，期望供機關導入雲端備份及回復作業參考。

1.B 目標讀者

本文件之主要標的讀者為規劃導入雲端備份及回復作業的機關執行單位，設身從執行單位人員角度可能遭遇的議題，透過問答集形式呈現，將要點與注意事項、其他機關導入經驗資訊彙整於解答中。可以根據章節安排循序掌握基礎概念、實務議題，或根據機關預計採用的解決方案查找切合自身情境的問答，協助機關了解如何確保系統符合資通安全政策與法規要求。其次，系統整合商亦可透過本文件，確認其所提供雲端服務之技術規範、資安控制措施，以作為自我檢核提供給機關服務之依據，確保其服務資安合規性。

1.C 技術諮詢聯絡資訊

若機關有相關技術諮詢需求，可電話聯絡 02-6631-1881 或電子郵件寄至業務聯絡信箱 (ra-res@nics.nat.gov.tw)。

2. 跨境公有雲資安合規性說明

本問答集所涉及之資通安全合規性要求，主要依循政府機關相關資通安全法規及指導文件辦理¹。鑒於資安院目前尚未訂立雲端政府組態基準（Government Configuration Baseline，簡稱 GCB）或我國專屬之雲端資安稽核規範標準，故本問答集以「政府機關雲端服務應用資安參考指引」作為主要參考依據。該指引內容涵蓋 Top Threats to Cloud Computing、ISO 27001/27002、ISO 17788、ISO 27017、ISO 27018、ISO 27036-4、ISO 19086-4 及 ISO 27701 等國際標準。

然 ISO 27001 系列標準對於雲端服務存取權限、日誌稽核等安全性定義未臻嚴謹，為求進階之安全性組態設定檢視標準，爰參考 Center for Internet Security (CIS) 的 Foundation Benchmark 及 National Institute of Standards and Technology (NIST) 的 SP 800-53 等規範，以涵蓋安全性管理、存取控制、身分驗證等面向。

3. 雲端加密分持解決方案問答集

3.A 共通性問題

3.A1 基本概念與導入目的

3.A1.Q1：什麼是「雲端備份加密分持」？它和我們以前做的異地備份到底差在哪裡？

A：雲端備份加密分持的基本概念，是先把機關最重要的資料加密鎖定，再把資料切成多份分片，分別放到三個以上不同國家的公有雲空間。這和我們以前只放在國內異地機房的備份不同，因為傳統備份仍然集中在臺灣境內，如果遇上極端的大規模天災或基礎設施全面中斷，資料可能無法取回；而透過分持的方式，任何單一雲端都拿不到完整資料，也無法看到明文，能同時避免資安風險、與雲端服務業者鎖定問題，真正做到「不幸全境都在受災範圍，我們仍能把資料救回來」。

3.A1.Q2：為什麼國內異地備援不夠？真的有必要把資料備份到國外嗎？

A：國內異地備援主要預防的是「局部」災害，例如某個縣市停電或單一機房故障；但國家等級的數位韌性需要考量的是「全境都可能失效」的狀況。當所有國內機房同時無法運作時，如果資料只有存在臺灣，便會面臨永久遺失的風險。把資料以加密後的分片方式放到國外，是為了讓核心資料在最糟情況下仍有可靠的存放點，確保能夠復原資料。這不是要把資料曝露在境外，而是透過加密與分片，讓跨境公有雲只能儲存「無法直接解讀的分片」，但在災害時我們仍能重組資料。

3.A1.Q3：資料放到國外雲端會不會有資安或洩漏的風險？雲端業者會不會看到我們的資料？

A：加密分持的設計就是為了避免這個疑慮。資料送到跨境公有雲之前已經完成加密和拆分，因此任何雲端業者只能看到部分無法解讀的加密分片，他們既無法復原資料，也不能取得全部分片。同時，金鑰掌握在我們自己手上，不會交給雲端業者；即便雲端業者想看，也沒有能力看到明文。這種方式比把完整資料放在國內機房還更能確保「沒有單一人、單一企業、單一地點」可以取得整份資料。

3.A1.Q4：如果真的發生重大災難，我們要怎麼從跨境公有雲把資料取回來？會不會很複雜？

A：災害發生時會啟動雲端上的應急核心功能，確保民眾能先得到基本服務，並由機關執行「資料重組與系統復原演練」的流程。實際上，復原流程已事先透過系統整合商設計成可操作的步驟：從雲端取回多個分片 → 重新合成 → 解密 → 部署回預備系統。承辦人不需要手動處理這些技術細節，但會需要按照既有的演練流程啟動系統，以確保整體備份政策真的能在最壞的情況下運作。

3.A1.Q5：誰負責把資料備份到雲端？承辦人需要自己操作這些工具嗎？

A：雲端備份分持的技術開發通常由系統整合商負責，但計畫特別強調「提升機關基本的自主備份與復原能力」。原因是若過度依賴廠商，一旦人員不在或廠商受災，就可能無法啟動備援。因此系統會提供簡化版的操作流程，讓承辦人可在必要時自行執行最基本的備份與復原步驟。這不是要求人人都成為技術人員，而是確保在沒有外部支援的情況下，機關仍能掌握最基本的資料生命線。

3.A2 資料上雲、加密與備份實務

3.A2.Q1：我們的資料在上傳到雲端之前，一定要先加密嗎？為什麼不能直接利用雲服務的內建加密？

A：是的，政府資料在上傳到雲端前必須先在「本地端」完成加密。雲端儲存服務雖然會提供加密功能，但金鑰由雲端業者管理，等於是把資料打開的鑰匙交給別人。政府的資料，特別是涉及個資、行政作業或政策資料，不應讓外部服務商擁有金鑰。因此必須在本地就先加密並切分，再把分片送出，使雲端業者只能存到無法解讀的加密資料。同時本地加密也確保傳輸中的資料不會遭到截取。

3.A2.Q2：誰應該保管金鑰？可以讓廠商或雲端業者代管嗎？

A：金鑰必須由政府自行保管，不能交給廠商。原因是金鑰代表解開資料的全部權限，一旦金鑰外流或不當管理，等同直接洩露資料。建議採取「多人分持」方式管理金鑰，例如由承辦人員與直屬主管共同持有，藉此降低依賴單一人員風險。此外，機關也應備妥金鑰的離線備份，確保在災害時仍能使用金鑰復原資料。

3.A2.Q3：如果金鑰遺失或忘記，備份的資料是不是永遠無法復原？

A：是的，金鑰遺失會使資料無法復原，因為加密機制是為了確保資料只有經過授權的人員能解密，因此不存在「重設金鑰」或「雲端業者幫忙解開」的機制。為預防金鑰遺失，機關應採用可靠的金鑰管理方式，例如多人分持、離線備份、保管箱保存、設計機關內部交接制度等。雖然這需要額外程序，但金鑰本身比資料還重要，因此必須受到最高等級的保護。

3.A2.Q4：資料在上傳雲端的傳輸途中會不會被攔截？要怎麼確保傳輸安全？

A：資料在上傳前已經加密，因此即使被攔截也無法解讀；但仍應要求傳輸通道本身必須使用安全協定，例如 TLS 1.2、1.3或結合後量子密碼學（Post-quantum Cryptography, PQC）新演算法在量子電腦時代仍具有防護效果的傳輸技術，以防止中間人攻擊或被導向惡意伺服器。這種雙層保護的方式，能確保資料從離開機關到抵達雲端的整段過程中都處於安全狀態。傳輸端點也會設成只能透過認證的 API 或 VPN 進行連線，降低遭到掃描或惡意連線的可能性。

3.A2.Q5：單一雲端儲存空間出問題時，備份資料還能正常使用嗎？

A：可以，這正是分持式備份的核心理念。資料會在本地被切成多個分片，每個分片分別存到不同國家的不同雲端供應商。概念上類似硬碟 RAID 5技術提升容錯性，即使壞掉一顆硬碟，也能利用剩餘資料重建，分持備份只要能取得足夠數量的分片（例如 3 分片之中取 2 分片，即可重組），就能完整復原資料。這使得備份不依賴任何特定一家雲端業者，即使有單一業者停擺、受災、遭攻擊或技術問題，資料仍能透過其他分片重建。

3.A2.Q6：能不能只使用同一國家的雲端，例如都放在美國？

A：不建議，也不符合分持的原則。資料全部存放在同一國家會讓資料曝露在相同的風險中，例如大規模停電、網路中斷等。分散到至少 3 個不同國家是為了降低國家級風險、同時符合容錯率設計（1 個分片失效仍可還原），使資料更具韌性。此外，各國法律對資料要求不同，分散放置可以避免單一國家的法律，對資料產生過度影響。

3.A2.Q7：雲端儲存位置能否指定在離我們比較近的區域，讓存取速度更快？

A：可調整，但需要在資安合規性觀點下取得平衡。備份資料本身不需要即時讀寫，因此通常會以安全與分散性優先，而不是速度。如果資料對存取延遲非常敏感，則一般會放在國內或第一備援機房，而不是境外備份。雲端備份的設計目的是確保「最壞時刻可以拿回資料」，不是提供即時存取，因此速度不是主要考量。

3.A2.Q8：雲端的物件儲存（Object Storage）和一般硬碟儲存有什麼差別？為什麼多半使用物件儲存？

A：物件儲存是一種設計給大量備份資料使用的雲端儲存方式，它不要求像傳統硬碟那樣的即時讀寫，而是強調高可用、高擴充與跨區複製。對備份來說，我們不會頻繁更動內容，而是存入後在必要時取出；這類需求非常適合物件儲存。不但成本較低，雲端對物件儲存也提供較高的耐久性，確保資料即使放很多年仍然能完整取回。

3.A2.Q9：上傳到雲端的備份資料可以修改或刪除嗎？會不會因為操作失誤造成資料消失？

A：備份儲存空間基本上應啟用「不可修改」的保護機制，而刪除則應依據機關訂定的備份生命週期進行管理。其目的就是避免資料因誤操作或惡意行為遭到刪除。此外，備份會保留多個版本，即使最新版本異常，也能回到先前可用的版本。這些都能大幅降低人為或攻擊造成的資料毀損風險。

3.A2.Q10：雲端備份會不會因為沒有長期使用而被自動刪除？

A：不會。只要機關持續維持租用與儲存設定，雲端服務不會自行刪除資料。雲端會依照儲存費用的結算方式持續保留資料，即使長期沒有存取也不會清除。相反地，某些儲存階層甚至是專門為長期保存設計，例如「封存層級」或「離線備份儲存」。

3.A2.Q11：可以把備份資料壓縮後再送到雲端嗎？

A：一般不建議在上傳前進行額外壓縮，除非系統整合商設計過程中已評估過。原因有兩個：第一，加密後的資料通常已不具備可壓縮性，壓縮效果有限；第二，壓縮會增加處理時間，也可能在壓縮或解壓縮過程中增加失敗風險。雲端環境可以使用分層儲存政策降低費用，比依靠壓縮更安全且更有彈性。

3.A2.Q12：雲端備份過程有沒有可以記錄每次上傳與下載的紀錄？我們需要這些做稽核。

A：有，雲端平臺會提供詳細的日誌，包括從哪個帳號、何時、從哪個 IP 存取了哪些資料。這些紀錄能輸出到政府自有的日誌系統或資訊安全作業維運中心 (SOC)，進行統一稽核。日誌不只是為了查問題，也能讓機關在異常行為發生時立即收到警示，例如在非上班時段有大筆資料被存取，就能讓資安人員即時處理。

3.A2.Q13：雲端系統如果出現異常，如上傳失敗，我們能否收到通知？

A：可以。承辦人可以設定通知機制，例如電子郵件，當備份任務失敗、傳輸中斷或雲端儲存空間接近用量上限時，系統會立即告知。這類通知能讓承辦人及早發現問題，而不是等到需要復原時才發現備份不完整。

3.A2.Q14：能不能用一般免費的雲端空間（如個人雲端硬碟）來放備份？

A：完全不行。個人雲端服務無法提供政府所需的安全標準，例如跨國資料處理保障、可稽核性、權限細分、傳輸與儲存規範，以及不可修改的儲存需求。政府資料需要高度保護，而個人雲端並未針對資安法規、政府採購與稽核條件設計，使用這類服務不但違反規範，也會使資料曝露於不必要的風險中。

3.A3 帳號、權限與跨國存取管理

3.A3.Q1：雲端帳號真的需要分工管理嗎？能不能只用一個管理者帳號就好？

A：雲端帳號必須分工管理，不能只用單一管理者帳號。雲端管理者帳號基本上擁有「刪除備份、調整權限、讀取設定」等最高權限，一旦遭到盜用，攻擊者就能直接破壞備援環境。分工管理能降低單一帳號成為單一失敗點的風險，例如可將備份操作、監控稽核、網路設定分配給不同人負責，讓任何操作都能被追蹤，也能避免個別人員離職或疏忽造成重大影響。

3.A3.Q2：雲端帳號密碼一定要啟用多重要素驗證（MFA）嗎？會不會很麻煩？

A：多重要素驗證是雲端管理最基本也是最必要的安全措施。雲端帳號會被攻擊者大量掃描，只靠密碼無法防止攻擊；MFA 能確保即使密碼外洩，也需要實體設備或認證 App 才能登入。雖然會比單純輸入密碼多一步驟，但對保護資料來說極為重要，也是政府與國際雲端資安標準的強制要求。

3.A3.Q3：是否可以讓外包廠商直接使用機關的雲端帳號嗎？

A：不行。外包廠商必須使用廠商的帳號，並以最低權限的方式授予必要存取。讓廠商使用機關帳號不但無法稽核，也會讓責任難以釐清。若廠商帳號遭到濫用，日誌才能清楚分辨是廠商帳號執行，而不是政府人員，這也是資安法要求的基本原則。

3.A3.Q4：人員離職或調職時，機關要怎麼確保雲端權限不會被遺留？

A：雲端帳號應納入機關的人事管理流程，並定期進行帳號盤點，例如與人事或資訊單位合作，將離職人員清冊定期與雲端帳號清單比對。每位人員的帳號都應是獨立的，才能在離職時立即停用，而不用擔心影響其他同仁。將能確保雲端環境不會留下已經不屬於機關的有效帳號，降低遭到惡意使用風險。

3.A3.Q5：雲端權限管理真的要做到「最低權限」嗎？這樣不會增加很多行政負擔嗎？

A：最低權限原則並不是為了增加行政負擔，而是為了避免資料曝露在不必要的範圍。例如，只負責稽核的人不應該能刪除資料，而負責備份的人也不需要能修改網路設定。透過分工設定，日後如果發生異常，也能迅速判斷可能的來源。實務上，最低權限通常透過角色或身分屬性設定即可，不需要逐項調整。

3.A3.Q6：可以在雲端帳號上設定 IP 限制嗎？例如只能從機關或 VPN 登入？又或阻擋國外 IP 來源？

A：可以，而且非常建議。IP 限制能讓雲端管理介面只能從機關網路或虛擬私人網路 (VPN) 存取，即使帳號密碼被偷走，也無法從外部登入。大多數針對雲端的攻擊來源來自境外，因此透過 IP 或地區封鎖，能有效阻擋大量的惡意流量。若機關有需要從國外操作，也可以先透過 VPN 或特定專線連回臺灣，再由機關網路登入雲端，而不是直接開放國外登入雲端管理介面。這種防護方式能顯著降低攻擊者成功登入的機率。

3.A3.Q7：使用雲端是否一定要啟用角色型（RBAC）或屬性型（ABAC）存取控制？

A：是的，因為雲端環境通常角色清楚，例如備份管理、稽核、網路設定、金鑰管理等。角色型存取控制（RBAC）能讓機關將權限依照工作內容分組，避免每個帳號各自設定不同的複雜權限。屬性型控制（ABAC）則能針對更細緻需求設定，例如特定專案底下授權。兩者都能降低權限設定錯誤的風險。

3.A3.Q8：雲端中的跨國存取需要特別申請嗎？是否會違反現行法規？

A：依照資安法與政府資料管理原則，資料若經過加密後進行跨國儲存，是可以在適當控管下進行的。不過機關仍需依照規範進行資料等級檢視，確認哪些資料可跨境、哪些不可，並與主管做必要的資訊同步。加密分持備份是將經加密、切分的資料保存在國外，因此原則上不會違反資料跨境規範，但仍需完成內部程序。

3.A3.Q9：雲端管理界面的存取需要留存操作紀錄嗎？

A：需要，而且必須保存。雲端上的所有重要操作，例如變更權限、設定網路、刪除儲存空間，都需要完整的稽核日誌。若日後發生問題，日誌是釐清責任、確認是否遭攻擊或判斷操作錯誤的唯一依據。政府要求雲端日誌必須保存至少一定期間，一般建議保留半年以上為佳，並能提供查核。

3.A3.Q10：我們能把雲端的稽核日誌下載回機關存放嗎？

A：可以，而且建議這樣做。雲端稽核日誌如果只存在雲端本身，一旦雲端發生問題或帳號被攻擊者入侵，日誌可能會遭到刪除。因此最好定期將重要日誌或即時警示輸出到機關自己的 SIEM （安全資訊與事件管理）或日誌管理系統，確保日誌能在多處保存。

3.A3.Q11：管理員帳號是不是永遠都要存在？能不能限制管理員帳號的使用？

A：管理員帳號通常無法刪除，但可以限制其使用。例如可以要求管理員帳號只能做緊急用途，不作日常操作；並利用「命名身分」或「委派管理」讓一般的管理行為由低權限帳號完成。這樣能避免管理員帳號在日常操作中遭到盜用。

3.A3.Q12：雲端登入可以限制使用期限或強制定期變更密碼嗎？

A：可以，而且建議定期複查。雲端通常能設定密碼長度、有效期限、登入失敗次數限制等政策。這些設定與政府資訊系統的密碼原則一致，能確保長期使用的帳號不會因為多年未變更而遭到暴力破解。雲端也能結合機關身分系統，使密碼政策與內部一致。

3.A3.Q13：如果攻擊者成功登入雲端帳號，我們如何知道？

A：雲端平臺提供異常登入偵測功能，可以偵測例如首次從國外登入、凌晨登入、多次失敗後成功登入等異常行為。這些事件能即時通知管理者，也能設定自動化處理，例如自動鎖定帳號或迫使重新驗證。將能大大降低攻擊者盜用帳號後長期停留的風險。

3.A3.Q14：雲端存取權限管理是否能細緻到細到個別檔案層級？

A：可以。雲端物件儲存能針對特定資料夾、特定物件、甚至特定時間範圍授予權限。例如可以讓備份操作人員能上傳但不能下載，或讓稽核人員只能讀取特定資料。這種細緻的權限設計比傳統檔案伺服器更具彈性，也能降低資料過度曝露的問題。

3.A4 雲端安全、稽核與弱點管理

3.A4.Q1：雲端資安與傳統機房資安有什麼不一樣？我們該從哪裡開始理解？

A：雲端資安的基礎理念與傳統機房一致，都是為了保護資料可用性、完整性與機密性；不同的是，雲端採用「共同責任模型」。雲端業者負責雲端基礎設施的安全，而機關則負責帳號、資料、應用程式與設定的安全。因此承辦人在雲端環境中需要更重視權限控制、日誌稽核與設定安全，而不是硬體維運。理解共同責任的分界，是機關順利運作雲端資安的第一步。

3.A4.Q2：「政府機關雲端服務應用資安參考指引」在雲端安全上扮演什麼角色？

A：這份指引整合了國際常用的雲端安全標準（如 ISO 27017、NIST SP 800-53、CIS Benchmark），並轉換成適合政府使用的具體措施。它提供清楚的檢查項目，包括帳號管理、加密、儲存、網路安全、稽核與監控等。對承辦人來說，這份指引就像一份「雲端安全健檢表」，能幫助機關確保設定完整，並在稽核時有所依循。

3.A4.Q3：雲端底層安全（如機房、硬體）是不是完全不需要我們管？

A：雲端底層安全由雲端業者負責包含電力、機房、冷卻、硬體修補等，但我們仍需要確認雲端業者是否具備合格的國際認證，例如 ISO 27001、SOC 2、FedRAMP 或其他政府需求的安全證書。雖然這些細節不是承辦人要直接管理，但確認雲端供應商符合標準，是機關導入雲端前的必要程序。

3.A4.Q4：雲端安全設定需要定期檢查嗎？頻率應該多久一次？

A：需要，而且建議定期檢查一次重要設定，如權限、儲存、網路與稽核日誌紀錄。依部分機關經驗，可納入既有的帳號盤查、弱點掃描或滲透測試等安全管理作業，至少上、下半年各 1 次。並可依據雲端部署程式更版、災害復原演練等不定期盤查。雲端的設定不像硬體環境一樣固定不變，帳號新增、專案調整或系統更新都可能帶來設定變化。若未定期檢查，可能會讓不必要的權限或開放端點持續存在，形成安全漏洞。定期檢查並因應平臺更新做對應調整，確保整體環境隨時保持安全狀態。

3.A4.Q5：雲端是否需要安裝防毒或惡意程式偵測工具？

A：視情況而定。若是在雲端部署應用程式（如：加密分持專用運算環境、簡易備份網頁、或應急核心功能系統等），通常會使用到雲原生的虛擬機或容器服務，那麼仍需要像傳統系統一樣部署惡意程式偵測工具。若只是儲存服務（如：S3、Blob Storage、GCS），通常不需要安裝防毒工具，但仍需確保存取端點受到保護（如：從組態設定限制端點公開存取），避免被植入異常檔案。此外，雲端平臺本身通常提供威脅偵測功能，能監控異常登入、可疑操作、暴力攻擊等，也應一併啟用。

3.A4.Q6：雲端防火牆要怎麼設定？是不是只要預設開啟就好？

A：雲端防火牆並非預設就絕對安全，需要依照機關需求設定最小開放範圍。通常做法是先全面阻擋外部流量，再逐一開放必要的連線來源，例如只讓機關 IP 或 VPN 網段能存取管理介面。若雲端上有應用程式服務，也應將入站與出站規則分開管理，避免不必要的流量。防火牆設定是雲端安全中最容易出錯的部分，因此建議定期檢查。

3.A4.Q7：雲端網路是否要與機關內網隔離？不能直接互通嗎？

A：應該隔離。雲端與機關內網透過 VPN 或專線連線是常見做法，但網路本身仍需要被邏輯隔離。原因是內網若遭到攻擊，攻擊者不應能直接橫向進入雲端；反之亦然。隔離能防止單點入侵擴大，也能清楚劃分責任區域，有助於稽核與事件調查。

3.A4.Q8：如果雲端服務被異常存取或遭攻擊，我們如何即時知道？

A：雲端平臺提供事件監控與告警系統，可以針對異常登入、權限變更、流量暴增、儲存被大量刪除等情況發送警告。承辦人可以設定告警透過電子郵件或簡訊發送。這些警告不只協助防止資安事件擴大，也能讓機關即時啟動調查與應變程序。

3.A4.Q9：雲端環境是否需要與資安事件通報流程結合？

A：需要。雲端系統若出現可疑行為、攻擊事件或資料異常，都必須依照資安法或機關資安通報流程通報。通報義務不因雲端或地端環境而不同，反而更需清楚記錄日誌與事件時間。將雲端事件監控與既有的資安事件程序建立連結，能確保機關在雲端出現問題時能立即採取正確行動。

3.A4.Q10：雲端稽核日誌是否需要長期保存？保存多久合適？

A：需要長期保存，最少應依照機關類型、資料敏感度或相關法規的保留期限（通常至少 6 個月以上）。日誌不只是稽核用，對資安事件調查而言非常重要。若沒有足夠保存期間，事件發生後可能無法回溯當初的操作與攻擊來源。

3.A4.Q11：雲端部署應用程式需要做弱點掃描嗎？

A：需要，而且是資安合規性要求。雲端系統與其他資訊系統相同，都需要定期進行弱點掃描與修補。雲端平臺也可能因設定錯誤導致漏洞，例如未加密的儲存空間、或過度開放的網路端點。弱點掃描能讓機關在問題被攻擊者利用之前先行修正。

3.A4.Q12：弱點掃描會不會影響雲端系統運作？

A：一般不會。弱點掃描的運作方式是模擬外部攻擊者檢查設定，與實際攻擊不同，不會破壞資料或系統。然而，在敏感或負載較高的環境中仍應安排在非尖峰時段，並由資安人員與雲端管理人員共同監看，確保穩定性。

3.A4.Q13：需要在雲端開發的應用程式上做資安檢測嗎？

A：需要。雲端只是運作環境，應用程式本身仍然可能存在 SQL Injection、XSS、弱密碼等問題。若雲端上運行的是與外部互動的服務，即使底層雲端安全，也無法防止應用程式漏洞。定期進行滲透測試與程式碼檢視能避免因應用端弱點造成資料外洩。

3.A4.Q14：雲端是否需要定期進行備用演練或復原測試？

A：需要，而且是確保備份真正可用的關鍵動作。備援演練能測試資料是否能成功解密與重組，並驗證備份流程與權限設定是否正確。沒有實際演練，無法確定備份在災害發生時能順利運作。演練頻率通常至少每年一次，並在系統重大變更後安排追加測試。

3.A4.Q15：雲端安全是否需要文件化？文件應包含哪些內容？

A：需要。文件化能讓機關在稽核、交接或事件調查時有依據，也能確保新進人員能快速了解雲端環境。雲端安全文件應包含系統架構、帳號權限、網路配置、加密與金鑰管理方式、備份流程、事件處理程序等。完善的文件能減少人員變動或系統變更對安全造成的風險。

3.A5 災害復原、演練與治理

3.A5.Q1：如果臺灣真的發生大規模災害，我們第一步要做什麼？

A：第一步是啟動機關的災害應變流程，確認哪些資訊系統受到影響，並依照復原優先順序啟動雲端備援環境。此時不需要立刻把所有資料復原，而是先讓最重要的核心服務恢復最低限度的運作，以確保民眾與機關能繼續運作，後續再依序進行完整資料重組與系統復原。

3.A5.Q2：災害時，誰該負責啟動雲端的資料復原流程呢？

A：通常由資訊單位負責啟動復原流程，但計畫強調「機關自主能力」，因此簡易備份與復原功能應高度簡化人為操作，承辦人或備援負責人必須熟悉如何操作簡易備份與復原功能。承平時期廠商通常會協助機關，但在重大災害下可能無法立即到場，或有足夠的技術支援人力，因此機關自身具備基本啟動能力非常重要。

3.A5.Q3：跨境公有雲上的備份分片怎麼回到臺灣？需要人工下載嗎？

A：不需要人工逐一下載。當備份復原工具已經預先建置自動化流程：連線 → 取得分片 → 驗證完整性 → 合成 → 解密。承辦人的工作是依照演練流程啟動這套自動化機制。將能避免在緊急時因人為錯誤而導致復原失敗。

3.A5.Q4：資料分成多個分片後，要全部都取回嗎？如果部分雲端斷線怎麼辦？

A：分持技術通常採用「M-of-N」的方式，意思是將資料切分為 N 個分片，僅需要其中任意 M 個分片即可完整恢復資料，例如資料被切成 3 個分片 (N=3)，但只需要其中任意 2 個分片 (M=2) 就能完整復原。因此即便某些雲端服務在災害期間不可用，或其中 1 個分片備份失效，仍能從其他可存取的分片中完成資料重組，這是加密分持備份的核心優勢之一。不過在災害時期可能出現網路頻寬受限、對外網路中斷、或僅少數單位具備衛星網路等極端情況，因此在承平時期應確實進行定期備份，並保有在災前或緊急狀態即時啟動備份程序的機制。

3.A5.Q5：資料重組後的明文會不會留在雲端？

A：資料重組、解密與復原的環境都應該在機關指定的安全地點執行，並採取臨時性環境或受控網段。雲端只存放不可讀的加密分片，明文資料只會存在於機關的復原環境中，且會在復原完成後依照程序清理。

3.A5.Q6：如果災害導致我們沒有可立即使用的本地機房，資料能否直接在雲端上重建？

A：可以，但需視資料等級而定。對某些業務而言，雲端可作為臨時運作環境，例如啟動應急核心功能服務以維持基本運作。對較敏感或受限於法規不可直接在雲端運行的系統，則需在安全地點（如：租用臨時機房）恢復。建議機關應盤點系統中哪些功能為核心功能模組（如：是否對民、業務重要性、關鍵業務邏輯等），針對核心功能模組運作所需資料，可在雲端先行啟動，哪些必須在本地端重建，以提高韌性。

3.A5.Q7：資料復原後，我們要如何確認資料沒有損毀或遺漏？

A：備援系統會在取回分片後進行完整性驗證，包括檢查雜湊值、比對版本、確認分片是否變更。復原後也需比對資料庫與檔案系統的完整性，並依照業務部門提供的驗證項目進行確認。若缺少資料或資料不一致，系統應提示錯誤，協助承辦人判斷是否需要重新復原。

3.A5.Q8：災害後重建的流程會不會很複雜？我們能不能事先練習？

A：實際流程經過最佳化後，由一系列可調用的自動化步驟組成，承辦人主要負責啟動、監看與確認。更重要的是，復原流程一定要事先演練。演練能幫助機關熟悉流程、驗證備份的可用性、找出設定錯誤及權限問題。沒有演練的備援往往在真正災害時無法成功運作。

3.A5.Q9：演練的內容通常包括哪些？

A：演練至少包括四個部分：

備份完整性檢查（確定分片可取回且未損毀）
資料重組與解密測試（確保流程正常運作）
服務啟動測試（復原後系統能正常運作）
問題記錄與改善（建立演練報告）。

3.A5.Q10：演練是否會影響正式系統的運作？

A：不會。演練通常在隔離環境或使用演練用資料進行，不會干擾正式業務。若必須使用正式資料，也會採取複製與隔離方式處理，確保不會對正常服務造成影響。因此承辦人不必擔心演練會造成業務中斷。

3.A5.Q11：災害後的備份怎麼更新？會不會因為災害而失去最近一次的資料？

A：備份保存啟用版本管控機制，也就是備份應有版本資訊與保存政策，而不是單純覆蓋舊的備份。災害發生後系統會選取時間點最近、未損毀的版本進行復原。若最後一次備份未完成，也可以選擇備份時間距離當下最近之版本，並紀錄影響時間範圍。版本化能確保災害不會造成整份備份失效，也有助特殊事件調查。

3.A5.Q12：復原後，我們需要做什麼後續檢查？

A：復原後需進行三項檢查，確保復原的環境與原始環境一致，避免因災害或復原過程導致設定異常：

資料一致性檢查（確認資料內容完整無誤）
系統功能驗證（確保服務可正常運作）
安全檢查（包含帳號、網路、日誌等設定）

3.A5.Q13：機關的內部稽核或資安稽核是否會檢查雲端備援？

A：會。稽核通常會檢查備援程序是否完整、演練是否定期執行、日誌是否留存、權限是否正確、雲端設定是否符合政府指引等。因此承辦人需要保持文件完整，包括架構圖、SOP、演練報告與設定紀錄，確保稽核時能清楚說明流程。

3.A5.Q14：資料復原後，我們是否需要重新建立新的備援環境？

A：需要。災害復原後，原本的備援環境可能已被使用或受到影響，因此需重新建立新的備份並重新分持儲存在雲端。這通常是復原流程最後的步驟之一，確保機關在新的運作環境下仍具備韌性。

3.A5.Q15：我們要怎麼持續改進雲端備援與復原流程？

A：改進流程通常從以下幾點著手：

演練經驗回饋：每次演練後記錄問題與改善方式。
設定定期複查：權限、網路、日誌等每季檢查一次。
人員教育訓練：讓承辦人熟悉基礎雲端概念與復原流程。
技術更新：依照政府指引與雲端平臺的新功能調整政策。

3.B 採用 hicloud 解決方案

3.B.Q1：解決方案供應商是否會提供雲端備份加密分持的 shell script 與操作手冊，供機關在應急時自主操作？

A：解決方案供應商應提供必要的 shell script 與基礎錯誤排除手冊，確保機關人員能在緊急情況下自主執行雲端加密分持備份操作。如無法進行基礎錯誤排除，應確保加密分持工具部署主機與加密金鑰有（異地）備份機制，可於應急時期重建可執行資料備份復原的環境。

3.B.Q2：解決方案供應商應提供哪些資安報告，以證明備份加密分持工具（Client/Server）的安全性？

A：解決方案供應商應提供最新弱點掃描報告和滲透測試報告，以證明備份加密分持工具（Client）與加密分持平臺（Server）的資安強度，機關應要求定期追蹤這些報告的更新。

3.B.Q3：如何確保備份資料上傳過程若發生中斷，仍能安全且可靠續傳？

A：應確保備份上傳中斷時，系統具備自動重試（例如重試 5 次）機制。若重試失敗，需切換為人工續傳，並提供足以辨識且必要的 Log 紀錄，以便通知相關關係人進行處理。系統整合商若為第三方，應確保資料庫備份蒐集至加密分持主機前的流程，遭遇中斷或非預期情境時，具備重試或有助於排查錯誤的 Log 紀錄。

3.B.Q4：若雲端備份、簡易備份及核心系統由不同廠商建置，是否都需填寫雲端組態設定檢查表？

A：是。只要這些功能（雲端備份加密分持、輕量化核心系統、簡易備份功能開發等）使用到不同的雲端環境，機關就應利用組態設定檢查表，確認其雲端基礎架構安全性，以確保一致的資安標準。

3.B.Q5：如何確保大檔案在切割與復原過程中的資料完整性？

A：驗證流程為確保雲端備份與分持機制在傳輸與復原階段的正確性與資料完整性，建議應向解決方案供應商索取說明文件，例如：大檔切割為多個資料碎片上傳。完整性驗證需透過逐個分片 checksum 計算比對，復原時則以組合後的資料檔計算一次 checksum。

3.C 採用開源解決方案

3.C.Q1：採用開源解決方案時，機關應如何確保長期的技術支援與維護？

A：應在契約中要求系統整合商（SI）負責長期維運與技術支援。雖然開源軟體不受特定廠商綁定，但機關仍需透過採購契約明確規範系統整合商的義務，包括：

長期技術支援與諮詢
問題排除與錯誤修復
軟體版本更新
資安事件通報與應變支援。

3.C.Q2：系統整合商如何證明所採用的開源方案（如 Tahoe-LAFS, Veeam）具備良好資安強度且程式碼無後門？

A：需提供弱點掃描、修補紀錄與第三方安全檢測報告。系統整合商需針對所使用的開源分持備份應用程式定期執行資安檢測，包括：

弱點掃描並修補已知弱點
源碼掃描（Source Code Review/Static Code Analysis）
第三方獨立資安單位出具的滲透測試報告
針對開源社群已知議題的追蹤與改善紀錄

3.C.Q3：若開源軟體出現新的資安漏洞，系統整合商應於多久內提供修補方案？

A：應在契約中明訂修補流程及時程，例如重大漏洞 30 天內提供修補或緩解措施。建議在契約中要求系統整合商提供明確的漏洞處理流程，包括：

漏洞評估時程（如 7 天內完成風險評估）
重大漏洞處理時程（如 30 天內提供修補或緩解措施）
日誌、版本更新與程式修補紀錄
通報時間與責任分工

3.C.Q4：系統整合商是否應具備將雲端備份復原至機關指定環境的整合能力？

A：是，且為核心要求之一。確保機關即使失去雲端環境，仍能掌握資料並完成復原。系統整合商必須支援：

將雲端環境備份資料復原至機關規劃之地端環境
提供完整復原流程文件、必要工具與操作說明
提供實作證明（PoC 或測試紀錄）以證明復原功能確實可行

3.C.Q5：如何確保開源解決方案在任一雲端儲存服務中斷時，仍能成功重建與恢復檔案？

A：系統整合商需提供備份分持機制的容錯率證明，並確保任一雲端故障仍能復原。系統整合商應提供：

分持備份機制之 M-of-N 容錯率設計（如：3 分片取 2 分片即可復原）
任一雲端區域或供應商中斷時的成功復原測試報告
分片完整性驗證機制（checksum、雜湊比對等）
恢復流程之 SOP 與測試紀錄

4. 雲端組態設定問答集