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

開発(ADV)

附属書A 開発(ADV) (参考)

510 この附属書は、ADV: 開発クラスのファミリで提示されたトピックをさらに説明して追加の例 を提供するための補助資料を記載する。

518 自己保護と同様に、一部のTOEの本質が、TSFの非バイパス性において役割を果たすた めにそれらの環境に依存する場合がある。例えば、セキュリティアプリケーション TOEは、

下層のオペレーティングシステムに呼び出される必要がある。同様に、ファイアウォールは、

内部及び外部のネットワーク間に直接の接続がないこと、及びそれらのネットワーク間の すべてのトラフィックがファイアウォールを通る必要があるという事実に依存する。

A.1.2 セキュリティアーキテクチャ記述

519 セキュリティアーキテクチャ記述は、上記の特性がTSFでどのように示されるかについて説 明する。ドメインがどのように定義され、TSF がそれらのドメインをどのように分離するかに ついて記述する。信頼できないプロセスが TSF にアクセスして変更することをどのようなこ とによって回避するかについて記述する。TSF の制御下にあるすべての資源が適切に保 護され、SFRに関連するすべてのアクションがTSFによって仲介されることをどのようなこと によって保証するかについて記述する。環境がこれらのいずれかにおいて果たす役割(例 えば、下層環境によって正しく呼び出されることを想定した場合、セキュリティ機能がどの ように呼び出されるか)を説明する。

520 セキュリティアーキテクチャ記述は、分解された記述の観点でTSFの自己保護、ドメイン分 離、及び非バイパス性という TSF の特性を示す。この記述のレベルは、主張されている ADV_FSP、ADV_TDS及びADV_IMP要件に必要なTSF記述に対応するものである。

例えば、ADV_FSPが使用可能な唯一のTSF記述である場合は、TSFのあらゆる内部動 作の詳細を得られないため、有意義なアーキテクチャ設計を提供することが難しくなるで あろう。

521 ただし、TOE 設計が提供されていれば、最も基本的なレベル(ADV_TDS.1)であっても、

TSF を構成するサブシステムに関するある程度の情報が示され、それらがどのように動作 して自己保護、ドメイン分離、及び非バイパス性を実装するかが記述されているであろう。

例えば、TOE に対するおそらくすべての利用者相互作用は、その利用者のすべてのセ キュリティ属性を使用して利用者に代わって作動するプロセスを通じて行われるものに制 約される。セキュリティアーキテクチャ記述は、このようなプロセスがどのように発生し、その プロセスのふるまいが TSFによってどのように(TSFを破壊できないように)制約され、その プロセスのすべてのアクションが TSF によってどのように調停されるか(それによって TSF をバイパスできない理由を説明)などを記述するであろう。

522 提供される TOE 設計がより詳細である(例えばモジュールレベル)場合、あるいは実装表 現も提供される場合は、それに応じてセキュリティアーキテクチャ記述もより詳細になり、利 用者のプロセスがTSFプロセスとどのように通信するか、複数の異なる要求をTSFがどの ように処理するか、どのパラメタが渡されるか、どのようなプログラムによる保護が行われる か(バッファオーバーフロー防止、パラメタ境界チェック、チェック時/使用時についての チェックなど)が説明されるであろう。同様に、ST が ADV_IMP コンポーネントを主張して いるTOEは、実装固有の詳細が示されるであろう。

523 セキュリティアーキテクチャ記述で提供される説明は、それらの正確性をテストできるため の十分な詳細さであることが期待される。つまり、単純な主張(「TSFはドメインを分離する」

など)は、TSF が実際にドメインを作成して分離することを読者に納得させるために役立つ 情報を提供しない。

開発(ADV)

A.1.2.1 ドメイン分離

524 TOEが完全に自力でドメイン分離を示す場合、これをどのように達成するかについて直接

的に記述されるであろう。このセキュリティアーキテクチャ記述は、TSF で定義される各種 のドメイン、それらの定義方法(各ドメインにどの資源が割り当てられるか)、保護されない 資源をなくす方法、及びあるドメイン内の能動的なエンティティが、別のドメインの資源を 改ざんできないようにドメインを分離する方法を説明するであろう。

525 TOE がドメイン分離で役割を果たすために他の IT エンティティに依存する場合、その役

割の共有は明確にしなければならない。例えば、単なるアプリケーションソフトウェアであ るTOEは、TOEが定義するドメインを正しく具体化するために下層のオペレーティングシ ステムに依存する。つまり、TOE がドメインごとに個別の処理空間、メモリ空間などを定義 すれば、TOE は下層のオペレーティングシステムに依存して正しくかつ悪意なく動作する

(例えば、プロセスはTOEソフトウェアが要求した実行空間でのみ実行できる)。

526 例えば、ドメイン分離を実装するメカニズム(例えば、メモリ管理、ハードウェアが提供する 保護された処理モードなど)は、識別され、記述される。または、TSF はソフトウェアドメイン の分離の実装に寄与する(利用者のアドレス空間とシステムのアドレス空間を明確に区別 するなど)ソフトウェア保護構造やコーディング規則を実装する場合がある。

