午前I問題

ソフトウェア開発においてセキュリティバイデザイン（Security by Design）を適用する主な目的はどれか。

ア）テスト工程で一括してセキュリティ検証を行い、開発効率を高める。

イ）要件定義・設計の上流工程からセキュリティを組み込み、後工程での手戻りコストを削減する。

ウ）セキュリティ担当者が実装工程にのみ関与することで、開発チームの負担を軽減する。

エ）リリース後の運用監視でセキュリティ問題を検出し、パッチ適用で対処する。

午前I の解答・解説を見る

正解： イ

解説： セキュリティバイデザインとは、システムの要件定義・設計という上流工程の段階からセキュリティ要件を組み込む開発アプローチです。ア） はテスト工程に集中させる考えで、設計上の欠陥を見逃すリスクが高く誤り。ウ） は上流工程への関与を排除しており、セキュリティバイデザインの趣旨に反します。エ） は「後付け対策」であり、根本的な脆弱性は設計変更を伴うため、リリース後の修正コストが飛躍的に増大します。イが正しく、上流での対応ほど修正コストが低いという「コストの法則（1:10:100ルール）」が根拠となります。

午前II問題

Ann Cavoukianが提唱したプライバシーバイデザイン（Privacy by Design）の7原則のひとつ「プライバシーをデフォルト設定に（Privacy as the Default Setting）」の説明として、最も適切なものはどれか。

ア）プライバシー保護設定はユーザが明示的に有効化した場合にのみ適用される。

イ）システムの初期状態では、ユーザの個人データが最大限に保護された設定になっている。

ウ）プライバシー設定はシステム管理者が業務上の必要性に応じて任意に変更できる。

エ）プライバシー保護は個人情報保護法やGDPRなど法的要件が存在する場合にのみ実装する。

午前II の解答・解説を見る

正解： イ

解説： 「プライバシーをデフォルト設定に」とは、ユーザが何も操作しなくても最もプライバシーが保護された状態が初期設定となる原則です。ア） はオプトイン方式を表しており、この原則の逆です。ユーザがプライバシー設定をしなくても保護される（オプトアウト不要の最大保護）が正しい理解です。ウ） は管理者が勝手に収集範囲を変更できることを示唆しており、データ主体の権利を侵害する可能性があります。エ） は法的義務の有無にかかわらず、プライバシーを積極的に設計に組み込む原則に反します。イが正しく、「ユーザは何もしなくても保護される」ことがデフォルトプライバシーの核心です。

午後問題

A社はECサイトのフルリニューアルプロジェクトを立ち上げた。新システムはEU在住の顧客も対象とするためGDPRの遵守が必要であり、情報セキュリティ担当のB氏が要件定義フェーズから参加することになった。マーケティング部門は購買傾向の分析に向けて、会員登録時に氏名・住所・生年月日・趣味嗜好・職業など幅広い属性情報の収集を求めていた。一方、B氏はプライバシーバイデザインの観点から個人データの取扱いに問題があると判断し、要件定義の見直しを提案した。また、開発チームへのセキュリティバイデザイン適用に向け、脅威モデリングの実施と脅威分析結果の設計への反映を計画している。

設問1

B氏がプライバシーバイデザインの「データ最小化」原則を根拠に、マーケティング部門の要求に対して行うべき対応を具体的に2点述べよ。

設問1の解答・解説を見る

正解例：

①　各属性情報について収集目的を明確化し、サービス提供（注文処理・配送・サポート）に直接必要ではない趣味嗜好や職業などの属性は収集要件から除外する。

②　サービスに必須な属性（氏名・住所・支払い情報）のみを必須入力項目とし、任意収集項目は初期値を「収集しない」に設定してユーザが能動的に同意した場合のみ収集する。

解説： GDPRのデータ最小化原則（第5条1項(c)）は「個人データは収集目的の達成に必要な範囲で適切かつ最小限でなければならない」と規定しています。採点ポイント： ①収集目的との紐付けによる不要データの排除（2点）。②初期状態を「未収集」とするデフォルトプライバシーの実装（2点）。「趣味嗜好・職業はサービス提供に不要」という判断理由を示していれば加点。目的外利用の禁止（目的制限原則）への言及があれば満点。

設問2

B氏が要件定義フェーズ完了前に脅威モデリングを実施する場合、その成果をシステム設計に反映させるために行うべき作業を2つ挙げ、それぞれの目的を説明せよ。

設問2の解答・解説を見る

正解例：

①　脅威一覧に基づくセキュリティ要件の定義： 脅威モデリングで洗い出した脅威（SQLインジェクション・不正アクセス等）ごとに対策要件を明文化し、機能要件と同列で要件定義書に記載する。これにより設計工程で対策が確実に実装される。

②　脅威シナリオに基づくアーキテクチャ設計の検討： 特定された高リスクな脅威に対し、ネットワーク分離・認証強化・暗号化などのセキュリティコントロールを初期アーキテクチャ設計段階から組み込む。後工程での設計変更によるコスト増を防ぐ。

解説： 脅威モデリング（STRIDEモデル等）の成果を設計に活かすには、「脅威→対策要件→設計反映」の流れを要件定義フェーズ内に完結させることが重要です。採点ポイント： ①要件定義書への明文化と設計工程での確実な実装（2点）、②アーキテクチャレベルへのセキュリティコントロール組み込み（2点）。「後工程での手戻りコスト削減」という目的を述べていれば加点。

重要キーワード

用語説明
セキュリティバイデザイン要件定義・設計の上流工程からセキュリティを組み込む開発原則。後付け対策より修正コストが低く、根本的な脆弱性を排除できる
プライバシーバイデザインAnn Cavoukianが提唱する7原則を持つ設計思想。個人情報保護を後付けではなく設計段階から積極的に内包する
データ最小化GDPR第5条に定める原則。個人データの収集・処理はサービス目的の達成に必要な最小限にとどめることを要求する
デフォルトプライバシーユーザが特別な設定を行わなくても、最もプライバシーが保護された状態がシステムの初期設定となる原則
脅威モデリング設計段階でシステムへの脅威を体系的に分析し対策要件を設計に反映させる手法。STRIDEなどのフレームワークが用いられる
SDLCソフトウェア開発ライフサイクル。各フェーズにセキュリティ活動を統合したものをSecure SDLC（SSDLC）と呼び、セキュリティバイデザインの実践基盤となる
個人情報保護個人情報保護法・GDPRなどの法規制に基づき個人データの取得・利用・管理を適切に行うための規範。プライバシーバイデザインと密接に関連する

まとめ

  • 午前I視点： セキュリティバイデザインは「上流工程からの組み込み」が核心。後付け対策との違いとコスト効果を理解する。
  • 午前II視点： プライバシーバイデザインの7原則（特にデフォルトプライバシー・データ最小化・事前的対応）の定義と具体例を押さえる。
  • 午後視点： GDPRのデータ最小化原則を根拠とした要件定義の見直しプロセスと、脅威モデリング成果をアーキテクチャ設計に反映する手順が問われる。キーワードは「目的との紐付け」「初期値設定」「要件定義書への明文化」。