はじめに
「リリース優先で作った結果、後からセキュリティ対策を大量追加することになった」
IT現場では、こうした状況が珍しくありません。
特に近年は、クラウド、生成AI、SaaS連携、API公開などによって、システムの接続範囲が急激に広がっています。その結果、「完成してから守る」という発想では、運用負荷もコストも急増しやすくなっています。
そこで重要になるのが「セキュリティバイデザイン（Security by Design）」です。
これは単なる「セキュリティ強化」ではありません。
設計段階からセキュリティを前提条件として組み込む考え方です。
本稿では、セキュリティバイデザインの基本概念、なぜ今重要なのか、従来型との違い、実務での導入ポイントまでを、初心者向けに整理します。
1. セキュリティバイデザインとは何か
セキュリティバイデザインとは、システムやサービスの企画・設計段階から、セキュリティを組み込む考え方です。
後から「脆弱性が見つかったので追加対策する」のではなく、最初から「攻撃される前提」で設計します。
欧州連合（EU）のサイバーレジリエンス法（Cyber Resilience Act）や、米国CISA（Cybersecurity and Infrastructure Security Agency）などでも、この考え方は強く推進されています12。
例えば、以下のような考え方が該当します。
| 従来型 | セキュリティバイデザイン |
|---|---|
| 作ってから守る | 作る時点で守る |
| 開発後に脆弱性診断 | 設計時に脅威分析 |
| パスワード運用頼み | 多要素認証を前提化 |
| 管理者権限を広く配布 | 最小権限を前提設計 |
| 境界防御中心 | ゼロトラスト前提 |
重要なのは、「セキュリティ担当だけの話ではない」という点です。
設計、開発、運用、クラウド、ネットワーク、認証、ログ監視まで含め、システム全体で考える必要があります。
2. なぜ今、重要視されているのか
背景には、システム構造そのものの変化があります。
従来は「社内ネットワークの中に閉じたシステム」が主流でした。しかし現在は、以下のような構造が一般化しています。
- クラウド利用。
- SaaS連携。
- API公開。
- モバイル利用。
- テレワーク。
- 生成AI接続。
- サプライチェーン連携。
つまり、「内部だけ守ればよい」時代ではなくなりました。
特に問題なのは、「後付け対策」の限界です。
例えば、後から以下を追加すると、大きなコストになります。
- IAM再設計。
- 権限整理。
- ログ設計変更。
- API認証変更。
- 暗号化対応。
- ネットワーク分離。
- 監査対応。
設計時点で考慮していれば簡単だったものが、リリース後には大規模改修になるケースも珍しくありません。
米国NIST（National Institute of Standards and Technology）でも、Secure Software Development Framework（SSDF）として、開発ライフサイクル全体でセキュリティを組み込むことを推奨しています3。
3. 「セキュリティ製品を入れる」とは違う
ここは誤解されやすいポイントです。
セキュリティバイデザインは、「高価なセキュリティ製品を導入すること」ではありません。
むしろ本質は、「危険な構造を最初から避ける」ことです。
例えば、以下は典型例です。
| 悪い例 | 良い例 |
|---|---|
| 全社員に管理者権限 | 権限分離 |
| APIキーをソース直書き | Secrets管理 |
| ログが残らない | 監査ログ標準化 |
| 本番DBへ直接接続 | 踏み台・制御導入 |
| 共有アカウント運用 | 個人識別アカウント |
つまり、「道具追加」ではなく「構造改善」です。
この違いは非常に重要です。
セキュリティ製品は、あくまで補助です。
設計自体が危険なら、防御製品だけでは限界があります。
4. DevSecOpsとの関係
セキュリティバイデザインとセットで語られやすいのが「DevSecOps」です。
DevSecOpsは、開発（Dev）、運用（Ops）、セキュリティ（Sec）を分離せず、一体化して継続運用する考え方です。
従来型では、以下のような流れでした。
開発 → リリース → セキュリティ確認
しかし現在は、以下のように変わっています。
設計
↓
開発
↓
CI/CD
↓
自動テスト
↓
脆弱性チェック
↓
監視
↓
継続改善
つまり、「最後に確認する」のではなく、「常時確認する」へ変わっています。
ここで重要なのは、自動化です。
例えば：
- SAST（静的解析）。
- DAST（動的解析）。
- IaCスキャン。
- コンテナ脆弱性検査。
- SBOM管理。
- CI/CDセキュリティゲート。
などを、開発パイプラインに組み込みます。
これにより、「人が気合で確認する」から、「構造として検出する」へ移行できます。
5. 日本企業で難しいポイント
一方で、日本企業では導入が難しいケースもあります。
理由は複数あります。
| 課題 | 内容 |
|---|---|
| 分業構造 | 開発と運用が分断 |
| 短納期文化 | セキュリティ設計が後回し |
| 属人運用 | 権限や構成がブラックボックス化 |
| レガシー資産 | 古い構成を変更できない |
| 責任分散 | 誰が決めるか曖昧 |
特に、「後から何とかする文化」は、セキュリティバイデザインと相性が悪いです。
設計段階で判断しないと、後から修正コストが跳ね上がるためです。
そのため、本格導入では「技術」だけでなく、「組織設計」や「運用設計」も重要になります。
6. 実務で最初に始めるなら
最初から完璧を目指す必要はありません。
まずは、以下のような「設計レビュー文化」を作るだけでも大きく変わります。
最初に確認したい項目
- 認証方式は適切か。
- 権限分離されているか。
- ログは追跡可能か。
- API公開範囲は適切か。
- 秘密情報管理は安全か。
- 通信暗号化されているか。
- 障害時の復旧設計があるか。
- 監査対応可能か。
また、以下の考え方は非常に重要です。
「運用で頑張る」ではなく、「事故が起きにくい構造を作る」
これは、セキュリティだけでなく、運用品質そのものにも直結します。
おわりに
セキュリティバイデザインは、「セキュリティを強化する技術論」だけではありません。
本質は、
- 後付け対応を減らす。
- 運用負荷を減らす。
- 属人化を減らす。
- 継続改善しやすくする。
という、「設計思想」にあります。
特にクラウド、生成AI、API連携が当たり前になった現在では、「完成後に守る」だけでは限界があります。
だからこそ、
- 最初から守る。
- 最初から監査できるようにする。
- 最初から権限を分離する。
という発想が、今後さらに重要になっていくでしょう。
参考
-
CISA Secure by Design
米国CISAによる「Secure by Design」推進資料 -
NIST Secure Software Development Framework (SSDF)
NISTによる安全なソフトウェア開発フレームワーク -
EU Cyber Resilience Act
EUのサイバーレジリエンス法一次資料 -
OWASP Top 10
Webアプリケーション主要脆弱性の整理 -
IPA 安全なウェブサイトの作り方
IPAによる日本語の実践ガイド