SSDLC (Secure Software Development Life Cycle)

安全系統發展生命週期

---

[TOC]

---

1. 存取控制

1.1 帳號管理

• 建立帳號管理機制，包含帳號之申請、建立、修改、啟用、停用及刪除之程序。

  【資安需求項目查檢】資通系統之帳號應透過正式的帳號申請程序所建立，完成開通審核程序始能使用，因此系統應具備帳號管理機制，可對系統帳號進行申請、建立、修改、啟用、停用或刪除之行為。

• 已逾期之臨時或緊急帳號應刪除或禁用。

  【資安需求項目查檢】若具有臨時帳號或緊急帳號時，應實作已逾期之系統帳號檢查機制，於帳號逾期時自動停用或刪除，以避免帳號遭有心人士盗用。

• 資訊系統閒置帳號應禁用。

  【資安需求項目查檢】宜記錄系統帳號最後登入時間，可透過工作排程，檢查是否有持續一段時間(如半年等)未登入系統之帳號，並實作自動停用該帳號之功能。

• 定期審核資訊系統帳號之申請。

  【日常維運管理需求】定期審核資通系統帳號使用現況，檢視是否存在帳號被異常建立、竄改或啟用等行為，並禁用或刪除閒置帳號與臨時帳號。

• 公司應定義各系統之閒置時間或可使用期限與資訊系統之使用情況及條件。

  【日常維運管理需求】機關宜定義系統閒置時間(如20分鐘等)或可使用期限(如達使用時數後自動登出等)與資通系統之使用情況及條件(如僅開放上班時間存取等)

• 逾越公司所許可之閒置時間或可使用期限時，系統應自動將使用者登出。

  【資安需求項目查檢】會談(Session)機制目的為管理使用者與伺服器之間的連線狀態，使用者於系統中若一段時間未進行活動，系統應有自動機制將該使用者的會談階段設為失效而登出系統，以降低資安風險。

• 應依公司規定之情況及條件，使用資訊系統。

  【資安需求項目查檢】應依據機關規定之情況及條件(如特定時間或指定IP來源等)，限制系統使用行為(如僅開放平時上班時間使用系統、特定功能或機敏資訊僅允許透過內部網路存取等)。

• 監控資訊系統帳號，如發現帳號違常使用時回報管理者。

  【資安需求項目查檢】應具備監控及通知機制，向系統管理者回報帳號異常使用行為(如短期內大量帳號登入失敗或存取未經授權之資源等)。

1.2 最小權限

• 採最小權限原則，僅允許使用者(或代表使用者行為之程序)依機關任務及業務功能，完成指派任務所需之授權存取。

  【日常維運管理需求】使用者(或代表使用者行為之程序)應以完成該工作所需的最小權限操作系統功能，避免過度授權而增加系統資源被不當存取的風險。因此在進行授權決定時，應考量該使用者(或代表使用者行為之程序)之業務性質與範圍，限制其所能存取的系統功能及資料。

1.3 遠端存取

• 對於每一種允許之遠端存取類型(如遠端桌面連線、ssh、網路芳鄰或FTP)，均應先取得授權，建立使用限制、組態需求、連線需求及文件化，使用者之權限檢查作業應於伺服器端完成。

  【資安需求項目查檢】機關應明確訂定資通系統之存取限制、組態需求、連線需求，並將這些資訊文件化，以供日後查檢。
  
  開放機關內部同仁及委外廠商進行遠端維護資通系統，應採「原則禁止、例外允許」方式辦理，若機關因地理限制、處理時效及專案特性等因素，須開放前揭人員自遠端存取資通系統時，至少辦理下列防護措施：
  (一)依資通安全管理法施行細則第4條及資通安全責任等級分級辦法附表十中有關遠端存取相關規定辦理，並建立及落實管理機制。
  (二)開放遠端存取期間原則以短天期為限，並建立異常行為管理機制。
  (三)於結束遠端存取期間後，應確實關閉網路連線，並更換遠端存取通道(如VPN)登入密碼。

