DXの進展やサイバー攻撃の増加・深刻化に伴い、サービスやシステム開発の初期段階からセキュリティを考慮する「セキュリティ・バイ・デザイン」の重要性が高まっています。その機運を受けて、2022年8月には『セキュリティ・バイ・デザイン導入指南書』が、2024年7月には『開発者のためのセキュリティ入門 アンチパターンから学ぶセキュアシステム開発』がIPA（情報処理推進機構）サイトにて公開されています（※）。

しかし、セキュリティ・バイ・デザインの実践方法や組織に導入するプロセスについて体系的に理解しているという方はまだまだ少ないはず。そこで本記事では、それらを含めた実践的な資料をもとに、情シス担当者が押さえておくべき「セキュリティ・バイ・デザイン実践法」を解説します。

※いずれも「産業サイバーセキュリティセンター 中核人材育成プログラム」における各卒業プロジェクトチームの著作物。

なぜ今「セキュリティ・バイ・デザイン」なのか──シフトレフトとの違いは？

「セキュリティ・バイ・デザイン（Security by Design）」は、システムの設計・開発・運用のすべての段階で、セキュリティを“後付け”ではなく“組み込み”として考慮する手法です。

同様の考え方は以前も存在したものの、企業のシステムはオンプレミスが主流だったこともあり、セキュリティ対策が組み込まれるのはシステムの完成後という場合も少なくありませんでした。しかし、クラウドサービスや外部API、SaaSツールなどを多数組み合わせた「つながる構成」が主流となった現在、「後付け」の防御モデルは十分に機能しません。

例えば、「営業支援システムと外部データベースをAPI連携した結果、社外のアプリケーション経由で情報が流出した」「クラウドストレージの共有設定を誤ったため、社外からアクセス可能になっていた」といったケースは、設計段階でのセキュリティ考慮が不足しているために起こりがちです。

特に予算や人的リソースが不足する中堅企業では、「後からセキュリティを補う」対処療法的な運用に危機感を覚えているという方も少なくないはずです。また、サプライチェーンリスクも高まる中、企業に求められるセキュリティ対策のハードルも上がっています。「システム導入後に監査や取引先からセキュリティチェックシート対応を迫られ、設定変更や追加対策が必要となった」「ベンダーに任せていたシステムの脆弱性検証やコードレビューが不十分なため、トラブルに発展した」といった事態を防ぐためにも、有効なのが「セキュリティ・バイ・デザイン」です。

「後から守る」ではなく「最初から組み込む」──この転換を象徴するのが、セキュリティ分野でよく使われる「Shift Left（シフトレフト）」という言葉です。これは、従来はリリース直前や運用後に行っていたセキュリティ検証を、設計・開発の早い段階（左側）に移行させることで、リスクを事前に検知し、修正コストを最小化するという考え方を指します。

【関連記事】サイバーセキュリティの「シフトレフト」実践のポイント

例えば、要件定義段階で「どのデータをどのレベルで保護すべきか」を明確化し、設計段階で「アクセス権限の最小化」「通信経路の暗号化」「脆弱性のあるOSS利用の禁止」などを定義しておくセキュリティ・バイ・デザインのアプローチは、サイバー攻撃による被害の最小化につながります。

このように、早期にリスクを見積もり、要件として組み込むことが、結果的に全体のコスト削減につながるのです。セキュリティ・バイ・デザインは、シフトレフトの‟前工程からセキュリティや運用を考慮する‟という考え方を、よりセキュリティやシステムアーキテクチャの設計思想に特化したものともいえるでしょう。

要件定義から開発、テストまで、四つのフェーズで実践するセキュリティ・バイ・デザインのポイント

セキュリティ・バイ・デザインが現代のシステム開発において欠かせない要素であることを解説してきました。

それでは、実際にセキュリティ・バイ・デザインを企業システムの設計・開発に組み込むプロセスはどのようになっているのでしょうか？

ここでは、情シス担当者が現場で活用できる実践ポイントを四つのフェーズで整理します。

【1】要件定義フェーズ──セキュリティを“非機能要件”から“必須要件”へ

最初に着手すべきは「要件定義フェーズ」で、セキュリティを組み込むことです。要件定義フェーズでは、以下の三つのポイントを踏まえ、アクセス権限、データの保管場所、法令上の制約といった要件をドキュメント化することが求められます。

ポイント1：データ分類の明確化

扱うデータを「秘匿情報」「社内限定」「外部公開」などに分類し、リスクに応じた保護レベルを決定します。例えば「顧客データ」は「秘匿情報」として“暗号化保存＋多要素認証”を義務付け、「Web記事data」は「外部公開」に分類するなどの対応が挙げられます。

ポイント2：認証・認可設計の方針決定

分類したデータに対し、「誰が、どこから、どの操作を行えるのか」を明確に定義するのも忘れてはなりません。ここで決定したことが、例えばクラウド利用における権限設定など設計フェーズ以降の対応の基礎ともなります。

