令和2年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2｜自宅から安全に働くために——情報処理安全確保支援士で学ぶゼロトラスト時代のテレワーク環境設計

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和2年度 10月 情報処理安全確保支援士試験 午後Ⅱ 問2
• 主なテーマ: テレワーク環境のセキュリティ設計、ゼロトラスト、IDaaS、多要素認証（TOTP）、MDM、仮想デスクトップ（DaaS）、OpenID Connect（認可コードフローとImplicitフロー）、クライアント証明書によるデバイス認証、EDR、情報持ち出し対策

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

働き方改革やパンデミックを契機に、テレワークは多くの企業にとって当たり前の選択肢になりました。しかし「家からでも会社のシステムにアクセスできる」ということは、裏を返せば「会社の外に、守るべき入口がいくつも増える」ということでもあります。社内ネットワークの中にいれば信頼する、という従来の発想だけでは、もはや守りきれません。

情報処理安全確保支援士試験の午後Ⅱで出題されたこの事例は、IT企業がテレワーク環境を一から設計していく過程を、要件ごとに丁寧に追いかけます。多要素認証、デバイス認証、仮想デスクトップ、マルウェア対策、ログの一元監視——一つずつ対策を積み上げながら、「それでも残るリスク」をどう扱うかまで踏み込んでいます。登場するのは、SMSやスマホアプリによるワンタイムパスワード、クラウドの認証基盤（IDaaS）、モバイルデバイス管理（MDM）、そしてOpenID Connectの認可シーケンスといった、いままさに現場で使われている技術ばかりです。

この記事を読むと、ゼロトラストの考え方が具体的な設計にどう落ちるのか、なぜパスワードだけでは足りないのか、画面を撮影されるような「技術では防ぎきれないリスク」にどう向き合うのかが見えてきます。受験者には頻出のクラウド・認証連携の論点が、経営者・管理職にはテレワーク導入の意思決定に必要な視点が、それぞれ得られるはずです。

インシデントの概要

舞台は、従業員5,000名のIT企業E社です。E社は働き方改革の一環として、テレワーク環境を整備することにしました。検討すべき重要なテーマの一つに、「テレワーク環境を経由した情報漏えいを起こさないためのセキュリティ確保」があります。担当することになったのは、システム企画部のF次長と部下のGさん。F次長は情報処理安全確保支援士（登録セキスペ）でもあります。

E社はすでに二つのクラウドサービスを使っていました。電子メールとスケジュール管理の基盤を提供するX社のクラウドサービス（SaaS-X）と、クラウドサービスの認証基盤を提供するY社のサービス（IDaaS-Y）です。IDaaS-Y（IDentity as a Service＝認証・ID管理をクラウドで提供するサービス）を使っても社内と同じ利用者ID・パスワードで認証できるよう、社内の認証サーバとIDaaS-Yの間で認証情報を同期していました。

F次長は、全社展開の前に、まずテレワークの実証実験環境（T環境）を構築し、一部の従業員（実験メンバ）に実際に使ってもらって結果を経営陣に報告する方針を立てます。T環境では、従業員の多くが行う三つの業務——メールとスケジュール管理、業務文書の作成・保存・閲覧・編集、テレカンファレンス——を自宅や出張先から実施できるようにしました。

ここで一つの大きな設計思想が貫かれています。「ネットワークの内か外か」で信頼を決めるのではなく、アクセスするたびに利用者とデバイスを検証する——いわゆるゼロトラストの考え方です。実験メンバには、インターネット接続用のスマホと、業務を行うノートPCを貸与し、業務そのものは仮想デスクトップ（VD。手元の端末ではなくクラウド上の仮想的なPCで作業する仕組み）で行わせる。VDの基盤はV社のクラウドサービス（DaaS-V）を使い、FWのVPN機能でDaaS-VとE社ネットワークをインターネットVPNで接続する。この骨格の上に、F次長は六つのセキュリティ要件を積み上げていきます。

何が起きたのか

この事例は実際の被害が起きた話ではなく、「被害を起こさないための設計」を一歩ずつ固めていく物語です。F次長とGさんが、要件ごとに「どんな攻撃がありうるか」を想像しながら手を打っていく様子は、まるで攻撃者との将棋を先回りで指しているようでもあります。

まず要件1は、スマホとノートPCにインストールできるアプリの制限と必要な設定の強制です。ここでF次長が選んだのが、モバイルデバイス管理基盤を提供するW社のサービス（MDM-W）でした。MDM（Mobile Device Management＝スマホやPCを遠隔から一元管理する仕組み）を使えば、端末に許可したアプリだけを入れ、設定を強制できます。MDM-Wはさらに、ノートPCの脆弱性修正プログラムやマルウェア対策ソフトのインストール、定義ファイルの更新にも使われました。

