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

USBメモリを禁止し、ローカル保存もメール添付も禁止し、社内ファイルサーバまで廃止した。それでも、業務用ファイルの持出し経路は残っていました。

情報処理安全確保支援士試験 令和5年度秋期 午後問2で問われるのは、対策の数ではなく、「誰が、どの端末から、どの経路でファイルに到達できるか」です。業務PCに効く対策と、個人所有PCからのアクセスを止める対策は、分けて考える必要があります。¹

この記事は問1(格納型XSS)の解説に続くシリーズの2本目です。各設問を「解答例 → 問題文の根拠 → 仕組み」の順に追い、試験の前提を超える実務上の注意は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つです。

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

2.3．ネットワークは分かれていても、インターネットへの出口は同じ

説明に必要な部分だけを書き起こすと、次の構成です。

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["インターネット"]

図1: M社の構成を簡略化した図。来客用・従業員用・サーバ用のネットワークは分かれているが、インターネット向け通信は同じFWのNATを通る。

2.4．Bサービスの「ログイン」と「外部共有」は別の入口

Bサービスには、次の2つの使い方があります。

共有リンクは申請者本人にも上長にも知らされません。推測困難なランダム文字列を含み、有効期限は1日です。一方、外部共有者はログインせずにダウンロードできます。従業員IDに対するログイン制限だけで、共有リンクの利用まで説明しないようにします。

情報システム部のYさんと、親会社L社の情報処理安全確保支援士S氏は、この構成を前提に、社外の攻撃者、従業員、追加対策の順に検討していきます。

3．設問1(1)(2) ── 偽APに接続しても、偽サイトへのログインは止まる

3.1．設問1(1)：無線LANに接続できても、IDとパスワードが必要

解答例：空欄a・bは「利用者ID」「パスワード」(順不同)。²

Yさんが最初に想定するのは、来客用無線LANを利用したことのある来客者が、後日M社の近くから接続し、Bサービスへアクセスする経路です。大通りに面したビルなので、社外から電波が届くことを考慮します。

WPA2-PSKは全員が同じ事前共有キーを持つ方式です。一度教えた相手だけを「知らない状態」に戻すことはできず、取り消すには全員分のキーを変える必要があります。しかし、無線LANへの接続とBサービスへのログインは別です。社外の攻撃者には、従業員の利用者IDとパスワードがありません。

3.2．設問1(2)：偽サイトの証明書は、発行元とサーバ名で不合格になる

そこで想定されるのが、来客用無線LANと同じ設定の偽APと、Bサービスと同じURLの偽サイトを用意し、DNSの設定を細工してログイン情報を盗む方法です。従業員の業務PCが偽APへ誤接続することを狙います。

同じSSID・同じ事前共有キーを使う偽APは、evil twin(悪魔の双子)と呼ばれます。WPA2-PSKで確かめられるのは、相手が同じキーを知っていることです。キーを知らなければ接続手順を完了できませんが、来客に配るキーを知る攻撃者なら、本物と区別しにくいAPを用意できます。

それでも、BサービスのURLへHTTPSで接続するとサーバ証明書の検証が入ります。問題冊子の図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: 来客用無線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/>そもそも通信していない

図2: 偽APへの接続後にも、HTTPSのサーバ証明書検証が残る。無線LANの認証と、接続先サイトの確認は別の段階である。

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の無線LANインタフェースのMACアドレスを、業務PCのものへ変更します。従業員は業務PCの利用者なので、共有されている事前共有キーを知り得ます。MACアドレスも端末側の設定やドライバのプロパティで変更でき、無線LANフレーム上では暗号化されないため、近くで受信すれば登録済みアドレスを知ることもできます。

SSIDの非通知も、接続時のやり取りからSSIDを知ることへの対策にはなりません。MACアドレスフィルタリングとSSID非通知は、誤接続を減らす整理には使えても、意図的に接続する相手を認証する仕組みではありません。