ポイント3：法令・契約対応の確認

個人情報保護法やGDPR、委託契約上のセキュリティ条項など、守るべき法的義務を明文化します。この段階で担当者を設定し、文書に要件をまとめておくことが、後のトラブルや工数の削減に大きく貢献します。

この段階でシステムの要件定義とは別に「セキュリティ要件定義書」を作成し、ベンダーと合意形成しておくことが理想的です。例えば「全社アカウントはIDaaSで一元管理する」「ログ保管は1年間」「委託先にOWASP Top 10対応を求める」など、明確な“線引き”を早期に共有することがリスク低減につながります。

【2】設計フェーズ──セキュリティ設計書を「並行設計」で作る

設計段階では、機能仕様の設計とは別軸で「セキュリティ設計書」を作成するのがセキュリティ・バイ・デザインの基本です。

「セキュリティ設計書」で押さえるべき原則としては以下のようなものが挙げられます。

原則1：最小権限設計

全ユーザー・システムに対し、「必要な権限だけを付与する」。例えば、管理者権限を運用担当者に恒常的に付与せず、申請制に切り替える。

原則2：ゼロトラスト設計

内部ネットワークだからといって信頼しないゼロトラストの原則に従って、暗号化や端末認証を実装します。VPN接続後も「秘匿情報」を扱う場合はアプリ単位での認証を組み込むなど、セキュリティ要件に従って厳密な運用を心がけましょう。

原則3：サプライチェーンリスクの評価

外部ベンダーやOSSの利用範囲を洗い出し、更新管理や依存関係を把握します。近年、関連企業への被害拡大を狙ったサプライチェーン攻撃も増加しており、即時対応できる体制の整備が不可欠となっています。

また、設計時には「セキュリティ観点レビュー会」を設けるのも効果的です。情シス・開発・運用の担当者が集まり、脅威分析を実施し、「攻撃者ならどう狙うか」を議論することで、机上の安全設計を“実効性ある防御設計”に変えられるのです。

【3】開発フェーズ──ツールで“自動化された安全性”を確保する

開発フェーズでは、「セキュリティ要件定義書」「セキュリティ設計書」に従い、機能を実装しながらセキュリティ観点でのチェックを並行して進めることが求められます。ここで近年、重要となっているのが人手によるレビューと自動化ツールによるチェックを並行させることです。

代表的な実践の内容と使用ツールの例は以下の通りです。

• 静的解析ツール（SAST）の導入：GitHub Advanced Security、SonarQube、Fortifyなど
• OSSライブラリの脆弱性チェック：OWASP Dependency-Check、Snyk、Trivyなど
• 開発委託先へのレビュー要求：契約時に「脆弱性スキャン実施」「開発環境アクセスの制限」「ログ提出」を明記し、成果物の安全性を可視化

開発を外部に委託した場合、重要なのが委託先とセキュリティ水準について明確な合意を結んでおくということです。開発委託元には開発委託先のセキュリティ品質を監査・指導できる体制が求められているという前提で、セキュリティ・バイ・デザインの実践に取り組みましょう。

【4】テスト～リリースフェーズ──“形式的チェック”から“攻撃視点”へ

リリース直前のテスト工程で重要なのが“攻撃者の視点”で最終的なチェックを実施することです。

ペネトレーションテストを通して、システムだけでなく組織構造や社内の文化に脆弱性はないかを調べる、開発メンバー以外の現場や外部の視点を組み込むことでセキュリティの穴を防ぐといった観点を持つことが、総合的に「脆弱性」を検証することにつながります。

また、こうしたテストは一度で終わりではなく、定期的に更新してセキュリティのアップデートを行うことが前提となります。このようにセキュリティ・バイ・デザインには、開発・セキュリティ・運用を一体化する「DevSecOps（Development + Security + Operations）」の観点も含まれていると考えてください。

【関連記事】DevSecOpsとは？セキュリティを重視した開発スタイルについて解説

DevSecOps──三つの観点で見る運用・改善フェーズでの「セキュリティ・バイ・デザイン」

システムをリリースした後こそ、本当の意味での「セキュリティ・バイ・デザイン」が問われます。

設計やテストで万全を期したつもりでも、クラウド環境やアプリケーションは日々更新され、リスクは常に変化しています。

ここでは、運用の仕組み化・組織文化の醸成・継続改善の三つの観点から、実務での定着方法を解説します。

1.運用の仕組み化──“変化を検知する仕組み”を組み込む

運用フェーズでは、日常業務の中に「変化を見逃さない仕組み」を組み込むことが重要です。特にクラウド活用が進む中で、設定変更や権限付与が頻繁に行われる現代では、ヒューマンエラーが大きなリスクとなります。