続く要件2が、この問題の山場の一つです。「T環境へのログインパスワードが見破られても、それだけでは不正アクセスできないように、2要素認証を行う」。F次長はIDaaS-Yが対応する四つの方式——SMS方式、自動音声方式、スマホアプリ方式、FIDO方式——を比較しました。SMSと自動音声は認証のたびに料金が発生し、FIDOは対応スマホが必要だが貸与予定のスマホは非対応。そこで採用されたのが、スマホアプリ方式です。OTP（ワンタイムパスワード）を表示するアプリが、TOTP（Time-Based One-Time Password Algorithm＝時刻に基づいて一定時間ごとに変わる使い捨てパスワードを生成する方式）に従ってパスワードを表示します。

ここでGさんは細部に気づきます。OTPアプリの初期設定では、QRコードを読み込ませます。このQRコードには「シェアードシークレット」（OTPアプリとサーバが共有する秘密の鍵。これと時刻からOTPが計算される）が含まれており、OTP生成の核心になっています。だからこそ、このQRコードを表示する機能へのアクセスは、E社のネットワークからのアクセスだけに制限する必要がありました。もしこの制限をかけなければ——攻撃者が利用者IDでログインしてQRコードを表示させ、第三者のOTPアプリで不正にOTPを生成できてしまう。2要素目が、まるごと攻撃者の手に渡るのです。一見地味な「アクセス元の制限」が、多要素認証の安全性を支えていました。

要件3では、各クラウドサービスとIDaaS-Yの認証連携を設計します。VDからSaaS-Xへのアクセスは、OpenID Connect（OAuth 2.0を土台にした認証の仕組み）の認可コードフローで行うことにしました。認証応答が返った後、SaaS-XはIDaaS-Yのトークンエンドポイントにトークンを要求し、トークン応答を受け取り、トークンを検証し、さらにユーザ情報エンドポイントにユーザ情報を要求して応答を受け取る——という一連のやり取りが続きます。一方、VDから会議ツールZへのアクセスはImplicitフローで行い、こちらは認証応答にトークンが直接含まれるため、トークンを検証するだけで済みます。認可コードフローとImplicitフローの違いを、シーケンスで正確に追えるかが問われました。

さらにF次長は、要件3の対応として、DaaS-V利用時にはIDaaS-Yによる2要素認証に加えて、クライアント証明書によるデバイス認証をDaaS-Vで行うことにしました。社内にプライベート認証局を構築し、その証明書でクライアント証明書を検証する。クライアント証明書はMDM-Wを使ってノートPCのTPM（Trusted Platform Module＝端末内で鍵を安全に保管する専用チップ）に格納します。「正しい利用者であること」だけでなく「正規のデバイスであること」まで確認する——ここにゼロトラストの核心があります。

要件4は、情報の持ち出し禁止です。VDとノートPCの間でクリップボードやディスクの共有を禁止し、VDからインターネットへのアクセスはすべてE社ネットワークを経由させて監視する。Gさんが設定してみると、ノートPCからはVDの画面閲覧、キーボード・マウス操作、マイク・スピーカでの会話しかできなくなりました。しかし、それでも残る穴がありました。利用者が故意に「社内情報を表示した画面をカメラで撮影する」という、アナログな方法での持ち出しです。これは技術では簡単に防げないため、利用規程で禁止することになりました。

要件5のマルウェア対策では、VDのディスクイメージが取得しにくい問題に備え、DaaS-Vがオプション提供するクラウド型のエンドポイント検知対応サービス（EDR-U）を契約します。EDR（Endpoint Detection and Response＝端末上の不審な挙動を検知し対応する仕組み）です。ここでも穴の議論が続きます。VDがマルウェアに感染した場合、「社内情報を表示した画面のスクリーンショットを取る」という方法で情報が取得・持ち出されるおそれがある。だからこそ、ノートPCからのアクセス先はT環境内に限り、さらにT環境内のアクセス先も必要最小限（DaaS-V、IDaaS-Y、MDM-W）に絞る設定にしました。

要件6では、認証ログ・操作ログを記録し、各クラウドサービスのログをWeb API経由で統合ログ管理サーバに取り込み、一元的に監視することにしました。こうして六つの要件への対応が出そろい、T環境のネットワーク構成が完成します。

その後も、クラウドサービス固有の課題、公衆無線LANの利用、業務文書のノートPCへのダウンロードといった現実的な要望と、それに伴うリスクの評価が続きました。攻撃が起きる前に、想定される穴を一つずつ塞いでいく——この事例全体が、地に足のついたリスク管理の実演になっています。