平成29年度 秋期 午後Ⅱ（旧試験）

本文の根拠

表3 項番1 検査内容

1〜65535 の TCP ポートに SYN を送信し，応答結果からポートが開いているかどうか確認する。

表3 項番1 検査結果

TCP ポート 2323 が開いていた。

表3 の項番1 の検査内容は，1〜65535 の TCP ポートに SYN を送り，その応答結果からポートが開いているかどうかを確認するというものである。TCP の接続は SYN，SYN ACK，ACK の 3 ウェイハンドシェークで確立する（RFC 793）。接続を確立せず，最初の SYN への応答だけでポートの状態を判定する検査を，SYN スキャンという。解答例は“SYNスキャン”である。

検査結果の“TCP ポート 2323 が開いていた。”は，表2 の項番2 でマルウェア M が接続を要求するポート（23，2323，22，6789）のうち 2323 が開いていたということである。項番2 以降の“プロトコル確認”“ログイン試行”は，開いていたポートを見つけたあとの検査で，項番1 の名称にはならない。

字数の制限はない。“ポートスキャン”と書くと検査の種類を表すだけで，SYN を送るという検査内容そのものは出ない。検査内容に“SYN を送信し”とあるので，名称にも SYN を入れる。

採点講評（IPA）

設問1(1)及び設問2(1)は，いずれも知識問題であり，正答率が高かった。情報セキュリティに関する一般的な用語については，受験者の知識が高いことがうかがえる。

本文の根拠

表3 項番1 検査内容

1〜65535 の TCP ポートに SYN を送信し，応答結果からポートが開いているかどうか確認する。

表3 項番1 検査結果

TCP ポート 2323 が開いていた。

検査は SYN を送るだけなので，期待される応答は SYN への返事に限られる。ポートが開いている（待ち受けている）場合は，3 ウェイハンドシェークの 2 番目の SYN ACK を返す。したがって“開いている場合”はカ（SYN ACK 受信）である。

ポートが閉じている場合，RFC 793 は，存在しない接続宛てのセグメントには RST を返すと定めている。受け取った SYN には ACK の欄が無いので，この RST には ACK も付く（RST ACK）。したがって“閉じている場合”はエ（RST ACK 受信）である。解答例はこれに加えてク（応答なし）も挙げている。これは，途中のファイアウォールなどがパケットを破棄して，ポートが閉じていても何も返ってこないことがあるからだと考えられる。

解答群の ACK 受信（ア）・SYN 受信（キ）・FIN 系（イ，ウ）は，SYN を送った側が受け取る応答として現れない。オ（RST 受信）は RST ACK との区別が付きにくいが，解答例は RST ACK（エ）だけを選んでいる。“全て選び”とあるので，閉じている場合はエとクの両方を答える。

採点講評（IPA）

設問1(2)は，TCP/IPの3ウェイハンドシェークについての知識を問う問題であるが，特に“閉じている場合”について，正答率が低かった。サイバー攻撃に関するインシデント対応やセキュリティ検査においては，ネットワークの知識は重要である。基本的な事項は理解しておいてほしい。

本文の根拠

表3 項番6 検査内容

項番 5 で起動したプロセスが，bできるか確認する。

表2 項番1

HTTP を用いて C&C サーバと通信し，ボットとして活動する。

表3 項番5 検査内容

項番 4 でダウンロードしたファイルが起動できるか確認する。

表3 の検査は，表2 のマルウェア M の動作を順に確かめる構成である。項番2 のプロトコル確認と項番3 のログイン試行は表2 の項番2・3，項番4 のダウンロードと項番5 のプロセス起動は表2 の項番6（wget 又は tftp で入手して実行）に当たる。その次は，起動したマルウェアが表2 の項番1 の動作をするかである。表2 の項番1 は，HTTP を用いて C&C サーバと通信し，ボットとして活動する，という動作である。解答例は“HTTPを用いて，インターネット上のサーバと通信”である。

Z カメラが感染するおそれがあるかを調べるのが検査の目的である（“検査結果から，Z カメラがマルウェア M 又はその亜種に感染するおそれがあることが判明した。”）。項番5 までで，ログイン，ダウンロード，起動ができている。残るのは，起動したプロセスが外部と通信してボットとして動けるかである。

字数は 30 字以内で，解答例は 24 字である。“HTTP を用いる”と“インターネット上のサーバと通信”の二つを残す。“ボットとして活動できるか”だけでは，何ができれば活動できたと言えるのかが示されず，表2 の動作（HTTP での通信）まで書く必要がある。

本文の根拠

〔Z カメラのセキュリティ検査と対策〕

委託先が開発時に使ったデバッグ用プログラムとその起動スクリプトが，出荷版のファームウェアにそのまま残されていたことが分かった。

〔Z カメラのセキュリティ検査と対策〕

B 主任は，既に出荷済みの Z カメラがあることに配慮し，②対策を関係部署に依頼した。

〔Z クラウドの詳細〕(5) 接続・通信

Z クラウドから Z カメラへの各種操作コマンド及び設定情報の送信とファームウェアの配信は，Z カメラが定期的にカメラ IF にアクセスすることによって行われる。

表3 の項番1 で TCP ポート 2323 が開いていたのは，委託先が開発時に使ったデバッグ用プログラムとその起動スクリプトが，出荷版のファームウェアに残っていたからである。そこで，原因のデバッグ用プログラムとその起動スクリプトを削除したファームウェアを作る。出荷済みの Z カメラは手元にないが，ファームウェアの配信は，Z カメラが定期的にカメラ IF にアクセスして行われる。つまり，新しいファームウェアを Z カメラに配布すれば，出荷済みのものにも反映できる。解答例は“デバッグ用プログラムとその起動スクリプトを削除したファームウェアを作成し，Zカメラに配布する。”である。

設問は“出荷済みの Z カメラに対する対策”を問う。今後の出荷分の対策（出荷前にデバッグ用プログラムを残さない手順にする）では答えにならず，すでに利用者の手元にある機器へどう届けるかまで書く。

