令和5年度 秋期 午前Ⅱ

解説

OS コマンドインジェクションは，Web アプリケーションが Perl の system 関数や PHP の exec 関数などで外部プログラムを呼び出すときに，入力データに OS のコマンドを紛れ込ませ，不正にシェルスクリプトや実行形式のファイルを実行させる攻撃である。イに分類される。

アの HTTP ヘッダインジェクションは，入力データに改行コードを含めて HTTP レスポンスヘッダに不正なヘッダや本文を挿入する攻撃。ウのクロスサイトリクエストフォージェリは，利用者に意図しないリクエストを Web サイトに送らせる攻撃。エのセッションハイジャックは，セッション ID を盗むなどしてセッションを乗っ取る攻撃である。

解説

TLS 1.3 の暗号スイートは，AEAD（Authenticated Encryption with Associated Data）のアルゴリズムと，鍵導出（HKDF）に使うハッシュアルゴリズムの二つの組みだけで表される（TLS_AES_128_GCM_SHA256 など）。TLS 1.2 までは鍵交換・署名・共通鍵暗号・MAC の四つを並べていたが，鍵交換と署名の指定は別の拡張へ移された。アが適切である。

イは逆で，TLS 1.3 は AES-CBC のような暗号化と改ざん検知を別々に行う方式を廃止し，一つの処理でまとめて行う AEAD だけに絞っている。ウの TLS を規格化しているのは IETF であり，Wi-Fi アライアンスは無線 LAN の規格を扱う団体である。エは，クライアントが使える暗号スイートを列挙し，その中からサーバが一つ選んで通知するので，両者が別々のアルゴリズムを使うことはない。

解説

VA（Validation Authority，検証局）は，デジタル証明書が失効していないかなどの有効性の問合せを受け付けて応答する機関である。OCSP などのプロトコルで，証明書の失効状態をオンラインで回答する。ウが正しい。

イのデジタル証明書にデジタル署名を付与して発行するのは CA（認証局）の発行局（IA）の役割，エの本人確認を行い証明書の発行を指示するのは RA（登録局）の役割である。アの属性証明書の発行を代行するのは VA の役割ではない。

解説

XML デジタル署名（XML Signature）は，署名と署名対象の位置関係によって三つの形式をとる。署名の中に署名対象を入れるエンベローピング署名，署名対象の中に署名を入れるエンベロープ署名，そして署名と署名対象を別々に置くデタッチ署名である。デタッチ署名の署名対象は外部のリソースでもよいが，同じ XML 文書の中の別のエレメントを URI で参照する形にもできる。アが適切である。

イのエンベローピング署名は，署名の中に署名対象を入れる形式を指すだけで，一つの署名対象に複数の署名を付けるという意味ではない。ウの CMS（Cryptographic Message Syntax）は S/MIME などで使われる署名の書式で，XML 署名は署名の情報を XML の要素として記述する。エの ASN.1 も同じく XML 署名では使わない記法である。

解説

クリプトジャッキング（cryptojacking）は，暗号資産（crypto）とハイジャック（hijacking）を組み合わせた語で，他人の PC やサーバに不正に入り込む，あるいは Web ページに仕込んだスクリプトを閲覧者のブラウザで動かすなどして，その機器の CPU などのリソースを勝手に使い，暗号資産のマイニング（採掘）を行う攻撃である。アが該当する。

イは暗号資産取引所の利用者アカウントへの不正ログインによる窃取で，リスト型攻撃などに当たる。ウは取引先や経営者を装ったメールで送金先を偽る攻撃で，ビジネスメール詐欺（BEC）である。エは PC を使えなくして復旧と引換えに金銭（暗号資産）を要求するもので，ランサムウェアである。いずれも他人の計算資源でマイニングを行う攻撃ではない。

解説

Mirai は，インターネット上のランダムな IP アドレスに対して telnet のポートでログインを試み，工場出荷時のままの弱い ID とパスワードを使っている IoT 機器（ネットワークカメラやルータなど）に感染を広げ，ボットネットを形成するマルウェアである。感染した機器は C&C サーバからの指令に従って，標的に DDoS 攻撃を行う。エが正しい。

アの Web サーバの脆弱性を悪用して Web ページを改ざんし，決められた日時に DDoS 攻撃を行うのは Code Red などのワームの特徴である。イの Web ページに不正な JavaScript を挿入して利用者を誘導するのは Web サイト改ざんによる攻撃（Gumblar など），ウのファイル共有ソフトで情報を公開してしまうのは Antinny などの暴露ウイルスの動作である。

解説