• 使用者之權限檢查作業應於伺服器端完成。

  【資安需求項目查檢】應於伺服器端實作權限檢查機制，並預設禁止任何未通過權限檢查之存取行為，以避免被使用者繞過。

• 應監控資通系統遠端連線。

  【日常維運管理需求】資通系統所允許之遠端連線活動，應使用監控設備或其他可偵測未經授權使用的設備，在發現異常連線或存取行為時提出警告，以防止資通系統被不當使用。

• 資通系統應採用加密機制。

  【資安需求項目查檢】遠端存取資通系統時，應以加密機制保護機敏資料傳輸時之機密性。常見作法如採用HTTPS加密傳輸等，並選擇高強度之協定版本及演算法。

• 資通系統遠端存取之來源應為機關已預先定義及管理之存取控制點。

  【日常維運管理需求】遠端存取行為應經過適當授權後始可放行，若有必要允許外部遠端存取之系統功能，應限制資通系統遠端存取之來源(如機器、網路位址等)，預先定義合法來源並進行管理，避免全面性開放存取。

---

2. 事件日誌與可歸責性

2.1 記錄事件

• 訂定日誌之記錄時間週期及紀錄留存政策，並保留日誌至少六個月。

  【資安需求項目查檢】應依機關規定之時間週期及紀錄留存政策，保留系統事件日誌(Audit Logs)，目的包含程式除錯、行為歸責、稽核取證及法規要求等。
  
  保存範圍如下：
  A級機關：應保存全部資通系統與各項資通及防護設備最近6個月之日誌紀錄。
  B級機關：應保存全部核心資通系統與相連之資通及防護設備最近6個月之日誌紀錄。
  C級機關：應保存全部核心資通系統最近6個月之日誌紀錄。
  
  保存項目如下：
  作業系統日誌 (OS event log)
  網站日誌 (web log)
  應用程式日誌 (AP log)
  登入日誌 (logon log)

• 確保資通系統有記錄特定事件之功能，並決定應記錄之特定資通系統事件。

  【資安需求項目查檢】資通系統應實作記錄特定事件之功能，如身分驗證失敗、存取資源失敗、重要行為、重要資料異動、功能錯誤及管理者行為等。

• 應記錄資通系統管理者帳號所執行之各項功能。

  【資安需求項目查檢】系統管理者為資通系統內具有最高權限之帳號，對系統及資料極具影響力，記錄所有管理者帳號執行之各項功能，有助於定期記錄系統行為及資安事件追查。

• 應定期審查機關所保留資通系統產生之日誌。

  【日常維運管理需求】機關應訂定日誌審查時程，由負責人員檢視日誌紀錄內容，以掌握是否在期間內曾發生重要的資安事件，如異常的存取行為、重大的系統錯誤等。

2.2 日誌記錄內容

• 資通系統產生之日誌應包含事件類型、發生時間、發生位置及任何與事件相關之使用者身分識別等資訊，並採用單一日誌紀錄機制，確保輸出格式之一致性，並應依資通安全政策及法規要求納入其他相關資訊。

  【資安需求項目查檢】日誌應詳細描述所觸發的事件，包含人、 事、時、地、物等關鍵資訊，宜包含：使用者帳號 (避免個資類型)、時間、執行之功能或存取之資源名稱、事件類型或優先等級、執行結果或事件描述、事件發生當下相關物件資訊、網路來源與目的位址，以及錯誤代碼等。盡可能採用單一的Log機制，如不得同時混用兩種以上日誌產生套件(如Log4Net與Nlog等)，並應確保日誌內容格式之可讀性，以便於事件比對與追查。日誌應依據資通安全政策及其他法規要求，納入任何有必要留存之資訊，如憑證資訊、日誌層級、會談識別碼等。

2.3 日誌儲存容量

• 依據日誌紀錄(Audit Logs)儲存需求，配置所需之儲存容量。

  【資安需求項目查檢】資通系統應配置日誌紀錄所需之儲存容量(如磁碟或資料庫空間等)，避免因儲存容量不足造成日誌處理失效。

