情報処理安全確保支援士 2009年 秋期 午後1 問01

解答の論理構成

• 問題文には「メールでは価格表や提案書などの機密データを社内関係者とやり取りすることが多い。」とあります。機密データを端末に保存する場合、本質的に求められるのは第三者からの漏えい防止＝機密性の確保です。選択肢のうち機密性を直接高めるものは「ウ：暗号化」だけです。したがって a には暗号化が入ると判断できます。
• 一方、メール送信時に注意すべき代表的なヒューマンエラーは送信先の誤指定です。選択肢でこれに該当するのは「イ：あて先ミス」です。問題文中でも、携帯電話への転送が原因で「特定の顧客にしか開示しない価格表の漏えい」が発生したと記されており、誤送信防止が再発防止策として重要であることが読み取れます。よって b はあて先ミスとなります。

誤りやすいポイント

• 圧縮（ア）と暗号化（ウ）の取り違え
  圧縮はファイルサイズ削減が目的で、機密性を直接高めるものではありません。
• 改ざん（エ）やディジタル署名（カ）との混同
  これは完全性・真正性の対策であり、漏えい（機密性）対策としては不十分です。
• メール送信チェックを「改ざん」だと誤解
  送信直後に改ざんの有無は通常確認できません。実務で直前確認できるのは宛先と添付ファイルです。

FAQ

解答の論理構成

1. 事故内容の整理
   • 下線①には「会社貸与の携帯電話の紛失」「携帯電話端末にメールが保存」「キーロック解除用の暗証番号が設定されていなかった」「特定の顧客にしか開示しない価格表の漏えい」が記述されています。
2. 規定と照合
   • 【図1】5.9(2)
     「端末の利用者を限定するために、利用者認証機能を有効にしなければならない。…携帯電話であれば暗証番号による端末操作制限機能やデータ保護機能を有効にしなければならない。」
     → 暗証番号未設定という事実はこの規定違反です。
   • 【図1】5.9(3)
     「端末上で機密データを取り扱う場合、ファイル保存中は重要度に応じてaなどの処理をとり、取扱いが不要となった時点でデータを削除しなければならない。」
     → 価格表という機密データがメールとして端末に残存しており、漏えいに至ったため、この規定の“保存中の保護”と“不要時の削除”が守られていません。
   • 【図1】5.13(5)
     「やむを得ず機密データをメールで送信する場合にはaしなければならない。」
     → 価格表がメールで送受信されていたにもかかわらず、本文中に暗号化などの対策を講じた記述がないため、本規定も不十分と判断できます。
3. したがって、問われている三つの規定は
   ① 5.9(2)
   ② 5.9(3)
   ③ 5.13(5)
   となります。

誤りやすいポイント

• 5.13(2)「私有メールアドレスへの転送禁止」を選びたくなるが、本件は「従業員用メールアドレス」への転送であり該当しません。
• 5.9(1)「会社貸与端末の利用限定」は満たしているため違反ではありません。
• 端末紛失＝即5.9(4)と短絡しがちですが、5.9(4)は「速やかな報告義務」。本文には「情報システム部門に直ちに報告された」とあるため遵守されています。

FAQ

解答の論理構成

• 【問題文】の下線部①には「携帯電話を紛失したこと、携帯電話端末にメールが保存されていたこと」とあるため、端末内には送受信メールだけでなく連絡先情報も格納されていたと推測できます。
• 営業部門は「顧客への訪問回数を増やすことによる受注拡大」を重視しており、顧客との連絡用に「会社貸与の携帯電話」を常時携行しています。営業担当者が最も頻繁に利用する顧客情報は、電話をかける際に使う電話番号です。
• したがって、漏えいした可能性が高い情報は「顧客電話番号」と判断できます。
• 次に、漏えい後に「被害を受ける可能性がある顧客の特定を迅速に行える」仕組みが必要です。紛失した端末が戻らなくても確認できるよう、端末に保存されるアドレス帳を安全にサーバへバックアップしておけば、影響範囲の把握を即時に行えます。暗号化したバックアップであれば機密保持も両立できます。

誤りやすいポイント

