【登録セキスペ】令和6年秋午後問4の解説（情報処理安全確保支援士試験）
このNoteでは「セキスペ令和6年秋午後問4」の解説をします。
※模範解答も別解も多いので、図解だけとか・分からないとこだけなど、絞って読まれた方が息切れしないかもです。
新SCになって午後1（2問）と午後2（1問）が廃止され、午後（2問）になりました。新SC午後は、午後2よりは短いのですが、作文文字数が無制限になるなど、深さが増しています。
私はプログラム系問題は見向きもしないのですが、令和6年秋の座学系（問1, 問2）が地雷だった時の備えが必要だと思い始めました。スタメン2問+控え1問の「3問体制」が良いかなと。
令和6年のプログラム系問題は、問3はソースコードがあり、問4はありません。HTTPの通信内容（ヘッダ）やHTMLやCSS程度なら呑めるかな。「プログラムコード問題を切った3問体制」で準備を進めれば良いかな、と考え至りました。次回もこの傾向であれば良いですが、新SCは未だ日が浅いので何とも…。
さて問4はWebサービスの悪用がテーマ。
「セッションハイジャック」や「メールヘッダインジェクション攻撃」を駆使します。プログラムというよりは、データ通信や処理の中身を見ているので、ネスペ寄りかも。
初見だと情報量が多くて混乱しますが、時間は沢山あります。演習でじっくり解いて復習したら「ちょっと理解して腰を据えればちゃんと点数稼げるなぁ」という印象。
下図で「赤×」がないことから理不尽ではないです。ただ初見で解いた感想はもっと難しいとは思います。解説や図をたくさん準備したので、何度も読んで頂けたら嬉しいです。
作文は多いですが、模範解答も3種×2も提案され、幅が広いよう。理解できた範囲、問題文に書かれた範囲で、解答を捻りだせば合格に粘れると思います。
私はSCPMIIを97点で独学合格し、IT専門学校で授業しています。このNoteには、授業で教えていること以上の情報を詰め込みました。
一所懸命に作ったので、信頼して下さったら嬉しいです。
それでは始めましょう！
長文問題なので、以下のテクニックを使います。解説の中でも適宜リンクしてますので、気が向いたら読んでみてくださいね。
＞長文問題を読む６つのテクニック
＞長文問題を解く６つのテクニック
＼私の3ヶ月の学習履歴／
問4も解く候補にした理由
そもそも私はプログラム系を切ってるので、問3と問4の見極め方を確立していません。旧SCの午後1を解いたときに、プログラム問題は使用言語やテーマがバラバラで、得点再現性がないと判断しました。
「PCで動けば良いのがプログラム」「PCでできることはPCでしたい」「紙面でやりたくない」。
＞SCの時間配分と問題選びNote
問4を選んだのは消去法。問3にソースコードがあったから。問4の画面遷移やHTTPレスポンスぐらいなら、どうにかなるかなと。
またプログラム系を選ぼうかと考え始めたのは、知識系の問1と問2がディープだったから。
問1も問2もテーマは頻出なので良いです。マルウェア感染と迷惑メール対策。しかし、問1は解き始めが絶望的に遅く、問2はSPF, DKIM, DMARCの詳細知識が必要。問1は選ぶけど、問2を選ぶかは自信が持てませんでした。
＞SCR6年秋午後問1の解説Note
＞SCR6年秋午後問2の解説Note
以上より、問1は解くとして、問2か問4のどちらかを選ぶ方針としました。
新SCの座学問題のレベルは間違いなく上がっています。今までアドバンスドだったものがベーシックになっています。
例えば今回の問2。SFPは今までも常識でしたが、DKIMとDMARCの中身が詳しく出るのが常識になりました。令和元年問1にジャブがあり、令和6年で確定しました。
＞SCR元年秋午後1問1の解説Note
＞SCR6年秋午後問2の解説Note
今後も「知らないと失点確実」な割合が増えていくと推測されます。座学問題を2問選べない場合があるので、プログラム系問題も1問選べる「3問体制」が良いかなと思い始めました。
PG系問題の読みについて
繰り返しになりますが。私はプログラム系を切ってるので、問題の読み方も確立されていません。
プログラムではない問題（知識・設定）では、表を読み飛ばすなどの解法が確立していますが…。
＞長文問題を読む６つのテクニック
＞長文問題を解く６つのテクニック
よって素直に読んでいきました。もちろん設問を最初に読んで、どこまで読むかぐらいの確認はしています。＞長文問題を読む６つのテクニック（１）
座学系問題では早く解き始めをするために表スキップなどもしていますが。表のスキップもせず、注釈も読んで、一歩一歩読み進めました。幸い図3と表1をカウントしなければ、解き始めの空欄aまで実質2頁ぐらいですから。＞長文問題を読む６つのテクニック（６）
読み | マーキングが重要
では問題文を読んでいきます。
読みながらマーキングするのはいつもの通り。組織やシステム名は四角囲み、数値は丸囲み、怪しいポイントは▼印。＞長文問題を読む６つのテクニック（３）
四角囲みだらけになりますがやります。「Mサイト」「氏名」「自宅住所」…「会社情報」「求人情報」…。あとでデータベースとか出るかもですからね。あと「WebAPI」。
【セキュリティ診断の診断対象と診断方法】
図1。
「Bからも～アクセスできるように、～設定を変更する」は設定戻し忘れないかな、「テスト用擬似データ」が業務用データと違ってテストで見落とすものはないかな。よくある怪しい表現なので▼印をしておきます。＞長文問題を読む６つのテクニック（３の３）
Webアプリの脆弱性はツールと手作業の2つなのに、Webサーバの脆弱性はツールのみなのも気になります。何かの隙になるかもと、▼印。
図2。
気になったのは、以下。
4(2)：なんで複数のAPIKeyを発行できるんだ？ 有効期限切れに先立って申請できるってことか？
注1：これはダメ絶対。利用者IDが容易に推測できます。
利用者IDはマズイですね。必ず問題になので▼印。
利用者IDは日付＋6桁の通し番号。
例えば、2025/01/01に一人でも会員登録すれば、利用者ID20250101000001は必ず存在します。容易に推測できますし、プログラムでIDを1つずつ増やして情報収集もできます。
202250101000001から1つずつ増やして「IDがありません」とエラーが出たら、202250102000001からまた始めれば、そのうち全会員の情報だって抽出できますね。
その意味では、2(3)。企業に問合せ/応募をしていない会員の求人情報を無尽蔵に検索できるのは疑問。求人者属性（希望職種・希望条件）で絞り込む検索なら分かりますが。
図3。
ざっくり見ます。日常経験と照らし合わせられると強いですね。
PWD変更が2通り（画面12～13, 14～17）あるのがリアルで、画面09後に2手に分かるのがややこしそう。
そして注記が多い…。解く時に見返すとは思いますが、見た感じ怪しい印象はなかったです。
表1。
URLなので、ほーっと。一応注記1。パスワード再設定のURLは「ランダム英数字32字」になってるから一安心。利用者IDは危なかったですが。
図4。やっと解きに入れそう。
図Aの攻撃の手口 | セッションハイジャック
最初から全貌を解説しますね。
図Aの手順1～7は穴埋めもあって混乱するので図解にしました。
要は、攻撃者が入手したsessionIDで、利用者にアクセスさせてIDとPWDを入力してログインしてもらう。攻撃者は「そろそろログインしたかな」って頃に試す。
よって対策は、ログイン成功した時に新しいsessionIDを発行して、ログイン成功した人にだけ渡す。攻撃者は新しいsessionIDを入手してないので、アクセスできない。
設問1(1)a | sessionIDは受付番号
正答は「イ」。
画面01で発行されたsessionIDが、画面遷移ア/イ/エでも同じになっているのが問題視されています。
各画面遷移の役割は以下。
ア：ログインに失敗してやり直し
イ：ログインに成功してシステム内へ
エ：ログイン済みでマイページへの遷移
sessionIDは「受付番号」と思うと良いかも。
sessionIDは、HTTP/HTTPS通信を特定するためのID。HTTP/HTTPSは「1問1答」。私たちは一連のアクセスと思っていましたが、イチイチ問うて答えられて終了、を繰り返しています。
sessionIDはWebサーバが「同じ相手の続きの通信だな」と判定するために使っています。よってsessionIDが盗まれると、なりすましアクセスができるんです。「セッションハイジャック」と云いますね。＞セキスペに出た73個の攻撃方法Note
遷移イは、画面01（ログイン画面）から画面02（ログイン済み画面）への遷移。ログインに成功したsessionIDを、攻撃者が使うとログイン後の画面を操作できます。
よって、遷移イ（画面01→02）のsessionID流用が脆弱。空欄aはイ、空欄bは「sessionIDを発行する」旨になります。
受付番号としてのsessionIDは誰にでも発行されてたので、悪用されます。よってログイン（認証）に成功した瞬間に、正当な利用者に改めてsessionIDを発行。仮番号と本番号みたいなものですね。
設問1(2)b | sesssionIDは受付番号だから
正答は「https://test.△△△.jp/」
必ず正解してください。
sessionIDが最初に発行されるページはログイン画面だから画面01。それだけ。お店や市役所に行ったら、受付番号は最初に発行されますよね。
そもそもログイン前にアクセスできるURLはほぼありません。例えば画面03（～/mypage）。ログイン前に直接アクセスしたら「ログインが未だですよ」と、画面01のログイン画面にリダイレクトさせるのが一般的ですね。
画面14, 15（～/pwreset）はログイン前にアクセスできます。01→14→15は、パスワードを忘れた方向けの処理なので。
しかし、画面01からの遷移を想定しているので、敢えて画面14でsessionIDを発行する必要はありません。
ログイン前のsesssionIDからのアクセスは、どのURLであっても画面01に飛ばす（リダイレクト）のが良いですね。
設問1(3)c | 攻撃者の目的を考える
模範解答は「メール受信者によるログイン」
正解できます。攻撃者の目的は、なりすましてシステムに入ることですから。
攻撃者が用意したsessionIDで、企業がログイン成功すれば、攻撃者はそのsessionIDを使えばログイン後画面にアクセスできるようになります。
図Aを、攻撃者がなりすましログインするまでの経緯に、書き直して解説しますね。
手順1：なりすます企業のメールアドレスを入手
手順2：画面01にアクセスしてsessionIDを入手
手順5：企業に罠サイトへの誘導メールを送る
企業が罠サイトにアクセスする
手順3のスクリプトが実行され、sessionIDと一緒にログイン画面に行く（システム的にはログインに1度失敗して再度ログインを試す状態）
企業がIDとPWDを入力してログインに成功する。サーバは、当該sessionIDがログイン済みであると認識する
手順7：攻撃者はsessionIDがログイン済みになったので、ログイン後画面02にアクセスできるようになる。sessionIDを持って画面02のURLにアクセスする。
「メールの受信者」と「ログイン」があれば正解ですね。「メールの受信者」は、別の書き方もできそう。
別解。
「罠サイトに誘導できた企業の社員がログインするの」が完了する。
「攻撃者が入手したsessionIDでログインされることが」が完了する。
など。
設問1(4)d | 再発行には削除も伴う
模範解答は「使用済みのsessionIDを無効にした上で、新しいsessionIDを発行」
正解してください。
今回は、ログイン前のsessionIDと、ログイン成功後のsessionIDが同じだから、悪用されました。よってsessionIDを再発行すれば良いと考え至ります。
「使用済みのsessionIDを無効」は、あった方が安全。ないと不正解寄りとは思います。
でも書けなかったら仕方がないので祈りましょう。「再発行だけでなく、以前のものを削除/無効することも必要なんだな」と学びになったので、次回から書ければ良いです。
設問1(5)e | HSTS
模範解答は「Mサイトへの接続をHTTPSを強制することができる」。
必ず正解してください。過去問で出てます。午前2に。＞HSTSのNote
理由はHTTP通信よりはHTTPS通信（暗号）が安全なので。もしHTTP通信されたら「次からHTTPSで通信始めましょう」と強制するんです。
表Dの3つのHTTPヘッダーは今回で完璧に覚える必要ありますね。さらに他のヘッダーも一覧にして学習ノートにまとめます。次の問題の後に補強しますのでご参考に。
設問1(5)f | Content-Type
模範解答は「Mサイトのコンテンツに対して、Content-Typeヘッダーで指定したMIMEタイプを強制的に適用することができる」。
例えば「日本語で話しましょう」って設定を強制するということ。HTTPで書かれるルール（MIME）をContent-Typeで示し、X-Content-Type-Optionsが「違う言語かなと、勝手に解釈しないでね」と強制する意志を示します。
なぜ強制するか。Content-Typeで形式を明記しても、Webブラウザは内容から勝手に判断し直す機能があります。攻撃者はその機能を悪用して、サイト制作側が予期せぬ動作をさせようと試みます。よって、想定/検証した動きだけをさせるために、Webブラウザに勝手な解釈をさせないよう縛ります。
HTTPヘッダを広く学ぶ必要があります。次回同じヘッダが問われる可能性が低いですが、他のヘッダは大いにあり得ます。
次節に、私がお世話になった上原本に書かれているHTTPヘッダを書き出し、優先順位を決めておきました。＞お世話になった上原本レビュー
補強 | HTTP, HTTPSのヘッダ
まず最優先はCookie周り。
午前でも午後でもよく出題されています。＞CookieのNote
Set-Cookie：サーバがCookieを設定する時に書き込む
Cookie：WebブラウザがCookieを送る時書き込む
expires：Cookieの有効期限
domain：Cookieが有効となるドメイン名
path：Cookieが有効となる領域（パス）
secure：HTTPSの時のみCookieを送付する
HttpOnly：Cookieの適用範囲をHTTP, HTTPSの時のみにする
次にHTTP/HTTPS通信で使われる項目。＞SSL/TLSのNote
HTTPリクエストヘッダ（PC→サーバ）
Authorization：認証方式
Referer：リンク元のURL
User-Agent：ブラウザの情報
Cookie：クッキー
Content-Type：ファイルや文字の種類
HTTPレスポンス（サーバ→PC）
Content-Type：ファイルや文字の種類
X-Content-Type-Options：Content-Typeで指定したMIMEを変更しない旨
Server：サーバのプログラム情報
Set-Cookie：クライアントにCookieをセットする
Location：リダイレクトさせるURL
X-Forwaded-For：プロキシやLBを通しても送信元IPアドレスを特定できる
Strict-Transport-Security：HTTPSによるアクセスを強制する
Content-Security-Policy(CSP)：Webブラウザで実行して良いスクリプトソースを限定する。XSSなどの攻撃を防ぐ。
必ず学習ノートに一覧表を書いて、いつでも見直せるようにしてください。インデックスラベルを貼って、ぱっと開けるようにすると更に良き。
設問2g | 使わなかったヒントを使う
模範解答は「画面09で、会社名に、図Cのabc@example.comを攻撃者のメールアドレスに変更した文字列を入力して変更ボタンをクリックする」。
正解してください。
空欄gはメールヘッダインジェクションの手順の途中。
(3)ではメアド変更手続きを悪用します。変更処理でメール送信されるけど、攻撃者は「メールアドレス」ではなく「会社名」に仕込んだメアドに送りたい。よって(2)は「会社名」にメアドを仕込む手順。
(2)～(3)で、企業に気づかれずメールアドレスの変更に成功。(4)でパスワードを再設定して、今後もなりすましログインできるように。
ここで読んでも解きに使わなかった図B・C・表C「メールヘッダインジェクション」を活かすわけです。読みながら「使わなかったなぁ」と気になってました。＞長文問題を解く６つのテクニック（３）
「画面09の企業プロパティ」の「会社名」に、「図Cのメアドや改行コードを含む文字列」を入力して「変更」を押下。「画面11」の処理で「会社名」にメアドが入った状態になる。
再度「画面09（会社名にメアド入った状態）」を開き、今度は「メールアドレス」に入力して「変更」を押下。「画面10」の処理でメールが送信される。
メールは「会社名」や「メールアドレス」を組み合わせて作成される。「会社名」にメアドが改行コードが入っている所為で、メールヘッダインジェクション攻撃が成立。メアド変更通知メールについて、インジェクションによって変更前アドレスにはメールは送られずabc@へ送られる。変更後アドレスのxyz＠にも送られる。どちらも攻撃者のメアドなので、企業には知られない。
補強 | メールヘッダインジェクション
メールはテキストです。
宛先（To）も件名（Subject）も文字で書かれています。そして区切りは改行。この2点がメールヘッダインジェクションを可能にしてしまいます。
メールを作成するプログラムは、会社名とメールアドレスを読み込んで、To:やSubject:を付け加えてメールを作成します。左図が本来作られるメール。
ところが、会社名に「%0D%0A」って特殊文字（改行）が入っていると、右図のように狂います。※%0D%0A（wikipedia）
●●会社名の後「%0D%0A」によって、メール件名が終了。次のTo:abc@～が宛先となり、「%0D%0A」が2発後は全てメール本文扱いになります。メール送信ソフトは、件名「●●株式会社」宛先「abc@～」と解釈します。
このようにプログラムと特殊文字を悪用するのがインジェクション攻撃です。
なお、データベースを不正利用する「SQLインジェクション攻撃」も同じ。SQL文を作るプログラムを、商品名に「’」などの特殊文字を入れ込んで悪用します。＞SCに出た73種類の攻撃手法Note
設問2h
模範解答は「画面04から一連の操作において、画面05又は画面07で再設定後のパスワードを入力して、WebAPIキーを確認又は発行する」
正解に近い解答を書いて下さい。せめて「WebAPIキーを確認」か「発行」は書いて下さい。
(7)でWebAPIを利用しているので、APIキーを知る必要があります。よって(6)にはAPIキーを知る方法を書きます。
ログインさえできればどうとでもできます。
2通り。
画面04（APIKey管理）で、「確認」ボタン、画面05でPWD入力して、画面06で発行済みKeyを知って使う。
画面04（APIKey管理）で、「発行」ボタン、画面07でPWD入力して、画面08で発行されたKeyを知って使う。
では解答を組み上げます。
設問文には「攻撃手順を答えよ」なので、片方で良いと思います。「全て挙げよ」「2つ答えよ」など具体的な指定がありません。WebAPIが使える手順を書けば正解でしょう。
別解。「画面02→03→04と行き、APIKey発行ボタンを押下する。画面07に(5)で設定したパスワードを入力する。画面08で発行されたAPIkeyを窃取する。」
設問文には「図3の画面名を使い」などの具体性への要求もありません。伝われば良いと思います。図Dでも画面名がちょっと書いてある程度なので。
もっとアバウトで貧相な解。「再設定したパスワードを使ってAPIkey発行をする」。こんぐらいでもギリ正解にしてくれるかも。(5)の「再設定」「パスワード」で理解してると伝わります。
勿論APIを確認する線も正解。「画面02→03→04と行き、APIKey確認ボタンを押下する。画面05に(5)で設定したパスワードを入力する。画面06で発行済みのAPIkeyを窃取する」。ボタンや画面の名前を変えた程度です。
なお「APIKeyを確認」の線は、当人にはバレないかもですね。「APIKeyを発行」だと、当人が「あれ？4個も発行したかな？」と気づく可能性も少なからずあり。
一方で「APIKeyを確認」しても有効期限切れで何も表示されないかも。その時は新規発行すれば良いだけですが。
ここまで解答に盛り込む必要はないです。「APIKey確認で、Keyがなければ新規発行する」まで書かなくても正解。確認か発行のうち1つだけで充分正解になりますよ。
設問3i, j | 模範解答の理由を理解する
模範解答を解釈しつつ、別解も考えてみます。
なお、模範解答の2番目は、空欄k, lの模範解答の2番目でもほぼ同じ文面。空欄i,j と 空欄k,lはほぼ同じ答えで良かったってことですね。びっくり。
模範解答１ | マーキングが活きた！
「求職IDが推測困難なものになるように、求職IDの生成方法を変更する」
「APIkeyが窃取された場合、当該求人企業への問合せ又は応募をした求職者の情報漏えいだけに被害を軽減することができるから」
表Fは「WebAPIの仕様」。空欄iは「仕様の改善」なのでWebAPIの仕様を見に行きます。図2が「WebAPIの仕様」。
ここでマーキングが役立ちます。怪しいと▼印した注。簡単すぎる利用者ID。
2025/01/01に一人でも会員登録すれば、利用者ID20250101000001は必ず存在します。よって「利用者IDが容易に推測できないような生成方法に変更する」の旨。逆に「利用者IDに日付や連番を使わないようにする」と否定形でも良いかも。
「利用者IDの生成方法を変更する」はちょっと弱い、「推測困難」の旨は欲しいですね。変更理由を伝えばなりません。この辺りが正解・不正解のラインでしょう。
理由が「利用者IDが推測できるから」は不正解寄りかなぁ。表F上に「被害を未然に防止」「被害を軽減」とあるんで、どんな被害を防止/軽減できるかが理由なので。
利用者IDを推測できる時の被害/できない時の効果を、図2WebAPIの仕様を見ながら考えます。
2(1)：問合せがあったIDは必ず知れます
2(2)：応募があったIDは必ず知れます
3(3)：任意IDを入力した情報取得
3(3)は該当するIDがなければ情報窃取できません。デタラメなIDを入力しても当たらないぐらいの桁数を設ければ良いです。宅急便のお問い合わせ番号ぐらいに。
よって3(3)で情報入手できる利用者IDは、2(1)・2(2)で問合せ・応募があった利用者のものだけ。「問合せか応募した利用者の情報漏えいだけに軽減」できる旨が、解答のコアになります。
別解３つ | ID検索への違和感
私は、図2WebAPIの「3(3)：任意IDを入力した情報取得」で違和感感じました。利用者IDで検索ってするかなぁと。マッチする求職者を探したいなら、希望条件で検索するのが一般的かなぁと。
「2(1)：問い合わせがあったID」「2(2)：応募があったID」は、教えても良いです。3(3)でID検索させるのも、他の仕組みができそうですが、まぁ良しとして別解1。
「図2の2(3)で検索できるIDを、当該企業に問合せ又は応募があった求人者IDに限定する」「情報漏えいの規模を、当該企業に問合せ又は応募した者だけに軽減できる」。全ての利用者の情報を検索して表示できるのがオカシイですから。
他には、「図2(1)と(2)のおいて、問合番号や応募番号を割り当て、3(3)による検索をIDではなく、問合番号や応募番号にする」「情報漏えいの規模を、～同じ」。
ただ「マッチング」なのに問合せ/応募の「待ち」だけになってしまうので検索も確保したい。でもIDで検索するのは違和感。普通は職種など希望条件ですよね。
問題文冒頭に「希望職種」「希望条件」という言葉もあります。
「図2(3)で検索できるIDを当該企業に問合せ又は応募した求人者に限定する。またマッチングのために希望職種や希望条件で検索できるAPIを設け、企業が検索できる検索条件は当該企業が関連するものに限定する」「情報漏えいの規模を、当該企業に問合せ又は応募した者だけに軽減できる。また、企業が検索できる利用者を求人に関係する者だけに軽減できる。」
企業から検索したい時は、企業に関連する職種・合う条件にある程度絞り込むのが良いと考えました。企業プロパティに職種や条件を設定する機能を追加すれば良いかなと。
この別解は深めなので、初見本試験では作れませんが、ご参考に。また別解分は2文になってますが、設問文に字数も文数の制限は書かれていないので、門前払いはされないと思います。
模範解答２ | よくある解答（送信元制限）
「WebAPIのアクセス元IPアドレスを限定して接続を許可するように変更する」
「WebAPIへの第三者による不正なアクセスを防ぐことができるから」
今回問われているのは「企業向けの機能」。求人サービスは出先ではなく社屋からアクセスするでしょう。いつも社屋からアクセスするなら、アクセス元で制限して良さそうですね。
不正アクセスに困った時のアクセス元制限は、セキスペ解答あるあるです。
なお、空欄k.lでも似た解答にしています。
模範解答３ | リスク回避の発想
「WebAPIで取得できる求職者属性情報は、個人を特定できないものだけに限定するように変更する」
「不正にWebAPIが利用されても、個人を特定できない情報の漏えいだけに被害を軽減することができるから」
「リスク回避」に近い考え方ですね。情報漏えいが怖ければ、情報を扱わなければ良い。APIでの個人情報の不正利用が怖ければ、個人情報を出力しないで良い。
補足 | 攻撃手順の全て
図Dの手順を図解にしました。
手順(1)(2)(3)で、利用者にバレずにメールアドレスを変更します。
手順(4)でパスワードを変更します。メールアドレスは変更済みなので、利用者には知られません。
更に補足。パスワードの変更はログイン前（忘れた人用）とログイン後の2通り。
ログイン後（画面12）だと現在のパスワードの入力も必要なので、攻撃者はできません。ログイン前（画面14～16）だと現在のパスワードなしで変更できます。
設問3k, l | 遠慮せず書こう
取っ掛かりを探せなかったので難しいですね。「求人企業向けの仕様」を探すのですが…。
自分の今までの経験、ITサービスを利用した経験から推測するのもテです。またちょっと感じてた違和感みたいなものを言語化。
模範解答の2番目は、空欄k, lと同じですが、本試験の時に迷ったら遠慮なく同じ解答・似た解答をして下さい。
設問で「攻撃」と「対策」などペアで答えさせるのは、よくある問題。あまり難しく考えて空欄にするよりは、シンプルに小分けにして書いたり、今回みたく同じ/似た解答をしてでも埋めてください。
今回は別解から先に提案して、模範解答の解釈をしますね。
別解１ | 「わざわざ」隙が書いてある
例えば図3下。わざわざ「クロスサイトリクエストフォージェリ対策が施されていない画面遷移」と書いてあります。なんか対策できるんでは？と違和感。ヒントは注記にあり。＞長文問題を解く６つのテクニック（５）
根拠が弱いですが「図3画面01から02への遷移など、CSRF対策が施されていない画面遷移について、対策を導入する」「CSRFによる、なりすまし操作を防止できるから」。図4の4章までの改修で解決済みなのか分かりませんし、どんな対策か具体的には分かりませんが、何か書くしかないので捻りだします。
別解２ | 日常生活を観察する
あとは日常生活から。＞長文問題を解く６つのテクニック（６の２）
日頃と違う環境からアクセスあったら別認証を要求される経験ありませんか？ google Driveへ自宅PCからではなく、出先のPCからアクセスした時など。「リスクベース認証」ですね。＞SCR4年春午後1問3の解説Note
別解。「ログイン時に、いつもログインしている通信・端末環境と違う場合、追加の認証作業を要求する」「本来の利用者は社屋からアクセスすると考えらえる。しかし攻撃者は全く異なる環境からアクセスするので、なりすましログインを検出しやすいから」。
模範解答１ | よくある解答（多要素認証）
では模範解答眺めましょう。
「ログインの認証を、多要素認証に変更する」
「アカウントの乗っ取りを防ぐことができるから」
たしかにIDとPWDを入力すれば誰でもログインできるのは問題点でしたね。図3画面01を見て違和感を感じれたら良かったですね。
過去問でも「多要素認証」は良く出ていたので、疑うセンスを身につけたいです。過去問の模範解答の流用は有効です。「公式が模範解答に出した技術を不正解にできるんかい？」ですね。＞長文問題を解く６つのテクニック（６の４）
たしかに問われているのは「企業向けの機能」。社員全員ではなく人事担当者の方、多くても部署の方でしょう。何らかの追加認証を要求しても応じられそう。
知識（PWD）以外の認証って何だろう。所有物か生体ですよね。部署で共有考えると所有物。例えばカードに書かれた番号とか、ワンタイムパスワードを発行するハード（やソフト）。生体認証は個人情報を業務で登録するのは抵抗がありそうですね。
模範解答２ | よくある解答（送信元制限）
「利用者ごとにアクセス元IPアドレスを限定して接続を許可するように変更する」
「第三者による不正なアクセスを防ぐことができるから」
今回問われているのは「企業向けの機能」。求人サービスは出先ではなく社屋からアクセスするでしょう。いつも社屋からアクセスするなら、アクセス元で制限して良さそうですね。
不正アクセスに困った時のアクセス元制限は、セキスペ解答あるある。
模範解答は送信元IPを使ってますが、たしかに企業なのでNAT/NAPTでグローバルIPアドレスを所有して使っているでしょう。
また「クライアント証明書」によって限定するのもよくある解答なので正解でしょう。事前インストールが必要ですが。
模範解答３ | シンプルかつ手厚いシステムへ
「求人企業プロパティ変更において、メールアドレス以外を変更した場合でも、メールを送信するように送信する」
「不正に求人企業プロパティが変更された場合に気付くことができるから」
たしかに画面遷移を見てた時、メールアドレス変更した時は通知して（画面10）、他の変更した時は通知しない（画面11）に分岐してたのは、理解が面倒でしたね。一本化してれば良かったのに。わざわざ処理を分けてます。
またセキュリティ面でも、企業の登録情報の変更だから、しっかり通知欲しいところでした。
まとめ
お疲れ様でした！
画面が多くて、画面遷移の注記が多くて、捌く情報が多いのであっぷあっぷしちゃいました。とはいえ、復習するとよく理解できて、初見力が上がった感覚があります。
最初に見た点数見込みの図。今ならちょっとはご賛同頂けるのではないでしょうか。
座学2問のうち1問が地雷ぽかったら、コードのないPG問題に切り替えても良いかなと考えています。コードありPG問題を切った「3問体制」。
新SC午後問題は旧SC午後2より短いけど、深さが増しているので、難しいです。私のNoteが少しでも理解や粘りの参考になったら嬉しいです。
頑張ってくださいね。応援してます。でわでわ！
＼私の3ヶ月の学習履歴／
いいなと思ったら応援しよう！