2.4 日誌處理失效回應

• 資通系統於日誌處理失效時，應採取適當之行動。

  【資安需求項目查檢】日誌處理失效時，應訂定相對應的處理措施(如覆寫最舊的稽核紀錄、停止產生稽核紀錄或對特定人員提出警告等)，避免危害系統可用性，或是當資安事件發生時無稽核紀錄可比對追查之情況。

• 機關規定需要即時通報之日誌處理失效事件發生時，資通系統應於機關規定之時效內，對特定人員提出警告。

  【資安需求項目查檢】應定義需要即時通報的特定日誌處理失效事件、即時通報的時效以及特定通知對象，並實作通知機制，以利及早釐清事件發生原因並進行故障排除。如當日誌紀錄無法正常寫入資料庫時，以信件或簡訊通知系統維護人員。

2.5 時戳及校時

• 資通系統應使用系統內部時鐘產生日誌紀錄(Audit Logs)所需時戳，並可以對應到世界協調時間(UTC)或格林威治標準時間(GMT)。

  【資安需求項目查檢】使用系統內部時鐘產生日誌所需時戳，採用全系統一致的時間標準，有助於彙整資安事件所發生的各種事件時間點，進而分析資安事件可能發生的原因。

• 系統內部時鐘應定期與基準時間源進行同步。

  【資安需求項目查檢】日誌紀錄必須維持使用精確的時間，以利事件追蹤及稽核取證等用途，實務上，可使用網路時間協定(Network Time Protocol, NTP)，讓機關內各個系統及網路設備與校時伺服器進行同步，如國家標準時間伺服器(time.stdtime.gov.tw)或使用機關自建之伺服器

2.6 日誌資訊之保護

• 對日誌(Audit Logs)之存取管理，僅限於有權限之使用者。

  【資安需求項目查檢】應施行日誌存取控管，避免未經授權使用者惡意讀取、竄改或刪除稽核紀錄。

• 應運用雜湊或其他適當方式之完整性確保機制。

  【資安需求項目查檢】日誌紀錄以安全雜湊演算法產生，並留存其雜湊值，後續可對資料再次產生雜湊值並與原先結果進行比對，以確保資料未遭到異動竄改。其他保護方式如加密、唯讀保存及即時監視檔案異動行為等。

• 定期備份日誌至原系統之外其他實體系統。

  【資安需求項目查檢】定期進行日誌異機備份，如建置Log伺服器或設定系統排程等方式，集中管理及保存日誌紀錄之備份，可降低因系統損毀或人為惡意刪除之風險。

---

3. 營運持續計畫

3.1 系統備份

• 訂定系統可容忍資料損失之時間要求。

  【日常維運管理需求】機關應訂定可容忍資料損失之時間要求，若資安事件發生造成資料損失時，需使用最接近的備份資料進行復原，資料損失與備份資料之間的時間間隔，亦稱為復原點目標(Recovery Point Objective, RPO)。 RPO一旦訂定完成，則可協助系統維護人員選擇適合的備份機制及頻率。如若訂定為 1 小時，則至少每小時必須進行一次資料備份，所選擇的儲存媒體可能為磁碟；但若RPO訂定為一週(168 小時)，則至少每週進行一次資料備份，使用磁帶或光碟片等媒體即可滿足備份需求。

• 執行系統源碼與資料備份。

  【日常維運管理需求】應備份系統源碼與資料，備份時機如廠商交付或內容變更時，或依機關規定定期備份。

• 應定期測試備份資訊，以驗證備份媒體之可靠性及資訊之完整性。

  【日常維運管理需求】常見之儲存媒體如磁碟、磁帶、光碟等，因使用方式及保存環境之差異，可能影響儲存媒體壽命而造成備份資料損毀。機關應訂定週期性測試時間表，並依時間表進行備份資料還原測試，以確保備份資料處於可用狀態。