字数は 60 字以内で，解答例は 47 字である。“デバッグ用プログラムとその起動スクリプトの削除”“ファームウェアの作成”“Z カメラへの配布”の三つを残す。“ファームウェアを更新する”だけでは，何を直すのかが分からない。

本文の根拠

表4 項番1 検査方法

TLS 終端装置（注 1）の付いたプロキシサーバを用いて，Z カメラと Z クラウド間の HTTPS 通信の内容を復号して確認できるか検査する。

表4 項番2 検査方法

偽 Z クラウド上で稼働している偽カメラ IF に Z カメラを接続させて，Z カメラが操作できるか検査する。

図3 検査システムの概要

L3SW には，プロキシサーバ（内部に TLS 終端装置），DNS サーバ，偽 Z クラウド，L2SW が接続される。

項番1 は，通信の途中にプロキシサーバ（TLS 終端装置）を置いて，Z カメラとの TLS 接続を終端し，Z クラウドとは別の TLS 接続を開始して，HTTPS の内容を復号して見る検査である。通信する二者の間に割り込んで内容を見る攻撃なので，c はカ（中間者攻撃）である。

項番2 は，偽の Z クラウドに Z カメラを接続させる検査である。図3 の検査システムには DNS サーバがあり，Z カメラが Z クラウドの FQDN を問い合わせたときに偽 Z クラウドのアドレスを返せば，Z カメラを偽 Z クラウドに誘導できる。DNS の応答を偽って利用者を別のサーバに誘導する攻撃なので，d はア（DNS キャッシュポイズニング攻撃）である。

解答群の紛らわしい選択肢を除く。イ（サービス不能攻撃）とク（リフレクション攻撃）は通信を止めたり妨害したりする攻撃で，内容の盗聴や誘導ではない。エ（辞書攻撃）は認証の突破，オ（セッション固定攻撃）は Web セッションの乗っ取り，キ（水飲み場型攻撃）は利用者が訪れるサイトを改ざんする攻撃，ウ（サイドチャネル攻撃）は消費電力や処理時間などから情報を推定する攻撃である。

採点講評（IPA）

設問1(1)及び設問2(1)は，いずれも知識問題であり，正答率が高かった。情報セキュリティに関する一般的な用語については，受験者の知識が高いことがうかがえる。

本文の根拠

〔Z クラウドの詳細〕(5) 接続・通信

Z カメラにはカメラ IF の URL が，Z アプリにはアプリ IF の URL が，それぞれ組み込まれており，Z カメラ及び Z アプリは Web サーバに HTTPS の POST メソッドを用いて通信する。

〔Z クラウドの詳細〕(5) 接続・通信

インターネットから Web サーバへの接続は，HTTP over TLS（以下，HTTPS という）だけが許可されている。

カメラ IF 通信は，Z カメラがカメラ IF（Z クラウドの Web サーバ）にアクセスする通信で，Z カメラ及び Z アプリは Web サーバに HTTPS の POST メソッドを用いて通信する。Web サーバへの接続は HTTPS だけが許可されているので，無線 LAN の区間を含む通信全体が，HTTPS（HTTP over TLS）の TLS によって暗号化されている。解答例は“HTTPS”である。

直前の D 社の説明は，暗号化されていない又は暗号強度の弱い無線 LAN の盗聴だった。B 主任の反論は，無線 LAN の暗号方式の強さに頼るのではなく，その上を流れる通信そのものが暗号化されているから盗聴されても内容は分からない，というものである。

字数の制限はなく，“英字で”と指定されている。TLS だけでも暗号化の技術としては正しいが，本文が定義している“HTTP over TLS（以下，HTTPS という）”に合わせて HTTPS と書く。無線 LAN の暗号方式（WPA2 など）を答えないように注意する。

本文の根拠

〔カメラ IF 通信に対する脅威〕(2) 検査システムとサーバ証明書

なお，検査に当たっては，③プライベート認証局のルート証明書を，テスト対象の Z カメラに，信頼されたルート証明機関のものとして登録していない。

〔カメラ IF 通信に対する脅威〕(2) 検査システムとサーバ証明書

証明書 2：CN が，Z クラウドの FQDN と異なる証明書

〔カメラ IF 通信に対する脅威〕(3) 検査結果と対応

表 4 の項番 1 の検査結果：証明書 1 を使用した場合は通信でき，さらに通信内容を復号して確認することができた。しかし，証明書 2 を使用した場合は通信できなかった。

TLS のクライアントは，サーバ証明書を受け取ると，発行元をたどって，信頼されたルート証明機関にたどり着けるか（証明書パスの検証）を確認する。検査で使った二つの証明書はプライベート認証局が発行したもので，Z カメラにそのルート証明書を登録していない。それにもかかわらず，証明書1 を使うと通信できた。つまり Z カメラは，信頼されたルート証明機関まで到達できない証明書も受け入れている。証明書パスの検証が行われていないことが，この検査で分かる。

逆に，プライベート認証局のルート証明書を信頼されたルート証明機関として登録すると，そのルート証明書を使って証明書パスの検証が成功してしまう。Z カメラが検証をしていなくても，検証をしていても同じ結果（通信できる）になるので，検証の有無を確認できなくなる。解答例は“証明書パスの検証が行われているかを確認できなくなるから”である。

字数は 30 字以内で，解答例は 27 字である。“証明書パスの検証”と“確認できなくなる”の二つを残す。“検査結果が変わるから”のように結果だけを書くと，何の確認ができなくなるのかが示されない。

採点講評（IPA）

設問2(3)は，正答率が低かった。セキュリティ検査では，検査の目的に応じて，手法とテスト環境を検討し選択することが必要である。

本文の根拠

図1 注記2

Z クラウドの管理者は，管理用端末を用いて，インターネット経由で Z クラウドを運用管理している。

図1 注記2

緊急時：貸与された管理用モバイル端末を用いて，自宅で実施することも可

表5 整理番号A2

第三者による不正アクセスを防止するため，利用者認証に加えて，アクセス元の端末を制限しており，十分な対策が取られている。

