平成21年度 春期 午前Ⅱ

解説

DNS キャッシュポイズニングは，DNS サーバ（キャッシュサーバ）に偽の応答を送り込んでキャッシュさせ，その DNS サーバを参照する PC に誤った IP アドレスを返させる攻撃である。利用者が正しいドメイン名を入力しても，攻撃者が用意した偽の Web サーバに誘導されてしまう。イが該当する。

アのソフトウェアのバージョン情報から脆弱性を特定するのは，攻撃の前段階の調査（偵察）である。ウの DNS サーバを踏み台にして大量の問合せを発生させ，攻撃対象に応答を集中させるのは DNS リフレクション攻撃（DNS amp）である。エのゾーン情報をまとめて転送させるのは，ゾーン転送を悪用した情報収集であり，いずれもキャッシュに偽の情報を注入するものではない。

解説

SSL-VPN 装置は，利用者の PC との間で SSL による暗号化通信を行うサーバの役割を果たすので，Web サーバと同様に，サーバ証明書（ディジタル証明書）を組み込む必要がある。証明書には装置ごとの FQDN 又は IP アドレスを記載するので，1 台 1 台を識別できるように組み込むことになる。アが正しい。

イの装置メーカが用意した機種固有の証明書や，ウの装置メーカから提供される認証局を使う必要はなく，一般の認証局などから発行された証明書を使える。エの複数拠点の装置で同一の証明書を使う必要はなく，装置ごとに FQDN に対応した証明書を用いるのが一般的である。

解説

リバースプロキシ型のシングルサインオンでは全ての通信がリバースプロキシを経由するので，そこで利用者認証を行う。認証方式はパスワードに限られず，クライアント証明書（デジタル証明書）を用いることもできる。

アは誤り。cookie を生成するのはクライアントではなく認証を行うサーバ側。イは誤り。cookie は発行元ドメインにしか送られないので，cookie 方式では同一ドメインに配置する必要がある。ウは誤り。リバースプロキシ方式ではドメインを分ける必要はない。

解説

OP25B（Outbound Port 25 Blocking）は，ISP が，管理下にある動的 IP アドレスの利用者から，ISP のメールサーバを経由せずに外部のメールサーバの TCP ポート 25 番へ直接送られる通信を遮断する対策である。ボットに感染した PC などが外部へ直接スパムメールを送ることを防ぐ。イが該当する。

アは外部から受信するメールをシグネチャで判定して遮断する受信側の対策，ウは送信元のメールサーバの DNS 逆引きによる受信側の対策，エは第三者中継を許すメールサーバからの受信を拒否する対策であり，いずれも外向き（Outbound）の通信を遮断する OP25B ではない。

解説

ディジタル署名では，送信者が自分の署名鍵（秘密鍵）でメッセージのハッシュ値などから署名を作成してメッセージに付け，受信者は送信者の検証鍵（公開鍵）で署名を検証する。署名鍵をもつのは送信者だけなので，検証に成功すれば送信者を確認でき，メッセージが改ざんされていないことも確かめられる。ウが適切である。

アの受信者が暗号文を元に戻すのは暗号化通信での復号であり，署名鍵は送信者だけがもつ鍵で受信者は使わない。イのディジタル署名で分かるのは改ざんの有無で，改ざんされた部位までは特定できない。エのメッセージの内容を関係者以外に分からないようにするのは暗号化による機密性の確保で，ディジタル署名の目的ではない。

解説

SHA-1 は，任意の長さのデータから 160 ビットの固定長のハッシュ値を求めるハッシュ関数である。データが 1 ビットでも変わればハッシュ値が大きく変わるので，送信前と受信後のハッシュ値を比べることで改ざんを検出できる。アが該当する。

イの IPsec でデータの暗号化に使うのは AES や 3DES などの共通鍵暗号のアルゴリズムで，SHA-1 は暗号化を行わない。ウの公開鍵暗号方式の鍵を生成するのは RSA などの鍵生成の手順であり，ハッシュ関数の役割ではない。エの暗号化が正常に完了したことを確認する，という用途のアルゴリズムはない。

解説

