セキュリティ・バイ・デザイン、セキュア・バイ・デザイン

掲載:2024年03月27日

改訂:2024年10月31日

用語集

「セキュリティ・バイ・デザイン」または「セキュア・バイ・デザイン」とは、システムの企画・設計(デザイン)段階から、セキュリティ対策を組み込む考え方のことです。従来は、システムの完成後に後付けでセキュリティ対策を行うことが一般的でした。一方、セキュリティ・バイ・デザインのアプローチでは、開発の初期段階からセキュリティを考慮することで、防御力を高めることが可能です。

         

セキュリティ・バイ・デザインが求められる背景

セキュリティ・バイ・デザインの考え方自体は、特に目新しいものではありません。2011年には、内閣サイバーセキュリティセンター(NISC)が「情報セキュリティを企画・設計段階から確保するための方策」を検討し、政府調達におけるセキュリティ・バイ・デザインの必要性を公表していました。

近年、セキュリティ・バイ・デザインが改めて重要視される背景には、以下のようなITを取り巻く環境の変化が挙げられます。

  • あらゆるものがインターネットにつながるIoTの普及
  • アジャイル開発やDevOps(開発と運用の統合)などビジネスの変化に素早く対応する開発手法の広がり
  • システムやサイバー攻撃手法の多様化・複雑化

例えば、IoTでは物理的な制約により、後付けのセキュリティ対策には限界があります。また、アジャイル開発やDevOpsでは、品質保証を前倒しするシフトレフトやセキュリティ・バイ・デザインの導入・活用が成功の鍵の一つとなるからです。

このように、ITを取り巻く環境が変化する中で、セキュリティ・バイ・デザインのアプローチが以前にも増して求められるようになってきました。

2023年10月、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は、主にソフトウェア開発者に対し、セキュア・バイ・デザインとセキュア・バイ・デフォルトの実践に向けた推奨事項をまとめたガイダンスを改訂し、公開しています。 日本のNISC、JPCERT/CCを含む各国の17機関との国際連携による共同ガイダンスとなっており、サイバーセキュリティを強化するうえで製品自体のセキュリティレベル向上が急務であることがうかがえます。

※ガイダンスで提示されている推奨事項の基本原則などの詳細については、セキュア・バイ・デフォルトの項をご覧ください。

セキュリティ・バイ・デザインのメリットと注意点

セキュリティ・バイ・デザインの導入には、以下のようなメリットがあります。

1)手戻りを防いで開発スピードを向上
開発の初期段階からセキュリティを考慮することで、後工程で致命的な脆弱性を検知するリスクを抑えられます。それにより、修正や手戻りの発生を防ぎ、開発スピードの向上や納期遅延の防止が可能です。

2)セキュリティ対策のコストを抑えられる
開発の初期段階でセキュリティ対策を組み込むことは、脆弱性発見後に専門家による調査や修正作業を行う場合に比べ、コストも大幅に抑えることが可能です。情報処理推進機構(IPA)が公開した「セキュリティ・バイ・デザイン導入指南書」※1によると、設計時のセキュリティ対策にかかるコストは、テスト工程に比べて15分の1、運用開始後に比べると100分の1で済むとされています。

3)システム全体の保守性が高まる
従来の後付けのセキュリティ対策では、システムの複雑性が増し、保守性を悪化させることがありました。一方、企画・設計段階からセキュリティ対策を組み込むセキュリティ・バイ・デザインではシステムの一貫性が保たれ、後から「付け足す」よりもシステム全体がスムーズに機能し保守や更新が容易になります。

これらのメリットにより、サイバー攻撃への防御力を効率的に高め、安全な製品やサービスの提供に貢献するといえます。

効率的に安全性を高められるセキュリティ・バイ・デザインですが、導入にあたり注意すべき点もないとはいえません。まだセキュリティ設計の歴史は浅く、知見のある人材を確保する難しさや、導入にかかる費用や時間が社内的に理解されにくい、セキュリティを最優先しすぎて設計における柔軟性が低下するなどです。さらにどこまでをセキュアとするのか、前提となる明確な基準を組織として明文化しておかないと、開発が長引くことになります。

セキュリティ・バイ・デザインの実践プロセス

デジタル庁は、2022年に「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」※2を公開しました。同資料を参考に、セキュリティ・バイ・デザインを実践する際の、各工程の実施内容を紹介します。

工程 実施内容
企画
  • セキュリティ脅威の特定とリスク分析
  • セキュリティ対応方針の策定とリソース決定
要件定義 システムが満たすべき機能面・非機能面のセキュリティ要件を定義
調達 セキュリティ要件を満たす調達仕様の策定、安全な委託先やプロダクトの選定
設計
  • セキュリティ要件を満たす実装方法の具体化、機能面・非機能面のセキュリティ設計
  • 堅牢でサイバーレジリエントな設計の実施
実装
  • セキュリティ設計に基づくセキュアコーディングの実装
  • セキュリティ設計に基づく基盤設定
テスト
  • システム特性や重要度に基づくテストの実施
  • 脆弱性診断による脆弱性の是正
運用 ・改善・保守
  • 平時・有事の運用体制の確保
  • インシデントを想定した手順の準備や訓練の実施

こうしたセキュリティ・バイ・デザインのアプローチを定着させるためには、経営層のコミットメントを含む組織的な変革や、継続的な改善の取り組みが重要です。