• 應將備份還原，做為營運持續計畫測試之一部分。

  【日常維運管理需求】災害復原是營運持續計畫中相當重要之環節，其目的是為了在發生天災、人為疏失或惡意破壞造成資通系統損害 時，能快速回復至正常或可接受的營運水準。營運持續計畫應定期完整測試、演練，以驗證計畫之適切性及有效性，在災害復原過程中應使用備份資料，以驗證備份機制是否正確可靠。

• 應在與運作系統不同地點之獨立設施或防火櫃中，儲存重要資通系統軟體與其他安全相關資訊之備份。

  【日常維運管理需求】備份資料應有適當的實體(如防火櫃等)及環境保護，且不可儲存於運作系統處，以避免因系統損毀造成無法取用備份資料之情況。將備份資料異地存放於離運作系統有一段距離之場所，則可減少災害(如火災等)發生時，同時傷害正式資料與備份資料的風險。
  
  有關不同地點備份，宜朝「不遭受同一風險或事件影響」的方向考量，目前並未設置距離要求；有關距離建議，機關亦可參考「102年我國電腦機房異地備援機制參考指引」中，異地備份/備援機制提及之主機房與異地備援機房之距離應距離30公里以上，做為參考依據，以期在發生地震等區域性毀損時，仍能夠保存完整之備份資料及縮短回復時間。

3.2 系統備援

• 訂定資通系統從中斷後至重新恢復服務之可容忍時間要求。

  【日常維運管理需求】機關應考量服務需求、使用現況、相關資源項目，以及資安事件發生之風險，訂定資通系統從中斷後至重新恢復服務之可容忍時間要求，亦可稱為復原時間目標(Recovery Time Objective, RTO)。

• 原服務中斷時，於可容忍時間內，由備援設備或其他方式取代並提供服務。

  【日常維運管理需求】機關應準備適當及足夠的備援設備或其他有效恢復服務運作之方式(如還原虛擬機器快照等)，以便在發生災害時，可於所訂定之容忍時間內讓服務回復正常運作。

---

4. 識別與鑑別

4.1 內部使用者之識別與鑑別

• 資通系統應具備唯一識別及鑑別機關使用者(或代表機關使用者行為之程序)之功能，禁止使用共用帳號。

  【資安需求項目查檢】資通系統應具備唯一識別及鑑別機關使用者之功能，如替內部使用者建立個別帳號，以強化系統之可歸責性(Accountability)。若多人共用同一個帳號登入系統，則難以從稽核紀錄識別確切的使用者身分。

• 對資通系統之存取採取多重認證技術。

  【資安需求項目查檢】多重因素身分驗證係指具備兩種以上驗證類型，驗證類型一般區分為所知之事(如密碼、特定問題之答案)、所持之物(如晶片卡、憑證)及所具之形(如指紋、虹膜辨識等生物特徵)。

4.2 身分驗證管理

• 使用預設密碼登入系統時，應於登入後要求立即變更。

  【資安需求項目查檢】使用者註冊時係由資通系統或人工配發預設密碼者，於使用者首次登入時，應強制其變更預設密碼。

• 身分驗證相關資訊不以明文傳輸。

  【資安需求項目查檢】身分驗證相關資訊於網路傳輸時，不可直接傳輸明文(如密碼原始字串)，避免被惡意攔截網路封包而外洩。

• 具備帳戶鎖定機制，帳號登入進行身分驗證失敗達五次，至少15分鐘內不允許該帳號繼續嘗試或使用機關自建之失敗驗證機制。

  【資安需求項目查檢】系統應實作帳戶鎖定機制，於鎖定期間禁止該帳號所有登入嘗試，超過鎖定時間則重新計次。

• 使用密碼進行驗證時，應強制最低密碼複雜度、強制密碼最短及最長之效期限制。(但對於非內部使用者可依機關自行規範辦理)

  【資安需求項目查檢】應強制最低密碼複雜度，包含密碼長度限制及組成字元種類，目的在避免因使用安全性不足之密碼而被人輕易破解。強制密碼最短效期目的在防止使用者規避3次密碼歷程之限制，而於短期內頻繁變換密碼後又改回原始密碼。強制最長之效期之目的在避免固定使用同一組密碼。實務上，可參考政府組態基準GCB之建議值，設定密碼複雜度及密碼使用效期限制。

