情報処理安全確保支援士 2012年 春期 午後2 問02

解答の論理構成

1. a の判断
   • 本文では「サーバの管理ミスや脆弱性対策の不備などに起因するリスクを外部にaする」とあります。
   • リスクを外部の事業者に“移して”自社の負担を軽減する行為は、リスクマネジメントの用語で「リスク移転」と呼びます。
   • 解答群で「移転」と一致するのは「ア：移転」です。
2. b の判断
   • 本文では「クラウドサービスへの切替えとなれば環境が大きく変わる…リスクbの結果に基づいて対応を行った上で」とあります。
   • ここに入るのは、リスクを洗い出し評価する工程を示す語で、一般的に「リスク分析」または「リスクアセスメント」と言います。
   • 解答群で該当するのは「カ：分析」です。
3. c の判断
   • 本文では「残るリスクをそのままcしてクラウドサービスに切り替えるかどうかは経営陣が判断することだ」とあります。
   • 対策後に残存するリスクをそのまま許容する意思決定は「リスク受容」です。
   • 解答群で「受容」と一致するのは「ウ：受容」です。

誤りやすいポイント

• a に「回避」や「低減」を入れてしまう
  • 外部に委託してもリスクが完全になくなるわけではなく、文字通りリスクを“移す”という概念を見落としがちです。
• b と c の混同
  • 「リスク分析」は評価作業を示し、「リスク受容」は意思決定を示します。ステップの違いを意識して区別しましょう。
• 日本語のニュアンス頼り
  • 「対応」「エ：対応」など汎用的な語を選ぶと意味がぼやけるため、専門用語として正確に当てはまる語を選択する必要があります。

FAQ

解答の論理構成

1. ①の発言

   「現在のメールをクラウドサービスへ移行すると、①メールによってはこれまでと比較して、ある種類のリスクが高くなります。」
   ここで S 主任は“クラウドに置くことで従来より高まるリスク”を問題視しています。

2. リスクの対象となるメール
   クラウドに置かれるのは「イベント参加者のデータベースや経営情報など重要なデータ」を添付・記載した内部メールです。これは本文で

   「重要なデータをクラウドサービスに移すことには抵抗があります。」
   と明示されています。よって“機密性の高い社内メール”が該当します。

3. リスクの内容
   クラウドはインターネット経由で“どこからでもアクセス可能”になるため、

   「アクセス元を限定できないC社のSaaS型サービスだと、…ネットカフェのPCなどでも利用できる」
   とあるように、第三者に不正アクセス・誤送信される経路が増えます。これは情報漏えい、すなわち“外部流出”リスクの高まりです。

4. 以上より解答は「機密性の高い社内のメールが外部に流出するリスク」となります。

誤りやすいポイント

• “誤送信”と“外部流出”を混同する。誤送信は原因の一つで、問われているのは結果としてのリスク（流出）の方です。
• “全メール”と書くミス。クラウド化しても取引案内など公開性の高いメールは問題にならず、焦点は「機密性の高い社内メール」です。
• “ウイルス感染”と答える誤解。本文ではウイルス対策は従来同様に実施される前提であり、主題は情報漏えいの危険です。

FAQ

解答の論理構成

1. 図3に示された検討課題は
   「(1) クラウドサービスに切り替えた場合の管理とセキュリティの確保」
   「(2) 携帯端末の管理とセキュリティの確保」
   「(3) 新システムへの切替えに伴うポリシーの改定」
   「(4) 利用者に対する周知、教育」
   という四つです。
2. 設問は「利用者に対して周知、教育すべき事項」を二つ挙げよ、という指示なので、(4)を実行する上で利用者に直接伝えるべき内容を抽出します。
3. クラウドサービスと携帯端末の導入で環境が大きく変わるため、現行ポリシとの差異を理解させる必要があります。本文でも
   「リスクbの結果に基づいて対応を行った上で、情報セキュリティポリシ…の見直しを行い、必要な対策を実施するべきだと思います。」
   と述べられています。したがって「新システムへの切替えに伴うポリシの改定点」は必須の周知事項です。
