• 検索結果がありません。

A.4 ADV_TDS: サブシステム及びモジュール

A.4.2 モジュール

582 モジュールは、一般的に、TSF内部構造(ADV_INT)で説明される特性の観点から特徴を 表すことができる比較的小さいアーキテクチャの単位である。ADV_TDS.3 基本モジュー ル設計(またはそれ以上)の要件及びTSF内部構造(ADV_INT)の要件の両方がPPまた は ST に存在する場合、TOE 設計(ADV_TDS)の要件の観点での「モジュール」は、TSF

内部構造(ADV_INT)の要件に対する「モジュール」と、同じものを指す。サブシステムとは

異なり、モジュールは、実装表現のレビューに対するガイドとしての役割を果たすことがで きる詳細レベルで実装を記述する。

583 TOEによっては、モジュールとサブシステムが同じ抽象概念を指す場合があるので注意が

必要である。ADV_TDS.1基本設計とADV_TDS.2アーキテクチャ設計(モジュールレベル での記述を要求しない)の場合、サブシステム記述はTSFに関する最下位レベルの詳細を 提供する。ADV_TDS.3 基本モジュール設計(モジュール記述を要求する)の場合、これら の記述は最下位レベルの詳細を提供する一方で、サブシステム記述(別のものとして存在 する場合)は、単にモジュール記述の枠組みを示すために使用される。つまり、モジュール 記述が存在する場合は、詳細なサブシステム記述を提供する必要がない。きわめて単純 な TOE では、独立した「サブシステム記述」が必要ない。つまり、モジュールによって提供 される証拠資料で要件を満たすことができる。複雑なTOEでの(TSFに関する)サブシステ ム記述の目的は、読者がそれぞれの分析の焦点を適切に絞り込むことができるように枠組 みを提供することである。図21には、この違いが示されている。

開発(ADV)

584 SFR 実施モジュールは、ST のセキュリティ機能要件(SFR)を直接実装するモジュールで

ある。このようなモジュールは一般にSFR実施TSFIを実装するが、SFRで表現されてい る一部の機能性(例えば、監査機能やオブジェクト再使用機能性)が単一の TSFIに直接 結び付いていない場合がある。サブシステムの場合と同様に、SFR 支援モジュールは、

SFR 実施モジュールから依存されているが、SFR を直接実装する責任を負わないモ ジュールである。SFR 非干渉モジュールは、SFRの実施を直接的にも間接的にも扱わな いモジュールである。

585 「直接実装する」が何を意味するかの判断は、やや主観的になるので注意が必要である。

最も狭義には、要件を実装する比較やゼロ化操作などを実際に実行する1、2行のコード を意味すると解釈できる。解釈を広げると、SFR 実施 TSFI に応答して呼び出されるモ ジュール、及びそのモジュールによって呼び出されることがあるすべてのモジュール(呼び 出しが完了するまで続く)までが含まれるかもしれない。どちらの解釈も特に十分ではない。

なぜなら、最初の解釈は意味が狭いために、重要なモジュールが間違ってSFR支援と分 類される可能性があり、2番目の解釈では、実際にはSFR実施でないモジュールがSFR 実施と分類されてしまうからである。

586 モジュールの記述は、その記述からモジュールの実装を作成できるものであるべきであり、

その結果の実装は 1)モジュールによって提示及び使用されるインタフェースの観点から実 際の TSF 実装と同一であり、2)TSF モジュールとアルゴリズムが同一である。例えば、RFC 793はTCPプロトコルの上位レベル記述を提供する。これは、必ずしも実装には依存してい ない。これは、豊富な詳細を提供するが、実装の特定ではないため、適切な設計記述では ない。実際の実装は RFC で指定されているプロトコルを追加でき、実装の選択(例えば、実 装の様々な部分で、グローバルデータとローカルデータのどちらを使用するか)は実行され る分析に対して影響を与える可能性がある。TCPモジュールの設計記述は、(RFC 793で定 義されたインタフェースだけではなく)実装によって提示されるインタフェース、及び TCP を (TSF の一部であったと想定して)実装しているモジュールに関連する処理のアルゴリズム記 述をリストするであろう。

587 設計では、モジュールが提供する機能(目的)、モジュールが提示するインタフェース、そ れらのインタフェースからの戻り値、モジュールが使用するインタフェース(他のモジュール が提示)、及びモジュールがその機能性を提供する方法を示す記述の観点から、モジュー ルが詳細に記述される(機能性記述のひとつの手段は、アルゴリズム記述である)。

