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

解答の論理構成

1. 【問題文】の「表2　W社が管理、運用する必要のある範囲」によれば、“O”は W社が管理・運用する必要がある要素、“×”は不要な要素を示します。
2. クラウドサービス分類ごとの責任分界は一般的に次のとおりです。
   • IaaS: 利用者が「OS, ミドルウェア」「アプリ」「アプリに登録されたデータ」を管理します。
   • PaaS: ベンダが「OS, ミドルウェア」を提供し、利用者は「アプリ」「アプリに登録されたデータ」を管理します。
   • SaaS: ベンダが「OS, ミドルウェア」「アプリ」を含めて提供しますが、利用者は「アプリに登録されたデータ」を管理します。
3. 以上を表2の空欄に当てはめると以下のようになります。
   • a IaaS の「OS, ミドルウェア」→ 利用者管理 → “○”
   • b PaaS の「OS, ミドルウェア」→ ベンダ管理 → “×”
   • c SaaS の「OS, ミドルウェア」→ ベンダ管理 → “×”
   • d IaaS の「アプリ」→ 利用者管理 → “○”
   • e PaaS の「アプリ」→ 利用者管理 → “○”
   • f SaaS の「アプリ」→ ベンダ管理 → “×”
   • g IaaS の「アプリに登録されたデータ」→ 利用者管理 → “○”
   • h PaaS の「アプリに登録されたデータ」→ 利用者管理 → “○”
   • i SaaS の「アプリに登録されたデータ」→ 利用者管理 → “○”
4. よって模範解答どおり
   　a：○、b：×、c：×、d：○、e：○、f：×、g：○、h：○、i：○ となります。

誤りやすいポイント

• SaaS では「アプリ」をベンダが提供するので利用者は運用不要ですが、「アプリに登録されたデータ」は利用者責任であることを混同しやすいです。
• 「OS, ミドルウェア」は PaaS で不要、IaaS では必要という基本を取り違えると連鎖的に誤答になります。
• ハードウェアとネットワークは全サービス形態で “×” という前提を忘れると全体のバランスが崩れます。

FAQ

解答の論理構成

1. 委託範囲の確認
   【問題文】には「移行後、表1の項番1～項番3の運用をD社に委託する計画」とあります。
   項番1～3は以下のとおりです。
   ・項番1「ログ保全」
   ・項番2「障害監視」―「サーバの一覧を参照する」
   ・項番3「性能監視」―「性能指標を監視する」「サーバの一覧を参照する」
2. 仮想マシンサービスで必要な権限（j）
   障害監視・性能監視の両方で必要なのは「サーバの一覧を参照する」ことだけで、起動・停止・削除などの操作は求められていません。
   表6を見ると「仮想マシンサービス」の操作を最小に抑えるなら
     一覧の閲覧権限＝「仮想マシン一覧の閲覧」
   だけで十分です。したがって
   j＝ウ「一覧の閲覧権限」
3. DBサービスで必要な権限（k）
   項番1～3の運用内容にデータベース操作は一切含まれていません。
   よって DB サービスには権限を与える必要がありません。
   k＝エ「なし」
4. モニタリングサービスで必要な権限（l）
   性能監視では「性能指標を監視する」「過去から現在までの性能指標の値の閲覧」が必要です。
   表6のモニタリングサービスの権限を見ると
   ・一覧の閲覧権限＝「監視している性能指標一覧の閲覧」
   ・閲覧権限＝「過去から現在までの性能指標の値の閲覧」
   の二つがあれば目的を達成できます。追加・削除までは不要なので編集権限は与えません。
   l＝イ「一覧の閲覧権限、閲覧権限」
5. 以上より
   j：ウ、k：エ、l：イ となります。

誤りやすいポイント

• 「障害時に仮想マシンを再起動するかもしれない」と考えて編集権限まで付けてしまう。問題文では一次切分けのみで復旧操作は求められていない点に注意。
• モニタリングサービスで「性能指標の追加・削除も必要」と誤解する。追加・削除はW社側の作業であり、D社は値の閲覧だけで足りる。
• 「ログ保全だからDBにもアクセスが必要」と短絡的に判断する。実際のログはオブジェクトストレージサービスに保管され、DBサービスは対象外。

FAQ

解答の論理構成

1. 対象システムの特定
   • 本文では「ログ保管ストレージ」のシステム ID を表5で「4０００」と明示しています。
   • 下線①は「Ｄ社の運用者がシステムから日記サービスのログを削除したとき」を検知するとあるので、system は “4０００” になります。