4. また、クラウドサービスと携帯端末の利用は従業員の操作が直接リスクに結び付くため、安全な利用方法を教育する必要があります。本文には
   「携帯端末からクラウドサービスを利用する場合には、二要素認証…SSLによる暗号化…」
   といった具体策が列挙されており、利用者が適切に実践できなければ意味がありません。
5. よって周知・教育すべき事項は
   ①「新システムへの切替えに伴うポリシの改定点」
   ②「クラウドサービス及び携帯端末の安全な利用方法」
   となります。

誤りやすいポイント

• 管理部門向けの技術的な運用手順（バックアップ取得方法など）を周知事項と勘違いする。周知対象は“利用者”である点に注意が必要です。
• 「クラウドサービスのメリット」など説明的情報を挙げてしまう。教育項目は“守るべきルールや手順”に絞ります。
• ポリシの改定内容を細目で列挙し過ぎてしまい、利用者が理解できない範囲まで書いてしまう。周知事項は要点をまとめることが重要です。

FAQ

解答の論理構成

• 表2は、サービス形態ごとに「管理主体・管理内容」を整理しています。該当箇所を確認すると、 「OS、ミドルウェアの管理主体」欄に d
  「アプリケーションの管理主体」欄に e
  とあります。
• PaaSは“Platform as a Service”であり、ユーザ（自社）はアプリケーションを載せるだけで、OSやミドルウェアまでは 事業者 が提供・管理する形態です。問題文はこの一般的定義と一致しているため、d には「事業者」が入ります。
• 一方で、アプリケーション層は利用企業が自由に実装・運用することがPaaS最大の特徴です。したがって、e には利用者側を示す「自社」が入ります。
• 表2の他欄と比較しても整合性が取れます。IaaS列では「OS、ミドルウェアの管理主体」が“自社又は事業者”、「アプリケーションの管理主体」が“自社”となっており、PaaS列はこれより一段階サービス範囲が広い（＝事業者側の責任範囲が増える）ため、上記の結論と矛盾しません。

誤りやすいポイント

• 「PaaS＝OSだけ提供」と思い込み、アプリケーション管理主体まで“事業者”と誤記する。
• IaaS/PaaS/SaaS のサービス責任範囲を丸暗記しているが、設問の“管理主体”が「自社か事業者か」を問う点を見落とす。
• 「管理主体＝利用者部門」と解釈し、“自社”ではなく“各部門”など別表現を記入してしまう。

FAQ

解答の論理構成

1. 稼働率と停止時間の関係
   表2には稼働率の例として
   ――「エンドユーザから見たサービスの稼働率　99.9%以上（SLAに依存）」――
   とあります。稼働率 99.9 % とは “全提供時間の 0.1 % までは停止して良い” という意味です。
2. 1 か月の総提供時間を分で求める
   問題文の条件より
   ・1 か月＝30日
   ・1 日＝24時間
   よって総時間は
   $30\times 24=720\text{時間}$
   分に直すと
   $720\times 60=43200\text{分}$ です。
3. 許容される停止時間
   停止許容率 0.1 % を掛けます。
   $43200\times 0.001=43.2\text{分}$
4. 秒以下は切り捨て
   43.2 分 → 43 分 が最大停止時間となります。

誤りやすいポイント

• 0.1 % を 0.01 と勘違いして 432 分としてしまう。
• 1 か月を 31 日、あるいは 4 週間（28 日）で計算してしまう。
• 総時間を分ではなく時間のまま 0.1 % を掛けてしまい、43.2 時間と誤答する。
• 千分率を掛けた後に “四捨五入” して 44 分としてしまう。問題文は「秒以下は切り捨て」と明示しています。

