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

解答の論理構成

1. 【問題文】には次の記述があります。

   ①各国及び各地域の個人情報保護に関する法規制
   設問は、この下線①について「2018年5月25日に適用が開始された欧州連合の規則の略称を英字4字で答えよ」と求めています。

2. 【問題文】にある日付「2018年5月25日」と「欧州連合」という条件に合致する個人情報保護規則は、欧州連合一般データ保護規則「General Data Protection Regulation」です。
3. この規則の略称は国際的に「GDPR」の4文字で統一されています。
4. 以上より、解答は「GDPR」となります。

誤りやすいポイント

• 「EU指令（Directive）」と混同し、旧指令「95/46/EC」や ePrivacy Directive の略称を書いてしまう。
• ドイツ語表記「DSGVO」やフランス語表記を記入してしまい英字4字要件を満たさない。
• 米国の「CCPA」や日本の「APPI」を欧州規則と誤認する。
• 2018年施行を「2020年」「2016年」と覚え違いをして別制度を連想する。

FAQ

解答の論理構成

1. 【問題文】の基本要件には
   「・R&D情報は、物理的な入退室管理が行われているプロジェクトルーム内に配置されたプロジェクト専用サーバに保管する。」
   と明記されています。
2. 条件2は
   「条件2　プロジェクト専用サーバ」
   を IaaS C へ移行しない理由を検討する箇所です。
3. プロジェクト専用サーバをクラウド環境へ移行すると、物理的に「プロジェクトルーム内」に置くことが不可能になり、当該基本要件を満たせなくなります。
4. したがって、解答は上記要件そのものを示す内容になります。

誤りやすいポイント

• 「生産関連サーバを国内二拠点に配置」の要件と混同し、誤って輸出管理規制に触れる記述を書いてしまう。
• 「プロジェクト専用サーバには、プロジェクトルーム内のプロジェクト専用PCからだけアクセスさせる。」を解答に選び、ネットワーク要件と取り違える。
• “クラウドでも論理的に部屋を分ければ良い”と考え、物理的入退室管理というキーワードを落としてしまう。

FAQ

解答の論理構成

1. 基本要件の確認
   問題文には次の三つの要求があります。
   ・「生産関連サーバは、X社の工場及びデータセンタに配置する。」
   ・「生産関連サーバは、重要インフラ設備の製造の事業継続のために、バックアップを他の工場又はデータセンタに配置する。」
   ・「同じ重要インフラ設備を製造する工場及び生産関連サーバは同一の国又は地域内の2か所以上に配置する。」
2. クラウド移行時の前提
   設問は「生産関連サーバをクラウド環境に移行し、かつIaaS Cの本文中に示したサービスを全て利用した場合」を想定しています。
   IaaS Cのサービス仕様には、 「日本国内のデータセンタが被災した場合はシンガポールのデータセンタでサービスが継続される。」
   という災害対策オプションが含まれます。
3. 各基本要件が満たせない理由
   (1) 生産関連サーバをIaaS Cへ置くと物理的所在地が「X社の工場及びデータセンタ」ではなくなります。したがって「生産関連サーバは、X社の工場及びデータセンタに配置する。」を満たせません。
   (2) バックアップもIaaS C側に置く想定のため、「バックアップを他の工場又はデータセンタに配置する。」を満たせません。
   (3) 災害対策により自動的に「シンガポールのデータセンタ」に切り替わるため、「同一の国又は地域内の2か所以上に配置する。」が守れなくなります。
4. IaaS C仕様が与える決定的影響
   上記(3)の直接要因は、IaaS Cの災害対策オプションにある「日本国内のデータセンタが被災した場合はシンガポールのデータセンタでサービスが継続される。」という仕様です。これにより日本国内という地域を越えてしまい、要件を満たせなくなります。

誤りやすいポイント