リスクへの対策は，損失の発生そのものを防いだり小さくしたりするリスクコントロールと，損失が発生したときに備えて資金面の手当てをしておくリスクファイナンスに分けられる。保険をかけておけば，被害が出たときの損失を保険金で補えるので，アがリスクファイナンスに当たる。

イのリスクの発生を抑える対策と，エの顕在化したときの被害を小さくする対策は，どちらも損失そのものに働きかけるリスクコントロールである。ウは，被害が出た後で復旧費用を借り入れただけで，損失に備えてあらかじめ資金を手当てしておく対策にはなっていない。

解説

リスク分析は，情報資産にどのような脅威と脆弱性があり，リスクがどこにどのように潜在しているかを洗い出して識別し，それが顕在化した場合の影響の大きさや発生の可能性を測定する作業である。ウが適切である。

アの情報セキュリティで対象とするのは，損失だけをもたらす純粋リスクであり，損失にも利益にもなり得る投機的リスクではない。イの予想損失額は，リスクが顕在化したときの復旧費用や代替手段の費用などの損失の額であり，損害を予防するために投入するコストは対策の費用であって損失額には含めない。エのリスク評価額は，1 回当たりの予想損失額に発生頻度を掛けた年間の予想損失額などで表し，1 回当たりの額だけでは表さない。

解説

インターネットから DMZ の Web サーバを乗っ取られた場合でも，DB サーバへの不正侵入を防ぐには，ファイアウォールで，DMZ から内部ネットワークへは必要な通信だけを通す。DB サーバが待ち受ける受信ポート番号を固定し，送信元を Web サーバ，あて先を DB サーバの受信ポート番号に限定して通せば，それ以外の通信を遮断できる。アが最も有効である。

イの DMZ から DB サーバへの通信全てを通すと，DNS サーバなどからも任意のポートにアクセスでき，制限が緩い。ウの同じ発信ポート番号を使った通信の拒否は，不正侵入の防止にはならない。エの Web サーバの発信ポート番号を固定して通すと，その番号を使えば DB サーバのどのポートにもアクセスできてしまう。

解説

IPsec のトランスポートモードは，送信ホストと受信ホストがそれぞれ IPsec を処理し，IP パケットのデータ部分を暗号化して送る。暗号化されたまま送信ホストから受信ホストまで届くので，途中のゲートウェイ間だけでなく全経路でメッセージが暗号化される。アが適切である。ゲートウェイどうしの区間だけを暗号化するのはトンネルモードの典型的な使い方である。

イの LDAP も，LDAPS や StartTLS によって通信を暗号化できる。ウの S/MIME はメールそのものを受信者の公開鍵で暗号化するので，メールサーバに格納されている間も暗号化されたままで，管理者が平文で見ることはできない。エの SSL で受け取った HTML 文書も，ブラウザやサーバの設定でキャッシュに残さないようにできる。

解説

SMTP サーバが自組織と無関係な送信元から無関係な宛先へのメールを中継してしまう状態（オープンリレー）だと，迷惑メールの踏み台にされる。これを防ぐには第三者中継を禁止し，自組織に関係する送信元・宛先だけを中継するように設定する。

アの DNS サーバのゾーン転送の制限，ウの Web サーバのディレクトリリスティングの禁止，エの Web サーバでの CGI 実行場所の制限は，いずれも別のサーバに対する設定である。

解説

ルートキット（rootkit）は，攻撃者が不正侵入したコンピュータで，バックドアや不正なプログラムの存在，ログの痕跡などを隠蔽し，管理者に気付かれずに管理者権限で活動し続けるための機能をまとめたツールである。エが正しい。

アのカーネル部分の脆弱性を分析するツールや，イのウイルスやワームに感染していないかをチェックするツール，ウの通信ポートを外部から調査するツール（ポートスキャナ）は，いずれもルートキットの説明ではない。

解説

ICMP（Internet Control Message Protocol）は，IP パケットを届けられなかったときなどに，ルータや受信ホストから送信元ホストへ，エラーの報告や制御のメッセージを通知するプロトコルである。ping で使うエコー要求・エコー応答も ICMP のメッセージである。ウが適切である。

