セキュリティ・バイ・デザインの実施内容

本章では、読者が各工程で実施すべきセキュリティ対策を俯瞰的に把握するため、各工程でセキュリティ・バイ・デザインにおいて満たすべき要求事項、実施内容を定義する。

加えて、各工程でのセキュリティ品質の維持に不可欠となる実務上陥りやすい留意点や昨今の傾向等をふまえ、セキュリティリスク低減のため、確実に抑えるべき、重要なセキュリティ対策の考え方ついても記載する。

セキュリティ・バイ・デザインの実施工程と概要

本項でセキュリティ・バイ・デザインの実施工程と概要を表 4‑1に示す。本書は「デジタル・ガバメント推進標準ガイドライン」のセキュリティ編と位置付けているため、両ガイドラインの関係が理解できるよう、セキュリティ・バイ・デザインの各工程と、紐づく「デジタル・ガバメント推進標準ガイドライン」の工程を併記する。

表 4‑1 セキュリティ・バイ・デザインの実施工程と概要

図 3‑1セキュリティ・バイ・デザインの実施プロセス

セキュリティ・バイ・デザインの実施内容

本項では、セキュリティ・バイ・デザインの工程ごとに、実現すべき状態を要求事項として記載し、それらを実現するためのタスクを実施内容として記載する。

加えて、各工程でのセキュリティ品質の維持に不可欠となる実務上陥りやすい留意点や昨今のセキュリティ対応の傾向等をふまえ、確実に抑えるべき、重要なセキュリティ対策の考え方ついても記載する。

セキュリティリスク分析

要求事項

  • システムにおけるセキュリティ脅威が特定されていること(システム面でのセキュリティ脅威だけでなく、サービス仕様上の脅威や利用者や開発/運用担当者等の人的ミスによるセキュリティ脅威も含めて検討すること)

  • 当該脅威にかかる発生可能性、システムへの影響度を踏まえて、リスク分析が実施されていること

  • リスク分析結果に基づき、セキュリティ対応方針を検討し、リスク対応優先度や遵守すべきセキュリティ標準(セキュリティベースライン)、対応リソース等が決定していること

実施内容

  • システムで取扱う重要情報、ステークホルダー、実施業務、他システムとの連携方法等、システムで取扱う重要情報のフローやライフサイクルが分かる内容を記載したシステムプロファイルの作成

  • システムプロファイルに基づくセキュリティ脅威の特定

  • セキュリティ脅威の発生可能性、システムへの影響度を踏まえたリスク分析の実施

  • リスク分析結果を踏まえたセキュリティ対応方針の決定(リスク対応優先度、遵守すべきセキュリティ標準、検証方法、対応リソース等)

重要なセキュリティ対策の考え方

  • システム特性や重要度に適したセキュリティ対応方針の決定
  • システム開発においては、システムの特性や重要度に応じた適切なセキュリティ対応方針が示されず、システムに対するセキュリティ対策が不十分、または、過剰なセキュリティ対策が実施されることがある。

  • 適切なレベルのセキュリティ対策を実施するため、システムにて想定される脅威にかかる発生可能性、システムへの影響度を踏まえて、リスク分析を実施する。

  • リスク分析結果から、システム特性や重要度に見合った適切なセキュリティ対応方針を検討し、主要なセキュリティ脅威に伴うリスクシナリオへの対策や遵守すべきセキュリティ標準(セキュリティベースライン)を決定する。

  • セキュリティ対応方針の中では、開発工程や運用工程で実施する第三者チェック(脆弱性診断やセキュリティレビュー)の方針を決め、必要なリソース等を決定する。

セキュリティ要件定義

要求事項

  • セキュリティリスク分析結果、セキュリティ対応方針に従い、システムで満たすべきセキュリティの状態が機能面、非機能面ともに定義されていること

実施内容

  • 遵守すべきセキュリティ標準(セキュリティベースライン)やリスク分析結果等に基づく、システムとして満たすべきセキュリティ要件の定義(機能、機能面)