下線④は，管理者アカウントのなりすましへの対策として，利用者認証に加えてアクセス元の端末を制限するというものである。Z クラウドの管理者は，インターネット経由で運用管理しており，通常は Z 社内又は委託先社内の管理用端末，緊急時は貸与された管理用モバイル端末を自宅で使う。自宅やモバイル回線では送信元の IP アドレスが一定せず，IP アドレスで制限する方法は Z システムに適さない。端末そのものを識別する必要があり，貸与した管理用端末だけにクライアント証明書を入れておき，TLS のクライアント認証で端末を確認する。解答例は“クライアント証明書を用いた端末認証を行う。”である。

貸与された端末に証明書を入れる方法なので，緊急時の自宅からのアクセスも通せる。端末に入っていない証明書は，第三者が利用者 ID とパスワードを知っても用意できない。

字数は 25 字以内で，解答例は 21 字である。“クライアント証明書”と“端末認証”の二つを残す。“IP アドレスで制限する”のように，通常時だけを想定した答えにならないようにする。

採点講評（IPA）

設問3(1)は，正答率が低かった。クラウドの利用拡大によって，クラウドにアクセスする端末が増える一方で，不正アクセス対策の重要度が増している。利用者認証だけでなく，端末を認証する方法についても理解を深めてほしい。

本文の根拠

図1 注記3

Web サーバのコンテンツ，及び Web アプリケーションサーバのプログラムの変更は，Z クラウドの管理者だけが実施できる。

表5

A2：管理者アカウントのなりすまし。

表5

D2：内部者の過失。

Web サーバ上のコンテンツを変更できるのは Z クラウドの管理者だけである。したがって，コンテンツの予期せぬ変更の原因は，管理者の権限が第三者や内部者に渡るか，管理者自身が誤るかのいずれかである。A2（管理者アカウントのなりすまし）は，管理者になりすませば変更できる。C2（OS やミドルウェアなどのシステム基盤の脆弱性を突いた攻撃）は，基盤の脆弱性を突いて管理者権限を得られれば変更できる。D1（内部者による犯行）と D2（内部者の過失）は，内部者が管理者権限を持つ場合に変更が起こり得る。解答例は“A2，C2，D1，D2”である。

A1（利用者アカウントのなりすまし）は，利用者の権限でのアクセスなので，管理者だけができるコンテンツの変更には至らない。B1（DDoS 攻撃）は可用性を損なう脅威である。C1（アプリケーションプログラムの脆弱性を突いた攻撃）は，動画の漏えいには結び付くが，ここで問われているのは Web サーバのコンテンツの変更である。

字数の制限はない。“該当する全ての脅威”とあるので，四つ全てを整理番号で答える。動画の漏えいの原因（A1，A2，C1，C2，D1，D2）との違いは，A1 と C1 が入らない点である。

本文の根拠

〔Z クラウドに対する脅威〕B 主任と E 君の会話

認証に失敗するごとに，その利用者 ID でログインできない期間を 5 秒間から最大 24 時間まで指数関数的に長くしていき，成功すると元に戻す仕組み（以下，ログイン制限という）

〔Z クラウドに対する脅威〕B 主任と E 君の会話

ブルートフォース攻撃ならログイン制限で防げる可能性が高いですが

ブルートフォース攻撃は，一つの利用者 ID に対してパスワードを総当たりで試す攻撃である。リバースブルートフォース攻撃は，その逆で，パスワードを固定し，利用者 ID を次々に変えて試す攻撃である。よく使われるパスワードを一つ選び，利用者 ID の方を変えながらログインを繰り返す。解答例は“利用者IDを変更しながら，よく用いられるパスワードでログインを試行する。”である。

本文はログイン制限（失敗するごとにその利用者 ID でログインできない期間を延ばす）をブルートフォース攻撃への対策としている。同じ利用者 ID を繰り返し試すブルートフォース攻撃は制限に掛かりやすいが，リバースブルートフォース攻撃は，利用者 ID が毎回違うので掛かりにくい。

字数は 40 字以内で，解答例は 36 字である。“利用者 ID を変更する”と“よく用いられるパスワードを使う”の二つを残す。“ID を固定してパスワードを総当たりにする”と書くとブルートフォース攻撃の説明になる。

本文の根拠

〔Z クラウドに対する脅威〕B 主任と E 君の会話

認証に失敗するごとに，その利用者 ID でログインできない期間を 5 秒間から最大 24 時間まで指数関数的に長くしていき，成功すると元に戻す仕組み（以下，ログイン制限という）

〔Z クラウドに対する脅威〕B 主任と E 君の会話

リバースブルートフォース攻撃やリスト型攻撃は，ログイン制限では防ぐのが難しい

ログイン制限は，認証に失敗するごとに，その利用者 ID でログインできない期間を長くする仕組みで，数える単位は利用者 ID である。リバースブルートフォース攻撃は利用者 ID を変えながら試し，リスト型攻撃は漏えいした利用者 ID とパスワードの組を一組ずつ試す。どちらも一つの利用者 ID に対する試行は 1 回か少数回で終わるので，失敗の回数が増えず，ログインできない期間が延びない。解答例は“一つの利用者IDでのログイン試行が1回ないしは少ない回数しか行われないから”である。

設問(3) の攻撃手法の説明と対になる設問で，ログイン制限が利用者 ID ごとの失敗回数に基づくことが分かれば答えられる。

字数は 40 字以内で，解答例は 37 字である。“一つの利用者 ID ごとの試行”と“回数が少ない”の二つを残す。“攻撃が分散されるから”のように曖昧にすると，何が分散されるのか（ID 単位の失敗回数）が伝わらない。

本文の根拠

〔Z クラウドに対する脅威〕B 主任と E 君の会話

最近は，ほかの Web サイトから漏えいした利用者 ID とパスワードのリストを悪用した，いわゆるリスト型攻撃が増えているそうです。

〔Z クラウドに対する脅威〕B 主任と E 君の会話

それでは，利用者 ID とパスワードに加えて，ほかの利用者情報，例えば電話番号や電子メールアドレスも使って認証するように変更すれば，防げるのではないでしょうか。

