はじめに
2024年度春に受けた安全確保支援士試験に一発合格できたので、その時の勉強方法などを書いていきます（午前Iは免除）。
ちなみに、私が受けた2024年度春は難化したと言われておりますが、当日特に焦ることもなく「いざ本番になると少し難しく感じたかも？」くらいで突破できました。
ちなみに、支援士の登録は今のところするつもりはないです。1年に1回の研修楽しそうですけどね。
参考
教材
過去問道場
午前Ⅱ対策は過去問道場やりまくれば大丈夫です！
全期間分の750問中630問解きました。
なお、最低1問2回は解いていて、間違えた問題は直前に何回か解き直しをしています。
情報処理教科書 情報処理安全確保支援士 2024年版
午前Ⅱ、午後含め安全確保支援士に必要な知識が網羅的に書いてある印象でした。
過去問道場で午前Ⅱ対策をしながらさらっと1周読んで知識をなんとなく入れていきました。
午後問題の演習が終わって最後の2週間くらいでもう一度読み直しました。
2024 情報処理安全確保支援士「専門知識＋午後問題」の重点対策
後述しますが、今回午後問題の対策をしっかりと行いました。
午後問題自体は公開されているのですが、解説が読みたいのでこの本を購入しました。この本に掲載されている問題は全て解きました（大問一問150分くらいかかるので時間が必要です）。
難しいと感じた大問は4月に入ってから解き直しを行いました。
うかる！ 情報処理安全確保支援士 午後問題集[第2版]
こちらも午後問題の対策本ですが独特で、マルが付きやすい回答の仕方や問題をパターン化してそのパターンを覚えてしまおうという本です。
なので知識がついて、ある程度午後問題の対策ができた人にオススメの本です（実際この本にもそう書いてあります）。
私は3月ごろからパラパラと空いたときに読んでいました。
実際午後問題を解いていると「なんでそれが答えなの？」ということが何回かあったので、出題者とシンクロすることを目的に、これを読んでおくと得点しやすくなるのではないかと思います。
学習スケジュール
12月後半から勉強し始めたので、かなり期間がありました。
12月中
安全確保支援士についてWebで検索して情報を集め、何をどれくらいやらないといけなそうかの見極めをした。
また、通勤時やスキマ時間に過去問道場で午前Ⅱ対策（以降試験までずっとやり続けていた）。
三が日
ひたすら「安全確保支援士教科書」を読んでいた。
2～3月ごろ
「重点対策」をひたすらやる。
たまに「うかる！」を読む。
4月～試験日まで
過去問道場の間違えた問題の総復習。間違いが0になるまで繰り返す。
「安全確保支援士教科書」をもう一周。
重点対策で難しいと感じた大問を解き直す。
引き続きたまに「うかる！」を読む。
受かったポイント
得意分野を作る
例えばネットワーク得意だな、とか業務でやってたから認証回りは得意だな、など得意分野があると当日選択する問題を悩まずに済むので、雑念が減って問題が解きやすくなります。
正直上記のスケジュールくらい勉強すればどの問題が出てもそこそこ解けるようになっているはずなのですが、厄介なのは試験当日、自分が選んだ問題より簡単な大問があるのでは？と考えてしまって集中できなくなることです。
私の場合はセキュアプログラミングの問題が出たので「得意！解きたい！」と思い即刻選択できたので、問題を解いていて悩む箇所が出てきてもそれを考え続けることができました。
そのおかげで、何とか答えに辿り着くことができたと思っています。
午後対策はちゃんとやった方が良い
個人的には応用情報までは、ここまでの対策をせずとも午後を突破できていた感触がありますが、安全確保支援士はそうではないと思っています。
学習の初めに安全確保支援士の午後問題はパッと見たとき、こんなことまで知らないといけないの？と思い、全てが知識を問う問題に見えました。
しかし、上記のようにしっかりと勉強した後に見てみると違いました。
勉強して基礎知識がついたことで 「これは流石に知らない仕組みだからきっと本文中にヒントがあるはずだ」 と考え、読解力を駆使して解けるようになりました。
つまり、安全確保支援士試験は勉強していない場合、すごい知識やスキルを持っていないと解けない問題であるかのように見えるのですが、勉強した後で見ると読解力でいけてしまう問題に見える ということだと思っています。
午後問題はなぜ間違えたかの振り返りをしっかりすべき
これは今デスぺの勉強をしていても感じていることなのですが、午後問題は解いて丸付けして終わり、というイメージではなく、なぜ間違えたのかの振り返りをしっかりとすべきだと思います。
なので、問題を解くときになぜその答えを書いたのかの考えの手順をメモ しておき「重点対策」などの解説と照らし合わせてどこに間違いがあったのか振り返ることが非常に重要 だと思います。
それをすると問題を解くのにかなり時間がかかるかもしれませんが、この振り返りを十分に行うことができれば、必ずしも「重点対策」全てを解き切る必要はないと思います。
セキュリティ初学者の方は手を動かすとよいかも
私はどの資格でも活きる知識 をつけてその資格を取りたいと思っています。
なので、以下のサイト等でハッキングに挑戦するなど実際に手を動かすことで活きたセキュリティに関する知識、スキルを得られると思います。
実際、SQLインジェクションやクロスサイトスクリプティング、クロスサイトリクエストフォージェリ等は自身の検証用のWebシステムで仕込んでみたりして遊びました。
その経験もあってかそのあたりの問題を間違えることは少なかった感触があります。
勉強メモ
最後に午前、午後それぞれの勉強メモを展開して終わりにしたいと思います。
午前問題重要事項
- Miraiはwebページの改ざんはしない
- CVEとかCVSSとかで構成されるものはSCAP
- ブロック暗号 CTRモード 排他的論理和
- 電子政府推奨暗号リスト
- FRR：本人拒否率
FAR：他人受入率 - WPA
暗号化プロトコル：TKIP
暗号規格：RC4 - WPA2
暗号化プロトコル：CCMP
暗号規格：AES - IEEE802.1x認証
IEEE802.11n：2.4GHz,5GHz
IEEE802.11ac：5GHz
IEEE802.11ax：2.4GHz,5GHz - ブルーレイディスクで使われているコンテンツ保護技術はAACS
- DVD-RAMやSDカードのコンテンツ保護技術はCPRM
- CPPMは、コンテンツをメディアに暗号化した状態で記録し、再生時に対応した機器で復号することで違法コピーを防止する技術
- ブラックボックステストのテストデータの作成方法は、機能仕様から同値クラスや限界値を識別し，テストデータを作成する。
- TLS1.3の暗号スイートは、認証暗号アルゴリズムとハッシュアルゴリズムの組みで構成されている。
- JIS Q 27001:2006における情報システムのリスクとその評価に関する記述
リスクの特定では，脅威が管理策の脆弱性に付け込むことによって情報資産に与える影響を特定する。 - ISO/IEC 15408は、IT関連製品や情報システムのセキュリティ機能の適切性・確実性について客観的に評価するための基準です。
午後問題重要単語
OAuth
- 概要: OAuthは、第三者アプリケーションがユーザーの代わりにリソースサーバー上のリソースにアクセスするための許可を得るためのプロトコルです。OAuth 2.0は最も広く使用されているバージョンです。
- 用途: OAuthは主に認可（Authorization）に使用されます。つまり、あるサービス（クライアントアプリケーション）が、ユーザーの許可を得て別のサービス（リソースサーバー）にアクセスするための仕組みを提供します。
OAuth 2.0
- 目的: OAuth 2.0は、第三者アプリケーションがユーザーの代わりにリソースサーバー上のリソースにアクセスするための認可フレームワークです。
- キーポイント: OAuth 2.0では、クライアント（第三者アプリケーション）は、リソースオーナー（ユーザー）の認可を得て、アクセストークンを使用してリソースサーバーにアクセスします。
OIDC（OpenID Connect）
- 概要: OIDCは、OAuth 2.0の上に構築された認証層です。OIDCは、ユーザーの認証情報（IDトークンなど）を提供することで、エンドユーザーの身元を確認することができます。
- 用途: OIDCは認証（Authentication）に使用されます。つまり、ユーザーが本当に彼らが主張する人物であることを確認するための仕組みを提供します。
state
-
概要: **
state**は、OAuthまたはOIDCの認証・認可リクエストに付加されるパラメータで、クライアントが生成するランダムな文字列です。 -
用途: **
state**パラメータは、CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐために使用されます。また、認証・認可プロセスが完了した後にクライアントが元の状態に戻ることを可能にします。
nonce
-
概要: **
nonce**は、OIDCの認証リクエストに付加されるパラメータで、クライアントが生成する一度限りのランダムな文字列です。 -
用途: **
nonceパラメータは、リプレイ攻撃（Replay Attack）を防ぐために使用されます。IDトークンが盗聴されて再利用されるのを防ぐため、クライアントはIDトークン内のnonce**値を検証する必要があります。 -
stateパラメータ
OAuthの「state」パラメータと「PKCE」、OIDCの「nonce」パラメータとは何か - Qiita
リソースオーナーから認可コードが送付されてくる時に一緒に送られてくるstateパラメータと突合することで、認可コードがインターセプトされたものではないことを確認する。
クライアント上ではなく認可サーバでstateパラメータを生成する手もあるのでは？とも思ったが、それだとクライアントと認可サーバ間の結合が強くなるので、柔軟性を確保すべく上記のような仕様になっている。
- Same-origin policy：スクリプトから別ドメインのURLに対してcookieが送られないwebブラウザの仕組み。
- MAIL FROMコマンド：SMTPでエンベロープの送信者メールアドレスを指定するのに使う。
- SPF：メール受信サーバが、メールに記載されている送信者のメールサーバのIPアドレスと、メールに記載されている送信者メールサーバのDNSサーバからのIPアドレス応答が同じであることを確認する仕組み。
- OCSP：電子証明書の失効情報を確認するためのプロトコル
- コードサイニング証明書：ソフトウェアの真正性を確かめるために使用する証明書。
- 改行コード：%0d%0a
- SEO回避：セクションにを記載する。
- CDNではオリジンサーバとキャッシュサーバで構成される。
- RFC7230では接続先サーバのFQDNをHTTPリクエストのHostヘッダに格納するように定めている
- リファラとはそのサイトを訪れる前に訪れたサイトの情報である。
- JSON Web Token形式ではヘッダ、ペイロード、署名はbase64urlでエンコードして送信される。
- サーバ証明書の種類
- ドメイン認証証明書（DV）
- 企業認証証明書（OV）
- EV-SSL証明書（EV）
- 電子政府推奨暗号リストに含まれる暗号技術
- AES、Camelia、ECDSA、RSA-OAEP、SHA-256、SHA-512
- 含まれていないもの
- DES、MD4、MD5
- デジタルフォレンジックスに必要な情報：ディスクイメージ
- DEP機能（Data Execution Prevention）：スタック領域やヒープ領域上のデータの実行を防止する機能。テキスト領域は守備範囲外。
- cookieにHttpOnly属性がついていると、HTML内のスクリプトからcookieを読みだすことができなくなる
- User-AgentヘッダフィールドとはWebブラウザのプログラムやバージョン番号を通知するために使用されるもの。
- 製品の脆弱性を示すCVSSには、CVSS基本値、CVSS現状値、CVSS環境値の3つがある。
- PKCEでは検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値とチャレンジコードを比較する。
- FTPでは以下の2つのコネクションがある。
- 制御コネクション：ポート21。
- データコネクション：ポート20もしくは制御コネクションで折衝された任意の番号。実際にファイルを送る。パッシブモード（クライアントからサーバに対してコネクションを確立するモード）とアクティブモード（サーバからクライアントに対してコネクションを確立するモード）の2つがある。
- SNMPv2ではpublicというコミュニティ名を使って機器のバージョン情報を取得し、結果ファイルに記録する。
- AレコードとTXTレコードの違い
Aレコード
Aレコードはホスト名に対応する宛先IPアドレスを設定する。
TXTレコード
TXTレコードは任意の文字列を設定可能。
- レースコンディション：並列動作する複数の処理が同一のリソースに同時にアクセスしたとき、想定外の処理結果が生じること。
- 悪手の例
- その便利な機能は今は利用していない
- IDを共用
- PCの電源を入れるのは久しぶり
- 更新されていない
- 構成管理は未導入
- 時間がかかった
- 対策は取られていない
- 手順は不明確
- 古いバージョンのまま
- じつは平文だった
- ログは取得していない
- 推測が容易なパスワード＝辞書攻撃に対して脆弱
- サーバ証明書の検証
サーバ証明書にsubjectAltNameのdNSNameがあれば、アクセス先のWebサーバNのFQDNと合致し、サーバ証明書にsubjectAltNameのdNSNameがなければ、アクセス先のWebサーバNのFQDNがsubjectのcommonNameと合致すること