588 モジュールの目的は、モジュールが提供する機能を示しながら記述されるべきである。ま た、アーキテクチャにおけるモジュールの機能を読者が全般的に把握できるように十分に 記述されるべきである。

589 モジュールが提示するインタフェースは、提供されている機能性を呼び出すために他のモ ジュールが使用するインタフェースである。インタフェースには、明示的なインタフェース (例えば、他のモジュールによって呼び出されるコーリングシーケンス)及び暗黙のインタ フェース(例えば、モジュールによって操作されるグローバルデータ)の両方が含まれる。イ ンタフェースは、どのように呼び出されるかという観点から、及び戻されるすべての値の観 点から記述される。この記述には、パラメタのリスト、及びこれらのパラメタの記述が含まれ るであろう。あるパラメタが値のセット(例えば「フラグ」パラメタ)であることを期待されていた 場合、処理しているモジュールに影響を与えるパラメタがとり得る値の完全なセットが特定 されるであろう。同様に、データ構造を表すパラメタは、データ構造の各フィールドが識別 及び記述されるように記述される。グローバルデータについては、モジュールがそのデー タの読み取りと書き込みのどちら(または両方)を行うかが記述されるべきである。

590 プログラミング言語によっては、明白とはならない追加の「インタフェース」を持つ可能性が ある。この例として挙げられるのは、C++における演算子/関数のオーバーロードがあるだろ う。クラス記述におけるこの「暗黙のインタフェース」は、モジュール設計の一部としても記 述されるであろう。モジュールは 1つのインタフェースのみを提示する可能性があるが、関 連するインタフェースの小規模なセットをモジュールが提示することのほうがより一般的で ある。

591 それとは対照的に、あるモジュールが使用するインタフェースは、その記述されているモ ジュールによってどのモジュールが呼び出されているかを決定できるように識別されなけ ればならない。設計記述から、呼び出されるモジュールがコールされるアルゴリズム上の 理由も明確でなければならない。例えば、モジュール A が記述されており、それがモ ジュールBのバブルソートルーチンを使用する場合、「モジュールAは、モジュールB内 の double_bubble()インタフェースを呼び出してバブルソートを実行する」は不適切なアル ゴリズム記述であろう。適切なアルゴリズム記述は、「モジュール Aは、アクセス制御エント リのリストを渡してdouble_bubbleルーチンを呼び出し、double_bubble()は、最初に利用者 名でソートされたエントリを戻してから、次の規則に従って access_allowed フィールドで ソートされたエントリを戻し...」となるであろう。設計におけるモジュールの詳細な記述は、

モジュールAがバブルソートインタフェースから期待する効果が明確となるように十分な詳 細を提供しなければならない。これらコールしたインタフェースを提示する 1 つの方法は コールツリーを介した方法であり、それにより、アルゴリズム記述はコールされたモジュー ルのアルゴリズム記述に含めることができる。

592 すでに説明したように、モジュールのアルゴリズム記述は、アルゴリズム方式でモジュール の実装を記述するべきである。これは、擬似コード、フローチャート、または(ADV_TDS.3 基本モジュール設計での)非形式的説明文で実現することができる。この記述では、モ ジュール入力と呼び出される関数をどのように使用してモジュールの機能が達成されるか が説明される。また、グローバルデータ、システム状態、モジュールによって生成される戻 り値に対する影響について言及する。この記述は、TOE の実際の実装にきわめて似た実 装を導き出せる程度の詳細レベルにある。

593 ソースコードは、モジュール証拠資料の要件を満たさないことに注意するべきである。モ ジュール設計は実装を記述するが、実装そのものではない。ソースコードの周囲にあるコ メントがソースコードの意図を説明している場合は、それらが十分な証拠資料となることが ある。単に各コード行の処理内容を記述するインラインコメントは、モジュールが達成する べき内容を説明しないので役に立たない。

594 以下のエレメントでは、サブシステムとモジュールについて検討されたラベル(SFR 実施、

SFR 支援、及び SFR 非干渉)が、開発者が提供する必要がある情報の量とタイプを記述 するために使用される。エレメントは、開発者が特定された情報のみを提供することを期待 しないように構成されている。つまり、開発者が提供するTSFの証拠資料が以下の要件の 情報を提供する場合、開発者が自らの証拠資料を更新し、サブシステムとモジュールを SFR実施、SFR支援、またはSFR非干渉とラベル付けすることは期待されない。このラベ ル付けの主な目的は、成熟した開発方法(及び詳細なインタフェース及び設計証拠資料 などの関連する資料)を確立していない開発者が、過度なコストをかけずに必要な証拠を 提供できるようにすることである。

開発(ADV)