リスト型攻撃は，ほかの Web サイトから漏えいした利用者 ID とパスワードの組を使う攻撃である。E 君の案は，認証に電話番号や電子メールアドレスを加える方法で，攻撃者が ID とパスワードしか持たなければ防げる。ところが，ほかの Web サイトから漏えいした情報に電話番号や電子メールアドレスも含まれていた場合，攻撃者はそれらも入力できるので，追加の認証要素が意味を持たない。解答例は“ほかのWebサイトから漏えいした情報に電話番号や電子メールアドレスが含まれていた場合”である。

リバースブルートフォース攻撃は利用者 ID を推測で変えるだけなので，電話番号などを要求すれば当てられずに防げる。リスト型攻撃では，攻撃者が持つリストの中身が防御の成否を決める。

字数は 50 字以内で，解答例は 42 字である。“ほかの Web サイトから漏えいした情報”と“電話番号や電子メールアドレスを含む”の二つを残す。“情報が漏えいした場合”だけでは，どの情報かが分からない。

本文の根拠

〔Z カメラの詳細〕(2) 利用者情報の登録・変更

登録時には自動的に 10 進数 12 桁の利用者番号が付与される。利用者番号は，Web IF の利用者登録完了画面上に表示される。また，利用者登録完了通知書に記載され，登録した住所に郵送される。

〔Z クラウドの詳細〕(3) Z カメラの登録

譲渡や転売などの理由で，登録済みの Z カメラが他の利用者によって登録された場合，Z カメラの利用者を変更するとともに，変更されたことを元の利用者に電子メールを送って通知する。

〔Z クラウドに対する脅威〕B 主任と E 君の会話

Z クラウドと各利用者だけが知っていて，利用者以外が入手するのが困難な情報で追加認証すれば

追加認証に使う情報は，下線⑦のとおり，Z クラウドと各利用者だけが知っていて，利用者以外が入手しにくいものでなければならない。Z カメラを譲渡や転売すると，新しい持ち主は，Z カメラのシリアル番号，製品パッケージに同梱されたパスコードなどを知ることになり，これらは追加認証の情報にならない。元の利用者の電話番号や電子メールアドレスは，ほかの Web サイトから漏えいする可能性が上の設問で挙がっている。一方，利用者番号は，利用者登録完了画面と，登録した住所に郵送される通知書に記載されるだけで，Z カメラとは結び付いていない。そこで，利用者番号の入力を求める。解答例は“利用者番号の入力を求める。”である。

Z カメラの登録で入力する項目は，Z カメラのシリアル番号と初期設定用パスコードで，利用者番号は含まれない。

字数は 25 字以内で，解答例は 13 字である。“利用者番号”と“入力を求める”の二つを残す。“ユーザ ID”や“メールアドレス”は，上で述べた理由から答えにならない。

本文の根拠

〔Z クラウドに対する脅威〕B 主任と E 君の会話

利用者 ID とパスワードによる認証が必要となるのはごく限られた状況だけなので，平均すると利用者 1 人当たり，年 1 回程度です。

〔Z クラウドに対する脅威〕B 主任と E 君の会話

リバースブルートフォース攻撃やリスト型攻撃を念頭に置いて，⑧平常時と異なる状況が発生していると判断される場合において，追加認証する方法を考えてみます。

Z アプリは，2 回目以降は UUID で認証されるので，利用者 ID とパスワードによる認証が行われるのは，平均すると利用者 1 人当たり年 1 回程度である。全利用者の認証失敗は，平常時はごく少ない。リバースブルートフォース攻撃やリスト型攻撃は，一つの利用者 ID では失敗が少なくても，全体としては失敗が増える。そこで，全利用者の単位時間当たりの認証失敗数が，あらかじめ決めたしきい値を超えた場合を異常と判断し，その間は追加認証を求める。解答例は“全利用者の単位時間当たりの認証失敗数がしきい値を超えた場合”である。

利用者 ID ごとの失敗回数で数えると，設問(4) のとおり，これらの攻撃は見逃される。そのため，全利用者を合計して見る。

字数は 40 字以内で，解答例は 29 字である。“全利用者の”“単位時間当たりの認証失敗数”“しきい値を超えた場合”の三つを残す。“失敗が多い場合”だけでは，何を数えるのかが分からない。

本文の根拠

〔Z クラウドに対する脅威〕C1

表 5 の整理番号 C1 については，開発委託先との契約に⑨必要な条項を追加することにした上で，納品時に Web アプリケーションプログラムの脆弱性検査を実施することが決まった。

表5 整理番号C1

Web アプリケーションサーバ上のアプリケーションプログラムの脆弱性を突いた攻撃のリスクを軽減するための対策が取られていない。

C1 の対策は，納品時に Web アプリケーションプログラムの脆弱性検査をすることである。ただし，検査をして脆弱性が見つかっても，契約に定めがなければ，委託先に修正を求めたり納品を受け入れなかったりする根拠にならない。そこで，委託契約に，脆弱性検査に合格することを受入条件とする条項を入れる。解答例は“脆弱性検査合格を受入条件とする。”である。

検査の実施そのものは，条項を追加した上での手続として本文に書かれている。条項で決めるべきは，検査の結果を受け入れの可否に結び付けることである。

字数は 25 字以内で，解答例は 16 字である。“脆弱性検査合格”と“受入条件”の二つを残す。“脆弱性検査を実施する”だけでは，すでに本文にある検査の実施と同じで，契約条項としての意味が出ない。

本文の根拠

〔Z クラウドに対する脅威〕C2

OS，ミドルウェアなど，Z クラウドのシステム基盤については，V 社が毎年，年度末にセキュリティ専門業者の脆弱性検査を受けている。

〔Z クラウドに対する脅威〕C2

脆弱性検査の結果，重大な問題が指摘された場合，V 社は，定期メンテナンス時に，脆弱性修正プログラムを適用するか，又は回避策を実装している。

〔Z クラウドに対する脅威〕C2

脆弱性を突いた攻撃が頻繁に発生する昨今の状況を踏まえると，⑩構成管理を導入した脆弱性対応の仕組みを構築する必要がある

