問題はIPAからご確認ください。
https://www.ipa.go.jp/shiken/mondai-kaiotu/2021r03.html#aki_sc
答えはIPAの回答例となります。
設問１
問題 本文中の下線①について、該当するものはどれか。解答群の中から全て選び、記号で答えよ。
ア CI デーモンのプロセスを中断させる。
イ いずれかのバックエンド上の全プロセスを列挙して攻撃者に送信する。
ウ インターネット上の Web サーバに不正アクセスを試みる。
エ 攻撃者サイトから命令を取得し、得られた命令を実行する。
オ ほかの N サービス利用者のビルドスクリプトの出力を取得する
仮想化の脆弱性を悪用しないので、できる攻撃はコンテナの中だけで完結するものです
また、バックエンドには管理者権限でプロセス監視が稼働しています
ア CI デーモンのプロセスを中断させる。
→CIデーモンはバックエンド側（OS側）なので、コンテナ内の操作だけでOS側は操作できないので不可です
イ いずれかのバックエンド上の全プロセスを列挙して攻撃者に送信する。
→コンテナ内の操作だけでOS側は操作できないので不可です
ウ インターネット上の Web サーバに不正アクセスを試みる。
→コンテナ内で任意コマンドを実行できるので、外部の Web サーバへ不正アクセスは可能です
エ 攻撃者サイトから命令を取得し、得られた命令を実行する。
→外部の Web サーバへ不正アクセスは可能であれば、命令の取得も可能です
オ ほかの N サービス利用者のビルドスクリプトの出力を取得する
→自分のコンテナから別のコンテナへアクセスとなるので不可です
答え：ウ、エ
設問２
（１）
問題 本文中の下線②について、攻撃者による不正ログインの方法を、50字以内で具体的に答えよ。
フィッシングサイトに引っかかったUさんが、誤って偽サイトにログイン情報を入力してしまい、その盗まれたログイン情報を元にログインされてしまったようです。
P18に記載されているように、クラウド管理サイトへのログインはTOTP（ワンタイムパスワード）が必要となります。
なので、このTOTPが有効なうちにログインを成功させる必要があります
答え：偽サイトに入力されたTOTPを入手し、そのTOTPが有効な内にログインした
（２）
問題 本文中の下線③について、RFC 9162 で規定されている技術を、解答群の中から選び、記号で答えよ。
ア Certificate Transparency
イ HTTP Public Key Pinning
ウ HTTP Strict Transport Security
エ Registration Authority
RFC 9162 は、Certificate Transparency (CT)を規定しています
CTは、不正なSSL/TLS証明書が出回るのを検知するための仕組みで、Googleが中心となって提案・標準化された技術です。
試験時でわかんない場合は知識問題なので、問題で証明書発行とか記載されているので、証明書と記載されているアを選びますかね
答え：ア
（３）
問題 本文中の下線④について、このような手法の名称を、解答群の中から選び、記号で答えよ。
ア DNS スプーフィング
イ ドメインフロンティング
ウ ドメイン名ハイジャック
エ ランダムサブドメイン攻撃
SNI（Server Name Indication） は、TLSハンドシェイク時に「どのドメイン名の証明書を要求しているか」をクライアントがClientHelloでサーバに知らせるための拡張機能です。
実際のhostヘッダは暗号化されてしまうが、SNIは暗号化されていないからUTMなどはSNIを見て通信先を安全かの判断材料にします。
SNIに正規ドメインを入れつつ、実際の HTTP Hostでは別の悪意あるホストにリクエストを届けさせる手法は、ドメインフロンティングです。
答え：イ
（4）
問題 本文中の下線⑤について、プロセスYがシークレットを取得するのに使った方法として考えられるものを、35字以内で答えよ。
シークレットは表１に記載されている、「ビルドスクリプトを実行するシェルに設定された環境変数を、Nサービス利用者が登録する機能で、登録した情報をシークレットと呼ぶ」とあります。
この問題の答えはLinuxが解っていないと答えは出せないですね
表2でバックエンドにはLinuxがインストールされていると記載されています/proc はカーネルが、システムの状態やプロセス情報をファイルやディレクトリの形で見せる「仮想ファイルシステム」です。
/proc/「pid」/environに環境変数が入ってます。
ここからシークレットを取得したと考えられます。
答え：/procファイルシステムから環境変数を読み取った
（５）
問題 図 2 中の下線⑥について、仮に、利用者が偽サイトでログインを試みてしまっても、攻撃者は不正ログインできない。不正ログインを防ぐ WebAuthn の仕組みを、40 字以内で答えよ。
WebAuthn の仕組みは下記脳ような流れです
■サイトへの認証器の登録
サイトにアクセスして認証器の登録作業をする
ブラウザが認証器へ対象のサイトの鍵ペア（秘密鍵＋公開鍵）の生成を依頼
作成した公開鍵をサイトへ登録
■登録後にユーザ認証（ログイン）
ユーザがサイトにアクセスして、ログインを要求するとサイトはユーザに短期のチャレンジを渡す（ランダムな文字列）。
ブラウザはそのチャレンジをPCの認証器に渡し、「署名」を依頼する。
認証器は受け取ったチャレンジは本当に対象のサイトの物かを確かめる（origin＝ドメインを確認）。
登録時とサイト（ドメイン）からのチャレンジなら、認証器は中の秘密鍵でチャレンジに署名して返す。
（もしサイトが偽物（フィッシング窓口）なら、認証器は署名しない）
ブラウザっはサイトへ署名を渡し、サイトは公開鍵で署名を検証。問題なければ確認OK。
答え：認証に用いる情報に含まれるオリジン及び署名をサーバが確認する仕組み
（６）
問題 図２中の「ａ」に入る適切な字句を、解答群の中から選び、記号で答えよ。
ア：CAA イ：CNAME ウ：DNSKEY エ：NS オ：SOA カ：TXT
CAA（Certification Authority Authorization）
証明書を発行できる認証局（CA）を制限するためのレコード。
CNAME（Canonical Name）
ドメインの別名（エイリアス）を設定する。
DNSKEY
DNSSEC（DNSのセキュリティ拡張）で使う公開鍵を登録するレコード。
NS（Name Server）
ドメインを管理する権威DNSサーバを指定する。
SOA（Start of Authority）
ドメインゾーン（DNS管理単位）の管理情報を示す。
TXT
任意のテキスト情報（SPFなど）を登録する。
答え ａ：ア
設問３
（１）
問題 本文中の下線⑦について、Kさんが開始した対応を踏まえ、予想される攻撃を、40字以内で答えよ。
APP_SIGN_KEYは「アプリ署名」に使われる秘密鍵なので、攻撃者は正規アプリを装った偽アプリを作って、正規の署名を付けることができます。
STORE_API_KEYは、J社のアプリ配信サイトへアプリをアップロードするための認証に使います、なので偽アプリを正規のアカウントとしてストアにアップロードできます
このことから、盗んだシークレットを悪用し、正規アプリを装った不正アプリを配布する攻撃が可能です。
2つの対応は盗まれたシークレットに対する物ですね
ソースコードは直ぐには影響はないと思いますが、脆弱性を発見されたり、偽アプリ作成に利用されたりすると思われます。
答え：有効なコード署名が付与された偽のＰアプリをJストアにアップロードする攻撃
（２）
問題 本文中の下線⑧について、必要な対応を、20字以内で答えよ。
契約者だけが取得・削除できるとあるので、漏えいしたとなれば無効か削除が必要となります。
無効とは記載が無いので、削除ですね
答え：J社Webサイトから削除する
（３）
問題 本文中の下線⑨について、コード署名を付与する際にHSMを使うことによって得られるセキュリティ上の利点を、20字以内で答えよ。
HSM は、 TPM と同様、鍵は HSM の外に出ることが無いです。
サーバーが暗号処理や署名を要求すると、HSM がその処理を行い、結果だけをサーバーに返します。
なので、鍵の漏えいや不正利用を防げます。
答え：秘密鍵が漏れないという利点
（４）
問題 本文中の下線⑩について、影響と対応を、それぞれの20字以内で答えよ。
二つの対応はシークレット「APP SIGN KEY・STORE API KEY」を削除して新たに作成しています。
STORE API KEYはJストアのアプリをアップロードするための物なのでユーザには影響がありません。
APP SIGN KEYはアプリが正式な物か確認するものとなりますので、旧バージョン（古い署名のまま）アプリだとコード署名の有効性の検証に失敗して起動しないです。
対応はアプリをアップデートして最新にする。
答え 影響：Pアプリが起動できない
対応：Pアプリをアップロードする
コメント