情報処理安全確保支援士 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. 重要な前提（問題文からの要点）

• 「認証サーバB1は、Linux及び商用UNIX上で稼働するWebアプリケーションにアクセスする際の利用者認証に用いるリバースプロキシ型の認証サーバ」とあります。リバースプロキシ型であるため、Linux系Webアクセスは認証サーバB1（あるいは同等のプロキシ）がHTTP(S)経路上に入り、実際のWebサーバへの要求を仲介します。これが経路上の負荷増加のキーです。
• 案Cについて「新たにIaaS Cに認証サーバB2を配置し…認証サーバB1がIdP、認証サーバB2がSPになる」とあります。つまり案Cでは、IaaS側のWeb（D）へのアクセスはIaaS内のB2がプロキシ（SP）となり、実トラフィックはIaaS内で完結しやすい設計です。
• ネットワークの接続について「X社の各国及び各地域のデータセンタは、VPNを介してIaaS Cのデータセンタにアクセスする」とあります。社内PC（G）など社内ネットワーク起点のアクセスは、IaaSへはVPN経路を使う点を押さえます。

1. 案C（基準）のイメージ（比較の基準）

• IaaS上のLinux（D）へはIaaS内の認証サーバB2がSPとしてプロキシするため、クライアント→Dの多くの通信は「クライアント→IaaS（B2）→D（IaaS内）」で完結します。オンプレのLinux（B）へはオンプレのB1がプロキシします。つまり各サイドでプロキシが近接しているため、余分な往復が発生しません。

1. 案A（B1をオンプレに残す）の検討

• 案AではIaaS側にB2を置かないため、IaaSのLinux（D）へのWebアクセスもオンプレ側のB1がプロキシ役を果たす想定になります。リバースプロキシであるため、クライアントがDにアクセスする流れは次のようになります（代表例：スマートフォンH → D）。
  • H（スマートフォン）→ インターネット → FW1 → 認証サーバB1（オンプレ）で認証・プロキシ処理
  • 認証サーバB1 →（インターネットまたはVPN経路を介して）→ FW2 → IaaS → 業務サーバD
  • 応答は逆経路で戻るため、インターネット／FW等の長距離経路や境界機器が往復で処理を行います。
• 案CでのH→Dは「H→インターネット→FW2→B2→D（IaaS内完結）」で済むため、案Aではインターネットや境界機器が二重に関与し、負荷が増えます。
• 同様にモバイルPC Iについても同じ理由で負荷増となります。
• 社内PC GからDへは、問題文のVPNによる接続関係から案Cでも既にX社社内WAN→VPN→IaaSを通るため、案AでわざわざオンプレのB1を経由して二重に往復するケースは発生しても、設問の想定する「案Cと比べて明確に負荷が高くなる」主要な対象は外部発信のH/Iと判断されます（以降のまとめ参照）。

1. 案B（B1をIaaSに移行）の検討

• B1がIaaSに移ると、オンプレのLinux（B）は逆に「リモートにあるプロキシ（B1 in IaaS）」にフロントされます。したがってオンプレBに対するアクセスは次のようになります（代表例：社内PC G → B）。
  • G（社内PC）→ X社社内WAN → VPN → FW2 → 認証サーバB1（IaaS）で認証・プロキシ処理
  • 認証サーバB1 → FW1 → オンプレ → 業務サーバB
  • 応答は逆経路で戻るため、IaaS側とオンプレ側の境界機器や広域リンクを往復で処理させることになり、案C（オンプレBはオンプレのB1が担当）に比べて負荷が増えます。
• この影響は社内PC G、スマートフォンH、モバイルPC Iの全てからオンプレBへアクセスする場合に当てはまるため、G→B、H→B、I→Bが負荷増の対象になります。
• 一方、IaaS側のDへのアクセスはB1がIaaSにあるため案Cと同等にIaaS内で完結し、負荷増とはなりません。

1. まとめ（図3の記号での組合せ）

• 上の経路解析により、図3の記号で表すと以下になります。
  案A：
  　① クライアント：H、業務サーバ：D
  　② クライアント：I、業務サーバ：D
  案B：
  　① クライアント：G、業務サーバ：B
  　② クライアント：H、業務サーバ：B
  　③ クライアント：I、業務サーバ：B

誤りやすいポイント

• B1/B2の役割の取り違え：B1はリバースプロキシ型で「毎回のWeb要求の経路に関与する」点を見落とすと誤答します。認証のための一回限りのトークン交換だけが増えるのではなく、プロキシ位置が変わることでトラフィックの経路自体が変わります。
• 案Aで社内PC G→Dを誤って含める：G→Dは案CでもVPN経路でIaaSに到達するため、問題が想定する「明確な負荷増」の対象にならないと判断されます。説明の際に「どのリンク（Internet/FW/VPN）を何回通るか」を明確に書くと誤りを防げます。
• 案Bで「IaaSに移せば負荷は下がる」と単純に考える誤り：オンプレ側のサーバ（B）へのアクセスは逆に負荷が増えるため、どのサーバがどの地点にあるか（オンプレvs IaaS）を常に確認する必要があります。
• 認証プロトコル（SAML等）だけで判断する誤り：SAMLのようなIdP/SPのトークン交換は頻度が少なくても、リバースプロキシが経路上にある限りデータ転送量は影響を受けます。