FAQ

解答の論理構成

1. 【問題文】の図4で、クラウド利用時の問題(3)として「クラウドサービス上のデータの消失」が示され、これに対し S主任は下線②で「②R社においてデータのバックアップを行う」と述べています。
2. 同じ段落には「メールサービスとグループウェアサービスをクラウドサービスに切り替えた場合」とあり、メール本文やスケジュールのような利用データはクラウド側で保持されることを前提にしています。
3. クラウドサービスでメールやグループウェアを利用する際、ユーザがサービスを利用するための情報は「利用者ID」と「パスワード」、すなわち“アカウント情報”です。これが失われると利用者はクラウドにアクセスできず、業務継続が不可能になります。
4. よって、メール・グループウェアの内容自体ではなく「クラウドサービス利用者のアカウント情報」をR社側で別途バックアップする必要があると結論づけられます。

誤りやすいポイント

• メール本文や予定表データを挙げてしまう。設問は「メールやグループウェアのデータ以外」と明記されており対象外です。
• 「設定ファイル」「アクセスログ」などとするケース。これらは消失しても再設定や再取得が可能であり、まず復旧すべき最重要データとは位置づけにくいです。
• 「SLA」「契約書」を答える誤解。文脈はサービス運用上の“データ”のバックアップであり、契約文書は対象外です。

FAQ

解答の論理構成

1. 下線③では、 “③受託業務に係る内部統制に関する監査”
   と明記されています。
2. “受託業務に係る内部統制”を評価する代表的な国際基準は「SAS 70」で、現在は後継の「SSAE16（SOC1）」に引き継がれています。
3. 解答群の中でこれに該当するのは
   “ウ：SAS 70(SSAE16)”
   だけです。
4. 第三者認証・監査取得の事業者を選ぶことで期待できる効果は、 “管理策が規程どおり運用されているか”
   “継続的に改善が図られているか”
   などを外部の専門家が定期的に確認する点です。
   よって模範解答の
   “事業者の定めた管理策が、適切なマネジメントに基づいて運用されていること”
   に帰着します。

誤りやすいポイント

• “ISO/IEC 20000”はITサービスマネジメント全般の運用基準であり、内部統制報告書とは目的が異なります。
• “PCI DSS”はカード情報保護の業界標準で、クラウド全体の内部統制保証には直接結びつきません。
• “情報セキュリティ監査基準”は国内の情報セキュリティ対策の有無を調べる枠組みであり、委託業務の内部統制評価を目的としたSAS 70 とはスコープが違います。
• “内部統制”というキーワードを見落とすと、漠然と“セキュリティ”に連想して別の基準を選択してしまうケースがあります。

FAQ

解答の論理構成

• 【問題文】には、携帯端末の特徴として「PCとの連携（無線LAN又はUSB経由）」と明記されています。これはスマートフォンなどが USB ケーブルで PC に接続できる機能を示します。
• さらに、W課長が指摘した下線④では「携帯端末の機能を用いて従業員の貸与PC上のデータに直接アクセスが可能である」とあります。
• “直接アクセス”という表現はネットワークを介さず PC のストレージへ物理的に到達する手段を意味し、USB 接続ならば携帯端末をリムーバブルメディアとしてマウントし、ファイルの取得・書込みが可能になります。
• したがって、貸与PCの USB ポートにスマートフォンを挿すだけで、ネットワーク制御や FW を経由せずにデータを抜き出せる恐れがあるため、模範解答は「携帯端末をPCのUSBポートに接続する」となります。

誤りやすいポイント

• 無線 LAN テザリングと混同し「スマートフォンの無線 AP 機能を使う」と書いてしまう。これはネットワーク経由の話であり“PC 上のデータに直接アクセス”とはずれます。
• Bluetooth 連携を挙げるケース。Bluetooth でもファイル転送は可能ですが、問題文が強調するのは「USB経由」であり、迷う必要のない代表的手段です。
• “USB メモリにコピー”とだけ書くと、携帯端末を介していることが抜け落ち、設問が求める“携帯端末の機能”を説明できなくなります。