重要なセキュリティ対策の考え方

  • 多層防御の実施
  • サイバー攻撃は成功する前提にたち、特定のセキュリティ対策が破られたとしても、別のセキュリティ対策により被害を極小化する多層防御の考え方に基づいて、セキュリティ要件を定義することが重要である。

  • OSやミドルウェア、ネットワーク、アプリケーション等の各コンポーネントにおいて、多層のセキュリティ対策を実施することで、攻撃者にとって攻撃コストの高いシステムを実現する。

  • サイバー攻撃や事故の発生自体の防止を目的とする対策(防止策)に偏らず、速やかなインシデント(兆候)の検知、有事のインシデント対応、サービス復旧のための対策をバランスよく、多層的に実装することが求められる。

セキュア調達

要求事項

  • 委託先とのセキュリティ対応の責任範囲を明確にした上で、必要なシステムにおけるセキュリティ要件やサプライチェーンリスク対策を含めた網羅的なセキュリティ仕様を策定していること

  • クラウドサービスを利用する際はサービス形態(SaaS、IaaS、PaaS等)を踏まえて責任範囲を特定し、責任共有モデルに基づく義務を果たす能力と内部統制について透明性の高いサービスを選定すること

  • システムのセキュリティ仕様を実装できる能力を有し、求めるセキュリティ管理基準を満たし、セキュリティリテラシーおよび意識が高い、安全な委託先が選定されていること

  • システムで利用する機器、ミドルウェア、ライブラリ等については、それら自身がセキュリティ・バイ・デザインやセキュリティ・バイ・デフォルト等の安全な開発手法を取り入れており、不正侵入の経路となるバックドア等が含まれていない、サービス提供期間中継続的なサポートを受けられる安全なものを選定すること

実施内容

  • セキュリティ要件に基づいて、調達仕様におけるセキュリティ仕様策定

  • セキュリティ仕様に関する、委託先との責任範囲の明確化

  • 委託先に求めるセキュリティ管理基準の策定

  • セキュリティ仕様を満たす能力を有した安全な委託先の選定

  • 不正侵入の経路となるバックドア等が含まれていない、継続的なサポートを受けられる安全なプロダクトの選定

重要なセキュリティ対策の考え方

  • セキュリティ仕様を満たす能力を有した委託先の選定、管理
  • 委託先の能力不足、管理不足が原因によるセキュリティインシデントが多発しているため、継続的に社内全体でセキュリティ意識向上施策を講じ、セキュリティに関する高いリテラシーを有する委託先を選定し、適切な管理を行う。

  • システムのセキュリティ要件に基づくセキュリティ仕様を策定した上で、当該仕様を実装可能な、十分な能力を有した委託先を選定する。

  • システム基盤にクラウドサービスを使用する場合は、各政府機関等におけるISMAP制度の利用の考え方を踏まえ、統一基準群の遵守事項に従ってクラウドサービスを選定する。

  • 委託先のセキュリティ管理等の不備によるインシデント等を防止するため、委託先に求める具体的なセキュリティ管理基準を策定し、委託先を管理、監督する。

  • バックドア等が含まれていない安全なプロダクトの選定
  • サプライチェーンの多様化、グローバル化に伴い、調達したソフトウェアや機器が原因による、セキュリティインシデントが多発している。

  • システムで利用するサードパーティのライブラリやミドルウェア、機器については、セキュリティ・バイ・デザインやセキュリティ・バイ・デフォルト等の安全な開発手法を製品開発に取り入れている事業者から提供されており、不正侵入の経路となるバックドア等が含まれていない安全なプロダクトを選定する。

  • システムの稼働期間中、脆弱性が検出された場合にセキュリティパッチの提供や緩和策の提示のサポートが受けられる、プロダクトを選定する。

  • サービス運用中のプロダクトのセキュリティ確保については、利用者側に管理責任があるため、構成管理、脆弱性管理、ライフサイクル管理等を適切に実施する。

セキュリティ設計

