110 國安局特考三等 資訊組(選試英文) 網路應用與安全 考古題詳解

核心觀念

本題考查 SSL/TLS 與 HTTP、HTTPS 的分工，以及網站憑證認證、加密傳輸的作用。

• HTTP 是應用層的超文字傳輸協定，負責規範瀏覽器與網站伺服器如何交換網頁及相關資料；HTTP 本身不提供加密或伺服器身分認證。
• SSL（Secure Sockets Layer）是早期設計的安全傳輸協定；因存在安全弱點，已由 TLS（Transport Layer Security）取代。現今日常所說的 SSL 憑證，多半是對 TLS 憑證的俗稱。
• TLS 在傳輸層與應用層協定之間提供安全保護，可提供加密、完整性驗證及伺服器認證。
• HTTPS 是以 TLS 保護 HTTP 傳輸的方式。HTTP 負責應用層的請求與回應；TLS 負責保護這些資料在網路上的傳輸。常見 HTTPS 網址使用 TCP 連接埠 443，傳統 HTTP 常用連接埠 80。

解題方法

依「協定分工」及「安全目標」作答：先說明 HTTP 與 HTTPS 的關係，再說明 TLS 如何以憑證驗證網站身分，並以協商出的金鑰保護資料。最後分別列出未加密網站對使用者的風險，以及 HTTPS 對企業的效益。

(一) SSL、TLS、HTTP、HTTPS 之間的關係（8 分）

HTTP 是應用層協定，定義用戶端與伺服器傳送請求、回應的格式與程序，但傳統 HTTP 資料以明文傳送，未提供傳輸機密性、完整性或伺服器身分驗證。

SSL 是較早期的安全傳輸協定；TLS 是其後續標準，設計上承襲 SSL 的用途並逐步取代 SSL。SSL 與 TLS 的目的都是在應用層協定傳輸資料時提供安全保護，但 SSL 已不適合用於現代安全連線。

HTTPS 可理解為「HTTP over TLS」：HTTP 的內容先由 TLS 保護，再於網路上傳輸。瀏覽器與伺服器透過 TLS 建立安全連線後，HTTP 請求與回應便可受到加密及完整性保護。因此，HTTPS 並非取代 HTTP 的另一種網頁內容協定，而是以 TLS 保護 HTTP 傳輸。

(二) SSL/TLS 如何做到網站認證及傳輸安全？（6 分）

核心觀念

本題考查虛擬桌面基礎架構（Virtual Desktop Infrastructure, VDI）的桌面集中託管原理，以及遠距辦公時的連線操作與資安管理。VDI 將桌面作業環境及應用程式集中於機構資料中心或雲端的伺服器，使用者從端點裝置連線至虛擬桌面進行操作；一般情況下，畫面、鍵盤與滑鼠等操作訊號透過網路傳送，應用程式執行及資料處理則留在伺服器端。

解題方法

作答分成兩部分：第一部分交代 VDI 的架構元件與連線流程；第二部分依序說明使用者如何連線操作，以及管理者如何透過身分驗證、存取控制、端點管理、傳輸保護與稽核降低風險。這樣可同時涵蓋「原理」與題目特別要求的「操作方式、資安管理方式」。

（一）VDI 原理

VDI 是一種以伺服器虛擬化技術集中提供桌面環境的架構。使用者不必在個人電腦上安裝並執行所有業務系統，而是透過網路使用資料中心內的虛擬桌面。

典型架構包含：

1. 虛擬化主機與虛擬桌面：虛擬化平台在實體伺服器上建立多個虛擬機器，每個虛擬機器可提供一個桌面作業系統及所需應用程式。
2. 連線代理伺服器（Connection Broker）：驗證使用者身分，並依帳號、權限、資源狀況及桌面配置，將使用者導向適當的虛擬桌面。
3. 集中式儲存與管理系統：存放虛擬桌面映像檔、使用者設定檔及資料，並管理桌面生命週期、修補程式與資源配置。
4. 端點裝置與遠端顯示協定：使用者以個人電腦、精簡型終端或受管理的行動裝置連線，透過遠端顯示協定傳送畫面與操作訊號。

基本連線流程如下：

使用者在端點上看到桌面畫面並輸入鍵盤、滑鼠操作；指令經網路傳至虛擬桌面執行，再將畫面更新傳回端點。業務應用程式及主要資料通常留在機構伺服器或儲存設備內，端點主要負責顯示與輸入，因此能集中管理桌面與資料存取。

VDI 可採持續型桌面或非持續型桌面。持續型桌面會保留使用者桌面狀態；非持續型桌面則可在登出後還原至標準映像，再載入使用者設定檔或個人資料。採用方式依業務需求與管理策略決定。

（二）使用執行方式

1. 使用者操作方式

核心觀念

本題考查一般防火牆與應用程式防火牆（Web Application Firewall，WAF）的防護層次、檢查依據與可阻擋的攻擊類型。

一般防火牆主要依據網路層與傳輸層資訊控制流量，例如來源與目的 IP 位址、通訊埠、傳輸協定及連線狀態；WAF 則檢查 HTTP／HTTPS 應用層請求內容與行為，例如 URL、標頭、Cookie、表單欄位及請求本文，並依 Web 應用程式攻擊特徵判斷是否允許通過。

解題方法

作答時可依序比較兩者的檢查層次、判斷資料與防護範圍，再舉出一般防火牆難以辨識、但 WAF 可檢查並阻擋的攻擊。