FAQ

解答の論理構成

1. 目的の確認
   表3の下線部には「⑤個々の個人所有携帯端末の脆弱性を一括で修正することは困難」とあり、各端末ごとの脆弱性対策が課題であると分かります。
2. 必要な情報の特定
   脆弱性は端末のハードウェア仕様と「OS 及びアプリケーションに最新の脆弱性対策パッチを適用する」（図9‐8.5(1)）ことに依存します。したがって、 ・どの端末か（＝機種）
   ・どのOSか（バージョンを含む）
   を把握しない限り、適切かつ十分な脆弱性情報を提供できません。
3. 申請内容の決定
   利用申請時に「機種とOSのバージョン」を届け出させれば、管理者は公開されている脆弱性情報を突合でき、利用者へ的確に伝達できます。
4. 結論
   よって、申請時に「従業員の個人所有携帯端末の機種とOSのバージョンを申請させる」とする解答になります。

誤りやすいポイント

• 端末のシリアル番号やIMEIなど詳細過ぎる情報を答えてしまう。脆弱性情報と直接の関連は薄く、過剰です。
• 「アプリ一覧」だけを要求すると勘違いするケース。OSバージョンが分からなければパッチ情報は提供できません。
• 「端末所有者の連絡先」を挙げるミス。連絡先は既に人事情報で把握していることが多く、本質ではありません。

FAQ

解答の論理構成

1. f について
   • 図10―1(3) に「クラウドサービス用のパスワードは、社内の情報システム用のパスワード及び f パスワードとは別のものにする。」とあります。
   • ここで “社内の情報システム用のパスワード” と対比させる第三のパスワードは、図8・図9で新たに利用が許可された「個人所有携帯端末」に関するものしか登場しません。
   • よって f は「個人所有携帯端末用の」が適切です。クラウド用と端末用を分離しておくことで、端末紛失時にクラウド側まで一気に侵害されるリスクを低減できます。
2. g について
   • 図10―2(2) に「メールの受信（バックアップ及びリストアを含む）のためのプロトコルとして g over SSL を用いる。」とあります。
   • バックアップ／リストアを含め“サーバ上にメールを残したまま多端末同期”という要件を満たす代表的な受信プロトコルは “IMAP4” です。
   • “POP3” では既読管理やフォルダ同期が弱く、本文の要件に合致しません。従って g は「IMAP4」と判断できます。

誤りやすいポイント

• 「POP3 over SSL」でも暗号化は可能ですが、図10(2) に示されたバックアップ／リストアを“サーバ側で”完結させたいという文脈を読み落とすと誤答になりがちです。
• f を「貸与ＰＣ用の」と誤記するケースがあります。貸与ＰＣは“社内の情報システム用のパスワード”に含まれるので二重カウントになり不適切です。
• “個人所有携帯端末用のパスワード”は画面ロックだけでなく端末内アプリ起動やストレージ暗号化パスワードを総称している点を見逃すと意味を取り違えやすいです。

FAQ

解答の論理構成

1. 図9のポリシ追加案では、携帯端末について「OS に対し、⑥インターネットに流布しているツールなどを利用した改造を行わない」と定めています。
2. 一般にこの種の改造（いわゆる root 化や Jailbreak）は、端末メーカーや OS ベンダが設計したアクセス制御を解除し、アプリケーションに本来与えられないシステム権限を付与します。
3. その結果、利用者が意図しないプログラムやマルウェアも同じ高い権限で動作でき、ストレージ内の機密情報や通信内容を自由に閲覧・改変できるようになります。
4. 従来は OS のサンドボックス機構により隔離されていた攻撃が直接成立するため、ウイルス感染・不正操作のリスクが急増します。
5. 以上から、改造が「携帯端末メーカーの設定したセキュリティ機構が無効化され、一般のアプリケーションが本来利用できない権限で動作」できる状態を招き、ウイルスに感染しやすくなると説明できます。

