Loading article…
‹テンプレート How-toは統合が検討されています。›
ソフトウェア エンジニアリングにおける「設計によるセキュリティ」とは、ソフトウェア製品と機能が根本的に安全になるように設計されていることを意味します。
ソフトウェア設計の初期段階では、代替のセキュリティ戦略、戦術、パターンが検討され、アーキテクチャによって最適なものが選択され、実施され、開発者の指針として使用されます。[1]また、セキュリティを考慮して考案されたものではない設計パターンであっても、セキュリティに有益な効果をもたらす戦略的な設計パターンを使用することが推奨されています。 [2]
セキュア バイ デザインは、ソフトウェア システムのセキュリティとプライバシーを確保するための開発アプローチとして、ますます主流になりつつあります。このアプローチでは、セキュリティはあらゆるレイヤーで考慮され、システムに組み込まれ、堅牢なアーキテクチャ設計から始まります。セキュリティ アーキテクチャ設計の決定は、特定の品質上の懸念事項を達成するための再利用可能な手法として定義された、よく知られたセキュリティ戦略、戦術、パターンに基づいています。セキュリティ戦術/パターンは、システムが攻撃を受けている場合でも、必要な認証、承認、機密性、データ整合性、プライバシー、説明責任、可用性、安全性、否認不可性の要件を実施するためのソリューションを提供します。 [3] ソフトウェア システムのセキュリティを確保するには、意図した堅牢なセキュリティ アーキテクチャを設計することが重要であるだけでなく、セキュリティの永続性を維持するために、更新されたセキュリティ戦略、戦術、パターンをソフトウェア開発にマッピングすることも必要です。
攻撃を予想する
ソフトウェアに対する悪意のある攻撃が発生することを想定して、影響を最小限に抑えるよう注意する必要があります。セキュリティの脆弱性や無効なユーザー入力が予想されます。[4]これに密接に関連しているのは、ドメイン駆動設計やクラウドネイティブなどの「優れた」ソフトウェア設計を使用して、脆弱性を生じさせるミスのリスクを軽減することでセキュリティを強化する方法ですが、使用される設計原則はもともとセキュリティ目的で考案されたものではありません。
隠蔽によるセキュリティ回避
一般的に、うまく機能する設計は、秘密であることに依存しません。多くの場合、秘密にすることで、脅威となる集団の一部をやる気にさせず、攻撃者の数を減らすことができます。その論理は、攻撃者にとって複雑さが増すと、ターゲットを侵害するための攻撃者の努力が増え、攻撃者がやる気を失うというものです。この手法は固有のリスクの軽減を意味しますが、時間の経過とともに事実上無限の脅威アクターと手法が適用されるため、ほとんどの秘密保持方法は失敗します。必須ではありませんが、適切なセキュリティは通常、設計が安全であるため、誰もがそれを知り、理解できることを意味します。これには、多くの人がソースコードを見ているという利点があり、欠陥が早く見つかる可能性が高くなります ( Linus の法則を参照)。欠点は、攻撃者もコードを入手できるため、悪用する脆弱性を見つけやすくなることです。ただし、一般には、オープンソースコードの利点が欠点を上回ると考えられています。
最も少ない権限
また、すべてが可能な限り最小限の権限で動作することも重要です(最小権限の原則を参照)。たとえば、管理ユーザー(「root」または「admin」)として実行されるWeb サーバーは、ファイルとユーザーを削除する権限を持つことができます。したがって、このようなプログラムに欠陥があると、システム全体が危険にさらされる可能性があります。一方、隔離された環境内で実行され、必要なネットワークおよびファイルシステム機能の権限のみを持つWeb サーバーは、その周囲のセキュリティ自体にも欠陥がない限り、実行されるシステムを危険にさらすことはできません。
方法論
セキュアな設計は、開発ライフサイクルのすべてのポイントで考慮する必要があります (どの開発方法論を選択した場合でも)。 事前に構築されたセキュア バイ デザイン開発方法論がいくつか存在します (例: Microsoft セキュリティ開発ライフサイクル)。
基準と法律
標準と法律は、「安全」の定義を管理し、安全なシステムをテストおよび統合するための具体的な手順を提供することで、安全な設計を支援するために存在します。
Secure By Design の原則をカバーまたは関連する標準の例をいくつか示します。
- ETSI TS 103 645 [5]は、英国政府の「消費者向けスマート製品のサイバーセキュリティ規制に関する提案」 [6]に一部含まれています。
- ISO/IEC 27000 シリーズは、安全な設計の多くの側面をカバーしています。
サーバー/クライアントアーキテクチャ
サーバー/クライアント アーキテクチャでは、相手側のプログラムが承認されたクライアントではない可能性があり、クライアントのサーバーが承認されたサーバーではない可能性があります。承認された場合でも、中間者攻撃によって通信が危険にさらされる可能性があります。
多くの場合、クライアント/サーバー システムのセキュリティを破る最も簡単な方法は、セキュリティ メカニズムに正面から取り組むのではなく、それを迂回することです。中間者攻撃は、ユーザーになりすますための詳細情報を収集するために使用できるため、この単純な例です。そのため、潜在的な攻撃者から収集された情報にアクセスできないように、暗号化、ハッシュ化、およびその他のセキュリティ メカニズムを設計に考慮することが重要です。
クライアント サーバー セキュリティ設計のもう 1 つの重要な特徴は、適切なコーディング プラクティスです。たとえば、クライアントとブローカーなどの既知のソフトウェア設計構造に従うと、強固な基盤を持つ適切に構築された構造を設計するのに役立ちます。さらに、将来ソフトウェアを変更する場合は、クライアントとサーバーを分離するという論理的な基盤に従うことがさらに重要になります。これは、プログラマーが参加してプログラムのダイナミクスを明確に理解できない場合、セキュリティ上の欠陥をもたらす可能性のあるものを追加または変更してしまう可能性があるためです。最高の設計であっても、これは常に起こり得ますが、設計の標準化が進むほど、これが発生する可能性は低くなります。
参照
参考文献
- ^ Santos, Joanna CS; Tarrit, Katy; Mirakhorli, Mehdi (2017).セキュリティアーキテクチャの弱点のカタログ。2017 IEEE 国際ソフトウェアアーキテクチャワークショップ会議 (ICSAW)。pp. 220–223。doi :10.1109 / ICSAW.2017.25。ISBN 978-1-5090-4793-2. S2CID 19534342。
- ^ ダン・バーグ・ジョンソン;ダニエル・デオガン;ダニエル・サワノ (2019)安全な設計。マニング出版物。ISBN 9781617294358。
- ^ Hafiz, Munawar; Adamczyk, Paul; Johnson, Ralph E. (2012 年 10 月)。「パターン言語の成長 (セキュリティ用)」。プログラミングとソフトウェアに関する新しいアイデア、新しいパラダイム、考察に関する ACM 国際シンポジウムの議事録。pp. 139–158。doi : 10.1145 / 2384592.2384607。ISBN 9781450315623. S2CID 17206801。
- ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (2009 年 10 月)。セキュア デザイン パターン(技術レポート)。ソフトウェア エンジニアリング研究所。doi :10.1184/ R1 /6583640.v1。技術レポート CMU/SEI-2009-TR-010。
- ^ 「CYBER; 消費者向け IoT 向けサイバーセキュリティ」(PDF)。ETSI TS 103 645。
- ^ 「政策文書：消費者向けスマート製品のサイバーセキュリティを規制するための提案 - 意見募集」。
外部リンク
- Linux および Unix 向けのセキュア プログラミング HOWTO
- セキュア UNIX プログラミング FAQ
- 安全なコーディングの実践トップ 10
- セキュリティバイデザインの原則