サイトアイコン やさしいネットワークとセキュリティ

【情報処理安全確保支援士試験 令和2年度 秋期 午後2 問2 No.1】

湊 コウ

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

【出典：情報処理安全確保支援士試験 令和2年度 秋期 午後2 問2（一部、加工あり）】

問2 クラウドサービスを活用したテレワーク環境に関する次の記述を読んで、設問1〜6に答えよ。

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

　E社のネットワーク構成を図1に示す。

　IDaaS-Yを用いても、社内と同じ利用者IDとパスワードで認証できるように、サーバセグメントに設置した認証情報同期サーバを経由して認証サーバとIDaaS-Yの認証情報を同期している。
　F次長は、全社に展開する前に、まずテレワーク実証実験環境（以下、T環境という）を構築し、一部の従業員（以下、実験に参加する従業員を実験メンバという）に実際に利用してもらい、結果を経営陣に報告することにした。

[T環境の要件]
　T環境においては、E社の従業員の多くが実施している次の業務を、自宅や出張先から実施できるようにすることにした。
業務1：電子メールの送受信及びスケジュールの管理を行う。
業務2：業務文書を作成し、ファイルサーバ上に保存する。また、その業務文書を閲覧・編集する。
業務3：従業員間でテレカンファレンスを実施する。

　F次長は、業務1〜3を実施できるよう、T環境を、次のように整備する方針とした。

　F次長は、T環境におけるセキュリティ要件を、次のように定め、対応するための対策を検討した。
要件1：スマホ及びノートPCには、インストール可能なアプリケーションソフトウェアの制限及び必要な設定の強制をする。
要件2：T環境へのログインパスワードが見破られても、それだけでは不正アクセスできないように、2要素認証を行う。
要件3：T環境へは、貸与するノートPCからだけログインできるようにする。
要件4：T環境からの情報の持ち出しは禁止する。
要件5：T環境でマルウェア感染を検知・防止する。
要件6：T環境では認証ログ、操作ログを記録する。

[要件1への対応]
　要件1への対応として、モバイルデバイス管理基盤とデバイス用ソフトウェアを提供するW社のクラウドサービス（以下、MDM-Wという）を利用することにし、貸与するスマホとノートPCにデバイス用ソフトウェアをインストールすることにした。また、MDM-Wの認証は、IDaaS-Yを利用することにした。
　MDM-Wは、ノートPCの脆弱性修正プログラム及びマルウェア対策ソフトのインストール並びにマルウェア定義ファイルの更新にも利用することにした。

[要件2への対応]
　要件2への対応として、IDaaS-Yを利用することにした。
　まず、IDaaS-Yが対応している2要素認証について調査した。パスワード方式による認証に追加可能なものは次の4方式であった。

　費用を抑えたいが、SMS方式及び自動音声方式は認証の都度料金が発生する。また、FIDO方式は、FIDO認証に対応したスマホが必要となるが、貸与予定のスマホはFIDO認証に対応していない。そこで、スマホアプリ方式を採用することにした。
　OTPアプリは事前に次のようにして設定する。

  1. PCからWebブラウザでIDaaS-Yにログインする。
  2. IDaaS-YのOTPアプリ初期設定用のQRコードを表示する機能にアクセスし、OTPアプリ初期設定用のQRコードを表示させる。
  3. ①当該QRコードをOTPアプリで読み込む。

　IDaaS-YのOTPアプリ初期設定用のQRコードを表示する機能へのアクセスは、E社の利用者IDでログインするときには、②E社のネットワークからのアクセスだけに制限することにした。
　次に、IDaaS-Yと各クラウドサービス間の認証連携について検討した。ノートPCからVDへアクセスする際の、VDとIDaaS-Yとの連携機能は、RADIUSで行うことにした。VDからSaaS-Xにアクセスする際の、SaaS-XとIDaaS-Yとの連携認証は、図2のようにOpenID Connectの認可コードフローでこれまでと同様に行うことにした。VDから会議ツールZにアクセスする際の、会議ツールZとIDaaS-Yとの認証連携は、図3のようにImplicitフローで行うことにした。

①について、QRコードに含まれ、OTPアプリがOTPの生成に使用する情報は何か：シェアードシークレット

　「①当該QRコードをOTPアプリで読み込む。」
　OTPアプリについては、「OTPアプリはTOTP（Time-Based One-Time Password Algorithm）に従ってOTPを表示する。」とあります。
　TOTPではOTPの生成に秘密鍵と現在時刻を使用し、サーバ側とクライアント側で共有する秘密鍵のことをシェアードシークレットといいます。
　このシェアードシークレットをQRコードに埋め込み共有し、現在時刻と組み合わせてパスワードを生成しますが、大体30秒程度で新しいパスワードが生成されていきます。

②について、E社のネットワークからのアクセスだけに制限しなかった場合、OTPについてどのような問題が起きると考えられるか。起きると考えられる問題を30字以内で述べよ。：第三者のOTPアプリで不正にOTPを生成される。

　「IDaaS-YのOTPアプリ初期設定用のQRコードを表示する機能へのアクセスは、E社の利用者IDでログインするときには、②E社のネットワークからのアクセスだけに制限することにした。」
　まず、改めて要件2を確認すると「T環境へのログインパスワードが見破られても、それだけでは不正アクセスできないように、2要素認証を行う。」とあるように、ログインパスワードが見破られる前提での対策となっています。
　したがって、E社の利用者IDが何らかの手段で第三者に漏えいした場合を想定すると、E社のネットワークからのアクセスだけに制限することで、第三者によるOTP生成を防ぐことができると考えられます。

a：ウ、b：エ、c：イ、d：ア、e：カ、f：オ

　認証連携として「OpenID Connectの認可コードフロー」や「Implicitフロー」という仕組みについて理解していなくても、この問題でざっくり把握するスタンスでいいかと思います。
　認証連携には「OAuth」という概念があり、従来のID・パスワードとは異なり、有効期限があるトークンをやり取りしたトークンベースの認証を行う方式です。
　そしてOAuthにはいくつかのフローがあり、「OpenID Connectの認可コードフロー」を簡略化して、利用するアプリケーションでトークンを発行するものが「Implicitフロー」になります。
　まずは「OpenID Connectの認可コードフロー」である図2（SaaS-XとIDaaS-Yとの認証連携）を確認します。
　IDaaS-Yの認可エンドポイントの認証応答を受信したSaaS-Xは、アクセス用のトークン発行をリクエストするためIDaaS-Yのトークンエンドポイントとやり取りします。（「トークン要求（ウ）」→「認可コードを検証（エ）」→「トークン応答（イ）」→「トークンを検証（ア）」）
　続いて、ユーザ情報をリクエストするためIDaaS-Yのユーザ情報エンドポイントとやり取りします。（「ユーザ情報要求（カ）」→「ユーザ情報応答（オ）」）
　一方、「Implicitフロー」である図3（会議ツールZとIDaaS-Yとの認証連携）では、IDaaS-Yの認可エンドポイントの認証応答にトークンが含まれていて、これを受信した会議ツールZが「トークンを検証（ア）」することで処理が完了します。
　なお、「Implicitフロー」は、処理簡略化のため脆弱性があり、推奨されていません。

モバイルバージョンを終了