現在の C2 の対応は，年度末の脆弱性検査と，重大な問題が指摘されたときの定期メンテナンス時の対応である。脆弱性は検査の時期とは関係なく公表され，それを突く攻撃も頻繁に発生する。構成管理は，システムを構成する OS やミドルウェアなどの種類やバージョンを把握しておく管理で，これを導入していないと，新しい脆弱性が公表されたときに，自社のシステムが対象かどうかをすぐに調べられない。解答例は“脆弱性がZ社のシステムに影響するかを短時間で判断できない。”である。

判断が遅れる間，対応が次の検査や定期メンテナンスまで先送りされる。構成管理があれば，公表された脆弱性と照合して影響の有無を短時間で判断し，必要な対応を早められる。

字数は 40 字以内で，解答例は 29 字である。“脆弱性が Z 社のシステムに影響するか”と“短時間で判断できない”の二つを残す。“脆弱性管理ができない”のように抽象的に書くと，構成管理がなぜ要るのかが伝わらない。

本文の根拠

〔Z クラウドの詳細〕(4) 動画の保管

動画は，暗号化されずに保管される。

〔Z クラウドに対する脅威〕E 君と B 主任の会話

故意か過失かにかかわらず，内部者にも見ることができないような仕組みが必要です。

〔Z アプリの詳細〕(3) Z カメラの無線 LAN 接続の設定

Z アプリは，Bluetooth のシリアルポートプロファイルで Z カメラに接続し，Z カメラの無線 LAN 接続の設定を行う。

Z クラウドの管理者に見られないようにするには，Z クラウド側で鍵を作ったり保管したり，動画を復号したりしてはいけない。鍵を扱うのは，利用者の側にある Z アプリと Z カメラだけにする。動画を撮影して送る Z カメラが暗号化し，動画を参照する Z アプリが復号する。共通鍵は，Z アプリで生成する。解答例は，生成が“Zアプリ”，暗号化が“Zカメラ”，復号が“Zアプリ”である。

鍵を Z カメラに渡す経路が問題である。Z クラウド経由で渡すと管理者に見える。Z アプリは Bluetooth で Z カメラに直接接続して無線 LAN の設定を行っている（本文のとおり，Z カメラ自体には操作インタフェースが無く，外部記憶媒体も接続できない）ので，同じ経路で鍵を渡す。解答例は“Bluetooth経由で受け渡す。”である。

字数は 25 字以内で，共有方法の解答例は 17 字である。“Bluetooth 経由”と“受け渡す”の二つを残す。“安全に共有する”のように書くと方法が示されない。

本文の根拠

〔K1 システムにおける課題〕指摘 1 の根拠

a の安全対策基準（日本国内において金融機関などがよりどころとすべき共通の安全対策基準）では，b 暗号リスト（電子政府における調達のために参照すべき暗号のリスト）などに記載されている暗号技術を採用するのが望ましいとしているが，当該暗号リストにおいて，56bitDES は推奨されていない。

〔K1 システムにおける課題〕

X 社は，従業員数 10,000 名の生命保険会社である。

a は，日本国内で金融機関などがよりどころとすべき共通の安全対策基準で，金融情報システムセンター（FISC）が定めている。英字 4 字なので FISC である。b は，電子政府における調達のために参照すべき暗号のリストを示す語で，CRYPTREC（暗号技術検討会などによる暗号技術の評価・監視の取組み）の名を冠した暗号リストである。英字 8 字なので CRYPTREC である。解答例は a が“FISC”，b が“CRYPTREC”である。

X 社は生命保険会社なので，金融機関などの安全対策基準が当てはまり，その基準が採用を望ましいとする暗号技術は CRYPTREC 暗号リストに載っているものである。56bitDES はそのリストで推奨されていないので，指摘 1 の根拠になる。

字数は英字 4 字と 8 字に指定されている。講評も，業界ごとの代表的なセキュリティ基準と暗号に関する基準は，セキュリティ要件を定義する際に参照すべきものなので知識をもっておいてほしいと述べている。

採点講評（IPA）

設問1(1)は，知識問題であるが，正答率が低かった。業界ごとの代表的なセキュリティ基準，データ暗号化に関する基準は，セキュリティ要件を定義する際に参照すべきものであり，代表的なものについては知識をもっておいてほしい。

本文の根拠

〔K1 システムにおける課題〕

1998 年に開催された第 2 回 DES 解読コンテストにおいて，4 万台の PC で 56bitDES の全鍵空間の 80％を探索し，40 日で解読した。

〔K1 システムにおける課題〕

解読所要時間はプロセッサの MIPS 値に反比例する。

〔K1 システムにおける課題〕

2017 年製の PC に搭載されたプロセッサの MIPS 値を，133,920 MIPS と仮定する。

1998 年のコンテストの PC は 540 MIPS で，2017 年製の PC は 133,920 MIPS である。設問の注記のとおり 133,920＝540×248 なので，2017 年製の PC は 1 台で 248 台ぶんの処理ができる。解読所要時間は MIPS 値に反比例するので，同じ時間（40 日）で同じ範囲（全鍵空間の 80％）を探索するのに要る台数は 40,000÷248＝161.29… となる。小数第 1 位を切り上げて 162 台である。解答例は“162”である。

検算は，台数×MIPS 値が同じになることで行える。40,000×540＝21,600,000 で，162 台では 162×133,920＝21,695,040 となり足りている。161 台だと 161×133,920＝21,561,120 となって 21,600,000 に届かない。

字数の制限はなく，台数を整数で答える。単純に切り捨てて 161 と答えると，同じ時間内に解読できない。“切り上げて整数”という指定は，この点を問うている。

採点講評（IPA）

設問1(2)及び設問1(3)は，正答率が高かった。多くの受験者が，比較的簡単な前提条件に基づいて，リスクを特定したり数値化したりする能力をもっていることがうかがえる。

本文の根拠

〔K1 システムの現在の運用〕(2)

システム管理者が担当

〔K1 システムの現在の運用〕(3)

オペレータとシステム管理者には，DBMS と Web アプリケーションサーバソフトウェアとを除くミドルウェア及び OS 上の全ての操作権限が付与されており，その他の権限は付与されていない。

〔K1 システムにおける課題〕指摘 2

契約情報の暗号化及び復号に用いる鍵が平文でファイルに保管されており，オペレータ及びシステム管理者に当該ファイルのアクセス権が付与されている状況である。