MITB（Man In The Browser）攻撃では，PC に入り込んだマルウェアが Web ブラウザの中で表示内容や送信内容をすり替えるので，画面に正しい振込先が出ていても実際には別の口座番号が送られてしまう。そこで，送金操作を行う PC とは別のデバイスに利用者自身が振込先口座番号などの取引情報を入力させ，そのデバイスが取引情報から計算した値（トランザクション署名）を銀行へ送る。銀行側は受け取った取引内容から同じ計算をして照合するので，途中で取引情報がすり替えられていれば値が合わずに検知できる。ウが該当する。

アのメールで送る送金用ワンタイムパスワードや，エのログイン用ワンタイムパスワードは，取引の “内容” とは結び付いていないので，正しい利用者が正しく認証したうえで中身だけをすり替える MITB を防げない。イのデジタル証明書による利用者認証も，認証を突破する攻撃には効くが，認証後のブラウザ内での改ざんには効かない。

解説

SAML（Security Assertion Markup Language）は，標準化団体 OASIS が策定した，認証・属性・認可の情報を “アサーション” として XML で表し，異なるドメインの間で安全にやり取りするための標準規格である。シングルサインオンの実現に広く使われている。イが適切である。

アは，利用者に代わって他のサービスがリソースへアクセスすることを許可する仕組みで，OAuth の説明である（なお OAuth は認証ではなく認可のプロトコルである）。ウの利用者 ID に URL や XRI を使うものは OpenID（2.0 まで）の説明である。エの SGML をインターネット用に最適化したものは XML そのものの説明で，SAML は XML を使って書かれた規格ではあるが，XML の定義ではない。

解説

CPS（Certification Practice Statement，認証実施規程）は，RFC 3647 で「認証局が証明書の発行，管理，失効，更新又は鍵更新に当たって用いる実務慣行を記述した文書」と定義されている。認証局が自らの認証業務をどのように運用するかを具体的に定めて公開するものなので，ウが該当する。

CPS と対になる文書に CP（Certificate Policy，証明書ポリシー）があり，CP が「証明書が満たすべき要件」を定めるのに対し，CPS は「その要件を認証局がどう満たすか」を明らかにする。アの証明書の所有者（利用者）やイの登録手続を代行する事業者（RA）が策定するものではなく，策定するのは認証局自身である。エの認証局を監査する第三者機関の運用を定めた文書でもない。

解説

NOTICE（National Operation Towards IoT Clean Environment）は，NICT が国内のグローバル IP アドレスをもつ IoT 機器に対して，容易に推測されるパスワードを入力するなどしてサイバー攻撃に悪用されるおそれのある機器を調査し，その結果をインターネットサービスプロバイダに通知して，プロバイダから利用者に注意喚起を行う取組である。イが適切である。

NOTICE は利用者への注意喚起を目的とした取組であり，アやエのように機器の製造者に向けて分析結果やテストベッドを提供するものではない。ウのように利用者の申告を受けて個別に侵入テストや脆弱性調査を行うものでもない。

解説

JIS Q 27000:2019 は，リスク特定（3.68）を“リスクを発見，認識及び記述するプロセス”と定義し，注記でリスク源，事象，それらの原因及び起こり得る結果の特定が含まれるとしている。エが適切である。

アの“付け込まれる可能性がある，資産又は管理策の弱点”はぜい弱性（3.77）の定義，イの“望ましくないインシデントの潜在的な原因”は脅威（3.74）の定義であり，二つが入れ替わっている。ウのリスク分析の結果をリスク基準と比較して受容可能か又は許容可能かを決定するプロセスは，リスク評価（3.67）の定義である。リスク対応（3.72）は“リスクを修正するプロセス”と定義されている。

解説

SCAP（Security Content Automation Protocol，セキュリティ設定共通化手順）は，NIST が策定した，脆弱性管理や測定，評価を自動化するための仕組みである。脆弱性を識別する CVE，深刻度を評価する CVSS，製品を識別する CPE，設定項目を識別する CCE，弱点の種類を示す CWE といった “共通の名前付け” の仕様と，それらを記述する言語（XCCDF・OVAL）を組み合わせて構成されている。イが該当する。

アの FIPS は米国の連邦情報処理規格の総称で，暗号モジュールの要求事項（140-3）などを含むが，脆弱性管理の自動化の基準ではない。ウの SIEM は複数機器のログを集約して相関分析する “製品の分類”，エの SOAR はインシデント対応を自動化する “技術” であり，どちらも NIST が策定した基準ではない。

解説