アの MAC アドレスから IP アドレスを求めるのは RARP である。イのグローバル IP アドレスとプライベート IP アドレスを相互に変換するのは NAT（NAPT）である。エの IP アドレスを一元管理してクライアントに動的に割り当てるのは DHCP である。

解説

TCP のコネクションは，あて先 IP アドレス，あて先ポート番号，送信元 IP アドレス，送信元ポート番号の四つの組で識別する。例えば，同じ Web サーバのポート 80 番に複数のクライアントが接続していても，送信元の IP アドレスとポート番号が違うので別のコネクションとして区別できる。イが適切である。

アのあて先だけでは，同じサーバの同じポートに接続する複数のクライアントを区別できない。ウの IP アドレスだけでは，同じホストどうしで同時に張られた複数のコネクションを区別できない。エの MAC アドレスは，ルータを越えるたびに書き換わる区間ごとの情報なので，コネクションの識別には使わない。

解説

TCP ヘッダのウィンドウサイズは，受信側がこれ以上受け取れるデータ量（受信バッファの空き）を送信側に通知する値である。送信側は，確認応答を待たずにウィンドウサイズの分まで続けてセグメントを送信でき，それを超える場合は確認応答を待つ。イが適切である。

アのような，再送に備えて送信側が保持しているデータ量を知らせるフィールドは TCP ヘッダにない。ウの接続開始時のハンドシェイクで通知するのは MSS（最大セグメント長）などのオプションで，ウィンドウサイズは通信中に受信側の状況に応じて随時変わる。エのような後続セグメント数を示すフィールドもなく，データの並びはシーケンス番号で管理する。

解説

SQL の GRANT 文は，表やビューに対する SELECT，INSERT，UPDATE，DELETE などの権限を，指定した利用者に与える文である。特定の利用者だけに表へのアクセス権を与えるには GRANT 文を使う。エが適切である。与えた権限を取り消すには REVOKE 文を使う。

アの CONNECT 文は，データベースへの接続（セッション）を確立するための文で，表ごとのアクセス権を与えるものではない。イの CREATE ASSERTION 文は，複数の表にまたがる整合性の制約（表明）を定義する文である。ウの参照制約は，外部キーの値が参照先の表に存在することを保証する参照整合性の制約であり，いずれも利用者ごとのアクセス権とは関係がない。

解説

排他制御は，複数のトランザクションが同じデータを同時に更新しようとしたときに，ロックなどで一方を待たせることで，更新が失われたり矛盾した値が読まれたりすることを防ぐ機能である。同時実行処理でのデータの整合性を保つことができるので，アが適切である。

イのデッドロックは，ロックを掛け合ったトランザクションどうしが互いの解放を待ち続ける状態で，排他制御を使うことによって起こり得るものであり，排他制御で防止できるわけではない。ウのロックは DBMS が自動で掛けるほか，アプリケーションプログラムから LOCK TABLE 文などで明示的に指示することもできる。エのバッチ処理も，オンライン処理や他のバッチ処理と同時に同じデータを更新することがあれば排他制御が必要になる。

解説

共通フレームの考え方では，設計の各段階で定義した事項が正しく実現されているかを，対応するテストで確認する（V字モデル）。システム方式設計で定義したシステムの構成や要件はシステム結合テストで，ソフトウェア方式設計で定義したソフトウェアの構造やコンポーネント間のインタフェースはソフトウェア結合テストで，ソフトウェア詳細設計で定義したユニットの仕様はソフトウェアユニットテストで確認する。ウが適切である。

ア，イの運用テストは，利用者が実際の運用環境で業務に使えるかを確認するテストで，システム要件定義や運用の要件に対応する。エはソフトウェア方式設計と詳細設計に対応するテストが入れ替わっている。

解説

臨時保守は，障害が発生したときに行う保守である。運用管理者は，作業前に保守作業者が障害の発生状況を正しく把握したことを確認し，作業後には障害の原因と作業の実施結果を確認して，復旧したことや再発防止策を確かめる。エが適切である。

アのシステムが自動的に回復した障害も，原因や対応処置の報告を受けて再発のおそれがないかを確認する必要があり，ログの分析結果だけで済ませるのは不十分である。イの定期保守でも，作業内容や影響範囲の事前確認と，作業後にシステムが正常に稼働していることの事後確認は省略できない。ウの遠隔保守も遠隔地のシステムに手を加える作業なので影響が出るおそれがあり，事前確認を省くのは誤りである。