FAQ

解答の導き方

• 「モバイル端末にクライアント証明書を組み込む」「VPNサーバでクライアント証明書を用いた端末認証が行われる」ので、VPN接続時に端末認証（クライアント証明書）のやり取りが生じます。
• 「モバイル端末が、X社のデータセンタに接続した後、認証サーバB1による利用者認証が行われ、トークンが発行される」ので、ユーザ認証とトークン発行は認証サーバB1が役割を持ち、VPNはB1との連携・トークンの中継などを行います。

• 背景：SaaS Qへのアクセス要求（トークンなし）により、認証フロー（B1によるトークン取得）が開始されます。認証フローの開始時点で認証サーバB1とVPNサーバは連携して動作する必要があるため、図4上で最初に認証サーバB1側からVPN側へトークン発行に関する指示が出される流れと解釈できます。
• 選択：カ（認証サーバB1列からVPNサーバ列へ向かう矢印「認証サーバB1が発行したトークン要求」）を当てます。矢印方向がB1→VPNであり、図のイベント（認証フロー開始をVPN側に知らせる）と整合します。

• 動作：VPNクライアントが立ち上がれば最初にVPNサーバへ接続を要求します。
• 選択：ウ（スマートフォン→VPNサーバ「接続要求」）。これはスマートフォン側からVPN接続の開始を通知する送信として唯一適合します。

• 動作：端末認証のためにVPNサーバがクライアント証明書の提示を要求します（対策文に「クライアント証明書を組み込む」「VPNサーバでクライアント証明書を用いた端末認証が行われる」とある）。
• 選択：イ（VPNサーバ→スマートフォン「クライアント証明書の要求」）。矢印方向（VPN→端末）と内容が一致します。

• 動作：要求に応じて端末が証明書を送信します。
• 選択：ア（スマートフォン→VPNサーバ「クライアント証明書」）。これは証明書送付の送信として自然です。

• 動作：端末レベルの接続が確立したら、VPNサーバは認証サーバB1に対してユーザ認証／トークン発行の要求を行います（問題文の「接続した後、認証サーバB1による利用者認証が行われ、トークンが発行される」に対応）。
• 選択：オ（VPNサーバ→認証サーバB1「トークン発行要求」）。矢印方向と内容が一致します。

• 動作：トークン発行のためにユーザの資格情報が必要なら、VPNサーバが端末側にID／パスワードの入力を促します。
• 選択：ク（VPNサーバ→スマートフォン「利用者ID及びパスワードの入力要求」）。

• 動作：ユーザが入力したID／パスワードを送信します。
• 選択：キ（スマートフォン→VPNサーバ「利用者ID、パスワード」）。この送信はそのままB1へ中継され、B1が必要なら認証サーバA1に検証要求を出します（図4のステップ10〜11）。

• 流れ：B1がA1での検証結果を受け、さらにVPNサーバがパッチ適用状況やセキュリティ設定の確認（図4のステップ12〜13）を行って問題なければ、最終的にトークンがクライアントに渡されます。B1発行のトークンがVPN経由で端末に提供されるため、端末側から見るとVPN→スマートフォンで「トークンの発行（供給）」が行われます。
• 選択：エ（VPNサーバ→スマートフォン「トークンの発行」）。これによりステップ15でスマートフォンが「アクセス要求（認証サーバB1が発行したトークン）」をSaaS Qへ送れます。

• a：カ（認証サーバB1→VPNサーバ「認証サーバB1が発行したトークン要求」）
• b：ウ（スマートフォン→VPNサーバ「接続要求」）
• c：イ（VPNサーバ→スマートフォン「クライアント証明書の要求」）
• d：ア（スマートフォン→VPNサーバ「クライアント証明書」）
• e：オ（VPNサーバ→認証サーバB1「トークン発行要求」）
• f：ク（VPNサーバ→スマートフォン「利用者ID及びパスワードの入力要求」）
• g：キ（スマートフォン→VPNサーバ「利用者ID、パスワード」）
• h：エ（VPNサーバ→スマートフォン「トークンの発行」）

誤りやすいポイント

• 矢印の向きを見落とすと誤答します。選択肢は送信元列→受信先列で定義されているため、必ず送受信者（列）と矢印方向を照合してください。
• 端末認証（クライアント証明書）と利用者認証（ID／パスワード→トークン発行）は別工程です。前者はVPN側の端末認証、後者は認証サーバB1／A1によるユーザ認証である点を混同しないでください。
• トークンの「発行者」を問題文で確認してください。トークンは「認証サーバB1による利用者認証...トークンが発行される」とあるため、発行主体はB1であり、VPNは中継する役割であると判断します（図ではVPN→端末で「トークンの発行」と表現されることがあります）。
• 図4中の注記（例：「認証サーバB1へのアクセスに必要なVPNクライアントの起動」）はユーザ操作の説明を含むため、必ず直後のネットワークメッセージと結びつけて考えてください。
• パッチ／セキュリティ設定確認（ステップ12〜13）は利用者認証と並行／直後に行われる「リスクベース認証」の一部です。これを忘れてユーザ認証→即トークン発行と考えると順序がずれます。

FAQ