資訊處理安全確保支援士(情報処理安全確保支援士) 2023年秋季(令和5年) 下午問2解說 ── 從來賓用Wi-Fi被帶出的檔案

禁止了USB隨身碟，禁止了本機儲存與郵件附加檔案，連公司內部檔案伺服器都廢止了。即便如此，業務用檔案的帶出路徑依然留著。

資訊處理安全確保支援士考試(情報処理安全確保支援士試験) 2023年度(令和5年度)秋季 下午問2要問的不是對策的數量，而是「誰、從哪一台終端裝置、經由哪一條路徑能夠到達檔案」。對業務PC有效的對策，和阻擋來自個人自有PC存取的對策，必須分開思考。¹

本文是接續問1(儲存型XSS)解說的系列第二篇。各設問依「解答範例 → 題目中的依據 → 機制」的順序追查，超出考試前提的實務注意事項整理在第10章。題本中的圖表不予原樣轉載，改用本公司繪製的簡化圖與摘要。出處以及引用、摘要的範圍記於文末。¹²

1. 先看全貌 ── 把公司外的攻擊者與員工分開

這道題目分成以下3個階段來讀就能理清。

公司外的攻擊者必須竊取認證資訊，員工則能用自己的正規ID登入。後者所使用的個人自有PC，業務PC上的資訊外洩防範軟體對它不起作用。而且，B服務的來源IP位址限制看的不是終端裝置，而是NAT的出口。這項差別把整道題目串了起來。

從設問前往需要的章節

若是為了應考，請先在第2章掌握前提，再前往想解的設問。如果目的是實務上的設計審查，可以從第11章的對策比較與第12章的檢查清單讀起，再到第10章確認條件與例外。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 24 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 題目的前提 ── M公司守護了什麼、允許了什麼

2.1. 前一年的事件與已實施的對策

M公司是L公司的子公司，經營服飾業，員工100名。辦公大樓面向東京都內人潮眾多的大馬路。前一年發生過一起事件：員工把公司內部檔案伺服器上的商品設計檔案存到USB隨身碟，帶進了競爭同業。在母公司的指導下，M公司已經完成以下檢討。¹

這是把前一年「公司內部檔案伺服器 → USB隨身碟」這條路徑的兩端都堵住、合情合理的對策。不過，對PC的限制，效力僅止於裝了那套軟體的業務PC。

2.2. 會議室與辦公室，規則涵蓋的範圍不同

資安規則有以下3條。

辦公室可以使用員工用無線區域網路，會議室則員工用與來賓用兩者都能使用。會議室的投影機，採用的是把來賓攜入的裝置(PC、平板電腦、智慧型手機)或業務PC連上來賓用無線區域網路來使用的架構。

2.3. 網路雖然分開，通往網際網路的出口卻是同一個

只把說明所需的部分寫出來，架構如下。

