「設計から安全」を組み込む ～ Vantaで証明する継続的なセキュリティ

はじめに ～ なぜ「後付け」では間に合わないのか？

近年、私たちのビジネスを取り巻くデジタル環境は劇的に変化しました。クラウドサービスの利用、DX（デジタルトランスフォーメーション）の加速により、製品やサービスのリリースサイクルは短期化しています。この変化に伴い、サイバーセキュリティの脅威もまた、その深刻度を増しています。

現代のサイバー脅威に対し、システムが完成した後でセキュリティパッチを当てるという従来の「後付け」対応では、もはや間に合いません。 セキュリティ対策の核心は、ビジネスやシステムの設計段階からセキュリティレベルを要件として明確に組み込み、開発の源流から安全性を底上げすることにあります。

これこそが、IT製品・サービスにおいて「設計段階から安全性を確保されていること」を指す、セキュリティ・バイ・デザイン（Security by Design：SbD）の思想そのものです。

サプライチェーン攻撃の深刻化と「設計」の責任

特に近年、深刻な脅威となっているのがサプライチェーン攻撃です。これは、セキュリティ対策が手薄な取引先や、製品に含まれるオープンソースなどの利用コンポーネントを足がかりに、最終的なターゲット企業や顧客のシステムへ侵入する手法です。

自社単体のシステムがいかに堅牢であっても、提供する製品の中に脆弱なポイントが一つでもあれば、それがサプライチェーン全体の致命的なリスクとなってしまいます。

こうした状況下で、製品・サービスを提供する企業に求められているのは、完成後に対策を講じる「後付け」の対応ではありません。ビジネスやシステムの設計段階からセキュリティレベルを要件として明確に組み込み、サプライチェーン全体でセキュリティ水準を底上げすることにあります。

これこそが、IT製品・サービスが「設計段階から安全性を確保されていること」を指す、セキュリティ・バイ・デザイン（SbD）の責任ある実践といえます。

加えて、SbDの実践は、脆弱性の発見が遅れるほど増大する修正コストを開発の初期段階で食い止め、ビジネスの信頼性と競争優位性を確保する最も経済的な戦略です。

セキュリティ・バイ・デザイン (SbD) の「6つの基本方針」

セキュリティ・バイ・デザイン (SbD) は、特定の技術に依存しない根本的な考え方であり、その思想は、大規模ソフトウェア開発のデファクトスタンダードであるMicrosoftのSDL（Security Development Lifecycle）^*1) や、アプリケーションセキュリティの専門コミュニティであるOWASP（Open Web Application Security Project）^*2) といった世界的なガイドラインで共通しています。

参照: Microsoft SDL Practices / OWASP Secure by Design Framework

ここでは、これらのグローバルな基準とも合致する、実務に適用しやすい「6つの基本方針」としてその要点を解説します。これらは、業種や規模を問わず、現代のIT製品・サービス開発においてすべての企業が共通して取り組むべきセキュリティ要件となります。

#	基本方針	概要	SbDにおける重要性 (設計思想の強調)
1.	予防的な対策の組み込み	インシデント発生を待つ事後的な対応ではなく、設計の初期段階から脅威を想定し予防的に対策を組み込む。	設計の基盤化（Be Explicit）の核心。脆弱性のリスクを早期排除する。
2.	全ライフサイクルの保護	企画から開発、運用、保守まで、全てのシステム開発ライフサイクルを通して一貫した対策を実施する。	DevSecOpsと合致。継続的なリスク評価と対応で、長期間の安全性を担保する。
3.	セキュア・バイ・デフォルト	システムの初期設定値が、最もセキュリティが担保された状態となるように設計・実現する。	セキュア・デフォルトの原則そのもの。設定ミスによる攻撃対象領域の拡大を防ぐ。
4.	システム特性に応じた過不足ない対策	システムの重要度に応じ、多層防御（Defense in Depth）の考えに基づいた適切なレベルの対策を実施する。	リスクベースの多層防御。リソースを効率的に配分し、攻撃成功を前提とした防御を実現する。
5.	リスクの評価・管理	セキュリティ対策の実施に留まらず、その充足性やリスクを継続的に評価・管理するための体制とプロセスを導入する。	信頼しない（Do Not Trust）というゼロトラストの思想に基づき、継続的な検証を義務付ける。
6.	利便性との両立	セキュリティ強化をしながらも利便性を損なわないように、最小権限の原則などを適用し、両方にとって利益がある状態を目指す。	フェイル・セキュアの思想も含め、セキュリティが業務効率の妨げになることを避け、対策の実用性と継続性を高める。

【 補足：セキュリティ・バイ・デザイン（SbD）の原則が要求する「安全性」】

