収録問題 60問 ／ 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ライフサイクル管理では、入退社や異動と権限変更を連動し、不要アカウント削除、定期棚卸し、ログ監視を実施します。
大量のobjectを暗号化しており、master keyをrotationしても全objectを再暗号化したくない。適切な鍵管理方式はどれですか？
答え： objectごとのdata encryption keyを使い、その鍵だけをmaster keyで包むenvelope encryption
envelope encryptionではdata本体をDEKで暗号化し、DEKをKEKで暗号化します。KEK rotation時は包まれたDEKを再保護すればよく、data全体の再暗号化を避けられます。
AES-GCMを使う実装で、同じ鍵とnonceの組合せを再利用していた。最も重要な修正はどれですか？
答え： 同一鍵ではnonceを一意にし、生成・保存方法を設計して再利用を防ぐ
GCMで同一key・nonceを再利用すると機密性と認証の安全性が崩れます。十分な長さのnonceを一意に管理し、tag検証失敗時はdataを使用しません。
社内APIでserverだけでなくclient workloadのidentityもcertificateで検証したい。適切な方式はどれですか？
答え： mutual TLS（mTLS）
mTLSは双方がcertificateを提示・検証し、通信暗号化に加えてworkload間の相互認証を実現します。certificate発行・失効・rotationの運用も必要です。
mobile applicationのOAuth 2.0認可code flowで、横取りされたauthorization codeの悪用を防ぎたい。追加すべき仕組みはどれですか？
答え： PKCEのcode verifierとcode challenge
PKCEは認可request時のchallengeとtoken交換時のverifierを結び付け、codeだけを奪った攻撃者による交換を防ぎます。redirect URIの厳密照合も必要です。
production databaseへの特権接続を、ticket承認された作業時間だけ許可し、sessionを記録したい。適切な構成はどれですか？
答え： PAMでjust-in-time権限、credential vault、session recordingを統合する
PAMは特権credentialを分離保管し、承認・時間制限・操作記録を組み合わせてstanding privilegeと責任追跡のriskを下げます。
外部入力をそのままJavaのobject deserializationへ渡すAPIがあり、任意code実行が懸念される。根本的な対策はどれですか？
答え： 安全なdata形式へ変更し、許可する型とschemaを限定して危険なnative deserializationを避ける
untrusted deserializationではgadget chain等によりcode実行され得ます。単純なdata形式、厳格なschema、allowlist、更新済みlibraryを用い、不要なobject復元を避けます。
reverse proxyとbackendでHTTP request境界の解釈が異なり、後続requestが攻撃者入力として処理された。疑う攻撃はどれですか？
答え： HTTP request smuggling
request smugglingはfrontendとbackendのContent-LengthやTransfer-Encoding等の解釈差を悪用します。曖昧requestの拒否、protocol正規化、component更新が必要です。
侵害serverからinternetへの任意通信を防ぎ、必要な外部APIだけ許可したい。最も有効なnetwork controlはどれですか？
答え： egress firewallまたはproxyで宛先・portをallowlistし、DNSと通信logを監視する
egress controlはC2接続やdata持出し経路を制限します。業務上必要な宛先を管理し、proxy/DNS logで逸脱を検知します。
端末が長いsubdomainを高頻度で問い合わせ、応答data量も不自然に大きい。疑うべき活動と確認方法は？
答え： DNS tunnelingを疑い、query長・entropy・頻度・宛先domainとendpoint processを相関分析する
DNS tunnelingはsubdomain等へdataをencodeしてC2や持出しに使います。統計的特徴、既知domain、endpoint telemetryを組み合わせて判断します。
source code内のtainted input経路を開発中に検出し、稼働中Web applicationの認証やsession問題も外部から確認したい。組合せは？
答え： SASTとDASTを併用する
SASTはcode構造やdata flowを、DASTは稼働systemの外部挙動を検査します。SCA、manual review、penetration test等もriskに応じて組み合わせます。
設計段階で「攻撃者がどの資産を、どのtrust boundary越しに、どう悪用するか」を整理したい。適切な活動は？
答え： data flow diagramとSTRIDE等を使うthreat modeling
threat modelingは資産、主体、data flow、trust boundary、abuse case、mitigationを設計中に明確化し、手戻りが小さい段階で対策します。
CI pipelineからcloudへdeployする際、長期access keyをsecretへ保存せず認証したい。適切な方式は？
答え： OIDC federationでrepository・branch等のclaimを検証し、短期credentialを発行する
workload identity federationはCIのOIDC tokenをcloud側で検証して短期credentialへ交換します。audience、subject、branch、environmentを条件に最小権限化します。
侵害が疑われる稼働serverを調査する。電源断で失われる可能性が高く、disk imageより先に取得すべき情報は？
答え： memory、process、network connection、logged-on session等の揮発性情報
order of volatilityを考慮し、memory内artifactや通信状態を先に保全します。ただし被害拡大とのtrade-offをincident commanderと判断し、取得手順を記録します。
複数端末でransomware実行を確認し、domain administrator credential侵害も疑われる。初期封じ込めとして適切なのは？
答え： 感染端末と影響segmentを隔離し、侵害credentialを安全な経路で失効・rotationし、backupと重要serverを保護する
ransomwareでは横展開、credential悪用、backup破壊を同時に抑えます。隔離範囲と業務影響を調整し、安全な管理端末・accountから対応します。
forensic imageを外部調査会社へ引き渡す際、証拠の同一性と取扱履歴を示すために必要なものは？
答え： 取得・複製時hash、日時、担当者、保管場所、引渡し記録を含むchain of custody
chain of custodyは誰がいつ何をどの状態で扱ったかを連続的に記録し、hashで複製の完全性を検証します。分析は原則として検証済みcopyで行います。
複数cloud accountで、監査log停止やpublic storage作成を組織全体として禁止したい。適切な設計は？
答え： organization-level guardrailまたはSCPで禁止し、central monitoringで違反試行を検知する
組織levelのpreventive guardrailで危険操作を拒否し、logを分離accountへ集約すると、各account管理者からも変更しにくい統制になります。
cloud VM上のWeb applicationにSSRF脆弱性がある場合、instance metadataからcredentialを盗まれるriskを下げる対策は？
答え： metadata serviceのsession token必須化・hop制限、egress制御、workload roleの最小権限
SSRF対策はapplication側の宛先検証に加え、metadata service保護とrole最小権限を重ねます。単一対策が破られてもcredential取得と悪用範囲を抑えます。
administratorが侵害された場合でもsecurity logの削除・改ざんを困難にしたい。適切な保管設計は？
答え： 分離accountへ転送し、append-onlyまたはWORM retentionと限定された削除権限を適用する
logを管理domainから分離し、immutability、retention lock、最小権限、時刻同期を適用すると、侵害者による証拠隠滅へ耐性を持たせられます。
SIEM ruleが大量の誤検知を出し、analystが重要alertを見落としている。改善方法として適切なのは？
答え： 検知目的とdata品質を確認し、asset重要度・利用者・baseline等で条件を調整して測定を続ける
detection engineeringではuse case、telemetry、threshold、contextを調整し、true/false positive、coverage、対応時間を測って継続改善します。
新serviceの残余riskを受容する判断をsecurity担当者一人に求められた。適切な進め方は？
答え： 事業影響と代替策を示し、権限を持つrisk ownerが期限・条件付きで正式承認する
risk acceptanceは影響を負う事業側の権限者が、評価結果、代替案、条件、期限を理解して承認します。security担当は分析と助言を行います。