情報処理安全確保支援士
厳選10問ドリル｜午前II＋午後ミックス
PKI/署名・セキュアコーディング・シークレット管理・委託先管理・DDoS対策という、実務寄りの分野を集中的に潰します。
🖋️ PKI/署名・メール暗号化編
「秘密鍵で署名、公開鍵で検証」という基本動作と、署名・暗号化・送信元認証の役割の違いを押さえます。
「誰の、どの鍵を使うか」を必ず確認する
公開鍵暗号を使う技術は、「誰の鍵で、何をするか」を入れ替えた選択肢が頻出します。署名は秘密鍵で作り公開鍵で検証する、という方向性を固定して読みましょう。
デジタル署名およびタイムスタンプに関する記述のうち、最も適切なものはどれか。
- アタイムスタンプは、電子文書がある時刻に存在し、それ以降改ざんされていないことを証明する技術であり、デジタル署名と組み合わせて長期署名に利用される
- イデジタル署名は、送信者の秘密鍵を用いて生成し、受信者は送信者の秘密鍵で検証する
- ウタイムスタンプを付与すれば、電子証明書の有効期限が切れた後も、署名自体の検証は不要になる
- エデジタル署名は、文書の機密性（盗聴防止）を保証するための技術である
タイムスタンプは「ある時刻にその電子文書が存在し、それ以降改ざんされていないこと」を時刻認証局（TSA）が証明する技術です。デジタル署名と組み合わせることで、証明書の期限切れ後も「署名した時点では有効だった」ことを証明できる長期署名が可能になります。
イのように検証に「送信者の秘密鍵」を使うとする記述は誤りで、検証には送信者の公開鍵を使います。エのように機密性の保証とする記述も誤りで、デジタル署名は完全性・本人性（否認防止）を保証する技術です。
デジタル署名＝「秘密鍵で署名、公開鍵で検証」。タイムスタンプ＋デジタル署名＝長期署名（証明書の期限切れ後も過去の正当性を証明できる）という組み合わせを覚えておきましょう。
S/MIMEに関する記述のうち、最も適切なものはどれか。
- アデジタル署名および公開鍵暗号方式によってメール本文を保護し、送信者の認証と内容の機密性を両立できる
- イ利用するには、送信者・受信者ともに共通鍵暗号方式の鍵をあらかじめ電話等で共有しておく必要がある
- ウSPFやDKIMと同様に、送信元のドメインを検証する仕組みである
- エS/MIMEで暗号化されたメールは、メールサーバ側でウイルススキャンを行わなくても安全性が保証される
S/MIMEは、PKI（公開鍵暗号基盤）を利用して、メール本文へのデジタル署名（送信者の本人性・完全性の保証）と暗号化（機密性の保証）を実現する規格です。送信者は自身の秘密鍵で署名し、受信者の公開鍵で本文を暗号化します。
イのように事前に共通鍵を電話等で共有する必要はありません（公開鍵証明書の交換が前提）。ウのように送信元ドメインの検証とするのも誤りで、それはSPF/DKIM/DMARCの役割です。
S/MIMEは「メール本文レベル」の署名・暗号化、SPF/DKIM/DMARCは「送信元（エンベロープ・ヘッダ）レベル」の認証、と階層を分けて理解しましょう。
💥 バッファオーバーフロー編
「緩和策」と「根本対策」を取り違えない読み方が、午後の記述で差がつくポイントです。
ASLR/DEP/カナリアは「防御の補強」、境界チェックは「根本治療」
これらの仕組みは攻撃を難しくする・検知するものであり、脆弱性そのものを取り除くわけではありません。設問が「対策」を聞いている場合、まず根本原因への対応を書きましょう。
バッファオーバーフロー対策に関する記述のうち、最も適切なものはどれか。
- アASLRは、プログラムの実行時にメモリ上の配置をランダム化することで、攻撃者が想定するアドレスへの攻撃コードの誘導を困難にする
- イスタック保護機構（カナリア等）は、ヒープ領域のメモリ破壊を検知するための機構であり、スタック領域には効果がない
- ウDEPは、データ領域に書き込まれたコードを含め、メモリ上のすべての領域でコードの実行を許可する機能である
- エ入力値の長さチェックを行わないプログラムであっても、最新のCPUを使用していればバッファオーバーフローは発生しない
ASLR（Address Space Layout Randomization）は、プログラムの実行ごとにメモリ配置アドレスをランダム化する仕組みで、攻撃者が固定アドレスを前提とした攻撃コードを仕込むことを困難にします。
イは誤りで、スタック保護機構はまさにスタック領域の破壊を検知する機構です。ウもDEPの説明が正反対（「許可する」ではなく「許可しない」が正しい）。エのように「最新のCPUなら安全」と過信するのも誤りです。
バッファオーバーフロー対策は「ASLR（アドレスのランダム化）」「DEP/NX（データ領域でのコード実行禁止）」「スタック保護（カナリア）」の3点セットですが、根本対策は入力値の長さを正しく検証する安全なコーディング（境界チェック）です。
📄 ケース
某社が開発するC言語で書かれたネットワークサービスでは、外部から受信したデータを固定長のバッファにコピーする処理において、受信データの長さを確認せずにコピーを行っていた。セキュリティ診断の結果、想定より長いデータを送信すると、プログラムが異常終了したり、特定の条件下では任意のコードが実行される可能性があることが確認された。
設問：このプログラムが実装すべき対策を、その理由も含めて40字以内で述べよ。
「受信データの長さを確認し、バッファサイズを超える場合はコピーを行わない境界チェックを実施する」
バッファオーバーフローは、確保したメモリ領域を超えるデータが書き込まれることで、隣接するメモリ領域が上書きされ、異常終了や任意のコード実行につながります。根本対策は、コピー処理の前に入力データの長さを確認する境界チェックです。
「ASLRを有効にする」「DEPを有効にする」は緩和策として有効ですが、根本対策にはなりません。これらはあくまで悪用を困難にする補助的な対策であり、脆弱性自体をなくすものではない点に注意です。
バッファオーバーフロー対策の優先順位は「①入力値の境界チェック（根本対策） ＞ ②ASLR/DEP/スタック保護（緩和策・多層防御）」。緩和策だけに頼った解答は減点対象になりやすいです。
🔍 シークレット管理・OSINT編
「後から削除すれば大丈夫」という誤解を崩す、Gitの履歴と認証情報漏えいの関係を押さえます。
漏えいに気付いたら「削除」ではなく「無効化」
公開リポジトリ上の認証情報は、攻撃者が自動スキャンしているためコミットから数分〜数時間で悪用される非常に速いインシデントです。削除では履歴に残るため、唯一の確実な対策は無効化・再発行です。
ソースコードにおける認証情報（APIキー等）の管理に関する記述のうち、最も適切なものはどれか。
- アソースコードにAPIキーやパスワードを直接記述（ハードコーディング）すると、リポジトリの公開設定の誤りなどにより認証情報が外部に漏えいするリスクがある
- イ認証情報をソースコードにハードコーディングしておけば、環境変数や外部の鍵管理サービスを利用するよりも安全性が高い
- ウプライベートリポジトリであれば、認証情報をソースコードに直接記述しても外部に漏えいするリスクは一切ない
- エ一度公開リポジトリにコミットした認証情報は、後から該当の行を削除すれば、漏えいのリスクは解消される
ソースコードへの認証情報のハードコーディングは、リポジトリを誤って公開設定にしてしまった場合などに漏えいするリスクを抱えます。認証情報は環境変数や専用の鍵管理サービス（Secrets Manager等）で管理することが推奨されます。
エのように「後から削除すれば大丈夫」と思いがちですが、Gitはコミット履歴を保持するため、過去のコミット履歴に認証情報が残り続けます。ウのように「プライベートだから安全」と思い込むのも危険です。
認証情報の管理は「ハードコーディングしない」「漏えいした場合は速やかに無効化・再発行する（削除だけでは不十分）」が基本です。コミット前に機密情報を検出するシークレットスキャンの活用も有効です。
📄 ケース
某社の開発者は、検証用のスクリプトをGitHub上の公開リポジトリにアップロードした際、誤ってクラウドサービスのAPIキーをソースコードに直接記述したままコミットしてしまった。数時間後、何者かが当該APIキーを使用して大量のクラウドリソースを不正に起動し、某社に高額な利用料金が発生する事案が発生した。某社が調査のためGitHub上の履歴を確認すると、開発者がその後すぐに該当行を削除する修正コミットを行っていたが、被害は防げなかった。
設問：この開発者が当該コミットの直後に最優先で行うべきだった対応を、25字以内で述べよ。
「漏えいしたAPIキーを無効化し、新しいキーを再発行する」
Gitはコミット履歴を保持するため、ソースコードから該当行を削除しても、過去のコミット履歴を遡れば認証情報を取得できてしまいます。一度公開された認証情報は「漏えいした」ものとして扱い、速やかに無効化することが唯一の確実な対策です。
「該当行を削除する」だけでは不十分です。このケースで実際に行われたが被害を防げなかった対応そのものです。「キーの無効化・再発行（ローテーション）」という対応こそが正解の核心です。
公開リポジトリ上での認証情報漏えいは、攻撃者が自動でリポジトリをスキャンしているため、コミットから数分〜数時間で悪用される非常に速いインシデントパターンです。漏えいに気付いた場合は「削除」ではなく「無効化・再発行」が原則です。
🤝 委託先・サードパーティ管理編
「委託すれば責任も移る」という誤解を崩す、委託元の監督義務を押さえます。
「適切に管理すること」だけでは契約として機能しない
抽象的な一文だけの契約は、委託先が何をすべきか分からず、実効性のある統制になりません。具体的なルール＋遵守状況の確認が委託元の監督義務の本質です。
個人データの取扱いを外部に委託する場合の委託元の義務に関する記述のうち、最も適切なものはどれか。
- ア委託元は委託先に対して必要かつ適切な監督を行う義務を負う
- イ委託先と業務委託契約を締結すれば、個人データ漏えいの責任は委託先のみが負い、委託元の責任は問われない
- ウ委託先のセキュリティ対策状況は、契約締結時に一度確認すれば、その後の見直しは不要である
- エ個人データの取扱いを委託する場合、委託先の選定基準やセキュリティ要求事項を定める必要はなく、委託先の裁量に委ねてよい
個人情報保護法のもとでは、個人データの取扱いを外部委託する場合でも、委託元は委託先に対して必要かつ適切な監督（選定、契約内容の取り決め、取扱状況の把握等）を行う義務を負います。
イのように「委託すれば責任も移る」と思いがちですが、委託先に問題があった場合でも委託元の監督責任が問われます。ウのように「一度確認すれば終わり」とする記述も誤りで、継続的な確認が求められます。
個人データの委託に関する義務は「委託先の適切な選定」「必要な契約事項の取り決め」「委託先における取扱状況の把握（定期的な監督）」の3点セットです。
📄 ケース
某社は、顧客データの分析業務を外部のデータ分析会社に委託していた。委託先の従業員が、私物のUSBメモリに暗号化せず顧客データをコピーして社外に持ち出し、紛失する事案が発生した。某社が委託先との契約内容を確認したところ、業務委託契約書には「個人情報を適切に管理すること」という抽象的な一文のみが記載されており、具体的な取扱いルール（外部記憶媒体への複製の禁止、暗号化の要否等）は定められていなかった。
設問：今後の再発防止のために、某社が委託契約において整備すべき内容を、その理由も含めて40字以内で述べよ。
「外部記憶媒体への複製禁止や暗号化の要否など、具体的な取扱いルールを契約書に明記し、委託先での遵守状況を定期的に確認する」
「適切に管理すること」という抽象的な記載のみでは、委託先がどのような対策を取るべきか具体性がなく、実効性のある統制になりません。
「委託先を変更する」のみでは、同様の問題が別の委託先でも再発するリスクがあるため、根本対策としては不十分です。「契約内容の具体化」と「監督の実施」の両方に言及できているとより高評価です。
「適切に管理すること」のような抽象的な契約条項は、実効性のある統制とは言えません。具体的な取扱いルールの明記と、委託先における遵守状況の定期的な確認が、委託元の監督義務を果たすための基本です。
🌊 DDoS対策編
「自社のサーバを強くする」のではなく「自社の手前で吸収する」という発想の転換を押さえます。
DDoSの目的は「盗む」ことではなく「止める」こと
DDoS攻撃は機密性ではなく可用性を狙います。対策もデータ保護とは違う発想、つまり「攻撃トラフィックを自社の手前で分散・吸収する」ことが基本です。
DDoS（分散型サービス妨害）攻撃に関する記述のうち、最も適切なものはどれか。
- アCDNやDDoS対策専用サービスの利用により、攻撃トラフィックを分散・吸収させる方法が有効である
- イ特定の脆弱性を悪用してサーバに侵入し、データを窃取することを目的とする攻撃である
- ウDDoS攻撃への対策は、サーバのCPUやメモリを増強することのみで十分である
- エSYNフラッド攻撃は、TCPの3ウェイハンドシェイクを悪用せず、UDPパケットの送信のみによって行われる攻撃である
DDoS攻撃対策としては、攻撃元を分散できないという特性を踏まえ、CDNやクラウド型のDDoS対策サービスを利用して、大量のトラフィックを地理的に分散したエッジ側で吸収・フィルタリングする方法が有効です。
イのようにデータ窃取を目的とするのは誤りで、DDoS攻撃は可用性の低下（サービス停止）を目的とします。エもSYNフラッド攻撃の説明が誤りで、まさにTCPの3ウェイハンドシェイクを悪用する攻撃です。
DDoS対策は「CDN・専用対策サービスによるトラフィックの分散・吸収」が基本です。SYNフラッド・UDPフラッド・DNSリフレクション攻撃など攻撃手法ごとの仕組みもセットで覚えましょう。
📄 ケース
某社が運営するECサイトは、ある日突然、通常の100倍以上の規模のHTTPリクエストを短時間に受信し、Webサーバの応答が極端に遅くなり、正規の利用者がサイトにアクセスできない状態になった。調査の結果、多数の踏み台となった機器（ボットネット）から分散的にリクエストが送信されていたことが判明した。某社は当時、オンプレミスのWebサーバのみで運用しており、外部のDDoS対策サービスは導入していなかった。
設問：今後同様の被害を防ぐために整備すべき対策を、その理由も含めて40字以内で述べよ。
「CDNやクラウド型のDDoS対策サービスを導入し、大量のトラフィックを分散・吸収できる構成に変更する」
DDoS攻撃は多数の分散した送信元から大量のトラフィックを送り込むため、オンプレミスの限られた回線・サーバ容量だけでは処理しきれません。CDN等を介して攻撃トラフィックをエッジ側で吸収・フィルタリングし、正規のリクエストのみをオリジンサーバに到達させます。
「サーバの台数を増やす」のみでは、攻撃規模がそれを上回れば同様の被害が再発するため、根本対策としては不十分です。「CDN」「DDoS対策サービス」「トラフィックの分散・吸収」というキーワードが採点上の核心です。
DDoS攻撃対策の基本は、自社の限られたインフラ容量で受け止めようとするのではなく、外部のCDN／専用対策サービスを介して攻撃トラフィックを「自社の手前で」分散・吸収する構成にすることです。
コメント