全体像（何の話か）
150名規模の投資コンサル会社C社が、SaaS活用やテレワークを進める中で、①社内LANのDHCPトラブル、②無料チャットSaaSでのアカウント乗っ取り疑い、という2つの出来事をきっかけに、無線LANの企業認証（802.1X）、IDaaS（SAML/SSO）、プロキシ型クラウドサービス（端末エージェント＝Pソフト）などを組み合わせて、アクセス統制と情報漏えい対策を設計・移行していく物語です。C社の構成や現状ネットワーク、そして次期ITのセキュリティ要件が順に示されています。
物語の流れ（時系列で理解）
-
会社の現状
-
トラブル1（DHCP絡み）
-
昼過ぎから多くの端末で「サーバに行けない／Webもメールも不可」。該当PCは169.254.x.xのアドレス＝DHCPに失敗した状態（APIPA）だった。偽DHCPを疑うも、原因は“社内LANに私物機器が多数接続されたことによる問題”と専門家が指摘。DHCP設定を変更して一旦収束。
-
トラブル2（無料チャットSaaSの乗っ取り疑い）
-
企画部の無料チャット「サービスR」で部員Vのアカウントからスパム投稿。実はSNS「サービスW」でパスワード漏えいがあり、同じパスワードをRでも使い回していた（Wは変更したがRは未変更）。無料プランでアクセスログ提供は不可。被害の上限把握のため、アクセスログ以外の現物調査を指示。
-
次期IT要件の整理
-
無線はWPA2-Enterprise＋802.1XでC-PCのみ接続可（要件1）。
-
業務の私物端末禁止、テレワーク用PCは貸与（要件2）。
-
SaaSのログインはIDaaSで統合し、パスワード管理負担を軽減（要件3）。
-
契約SaaS以外や不要サイトへのアクセス制限（情報収集は阻害しない）（要件4）。
-
契約SaaSには会社管理アカウントのみアクセス可（個人アカウント不可）（要件5）。
-
SaaSからの漏えい対策（たとえば自動暗号化）（要件7）。
-
要件実現の具体策
-
802.1Xのシーケンス（サプリカント＝C-PC、認証装置＝AP、認証サーバ）を用意。IPは認証完了後にDHCPから払い出される想定。
-
IDaaS（サービスQ）：利用者ID/パスワード、TLSクライアント証明書、生体、OTPなどで認証し、SAML対応SaaSにSSO。パスワードレスに近い運用も可。
-
プロキシ型クラウドサービス（サービスN）＋端末エージェント（Pソフト）で、URLフィルタ、IDごとの許可、可視化ログ、API連携での保管時自動暗号化などを実施。管理者以外は停止/アンインストール不可に設定できる。
キーワードを短く整理
-
169.254.x.x：リンクローカル（APIPA）。DHCPに失敗した端末が自動採番する宛先。
-
IDaaS（サービスQ）：SAML連携でSSO、認証手段はID/PW・クライアント証明書・OTP・生体など。
-
サービスN＋Pソフト：URLフィルタ（#2）、利用者IDフィルタ（#1）、可視化（#3）、保管時自動暗号化（#4）。端末の通信を必ずN経由にし、一般権限で無効化できない設定が可能。
設問ごとの「狙い」と「拾う場所」「書き方のコツ」
■ 設問1（トラブル1）
(1) 169.254.x.xは何か？
→「リンクローカルアドレス（APIPA）」を選ぶ問題。根拠は“上位2オクテットが169.254”の描写。
(2) 私物機器のどんな使い方が、どんな問題を引き起こしたか（60字以内）
→「多くの個人所有機器が社内LANに接続し、DHCPのアドレス枯渇を招いた（結果、IP取得不可で通信不能）」と因果で書く。背景に“私物端末の接続を統制せずAPに接続”の記述。
(3) ほかにDHCPサーバがいるかの調査（UTM稼働のまま／停止して）
→ 稼働のまま：L2SWでミラー→LANモニタでDHCP OFFERの数を確認（複数サーバが応答していないか）。停止後：IP配布が行われないことを確認。出題は手順の具体性がポイント。（公式要点の道筋）
■ 設問2（トラブル2：ログ以外の調査）
→ 無料プランで提供会社のアクセスログが取れない前提。最大被害推定のため「企画部の部員がアクセスできるチャットエリアで共有されている情報」を実地に棚卸しする、が答えの核。
■ 設問3（要件1：802.1X）
(1) 図2のa/bに何が入る？
→ a＝C‑PC、b＝AP。問題文が「図2中のサプリカントには図1中のa（＝C‑PC）、認証装置には図1中のb（＝AP）」と対応付け。
(2) DHCPでIPが割り当てられるタイミング
→ 「“6.”より後に」（＝エ）。認証成功・鍵配布が済んだ後に、はじめてネットワーク参加→DHCP。
■ 設問4（要件4・5＋図3）
(1) “情報収集は妨げない”のに「契約済SaaSだけ許可＋その他遮断」だと何が困る？
→ 事業部・企画部の「インターネットを使った情報収集／提案・企画立案」に支障。本文が明示。
(2) 要件4（サイト制限など）は表3のどれ？ → #2：URLフィルタリング。
(3) 要件5（私物アカウント不可）は表3のどれ？ → #1：利用者IDによるフィルタリング。
(4) 図3のどこで「会社管理外の機器」を遮断？方法は？
→ 段階は「5～6」（＝ウ）。方法は「TLSクライアント証明書で端末（管理機）の真偽を検証」。図3と本文の“総務Gが管理していない機器は途中で遮断”の記載がヒント。
■ 設問5（要件6・7）
(1) 規格・認証の例
→ ISMS（ISO/IEC 27001）やISAE3402/SSAE16などが代表例。
(2) 「表3の番号d」はどれ？
→ #4：保管時の自動暗号化機能（SaaSのAPIで特定フォルダを自動暗号化し、Nを経由しない不正アクセスによる漏えいを防ぐ狙い）。
■ 設問6（移行時の端末設定）
(1) クライアント認証の“無効化させない”設定
→ 「秘密鍵を書き出しできない（非エクスポート）」等、ユーザ権限で触れない形で証明書を配備・保護。
(2) 要件4・5の維持に必要なソフトと設定
→ Pソフトを“一般利用者権限では変更・停止・アンインストールできないように設定”。（端末からの全通信をN経由へ強制し、ポリシー逸脱を防止）
ひっかけ・注意点
-
169.254は“リンクローカル”。プライベートアドレス（RFC1918の10/8, 172.16/12, 192.168/16）とは別物。ここで取り違えない。
-
要件4と5の機能対応は逆にしない（#2＝URLフィルタ、#1＝IDフィルタ）。
-
図3の遮断ポイントは“認証フェーズ（5～6）”。そこでPソフトやクライアント証明書の有無で弾くイメージ。
