セキュリティ・バイ・デザイン
From Wikipedia, the free encyclopedia
原則と目的
セキュリティ・バイ・デザインは、ソフトウェア開発初期フェーズ、すなわち設計・アーキテクチャ構築の時点でセキュリティ要件を組み込むことを中核とする。これは、開発の終盤やリリース後に脆弱性が発見されてから修正を行う従来のアプローチとは対照的である。
このアプローチでは、ソフトウェア設計の初期段階で代替的なセキュリティ戦略、戦術、パターンが検討され、その中から最良のものが選択される。選択されたセキュリティ設計はアーキテクチャによって強制され、開発者全体の指針として用いられる[1]。また、元々はセキュリティを直接の目的として考案されたものではないデザインパターンであっても、結果としてセキュリティに有益な効果をもたらす戦略的デザインパターンを使用することも推奨される。
セキュリティ・バイ・デザインは、ソフトウェアシステムのセキュリティとプライバシーを確保するための主流な開発アプローチになりつつある。このアプローチでは、セキュリティは単一の機能としてではなく、システムのあらゆる層で考慮・構築され、堅牢なアーキテクチャ設計から始まる[2]。
セキュアバイデザインにおけるアーキテクチャの設計は、既知のセキュリティ戦略、戦術、およびパターンに基づいて行われる。これらは、特定のセキュリティ品質要件を満たすための再利用可能な技術として定義される[3]。セキュリティ戦術とパターンは、システムがサイバー攻撃を受けている状況下でも、以下の要件を満たすためのソリューションを提供する。
- 認証 (Authentication)
- 認可 (Authorization)
- 機密性 (Confidentiality)
- データ完全性 (Data integrity)
- プライバシー (Privacy)
- 説明責任 (Accountability)
- 可用性 (Availability)
- 安全性 (Safety)
- 否認防止 (Non-repudiation)
セキュリティの持続性
ソフトウェアシステムのセキュリティを確保するためには、初期段階で堅牢なセキュリティアーキテクチャを設計することが不可欠である。それに加え、新たな脅威や技術の進化に対応するため、常に更新されたセキュリティ戦略、戦術、パターンをソフトウェア開発プロセスに反映し続け、システムのライフサイクル全体で、セキュリティの持続性を維持する[4]。
攻撃の想定
ソフトウェアに対する悪意のある攻撃は発生するものと想定し、その影響を最小限に抑えるようにするべきである。無効なユーザー入力とともに、セキュリティ上の脆弱性も予期しておく必要がある[5]。これと密接に関連するのが、ドメイン駆動設計やクラウドネイティブのような「優れた」ソフトウェア設計を、脆弱性を生み出すミスを減らすことで、セキュリティを向上させる手段として用いるという実践である。
最小権限
可能な限り最小の権限で動作することが重要である（最小権限の原則を参照）。例えば、管理者ユーザー（「root」や「admin」）として実行されるWebサーバは、ファイルやユーザーを削除する権限を持つことができる。このようなプログラムの欠陥は、システム全体を危険にさらす可能性がある。一方、隔離された環境内で実行され、必要なネットワーク機能とファイルシステム機能に対する権限しか持たないWebサーバは、それ自体の周囲のセキュリティにも欠陥がない限り、実行されているシステムを侵害することはできない。
方法論
セキュアな設計は、（どの開発方法論が選択されたとしても）開発ライフサイクル中に考慮されるべきである。セキュアバイデザインを組み込んだ開発方法論もいくつか存在する（例：Microsoft Security Development Lifecycle）。
設計の公開性
セキュア・バイ・デザインの原則において、堅牢なセキュリティ設計は隠蔽によるセキュリティ（英語: Security through obscurity）に依存しないことが一般的である。
隠蔽によるセキュリティの論理と限界
隠蔽によるセキュリティとは、システムの内部構造やアルゴリズム、ソースコードなどを意図的に秘密にすることで、攻撃対象となることを防ごうとする防御手法である。その論理は、攻撃者にとっての解析の複雑さを増大させ、標的を侵害するための労力を引き上げることで、攻撃を思いとどまらせるという点にある。この手法は、攻撃者の母数を減らし、内在するリスクを一時的に低減させる効果は持つものの、本質的な安全性を保証するものではない。無数に存在する攻撃者と、時間と共に進歩する解析技術が適用されることで、ほとんどの秘密保持は失敗に終わる可能性が高いとされる。
設計の公開性とケルクホフスの原理
対照的に、優れたセキュリティ設計とは、その設計内容が公知のものとなっても、なお安全性が損なわれない状態を指す。これは、暗号学におけるケルクホフスの原理、すなわち「暗号方式は、秘密鍵以外の全てが公になったとしても安全であるべき」という考え方にも通じる。設計そのものが堅牢であるため、隠す必要がないのである。
このアプローチには、以下のような利点と欠点が存在する。
- 利点: ソースコードのような設計情報を公開することで、世界中の多くの開発者や研究者がそれを検証できる。これにより、欠陥や脆弱性がより迅速に発見・修正される可能性が高まる。この効果は、オープンソース開発における経験則として知られるリーナスの法則（「十分な目があれば、すべてのバグは洗い出される」）によっても支持されている。
- 欠点: 攻撃者も同様に設計情報へアクセスできるため、悪用可能な脆弱性を探索することが容易になるという側面も持つ。
しかし、情報セキュリティの分野では、設計を公開し多くの専門家によるレビューを受けることの利点は、攻撃者に情報を与えるという欠点を上回ると広く考えられている。