要求事項

  • セキュリティ要件を満たすように実装方針を具体化し、システムにおける機能面と非機能面でのセキュリティ設計が実施されていること

  • 堅牢化(攻撃対象領域が少なく、多層多重で守られている)されていること

  • サイバーレジリエントな設計が実施されていること

  • サービスデザインの観点から、システムの利用者や運用者等による人的ミスを引き起こす可能性が十分に低減された仕様になっていること

実施内容

  • セキュリティ設計の実施

    • アプリケーションセキュリティ

    • OSセキュリティ

    • ミドルウェアセキュリティ

    • ネットワークセキュリティ

    • クラウドセキュリティ

    • 物理セキュリティ

    • セキュリティ運用(平時、有事)

重要なセキュリティ対策の考え方

  • アタックサーフェス(攻撃対象領域)の管理、防御
  • セキュリティ設計においては、攻撃対象となるアタックサーフェス(攻撃対象領域)を極力減らす設計を行い、防御することが重要となる。

  • システムにおけるアタックサーフェス(攻撃対象領域)を把握するため、システムで使用するリソースの資産管理を徹底し、最新な状態を維持するとともに脆弱性を管理可能な仕組みを導入する。

  • 攻撃者による脆弱性や設定ミスの悪用を防止するため、システムにおいて不要な機能やサービスは使用しない。また、ソフトウェアやミドルウェアに設定されている初期設定値をそのまま使用しない。

  • 外部I/Fへの入力に関しては信頼せず、必ず入力値検証を実施する。

    • 管理者アカウントの保護
  • 権限管理に起因するインシデント被害を極小化するため、ユーザアカウント、管理者アカウントに対して過剰なアクセス権限は付与しない。

  • とりわけ、管理者アカウントの悪用は被害が大きくなるため、管理者権限の利用者は必要最小限にとどめ、管理者アカウントでのアクセスには多要素認証等を用いて十分に保護する。

  • 管理者アカウントの利用者を特定可能な仕組みを導入し、追跡可能な状態にする。

    • サイバーレジリエントな設計の実施
  • サイバー攻撃の大規模化や高度化に伴い、攻撃は成功してインシデントは発生する前提に立ち、防御力だけでなく回復力(サイバーレジリエンス)を高める設計が重要となる。

  • システムアーキテクチャの設計においても、ネットワーク分離やアクセス権の必要最小権限付与、ゼロトラストセキュリティの考えに基づく対策の導入等、インシデント発生時のシステムへの被害を極小化するための設計が求められる。

  • 必要な機器やソフトウェアのログ、セキュリティ製品のアラート等を収集/分析し、インシデント等異常な状態を速やかに検知するための独立した監視環境を用意することが、セキュリティ運用上重要となる。

  • インシデントを検知した際は、速やかなインシデント対応やサービス復旧を可能とする、運用体制や運用プロセスの整備が求められる。また、速やかなサービス復旧を行うため、重要データやシステムのバックアップを行い、リストア手順を事前に準備する。

    • 人的ミスへの対応策の検討
  • サービス利用者やシステム管理者、運用者等による人的ミスにつながる可能性のあるシステム仕様については、デザイン(UI、UX)の改善することで事故発生防止につとめる。

  • システム仕様の改善に加えて、ワークフロー(ダブルチェックや承認フローを設定等)や作業者のリテラシーを高めるための取組みとして必要な教育コンテンツを事前に提供する等の対策を講じることで、人的ミスの発生可能性をできるだけ低減する。

  • 人的セキュリティの対応については、システム開発部門や運用部門だけでなく、システム利用者となる国民や自治体等多くのステークホルダを事前に巻きこみ、過去のインシデント事例等に基づいて事故発生防止に向けた建設的な議論やサンプル等を用いた検証を重ね、システム仕様や業務の改善をはかることが重要となる。

  • また人的ミスによる事故は必ず発生するという前提の下、発生状況の定期的な確認、事故発生時に速やかに上層部まで報告される体制や事故発生時の被害を極小化する対応手順を事前に整備する。

