令和4年度 秋期 午前Ⅱ

解説

MAC（メッセージ認証符号）は，メッセージと，送信者と受信者だけが共有する共通鍵とから生成する短い値である。受信者は同じ共通鍵で MAC を計算し直し，受け取った MAC と一致すれば，メッセージが途中で改ざんされていないこと（完全性）を確認できる。アが適切である。

イが誤りなのは，共通鍵をもたない第三者には MAC を検証できないからである。仮に検証できたとしても，共通鍵は送信者と受信者の 2 人が持つので，MAC を作れるのは 2 人のどちらかであり，送信者が作ったと第三者に示すことはできない（これができるのはデジタル署名である）。ウ・エのように公開鍵を使って MAC を生成することはない。公開鍵は誰でも知っているので，それだけで作れる値では誰が作ったかを絞り込めない。

解説

RA（Registration Authority，登録局）は，証明書の発行を申請した者の本人確認や申請内容の審査を行い，発行申請を承認又は却下する。承認された申請に基づいて，CA（認証局）が証明書を発行する。エが該当する。

アのデジタル証明書へのデジタル署名の付与は，証明書を発行する CA（IA：発行局）の役割である。イの属性証明書を発行するのは AA（Attribute Authority，属性認証局）である。ウの失効リスト（CRL）の管理は CA の役割で，証明書の有効性の確認を応答するのは VA（検証局，OCSP レスポンダなど）である。

解説

SAML（Security Assertion Markup Language）は，標準化団体 OASIS が策定した，異なる Web サイトやドメインの間で，利用者の認証の結果や属性，認可の情報を XML 形式のアサーションとして安全に交換するためのフレームワークである。シングルサインオンの実現などに使われる。アが正しい。

イの SOAP は，XML 形式のメッセージでほかのコンピュータのサービスを呼び出すためのプロトコル（W3C が標準化）。ウの XKMS は，XML で公開鍵の登録や検証などの鍵管理を行うための仕様。エの XML Signature は，XML 文書にディジタル署名を付けるための仕様（W3C が標準化）である。

解説

Smurf 攻撃は，ICMP エコー要求（ping）の送信元 IP アドレスを攻撃対象のものに偽装し，宛先をネットワークのブロードキャストアドレスにして送る攻撃である。そのネットワークの多数のホストがいっせいに攻撃対象へエコー応答を返すので，わずかな要求で大量の応答を攻撃対象に浴びせられる。イが該当する。

アの SYN パケットを大量に送り付けるのは SYN フラッド攻撃である。ウの大きな UDP パケットを大量に送り付けるのは UDP フラッド攻撃で，第三者に反射させる形ではない。エの大きな電子メールや大量の電子メールを送り付けるのはメールボム（メール爆弾）である。Smurf の要点は，攻撃者自身が送る量よりはるかに多い通信を，第三者のホストに肩代わりさせて増幅するところにある。

解説

SYN/ACK パケットは，TCP の接続要求（SYN）を受け取ったサーバが返す応答である。IP アドレス A のポート 80/tcp から，ホストに割り振られていない未使用アドレス宛てに SYN/ACK が大量に送られているのは，攻撃者が送信元 IP アドレスを未使用アドレスなどに偽装した SYN パケットを A に大量に送り付け，A がその偽の送信元に応答している状況と推定できる。これは A を攻撃先とする SYN フラッド攻撃（サービス妨害攻撃）の跳ね返り（バックスキャッタ）であり，アが該当する。

A は SYN/ACK を返している側なので攻撃元ではなく，ウ・エは当たらない。パスワードリスト攻撃は TCP 接続を確立したうえで認証を試行する攻撃であり，実在しないアドレスとの間では接続が確立しないので，イも当たらない。

解説

パスワードスプレー攻撃は，多くの利用者が使いがちなパスワード（password や qwerty など）を一つ選び，それを多数の利用者 ID に “薄く広く” 試す攻撃である。一つの ID への連続した失敗を避けられるので，アカウントロックにかからない。攻撃の時刻や攻撃元 IP アドレスも変えて検知を逃れる。ウが該当する。

アは辞書や人名リストの語を順に試す辞書攻撃，イは考えられるパスワードをすべて試す総当たり（ブルートフォース）攻撃で，どちらも ID を一つに固定してパスワードを変えていく。エは他のサイトから漏れた ID とパスワードの組みをそのまま試すパスワードリスト攻撃である。ID を固定してパスワードを変えるのではなく，パスワードを固定して ID を変えるところがパスワードスプレーの特徴である。