• 「データセンタ間の通信は課金されない。」を根拠に誤って要件未満と判断する受験者がいますが、通信コストは今回の基本要件とは無関係です。
• IaaS Cに置いたとしても「同一の国又は地域内」に複数ロケーションがあるだろうと想像してしまいがちですが、災害対策で海外へフェイルオーバする仕様が示されているため不適合となります。
• バックアップをクラウド上で地理的冗長化すれば要件を満たすと早合点し、工場／自社データセンタという限定条件を見落とすケースも頻発します。

FAQ

解答の論理構成

1. X社はオンプレミス側の全機器に「プライベートIPアドレスを割り当てる。」と明記しています。
   引用：【問題文】「・X社のシステムの機器には、プライベートIPアドレスを割り当てる。」
2. 一方、IaaS C には利用者が自由に使えない「予約されているプライベートIPアドレス」が存在します。
   引用：【問題文】「・あらかじめ予約されているプライベートIPアドレスがあり、利用者はそれらを使うことができない。」
3. もし X社で既に使っているプライベートアドレス帯と、IaaS C が予約している帯が重複すると、 ・ルーティングで到達できない宛先が発生
   ・誤配送や通信断、ファイアウォール誤動作
   などの衝突が起こり得ます。これは「サービス仕様の制約から起こる問題」に該当します。
4. そこで「FWのNAT機能を用いて一部のアドレスを変換」し、IaaS C との境界で重複を回避する設計を採用しました。
   引用：【問題文】「FWのNAT機能を用いて一部のアドレスを変換することにした。」
5. 以上から、設問が求める「回避したい問題」とは
   「X社で使用中のプライベートアドレスと IaaS C で予約済みのプライベートアドレスが重複する」
   ことになります。

誤りやすいポイント

• NAT＝グローバル⇔プライベート変換だと短絡し、重複問題に思い至らない。
• IaaS C の「課金されない閉域網」や「災害対策サービス」の方に着目し、帯域制御やDR対策と混同する。
• 「予約済み＝専用に割り当てられる」と誤解し、むしろ重複しないと考えてしまう。

FAQ

解答の論理構成

1. 認証連携の仕組み
   • 問題文では、複数の認証サーバとSaaS間を
     「“SAML 2.0プロトコルで通信”」
     「“SPNEGOプロトコルによって…認証サーバA1が発行するトークンを用いて利用者認証”」
     と記載しています。いずれもトークンを介して認証結果を他システムへ受け渡す方式です。
2. トークンの再利用
   • 「認証サーバA1が発行するトークン」や「認証サーバB1が発行するトークン」が他システムに提示されるため、利用者は追加のID／パスワード入力を求められません。
3. もたらされる利便性
   • 認証サーバ間・SaaS間でトークンを共有することで、利用者は初回ログイン後に同一セッション情報で各サービスへ横断的にアクセスできます。
4. 以上より、「一度のログインで全システムにアクセスできる」というシングルサインオン(SSO)の利便性が導かれます。

誤りやすいポイント

• SAML 2.0 と SPNEGO の違いを問う設問ではないのに、プロトコル特徴を詳述してしまい本質の利便性を外す。
• 多要素認証の有無と混同し、「安全性向上」とだけ書いてしまう。
• 「IDを統合管理できる」と組織側の管理メリットを中心に記述し、利用者視点を欠く。

FAQ

解答の論理構成

1. まず案1（現行構成）では、社内PCからオンプレミスの業務サーバへは社内ネットワーク経由で直接アクセスする。したがって、図2中の「ク」「ケ」「コ」「サ」を通過せず、これらの機器・回線には業務トラフィックが流れない。
2. 案2では「認証サーバB1をIaaS Cに移行する」と明記されている。
   • 本問の認証サーバB1は「リバースプロキシ型の認証サーバ」であり、認証後も業務データを中継する。
3. そのため社内PCがオンプレミス側の業務サーバを利用する場合、経路は
   社内PC → FW1（ケ）→ IPS（ク）→ インターネット（コ）→ FW2（サ）→ 認証サーバB1（IaaS）→ オンプレミス業務サーバ
   となり、往復とも「ク・ケ・コ・サ」を必ず経由する。
