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

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

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

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

各プロジェクト・チームが独自のセキュリティ機能(認証、役割管理、鍵管理、監査/ログ、暗号化、プロトコルなど)を実装するのではなく、SSGがセキュリティのクリアリングハウスとしての役割を果たし、開発グループが使用できるよう事前予防に対するガイダンスを提供します。これらの機能は、SSGまたは専門の開発チームが行うコード・レビュー中に検出される場合や、クラウド・サービス・プロバイダーなどのベンダーが提供するライブラリに含まれている場合があります。市販のセキュリティ機能は、多くの場合、特定のプラットフォーム用にカスタマイズされています。モバイル暗号化機能の場合、少なくともAndroid とiOSの2つのバージョンが必要になり、クラウドのID管理の場合、AWS、Google、Azureに固有のバージョンが必要になる可能性があります。プロジェクト・チームには、SSGによって事前に承認された実装を使用するという利点があり、SSGは、セキュリティ機能に潜んでいることが多い、細微なエラーを繰り返し追跡する必要がないという利点があります。

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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