flowchart LR
    subgraph M["M公司的公司內部網路"]
        direction TB
        G["來賓用無線區域網路<br/>192.168.10.0/24<br/>(只有會議室的AP)"]
        E["員工用無線區域網路<br/>192.168.20.0/24<br/>(辦公室與會議室)"]
        S["伺服器網路<br/>192.168.30.0/24<br/>DHCP、DNS、目錄服務"]
        FW["FW<br/>以NAT把來源轉換為<br/>1個公用IP<br/>位址"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["B服務<br/>(雲端儲存空間)"]
    FW --> I["網際網路"]

圖1：M公司架構的簡化圖。來賓用、員工用、伺服器用的網路雖然分開，但通往網際網路的通訊都經過同一台FW的NAT。

2.4. B服務的「登入」與「對外共用」是兩個不同的入口

B服務有以下2種使用方式。

共用連結不會告知申請者本人，也不會告知主管。連結含有難以猜測的隨機字串，有效期限是1天。另一方面，外部共用對象不必登入就能下載。請不要拿針對員工ID的登入限制，去解釋共用連結的使用。

資訊系統部的Y先生，與母公司L公司的資訊處理安全確保支援士S先生，就以這個架構為前提，依公司外的攻擊者、員工、追加對策的順序展開檢討。

3. 設問1(1)(2) ── 就算連上假AP，登入假網站還是會被擋下

3.1. 設問1(1)：就算能連上無線區域網路，還是需要ID與密碼

解答範例：空格a、b是「使用者ID」「密碼」(順序不拘)。²

Y先生最先設想的，是曾經使用過來賓用無線區域網路的來賓，日後從M公司附近連線、存取B服務的路徑。由於大樓面向大馬路，因此要把電波能傳到公司外面這件事納入考量。

WPA2-PSK是所有人持有同一把預先共用金鑰的方式。沒辦法只讓曾經告知過的對象回到「不知道」的狀態，要取消就得更換所有人的金鑰。不過，連上無線區域網路和登入B服務是兩回事。公司外的攻擊者沒有員工的使用者ID與密碼。

3.2. 設問1(2)：假網站的憑證會在核發單位與伺服器名稱上不合格

於是接下來設想的，是準備一台設定與來賓用無線區域網路相同的假AP，以及一個URL與B服務相同的假網站，再對DNS設定動手腳來竊取登入資訊的做法。目標是讓員工的業務PC誤連到假AP。

使用相同SSID、相同預先共用金鑰的假AP，稱為evil twin(邪惡雙胞胎)。WPA2-PSK能確認的，只有對方知道同一把金鑰這件事。不知道金鑰就無法走完連線程序，但只要是知道發給來賓那把金鑰的攻擊者，就能架出難以與真品區分的AP。

即便如此，只要以HTTPS連線到B服務的URL，就會進行伺服器憑證的驗證。把題本圖2中的錯誤詳情連同空格一起填出來，就是以下4個項目。

• 這張伺服器憑證不是由受信任的憑證授權單位所核發的伺服器憑證(空格c)
• 這張伺服器憑證上記載的伺服器名稱，與連線目標的伺服器名稱不同(空格d)
• 這張伺服器憑證已被撤銷
• 這張伺服器憑證已超過有效期限

設問1(2)要回答的是上面2個項目(c、d，各40字以內、順序不拘)。撤銷與有效期限這2項，題目一開始就已經寫出來了。²

sequenceDiagram
    autonumber
    participant U as 員工的業務PC
    participant F as 假AP、假網站<br/>(攻擊者)
    participant B as B服務(正規)

    Note over F: 以與來賓用無線區域網路相同的SSID、<br/>相同的預先共用金鑰架設AP
    U->>F: 誤連到假AP
    Note over F: 對DNS動手腳，把B服務的<br/>網域名稱指向假網站
    U->>F: 以HTTPS連線到B服務的URL
    F-->>U: 假網站的伺服器憑證
    Note over U: 驗證不合格<br/>・不是由受信任的憑證授權單位核發<br/>・憑證的伺服器名稱與連線目標不同
    Note over U: 顯示連線不安全的錯誤<br/>不會顯示登入畫面
    Note over U,B: 根本就沒有與正規的B服務<br/>進行通訊

圖2：即使連上了假AP，HTTPS的伺服器憑證驗證依然存在。無線區域網路的驗證，與連線目標網站的確認，是不同階段的事。

3.3. 不要只說「憑證錯誤」，要答到驗證了什麼

若是自我簽署憑證，憑證鏈就無法追溯到信任的根憑證。就算攻擊者為自己的網域(例如 b-service.example.net)正規取得了憑證，也不會與B服務的網域名稱一致。在題目的前提下，攻擊者並未管理B服務的網域，因此無法取得該名稱的正規憑證——這就是解答的依據。

憑證的路徑驗證由RFC 5280說明，名稱的比對則由RFC 6125說明。³⁴

IPA的評分講評對設問1(2)有如下敘述。⁵

設問1(2)的正答率偏低。就算攻擊者準備了假網站，只要是以HTTPS存取，伺服器憑證的驗證就會失敗。伺服器憑證的驗證，是確保通訊安全性的基本知識，希望考生連「具體要驗證哪些事項」都一併好好理解。

被問的不只是「會出現錯誤」這個結果，而是能否具體舉出核發單位與名稱。不過在實務上，還需要確認撤銷檢查的實作以及終端裝置的信任存放區。4個項目並不是永遠以相同的可靠程度發揮作用，這一點會在10.1、10.2節說明。

4. 設問1(3) ── HSTS在送出HTTP之前就換成HTTPS

4.1. 解答要寫到「替換 → 收到憑證」為止

設問問的是：連上假AP的員工把B服務的URL誤打成 http:// 時，直到顯示錯誤之前瀏覽器如何動作，限60字以內。

解答範例：「把HTTP的存取替換成HTTPS的存取後再進行存取。之後，從假網站收到伺服器憑證」。²

HSTS(HTTP Strict Transport Security)是這樣一種機制：瀏覽器會記住以HTTPS收到的 Strict-Transport-Security 標頭，之後便以HTTPS連線到該主機。這由RFC 6797所規定。⁶

存取已知的HSTS主機時，會依以下順序進行。

1. 在瀏覽器內部把URL的配置由 http 換成 https。如果明確指定了通訊埠80，則轉換為443。
2. 以HTTPS連線。不過在這道題目中DNS已被動過手腳，所以連線目標是假網站。
3. 從假網站收到伺服器憑證。
4. 憑證驗證失敗，變成第3章的錯誤。

並不是先送出明文的HTTP要求之後才切換。替換在送出到網路之前就已經完成。設問要求的是直到錯誤之前，所以解答範例只說明到第3步。

4.2. HSTS還有「不讓人無視警告繼續前進」的作用

RFC 6797的8.4節要求：在與已知的HSTS主機建立安全通訊路徑的過程中只要發生錯誤，無論屬於警告等級還是致命等級，都要切斷連線。12.1節則把這一點說明為 “No User Recourse”。⁶

一般的憑證錯誤，在許多瀏覽器上都會有「進階設定」「繼續前往」之類的動線。對於已啟用HSTS的主機，不得把這種迴避手段提供給使用者。連「反射性地按掉憑證錯誤」這個動作都一併擋住，對於防範假網站很重要。

4.3. 前提是那個瀏覽器裡有有效的HSTS紀錄

光是網站端有HSTS設定，並不代表所有終端裝置的第一次存取都受到保護。通常必須是那個瀏覽器曾經以HTTPS抵達正規網站並收到過標頭才行。

新業務PC的第一次存取、因重建瀏覽器設定檔或刪除瀏覽資料而使紀錄一併消失的情況、紀錄的 max-age 已到期的情況，都無法使用該紀錄。填補「第一次」這個問題的，是瀏覽器的HSTS預先載入清單。登錄要件與撤回的困難，會在10.3節說明。

5. 設問2(1) ── 正規的共用功能，若不確認收件對象也會變成帶出路徑

5.1. 解答的依據是「主管沒有確認收件對象」

接下來要檢討的是持有正規使用者ID的員工。設問2(1)問的是：為了讓檔案能從M公司外部下載，要如何濫用共用功能，限40字以內。

解答範例：「把外部共用對象的電子郵件地址指定為自己的私人電子郵件地址」。²

B服務有主管核准，而且共用連結不會告知申請者本人，也不會告知主管。連結還有難以猜測的字串與1天的有效期限。即便如此，只要把收件對象設成自己的私人地址，自己就能以外部共用對象的身分收到連結。既不需要猜測連結，也不需要從業務PC寄送附加檔案。

題目中Y先生的回答是：有些主管並未確認收件的電子郵件地址與檔案。缺的不是核准機制本身，而是「核准者會確認收件對象」這個維運上的前提。

5.2. 有沒有核准，與核准內容是否被確認，要分開來看

核准工作流程的前提，是核准者會看內容。如果沒看，它就不是阻止不當共用的機制，而會變成配送連結的管道。

在實務上，核准件數、判斷材料、業務的截止期限、核准結果的事後確認，都要一起設計。具體的檢討表整理在10.4節。

6. 設問2(2) ── 個人自有PC從會議室就能到達B服務

6.1. 共通點是「不使用業務PC」

禁止攜入個人自有PC的只有辦公室，會議室是可以帶進去的。題目中的方法1與方法2，都是用個人自有PC下載檔案，再把整台PC帶出去的路徑。

下載的目的地在資訊外洩防範軟體的管轄之外。就算在業務PC上禁止USB隨身碟與本機儲存，對這條路徑也起不了作用。

6.2. 設問2(2)：要變更的是MAC位址

解答範例：空格e是「MAC位址」。²

方法1會把個人自有PC無線網路介面的MAC位址，改成業務PC的MAC位址。員工本身就是業務PC的使用者，因此能夠得知大家共用的預先共用金鑰。MAC位址也能在終端裝置端的設定或驅動程式的內容中變更；而且它在無線區域網路訊框上並未加密，只要在附近接收電波，也能得知已登錄的位址。

停用SSID廣播，也擋不住從連線時的交握過程得知SSID。MAC位址過濾與停用SSID廣播，雖然可以當作減少誤連線的整頓手段，卻不是能驗證「刻意前來連線的對象」的機制。

6.3. 方法2只要連上來賓用無線區域網路就行

只要使用發給來賓的預先共用金鑰，員工也能把個人自有PC連上來賓用無線區域網路。接著只要用自己的使用者ID登入B服務下載就行了。

為什麼能通過「只能從M公司的公用IP位址」這項限制呢？答案就在FW的NAT設定裡。

從B服務看到的來源IP位址，全都是同一個。單靠這項設定，無法區分員工用無線區域網路上的業務PC與來賓用無線區域網路上的個人自有PC。

來源IP位址限制允許的不是終端裝置，而是共用那個出口的範圍。這不是說限制不需要，而是必須掌握實際的允許範圍，並與終端裝置驗證或使用者驗證疊加起來。實務上的例子整理在10.5節，題目中的對策則整理在第8、9章。

7. 設問3(1)〜(4) ── 用EAP-TLS與TPM限定能夠連線的終端裝置

7.1. 設問3(1)：AP與驗證伺服器之間是RADIUS

針對方法1的對策，是把員工用無線區域網路改成EAP-TLS，並準備一台驗證伺服器。設問3(1)問的是驗證伺服器在EAP中使用、在UDP上運作的通訊協定，解答範例是「RADIUS」。²

業務PC與AP之間是IEEE 802.1X(EAP over LAN)，AP與驗證伺服器之間是RADIUS。RADIUS由RFC 2865規定，EAP-TLS的程序則由RFC 5216規定。若以Windows Server建置驗證伺服器，則由網路原則伺服器(NPS)擔任這個角色。⁷⁸⁹

表格最後一列中，用戶端驗證憑證的對象不是AP，而是驗證伺服器。前提是要在用戶端設定好所信任的憑證授權單位與伺服器名稱，光是選用EAP-TLS並不夠。詳細會在10.6節說明。

7.2. 設問3(2)：要保護的不是公開金鑰而是私密金鑰

新建置一台CA伺服器來核發用戶端憑證，並且不透過員工手動作業，而是以目錄伺服器的功能存放到業務PC。與那張憑證配對、要用TPM保護的空格f，解答範例是「私密金鑰」。²

公開金鑰包含在憑證裡，是可以交給對方的資訊。驗證時要證明的，是自己持有與之配對的私密金鑰。由於是用那把金鑰簽章來證明，因此私密金鑰一旦被複製，別台終端裝置也能使用同一份認證資訊。

IPA的評分講評也指出了區分私密金鑰與其他要素的重要性。⁵

設問3(2)的正答率略高，但仍有部分考生作答為”公開金鑰”或”伺服器憑證”。PKI是各種資安技術的基礎，是很重要的技術，希望考生能好好理解它在什麼場合、以什麼方式被使用。

7.3. 設問3(3)：存放到TPM，使其無法從業務PC取出

空格g問的是存放到TPM的目的，限20字以內。解答範例是「使其無法從業務PC取出」。²

如果把私密金鑰以檔案形式放在終端裝置上，那就是可以複製的資料。只要複製到個人自有PC，那台個人自有PC就能以業務PC的身分通過驗證。本以為堵掉了方法1(偽造MAC位址)，結果只是換成了「偽造憑證」而已。

TPM可以在其內部產生金鑰，並以無法取出到外部的狀態保存。簽章等運算都在TPM內部進行，金鑰本身不會交給OS，也不會交給應用程式或惡意軟體。結果就是，那把私密金鑰被固定在那1台機器的實體零件上。

若要在Windows上實作，需在憑證範本的金鑰儲存提供者(KSP)中指定 Microsoft Platform Crypto Provider。這個提供者會利用TPM來保護金鑰；如果憑證範本那邊勾選了「允許匯出私密金鑰」，就無法選擇它¹⁰。既然能匯出，保護就失去意義——這是理所當然的限制。

關於TPM這個零件本身的角色，BitLocker實務指南已從磁碟機加密的脈絡加以說明。「不讓私密金鑰離開裝置」這種想法，與為什麼Passkey安全中說明的驗證器設計，出於相同的發想。

7.4. 設問3(4)：把配發對象與金鑰保護成套說明

這道設問要問的是：S先生之所以回答「採用那種儲存方式就沒問題」的理由，限40字以內。

解答範例：「因為EAP-TLS所需的認證資訊，只能存放在業務PC上」。²

依據是以下的連鎖關係。

1. 用戶端憑證由目錄伺服器配發到業務PC，不經過員工之手。
2. 與之配對的私密金鑰由TPM保護，使其無法從業務PC取出。
3. 由於無法把認證資訊搬到個人自有PC，即使偽造MAC位址，EAP-TLS的驗證也不會通過。

重點在於「採用那種儲存方式的話」這個條件。如果把私密金鑰以可複製的檔案形式交出去，就得不到相同的結論。另一方面，TPM擋下的是金鑰的複製，終端裝置本身被帶走、使用者被冒用、終端裝置上的惡意軟體，則是另外的問題。侷限整理在10.7節。

8. 設問3(5) ── 只把來賓用無線區域網路的NAT出口換掉

針對方法2的對策，有變更NAT設定的方案，以及用另一項無線區域網路服務(D服務)把來賓用網路隔離的方案。

設問3(5)問的是NAT的變更內容，限70字以內。解答範例的要旨是「把從來賓用無線區域網路存取網際網路時的來源IP位址，改成與目前使用的公用IP位址不同的IP位址」。題目中表示目前位址的記號是 a1.b1.c1.d1。²

這不是去變更B服務那一側的IP位址限制。而是只讓來賓用無線區域網路被轉換成另一個公用IP位址，把它排除在既有的允許範圍之外。

這個方案之所以可行，依據在於題目中FW的WAN側子網路遮罩是255.255.255.248(/29)，可用的公用IP位址不只1個。實務上能不能採用同樣的方案取決於線路合約；如果只能使用1個公用IP位址，這個方案就行不通。那種情況下，就要考慮下一章的隔離方案。

9. 設問3(6)(7) ── 隔離來賓用網路，並刪除舊設定

9.1. 最後採用的是以SIM直接連上網際網路的D服務

M公司最後選擇的是D服務。在會議室放置租借來的D路由器，並啟用其DHCP伺服器功能與DNS快取伺服器功能。來賓攜入的裝置不經過M公司的網路，而是透過D路由器的SIM連上網際網路。投影機也從來賓用無線區域網路改成以HDMI線連接的方式。

flowchart LR
    subgraph M["M公司的公司內部網路(對策後)"]
        direction TB
        E["員工用無線區域網路<br/>EAP-TLS + RADIUS<br/>私密金鑰在TPM之中"]
        S["伺服器網路"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["會議室"]
        T["來賓攜入的裝置"]
        D["D路由器<br/>以SIM直接連上網際網路"]
        T --> D
    end
    FW --> B["B服務"]
    D --> I["網際網路"]

圖3：對策後架構的簡化圖。員工用強化終端裝置的驗證，來賓用則隔離到不使用與M公司相同出口的路徑。

9.2. 設問3(6)：變得不需要的通訊對象是DNS伺服器

設問問的是來賓攜入的裝置不再使用的M公司DHCP伺服器與空格h的伺服器。解答範例是「DNS」。²

由於D路由器本身就具備這兩項功能，來賓裝置不再需要與M公司伺服器網路上的DHCP、DNS伺服器通訊。

9.3. 設問3(7)：表3是項次1，表4是項次1與4

設問要求的是：從FW的VLAN介面設定與過濾設定中，各自把要刪除的項次全部列出來。²

同時也要從AP刪除來賓用SSID的設定。不過，設問3(7)要作答的項次，是上面表3、表4裡的那些。請不要與AP的SSID刪除混為一談。

IPA的評分講評對設問3(7)有如下敘述。⁵

設問3(7)的正答率很高。雖然必須理解防火牆的全部過濾設定，以及重新檢視無線區域網路環境所帶來的影響才能作答，但考生都有適當理解。

這道題目的FW，是依項次由小到大逐一評估，套用第一條符合的規則。不過，這並不是所有產品共通的規格。漏刪的風險與評估方式的差異，會在10.8節說明。

10. 實務補充 ── 不要把考試的答案直接一般化

接下來要談的，是希望與設問解答本身分開確認的幾點。整理憑證、HSTS、終端裝置驗證能發揮作用的條件，以及在實際運作中仍然殘留的路徑。

10.1. 憑證的撤銷檢查，可靠程度因瀏覽器而異

這裡要先把考試的答案和實際瀏覽器的行為分開。3.3節的4個項目，是題目圖2以「可能顯示的錯誤詳情」列出來的內容，不能解讀成每一款瀏覽器都以相同的可靠程度檢查這4項。

核發單位、伺服器名稱、有效期限這3項，在收到憑證的當下光憑手邊的資訊就能判定，因此一定會被驗證。擋下這道題目中攻擊的，也正是這3項。

另一方面，唯獨撤銷的確認性質不同。 是否已被撤銷並沒有寫在憑證裡，必須另外去取得資訊，因此取決於實作與設定。

• Chrome通常不會進行線上的OCSP或CRL確認。取而代之的是散布一份名為 CRLSet 的有限清單，其主要目的是在緊急時迅速封鎖憑證，而從CA的撤銷清單納入其中的只是一部分¹¹
• 就算是會查詢OCSP的實作，在取不到回應時仍放行連線的(soft-fail)組態也被廣泛採用

因此，請不要把「私密金鑰外洩了就撤銷即可」當成對策的支柱。撤銷是該做的事，但它並不是能在所有使用者的瀏覽器上確實生效的機制。近年來憑證有效期間的縮短，也是業界對「撤銷靠不住」這件事給出的回答。當自家公司懷疑金鑰外洩時，必須在申請撤銷的同時，一併著手更換憑證，並把那把金鑰所保護的東西(工作階段、API金鑰等)全部作廢。

10.2. 信任存放區的內容，以及使用者原本想連的網域也要確認

從這裡開始是題目之外的話題。3.3節表格的第1項，取決於那台終端裝置信任什麼。信任清單由瀏覽器或OS持有，在Windows上就是憑證存放區中的「受信任的根憑證授權單位」。

也就是說，在以下狀況中，第1項檢查是會通過的。

• 已把公司內部憑證授權單位(私有CA)的根憑證配發到業務PC。而該CA的私密金鑰，或是憑證的核發程序被攻擊者掌握了
• 檢查通訊內容的Proxy或資安產品，為了終結TLS而把自家的根憑證裝進終端裝置。而該產品或其維運被攻擊者掌握了
• 以「會出現憑證錯誤」為由，過去有人登錄了例外，或是把自我簽署憑證放進了受信任的根憑證

第3種在現場真的很常見。像是為了消掉公司內部系統的憑證錯誤而手動放進去一次的東西，一直留在從離職者PC沿用下來的映像檔裡。受信任的根憑證授權單位存放區裡的內容，本身就是那台終端裝置宣告自己信任誰，因此請把它列入盤點對象。哪個存放區該放什麼，這類判斷已整理在Windows憑證存放區實務指南。

至於第2項檢查(伺服器名稱的一致)，實務上另有需要注意的地方。使用者看錯網域名稱的攻擊，憑證對此無能為力。只要攻擊者取得像 b-serv1ce.example.com 這種容易混淆的網域，並為該網域正規取得憑證，瀏覽器就不會顯示錯誤。憑證所保證的是「連線目標的伺服器名稱與憑證上的伺服器名稱一致」，而不是「那個伺服器名稱就是使用者想連的對象」。不讓最後這一步依賴使用者目視的機制，就是像Passkey(WebAuthn)那樣由驗證器端驗證來源(origin)的方式。詳情在為什麼Passkey安全中說明。

10.3. HSTS預先載入，要先確認子網域與撤回的影響

填補這個「第一次」問題的，就是HSTS預先載入清單。只要列在事先內建於瀏覽器的網域清單裡，即使從未存取過，也會被強制走HTTPS。

不過，如果考慮登錄自家網站，請先確認條件。登錄的要件如下¹²。

• 要提供有效的憑證
• 若有在通訊埠80上接聽，要在同一主機上從HTTP重新導向到HTTPS
• 所有子網域都要以HTTPS提供(只要有DNS記錄，www 也包含在內)
• 在基礎網域上要回傳 max-age 為 31536000秒(1年)以上、並帶有 includeSubDomains 與 preload 的 Strict-Transport-Security 標頭

真正會產生影響的，是第3項與 includeSubDomains 的組合。如果對內使用的舊子網域只支援HTTP，或是根本沒準備憑證，那麼在登錄的瞬間就會連不上它們。 登錄前請把子網域全部盤點一遍。

而且，撤回並不容易。 刪除的申請一般是會受理的，但變更要送達使用者的瀏覽器需要花上數個月，而且Chrome以外的瀏覽器並無保證¹²。最好抱著「預先載入不是弄錯了再改回來就好的設定」這種認知來面對，才比較安全。

反過來站在使用者的立場，業務上使用的雲端服務是否支援HSTS，是可以納入選型確認項目的觀點。

10.4. 設計給核准者的判斷材料，以及核准後的檢查

實務上核准之所以流於形式，原因大致是以下幾種之一。

這道題目中的M公司所欠缺的，主要是最後兩項。導入了讓核准通過的機制，也就需要事後檢視核准結果的機制。 光是能列出每個月有幾件外部共用是寄給免費信箱網域的，這種手法就會變得相當容易被發現。

中小企業該從何處著手的整體樣貌，在IPA「中小企業資訊安全對策指南」第4.0版導覽中說明。

10.5. 從出口把來源IP位址的允許範圍全部盤出來

這個結構在考試之外也會反覆出現。以來源IP位址進行的限制，意思不是「只允許這台終端裝置」，而是「允許所有從這個公用IP位址出去的人」。 以下舉出「自以為允許的範圍」與「實際被允許的範圍」出現落差的典型例子。

這並不是說以來源IP位址進行的限制沒有意義，而是說不要只靠這一層限制。先用IP位址收斂之後，再疊上識別終端裝置本身的機制(用戶端憑證或裝置憑證)以及識別使用者的機制(多因素驗證)，才終於能表達「這台終端裝置上的這個人」。第7〜9章所看到的對策，也是依循這個想法。

10.6. EAP-TLS中被驗證的對象是驗證伺服器

7.1節比較表的最後一列需要補充。在EAP-TLS中，用戶端驗證憑證的對象不是AP，而是驗證伺服器。AP只是中繼EAP交握的驗證者，用戶端並沒有在確認AP本身的身分。

即便如此，它之所以仍能作為第3章evil twin的防備，是因為驗證成功後才會產生的金鑰素材，只會交給持有RADIUS共用秘密的正規AP。攻擊者擅自架設的AP，除非後面接著正規的驗證伺服器，否則無法把這套程序走到最後。用戶端直接驗證的是驗證伺服器，AP的正當性則是從那裡間接導出來的——結構是這樣。

不過這是有條件的。如果沒有在用戶端設定好「要相信由哪個憑證授權單位核發、名稱為何的伺服器憑證」，那麼當攻擊者準備了自己的驗證伺服器時就分辨不出來。明明導入了EAP-TLS，卻在用戶端的設定檔中停用伺服器憑證驗證，這樣的組態實際存在。導入之後，請連這部分一起確認。

10.7. TPM解決不了終端裝置本身被濫用與使用者驗證的問題

另一方面，這也不是說放進TPM就高枕無憂。TPM所保證的只有「那把金鑰不會被複製到其他終端裝置」這一點。以下這些它並不防護。

• 終端裝置本身被帶走的情況。 只要把業務PC帶走，就等於連TPM一起帶走。M公司的規則雖然禁止把業務PC帶出公司，但規則與技術上的強制是兩回事。另外還需要磁碟機加密(含開機前驗證)，以及遺失時撤銷憑證的維運做法
• 使用者被冒用。 TPM能識別終端裝置，卻不保證操作那台裝置的人是誰。使用者的驗證必須另外準備
• 在終端裝置上運作的惡意軟體。 私密金鑰雖然讀不出來，但在那台裝置上執行的程式碼是可以「請TPM代為簽章」的。就算能防止金鑰被複製，也擋不住那台裝置被占據期間遭到濫用

10.8. 刪除舊的放行規則。FW的評估方式要逐一產品確認

雖然是正答率很高的設問，但在實務上真正能做到這個地步的組織並不多。 導入新機制的工作有預算也有期限，刪除舊設定的工作卻兩者都沒有。而忘記刪除，會以下列形式浮上檯面。

這道題目的防火牆採用的是從項次小的規則開始依序評估，套用第一條符合的規則的方式(題目中有明確寫出)。在這種方式下，把不再使用的放行規則留在上方，就等同於留著一個不讓封包走到末尾拒絕規則的破口。

不過，請不要把這種評估方式一般化到所有的防火牆上。 判定方式會因產品而異。

無論是哪種方式，留著用不到的放行規則很危險這一點本身並不會改變。改變的是「為什麼危險」與「該怎麼修正」。請先確認自家設備屬於哪一種方式，再把「來源與目的地現在是否還存在」這個觀點納入定期盤點的對象。

至於業務應用程式端所需的輸入規則該如何管理，這種主機端防火牆的話題，在Windows防火牆與業務應用程式中說明。

11. 把對策與路徑對應起來，回顧全貌

11.1. 既有的對策，究竟發揮作用到什麼程度

HTTPS與HSTS擋下了題目所設想的通往假網站的路徑。另一方面，就算增加業務PC上的操作限制，使用未受管終端裝置或正規共用功能的路徑依然留著。

11.2. 追加的對策各自堵住哪一條路徑

被跨過的對策中，有許多是禁止手段的對策，例如USB隨身碟或郵件附加檔案。發揮作用的對策與追加的對策，改變的則是路徑或認證資訊的性質。堵住USB隨身碟，只要還留著能到達檔案的路徑，帶出就依然成立；把預先共用金鑰加長，它是共用秘密這件事也不會改變。

12. 套用到自家架構上的檢查清單

1. 帶出對策能不能以路徑而非手段寫出來。 不要列USB隨身碟、郵件附加檔案、網頁郵件這種手段清單，而是做出「能到達業務檔案的終端裝置與網路清單」。只要還有1條未受管終端裝置能到達的路徑，禁止手段就會被繞開
2. 攜入、帶出的規則是不是限定了場所。 「禁止攜入辦公室」等於允許了會議室、櫃台、共用空間。要確認實體的分區與網路的分區是否一致
3. 說不說得出來源IP位址限制實際允許的範圍。 把從那個公用IP位址出去的東西全部數過一遍：來賓用Wi-Fi、來賓用網路、據點間VPN、遠距辦公的集中閘道、驗證環境
4. 無線區域網路的認證資訊是不是每台終端裝置各自一份。 預先共用金鑰是所有人持有同一份的共用秘密，一人外洩就等於所有人外洩，也沒辦法只停用特定的1台
5. 有沒有把MAC位址過濾與停用SSID廣播算進對策的數量裡。 這兩者都只是減少誤連線的整頓，並不是驗證
6. 用戶端憑證的私密金鑰是不是處於無法從終端裝置取出的狀態。 以檔案形式放著的私密金鑰是可以複製的。要指定使用TPM的金鑰儲存提供者，並且不允許匯出
7. 導入EAP-TLS的用戶端，有沒有在驗證驗證伺服器的憑證。 這裡一旦停用，對假驗證伺服器的抵抗力就消失了
8. 伺服器憑證的錯誤，使用者是不是按「繼續」就能跨過去。 自家網站要設定HSTS。不要放著公司內部系統的憑證錯誤不管，讓使用者學會「錯誤就是按下去往前走」
9. 有沒有盤點受信任的根憑證授權單位存放區的內容。 放在那裡面的東西，正是那台終端裝置宣告「只要是這個憑證授權單位核發的憑證就視為真品」的對象本身
10. 核准工作流程的核准者，手上有沒有判斷材料。以及事後有沒有檢視核准結果。 定期以清單確認寄給公司外部網域、免費信箱的共用
11. 有沒有刪除已廢止路徑的設定。 VLAN介面、過濾規則、SSID、允許清單的項目。要比照「新導入」的工作，也給刪除的工作訂出期限

結語 ── 要寫的不是對策清單，而是路徑清單

如果說問1問的是「要擋下哪一種攻擊的哪一個階段」，那麼問2問的就是「那項對策守護的是哪一個範圍」。

資訊外洩防範軟體管到業務PC為止，禁止攜入管到辦公室為止，MAC位址過濾管到不會偽造的對象為止。而來源IP位址限制所允許的，是所有從同一個公用IP位址出去的人。逐一確認每項對策的範圍，銜接處的縫隙就會浮現出來。

M公司是在前一年事件之後持續推進對策的公司。即便如此仍留有破口，並不是承辦人員不夠努力，而是因為只靠一項一項增加對策，很難找出範圍之間的縫隙。像Y先生與S先生那樣，把公司外的攻擊者與員工分開，逐一確認通往檔案的到達路徑，才是希望帶回實務中的讀法。

出處以及引用、摘要的範圍

本文探討的是下面這道題目。

出處：2023年度(令和5年度) 秋期 資訊處理安全確保支援士考試 下午 問2

IPA表示，對於其公開的歷屆考試題目，除法令另有特別規定的情況外，不需要取得許可或支付使用費。但這並不代表放棄著作權，IPA要求以「年度、期別、考試類別、時段類別、題號等」的格式明確標示出處；若對題目內容有部分改動，也必須明確標示這一點¹³。

本文沒有原樣轉載題本中刊載的圖表，而是在說明機制所需的範圍內，換成了本公司自行繪製的簡化圖與摘要。設問文與解答範例也以摘要處理。題本、解答範例、評分講評的原文都可以從IPA的頁面免費下載，建議對照著閱讀^{1 2 5}。

用於把題本與本文對照的對應表

相關諮詢領域

合同會社小村軟體處理以既有網路與終端裝置架構為前提的設計審查，以及Windows環境中憑證發布、金鑰保護的實作。

• 技術諮詢・設計審查
• Windows開發
• 不具合調查・原因分析
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

已經禁止連接USB隨身碟，也禁止儲存到本機磁碟，為什麼還是能把檔案帶出去？

因為被禁止的只是公司配發的業務PC的功能，而不是通往檔案所在位置的路徑。這道題目中員工使用的是自己的個人自有PC。完全不碰業務PC，把個人自有PC連接到會議室的無線區域網路，用自己的使用者ID登入雲端儲存空間(B服務)下載檔案，再把這台個人自有PC整台帶走。安裝在業務PC上的資訊外洩防範軟體的設定，對個人自有PC完全不起作用。M公司雖然禁止攜入個人自有PC，但禁止的只有辦公室，會議室不在此限。就算把手段(USB隨身碟、郵件附加檔案、網頁郵件)一一堵住，只要還留有能到達檔案的路徑，帶出檔案就會成立。

B服務限制為「只能從M公司的公用IP位址登入」。為什麼還能從來賓用無線區域網路溜出去？

因為來賓用無線區域網路的通訊也要經過同一台防火牆的NAT，轉換成同一個公用IP位址之後才會出向網際網路。從B服務的角度來看，來自公司內部業務PC的存取，和在會議室連接來賓用無線區域網路的個人自有PC的存取，看到的都是同一個來源IP位址，無法區分。必須這樣理解來源IP位址限制：它不是「只允許這台終端裝置」，而是「允許共用這個出口的所有人」。來賓用Wi-Fi、據點間VPN、遠距辦公用的集中閘道等等，只要是從同一個公用IP位址出去的，全都落在允許範圍之內。

員工用無線區域網路設有MAC位址過濾。這不能算是對策嗎？

不能。因為MAC位址可以在終端裝置端自由改寫。這道題目的方法1，就是把個人自有PC無線網路介面的MAC位址，改成已登錄的業務PC的MAC位址，再拿去連線。無線區域網路的訊框中所帶的MAC位址是未加密傳送的，只要在附近接收電波，也能得知已登錄的MAC位址。同樣的道理也適用於停用SSID廣播：即使停用SSID通知，終端裝置連線時的交握過程也會洩漏SSID。MAC位址過濾與停用SSID廣播，雖然有減少誤連線的效果，但並不是能夠阻止蓄意連線的驗證機制。

就算準備了假的存取點與假網站，為什麼還能說員工不會上當？

因為只要是以HTTPS連線，假網站就無法通過伺服器憑證的驗證。題目的圖2列舉了此時瀏覽器可能顯示的錯誤詳情，共4項：不是由受信任的憑證授權單位所核發的、憑證上記載的伺服器名稱與連線目標的伺服器名稱不同、已被撤銷、已過有效期限。攻擊者拿不到B服務網域名稱對應的正規憑證，所以如果使用自我簽署憑證，會在第一項不合格；如果使用為自己網域正規取得的憑證，會在第二項不合格。根據IPA的評分講評，考查這項驗證內容的設問正答率偏低。此外，這4個項目的可靠程度並不相同。真正擋下攻擊的是前兩項(核發單位與名稱)以及有效期限，這些是瀏覽器必定會驗證的項目。另一方面，撤銷確認則取決於實作與設定。舉例來說，Chrome通常不會進行線上的OCSP或CRL查詢，而是採用一份名為CRLSet的有限清單，其主要目的是緊急封鎖。請不要以為「只要撤銷就一定能擋下」。此外，如果業務PC上配發了公司內部憑證授權單位的根憑證，而該單位的私密金鑰或核發程序被攻擊者掌握，那麼第一項檢查也會被通過。

如果把網址誤打成「http://」會發生什麼事？HSTS做的是什麼？

瀏覽器會先把HTTP替換成HTTPS之後才連線，所以結果同樣會出現伺服器憑證錯誤。HSTS是這樣一種機制：瀏覽器會記住先前以HTTPS連線該網站時收到的標頭內容。RFC 6797要求，當目標主機的URL中含有http配置時，使用者代理程式要將其替換為https；如果明確指定了通訊埠80，則轉換為443。也就是說，明文的HTTP請求在送出到網路之前就已經消失。更重要的是，當與已啟用HSTS的主機通訊時，如果憑證驗證失敗，無論是屬於警告等級還是致命等級，都要求切斷連線。規範中明確寫明，不得向使用者提供「這個連線不安全，是否仍要繼續」之類的選項。不過HSTS有一個前提：這個瀏覽器必須曾經以HTTPS成功抵達過正規網站並收到過該標頭。如果是一台全新的終端裝置，第一次存取就直接連到假網站，HSTS就不起作用。填補這個「第一次」空白的，就是內建在瀏覽器裡的預先載入清單(preload list)。

把用戶端憑證的私密金鑰儲存到TPM，會有什麼變化？

私密金鑰將無法從那台業務PC取出。以檔案形式放在終端裝置上的私密金鑰，只要複製到個人自有PC，那台PC就能以業務PC的身分通過驗證。如果在TPM內部產生金鑰、並設為無法匯出，那麼簽章等運算都只會在TPM內部進行，金鑰本身不會交給作業系統，也不會交給惡意軟體。結果就是，能透過EAP-TLS通過驗證的，就只剩下公司配發的業務PC。這道題目中S先生之所以能說「用這種儲存方式就沒問題」，原因正在於此。若在Windows上實作，需要在憑證範本的金鑰儲存提供者中指定Microsoft Platform Crypto Provider，並設定為不允許匯出私密金鑰。不過TPM所守護的僅止於「金鑰不會被複製到其他終端裝置」這一點，持有該終端裝置的人依然能夠使用它。針對終端裝置的遺失、遭竊，還需要另外準備磁碟機加密與憑證撤銷的做法。

從這道題目該帶回實務中的是什麼？

有4點。第一，帶出對策要按路徑而不是按手段來思考。USB隨身碟、郵件附加檔案、網頁郵件即使一一堵住，只要還留有能到達檔案的終端裝置，就沒有意義。第二，把來源IP位址限制實際允許的範圍寫出來看看。如果來賓Wi-Fi或VPN使用同一個出口，那裡也在允許範圍之內。第三，把無線區域網路的驗證改成依終端裝置區分的認證資訊。預先共用金鑰是所有人持有同一把金鑰的共用秘密，一人外洩，所有人的就都跟著外洩。改成EAP-TLS加用戶端憑證，並且私密金鑰不從TPM取出的架構，認證資訊就會固定在終端裝置上。第四，刪除不再使用的設定。這道題目的最後一個設問，要求把廢止來賓用無線區域網路之後殘留的VLAN介面設定與防火牆過濾規則全部列出來，根據IPA的評分講評，這一題的正答率很高，但在實務中真正能做到這個地步的組織並不多。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。