A 社は，従業員数 500 名の小売業者である。A 社では，ネットワークの構築，運用を自社で行っている。ある朝，社内 LAN からインターネット上の Web ページを閲覧しているときの応答が遅いといった苦情が寄せられ，システム管理部門の J 主任と運用担当の K 君が調査を行うことになった。
〔原因調査と対処〕
J 主任と K 君は，Web ページの閲覧状況の確認から始めることにした。
K 君：ブラウザでインターネット上の Web ページを閲覧しようとすると，図 1 に示す状態が長く続き，表示までに時間が掛かります。
図 1 Web ページを閲覧しようとしたときのブラウザの状態
J 主任：なるほど，図 1 中の a を見ると，DMZ 上の DNS サーバに問題があるようです。当社の社内ネットワークの構成は図 2 のとおりです。設置してあるパケットモニタの，該当する時間帯のログを解析してみましょう。
図 2 A 社の社内ネットワークの構成
K 君：パケットモニタ Y には，DNS クエリとそれに対応する DNS クエリレスポンスが多量に記録されていました。しかし，パケットモニタ Z には，DNS クエリを伴わない DNS クエリレスポンスが多量に記録されていました。パケットモニタ Z のログを図 3 に示します。
図 3 パケットモニタ Z のログ（抜粋）
J 主任：このようなログは，社内 LAN 上の PC が DNS クエリを送信するときに自身の IP アドレスを b の IP アドレスに c した場合に記録されます。
K 君：不正な DNS クエリが多量に DMZ 上の DNS サーバに送りつけられたことで，Web ページを閲覧するときの応答が遅くなったのですね。確かに，すべての社内 PC からの名前解決を，DMZ 上の DNS サーバが担っていますから。
J 主任：こういった通信は d 攻撃と呼ばれています。至急，不正なパケットを棄却する設定をすべての部門のルータに適用してください。
K 君：はい，分かりました。
J 主任：こうした事象は，ウイルス感染によってよく引き起こされます。今回の事象以外にも，異常な通信が観測される可能性があります。社内 LAN に接続されているすべての部門のルータにパケットモニタを設置して，原因となっている社内 PC を特定してください。
K 君：ルータへの設定が終わり次第，パケットモニタによる調査を開始します。
J 主任：ところで，図 3 中の e と f の記録から，DMZ 上の DNS サーバが攻撃の踏み台に利用される危険性があることが分かります。①DNS サーバの不適切な設定も修正しておくべきですね。
K 君：はい，分かりました。
〔異常 PC の特定〕
K 君は社内 LAN に接続されたすべての部門のルータの配下にパケットモニタを設置して，異常な通信の監視を開始した。
図 4 社内 LAN からインターネットに向けたパケットログ（抜粋）
K 君：図 4 が α 部門に設置したパケットモニタのログです。
J 主任：②図 4 中の (Ⅵ) に示した箇所に，通常の社内 PC には見られない不審な通信挙動が記録されていますね。これは g におけるアドレス探索に見られる特徴です。また，図 4 中の (Ⅶ) に示した箇所にも，不審な通信挙動が記録されていますね。(Ⅶ) に示す通信によって，③通信の異常な偏りが発生します。
K 君：なるほど，a1.a2.a3.a4 に該当する社内 PC が，原因となっている PC ですね。
J 主任：こうした視点で，ほかの部門に設置したパケットモニタのログも確認してみましょう。
〔異常 PC の対処と今後の対策〕
J 主任と K 君は，全部門のパケットモニタのログを調べた結果，IP アドレスが a1.a2.a3.a4 のログだけに異常が見られたことから，この IP アドレスの PC への対処を開始した。この対処として，通信プロセス名，実行ファイル名，通信のあて先の IP アドレスとポート番号を記録する通信プロセスモニタを，該当する PC に設定して監視を行った。
K 君：該当する PC に設定した通信プロセスモニタのログから，起動していた④不審な通信プロセスを特定でき，それがウイルスであることが分かったので，その実行ファイルを削除しておきました。この PC ではウイルス対策ソフトが起動しており，そのパターンファイルの自動更新も設定されていました。検知できないウイルスもあるのですね。
図 3 は，DMZ 上の DNS サーバ（p1.p2.p3.p4）がインターネット上の r1.r2.r3.r4 へ返した DNS クエリレスポンスの記録で，対応するクエリは記録されていない。J 主任の説明は“社内 LAN 上の PC が DNS クエリを送信するときに自身の IP アドレスを b の IP アドレスに c した場合”に記録される，というものである。クエリの送信元アドレスが偽られていれば，DNS サーバは応答をその偽のアドレスあてに返す。応答のあて先がインターネット上の r1.r2.r3.r4 なので，PC は自身の IP アドレスをインターネット上のアドレスに偽った，と読める。したがって b はウ（インターネット上），c は詐称である。
アの DMZ 上の DNS サーバは図 3 では応答の送信元側（p1.p2.p3.p4），イの DMZ 上の Web サーバのアドレス（q1.q2.q3.q4）は応答の中身に出てくるもので，どちらもクエリレスポンスのあて先ではない。
c は 5 字以内で，解答例は“詐称”の 2 字。自分のアドレスを別のアドレスに見せかける行為を表す短い語で答える。
設問1(3)解答欄1つ
本文中の d に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア DNS cache poisoning イ DNS reflection ウ 総当たり エ ファーミング
〔d〕解答例
イ
解説
本文の根拠
K 君の発言
パケットモニタ Z には，DNS クエリを伴わない DNS クエリレスポンスが多量に記録されていました。
J 主任の発言
こういった通信は d 攻撃と呼ばれています。
送信元を偽った DNS クエリを DNS サーバに送ると，その応答は偽られたあて先（被害者）へ返される。クエリを送った側は応答を受け取らず，被害者のもとにクエリを伴わない応答が届く。このように DNS サーバを踏み台にして第三者へ応答を送りつけさせる攻撃が DNS reflection（イ）である。CISA の資料にも，UDP は送信元アドレスを検証しないので，攻撃者が要求の送信元を被害者のアドレスに偽ると，応答が被害者へ送られる，と説明されている。
アの DNS cache poisoning は DNS サーバが覚える情報（キャッシュ）に偽の情報を入れる攻撃，ウの総当たりはパスワードなどを順に試す攻撃，エのファーミングは利用者を偽のサイトへ誘導する攻撃で，どれも“クエリを伴わない応答が被害者に届く”という図 3 の状況とは異なる。
図 3 中の e と f の記録から，DMZ 上の DNS サーバが攻撃の踏み台に利用される危険性があることが分かります。
図 3
番号 5（0.007 秒）と 6（0.008 秒）の詳細は Query response, A s1.s2.s3.s4。
図 3 の注
r1.r2.r3.r4 と s1.s2.s3.s4 はインターネット上の IP アドレス。
e は，攻撃の被害者を示す箇所である。応答のあて先は，すべての行で r1.r2.r3.r4 なので (Ⅱ) になる。f は，DNS サーバが踏み台に利用される危険性を示す箇所である。(Ⅲ) は“No such name”，(Ⅳ) は A 社の Web サーバ（q1.q2.q3.q4）のアドレスの応答で，A 社が管理するドメインの名前に関する応答と読める。これに対し (Ⅴ) の応答は，インターネット上のアドレス s1.s2.s3.s4 を返している。A 社以外のドメインの名前の問合せにも応答していることを示すので，踏み台に使われる危険性を表す記録は (Ⅴ) である。
下線①の修正は，この危険性をなくす設定である。講評は，企業の DNS サーバが本来応答する必要のない外部ホストからの外部アドレスの問合せを許していると DNS Reflection 攻撃の踏み台に悪用されるおそれがある，とし，“修正”の解答には問合せ元と問合せ対象の両者を含めてほしかったとしている。解答例は“インターネットからのA社以外のドメイン上のアドレスに関するDNSクエリを拒否する。”である。
通信プロセス名，実行ファイル名，通信のあて先の IP アドレスとポート番号を記録する通信プロセスモニタを，該当する PC に設定して監視を行った。
K 君の発言
起動していた④不審な通信プロセスを特定でき
通信プロセスモニタが記録するのは，通信プロセス名，実行ファイル名，通信のあて先の IP アドレスとポート番号である。この中から“不審な通信プロセス”を見つけるには，プロセスが通信しているあて先ホスト，又はあて先ポートに注目すればよい。OS やアプリケーションは，ふだんは決まったホストの決まったポートとしか通信しない。そこで，本来通信しないあて先ホストと通信するプロセス，又は本来通信しないあて先ポートを利用するプロセスが不審な通信プロセスになる。解答例はこの二つで，どちらでもよい。
記録項目のうち，プロセス名や実行ファイル名は名前が分かるだけなので，通信の相手に関する項目（あて先の IP アドレスとポート番号）を手掛かりにする。
P 君：現在，開発元から Web サーバプログラムの修正プログラムが提供されていないので暫定的対策となりますが，POST メソッドでのアクセスを拒否する方法が考えられます。
S 君：Web 販売システムで POST メソッドでのアクセスを拒否すると，HTML 文書の a 要素内に利用者が入力したデータを受け付けることができず，製品の販売ができなくなってしまいます。HTML 文書を修正して，POST メソッドを GET メソッドに置き換えた上で POST メソッドでのアクセスを拒否するという対策であれば，製品販売も続けられます。
任意の OS コマンドを実行させることが可能である。その際，OS コマンドは Web サーバプログラムの動作権限で実行される。
図 2 (f)
(f) Web サーバプログラムは，システム管理者権限で動作している。
図 4
(1) 機密性の高い情報が漏えいする。(2) システムの機能が全面的に停止する。
P 君は，損害金額の算出が難しい場合の基準（*2）で判定している。この基準で“緊急”になるのは，機密性の高い情報の漏えい，又はシステムの機能の全面的な停止が起こる場合である。図 3 の脆弱性では，任意の OS コマンドが Web サーバプログラムの動作権限で実行され，図 2 の (f) のとおりその権限はシステム管理者権限である。したがって，攻撃者が指定したコマンドが実行されると，システムが全面的に停止するおそれがある。また，管理者権限が奪われれば，図 2 の (e) の DB サーバ内の個人情報（機密性の高い情報）が漏えいする可能性がある。解答例は，この二つのどちらかである。
HTML 文書を修正して，POST メソッドを GET メソッドに置き換えた上で POST メソッドでのアクセスを拒否するという対策であれば，製品販売も続けられます。
POST メソッドでのアクセスを拒否すると，利用者が入力したデータを受け付けられなくなるのは，HTML 文書でデータを送信する部分である。HTML では，送信方法（GET か POST か）を form 要素の method 属性で指定し，利用者の入力欄は主に input 要素で表す。そのため，a には form 又は input が入る。解答例も“form”と“input”のどちらでもよい。
“POST メソッドを GET メソッドに置き換える”という S 君の案は，form 要素の method 属性を変えることに当たる。a が入るのは，その送信を受け付ける要素の名前である。
C 社は，一般消費者向けにファックスや電話による，生活用品の通信販売を行っている，従業員数 50 名の会社である。C 社の企画開発課は申込方法の多様化を目的として，インターネットで申込みを受けるための X システム（図 1）を開発してきた。X システムでは，Web アプリケーション（以下，Web アプリという）のログイン画面で，利用者 ID とパスワードによって利用者認証を行う。C 社の開発ポリシには，サービス開始前に第三者によるセキュリティ検査を実施することが規定されている。そこで，企画開発課の F 課長は，部下の G 君に指示して Web アプリを対象とした疑似侵入テストと，データベース（以下，DB という）サーバを対象とした脆弱性診断を，セキュリティ専門会社の D 社に依頼した。
図 1 X システムの構成
〔Web アプリのセキュリティに関する問題点〕
D 社の H 氏から疑似侵入テストと脆弱性診断の結果が報告された。次は，疑似侵入テストで見つかった脆弱性に関する会話の一部である。
H 氏：まず，各ログインセッションを識別するセッション識別子は，ログイン日と会員番号を組み合わせた文字列として構成され，図 2 のように cookie にセットされますね。このままでは，悪意をもつ者に他人のセッション識別子を推定され，①容易になりすましアクセスができてしまいます。影響と対策については報告書に記述しましたので参照してください。
G 君：分かりました。セッション識別子の生成部分を修正します。
図 2 cookie にセットされたセッション識別子の例
H 氏：次は，クロスサイトスクリプティング（以下，XSS という）についてです。Web アプリでは，XSS の脆弱性が多数見つかりました。
G 君：XSS 対策については，図 3 のプログラムのように，利用者からの入力データに<script や<iframe などの文字列が含まれていた場合は，入力チェックで，処理を中止するようにしていました。
H 氏：入力チェックだけで完全な XSS 対策を行うのは困難です。まず HTML 出力の際に“<”，“>”，“"”，“'”，“&”をそれぞれ“<”，“>”，“"”，“'”，“&”に置換することが基本です。その上で，プログラムが HTML タグの②ある特定の属性に値を出力する場合は，個別の対処が必要です。
G 君：（報告書を見ながら）なるほど，そのように対応します。
図 3 プログラム（抜粋）
H 氏：次に，図 3 のプログラムは HTTPS でアクセスする画面を出力するものですが，その画面を御社で推奨されているブラウザで見たときに，③HTTPS での正常なアクセスを意味する鍵マークが表示されなくなっています。
H 氏：DB サーバには，利用者の個人情報が平文で格納される仕様になっています。万が一，不正アクセスによって個人情報が流出した場合に備えて，Web アプリで個人情報を暗号化して格納することをお勧めします。
G 君：実は，DBMS 側で自動的に暗号化／復号する透過的データ暗号化機能（以下，透過的暗号化という）を利用する予定です。
H 氏：残念ながら④透過的暗号化の効果は限定的です。
H 氏は透過的暗号化について説明した。
F 課長：防止できる脅威を考えると，Web アプリによる暗号化を採用すべきだな。個人情報の登録と参照をしている箇所を洗い出して，実装してくれ。
G 君：承知しました。ざっと見積もって 1 週間以上は掛かると予想されます。
F 課長：仕方ない。よろしく頼む。
H 氏：今後システム開発をするときにはもっと早い段階で暗号化について検討し，実装すべきですね。次に，X システムのログイン認証用のパスワード情報について確認します。DB に格納されているパスワード情報はハッシュ値のように見えますが，どのような方法で算出しているのですか。
G 君：パスワードを MD5 関数の引数にして算出しています。
H 氏：パスワードだけからハッシュ値を算出すると，悪意ある第三者にハッシュ値が知られた場合，検索エンジンや専用ツールを使って，元の値であるパスワードを突き止められてしまう可能性があります。
F 課長：パスワードを突き止められることで，X システムに不正ログインされる可能性があるのは理解できますが，ほかに何か問題があるのですか。
H 氏：利用者の多くは，ほかのサイトでも同じパスワードを使用しているようです。攻撃者は不正に入手した利用者 ID，パスワードを使ってほかのサイトに不正ログインを試みるでしょう。したがって，万が一，情報流出した際には，御社に対する非難の声が大きくなりかねませんし，利用者にほかのサイトのパスワードを変更する負担を強いることにもなります。そういう最悪の事態にならないようにするためにも，⑤より工夫してパスワードのハッシュ値を算出した方がよいでしょう。
E 社は，従業員数 2,000 名の上場している運輸会社である。E 社の情報システム部では 80 台のサーバを管理しており，複数種の OS と，複数の DBMS 及びアプリケーション（以下，AP という）が稼働している。
インストールされたそれぞれの OS，DBMS，AP に対して，システム管理特権が付与された利用者 ID（以下，特権 ID という）が一つずつ登録されており，情報システム部内のシステム管理チームに所属するシステム管理者 10 名がすべての特権 ID とパスワードを共用している。例えば，OS，DBMS，AP がそれぞれ一つずつ稼働しているサーバでは，OS に一つ，DBMS に一つ，AP に一つの特権 ID が登録されており，システム管理者 10 名がこれらの特権 ID を共用している。特権 ID の使用は，基本的にはネットワーク経由で行われているが，コンソールからでないと行えない特定の作業については，サーバが保管されているラック内に設置されたコンソールから行われている。
E 社は，システム運用の安全性を確認するために，セキュリティ専門会社の F 社に，サーバの設定や運用に関するセキュリティ診断を依頼した。診断の結果，情報システムの特権 ID 管理が十分でないとの指摘を受けたことから，経営陣は情報システム部に対して特権 ID の管理を改善するように指示した。
〔特権 ID 管理の要件〕
F 社による指摘は，“特権 ID の使用において，内部者の不正使用を防止及び発見する仕組みが構築されていない”というものであった。システム管理チームの N 課長と M 君は，この指摘に基づき，必要な管理要件を明確にすることにした。
N 課長：M 君，現状の特権 ID 管理において必要な管理要件とは具体的に何だろう。
M 君：現在の当社のシステムでは，特権 ID を使用したときのログがほとんど取得されていないので，不正使用があったとしても発見できないおそれがあります。ログインやログアウトなどの基本的なイベントと，システムの設定変更や利用者 ID 登録などの重要な操作については，ログを取得する必要があると思います。当社の全システムが，特権 ID に関するこれらのログを取得する機能をもっていることは確認できています。
N 課長：なるほど。それらのログを取得することにしよう。
M 君：ただし，今の状態では，ログを取得したとしても a をやめないと，ログからはだれが不正使用を行ったのかを特定できないので意味がありません。
N 課長：なるほど。それは①上場企業に求められる内部統制の観点からも改善が必要だな。近々内部統制を評価するための内部監査が行われることになっているが，今回の診断はその準備にもなっている。早速すべての OS，DBMS，AP で改善してくれ。
M 君：分かりました。すぐに改善することにします。
N 課長：F 社からは，内部不正を発見する仕組みも必要と言われているが，これはどう考えるかね。
M 君：はい。特権 ID の使用が業務目的であることを確認するために，使用目的，使用者，使用する特権 ID を記入した特権 ID 利用申請書を使用日ごとに課長に提出し，事前に承認していただくという運用にします。その上で，月に 1 回程度 b を実施して不正な使用がなかったことを確認します。この b が，内部不正を発見する仕組みに当たります。
N 課長：よし，ではそれで試験的に運用してみよう。
新たな特権 ID 管理の仕組みが試験的に運用され，1 か月が経過した。
〔特権 ID 管理の運用〕
N 課長：先月の b の結果はどうだったかね。
M 君：ある DBMS に利用申請のない特権 ID の使用がありました。OS，DBMS，AP の特権 ID を必要に応じて追加作成し，一つの特権 ID は 1 人のシステム管理者だけが使用する環境を実現できましたので，だれが使ったのかすぐ分かりました。その特権 ID を使った者に確認したところ，状況監視のために毎日使用していました。しかし，一般権限でも問題ないということでしたので，②データの参照だけを行うことができる，状況監視用の利用者 ID を作成し，それを使用させることにしました。また，あるサーバの OS では，特権 ID の利用申請があったのに，ログが残っていないものがありました。チーム全員に確認してみたところ，ある従業員が誤ってシステムのリストアの際にログファイルを上書きしてしまったということでした。
N 課長：ログがちゃんと保存されないのは問題だな。
M 君：そう思います。追記型記憶装置を使えばログが消えてしまうことを防止できるのですが，すべてのサーバに導入するとコストが掛かりすぎます。実は UNIX でログを収集，転送する方式として一般的に使われている c を使ったログサーバについて調査していました。これを導入して，ログサーバで追記型記憶装置を使用し，OS，DBMS，AP のログを保存するというのはどうでしょう。
N 課長：なるほど。しかし，今年度の予算では，ログサーバを購入できたとしても，追記型記憶装置までは購入できないな。そこまでしなくても，もっと簡単な方法でログサーバのログは保護できるのではないだろうか。例えば，d することにすれば，ログサーバの中にログが保存された状態であっても，ほかのサーバ管理者による故意のログ削除を防止できるし，誤操作によるログ喪失の可能性も低下させることができるだろう。
M 君：そうですね。そうすれば大丈夫だと思います。
N 課長：では，ログサーバだけを導入することにしよう。ログは，当社の情報セキュリティ規程に従って，2 年間保存するようにしておいてくれ。しかし，問題の発見に最悪で 1 か月も掛かるというのは遅すぎるな。ほかに方法はないのかね。
M 君：例えば，不正の可能性が考えられる特権 ID の使用が発見されたときにだけアラートを発生させ，それを電子メール（以下，メールという）で通知する仕組みをログサーバに導入すれば，もっと早期に発見することができると思います。例えば，サーバへのログイン回数が多かった場合にアラートを発生させればよいかもしれません。
N 課長：しかし，サーバへのログイン回数が多かったからといって不正使用というわけではないだろう。
M 君：はい，そのとおりです。アラートが発生したからといって特権 ID の不正使用があったとは断言できないので，特権 ID 利用申請書などを基に確認を行う必要がある，という意味です。
N 課長：なるほど。では，どのようなアラートの発生条件を設定するか，案を作ってくれ。
M 君：分かりました。
数日後，M 君から特権 ID の使用に関するアラートの発生条件案（表）が提出された。
表 特権 ID の使用に関するアラートの発生条件案
N 課長：これらの条件だけでは，本人に割り当てられている特権 ID を使用したときにしか検出できないな。③特権 ID をもっていない人が特権 ID を使用しようとする行為があったときにも検出できるようにしてくれないか。それから，アラートを通知するメールは管理職の私が受け取って確認しよう。ところで，④アラートを設定していることはシステム管理者に周知してほしいが，⑤具体的なアラートの発生条件は伝えないようにしておいてもらえるかね。
M 君：分かりました。アラートを通知するメールへの対応はよろしくお願いします。
M 君の案に基づき，アラートを発生させる仕組みが導入され，1 週間が経過した。
N 課長：M 君，アラートを通知するメールが多くて確認が大変だよ。特に，表の項番 6 の条件のときに発生させるアラートの通知メールが必ず毎日届くんだ。
M 君：すみません。どうも最近，DBMS に対して特権 ID を使用して SQL 文を実行する運用作業が増えたことが原因のようです。アラートの数を減らす方法として，SQL 文の中身を解釈し，その内容に応じてアラートを発生させることができるツールを使うことも考えているのですが，まだ調査中で導入にはしばらく時間が掛かりそうです。
N 課長：これではほかの仕事ができないな。この条件はそのツールを導入するまでいったん外してくれないか。
M 君：分かりました。当面，特権 ID を使用した SQL 文の実行に関するログの取得はやめましょう。
N 課長：M 君，それは駄目だよ。⑥データベース（以下，DB という）では当社の財務にかかわる重要なデータが管理されているから，財務報告の信頼性を担保するためにも，特権 ID を使用して DB を操作したログを取得して保存することは重要なんだ。
M 君：なるほど，分かりました。アラートの発生条件からは外しますが，ログは取得するようにしておきます。
N 課長：よし，ではこの状態でしばらく運用することにしよう。
その後，SQL 文の中身を解釈してアラートを発生させるツールが導入され，再度の試験運用が行われた。その 1 か月後，アラート発生の設定が適切であることが確認され，本格運用が開始された。これによって，E 社システムの特権 ID 管理が改善され，より安全なシステム運用が実現された。
E 社は上場している会社で，N 課長は内部統制の観点からの改善を求めている。上場企業を対象に，財務報告に関する内部統制の評価と報告を求める法律は金融商品取引法（イ）である。この問題の出題趣旨も，上場企業においては金融商品取引法の改正（いわゆる日本版 SOX 法）に基づいて内部統制を評価・報告することが求められている，と述べている。
ログを取得したとしても a をやめないと，ログからはだれが不正使用を行ったのかを特定できないので意味がありません。
E 社では，システム管理者 10 名がすべての特権 ID とパスワードを共用している。共用していると，ログに特権 ID が記録されても，その 10 名のうちのだれが使ったのかが分からない。ログからだれが不正使用を行ったのかを特定するには，特権 ID を共用するのをやめ，1 人に 1 つの特権 ID を割り当てる必要がある。a は“特権IDの共用”である。
〔特権 ID 管理の運用〕で，M 君が“一つの特権 ID は 1 人のシステム管理者だけが使用する環境を実現できましたので，だれが使ったのかすぐ分かりました”と述べているのは，この改善の結果である。
10 字以内に対し解答例は 7 字。“特権IDの共用”と，何をやめるのかを名詞で答える。
設問1(3)解答欄1つ
本文中の b に入れる適切な字句を，10 字以内で答えよ。
〔b〕解答例
ログのレビュー
解説
本文の根拠
M 君の発言
月に 1 回程度 b を実施して不正な使用がなかったことを確認します。
M 君の発言
ある DBMS に利用申請のない特権 ID の使用がありました。
M 君は，特権 ID の使用が業務目的であることを確認するため，使用目的，使用者，使用する特権 ID を書いた特権 ID 利用申請書を課長が事前に承認する運用にしている。月に 1 回程度，b を実施して不正な使用がなかったことを確認し，これが内部不正を発見する仕組みに当たる。確認の材料は，取得した特権 ID のログと利用申請書であり，ログを調べて申請と照らし合わせる作業は“ログのレビュー”である。〔特権 ID 管理の運用〕では，この b の結果として“利用申請のない特権 ID の使用”が見つかっている。
追記型記憶装置を使わずにログサーバのログを守る方法として，N 課長は，ほかのサーバ管理者による故意の削除と，誤操作による喪失の両方を防ぐ対策を考えている。ログサーバの特権 ID を使える人を，ほかのサーバの特権 ID の使用者と分ければ，ほかのサーバの管理者はログサーバのログを削除できない。ログサーバを触る人が限られるので，誤操作による喪失の可能性も下がる。解答例は“ログサーバの特権ID使用者とほかのサーバの特権ID使用者を分離”である。
講評は，ログサーバ内のログに対してアクセス権を設定することだけを記述した解答が多かったとし，特権 ID は強力な権限をもつ ID なので，管理を改善する際には，システム設定などの技術的側面だけでなく，使用者の範囲や使用手続などの運用に関する部分も含めて検討する必要があるとしている。この設問は正答率が低かった。
40 字以内に対し解答例は 31 字。“ログサーバの特権 ID の使用者”と“ほかのサーバの特権 ID の使用者”を分けることを，使用者の範囲の面から書く。
特権 ID をもっていない人が特権 ID を使用しようとする行為があったときにも検出できるようにしてくれないか
表
項番 1：一つのサーバにおいて，過去 1 か月間ログインしたことがない特権 ID によるログインが行われたとき（普段使わない特権 ID の使用）。
表の項番 1〜6 は，ログインや操作が行われた場面で発生させる条件で，本人に割り当てられた特権 ID を使った場合にしか検出できない。特権 ID をもっていない人が使おうとしても，パスワードが分からなければ認証に失敗する。したがって，特権 ID の認証が失敗したときをアラートの発生条件に加えれば，このような行為を検出できる。解答例は“特権IDの認証が失敗したとき”である。
本文中の下線⑥において，財務報告の信頼性を担保するために，特権 ID に関する DB のログの個々の記録について何を確認し，全体として何を立証しようとしているか。特権 ID に関する DB のログの個々の記録に対して確認する内容を 50 字以内で，立証しようとしていることを 35 字以内で述べよ。
〔確認する内容〕解答例
特権IDでDBのデータを変更した処理のログに対応する特権ID利用申請書が提出されていること
DBのデータを変更した処理が，すべて業務目的に基づいていること
〔立証しようとしていること〕解答例
DBMS内の財務データが特権IDによって改ざんされていないこと
DBMS内の財務データの完全性
解説
本文の根拠
N 課長の発言
⑥データベース（以下，DB という）では当社の財務にかかわる重要なデータが管理されているから，財務報告の信頼性を担保するためにも，特権 ID を使用して DB を操作したログを取得して保存することは重要なんだ
M 君の発言
特権 ID の使用が業務目的であることを確認するために，使用目的，使用者，使用する特権 ID を記入した特権 ID 利用申請書を使用日ごとに課長に提出し，事前に承認していただくという運用にします。
ログの個々の記録については，特権 ID を使って DB のデータを変更した処理が，利用申請に基づいていること（特権 ID の利用申請書が提出されていること，すべて業務目的に基づいていること）を確認する。解答例は“特権IDでDBのデータを変更した処理のログに対応する特権ID利用申請書が提出されていること”と“DBのデータを変更した処理が，すべて業務目的に基づいていること”で，どちらでもよい。
この確認を全体として積み重ねて立証しようとしているのは，DBMS 内の財務データが特権 ID によって改ざんされていないこと，すなわち DBMS 内の財務データの完全性である。出題趣旨も，システムの完全性を担保する要素の一つとして特権 ID の管理を挙げている。