4. どの業務サーバがこの影響を受けるか。
   • Linux業務サーバについては、問題文に「従業員がWebブラウザを用いてLinux及び商用UNIXの業務サーバにログオンする際は、認証サーバB1による利用者認証が行われる」とあるので確実に該当する（図2中「ウ」）。
   • Windows業務サーバについては、今回B1をSPNEGO対応にバージョンアップし、「認証サーバB1が認証サーバA1と通信し、認証サーバA1が発行するトークンを用いて利用者認証を行うようにする」と設計している。したがってブラウザ経由のWebアプリケーションはB1経由となり、同じく経路が長くなる（図2中「イ」）。
5. IaaS側の業務サーバ（「エ」「オ」）はB1と同一クラウド内にあるため、社内→クラウド→業務サーバという経路は案1と大差なく、負荷増大には直結しない。
6. 以上より、案2で負荷が増える業務サーバは「イ」「ウ」、負荷が高くなる構成要素は通信経路上で重複利用される「ク」「ケ」「コ」「サ」となる。

誤りやすいポイント

• 認証サーバB1を「認証だけを行うサーバ」と誤解し、認証後の業務データはB1を通らないと考えてしまう。問題文で明示されている「リバースプロキシ型」を見落とさないこと。
• Windows業務サーバ（イ）はA1で認証するから影響なし、と短絡的に判断してしまう。設計変更によりWebアクセスはB1経由になる点が要注意。
• 「インターネット（コ）」だけが混雑すると考え、FWやIPSの負荷を忘れるケース。通信経路図を矢印ごとに追うことが有効。

FAQ

解答の論理構成

1. 本文には、NIST CSF におけるティアの説明として
   「下線②フレームワークインプリメンテーションティア（以下、ティアという）1からティア4までの段階を定義しており、ティア4が最も高い段階である。」
   と記載されています。
2. NIST CSF 公式文書の定義は、上記①～④の順に成熟度が高まる構造です。一般に
   ・Tier 1＝Partial（部分的）
   ・Tier 2＝Risk-Informed（リスク情報を活用）
   ・Tier 3＝Repeatable（繰返し適用可能）
   ・Tier 4＝Adaptive（適応的）
   という対比が使われます。
3. 解答群には
   「イ：部分的である(Partial)」
   「ウ：リスク情報を活用している(Risk Informed)」
   「ア：繰返し適用可能である(Repeatable)」
   が提示されています。
4. よってティアと選択肢を対応付けると
   ティア1 → 「イ：部分的である(Partial)」
   ティア2 → 「ウ：リスク情報を活用している(Risk Informed)」
   ティア3 → 「ア：繰返し適用可能である(Repeatable)」
   となり、模範解答と一致します。

誤りやすいポイント

• 「ティア3＝Adaptive」と勘違いし、Tier3 と Tier4 を取り違えるケースが多いです。Adaptive は最上位のティア4です。
• 「Risk-Informed」を “リスクに対応できる” と訳し Tier3 と連想してしまう誤答が見受けられます。Risk-Informed はあくまでリスクを“把握・考慮”している段階 (Tier2) です。
• ｢繰返し適用可能｣という表現を下位レベルだと思い、Tier1 と誤結び付けるミスが発生しやすいです。プロセスが再現性を持つ時点で組織的成熟度は Tier3 になります。

FAQ

解答の論理構成

1. 運用サービスの対象範囲を確認
   【問題文】には
   ・「運用サービス1　標準ソフトウェアに関する脆弱性情報を日次で収集する。」
   ・「運用サービス2 … 標準ソフトウェアのパッチ適用状況及びセキュリティ設定を日次で監視する。」
   とあり、脆弱性情報収集・監視の対象はあくまでも「標準ソフトウェア」に限定されています。