• 密碼變更時，至少不可以與前三次使用過之密碼相同。(但對於非內部使用者可依機關自行規範辦理)

  【資安需求項目查檢】使用者前3次舊密碼應被保留(以雜湊值形式)，於設定新密碼時，比對新密碼與舊密碼之雜湊值，若雜湊值相同則拒絕此次密碼設定。

• 身分驗證機制應防範自動化程式之登入或密碼更換嘗試。

  【資安需求項目查檢】系統若採用帳號密碼進行身分驗證，往往可能遭受到自動化程式以暴力破解方式嘗試登入。如圖形驗證碼(CAPTCHA)為常見的防範方式，透過將驗證碼以圖形方式呈現於頁面上，並要求使用者辨別該圖形中文字之方式，或以其他足以辨識人為動作之方式(如勾選特定選項等)，防堵自動化程式之嘗試行為。

• 密碼重設機制對使用者重新身分確認後，發送一次性及具有時效性符記。

  【資安需求項目查檢】密碼重設機制設計不良可能造成安全問題，常見錯誤是系統自行產生隨機密碼後以電子郵件寄送給使用者，此問題在於無法確保傳輸過程經過加密保護，故提高資安風險。使用者忘記密碼並啟動密碼重設機制時，應以使用者其他留存於系統的聯絡資訊，如電子郵件或手機號碼等，先要求使用者輸入該資訊，比對正確無誤後，發送一次性及具有時效性符記(如簡訊驗證碼、電子郵件驗證連結等)，一般會由亂數產生的英數字所組成，使用者接收後須於時效內進行輸入回傳動作，系統檢查回傳符記之有效性後，才允許使用者進行重設密碼動作。

4.3 鑑別資訊回饋

• 資通系統應遮蔽鑑別過程中之資訊。

  【資安需求項目查檢】資通系統身分鑑別頁面 中，資料輸入欄位(如密碼等)應設定不以明文顯示方式，如以*取代真實輸入字元，以避免他人從旁窺視而盜取密碼。

4.3 加密模組鑑別

• 資通系統如以密碼進行鑑別時，該密碼應加密或經雜湊處理後儲存。

  【資安需求項目查檢】密碼不可以明文方式儲存，應經過加密或雜湊處理，使得系統管理者或是惡意入侵的攻擊者皆無法輕易取得使用者原始密碼，以降低密碼外洩風險。實務上，當使用者設定密碼時，應針對該帳號產生一個亂數值(Salt)，將密碼結合亂數值，再以雜湊函式處理產生雜湊值後，分別於不同欄位儲存亂數值及雜湊值。後續使用者輸入密碼時，以輸入值添加當初設定密碼時產生的亂數，再次以雜湊函式處理，若產出結果同當初設定密碼時的雜湊值，則表示輸入密碼正確。

4.4 非內部使用者之識別與鑑別

• 資通系統應識別及鑑別非機關使用者(或代表機關使用者行為之程序)。

  【資安需求項目查檢】資通系統若開放給外部使用者(含其他機關、委外開發與維護廠商、臨僱人員及一般民眾等)存取使用，應具備識別及鑑別之能力，如利用帳號、憑證或來源IP位址等方式，識別與鑑別使用者。

---

5. 系統發展生命週期

5.1 系統發展生命週期需求階段

• 針對系統安全需求(含機密性、可用性、完整性)，以檢核表方式進行確認。

  【資安需求項目查檢】使用此自評工具進行系統安全需求檢核。

5.2 系統發展生命週期設計階段