2. 対象利用者の特定
   • 小問説明で「Ｄ社の利用者ＩＤは、111０〜1199」と指定されています。
   • account パラメータは正規表現が使えるので、111０〜1199を1行で表す正規表現は “11[1-9][０-9]” となります。
     • 11の後ろに1〜9を表す「[1-9]」、その後に０〜9を表す「[０-9]」を続けることで111０〜1199を網羅します。
3. service 値の決定
   • 表6で「オブジェクトストレージサービス」に対し「オブジェクトの作成・編集・削除」が編集権限に該当すると示されています。
   • ログ保管ストレージは「オブジェクトストレージサービス」を利用している（表5）ため、service は “オブジェクトストレージサービス” です。
4. event 値の決定
   • 表4の event に関する説明で「オブジェクトストレージサービスの場合」の選択肢に “オブジェクトの削除” があります。
   • ログを削除する操作は “オブジェクトの削除” に該当します。
5. 以上を JSON 形式でまとめる

誤りやすいポイント

• account の正規表現で「11[0-9][0-9]」と書くと111０未満（11００〜11０9）も含まれてしまいます。
• service を “仮想マシンサービス” と誤記すると、イベント種別に “オブジェクトの削除” が存在しないため検知できません。
• system に公開Ｗｅｂサーバ（1０００）を指定すると、ログ保管領域以外の削除操作を監視してしまい目的から外れます。

FAQ

解答の論理構成

1. 図3について
   • 【問題文】には「OAuth 2.0を利用してサービスTと連携した場合のサービス要求から記事投稿結果取得までの流れを図3に示す。」とあります。
   • したがって、図3のシーケンスは“新日記サービス”と“サービスT”の間で行われるやり取りです。
2. “mのWebサーバ”
   • シーケンス(1)は「Webブラウザ → mのWebサーバ：サービス要求」。
   • 会員がアクセスするのは“新日記サービス”のサイトであり、そこで記事の同時投稿を要求します。
   • よって “mのWebサーバ” ＝ “新日記サービス”。
3. “nの認可サーバ”
   • シーケンス(3)は「Webブラウザ → nの認可サーバ：認可要求」。
   • OAuth 2.0 の認可サーバはリソース提供側（今回の SNS）に属します。【問題文】では「サービスTと連携」と明記されているため、ここは “サービスT” となります。
4. “oのリソースサーバ”
   • シーケンス(9)は「mのWebサーバ → oのリソースサーバ：記事投稿」。
   • 記事を実際に保存するのはサービスTのSNS側リソースサーバです。
   • よって “oのリソースサーバ” ＝ “サービスT”。
5. 以上より
   • m：新日記サービス
   • n：サービスT
   • o：サービスT

誤りやすいポイント

• 認可サーバとリソースサーバを“新日記サービス”と誤解する
  • OAuth 2.0 ではリソースを持つ側（今回のSNS）が両方を提供するのが一般的です。
• Webサーバの所在をサービスTと誤認する
  • シーケンス(1)の「サービス要求」は会員が新日記サービスに対して行う操作です。
• 「記事投稿」を“API Gateway”など別名で考えてしまう
  • 問題文は単純化しており、リソースサーバ＝SNS の API であると読み替える必要があります。

FAQ

解答の論理構成

1. 表8の p には
   “GET /authorize?response_type=code&client_id=abcd1234&redirect_uri=https://△△△.com/callback HTTP/1.1¹)”
   と記載されています。
   これは OAuth 2.0 における認可エンドポイント /authorize へのリクエストであり、図3で示される
   “(3) 認可要求”
   と同一の内容です。
   したがって p ＝ (3) になります。
2. 表8の q には
   “POST /oauth/token HTTP/1.1 … grant_type=authorization_code …”
   と記載されています。
   /oauth/token への POST は、発行された認可コードを用いてアクセストークンを要求する処理で、図3の
   “(7) アクセストークン要求”
   に対応します。
   よって q ＝ (7) になります。
3. 以上より、解答は
   p：(3)
   q：(7)
   となります。

誤りやすいポイント

• /authorize と /oauth/token のエンドポイントを取り違える。前者は認可コード取得、後者はアクセストークン取得。
• 図3の(5)「リダイレクト」と(7)「アクセストークン要求」を混同し、POST と GET の違いを見落とす。
• Webブラウザから送られるリクエストか、クライアント（Webサーバ）から送られるリクエストかを区別せず番号を選んでしまう。