2. 標準外ソフトウェアが導入されている場合の影響
   標準外のソフトウェアは上記サービスの対象外であるため、 ・脆弱性情報の収集が行われない
   ・パッチ適用状況の確認・強制が行われない
   →結果として脆弱性が放置される可能性があります。
3. 以上より、不都合は「標準ソフトウェア以外は脆弱性管理されない」ことになります。

誤りやすいポイント

• 「標準ソフトウェア一覧に追加すれば良い」と考え、現時点の管理漏れのリスクを見落とす。
• パッチ管理だけでなく「セキュリティ設定」も対象外になることを忘れる。
• 製品Ｄの機能が自動で全ソフトを検出すると誤解し、対象範囲の制限を読み飛ばす。

FAQ

解答の論理構成

• 手作業・目視チェックは人が設定値を確認するため、ヒューマンエラーが入りやすく時間も掛かります。
• 【問題文】には、製品Dについて
  • 「エージェントソフトウェアが、サーバ又はPCにおけるパッチの適用状況及びセキュリティ設定パラメタの設定値を収集し、サーバソフトウェアに送信する。」
  • 「サーバソフトウェアが提供する管理画面において、必要なパッチ…及びPCの一覧を表示することができる。」
    と記載されており、機械的に情報を集めて一覧化する仕組みが備わっています。
• さらに「1回の操作で…必要なパッチを適用」「1回の操作で…設定値を指定した値に変更」とあるため、複数端末をまとめて迅速に処理できます。
• 以上から、製品Dを用いることで
  ①自動収集・比較により誤判定が起きにくい（＝正確）
  ②一覧表示と一括操作により短時間で処理できる（＝速い）
  という二つの利点が導かれ、「正確である」「作業が速くできる」が解答となります。

誤りやすいポイント

• 「管理画面で一覧を表示できる」から“可視化できる”とだけ書くと、手作業でも一覧表を作れば可視化可能という反論が成立し得ます。自動収集による正確性まで触れる必要があります。
• “自動的にパッチを適用できる”と書くと、「適用可否は管理者が操作する」点を見落としやすく、利点の本質（スピード・正確性）から外れます。
• 15字以内に収める制約を意識するあまり、意味が曖昧な語（例：効率化）だけを書いてしまうと部分点の対象になりにくいです。

FAQ

解答の論理構成

1. まず各案での認証サーバの配置を確認します。
   ・引用：「案A　現行の構成のまま、オンプレミス環境に認証サーバB1を配置する。」
   ・引用：「案B　認証サーバB1をIaaS Cに移行する。」
   ・引用：「案C　新たにIaaS Cに認証サーバB1と同じ製品を用いた認証サーバB2を配置し…この場合、認証サーバB1がIdP、認証サーバB2がSPになる。」
   案Cでは Linux 業務サーバ（記号 D、B）に対し、IaaS 側の認証サーバB2が“リバースプロキシ型”で直接フロントに立つため、アプリケーション通信は IaaS 内で完結しやすくなります。
2. モバイル端末経由のトラフィックの特徴を整理します。
   ・引用：「モバイル端末が、X社のデータセンタに接続した後、認証サーバB1による利用者認証が行われ…トークンが発行された後、従業員は、IaaS C…にアクセスできる。」
   つまり VPN で社内 DC に入ったあとは、認証サーバを経由して業務サーバへ Web アクセスが継続的に流れます。リバースプロキシ型である B1／B2 が通信経路に残り続けるため、その所在がボトルネックになります。
3. 案Aで負荷が高まる通信を導出します。
   ・B1 がオンプレミスなので、Linux 業務サーバ D との間の全 Web トラフィックが
   (H または I) → VPN → B1 → インターネット → D → B1 → (H または I)
   と“往復2回”インターネットを横断します。
   ・案Cでは B2 が IaaS 内にあり
   (H または I) → VPN → インターネット → B2 → D
   と1回で済み、オンプレミス側の FW／IPS／WAN が半減します。
   従ってスマートフォン H とモバイルPC I から Linux 業務サーバ D への2組が対象です。
   ⇒ 案A：① H→D、② I→D
