情報処理安全確保支援士 令和5年秋 午後問2解説 ── 来客用Wi-Fiから持ち出されるファイル

USBメモリの接続を禁止した。ローカルディスクへのファイル保存も禁止した。会社が許可していないWebメールとクラウドストレージへの通信は遮断した。電子メールへのファイル添付も禁止した。社内ファイルサーバは廃止した。

それでも、業務用ファイルは持ち出せます。

情報処理安全確保支援士試験 令和5年度 秋期 午後 問2は、これだけの対策を実施済みのアパレル業M社を舞台に、まだ残っている穴を洗い出す問題です¹。この記事は前回の問1(格納型XSS)の解説に続くシリーズの2本目で、扱う範囲がWebアプリケーションから社内ネットワークと端末認証へ移ります。

問1が「Webアプリに並べた対策が、どこですり抜けられたか」を問う問題だったのに対して、問2は「対策の設計が、どの範囲を守るつもりだったのか」を問う問題です。M社の対策はどれも間違っていません。ただ、守る範囲の指定を一つずつ確認すると、そのすぐ外側が空いています。

この記事で得られるものは、各設問の解答例とその根拠に加えて、無線LAN・サーバ証明書・送信元IPアドレス制限という3つの領域について、実務でそのまま使える確認観点です。試験対策で読む方は設問ごとのセクションを、実務の観点だけが必要な方は11章と12章から読んでも意味が通るように書いています。

1．まず結論

• 抜け道は会議室だった。M社は個人所有PCの持込みを禁止していたが、禁止していたのは執務室だけで、会議室は対象外。会議室には従業員用無線LANと来客用無線LANの両方が飛んでいる
• 従業員による持出しの経路は2つ。MACアドレスを詐称して従業員用無線LANに繋ぐ方法と、来客用無線LANに繋ぐだけの方法。後者のほうがはるかに簡単で、必要なのは来客に配っている事前共有キーだけ
• クラウドストレージ(Bサービス)は「M社のグローバルIPアドレスからだけログイン可能」に制限していた。しかし来客用無線LANの通信も同じNATで同じグローバルIPアドレスに変換されるため、この制限は素通りする。送信元IPアドレスによる制限は、端末ではなく出口を共有している全員を許可する設定である
• 社外の攻撃者による偽AP+偽サイトは、サーバ証明書の検証で止まる。効いているのは「信頼された認証局が発行したものか」と「証明書のサーバ名が接続先と一致するか」の2点。IPAの採点講評によれば、この2点を答えさせる設問の正答率は低かった
• http:// と打ち間違えても、HSTSがHTTPSに置き換えてから接続するので、やはり証明書エラーになる。しかもHSTSが有効なホストでは、警告を無視して先へ進む選択肢を利用者に出してはならない
• 正規のファイル共有機能も持出し経路になる。外部共有者のメールアドレスに自分の私用アドレスを指定すればよい。上長承認はあったが、宛先を確認していない上長がいた
• 対策の柱は3つ。従業員用無線LANをEAP-TLSにして端末ごとのクライアント証明書で認証し、秘密鍵はTPMに入れて業務PCから取り出せなくする。来客用無線LANはM社のネットワークから切り離す(または出口のグローバルIPアドレスを分ける)。そして使わなくなったVLAN・フィルタリングルール・SSIDを消す

2．題材について ── 出典と、この記事での扱い

取り上げるのは次の問題です。

出典：令和5年度 秋期 情報処理安全確保支援士試験 午後 問2

IPAは、公表している過去の試験問題について、法令に特別の定めがある場合を除き許諾や使用料は必要ないとしています。ただし著作権を放棄しているわけではなく、出典を「年度、期、試験区分、時間区分、問番号等」の形式で明記すること、問題の一部を改変している場合はその旨も明記することを求めています²。

この記事では、問題冊子に掲載された図表をそのまま転載していません。仕組みの説明に必要な範囲で、当社が書き起こした簡略図と要約に置き換えています。設問文と解答例も要約して扱います。問題冊子・解答例・採点講評の原文はIPAのページから無償でダウンロードできますので、手元に開きながら読むことをおすすめします^{1 3 4}。

設問と本記事の対応

解きたい設問のところから読み始めても構いません。

問題冊子の記述と、本記事での扱い

原文と照らし合わせられるよう、どこをどう扱ったかをまとめます。

3．問題の舞台 ── M社が「すでにやっていたこと」

M社は、L社の子会社で、アパレル業を手掛ける従業員100名の会社です。オフィスビルは人通りの多い都内の大通りに面しています。この一文が、後で効いてきます。

前年、M社の従業員が社内ファイルサーバに保存していた秘密情報の商品デザインファイルをUSBメモリに保存し、競合他社に持ち込むという事件が起きました。親会社であるL社からの指導で、セキュリティ対策の見直しが進んでいます。すでに実施済みの見直しは次の3つです。

• 従業員に貸与するノートPC(以下、業務PC)に情報漏えい対策ソフトを導入し、USBメモリなど外部記憶媒体の接続禁止、ソフトウェアのインストールを除くローカルディスクへのファイル保存禁止、会社が許可していないWebメールおよびクラウドストレージへの通信遮断、会社が許可していないソフトウェアのインストール禁止、電子メール送信時のファイル添付禁止、を設定した
• 業務用ファイルの保存場所を、以前から使っていたクラウドストレージ(以下、Bサービス)の1か所にまとめ、設定を見直した
• 社内ファイルサーバを廃止した

前回の事件が「社内ファイルサーバ」→「USBメモリ」という経路だったので、その経路の両端を潰した形です。筋は通っています。

ネットワークの構成

オフィスビルには執務室と会議室があります。執務室では従業員用無線LANが使え、会議室では従業員用と来客用の両方が使えます。会議室のプロジェクターは、来客持込端末(来客が持ち込むPC・タブレット・スマートフォン)または業務PCを来客用無線LANに接続して利用します。