解説

リバースプロキシ方式のシングルサインオンでは，対象システムへの通信をすべてリバースプロキシサーバ経由にし，そこで認証をまとめて行う。経路を 1 か所に集約するので，そのサーバが止まると SSO を使うすべてのシステムにアクセスできなくなる。つまりリバースプロキシサーバが単一障害点（SPOF）になり得る。エが適切である。

アの URL 形式の利用者 ID を自動生成するのは OpenID の特徴で，SAML は IdP と SP がアサーションをやり取りする方式である。イのクライアント PC 側でログイン画面を監視して認証情報を代行入力するのは代理認証方式で，エージェント方式は SSO の対象となるサーバ側にエージェントを組み込む。ウの代理認証方式は，対象サーバに手を入れずに導入できる点が長所であり，モジュールの組込みが要るのはエージェント方式である。

解説

前方秘匿性（Forward Secrecy）は，長期間使う秘密鍵が将来漏えいしても，過去の通信の暗号文が解読されない性質である。セッションごとに一時的な鍵を生成して使い捨てる鍵交換（DHE や ECDHE など）で実現される。TLS 1.3 では，鍵交換がこの方式に限られている。アが適切である。

イはブロックチェーンの改ざん耐性，ウは公開鍵暗号方式の鍵ペアの性質，エはハッシュ関数の一方向性（原像計算困難性）の説明である。

解説

ISO/IEC 15408 は，コモンクライテリア（CC）と呼ばれる IT セキュリティ評価基準で，IT 製品やシステムのセキュリティ機能と，その保証の度合い（EAL1〜EAL7）を共通の枠組みで評価できるようにした規格である。第三者機関が評価・認証した結果が公開されるので，調達者は製品を比べて必要な水準を満たすかを判断できる。アが該当する。

イの ISO/IEC 27002 は情報セキュリティ管理策の実践規範，ウの ISO/IEC 27017 はクラウドサービスに固有の情報セキュリティ管理策の規範で，どちらも組織のマネジメント側の規格である。エの ISO/IEC 30147:2021 は，IoT システム・サービスに信頼性を作り込むための活動を ISO/IEC/IEEE 15288 のシステムライフサイクルプロセスに組み込む規格（日本が提案したもの）で，製品の評価結果を比較するためのものではない。

解説

CASB（Cloud Access Security Broker）は，組織の利用者とクラウドサービスの間に置かれ，利用者が使っているクラウドサービスの利用状況の可視化，データセキュリティ，脅威の防御，コンプライアンスの確保などを行う仕組みである。組織の管理者は，利用されている全てのクラウドサービスを把握し，許可を得ずにクラウドサービスを利用している者（シャドー IT）を特定できる。エが正しい。

ア，イはクラウドサービスプロバイダ自身が行う DDoS 攻撃対策や入退室管理である。ウの利用しているクラウドサービスに対する脆弱性診断は，CASB の機能ではない。

解説

クリックジャッキングは，攻撃者のページに透明にした iframe で正規のページを重ね，利用者が攻撃者のページのボタンを押したつもりで，実際には重ねた正規のページのボタンを押してしまう攻撃である。対策は，自サイトのページが他サイトの frame や iframe に埋め込まれるのを禁じることで，HTTP レスポンスヘッダーに X-Frame-Options（DENY や SAMEORIGIN）を設定する。エが有効である。

アの HttpOnly 属性は JavaScript から cookie を読めなくしてクロスサイトスクリプティングによる cookie の盗取を防ぐもの，イの Secure 属性は HTTPS のときだけ cookie を送らせるものである。ウの Strict-Transport-Security は，そのサイトへは常に HTTPS で接続させる指示であり，いずれも frame への埋込みを止められない。なお Content-Security-Policy の frame-ancestors でも同じ制限ができる。

解説

ブロックチェーンでは，取引データなどをまとめたブロックに，直前のブロックのハッシュ値を含めて鎖のようにつなぐ。過去のブロックの内容を書き換えるとハッシュ値が変わり，後続のブロックとの整合性が崩れるので，参加者は改ざんを検出できる。ハッシュ関数は必須の技術で，エが適切である。

アの RADIUS は利用者認証を一元管理するプロトコル，イの SPF は電子メールの送信元ドメインを認証する仕組みで，いずれもブロックチェーンに必須の技術ではない。ウの楕円曲線暗号は取引の電子署名などに使われることがあるが，P2P ネットワークを暗号化するための必須の技術ではない。