〔K1 システムの現在の運用〕(4)

契約情報は，業務アプリケーションが，共通鍵暗号方式で暗号化し，DB サーバに保管している。

契約情報は，業務アプリケーションが共通鍵暗号方式で暗号化して DB サーバに保管している。その鍵が平文でファイルに保管されており，オペレータとシステム管理者に当該ファイルのアクセス権が付与されている。この二つの職種には OS 上の全ての操作権限があるので，暗号化された契約情報と鍵のファイルを入手でき，鍵で復号して契約情報を取得できる。解答例は“オペレータ及びシステム管理者が，暗号化された契約情報を暗号化・復号に用いられる鍵を用いて復号し，取得するリスク”である。

指摘 2 は，暗号化していても鍵が平文で置かれ，その鍵に触れる者がいれば，暗号化の意味が薄れるという指摘である。解答に必要なのは，“誰が”（オペレータ及びシステム管理者）と“どのような方法で”（鍵を用いて復号）である。

字数は 60 字以内で，解答例は 55 字である。“オペレータ及びシステム管理者”，“鍵を用いて復号”，“契約情報を取得するリスク”の三つを残す。“内部者が不正に取得する”のように書くと，どの職種が，何を使うのかが分からない。

採点講評（IPA）

設問1(2)及び設問1(3)は，正答率が高かった。多くの受験者が，比較的簡単な前提条件に基づいて，リスクを特定したり数値化したりする能力をもっていることがうかがえる。

本文の根拠

〔暗号方式の検討〕

NIST が定めた c 140-2 は，暗号モジュールに求められるセキュリティ要件を定義したものである。

〔暗号方式の検討〕

製品 H は，c 140-2 Level 4 の要件を満たすハードウェアの暗号モジュールであり

NIST が定めた暗号モジュールのセキュリティ要件の規格は FIPS 140-2（Security Requirements for Cryptographic Modules）で，レベル 1〜4 の 4 段階がある。本文の“140-2 Level 4”がその最上位のレベルである。英字 4 字なので FIPS である。解答例は“FIPS”である。

FIPS は NIST が公表する連邦情報処理標準（Federal Information Processing Standards）で，暗号モジュールの要件はその 140 番である。英字 4 字の指定と“NIST が定めた”が手掛かりになる。

字数は英字 4 字に指定されている。講評は，設問 2 の HSM に関する知識問題は(5)を除いて正答率があまり高くなかったと述べている。暗号モジュールの検証規格として FIPS 140-2 を押さえておく。

採点講評（IPA）

設問2は，HSMに関する知識問題であるが，(5)を除いて正答率があまり高くなかった。HSMは，データ暗号化に用いられる鍵を安全に管理する技術である。基本的な知識をもっておいてほしい。

本文の根拠

製品 H の仕様 1 初期化

マスタ鍵は，3 人の鍵管理者が別々に管理端末から入力した 256 ビットの値（以下，部分鍵という）の排他的論理和によって生成され，製品 H のメモリ内に保持される。

仕様 1 では，マスタ鍵は 3 人の鍵管理者が別々に入力した部分鍵の排他的論理和で作られる。1 人が知っているのは自分の部分鍵だけで，ほかの二人の部分鍵が分からなければマスタ鍵は求まらない。比較対象の，1 人の鍵管理者が三つの部分鍵を入力して 3 枚の IC カードに保管する場合は，その 1 人が三つの部分鍵を全部知るので，単独でマスタ鍵を復元できる。したがって仕様 1 の効果は，単独の鍵管理者ではマスタ鍵を復元できないことである。解答例は“単独の鍵管理者ではマスタ鍵を復元できない。”である。

部分鍵を別々の IC カードに別々に保管するという仕様 1 の条件も，同じ考え方である。鍵を分けて，複数の者が揃わないと使えない状態にする。

字数は 25 字以内で，解答例は 21 字である。“単独の鍵管理者”と“マスタ鍵を復元できない”の二つを残す。“不正が防げる”のような抽象的な書き方だと，仕様 1 の効果として何が起きるのかが示されない。

採点講評（IPA）

設問2は，HSMに関する知識問題であるが，(5)を除いて正答率があまり高くなかった。HSMは，データ暗号化に用いられる鍵を安全に管理する技術である。基本的な知識をもっておいてほしい。

本文の根拠

製品 H の仕様 1 初期化

部分鍵は，管理端末に接続された IC カードリーダ／ライタを用いて，別々の IC カードに保管することができる。

製品 H の仕様 1 初期化

製品 H のメモリは，製品 H の内蔵バッテリによって駆動する。

製品 H の仕様 5 マスタ鍵のゼロ化

①センサが次のいずれかを検知すると，製品 H は，メモリ上に保持されているマスタ鍵をゼロ化するとともに，自身を使用不能で，かつ，元に戻せない状態にする。

マスタ鍵は製品 H のメモリ内にしか保持されず，そのメモリは内蔵バッテリで駆動する。製品 H が故障して交換したり，仕様 5 のゼロ化（自身を使用不能で，かつ，元に戻せない状態にする）が起きたりした場合は，新しい製品 H にマスタ鍵が無い。鍵ストアファイルのデータ鍵はマスタ鍵で暗号化されているので，マスタ鍵が無いとデータ鍵を復号できず，契約情報を復号できなくなる。そこで，IC カードの部分鍵を管理端末から入力して，マスタ鍵を復元する。場合は“製品Hを交換した場合”，目的は“マスタ鍵を復元するため”である。

IC カードに記録されるのは，部分鍵であってマスタ鍵そのものではない。3 人の鍵管理者が別々に保管する点は，設問(2) の効果と合わせて読む。

字数は場合・目的ともに 15 字以内で，解答例は 10 字と 11 字である。場合は“製品 H を交換した”，目的は“マスタ鍵を復元する”を軸にする。“故障した場合”だけでは，故障したとなぜ必要になるのかが示されない。

採点講評（IPA）

設問2は，HSMに関する知識問題であるが，(5)を除いて正答率があまり高くなかった。HSMは，データ暗号化に用いられる鍵を安全に管理する技術である。基本的な知識をもっておいてほしい。