説明に必要な範囲だけを図にすると、次の形です。

flowchart LR
    subgraph M["M社の社内ネットワーク"]
        direction TB
        G["来客用無線LAN<br/>192.168.10.0/24<br/>(会議室のAPだけ)"]
        E["従業員用無線LAN<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["インターネット"]

押さえておくべき仕様は次のとおりです。

そして、セキュリティルールが3つ。業務PCの社外への持出しは禁止、個人所有のPC・タブレット・スマートフォンなどの執務室への持込みは禁止、業務用ファイルの社外への持出しはBサービスのファイル共有機能以外の方法では禁止。

2つ目のルールに「執務室への」と書いてあることに気付いたでしょうか。会議室は書かれていません。

この問題の進み方

情報システム部のYさんが、親会社L社の情報処理安全確保支援士(登録セキスペ)であるS氏の支援を受けながら、Bサービスからのファイル持出しについて対策が十分かを確認していきます。2人は社外の攻撃者による持出しと従業員による持出しを分けて検討します。設問1が前者、設問2が後者、設問3が対策の立案です。

4．偽Wi-Fiと偽サイト ── 設問1(1)(2)

まずYさんが挙げるのは、来客用無線LANを利用したことのある来客者が、攻撃者としてM社の近くから来客用無線LANに接続し、Bサービスにアクセスする、というシナリオです。

このシナリオが成立してしまう理由は、無線LANの認証方式がWPA2-PSKだからです。PSK(Pre-Shared Key、事前共有キー)は、その名のとおり全員が同じ鍵を共有する方式です。来客用無線LANの事前共有キーは、来客に教えるためのものです。一度教えてしまえば、その人が今後も知っているという状態を取り消す手段はありません(全員分を変えるほかありません)。しかもオフィスビルは人通りの多い大通りに面しているので、建物の外からでも電波は届きます。

これに対するS氏の回答は明快です。Bサービスにログインするには [a] 利用者ID と [b] パスワード が必要である、と。これが設問1(1)の解答例(順不同)です。無線LANに繋げること自体は、Bサービスへのログインを意味しません。

偽APと偽サイト

そこでYさんは、もう一段踏み込んだシナリオを出します。来客用無線LANのAPと同じ設定の偽APと、Bサービスと同じURLの偽サイトを用意し、DNSの設定を細工して、利用者IDとパスワードを盗む方法はどうか。偽APをM社の近くに置けば、M社の従業員が業務PCを誤って偽APに接続し、Bサービスにアクセスしようとして偽サイトにアクセスし、ログインしてしまうかもしれない、というものです。

いわゆるevil twin(悪魔の双子)です。来客用無線LANと同じSSID・同じ事前共有キーでAPを立てれば、端末から見て正規のAPと区別がつきません。WPA2-PSKで端末がAPについて確かめられるのは「同じ事前共有キーを知っていること」だけだからです。鍵を知らないAPは接続手順を完了できませんが、逆に言えば、鍵を知っている者は誰でも「本物のAP」になれます。来客に配る鍵である以上、それは攻撃者にも配られていると考えるべきです。

S氏の答えは、ここでも明快です。従業員がHTTPSで偽サイトにアクセスしようとすると、安全な接続ではない旨のエラーメッセージとともに、偽サイトに使われたサーバ証明書に応じて、次の4項目のうち1つ以上がWebブラウザに表示されます。

• このサーバ証明書は、信頼された認証局から発行されたサーバ証明書ではない(空欄c)
• このサーバ証明書に記載されているサーバ名は、接続先のサーバ名と異なる(空欄d)
• このサーバ証明書は、失効している
• このサーバ証明書は、有効期限が切れている

このうち下2つは問題冊子に最初から書かれており、上2つ(空欄c・d、それぞれ40字以内・順不同)を答えるのが設問1(2)です。

sequenceDiagram
    autonumber
    participant U as 従業員の業務PC
    participant F as 偽AP・偽サイト<br/>(攻撃者)
    participant B as Bサービス(正規)

    Note over F: 来客用無線LANと同じ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/>そもそも通信していない

証明書の検証は何を見ているのか

採点講評はこの設問について、こう書いています。

設問1(2)は，正答率が低かった。攻撃者が偽サイトを用意したとしても，HTTPS でアクセスするのであれば，サーバ証明書の検証に失敗する。サーバ証明書の検証は，通信の安全性を確保するうえで基本的な知識であるので，具体的にどういった事項を検証するのかということまで含めて，よく理解しておいてほしい。

「証明書エラーが出る」ことは知っていても、何を確認して不合格になっているのかを4項目に分解できる人が少なかった、ということです。図2が挙げる4項目を、それぞれ何のための確認なのかという観点で整理すると次のようになります。

攻撃者から見ると、上の2つが越えられない壁になっています。自己署名の証明書を作れば1つ目で落ち、自分のドメイン(たとえば b-service.example.net)用に無料の証明書を正規に取得しても、接続先はBサービスのドメインなので2つ目で落ちます。Bサービスのドメイン名に対する証明書は、Bサービスのドメインを管理していないと取得できないからです。この2点の組み合わせが、証明書という仕組みの本体だと言ってよいでしょう。

証明書のパス検証の手順はRFC 5280が⁵、証明書に書かれた名前と接続先の名前を照合する手順はRFC 6125が⁶規定しています。

4項目が同じ強さで効くわけではない

ここで、試験の答えと実際のブラウザの挙動を分けておきます。上の4項目は、問題文の図2が「表示されうるエラーの詳細」として挙げているものであって、どのブラウザも4つを同じ確実さで検査すると読んではいけません。

発行元・サーバ名・有効期限の3つは、証明書を受け取った時点で手元の情報だけで判定できるので、必ず検証されます。この問題の攻撃を止めているのもこの3つです。

一方、失効の確認だけは性質が違います。 失効しているかどうかは証明書の中に書かれておらず、別の情報を取りにいく必要があるため、実装と設定に依存します。

• Chromeは、オンラインのOCSPやCRLの確認を通常は行いません。代わりに、緊急時に証明書を素早くブロックすることを主目的とした CRLSet という限定的な一覧を配布しており、CAの失効リストから取り込まれるのはその一部です⁷
• OCSPを問い合わせる実装でも、応答が得られないときに接続を通してしまう(soft-fail)構成が広く使われています

したがって「秘密鍵が漏れたら失効させればよい」を対策の柱にしないでください。失効はやるべきことですが、利用者の全ブラウザで確実に効く仕組みではありません。近年の証明書の有効期間短縮は、失効が当てにならないことへの業界側の答えでもあります。自社で鍵の漏えいを疑ったときは、失効の申請と並行して、証明書の入れ替えと、その鍵で守っていたもの(セッション、APIキーなど)の無効化まで手を打つ必要があります。

実務での落とし穴 ── 「信頼された認証局」は誰が決めているか

ここから先は問題文の外の話です。上の表の1つ目は、その端末が何を信頼しているかに依存します。信頼の一覧はブラウザやOSが持っており、Windowsであれば証明書ストアの「信頼されたルート証明機関」がそれにあたります。

つまり、次のような状況では1つ目のチェックは通ってしまいます。

• 社内の認証局(プライベートCA)のルート証明書を、業務PCに配布している。そのCAの秘密鍵、あるいは証明書の発行手続きが攻撃者に押さえられた
• 通信内容を検査するプロキシやセキュリティ製品が、TLSを終端するために自前のルート証明書を端末に入れている。その製品や運用が攻撃者に押さえられた
• 「証明書エラーが出るから」という理由で、過去に誰かが例外を登録した、あるいは自己署名証明書を信頼されたルートに入れた

3つ目は現場で本当によく見ます。社内システムの証明書エラーを消すために一度手で入れたものが、退職者のPCから引き継がれたイメージに残り続ける、といった形です。信頼されたルート証明機関ストアの中身は、その端末が誰を信じるかの宣言そのものなので、棚卸しの対象にしてください。どのストアに何を入れるべきかという判断は、Windows証明書ストア実務ガイドで整理しています。

2つ目のチェック(サーバ名の一致)については、実務での注意点が別にあります。利用者がドメイン名を見間違える攻撃には、証明書は無力です。攻撃者が b-serv1ce.example.com のような紛らわしいドメインを取得し、そのドメイン用に正規の証明書を取得していれば、ブラウザはエラーを出しません。証明書が保証しているのは「接続先のサーバ名と証明書のサーバ名が一致していること」であって、「そのサーバ名が利用者の意図した相手であること」ではありません。この最後の一歩を利用者の目視に頼らない仕組みが、パスキー(WebAuthn)のようにオリジンを認証器側で検証する方式です。詳しくはパスキーはなぜ安全なのかで扱っています。

5．http:// と打ってしまっても止まる理由 ── 設問1(3)

Yさんは食い下がります。偽APに接続した状態で、従業員がWebブラウザにBサービスのURLを入力する際、誤って http:// と入力してしまった場合は、エラーメッセージが表示されないのではないか、と。

もっともな疑問です。HTTPで接続するなら、そもそもサーバ証明書は登場しません。偽サイトは何のエラーも出さずにログイン画面を表示できてしまいそうです。

S氏の答えは「大丈夫です。HSTSを有効にしてあるので、その場合でも先ほどと同じエラーメッセージが表示されます」。設問1(3)は、このエラーメッセージが表示される直前までのWebブラウザの動きを60字以内で問います。

解答例は「HTTPのアクセスをHTTPSのアクセスに置き換えてアクセスする。その後、偽サイトからサーバ証明書を受け取る」です。

ブラウザの中で何が起きているか

HSTS(HTTP Strict Transport Security)は、サイトが Strict-Transport-Security ヘッダーで「今後このホストには必ずHTTPSで来い」と宣言し、ブラウザがそれを覚えておく仕組みです。RFC 6797が規定しています⁸。

覚えているホストへ http:// でアクセスしようとしたとき、ブラウザは次のように動きます。

1. URLのスキームを http から https に置き換える。ポート80が明示されていれば443に変換する(RFC 6797 8.3節)
2. その結果としてHTTPSで接続する。このとき、DNSは細工されているので接続先は偽サイト
3. 偽サイトからサーバ証明書を受け取る
4. 検証に失敗し、4章と同じエラーになる

重要なのは、1の置き換えがネットワークに出る前に完了していることです。平文のHTTPリクエストはそもそも送信されません。だから「HTTPで接続したから証明書が出てこない」という状況にならないのです。

「無視して進む」が押せない

もう一つ、HSTSには実務上とても大きな性質があります。RFC 6797の8.4節は、HSTSが有効なホストとの安全な通信路の確立中にエラーが起きた場合、それが警告であれ致命的であれ、接続を打ち切ることを求めています。そして12.1節は、その挙動を “No User Recourse”(利用者に回避手段を与えない)と表現し、「この接続は安全ではありませんが続行しますか」といった選択肢を出してはならない、としています。

通常の証明書エラーであれば、多くのブラウザは警告画面に「詳細設定」「続行する」といった導線を用意しています。実務では、社内システムの証明書エラーに慣れきった利用者がこれを反射的に押す、という光景が珍しくありません。HSTSは、その反射を封じます。 偽サイトに対する防御としては、証明書の検証そのものより、この「押せない」ことのほうが効いているとすら言えます。

HSTSの前提 ── 初回だけは守れない

ただし、HSTSには前提があります。RFC 6797の8.1節が定めるとおり、あるホストが「既知のHSTSホスト」になるのは、利用者エージェントが安全な通信路の上で Strict-Transport-Security ヘッダーを受け取ったときです。つまり、そのブラウザが一度は正規のサイトへHTTPSで到達している必要があります。

したがって、次の場合は守られません。

• 新しく配ったばかりの業務PCで、最初のアクセスがいきなり偽APの下で行われた
• ブラウザのプロファイルを作り直した、あるいは閲覧データを消してHSTSの記録も消えた
• 記録の有効期限(max-age)が切れていた

この初回問題を埋めるのが、HSTSプリロードリストです。あらかじめブラウザに組み込まれたドメイン一覧に載っていれば、一度もアクセスしたことがなくてもHTTPSに強制されます。

ただし、自社サイトの登録を検討するなら先に条件を確認してください。登録の要件は次のとおりです⁹。

• 有効な証明書を提供していること
• ポート80で待ち受けているなら、同一ホストでHTTPからHTTPSへリダイレクトすること
• すべてのサブドメインをHTTPSで提供していること(DNSレコードがあるなら www も含む)
• ベースドメインで max-age を 31536000秒(1年)以上、includeSubDomains、preload を付けた Strict-Transport-Security ヘッダーを返すこと

効いてくるのは3つ目と、includeSubDomains の組み合わせです。社内向けの古いサブドメインがHTTP専用だったり、証明書を用意していなかったりすると、登録した瞬間にそれらへ到達できなくなります。 登録前にサブドメインを全部棚卸ししてください。

そして、取り消しは簡単ではありません。 削除の申請は一般に受け付けられますが、変更が利用者のブラウザに届くまでには数か月かかり、Chrome以外のブラウザについては保証がありません⁹。プリロードは「間違えたら戻せばいい」設定ではない、と考えて臨むのが安全です。

逆に利用する側としては、業務で使うクラウドサービスがHSTSに対応しているかは、選定時の確認項目に入れてよい観点です。

6．承認が形骸化した瞬間、共有機能は持出し経路になる ── 設問2(1)

ここから、従業員による持出しの検討に移ります。

S氏はまずファイル共有機能の運用を確認します。上長は宛先のメールアドレスとファイルをちゃんと確認してから承認しているか。Yさんの答えは「確認できていない上長もいるようです」。

そこでS氏が指摘するのが設問2(1)です。M社外からファイルをダウンロード可能にするための、ファイル共有機能の悪用方法を40字以内で具体的に答えます。

解答例は「外部共有者のメールアドレスに自身の私用メールアドレスを指定する」です。

設計は正しく、運用が抜けている

Bサービスのファイル共有機能は、よく考えて作られています。

• 共有には上長の承認が必要
• 外部共有リンクは本人にも上長にも知らされない。共有者本人がリンクを転送して持ち出すことはできない
• リンクは推測困難なランダム文字列を含み、有効期限は1日

とくに2つ目は、内部からの持出しを意識した設計です。それでも破れます。宛先を自分にしてしまえば、「本人に知らされない」リンクが本人の手元に届くからです。

そして、この抜け道が開くための条件は一つだけ、「上長が宛先を確認していないこと」です。承認ワークフローは、承認者が中身を見ることを前提に設計されています。見ていなければ、それは自動化された配送経路にすぎません。

承認が形骸化する条件は決まっている

実務で承認が形骸化するとき、原因はだいたい次のどれかです。

この問題のM社に足りていないのは、主に最後の2つです。承認を通す仕組みを入れたら、承認した結果を後から見る仕組みも要ります。 フリーメールのドメイン宛ての外部共有が月に何件あったかを一覧できるだけで、この手口はかなり見つけやすくなります。

中小企業がどこから手を付けるかという全体像は、IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の歩き方で扱っています。

7．会議室という抜け道 ── 設問2(2)

S氏の次の質問は「会議室には個人所有PCは持ち込めるのでしょうか」。Yさんの答えは「会議室への持込みは禁止していないので、持ち込めます」。

ここで方法1と方法2が出てきます。どちらも、個人所有PCでBサービスからファイルをダウンロードし、その個人所有PCごと持ち出すという筋書きです。業務PCに入れた情報漏えい対策ソフトの設定は、個人所有PCには一切効きません。

方法1 ── MACアドレスの詐称

方法1は、個人所有PCの無線LANインタフェースの [e] MACアドレス を、業務PCの無線LANインタフェースのMACアドレスに変更したうえで、個人所有PCを従業員用無線LANに接続する、というものです。空欄eを答えるのが設問2(2)です。

従業員用無線LANの入口を守っていたのは、WPA2-PSKの事前共有キーと、MACアドレスフィルタリングの2つでした。どちらも従業員には越えられます。

• 事前共有キーは業務PCに設定されているものであり、従業員は業務PCの利用者です。全員で1つの鍵を共有する方式である以上、「利用者は知り得る」と考えるのが前提です
• MACアドレスは端末側で書き換えられます。OSの設定やドライバのプロパティから変更できるのが普通で、特別な道具は要りません。そのうえ無線LANのフレームに載っているMACアドレスは暗号化されないので、近くで電波を受信すれば、登録済みの業務PCのMACアドレスを知ることもできます

MACアドレスフィルタリングとSSIDの非通知は、誤接続を減らす整理整頓としては意味があります。しかし、意図して入ろうとする相手を止める認証の仕組みではありません。この2つを「対策」として数の中に入れていないか、自社の構成でも確認してみてください。

方法2 ── ただ来客用無線LANに繋ぐだけ

方法2はもっと単純です。個人所有PCを来客用無線LANに接続し、Bサービスからファイルをダウンロードし、個人所有PCごと持ち出す。それだけです。

MACアドレスの詐称も要りません。必要なのは来客用無線LANの事前共有キーだけで、これは来客に配っているものです。従業員が知らないはずがありません。

ここで当然、次の疑問が出ます。Bサービスは「M社の従業員に割り当てられた利用者IDでは、M社のグローバルIPアドレスからだけログイン可能」に制限していたはずではないか、と。

送信元IPアドレス制限は、何を許可しているのか

問題文のファイアウォールの設定を読むと、答えが出ています。来客用無線LANからインターネットへ出る通信も、従業員用無線LANからの通信も、同じNATで同じ1つのグローバルIPアドレスに変換されているのです。

Bサービスから見れば、この3つは区別できません。IPアドレスによる制限は素通りします。

この構図は、試験の外でも繰り返し現れます。送信元IPアドレスによる制限は、「この端末からだけ」を意味しません。「このグローバルIPアドレスで出ていく全員から」を意味します。 許可しているつもりの範囲と、実際に許可される範囲がずれる典型例を挙げます。

送信元IPアドレスによる制限が無意味だという話ではありません。制限を1枚だけで使わない、という話です。IPアドレスで絞ったうえで、端末そのものを識別する仕組み(クライアント証明書やデバイス証明書)や、利用者を識別する仕組み(多要素認証)と重ねて初めて、「この端末の、この人が」を表現できます。この問題の対策も、まさにその方向に進みます。

8．端末を証明書で縛る ── 設問3(1)〜(4)

方法1への対策として、M社は従業員用無線LANの認証方式にEAP-TLSを選び、認証サーバを用意することにしました。

設問3(1) ── RADIUS

設問3(1)は、認証サーバがEAPで使うUDP上のプロトコルを問います。解答例は RADIUS です。

構図を整理すると、登場人物は3者です。

業務PCとAPの間は IEEE 802.1X(EAP over LAN)、APと認証サーバの間はRADIUSです。RADIUSはUDP上で動きます¹⁰。EAP-TLSそのものの手順はRFC 5216が規定しています¹¹。Windows Serverで組む場合、認証サーバの役割を担うのはネットワークポリシーサーバー(NPS)です¹²。

WPA2-PSKからEAP-TLSへ移ることで、何が変わるのかを押さえておきましょう。

最後の行は補足が要ります。EAP-TLSでクライアントが証明書を検証する相手は、APではなく認証サーバです。APはEAPのやり取りを中継するオーセンティケータにすぎず、クライアントはAPそのものの身元を確かめているわけではありません。

それでも4章のevil twinへの備えになるのは、認証が成功して初めて生成される鍵材料が、RADIUSの共有秘密を持つ正規のAPにしか渡らないからです。攻撃者が勝手に立てたAPは、その先に正規の認証サーバを持たない限り、この手続きを最後まで進められません。クライアントが直接検証しているのは認証サーバで、APの正当性はそこから間接的に導かれている、という構造になっています。

ただし条件付きです。クライアント側で「どの認証局が発行した、どの名前のサーバ証明書なら信じるか」を設定しておかないと、攻撃者が自前の認証サーバを用意したときに見分けられません。EAP-TLSを入れたのに、クライアントのプロファイルでサーバ証明書の検証を無効にしている、という構成は実際にあります。導入したら、そこまで含めて確認してください。

設問3(2) ── 採点講評が指摘した誤答

Yさんの説明はこう続きます。クライアント証明書はCAサーバを新設して発行し、従業員が自分の業務PCにインストールするのではなく、ディレクトリサーバの機能で業務PCに格納する。そして、クライアント証明書に対応する [f] は [g] しておくために業務PCのTPMに格納して保護する、と。

設問3(2)は空欄fを問います。解答例は 秘密鍵 です。

採点講評はこう書いています。

設問3(2)は，正答率がやや高かったが，”公開鍵”や”サーバ証明書”といった解答が一部に見られた。PKI は，様々なセキュリティ技術の基礎となる重要な技術であるので，どのような場面でどのように利用されているのか，よく理解しておいてほしい。

公開鍵は、証明書の中に入って世界中に配られるものです。守る対象になりません。守らなければならないのは、その証明書の持ち主だけが持っているはずの秘密鍵です。「クライアント証明書で認証する」とは、正確には「証明書に入っている公開鍵に対応する秘密鍵を持っていることを、その鍵で署名してみせることで証明する」ことです。だから秘密鍵を複製できてしまえば、証明書による認証は意味を失います。

TPMに入れると何が変わるのか ── 設問3(3)

設問3(3)は空欄gを20字以内で問います。解答例は「業務PCから取り出せないように」です。

秘密鍵をファイルとして端末に置いた場合、それはコピーできるデータです。個人所有PCにコピーすれば、その個人所有PCが業務PCとして認証を通ります。方法1(MACアドレスの詐称)を潰したつもりが、「証明書の詐称」に置き換わるだけです。

TPMは、鍵をその中で生成し、外へ取り出せない状態で保持できます。署名などの演算はTPMの中で行われ、鍵そのものはOSにもアプリケーションにもマルウェアにも渡りません。結果として、その秘密鍵はその1台の物理的な部品に固定されます。

Windowsで実装する場合、証明書テンプレートのキーストレージプロバイダー(KSP)に Microsoft Platform Crypto Provider を指定します。このプロバイダーはTPMを使って鍵を保護するもので、証明書テンプレート側で「秘密キーのエクスポートを許可する」にチェックが入っていると選択できません¹³。エクスポートできてしまうなら保護する意味がない、という当然の制約です。

TPMという部品の役割そのものについては、BitLocker実務ガイドでドライブ暗号化の文脈から扱っています。「秘密鍵をデバイスの外に出さない」という考え方は、パスキーはなぜ安全なのかで説明している認証器の設計と同じ発想です。

なぜ「問題ない」と言えるのか ── 設問3(4)

Yさんの説明を聞いたS氏は「その格納方法であれば問題ないと思います」と応じます。設問3(4)は、その理由を40字以内で問います。

解答例は「EAP-TLSに必要な認証情報は、業務PCにしか格納できないから」です。

流れを追うとこうなります。

1. クライアント証明書は、従業員が自分でインストールするのではなく、ディレクトリサーバの機能で業務PCに配られる。従業員の手を経由しない
2. 秘密鍵はTPMの中にあり、業務PCから取り出せない
3. したがって、EAP-TLSで従業員用無線LANに接続できるのは、会社が配った業務PCだけになる
4. 個人所有PCは、MACアドレスを詐称しても認証を通せない。方法1は封じられる

「その格納方法であれば」という条件付きの言い方に注意してください。もし秘密鍵をファイルとして業務PCに置いていたら、S氏は問題ないとは言わなかったはずです。同じ「クライアント証明書による認証」でも、秘密鍵の置き方で守れる範囲が変わります。

TPMが守らないもの

一方で、TPMに入れれば安心という話ではありません。TPMが保証するのは「その鍵が他の端末へ複製されないこと」だけです。次のことは守りません。

• 端末そのものを持ち出された場合。 業務PCを持ち出せば、TPMごと持ち出したことになります。M社のルールでは業務PCの社外への持出しは禁止ですが、ルールと技術的な強制は別です。ドライブの暗号化(起動前認証を含む)と、紛失時に証明書を失効させる運用が別に要ります
• 利用者のなりすまし。 TPMは端末を識別しますが、その端末を操作している人が誰かは保証しません。利用者の認証は別途必要です
• 端末上で動くマルウェア。 秘密鍵は読み出せませんが、その端末で動くコードは「TPMに署名を依頼する」ことはできます。鍵の複製は防げても、その端末が乗っ取られている間の悪用は防げません

9．出口のIPアドレスを分ける ── 設問3(5)

方法2(来客用無線LANに繋ぐだけ)への対策として、M社は2案を検討します。FWのNATの設定を変更する案と、無線LANサービス(Dサービス)を利用する案です。

設問3(5)は、前者の変更内容を70字以内で問います。解答例は「来客用無線LANからインターネットにアクセスする場合の送信元IPアドレスを、現在使っているグローバルIPアドレスとは別のIPアドレスにする」という趣旨のものです(問題文ではそのグローバルIPアドレスを a1.b1.c1.d1 と表記しています)。

7章で見たとおり、方法2が成立するのは来客用無線LANの通信が従業員と同じグローバルIPアドレスで出ていくからでした。ならば、来客用無線LANだけ別のグローバルIPアドレスに変換すればよい。Bサービス側のIPアドレス制限は変えずに、来客用無線LANからのアクセスだけがそこから外れます。

これが成立するのは、M社のWAN側に複数のグローバルIPアドレスが割り当てられているからです。問題文のFWのインタフェース設定を読むと、WAN側のサブネットマスクは255.255.255.248、つまり/29で、使えるアドレスが1つではないことが分かります。問題文の表を細かく読ませる、地味ですが確実な伏線です。

自社で同じ手を打てるかどうかは、契約している回線でグローバルIPアドレスを複数使えるかに依存します。1つしかないなら、この案は取れません。その場合は次章の分離案になります。

10．使わなくなった設定を消すまでが対策 ── 設問3(6)(7)

検討の結果、M社はDサービスを利用することにしました。

• 会議室に、Dサービスから貸与された無線LANルータ(Dルータ)を設置する
• Dルータでは、DHCPサーバ機能とDNSキャッシュサーバ機能を有効にする
• 来客持込端末は、M社のネットワークを経由せずに、Dルータに搭載されたSIMを使ってインターネットに接続する
• プロジェクターは来客用無線LANを使わず、HDMIケーブルで接続する方法に変更する

flowchart LR
    subgraph M["M社の社内ネットワーク(対策後)"]
        direction TB
        E["従業員用無線LAN<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["インターネット"]

来客用のネットワークが、M社のネットワークから物理的にも論理的にも切り離されました。同じグローバルIPアドレスで出ていくこともありません。

設問3(6) ── 不要になる通信

来客持込端末がM社のネットワークを使わなくなると、今まで必要だったDHCPサーバと [h] サーバへの通信が不要になります。空欄hの解答例は DNS です。

Dルータ自身がDHCPサーバ機能とDNSキャッシュサーバ機能を持つので、来客持込端末はM社のサーバネットワークにあるDHCPサーバ・DNSサーバを使う必要がなくなります。問題文の説明を読み返せば、そのまま書いてあります。

設問3(7) ── 消すべき設定を全部挙げる

設問3(7)は、この変更に伴ってFWのVLANインタフェース設定とフィルタリング設定から削除すべき項番を、それぞれ全部答えさせます。

解答は、VLANインタフェース設定からは来客用無線LANのVLAN(項番1)、フィルタリング設定からは来客用無線LANからインターネットへのHTTP/HTTPSを許可するルール(項番1)と、来客用無線LANからサーバネットワークのDNSへのアクセスを許可するルール(項番4)の2つです。あわせて、APの設定からは来客用SSIDの設定を削除します。

採点講評はこう書いています。

設問3(7)は，正答率が高かった。ファイアウォールの全てのフィルタリング設定と無線LAN 環境の見直しに伴う影響を理解して解答する必要があったが，適切に理解されていた。

正答率が高かった設問ですが、実務でここまでやり切れている組織は多くありません。 新しい仕組みを入れる作業には予算も期日も付きますが、古い設定を消す作業には付きません。そして消し忘れは、次のような形で表に出てきます。

この問題のファイアウォールは、項番の小さいルールから順に評価し、最初に合致したルールを適用する方式です(問題文にそう明記されています)。この方式では、使わなくなった許可ルールを上のほうに残しておくことは、末尾の拒否ルールに届かせないための穴を空けたままにしておくのと同じことになります。

ただし、この評価方式をすべてのファイアウォールに一般化しないでください。 製品によって決め方が違います。

どの方式であっても、使わない許可を残しておくのが危険であること自体は変わりません。変わるのは「なぜ危険か」と「どう直すか」です。自社の機器がどの方式かを確認したうえで、定期的な棚卸しの対象に「今も送信元・宛先が存在するか」という観点を入れてください。

業務アプリの側で必要な受信規則をどう管理するかという、ホスト側のファイアウォールの話はWindowsファイアウォールと業務アプリで扱っています。

11．効かなかった対策と、効いた対策

この問題を1枚にまとめると、次の表になります。M社が持っていた対策と、それがどこで越えられたかの対応です。

最後の1行だけが「効いた」です。そして、対策として立案されたものを並べると次のようになります。

見比べると、性格の違いがはっきりします。越えられた対策は「手段」を禁止するものが多く、効いた対策と立案された対策は「経路」や「資格情報の性質」を変えるものです。USBメモリを塞いでもファイルへの経路が残っていれば持出しは成立し、事前共有キーを長くしても共有秘密であることは変わりません。

12．実務のチェック観点

この問題を自社の構成に当てはめるときの確認項目を挙げます。

1. 持出し対策を、手段ではなく経路で書き出せるか。 USBメモリ・メール添付・Webメールという手段の一覧ではなく、「業務ファイルに到達できる端末とネットワークの一覧」を作る。管理外の端末が到達できる経路が1本でもあれば、手段の禁止は迂回される
2. 持込み・持出しのルールが、場所を限定していないか。 「執務室への持込み禁止」は、会議室・受付・共用スペースを許可している。物理的な区画とネットワークの区画が一致しているかを確認する
3. 送信元IPアドレス制限が、実際に許可している範囲を言えるか。 そのグローバルIPアドレスで出ていくものを全部数える。ゲスト用Wi-Fi、来客用ネットワーク、拠点間VPN、テレワークの集約ゲートウェイ、検証環境
4. 無線LANの資格情報が、端末ごとになっているか。 事前共有キーは全員が同じものを持つ共有秘密で、一人が漏らせば全員分が漏れ、特定の1台だけを止めることもできない
5. MACアドレスフィルタリングとSSID非通知を、対策の数に入れていないか。 どちらも誤接続を減らす整理であって、認証ではない
6. クライアント証明書の秘密鍵が、端末から取り出せない状態か。 ファイルとして置いた秘密鍵は複製できる。TPMを使うキーストレージプロバイダーを指定し、エクスポートを許可しない
7. EAP-TLSを入れたクライアントが、認証サーバの証明書を検証しているか。 ここを無効にすると、偽の認証サーバに対する耐性が失われる
8. サーバ証明書のエラーを、利用者が「続行」で越えられる状態になっていないか。 自社サイトにはHSTSを設定する。社内システムの証明書エラーを放置して、利用者に「エラーは押して進むもの」と学習させない
9. 信頼されたルート証明機関ストアの中身を棚卸ししているか。 そこに入っているものは、その端末が「この認証局が発行した証明書なら本物とみなす」と宣言している相手そのものである
10. 承認ワークフローの承認者に、判断材料が渡っているか。そして承認結果を後から見ているか。 社外ドメイン宛て・フリーメール宛ての共有を定期的に一覧で確認する
11. 廃止した経路の設定を消しているか。 VLANインタフェース、フィルタリングルール、SSID、許可リストのエントリ。「新しく入れる」作業と同じ扱いで、消す作業にも期日を付ける

おわりに ── 「範囲」を書いていない対策は守らない

問1が「その対策は、どの攻撃の、どの段階を止めるのか」を問う問題だったとすれば、問2が問うているのは「その対策は、どの範囲を守るのか」です。

M社の対策には、どれにも暗黙の範囲がありました。情報漏えい対策ソフトの範囲は業務PCまで。持込み禁止の範囲は執務室まで。MACアドレスフィルタリングの範囲は「詐称しない相手」まで。送信元IPアドレス制限の範囲は「そのグローバルIPアドレスで出ていく全員」まで。それぞれの範囲は正しく機能していて、ただ、隣とのつなぎ目が空いていました。

この問題が実務的なのは、M社が真面目に対策していた会社として描かれている点です。前年の事件を受けて、経路の両端を潰し、専用のソフトまで入れています。それでも穴が残るのは、担当者が怠けていたからではなく、対策を一つずつ足していくやり方では範囲の隙間が見えないからです。

隙間を見つけるには、対策の一覧ではなく経路の一覧を書くしかありません。この問題のYさんとS氏がやっていたのは、まさにそれです。「社外の攻撃者」と「従業員」に分け、それぞれについて到達経路を1本ずつ潰していく。IPAが出題趣旨に書いた「無線LANを使った環境における脅威を様々な角度から想定する能力」とは、この作業のことでしょう。

関連する相談領域

合同会社小村ソフトでは、既存のネットワークや端末構成を前提にした設計レビューと、Windows環境での証明書配布・鍵保護の実装を扱っています。

• 技術相談・設計レビュー
• Windows開発
• 不具合調査・原因解析
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

USBメモリの接続を禁止し、ローカルディスクへの保存も禁止したのに、なぜファイルを持ち出せるのですか。

禁止したのは会社が貸与した業務PCの機能であって、ファイルが置いてある場所への到達経路ではないからです。この問題で従業員が使うのは、自分の個人所有PCです。業務PCを一切触らず、個人所有PCを会議室の無線LANに接続し、クラウドストレージ(Bサービス)へ自分の利用者IDでログインしてファイルをダウンロードし、その個人所有PCごと持ち帰ります。業務PCに入れた情報漏えい対策ソフトの設定は、個人所有PCには一切効きません。M社は個人所有PCの持込みを禁止していましたが、禁止していたのは執務室だけで、会議室は対象外でした。手段(USBメモリ、メール添付、Webメール)を一つずつ塞いでも、ファイルに到達できる経路が残っていれば持出しは成立します。

Bサービスは「M社のグローバルIPアドレスからだけログイン可能」に制限していました。なぜ来客用無線LANから抜けられるのですか。

来客用無線LANの通信も、同じファイアウォールのNATを通って、同じグローバルIPアドレスに変換されてからインターネットへ出ていくからです。Bサービスから見ると、社内の業務PCからのアクセスと、会議室で来客用無線LANに繋いだ個人所有PCからのアクセスは、どちらも同じ送信元IPアドレスに見えます。区別できません。送信元IPアドレスによる制限は「この端末からだけ」ではなく「この出口を共有している全員」を許可する設定である、と理解する必要があります。ゲスト用Wi-Fi、拠点間VPN、テレワーク用の集約ゲートウェイなど、同じグローバルIPアドレスで出ていくものはすべて許可範囲に入ります。

従業員用無線LANにはMACアドレスフィルタリングがかかっていました。これは対策になりませんか。

なりません。MACアドレスは端末側で自由に書き換えられるからです。この問題の方法1は、個人所有PCの無線LANインタフェースのMACアドレスを、登録済みの業務PCのMACアドレスに変更して接続する、というものでした。無線LANのフレームのMACアドレスは暗号化されずに飛んでいるので、近くで受信すれば登録済みのMACアドレスを知ることもできます。同じことがSSIDの非通知にも言えます。SSID通知を無効にしても、端末が接続するときのやり取りからSSIDは判明します。MACアドレスフィルタリングとSSID非通知は、間違えて接続してしまう事故を減らす効果はあっても、意図的な接続を止める認証の仕組みではありません。

偽のアクセスポイントと偽サイトを用意されても、なぜ従業員は騙されないと言えるのですか。

HTTPSで接続する以上、偽サイトはサーバ証明書の検証を通せないからです。問題文の図2は、このとき表示されうるエラーの詳細として4項目を挙げています。信頼された認証局から発行されたものではない、証明書に書かれたサーバ名が接続先のサーバ名と異なる、失効している、有効期限が切れている、の4つです。攻撃者はBサービスのドメイン名に対する正規の証明書を入手できないので、自己署名の証明書を使えば1つ目で、自分のドメイン用に正規に取得した証明書を使えば2つ目で不合格になります。IPAの採点講評によれば、この検証内容を問う設問の正答率は低かったとのことです。なお、この4項目が同じ強さで効くわけではありません。攻撃を止めているのは前の2つ(発行元と名前)と有効期限で、これらはブラウザが必ず検証します。一方で失効の確認は実装と設定に依存します。たとえばChromeは、オンラインのOCSPやCRLの確認を通常は行わず、緊急時のブロックを主目的とするCRLSetという限定的な一覧を使う設計です。失効させれば必ず弾ける、とは考えないでください。また、業務PCに社内の認証局のルート証明書を配布していて、その認証局の秘密鍵や発行手続きが攻撃者に押さえられていれば、1つ目のチェックも通ってしまいます。

URLを間違えて「http://」と入力した場合はどうなりますか。HSTSは何をしているのですか。

ブラウザがHTTPをHTTPSに置き換えてから接続するので、結果は同じくサーバ証明書のエラーになります。HSTSは、そのサイトへ以前HTTPSで接続したときに受け取ったヘッダーの内容をブラウザが覚えておく仕組みです。RFC 6797は、対象のホストへのURLにhttpスキームが含まれる場合、利用者エージェントがそれをhttpsに置き換えること、ポート80が明示されていれば443に変換することを求めています。つまり平文のHTTPリクエストはネットワークに出る前に消えます。さらに重要なのは、HSTSが有効なホストとの通信で証明書の検証に失敗した場合、警告か致命的かを問わず接続を打ち切ることが求められている点です。「この接続は安全ではありませんが続行しますか」という選択肢を利用者に出してはいけない、と明記されています。ただしHSTSは、そのブラウザが一度は正規のサイトへHTTPSで到達してヘッダーを受け取っていることが前提です。まっさらな端末で最初のアクセスがいきなり偽サイトだった場合は効きません。この初回を埋めるのがブラウザに組み込まれたプリロードリストです。

クライアント証明書の秘密鍵をTPMに格納すると、何が変わるのですか。

秘密鍵をその業務PCから取り出せなくなります。ファイルとして端末に置いた秘密鍵は、コピーして個人所有PCに持っていけば、そのPCが業務PCとして認証を通ってしまいます。TPM内で鍵を生成してエクスポートできない状態にしておけば、署名などの演算はTPMの中だけで行われ、鍵そのものはOSにもマルウェアにも渡りません。結果として、EAP-TLSで認証を通せるのは会社が配った業務PCだけになります。この問題でS氏が「その格納方法であれば問題ない」と言えたのはこのためです。Windowsで実装する場合は、証明書テンプレートのキーストレージプロバイダーにMicrosoft Platform Crypto Providerを指定し、秘密キーのエクスポートを許可しない設定にします。ただしTPMが守るのは「鍵が他の端末へ複製されないこと」だけで、その端末を持っている人が使えることは変わりません。端末の紛失・盗難に対しては、ドライブの暗号化と証明書の失効を別に用意する必要があります。

この問題から実務に持ち帰るべきことは何ですか。

4つあります。第一に、持出し対策は手段ではなく経路で考えることです。USBメモリ、メール添付、Webメールを一つずつ塞いでも、ファイルに到達できる端末が残っていれば意味がありません。第二に、送信元IPアドレスによる制限が実際に許可している範囲を書き出してみることです。ゲストWi-FiやVPNが同じ出口を使っていれば、そこも許可範囲です。第三に、無線LANの認証を端末ごとの資格情報にすることです。事前共有キーは全員が同じものを持つ共有秘密なので、一人が漏らせば全員分が漏れます。EAP-TLSとクライアント証明書、そして秘密鍵をTPMから出さない構成にすると、資格情報が端末に固定されます。第四に、使わなくなった設定を消すことです。この問題の最後の設問は、来客用無線LANを廃止したあとに残るVLANインタフェース設定とファイアウォールのフィルタリングルールを全部挙げさせるもので、IPAの採点講評によれば正答率は高かったのですが、実務でここまでやり切れている組織は多くありません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。