FAQ

解答の論理構成

1. 下線②では「TLS 1.2 及び TLS 1.3 を利用可能とするために、暗号スイートの設定をどのようにすればよいか」を検討します。
2. TLS 1.2 で利用できても、CRYPTREC の“電子政府推奨暗号リスト(令和4年3月30日版)”において推奨されない暗号技術が含まれるスイートは設定から除外する必要があります。
3. 解答群の各スイートを構成要素で比較すると次のとおりです。

1. 「3DES」および「RC4」「MD5」は同リストで“利用を推奨しない暗号技術”に明記されています。したがって該当スイートは
   ウ：TLS_RSA_WITH_3DES_EDE_CBC_SHA
   エ：TLS_RSA_WITH_RC4_128_MD5
2. よって解答は「ウ、エ」となります。

誤りやすいポイント

• 「AES-CBC は危険」と短絡的に判断してしまい、TLS_DHE_RSA_WITH_AES_256_CBC_SHA256まで除外してしまう。CBC モードは SHA-256 と組み合わせた DHE キー交換であれば現行リストで「推奨」扱いです。
• 「RSA キー交換＝非推奨」と思い込み、TLS_RSA_WITH_3DES_EDE_CBC_SHAだけでなくア～エすべてを疑ってしまう。問題は暗号アルゴリズムそのもの（3DES, RC4, MD5）にあります。
• TLS 1.3 のみを意識して TLS 1.2 のスイート分類を見落とす。設問は「TLS 1.2 の暗号スイート」を対象にしています。

FAQ

解答の論理構成

• 本文には、攻撃者が「mのWebサーバであると偽ってリクエストを送信できる」ものの、下線部③として「アクセストークンの取得に成功することは困難」とあります。
• OAuth 2.0 では、アクセストークン取得時に POST /oauth/token 要求（表8の番号q）で grant_type=authorization_code とともに code=... を送信します。
• code は (3)～(6) の正規フローで認可サーバが生成し、Webブラウザ経由で「mのWebサーバ」へリダイレクトされるまで外部に漏えいしません。
• 攻撃者が偽 Web サーバを名乗るだけでは、この code パラメータを入手できないため、後続の POST /oauth/token を正しく実行できず、アクセストークンを取得できません。
• したがって解答は「アクセストークン要求に必要なcodeパラメータを不正に取得できないから」となります。

誤りやすいポイント

• client_id や redirect_uri が分かればアクセストークンを得られると勘違いする。実際には一度限りの code が必須です。
• TLS を用いていれば安全とだけ考え、code の機密性が根拠である点を見落とす。
• 表8のqリクエスト内に code が含まれることを確認せず、別パラメータ名を書いてしまう。

FAQ

解答の論理構成

• 問題文では、PKCEを利用したときに「④認可サーバが二つのコードの関係を検証する」と記載されています。
• また「code_challenge_methodこの値はS256とする」と明示されています。S256は、検証コード（verifier）の SHA-256 ハッシュ値を base64url エンコードしてチャレンジコードと比較する方式です。
• したがって認可サーバ側は、
  1. クライアントから送られてきた検証コードを受け取る
  2. その検証コードを SHA-256 でハッシュ化する
  3. 得られたハッシュ値を base64url エンコードする
  4. (3) の値が事前に受け取っているチャレンジコードと一致するか確認する
• この手順が具体的な「検証方法」となり、模範解答で示された内容と合致します。

誤りやすいポイント

• チャレンジコードをそのまま平文比較してしまい、ハッシュ化とエンコードの工程を忘れる。
• base64 と base64url の違いを意識せず実装し、文字種の違いによって不一致になる。
• SHA-256 ではなく SHA-1 や SHA-512 など別のハッシュ関数を使おうとしてしまう。
• 検証コードを一度ハッシュ化した後にさらに何らかの変換を重ねてしまい、本来の PKCE フローとずれる。

FAQ

解答の論理構成

1. アップロードされたソースコードは承認後に“変更履歴”へ保存
   • 【問題文】表9 “バージョン管理”
     「ソースコードがアップロードされ、承認されると、対象のソースコードが新バージョンとして記録され、変更履歴のダウンロードが可能になる。」
   • ファイルZは開発者がアップロードし承認済みなので、削除しても履歴には残存します。
