セキュリティ機能および設計

セキュリティ機能および設計では、主なセキュリティ制御(標準および要件プラクティスで定義された標準に適合する)のために使用できるセキュリティ・パターンを作成し、これらの統制のためのミドルウェア・フレームワークを構築し、その他の事前予防的なセキュリティ・ガイダンスの作成と公開を行います。

セキュリティ機能および設計レベル1

[SFD1.1: 95] セキュリティ機能の構築と公開。

問題の中には、解決策を共有できるものがあります。セキュリティ機能(認証、役割管理、鍵管理、監査/ログ、暗号化、プロトコルなど)のすべてを各プロジェクト・チームが実装するのではなく、SSGは他のグループが使用できるようセキュリティ機能を構築、公開して事前予防に対するガイダンスを提供します。市販のセキュリティ機能は、多くの場合、モバイルなどの特定のプラットフォーム用にカスタマイズされています。たとえば、低レベルのシステム呼び出しを使用しているモバイル暗号化機能の場合、少なくともAndroid とiOSの2つのバージョンが必要です。プロジェクト・チームには、SSGによって事前に承認された実装を使用するという利点があり、SSGは、セキュリティ機能に潜んでいることが多い、細微なエラーを繰り返し追跡する必要がないという利点があります。SSGは、選択した実装を、承認されたソリューションとして推奨できます。

[SFD1.2: 70] SSGがアーキテクチャに関与している。

セキュリティは、組織のソフトウェア・アーキテクチャに関する議論で常時議題になります。アーキテクチャ・グループは、パフォーマンス、可用性、スケーラビリティと同様にセキュリティに対しても責任を持ちます。セキュリティが討議の議題から漏れないようにする1つの方法は、アーキテクチャ会議にSSGメンバーが定期的に出席することです。また、企業アーキテクトからの支援を受けて、SSGが、企業設計標準に適切に統合できる、セキュリティ上安全な設計を構築することができます。SSGが早期から関わることが成功の鍵となります。たとえば、既知のシステムをクラウドに移動した場合は、SSGが再度参加する必要があります。安全であると推測してはなりません。  

 

セキュリティ機能および設計レベル2

[SFD2.1: 34] セキュリティ上安全な設計のミドルウェア・フレームワークと共通ライブラリを構築する。

SSGは、セキュリティ上安全な設計のミドルウェア・フレームワークと共通ライブラリのための指針を作成し、提供することにより、ソフトウェア設計に事前予防的な役割を果たします。このミドルウェアの構成要素を使用すると、例示による学習に加え、エラーが発見しやすくなるため、アーキテクチャ解析やコード・レビューを支援します。たとえば、SSGは、入力検証要件に簡単に適合できるよう、Springなどのよく使用されるWebフレームワークを変更できます。最終的には、提供するコンポーネント用にコード・レビューのルールをカスタマイズできます([CR3.1 カスタマイズしたルールで自動化されたツールを使用している]を参照)。ミドルウェア・フレームワーク(または他の一般的に使用されているソフトウェア)を採用する場合は、公開前にセキュリティを入念に検査することが重要です。既存のコンポーネントの採用を奨励し、セキュリティ上問題のあるミドルウェアを使用すると、ソフトウェア・セキュリティ状況は好転しません。OWASP ESAPIなどの汎用オープンソース・ソフトウェア・セキュリティ・アーキテクチャは、セキュリティ上安全な設計とはいえません。最後にライブラリを呼び出してセキュリティ対策ができたとするのは、セキュリティ上安全な設計方法とは呼べません。

[SFD2.2: 46] 困難な設計問題を解決するSSG能力を開発する。

SSGが新しいプロジェクト・プロセスに早期から参加していれば、新しいアーキテクチャに貢献して、困難な設計の問題を解決できます。他の制約(市場投入時期、価格など)にセキュリティが及ぼす影響を最低限に抑えられます。高度な技術を持つSSGからのセキュリティ・アーキテクトが、新しいプロトコルの設計に参加していれば、既存のプロトコルのセキュリティ上の意味を分析し、廃止または使用を回避すべき要素を特定できます。同様に、セキュリティ・アーキテクトが、一見よく理解されているアプリケーションをクラウドに移行することのセキュリティ上の意味を理解していれば、後で問題が発生して対応に追われなくてすみます。セキュリティを当初から念頭に入れて設計すれば、不具合が見つかってから既存の設計のセキュリティを分析しリファクターリングを行うより、はるかに効率的です。どれほど優秀な専門家でも、ソフトウェア製品群全体のニーズに対応することはできません。設計の問題の中には、SSGの専門外の特別な専門知識が必要な場合もあります。  

セキュリティ機能および設計レベル3

[SFD3.1: 9] セキュリティ上安全な設計パターンを承認し管理する、審査委員会または中央委員会が形成されている。

審査委員会または中央委員会は、設計上のニーズとセキュリティの間のトレードオフに関する合意に達するプロセスを形式化します。アーキテクチャ委員会とは異なり、このグループはセキュリティ・ガイダンスを提供することに特化し、設計に関する決定が無効、または時代遅れになっていないか、すでに公開された設計標準(特に暗号化に関する)を定期的に審査します。さらに、審査委員会は、開発部門がSSGを無視して暴走し混沌としかねない、新しいテクノロジーの導入時にも、影響力を持ちます。

[SFD3.2: 9] 承認されたセキュリティ機能とフレームワークの使用を必須としている。

実装者は、承認済みリストに記載されているセキュリティ機能やフレームワークのみを使用できます。このアクティビティには2つの利点があります。1つは、開発者がすでにある機能を再発明するために時間を浪費しないこと、2つ目は、新規のプロジェクトや新しいプラットフォームが採用された場合に、過去にあった同じ不具合を特定して審査チームが論争しなくてすむことです。特に、証明済みのコンポーネントを使用するプロジェクトが増えれば、アーキテクチャ分析やコードが簡易化できます([AA1.1 セキュリティ機能のレビューを実行する]を参照)。再利用は、一貫性のあるソフトウェア・アーキテクチャの主な利点であり、これはとくにアジャイル開発やCI/CDパイプラインの速度確保に有効です。

[SFD3.3: 2] 組織から成熟した設計パターンを特定し公開している。

SSGは、組織全体から設計パターンを収集し、全従業員が利用できるよう公開することによって、中央管理された設計の再利用を促進します。SSGのWebサイトのセクションで、アーキテクチャ分析中に特定された有効な要素を奨励すれば、有効な案を普及できます。このプロセスは公式化される必要があります。臨時の、単発的な通知では不十分です。このアクティビティは、中央アーキテクチャやテクノロジー・チームが支援したり強化できます。共通の設計パターンがあれば、ソフトウェア開発の時間が短縮できます。セキュリティ上安全な設計パターンは、アプリケーションだけでなく、マイクロサービス、API、フレームワーク、インフラストラクチャ、自動化など、すべてのソフトウェアに使用する必要があります。