誤りやすいポイント

• 「ツールを使った改造＝単なるカスタマイズ」と誤解し、権限昇格によるセキュリティ機構の無効化に触れない。
• 感染経路を“改造ツールそのもの”に限定し、改造後にあらゆるアプリが高権限で動作できる点を見落とす。
• PC の管理権限と同一視してしまい、モバイル OS が前提とするサンドボックス方式の破壊という本質を逃す。

FAQ

解答の論理構成

1. 下線部④では「携帯端末の機能を用いて従業員の貸与PC上のデータに直接アクセスが可能である」と指摘しています。すなわち重要データの保存場所は「貸与PC上」です。
2. インシデント調査の結果、従業員が「貸与PCと携帯端末とを無線LAN機能で接続し、貸与PCから携帯端末及び携帯電話事業者網経由でクラウドサービスや外部のサイトにアクセス」していたと判明しました。
3. この接続形態では、社内FW・プロキシを経由しないためメール添付やWebアップロードなどでデータを社外へ送信しても検知されません。
4. したがって想定される漏えいは、貸与PCに格納された重要データが、社内ネットワークを経ずに
   「貸与PC →（アドホック無線LAN）→ 個人所有携帯端末 → 携帯電話事業者網 → インターネット」
   という経路で外部に流出するケースになります。
5. 以上より模範解答は「貸与PCの中にある重要なデータが無線LANと個人所有携帯端末を経由して社外に故意に送信される」となります。

誤りやすいポイント

• 漏えい源を「社内サーバ」と誤認し、場所を間違える。④で明示されているのは「貸与PC上」です。
• 経路を「公衆無線LAN」や「社内LAN」とするミス。実際は携帯端末の無線LAN機能と携帯電話事業者網による経路です。
• 「偶発的漏えい」と決め付ける誤答。本文は「回避していた」「故意に送信」など意図的行為を想定しています。

FAQ

解答の論理構成

1. 事象の把握
   • 問題文には「貸与PCと携帯端末とを無線LAN機能で接続し、貸与PCから…アクセスしていた」ことが判明したとあります。
   • これによりプロキシ経由の制御を回避し「⑦重大なセキュリティ事故」が発生し得ると示唆されています。
2. ポリシに不足している禁止事項
   • 図9では個人所有携帯端末の改造禁止や脆弱性対策は規定されているものの、貸与PCとの無線直結を禁じる条項がありません。
   • したがって「個人所有携帯端末と貸与PCと無線LANで接続しない」という項目を追加し、物理層での経路遮断を明文化する必要があります。
3. 技術的対策の導出
   • 既存環境には「ディレクトリサーバのもつ機能との連携によって、利用者パスワードの安全性やスクリーンセーバの設定などが一元管理」とあります。
   • 同じ管理基盤を用いれば、グループポリシーもしくは端末管理設定で「貸与PCの無線LAN機能を無効化」できます。
   • これによりユーザが勝手にアクセスポイントへ接続する経路自体を物理的に遮断でき、ポリシ違反を技術で防げます。
4. 解答
   • 項目：個人所有携帯端末と貸与PCと無線LANで接続しない
   • 技術的対策：ディレクトリサーバとの連携によって貸与PCの無線LAN機能を無効にする

誤りやすいポイント

• 「無線LAN利用禁止」とだけ書くと、社外の正規公衆無線LANからのクラウド利用まで遮断してしまい、要望と矛盾します。
• 技術的対策を「ファイアウォール設定」と誤答しがちですが、問題は社内ネットワークを経由しない直結なので無効です。
• ポリシ追加と技術対策を混同し、どちらか片方のみを解答して減点となるケースがあります。

FAQ