Question 1

システム開発において、セキュリティ対策を要件定義や設計の段階から組み込む考え方(セキュリティ・バイ・デザイン)が重視される理由として、最も適切なものはどれか。

Accepted Answer

後工程や運用開始後に脆弱性を修正する方が、手戻りの範囲や修正コストが大きくなりやすいため。【解説】セキュリティ上の不備は、要件定義や設計の段階で作り込まれることが多いにもかかわらず、開発の後工程やシステムの運用開始後に発見されるほど、修正に伴う手戻りの範囲や改修コスト、リリース遅延のリスクが大きくなる傾向がある。そのため、要件定義・設計の段階からセキュリティ要件を組み込む「セキュリティ・バイ・デザイン」の考え方が重視されている。【他の選択肢が不適切な理由】要件定義段階でのセキュリティ検討が開発期間を必ず大幅に短縮するという因果関係は成り立たない。セキュリティを設計段階で組み込んだとしても、実装の誤りは生じうるためテスト工程を省略できるわけではない。要件定義段階の検討が工数見積もりにしか影響しないという主張は誤りであり、実際にはこの段階での検討不足こそが後工程での脆弱性の作り込みにつながりやすい。

Question 2

システムの設計段階で、想定される脅威を体系的に洗い出す「脅威モデリング」の手法の1つであるSTRIDEが分類する脅威の例として、最も適切なものはどれか。

Accepted Answer

なりすまし・改ざん・情報漏えいなど、6つの観点で脅威を体系的に分類する手法。【解説】STRIDEは、なりすまし(Spoofing)、改ざん(Tampering)、否認(Repudiation)、情報漏えい(Information Disclosure)、サービス拒否(Denial of Service)、権限昇格(Elevation of Privilege)という6つの観点から、システムに想定される脅威を体系的に分類・洗い出すための脅威モデリング手法である。設計段階でこうした観点から脅威を検討することで、対策の抜け漏れを減らすことができる。【他の選択肢が不適切な理由】脆弱性を発生確率と影響度の2軸で数値化する手法はリスクアセスメントの考え方であり、設計段階であらかじめ脅威の種類を体系的に分類するSTRIDEとは異なる。既知の脆弱性情報とソースコードを突き合わせる手法は脆弱性スキャンやSCA(Software Composition Analysis)に近い実装後の検査手法であり、設計段階で脅威を洗い出すSTRIDEとは異なる。通信ログのみを対象とした異常検知はネットワーク監視の手法であり、システムの設計に内在する脅威を分類するSTRIDEとは異なる。

Question 3

ソースコードを実行せずに解析し、脆弱性の可能性がある記述を検出する手法「静的解析(SAST)」の説明として、最も適切なものはどれか。

Accepted Answer

ソースコードを走査し、既知の危険なパターンや不適切な実装を検出する解析手法。【解説】静的解析(SAST:Static Application Security Testing)は、プログラムを実行することなくソースコードやバイトコードそのものを走査し、SQLインジェクションにつながりやすい実装や、危険な関数の利用など、既知の危険なパターンや不適切な記述を検出する手法である。開発の早い段階(コーディング時やビルド時)から脆弱性を発見できる点が特徴である。対して動的解析(DAST)は、実際にシステムを動作させながら外部から擬似的な攻撃を行い、実行時の挙動から脆弱性を検出する手法である。【他の選択肢が不適切な理由】システムを稼働させ外部から擬似攻撃を行う手法は動的解析(DAST)の説明であり、静的解析とは異なる。ネットワーク上の通信を収集して内容を解析する手法はパケットキャプチャ等の通信解析であり、ソースコードそのものを走査する静的解析とは異なる。稼働中のログを収集し相関分析によって攻撃の兆候を検知する手法はSIEM等による監視の考え方であり、開発中のソースコードを解析する静的解析とは異なる。

Question 4

システム開発で利用するオープンソースソフトウェア(OSS)や外部ライブラリに含まれる既知の脆弱性を管理する取り組みとして、最も適切なものはどれか。

Accepted Answer

利用ライブラリの構成とバージョンを把握し、脆弱性公開時に速やかに更新する取り組み。【解説】OSSや外部ライブラリにも脆弱性が発見されることがあり、それを組み込んだシステムがそのまま影響を受ける。対策として、SCA(Software Composition Analysis)ツール等を用いて利用しているライブラリの構成・バージョンを継続的に把握し、脆弱性情報(CVE等)が公開された際に速やかに影響範囲を確認し、修正版へ更新する体制を整えることが重要である。【他の選択肢が不適切な理由】開発完了後にバージョン確認を一切行わない方針は、公開後に発見された脆弱性への対応が遅れ、既知の脆弱性を放置することになる。OSSが無償であることと脆弱性管理の要否は無関係であり、有償・無償を問わず脆弱性管理は必要である。ライブラリ名を秘密にしても、実際の脆弱性の有無が変わるわけではなく、対策として意味をなさない。

Question 5

セキュアコーディングにおける基本原則の1つ「外部からの入力はすべて信頼しない」という考え方に基づく実装として、最も適切なものはどれか。

Accepted Answer

受け取った値を、想定する形式・範囲・型に合致するか検証してから処理に用いる。【解説】セキュアコーディングの基本原則の1つに「外部からの入力はすべて信頼しない」という考え方があり、利用者の入力やAPI経由で受け取った値、外部システムから渡されるデータなどを、想定する形式・文字種・範囲・型に合致しているかを検証(バリデーション)したうえで処理に用いることが求められる。この検証を怠ることが、インジェクション系の脆弱性など多くの攻撃を許す原因となる。【他の選択肢が不適切な理由】入力値を無条件に安全とみなす前提は、外部入力を信頼しないという原則と正反対である。内部生成値のみを検証し外部入力を省略することは、最も検証が必要な箇所を見落としている。処理速度の低下を理由に検証処理を実装しないことは、セキュリティを著しく損なう判断であり適切ではない。