4. 案Bで負荷が高まる通信を導出します。
   ・B1 が IaaS 側に移ることで、オンプレミス Linux 業務サーバ B へは常に
   (G, H, I) → … → インターネット → B1 → 社内ネットワーク → B → B1 → インターネット → …
   と“往復2回”インターネット横断が発生。
   ・案Cは B1 がオンプレミスのままなので1回で済みます。
   社内PC G、スマートフォン H、モバイルPC I の3種類すべてが対象です。
   ⇒ 案B：① G→B、② H→B、③ I→B
5. 以上より模範解答のとおりになります。

誤りやすいポイント

• 認証が終わればリバースプロキシを通らなくなると誤解しやすい
  B1/B2 は「リバースプロキシ型」と明示されているため、認証後も Web 通信が継続的に通過します。
• VPN を張った時点で“インターネットを出入りしない”と考えてしまう
  社内 DC から IaaS へは別途インターネット経由となるため、FW・IPS の負荷を見落としがちです。
• 案Cでスマートフォン H の通信は改善されないと思い込む
  IaaS 内に B2 があることで、往復回数が減りオンプレミス側の負荷は確実に下がります。

FAQ

解答の論理構成

1. VPN 接続開始とトークンの前提確認
   ・問題文には「対策2 VPNサーバ及びVPNクライアントを導入し、モバイル端末にクライアント証明書を組み込む」とあり、VPN サーバはまずトークンの有無を確認する必要があります。
   ・よって VPN サーバは認証サーバ B1 に対して「認証サーバB1が発行したトークン要求」（行 カ）を出し、これが a になります。
2. スマートフォンから VPN サーバへの接続要求
   ・トークンが発行されていないことを確認した VPN サーバは、端末からの接続を受け付けるために「接続要求」（行 ウ）を受信します。これが b です。
3. 端末認証（クライアント証明書）
   ・VPN サーバは「クライアント証明書の要求」（行 イ）を送り（c）、スマートフォンは「クライアント証明書」（行 ア）を提示します（d）。
   ・図4には “クライアント証明書の検証” と明記されており、ここで端末認証が完了します。
4. トークン発行要求
   ・端末認証が済むと、VPN サーバはシングルサインオン用トークンを得るために「トークン発行要求」（行 オ）を認証サーバ B1 に送信します。従って e は行 オです。
5. 利用者認証（ID／パスワード）
   ・認証サーバ B1 は利用者を特定するために「利用者ID及びパスワードの入力要求」（行 ク）を VPN サーバ経由でスマートフォンへ返します（f）。
   ・スマートフォンは「利用者ID、パスワード」（行 キ）を送り（g）、B1 は問題文にある “認証サーバB1が発行するトークンを用いて利用者認証を行う” 処理として認証サーバ A1 との連携（図4のステップ10〜11）を行います。
6. トークンの発行
   ・利用者認証が成功したあとは「トークンの発行」（行 エ）を VPN サーバ経由でスマートフォンに返します。図4のステップ15「アクセス要求（認証サーバB1が発行したトークン）」につながるため、h は行 エです。
7. 以上から
   a：カ b：ウ c：イ d：ア e：オ f：ク g：キ h：エ が妥当となります。

誤りやすいポイント

• クライアント証明書と SAML トークンを混同する
  証明書は端末認証、トークンは利用者認証とアクセス制御で用途が異なります。
• 「利用者ID及びパスワードの入力要求」と「トークン発行要求」の送信先を逆にする
  トークンは認証サーバ B1 が発行するため、VPN サーバ→B1 が要求、B1→VPN サーバ が結果という流れを取り違えやすいです。
• “トークンの発行” をスマートフォン→VPN サーバ方向と誤解する
  発行主体は VPN サーバではなく認証サーバ B1 なので、VPN サーバ→スマートフォン方向が正しいです。

FAQ