• 根據系統功能與要求，識別可能影響系統之威脅，進行風險分析及評估。

  【資安需求項目查檢】可參照「安全軟體設計參考指引」之第3章安全軟體設計階段實務活動，包含「安全設計原則」，進行系統設計時應參考使用的設計原則；「執行攻擊面分析」，進行攻擊面的定義、識別與對應方式，包含如何進行攻擊面的衡量與評估，並進行管理等；「執行風險分析」，軟體設計過程中，如何透過使用威脅建模與架構風險分析，進行系統架構與威脅的分析，並使用通用性的安全設計原則與控制措施，提供軟體安全風險分析與控制；「安全設計審查」，在進行一連安全軟體設計的實務活動之後，應確保安全設計符合需求階段提出的相關安全需求。

• 將風險評估結果回饋需求階段之檢核項目，並提出安全需求修正。

  【資安需求項目查檢】系統發展生命週期需求階段發展之安全需求檢核項目，可能未能充分符合系統之所有安全需求，故應依據風險評估結果進行修正。

5.3 系統發展生命週期開發階段

• 應針對安全需求實作必要控制措施。

【資安需求項目查檢】應於系統開發階段，針對安全需求實作必要之控制措施，輔以檢核表方式進行確認，可減少遺漏之可能。

• 應注意避免軟體常見漏洞及實作必要控制措施。

  【資安需求項目查檢】軟體開發時應避免常見漏洞，如OWASP TOP 10或CWE/SANS TOP 25等，這些錯誤容易被惡意攻擊者利用，造成資料被竊取、竄改或使軟體無法運作，故需實作必要控制措施，以降低資安風險。

  • OWASP TOP 10

  • CWE/SANS TOP 25

• 發生錯誤時，使用者頁面僅顯示簡短錯誤訊息及代碼，不包含詳細之錯誤訊息。

  【資安需求項目查檢】系統應設計錯誤處理機制，當系統發生錯誤時，儘可能採取錯誤代碼或簡短訊息呈現，避免將詳細或除錯用訊息直接顯 示於使用者頁面，以防被攻擊者用來刺探系統內部資訊，或根據錯誤訊息推測出系統可能之弱點。確保系統所有功能的程式碼，在程式的進入點之後，盡可能採用程式語言的try-catch陳述，捕捉可能發生的錯誤與例外狀況。另外，採用程式語言的finally陳述，確保將該段功能程式碼所使用的資源正確釋放。

• 執行「源碼掃描」安全檢測。

  【資安需求項目查檢】源碼檢測可於程式開發及測試階段進行，以及早發現源碼之安全實作問題，並進行修補。實務上，常使用自動化檢測工具以提高檢測效率，輔以有經驗之軟體開發人員進行檢測結果檢視及分析，檢測工具可參考OWASP組織整理之免費及商業化工具列表。

• 具備系統嚴重錯誤之通知機制。

  【資安需求項目查檢】系統應區分錯誤等級，若發生嚴重等級錯誤時，採用電子郵件或簡訊等通知機制，使系統管理員或相關人員可及時掌握狀況，以利進行後續處理。

5.4 系統發展生命週期測試階段

• 執行「弱點掃描」安全檢測。

  【資安需求項目查檢】弱點掃描係利用自動化工具，對受測目標進行安全性掃描，以找出系統潛在弱點。

• 執行「滲透測試」安全檢測。

  【資安需求項目查檢】滲透測試係在取得合法授權後，對受測目標進行安全探測，由專業人士模擬駭客的攻擊行為，以人工及自動化掃描工具或攻擊程式等方式，尋找並利用系統弱點入侵系統，並於檢測作業完畢後提供完整的評估報告。

5.5 系統發展生命週期部署與維運階段

• 於部署環境中應針對相關資通安全威脅，進行更新與修補，並關閉不必要服務及埠口。

  【資安需求項目查檢】就作業系統或平台之安全更新，定期評估、測試與更新。系統上線前，就作業系統或平台預設開啟的服務與埠口(Port)進行檢視與評估，正面表列需要開啟該服務及埠口之理由，並關閉不必要之項目。

• 資通系統相關軟體，不使用預設密碼。

  【資安需求項目查檢】系統相關軟體元件或組態設定若有使用預設密碼，應於系統正式上線前變更完畢。

