情報処理安全確保支援士 2020年 10月 午後II 問題

共通の文章

百貨店におけるWebサイトの統合に関する次の記述を読んで,設問1ー5に答えよ。 C社は,半年ほど前に旧A社と旧B社が合併してできた会社である。旧BADE 続会社となり,I A社の事業を承継した上で,C社に改称した。C社は,IH A HO 10店舗の百貨店(以下,A百貨店という)と,旧B社の5店舗の百貨店(以下,BA 貨店という)を運営している。 C社は,IR A社が発行していたクレジットカードの会員向けWebサイト(以下, サイトPという),A百貨店の取扱商品を販売するオンラインストアWebサイト(LA 下,サイトQという),及び旧B社のポイントカードを保有する会員向けWebサイト (AE,サイトRという)を運営している。 合併後,旧A社クレジットカードのB百貨店での利用を促進したり,IAB社ポイ ントカードのA百貨店での利用を可能にしたりするなど,両社の顧客サービスの融合 に力を入れている。表1は,サイトP,Q,Rの概要である。 表1各サイトの概要 サイトP|・利用明細の表示英数字8て16字の文 ・クレジットカード利用ポイントの残高確認,商品又は他社の|字列を利用者が設定 ポイントとの交換申請する。 ・各種申請書類の送付依頼 ・アカウント管理(新規登録,パスワード変更,登録事項変更 など) サイトQ|・A百貨店の商品の購入英数字8て16字の文 ・購入履歴の表示字列を利用者が設定 ・アカウント管理(新規登録,.パスワード変更,決済用クレ|する。 ジットカード登録など) サイトR|・ポイント獲得履歴,利用履歴の表示ポイントカードに記 ・ポイント獲得履歴から購買傾向を分析し,傾向に基づいた|載されている数字8 お買い得情報の表示桁の会員番号が割り ・キャンペーンへの応募,応募履歴の表示当てられる。 ・アカウント管理(新規登録,パスワード変更,パスワード 失念時の処理など) [機器の集約と運用作業の効率化〕 C社では,運用作業を効率化するために,別々の場所に設置されていた各サイトを 構成する機器を1か所のデータセンタに集約するとともに,これらの機器を管理する ea 2— Web管理課を新設した。機器集約後のネットワーク構成は図1のとおりである。 でジジ a ee IrDAPTT WT FL Web-P Ji]LDAP-Q}]FW-G fj Web-@]}|LDAP-RT]PWR f]Web-R j FW:ファイアウォール OR Saari ee BES aE 7A w+.)—p||Webi2#LAN! L2SW:レイヤ2スイッチ|EAN 1 注記FW-1では,サイトP,Q,R相互問の通信を禁止している。 図1機器集約後のネットワーク構成(抜粋) サイトP,Q,Rは,それぞれ独立して運営されている。いずれのサイトも,アカ ウント情報はサイトごとに設置したLDAPサーバのユーザエントリとして管理してお り,ログイン時の認証には,各LDAPサーバのユーザエントリ内の利用者IDとパス ワードを利用している。 [サイト間でのアカウントの共通利用〕 C社では経営戦略の一環として,三つのサイトで収集した情報から顧客の購買傾向 を分析することにした。そこで,サイトP,Q,Rでクロス分析などの手法を用いて 購買傾向を分析する上で,各サイト間で同一の顧客を特定するために,サイトP,Q, R相互間でのアカウントの共通利用を実現することにした。 アカウントの共通利用では,次の三つの利用方法のいずれかを各顧客に選択して aもらうことにした。 Q)サイトPのアカウントを親アカウントとし,サイトQ,Rのアカウントを子ア カウントとして,子アカウントを親アカウントに紺付ける。主に旧A社の旋客向 けである。 (2)サイトRのアカウントを親アカウントとし,サイトP,Qのアカウントを子ア カウントとして,子アカウントを親アカウントに紐付ける。主に旧BE社の顧客向 けである。 (3)アカウントの共通利用をしない。 nn ig a 顧客がアカウントの紐付けを設定すれば,子アカウントの代わりに親アカウント を用いて各サイトにログインできる。 [アカウントの共通利用の設計] Web管理課のJ主任は,アカウントの共通利用の設計を任された。J EE,アカ ウントの共通利用を実現するために,次の四つを行うことにした。 (1)サイトP,Q Rのログイン処理を変更する。 (2)LDAP-P,LDAP-Rで管理するアカウント情報に,紐付け情報を保存する。具体 的には,LDAP_PのユーザエントリにsiteQid,siteRid属性を追加して,当該ア カウントに紐付けた子アカウントの利用者IDを保存する。LDAPRのユーザエ ントリには,sitePid,siteQid属性を追加する。 なお,紐付け前のsitePid,siteQid,siteRidには,空文字列が設定される。 (3)Web-P,Web-RのWebアプリケーションプログラム(以下,Webアプリケーシ ョンプログラムをWebアプリという)に,アカウントの紐付け機能を追加す る。 サイトPのアカウントを親アカウントとし,サイトQのアカウントを子アカウ ントとして紐付けるときのサイトPの画面と処理内容は図2のとおりである。 サイトQの利用者D[|yee PeがLDAPQE還合せて入 oreーーみされたサイトQの利用者PEスワードを肝い (i)認証に失敗したら,エラー画面を表示する。 (iii)Web-PのWebアプリが,LDAP-Pの該当するユー ザエントリのsiteQid属性に,サイトQの利用者ID を書き込んで完了画面を表示する。 注記サイトPにログイン済みである。 図2サイトPにおけるサイトQのアカウントの紐付けの画面と処理内容 (4)FW-P,Q,Rのルールに対して必要な変更を行う。例えば,変更後のFW-Pの ルールは,表2のようにする。 a 表2変更後のFW-Pのルール 和信 1監視サーバ,管理コンソール,|Web-P,LDAP-P管理用プロトコル許可 Web管理課LAN a ee|ee mm| |ee ee GS Se』 注記1 FW-P lt,ステートフルパケットインスペクション型である。 注記2項番が小さいルールから順に,最初に合致したルールが適用される。 注記3項番4ご14には,LDAPに関するルールは記述されていない。 〔個人情報の取扱い〕 JE,C社の法務担当のMさんに,アカウントの共通利用について説明し,個 人情報の取扱いの観点から問題がないかどうか相談した。Mさんは,合併前後の個 人情報の利用目的の内容について確認した。 確認後,Mさんは,アカウントの共通利用には,顧客に対して利用目的の変更を 通知して,同意を得る必要があると指摘した。 指摘を受け,J主任は,顧客がアカウントの共通利用を選択したときに,個人情報 の利用目的の変更を通知するとともに,変更後の利用目的を明示して同意を得る機 能を加えることにした。 [コードレビュー] アカウントの共通利用の設計を終えた主任は,サイトPのWebアプリの改修に着 手した。 3及び図4は,サイトPのアカウントにサイトQのアカウントを紐付ける場合 のサイトP上での紐付け処理のJavaソースコードである。 利用者が,サイトPにログイン後,2の画面を操作し,“MAT”ボタンをクリ ックした場合,図4の行番号101のsiteIDにサイトの識別文字列として“siteQ”が 代入された状態で図4のコードの実行が開始される。図4のコードが正常に終了した ら,紐付けが完了したことを表示する。 —5ーー (省略)//パッケージ宣言,インポート宣言 //インポート宣言には,javax.naming.NamingExceptionを含む。 1:public class AccountLink{ 2:boolean childChecked://子アカウントの利用者IDのチェック完了フラグ 3:String chi ldSite;//子アカウントのサイトの識別文字列 4:String childID;//子アカウントの利用者ID 5:String childPW://子アカウントのパスワード 6:String parentID;//親アカウントの利用者ID 7:public static final int NO ERROR=0;//正常終了コード 8:public static final int ERROR SITE_UNAVAILABLE=-101;//エラーコード 9:public static final int ERROR_ID OR_PW=-102;fi LB—T=ド 10:public static final int ERROR LINK FAILED=-103;//エラーコード 11:public AccountLink(String site,String id,String pw,String loginID){ 12:childChecked=false; 13:childSite=site; 14:childID=id; [52 childPW=pw; 16:parentID=loginID: V7:} 18:public int checkChild()throws NamingException{ //サイトの識別文字列のチェック 19:childChecked=childSite.equals("siteQ")||childSite.equals(”siteR”); 20:if(IchildChecked){//サイトの識別文字列が正当でなかった場合 21:return ERROR_SITE_UNAVAILABLE; 22:} 23:switch(childSite){ 24:case"siteQ”: 25:try{ //認証情報チェック 26:if(siteQAuth(childID,childPW)==NO ERROR){ 27:childChecked=true;//認証成功 28:)else{ 29:childChecked=false;//認証失敗 30:} 31:}catch(NamingException e){//認証が実行できなかった場合 32:throw e; 33:} 34:if(IchildChecked){ 35:return ERROR_ID OR_PW: 36:}else{ 3が3 return NO_ERROR: 38:} 図3 Web-PのWebアプリにおけるAccountLinkのクラス定義 —6— 39:case"siteR”: (省略)//サイトRに対して認証を行い,結果に応じてERROR_ID OR_PW又は //NO_ERRORを返して終了する。 40:default: (省略)//ERROR_SITE_UNAVAILABLEを返して終了する。 41:} 42:} 43:public int makeLink()throws NamingException{ (省略)//LDAP-P上のparentIDのユーザエントリの属性siteQid又はsiteRid //にchitldIDを書き込む。 44: 45:private int siteQAuth(String qID,String qPW)throws NamingException{ (省略)//認証情報を確認し,認証成功ならNO_ERRORを,認証失敗ならNO_ERROR //以外の値を返す。必要な通信ができないなど,認証そのものが実行 //できない場合,例外NamingExceptionを投げる。 46:} (省略)//その他のメソッドなどの定義 47:} 3 Web-PのWebアプリにおけるAccountLinkのクラス定義(続き) 101:AccountLink idPair=new AccountLink(siteID,userID,userPassword,loginId); //各変数には次の内容が代入されている。 //siteIDには,紐付け(るアカウントのサイトの識別文字列 //userIDには,紐付けるアカウントの利用者ID //userPasswordには,紐付けるアカウントのパスワード //loginldには,現在サイトPにログインしている利用者ID 102:int result=AccountLink,NO ERROR; 103:for(int retryCount=1;retryCount<4;retryCount++){ 104:try{ //サイトの識別文字列,利用者ID/パスワードの組みを確認する。 105:result=idPair,checkChild(); 106:if(result==AccountLink.NO ERROR){ |107:break: I 108:}else{ (省略)//resultの値に従った適切な処理を実施する。 109:} 110:}catch(NamingException e){ (省略)//再試行のために,一定時間待つ。 111:} 112:} Ts:if(lidPair.childChecked){ 114:return AccountLink,ERROR_LINK FAILED; 115:} 4 Web-P M WebアプリにおけるAccountLinkのメソッドを呼んでいる部分 ey 7=u, 1 117:idPair.makeLink()://アカウントの紐付けを実施する。 118:}catch(NamingException e){ 119:} (省略)//例外処理 図4 Web-PのWebアプリにおけるAccountLinkのメソッドを呼んでいる部分(続き) ]主任は,情報処理安全確保支援士(登録セキスペ)OK主任とともにコードレビ ューを実施した。K主任は,次のような特定の状況では,サイトPのある利用者のア カウントに,サイトQの他人のアカウントが紐付いてしまうと指摘した。 (1)図2で,サイトQの利用者ID欄に誤った利用者IDを入力する。 (②)図4のコードが呼び出され,|c|に誤った利用者IDが代入されたま ま,| q|が呼び出される。 @)何らかの理由で,| q|中の図3中の行番号|e|で|ij| が発生し,結果として| d|が再試行される。 ④[|3]が8回試行され,全て同じくが発生すると, |gz|の値はtrueなので,図4中の行番号|h|に進み,紐付けが行 われる。 KEE,図3の32行目前後に着目し,| :|という修正案を提示した。 〔[サイトRでのインシデント〕 リリースに向けて準備を進めていたところ,インシデント発生の報告があった。 発端は,ある顧客からの指摘で,その内容は,“Tb Rのキャンペーン応募履歴を 見たら,3月のキャンペーンに応募したことになっているが,身に覚えがない。3月 にはサイトRに一度もアクセスしていないはずだ。”というものであった。 ]主任が,サイトRのアクセスログを確認したところ,次のことが分かつった。 ・3月30日に,当該顧客のアカウントでキャンペーンに応募していた。 ・応募の直前にパスワード和失念時の処理を実行しパスワードを電子メール(以下, メールという)で未登録のメールアドレスに送信した記録がある。 ・3月25日から3月31日に掛けて,サイトRへの通信量が増加傾向にあった。 ーg一 図5は,サイトRのパスワード和失念時の操作画面である。 ce Cg 会員番号[|新たなメールアドレス|| 現在のパスワードをメールで送信 メールが受信できなり場合 現在のパスワードをメールで送信 注記実線の矢印は当該画面の入力フォームに適切な値を入力してボタンがクリックされたときの EBERT. 図5サイトRのパスワード失念時の操作画面 J主任は,攻撃者がパスワード失念時の処理を悪用して,会員番号及び誕生日を総 当たりで入力し,たまたま合致した当該顧客のアカウントを乗っ取ったものと判断 した。本主任は,このインシデントについてWeb管理課のL課長に報告した。L課長 は旧A社出身で,この報告でサイトRのパスワード和失念時の操作を初めて知った。 次は,その報告の時のL課長と主任の会話である。 L課長:サイトRのパスワード失念時の処理には,三つの問題があるね。一つ目は, 本人であることを確認するための情報が少なすぎるという問題だ。そこは 後で解決するとしよう。二つ目は,パスワードそのものをメールで送ると いう問題だ。三つ目は,という問題だ。二つ目と三つ目の問題 の解決には,|k|ように改修すべきだ。この方法では,一部の利用 者はパスワード和失念時にログインできなくなるが,その場合はコールセン タで対応することにしよう。 主任:はい。分かがりました。 L課長:サイトRでは,攻撃者がアカウントを乗っ取ったとしても,あまり経済的利 益を得られないので,今回のような被害で済んだと考えられるが,直ちに 改修を完了させてほしい。もしもこれらの問題に気付かずにアカウントの 共通利用を提供していたら,①利用者に更に大きな被害が発生するところ ー9一 だった。アカウントの共通利用の設計,及びリリースまでのスケジュール も見直してほしい、。 [アカウントの共通利用の設計の見直し] ]主任は,次のように全面的に設計を見直し,承認を得た。 ・サイトSを立ち上げ,新たにサイトSのアカウントを発行して管理する。 ・アカウントの共通利用に当たり,アカウントの紐付け時とサイトP,Q,R AOU グイン時には,SAMLプロトコルのWeb Browser SSO Profileを用いる。サイトS が,IdP(Identity Provider)となり,サイトP,Q,Rは,SP(Service Provider) となる。 ・サイトQには,サイトQのアカウントでも,サイトQのアカウントと紐付けたサ イトSのアカウントでもログインできる。サイトP,Rも同様である。 図6は,Web Browser SSO Profileの基本的な通信の流れである。 利用者のWebブラウザSP IdP ログインが必要なSPのリソースへのアクセス要求 om>C転送された認証要求 め和正のための通1 >as | 。。。問Eのたゅ通信|| a(t asec」 (4)—> 6 Web Browser SSO Profileの基本的な通信の流れ 7は,紐付け済みのサイトSのアカウントでサイトQにログインするときの画 面相移図である。 (あ)(い)(う) サイトQのDでログインしサイトQのトップメニュー| サイトSのIDでのッ SOmDでのアカウントを作成する 注記1画面内の“ID”は,利用者IDを指す。 注記2実線の矢印は当該画面の入力フォームに適切な値を入力してボタンがクリックされたときの EBERT.破線の矢印はリンクがクリックされたときの居移を示す。 図7サイト$のアカウントでサイトにログインするときの画面居移図 図8は。サイトQのアカウントとサイトSのアカウントを紐付けるときの画面居 移図である。 (え)(お)(か) ie]||or サイトQのIDでログインee |サイトQのトップメニュー) ログインはこちらサイトSのIDと紐付け-|-アカウントを作成する | (き)(く) 氏名[サイトQのアカウント メールアドレス||||カウント“AAA"を紐付け “OOO”と,サイトSのア 2へ| o rs)ニーーーーー パスワード(確認用)[||wy)) ログインしました。 アカウントを作成ようこそ,サイトQへ 注記1画面内の“ID”は,利用者IDを指す。 注記2実線の矢印は当該画面の入力フォームに適切な値を入力してボタンがクリックされたときの BERT.破線の矢印はリンクがクリックされたときの居移を示す。 図8サイト0のアカウントとサイトSのアカウントを紐付けるときの画面乱移図 [見直し後のアカウント共通利用の提供開始 C社は,サイトP,Q,Rの改修とサイトSの開発を完了して,アカウント共通利 用の提供を開始し,順調に運用を続けた。サイトP,Q,Rのアカウントの廃止,及 びサイトSのアカウントへの統合を目指している。この統合が実現すれば,図7の (あ)や,図8の(A),(お)などの画面は不要となり,より使いやすいサイトを実 現できる。