• 価格表と同じくメール本文や添付ファイルを答えてしまい、「顧客の情報」という条件を満たさない。
• 「顧客のメールアドレス」を選ぶと7字を超えて要件を満たさない。
• 対策として“リモートワイプを行う”など漏えいを防ぐ手段だけを書き、影響顧客を“迅速に特定”する観点を欠落させる。
• 単に「バックアップする」とだけ書き、どこに保管し、どう活用するかまで触れず具体性が不足する。

FAQ

解答の論理構成

1. 事故の原因整理
   事故では「①会社貸与の携帯電話の紛失による情報漏えい事故が発生した」とあるように、端末自体の喪失が情報漏えいを招いています。
2. 対応可能な管理機能の存在
   本文には「②A社で使用している携帯電話の場合、盗難・紛失が起きたときの事後対策を情報システム部門が施せる」と明記されています。ここでいう“事後対策”とは、回収不能になった端末に対し、遠隔操作で機密情報を守る措置を講じることを指します。
3. 具体的に想定される措置
   端末が手元にない状況で機密データを守る代表的な手段は
   ・遠隔で端末を操作不能にする（リモートロック）
   ・遠隔で端末内データを抹消する（リモートワイプ）
   の二つです。これらは多くの携帯電話サービスが標準またはオプションで提供している管理機能であり、情報システム部門が“施せる”手段に合致します。
4. よって解答は、管理者が遠隔でロック・消去を実行できる機能を挙げれば良いことになります。

誤りやすいポイント

• 「端末の暗証番号設定」だけを書くと“事前対策”であり、設問が求める“事後対策”を満たしません。
• 「GPS追跡」機能は所在確認には役立ちますが、漏えい防止には直接結び付かないため減点対象になりがちです。
• “携帯電話サービスによって提供”という条件を読み落とし、社内ツールやMDM（モバイルデバイス管理）製品名を書くと設問意図とずれます。

FAQ

解答の論理構成

1. 【問題文】の表には、Y社案の認証方式として
   「ポータルサーバにおいてSSLクライアント認証で認証する。電子証明書のコモンネーム(Common Name)には携帯電話のSIMカードを一意に識別できる情報が記載されている。認証時、ポータルサーバはLDAPサーバへの問合せを行い、登録済の従業員であることを確認する。」
   とあります。
2. ここで LDAP サーバは「登録済かどうか」を判定するための台帳です。判定キーには、証明書提示時にポータルサーバが取得できる情報を使う必要があります。
3. 証明書提示時に必ず送られてくるのは証明書自体であり、その中でも利用しやすい一意情報が「コモンネーム(Common Name)」です。
4. したがって、従業員固有のコモンネーム値を LDAP に登録しておけば、ポータルサーバは照合結果によって「登録済み従業員のみ許可」という制御を実現できます。
5. 以上より、LDAP に追加登録する内容は「携帯電話の電子証明書のコモンネーム」となります。

誤りやすいポイント

• 「従業員ID」や「メールアドレス」を登録すると考えてしまう。SSLクライアント認証では証明書の提示が先なので、照合キーは証明書内の情報である必要があります。
• 「端末電話番号」や「SIMカード番号」などをそのまま登録しようとする。これらが LDAP に格納されていても、証明書認証処理で直接取得できないため照合できません。
• 「証明書ファイル全体」を登録すればよいと思い込む。LDAP 側で扱いやすく、かつ一意性が保証されるのはコモンネームであり、ファイル全体を格納する必要はありません。

FAQ

解答の論理構成

1. 表の下線部“③”では
   「メールサーバにログインするための利用者IDとパスワードは、ポータルサーバとメールサーバ間でID連携するので、携帯電話からは直接入力しない」
   とあり、携帯電話側での資格情報入力が不要です。
2. したがって携帯電話を盗難・紛失されても、端末さえ操作できればポータルにアクセスしメールが閲覧される恐れがあります。
3. 図1の規定「5.9(2)　端末の利用者を限定するために、利用者認証機能を有効にしなければならない。…携帯電話であれば暗証番号による端末操作制限機能やデータ保護機能を有効にしなければならない。」
   ─ この“暗証番号”が未設定だと、前述②「携帯電話端末にメールが保存されていたこと、そして、キーロック解除用の暗証番号が設定されていなかったこと」と同じ事故が再発します。
