収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
大量データの暗号化に共通鍵暗号（AESなど）が向いている主な理由はどれですか？
答え： 公開鍵暗号より処理が高速である
共通鍵暗号は公開鍵暗号より高速で、大量データの暗号化に適します。鍵配送の課題は別途解決が必要です。
共通鍵を公開鍵暗号で安全に渡し、本文は共通鍵で高速に暗号化する方式はどれですか？
答え： ハイブリッド暗号方式
ハイブリッド暗号は鍵配送を公開鍵暗号で、本文の暗号化を共通鍵暗号で行い、安全性と速度を両立します。TLSでも用いられます。
ファイルが改ざんされていないかを検証するために用いる技術はどれですか？
答え： ハッシュ値（SHA-256など）の比較
ハッシュ値は入力が少しでも変わると大きく変化するため、配布前後のハッシュ比較で改ざんを検知できます。
共有鍵を用いてメッセージの完全性と送信者の正当性を同時に確認できる技術はどれですか？
答え： HMAC（鍵付きハッシュによるメッセージ認証）
HMACは共有鍵とハッシュ関数を組み合わせ、改ざん検知と送信者認証を同時に提供します。
ディジタル署名が提供するセキュリティ特性として適切なものはどれですか？
答え： 完全性・認証・否認防止
ディジタル署名は署名者の秘密鍵で作成し公開鍵で検証することで、完全性・認証・否認防止を実現します。
公開鍵とその持ち主の対応を第三者機関が保証する電子データはどれですか？
答え： ディジタル証明書（公開鍵証明書）
ディジタル証明書は認証局（CA）が発行し、公開鍵が確かに本人のものであることを保証します。
ディジタル証明書が失効していないかをオンラインで問い合わせて確認する仕組みはどれですか？
答え： OCSP
OCSPは証明書の失効状態をオンラインで問い合わせます。一覧形式で失効を配布するのがCRLです。
パスワードに加えてICカードや生体情報を組み合わせる認証方式はどれですか？
答え： 多要素認証
多要素認証は知識・所持・生体など異なる要素を組み合わせ、単一要素の漏えいによる突破を防ぎます。
あるサービスに、別サービスのリソースへのアクセス権限を安全に委譲する仕組みはどれですか？
答え： OAuth 2.0
OAuth 2.0はパスワードを渡さずにアクセス権限（認可）を委譲する仕組みで、アクセストークンを用います。
企業内で一度の認証で複数のサービスを利用できるようにする仕組みはどれですか？
答え： シングルサインオン（SSO）
SSOは一度の認証で複数サービスを利用可能にします。SAMLやOpenID Connectが代表的な実現方式です。
フィッシングに強く、パスワードを使わずに公開鍵暗号で認証する方式はどれですか？
答え： FIDO2／パスワードレス認証
FIDO2は端末内の秘密鍵と公開鍵暗号で認証し、サーバにパスワードを送らないためフィッシング耐性が高い方式です。
Webページに不正なスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃はどれですか？
答え： クロスサイトスクリプティング（XSS）
XSSは入力値が適切にエスケープされない箇所に悪意あるスクリプトを混入させます。出力時のエスケープが基本対策です。
利用者がログイン状態のWebサイトに対し、意図しない操作を強制する攻撃はどれですか？
答え： クロスサイトリクエストフォージェリ（CSRF）
CSRFはログイン中の利用者に不正なリクエストを送らせます。トークン検証（CSRFトークン）などで防ぎます。
SQLインジェクションの根本的な対策として最も適切なものはどれですか？
答え： プレースホルダ（プリペアドステートメント）を使う
プレースホルダは入力値をデータとして扱い、SQL文の構造を変えさせないため根本的な対策になります。
「../」などを使い公開範囲外のファイルへ不正にアクセスする攻撃はどれですか？
答え： ディレクトリトラバーサル
ディレクトリトラバーサルはパス指定の検査不備を突き、想定外のファイルを参照します。入力の検証・正規化で防ぎます。
通信経路に割り込み、双方になりすまして通信を盗聴・改ざんする攻撃はどれですか？
答え： 中間者攻撃（MITM）
中間者攻撃は通信に割り込み盗聴・改ざんします。TLSによる暗号化と証明書検証が有効な対策です。
DNSサーバに偽の名前解決情報を覚え込ませ、利用者を偽サイトへ誘導する攻撃はどれですか？
答え： DNSキャッシュポイズニング
DNSキャッシュポイズニングは偽の応答をキャッシュさせ、利用者を悪意あるサイトへ誘導します。DNSSECが対策の一つです。
別サービスから流出したIDとパスワードの組を使い回し、不正ログインを試みる攻撃はどれですか？
答え： パスワードリスト攻撃
パスワードリスト攻撃は流出した認証情報を別サイトで使い回します。使い回しの回避と多要素認証が対策です。
セッションIDを格納するCookieの不正取得を防ぐ設定として適切なものはどれですか？
答え： Cookieに Secure 属性と HttpOnly 属性を付与する
Secure属性でHTTPS時のみ送信、HttpOnly属性でスクリプトからの読み取りを防ぎ、セッション窃取リスクを下げます。
WebブラウザとサーバのHTTP通信を暗号化し、なりすましや盗聴を防ぐプロトコルはどれですか？
答え： TLS
TLSは暗号化・サーバ認証・完全性を提供し、HTTPSの基盤になります。FTPやTelnetは平文通信です。
拠点間をインターネット経由で暗号化接続し、仮想的な専用線を構築する技術はどれですか？
答え： IPsec VPN
IPsec VPNはIP層で暗号化・認証を行い、拠点間を安全に接続します。
Webアプリへの攻撃（SQLインジェクションやXSSなど）を通信内容から検知・遮断する仕組みはどれですか？
答え： WAF（Web Application Firewall）
WAFはWebアプリ層の通信を検査し、典型的な攻撃パターンを検知・遮断します。
多数の機器のログを集約・相関分析し、セキュリティ上の異常を検知する仕組みはどれですか？
答え： SIEM
SIEMはログを一元的に収集・相関分析し、攻撃や異常の兆候を検知してインシデント対応を支援します。
セキュアコーディングで最も重視される基本的な対策はどれですか？
答え： 入力値の検証（バリデーション）を適切に行う
入力値検証は多くの脆弱性（インジェクション等）の根本対策です。エラーでの情報露出や過剰権限は避けます。
システムの企画・設計段階からセキュリティを組み込む考え方を表す用語はどれですか？
答え： セキュリティバイデザイン
セキュリティバイデザインは後付けでなく、設計初期からセキュリティを考慮して作り込む考え方です。
インシデント発生後、原因究明や証拠保全のためにログや記録媒体を解析する活動はどれですか？
答え： ディジタルフォレンジック
ディジタルフォレンジックは証拠の完全性を保ちながらログ等を解析し、原因究明や法的対応に役立てます。
セキュリティインシデント対応で、まず行うべき初動として適切なものはどれですか？
答え： 被害拡大を防ぐため影響範囲を把握し封じ込める
初動では検知後に影響範囲を把握し、封じ込めて被害拡大を防ぎます。証拠保全のためログ削除は避けます。
他人の識別符号を無断で使う行為や、脆弱性を突いた不正侵入を禁止する法律はどれですか？
答え： 不正アクセス禁止法
不正アクセス禁止法は、無断での識別符号利用やセキュリティホールを突いた侵入などを禁止しています。
社内端末で不審なPowerShellの実行や外部への通信が検知されました。侵害後の調査、端末の隔離、プロセスの停止に使う製品の分類はどれですか？
答え： EDR
EDRは端末上の挙動を継続的に記録・検知し、侵害時の調査、隔離、封じ込めを支援します。従来型のマルウェア検知だけでは追えない挙動の分析に使います。
境界型防御だけに依存せず、端末状態・利用者・アクセス先・リスクに応じて毎回アクセス可否を判断したい。採用する考え方はどれですか？
答え： ゼロトラスト
ゼロトラストは内外の境界で暗黙に信頼せず、認証、認可、端末健全性、状況などを継続的に評価してアクセスを制御します。
公開サーバの脆弱性対応で、CVSSの値だけでなく、外部に公開されているか、悪用コードが出回っているかも踏まえて優先順位を決めたい。適切な進め方はどれですか？
答え： 資産重要度・露出・悪用可能性を含めてリスクベースで優先順位を付ける
実務ではCVSSに加え、資産の重要度、インターネット露出、悪用状況、代替策、業務影響を見て優先順位を決めます。無検証適用も放置もリスクがあります。
クラウド環境で、長期アクセスキーをアプリに埋め込まず、一時的な認証情報で権限を委任したい。基本方針として適切なのはどれですか？
答え： ワークロード用のロールを使い、一時認証情報を自動取得させる
クラウドのIAMでは、ワークロードにロールを割り当てて一時認証情報を使わせると、長期キー漏えいリスクを下げられます。最小権限も併せて設計します。
コンテナイメージに含まれる既知脆弱性を本番投入前に検出したい。CI/CDで組み込む対策として適切なのはどれですか？
答え： イメージスキャンを実行し、重大度や悪用可能性に応じてデプロイを止める
コンテナ運用では、イメージスキャン、ベースイメージ更新、署名検証、最小権限実行などをCI/CDに組み込み、リリース前にリスクを下げます。
利用しているOSSライブラリとバージョンを把握し、脆弱性発覚時に影響範囲を素早く特定したい。整備するものはどれですか？
答え： SBOM
SBOMはソフトウェア部品表で、利用コンポーネント、バージョン、依存関係などを把握し、サプライチェーンリスク管理に役立ちます。
APIで、利用者が指定した任意のURLへサーバがアクセスできる実装にしたところ、内部管理画面へ到達されるリスクがある。この脆弱性はどれですか？
答え： SSRF
SSRFは攻撃者がサーバに任意のリクエストを送らせ、内部ネットワークやメタデータサービスなどへ到達させる攻撃です。許可リストや内部宛て遮断が有効です。
自社ドメインを詐称したメールをどう扱うか（検知・拒否）の方針を受信側へ伝えたい。SPFやDKIMの認証結果を利用するこの仕組みはどれですか？
答え： DMARC
DMARCはSPFやDKIMの結果を基に、認証失敗メールの扱い方をドメイン所有者がポリシーとして公開し、なりすまし対策に使います。
インシデント調査に備え、ログの証拠能力を高めるための運用として適切なのはどれですか？
答え： 時刻同期を行い、改ざんされにくい場所へ必要期間保管する
ログは時刻同期、完全性保護、アクセス制御、保管期間、集中管理を整えることで、事後調査や監査で利用しやすくなります。
ランサムウェアに備えたバックアップ設計で、復旧可能性を高める実務上の対策はどれですか？
答え： 世代管理し、攻撃者が変更しにくいオフラインまたはイミュータブル領域にも保管する
ランサムウェア対策では、複数世代、オフラインまたはイミュータブル保管、権限分離、定期的な復元テストが重要です。
重要業務を外部SaaSへ移行する前に、可用性、ログ取得、データ削除、障害時連絡などを確認したい。適切な管理活動はどれですか？
答え： クラウドサービス利用時のリスク評価と委託先管理
SaaS利用では、契約、SLA、監査ログ、データ保護、削除・返却、インシデント連絡、委託先の統制状況を確認してリスクを管理します。
退職者のアカウントが残り、VPNへログインできる状態だった。再発防止として最も適切な管理はどれですか？
答え： 人事イベントと連動したアカウント無効化、定期棚卸し、権限レビューを行う
IDライフサイクル管理では、入退社や異動と権限変更を連動し、不要アカウント削除、定期棚卸し、ログ監視を実施します。
大量のオブジェクトを暗号化しています。マスターキーをローテーションしても、すべてのオブジェクトを再暗号化したくありません。適切な鍵管理方式はどれですか？
答え： オブジェクトごとのデータ暗号鍵を使い、その鍵だけをマスターキーで包むエンベロープ暗号化
エンベロープ暗号化ではデータ本体をDEKで暗号化し、DEKをKEKで暗号化します。KEKローテーション時は包まれたDEKを再保護すればよく、データ全体の再暗号化を避けられます。
AES-GCMを使う実装で、同じ鍵とナンス（nonce）の組み合わせを再利用していました。最も重要な修正はどれですか？
答え： 同一鍵ではnonceを一意にし、生成・保存方法を設計して再利用を防ぐ
GCMで同一キー・nonceを再利用すると機密性と認証の安全性が崩れます。十分な長さのnonceを一意に管理し、タグ検証失敗時はデータを使用しません。
社内APIで、サーバだけでなく呼び出し元のワークロードの身元も証明書で検証したい。適切な方式はどれですか？
答え： mutual TLS（mTLS）
mTLSは双方がcertificateを提示・検証し、通信暗号化に加えてワークロード間の相互認証を実現します。certificate発行・失効・ローテーションの運用も必要です。
モバイルアプリのOAuth 2.0認可コードフローで、横取りされた認可コードを悪用されないようにしたい。追加すべき仕組みはどれですか？
答え： PKCEのcode verifierとcode challenge
PKCEは認可リクエスト時のchallengeとトークン交換時のverifierを結び付け、コードだけを奪った攻撃者による交換を防ぎます。redirect URIの厳密照合も必要です。
本番データベースへの特権接続を、チケットで承認された作業時間だけ許可し、操作内容も記録したい。適切な構成はどれですか？
答え： PAMでjust-in-time権限、認証情報の保管庫、セッション記録を統合する
PAMは特権認証情報を分離保管し、承認・時間制限・操作記録を組み合わせてstanding privilegeと責任追跡のリスクを下げます。
外部からの入力をそのままJavaのオブジェクトのデシリアライズに渡すAPIがあり、任意のコードを実行される恐れがあります。根本的な対策はどれですか？
答え： 安全なデータ形式へ変更し、許可する型とスキーマを限定して危険なnative deserializationを避ける
untrusted deserializationではgadget chain等によりコード実行され得ます。単純なデータ形式、厳格なスキーマ、allowlist、更新済みライブラリを用い、不要なオブジェクト復元を避けます。
リバースプロキシとバックエンドでHTTPリクエストの境界の解釈が異なり、後続のリクエストが攻撃者の入力として処理されました。疑うべき攻撃はどれですか？
答え： HTTP request smuggling
request smugglingはfrontendとバックエンドのContent-LengthやTransfer-Encoding等の解釈差を悪用します。曖昧リクエストの拒否、プロトコル正規化、コンポーネント更新が必要です。
侵害されたサーバからインターネットへ自由に通信できないようにし、必要な外部APIだけを許可したい。最も有効なネットワーク制御はどれですか？
答え： egress firewallまたはプロキシで宛先・portをallowlistし、DNSと通信ログを監視する
egress controlはC2接続やデータ持出し経路を制限します。業務上必要な宛先を管理し、proxy/DNSログで逸脱を検知します。
ある端末が長いサブドメイン名を高い頻度で問い合わせており、応答のデータ量も不自然に大きい。疑うべき活動と確認方法はどれですか？
答え： DNS tunnelingを疑い、クエリ長・entropy・頻度・宛先ドメインとエンドポイントプロセスを相関分析する
DNS tunnelingはsubdomain等へデータをencodeしてC2や持出しに使います。統計的特徴、既知ドメイン、エンドポイントテレメトリを組み合わせて判断します。
開発中にソースコード内の汚染された入力の経路を検出し、稼働中のWebアプリケーションの認証やセッションの問題も外部から確認したい。適切な組み合わせはどれですか？
答え： SASTとDASTを併用する
SASTはコード構造やデータフローを、DASTは稼働システムの外部挙動を検査します。SCA、手動レビュー、ペネトレーションテスト等もリスクに応じて組み合わせます。
設計段階で「攻撃者がどの資産を、どの信頼境界を越えて、どう悪用するか」を整理したい。適切な活動はどれですか？
答え： データ flow diagramとSTRIDE等を使う脅威モデリング
脅威モデリングは資産、主体、データフロー、信頼境界、悪用ケース、緩和策を設計中に明確化し、手戻りが小さい段階で対策します。
CIパイプラインからクラウドへデプロイするとき、長期のアクセスキーをシークレットとして保存せずに認証したい。適切な方式はどれですか？
答え： OIDCフェデレーションでリポジトリ・ブランチ等のクレームを検証し、短期認証情報を発行する
ワークロードIDフェデレーションはCIのOIDCトークンをクラウド側で検証して短期認証情報へ交換します。オーディエンス、サブジェクト、ブランチ、環境を条件に最小権限化します。
侵害が疑われる稼働中のサーバを調査します。電源を切ると失われる可能性が高いため、ディスクイメージより先に取得すべき情報はどれですか？
答え： メモリ、プロセス、ネットワーク接続、ログオン中のセッション等の揮発性情報
order of volatilityを考慮し、メモリ内アーティファクトや通信状態を先に保全します。ただし被害拡大とのトレードオフをインシデントコマンダーと判断し、取得手順を記録します。
複数の端末でランサムウェアの実行を確認し、ドメイン管理者の認証情報の侵害も疑われます。初期の封じ込めとして適切なのはどれですか？
答え： 感染端末と影響segmentを隔離し、侵害認証情報を安全な経路で失効・ローテーションし、バックアップと重要サーバーを保護する
ランサムウェアでは横展開、認証情報悪用、バックアップ破壊を同時に抑えます。隔離範囲と業務影響を調整し、安全な管理端末・アカウントから対応します。
フォレンジックイメージを外部の調査会社へ引き渡します。証拠が同一であることと取り扱いの履歴を示すために必要なものはどれですか？
答え： 取得・複製時ハッシュ、日時、担当者、保管場所、引渡し記録を含むchain of custody
chain of custodyは誰がいつ何をどの状態で扱ったかを連続的に記録し、ハッシュで複製の完全性を検証します。分析は原則として検証済みcopyで行います。
複数のクラウドアカウントで、監査ログの停止や公開ストレージの作成を組織全体として禁止したい。適切な設計はどれですか？
答え： organization-level guardrailまたはSCPで禁止し、central monitoringで違反試行を検知する
組織レベルのpreventive guardrailで危険操作を拒否し、ログを分離アカウントへ集約すると、各アカウント管理者からも変更しにくい統制になります。
クラウドのVM上のWebアプリケーションにSSRF脆弱性があります。インスタンスメタデータから認証情報を盗まれるリスクを下げる対策はどれですか？
答え： メタデータサービスのセッショントークン必須化・ホップ制限、egress制御、ワークロードのロールの最小権限
SSRF対策はアプリケーション側の宛先検証に加え、メタデータサービス保護とロール最小権限を重ねます。単一対策が破られても認証情報取得と悪用範囲を抑えます。
管理者アカウントが侵害された場合でも、セキュリティログの削除や改ざんを困難にしたい。適切な保管設計はどれですか？
答え： 分離アカウントへ転送し、append-onlyまたはWORM 保持と限定された削除権限を適用する
ログを管理ドメインから分離し、immutability、保持ロック、最小権限、時刻同期を適用すると、侵害者による証拠隠滅へ耐性を持たせられます。
SIEMのルールが大量の誤検知を出し、アナリストが重要なアラートを見落としています。改善方法として適切なのはどれですか？
答え： 検知目的とデータ品質を確認し、asset重要度・利用者・baseline等で条件を調整して測定を続ける
detection engineeringではuse case、テレメトリ、threshold、コンテキストを調整し、true/false positive、coverage、対応時間を測って継続改善します。
新サービスの残余リスクを受容するかどうかの判断を、セキュリティ担当者1人に求められました。適切な進め方はどれですか？
答え： 事業影響と代替策を示し、権限を持つリスクオーナーが期限・条件付きで正式承認する
リスク受容は影響を負う事業側の権限者が、評価結果、代替案、条件、期限を理解して承認します。セキュリティ担当は分析と助言を行います。
請求書APIではログインを確認していますが、URLの請求書IDを変更すると他社の請求書も取得できました。再発防止の中核はどれですか？
答え： 取得時に利用者の所属と対象請求書の権限を照合する
認証は利用者が誰かを確認しますが、その請求書を読めるかは別の認可判断です。サーバー側で毎回、信頼できる利用者情報と対象の所属・権限を照合し、他社IDに差し替える回帰テストも追加します。
同じ認証基盤が発行するJWTを使うAPI AとAPI Bがあります。API Bが署名と有効期限だけを確認したため、API A専用のトークンも受理しました。追加すべき検証はどれですか？
答え： 想定する発行者と、API Bを示す宛先を照合する
JWTの署名が正しくても、別のAPI向けに発行されたトークンかもしれません。信頼する発行者issと自APIを含む宛先audを検証し、許可した署名方式や有効期間の検証と組み合わせます。
ログイン前のセッションIDがログイン成功後も変わりません。他人に知られたログイン前のIDが、認証後の操作に使われる危険への対策はどれですか？
答え： 認証成功時にIDを再発行し、旧IDの認証利用を無効にする
これはセッション固定攻撃につながる設計です。認証など権限が変化する時点でセッションIDを更新し、古いIDでは認証済み状態を利用できなくします。Cookieの保護属性も必要ですが、ID更新の代わりにはなりません。
応募書類のアップロード機能が、送信されたContent-Typeがapplication/pdfならそのまま公開しています。改善案として最も適切なのはどれですか？
答え： 許可形式と内容を検査し、公開前は非公開領域に保管する
Content-Typeは送信者が指定できるため、PDFである証明にはなりません。許可する拡張子・実際の形式・サイズ・内容を多層で検査し、必要なマルウェア検査等が終わるまで公開しない構成にします。単一の検査で安全が保証されるわけではありません。
パスワード再設定URLは十分長い乱数ですが、変更完了後も同じURLで再度変更でき、期限もありません。追加すべき制御はどれですか？
答え： 有効期限を設け、変更成功時にトークンを使用済みにする
推測困難性と再利用防止は別の要件です。サーバーで期限と未使用状態を確認し、パスワード更新とトークン消費を一体的に処理して、同時要求でも複数回使えないようにします。
プロフィール更新APIが、受信したJSONの全項目を利用者レコードへ自動反映しています。画面にない管理者フラグまで変更されないようにする対策はどれですか？
答え： 更新を許す項目だけ受け取り、権限項目は別に管理する
一括代入の脆弱性では、画面にない項目も直接要求に含められます。プロフィール用の入力モデルに編集可能項目だけを定義し、管理者権限などは権限確認を伴う別の処理で変更します。
管理APIの認証を省き、CORSで自社の画面だけを許可しました。curlなどブラウザ以外からも操作できる状態です。必要な修正はどれですか？
答え： 各API要求で利用者を認証し、管理操作の権限を検証する
CORSはブラウザの別オリジンからの応答読み取り等を制御する仕組みで、API利用者の認証・認可ではありません。ブラウザ以外のクライアントにも通用する認証と、操作単位の権限確認をサーバーで実施します。
本番用APIキーを公開リポジトリへ誤って登録し、数時間後に気付きました。ファイルから削除した後、優先して行うべき対応はどれですか？
答え： 漏えいキーを失効・交換し、そのキーの利用履歴を調査する
公開されたキーは、履歴・複製・外部取得先に残っている可能性があります。漏えいした認証情報として失効させ、安全な保管先で新しいキーへ切り替えます。利用記録から不正利用と影響範囲を調べ、履歴の清掃や再発防止も進めます。
支払通知のWebhookで署名は検証していますが、正規の同じ通知を繰り返し受け取ると残高が重複加算されます。再送も想定した対策はどれですか？
答え： 通知IDを保存し、処理済み判定と残高更新を一体化する
署名が正しいことと、未処理の通知であることは別です。送信元の安定した通知IDを利用し、重複判定と業務更新を原子的に処理して二重実行を防ぎます。署名対象の時刻による鮮度確認も補助になりますが、許容時間内の再送には重複排除が必要です。
利用者の表示名をHTML本文へ文字列連結して表示しており、CSPは補助的に導入済みです。表示名を装飾のない文字列として表示する場合、基本対策はどれですか？
答え： textContentなどを使い、表示名をHTMLとして解釈させない
文字列として表示する用途なら、textContentのような安全な出力先や文脈に適したエスケープを使います。CSPは多層防御であり、不正なHTML解釈を防ぐ実装の代替ではありません。装飾HTMLを許す別の用途では適切なサニタイズが必要です。