これらの原則は、開発者が「安全をどのように定義し、実装するか」という設計思想を具体化するものです。

• 最小権限の原則を例にとると、Webアプリケーションのデータベース接続ユーザーに、必要な読み書き権限のみを与え、データベース構造を変更するような破壊的な権限を与えないことで、仮にアプリケーションが侵害されても致命的な被害を防ぐように設計します。
• フェイル・セキュアは、認証に失敗した場合に「アクセス拒否」という最も安全な結果をもたらすようにシステムを設計することで、機能的なエラーがセキュリティリスクに直結するのを防ぎます

*1) Microsoftのセキュリティ開発ライフサイクル（SDL） https://www.microsoft.com/en-us/securityengineering/sdl　
*2) OWASP Secure by Design Framework　https://owasp.org/www-project-secure-by-design-framework/

実践の第一歩 ～ 脅威モデリングによる「設計の可視化」

セクション2で確立したセキュリティ・バイ・デザイン (SbD) の「根本的な考え方」を、具体的な設計に落とし込むための最も重要な手法が脅威モデリング (Threat Modeling) です。

脅威モデリングの目的
脅威モデリングは、システムが完成してから脆弱性を見つけるのではなく、設計図の段階で潜在的なセキュリティ上の欠陥や攻撃経路を特定し、対策を組み込むための、SbD実践の第一歩となります。
主な目的は、「攻撃者がシステムで何をしたいか、そのためにどこを狙うか」を開発者視点で明確にし、対策をセキュリティ要件として定義することにあります。

要件への変換: 抽象的なセキュリティ原則（最小権限、多層防御など）を、具体的な実装タスクに変換します。

リスクの早期発見: 脆弱性の修正コストが最も低い、開発の初期段階（設計時）で問題を発見します。

脅威モデリングの手法はいくつかありますが、ここでは、SbDの設計思想を最もシンプルかつ体系的に具現化できるSTRIDEモデルを例としてご説明します。STRIDEモデルは、大規模ソフトウェア開発のデファクトスタンダードであるMicrosoft SDLで採用されている手法であり、「設計時」における脅威の網羅的な洗い出しに優れています。

脅威のカテゴリ	脅威の目的	セキュリティの欠陥
Spoofing (なりすまし)	認証の欠陥	ユーザーやプロセスが別人/別のシステムになりすます行為
Tampering (改ざん)	整合性の欠陥	データやシステムのコードを不正に変更する行為
Repudiation (否認)	否認防止の欠陥	操作の事実を否定できるようにする行為
Information disclosure (情報漏洩)	機密性の欠陥	機密データやシステム情報が外部に漏れる行為
Denial of service (サービス妨害)	可用性の欠陥	サービスを停止させたり、利用不能にしたりする行為
Elevation of privilege (権限昇格)	認可の欠陥	本来持たない上位の権限を獲得する行為

STRIDEは、「最小権限の原則」や「多層防御」といったSbDの普遍的な設計思想を、以下の手順で具体的な対策に変換します。

1. システム構成の図示（データフローダイアグラム）: まず、システムの構成要素（外部連携、データ保存場所、プロセス）を図示します。
2. 脅威の分類と適用: 図示された各要素に対し、STRIDEの6つの脅威カテゴリを一つずつ当てはめて、「この要素にはどのような脅威が存在するか」を網羅的に洗い出します。
3. セキュリティ要件への変換: 洗い出された脅威（例：「認証プロセスでなりすましが起こる」）を回避するための具体的な対策（例：「多要素認証の実装」「最小権限のアカウント割り当て」）を決定し、それをセキュリティ要件として定義します。

この手法を用いることで、開発の初期段階でセキュリティを「設計」の一部として捉えることができ、「予防的な対策の組み込み」を確実に行うことが可能になります。

SbDの継続と証明：DevSecOpsとVantaによるコンプライアンスの自動化

設計段階でセキュリティ (SbD) を組み込んでも、システムのリリース後、運用中に設定が変更されたり、新たな脆弱性が発見されたりすれば、安全性が損なわれます。

そこで必要となるのが、開発 (Dev) 、セキュリティ (Sec) 、運用 (Ops) を統合したDevSecOpsの体制です。DevSecOpsは、SbDの思想をシステム開発ライフサイクル全体で継続させるための、具体的なプロセスと自動化のフレームワークです。

DevSecOpsによる継続的なSbDの実践

DevSecOpsでは、以下の活動を自動化・継続化することで、SbDの原則が運用フェーズでも守られるようにします。