DNSSEC は，DNS のリソースレコードに認証局ではなくゾーンの鍵によるデジタル署名（RRSIG レコード）を付け，検証する側であるリゾルバ（フルサービスリゾルバ）が，受信したリソースレコードの署名を上位ゾーンからの信頼の連鎖にたどって検証する仕組みである。これによって，データが正当な権威 DNS サーバに由来すること（作成元の正当性）と，途中で書き換えられていないこと（完全性）を確認でき，キャッシュポイズニングを防げる。エが適切である。

ア・ウの “暗号化して盗聴を防ぐ” は DNSSEC の目的ではない。DNS の内容はもともと公開情報であり，検証できることに意味がある。経路を暗号化したい場合は DoT（DNS over TLS）や DoH（DNS over HTTPS）を使う。イは検証を行う主体が逆で，署名を検証するのは権威 DNS サーバではなくリゾルバ側である。

解説

OAuth 2.0 は RFC 6749 “The OAuth 2.0 Authorization Framework” で規定された，認可（authorization）のためのプロトコルである。リソースオーナー（利用者）が，自分の持つリソースへのアクセスをクライアント（サービス）に許可すると，認可サーバがアクセストークンを発行し，クライアントはその範囲の権限でリソースサーバにアクセスする。イが適切である。

ア・ウの「アクセスしてきた者が本人であるかどうかを確認する」のは認証（authentication）であり，OAuth 2.0 の目的ではない。OAuth 2.0 の上に認証の層を載せた仕様が OpenID Connect で，こちらは ID トークンで本人確認の結果を伝える。エは権限の付与という中身は正しいものの，それを「認証を行うためのプロトコル」としている点が誤りである。

解説

SSH（Secure Shell）は，遠隔のコンピュータにログインして操作するためのプロトコルで，通信路の暗号化，サーバとクライアントの認証，利用者の認証を備える。平文のまま通信する telnet や rlogin を置き換えるものとして使われる。エが正しい。

アの L2TP は第 2 層のトンネリングプロトコルで，暗号化の機能はもたず IPsec と組み合わせて使う。イの LDAP はディレクトリに問い合わせるためのプロトコル。ウの RADIUS は認証サーバとアクセスサーバの間で認証・認可・課金の情報をやり取りするプロトコルであり，遠隔ログインの手段ではない。

解説

IMAPS は，メールを受信・閲覧するプロトコル IMAP の通信を TLS で暗号化したもの（IMAP over TLS）で，認証情報だけでなくメール本文を含む通信全体が暗号化される。イが該当する。

アの APOP は，POP3 のパスワードをチャレンジレスポンス方式でハッシュ化して送る認証方式で，パスワードは平文で流れないがメール本文は暗号化されない。ウの POP3 はそのままでは通信を暗号化しない。エの SMTP Submission は，メールクライアントからメールサーバへの送信に使う仕組み（ポート 587）であり，受信のためのプロトコルではない。

解説

変更前は DB サーバが DMZ にあったので，内部ネットワークの運用管理 PC から DB サーバへの SSH は FW をまたいでおり，これを許可するルールが要った。変更後は DB サーバが運用管理 PC と同じ内部ネットワークへ移り，この通信は FW を通らなくなるので，条件 (4) の “必要な通信だけを許可する” に従えば不要になったルールは削除する。イが該当する。

アのインターネットから WebAP サーバへの HTTPS は，条件 (1) で公開を続けるので削除できない。ウは，条件 (2) で WebAP サーバから DB サーバへ使うのは ODBC であり，条件 (3) で SSH で各サーバに接続できるのは運用管理 PC だけなので，サービスも送信元も合っていない。エのインターネットから WebAP サーバへの ODBC は，条件のどこにも必要と書かれておらず，公開してはならない通信である。

解説

クラス C のネットワークはホスト部が 8 ビットで，256 個のアドレスをもつ。これを四つのサブネットに分けるにはサブネット部に 2 ビット使うので，ホスト部は残り 6 ビットとなり，サブネットマスクは上位 26 ビットが 1 の 255.255.255.192（/26）になる。エが正しい。

1 サブネット当たりのアドレスは 2⁶＝64 個で，ネットワークアドレスとブロードキャストアドレスを除くと 62 ノードを収容できるので，50 ノードずつという条件を満たす。ウの 255.255.255.128（/25）では 2 分割にしかならず，アの 255.255.255.0 は分割しない場合のマスクである。イの 255.255.255.64 は，2 進数にすると 01000000 となって 1 が連続しないため，そもそもサブネットマスクとして使えない。

解説

IPv4 のマルチキャストアドレスはクラス D と呼ばれる 224.0.0.0〜239.255.255.255 の範囲で，この範囲のアドレスを宛先にすると，そのグループに参加しているノードだけがデータを受け取る。エの 239.0.1.1 がこの範囲に入る。