• 於系統發展生命週期之維運階段，應執行版本控制與變更管理。

  【日常維運管理需求】在維運階段可能因需求變更、系統除錯、功能精進等原因而需要變更系統組態，而版本控制之目的，即在記錄系統組態在某段時間內的變更行為，使得使用者在需要時可取回特定的版本，嚴謹的版本控制(如git、svn)與變更管理(如應用系統維護紀錄單)可強化系統的安全性與可用性。

5.6 系統發展生命週期委外階段

• 資通系統開發如委外辦理，應將系統發展生命週期各階段依等級將安全需求(含機密性、可用性、完整性)納入委外契約。

  【日常維運管理需求】機關委外開發資通系統時，可參考本文件之內容，並依據不同之安全等級(高、中、普)制定適用之安全需求，明確納入委外契約以做為驗收時之依據。

5.7 獲得程序

• 開發、測試及正式作業環境應為區隔。

  【日常維運管理需求】開發環境、測試環境與正式作業環境可區隔成不同的設備及網段，限制所能存取的應用程式及資料庫，以保護正式作業環境系統及資料。實務上，開發人員常以本機電腦為開發環境，並連結使用本機端之資料庫進行應用程式開發。俟開發完畢則將應用程式部署至測試主機，並連結至測試用資料庫，供測試人員進行測試使用。俟測試完畢，再將應用程式部署至正式環境，並連結至正式資料庫提供上線服務。

---

6. 系統與通訊保護

6.1 傳輸之機密性與完整性

• 資訊系統應採用加密機制，以防止未授權之資訊揭露或偵測資訊之變更。但傳輸過程中有替代之實體保護措施者，不在此限。

  【資安需求項目查檢】資訊系統傳輸機敏資料時，應避免明文傳輸。實務上，常採用加密傳輸協定(如HTTPS等)，以確保機敏資料傳輸過程中的安全，並應採取較安全的傳輸協定(如 TLS1.1 以上)及加密演算法(Cipher)，以降低被破解之風險。亦可進一步於伺服器端設定強制使用加密傳輸協定(如啟用網站安全性標頭之HTTP Strict Transport Security強制安全傳輸技術等)，避免使用者透過非加密傳輸協定存取應用系統伺服器。

• 使用公開、國際機構驗證且未遭破解之演算法。

  【資安需求項目查檢】若使用自行創造的加密方式且未經過適當的驗 證程序，可能存在設計瑕疵，增加被破解的風險。應採用公開、國際認可之演算法，如AES對稱式加密演算法、RSA非對稱式演算法及SHA安全雜湊演算法等。

• 支援演算法最大長度金鑰。

  【資安需求項目查檢】系統若採用密碼學演算法時，應使用該演算法目前支援的最大金鑰長度，以減少被暴力破解解密之可能及弱點。

• 加密金鑰或憑證應定期更換。

  【資安需求項目查檢】產生網站 HTTPS 使用之憑證，應具備使用年限限制，並於到期前進行更換。系統若另行使用自行產生之加密金鑰，亦需定期更換。

• 伺服器端之金鑰保管應訂定管理規範及實施應有之安全防護措施。

  【日常維運管理需求】伺服器端之金鑰一旦外洩，則加密機制視同無效，嚴重危害系統之機密性，故應訂定相關作業標準或管理規範，以妥善保護金鑰。如不將加密金鑰與加密資料存放於同一系統中，或對於加密金鑰的存取進行限制。

6.2 資料儲存之安全

• 資訊系統重要組態設定檔案及其他具保護需求之機密資訊應加密或以其他適當方式儲存。

  【資安需求項目查檢】資訊系統重要組態設定(如資料庫連線資訊等)以及任何具保護需求之資訊皆應實作機密保護機制避免外洩。

---

7. 系統與資訊完整性

7.1 漏洞修復

