令和5年度 春期 情報処理安全確保支援士試験 午後II 問2 クラウド移行の権限設計とOAuth 2.0連携の安全性
この問題は2023(R5)春 情報処理安全確保支援士 午後IIに出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。
本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています（改行・記号・数式・図表参照の調整）。設問の趣旨および正解に影響する変更は加えていません。
学習ガイド
日記サービスのクラウド移行とOAuth 2.0連携で生じた、権限管理と不正コード混入の問題です。クラウドとリポジトリを、誰にどの余分な権限があったかという共通の観点で整理します。OAuthとPKCEのシーケンスを追い、トークン漏えいの影響範囲を確認します。本文・表・図の根拠を行き来し、用語だけを暗記するのではなく、短い記述にも判断の理由を残して解答する手順を示します。
この記事で押さえる論点
- IaaS・PaaS・SaaSごとの責任分界と、委託先に付与する最小権限を表から導ける
- 正規表現を使ったイベント検知ルールをJSONで正確に書ける
- 認可コードフローとPKCEで、クライアントシークレット漏えい時に何が守られるかを説明できる
- OSSリポジトリの変更履歴からのトークン漏えい経路と、承認権限・トークン権限の見直し策を記述する
出題情報
- 出題
- 2023(R5)春 情報処理安全確保支援士 午後II 問2
- 配点
- 100点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
近年，クラウドサービスへの移行が加速する中で，セキュリティについてオンプレミスとは異なる知見が求められている。また，外部サービスとの連携が増加しているが，セキュアではない設定がされるケースも散見される。本問では，Webサイトのクラウドサービスへの移行と機能拡張を題材として，自社システムからクラウドサービスへの移行時及び移行後におけるセキュリティに関わる設定と，外部サービスと連携する際の認可，権限設定についての分析能力を問う。
問2では，Webサイトのクラウドサービスへの移行と機能拡張を題材に，権限設定及び認可に関連するセキュリティ対策について出題した。全体として正答率は平均的であった。
問題本文
Webサイトのクラウドサービスへの移行と機能拡張に関する次の記述を読んで，設問に答えよ。
W社は，従業員100名のブログサービス会社であり，日記サービスというWebサービスを10年前から提供している。日記サービスの会員は，自分の食事に関する記事の投稿及び摂取カロリーの管理ができる。
日記サービスは，W社のデータセンター内で稼働している。ハードウェアの調達には1か月程度を要する。W社は，日記サービスが稼働している各機器の運用をD社に委託している。D社に委託している運用を表1に示す。
図の説明テキスト
表1 D社に委託している運用（概要）
| 項番 | 運用 | 運用内容 |
|---|---|---|
| 1 | ログ保全 | ・定期的に, 日記サービスが稼働している各機器の全てのログを外部メディアにバックアップする。 ・外部メディアにバックアップする前に, ログを一時的に D社作業用端末にダウンロードする。 ・D社作業用端末でのバックアップ作業後に, D社作業用端末からログを削除する。なお, 各機器からログを削除する作業は W社が行う。 |
| 2 | 障害監視 | ・アプリケーションプログラム（以下, アプリという）の問題の一次切分けを行う。アプリの問題は, ログを監視しているソフトウェアによって検知される。 ・ログを確認して一次切分けを行う。その際に, サーバの一覧を参照する。 ・W社への連絡は, 電子メール（以下, メールという）と電話で行う。 |
| 3 | 性能監視 | ・W社が定めた, CPU稼働率, 処理性能及び応答時間に関わる指標（以下, 性能指標という）を監視する。 ・異常を検知すると, 一次切分けを行う。その際に, サーバの一覧を参照する。 ・必要に応じて, W社への連絡をメールと電話で行う。 |
| 4 | 機器故障対応 | ・交換対象のハードウェアの発注を行う。 ・故障機器のハードウェア交換作業を行う。 |
この2, 3年，会員が急増しているので，W社は，日記サービスをクラウドサービスに移行することにした。
〔移行先のクラウドサービス選定〕
W社は，クラウドサービスへの移行時及び移行後の管理，運用について，検討を開始した。
まず，クラウドサービスへの移行時及び移行後に，W社が何を管理，運用する必要があるかを調べたところ，表2のとおりであった。
図の説明テキスト
表2 W社が管理，運用する必要のある範囲
| 構成要素 | クラウドサービスの分類 IaaS | クラウドサービスの分類 PaaS | クラウドサービスの分類 SaaS |
|---|---|---|---|
| ハードウェア，ネットワーク | × | × | × |
| OS，ミドルウェア | a | b | c |
| アプリ | d | e | f |
| アプリに登録されたデータ | g | h | i |
注記 “○”はW社が管理，運用する必要があるものを示し，“×”は必要がないものを示す。
クラウドサービスへの移行及びクラウドサービスの設定はW社が行い，移行後，表1の項番1～項番3の運用をD社に委託する計画にした。
移行先のクラウドサービスとして，L社のクラウドサービスを選定した。L社が提供しているクラウドサービスを表3に示す。
図の説明テキスト
表3 L社が提供しているクラウドサービス
| クラウドサービス名 | 説明 |
|---|---|
| 仮想マシンサービス | ・利用者が OS やアプリを配備することによって，物理サーバと同じ機能を実行するための仮想化基盤である。 |
| データベース（以下，DBという）サービス | ・関係 DB である。 ・容量の拡張，バックアップなどは，自動で実行される。 |
| ブロックストレージサービス | ・固定長のブロックという論理単位で管理できるストレージである。仮想マシンサービスのファイルシステムとして割り当てることが可能である。 |
| オブジェクトストレージサービス | ・データをオブジェクトとして扱い，各オブジェクトをメタデータで管理できるストレージである。 ・オブジェクトの保存のために必要なサーバの資源管理，容量の拡張などは，自動で実行される。 |
| モニタリングサービス | ・利用者が利用している L 社の各クラウドサービスについて，性能指標を監視する。 |
図の説明テキスト
表3 L社が提供しているクラウドサービス（続き）
| クラウドサービス名 | 説明 |
|---|---|
| アラートサービス | ・L社のクラウドサービスの環境 1) でイベント 2) が発生したときに，そのイベントを検知してアラートをメールで通知する。 |
| 仮想ネットワークサービス | ・レイヤー2 スイッチ（以下，L2SW という），ファイアウォール（以下，FW という），ルータなどのネットワーク機器を含むネットワークを仮想的に構成でき，インターネットとの接続を可能にする。 |
注 1) L社の各クラウドサービスを利用して構築したシステム及びネットワークを指す。
注 2) 特定の利用者による操作，システム構成の変更，設定変更などである。
イベント検知のルールは JSON形式で記述する。そのパラメータを表4に示す。
図の説明テキスト
表4 イベント検知のルールに記述するパラメータ
| パラメータ | 内容 | 取り得る値 |
|---|---|---|
| system | 検知対象とするシステム ID | ・0000 ～ 9999 |
| account | 検知対象とする利用者 ID | ・0000 ～ 9999 |
| service | 検知対象とするクラウドサービス名 | ・仮想マシンサービス ・オブジェクトストレージサービス ・モニタリングサービス |
| event | 検知対象とするイベント | eventの取り得る値は，serviceの値によって異なる。 ・仮想マシンサービスの場合 - 仮想マシンの起動 - 仮想マシンの停止 - 仮想マシンの削除 ・オブジェクトストレージサービスの場合 - オブジェクトの作成 - オブジェクトの編集 - オブジェクトの削除 - オブジェクトの閲覧 - オブジェクトのダウンロード ・モニタリングサービスの場合 - 監視する性能指標の追加 - 監視する性能指標の削除 |
注記 system と account の取り得る値には正規表現を利用できる。正規表現は次の規則に従う。
[012] は，0，1 又は 2 のいずれか数字 1 文字を表す。
[0-9] は，0 から 9 までの連続する数字のうち，いずれか数字 1 文字を表す。
- は，直前の正規表現の 0 回以上の繰返しを表す。
- は，直前の正規表現の 1 回以上の繰返しを表す。
仮想マシンサービスを利用して構築した，システムIDが0001のシステムにおいて，利用者IDが1000である利用者が仮想マシンを停止させた場合の，イベント検知のルールの例を図1に示す。
図の説明テキスト
図1 イベント検知のルールの例
{
"system": "0001",
"account": "1000",
"service": "仮想マシンサービス",
"event": "仮想マシンの停止"
}
〔日記サービスのL社のクラウドサービスへの移行〕
移行後の日記サービスの仮想ネットワーク構成を図2に，図2中の主な構成要素を表5に示す。
図の説明テキスト
図2 移行後の日記サービスの仮想ネットワーク構成
最上位に「インターネット」の楕円があり、仮想ネットワーク内の「ルータ」へ接続されている。仮想ネットワークは破線の枠で囲まれ、内部に「DMZ」と「内部セグメント」が存在する。
DMZ内には「公開Webサーバ」と「権威DNSサーバ」があり、それぞれ「L2SW」を介して「FW」に繋がっている。FWはルータと接続されている。
内部セグメント内には「日記DB 1)」と「ログ保管ストレージ 2)」があり、これらも「L2SW」を介してFWに繋がっている。
注1) 日記サービスのデータを管理するDB
注2) 日記サービスのログを保管するストレージ
図の説明テキスト
表5 図2中の主な構成要素
| システム ID | 構成要素 | 利用する L 社のクラウドサービス |
|---|---|---|
| 1000 | 公開 Web サーバ | ・仮想マシンサービス ・ブロックストレージサービス |
| 2000 | 権威 DNS サーバ | ・仮想マシンサービス ・ブロックストレージサービス |
| 3000 | 日記 DB | ・DB サービス |
| 4000 | ログ保管ストレージ | ・オブジェクトストレージサービス |
| 5000 | 仮想ネットワーク | ・仮想ネットワークサービス |
注記 日記サービスでは，モニタリングサービスとアラートサービスを利用する。
W社は，L社のクラウドサービスにおける，D社に付与する権限の検討を開始した。
〔L社のクラウドサービスにおける権限設計〕
L社の各クラウドサービスにおける権限ごとに可能な操作を表6に示す。
図の説明テキスト
表6 L社の各クラウドサービスにおける権限ごとに可能な操作（抜粋）
| クラウドサービス名 | 一覧の閲覧権限 | 閲覧権限 | 編集権限 |
|---|---|---|---|
| 仮想マシンサービス | 仮想マシン一覧の閲覧 | 仮想マシンに割り当てたファイルシステム上のファイルの閲覧 | ・仮想マシンの起動，停止，削除 ・仮想マシンへのファイルシステムの割当て ・仮想マシンに割り当てたファイルシステム上のファイルの作成，編集，削除 ・仮想マシンの性能の指定 |
| DBサービス | スキーマ一覧及びテーブル一覧の閲覧 | テーブルに含まれるデータの閲覧 | ・テーブルの作成，編集，削除 ・テーブルに含まれるデータの追加，編集，削除 |
| ブロックストレージサービス | 生成したストレージ一覧の閲覧 | ストレージの使用済み容量及び空き容量の閲覧 | ・ストレージの生成 ・ストレージの容量の指定 |
| オブジェクトストレージサービス | オブジェクト一覧の閲覧 | オブジェクトの閲覧 | ・オブジェクトの作成，編集，削除 ・オブジェクトのダウンロード |
| モニタリングサービス | 監視している性能指標一覧の閲覧 | 過去から現在までの性能指標の値の閲覧 | ・監視する性能指標の追加，削除 |
W社は，D社に付与する権限が必要最小限となるように，表7に示すD社向けの権限のセットを作成した。
図の説明テキスト
表7 D社向けの権限のセット（抜粋）
| クラウドサービス名 | D社に付与する権限 |
|---|---|
| 仮想マシンサービス | [ j ] |
| DBサービス | [ k ] |
| オブジェクトストレージサービス | 一覧の閲覧権限, 閲覧権限, 編集権限 |
| モニタリングサービス | [ l ] |
さらに，W社は，①D社の運用者がシステムから日記サービスのログを削除したときに，そのイベントを検知してアラートをメールで通知するための検知ルールを作成した。
W社は，L社とクラウドサービスの利用契約を締結して，日記サービスをL社のクラウドサービスに移行し，運用を開始した。
〔機能拡張の計画開始〕
W社は，サービス拡大のために，機能を拡張した日記サービス（以下，新日記サービスという）の計画を開始した。新日記サービスの要件は次のとおりである。
- 要件1：会員が記事を投稿する際，他社のSNSにも同時に投稿できること
- 要件2：スマートフォン用のアプリ（以下，スマホアプリという）を提供すること
W社は，要件1を実装した後で要件2に取り組むことに決めた。その上で，要件1を実現するために，T社のSNS（以下，サービスTという）と連携することにした。
〔サービスTとの連携の検討〕
OAuth 2.0を利用してサービスTと連携した場合のサービス要求から記事投稿結果取得までの流れを図3に，送信されるデータを表8に示す。
図の説明テキスト
図3 サービス要求から記事投稿結果取得までの流れのシーケンス図
参加要素: Webブラウザ、mのWebサーバ、nの認可サーバ、oのリソースサーバ
処理の流れ:
(1) サービス要求: Webブラウザから mのWebサーバへ
(2) リダイレクト: mのWebサーバからWebブラウザへ
(3) 認可要求: Webブラウザから nの認可サーバへ
(4) 認可同意処理: Webブラウザから nの認可サーバへ
(5) リダイレクト: nの認可サーバからWebブラウザへ
(6) 認可コード: Webブラウザから mのWebサーバへ
(7) アクセストークン要求: mのWebサーバから nの認可サーバへ
(8) アクセストークン応答: nの認可サーバから mのWebサーバへ
(9) 記事投稿: mのWebサーバから oのリソースサーバへ
(10) 記事投稿結果取得: oのリソースサーバから mのWebサーバへ
図の説明テキスト
表8 送信されるデータ（抜粋）
| 番号 | 送信されるデータ |
|---|---|
| p | GET /authorize?response_type=code&client_id=abcd1234&redirect_uri=https://△△△.com/callback HTTP/1.1 1) |
| q | POST /oauth/token HTTP/1.1 Authorization: Basic YWJjZDEyMzQ6UEBzc3dvcmQ= 2) grant_type=authorization_code&code=5810f68ad195469d85f59a6d06e51e90& redirect_uri=https://△△△.com/callback |
注記 △△△.com は，新日記サービスのドメイン名である。
注1) クエリ文字列中の “abcd1234” は，英数字で構成された文字列であるクライアント ID を示す。
注2) “YWJjZDEyMzQ6UEBzc3dvcmQ=” は，クライアント ID と，英数字と記号で構成された文字列であるクライアントシークレットとを，“:” で連結して base64 でエンコードした値（以下，エンコード値 G という）である。
各リクエストの通信で TLS 1.2 及び TLS 1.3 を利用可能とするために, ②暗号スイートの設定をどのようにすればよいかを検討した。また, サービスTとの連携のためのモジュール（以下, Rモジュールという）の実装から単体テストまでをF社に委託することにした。F社は, 新技術を積極的に活用しているIT企業である。
〔F社の開発環境〕
F社では, Rモジュールの開発は, 取りまとめる開発リーダー1名と, 実装から単体テストまでを行う開発者3名のチームで行う。システム開発において, 顧客から開発を委託されたプログラムのソースコードのリポジトリと外部に公開されている OSSリポジトリを利用している。二つのリポジトリは, サービスEというソースコードリポジトリサービスを利用して管理している。
サービスEの仕様と, RモジュールについてのF社のソースコード管理プロセスは, 表9のとおりである。
図の説明テキスト
表9 サービスEの仕様とF社のソースコード管理プロセス
| 機能 | サービスEの仕様 | F社のソースコード管理プロセス |
|---|---|---|
| 利用者認証及びアクセス制御 | ・利用者IDとパスワードによる認証、及び他のIdPと連携したSAML認証が可能である。 ・リポジトリごとに、利用者認証の要・不要を設定できる。 ・サービスEは外部に公開されている。 ・IPアドレスなどで接続元を制限する機能はない。 |
・利用者認証には、F社内で運用している認証サーバと連携した、SAML認証を利用する。 ・Rモジュール開発向けのリポジトリ（以下、リポジトリWという）には、利用者認証を“要”に設定する。 |
| バージョン管理 | ・ソースコードのアップロード 1)、承認、ダウンロード、変更履歴のダウンロード、削除が可能である。 ・新規作成、変更、削除の前後の差分をソースコードの変更履歴として記録する。 ・ソースコードがアップロードされ、承認されると、対象のソースコードが新バージョンとして記録され、変更履歴のダウンロードが可能になる。 |
・開発者は、静的解析と単体テストを実施する。開発者が、それら二つの結果とソースコードをアップロードして、開発リーダーに承認を依頼するルールとする。ただし、静的解析と単体テストについてリスクが少ないと開発者が判断した場合は、開発者自身がソースコードのアップロードとその承認の両方を実施できるルールとする。 |
| 権限管理 | ・設定できる権限には、ソースコードのダウンロード権限、ソースコードのアップロード権限、アップロードされたソースコードを承認する承認権限がある。 ・利用者ごとに、個別のリポジトリの権限を設定することが可能である。 ・変更履歴のダウンロードには、ソースコードのダウンロード権限が必要である。 ・変更履歴の削除には、アップロードされたソースコードを承認する承認権限が必要である。 ・外部のX社が提供している継続的インテグレーションサービス 2)（以下、X社CIという）と連携するには、ソースコードのダウンロード権限をX社CIに付与する必要がある。 |
・開発者、開発リーダーなど全ての利用者に対して、設定できる権限全てを与える。 |
| サービス連携 | ・別のクラウドサービスと連携する際に、権限を付与するトークン（以下、Eトークンという）を、リポジトリへアクセスしてきた連携先に発行することができる。 ・Eトークンの有効期間は1か月である。Eトークンの発行形式や有効期間の変更はできない。 |
・X社CIと連携する。 ・X社CIに発行するEトークン（以下、Xトークンという）には、リポジトリWの全ての権限が付与されている。 |
注記 OSSリポジトリには、利用者認証を“不要”に設定している。また、OSSリポジトリのソースコードと変更履歴のダウンロードは誰でも可能である。
注 1) ソースコードのアップロードには、関連するファイルの新規作成、変更、削除の操作が含まれる。
注 2) アップロードされたソースコードが承認されると、ビルドと単体テストを自動実行するサービスである。
〔悪意のある不正なプログラムコードの混入〕
F社は，Rモジュールの実装について単体テストまでを完了して，ソースコードをW社に納品した。その後，W社とT社は結合テストを開始した。
結合テスト時，外部のホストに対する通信がRモジュールから発生していることが分かった。調べたところ，不正なプログラムコード（以下，不正コードMという）がソースコードに含まれていたことが分かった。不正コードMは，OSの環境変数の一覧を取得し，外部のホストに送信する。新日記サービスでは，エンコード値GがOSの環境変数に設定されていたので，その値が外部のホストに送信されていた。
W社は，漏えいした情報が悪用されるリスクの分析と評価を行うことにした。それと並行して，不正コードMの混入の原因調査と，プログラムの修正をF社に依頼した。
〔W社によるリスク評価〕
W社は，リスクを分析し，評価した。評価結果は次のとおりであった。
・エンコード値Gを攻撃者が入手した場合，mのWebサーバであると偽ってリクエストを送信できる。しかし，図3のシーケンスでは，③攻撃者が特定の会員のアクセストークンを取得するリクエストを送信し，アクセストークンの取得に成功することは困難である。
次に，W社は，近い将来に要件2を実装する場合におけるリスクについても，リスクへの対応を検討した。
そのリスクのうちの一つは，スマホアプリのリダイレクトにカスタムURLスキームを利用する場合に発生可能性がある。W社が提供するスマホアプリと攻撃者が用意した偽のスマホアプリの両方を会員が自分の端末にインストールしてしまうと，正規のスマホアプリとサーバとのやり取りが偽のスマホアプリに横取りされ，攻撃者がアクセストークンを不正に取得できるというものである。この対策として，PKCE (Proof Key for Code Exchange) を利用すると，偽のスマホアプリにやり取りが横取りされても，アクセストークンの取得を防ぐことができる。
要件2を実装する場合のサービス要求から記事投稿結果取得までの流れを図4に示す。
図の説明テキスト
図4 要件2を実装する場合のサービス要求から記事投稿結果取得までの流れ
参加要素: スマホアプリ、mのWebサーバ、nの認可サーバ、oのリソースサーバ
処理の流れ:
(1) サービス要求: スマホアプリから mのWebサーバへ
(2) リダイレクト: mのWebサーバからスマホアプリへ
(3) 認可要求: スマホアプリから nの認可サーバへ
(4) 認可同意処理: スマホアプリと nの認可サーバ間で
(5) リダイレクト: nの認可サーバからスマホアプリへ
(6) 認可コード: スマホアプリから mのWebサーバへ
(7) アクセストークン要求: mのWebサーバから nの認可サーバへ
(8) アクセストークン応答: nの認可サーバから mのWebサーバへ
(9) 記事投稿: mのWebサーバから oのリソースサーバへ
(10) 記事投稿結果取得: oのリソースサーバから mのWebサーバへ
PKCEの実装では，乱数を基に，チャレンジコードと検証コードを生成する。(3)のリクエストにチャレンジコードと code_challenge_methodパラメータを追加し，(7)のリクエストに検証コードパラメータを追加する。最後に，④認可サーバが二つのコードの関係を検証することで，攻撃者からのアクセストークン要求を排除できる。
〔F社による原因調査〕
F社は，不正コードMが混入した原因を調査した。調査の結果，サービスEのOSSリポジトリ上に，Xトークンなどの情報が含まれるファイル（以下，ファイルZという）がアップロードされた後に削除されていたことが分かった。
F社の開発者の1人が，ファイルZを誤ってアップロードし，承認した後，誤ってアップロードしたことに気付き，ファイルZを削除した上で開発リーダーに連絡していた。開発リーダーは，ファイルZがOSSリポジトリから削除されていること，ファイルZがアップロードされてから削除されるまでの間にダウンロードされていなかったことを確認して，問題なしと判断していた。
F社では，⑤第三者がXトークンを不正に取得して，リポジトリWに不正アクセスし，不正コードMをソースコードに追加したと推測した。そこで，F社では，Xトークンを無効化し，次の再発防止策を実施した。
・表9中のバージョン管理に関わる見直しと⑥表9中の権限管理についての変更
・Xトークンが漏えいしても不正にプログラムが登録されないようにするための，⑦表9中のサービス連携に関わる見直し
ソースコードには他の不正な変更は見つからなかったので，不正コードMが含まれる箇所だけを不正コードMが追加される前のバージョンに復元した。
W社は，F社が改めて納品したRモジュールに問題がないことを確認し，新日記サービスの提供を開始した。
設問と解答・解説
設問1
(1)
空欄 a
模範解答
○
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「○」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- クラウド環境における責任共有モデルや権限設定のベストプラクティスを理解していること。
オンプレミス環境と異なり、クラウドサービスでは適切な認可設定が行われていないと外部からの不正アクセスのリスクが高まります。設定の適切性を正しく判断することが求められます。
(2)
空欄 b
模範解答
×
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「×」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- 設定ミスがもたらす情報漏えいのリスクを理解していること。
クラウド環境で不適切な権限が付与されているケースを見抜き、「×」と判定できるかが鍵となります。
(3)
空欄 c
模範解答
×
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「×」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- クラウドのアクセス制御における過剰な権限付与の危険性を理解していること。
権限管理の最小権限の原則に反する設定を特定し、「×」と判定する必要があります。
(4)
空欄 d
模範解答
○
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「○」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- クラウド事業者が提供するセキュリティ機能や連携仕様を正しく理解していること。
安全な設定手法が適用されていると評価し、「○」と判断することが求められます。
(5)
空欄 e
模範解答
○
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「○」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- 外部サービス連携における認可モデルの正しい適用方法を理解していること。
適切な保護が講じられている設定を見極め、「○」と判断することが求められます。
(6)
空欄 f
模範解答
×
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「×」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- 不十分な認証・認可設定に起因するセキュリティ脆弱性を認識していること。
外部サービスとの連携において、セキュアではない設定を特定し、「×」と判定する必要があります。
(7)
空欄 g
模範解答
○
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「○」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- クラウド上でのセキュアなリソース管理とアクセス制御について理解していること。
適切な制限が設けられた安全な設計であると評価し、「○」と判断することが求められます。
(8)
空欄 h
模範解答
○
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「○」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- 外部サービスとの安全な連携方式を正しく評価できること。
リスクが十分にコントロールされている連携仕様であることを理解し、「○」と判断することが求められます。
(9)
空欄 i
模範解答
○
採点基準(配点 3点)
正確性（内容）(3点)
- 3点: 正解である「○」が記述されている。
- 1点: 回答の意図は正解に近いが、指定された記号以外の表現が混じっている。
- 0点: 誤答である、または無解答。
解説
本設問は、自社システムからクラウドサービスへの移行時におけるセキュリティ設定の妥当性を評価する問題です。
高得点のポイント
- 権限の分離やアクセス元の制限など、多層的な防御策の有効性を理解していること。
堅牢な設定が適用されていることを見極め、「○」と判断することが求められます。
設問2
〔L社のクラウドサービスにおける権限設計〕について答えよ。
(1)
表7中の j に入れる適切な字句を，解答群の中から選び，記号で答えよ。
模範解答
選択肢ウ: 一覧の閲覧権限
配点 2点
解説
本設問は、L社のクラウドサービスにおける役割ベースのアクセス制御（RBAC）に基づく適切な権限付与を問う問題です。
業務に必要な最小限の権限のみを付与する最小権限の原則に則り、対象の役割にとって過不足のない権限セットを選択する必要があります。
各選択肢の解説
ア: 編集権限まで含まれており、対象の役割には権限が過剰です。
イ: 詳細な閲覧権限が含まれますが、対象の役割にとっては不要な権限を含みます。
ウ (正解): 業務を遂行する上で必要十分な「一覧の閲覧権限」のみが付与されており、適切な設計です。
エ: 権限が全く付与されておらず、必要な業務を遂行できなくなります。
(2)
表7中の k に入れる適切な字句を，解答群の中から選び，記号で答えよ。
模範解答
選択肢エ: なし
配点 2点
解説
本設問は、特定の役割に対して適切な権限セットを割り当てる能力を問う問題です。
対象の役割がクラウドサービス上のリソースへアクセスする必要がない場合、権限を一切持たせないことがセキュリティ上最も安全な設計となります。
各選択肢の解説
ア, イ, ウ: いずれも何らかの閲覧または編集権限を含んでおり、不必要なアクセスを許してしまうため不適切です。
エ (正解): 対象の役割には一切の権限を付与しない「なし」が正解となり、情報漏えいのリスクを極小化できます。
(3)
表7中の l に入れる適切な字句を，解答群の中から選び，記号で答えよ。
模範解答
選択肢イ: 一覧の閲覧権限，閲覧権限
配点 2点
解説
本設問は、クラウド上のデータを参照する必要があるが変更は許可すべきではない役割への権限設計を問う問題です。
データを安全に確認させるためには、閲覧に特化した権限設定が必要です。
各選択肢の解説
ア: 編集権限が含まれているため、誤操作や不正なデータ改ざんのリスクがあり不適切です。
イ (正解): 一覧の閲覧と詳細の閲覧権限のみが含まれ、データの変更を伴わない業務要件に完全に合致しています。
ウ: 詳細の閲覧権限が欠如しているため、必要な業務が行えません。
エ: 権限が全く付与されていないため不適切です。
(4)
本文中の下線①のイベント検知のルールを，JSON形式で答えよ。ここで，D社の利用者IDは，1110～1199とする。
模範解答
{ "system": "4000", "account": "11[1-9][0-9]", "service": "オブジェクトストレージサービス", "event": "オブジェクトの削除" }
採点基準(配点 4点)
知識・理解度（内容）(2点)
- 2点: 利用者IDの条件を満たす正規表現（11[1-9][0-9]等）が正確に記述され、必要なパラメータが全て含まれている。
- 1点: 必要なパラメータは含まれているが、正規表現の記述に一部誤りや過不足がある。
- 0点: 条件を満たす内容が記述されていない。
論理性（構造）(2点)
- 2点: JSON形式（キーと値のペア、ダブルクォーテーションの使用、波括弧など）の構文が完全に正しく記述されている。
- 1点: JSON形式を意図しているが、カンマの抜けやクォーテーションの欠落など軽微な構文エラーがある。
- 0点: JSON形式の構造を全く成していない。
解説
本設問は、クラウド環境の監視において、特定の条件を満たすイベントを検知するためのルールをJSON形式で表現する能力を問う問題です。
高得点のポイント
設問で指定されたD社の利用者IDの範囲「1110～1199」を表現するため、正規表現
11[1-9][0-9]を適切に使用していること。キーと値がダブルクォーテーションで囲まれているなど、有効なJSONとしての構造を満たしていること。
システムID、アカウント、サービス名、イベント名の各フィールドが要件に従って正確に記述されていること。
設問3
〔サービスTとの連携の検討〕について答えよ。
(1)
本文中，図3中及び図4中の m に入れる適切な字句を，“新日記サービス”又は“サービスT”から選び答えよ。
模範解答
新日記サービス
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 正解である「新日記サービス」が正確に記述されている。
- 2点: 意図は伝わるが、指定された字句と完全に一致していない。
- 0点: 誤答である、または無解答。
解説
本設問は、OAuth 2.0やOpenID Connectを利用した外部サービス連携において、HTTPリクエストやレスポンスの主体がどのシステムであるかを特定する問題です。
高得点のポイント
- 連携フローの図やシーケンスにおいて、認可を要求するクライアントとリソースを提供するサーバーの関係を正確に読み取ること。
該当する通信が「新日記サービス」から発せられるものか、「サービスT」から発せられるものかを文脈から判断します。本空欄では「新日記サービス」が該当します。
(2)
本文中，図3中及び図4中の n に入れる適切な字句を，“新日記サービス”又は“サービスT”から選び答えよ。
模範解答
サービスT
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 正解である「サービスT」が正確に記述されている。
- 2点: 意図は伝わるが、指定された字句と完全に一致していない。
- 0点: 誤答である、または無解答。
解説
本設問は、外部サービス連携における通信主体を特定する問題です。
高得点のポイント
- トークンの発行やAPIの提供を行う主体がどのサービスであるかを正確に理解すること。
文脈および連携図の構造から、この通信は「サービスT」が主体となって行われるものであると判断できます。
(3)
本文中，図3中及び図4中の o に入れる適切な字句を，“新日記サービス”又は“サービスT”から選び答えよ。
模範解答
サービスT
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 正解である「サービスT」が正確に記述されている。
- 2点: 意図は伝わるが、指定された字句と完全に一致していない。
- 0点: 誤答である、または無解答。
解説
本設問は、外部サービス連携におけるシーケンス図内の主体を特定する問題です。
高得点のポイント
- HTTPリクエストとHTTPレスポンスの主体を混同せず、プロトコルの基本的なやり取りを正確に追跡できること。
受験者の多くがリクエストとレスポンスを誤認しやすい部分です。データの流れをよく確認し、「サービスT」であることを特定します。
(4)
表8中の p に入れる適切な番号を，図3中の番号から選び答えよ。
模範解答
(3)
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 正解である「(3)」が正確に記述されている。
- 2点: 意図は伝わるが、括弧の有無など形式に軽微な逸脱がある。
- 0点: 誤答である、または無解答。
解説
本設問は、OAuth 2.0の認可コードフローにおいて、各ステップが図中のどの番号に該当するかを特定する問題です。
高得点のポイント
- 認可サーバーへのリダイレクトや認可コードの返却など、フローの順序を正確に把握していること。
該当する処理は、図中の「(3)」のステップと一致します。
(5)
表8中の q に入れる適切な番号を，図3中の番号から選び答えよ。
模範解答
(7)
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 正解である「(7)」が正確に記述されている。
- 2点: 意図は伝わるが、括弧の有無など形式に軽微な逸脱がある。
- 0点: 誤答である、または無解答。
解説
本設問は、OAuth 2.0の認可コードフローにおけるトークン取得のステップを特定する問題です。
高得点のポイント
- アクセストークン要求（リクエスト）と、その発行（レスポンス）の違いを正しく理解していること。
講評にもある通り、レスポンスである「(8)」と誤認しやすい箇所です。リクエストにあたる「(7)」を選択できるかが重要です。
(6)
本文中の下線②について，CRYPTRECの“電子政府推奨暗号リスト（令和4年3月30日版）”では利用を推奨していない暗号技術が含まれるTLS 1.2の暗号スイートを，解答群の中から全て選び，記号で答えよ。
模範解答
選択肢ウ: TLS_RSA_WITH_3DES_EDE_CBC_SHA
選択肢エ: TLS_RSA_WITH_RC4_128_MD5
配点 3点
解説
本設問は、CRYPTRECの「電子政府推奨暗号リスト」において、安全性に懸念があるため利用が推奨されていない暗号技術を含むTLS 1.2の暗号スイートを特定する問題です。
各選択肢の解説
ア:
AES_128_GCMは現在も安全性が高く、推奨される暗号技術です。イ:
AES_256_CBCも同様に推奨リストに含まれており、安全に利用可能です。ウ (正解):
3DESは「Sweet32」攻撃などの脆弱性が知られており、現在では利用が推奨されていません。エ (正解):
RC4およびMD5はいずれも深刻な脆弱性が発見されており、利用すべきではない非推奨の技術です。
設問3(2)qは，正答率がやや低かった。HTTPレスポンスである(8)と誤って解答した受験者が多かった。HTTPプロトコルの理解を深め，HTTPリクエストとHTTPレスポンスとのデータの違いをよく確認しておいてほしい。
設問4
〔W社によるリスク評価〕について答えよ。
(1)
本文中の下線③について，アクセストークンの取得に成功することが困難である理由を，表8中のパラメータ名を含めて，40字以内で具体的に答えよ。
模範解答
アクセストークン要求に必要なcodeパラメータを不正に取得できないから
採点基準(配点 8点)
知識・理解度（内容）(4点)
- 4点: codeパラメータを不正取得できても、検証コードがないためアクセストークンの取得に必要な条件を満たせない旨が正確に説明されている。
- 2点: アクセストークンが取得できない理由は記述されているが、説明がやや不足しているか、codeパラメータと検証コードの関係性が不明確。
- 0点: PKCEの仕組みについて誤った説明がなされている。
論理性（構造）(4点)
- 4点: 指定された「codeパラメータ」を含め、因果関係が論理的に破綻なく40字以内でまとめられている。
- 2点: 意味は通じるが、文脈にやや飛躍があるか、表現が不自然である。
- 0点: 論理が通っておらず、文章として成立していない。
解説
本設問は、OAuth 2.0におけるPKCE（Proof Key for Code Exchange）のメカニズムを理解し、不正なアクセストークン取得を防ぐ原理を説明する問題です。
高得点のポイント
単に用語を暗記するだけでなく、PKCEがどのように認可コード横取り攻撃を防ぐのか、その具体的な仕組みを理解していること。
攻撃者が
codeパラメータを不正取得できても、それに紐づく検証コード（code_verifier）を知り得ないため、トークンの要求に失敗する旨を論理的に記述すること。
(2)
本文中の下線④について，認可サーバがチャレンジコードと検証コードの関係を検証する方法を，“ハッシュ値をbase64urlエンコードした値”という字句を含めて，70字以内で具体的に答えよ。ここで，code_challenge_methodの値はS256とする。
模範解答
検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値と，チャレンジコードの値との一致を確認する。
採点基準(配点 8点)
知識・理解度（内容）(4点)
- 4点: 検証コードに対してSHA-256ハッシュ化とbase64urlエンコードを行い、その結果がチャレンジコードと一致するか確認することが正確に説明されている。
- 2点: ハッシュ化や比較の記述はあるが、対象（検証コードとチャレンジコード）の関係性や手順に一部誤りや不足がある。
- 0点: 暗号技術や検証方法について見当違いの説明をしている。
論理性（構造）(4点)
- 4点: 指定された「ハッシュ値をbase64urlエンコードした値」を含め、論理的かつ明確に70字以内で検証手順が記述されている。
- 2点: 意味は通じるが、文の繋がりにやや不自然な点がある。
- 0点: 論理が通っておらず、文章として成立していない。
解説
本設問は、PKCEにおいて、認可サーバーがトークン要求の正当性を検証する具体的な方法を記述する問題です。
高得点のポイント
code_challenge_methodがS256の場合、クライアントから送信された検証コード（code_verifier）に対して認可サーバーがSHA-256ハッシュ関数を適用することを理解していること。ハッシュ化された値をさらにbase64urlエンコードし、事前に受け取っていたチャレンジコード（code_challenge）と一致するかを比較・確認するという手順を正確に記述すること。
設問4は，(1)，(2)ともに正答率が低かった。OAuth 2.0のメカニズムについては，用語だけではなく，その具体的な方法を理解してほしい。また，ハッシュ関数など，暗号技術の基礎的な仕組みを理解しておくことが認証認可の中で使われるPKCEなどのメカニズムを理解する上でも重要であることを知ってほしい。
設問5
〔F社による原因調査〕について答えよ。
(1)
本文中の下線⑤について，第三者がXトークンを取得するための操作を，40字以内で答えよ。
模範解答
OSSリポジトリのファイルZの変更履歴から削除前のファイルを取得する。
採点基準(配点 8点)
知識・理解度（内容）(4点)
- 4点: OSSリポジトリの変更履歴（コミット履歴）から、削除される前のファイルを参照・取得することが正確に説明されている。
- 2点: 履歴から取得することには触れているが、対象のファイルや操作内容が曖昧である。
- 0点: 情報取得の経路について全く見当違いの説明をしている。
論理性（構造）(4点)
- 4点: 具体的な操作手順が論理的かつ簡潔に40字以内で記述されている。
- 2点: 状況は推測可能だが、説明表現にやや飛躍や不足がある。
- 0点: 論理が通っておらず、文章として成立していない。
解説
本設問は、OSSリポジトリ等で誤って機密情報（トークンなど）を公開してしまった際、攻撃者がそれを取得する経路を特定する問題です。
高得点のポイント
Gitなどのバージョン管理システムの仕組みを理解していること。
最新のコミットでファイルを削除しても、変更履歴（コミット履歴）を遡ることで削除前のファイル内容を参照可能であるという事実を明確に記述すること。
(2)
本文中の下線⑥について，権限管理の変更内容を，50字以内で答えよ。
模範解答
アップロードされたソースコードを承認する承認権限は，開発リーダーだけに与えるようにする。
採点基準(配点 8点)
知識・理解度（内容）(5点)
- 5点: ソースコードの承認権限を開発リーダーのみに限定することが明確に記述されている。
- 3点: 権限の限定には触れているが、対象者（開発リーダー）が明示されていない等、具体性に欠ける。
- 0点: 権限変更の内容について見当違いの説明をしている。
論理性（構造）(3点)
- 3点: 権限変更の意図と内容が論理的に破綻なく50字以内で記述されている。
- 1点: 意味は通じるが、文脈や表現に不自然な点がある。
- 0点: 論理が通っておらず、文章として成立していない。
解説
本設問は、インシデント再発防止の観点から、承認権限の絞り込みに関する設定変更を具体的に記述する問題です。
高得点のポイント
権限管理における「最小権限の原則」を正しく適用していること。
誰でもコードを承認できる状態から、開発リーダーのみに承認権限を制限する旨を明確に記述すること。
(3)
本文中の下線⑦について，見直し後の設定を，40字以内で答えよ。
模範解答
Xトークンには，ソースコードのダウンロード権限だけを付与する。
採点基準(配点 8点)
知識・理解度（内容）(5点)
- 5点: Xトークンに対して、ソースコードのダウンロード（または読み取り）権限のみを付与することが正確に記述されている。
- 3点: 権限の縮小には触れているが、具体的な権限内容（ダウンロードのみ）が曖昧である。
- 0点: 見直し後の設定について見当違いの説明をしている。
論理性（構造）(3点)
- 3点: 設定内容が論理的に破綻なく40字以内で明確に記述されている。
- 1点: 意味は通じるが、表現に不自然な点がある。
- 0点: 論理が通っておらず、文章として成立していない。
解説
本設問は、トークンに付与する権限を業務要件に照らし合わせ、最小限に絞り込む設定を見直す問題です。
高得点のポイント
対象のXトークンが本来必要とする操作（ソースコードのダウンロード等）のみに権限を制限するよう見直すこと。
不正なアップロードや改ざんを防ぐための根本的な対策として、ダウンロード権限（読み取り権限）だけを付与する旨を明確に記述すること。
設問5(1)は，正答率が低かった。インシデントの再発防止では，受けた攻撃の経路を特定することが重要であることを知っておいてほしい。設問5は，(2)，(3)ともに正答率がやや高かった。権限は，利用者には必要最小限しか与えないよう，慎重に検討することが求められる。業務などの要件と照らし合わせて，設定が必要最小限かどうかを確認してほしい。