本文の根拠

製品 H の仕様 5 マスタ鍵のゼロ化

①センサが次のいずれかを検知すると，製品 H は，メモリ上に保持されているマスタ鍵をゼロ化するとともに，自身を使用不能で，かつ，元に戻せない状態にする。

製品 H の仕様 5 マスタ鍵のゼロ化

(b) 製品 H のカバーのこじ開け又は損傷

下線①は，センサが電圧の異常やカバーのこじ開け又は損傷という物理的な攻撃を検知すると，製品 H がマスタ鍵をゼロ化して自分自身を使えなくするという仕組みである。外から物理的に攻撃されても，内部の鍵などの情報を取り出せないようにする性質を，耐タンパ性という。解答例は“耐タンパ性”である。

“タンパ”は tamper（不正に手を加える）に由来し，耐タンパ性は tamper resistance の訳である。暗号モジュールは，鍵を守るために，ソフトウェアの面だけでなく物理的な攻撃への耐性も備える。

字数は 7 字以内で，解答例は 5 字である。“耐タンパ性”と書く。“物理的な保護”のように性質の名前でなく説明を書くと，7 字を超えるうえに，用語を問う設問の答えにならない。

採点講評（IPA）

設問2は，HSMに関する知識問題であるが，(5)を除いて正答率があまり高くなかった。HSMは，データ暗号化に用いられる鍵を安全に管理する技術である。基本的な知識をもっておいてほしい。

本文の根拠

製品 H の仕様 5 マスタ鍵のゼロ化

(a) 電気的短絡（ショート）の発生などによる規定の範囲を超える電源電圧の発生

製品 H の仕様 5 マスタ鍵のゼロ化

①センサが次のいずれかを検知すると，製品 H は，メモリ上に保持されているマスタ鍵をゼロ化するとともに，自身を使用不能で，かつ，元に戻せない状態にする。

製品 H の仕様 5 マスタ鍵のゼロ化

内蔵バッテリの交換手順として，(a)の発生を回避する手順が提供されている。

仕様 5 は，センサが(a)規定の範囲を超える電源電圧の発生，又は(b)カバーのこじ開け・損傷のいずれかを検知すると，マスタ鍵をゼロ化して製品 H を使用不能にすると定めている。静電気防止シートで覆わずに運搬すると，静電気の放電が起きて，規定の範囲を超える電源電圧が生じるおそれがある。これが(a)に当たり，センサが検知して，製品 H はマスタ鍵をゼロ化し，自身を使用不能で戻せない状態にする。事象の解答例は“静電気の放電による規定の範囲を超える電源電圧の発生”，機能の解答例は“事象をセンサが検知し，製品H自身を使用不能で戻せない状態にする。”である。

本文は，内蔵バッテリの交換でも(a)の発生を避ける手順を設けていて，電源電圧の異常を避けることが運用上の関心であると分かる。

字数は 40 字以内で，解答例は事象が 25 字，機能が 32 字である。事象は“静電気の放電”と“規定の範囲を超える電源電圧の発生”，機能は“センサが検知”と“使用不能で戻せない状態にする”を残す。“製品 H が壊れる”のような一般的な書き方は，仕様 5 の機能として答えにならない。

本文の根拠

H クライアントと H サーバの仕様 (2) H サーバに対する負荷分散

H クライアントは，登録された H サーバのうち稼働している H サーバに，ラウンドロビン方式で API-X の実行要求を送信する。

製品 H の仕様 3 鍵の生成

生成されたデータ鍵は，製品 H においてマスタ鍵で暗号化され，データ鍵 ID とともに鍵ストアファイルに保管される。

製品 H の仕様 4 暗号化又は復号

鍵ストアファイルに存在しないデータ鍵 ID を指定して暗号化又は復号を行おうとすると，API-X の処理結果はエラーとなる。

DB 及び表領域の作成手順

(ⅷ) 鍵ストアファイル 1 を，鍵ストアファイル 2 及び鍵ストアファイル 3 にコピーする。

H クライアントは稼働している H サーバに順番に実行要求を送り，最初の要求は H サーバ 1 に送られる。図3 では，DB 作成は鍵生成の要求 1 回，表領域作成は乱数生成と暗号化の要求 2 回である。(ⅲ)の DBα 作成の鍵生成は H サーバ 1 に送られ，DBα の DB マスタ鍵は鍵ストアファイル 1 に保管される。(ⅳ)の DBβ 作成の鍵生成は次の H サーバ 2 に送られ，鍵ストアファイル 2 に保管される。(ⅴ)の表領域 1 の作成では，乱数生成が H サーバ 1 に送られ，暗号化(DBαのDBデータ鍵，DBαのDBマスタ鍵ID)が H サーバ 2 に送られる。鍵ストアファイル 2 には DBα の DB マスタ鍵が無く，仕様 4 のとおり API-X の処理結果はエラーとなる。解答例は手順が“(ⅴ)”，コマンドが“暗号化(DBαのDBデータ鍵，DBαのDBマスタ鍵ID)”，原因が“DBαのDBマスタ鍵が鍵ストアファイル2に存在しないこと”である。

(ⅰ)で HSM サーバ 1 だけを稼働させるのは，鍵の作成を鍵ストアファイル 1 だけに集め，(ⅷ)でそれを他の鍵ストアファイルにコピーするためである。2 台を稼働させると，鍵ストアファイルが別々に更新される。

字数は 35 字以内で，コマンドの解答例は 28 字，原因の解答例は 28 字である。コマンドは図3 の形式に，図4 の用語（DBα）を当てはめる。“どの DB のものか”を落とすと，設問の指定に反する。原因は“鍵ストアファイル 2”と“DB マスタ鍵が存在しない”の二つを残す。

採点講評（IPA）

設問3(1)は，DBMSの暗号化機能，HSM，及びHSMをネットワーク経由で利用するためのソフトウェアの3種類の構成要素を組み合わせたデータ暗号化の設計に関する設問であるが，正答率が低かった。鍵を安全に保護した上でデータを暗号化する仕組みについての理解を深めてほしい。また，設問文で求められている解答形式から大きく逸脱した解答が多かった。他者と協力して業務を行う技術者は，問いと解答形式を正しく理解し，求められている解答を的確に表現できるよう基本的なコミュニケーション能力を身につけてほしい。