解説

IPsec は IP パケット自体を暗号化・認証するプロトコルで，OSI 基本参照モデルのネットワーク層（第3層）で動作する。IPv6 では標準的に組み込まれている。

イの PPP はデータリンク層のプロトコル。ウの SSH とエの TLS はトランスポート層より上位で動作し，ネットワーク層の暗号化には当たらない。

解説

SMTP-AUTH は，メールクライアントがメールサーバにメールを送信するときに，ユーザアカウントとパスワードによる利用者認証を行い，認証に成功した利用者からだけ送信を受け付ける仕組みである。第三者による不正中継やなりすまし送信を防げる。ウが正しい。

アの動的 IP アドレスから管理外のメールサーバへの SMTP 接続の禁止は OP25B。イの送信元のサーバが送信元ドメインの DNS に登録されていることを確認するのは SPF。エの POP 接続で認証済みの場合だけ送信を許可するのは POP before SMTP である。

解説

SPF（Sender Policy Framework）は，あるドメインの名前で電子メールを送ってよい送信元メールサーバの IP アドレスを，そのドメインの所有者が DNS に SPF レコード（実体は TXT レコード）として公開しておく仕組みである。受信側は，受け取ったメールの送信元 IP アドレスをこのレコードと突き合わせ，ドメインが詐称されていないかを判定する。ドメイン所有者側で必要なのはこの登録なので，アが該当する。

イの DNS の問合せポート番号（53 番）を変えることは，そもそも他のサーバから引けなくなるので行わない。ウのメールサーバへのデジタル証明書の導入は SMTP over TLS などで通信を暗号化するための準備であり，送信元ドメインの認証とは別の話である。エのポート 25 番を利用不可にすると，他のメールサーバからのメールを受け取れなくなる。

解説

PGP と S/MIME は，電子メールそのものを暗号化したり，ディジタル署名を付けたりする方式で，送信者や受信者ごと，つまりメールアドレスごとに公開鍵（S/MIME ではディジタル証明書）を用意する。SMTP over TLS は，メールサーバ間などの SMTP の通信路を TLS で暗号化する方式で，サーバ証明書をメールサーバごとに用意する。

したがって，PGP がメールアドレスごと，S/MIME がメールアドレスごと，SMTP over TLS がメールサーバごとのアが適切である。

解説

プライバシーセパレータ機能（アクセスポイントアイソレーション）は，同じアクセスポイントに接続している無線 LAN 端末同士の直接通信を遮断し，各端末がアクセスポイントの先のネットワークとだけ通信できるようにする機能である。公衆無線 LAN などで，他の利用者の端末からのアクセスを防ぐために使われる。イが正しい。

アは SSID を知っている利用者だけに接続させる SSID ステルス（ANY 接続拒否），ウは MAC アドレスフィルタリングの説明である。エは電波を遮る建材やシールドなどによる電波漏えいの対策である。

解説

IPv6 の基本ヘッダーは 40 オクテットの固定長で，経路情報や断片化といった付加的な情報は拡張ヘッダーとして基本ヘッダーの後ろに連ねる。この拡張ヘッダーの長さは 8 オクテットの整数倍と決められていて，ルータが効率よく読み飛ばせるようになっている。エが適切である。

アの IPv6 では ARP を使わず，ICMPv6 の近隣探索（NDP）でアドレスを解決する。イのアドレス空間は IPv6 が 2¹²⁸，IPv4 が 2³² なので，倍率は 2¹²⁸ 倍ではなく 2⁹⁶ 倍である。ウの断片化（フラグメンテーション）は IPv6 では送信元のホストだけが行い，経路の途中のルータは行わない。大きすぎるパケットは “Packet Too Big” で送信元に通知して，送信元が経路 MTU に合わせて送り直す。

解説

クラス D の IP アドレスは，先頭 4 ビットが 1110 の 224.0.0.0～239.255.255.255 の範囲で，マルチキャストのグループを識別するために使う。エが正しい。なお，現在はクラスによる区分は CIDR に置き換えられているが，224.0.0.0/4 は引き続きマルチキャスト用に割り当てられている。

アの 250 台程度までの小規模なネットワークに割り振るのはクラス C（ホスト数最大 254），イの 65,000 台程度の中規模なネットワークに割り振るのはクラス B（最大 65,534）である。ウのプライベートアドレスは，クラス A の 10.0.0.0/8，クラス B の 172.16.0.0/12，クラス C の 192.168.0.0/16 から割り振られ，クラス D には含まれない。