Question 6

Webアプリケーションのエラーメッセージの設計に関するセキュリティ上の注意点として、最も適切なものはどれか。

Accepted Answer

利用者には簡潔な案内のみ表示し、詳細情報はログにのみ記録するようにする。【解説】エラーメッセージに、プログラムの内部構造を示すスタックトレースや実行されたSQL文、サーバーのパス情報などを詳細に表示してしまうと、攻撃者に脆弱性の手がかりを与えることになる。利用者向けの画面には簡潔で一般的な案内のみを表示し、原因調査に必要な詳細情報は開発者・運用者のみが参照できるログに記録するという設計が、セキュリティ上望ましい。【他の選択肢が不適切な理由】本番環境で詳細なスタックトレースを利用者へ表示することは、内部構造の手がかりを外部に与えてしまう。データベースの接続文字列やパスワードをエラーメッセージに含めることは、重大な情報漏えいに直結する。エラー発生時の記録を一切行わないことは、原因調査やインシデント対応を困難にする。

Question 7

URLに含まれるIDを他の値に書き換えることで、本来アクセス権限のない他の利用者のデータを閲覧できてしまう不具合(認可制御の実装漏れ)を防ぐための対策として、最も適切なものはどれか。

Accepted Answer

リクエストされたデータが、ログイン中の本人のものかをサーバー側で必ず検証する。【解説】この不具合はIDOR(Insecure Direct Object References、安全でない直接オブジェクト参照)と呼ばれ、URLやパラメータのIDを操作するだけで他人のデータへアクセスできてしまう認可制御の実装漏れが原因である。対策としては、リクエストされたデータが、認証済みのログイン利用者本人がアクセス権限を持つものかどうかを、サーバー側で必ず検証する処理を実装することが必要である。【他の選択肢が不適切な理由】IDの桁数を増やすだけでは推測されにくくなる効果はあっても、権限確認自体を行わない限り、IDを知られた場合の不正アクセスは防げない。ログイン機能自体を廃止することは、認可制御の問題を回避するどころか誰でもアクセスできる状態を招く。クライアント側の表示制御のみでは、サーバー側へ直接リクエストを送ることで容易に回避されてしまう。

Question 8

システム開発のテスト工程で、本番環境から抽出した個人情報を含むデータをテスト環境で利用する場合の対応として、最も適切なものはどれか。

Accepted Answer

データマスキングを施すか、テストに必要な範囲のダミーデータへ置き換えて利用する。【解説】テスト工程で本番環境の個人情報を含むデータをそのまま利用すると、テスト環境からの情報漏えいリスクが生じる。可能な限りデータマスキングを施したり、実データを模したダミーデータに置き換えたりしてテストを行うことが望ましい。やむを得ず実データを利用する場合も、必要最小限の範囲に限定し、アクセス制御や利用後の確実な削除を徹底する必要がある。【他の選択肢が不適切な理由】個人情報を制限なく全開発者・外部委託先へ共有することは、目的外利用や漏えいのリスクを高める。テスト環境だからといってアクセス制御を不要とする方針は、本番データを扱う以上不適切である。複製の記録を残さない運用は、データの所在を追跡できなくなり管理上望ましくない。

Question 9

開発者が開発したプログラムを本番環境へ反映する際、不正な変更の混入を防ぐための体制として、最も適切なものはどれか。

Accepted Answer

コードレビューやリリース承認の工程を設け、開発者本人以外の確認を経て反映する。【解説】開発者が単独で本番環境への変更を反映できる体制では、意図的な不正コードの混入や意図しないミスの見落としに気づきにくい。コードレビューや、開発担当者以外の担当者によるリリース承認の工程を設けることで、変更内容を第三者の目で確認したうえで本番環境へ反映する体制(職務分掌)を整えることが、不正の混入や事故を防ぐうえで重要である。【他の選択肢が不適切な理由】開発担当者が単独ですべてを完結できる体制は、確認の目が入らず不正や誤りを見落としやすい。開発環境と本番環境を区別しないことは、テスト中の不具合が直接利用者へ影響するなど別のリスクを生む。リリース内容の記録を残さない運用は、問題発生時の原因追跡や責任の所在確認を困難にする。

Question 10

個人情報を取り扱うシステムを新たに開発する際、企画・設計段階で実施することが望ましい「プライバシー・バイ・デザイン」の考え方に基づく取り組みとして、最も適切なものはどれか。

Accepted Answer

収集する個人情報の項目と利用目的をあらかじめ最小限に絞り込み、リスクを評価する。【解説】プライバシー・バイ・デザインは、個人情報保護への配慮をシステムの企画・設計段階からあらかじめ組み込む考え方である。具体的には、収集する個人情報の項目や利用目的を業務上必要な範囲に最小限に絞り込み(データ最小化)、設計段階でプライバシーへの影響を評価(PIA:プライバシー影響評価)しておくことなどが挙げられる。【他の選択肢が不適切な理由】将来使うかもしれないという理由で目的を定めず個人情報を収集することは、目的外利用や漏えい時の被害拡大につながり、データ最小化の考え方に反する。運用開始後にまとめて検討する進め方は、設計段階からの組み込みを重視するプライバシー・バイ・デザインの趣旨に反する。項目を増やすほど良いという考え方も、データ最小化の原則に反する。

システム開発におけるセキュリティの一問一答