共通の文章

クラウドサービスを活用したテレワーク環境に関する次の記述を読んで,設問1ー 6に答えよ。 E社は,従業員数5.000名のIT企業である。E社では,働き方改革の一環として, テレワーク環境を整備することになった。テレワーク環境について検討すべき重要 なテーマの一つに,テレワーク環境経由での情報漏えいを起こさないためのセキュ リティ確保がある。そこで,テレワーク環境の整備をシステム企画部長の指示の下, 情報処理安全確保支援士(登録セキスペ)でもあるシステム企画部のFRE,及び 部下のGさんが担当することになった。 現在E社では,次のクラウドサービスを利用している。 ・電子メールの送受信及びスケジュールの管理のための基盤を提供する,X社のクラ ウドサービス(以下,SaaS-Xという) ・クラウドサービスの認証基盤を提供する,Y社のクラウドサービス(以下,IDaaS- Yという) E社のネットワーク構成を図1に示す。 1ーーニニニニニニーーー3|i }|; i||pees PC NiswH ew] oS oe my リー| :|i ifファイル||統合ログ|||Bae| |サーバ|ES]同期サーバ|」FW:ファイアウォール 1リーーーーーーーニーーニーニニニーニーニニニニニニニニニーL2SW:レイヤ2スイッチ 注!SaaS-Xの認証に利用している。 M1 E社のネットワーク構成(概要) IDaaS-Yを用いても,社内と同じ利用者IDとパスワードてで認証できるように,サ ーバセグメントに設置した認証情報同期サーバを経由して認証サーバとIDaaS-Y Oi 証情報を同期している。 F次長は,全社に展開する前に,まずテレワーク実証実験環境(以下,T環境とい う)を構築し,一部の従業員(以下,実験に参加する従業員を実験メンバという) に実際に利用してもらい,結果を経営陣に報告することにした。 (T環境の要件] T環境においては,E社の従業員の多くが実施している次の業務を,自宅や出張先 から実施できるようにすることにした。 業務1:電子メールの送受信及びスケジュールの管理を行う。 業務2:業務文書を作成し,ファイルサーバ上に保存する。また,その業務文書を閲 覧・編集する。 業務3:従業員間でテレカンファレンスを実施する。 F次長は,業務1~3を実施できるよう,T環境を,次のように整備する方針とし ake ・T環境の構成要素の一部として,各実験メンバにスマートフォン(以下,スマホと いう)及びノートPCを貸与する。スマホは,ノートPCをインターネットに接続 するために利用する。 ・実験メンバは,仮想デスクトップ(以下,VDという)で業務を行う。そのために, VD基盤を提供するV社のクラウドサービス(以下,DaaS-Vという)を利用する。 ・FWのVPN機能を利用して,DaaS-VとE社のネットワークをインターネット VPNで接続する。 ・VDでは文書作成ソフトによる業務文書の作成・閲覧・編集・保存を行えるように する。 ・テレカンファレンスは,コミュニケーション基盤を提供するZ社のクラウドサー ビス(以下,会議ツールZという)を利用し,E社のネットワークからのアクセス だけを許可する。VDには会議ツール2のクライアントソフトを導入する。 ー45— F次長は,T環境におけるセキュリティ要件を,次のように定め,対応するための 対策を検討した。 要件1:スマホ及びノートPCには,インストール可能なアプリケーションソフトウ ェアの制限及び必要な設定の強制をする。 要件2:環境へのログインパスワードが見破られても,それだけでは不正アクセス できないように,2要素認証を行う。 要件3:環境へは,貸与するノートPCからだけログインできるようにする。 要件4:環境からの情報の持ち出しは禁止する。 要件5:環境でマルウェア感染を検知・防止する。 要件6:環境では認証ログ,操作ログを記録する。 [要件1への対応〕 要件1への対応として,モバイルデバイス管理基盤とデバイス用ソフトウェエアを 提供するW社のクラウドサービス(以下,MDM-Wという)を利用することにし, 貸与するスマホとノートPCにデバイス用ソフトウェアをインストールすることにし た。また,MDM-Wの認証は,IDaaS-Yを利用することにした。 MDM-Wは,ノートPCの脆弱性修正プログラム及びマルウェア対策ソフトのイン ストール並びにマルウェア定義ファイルの更新にも利用することにした。 [要件2への対応〕 要件2への対応として,IDaaS-Yを利用することにした。 まず,IDaaS-Yが対応している2要素認証について調査した。パスワード方式によ る認証に追加可能なものは次の4方式であった。 SMS方式:事前登録した電話番号にSMSでワンタイムパスワード(以下, OTPという)を送付する。 自動音声方式 :事前登録した電話番号に自動音声でOTPを通知する。 スマホアプリ方式:OTP表示用のスマホアプリケーションソフトウェア(以下, OTPアプリという)を利用する。OTPアプリはTOTP(Time- Based One-Time Password Algorithm)に従ってOTPを表示する。 FIDO方式:事前登録したデバイスでFIDO認証を行う。 ー16一 費用を抑えたいが,SMS方式及び自動音声方式は認証の都度料金が発生する。ま た,FIDO方式は,FIDO認証に対応したスマホが必要となるが,貸与予定のスマホ はFIDO認証に対応していない。そこで,スマホアプリ方式を採用することにした。 OTPアプリは事前に次のようにして設定する。 1.PCからWebブラウザでIDaaS-Yにログインする。 2.IDaaS-YのOTPアプリ初期設定用のQRコードを表示する機能こアクセスし, OTPアプリ初期設定用のQRコードを表示させる。 3.①当該NRコードをOTPアプリで読み込む。 IDaaS-YのOTPアプリ初期設定用のQRコードを表示する機能へのアクセスは,E 社の利用者IDでログインするときには,②E社のネットワークからのアクセスだけ に制限することにした。 次に,IDaaS-Yと各クラウドサービス間の認証連携について検討した。ノートPC. DS VDへアクセスする際の,VDとIDaaS-Yとの認証連携は,RADIUSで行うこと にした。VDからSaaS-Xにアクセスする際の,SaaS-XとIDaaS-Yとの認証連携は, 図2のようにOpenID Connectの認可コードフローでこれまでと同様に行うことにし た。VDから会議ツールZにアクセスする際の,会議ツールZとIDaaS-Yとの認証連 携は,図3のようにImplicitフローで行うことにした。 ー17一 「Daa YO : ログイン要ポa!ee Cl eencmaee| es ee| C|gaseemmee|| ec ee| a<?ン<| eee しーーパー ee WWwWwWwW、W、W0Wtwt〔{〔| $< 図2 SaaS-XとIDaaS-Yとの認証連携 「Daa [ ログイン要求(a ee eee Cl sesncmmer es ee 」 CI_aeee」 a ee| a 0) 図3会議ツールZとIDaaS-Yとの認証連携 要件3への対応】 要件3への対応として,DaaS-Vの利用時は,IDaaS-Yによる2要素認証に加えて, クライアント証明書によるデバイス認証をDaaS-Vで行うことにした。社内にプライ ベート認証局を構築し,当該認証局の証明書によるクライアント証明書の検証が行 ー18一 われるようにDaaS-Vを設定することにした。クライアント証明書はMDM-Wを利用 UT,ノートPCのTPM(Trusted Platform Module)に格納することにした。 [要件4への対応〕 要件4への対応として,VDからインターネットへのアクセスは,全て社のネッ トワークを経由させることによってアクセス先の制限とアクセスの監視を行うこと にした。 また,VDとノートPCとの間でクリップボード及びディスクの共有を禁止するよ うにDaaS-Vを設定することにした。Gさんが設定してみたところ,ノートPCから は,VDの閲覧,キーボード及びマウスによる操作,並びにマイク及びスピーカによ る会話しかできなくなることが確認できた。しかし,この設定であっても③利用者 が故意に社内情報を持ち出すおそれがある。これについては,簡単には技術的対策 ができないので,利用規程で禁止することにした。 [要件5への対応〕 要件5への対応として,VD,ノートPC及びスマホに対するマルウェア感染の対 策を検討した。 VDでは,電子メールの添付ファイル開封及びWebアクセスによるマルウェア感染 のおそれがある。仮にVDがマルウェアに感染した場合に被害調査のためのディジタ ルフォレンジックスを行おうとしても,マルウェア感染したVDのディスクイメージ を取得するのに時間が掛かったり,提供してもらえなかったりすることも考えられ BoそこでDaaS-Vがオプションとして提供しているU社のクラウド型エンドポイン ト検知対応サービス(以下,EDR-Uという)も契約し,マルウェアの検知及び駆除 並びに調査に必要な情報の常時収集をすることにした。 ノートPCについては,自由なWebアクセスを許可した場合,マルウェアに感染 するリスク,及び利用者がVDを利用中に②④マルウェアが人社内情報を取得して持ち出 すリスクが高くなる。そこで,それらのリスクを低減するために,MDM-Wでは,ノ ートPCからT環境へのアクセスだけを許可し,⑧⑥T環境内のアクセスも必要最小限 にする設定を行うことにした。 スマホについては,自由なWebアクセスを許可した場合でもマルウェア感染のリ ー19一 スクは十分低いと考えられたので,追加の対応は行わなかいことにした。 [要件6への対応】 要件6への対応として,ノートPC,スマホ及び各クラウドサービスで認証ログ 操作ログの記録を有効化することにした。また,各クラウドサービスにおいて記録 した認証ログ,操作ログを取り出すためのWeb APIが用意されていたので,MAU グ管理サーバにログを取り込み,ログ監視を一元的に行うことにした。 要件1ー6に対応したT環境のネットワーク構成を図4に示す。 Ce see ie ||認証サーバ|携帯電話回線 {Le aa ae dR ERE“ 注記太線は環境構築に当たって追加されるものを示す。 図4 1環境のネットワーク構成(概要) [クラウドサービス固有の課題] T環境で利用するクラウドサービスに脆弱性があれば,それを悪用する攻撃によっ て,E社のセキュリティが侵害されるおそれがある。そこで,各クラウドサービスプ ロバイダ(以下,CSPという)に,脆弱性対策の状況にヒついてのヒアリング及びサ ービスの基盤についての脆弱性検査を実施させてもらえないか確認した。そうした ところ,各CSPともヒアリングには対応するが,利用者による脆弱性検査は,サー ビス提供に影響を及ぼすおそれがあるので許可していないとの回答だった。そこでF 次長は,脆弱性検査を⑥別の方法ととアリングで代替することにした。 ー20一 (実証実験の実施] 各CSPの脆弱性対策には大きな問題がなかった。そこで,図4のT環境を構築し, システム企画部,人事部,営業部から実験メンバをそれぞれ20名ずつ計60名募っ た。実験メンバには,T環境を利用できるように設定したスマホとノートPCを貸与 し,期間を3か月間として,実証実験を開始した。 実証実験後,実験メンバにアンケートを採ったところ,多くの実験メンバから, これまでより利便性・生産性が向上したとの意見が集まった。また,二つの要望が 出た。 【公衆無線LAN©Ail FA) ーフつ目の要望は,出張の移動中又は宿泊先でスマホの通信回線が利用できなかっ た場合,公衆無線LANを利用したいというものである。国内の多くの公衆無線LAN 環境では,無線LANアクセスポイントへの接続時にWebで利用者登録画面や利用規 約同意画面が表示され,利用者が利用者情報を登録したり,利用規約への同意をし たりした後にインターネット接続が許可される仕組みになっている。ノートPCでは アクセス先をT環境宛に制限していたので,これらの画面が表示されず,公衆無線 LANを利用できなかったということであった。 そこで,FRE,ノートPCのアクセス先制限を緩和して利用者が公衆無線LAN 環境に接続できるようにした場合のリスクを評価した。その結果,フィッシングサ イトなどに誘導されるリスクが高まると考えられたが,仮にDaaS-Vのフィッシング サイトで,利用者の入力が詐取されたとしても,その情報を悪用した不正アクセス は⑦検討済みの他の対策で防止できるので,ノートPCのアクセス先制限を緩和する CHE Wes 【業務文書のノートPCへのダウンロード〕 =THORS(以下,要望Xという)は,営業部の実験メンバから,顧客を訪問 した際の業務文書の閲覧・作成について挙がったものである。持込端末のインター ネット接続が禁止されている顧客を訪問した際は,VDにアクセスできない。そこで, 会社を出た後,訪問前にたファイルサーバ上の営業資料をノートPCにダウンロードし ておき,それを閲覧したり,ノートPC上で顧客打合せの議事録の文書を作成し,訪 ー21一 FA,会社に戻る前にその文書をファイルサーバにアップロードしたりしたいとい うととどぐであつたな。 要望Xを実現すると,ノートPCに対する盗難・紛失時の情報漏えい対策が必要に RS,Mik,この件についてのGさんと次長の会話である。 Gさん:ノートPCの盗難・紛失時の情報漏えい対策としては,OSに搭載されたデ ィスク暗号化機能を使えばよいのではないでしょうかが。 FRE:そうだな。しかし,紛失したノートPCを第三者に取得されたときに, [|gz|されてディスクが復されてしまうおそれがある。ディスク暗 号化機能だけでは不十分だ。 GSA:追加の対策はあるのでしょうか。 F次長:PINコードを利用したログイン方式を強制した場合を考えてみよう。PINコ ードを利用したログイン方式は,TPMを利用する。正しいPINコードが入 力された場合,ディスクが復号される。今回,PINコードは,6桁の数字 とし,システム管理者が事前にランダムなものを設定することにしよう。 Gさん:6桁の数字だと総当たり攻撃で破られそうですが,大丈夫なのでしょうか。 FRE:誤った入力が5回連続で行われると管理者が回復用のパスワードを入力し ない限りログインできなくなるように設定し,回復用のパスワードには推 測困難な十分に長いランダムな文字列を設定する方法もある。 Gさん:なるほど。 F次長は,検討の結果,要望Xには原則として対応しないが,希望者には個別に 申請してもらい,⑨申請が許可された利用者のノートPCについては,E社のネット| ワークとのインターネットVPNでの接続を可能とする方針にした。 F次長は,実証実験の結果,実験メンバからの要望及びそれへの対応,並びに残存 するリスク及びその低減策についてシステム企画部長と経営陣に報告した。経営陣 はテレワーク環境を全社に展開することを決めた。 ー22一