セキュリティ実装

要求事項

  • 設計に基づいて、セキュリティ機能の実装が完了していること

  • セキュリティ設計方針に基づいて、脆弱性を作りこまないよう、アプリケーションのセキュアコーディングが実施されていること

  • セキュリティ設計方針に基づいて、システム基盤となるプラットフォームのセキュリティ設定の実施(堅牢化、要塞化)が完了していること

実施内容

  • 設計に基づくシステムにおけるセキュリティ機能の実装

  • セキュリティ設計に基づくアプリケーションのセキュアコーディング

  • セキュリティ設計に基づくプラットフォームのセキュリティ設定の実施(堅牢化、要塞化)

    • OSセキュリティ

    • ミドルウェアセキュリティ

    • ネットワークセキュリティ

    • クラウドセキュリティ

    • 物理セキュリティ

重要なセキュリティ対策の考え方

  • セキュリティテンプレート、自動化技術の活用
  • セキュリティ実装においては、担当者によるミスやばらつきの発生を防止することが重要であるため、セキュリティ関連のコーディングやセキュリティ設定は、テンプレートの使用や自動化機能を用いて対応することが望ましい。

  • アプリケーション開発は、安全で利便性の高い、セキュアコーディングをサポートするような機能を有した開発用ツールやフレームワークを活用することで、人的なミスの発生をおさえ、セキュリティ確保することが有効である。

  • システム基盤のセキュリティに関しては、各種プラットフォーム向けに最適化されたセキュリティベンチマーク(ベストプラクティス)やセキュリティ設定が組み込まれたシステムイメージ、IaCテンプレート等を使用することで、人的なミスや担当者依存の品質のばらつきを防止する。また、ベンチマークやテンプレートを用いてセキュリティベースラインを定義することで、セキュリティ監査の実行容易性も向上する。

  • 他方、システムイメージやIaCテンプレートに脆弱性やセキュリティ設定の不備がある場合、複数のリソースに広範囲に悪影響が及ぶことが懸念されるため、有識者や外部サービス等による事前の検証を必ず実施すること。

セキュリティテスト

要求事項

  • セキュリティ機能に対する各種テストが実施され、品質が確保されていること

  • 脆弱性診断を実施し、システムにおける脆弱性が取り除かれていること

実施内容

  • セキュリティ機能テストの実施(単体テスト、結合テスト、システムテスト等)

  • 脆弱性診断の実施

    • Webアプリケーション脆弱性診断

    • プラットフォーム脆弱性診断

    • スマートフォンアプリケーション診断

    • 高度セキュリティ診断(ペネトレーションテスト、レッドチーム演習等)

  • 機能テストで検出されたバグの是正対応

  • 脆弱性診断で検出された脆弱性に対する、リスクベースの是正対応

重要なセキュリティ対策の考え方

  • システム特性、システム重要度に応じた適切な脆弱性診断の実施
  • 脆弱性診断の実施に関しては、アタックサーフェス(攻撃対象領域)に対して漏れなく脆弱性診断が実施されるように、システム特性に応じた適切なスコープで脆弱性診断を実施する。

  • また、重要度の高いシステムにおいては、脆弱性診断ツールのみを実行する表層的な脆弱性診断では不十分であるため、専門家による高度な診断を追加で実施する等、リスクレベルに応じた脆弱性診断を実施が重要となる。

セキュリティ運用準備

要求事項

  • セキュリティ運用(平時、有事)を実施するのに十分な運用体制が確立されていること。

  • セキュリティ手順が策定され、運用の実行性が確保されていること

実施内容

  • セキュリティ運用体制の確立

  • 下記項目に対応したセキュリティ運用手順の整備

□平時の運用

  • 構成管理、変更管理

  • セキュリティ製品のアラート、システムログ等を活用したセキュリティ監視、検知

  • 脅威情報収集、自システムへの影響分析

  • CVSS等に基づく、リスクに応じた脆弱性対応

  • 定期的な脆弱性診断の実施