例えば、「運用担当者が一時的なトラブル対応のためにS3バケットを“全公開”に設定したまま戻し忘れ、機密資料が外部から閲覧可能になっていた」というケースを考えてみましょう。

こうした「構成ドリフト」を防ぐには、Infrastructure as Code（IaC）で構成をコードとして管理し、意図しない変更が発生しても検知できる仕組みを整えることが有効です。具体的には、Terraformなどでインフラ構成をコード化し、AWS ConfigやCloudTrailといったサービスを併用することで、S3 バケットの公開設定が変更された際に自動で検知・アラートを出すことができます。

また、権限管理とアカウント棚卸しの定期実施も欠かせません。半年または年次で「誰がどの権限を持っているか」「不要なアカウントが残っていないか」を点検することで、組織の異動・退職による“権限の野放し”を防げます。特に外部委託先やアルバイトスタッフなど、短期契約者のアカウントは削除漏れが起こりやすくなっています。

さらに、ログ監視・アラートの継続改善も運用段階の重要なテーマです。SIEM（Security Information and Event Management）ツールやクラウド監視サービスを導入していても、アラート設定が形骸化しているケースは少なくありません。「どのイベントを重大と判断するか」「どの部署に通報するか」を定期的にアナウンスすることで、実際の脅威に迅速に対応できる体制を整えましょう。

2.組織文化の醸成──“一部の担当者の仕事”から“全員の責任”へ

セキュリティ・バイ・デザインを継続的に機能させるには、“人”の意識改革と協働体制が欠かせません。

特に中堅企業では、「セキュリティは情シスの担当範囲」と捉えられがちですが、真に安全なシステム運用は、開発・運用・総務・経営層が一体となって支える文化によって成り立ちます。

例えば、近年注目されているのが、「セキュリティ・チャンピオン制度」です。

これは開発チームや事業部ごとに“セキュリティ担当代表”を任命し、情シスとの橋渡し役として活動する仕組みであり、情シスだけではカバーしきれない日常的なセキュリティ判断を、現場レベルで補完できるようになります。例えば、新しいSaaS導入時に「データ保存先」「認証方式」「契約時の責任範囲」などをチャンピオンが事前チェックすることで、情シスへの報告遅れや設定ミスを減らせます。

また、インシデント共有会や“ポストモーテム文化”の導入も有効です。

トラブルやヒヤリハット事例を「責任追及の場」ではなく「学びの共有の場」として扱うことで、現場が萎縮せずに知見を積み上げられます。また、GoogleやNetflixなどが採用するポストモーテム（事後分析）では、「何が悪かったか」ではなく「次にどう改善するか」を重視し、仕組みの改善につなげています。

さらに、経営層の関与も文化定着の要です。「サイバー攻撃は経営リスクである」という認識を共有し、経営会議でも重大インシデント数、脆弱性対応完了率などのセキュリティ指標をモニタリング項目に含めることで、全社的な優先順位が高まるはずです。

3.継続的改善──“仕組みそのものをアップデートする”発想を持つ

セキュリティ・バイ・デザインの仕組みを継続的に見直し、常に対策を有効なものに保つためには定期的な運用レビューの実施が欠かせません。具体的には、半年〜年次のタイミングで、以下の点を洗い出し、改善サイクルに組み込みます。

• 直近のアラートやインシデントの傾向に変化はないか
• 重要ログの取得・保存期間は十分か
• IaCコードのメンテナンス状況は適切か
• アクセス権限やチーム体制に、現状との不整合はないか

特にクラウド環境では、AWS・Azure・Google Cloudなどのサービス仕様が数カ月単位で更新されるため、「いつの間にか推奨設定が変わっていた」「ベストプラクティスが更新されていた」というケースも珍しくありません。運用レビューを定例化し、“最新のセキュリティ要件に追随できる組織”であることが長期的なリスク低減につながります。

さらに、脆弱性情報の収集とパッチ適用プロセスの標準化も重要です。CVE情報や各クラウドベンダーのセキュリティアラートをウォッチし、「Criticalは72時間以内」「Highは1週間以内」など、優先度（深刻度）に応じて対応時間を明確化することで、対応漏れを防止できます。

情シスが“明日から実践できる”仕組みづくりに踏み出すために

「難しい」と捉えられがちなセキュリティ・バイ・デザインを組織に根付かせるには「具体的な仕組みを一つずつ動かす」ことが大切です。例えば、権限の棚卸しを定例化する、IaCで設定変更を追跡できるようにする、チーム横断のレビュー会を月1回実施する──一つ一つの取り組みを積み重ねれば徐々に‟組織の常識”が変わっていきます。

最初から仕組みを完璧に整える必要はありません。一度でもツールやドキュメントが活用され、一つでも仕組みが定着すれば、インシデント防止に確実につながっていくはずです。長期的な視点を持って、“明日から実践できる”仕組みづくりに踏み出してみてください。