アの 10.0.1.1 とウの 192.168.1.1 は，組織内で自由に使えるプライベート IP アドレスで，いずれも特定の 1 台を指すユニキャストアドレスである。イの 127.0.1.1 は 127.0.0.0/8 のループバックアドレスで，自分自身を指す。なお 239.0.0.0/8 はローカルスコープに限定されたマルチキャストアドレスで，組織の外へは転送されない。

解説

DHCP でアドレスを受け取ったクライアントは，そのアドレスを使い始める前に，同じアドレスを使っているホストがいないかを自分でも確かめることが望ましい。RFC 2131 は “The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address)” とし，配布されたアドレスに対する ARP 要求をブロードキャストする方法を示している。応答が返れば既に使われていると分かり，クライアントは DHCPDECLINE をサーバへ送って割当てをやり直す。アが適切である。

イの DNS は名前と IP アドレスの対応を引く仕組み，ウの ICMP は到達性の確認やエラー通知に使うが，重複の検出手順として推奨されているのは ARP である。エの RARP は MAC アドレスから IP アドレスを得る古い仕組みで，用途が逆である。

解説

データディクショナリは，DBMS が管理している情報そのものを格納した領域で，表や列の定義といったデータ構造，索引，利用者とその権限，統計情報などが入っている。利用者が定義したデータではなく，データについてのデータ（メタデータ）を持つ点が要点である。ウが該当する。

アの一時的なデータを置くのは作業領域（ソート用の一時表領域など）である。イのデータベース自体の複製はバックアップファイル，エの読込み・書込みの記録はログファイル（ジャーナル）であり，いずれも障害回復のために使うものでデータディクショナリではない。

解説

カオスエンジニアリングは，分散システムに対して，本番やそれに近い環境でわざとサーバの停止や遅延といった障害を起こし，そのときのシステムの振る舞いを観察して弱点を見つけ，修正することを繰り返す手法である。障害時の挙動が予測しきれない大規模な分散システムで，実際に壊してみることで耐障害性を確かめる。ウが該当する。

アの DevOps は開発と運用が連携して継続的に価値を届ける考え方や文化，イの Infrastructure as Code はサーバやネットワークの構成をコードで記述して自動で構築できるようにする手法，エのテスト駆動開発はコードを書く前にテストコードを書く開発手法であり，いずれも意図的に障害を起こして観察するものではない。

解説

スクラムは，プロダクトオーナ，スクラムマスタ，開発者という役割，スプリント，スプリントプランニング，デイリースクラム，スプリントレビュー，スプリントレトロスペクティブというイベント，プロダクトバックログ，スプリントバックログ，インクリメントという作成物，及びそれらを結び付けるルールから成る，ソフトウェア開発のフレームワークである。ウが該当する。

アはコミュニケーション，シンプル，フィードバック，勇気，尊重の価値を掲げるエクストリームプログラミング（XP）。イは推測・協調・学習のサイクルを繰り返す適応型ソフトウェア開発（ASD）。エはフィーチャ（顧客にとって価値のある機能）を単位として計画と開発を進めるフィーチャ駆動型開発（FDD）の説明である。

解説

JIS Q 20000-1:2020 の 9.2（内部監査）は，SMS が“組織自体が規定した SMS に関する要求事項”及び“この規格の要求事項”に適合しているか，並びに有効に実施され維持されているかに関する情報を提供するために，あらかじめ定めた間隔で内部監査を実施することを要求している。設問の〔要求事項〕は，この二つをそのまま挙げたもの。

アは 9.1（監視，測定，分析及び評価）で，SMS 及びサービスのパフォーマンスを測る活動。イは 9.4（サービスの報告）。エは 9.3（マネジメントレビュー）で，トップマネジメントが SMS の適切性・妥当性・有効性を評価するものであり，要求事項への適合を確かめる監査とは目的が異なる。

解説

直接修正は，アプリケーションソフトウェアの機能を経由せずに特権 ID でデータを書き換えるので，何をどう変えたかの証跡を別に残さないと後から追えなくなる。更新ログ上でアプリケーションの機能を経由した更新として記録されていると，直接修正が行われた事実そのものが記録から読み取れず，事後の検証ができない。これは統制上の不備なので，監査人が指摘事項として報告すべきものである。アが該当する。

イの事前申請の承認と事後の結果承認，ウの作業終了時に特権 ID を無効にすること，エの利用部門からの依頼票に基づいてシステム部門が実施することは，いずれも直接修正を必要最小限に抑え，正当性を確かめるための適切な統制であり，指摘事項には当たらない。