一般防火牆像是依據封包的網路身分與連線狀態決定是否放行；WAF 則進一步檢視 HTTP 請求內的應用層語意。即使流量來自合法 IP，且使用允許的 TCP 埠號，只要 HTTP 請求內容含有攻擊行為，WAF 仍可依規則或異常行為特徵予以阻擋。

一般防火牆的運作原理

一般防火牆設置在網路邊界或網路區段之間，依管理者設定的存取控制規則，允許或拒絕網路流量。常見檢查方式包括：

• 封包過濾：檢查來源／目的 IP、通訊埠及傳輸協定等欄位。
• 狀態檢查：追蹤連線狀態，只允許符合既有連線狀態的封包通過。
• 網路存取控制：依規則限制哪些主機或網段可連線至哪些服務。

一般防火牆能有效阻擋未授權的網路連線、封鎖特定 IP 或通訊埠，也能限制不應對外開放的服務。然而，若攻擊者透過允許的 HTTP／HTTPS 服務送出惡意請求，從 IP、通訊埠與連線狀態來看仍可能是合法流量，一般防火牆便不容易判斷請求內容是否具備攻擊意圖。

WAF 的運作原理

WAF 專門保護 Web 應用程式，部署於使用者與 Web 伺服器之間，或以代理、雲端服務等方式檢查 Web 流量。它會解析 HTTP／HTTPS 請求與回應，依據規則、攻擊特徵、正規表示式、信譽資料或行為異常偵測，判斷是否應放行、記錄、告警或阻擋。

WAF 可檢查的內容包括：

• URL、查詢字串及 HTTP 方法。
• HTTP 標頭、Cookie 與表單欄位。
• 請求本文中的輸入資料。
• 請求頻率、欄位格式或其他應用層行為。

若流量經 HTTPS 加密，WAF 必須能在適當位置解密或終止 TLS，才能檢查加密後的 HTTP 內容。

核心觀念

本題考查「行動應用 App 基本資安檢測基準」中的敏感性資料定義，以及 App 在蒐集、儲存、傳輸、分享等資料生命週期中，如何保護這些資料。

法規與機關名稱以命題當年（民國 110 年）為準：當時依「行政院及所屬各機關行動化服務發展作業原則」，機關開發的行動化服務須通過經濟部工業局訂定的行動化應用軟體檢測項目，始得提供民眾下載使用。現行法規已修正相關機關名稱及規定，解題仍依命題當年版本。

解題方法

先界定何種資訊屬於安全敏感性資料，再依資料從取得、使用、儲存到傳輸或分享的流程，分別說明必要的安全控制。作答時要特別分清楚：蒐集、儲存及分享涉及告知與使用者同意；儲存、傳輸及分享則另須防止未授權存取或洩漏。

第一小題：定義及具體項目

依命題當年「行動應用 App 基本資安檢測基準」，安全敏感性資料係指：依使用者行為或行動應用程式運作，在行動裝置及其附屬儲存媒介建立、儲存或傳輸的資訊；若資訊洩漏，可能對使用者造成損害。

具體項目包括：

• 個人資料
• 通行碼、金鑰
• 即時通訊訊息
• 筆記、備忘錄、通訊錄
• 地理位置、行事曆
• 通話紀錄、簡訊

判斷重點是資料洩漏是否可能損害使用者，不宜只把敏感性資料理解成法定個人資料；通行碼、金鑰或位置資訊等，也可能屬於安全敏感性資料。

第二小題：各階段的安全原則

一、功能設計及資料蒐集

1. 必要且透明地蒐集：蒐集的敏感性資料應事先於可信任的應用程式商店或 App 內清楚聲明，並在蒐集前取得使用者同意。
2. 尊重拒絕權：應提供使用者拒絕蒐集的選項；使用者拒絕後，App 不得繼續蒐集該資料。
3. 使用目的明確：敏感性資料應限於已聲明的用途，不得超出原先告知範圍使用。

二、發布及使用

核心觀念

本題考查如何把資訊安全要求納入資通系統的完整發展流程，也就是安全系統發展生命週期（SSDLC）。核心原則是：安全不能等到系統上線後才補強，而應從需求階段開始，貫穿設計、開發、測試及部署維運。

解題方法與分題作答

一、SSDLC 的五個階段

依系統發展流程作答，五階段為：

1. 需求階段：確認系統功能及安全需求，例如身分驗證、存取控制、資料保護、稽核紀錄與可用性要求。
2. 設計階段：將需求落實於系統架構與安全設計；分析威脅與風險，規劃必要的安全控制措施。
3. 開發階段：依安全設計撰寫程式，遵循安全編碼規範，避免常見漏洞，並妥善處理錯誤與例外狀況。
4. 測試階段：驗證功能與安全需求是否達成，進行源碼檢測、弱點掃描及必要的安全測試，並修補發現的問題。
5. 部署與維運階段：安全地安裝、設定及上線系統，持續監控、更新、修補與處理事件。

作答時應以這五個階段為主軸，並點出「各階段都納入安全活動」這項 SSDLC 的特色。

二、開發時的一般錯誤訊息設計原則

系統發生錯誤時，面向一般使用者的畫面應只顯示簡短、適當的錯誤訊息或錯誤代碼，不應直接顯示詳細錯誤內容或除錯資訊。詳細訊息可能暴露系統內部資訊，例如檔案路徑、資料庫結構、程式堆疊資訊或元件版本，讓攻擊者藉此推測弱點。

程式應妥善捕捉錯誤與例外狀況，例如使用 try-catch；並在適當情況下以 finally 釋放資源，避免錯誤處理不當造成資源未釋放或系統狀態異常。