本文の根拠

H クライアントと H サーバの仕様 (1) API-X の実行要求

H クライアントは，内部でデータ鍵 ID を 0 から順番に採番して H サーバに API-X の実行要求を送信し，鍵生成が成功した場合にデータ鍵 ID を API-X の出力値としてリモートプログラムに返す。

製品 H の仕様 3 鍵の生成

既に鍵ストアファイルに存在しているデータ鍵 ID を指定してデータ鍵を生成しようとすると，API-X の処理結果はエラーとなる。

〔DB サーバ及び HSM サーバの構成設計〕

HSM サーバは，K2 システム以外のシステムの DB サーバを含めた全 DB サーバからも共有できるようにする。

H クライアントは，鍵生成のたびにデータ鍵 ID を 0 から順に採番して H サーバに要求する。H クライアント ID を付け加える機能が無いと，この ID は H クライアントごとに独立した番号になる。HSM サーバを複数のシステムの DB サーバが共有する図5 の構成では，複数の H クライアントが同じデータ鍵 ID（例えば 0）で鍵生成を要求することになる。既に存在するデータ鍵 ID での鍵生成は仕様 3 のとおりエラーになるので，後から要求した DB 作成が失敗する。解答例は“複数のHクライアントが送信したデータ鍵IDが重複した場合”である。

追加される機能は，H クライアント ID と従来のデータ鍵 ID を結合した新たなデータ鍵 ID にする（K2.nnnnnnnn や V.nnnnnnnn の形）ことで，H クライアントごとに ID が重複しない。

字数は 40 字以内で，解答例は 28 字である。“複数の H クライアント”と“データ鍵 ID が重複”の二つを残す。“同時に DB を作成した場合”とだけ書くと，なぜエラーになるのかの原因（ID の重複）が示されない。

本文の根拠

〔K2 システムにおけるリスク対策の補完〕

不審なアクセスがないか監視する。具体的には，週次で，業務アプリケーションのログから，業務時間外のアクセス及び大量の契約情報へのアクセスがないかチェックし，もしあれば，その内容を確認する。

〔K1 システムの現在の運用〕(4)

業務処理を行う際，業務アプリケーションは，DB サーバから契約情報を読み出して復号する。

〔K1 システムにおける課題〕

契約者が PC の Web ブラウザ及びスマートフォンのアプリからインターネットを介して K2 システムにアクセスし，契約情報の参照，被保険者情報の更新などを行えるようにする。

対策 1 は，業務アプリケーションのログから，業務時間外のアクセスと大量の契約情報へのアクセスを調べる。これは，業務アプリケーションを使う正規の利用者による持ち出しを見つける対策である。DB 暗号方式（表領域の暗号化）は，ディスクやバックアップなどに保管された契約情報を守る。しかし業務アプリケーションは，業務処理を行う際，契約情報を復号して扱うので，利用権限のある者が業務アプリケーションを使って取得した情報は，暗号化では守れない。K2 システムでは契約者もインターネットから業務アプリケーションを使えるようになる。解答例は“業務担当者及び契約者が業務アプリケーションを利用して持ち出すリスク”である。

監視の方法が“業務アプリケーションのログ”であることが，持ち出しの手段が業務アプリケーションの利用であることの手掛かりになる。DB サーバ上のデータを直接取得する者への対策なら，DB の暗号化がそれに当たる。

字数は 45 字以内で，解答例は 33 字である。“業務担当者及び契約者”と“業務アプリケーションを利用して持ち出す”の二つを残す。“内部者が持ち出す”だけでは，誰が，どの手段でが示されない。

採点講評（IPA）

設問4は，セキュリティ対策後の残留リスクに関する設問であるが，正答率が低かった。セキュリティ対策の設計において，対策後の残留リスクを正しく分析する能力を身につけてほしい。

本文の根拠

〔K2 システムにおけるリスク対策の補完〕

DB サーバ又は Web アプリケーションサーバのメモリダンプをファイルに出力した場合，次の作業に対して，作業者，作業日時及び作業内容を履歴として残す。

〔K1 システムの現在の運用〕(3)

オペレータとシステム管理者には，DBMS と Web アプリケーションサーバソフトウェアとを除くミドルウェア及び OS 上の全ての操作権限が付与されており，その他の権限は付与されていない。

製品 D の表領域暗号化機能の仕様 B

生成された乱数は，データの暗号化鍵・復号鍵（以下，DB データ鍵という）として，製品 D のメモリ上に保持される。

メモリダンプには，その時点のメモリの内容がそのまま入る。DB サーバでは，製品 D が DB データ鍵をメモリ上に保持し，ディスクから読み込んだデータを復号するので，メモリ上には平文のデータや鍵が現れる。Web アプリケーションサーバのメモリにも，業務アプリケーションが扱う平文の契約情報がある。オペレータとシステム管理者には OS 上の全ての操作権限があり，メモリダンプを OS から出力して，ファイルや外部記憶媒体に持ち出せる。DB の暗号化は，メモリ上の平文までは守らない。解答例は“オペレータ及びシステム管理者が，メモリダンプから平文の契約情報を読み出し，持ち出すリスク”である。

対策 2 が履歴を残す対象は，メモリダンプのファイルへの出力・アクセス，ダンプを保管した外部記憶媒体の利用，ファイルの消去で，ダンプの取得から持ち出しまでの流れと一致する。これらに作業者と日時を残すことで，持ち出しを抑止し，起きたときに追跡できる。

字数は 50 字以内で，解答例は 44 字である。“オペレータ及びシステム管理者”，“メモリダンプから平文の契約情報を読み出す”，“持ち出す”の三つを残す。設問(1) の答え（業務アプリケーションの利用）と混同しないように，メモリダンプという手段を書く。

採点講評（IPA）

設問4は，セキュリティ対策後の残留リスクに関する設問であるが，正答率が低かった。セキュリティ対策の設計において，対策後の残留リスクを正しく分析する能力を身につけてほしい。