情報処理安全確保支援士試験 令和２年秋午後２問２の問題解説

全体像（舞台設定）

• E社（従業員5,000名）が働き方改革でテレワーク環境を整えたい。セキュリティ（特に情報漏えい防止）が大テーマ。推進役は登録セキスペのF次長と部下Gさん。

• 既存クラウド：メール/スケジュールのSaaS‑XとID基盤のIDaaS‑Yを使用中。IDaaS‑Yのアカウントは社内認証サーバと同期して、社内と同じID/パスワードでログインできる。

まずは実証用の「T環境」を作る

T環境で、社員が自宅/出張先から次の“3つの業務”をできるようにする：①メール/予定、②ファイルサーバの文書作成・保存・閲覧/編集、③テレカン。
実現方針は次のとおり。

• 端末は会社貸与の「スマホ＋ノートPC」。スマホはノートPCのネット接続用（テザリングなど）。

• 業務は仮想デスクトップ（VD）で行う。VD基盤はクラウドのDaaS‑Vを使う。社内とはFWのVPN機能でインターネットVPN接続。

• 会議はクラウドの「会議ツールZ」。E社ネットワークからのアクセスだけ許可し、VDにクライアントを入れる。

セキュリティ要件（6本柱）

1. 端末のアプリ制限＆設定強制、2) 2要素認証、3) 会社貸与ノートPC限定でログイン可、4) 情報持ち出し禁止、5) マルウェア検知/防止、6) 認証ログ・操作ログの記録。

各要件への“具体的な設計”

■ 要件1（端末統制）：MDM‑Wを採用。スマホ/ノートPCにエージェント導入し、設定強制・脆弱性パッチ配布・AV/定義更新まで面倒を見る。MDM‑W自体の認証にはIDaaS‑Yを使う。

■ 要件2（強固な認証）

• 2FA方式の候補はSMS/音声/スマホアプリ（TOTP）/FIDO。貸与スマホがFIDO未対応＆コストの観点から、スマホアプリ（TOTP）方式を採用。

• OTPアプリの初期設定は「PCでIDaaS‑Yにログイン→QRコード表示→アプリで読み取り」。このQR表示機能へのアクセスは“社内ネットからだけ”に制限（本文の下線①②に対応）。

• 認証連携：VD↔IDaaS‑YはRADIUS、VD→SaaS‑XはOIDCの認可コードフロー、VD→会議ツールZはImplicitフロー（図2/図3のa〜fが後の設問で問われる）。

■ 要件3（貸与PC“だけ”を通す）：DaaS‑Vでクライアント証明書のデバイス認証を実施。社内のプライベートCAで検証し、証明書はMDM‑WでノートPCのTPMに格納。

■ 要件4（持ち出し禁止の実装）：

• VDから外部サイトへは必ずE社ネットワーク経由（プロキシ等）にして監視・制限。

• VDとノートPCのクリップボード/ディスク共有を禁止。表示とキーボード/マウス、マイク/スピーカだけ許可。ただし、意図的な持ち出し（写真撮影や画面キャプチャ等）は技術的に完全防止が困難なので“規程で禁止”する方針（本文の下線③の布石）。

■ 要件5（マルウェア対策）：

• VD側はEDR‑U（クラウド型EDR）を追加契約し、検知/駆除と常時の証跡収集を行う（VDのディスクイメージ確保は難しいためEDRで補完）。

• ノートPCはWeb自由化で感染/情報抜き取りの危険が高いので、「T環境への接続だけ許可」「T環境内のアクセスも最小化」にMDMで縛る（本文の下線④⑤の布石）。スマホはリスクが十分低いと判断し追加対策なし。

■ 要件6（ログ一元監視）：

• 端末と各クラウドの認証・操作ログを有効化し、クラウド側のWeb APIで統合ログ管理サーバへ集約して一元監視。

実証後に出た“2つの要望”と検討

1. 公衆無線LANを使いたい

• T環境宛のみに通信を絞っていたため、ホテルや駅の“同意画面/登録画面（キャプティブポータル）”が出ず、接続できなかった。

• 制限緩和のリスク（フィッシング誘導など）はあるが、仮にDaaS‑Vの偽サイトで入力を抜かれても“他の対策（後述の強固な認証やデバイス認証等）”で不正アクセスは防げると評価し、緩和を決定（本文の下線⑦の示唆）。

2. 業務文書をノートPCへダウンロードしたい（要望X：オフライン作業）

• 取引先でネット禁止だとVDに入れない→外出前に資料をPCへ落として閲覧/メモし、帰社前にアップしたいという要望。

• ただし盗難/紛失時の情報漏えい対策が必要。ディスク暗号だけでは、第三者に取得されたPCに“ログインされて”復号され得る懸念があるため（本文の g に相当する問題提起）、PIN＋TPM、誤入力5回でロック＆長大な回復用パスワード等を検討。

• 方針：原則非対応。ただし申請許可者はE社ネットワークへのインターネットVPN接続を可とする（強い端末・通信側コントロールを前提）。

図と下線の“読みどころ”整理

• 図1/図4は、既存とT環境の全体構成（どのクラウドをどうつなぎ、どこに統合ログを集めるか）を掴む地図。後半で「どこを最小許可にするか？」の判断材料になる。

• 図2/図3はOIDCのメッセージ流れ。a〜f（SaaS‑Xの認可コードフロー）／d（会議ツールZのImplicit）に、認可エンドポイント/トークン/ユーザ情報等の正しい対応付けをする設問が出る。

• 下線①②：TOTP初期設定の“QRコードをどこから読ませるか”と、社外からの悪用（第三者OTP生成）を防ぐための内側限定の意図。

• 下線③：VD側の共有を塞いでも、写真撮影/スクショ等の“人手の抜け道”は残る→規程で禁止という設計思想。

• 下線④⑤：ノートPCの自由Webを許さず「T環境だけに最小アクセス」へ絞るMDMポリシー。

• 下線⑦：公衆Wi‑Fi解禁の際、フィッシングなどの増加リスクは“他の強固対策”で相殺可能という考え方。