セキュリティの基本概念

セキュリティバイデザインせきゅりてぃばいでざいん

セキュリティ設計プライバシーバイデザイン脆弱性対策開発プロセスリスク管理セキュアコーディング

セキュリティバイデザインについて教えて

簡単に言うとこんな感じ！

家を建てるとき、あとから「やっぱり鍵をつけよう」じゃなくて、最初の設計図の段階からドアや窓の鍵をちゃんと組み込んでおく考え方だよ。システムも同じで、「セキュリティは後回し」じゃなく、作り始めの段階からセキュリティを織り込むってこと！

セキュリティバイデザインとは

セキュリティバイデザイン（Security by Design）とは、システムやソフトウェアを開発する際に、設計・企画の段階からセキュリティ対策を組み込むという考え方・アプローチのことです。完成後に「穴をふさぐ」のではなく、最初から安全な構造を作り上げることを目指します。

従来の開発では「まず機能を作り、後からセキュリティ対策を追加する」という進め方が多く見られました。しかしこの方法では、設計の根本にセキュリティの欠陥が埋め込まれてしまうことがあり、後から修正するほどコストも手間も爆発的に増大します。セキュリティバイデザインはこの問題を解決するための根本的な発想の転換です。

近年、個人情報保護法の強化やサイバー攻撃の高度化を背景に、政府機関や大手企業のシステム調達でも「セキュリティバイデザインに基づいた設計であること」が要件として明記されるケースが増えています。システム発注側もこの考え方を理解しておくことが、いまや必須になってきています。

セキュリティバイデザインの7原則

セキュリティバイデザインには、提唱者アン・カヴーキアン（Ann Cavoukian）らが整理した7つの原則があります。もともとはプライバシー保護の文脈で生まれましたが、セキュリティ全般にも広く応用されています。

#	原則	意味・ポイント
1	事後対応ではなく予防的に	問題が起きてから直すのではなく、起きないよう設計する
2	デフォルトでセキュア	初期設定の状態が最も安全になっていること
3	設計に組み込む	セキュリティは後付けではなく設計の一部
4	全機能を損なわない	セキュリティと利便性はトレードオフではない
5	ライフサイクル全体で保護	開発・運用・廃棄まで一貫して安全に
6	可視性と透明性	設計や仕組みをステークホルダーに見せられる状態にする
7	ユーザー中心	利用者のプライバシー・安全を最優先に設計する

覚え方のヒント

「予・デ・設・全・ライ・可・ユー」と頭文字で覚えるか、「予め、デフォルトで、設計に、全部入れて、ライフ通じて、可視化して、ユーザー守る」と一文でつなげると記憶しやすいです。

セキュリティを組み込むタイミングの違い

【後付けセキュリティ】
  企画 → 設計 → 開発 → テスト → リリース → 【ここでやっと対策！】
                                              ↑ 手遅れになりやすい

【セキュリティバイデザイン】
  企画
  ↓ ← セキュリティ要件を定義
  設計
  ↓ ← 脅威モデリング・リスク分析
  開発
  ↓ ← セキュアコーディング・レビュー
  テスト
  ↓ ← セキュリティテスト（ペネトレーションテスト等）
  リリース・運用
  ↓ ← 継続的な監視・アップデート
  廃棄
  ↓ ← データの安全な削除

歴史と背景

1990年代後半〜2000年代初頭：インターネットの普及に伴いサイバー攻撃が増加。「作ってから直す」アプローチの限界が顕在化し始める
2009年：カナダのプライバシーコミッショナー、アン・カヴォーキアンがプライバシーバイデザイン（Privacy by Design）を提唱。セキュリティバイデザインの思想的な基盤となる
2010年代前半：MicrosoftがSDL（Security Development Lifecycle）を策定・公開。開発プロセスへのセキュリティ統合が業界標準として広まる
2016年：EUのGDPR（一般データ保護規則）がプライバシーバイデザインを法的義務として明記。セキュリティバイデザインへの注目が世界規模で急上昇
2020年代〜現在：日本でも経済産業省・IPAがセキュリティバイデザインの実践を強く推奨。DX推進と同時にセキュリティ内製化の流れが加速している

「後付けセキュリティ」との比較・コスト構造

セキュリティバイデザインが重要視される最大の理由のひとつが、修正コストの違いです。IBMの調査などでは、リリース後に発見された脆弱性の修正コストは、設計段階で発見した場合の数十倍〜100倍以上になるとも言われています。

セキュリティバイデザイン vs 後付けセキュリティ：実務での違い

観点	セキュリティバイデザイン	後付けセキュリティ
対策のタイミング	設計・企画段階から	リリース後・問題発生後
修正コスト	低い（根本から直せる）	高い（設計変更が困難）
セキュリティの品質	高い（構造的に安全）	低い（パッチワーク的）
開発期間への影響	初期は増えるが総合的に短縮	後半に大幅な手戻りが発生
発注側の関与	要件定義の段階で必要	問題が起きてから気づく

規格・ガイドライン	内容
IPA「セキュア・バイ・デザイン」ガイド	日本のIPAが発行する設計段階からのセキュリティ実装指針
GDPR 第25条	プライバシーバイデザインをEU域内の事業者に義務付け
NIST SP 800-160	セキュアなシステムエンジニアリングの実践フレームワーク
Microsoft SDL	Microsoftが公開するセキュリティ開発ライフサイクルの手法
ISO/IEC 27001	情報セキュリティマネジメントシステムの国際規格