2. 変更履歴はダウンロード可能
   • 【問題文】表9 “バージョン管理”
     「…変更履歴のダウンロード…が可能である。」
   • さらに【問題文】表9 “権限管理”
     「変更履歴のダウンロードには、ソースコードのダウンロード権限が必要である。」
3. OSSリポジトリは外部公開されており、認証不要設定も選択できる
   • 【問題文】表9 “利用者認証及びアクセス制御”
     「サービスEは外部に公開されている。」
     「リポジトリごとに、利用者認証の要・不要を設定できる。」
   • OSSリポジトリ側で認証を“不要”にしていれば第三者もアクセス可能です。
4. 第三者の取得手順
   ① 公開された OSS リポジトリY に接続
   ② “変更履歴のダウンロード”機能で削除前バージョンを取得
   ③ バージョン内のファイルZを閲覧し「Xトークン」を入手
5. したがって、下線⑤の操作は
   「OSSリポジトリYのファイルZの変更履歴から削除前のファイルを取得する。」

誤りやすいポイント

• 削除すればファイルが完全に消えると誤解し、変更履歴の存在を見落とす。
• “承認前”のアップロードなら履歴に残らない点と混同しがち。
• アクセス制御を設定していると思い込み、外部公開状態を失念する。
• “クローン”操作など別のダウンロード方法を解答してしまう。

FAQ

解答の論理構成

1. 事故の背景
   表9の権限管理では「開発者、開発リーダーなど全ての利用者に対して、設定できる権限全てを与える。」とあり、 アップロード・ダウンロード・承認の三つの権限が誰にでも付与されていました。
2. 問題点の特定
   その結果、Xトークンを悪用した第三者が開発者になり替わり「不正コードM」をリポジトリWへ追加しても、 承認権限を自分で行使してしまえば変更が正式版として登録されてしまう脆弱な運用でした。
3. 再発防止の方向性
   権限委譲の原則（最小権限の原則）に従い、アップロードと承認を同一人物が行えないよう分離すべきです。
4. 具体的変更内容
   アップロードは開発者が行い、承認は「開発リーダー」だけが行えるように承認権限を限定します。
   これにより、Xトークンが流出しても承認フローで不正な変更を排除できます。
5. 結論
   以上から、承認権限を開発リーダーのみに絞る内容が最も適切です。

誤りやすいポイント

• 「承認権限を全員から削除する」と解釈してしまいがちですが、リポジトリ運用には承認者が必須です。
• 「アップロード権限も開発者から取り上げる」と勘違いすると開発フローが停止します。
• 「最小権限」という語から“閲覧だけ許可すればよい”と早合点すると、変更作業自体が出来なくなります。

FAQ

解答の論理構成

• 問題文では、事故発生時の状況として
  “X社CIに発行するEトークン（以下、Xトークンという）には、リポジトリWの全ての権限が付与されている。”
  と記載されています。
• また、設定できる個別権限は
  “ソースコードのダウンロード権限、ソースコードのアップロード権限、アップロードされたソースコードを承認する承認権限”
  の3種類であることが示されています。
• 不正コード混入の原因として、下線⑤で
  “第三者がXトークンを不正に取得して、リポジトリWに不正アクセス”
  と推測されています。全権限が付いていたため、攻撃者はアップロードや承認まで行えました。
• 再発防止では“表9中のサービス連携に関わる見直し”とあり、X社CIが本来実施する作業はビルド・テスト用にソースコードを取得することだけです。アップロードや承認は不要です。
• したがって、見直し後は最小権限の原則に従い、X社CIへ付与する権限を
  “ソースコードのダウンロード権限のみ”
  に限定するのが合理的となり、模範解答
  「Xトークンには、ソースコードのダウンロード権限だけを付与する。」
  が導かれます。

誤りやすいポイント

• 「アップロードは不要でもテスト結果を書き戻すので承認権限が要る」と誤解する。
  ⇒ テスト結果の保存はX社CI側で完結し、リポジトリへの書き戻し要件は示されていません。
• “全権限”を剥奪しトークン発行を止めるとCIが動かないと考えてしまう。
  ⇒ ビルド・テストにはダウンロード権限さえあれば十分です。
• 権限を細分化できないと早合点し「設定変更不可」と判断する。
  ⇒ 問題文は「個別に設定可能」と明言しています。

FAQ