□有事の運用

  • インシデント対応
  • システム運用において人的ミスが発生する可能性のある箇所の洗い出し、是正

  • 有事を想定したセキュリティ運用訓練の実施

重要なセキュリティ対策の考え方

  • インシデント発生を想定した運用訓練の実施
  • セキュリティ運用手順等を事前に整備しても、実際にインシデントが発生すると、手順どおりに対応が進まず、多くの時間を要して被害が拡大するケースが多々ある。

  • 主要な想定脅威(リスクシナリオ)については、関係者を含めて、インシデント発生を想定した訓練を実施し、実運用上の課題を特定し、体制や手順の見直しを行うことで、インシデント対応の実行性を担保する。

  • 運用訓練実施後に関係者にフィードバックを行うことで、セキュリティ意識の向上やインシデント対応手順の理解の定着をはかる。

セキュリティ運用

要求事項

  • システムの構成監理、変更管理が適切に実施されていること

  • システムに影響する脅威情報、脆弱性情報が定常的に分析され、脆弱性対応等継続したリスク管理が行われていること

  • 速やかなインシデント(予兆)の検知が行えること

  • インシデント発生時に速やかな対応、システム復旧が実施できること

実施内容

  • セキュリティ運用を行う要員の教育/訓練の実施、重要な情報を取り扱う要員のスクリーニング(要員のスキルや行動特性等を考慮)

  • セキュリティ運用の実施(下記)

□平時の運用

  • 構成管理、変更管理

  • セキュリティ製品のアラート、システムログ等を活用したセキュリティ監視、検知

  • 脅威情報収集、自システムへの影響分析、是正対応

  • CVSS等に基づく、リスクに応じた脆弱性対応

  • 定期的な脆弱性診断の実施

□有事の運用

  • インシデント対応

重要なセキュリティ対策の考え方

  • ソフトウェアの構成管理
  • アプリケーションで使用するライブラリやミドルウェア等に深刻な脆弱性が発見された場合、自システムで該当のライブラリやミドルウェアが該当のものが含まれるかどうかを迅速に判断できるよう、システムで使用するソフトウェアの開発元、バージョン、ライセンス、依存関係などを容易に参照できるような構成管理を行う(SBOM等を利用したソフトウェア構成管理を行うことも有用)。
  • 定常的な脅威情報/脆弱性情報の収集、分析、リスクに応じた対応
  • 日々出現するセキュリティ脅威や脆弱性に対処するため、定常的に脅威情報や脆弱性情報を収集し、自システムへの影響含めてリスク分析を行う。

  • 脆弱性においてはCVSS等の値に基づき、当該脆弱性によるシステム環境への影響を分析し、被害の発生が想定される脆弱性に対しては緊急にセキュリティパッチを適用する、セキュリティパッチが適用できないケースは暫定対処として仮想パッチを用いる、システムの利用機能を制限する等、対応方針決定する。

  • 上記の脅威情報や脆弱性への対応方針については、都度個別判断を実施するのではなく、事前に脆弱性対応方針を整理し、当該方針に従った運用を実践することで円滑な対応が可能となる。

  • サイバーレジリエントなセキュリティ運用
  • インシデント(その兆候)の早期検知、速やかなインシデント対応やサービス復旧を実践することで、インシデント発生時のシステム被害やサービスへの影響を極小化する。

  • インシデント対応やサービス復旧の実行性を維持するため、定期的にインシデント対応手順やサービス復旧手順の見直しを行い、不具合が特定された際は速やかに改善する。また、運用開始後の定期的なインシデント対応訓練の実施は、関係者の緊張感を高めるとともに、インシデント対応手順の実行性確保に有効である。

  • セキュリティンシデントが発生した際は、根本的な発生源の原因究明を行い、再発防止策を講じる。また、実際のインシデント発生時において、円滑に進まなかった作業についても振り返りを行い、継続した改善を繰返すことで、インシデント対応レベルの成熟度向上に努める。