4. よって“遵守が不十分”な箇所は「5.9(2)」となり、対策は暗証番号（端末操作制限）の確実な設定・確認を徹底することです。

誤りやすいポイント

• 「③ID連携により資格情報入力なし」＝安全、と短絡して端末側認証を軽視しがち
• 5.13(2)の“私有メールアドレスへの転送禁止”と混同してしまう
• 端末認証と通信経路暗号化（SSLクライアント認証）を同列に捉え、端末PIN設定の必要性を見落とす

FAQ

解答の論理構成

1. 課題は「図2中の(α)と(β)で示したFV間」でアプリケーション限定の IPsec を掛けることです。
   図2では、(α)側のFVは「Z社が運営するサービス基盤」へ、(β)側のFVは「A社データセンタ」のDMZ‐内FVへ接続しています。したがって、ここを流れる通信は “Z社提案ポータルサーバ ↔ A社内サーバ群” のトラフィックです。
2. 表の「Z社」欄を見ると、サービス基盤側に「ポータルサーバ」を置き、「サービス基盤とサーバ用セグメント間はインターネットVPNで接続する」とあります。つまり(α)―(β)間で最も重要なのはポータルサーバがA社のメールサーバへアクセスするときの通信です。
3. では、そのアクセスはどのプロトコルか。表の「Y社」欄に
   「① ポータルサーバからメールサーバにIMAPで接続し、メールを閲覧する。」
   と明示されています。Z社欄は空欄ですが、どちらの提案も“携帯電話端末にメールを保存せず、ポータルサーバ経由で閲覧させる”という同一要件を満たすシステムであるため、メール閲覧プロトコルは同じく IMAP と判断できます。
4. 以上より、IPsec で暗号化すべきアプリケーション通信は
   ・サーバ間：Z社提案ポータルサーバ ↔ メールサーバ
   ・プロトコル：IMAP
   となります。

誤りやすいポイント

• 「LDAP問い合わせ」や「ワンタイムパスワード認証」の通信を選んでしまう
  → これらはA社内部で完結しており(β)側のFVを越えないので対象外です。
• 「携帯電話 ↔ ポータルサーバ」を選択する
  → ここは携帯電話事業者網＋SSLで保護済み。問われているのは(α)―(β)間です。
• POP3 と誤答する
  → 表の引用「① ポータルサーバからメールサーバにIMAPで接続し、メールを閲覧する。」が根拠であり、POP3 は使われていません。

FAQ

解答の論理構成

1. 事故原因の把握
   • 問題文では「営業部門の部員の中には、会社貸与の携帯電話の従業員用メールアドレスにメールを転送する者がいた」ことが明示されています。
   • さらに「①会社貸与の携帯電話の紛失による情報漏えい事故が発生した」とあり、転送されたメールが端末内に残存していたため顧客情報（価格表）が漏えいしました。
2. 既存規定の抜け穴
   • 情報セキュリティ対策基準の 5.13(2) は“私有メールアドレス”への転送を禁止しているものの、会社貸与端末の従業員用メールアドレスへは言及していません。
   • 事故はこの盲点を突く形で起こっており、同じ転送行為を放置すれば再発リスクが残ります。
3. 追記すべき内容
   • 事故原因を直接断つには、従業員が自らメールを端末に転送できないよう明文化する必要があります。
   • よって「業務目的のメールを会社貸与の携帯電話の従業員用メールアドレスに転送することを禁止する。」と追記すれば、端末保存→紛失→漏えいの連鎖を防止できます。
4. 解答の導出
   • 事故報告と規定のギャップを整理し、転送禁止対象を“私有アドレス”から“会社貸与携帯の従業員用アドレス”まで拡張するのが合理的であるため、提示の解答に至ります。

誤りやすいポイント

• 「私有メールアドレス禁止」を強化すれば良いと勘違いし、会社貸与端末を見落とす。
• 転送自体を全面禁止と誤記し、業務上の正当な自動転送（バックアップ等）まで阻害してしまう。
• 追記先を 5.13(1) と誤認し、アドレス利用ルールと転送ルールを混同する。

FAQ