解説

VRRP（Virtual Router Redundancy Protocol）は，複数のルータで一つの仮想ルータを構成し，仮想 IP アドレスと仮想 MAC アドレスを共有する。通常はマスタのルータが転送を担い，マスタが故障するとバックアップのルータが引き継ぐ。クライアントはデフォルトゲートウェイとして仮想 IP アドレスを設定しておけばよいので，設定を変えずに障害を回避できる。エが該当する。

アの RARP は MAC アドレスから IP アドレスを求めるプロトコル，イの RSTP はスパニングツリーの収束を速くしたレイヤ 2 のループ防止プロトコル，ウの RTSP は音声や動画のストリーミングの再生・停止などを制御するプロトコルである。

SELECT R.X AS A, R.Y AS B, S.X AS C, S.Z AS D
    FROM R LEFT OUTER JOIN S ON R.X = S.X

解説

LEFT OUTER JOIN は，左側の表（R）の行をすべて残し，結合条件に合う右側（S）の行があればその値を，なければ NULL を並べる。したがって結果の行数は R の 4 行のままになる。

R.X が A002 と A003 の行は S に同じ X があるので S の値が入る。A001 と A005 は S に対応する行が無いので C と D が NULL になる。S にしか無い A004 は，左側を基準にする結合なので結果に現れない。この 4 行を並べたウが正しい。アは結合できなかった行だけ，イは右側を基準にした RIGHT OUTER JOIN の結果，エは両側の行をすべて残す FULL OUTER JOIN の結果である。

解説

判定条件網羅（分岐網羅）は，各判定の結果が真になる場合と偽になる場合を少なくとも 1 回ずつ通るようにテストケースを選ぶ基準である。判定は “A > 6 or B = 0” の一つなので，これが真になる組と偽になる組の両方が要る。

アの (A=1, B=1) は 1 > 6 も 1 = 0 も成り立たないので偽，(A=7, B=1) は 7 > 6 が成り立つので真となり，両方を通る。アが適切である。イの (A=4, B=0) は B = 0 で真，(A=8, B=1) は A > 6 で真なので，どちらも真にしかならない。ウの (A=4, B=1) と (A=6, B=1) はどちらも偽（6 > 6 は成り立たない）。エの (A=7, B=1) と (A=1, B=0) はどちらも真である。なお，条件網羅（判定条件の中の個々の条件の真偽を網羅する基準）とは別の基準なので，混同しないこと。

解説

CPRM（Content Protection for Recordable Media）は，記録型のメディアに録画・録音したコンテンツを保護する著作権保護技術で，SD メモリカードや記録型 DVD で使われている。メディアごとの固有の ID を使って暗号化するので，コンテンツを別のメディアに複製しても再生できない。イが該当する。

アの CPPM は DVD-Audio など記録済み（再生専用）のメディアの保護技術，ウの DTCP は IEEE 1394 や IP ネットワーク（DTCP-IP）などで機器間を伝送するコンテンツを保護する技術，エの HDCP は HDMI や DVI などで機器からディスプレイへ送る映像信号を保護する技術である。

投資利益率 ＝ 利益の増加額 ÷ 投資額

解説

5年間の投資額は，初期費用に1年間の運用費の5年分を足したもの，削減される業務費も1年分の5年分である。A 案は投資額 30＋4×5＝50，削減額 25×5＝125，利益の増加額75で投資利益率1.5。B 案は投資額 20＋6×5＝50，削減額100，利益50で1.0。C 案は投資額 20＋4×5＝40，削減額75，利益35で0.875。D 案は投資額 15＋5×5＝40，削減額 22×5＝110，利益70で1.75。

最も投資利益率が高いのは D 案で，エが正しい。削減額が最も大きいのは A 案だが，投資額も大きいので比率では D 案に及ばない。運用費を5年分足し忘れると投資額が小さく出て順位が変わるので注意する。

解説

SaaS では，サーバの OS，DBMS，ストレージなどの基盤は SaaS 事業者が管理しており，利用者である被監査企業は，提供されるアプリケーションの利用者 ID を発行・管理して業務に使う。被監査企業のシステム監査人が利用者環境から評価できるのは，自社が管理するアプリケーションの利用者 ID のアクセスコントロールで，イが正しい。

アの DBMS の管理者 ID，ウのサーバの OS の利用者 ID，エのストレージデバイスの管理者 ID は SaaS 事業者が管理するもので，利用者環境からは評価できない。これらは事業者の監査報告書などで確認する。