問題冊子、解答例、採点講評はこれ

本文(設問1)

問題文(設問1)

解説(設問1)

午前で見た穴埋め。どこまで丸投げできるかという話ですね。基本的にIaaS→PaaS→SaaSと進むにつれてW社でやることはなくなります。IaaSはミドルウェアから管理が必要なので、〇〇〇(adg)、PaaSはアプリからで×〇〇(bdh)、SaaSはアプリデータのみで××〇(cfi)
正直非ITだとSaaS以外なじみがなくてわかりにくいところではある
答え a : 〇, b : ×, c : ×, d : 〇, e : 〇, f : ×, g : 〇, h : 〇, i : 〇

本文(設問2)

問題文(設問2)

解説(設問2)

(1)は必要な権限を埋めよう。D社は表1項番1～3を担当するらしく、監視時にマシン一覧が見れないのは流石に困るので、仮想マシンサービスの一覧は必要ですが、その中身が必要かと言うと障害や性能監視には不溶なのでjはウです。DBについては特に触れられていないので不要のエ。モニタリングは主に委託しているサービスですが、監視する性能指標はW社が定めるので閲覧権限までのイでいいでしょう。
答え j : ウ, k : エ, l : イ

(2)はD社がシステムから日記サービスのログを消すイベントを検知するルールをJSON形式で書けというもの。普段ならJSONと言われても…となるけど図1になにかありがたいものがあるので、これに倣います。
systemはシステムIDを書くということで、日記サービスのログは表5からログ保管ストレージの4000にあると思いますのでこれは決まり。accountは問題文から1110～1199ですが、正規表現にしないといけないようなので、11は固定で10～99を表現したい。これは表4注記に従って[1-9][0-9]になるので、11[1-9][0-9]です。続いてserviceは表4の取り得る値と編集権限を考えるとオブジェクトストレージサービスになります。最後にeventはそのままオブジェクトの削除です。
答え

本文(設問3)

問題文(設問3)

解説(設問3)

(1)はここ数年で2回目のOAuth2.0の認証の流れ。あくまで主で使うサービスは新日記サービスなのでmは新日記サービス。残りはサービスTに投稿するためのものなので、nもoもサービスTになります。(9)の記事投稿が紛らわしい
答え m : 新日記サービス, n : サービスT, o : サービスT
(2)はp, qのデータはいつ送られるのかについて。pはauthorizeとあるので認可の要求なことがわかります。そしてその結果を新日記サービスにredirectしろというところから(3)となります。
qはtokenとあるので(7)～(10)として、トークン要求のためのデータのようです。なので(7)となります。
どちらも知識問題に近いところ
答え p : (3), q : (7)
(3)はOAuthから少し離れて暗号スイートでもう古いのはどれか
知識なのであまり言うことはない。SHA256は強いって最近聞きました。
答え ウ, エ

本文(設問4)

問題文(設問4)

解説(設問4)

(1)はエンコード値G(クライアントIDと英数字と記号の文字列であるクライアントシークレットを連結してbase64でエンコードした値, (7)で出た)を攻撃者が入手、新日記サーバと偽ってリクエストを送信できるリスクがあるが、攻撃者が特定会員のアクセストークンを取得するリクエストを送って実際にアクセストークンが取得するのは困難なのはなぜか。qの中で秘匿にされるべき情報は何かと考えたときに2)の値とcode以降の値の2つがあります(他は一般的な内容しかない)。ただ2)の値はエンコード値Gでばれてるので、もう1つのcodeの値がばれなければ安全ということで、codeパラメータは不正に取得できないが答えになります。codeの値は(4)で使用される模様
答え アクセストークン要求に必要なcodeパラメータを不正に取得できないから
(2)はPKCEで(3)のリクエスト時にチャレンジコードとパラメータを追加、(7)で検証コードパラメータを追加して認可サーバが2コードの関係を検証するという話でどのように検証するのか。知識じゃん?
答え 検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値と、チャレンジコードの値との一致を確認する。

本文(設問5)

問題文(設問5)

解説(設問5)

(1)はXトークンなどをアップロードしたけど消したからセーフと思ってたらやっぱり誰かに取られてたという話で、どうやって取るのか。表9に戻りますが、バージョン管理の項目で削除もまた変更ということで、変更履歴として残っています。よって変更履歴から削除前ファイルを取得できるということです。
答え OSSリポジトリのファイルZの変更履歴から削除前のファイルを取得する
(2)は権限の見直しで、今回は開発者がアップロードして承認して削除してというのを1人でやってます。まあこんなの分離しようねという原則に従って承認権限は開発リーダーに投げるでいいと思います。
答え アップロードされたソースコードを承認する承認権限は、開発リーダーだけに与えるようにする。
(3)はトークンが漏れても不正プログラムが登録されないようにサービス連携を見直す。X社CIに発行するトークンには全権限が付与されてるらしいのでやりすぎということで、登録権限を外してダウンロード権限だけにします。
答え Xトークンには、ソースコードのダウンロード権限だけを付与する。

終わりに

OAuthの深い理解も必要というのと普通に難易度高めな感じ

主な参考サイト

【図解】TLSの暗号化スイートの見方とセキュリティ設定/脆弱性の確認方法
【解答速報】情報処理安全確保支援士 令和5年度春期【午後2問2】
OAuth 2.0 の認可レスポンスとリダイレクトに関する説明
一番分かりやすい OAuth の説明
OAuth 2.0 認可コードグラントフローについて理解したことをまとめます