6.3．方法2は、来客用無線LANへ接続するだけ

来客に配る事前共有キーを使えば、従業員も個人所有PCを来客用無線LANへ接続できます。自分の利用者IDでBサービスにログインし、ダウンロードするだけです。

なぜ「M社のグローバルIPアドレスからだけ」という制限を通れるのでしょうか。答えは、FWのNAT設定にあります。

Bサービスから見える送信元IPアドレスは、いずれも同じです。この設定だけでは、従業員用無線LANの業務PCと、来客用無線LANの個人所有PCを区別できません。

送信元IPアドレス制限は、端末ではなくその出口を共有する範囲を許可します。制限が不要なのではなく、実際の許可範囲を把握し、端末認証や利用者認証と重ねる必要があります。実務の例は10.5節に、問題での対策は8・9章にまとめます。

7．設問3(1)〜(4) ── EAP-TLSとTPMで、接続できる端末を限定する

7.1．設問3(1)：APと認証サーバの間はRADIUS

方法1への対策として、従業員用無線LANをEAP-TLSにし、認証サーバを用意します。認証サーバがEAPで使うUDP上のプロトコルを問う設問3(1)の解答例は「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実務ガイドでドライブ暗号化の文脈から扱っています。「秘密鍵をデバイスの外に出さない」という考え方は、パスキーはなぜ安全なのかで説明している認証器の設計と同じ発想です。

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) ── 来客用無線LANだけ、NATの出口を変える

方法2への対策には、NAT設定を変更する案と、別の無線LANサービス(Dサービス)で来客用ネットワークを分離する案があります。

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

Bサービス側のIPアドレス制限を変更するのではありません。来客用無線LANだけ別のグローバルIPアドレスへ変換し、既存の許可範囲から外します。

この案が取れる根拠は、問題のFWのWAN側サブネットマスクが255.255.255.248(/29)で、使えるグローバルIPアドレスが1つではないことです。実務で同じ案を使えるかは回線契約に依存し、グローバルIPアドレスが1つしか使えないなら、この案は取れません。その場合は、次章の分離案を検討します。

9．設問3(6)(7) ── 来客用ネットワークを分離し、古い設定も消す

9.1．採用したのは、SIMで直接インターネットへ出るDサービス

M社が最終的に選んだのは、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["インターネット"]

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

この問題の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の秘密鍵、あるいは証明書の発行手続きが攻撃者に押さえられた
• 通信内容を検査するプロキシやセキュリティ製品が、TLSを終端するために自前のルート証明書を端末に入れている。その製品や運用が攻撃者に押さえられた
• 「証明書エラーが出るから」という理由で、過去に誰かが例外を登録した、あるいは自己署名証明書を信頼されたルートに入れた

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

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

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

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

10.5．送信元IPアドレスの許可範囲を、出口から洗い出す

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

送信元IPアドレスによる制限が無意味だという話ではありません。制限を1枚だけで使わない、という話です。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メモリ・メール添付・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は「その対策は、どの範囲を守るか」を問う問題です。

情報漏えい対策ソフトは業務PCまで、持込み禁止は執務室まで、MACアドレスフィルタリングは詐称しない相手まで。送信元IPアドレス制限が許可するのは、同じグローバルIPアドレスで出ていく全員です。個々の対策の範囲を確認すると、そのつなぎ目の隙間が見えてきます。

M社は、前年の事件を受けて対策を進めていた会社です。それでも穴が残るのは、担当者の努力不足ではなく、対策を一つずつ足すだけでは範囲の隙間を見つけにくいからです。YさんとS氏のように、社外の攻撃者と従業員を分け、ファイルへの到達経路を1本ずつ確認することが、実務に持ち帰りたい読み方です。

出典と引用・要約の範囲

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

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

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

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

問題冊子と本記事を照合するための対応表

関連する相談領域

合同会社小村ソフトでは、既存のネットワークや端末構成を前提にした設計レビューと、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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。