問題はIPAからご確認ください。
https://www.ipa.go.jp/shiken/mondai-kaiotu/2021r03.html#aki_sc
答えはIPAの回答例となります。
設問１
問題 表2中の「ａ」～「ｉ」に入れる適切な内容を、“○”又は”×”から選び答えよ。
これはクラウドでの分類でよく目にする物ですね。
IaaS（Infrastructure as a Service）：マシン（VM）・ストレージ・ネットワークなどを提供
ユーザー管理：OS、ミドルウェア
土地だけを借りて、建物・内装などは自分で建てる感じ
AWS EC2・google（GCE）など
PaaS（Platform as a Service）：マシン（VM）・ストレージ・ネットワーク・OS・ミドルウェアなどを提供
ユーザー管理：アプリケーション、データ
土地・建物・厨房設備を借りて、料理を作る感じ
AWS Lambda・Azure Functionsなど
SaaS（Software as a Service）：完成されたソフトウェアを提供
ユーザー管理：ソフトウェア上のデータ
レストランへ人数分予約して食べに行くだけな感じ
Gmail・Microsoft 365・Slackなど
な感じですね
| 答え：斜めな階段になっています | ||
| Iaas | PaaS | SaaS |
| a:〇 | ｂ:✕ | c:✕ |
| d:〇 | e:〇 | f:✕ |
| g:〇 | h:〇 | i:〇 |
設問２
（１）
問題 表7中の「ｊ」～「ｌ」 に入れる適切な字句を、解答群の中から選び、記号で答えよ。
ア：一覧の閲覧権限、閲覧権限、編集権限
イ：一覧の閲覧権限、閲覧権限
ウ：一覧の閲覧権限
エ：なし
W社からD社への権限の付与となります。
D社は元々、データセンタにW社の日記サーバがあった時に表１の運用を委託していました。主に
・ログ保全：定期的に全ログを外部メディアにバックアップ
・障害監視：アプリ障害時の1次切り分け。ログを確認してサーバ一覧を参照
・性能監視：CPUの稼働率や処理性能・応答時間を監視。異常の際は1次切分を実施、サーバ一覧を参照
・機器故障対応：機器の故障対応
新たにクラウド管理となったので
ｊ：表５を確認すると仮想マシンサービスは公開Webサービスを提供しています。
これは監視項目で1次切り分けの為にサーバ一覧を参照しているので「ウ」ですね
ｋ：ＤＢサービスは特にD社では、なにもしていないので「エ」ですね
ｌ：モニタリングはデータセンタの時も監視していますが、、指標などは設定していないので「イ」ですね
答え ｊ：ウ
ｋ：エ
ｌ：イ
（２）
問題 本文中の下線①のイベント検知のルールを、JSON形式で答えよ。ここで、D社の利用者 ID は、1110～1199 とする。
日記サービスのログなので、参照してシステムIDは「4000」です
アカウントはD社で【D社の利用者 ID は、1110～1199 】なので表４の注記を参照すると、”11[1-9][0-9]”となります
対象のサービスは4000のログ管理ストレージなので「オブジェクトストレージ」です
イベントは表４を参照してログを削除した時のアラートなので、「オブジェクトの削除」です
答え：
{
“system”:”4000″,
“account”:”11[1-9][0-9]”,
“service”:”オブジェクトストレージサービス”,
“event”:”オブジェクトの削除”,
}
設問３
（１）
問題 文中、図3中及び図4中の「ｍ」～「ｏ」に入れる適切な字句を、“新日記サービス”又は“サービス T”から選び答えよ。
図４はユーザの項目がスマホとなっているだけで、フローに違いは無いです
m：「(1) サービス要求」はWebブラウザから始まり、Webサーバーにアクセスしますので、【新日記サービス】となります。
ｎ：(3) 認可要求の(8)アクセストークン応答といった処理は、OAuth 2.0では、ユーザーの認証と認可を行う役割を持つサーバー（認可サーバー）が担当しますので、連携対象であるT社のSNS【サービスT】となります
ｏ：機能要件1で会員が記事を投稿する際、他社の SNS にも同時に投稿できること。となっていて、Webサーバから(9) 記事投稿を実施しているので、【サービスＴ】となります
答え ｍ：新日記サービス
ｎ：サービスＴ
ｏ：サービスＴ
（２）
問題 表8中の「ｐ」、「ｑ」に入れる適切な番号を、図3中の番号から選び答えよ。
ｐ：GETメソッドなので、ブラウザが「XXの情報をください」とサーバーに要求するときに送信するものです
/authorizeなので、認可サーバへID：abcd1234を承認してって感じの内容ですので（３）となります
ｑ：ブラウザから取得した認可コードを使って、アクセストークンを発行してもらうものとなります
なので、（７）となります
答え ｐ：（３）
ｑ：（７）
（３）
問題 本文中の下線②について、CRYPTREC の“電子政府推奨暗号リスト (令和4年3月30日版)”では利用を推奨していない暗号技術が含まれる TLS 1.2の暗号スイートを、解答群の中から全て選び、記号で答えよ。
ア TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 AES-128
イ TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 AES-256
ウ TLS_RSA_WITH_3DES_EDE_CBC_SHA
エ TLS_RSA_WITH_RC4_128_MD5
ウ（3DES）とエ（RC4）は危殆化されていて、推奨されていない暗号方式となります。
またエ（MD5）もハッシュ関数では非推奨となります。
答え：ウ、エ
設問４
（１）
問題 本文中の下線③について、アクセストークンの取得に成功することが困難である理由を、表8中のパラメータ名を含めて、40字以内で具体的に答えよ。
エンコード値Gは表3の注2)に記載されている（クライアントのIDとシークレットを連結してbase64でエンコードした値）
攻撃者はエンコード値 G:（クライアント ID・シークレット）を持っています
しかし、表８を確認してみると、トークンの要求には
エンコード値 G
認可コード（code パラメータ）: ブラウザが取得し、新日記サーバに教える
redirect_uri:（コールバック URL）
が必要になりますが、攻撃者は認可コードは取得できません。
またれダイレクトのURLは新日記サービスとなるので、リクエストしても応答は新日記サービスに返されます。
答え：アクセストークン要求に必要なcodeパラメータを不正に取得できないから
（２）
問題 本文中の下線④について、認可サーバがチャレンジコードと検証コードの関係を検証する方法を、“ハッシュ値をbase64urlエンコードした値”という字句を含めて、70字以内で具体的に答えよ。
ここで、code_challenge_methodの値は S256 とする。
この問題は正規のスマホアプリと攻撃スマホアプリがあり、正規アプリのやり取りを攻撃アプリが横取りして、アクセストークンが不正に取得されてしまうとのことです。
なのでPKCE（ProofKeyCodeExchange）を使って、横取りを防止するようです。
１．スマホアプリは検証コード（code_verifier）を生成する
２．スマホアプリは検証コードを SHA256 でハッシュ化し、Base64url エンコードしてチャレンジコード（code_challenge）を生成
３．認可サーバーは、(3)認可要求でチャレンジコードを受け取ります
※チャレンジコードはURL パラメータとして送信されるので、攻撃者は盗聴可能
４．スマホアプリは（５）リダイレクトで認可コードを受け取る
※攻撃者はリダイレクトを偽アプリに受け取り、認可コードを取得可能
５．スマホアプリはリダイレクト先（Webサーバ）へ、検証コード（code_verifier）と認可コードをPOST の本文に含めて（６）認可コード送信
※攻撃者はPOST本文を盗んでもTLSで暗号化されているので、解読できない
6．認可サーバーは、(7) アクセストークン要求で送られてくる検証コードを受け取り、
「検証コード」をSHA256でハッシュ化して、そのハッシュ値を Base64urlでエンコードします。
エンコードした値と(3)認可要求で受け取ったチャレンジコードと一致するかどうかを比較する。
答え：検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値と、チャレンジコードの値との一致を確認する
設問５
（１）
問題 本文中の下線⑤について、第三者がXトークンを取得するための操作を、40字以内で答えよ。
リポジトリ（Repository）と主に「バージョン管理・コードの履歴を管理する場所」です。
リポジトリに開発者が間違ってファイルZをアップして、その後直ぐに削除しました。
しかし、表９の差サービスEの仕様を確認すると、バージョン管理項目で「ソースコードがアップロードされて承認されると、新バージョンとして記録され、変更履歴のダウンロードが可能となる」とあり、更に注記でリポジトリの利用者認証は不要とされていてダウンロードが誰でも可能となっています。
このことからリポジトリから誰でもダウンロード出来てしまう状態になっています。
答え：OSSリポジトリのファイルZの変更履歴から削除前のファイルを取得する。
（２）
問題 本文中の下線⑥について、権限管理の変更内容を、50字以内で答えよ
権限管理につてい見直しとなります。
現在のプロセスだと開発者・開発リーダなど全ての利用者に権限全てを付与しています。
適切な設定は
開発リーダに全権限（アップロード・アップロードの承認・ダウンロード）
開発者にはアップロード権限
X社CIにダウンロード権限
を与えるのが最小限で良いかと思います
答え：アップロードされたソースコードを承認する承認権限は、開発リーダーだけに与えるようにする
（３）
問題 本文中の下線⑦について、見直し後の設定を、40字以内で答えよ。
XトークンはEサービスがX社CIと連携するのに権限を付与するEトークンです
そして連携が必要なのはX社CIで、X社CIに発行するトークンはリポジトリWへの全権限が与えられています。
管理権限で確認した通り、X社CIの必要な権限はダウンロード権限ですので、これに絞れば良いです
答え：Xトークンには、ソースコードのダウンロード権限だけを付与する
コメント