• 系統之漏洞修復應測試有效性及潛在影響，並定期更新。

  【資安需求項目查檢】針對系統所使用的外部元件與軟體進行表列，包含其版本資訊，定期關注元件版本更新訊息及安全漏洞通告，若有相關之安全漏洞，評估系統元件更新之必要性，並於系統測試環境進行更新測試驗證後，才於正式環境進行更新。

• 定期確認資訊系統相關漏洞修復之狀態。

  【日常維運管理需求】注意相關之安全漏洞訊息(透過CVE相關訊息網站、廠商安全通告等)，若發現採用之軟體或元件具有安全漏洞，應設法修復漏洞並定期追蹤修復之狀態。

7.2 資訊系統監控

• 發現資訊系統有被入侵跡象時，應通報相關人員。

  【日常維運管理需求】應指派人員負責處理資訊系統入侵攻擊相關資安事件，並於發現資訊系統有被入侵跡象時，通報相關人員進行處理。

• 監控資訊系統，以偵測攻擊與未授權之連線，並識別資訊系統之未授權使用。

  【日常維運管理需求】機關應具備監控資訊系統之能力，如指派專業人員或使用監控設備，用以偵測資訊系統連線行為，當發現未授權之連線或存取行為應向系統維護人員提出告警。

• 資訊系統應採用自動化工具監控進出之通信流量，並於發現不尋常或未授權之活動時，針對該事件進行分析。

  【日常維運管理需求】機關應透過多種工具及技術(如入侵偵測系統、入侵防禦系統、WEB應用程式防火牆、網路設備流量監控軟體等)達成監控能力，監控資訊系統所有進出之通訊活動，以發現不尋常或未經授權之連線及存取行為，並進行資安事件分析。

7.2 軟體及資訊完整性

• 使用完整性驗證工具，以偵測未授權變更特定軟體及資訊。

  【資安需求項目查檢】提供完整性驗證工具以驗證軟體或資訊在儲存或傳輸過程中未被人惡意竄改，如網站可在檔案下載連結處，提供以安全雜湊演算法產生之雜湊值，並說明使用的雜湊演算法為何，供使用者取得資料後自行計算雜湊值進行比對。另外，為確保系統程式之完整性，可對系統程式檔案留存雜湊值，並進行監控比對，以偵測未授權之惡意變更。

• 使用者輸入資料合法性檢查應置放於應用系統伺服器端。

  【資安需求項目查檢】對於使用者輸入欄位資料應檢查是否符合預期之邏輯規則，實務上以正規表示式(Regular Expression)驗證內容之合法性。檢查機制若於客戶端實作，容易被使用者繞過檢查機制，故應於應用系統伺服器端實作始視為有效。
  
  如採用Prepared statements, Stored procedures,Input Validation等措施防範SQL Injection攻擊；如採用黑名單過濾跳脫特殊字元、白名單正規表示式驗證、輸出編碼等措施防範XSS跨站腳本攻擊；網站若提供頁重導(Redirects)或導向(Forwards)之功能，必須確認使用者輸入欲重導向的網頁在合法白名單內，以避免重導向至惡意網頁。

• 發現違反完整性時，資訊系統應實施公司指定之安全保護措施。

  【日常維運管理需求】機關應訂定相關安全保護措施，在發現資訊系統完整性遭到破壞時採取適當之行動。如當發現資料庫或檔案被不當竄改、站台被植入惡意指令碼或元件等資安事件時，應通知系統管理者進行緊急應變處置，並依【日常維運管理需求】機關應訂定相關安全保護措施，在發現資訊系統完整性遭到破壞時採取適當之行動。如當發現資料庫或檔案被不當竄改、站台被植入惡意指令碼或元件等資安事件時，應通知系統管理者進行緊急應變處置，並依規定之通報流程進行資安事件通報作業。

• 應定期執行軟體與資訊完整性檢查。

  【資安需求項目查檢】重要資料或紀錄，以安全雜湊演算法產生並留存其雜湊值，後續可對資料再次產生雜湊值並與原先結果進行比對，以確保資料未遭異動竄改。