解説

スパイラルモデルは，システムをいくつかの部分に分け，計画，リスク分析，開発，評価のサイクルを繰り返しながら，らせんを描くように少しずつ機能を追加し，システムの完成度を高めていくプロセスモデルである。ウが該当する。

アの RAD は，少人数の開発チームが開発支援ツールなどを活用し，期間を区切って短期間で開発する手法である。イのウォータフォールモデルは，要件定義から設計，製造，テストまでの工程を上流から順に一度だけ進めるモデルである。エのプロトタイピングモデルは，開発の早い段階で試作品を作って利用者に確認してもらい，要求を明確にする手法で，試作は要求を確かめるためのものである。

解説

リバースエンジニアリングは，既存のソースプログラムなどを解析して，その構造や仕様を読み取り，設計書や仕様書などの上位の表現を得る技術である。ドキュメントの残っていないソフトウェアを保守するときなどに使われる。アが該当する。

イは，修正の影響が及ぶ範囲を調べる影響分析（インパクト分析）である。ウは，機能を変えずにプログラムを構造化された形に変換するリストラクチャリング，エは，外部から見た動作を変えずにプログラムを分かりやすく書き換えるリファクタリングに当たり，いずれも同じ抽象度のままでの変換であって，上位の仕様を得るリバースエンジニアリングではない。

解説

ITIL のインシデント管理は，サービスの中断や品質の低下が起きたときに，できるだけ早く通常のサービスレベルに回復させ，業務への影響を最小限に抑えることを目的とするプロセスである。根本原因の究明よりも，回避策を使ってでもまずサービスを戻すことを優先する。エが適切である。

イの一時的回避策で対処した問題の根本原因を分析し恒久対策を検討するのは，問題管理の役割である。ウの潜在的な問題を事前に見つけ出すのも問題管理（予防的な問題管理）の役割であり，その対策は変更要求として変更管理に引き渡される。アの新しいサービスの要求を受け付けて企画立案するのは，サービスの戦略や設計の段階の活動で，インシデント管理の役割ではない。

解説

ディスクを二重化（ミラーリング）し，通常稼働時から常に二つのディスクに同じデータを書き込んでおけば，一方のディスクが故障しても，もう一方のディスクを使ってそのまま処理を続けられる。データも最新の状態に保たれるので，ハードディスクの障害時にサービスを続行する方策としてイが最も適切である。

アの格納場所を複数のディスクに分散させるのは負荷分散の方法で，どれか 1 台が故障すればそのディスクにあるデータが使えなくなる。ウの予備機を待機させても，データベースが本番機のディスクにある限り，ディスクの障害で失われたデータは予備機にない。エの毎週末のコピーでは，最大で 1 週間分の更新が失われ，復元の間はサービスも止まる。

解説

退職による権限喪失者が削除されているかを検証するには，退職の事実を正しく記録した独立の資料を出発点にして，その全員が利用者 ID リストから消えていることを確かめる。人事発令簿は退職者を漏れなく記録しているので，その全件について利用者 ID リストを照合するウが最も適切である。

アとエは，アクセス権限削除申請書を出発点や照合の相手にしているので，申請書が出されずに放置された退職者の ID は見つけられない。イは，利用者 ID リストに残っている ID について削除申請書が存在しないことを確かめるだけで，申請書が出ていないまま残っている退職者の ID を発見できない。

解説

バックアップ媒体を外部に引き渡すときは，輸送中や受渡しの間に媒体が抜き取られたり，中身が見られたりしないように，施錠できるケースに入れたり封印をしたりして，不正な持出しがあれば分かるようにしておく必要がある。単に段ボール箱に入れて渡しているだけでは，途中で抜き取られても気付けないので，エが指摘事項となる。

アの委託先での保管状況の定期的な確認，イの機密保持条項を盛り込んだ委託契約の締結，ウの記録簿への記入と受領印による引渡しの記録は，いずれも外部保管を委託する際に求められる適切な管理であり，指摘事項にはならない。