14.1. 統合 TOE
TOE の運用環境では、大半の TOE が他の IT 製品やシステムと相互作用する。こういった TOE は、SFR を満足さ せる IT 製品やシステムによるサポートが必要な場合が多い。この簡単な例が、下位層のオペレーティングシステムを ベースにしたファイルの保護、アドレス空間の分割や利用者認証機能に依存するデータベースシステムの TOE であ る。もう 1 つの例は、認証用にデジタル認証や証明書失効リストを保存する外部の LDAP サーバに依存するオペレ ーティングシステムである。このオペレーティングシステムは、こういったデジタル認証や証明書失効リストを生成し、
LDAP サーバを通じて時機的な方法でこれらを公開する外部の PKI（システム）にも依存している。この 2 つの例を 組み合わせて、（利用者を認証する場合、実際に TOE が依存するのはオペレーティングシステムであっても）データ ベース管理システムも、利用者の認証時には LDAP サーバと PKI システムに依存することになる。また、この例は、
利用者の認証手続きの中で用いられるスマートカードにも簡単に応用することができる。この場合、上の例のような TOE との依存関係はスマートカード上に存在するが、スマートカードを個別化するシステム上にも存在する。
これらの例は、一見したところ単純な SFR（この場合は、利用者認証）が、個別に評価することができる多くの IT 製 品による正しくセキュアな協調を必要とすることを示すものである。本章では、TOE の SFR を定める際に生ずる問 題点との関連で、IT 製品を組み合わせることによって満足される SFR の問題点を扱うための TOE 環境のセキュリ ティ対策方針について説明する。
上述の例には、次のような依存性が確認できる：
－ データベースの管理システムは、利用者認証、ファイルの保護やアドレス空間の分割に依存している。
－ オペレーティングシステムは、アドレス空間の分割や、特権が付与されていないプログラムに付加されている I/O デバイスやプロセッサ専用構成レジスタによる直接的なアクセスから保護するハードウェアに依存している。
－ オペレーティングシステムは、利用者認証に用いられる情報を不正なアクセスから保護する LDAP サーバに依 存している。また、このシステムでは、LDAP サーバが、リクエストに応じて時機的な方法で情報を提供する場 合にも、LDAP サーバとオペレーティングシステムとの間で転送される情報が検知できない方法で改ざんされな いように保護している。
－ オペレーティングシステムは、認証に関連のある利用者の適切な情報に基づいてデジタル認証を生成し、
（LDAP サーバ上の証明書と証明書失効リストの時機的な公開も含め）これらの認証を適切に管理するため に、PKI（システム）に依存している。
－ オペレーティングシステムは、利用者のプライベート鍵を保護し、正しい認証情報（例えば、PIN）を受信したの ちにその鍵のみを用いることができるスマートカードに依存している。
- スマートカードは、利用者が PIN を入力してから、スマートカードに転送され、オペレーティングシステムのメモリか ら PIN が安全に消去されるまで、利用者の PIN を保護するためにオペレーティングシステムに依存している。スマ ートカードは、例えば、許可されていない利用者が PIN を入力した場合など、PIN が悪用されないようにオペレ ーティングシステムに依存している。
これらは単に、PP、または ST で上述の例にあった依存性をどのように対処することができるかを示すリストとして用 いたに過ぎない。
依存性を特定するための簡単な方法が以下である：
－ データベースが、自身にセキュリティ機能を提供するために、オペレーティングシステムに依存している。
－ オペレーティングシステムが、ハードウェアに依存している。
－ オペレーティングシステムが、LDAP サーバに依存している。
－ オペレーティングシステムが、PKI システムに依存している。
－ オペレーティングシステムが、スマートカードに依存している。
－ スマートカードが、オペレーティングシステムに依存している。
1 つのコンポーネントが、別のコンポーネントに依存している場合、ISO/IEC 15408 では、前者は「依存コンポーネン ト」、後者は「基本コンポーネント」と呼ぶ。データベースとオペレーティングシステムを組み合わせた上述の例では、デ ータベースが依存コンポーネントであり、オペレーティングシステムが基本コンポーネントに当たる。同様に、オペレーテ ィングシステムとハードウェアの組み合わせでは、オペレーティングシステムが依存コンポーネントであり、ハードウェアが 基本コンポーネントである。スマートカードとオペレーティングシステムの場合は、双方のコンポーネントが相互に依存 しているため、双方が依存コンポーネントと基本コンポーネントである。
依存コンポーネント用に ST、または PP を作成する場合は、基本コンポーネントに依存する依存コンポーネントは、
前提条件とこれらの前提条件から導出される運用環境のセキュリティ対策方針として扱われなければならない。
DBMS を例にした前提条件は、次のようなものである：
－ 前提条件 1
運用環境は、DBMS として同じシステム上で実行される他のアプリケーションソフトウェアによる DBMS ソフトウェ アへの妨害や改ざんから保護する。
－ 前提条件 2
運用環境は、DBMS の利用者データや TSF データの保存に用いられるファイルを不正なアクセスから保護す る。
－ 前提条件 3
運用環境は、個々の利用者を識別、及び認証し、DBMS によるリクエストの中から、DBMS が消費者の識別 情報を取得する方法を提供する。
こういった前提条件は、運用環境の一部としてオペレーティングシステムにとって非常に明確な対策方針を特定す るために用いることができる。こういった対策方針の詳述さのレベルは、DBMS に対する要求がどの程度具体的かに よって大きく左右される。例えば、監査が DBMS の SFR の場合、DBMS が依存するオペレーティングシステムのセキ ュリティ機能をバイパス、または改ざんさせる試みを検知するためにオペレーティングシステムの中からある程度の監 査レベルを要求することも役に立つことがある。上述のような前提条件から導出されるセキュリティ対策方針の例に は、次のようなものがある：
－ オペレーティングシステムは、そのシステムの制御下で実行される他のアプリケーションプログラムによる妨害や改 ざんから自身の実行ドメインを保護するために、そのドメインの中で DBMS に実行を許可するメカニズムを提供 しなければならない。
－ オペレーティングシステムは、DBMS に属す実行型プログラムを不正なアクセスから保護しなければならない。
－ オペレーティングシステムは、DBMS のソフトウェアに完全性を侵害する脅威や攻撃を検知するメカニズムを提 供し、修正することができない完全性の侵害が検知された場合には DBMS の実行を禁止しなければならな い。
－ オペレーティングシステムは、少なくても読み取りと書き込み/更新用のアクセスの違いを認識するファイルに、ア クセス制御メカニズムを提供し、個々の利用者に合わせた詳述さで（「アクセスなし」の場合も含め）それぞれの アクセスレベルの定義を許可しなければならない。
－ オペレーティングシステムは、個々の利用者、または所定の利用者グループのファイルへのアクセス権の管理の 制限を許可しなければならない。
－ オペレーティングシステムは、DBMS の機能を呼び出す前に、個々の利用者を識別、及び認証しなければなら ない。
－ オペレーティングシステムは、利用者を誤認証する確率が 1,000,000 分の 1 以下で認証する保護メカニズムを 用いなければならない。
－ オペレーティングシステムは、監査記録に利用者の識別情報や認証を試みた際の日時が含む認証試行の成 功、または失敗を監査する機能を備えていなければならない。
－ オペレーティングシステムは、呼び出されたデータベースの機能の代わりに DBMS が利用者の識別情報を適切 に取得することができるインタフェースを提供しなければならない。
ISO/IEC 15408-2 で示されているように、セキュリティ対策方針の大半は、SFR との対応付けが容易であることが お判りいただけたことだろう。1 番目のセキュリティ対策方針だけは、ドメイン分離の構造的な特性を扱っているという 点が他と異なっている。セキュリティアーキテクチャに関する文書では、この特性がオペレーティングシステムでどのよう に実装されるかを説明する必要がある。セキュリティアーキテクチャに関する文書は、保証レベルが EAL2 以上の TOE には必須である。
前述の例のように、DBMS が依存コンポーネントでオペレーティングシステムが基本コンポーネントの場合、オペレー ティングシステムのセキュリティ対策方針は、SFR の詳細レベルに近い非常に高位な詳細レベルで定義することがで き、可能な場合は、常に高位な詳細レベルを提供すべきである。
前提条件とそこから導出された運用環境のセキュリティ対策方針が、包括的でなければならない場合もある。オペ レーティングシステムを依存コンポーネントとし、LDAP サーバを基本コンポーネントとした場合に、作成する必要があ る前提条件の例を取り上げる：
－ 運用環境は、利用者の認証にオペレーティングシステムが要求するデジタル認証と証明書失効リストを、不正 な修正や不正な手段で証明書や証明書失効リストに追加する行為から保護しなければならない。
この場合、ST、または PP は、この前提条件に別な方法で適合するために、この保護メカニズムの一部が動作しな いようにしておくことができる。この前提条件から導出される運用環境のセキュリティ対策方針には：
－ LDAP サーバは、オペレーティングシステムが利用者認証に用いる証明書や CRL（証明書失効リスト）への修 正、及び/または追加を許可する前に、利用者を識別し、認証しなければならない。
－ 運用環境は、LDAP サーバとオペレーティングシステムとの間でやり取りされるデータを、（追加や繰返しを含め）
検知されない方法で改ざんされないように保護しなければならない。
運用環境のセキュリティ対策方針を達成するために、異なる方法で対策することを許容するために、運用環境の セキュリティ対策方針をどのように達成するべきかについてまでは特定しない。例えば、上記の 2 番目のセキュリティ 対策方針については、暗号によって保護された通信プロトコルを用いて構築する、または物理的に保護されている ネットワークによって構築する等によって、対策方針を達成させることができる。
依存コンポーネント用に ST、または PP を作成する場合は、基本コンポーネントが評価されており、その評価結果 を依存コンポーネントの評価に利用することができる場合と基本コンポーネントが評価されていないか基本コンポー ネントの評価結果を利用することができない場合には、その違いを区別しなければならない。
前者の場合、ISO/IEC 15408-3 には、評価済みのコンポーネント用に評価基準を定義する ACO 保証クラスが含 まれる。統合 TOE の ST、または PP の作者は、ACO クラスの中から保証レベルに相応しいと思われるコンポーネン トをその TOE に含めなければならない。これを裏付けるために、ISO/IEC 15408-3 では、統合 TOE の ST、または PP に含まれる 3 通りの「統合保証パッケージ」を定義している。こういったあらかじめ定義されているパッケージとは異 なるコンポーネントを ACO クラスから選択する場合は、依存関係が満足されていることを確認しなければならない。
14.2. コンポーネント TOE
TOE の環境には、別の IT コンポーネントとの明確な依存性がない自己完成型の TOE があるが、これには当てはま らない TOE も数多く存在する。こういった TOE は、ST、または PP の中では「コンポーネント TOE」と見なされている。
この一般的な例には：
－ ソフトウェアのパッケージに明確なセキュリティ機能が提供されているが、これらの機能は、さまざまな数多くの製 品に組み込むことを目的としている。このソフトウェアパッケージは、それが組み込まれた製品の TSF や TSF デー タを保護すると共に一部の TSF データを管理するためにその製品に依存する。
－ アプリケーションが自身のオブジェクトのためにアクセス制御機能を実装しているが、そのアプリケーション環境によ って提供される利用者の身分識別や認証にも依存している。
－ アプリケーション、またはオペレーティングシステムが、暗号化の機能や暗号鍵の管理を提供する暗号化コプロセ ッサに依存している。