1. 静的/動的分析 (SAST/DAST) の自動化:
   • コードレビューやテスト段階で、SAST (Static Application Security Testing / 静的アプリケーションセキュリティテスト) や DAST (Dynamic Application Security Testing / 動的アプリケーションセキュリティテスト) をCI/CDパイプラインに組み込み、脆弱性の作り込みを自動でチェックします。
2. 構成管理と変更管理:
   • 「セキュア・バイ・デフォルト」で設定した安全な初期状態（例：最小権限のクラウド設定、暗号化設定）が、運用中の設定変更によって意図せず緩んでいないかを継続的に監視します。
3. 脆弱性対応の迅速化:
   • ソフトウェアのライフサイクル全体で、新たな脆弱性情報（CVEなど）を継続的に監視し、インシデント発生を想定した迅速なパッチ適用やアップデートを可能にする体制を整えます。

Vantaによる「セキュリティ実践の自動証明」

設計と実装がセキュアであっても、企業には、その安全性が継続していることを客観的に証明する責任が伴います。この証明のプロセスを自動化するのが、Vantaのようなコンプライアンス自動化ツールです。

• コンプライアンスとは: SOC 2やISO 27001といったセキュリティ基準は、SbDの思想（最小権限、多層防御、リスク管理）が組織全体で継続的に実行されていることを要求します。
• Vantaの機能: Vantaは、クラウド環境、コードリポジトリ、人事システムなどと連携し、SbDの原則が守られていることを示す証拠（エビデンス）を自動的かつ継続的に収集します。

監査項目（SbDの原則）	Vantaによる証明
1. 予防的な対策の組み込み	脆弱性スキャナーとの連携により、設計後の脆弱性が期日内に修正されている継続的な記録を提示。
2. 全ライフサイクルの保護	全従業員が最新のセキュリティトレーニングを完了している継続的な記録。
3. セキュア・バイ・デフォルト	クラウド設定監視（CSPM）により、システム設定が常に安全な初期状態にあることの継続的な証拠。
4. システム特性に応じた過不足ない対策	是正措置の自動追跡機能により、リスクレベルに応じた脆弱性対応が定期的に実行されている証拠。
5. リスクの評価・管理	アクセス権の定期的なレビューの記録や、リスクの継続的な評価プロセスが機能している継続的な証拠。
6. 利便性との両立	最小権限の原則に基づき、従業員のアクセス権限が適切に設定・管理されているリストと定期的なレビューログ。

Vantaを活用してSbDを「信頼の証」へ変える

これまで、セキュリティ・バイ・デザイン (SbD) の思想から具体的な手法（脅威モデリング）、そしてVantaを使用した継続的な証明に至るまでを解説してきました。

SbDの導入は、単なるセキュリティ対策ではなく、企業に以下の決定的なビジネス上の優位性をもたらします。

SbDの実践がもたらす3つの価値

1. グローバル標準への適合とビジネスの信頼獲得

• 設計基準への適合: MicrosoftのSDLやOWASPといったグローバルなデファクトスタンダード を開発プロセスに織り込むことで、「設計から安全」を追求する組織姿勢を対外的にアピールできます
• 顧客・パートナーからの信頼獲得: サプライチェーン攻撃が深刻化する中 、自社のシステムや製品が確かなセキュリティ要件を満たしていることを証明できれば、B2B取引における強力な信頼の証（トラスト・シグナル）となり、競合他社に対する決定的な差別化要因になります。

2. 脆弱性のコストを「予防的投資」へ転換

• 手戻りの劇的削減: 脆弱性の修正コストが最も低くなる設計初期に脅威モデリングを実施することで、開発終盤での大規模な手戻りや納期遅延を防止します。これにより、セキュリティへの投資を、非効率な対応費用ではなく、将来のリスクを防ぐ予防的投資へと転換できます。

3. Vantaによる「継続的な証明」と市場での優位性

• 監査工数の削減: Vantaのようなコンプライアンス自動化ツールを活用し、SbDの原則が運用中も継続的に守られている証拠を自動で収集することで、監査対応やコンプライアンス維持にかかる工数を劇的に効率化します。
• 「信頼の証」の獲得: 監査や認証を迅速にクリアできる体制は、市場において「信頼性の高い企業」という優位性をもたらします。

次の一歩を踏み出すために

セキュリティ・バイ・デザインは、もはや「あれば良い」ものではなく、「設計から安全」を実現することでリスクを減らし、信頼性を高める、現代ビジネスにおける必須の戦略です。

このSbDの思想を「継続的な証明」という形で実現するためには、DevSecOpsとコンプライアンス自動化が不可欠です。

まずは、SbDの原則がコンプライアンス基準に則って実現されている証拠を自動で収集し、監査対応工数を劇的に効率化するVantaについて、詳しく資料請求またはお問い合わせから始めてみませんか？