情報処理安全確保支援士
厳選10問ドリル｜午前II＋午後ミックス
JWT/API・IoT・メール運用（PPAP）・リスク分析・サブドメインテイクオーバーという実務頻出分野を潰します。
🪙 JWT・APIセキュリティ編
「JWTは暗号化されている」という誤解と、APIにも認証・認可が必要という当然だが見落とされがちな原則を押さえます。
クライアントが言っていることをそのまま信じない
JWTのヘッダに書かれた署名アルゴリズムも、APIへのリクエストも、クライアント側の情報をそのまま信用してはいけません。サーバ側で常に独立して検証・制御する、という発想が共通点です。
JWT（JSON Web Token）に関する記述のうち、最も適切なものはどれか。
- ア検証では、署名アルゴリズムをトークン内のヘッダ情報のみで決定するのではなく、サーバ側であらかじめ許可したアルゴリズムでの署名であることを確認する必要がある
- イペイロード部分は暗号化されているため、第三者がデコードして内容を読み取ることはできない
- ウ署名検証に成功すれば、トークンの有効期限（exp）を確認する必要はない
- エサーバ側でセッション情報を保持しないステートレスな認証を実現できるため、発行後は無効化させることが一切できない
JWTの検証では、ヘッダに記載された署名アルゴリズムをそのまま信用せず、サーバ側で許可されたアルゴリズムでの署名であることを確認する必要があります。これは「alg=none攻撃」のような、ヘッダの改ざんによる検証バイパスを防ぐための重要な実装上の注意点です。
イのように「暗号化されている」と思いがちですが、ペイロードはBase64URLエンコードされているだけで暗号化はされておらず、誰でもデコードできます。機密情報をペイロードに含めるべきではありません。
JWTのセキュリティ実装で最重要なのは「署名アルゴリズムをクライアント側のヘッダ情報に依存せず、サーバ側で固定・検証すること」です。ペイロードは平文同等であることも覚えておきましょう。
WebAPIのセキュリティに関する記述のうち、最も適切なものはどれか。
- アレート制限（リクエスト数の上限）を設けることで、過剰なリクエストによるリソース枯渇や、総当たり攻撃の試行回数を制限できる
- イAPIキーは、URLのクエリパラメータに平文で含めて送信することが最も安全な利用方法である
- ウ認証に成功した利用者であれば、すべてのエンドポイントへのアクセスを許可することが望ましい
- エWebAPIは画面を持たないため、認可制御を実装する必要がない
WebAPIにレート制限を設けることで、過剰なリクエストによるサーバリソースの枯渇や、認証情報の総当たり攻撃の試行回数を実効的に制限できます。
イのようにAPIキーをURLに平文で含めるのは、アクセスログ等を通じて漏えいするリスクが高く危険です。ウ・エのように認可制御を省略するのも誤りで、認証（誰か）と認可（何をしてよいか）は別の論点です。
WebAPIセキュリティの基本は「適切な認証・認可」「レート制限」「APIキー等の機密情報をURLに含めない」の3点セットです。
📡 IoTセキュリティ編
「初期パスワードのまま使われる」という運用面の問題が、技術的な脆弱性以上に深刻な被害を生んでいる実態を押さえます。
利用者に委ねるだけでは対策にならない
「パスワードを変更してください」という案内だけでは、多くの利用者が実行しません。仕組みとして変更を強制する設計が、実効性のある対策になります。
IoT機器のセキュリティに関する記述のうち、最も適切なものはどれか。
- アIoT機器は、工場出荷時に設定された共通の初期パスワードのまま利用されることが多く、これを悪用したボットネット化の被害が知られている
- イIoT機器のファームウェアは、一度導入すれば更新の必要がない設計が望ましい
- ウIoT機器は計算性能が限られるため、認証機能を一切持たせるべきではない
- エIoT機器に対するセキュリティ対策は、機器の購入者ではなく、常にメーカー側のみが負うべき責任である
多くのIoT機器は、工場出荷時の共通（または推測しやすい）初期パスワードのまま運用されることが多く、これを悪用して大量のIoT機器を乗っ取り、DDoS攻撃等に利用するボットネット（Miraiなど）の被害が広く知られています。
イのようにファームウェア更新が不要とするのは誤りで、IoT機器もソフトウェアの脆弱性が発見されるため更新の仕組みが必要です。エのように責任をメーカー側のみとするのも誤りで、利用者側にも初期パスワード変更等の責任があります。
IoTセキュリティの基本は「初期パスワードの変更」「ファームウェアの定期更新」「不要なサービス・ポートの無効化」。Miraiボットネットは初期パスワード問題の象徴的事例として頻出です。
📄 ケース
某社が製造・販売する家庭用ネットワークカメラは、工場出荷時に全製品共通の初期パスワード（admin/admin）が設定されており、利用者に対してパスワード変更を促す案内は同梱されていなかった。ある日、これらのカメラの多くが何者かに乗っ取られ、大規模なDDoS攻撃の踏み台（ボットネット）として悪用されていることが判明した。
設問：今後製造する製品において講じるべき対策を、その理由も含めて40字以内で述べよ。
「製品ごとに異なる初期パスワードを設定するか、初回起動時にパスワード変更を必須とする仕組みを導入する」
全製品共通の初期パスワードは、一度知られてしまえば同一製品すべてが一括で攻撃対象になります。製品ごとに異なる初期パスワードを設定するか、初回セットアップ時の変更を強制することで、共通パスワードによる大規模な乗っ取りを防止できます。
「利用者にパスワード変更を案内する」だけでは、案内を読まない・実行しない利用者が一定数残るため不十分です。「初回起動時の変更必須化」など、利用者の行動に依存しない仕組みレベルの対策が採点上の核心です。
IoT機器の共通初期パスワード問題は、Miraiボットネットに代表される大規模DDoS攻撃の主要な原因となった、実際に深刻な被害をもたらした典型的な設計ミスです。
📨 メール運用・PPAP問題編
「対策しているように見える」が実効性に乏しい運用と、単純な人的ミスがもたらす大規模漏えいを押さえます。
見た目のセキュリティ対策と、実効性のある対策を区別する
パスワード付きZIPも、ダブルチェックの運用注意も、「対策しているつもり」になりやすい典型例です。本当に有効なのは、ミスや漏えいを構造的に防ぐ仕組みです。
添付ファイルをパスワード付きZIPで暗号化し、パスワードを後続の別メールで送る運用（PPAP）に関する記述のうち、最も適切なものはどれか。
- アメールが盗聴・転送された場合、添付ファイルとパスワードの両方が同じ経路で漏えいするため、実効的な保護にならない
- イパスワード付きZIPファイルは、メールセキュリティ製品によるウイルスチェックの精度を一切損なわない
- ウ国際的な標準として広く推奨されているメールセキュリティのベストプラクティスである
- エ誤送信による情報漏えいを完全に防止できる
PPAPは、添付ファイルの暗号化パスワードを同じメール経路（多くは直後の別メール）で送るため、メールが盗聴・誤送信された場合、ファイルとパスワードの両方が同じ宛先に渡ってしまい、暗号化の効果が実質的に失われます。
イのようにウイルスチェックへの影響がないとするのは誤りで、暗号化されているため内容を検査できないという別の問題も引き起こします。ウのように国際標準のベストプラクティスとするのも誤りで、近年は廃止が進められています。
PPAPの問題点は「同一経路でのパスワード送付による保護の無効化」と「ウイルスチェックの困難化」の2点です。代替策はクラウドストレージでの共有やメール暗号化（S/MIME等）が挙げられます。
📄 ケース
某社の広報担当者は、セミナー参加者500名に案内メールを送付する際、本来は参加者のメールアドレスをBCC欄に入力すべきところを、誤ってTO（宛先）欄に全員のメールアドレスを入力して送信してしまった。これにより、参加者全員のメールアドレスが、他の参加者全員に閲覧可能な状態で開示されてしまった。
設問：今後同様の事案を防ぐために整備すべき対策を、その理由も含めて40字以内で述べよ。
「複数宛先への一斉送信が必要な場合は、メール配信システムを利用し、個別の宛先ごとに送信する仕組みに変更する」
TO/CC/BCCを人手で操作する運用は、ヒューマンエラーのリスクを常に伴います。一斉送信業務自体を、個別配信が前提の配信システムに置き換えることで、入力ミスによる漏えいの可能性を構造的に排除できます。
「送信前にダブルチェックする」という運用上の注意喚起のみでは、ヒューマンエラーを完全には防げません。「配信システムの導入」「送信前の自動チェック機能」など、仕組みレベルの対策がより高く評価されます。
TO/CC/BCCの誤りによる一斉送信時の情報漏えいは、技術的に高度な攻撃ではなく単純な人的ミスですが、実際のインシデントとして非常に頻発するパターンです。配信システムの利用が最も効果的な対策とされます。
📐 リスク分析・脆弱性開示編
リスクを金額で表す定量的分析と、報告者との適切なコミュニケーションが招く・防ぐ結果の違いを押さえます。
「無視する」ことが最悪の結果を招く
脆弱性報告への対応の遅れは、研究者を「公開せざるを得ない」状況に追い込みます。無対応こそが、未修正の脆弱性が世に出るきっかけになります。
定量的リスク分析に関する記述のうち、最も適切なものはどれか。
- アALE（年間予想損失額）は、ある脅威が1年間に発生する頻度（ARO）と、1回の発生で生じる損失額（SLE）を掛け合わせて算出する
- イ定量的リスク分析は、リスクを「高・中・低」のような相対的な尺度で評価する手法であり、金額で表すことはない
- ウALEを算出すれば、対策に投資すべき金額の上限を検討する必要はなくなる
- エリスクアセスメントにおいて、資産価値・脅威・脆弱性のいずれか一つだけを評価すれば十分である
ALE（Annualized Loss Expectancy）は、ARO（年間発生率）とSLE（単一損失予想額）を掛け合わせて算出する定量的リスク分析の代表的な指標です（ALE＝SLE×ARO）。
イのように「高・中・低」の相対評価とするのは定性的リスク分析の説明であり、定量的リスク分析はまさに金額で表す手法です。エも3要素のうち一つだけでよいとする点が誤りです。
ALE＝SLE（単一損失予想額）×ARO（年間発生率）。この算出式と、対策コストとの比較（ALEを上回るコストの対策は投資効果が薄い）という考え方をセットで覚えましょう。
📄 ケース
某セキュリティ研究者は、某社が提供するWebサービスに重大な脆弱性を発見し、某社の公開している問い合わせ窓口へ詳細を報告した。しかし、某社からは1か月以上にわたって返信がなく、脆弱性が修正される見込みも示されなかった。研究者は、利用者への注意喚起のため、詳細な技術情報を含めてSNS上で脆弱性を公開した。その結果、某社が対応を完了する前に、攻撃者がその情報を悪用し、複数の利用者に被害が生じた。
設問：このような事態を防ぐために、某社が整備すべき仕組みを、その理由も含めて40字以内で述べよ。
「脆弱性報告の受付窓口を明確化し、報告から一定期間内に状況を回答する対応プロセスを整備する」
報告への応答がない状態が続くと、研究者が「公開せざるを得ない」と判断し、未修正の脆弱性情報が公開され攻撃者に悪用されるリスクが高まります。一定期間内の状況報告など、責任ある開示のプロセスを整備することが重要です。
「研究者からの報告を受け付けない」「法的措置を取る」のような対応は、研究者との関係を悪化させ、むしろ脆弱性情報が無秩序に公開されるリスクを高めるため不適切です。「窓口の明確化」「対応プロセス・期限の整備」がキーワードです。
脆弱性報告への対応が遅れる、または無視されることは、結果的に「未修正の脆弱性情報が公開され、攻撃者に悪用される」という最悪のシナリオを招きます。責任ある開示の仕組みを整備することは、組織の脆弱性管理体制の重要な一部です。
🌐 サブドメインテイクオーバー・HTTPS化編
「削除し忘れたDNSレコード」が、自社の信頼性を悪用される入口になる構造を押さえます。
参照先が消えても、参照そのものは残る
クラウドリソースを削除しても、DNSレコードという「指し示す矢印」が残っていると、その先を第三者が乗っ取れることがあります。削除はワンセットで考えましょう。
HSTSおよびMixed Contentに関する記述のうち、最も適切なものはどれか。
- アHSTSは、Webブラウザに対して、当該サイトへの今後の通信を常にHTTPSで行うよう指示するレスポンスヘッダである
- イMixed Contentとは、HTTPSページ内でHTTPSのリソースのみを読み込んでいる状態のことであり、特に問題は生じない
- ウHSTSを設定すれば、サーバ証明書の管理（更新・失効確認）は一切不要になる
- エHTTPSページ内でHTTPのリソースを読み込んでも、ブラウザは警告を表示せず、セキュリティ上の問題はない
HSTSは、Webサーバがブラウザに対して「このサイトへの通信は今後常にHTTPSで行うこと」を指示するレスポンスヘッダです。これにより、HTTPでの初回アクセス時の盗聴・改ざんリスクを低減できます。
イのようにMixed ContentをHTTPSのみの読み込みと説明するのは誤りで、実際はHTTPSページ内にHTTPのリソースが混在する状態を指し、改ざんのリスクがあるため問題となります（説明が逆）。
HSTSは「常にHTTPSで通信させる」ための仕組み、Mixed Contentは「HTTPSページの中にHTTPのリソースが混在する」ことで生じるリスクです。両者をセットで、HTTPS化を徹底する際の注意点として覚えましょう。
📄 ケース
某社では、キャンペーン用に一時的にクラウドサービス上で構築したWebサイトを「campaign.example.co.jp」というサブドメインで公開していた。キャンペーン終了後、当該クラウドサービスのリソースは削除したが、DNSのCNAMEレコード（campaign.example.co.jp→クラウドサービスの提供するドメイン）の削除を忘れていた。数か月後、第三者が同じクラウドサービス上で同名のリソースを新たに取得し、当該サブドメインを使ってフィッシングサイトを公開する事案が発生した。
設問：このインシデントの根本原因と、再発防止のために整備すべき仕組みをそれぞれ30字以内で述べよ。
原因：「クラウドリソースの削除時に、対応するDNSレコードの削除を忘れていた」
対策：「クラウドリソースとDNSレコードの対応関係を一覧管理し、リソース削除時にDNSレコードも合わせて削除する手順を整備する」
DNS側のCNAMEレコードが残っていると、第三者が同名のリソースを新たに取得した場合、そのまま自社のサブドメインの参照先として悪用できてしまいます。
「定期的にDNSレコードを確認する」のような事後対応のみでは、削除忘れの発生自体を防げません。「リソース削除とDNSレコード削除を一体の手順として運用する」という、削除フローレベルの対策が採点上の核心です。
サブドメインテイクオーバーは、DNSレコードが参照先のクラウドリソース等よりも長く残ってしまうことで生じる典型的な設定不備です。自社の正規サブドメインがフィッシング等に悪用されるため、ブランドの信頼性にも大きな影響を与えます。
コメント