527 脆弱性分析及びテスト(AVA_VAN を参照)アクティビティには、TSF の監視または直接攻 撃を利用することで、記述されたTSFドメイン分離を打ち負かす試みが含まれる可能性が 高い。

A.1.2.2 TSF自己保護

528 TOEが完全に自力で自己保護を示す場合、この自己保護をどのように達成するかについ

て直接的に記述されるであろう。他の(利用者)ドメインから保護される TSF ドメインを定義 するためにドメイン分離を提供するメカニズムが識別及び記述されるであろう。

529 TOEが自己保護で役割を果たすために他のITエンティティに依存する場合、その役割の

共有は明確にしなければならない。例えば、単なるアプリケーションソフトウェアである TOE は、正しくかつ悪意なく動作するために下層のオペレーティングシステムに依存する。

つまり、アプリケーションはそれ自身を破壊する(例えば、実行可能コードまたはTSFデー タを上書きする)悪意のあるオペレーティングシステムから自分自身を保護できない。

530 セキュリティアーキテクチャ記述は、また TSF が利用者入力によって自分自身を破壊しな いように、TSFが利用者入力をどのように処理するかもカバーする。例えば TSF は、特権 の概念を実装し、特権モードのルーチンを使用して利用者データを処理することによって、

自分自身を保護することができる。TSF は、TSF コード及びデータを利用者コードやデー タから分離するためにプロセッサベースの分離メカニズム(例えば、特権レベルやリング)を 使用する場合がある。TSF は(おそらくは利用者のアドレス空間とシステムのアドレス空間 を明確に区別することにより)ソフトウェアの分離の実装に寄与するソフトウェア保護構造や コーディング規則を実装する場合がある。

531 低機能モード(例えば、設置者または管理者にのみアクセスできる単一利用者モード)で 立ち上げてから、評価されたセキュアな構成へ移行する(信頼できない利用者がログイン して、TOE のサービスや資源を利用できるモード)TOE の場合、セキュリティアーキテク チャ記述には、評価構成で実行されないこの初期化コードからTSFをどのように保護する かについての説明も含まれる。このようなTOEの場合、セキュリティアーキテクチャ記述で は、初期化中にのみ使用可能であるべきサービス(資源への直接アクセスなど)が評価構 成でアクセス可能になるのを回避するための説明がなされるであろう。また、TOE が評価 構成であるときに初期化コードが実行されるのを回避する方法についても説明するであろ う。

532 TSF が初期のセキュアな状態であると信じ込ませるような結果を招く改変を初期化プロセ

スが検出できるように、信頼できる初期化コードがどのように TSF(及びその初期化プロセ ス)の完全性を維持するかについても説明しなければならない。

533 脆弱性分析及びテスト(AVA_VANを参照)アクティビティには、TSFの改ざん、直接攻撃、

または監視を利用することで、記述された TSF 自己保護を打ち負かす試みが含まれる可 能性が高い。

A.1.2.3 TSFの非バイパス性

534 非バイパス性の特性は、実施メカニズムのバイパスを許可するインタフェースに関係する。

ほとんどの場合、この特性は実装によってもたらされる。つまりその実装では、オブジェクト をアクセスまたは操作するインタフェースをプログラマが作成する場合に、そのプログラマ が、オブジェクトに対する SFR 実施メカニズムの一部であるインタフェースを使用し、それ らのインタフェースを回避しないようにする責任を負う。そのため、非バイパス性に関する 記述では、2つの広範な領域を扱う必要がある。

535 第1の領域は、SFR 実施に対するインタフェースで構成される。これらのインタフェースの 特性は、それらを使用して TSF をバイパスできる操作やモードを含んでいないという点で ある。この決定を行うために、ADV_FSP 及び ADV_TDS の証拠を大いに使用できること は十分に考えられる。非バイパス性は重要な問題であるため、TSFIを通じて利用できる操 作の一部のみが(SFR 実施操作であるために)証拠資料として提出され、それ以外の操作 は証拠資料として提出されない場合は、TSFIのSFR支援及びSFR非干渉操作が、実施 されている方針をバイパスする能力を信頼できないエンティティに与えないことを決定する

ためにADV_FSP及びADV_TDSで提示された情報に対する追加情報が必要かどうかを、

開発者は考慮するべきである。このような情報が必要である場合は、セキュリティアーキテ クチャ記述にその情報が組み込まれる。

536 非バイパス性の第 2 の領域は、SFR 実施に関連しない相互作用を持つインタフェースに 関係している。主張されたADV_FSP及びADV_TDSコンポーネントによっては、これらの インタフェースに関する情報が、機能仕様及び TOE 設計証拠資料に存在する場合と存 在しない場合がある。このようなインタフェース(またはインタフェースのグループ)に対して 提示される情報は、実施メカニズムのバイパスが不可能であることを読者が(ADV: 開発ク ラスで提供されるその他の証拠と同等の詳細レベルで)決定できるほど十分な内容である べきである。