コンピュータセキュリティ基本要件 機能編

コンピュータセキュリティ基本要件
機能編
【第２版】
平成９年８月
日本電子工業振興協会
社団法人 １．はじめに １．１ 基本要件作成の目的と経緯 １．２ 海外動向 １．３ 基本要件・機能編の作成方針と性格 １．３．１ 概要 １．３．２ 作成方針 １．３．３ 本書の想定する対応範囲 １．３．４ 想定する読者 １．４ 評価対象 １．４．１ セキュリティ方針 １．４．２ 評価対象 １．５ 想定するシステムモデルと用語の定義 １．５．１ ユーザ １．５．２ 資源 １．５．３ システム １．５．４ ネットワーク １．５．５ 分散システム環境 １．６ 本書を利用したセキュリティ評価の実施 １．６．１ セキュリティ評価の実施方法 １．６．２ 想定するセキュリティ評価の実施方法 ２． セキュリティ機能要件 ２．１ 識別と認証 ２．１． 識別 ２．１． 認証 ２．２ アクセス制御 ２．２． システムアクセス制御 ２．２． 資源アクセス制御 ２．３ 資源の再利用 ２．４ 監査 ２．４． 記録機能 ２．４． 分析・報告機能 ２．５ 完全性 ２．５． システムの完全性 ２．５． データの完全性 ２．６ サービスの信頼性 ２．７ ネットワーク上のデータ保護 【付録Ａ】 国際的なハーモナイズ状況 【付録Ｂ】ＣＣの構成 【付録Ｃ】用語集 !"#$%!!&"%'
$ ( $$ )$ ( # ( *+
$$)
本書は、（社）日本電子工業振興協会コンピュータセキュリティ委員会、コンピュー
タセキュリティ評価基準専門委員会により作成されたものです。
本書の著作権は（社）日本電子工業振興協会が有しております。書籍、文献等に引用、
掲載を行う際には、「"%$ ( $$」または「電子
協 年コンピュータセキュリティ委員会」と明記してください。
１．はじめに
１．１ 基本要件作成の目的と経緯
今日、さまざまな業務処理分野において、情報システムの重要性が増して来ると
共に、インターネットのような不特定ユーザと相互にネットワークで接続されたコ
ンピュータが増加している。これにより、情報セキュリティが大切な関心事のひと
つとしてクローズアップされて、情報システムの持つセキュリティレベルの客観的
評価が求められるようになってきた。このようなセキュリティ評価を客観的に行う
ための尺度は、通常、評価基準書（# ）と呼ばれる各種基準のセッ
トである。この基準をすべて満たしていることで、そのセキュリティレベルに達し
ていると評価できるのである。ここでいうセキュリティ機能の客観的評価とは、必
ずしも第三者機関による評価だけを意味しているのではなく、ユーザ自身による自
社システムの評価や、メーカによる自社製品の自主評価も含んでいる。評価の公平
性が求められる政府調達はともかくとして、民間市場においては、評価コストやタ
イムリな出荷を可能にするというようなことからむしろ後の２者の方が、評価基準
への期待が大きい。
評価基準の制定に関する海外動向については、「２海外動向」で述べるが、日本
以外のコンピュータ先進国では既に開発を行い、一部では運用を始めているのが実
情であり、国際的な標準化も着手されている。一方日本では、従来から通商産業省
の「情報システム安全対策基準」を始めとする各種の対策基準があり、ユーザのシ
ステム構築におけるセキュリティ機能充足のガイドラインとして活用されてきたが、
欧米のように技術的対策に焦点を当てたセキュリティ評価基準はなかった。このた
め日本も、欧米と同じ考え方の評価基準を明示的に持つことが、情報システムのセ
キュリティ向上、国際社会における協調関係の醸成、情報社会のボーダーレス化促
進に役立つと判断された。
その後「２海外動向」で述べるように、欧米各国の各々の評価基準はＣＣ
（$$ ）として集約される事になり、その作業が進行中であり、１９
９６年１月には第１版が発行された。ここで日本も独自に評価基準を開発するのは、
いたずらにハーモナイズ対象を増やすだけであり、評価基準の国際的集約作業を遅
らせるだけであると判断し、日本としては、ＣＣの発行を待って、それを日本の評
価基準の要件項目として導入する事にした。その代わりに、ＣＣの集約作業の過程
でのレビューに参加し、ＣＣへのコメントで日本の立場の反映を図ることにして、
コメントを提出してきた。
セキュリティ要件は、本来適用領域毎に異なるものであり、この特性に対応する
ために、ＣＣではＰＰ（, ,-）という考え方を採用している。ＰＰは
適用領域または個々のシステム毎に適用するセキュリティ要件のセットを記述した
もので、適用領域または各システムに対応して作られる。ＣＣの要件集（パート２
および３）はこのＰＰを規定するための要件を各セキュリティ項目ごとにレベル分
けして全て列記したものであって、それ自身は特定の要件のセットを規定している
ものではない。パート４では３つの要件のセット（ＰＰ）をサンプルとしてあげて
いる。
日本ではＣＣに基づくＰＰの一つとして、日本ではＣＣに基づくＰＰの一つとし
て、基本的なセキュリティ要件のセットを開発することにした。これはユーザがシ
ステムを構築する際のベースとして参照できるものであると共に、ベンダにおける
セキュリティ製品の開発指針としての参照を可能にするものである。セキュリティ
要件には２つの観点がある。即ち、必要なセキュリティ機能がシステムに導入され
ているかを評価する機能（. ）の観点からの機能要件と、その機能がど
れだけ確実に実現されているかを評価する保証（%!! ）の観点からの保証要件
である。本基本要件・機能編は、上記の基本的なセキュリティ要件のうちの機能要
件を規定したものであり、保証要件については、基本要件・保証編を参照されたい。
この機能要件のセットは、従来の安全対策規準とは以下の点で異なる性格を持つ
ものであり、この点からも機能要件のセットを新たに検討して作成する必要があっ
た。
・評価基準は基本的に評価対象とするシステムの持つべきセキュリティのレベル
によって異なるものである。それを実現できるようにするために、マルチユー
ザ環境をサポートするシステムにおける必須要件のみを規定する基本要件が必
要であること。
・政府関連システムの調達要件として使用される場合には、製品仕様の前提条件
となるようなものであること。
・今後ＣＣが国際標準になれば、セキュリティ評価について欧米諸国をはじめ各
国との相互認証が行われることが想定される。その際の各国の基準書とハーモ
ナイズされるものが必要である。
ＣＣは、現在第２版に向けてコメント反映が行われている。本基本要件・機能編
第２版（以下、本書）は、基本要件・機能編第１版を基に、ＣＣ第１版のＰＰのＣ
Ｓ３&$$( 'の要求項目をたたき台に、基本要件として相応しいと
思われるＣＣ第１版の要求項目を採用し、作成された。ただし、ＣＣには複雑にネッ
トワーク化されたコンピュータのセキュリティ機能の項目が不足していることから、
この分野を目指して作成された、ＥＣＭＡ& $ / - !0
%!!' の Ｅ − Ｃ Ｏ Ｆ Ｃ &1 $$ 2 . !
!!'を参考にして、ネットワーク関係の項目を設定した。これにより、本書は、今
日の日本で使われるコンピュータシステムの基本的なセキュリティ要件となったと
考える。
１．２ 海外動向
セキュリティ機能評価への関心は、当初専ら情報の機密性（-）に
限 ら れ て い た が 、 次 第 に 情 報 の 完 全 性 （ ） や シ ス テ ム の 可 用 性
（%#*）にも焦点があてられるようになった。
先ず、米国において国家安全保障上の理由から、機密保護が必要な情報（!!-
）を取り扱う情報システムのセキュリティを確保する必要性が叫ばれた。その
ために、製品の購入時におけるセキュリティ機能の観点からの判断基準として、１
９８５年に国防総省によってＴＣＳＥＣ（3 ! $ (!$ # 、通称：オレンジブック）が制定された。この基準は、機密性偏重のため、
商用領域への適用には問題があるものの、国防領域においては、ＮＣＳＣ（4
$ ( ）による評価で多くの運用実績があり、定着している。
ＴＣＳＥＣは、上述の理由で商用領域への適用に問題がある他に、その運用にお
いては評価過程にかなりの時間と経費を要することから、商用および非軍事分野で
の 利 用 も 考 え た 新 し い 連 邦 評 価 基 準 Ｆ Ｃ （ . - -$
3( ）の検討が、ＮＳＡ（4( %）とＮＩＳＴ
（4! -(!3）の共同作業として１９９１年
に開始された。この作業の一環として、商用および非軍事向けのシステムが具備す
べき、最低限の機能要件の検討が行われ、その結果は、ＭＳＦＲ（/$ $( . 56 $!）としてまとめられた。ＭＳＦＲは、更に保証要件を
加えてＭＳＲ（/$ $( 56 $!7/）として刊行されて
いる。ＦＣ自体は１９９２年１２月にバージョン１．０がレビュー用に公開された。
特定の利用分野を前提としないＦＣでは、本来的に利用分野毎に異なるセキュリ
ティ要件を、どの様に扱うかが問題となる。この解決のために、プロテクション・
プロファイルＰＰの概念が導入された。ＰＰとは、利用分野毎ないしは個別システ
ム毎にセキュリティ要件を記述したものである。ＦＣは、ＰＰ記述のための基本的
枠組みを与える第１部と、具体的なＰＰを示した第２部とからなっている。ＦＣで
は商用・非軍事用の３種のＰＰと、機密用（軍事用等）の４種のＰＰとが示されて
いる。ただし、第２部で示されたＰＰだけしか許されないのではなく、ＦＣの考え
方では、基本的にオープンエンデッド（開放的設計）になっており、誰でもＰＰを
作ることができ、作られたＰＰは登録して広く利用する事が可能な運用が考えられ
ている。
一方欧州では、英、独、仏等の国々で、それぞれ独自の評価基準を作成し、その
運用が計画された。しかし、欧州の市場統合を控えて、ＥＣ（ $$ ）
委員会は域内各国が異なる基準を運用することに危惧を覚え、セキュリティ評価基
準 の 統 一 に 乗 り 出 し た 。 こ の 結 果 作 ら れ た も の が Ｉ Ｔ Ｓ Ｅ Ｃ （ -$
3 ( # ） で あ り 、 １ ９ ９ １ 年 に Ｅ Ｎ Ｖ
（ !4$84$：欧州準規格）として暫定運用が始められた。現
在英、独、仏で正式運用されている。
ＩＴＳＥＣは機能要件と保証要件とを分離し、機能要件については具体的な要件
を示さず（ただし、参考例としてＴＣＳＥＣの各クラスの機能要件相当等の複数の
機能要件クラスを添付）、記述法だけを規定して評価対象毎に記述する考え方を採
用することで、評価対象システムの適用領域を限定せずにオープンエンデッドなス
タイルを採っている。
またカナダでは、ＴＣＳＥＣを参考にし、ＩＴＳＥＣの考え方も取り入れて、独
自の評価基準ＣＴＣＰＥＣ（ 3 ! $ , # ）を作成した。この作業は米国におけるＦＣ作成作業よりも先行したため、
ＣＴＣＰＥＣの考え方はＦＣに大きな影響を与えた。
これらの各国での評価基準作成作業を受けて、評価基準の国際標準化がＩＳＯ／
ＩＥＣ ＪＴＣ１ ＳＣ２７&29-(9
: $$!! 3 $$ ( *$$ 'に取り上げられ、ＷＧ３&;< = 'として作業が始めら
れた。ここでは、当初ＩＴＳＥＣが原案として提案され、後にＦＣをベースとした
修正提案がカナダの支持を得て米国から出された。
この結果、評価基準の国際的ハーモナイズの必要性が認識され、ＥＣ委員会（英、
独、仏）、米国およびカナダ政府によって、ＣＣプロジェクトが開始され、ＣＣＥ
Ｂ&$$>'が結成された。この成果としては、９４年３
月に第一次案が、さらに９４年１２月にはドラフト０．９版が配布された。さらに
それに対するコメントを反映して第１版が９６年１月に発行された。ＳＣ２７ Ｗ
Ｇ３ で は、この第１版の , ∼ がＷＤ&;< "-'、 , がＣ Ｄ
&$$"-'となり、,∼ をＣＤにするための、条件等を検討している。
現在、ＣＣＥＢはオランダも加えＣＣＩＢ（$$ $$
>）と名称変更し、第１版へのコメントを反映中であり、９７年１２月には第２
版を発行する予定である。さらにそれに対するコメントを反映し、９８年７月にＤ
ＩＳ&"-('としてＩＳＯに提案して、９８年１１月にＩＳ
&(、国際標準'とする予定になっている。
なお、海外における各種セキュリティ評価基準と本書との関連を付録Ａに示す。
１．３ 基本要件・機能編の作成方針と性格
１．３．１ 概要
本書は、商用のコンピュータシステムにおいて最小限具備すべき、セキュリティに
関わる機能要件を記述したものである。
コンピュータシステムに求められる機能要件は本来ユーザ、システムが実現する業
務（アプリケーション）ごとに異なるものであるが、本書では商用アプリケーショ
ン領域（軍事・外交等の国家安全保証に係わるものを除く領域）に共通に必要とさ
れる機能要件を規定する。
近年開発された、または開発中のセキュリティ評価基準では、コンピュータシステ
ムに求められる機能要件がユーザ／システムごとに異なるという概念を採り入れて
いる。例えば開発中のＣＣの機能要件集（パート２）では付録Ｂに示すように、一
般的に想定されるセキュリティ目標に沿い、セキュリティ各機能分野ごとにさまざ
まなレベルの要件を記述した体系的な要件集として作成されている。
ユーザが実際の情報システムにＣＣを適用するにあたっては、具体的なセキュリ
ティ目標に従い、機能要件集から必要な分野の必要なレベルの要件だけを記述した
ＰＰを利用して、製品、システムのセキュリティ実現レベルを評価する。
本書は、ＣＣにおける商用分野向け共通機能要件のセットとしてのＰＰに相当する。
１．３．２ 作成方針
本書の検討にあたっては、将来における評価結果の国際的相互認証を実現すること
を想定するとともに、日本の各種安全対策基準と明らかな矛盾を生じさせないこと
に注意を払った。
（１）第１版（１９９４年）作成の方針と経緯
ＭＳＲおよび日本の各種安全対策基準を抽出の参考とし、ＭＳＲの機能要件の必須
項目（56 $!）と各種安全対策基準の項目との和集合の内で、他の項目の機
能で代替できない項目をすべて網羅するようにした。
（２）第２版作成の方針
将来において評価結果の国際的相互認証を可能とすることを重要視した。特にＣＣ
がいずれＩＳＯ／ＩＥＣの場において国際標準になることを想定し、ＣＣ第１版で
商用コンピュータシステム向けのＰＰとして提示されたＣＳ３で採用されている機
能要件をたたき台に、基本要件として相応しいと判断できるＣＣ第１版の機能要件
を採用した。
またインターネットをはじめとしたネットワーク環境に対応するための要件をカ
バーするため、ＥＣＭＡのＥ−ＣＯＦＣの要件を参照した。
１．３．３ 本書の想定する対応範囲
（１）想定するセキュリティ上の脅威
本書は、コンピュータシステムに対する各種のセキュリティ上の脅威のうち、情報
技術により対抗すべきものを想定し、対抗するために実現すべきセキュリティ機能
に関する要件を規定したものである。
したがって、物理的な破壊や侵入・妨害といった脅威に対する物理的な防御（建屋
の耐火・耐震・耐水性能、マシン室への入退室管理、テープ・ディスク等の保管等）
という観点でのセキュリティ機能要件は本書では取り扱わない。また災害によるマ
シン自体への脅威に対抗するためのセキュリティ機能要件も対象外である。
この結果、本書が想定するセキュリティ上の脅威は、人為的な故意・過失や偶発的
なシステムエラー等によるシステム管理資源、ユーザデータに対する脅威に限定さ
れる。
（２）要件規定の範囲
本書は、本書が想定するセキュリティ上の脅威（上記（１）参照）に対抗するため
に、ベンダまたはシステム・インテグレータが提供する製品／システムで実現すべ
き機能要件を記述したものであり、システム構築・運用上のセキュリティ確保に必
要な考察要因をすべて網羅したものではない。
コンピュータシステムのセキュリティ確保のためには、本書で規定した要件の他に、
●コンピュータセキュリティ基本要件・保証編への準拠
●コンピュータシステムの物理的なセキュリティ（上記（１）参照）
●セキュリティ方針に基づいたシステム運用マニュアルの整備と確実な実施
●システム管理者を含むユーザの教育、指導
●監査の実施
が必要である。
換言すれば、本書に記載する機能要件は、セキュリティ確保のための必要条件では
あるが、十分条件ではないことを留意する必要がある。
（３）各機能要件に共通な前提事項
本機能要件で規定していない機能をシステム及びシステムの動作に関連するソフ
トウェア、ハードウェア、ネットワークに追加する場合、それらの機能がシステム
の他のセキュリティ機能に悪影響を与えてはならない。
１．３．４ 想定する読者
本書は、以下の読者と利用方法を想定している。
（１）製品開発ベンダ及びシステム・インテグレータ
評価対象（ＴＯＥ：3 - # ，
参照）となる製品、システムを
開発、構築する際の指針（
参照）として利用されることを期待している。
（２）ユーザ
システム管理者が固有のセキュリティ方針（
参照）を定めるための参考とし
て利用されることを期待している。必要に応じ、本書のサブセット、または本書に
更に固有の要件を付加した形でユーザシステムに適用することも考えられる。
またベンダ等から提供・提案される製品の評価結果が公表されている場合、製品の
選択を行う際の判断基準のひとつとして利用されることも期待できる。
（３）評価者
ベンダが開発した製品、システム・インテグレータが構築したシステムを評価対象
とした評価実施（ 参照）のために利用される。
１．４ 評価対象
１．４．１ セキュリティ方針
コンピュータシステムのセキュリティを確保するためには、最初にセキュリティ方
針を明確にしなければならない。これは製品やシステムの開発者、ユーザ相互に共
通な事項である。
セキュリティ方針では、どのようなセキュリティ上の脅威に対処し、どのようなセ
キュリティレベルを維持するかを明確にしなければならない。
特に製品開発にあたっては、セキュリティ方針に基づいた具体的なセキュリティ目
標を設定しなければならない。本書では各機能要件がどのような脅威に対抗し得る
ものであるかを「解説」の中で記している。
１．４．２ 評価対象
本書の適用にあたっては、評価対象となるソフトウェア、システムの範囲を明確に
定義して評価を実施しなければならない。
評価対象は、システムソフトウェア（オペレーティングシステム（ＯＳ：2
(!$）等）、ミドルウェア、アプリケーションソフトウェア、ハードウェア、及
びこれらの組み合わせとして定義する。
評価対象の定義にあたっては、以下の項目を明確にしなければならない。
（１）評価対象の動作環境
評価対象が正常に動作するための前提環境を規定しなければならない。
本項目には、前提とするハードウェア（必要な装置名、仕様、性能、ネットワーク
種別等）、ソフトウェア（ＯＳのバージョン等）、及びそれらの設定条件等を含む。
（２）評価対象物
本書で記述した機能要件を実現する製品、または製品群を規定しなければならない。
本項目には、評価対象を特定するための情報（開発者、製品名称、バージョン等）
を含む。また評価対象が複数の製品から成り立っている場合、評価対象間の関連を
明記しなければならない。
（３）評価対象がセキュリティを実現する範囲
評価対象物が本書で記述した機能要件を満足するセキュリティを実現するシステ
ム上の範囲を規定しなければならない。
本項目には、本書準拠のセキュリティを実現できる、システム構成上の範囲、装置
上の範囲（メモリ上の範囲、ディスク上の範囲等）を含む。
１．５ 想定するシステムモデルと用語の定義
１．５．１ ユーザ
コンピュータシステムのセキュリティ実現においては、誰がどのようにコンピュー
タシステムを利用する（した）のか制御、管理する必要がある。本書の２章では、
コンピュータシステムを利用するすべての人を「ユーザ」と呼ぶ。ひとりひとりの
人間は独立したユーザとして識別できなければならない。
コンピュータシステムで処理されるあらゆる事象は、特定のユーザの指示に起因す
る。また、実行されるタスク、プロセス、スレッドは、個々のユーザと関連づけら
れる必要がある。
本書の２章では、さらにユーザを以下の２つに分類して扱う。
（１）システム管理者
ユーザのうち、システム運用やセキュリティ管理に関して責任と権限を有するユー
ザを「システム管理者」と呼ぶ。
なお、システム管理者が有する権限をどのように割り当てるかは、製品やシステム
の実装、運用に係わる問題であり、本書の対象外である。
（２）一般ユーザ
ユーザのうち、システム管理者以外のユーザを「一般ユーザ」と呼ぶ。
１．５．２ 資源
本書の２章においては、コンピュータシステムを構成するハードウェア、ソフト
ウェア、データ（システムデータ、ユーザデータ）の中で、評価対象が提供するセ
キュリティ機能が保護対象とするもの（メモリや磁気ディスク等）を資源と呼ぶ。
１．５．３ システム
本書の２章においては、評価対象をシステムと呼ぶ。
本書の適用においては、１．４．２で述べたとおり、評価対象とするシステム構成
上の範囲を明確にしなければならない。この範囲内においては、個々のユーザおよ
び資源は一意に識別できなければならない。
また、ユーザシステムのセキュリティ管理者は、管理対象とするシステム構成上の
範囲（１つの評価対象に閉じるとは限らない）を明確にした上でセキュリティ方針
を確立しなければならない。
異なる評価対象との（つまり、システム外部との）接続及びデータの交換は、双方
をあわせて一元的に管理される必要はないが、システム内のセキュリティ方針を維
持可能な範囲で、相手評価対象との間で等価な解釈が可能な手段で行わなければな
らない。
１．５．４ ネットワーク
本書の２章においては、物理的なコンピュータシステムを接続する物理的な通信
路・通信網をネットワークと呼ぶ。
ネットワークを介して接続されたコンピュータシステムは、ネットワークの存在に
起因するセキュリティ上の脅威にさらされている可能性があり、本書にはこの脅威
に対抗するための機能要件も２．７「ネットワーク上のデータ保護」として定義す
る。
１．５．５ 分散システム環境
本書の２章においては、複数の物理的なコンピュータシステムから構成されている
システム形態を分散システム環境と呼ぶ。評価対象が分散システム環境である場合
も、評価対象内の各コンピュータシステムに本書は適用されるが、評価対象内の内
部コンポーネントにおけるデータ交換においては、２．７「ネットワーク上のデー
タ保護」の要件を適用しなければならない。
１．６ 本書を利用したセキュリティ評価の実施
１．６．１ セキュリティ評価の実施方法
セキュリティ評価は、その実施者により次の３タイプに分類できる。
（１）第一者評価：ベンダが開発したソフトウェア、インテグレータが構築したシ
ステムに対して、ベンダやインテグレータ自身が実施する評価。
（２）第二者評価：購入する製品、構築されるシステムに対して発注者であるユー
ザ等が自ら実施する評価。
（３）第三者評価：メーカやユーザ等の依頼を受けた中立機関が実施する評価。
１．６．２ 想定するセキュリティ評価の実施方法
本書は、１．６．１で示したいずれの実施方法においても利用可能な評価基準とし
て作成されている。
２． セキュリティ機能要件
２．１ 識別と認証
システムは個々のユーザを識別できなければならない。また、ユーザのシステム
利用に際して、ユーザが確かに本人であることを確認できなければならない。ユー
ザを識別する為に、個々のユーザにユーザ識別子を割り当てる。本人の確認は本人
しか知り得ない情報（例えばパスワード）や本人に固有な身体的特徴（指紋、声紋
等）を利用して行う。
なお、この識別はシステムを一時的に利用するユーザ（いわゆる「ゲストユーザ」）
の存在を否定するものではない。ゲストユーザとして識別されたユーザはその権限
の範囲でシステムを利用することが可能である。
２．１．1 識別
&'
システムはユーザを一意に識別するために、個々のユーザに対してユーザ識別
子を付与して管理しなければならない。ユーザの集合としてグループを構成す
ることもできる。この場合はグループ識別子を付与して管理しなければならな
い。ユーザは複数のグループに所属することもでき、システムはこのグループ
の構成員を変更できる機能を提供しなければならない。この構成員を変更する
機能はシステム管理者のみが利用可能でなければならない。
&'
システムは識別や認証の為に、利用に先立って、ユーザを登録したり抹消した
りできなければならない。このユーザ登録や抹消は、特別な権限を付与された
システム管理者のみが実施できるようにしておかなければならない。グループ
識別子を有するときは、グループとしての登録や抹消もできなければならない。
【解説】
&'
ユーザ登録／抹消の手続きを一般のユーザがなんの制限も無しにできた
のでは、管理の意味が無い。特別な権限を持ったシステム管理者である
ことを識別、認証した後に、はじめて、ユーザの登録や抹消の操作を可
能としなければならない。
ユーザがシステムを利用するに先立って、システムはユーザの識別を実施しな
ければならない。識別は個々のユーザ識別子とグループが構成されている場合
には、グループ識別子によって実施されなければならない。この際には、まえ
もって、許可されたグループである事を確認しなければならない。
【解説】 システムの入り口でユーザを識別することは、セキュリティ上重要なこ
とである。ユーザの識別が遅れれば、それだけ、許可されていないユー
ザによるシステム資源の利用を許すことになる。
&
'
システムは任意の時点で、任意の処理の要求元ユーザを識別できなければなら
ない。ユーザはその処理を起動したユーザか、又は、その処理の実行責任者か
である。
利用者が直接起動したものでない処理（例えば、プリントサーバ、データベー
スサーバ等）については、システム管理者又は一意の識別子で識別できなけれ
ばならない。
【解説】 通常、システム内では複数の処理が平行して実行される。どの処理もそ
れを起動した、または、その責任者であるユーザを識別できなければ、
処理の妥当性を管理することはできない。また、一つの処理から別の処
理を呼び出す場合は、呼び出された処理についてもその要求元の利用者
が識別できなければならない。
&'
ユーザが一定期間システムを利用しなかった場合には、そのユーザ識別子を自
動的に使用禁止にできなければならない。
【解説】 システムの利用開始時には、前回の利用時間や認証に失敗した情報（回
数等）が表示される。もし、自分のユーザ識別子が不正に利用されてい
れば、この情報をチェックすることによって検出できる。しかし、長期
間システムを利用しない場合、他利用者が不正にその利用者の識別子を
利用しても、検出が困難である。このため、本処置が必要となる。
&'
システムはユーザ識別子のユーザ属性を初期値に設定できなければならない。
&'
システムはユーザ識別子を使用禁止にしたり、禁止状態を解除する機能がなけ
ればならない。本機能は特別の権限を付与された管理者のみが実施できるよう
にしておかなければならない。
【解説】 システム管理者がユーザ識別子の利用に関して異常を検出した場合、即
座に対処するために、本機能が必要となる。
&'
システムは登録されているユーザの状態（例えば、利用中とか利用禁止状態と
か）を把握できる機能を提供しなければならない。
【解説】 システム管理者がユーザ識別子の利用に関して異常を検出した場合、現
在のユーザ状態を把握し、即座に対処するために、本機能が必要となる。
&'
システムは同一のユーザ識別子を使用して複数のログインを同時に行うこと
（セッションの数）を制限できなければならない。また、ユーザ識別子毎に同
時にログインする数（セッション数）を制限できなければならない。本機能は
システム管理者のみが実施できるようにしておかなければならない。
【解説】 正規のユーザがシステムを利用している場合、他の利用者が同じユーザ
識別子を利用して不正な利用を実施しても検出が困難である。同時に実
行できるログインセッション数を制限できれば、不正を検出することが
可能となる。デフォルト値は１とする。
&' ユーザ識別子をユーザが動的に変更できる場合、特権を持っているユーザ識別
子への変更は、特定のユーザ（複数でも可）のみに限定できなければならない。
【解説】
特権ユーザへの変更が自由にできたのでは、特権を設定した意味が無く
なる。
２．１．2 認証
&'
システムはユーザを認証する機能を提供しなければならない。
【解説】
通常、利用者識別子は公開（誰でも知ることができる）されている。こ
のため、容易に他人を偽ってシステムを利用することができる。これを
防ぐために、本人しか知りえない情報や本人に固有な身体的特徴を利用
した、本人の確認が必須である。
&'
システムは認証情報が不当に利用されないように保護しなければならない。
&'
認証情報は各ユーザ識別子ごとに設定できなければならない。
&
'
認証情報に関するいかなる情報もユーザに提供してはならない。
【解説】 他人の認証情報の推測を可能とするようないかなる情報もユーザに提供
してはならない。
&'
認証情報の登録、更新時や認証時に、ユーザより入力される認証情報を端末画
面等に表示してはならない。
【解説】 入力時に他人に見られることに対する保護である。
&'
認証情報をプリントアウトしてはならない。
&'
認証情報をシステム内に保持する場合には、一方向の暗号化によって暗号化処
理された情報を格納しなければならない。
【解説】 ユーザより入力された認証情報はただちに暗号化処理して保護し、不当
に利用されないようにしなければならない。認証情報が暗号化されてい
ない場合、認証情報が格納されているファイルをダンプされた場合、認
証情報を暴露することが可能である。たとえ、暗号化されていたとして
も、暗号鍵をそのファイル上に持っていたのでは、認証情報が十分保護
されていることにはならない。暗号化された情報から元の情報を入手で
きないような論理によって暗号化（一方向性の暗号化処理と呼ぶ）して、
システム内に保持しなければならない。
&'
ユーザが自分の認証情報を変更できる機能がなければならない。なお、この変
更時には、新しい認証情報の入力に先立って、それまでの認証情報を入力させ
て、本人の認証をおこなわなければならない。
&'
システム管理者は任意のユーザの認証情報を初期化できなければならない。
【解説】 不正なユーザが他人のパスワードを取得しているということが判明した
場合、管理者は直ちにこの不正をやめさせなければならない。この為に、
対象となるユーザの認証情報をただちに初期化し、それまでの認証情報
を利用できなくすることが必要となる。
&' 認証情報の有効期間を設定できなければならない。認証情報の有効期限を終了
するときは警告を発すること。
【解説】 長期間同じ認証情報を利用していると、他人に暴露される危険性は高ま
る。自ら認証情報を変更しないユーザに対しては強制的に別の認証情報
に変更させることが必要である。
&' 一定の期間は同一ユーザが過去に使用した認証情報を再度使用することを禁
止できなければならない。
【解説】 （）によって、認証情報を変更しても、新規認証情報が以前のものと
同じであれば意味がない。このために、一定期間は異なった認証情報を
利用させることが必要である。
&' システムはユーザにより入力された認証情報が間違っていても利用者の認証
処理を途中で打ち切ることなく全て実施する。その際、間違った認証情報のど
こに問題があるかについての情報をエラーとして表示してはならない。
【解説】 ユーザより入力された認証情報が誤っている場合、その誤りの内容をユー
ザに通知すれば、不正なユーザにとっては、類推が容易に可能となる。
誤っているという事実だけを通知し、他のいかなる情報も与えてはなら
ない。また、同じ認証情報を他のユーザが使用している場合でも、その
事実を通知してはならない。
&' ネットワークを介して認証情報を送受信する場合、盗聴防止のため認証情報を
秘匿できなければならない。また、認証情報が不正な再送、挿入、削除、改竄
を検知して、不正な利用を防止する手段を講じなければならない。
【解説】 利用者認証は認証情報が正当な認証機能によって利用者が提示したとお
りに正しく受信されることが前提条件になっている。また認証情報が認
証機能に受信される前に別のプログラムを経由する場合も認証情報が漏
れる可能性がある。これを防ぐには、認証情報の暗号化に際して、乱数
やタイムスタンプを付加して、通信回線上での見かけが、毎回異なるよ
うにしておく必要がある。
&
' 認証情報としてパスワードを利用する場合、ユーザが指定できる認証情報の文
字種、最小長を規定できなければならない。
【解説】 数字だけとか、一文字だけの認証情報は類推を容易なものにする。
２．２ アクセス制御
システムは、端末等の利用が物理的に保護（コンピュータが設置された建屋やコ
ンピュータルームへの入退室制限等、１．３．３（１）参照）されていない限り、
一般に誰でもが利用できる。また分散環境においては、ネットワークを介して遠隔
地から利用することも可能である。このようなシステムを、正当なユーザに、許可
された権限の範囲内で利用させ、不正利用を防止することがアクセス制御の目的で
ある。
アクセス制御では、システムはユーザを識別・認証した上で、システム自体の利
用（システムアクセス制御）及びシステムが管理する個々の資源の利用（資源アク
セス制御）について、ユーザが正当な権限を持っていることを確認しなければなら
ない。
システムで実際に各種の処理を実行するのはユーザ自身だけではなく、ユーザの
代理として機能するプロセスの場合がある。これらプロセスの動作においても、ユー
ザ自身と同様に識別・認証が必要であり、その権限はユーザ自身の権限と同一であ
る。本節では、ユーザ自身及びユーザの代理として機能するプロセスを合わせてユー
ザと呼ぶこととする。
アクセス制御の機能要件は、システムアクセス制御機能と資源アクセス制御機能
に大別される。
２．２．1 システムアクセス制御
システムを正当なユーザにだけ利用させるための機能を提供する。一般的には認
証において、そのユーザの正当性が確認されれば、ユーザはシステムの利用を許可
されるが、システムのセキュリティをより確実にするために、ユーザごとにいつ、
どこから、どのようにして、またどの機能範囲でシステムを利用できるかを限定で
きなければならない。
分散環境において複数のサーバが存在するような場合は、認証されてもすべでの
サーバにアクセスできるとは限らない。さらに、それぞれのサーバごとに本節で規
定する機能要件が適用されなければならない。
また認証されたユーザがシステム内のすべての機能、資源を利用できるわけでは
ない。ユーザが利用できる範囲（権限）は、「２．２． 資源アクセス制御」で規定
される機能要件に基づき、ユーザごとに規定される。
以下に、システムアクセス制御に関する機能要件を記述する。
&'
すべてのユーザは、システム及びシステム内の各種資源の利用に先立って、
ユーザ本人であることが認証されなければならない。
&' システムは「認証情報なし」のユーザの定義を許可してはならない。また、途
中で認証情報を変更する場合、「認証情報なし」の状態を作ってはならない。
（*）ユーザがネットワークを介して接続されたシステム（コンピュータ、端末）か
らアクセスを求めている場合も、同様の確認が必要である。
【解説】 システムアクセス制御の目的は、システムの不正利用を未然に防止する
ことにある。システム利用に関するユーザの権限は、ユーザ識別子によっ
て判断されるため、そのユーザ識別子を利用しているユーザが正当であ
ることを確認することは、アクセス制御の根幹に関わる。
したがって、いかなるユーザであっても、認証を受けずにシステムを利
用することは認められない。ユーザ（ユーザ識別子）に対する認証を実
行しないと、他のユーザになりすましてシステムにアクセスすることが
可能となり、システムが管理する資源（例えば、メモリや磁気ディスク）
に存在する情報の機密を保ち、またシステムが安定して動作することが
困難となる。
またネットワークで接続されたシステムは、不特定多数の人間がアクセ
スできる可能性がより高いことを留意すべきである。特に分散システム
環境では、ユーザが最初にアクセスしたシステムからさらに別のシステ
ムにアクセスする際には、新たにアクセスされたシステムは認証その他
の方法によってユーザの正当性を再度確認する必要がある。
（）上記にかかわらず、ユーザのアクセスが他のシステムへの取り次ぎだけを求め
ており、かつシステムアクセス制御の対象外となる場合には、この限りではな
い。
【解説】 一方で、他のシステムへアクセスするために、ユーザがあるシステムを
中継機器としで利用して取り次きを依頼する場合は、以下の考え方を適
用することもできる。
そのシステム内で当該ユーザがいかなる処理も実行できないことを保
証できれば、システムアクセス制御の対象外であるとしてそのシステム
での認証を実行せずに、ユーザアクセスを他のシステムに取り次ぐこと
ができる。
&'
システムにアクセスするユーザは、システム管理者によって事前に登録されて
いなければならない。
（）ネットワークを介して接続された機器からシステムにアクセスする場合、その
機器はセキュリティ情報として事前に登録されていなければならない。
（*）このセキュリティ情報にユーザ、及びネットワークを介して接続された機器を
登録する、または登録されているユーザまたは機器を無効にするという変更は、
システム管理者だけが実行できる機能でなければならない。
（）システムへのアクセスに関して登録されたすべてのユーザ及び機器のリストを
出力できなければならない。またこの機能はシステム管理者だけが実行できる
機能でなければならない。
【解説】 システムへの接続を要求してきたユーザに、接続を許可するかどうかを
判断するためには、アクセス可能なユーザ（ユーザ識別子）を事前に登
録しておく必要がある。事前にシステムを利用できるユーザを規定（登
録）しておかないと、権限をもたないユーザがシステムにアクセスする
可能性がある。
システムのセキュリティ方針でシステムの利用条件を規定しておき、そ
れに基づいてユーザ登録するべきである。システムの利用を要求する
ユーザがこの利用条件に合致するかどうかを確認するためにも、この機
能の利用はシステムのセキュリティを管理するシステム管理者に限定す
る必要がある。
ネットワークを介した機器からのシステム利用を許可する場合、誰かが
ネットワーク上から他のユーザになりすましてシステムにアクセスする
ことを防止するために、必要に応じてネットワークを介して接続した相
手システム（機器）を確認できるよう、事前にシステム管理者によって
登録しておく必要がある。
&'
ユーザがシステムを利用している際に、システムのセキュリティ方針で規定し
た一定時間、ユーザがシステムを利用しなかった場合には、処理をロック（中
断）できなければならない。この一定時間の設定は、システム管理者以外が実
行できてはならない。また、処理を中断するのではなく、処理を終了させる機
能も提供しなければならない。この処理終了機能はシステム管理者以外が実行
できてはならない。さらに、ユーザは利用している処理をユーザ自身がロック
できなければならない。またロックに関して、システムは次の機能を提供でき
なければならない。
（）処理のロックを解除する前に、ユーザ認証を実施することを要求すること。
（*）処理のロック中は、当該プロセス及び関連するプロセス・デバイスを他のユー
ザが利用できないようにするか、処理のロックを解除すること以外のデータ入
力やディスプレイ表示等を実行できないようにすること。
（）ディスプレイに表示されていた内容が読めないように、画面をクリアするか、
上書きして別の表示を行うこと。
【解説】 キーボード等の入出力機器を利用してシステムにアクセスしているユー
ザが、一定時間システムを利用しなかった場合、そのユーザが中座した
か、もしくは何らかの要因によりアクセスできなくなったことが考えら
れる。このような間に他人が勝手にシステムを利用することを防止する
ために、システムはそのような状態に陥ったユーザのシステム利用を一
時ロックできなければならない。
またこのような状態に陥るのを未然に防ぐために、ユーザ自身が処理を
ロックできることも必要である。
処理のロック解除には、ユーザの身元を確認するために再度ユーザの認
証を実施すべきである。
また処理のロック中においては、ユーザが利用していた処理を他人が実
行することのないよう、ロック中のセッションに関するプロセスやデバ
イスを分離したり、作業の内容を見られることのないよう、ディスプレ
イ上の情報を隠蔽する必要がある。
また、よりセキュリティを確実にするために、処理を中断するだけでな
く、そのユーザのシステム利用を終了させることができる必要もある。
&
'
ユーザがシステムにアクセスする際に、システムのセキュリティ方針で規定し
た一定回数以上認証に失敗した場合には、ユーザとの接続を切断しなければな
らない。
【解説】 一定回数以上連続して認証に失敗するユーザは、パスワード等の認証情
報を知らない、つまりシステムを利用可能であると登録されていない
ユーザである可能性がある。このようなユーザが、システムを不正に利
用するために、推定したさまざまな認証情報を用いてシステムへの接続
を繰り返し試行することは十分に考えられる。このような行為を防止す
るため、一定回数以上認証に失敗したユーザからの接続を切断し、不正
な試みを断つ必要がある。
（）この機能が実行されたとき、本事象が発生した旨の警告をシステム管理者に通
知できなければならない。
【解説】 システムに不正にアクセスしようとしているユーザが存在する可能性が
あることをシステム管理者に速やかに通知し、必要であればシステム管
理者が処置をとれるようにすべきである。
不正にシステムを利用しようとしている可能性があることをシステム
管理者が知らないでいることは、システムセキュリティの運用上問題が
ある。
（*）この機能が実行された後、システムのセキュリティ方針で規定した一定時間が
経過した後でなければ、同一ユーザ識別子によるシステムへの接続処理を開始
することはできない。
【解説】 認証に失敗したユーザが、すぐにまたシステムへのアクセスを試みる可
能性がある。このようなユーザによるシステムへのアクセスは、一定時
間経過した後にのみ許可するということで、このような行為を防止する
必要がある。また連続して認証に失敗するようなユーザは、不正ユーザ
である可能性がより一層高まったといえるので、接続処理（例：ログイ
ン手続き）再開までの時間を長くするようにする機能を提供することも
考えられる。
（）この機能が実行されたとき、そのユーザ識別子を無効にできなければならない。
この機能を、全ユーザに対してデフォルトにしてはならない。
【解説】 より機密性の高いシステムでは、不正アクセスを厳しく防止するため、
認証に失敗したユーザの識別子使用を停止させる機能も必要である。全
ユーザに対してデフォルトにすると、悪意のユーザによって全識別子が
無効にされてしまう。
&'
特定のユーザに対して、システムを利用できる日時・時間帯等を制限できなけ
ればならない。この設定はシステム管理者のみが実行できること。
【解説】 ユーザのアクセスレベルや業務内容によってシステムを利用可能な時間
帯（期間）を設けた方がよい場合がある。例えば、社内システムであれ
ば、勤務時間帯に限ってサービスを提供するということが考えられる。
本来そのユーザが利用しないはずの時間帯（期間）には、最初からサー
ビスを提供しないことで、不正な利用者がシステムに接続しようと試み
るのを防止することができる。つまり、システムの利用が可能な時間を
制限することで、不正侵入の確率を減らすことができる。
システムが提供する機能としては、
・一日（
時間）のうちの利用可能または不可能な時間帯の指定
・一週間のうちの利用可能または不可能な曜日の指定
・利用可能または不可能な特定の日付（期間）の指定
が考えられる。
&'
特定のユーザに対して、システムを利用する際のアクセス経路を制限できなけ
ればならない。この設定はシステム管理者のみが実行できること。
（）公衆電話回線からシステムにアクセスできるユーザを制限できなければならな
い。
（*）ネットワークからシステムにアクセスできるユーザを制限できなければならな
い。
【解説】 ネットワークをすべて物理的な管理下におくのは困難であり、ネットワー
ク上を伝送される識別・認証データ等を不正に奪取して、それをもとに、
システムを不正利用される可能性がある。これを防止するためには、 つ
の対策が考えられる。
①利用できるシステム（端末）を制限し、ユーザがシステムを利用しよ
うとした時、アクセスしてきたシステム（端末）を確認することであ
る。実現手段としては、コールバック、ネットワークアドレスの確認
等が考えられる。
②利用できるネットワークそのものを制限し、特に危険度の高い公衆電
話網や無線の利用を制限することが考えられる。
③ネットワークを介してシステムを利用できるユーザを制限することも
有効である。
&' 特定のユーザに対して、システムを利用する際のアクセス手段を制限できなけ
ればならない。この設定はシステム管理者のみが実行できること。
【解説】 ユーザがシステムを利用する時、どのような手段でアクセスするかを制
限する。例えば、端末からのアクセスか、:- プロトコルによるア
クセスか等が考えられる。
&' アクセス経路によって、ユーザの特権を制限できなければならない。
【解説】 （）と同様の考え方に基づき、ネットワークを介した場合のシステムの
利用は、利用できる機能、権限についても制限できることが必要となる。
特に特権利用については、一般的にシステム管理者が特定の端末から利
用することを前提にし、一般のユーザが不正にその権限を利用すること
がないようにする必要がある。
&'
システムの利用を許可されたユーザに対して、以下の情報を表示できなければ
ならない。また、ユーザ自身以外がそれを消去してはならない。
（）前回システムを利用した日時、アクセス経路、アクセス手段。
（*）前回システムを利用した後、そのユーザ識別子でシステムへの接続に失敗した
日時または回数、アクセス経路とアクセス手段。
【解説】 前回システムを利用した後に、誰かがそのユーザの識別子を勝手に利用
してシステムに不正にアクセスする可能性がある。自分のユーザ識別子
を不正に利用されていないかどうかを、ユーザ自身が確認するためには
この機能が必要である。
この機能でそれを防止することはできないが、不正をユーザ自身で発見
することができ、対策を取ることが可能になる。
&' ユーザへの権限の付与、または剥奪、及び属性の変更に関する機能は、システ
ム管理者以外が利用できてはならない。
【解説】 ユーザがシステムを利用する際の権限の付与／変更等は、システムのセ
キュリティ方針に基づき、定められたシステム管理者だけが行うべきで
ある。
これはセキュリティの運用を一元化するために必要であり、システム管
理者以外がこの機能を利用できると、ユーザの権限を勝手に変更できる
ことになり、システム全体のセキュリティを維持することが困難となる。
&' セキュリティ制御に関する機能をグループ分けし、それぞれごとに利用できる
ユーザ（システム管理者）の設定を可能にしなければならない。
（）この機能を使用する際は、ユーザがその権限を有していることを確認しなけれ
ばならない。
【解説】 セキュリティ制御に関する機能は、一人にすべての権限を持たせるとそ
の人間が不正を働いた場合にチェックできず、かつ何でも実行できるの
で、被害が広がる可能性がある。このため役割を複数人で分担する方法
がよくとられる。この時、他の管理者がもつ権限の機能を利用できない
よう、セキュリティ制御に関する機能を分割して設定できる必要がある。
例えば、日常の運用でシステム管理者が不正を働くという可能性がある
が、この場合の被害を最小限にし、かつ監査等によってチェック可能と
するために、ユーザの権限の管理等を行っている管理者と監査を実施す
る管理者とを分離する等がある。
２．２．2 資源アクセス制御
資源の所有者または、システム管理者は、その資源への他のユーザからのアクセ
スを許可または禁止するために、システムで提供する機構を利用する。
システムの資源アクセス制御は、個々の資源への正当なアクセス権限を有する
ユーザに対してのみアクセスを許可し、ユーザと資源との間を仲介しなければなら
ない。
以下に資源アクセス制御に関する機能要件を列記する。
&'
システムは、資源へのアクセスを制御しなければならない。
【解説】 許可されていないユーザが、システムが保護対象とする全ての資源（例
えば、メモリや磁気ディスク）に存在する情報を利用（参照）したり、
資源を変更・破壊（削除）するのを防御するためには資源へのアクセス
を制御する必要がある。
&'
システムは、識別と認証を終了していないユーザに対しては、資源へのアクセ
スを許可してはならない。また、この資源へのアクセス制御は、システムが認
証済みのユーザ識別情報に基づいて実行されなければならない。
【解説】 許可されていないユーザが、資源にアクセスするのを防御するためには
識別と認証を受けずに資源を利用することを認めてはならない。識別と
認証を受けないユーザに資源のアクセスを許すと、他のユーザになりす
まして資源にアクセスすることが可能となり機密性が失われてしまう。
&'
システムは、各資源毎に個々のユーザあるいはユーザの集合として構成される
個々のグループからのアクセス権限を設定できなければならない。
【解説】 アクセス制御を行う資源単位は、システム全体という大きな範囲では識
別と認証を終えたユーザはすべて同じ扱いで全ての資源にアクセス可能
となり、個々のユーザ間では何の機密性も無くなってしまう。また、個々
の資源毎に機密性・重要性が異なり、個々のユーザ単位にその権限も異
なる。よって、各資源別に機密性を維持するためにはシステム内の資源
を一意に識別できる必要があり、その各々についてユーザからのアクセ
ス権限を設定できるようにする必要がある。またグループを構成できる
場合には、個々のグループからのアクセス権限も設定できるようにする
必要がある。
&
'
システムは、資源の利用性をできるだけ高め、かつ不当な利用方法から資源を
保護するために、アクセス権限をユーザの資源の利用方法によって分割して設
定できなければならない。すくなくとも、資源毎に「参照」「更新（書き込み）」
「実行（利用）」という権限を個別に設定できなければならない。
【解説】 本来は「参照」等、限られたアクセス権限だけを与えるべきユーザに当
該資源へのアクセス権限全てを付与することによって、そのユーザが本
来許可されていないはずの資源に対する更新、実行等を行うことができ
るようになり機密性を維持できなくなる恐れがある。「参照」権には、
磁気ディスクや磁気テープ等からのデータの読み出し等が該当する。
「更
新（書き込み）」権は、磁気ディスクや磁気テープ等への書き込み、お
よび資源の構成変更等が該当する。「実行（利用）」権は、プログラム
実行、処理機構の利用等が該当する。
この他にディレクトリ作成または、カタログ中のエントリ変更のための
アクセス権限として、「作成」と「削除」権を持つ事も考えられる。ア
クセス権限の細分化は実現レベルの問題であると考える。
&'
システムは、資源にアクセスしようとしたユーザに対するアクセス権限と、そ
のユーザが属するグループに対するアクセス権限の両方がその資源に設定さ
れている場合、ユーザに対するアクセス権限とグループに対するアクセス権限
のいずれを優先するかを統一しなければならない。
【解説】 ユーザのアクセス権限よりもグループのアクセス権限の方が大きい場合、
そのグループに属するユーザのアクセス権限が不当に拡大し、資源に対
して不当にアクセスするのを防御する必要がある。
&'
システムは、資源にアクセスしようとしたユーザに対するアクセス権限も、そ
のユーザが属するグループに対するアクセス権限もその資源に設定されてい
ない場合、初期値としてのアクセス権限を使用すること。また、システムはこ
の初期値としてのアクセス権限を設定する機構を提供しなければならない。
【解説】 新規のユーザのように明示的なアクセス権限が設定されていないユーザ
が、許可されていない資源にアクセスするのを防御するために必要。
例えば、明示的にアクセス権限が設定されているかどうかを判定可能な
場合には、上記のようにシステム管理者が指定したデフォルトに従う方
式でもよい。また、代替として明示的アクセス権限が指定されていない
ユーザを無くす方式として、システムへの新規ユーザ登録時にアクセス
権限指定を省略した場合には、必ず暗黙のアクセス権限が設定されるよ
うにしておくなどの方式も考えられる。
&'
システムは、ユーザの資源へのアクセス権限の確認とアクセスの許可を、少な
くとも資源のアクセス開始時（または、アクセスを開始するために資源を確保
する時）に、実施しなければならない。
【解説】 アクセス権限が確認され、許可を取得する以前に、ユーザが資源にアク
セスするのを防御するために必要。
例えばファイルの使用に際しては、ファイルのオープン処理要求時に
チェックするのが一般的である。
&'
システムは資源の所有者（資源のアクセス権限を変更することができるユー
ザ）を設定・変更するための機構を提供しなければならない。この機構の利用
は現在の所有者および、システム管理者だけに限定されなければならない。
【解説】 資源作成者の許可無しに、他のユーザが資源にアクセスするのを防御す
るために必要。また、該当資源内に記憶されている情報の機密性に変化
があった場合など、必要に応じて他のユーザからのアクセス権限を制御
できる必要が生じる。このような制御をできるのはその資源の所有者の
みであり、情報を作成した所有者という概念が必須である。
&'
システムは、新しく作成された資源のアクセス権限情報の初期値を指定するた
めの機構を提供しなければならない。
【解説】 作成した資源へのアクセス権限が明示的に設定される前に、資源作成者
以外のユーザが、当該資源にアクセスするのを防御するのに必要。
&' システムは、資源に対するアクセス権限の追加・削除等の内容を変更する機構
を提供しなければならない。また、これらの行為は、その資源の所有者とシス
テム管理者または権利を付与されたユーザに限定して許可しなければならな
い。
【解説】 アクセス権限の変更を許可されていないユーザが、資源へのアクセス権
限を不当に変更し、本来許可されていないユーザが資源にアクセスする
のを防御するのに必要。
また、該当資源内に記憶されている情報の機密性に変化があった場合な
ど、必要に応じて他のユーザからのアクセス権限を制御できる必要が生
じる。
&' システムは、コマンドやユーティリティで資源の複製を作成する場合、複製元
の資源に対するアクセス権限属性を複製された資源にも引き継がなければな
らない。
【解説】 システム管理者がバックアップを取るような場合に有効な機能である。
単純に複製された資源へのアクセス権限が緩和され、本来、当該資源の
利用を許可されていないユーザが当該資源にアクセスするのを防御する
ために必要。
&' システムは、指定されたユーザあるいはグループが所有しているすべての資源
と、指定されたユーザあるいはグループがアクセス可能なすべての資源のリス
トを出力するための機能を持たなければならない。また、その資源毎にアクセ
ス権限の内容も出力できる必要がある。この機能は、システム管理者以外に使
用させてはならない。
【解説】 資源に対するアクセス権限が不当に設定され、許可されていないユーザ
が資源にアクセスすることを察知するために必要。
&' システムは、特定のユーザあるいはグループについて、すべての資源への特定
のアクセス権限を剥奪することのできる機能を提供しなければならない。また、
この機能をシステム管理者以外に使用させてはならない。
【解説】 許可されていないユーザが不当に資源をアクセスしていることを察知し
た場合などにおいてこの機能を用いて、その行為を停止させるために必
要。
このためには、指定されたユーザあるいはグループについては、すべて
の資源について特定のアクセス権限を拒否するように制御できる必要が
あり、また、この機構は標準のアクセス管理機構を無視しなければなら
ない。
&
' システムが出荷時に提供される各資源は、その資源の意図された利用を可能に
するための、必要最小限のアクセス権限が付けられなければならない。システ
ムは、資源アクセス制御を実行するための制御情報テーブルおよびファイルを、
無許可のアクセスから保護しなければならない。
【解説】 システム出荷時に提供されるＯＳで使用するシステムプログラム、シス
テムファイルなどには、一般ユーザからのアクセスに対して必要最小限
のアクセス権限を付けるようにしてそのアクセスを制限すべきである。
許可されていないユーザが、アクセス権限を不正に変更したり、利用す
ることで機密管理が崩れ、資源に不正にアクセスするのを防御するため
である。
資源アクセス制御を実行するための管理情報とは、アクセス制御リスト、
グループリスト、システム日および時間などである。アクセスできるの
はシステム管理者に限定される。
２．３ 資源の再利用
資源の中には、あるユーザが使用を終えて一旦非割り当て状態になった後、他の
ユーザに再割り当てが可能なものがあるが、その資源には元のユーザのデータが
残っているかもしれない。システムはこのような再利用可能な記憶型資源に関し、
非割り当て状態の時、あるいは、他のユーザに再割り当て後、両方について、元の
ユーザ・データの開示を制限する機能を持たなくてはならない。次に記憶型資源の
再利用に関する機能要件を列記する。
&'
システムは、権限を持たないユーザが、非割り当て状態の資源に含まれる、元
のユーザのデータを入手できてはならない。
【解説】 想定する脅威の一例を示す。あるユーザがディスク上のファイルを消去
すると、そのファイルが存在したディスク領域は非割り当て状態となる
が、領域上には元のデータが残っているかもしれない。
この領域を別のユーザが直接アクセスして、元のデータを入手してしま
う可能性がある。
&'
システムは、資源を割り当てたユーザに、その資源が以前割り当てられていた
ときに格納された情報へ、アクセスさせてはならない。
【解説】 想定する脅威の一例を示す。あるユーザにディスクファイルを割り付け、
それを使用する前に、そのファイルの内容を読めば、以前そのディスク
領域を使用していたユーザのデータが入手できる可能性がある。
２．４ 監査
監査の目的は、システム上でのセキュリティに関係する行動（セキュリティ関連
事象）を記録し、分析することによって、ユーザ一人一人の責任追跡性を確保する
ことにある。従ってシステムは、あらゆるセキュリティ関連事象を最終的には個々
のユーザに結びつけ、監査証跡として記録できなければならない。
監査証跡自体のセキュリティ保護が必要であるとともに、記録された証跡を適時
適切にわかりやすいかたちで利用できる機能も欠くことができない。
監査機能要件は、証跡の記録機能と分析・報告機能に大別される。
２．４．1 記録機能
監査証跡は、それを分析し総合することによって個々のユーザのセキュリティ関
連行動の全体像を把握する目的で収集する。従って分散システム環境下であっても、
個々のユーザに関して収集するデータは、当該ユーザの直接的な行動はもとより、
間接的に当該ユーザに起因するあらゆる行動・事象を、システム全体にわたって当
該ユーザに関連づけて追跡できる情報を含むものでなければならない。
また、監査機能自体も、個々のシステム・ニーズや環境に使いやすく適応できる
ように、柔軟性を備えていることが要求される。
従って、監査証跡記録の機能要件は、
①どのような観点からどのような内容の証跡を記録するか
②証跡記録の機能自体はどのような特性を備えていることが必要か
を規定する必要がある。
&'
システムは、監査証跡を生成し記録することができなければならない。証跡内
容としては、それを事後に分析利用することによって、情報・資源の減失やシ
ステムの不正使用に対して、適切な管理対策をとれるだけの十分な情報を包含
していることが必要である。
【解説】 監査機能の最終目的は、システムの不正使用や、情報・資源の破損・減
失を防ぐことにある。そのためには、適切な管理対応策をとるのに十分
なデータと情報が必要になる。そして基本的には監査証跡がこのデータ
の基礎となるので、システムには確実かつ有効に監査証跡を記録できる
機能が要求される。
監査証跡が、適切な管理対応策がとれるだけの十分なデータと情報を包
含していてはじめて意味をなす。
&'
システムの基本機能として行う証跡記録のほかに、アプリケーションプログラ
ムから証跡記録をとることができる、ないしはアプリケーションが指定する代
替証跡ファイルに記録することができるように、%,（% ,$
-）が用意されている必要がある。これらのアプリケーションプログラ
ムの利用にあたっては、特権を必要とすること。
【解説】 監査機能は、個々のアプリケーション機能から独立していることが望ま
しいので、基本的にはシステム共通の基本機能として装備される必要が
ある。
しかし、個別のニーズ・環境に対応した、きめ細かい監査機能を実現で
きるように、アプリケーションプログラムて使える安全な %, が求めら
れる。
&'
セキュリティ関連事象に関するユーザの責任はシステム全体にわたり、行動の
発生から終了までの全過程で追跡可能でなければならない。分散システム環境
においても、ユーザ行動の直接的・間接的影響が及ぶすべてのセキュリティ関
連事象が、当該ユーザと関連づけて監査できることが求められる。
従って、当初の処理要求元ユーザに関する情報が以降の全過程で保持・伝
達されて、監査証跡と当該処理要求元ユーザの関連づけができなければならな
い。
【解説】 システムを使用する企業・組織のセキュリティ方針の下で、個々のユー
ザのセキュリティ関連行動の全体像を総合的に把握してその責任を追跡
することが監査機能の目標である。従って個々ユーザに関わるセキュリ
ティ関連事象は、それが当該ユーザの直接的行動によるものはもとより、
クライアント・サーバの関係で間接的に起因する事象も含めて、また当
該ユーザが直接に関わるシステムにおいてだけではなく、ネットワーク
を介して間接的に使用されるシステムにおいても、責任追跡が可能でな
ければならない。
この要件は、一つの情報システムが複数のコンピュータシステムの結合
でできている、いわゆる分散環境においても、構成するシステムの 2(
や通信プロトコルなどの環境・基盤に左右されることなく、処理要求元
ユーザとその行動責任を関連づけることを求める意味で、（介在する環
境条件にかかわりない）エンド・エンド要件と呼ばれる。
分散環境でこのエンド・エンド要件の追跡性が確保されていないと、監
査証跡がシステム間で一貫性を欠く可能性があり、この欠陥を利用する
セキュリティ侵害に対応できなくなる。
&
'
システムの通常稼働中でも、証跡記録対象となる事象のタイプを即座に変更で
きるような機能を備えていなければならない。
この動的変更管理機能としては、初期設定した監査対象事象の一部分を対
象からはずす、あるいはその他の事象を監査対象に入れたりはずしたりできる
ことが要求される。
この機能の実行は、特権を必要とすること。
【解説】 セキュリティ侵害は時に予想外の事態で発生しうる。その事実把握のた
めには当初想定した記録対象以外の事象をトレースすることも必要にな
る。ことにハッカーを典型とするオンライン侵害などに対しては、即時
の証跡記録採取が要求される。
ただしこの機能により、記録対象事象の変更が恣意的に行われることが
あってはかえって不正利用の原因となりうるので、実行は特権ユーザ（シ
ステム管理者）に限定すること。その場合、下記の①、②の付記が必要
となる。
①上記項目に関わらず、特権を要する行動は、すべて監査対象として
おかなければならない。
②上記項目に関わらず、監査対象事象の範囲を変更する行動自体は、
必ず証跡記録の対象とすること。
&'
最小限次に掲げる事象は監査証跡に記録する。この要件機能は、初期設定とす
ること。
【解説】 ①から⑮に掲げる事項は、一般的にどのシステムにも共通する基本監査
対象項目。
①監査の起動および終了
②失敗したユーザ認証
③不許可になった資源アクセス要求
④許可・不許可にかかわらず、すべての特権獲得の要求
⑤特権を必要とするすべての行動
特権を伴う行動は権限範囲が広く、一般業務に関連した資源や機能だけではな
く、セキュリティ上重要な機能や資源にもアクセスできる。例えば監査機能や
監査証跡の変更も可能になる。従って、特権行為は無条件で監査対象にしてお
かないと、特権を利用したセキュリティ侵害を惹き起こす可能性がある。特権
行動に対するセキュリティ上でのより厳しい管理は、内部関与者、ことに管理
者によるセキュリティ侵犯への対策の基本原則である。
⑥セキュリティ上重要な資源についてのすべてのアクセス要求
例えば監査証跡ファイル
⑦ユーザのセキュリティ情報の変更要求
例えばユーザ登録データやそのパスワードファイルなど
⑧ユーザ毎に設定されている特権の変更要求
⑨資源に設定されているアクセス権限の変更要求
アクセス制御リストが代表的な例
⑩セキュリティ構成の変更要求
例えば 2( が使う制御リスト／テーブル類。あるいは ?4@ において 3>
（3 !$ >!）を規定している::! :!!<- など
⑦∼⑩の各項目の情報はいずれもユーザのセキュリティ方針を直接表現してい
るので、その内容を変更する行動はセキュリティ上のきわめて重要な事象であ
り、原則として監査記録対象とされる。
⑪システムが提供する基本ソフトウェアの変更要求
基本ソフトウェアは、ハードウェアとともにシステムの基盤を形成する。すべ
てのセキュリティ機能やアプリケーション機能が乗っている基盤自体の整合
性・一貫性を確保することはシステムセキュリティの前提条件である。
⑫ログイン数の制限による新しいログインの失敗
⑬セションロックの開始／ロック解除要求／ロック解除
⑭ログインの終了
⑮他のシステムとのセキュリティに関する管理データの交換及び解釈
他システムを含む分散・混成システム全体の監査のためには、他システムとセ
キュリティに関する管理データ（アクセス制御リスト等）を交換する場合には
記録を残しておく必要がある。また、システム間で交換する管理データの解釈
が個々のシステムで異なると全体としてのセキュリティレベルを保持できない
ため、関連する全システムに一貫した解釈が必要である。
&'
最小限次に掲げる事象については監査証跡への記録対象に含めたり、はずした
りできる機能を備えていること。なお、この機能の実行は特権を必要とする。
【解説】 一般にどのシステムにも共通する監査対象のほかに、個別（企業・事業
所）システムのセキュリティ方針やユーザ（システム管理者）の判断で、
以下①∼⑧のようなセキュリティ関連事象やその他の事象を管理対象に
指定できることは、監査機能の柔軟性を確保する観点から必要である。
①成功したユーザ認証
特定ユーザに注目して選択的に監査する必要が生ずることがある。その場合、
当該ユーザの行動の全体像と個別行動を把握分析することになるが、そのため
にはユーザ認証から始まる一連の行動を、許可・不許可、成功・不成功にかか
わりなく、すべて証跡に記録して分析できる機能が必要になる。
②資源の作成・削除
③ディスクファイルへのアクセス
④テープファイルへのアクセス
⑤プログラムの実行
⑥オンラインコマンドの実行
⑦ユーザ（システム管理者）が定義した事象
監査機能自体が、個々のシステム・ニーズや環境に柔軟に対応できることが求
められる。また、企業・組織全体の監査ニーズに加えて、部門管理者の個別判
断によって監査対象を管理できる弾力性も必要である。
⑧特定のユーザ識別子に関わる行動
特定のユーザ識別子についてセキュリティ侵害の恐れが検知された際には、当
該ユーザ識別子にかかわる行動を選択的に証跡記録できるようにする機能が求
められる。ハッカーによるオンライン侵害や、内部のユーザを装った（ユーザ
識別子を使った）外部者によるシステム侵害等の場合に、このような機能が必
要になる。
&' すべての証跡記録は、最小限次の情報を含んでいること。
①事象の日付・時刻
②ユーザ識別子とアクセス経路とアクセス手段
アクセス経路：
ネットワーク
アクセス手段：
使用したプロトコル
③事象のタイプ
④アクセスした資源名
⑤可否結果（許可／不許可）
注）アクセス経路とはダイアルアップやＬＡＮ（A%4B<）経由を指
す。アクセス手段とは使用したプロトコル & 等' を指す。
&'
ユーザ認証の過程で、ユーザ認証情報は、監査証跡に含めてはならない。
【解説】 ユーザ認証はあらゆるセキュリティ機能の前提であり、なかでもパスワー
ドは（他の本人確認方式が実用化されるまでは）本人認証の最終的な根
拠情報である。そのために、何よりもパスワードの安全保護が必要であ
る。
①暗号化されていない平文パスワードをいっさい記録・保管しない。
②平文パスワードがシステム内で存在する機会を最小にすることは、
パスワード保護の基本原則である。
この意味でパスワードを保護するために、監査証跡といえどもユーザが
入力した平文データそのものを記録・保管してはならない。
&'
特定の端末やネットワーク接続の状況をリアルタイムで監視できるツールを
備えていること。このツールの使用には特権が必要とされていること。また、
どこを監視しているかをリアルタイムで表示できること。
&' 監査証跡に権限のないアクセスがなされないように、保護できなければならな
い。
【解説】 監査証跡それ自体に対して、不正なアクセスをされないようなセキュリ
ティ保護を行わなければならない。アクセスできるのはシステム管理者
に限定される。
&' 監査証跡ファイルを生成、消去、空にする等の維持・管理機能は、特権を必要
とする。
【解説】 無許可の監査証跡の変更によって監査を逃れるようなことがあってはな
らない。
&' 監査機能自体に権限のないアクセスがなされないように、保護できなければな
らない。
【解説】 監査機能自体の整合性、一貫性の確保。アクセスできるのはシステム管
理者に限定される。
&' システムが再起動されても、監査制御に関するデータ（例えば監査事象の設定
値）の一貫性を保持できなければならない。
【解説】 システムの再起動によって監査制御データが変更ないしはリセットされ
ることがあると、意図的にシステムを停止再起動させて、監査を逃れる
不正が考えられる。
&
' システムは、監査証跡ファイルのサイズを監視し、あるしきい値を超えたとき
にシステム管理者に通知できなければならない。またそのしきい値をシステム
管理者が設定できるための機能を提供しなければならない。
【解説】 システムの記憶領域不足により監査証跡の記録が停止することを未然に
防ぐための機能である。
&' 監査証跡の記録ができない事態が生じたときには
①アラーム（警告）をあげる（初期設定機能）
②システムを停止する
③監査記録の発生を無視または抑制する
などの対応措置ができなければならない。
【解説】 監査機能自体の障害への対応策を備えることが必要である。最小対応策
要件として、アラームやシステム停止機能が求められる。
&' システムは、生成した監査記録を永久的な監査証跡に格納しなければならない。
【解説】 停電で消えてしまうような監査証跡の格納場所では本来の機能が発揮で
きない。
&' システムは、システムの監査証跡格納場所の枯渇、または故障・攻撃等による
監査証跡の消失の数量を制限できねばならない。
【解説】 監査証跡は絶対に消失しない事が望ましいが、やむを得ない場合でも消
失する数量を最小限度にすべきである。
２．４．2 分析・報告機能
記録された監査証跡は、セキュリティ侵害対策のために利用することではじめて
意味がある。そのために監査機能の要件として、監査証跡にもとづいてセキュリティ
侵犯（ならびにその可能性）を即座に知らせるアラーム（警告）機能と、監査証跡
を目的別に分析し、わかりやすく報告にまとめる分析、報告機能とが求められる。
&'
記録される監査証跡にもとづいて、必要な場合にアラーム（警告）をあげる機
能を備えていること。そのためにシステムは、アラームのあげ方（例えば、ど
こにアラームを出すか、誰にアラームするか）を指定できる機能を持っている
こと。
【解説】 監査報告・利用形態の一つとして、事象発生とともにただちにアラーム
をあげる機能が必要とされる。ネットワーク経由のハッカー侵害を受け
たような場合は、即時対応こそがもっとも適切な管理措置となる。
また、セキュリティ侵害の恐れが検知された場合、事後監査を待つ間に
侵害を許してしまうのではなく、アラームによって即時対応を行い侵害
を未然に防ぐことも監査の目的である。
&'
監査証跡を、監査目的に応じて事後的に分析し、報告にまとめるためのツール
を備えていること。このツールを例外報告やサマリー報告のほかに、特定の
データやユーザ、通信機器に関しても詳細な報告が作れること。このツールは
システム管理者のみが使用できること。
【解説】 監査証跡は、これを分析し、わかりやすい報告にまとめることで役に立
つ。従って分析・報告ツールは大切な機能要件である。このツールはシ
ステム管理者のみが使用できる。
&'
個別ユーザ識別子にもとづき、任意・特定のユーザ（特権ユーザを含む）の行
動を分析できるツールを備えていること。
&
'
システム上のいかなる資源の変更に関する事象についても、報告可能であるこ
と。
【解説】 &'&
'両項目に関して
監査証跡の分析・報告の基本切り口はユーザと資源である。この切り口
をニーズによって任意に設定して監査実態を把握できることが求められ
る。なかでも、資源の変更に関わる行動・事象はセキュリティ確保に重
要な影響を持つ可能性が大きいので、その報告出力ができることは必須
条件である。
&'
上記のツール類は、システムの通常稼働時に同時平行的に使用可能であること。
【解説】 監査機能の弾力的運用の観点から、分析・報告ツールはシステム稼働中
でもいつでも使用できる必要がある。
２．５ 完全性
完全性とは、システム内で行われる各種の変更操作が、定められた手段、定めら
れた手順通りに実行されている状態をいう。
例えば、ユーザがディスク上にデータを書き込む場合、ディスクの任意の位置に
書きこむことは許されず、ＯＳが定めたファイル・システムの規則にしたがって、
空き領域の割り当てをあらかじめ行う必要がある。
これらは、システム内のデータの完全性を維持するための機能であり、通常は、
ユーザによるデータの変更は、システム提供の（セキュリティ機能を有した）ソフ
トウェアを介してのみ許されるというメカニズムで実現されている。ただし、この
ソフトウェアが持つべき機能は 2( ごとに多種多様なものが考えられるので、本書で
は機能要件としては取り扱わず、データの完全性の検査に関するもののみとしてい
る。
一方、このセキュリティ機能はデータだけではなく、システム提供のソフトウェ
ア自身にも適用されるべきであり、これをシステムの完全性と呼ぶ。例えば、シス
テム提供のソフトウェアの変更は、定められた改版手続きでのみ実施されなければ
ならない。
２．５．1 システムの完全性
&'
システムは、システムまたはユーザのプログラムとデータを、その他のユーザ
のプログラムとデータから分離して保護する機能を提供しなければならない。
【解説】 マルチ・ユーザ 2( の多くは、ユーザ（プロセス）ごとに異なるアドレス
空間を使用して、プログラムやデータを分離し、故意あるいは偶発的な
エラーにより、システムのセキュリティ機能が変更されることを防いで
いる。
&'
システムは、システムコンソールがある場合、その使用に関する管理と監査を
行う機能を提供しなければならない。
【解説】 システムコンソールの操作は、システムのセキュリティ機能を含めた各
種機能に重大な影響を与える。従来は、システムコンソールは入室管理
などの物理的な対策で十分であったが、最近のマルチ・コンソール、リ
モート・コンソール機能の出現により、一般の端末装置と同様のセキュ
リティ機能（例えば、ユーザの識別、認証）が求められるようになって
きた。
&'
システムは、システムが提供するソフトウェアの実行、変更、削除を禁止、制
限、または検出する機能を提供しなければならない。
【解説】 システムが提供するソフトウェアの中には、例えばシステムのメインテ
ナンスや回復のためのユーティリティなどがあるため、ソフトウェアご
とに、実行できるユーザを制限できることが望ましい。また、システム
の提供するすべてのソフトウェアの変更（改版を含む）や削除は、権限
を持つユーザ（例えばシステム管理者）に限るべきである。
&
'
システムが正常に動作することを管理者が確認できなければならない。
【解説】 この確認機能は、電源投入時、オフラインで動作すればよい。
&'
システムは、現在設定されているすべてのセキュリティ関連パラメータ値を出
力する機能を提供しなければならない。また、当該データへのアクセスは制限
できなければならない。
【解説】 システム自身は十分なセキュリティ機能を有しているにも関わらず、故
意または過失による不適切なパラメータ設定のため、それら機能が適切
に動作していない状態を検出するのが目的である。
&'
管理者の操作ミスによりセキュリティ機能が誤動作しないように有効なパラ
メタ値をチェックできなければならない。
&'
システムのセキュリティ機能を妨害や誤操作から守るために、セキュリティ機
能は他のアプリケーションと分離した領域に置かなければならない。
&'
システムはシステムの設置や構成や管理等のセキュリティ関連の管理機能を
使用する特権を持ったユーザ達を他の一般ユーザから区別できること。
２．５．2 データの完全性
&'
システムは、データの完全性を確認（データの改ざん・破壊を検出）するため
の手段をユーザが利用できるようにしなければならない。
【解説】 このような手段として、例えば暗号技術の利用、チェックサムなどが考
えられる。また、対象となるのは資源上に保存されたデータだけでなく、
通信回線を介して送受するデータも含まれる。
&'
システムは、指定された資源に関して、最後に行われた変更の日時及び変更し
たユーザの識別情報を出力する機能を提供しなければならない。
【解説】 これらの情報は、データの完全性に支障があった場合の原因追及手段と
して、最低限必要なものである。
２．６ サービスの信頼性
&'
システムの動作に関する障害の発生を検出しなければならない。検出した障害
発生の事実は記録する必要がある。また回復可能な場合には障害を回復しなけ
ればならない。
&'
障害その他の原因によりシステムの運用継続ができなくなった場合でも、運転
中と同程度のセキュリティを保ちながら回復を行うことが出来なければなら
ない。
【解説】 システムまたはそこに蓄積された情報が、システムの回復中に通常の運
転中以上の危険にさらされてはならない。
&'
ファイルのバックアップと復旧との手段が備えられていなければならない。こ
のバックアップをとる作業の実行と作成されたバックアップ・ファイルへのア
クセスは、特権を有するシステム管理者のみであること。
【解説】 ファイルの復旧に際しては、アプリケーションプログラムとの同期を取
るためのチェックポイント機能（関連するファイルの整合をとって復旧
する機能）の利用が必要になることがある。
&
'
一般ユーザの行為によって他のユーザがシステムを利用できなくなることが
あってはならない。
【解説】 一般ユーザが自分以外のユーザのファイルに対するアクセス権限を変更
してアクセス不能にすることなどが出来てはならないのは言うまでもな
いが、それ以外にシステムの共用資源（メモリ領域、ファイル領域、,?
（ ,!! ?）能力、回線容量など）を一般ユーザが大量
に占有し、他のユーザに使えなくすることなどは、たとえそれが故意に
よるものでなくとも、防止できなければならない。
&'
システムの重要な共用資源について、ユーザが占用できる限度量をユーザ毎お
よびグループ毎に設定できる必要がある。
【解説】 （
）の解説に述べたようなシステム共用資源の独占現象を防ぐために有
効な機能要件である。
２．７ ネットワーク上のデータ保護
&'
保護が完全でないネットワークを利用する場合、暗号機能を使用して、盗聴防
止のためデータを秘匿すること。
【解説】 暗号機能については、最低限、その時点での技術動向等を考慮し、安全
と思われるアルゴリズム・鍵長等を、データの重要度・暗号化速度・コ
スト等に応じて選択すること。暗号鍵の生成方法、配布と確認、運用時
の保管、有効期限、バックアップに関して、安全性を考慮すること。
&'
保護が完全でないネットワークを介してデータを送受信する場合、データの不
正な再送、挿入、削除、改竄を検知して、不正なデータの使用を防止する手段
を講じなければならない。
&'
ネットワークを介してデータを送受信するときは、互いに相手が認識されてい
ること。
【解説】 ネットワークを介してサーバ間やサーバ・クライアント間でデータを送
受信するときは、ネットワークの構成が決まっているので直接通信する
相手も既知のはずである。特にダイヤルアップによるアクセスの場合等
は、通信相手を確認することが重要である。未知の相手とデータを送受
信することは危険である。
【付録Ａ】 国際的なハーモナイズ状況
米国
イギリス
カナダ
TCSEC
(1985)
MSR
(1993)
Green Book
ドイツ
フランス
Blue/White
/Red book
Blue/White
Book
CTCPEC
(1991)
FC
(1992)
ＥＵ
ITSEC
(1991)
CCEB(CCIB)
日本
安全対策
基準他
CC 0.9
(1994)
CC 1.0
(1996)
CC 2.0
(1997)
CC 3.0?
(1998?)
ISO/IEC JTC1 SC27 WG3
基本要件・機能編
1.0
(1994)
WD/CD
(1996)
基本要件・機能編
2.0
(1997)
CD
(1997)
DIS
(1998?)
矢印の意味
複数の基準の統合
CC 4.O?
(1998?)
IS
(1998?)
同等の内容
対応する要件の配慮
標準化
【付録Ｂ】ＣＣの構成
１．ＣＣの構成
ＣＣは、１章でも述べているように、米国、カナダ、ＥＵ（ ?，
ＥＣから名称変更）によって開発中のコンピュータセキュリティ評価基準である。
１９９６年１月に発行されたＣＣ第１版は、次に示す構成から成り立っている。
ＰＡＲＴ１：導入及び一般モデル& $'
ＰＡＲＴ２：セキュリティ機能要件&( - 6 $!'
ＰＡＲＴ３：セキュリティ保証要件&( !! 6 $!'
ＰＡＲＴ４：プロテクションプロファイル（,-,,-!'
２．ＣＣにおけるセキュリティ評価基準のモデル
ＰＡＲＴ１で示されたモデルを図示すると下記の図のようになる。
網カケを行った部分がＣＣで作成している箇所である。
一般的なセキュリティ目標
(Security Target)
機能要件(PART2)
保証要件(PART3)
分類(family)
一般的要件を
体系的に整理
分類(family)
分類(family)
分類(family)
レベル１ 分類(family)
レベル１ 分類(family)
レベル２ レベル１
レベル２ レベル１
レベル１
レベル２
レベル２
レベル１
レベル２
レベル２
参照
参照
個々のユーザ／
システムごとの
セキュリティ
目標
要件１
要件１
要件２ 要件１ 要件２ 要件１
要件３ 要件２ 要件３ 要件２
要件３
要件３
保証要件
機能要件
プロファイル
プロファイル
機能要件
保証要件
プロファイル
プロファイル
プロテクションプロファイル１
プロテクションプロファイル２
プロテクションプロファイル(PART4)
参照
各国標準
プロファイル
ユーザ定義
プロファイル
特定用途向け
プロファイル
【付録Ｃ】用語集
本書の２章（機能要件及びその解説等）で使用している用語等について解説する。
アクセス［!!］
（１）ユーザによるシステムや資源の利用（の総称）。
（２）ユーザによるシステムの利用。システムアクセス。
（３）ユーザによる資源の利用。ディスク上のファイルの読み出し、更新等。資
源アクセス。
アクセス経路［!!］
システムにアクセスする時に使用する通信経路を意味する。ＬＡＮや電話回線に
よるダイヤルアップ等を指す。
アクセス手段［!!$］
システムにアクセスする時に使用するプロトコルを意味する。 等を指す。
アクセス制御［!!］
正当なユーザにのみシステムの利用を許可し、また、システムの利用を許可され
たユーザに許可された権限の範囲内でのみ資源を利用させるように制御し、不正
を防ぐこと。「システムアクセス制御」及び「資源アクセス制御」参照。
アクセス制御リスト［!!!］
資源に対するアクセスを許可されたユーザとそのアクセス権のリスト。
暗号［］
データの機密性を保つために、データを意味がわからないように変換するための
原理・方式。データの完全性の確認（データの改ざん・破壊の検出）等にも応用
される。
暗号アルゴリズム［$，］
暗号化の手順を暗号化アルゴリズム（$）、復号の手順を復
号（化）アルゴリズム（$）といい、暗号化アルゴリズムと復
号アルゴリズムをまとめて暗号アルゴリズムという。
暗号化［］
データ（平文）を意味がわからないように変換すること。その逆変換を復号（化）
という。
暗号鍵［<］
暗号化または復号（化）のアルゴリズムに入力される変換のためのパラメータの
総称。例外的な場合を除いて、秘密に保持されるべきもの。単に鍵（<）ともい
う。
一貫性［!!］
分散システム環境等において、セキュリティに関する管理データ（アクセス制御
リスト等）が矛盾のない一貫した解釈であること。システム内またはシステム間
において、セキュリティ方針に従ったセキュリティレベルが保持されるためには、
このような一貫性が必要である。
一般ユーザ［ !］
システム管理者以外のユーザ。システム運用やセキュリティ管理に関して特別な
権限を持たない。
可用性［#*］
ユーザに許可された範囲内で、システム及び資源の利用が常時可能な特性。許可
されたユーザがサービスの拒否に会わないこと。
監査［ ］
不正なシステム利用や資源アクセス等のセキュリティ上の異常を検出し、システ
ムのセキュリティ管理を確立されたセキュリティ方針通りの妥当なものにするた
めの、システムやアプリケーションプログラムによる自らのセキュリティ関連事
象に関する記録とシステム管理者等によるその記録の分析。
監査者［ ］
監査を実施する権限を持つ人。
監査証跡［ ］
監査を的確に行うためのシステムやアプリケーションプログラムが自らのセ
キュリティ関連事象に関して記録するデータ。
完全性［］
「データの完全性」、「システムの完全性」を参照。
機能要件［- 6 $］
情報システム、または、情報システムを構成する個々の製品が具備すべきセキュ
リティ機能を定めた要件。
機密性［-］
未認可のユーザまたはプロセスにデータの開示や利用を許可せず、データの秘匿
が保たれる特性。不正なデータの流失が防止されること。
脅威［］
（１）システムにセキュリティ上の被害を与える可能性のある行為・事象。
（２）システムにセキュリティ上の被害を与える可能性のある、主として人為的
な故意・過失による行為・事象。
許可［ 9］
権利の許諾がなされること。
資源へのアクセス権限を持つユーザであっても、資源にアクセスをする際に事前
にアクセス許可を得る必要がある。
グループ［ ］
システムにより識別される、アクセス権限等を共通化するための指定されたユー
ザの集合。
グループ識別子［ "： -］
システム内で、各々のグループを一意に識別するための識別情報。
コンピュータシステム［$ !!$］
一つのオペレーティングシステムが動作するハードウェア、ソフトウェア等から
なる構築物。
サービスの拒否［-!#］
システムや資源の利用が障害・妨害等により停止されること。または、効率的な
利用ができないこと。
識別［-］
システム内部でユーザ、資源を一意かつ監査可能な形で区別すること。
識別子［"：-］
システム内でユーザ、グループ、資源を一意に特定するための符号。
識別情報［--$］
システム内でユーザ、グループ、資源を一意に特定するための情報。識別子等。
資源［! ］
コンピュータシステムを構成するハードウェア、ソフトウェア、データ（システ
ムデータ、ユーザデータ）のうち、評価対象が提供するセキュリティ機能が保護
対象とするもの（例．メモリ内のデータ、磁気ディスク上のファイル）。
資源アクセス制御［! !!］
ユーザによる資源の利用を、ユーザ毎に設定された資源へのアクセス権限により
制御し、権限のないユーザには当該資源へのアクセスを許可しないこと。
資源の再利用［*C !］
一度使用され、システムに返却された記憶型資源を、ユーザまたはプロセスに割
り当て、再び利用可能な状態にすること。
資源の所有者［B-! ］
資源（情報）の作成者であり、当該資源のアクセス権限を変更できるユーザ。ま
たは、当該資源のアクセス権限を変更できる権限を付与されたユーザ。
システム［!!$］
評価対象。システム内で、個々のユーザ及び資源は一意に識別できなければなら
ない。
システムアクセス制御［!!$!!］
ユーザによるシステムの利用を、ユーザ毎に設定したシステムへのアクセス権限
により制御し、権限のないユーザには当該システムへのアクセスを許可しないこ
と。
システム管理者［!!$$!，# !， 9 !］
システム運用やセキュリティ管理に関して責任と特別な権限を有するユー ザ。
システム全体の責任者、システムオペレータ、セキュリティ管理者、システム監
査者等。
システムの完全性［!!$］
人為的な故意・過失による操作、偶発的なシステムエラー等が発生しても、シス
テムのセキュリティ管理機能が正常に保たれる特性。
情報システム［3!!$：-$!!$］
個々のコンピュータシステム、または、接続された複数のコンピュータシステム
からなる特定の情報技術設備（の総称）。
情報セキュリティ［3! ：-$! ］
「セキュリティ」参照。
省略値［- ］
システムの機能を利用する際、ユーザが特別な指定をしないときに設定される値。
セキュリティ［! ］
（１）情報システム内のデータ（システムデータ、ユーザデータ）、ソフトウェ
ア、ハードウェアを、それらに被害を与える可能性のある物理的・人為的
等の行為・事象から保護すること。
（２）主として人為的な故意・過失による行為、事象から情報システム内のデー
タ（システムデータ、ユーザデータ）、ソフトウェア、ハードウェアを保
護すること。機密性、完全性、可用性がセキュリティ上考慮すべき主要な
３要素である。
セキュリティ関連事象［! ##］
システムのセキュリティに関連するシステム内におけるユーザやシステムのす
べての行為・事象。具体的には、ユーザ認証の成功・失敗、システムアクセスの
許可・不許可、資源アクセスの許可・不許可及び許可の内容、ユーザに付与する
アクセス権限の変更、特権獲得の要求等。
セキュリティ機構［! $!$］
セキュリティ機能を実装したシステム内の仕組み。
セキュリティ方針［! ］
システムにおいて、どのようなセキュリティ上の脅威に対処し、どのようなセ
キュリティレベルを維持するかを明確にした方針。具体的には、システム内のデー
タを保護するための一連の規則等。
追跡性［ *］
あるユーザの行為が、最初のシステムログインからシステムログアウトまで、一
意に追跡できる特性。
データの完全性［］
人為的な故意・過失による行為、偶発的なシステムエラー等によって、データが
改ざん・破壊されない特性。
認証［ ］
個々のユーザ、マシン及びプロセス等の身元の正当性を証明すること。
代表的な認証機構としては、パスワード及び本人に固有な身体的特徴を利用した
認証方法がある。
認証情報［ -$］
個々のユーザ、マシン及びプロセス等の身元の正当性を保証するために使用され
る情報。
ネットワーク［B<］
コンピュータシステムを接続する物理的な通信路・通信網。
パスワード［!!B］
秘密の本人認証情報であり、通常は文字列から構成される。
評価［# ］
情報システム、または、情報システムを構成する個々の製品を評価基準の定義に
照らして、合致しているかを判定すること。セキュリティ評価。
評価基準［# ］
情報システム、または、情報システムを構成する個々の製品のセキュリティ充足
度を判定するための基準。機能要件及び保証要件からなる。
評価対象［32D-# ］
セキュリティ評価の対象とする情報システム、または、情報システムを構成する
個々の製品。正確には、セキュリティ評価の対象とする、一つのコンピュータシ
ステム、または、接続（ネットワーク接続、分散システム環境）された複数のコ
ンピュータシステムにおけるソフトウェア（システムソフトウェア、ミドルソフ
トウェア、アプリケーションソフトウェア）、ハードウェアの範囲。
復号（化）［］
意味がわからないように変換（暗号化）されたデータ（暗号文）を意味のわかる
元のデータに戻すこと。
プロセス［!!］
コンピュータ内部でプログラムを実行する単位。タスクとも呼ばれる。個々の
ユーザの代理として動作することがあり、このときにはシステムは識別・認証や
アクセス権限に関し、ユーザと同様に扱う。
分散システム環境［!* $ !!$#$］
複数の物理的なコンピュータシステムから構成されているシステム形態。分散環
境。分散システム。
平文［1，1］
暗号化が施されていない通常の形態のデータ（テキスト、画像、音声等）。平文
を暗号化したものを暗号文（1）という。
保証要件［!! 6 $］
機能要件の実現の確かさを保証するための要件。
ユーザ［ !］
システムを利用する人間。または、システム内で特定のユーザの代理として処理
を実行する当該ユーザの識別情報を有するプロセス。
ユーザ識別子［ !"： !-］
システム内で個々のユーザを一意に識別するための符号。ユーザを識別するため
の識別情報。
ログアウト［ ］
サーバに接続したパソコンや端末からの、サービスの利用を終了すること。
ログイン［］
サーバに接続したパソコンや端末からの、サービスの利用をシステムから許可を
受け開始すること。通信回線やＬＡＮを介した接続の場合と、サーバへ直接接続
する場合とがある。
コンピュータセキュリティ基本要件・機能編
【第 版】
平成 年８月
発行 社団法人 日本電子工業振興協会
印刷 有限会社 矢部印刷