情報処理安全確保支援士 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. 何を検知するルールかを整理する
   下線①は「D社の運用者がシステムから日記サービスのログを削除したときに、そのイベントを検知してアラートをメールで通知するための検知ルール」です。図1の例に倣い、表4のsystem・account・service・eventの四つのパラメータに、どのシステムで、誰が、どのクラウドサービスで、何をしたかを当てはめていきます。
2. system：日記サービスのログを保管しているシステム
   表5で、日記サービスのログを保管する構成要素は「ログ保管ストレージ」で、そのシステムIDは4000です。したがって、systemは4000です。
3. service：ログ保管ストレージが利用するクラウドサービス
   表5から、ログ保管ストレージが利用するのはオブジェクトストレージサービスです。表4のserviceの取り得る値にもオブジェクトストレージサービスが含まれているので、serviceはオブジェクトストレージサービスです。
4. event：ログの削除に当たる操作
   ログはオブジェクトストレージにオブジェクトとして保存されているので、ログを削除する操作はオブジェクトの削除に当たります。表4で、オブジェクトストレージサービスの場合のeventには「オブジェクトの削除」があるので、これを指定します。
5. account：D社の利用者IDを正規表現で表す
   設問に「D社の利用者IDは、1110〜1199とする」とあり、表4の注記には「systemとaccountの取り得る値には正規表現を利用できる」とあります。1110〜1199は、上2桁が11、3桁目が1〜9、4桁目が0〜9の4桁の数です。注記の規則では「[0-9]は、0から9までの連続する数字のうち、いずれか数字1文字を表す」ので、3桁目は[1-9]、4桁目は[0-9]と書けます。したがって、accountは11[1-9][0-9]です。
6. このルールが必要になる理由を確かめる
   D社は、表1の項番1のログ保全で「外部メディアにバックアップする前に、ログを一時的にD社作業用端末にダウンロードする」作業を行います。表6では、オブジェクトのダウンロードは編集権限に含まれるため、表7でD社にはオブジェクトストレージサービスの編集権限まで付与されています。編集権限にはオブジェクトの削除も含まれるので、D社の運用者はログを削除できてしまいます。一方、表1には「なお、各機器からログを削除する作業はW社が行う」とあり、D社がログを削除することは本来ありません。権限では削除を防げないので、削除されたことを検知して通知するルールが必要になるわけです。
7. 以上を、図1の例と同じJSON形式でまとめると次のようになります。

   {
     "system": "4000",
     "account": "11[1-9][0-9]",
     "service": "オブジェクトストレージサービス",
     "event": "オブジェクトの削除"
   }
   

誤りやすいポイント

• accountを11[0-9][0-9]と書いてしまう。これでは1100〜1109も一致し、D社以外の利用者の操作まで検知対象になります。
• accountを1110〜1199のような範囲の書き方で書いてしまう。表4の注記で使えるのは正規表現なので、各桁を[ ]で1文字ずつ表します。
• serviceを仮想マシンサービスにしてしまう。日記サービスのログを保管しているのはログ保管ストレージ（オブジェクトストレージサービス）で、仮想マシンサービスのeventにはオブジェクトの削除がありません。
• systemに公開Webサーバの1000や仮想ネットワークの5000を指定してしまう。ログを保管しているのはシステムID4000のログ保管ストレージです。
• JSONの書式を崩してしまう。図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リポジトリに接続
   ② “変更履歴のダウンロード”機能で削除前バージョンを取得
   ③ バージョン内のファイルZを閲覧し「Xトークン」を入手
5. したがって、下線⑤の操作は
   「OSSリポジトリのファイル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