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

58
コンピュータセキュリティ 【第2

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

Page 1: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

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

機能編

【第2版】

平成9年8月

社団法人 日本電子工業振興協会

Page 2: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

1.はじめに ���������������������������������������������������������������������������������������������������������� �

1.1 基本要件作成の目的と経緯 ���������������������������������������������������������������������� �

1.2 海外動向 ��������������������������������������������������������������������������������������������������� �

1.3 基本要件・機能編の作成方針と性格 �������������������������������������������������������� �

1.3.1 概要��������������������������������������������������������������������������������������������� �

1.3.2 作成方針 ������������������������������������������������������������������������������������� �

1.3.3 本書の想定する対応範囲 ������������������������������������������������������������ �

1.3.4 想定する読者 ������������������������������������������������������������������������������ �

1.4 評価対象 ������������������������������������������������������������������������������������������������� ��

1.4.1 セキュリティ方針 ��������������������������������������������������������������������� ��

1.4.2 評価対象 ����������������������������������������������������������������������������������� ��

1.5 想定するシステムモデルと用語の定義��������������������������������������������������� ��1.5.1 ユーザ ��������������������������������������������������������������������������������������� ��

1.5.2 資源������������������������������������������������������������������������������������������� ��

1.5.3 システム ����������������������������������������������������������������������������������� ��

1.5.4 ネットワーク ���������������������������������������������������������������������������� �

1.5.5 分散システム環境 ��������������������������������������������������������������������� �

1.6 本書を利用したセキュリティ評価の実施 ����������������������������������������������� ��

1.6.1 セキュリティ評価の実施方法 ��������������������������������������������������� ��

1.6.2 想定するセキュリティ評価の実施方法 ������������������������������������� ��

2. セキュリティ機能要件 ������������������������������������������������������������������������������� �

2.1 識別と認証 ��������������������������������������������������������������������������������������������� �

2.1.��識別 ���������������������������������������������������������������������������������������������� �

2.1. 認証 �������������������������������������������������������������������������������������������� ��

2.2 アクセス制御������������������������������������������������������������������������������������������ �

2.2.� システムアクセス制御���������������������������������������������������������������� �

2.2. 資源アクセス制御����������������������������������������������������������������������� �

2.3 資源の再利用������������������������������������������������������������������������������������������ �

2.4 監査 �������������������������������������������������������������������������������������������������������� ��

2.4.� 記録機能 ������������������������������������������������������������������������������������� ��

2.4. 分析・報告機能 �������������������������������������������������������������������������� ��

2.5 完全性����������������������������������������������������������������������������������������������������� 2.5.� システムの完全性�����������������������������������������������������������������������

2.5. データの完全性 �������������������������������������������������������������������������� �

2.6�サービスの信頼性 ������������������������������������������������������������������������������������ �

Page 3: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2.7�ネットワーク上のデータ保護������������������������������������������������������������������� �

【付録A】 国際的なハーモナイズ状況 ������������������������������������������������������������� �

【付録B】CCの構成������������������������������������������������������������������������������������������ �

【付録C】用語集 ������������������������������������������������������������������������������������������������� �

������������������������������� !����"�#����$����%!!���������&���"%'

�$� ���� (�� ����� �$$������ ) �$� ���� (�� ����� �#�� ������ �������� ( *+

�$$�����)

� �������

本書は、(社)日本電子工業振興協会コンピュータセキュリティ委員会、コンピュー

タセキュリティ評価基準専門委員会により作成されたものです。

本書の著作権は(社)日本電子工業振興協会が有しております。書籍、文献等に引用、

掲載を行う際には、「����"%� �$� ����(�� ����� �$$����������」または「�電子

協 ����年コンピュータセキュリティ委員会」と明記してください。

Page 4: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

1.はじめに

1.1 基本要件作成の目的と経緯

今日、さまざまな業務処理分野において、情報システムの重要性が増して来ると共に、インターネットのような不特定ユーザと相互にネットワークで接続されたコンピュータが増加している。これにより、情報セキュリティが大切な関心事のひとつとしてクローズアップされて、情報システムの持つセキュリティレベルの客観的評価が求められるようになってきた。このようなセキュリティ評価を客観的に行うための尺度は、通常、評価基準書(�#�� ������ �������)と呼ばれる各種基準のセットである。この基準をすべて満たしていることで、そのセキュリティレベルに達していると評価できるのである。ここでいうセキュリティ機能の客観的評価とは、必ずしも第三者機関による評価だけを意味しているのではなく、ユーザ自身による自社システムの評価や、メーカによる自社製品の自主評価も含んでいる。評価の公平性が求められる政府調達はともかくとして、民間市場においては、評価コストやタイムリな出荷を可能にするというようなことからむしろ後の2者の方が、評価基準への期待が大きい。評価基準の制定に関する海外動向については、「��2海外動向」で述べるが、日本以外のコンピュータ先進国では既に開発を行い、一部では運用を始めているのが実情であり、国際的な標準化も着手されている。一方日本では、従来から通商産業省の「情報システム安全対策基準」を始めとする各種の対策基準があり、ユーザのシステム構築におけるセキュリティ機能充足のガイドラインとして活用されてきたが、欧米のように技術的対策に焦点を当てたセキュリティ評価基準はなかった。このため日本も、欧米と同じ考え方の評価基準を明示的に持つことが、情報システムのセキュリティ向上、国際社会における協調関係の醸成、情報社会のボーダーレス化促進に役立つと判断された。その後「��2海外動向」で述べるように、欧米各国の各々の評価基準はCC( �$$��� �������)として集約される事になり、その作業が進行中であり、1996年1月には第1版が発行された。ここで日本も独自に評価基準を開発するのは、いたずらにハーモナイズ対象を増やすだけであり、評価基準の国際的集約作業を遅らせるだけであると判断し、日本としては、CCの発行を待って、それを日本の評価基準の要件項目として導入する事にした。その代わりに、CCの集約作業の過程でのレビューに参加し、CCへのコメントで日本の立場の反映を図ることにして、コメントを提出してきた。セキュリティ要件は、本来適用領域毎に異なるものであり、この特性に対応するために、CCではPP(,���������� ,��-���)という考え方を採用している。PPは適用領域または個々のシステム毎に適用するセキュリティ要件のセットを記述した

Page 5: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

もので、適用領域または各システムに対応して作られる。CCの要件集(パート2および3)はこのPPを規定するための要件を各セキュリティ項目ごとにレベル分けして全て列記したものであって、それ自身は特定の要件のセットを規定しているものではない。パート4では3つの要件のセット(PP)をサンプルとしてあげている。日本ではCCに基づくPPの一つとして、日本ではCCに基づくPPの一つとして、基本的なセキュリティ要件のセットを開発することにした。これはユーザがシステムを構築する際のベースとして参照できるものであると共に、ベンダにおけるセキュリティ製品の開発指針としての参照を可能にするものである。セキュリティ要件には2つの観点がある。即ち、必要なセキュリティ機能がシステムに導入されているかを評価する機能(. �����������)の観点からの機能要件と、その機能がどれだけ確実に実現されているかを評価する保証(%!! �����)の観点からの保証要件である。本基本要件・機能編は、上記の基本的なセキュリティ要件のうちの機能要件を規定したものであり、保証要件については、基本要件・保証編を参照されたい。この機能要件のセットは、従来の安全対策規準とは以下の点で異なる性格を持つものであり、この点からも機能要件のセットを新たに検討して作成する必要があった。・⦆評価基準は基本的に評価対象とするシステムの持つべきセキュリティのレベルによって異なるものである。それを実現できるようにするために、マルチユーザ環境をサポートするシステムにおける必須要件のみを規定する基本要件が必要であること。・⦆政府関連システムの調達要件として使用される場合には、製品仕様の前提条件となるようなものであること。・⦆今後CCが国際標準になれば、セキュリティ評価について欧米諸国をはじめ各国との相互認証が行われることが想定される。その際の各国の基準書とハーモナイズされるものが必要である。

CCは、現在第2版に向けてコメント反映が行われている。本基本要件・機能編第2版(以下、本書)は、基本要件・機能編第1版を基に、CC第1版のPPのCS3& �$$�������(�� ������'の要求項目をたたき台に、基本要件として相応しいと思われるCC第1版の要求項目を採用し、作成された。ただし、CCには複雑にネットワーク化されたコンピュータのセキュリティ機能の項目が不足していることから、この分野を目指して作成された、ECMA&� ������� �$� ���� /�� -��� ���!0

%!!��������'のE-COFC &�1������� �$$������� 2�������� . ������������!

��!!'を参考にして、ネットワーク関係の項目を設定した。これにより、本書は、今日の日本で使われるコンピュータシステムの基本的なセキュリティ要件となったと

Page 6: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

考える。

1.2 海外動向

セキュリティ機能評価への関心は、当初専ら情報の機密性( ��-�����������)に限られていたが、次第に情報の完全性( ���������)やシステムの可用性(%#����*�����)にも焦点があてられるようになった。先ず、米国において国家安全保障上の理由から、機密保護が必要な情報( ��!!�-���

����)を取り扱う情報システムのセキュリティを確保する必要性が叫ばれた。そのために、製品の購入時におけるセキュリティ機能の観点からの判断基準として、1985年に国防総省によってTCSEC(3� !���� �$� ���� (�!��$� �#�� ����� �������、通称:オレンジブック)が制定された。この基準は、機密性偏重のため、商用領域への適用には問題があるものの、国防領域においては、NCSC(4������� �$� ����(�� ����� �����)による評価で多くの運用実績があり、定着している。TCSECは、上述の理由で商用領域への適用に問題がある他に、その運用においては評価過程にかなりの時間と経費を要することから、商用および非軍事分野での利用も考えた新しい連邦評価基準FC(.������� �������� -��� ��-��$�����

3����������(�� ����)の検討が、NSA(4��������(�� �����%�����)とNIST(4����������!��� ����-�(�������!�����3���������)の共同作業として1991年に開始された。この作業の一環として、商用および非軍事向けのシステムが具備すべき、最低限の機能要件の検討が行われ、その結果は、MSFR(/���$ $�(�� ����

. ������������ 5�6 ���$���!)としてまとめられた。MSFRは、更に保証要件を加えてMSR(/���$ $�(�� �����5�6 ���$���!�7�/��������)として刊行されている。FC自体は1992年12月にバージョン1.0がレビュー用に公開された。特定の利用分野を前提としないFCでは、本来的に利用分野毎に異なるセキュリティ要件を、どの様に扱うかが問題となる。この解決のために、プロテクション・プロファイルPPの概念が導入された。PPとは、利用分野毎ないしは個別システム毎にセキュリティ要件を記述したものである。FCは、PP記述のための基本的枠組みを与える第1部と、具体的なPPを示した第2部とからなっている。FCでは商用・非軍事用の3種のPPと、機密用(軍事用等)の4種のPPとが示されている。ただし、第2部で示されたPPだけしか許されないのではなく、FCの考え方では、基本的にオープンエンデッド(開放的設計)になっており、誰でもPPを作ることができ、作られたPPは登録して広く利用する事が可能な運用が考えられている。一方欧州では、英、独、仏等の国々で、それぞれ独自の評価基準を作成し、その運用が計画された。しかし、欧州の市場統合を控えて、EC(� ������� �$$ ����)

Page 7: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

委員会は域内各国が異なる基準を運用することに危惧を覚え、セキュリティ評価基準の統一に乗り出した。この結果作られたものがITSEC( ��-��$�����

3���������� (�� ����� �#�� ������ �������)であり、1991年にENV(� ������!����4��$�8���4��$:欧州準規格)として暫定運用が始められた。現在英、独、仏で正式運用されている。ITSECは機能要件と保証要件とを分離し、機能要件については具体的な要件を示さず(ただし、参考例としてTCSECの各クラスの機能要件相当等の複数の機能要件クラスを添付)、記述法だけを規定して評価対象毎に記述する考え方を採用することで、評価対象システムの適用領域を限定せずにオープンエンデッドなスタイルを採っている。またカナダでは、TCSECを参考にし、ITSECの考え方も取り入れて、独自の評価基準CTCPEC( �������� 3� !���� �$� ���� ,��� ��� �#�� �����

�������)を作成した。この作業は米国におけるFC作成作業よりも先行したため、CTCPECの考え方はFCに大きな影響を与えた。これらの各国での評価基準作成作業を受けて、評価基準の国際標準化がISO/IEC JTC1 SC27&������������������2�����9������-���(��������9�����

:� ���� �������������� ����������������� �$$�!!���� ������ 3��������� �$$������ �

( *��$$�������'に取り上げられ、WG3&;��<����=�� ���'として作業が始められた。ここでは、当初ITSECが原案として提案され、後にFCをベースとした修正提案がカナダの支持を得て米国から出された。この結果、評価基準の国際的ハーモナイズの必要性が認識され、EC委員会(英、独、仏)、米国およびカナダ政府によって、CCプロジェクトが開始され、CCEB& �$$��� ������������������>����'が結成された。この成果としては、94年3月に第一次案が、さらに94年12月にはドラフト0.9版が配布された。さらにそれに対するコメントを反映して第1版が96年1月に発行された。SC27 WG3では、この第1版の ,���� �~� がWD&;��<���� "��-�'、,���� がCD& �$$������"��-�'となり、,����~�をCDにするための、条件等を検討している。現在、CCEBはオランダも加えCCIB( �$$��� �������� �$���$��������

>����)と名称変更し、第1版へのコメントを反映中であり、97年12月には第2版を発行する予定である。さらにそれに対するコメントを反映し、98年7月にDIS&"��-����������������(�������'としてISOに提案して、98年11月にIS&��������������(�������、国際標準'とする予定になっている。なお、海外における各種セキュリティ評価基準と本書との関連を付録Aに示す。

Page 8: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

1.3 基本要件・機能編の作成方針と性格

1.3.1 概要

本書は、商用のコンピュータシステムにおいて最小限具備すべき、セキュリティに関わる機能要件を記述したものである。コンピュータシステムに求められる機能要件は本来ユーザ、システムが実現する業務(アプリケーション)ごとに異なるものであるが、本書では商用アプリケーション領域(軍事・外交等の国家安全保証に係わるものを除く領域)に共通に必要とされる機能要件を規定する。

近年開発された、または開発中のセキュリティ評価基準では、コンピュータシステムに求められる機能要件がユーザ/システムごとに異なるという概念を採り入れている。例えば開発中のCCの機能要件集(パート2)では付録Bに示すように、一般的に想定されるセキュリティ目標に沿い、セキュリティ各機能分野ごとにさまざまなレベルの要件を記述した体系的な要件集として作成されている。ユーザが実際の情報システムにCCを適用するにあたっては、具体的なセキュリティ目標に従い、機能要件集から必要な分野の必要なレベルの要件だけを記述したPPを利用して、製品、システムのセキュリティ実現レベルを評価する。本書は、CCにおける商用分野向け共通機能要件のセットとしてのPPに相当する。

1.3.2 作成方針

本書の検討にあたっては、将来における評価結果の国際的相互認証を実現することを想定するとともに、日本の各種安全対策基準と明らかな矛盾を生じさせないことに注意を払った。

(1)第1版(1994年)作成の方針と経緯MSRおよび日本の各種安全対策基準を抽出の参考とし、MSRの機能要件の必須項目(5�6 ���$���!)と各種安全対策基準の項目との和集合の内で、他の項目の機能で代替できない項目をすべて網羅するようにした。

(2)第2版作成の方針将来において評価結果の国際的相互認証を可能とすることを重要視した。特にCCがいずれISO/IECの場において国際標準になることを想定し、CC第1版で商用コンピュータシステム向けのPPとして提示されたCS3で採用されている機

Page 9: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

能要件をたたき台に、基本要件として相応しいと判断できるCC第1版の機能要件を採用した。またインターネットをはじめとしたネットワーク環境に対応するための要件をカバーするため、ECMAのE-COFCの要件を参照した。

1.3.3 本書の想定する対応範囲

(1)想定するセキュリティ上の脅威本書は、コンピュータシステムに対する各種のセキュリティ上の脅威のうち、情報技術により対抗すべきものを想定し、対抗するために実現すべきセキュリティ機能に関する要件を規定したものである。したがって、物理的な破壊や侵入・妨害といった脅威に対する物理的な防御(建屋の耐火・耐震・耐水性能、マシン室への入退室管理、テープ・ディスク等の保管等)という観点でのセキュリティ機能要件は本書では取り扱わない。また災害によるマシン自体への脅威に対抗するためのセキュリティ機能要件も対象外である。この結果、本書が想定するセキュリティ上の脅威は、人為的な故意・過失や偶発的なシステムエラー等によるシステム管理資源、ユーザデータに対する脅威に限定される。

(2)要件規定の範囲本書は、本書が想定するセキュリティ上の脅威(上記(1)参照)に対抗するために、ベンダまたはシステム・インテグレータが提供する製品/システムで実現すべき機能要件を記述したものであり、システム構築・運用上のセキュリティ確保に必要な考察要因をすべて網羅したものではない。コンピュータシステムのセキュリティ確保のためには、本書で規定した要件の他に、●⦆コンピュータセキュリティ基本要件・保証編への準拠●⦆コンピュータシステムの物理的なセキュリティ(上記(1)参照)●セキュリティ方針に基づいたシステム運用マニュアルの整備と確実な実施●システム管理者を含むユーザの教育、指導●監査の実施が必要である。換言すれば、本書に記載する機能要件は、セキュリティ確保のための必要条件ではあるが、十分条件ではないことを留意する必要がある。

(3)各機能要件に共通な前提事項本機能要件で規定していない機能をシステム及びシステムの動作に関連するソフ

Page 10: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

トウェア、ハードウェア、ネットワークに追加する場合、それらの機能がシステムの他のセキュリティ機能に悪影響を与えてはならない。

1.3.4 想定する読者

本書は、以下の読者と利用方法を想定している。(1)製品開発ベンダ及びシステム・インテグレータ評価対象(TOE:3������ �-� �#�� �����,���参照)となる製品、システムを開発、構築する際の指針(����参照)として利用されることを期待している。(2)ユーザシステム管理者が固有のセキュリティ方針(����参照)を定めるための参考として利用されることを期待している。必要に応じ、本書のサブセット、または本書に更に固有の要件を付加した形でユーザシステムに適用することも考えられる。またベンダ等から提供・提案される製品の評価結果が公表されている場合、製品の選択を行う際の判断基準のひとつとして利用されることも期待できる。(3)評価者ベンダが開発した製品、システム・インテグレータが構築したシステムを評価対象とした評価実施(���参照)のために利用される。

Page 11: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

1.4 評価対象

1.4.1 セキュリティ方針

コンピュータシステムのセキュリティを確保するためには、最初にセキュリティ方針を明確にしなければならない。これは製品やシステムの開発者、ユーザ相互に共通な事項である。セキュリティ方針では、どのようなセキュリティ上の脅威に対処し、どのようなセキュリティレベルを維持するかを明確にしなければならない。特に製品開発にあたっては、セキュリティ方針に基づいた具体的なセキュリティ目標を設定しなければならない。本書では各機能要件がどのような脅威に対抗し得るものであるかを「解説」の中で記している。

1.4.2 評価対象

本書の適用にあたっては、評価対象となるソフトウェア、システムの範囲を明確に定義して評価を実施しなければならない。評価対象は、システムソフトウェア(オペレーティングシステム(OS:2��������

(�!��$)等)、ミドルウェア、アプリケーションソフトウェア、ハードウェア、及びこれらの組み合わせとして定義する。

評価対象の定義にあたっては、以下の項目を明確にしなければならない。(1)評価対象の動作環境評価対象が正常に動作するための前提環境を規定しなければならない。本項目には、前提とするハードウェア(必要な装置名、仕様、性能、ネットワーク種別等)、ソフトウェア(OSのバージョン等)、及びそれらの設定条件等を含む。(2)評価対象物本書で記述した機能要件を実現する製品、または製品群を規定しなければならない。本項目には、評価対象を特定するための情報(開発者、製品名称、バージョン等)を含む。また評価対象が複数の製品から成り立っている場合、評価対象間の関連を明記しなければならない。(3)評価対象がセキュリティを実現する範囲評価対象物が本書で記述した機能要件を満足するセキュリティを実現するシステム上の範囲を規定しなければならない。本項目には、本書準拠のセキュリティを実現できる、システム構成上の範囲、装置上の範囲(メモリ上の範囲、ディスク上の範囲等)を含む。

Page 12: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

1.5 想定するシステムモデルと用語の定義

1.5.1 ユーザ

コンピュータシステムのセキュリティ実現においては、誰がどのようにコンピュータシステムを利用する(した)のか制御、管理する必要がある。本書の2章では、コンピュータシステムを利用するすべての人を「ユーザ」と呼ぶ。ひとりひとりの人間は独立したユーザとして識別できなければならない。コンピュータシステムで処理されるあらゆる事象は、特定のユーザの指示に起因する。また、実行されるタスク、プロセス、スレッドは、個々のユーザと関連づけられる必要がある。本書の2章では、さらにユーザを以下の2つに分類して扱う。(1)システム管理者ユーザのうち、システム運用やセキュリティ管理に関して責任と権限を有するユーザを「システム管理者」と呼ぶ。なお、システム管理者が有する権限をどのように割り当てるかは、製品やシステムの実装、運用に係わる問題であり、本書の対象外である。(2)一般ユーザユーザのうち、システム管理者以外のユーザを「一般ユーザ」と呼ぶ。

1.5.2 資源

本書の2章においては、コンピュータシステムを構成するハードウェア、ソフトウェア、データ(システムデータ、ユーザデータ)の中で、評価対象が提供するセキュリティ機能が保護対象とするもの(メモリや磁気ディスク等)を資源と呼ぶ。

1.5.3 システム

本書の2章においては、評価対象をシステムと呼ぶ。本書の適用においては、1.4.2で述べたとおり、評価対象とするシステム構成上の範囲を明確にしなければならない。この範囲内においては、個々のユーザおよび資源は一意に識別できなければならない。また、ユーザシステムのセキュリティ管理者は、管理対象とするシステム構成上の範囲(1つの評価対象に閉じるとは限らない)を明確にした上でセキュリティ方針を確立しなければならない。異なる評価対象との(つまり、システム外部との)接続及びデータの交換は、双方

Page 13: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

をあわせて一元的に管理される必要はないが、システム内のセキュリティ方針を維持可能な範囲で、相手評価対象との間で等価な解釈が可能な手段で行わなければならない。

1.5.4 ネットワーク

本書の2章においては、物理的なコンピュータシステムを接続する物理的な通信路・通信網をネットワークと呼ぶ。ネットワークを介して接続されたコンピュータシステムは、ネットワークの存在に起因するセキュリティ上の脅威にさらされている可能性があり、本書にはこの脅威に対抗するための機能要件も2.7「ネットワーク上のデータ保護」として定義する。

1.5.5 分散システム環境

本書の2章においては、複数の物理的なコンピュータシステムから構成されているシステム形態を分散システム環境と呼ぶ。評価対象が分散システム環境である場合も、評価対象内の各コンピュータシステムに本書は適用されるが、評価対象内の内部コンポーネントにおけるデータ交換においては、2.7「ネットワーク上のデータ保護」の要件を適用しなければならない。

Page 14: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

1.6 本書を利用したセキュリティ評価の実施

1.6.1 セキュリティ評価の実施方法

セキュリティ評価は、その実施者により次の3タイプに分類できる。(1)第一者評価:ベンダが開発したソフトウェア、インテグレータが構築したシステムに対して、ベンダやインテグレータ自身が実施する評価。(2)第二者評価:購入する製品、構築されるシステムに対して発注者であるユーザ等が自ら実施する評価。(3)第三者評価:メーカやユーザ等の依頼を受けた中立機関が実施する評価。

1.6.2 想定するセキュリティ評価の実施方法

本書は、1.6.1で示したいずれの実施方法においても利用可能な評価基準として作成されている。

Page 15: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2. セキュリティ機能要件

2.1 識別と認証

システムは個々のユーザを識別できなければならない。また、ユーザのシステム利用に際して、ユーザが確かに本人であることを確認できなければならない。ユーザを識別する為に、個々のユーザにユーザ識別子を割り当てる。本人の確認は本人しか知り得ない情報(例えばパスワード)や本人に固有な身体的特徴(指紋、声紋等)を利用して行う。なお、この識別はシステムを一時的に利用するユーザ(いわゆる「ゲストユーザ」)の存在を否定するものではない。ゲストユーザとして識別されたユーザはその権限の範囲でシステムを利用することが可能である。

2.1.1 識別

&�' システムはユーザを一意に識別するために、個々のユーザに対してユーザ識別子を付与して管理しなければならない。ユーザの集合としてグループを構成することもできる。この場合はグループ識別子を付与して管理しなければならない。ユーザは複数のグループに所属することもでき、システムはこのグループの構成員を変更できる機能を提供しなければならない。この構成員を変更する機能はシステム管理者のみが利用可能でなければならない。

&' システムは識別や認証の為に、利用に先立って、ユーザを登録したり抹消したりできなければならない。このユーザ登録や抹消は、特別な権限を付与されたシステム管理者のみが実施できるようにしておかなければならない。グループ識別子を有するときは、グループとしての登録や抹消もできなければならない。

【解説】 ユーザ登録/抹消の手続きを一般のユーザがなんの制限も無しにできたのでは、管理の意味が無い。特別な権限を持ったシステム管理者であることを識別、認証した後に、はじめて、ユーザの登録や抹消の操作を可能としなければならない。

&�' ユーザがシステムを利用するに先立って、システムはユーザの識別を実施しなければならない。識別は個々のユーザ識別子とグループが構成されている場合には、グループ識別子によって実施されなければならない。この際には、まえもって、許可されたグループである事を確認しなければならない。

Page 16: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 システムの入り口でユーザを識別することは、セキュリティ上重要なことである。ユーザの識別が遅れれば、それだけ、許可されていないユーザによるシステム資源の利用を許すことになる。

&' システムは任意の時点で、任意の処理の要求元ユーザを識別できなければならない。ユーザはその処理を起動したユーザか、又は、その処理の実行責任者かである。

  利用者が直接起動したものでない処理(例えば、プリントサーバ、データベースサーバ等)については、システム管理者又は一意の識別子で識別できなければならない。

【解説】 通常、システム内では複数の処理が平行して実行される。どの処理もそれを起動した、または、その責任者であるユーザを識別できなければ、処理の妥当性を管理することはできない。また、一つの処理から別の処理を呼び出す場合は、呼び出された処理についてもその要求元の利用者が識別できなければならない。

&�' ユーザが一定期間システムを利用しなかった場合には、そのユーザ識別子を自動的に使用禁止にできなければならない。

【解説】 システムの利用開始時には、前回の利用時間や認証に失敗した情報(回数等)が表示される。もし、自分のユーザ識別子が不正に利用されていれば、この情報をチェックすることによって検出できる。しかし、長期間システムを利用しない場合、他利用者が不正にその利用者の識別子を利用しても、検出が困難である。このため、本処置が必要となる。

&�' システムはユーザ識別子のユーザ属性を初期値に設定できなければならない。

&�' システムはユーザ識別子を使用禁止にしたり、禁止状態を解除する機能がなければならない。本機能は特別の権限を付与された管理者のみが実施できるようにしておかなければならない。

【解説】 システム管理者がユーザ識別子の利用に関して異常を検出した場合、即座に対処するために、本機能が必要となる。

Page 17: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

&�' システムは登録されているユーザの状態(例えば、利用中とか利用禁止状態とか)を把握できる機能を提供しなければならない。

【解説】 システム管理者がユーザ識別子の利用に関して異常を検出した場合、現在のユーザ状態を把握し、即座に対処するために、本機能が必要となる。

&�' システムは同一のユーザ識別子を使用して複数のログインを同時に行うこと(セッションの数)を制限できなければならない。また、ユーザ識別子毎に同時にログインする数(セッション数)を制限できなければならない。本機能はシステム管理者のみが実施できるようにしておかなければならない。

【解説】 正規のユーザがシステムを利用している場合、他の利用者が同じユーザ識別子を利用して不正な利用を実施しても検出が困難である。同時に実行できるログインセッション数を制限できれば、不正を検出することが可能となる。デフォルト値は1とする。

&��' ユーザ識別子をユーザが動的に変更できる場合、特権を持っているユーザ識別子への変更は、特定のユーザ(複数でも可)のみに限定できなければならない。

【解説】 特権ユーザへの変更が自由にできたのでは、特権を設定した意味が無くなる。

2.1.2 認証

&�' システムはユーザを認証する機能を提供しなければならない。

【解説】 通常、利用者識別子は公開(誰でも知ることができる)されている。このため、容易に他人を偽ってシステムを利用することができる。これを防ぐために、本人しか知りえない情報や本人に固有な身体的特徴を利用した、本人の確認が必須である。

&' システムは認証情報が不当に利用されないように保護しなければならない。

&�' 認証情報は各ユーザ識別子ごとに設定できなければならない。

&' 認証情報に関するいかなる情報もユーザに提供してはならない。

Page 18: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 他人の認証情報の推測を可能とするようないかなる情報もユーザに提供してはならない。

&�' 認証情報の登録、更新時や認証時に、ユーザより入力される認証情報を端末画面等に表示してはならない。

【解説】 入力時に他人に見られることに対する保護である。

&�' 認証情報をプリントアウトしてはならない。

&�' 認証情報をシステム内に保持する場合には、一方向の暗号化によって暗号化処理された情報を格納しなければならない。

【解説】 ユーザより入力された認証情報はただちに暗号化処理して保護し、不当に利用されないようにしなければならない。認証情報が暗号化されていない場合、認証情報が格納されているファイルをダンプされた場合、認証情報を暴露することが可能である。たとえ、暗号化されていたとしても、暗号鍵をそのファイル上に持っていたのでは、認証情報が十分保護されていることにはならない。暗号化された情報から元の情報を入手できないような論理によって暗号化(一方向性の暗号化処理と呼ぶ)して、システム内に保持しなければならない。

&�' ユーザが自分の認証情報を変更できる機能がなければならない。なお、この変更時には、新しい認証情報の入力に先立って、それまでの認証情報を入力させて、本人の認証をおこなわなければならない。

&�' システム管理者は任意のユーザの認証情報を初期化できなければならない。

【解説】 不正なユーザが他人のパスワードを取得しているということが判明した場合、管理者は直ちにこの不正をやめさせなければならない。この為に、対象となるユーザの認証情報をただちに初期化し、それまでの認証情報を利用できなくすることが必要となる。

&��' 認証情報の有効期間を設定できなければならない。認証情報の有効期限を終了するときは警告を発すること。

Page 19: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 長期間同じ認証情報を利用していると、他人に暴露される危険性は高まる。自ら認証情報を変更しないユーザに対しては強制的に別の認証情報に変更させることが必要である。

&��' 一定の期間は同一ユーザが過去に使用した認証情報を再度使用することを禁止できなければならない。

【解説】 (��)によって、認証情報を変更しても、新規認証情報が以前のものと同じであれば意味がない。このために、一定期間は異なった認証情報を利用させることが必要である。

&�' システムはユーザにより入力された認証情報が間違っていても利用者の認証処理を途中で打ち切ることなく全て実施する。その際、間違った認証情報のどこに問題があるかについての情報をエラーとして表示してはならない。

【解説】 ユーザより入力された認証情報が誤っている場合、その誤りの内容をユーザに通知すれば、不正なユーザにとっては、類推が容易に可能となる。誤っているという事実だけを通知し、他のいかなる情報も与えてはならない。また、同じ認証情報を他のユーザが使用している場合でも、その事実を通知してはならない。

&��' ネットワークを介して認証情報を送受信する場合、盗聴防止のため認証情報を秘匿できなければならない。また、認証情報が不正な再送、挿入、削除、改竄を検知して、不正な利用を防止する手段を講じなければならない。

【解説】 利用者認証は認証情報が正当な認証機能によって利用者が提示したとおりに正しく受信されることが前提条件になっている。また認証情報が認証機能に受信される前に別のプログラムを経由する場合も認証情報が漏れる可能性がある。これを防ぐには、認証情報の暗号化に際して、乱数やタイムスタンプを付加して、通信回線上での見かけが、毎回異なるようにしておく必要がある。

&�' 認証情報としてパスワードを利用する場合、ユーザが指定できる認証情報の文字種、最小長を規定できなければならない。

Page 20: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 数字だけとか、一文字だけの認証情報は類推を容易なものにする。

Page 21: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2.2 アクセス制御

システムは、端末等の利用が物理的に保護(コンピュータが設置された建屋やコンピュータルームへの入退室制限等、1.3.3(1)参照)されていない限り、一般に誰でもが利用できる。また分散環境においては、ネットワークを介して遠隔地から利用することも可能である。このようなシステムを、正当なユーザに、許可された権限の範囲内で利用させ、不正利用を防止することがアクセス制御の目的である。アクセス制御では、システムはユーザを識別・認証した上で、システム自体の利用(システムアクセス制御)及びシステムが管理する個々の資源の利用(資源アクセス制御)について、ユーザが正当な権限を持っていることを確認しなければならない。システムで実際に各種の処理を実行するのはユーザ自身だけではなく、ユーザの代理として機能するプロセスの場合がある。これらプロセスの動作においても、ユーザ自身と同様に識別・認証が必要であり、その権限はユーザ自身の権限と同一である。本節では、ユーザ自身及びユーザの代理として機能するプロセスを合わせてユーザと呼ぶこととする。アクセス制御の機能要件は、システムアクセス制御機能と資源アクセス制御機能に大別される。

2.2.1 システムアクセス制御

システムを正当なユーザにだけ利用させるための機能を提供する。一般的には認証において、そのユーザの正当性が確認されれば、ユーザはシステムの利用を許可されるが、システムのセキュリティをより確実にするために、ユーザごとにいつ、どこから、どのようにして、またどの機能範囲でシステムを利用できるかを限定できなければならない。分散環境において複数のサーバが存在するような場合は、認証されてもすべでのサーバにアクセスできるとは限らない。さらに、それぞれのサーバごとに本節で規定する機能要件が適用されなければならない。また認証されたユーザがシステム内のすべての機能、資源を利用できるわけではない。ユーザが利用できる範囲(権限)は、「2.2.資源アクセス制御」で規定される機能要件に基づき、ユーザごとに規定される。以下に、システムアクセス制御に関する機能要件を記述する。

&�' すべてのユーザは、システム及びシステム内の各種資源の利用に先立って、

Page 22: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

ユーザ本人であることが認証されなければならない。� &�' システムは「認証情報なし」のユーザの定義を許可してはならない。また、途

中で認証情報を変更する場合、「認証情報なし」の状態を作ってはならない。(*)ユーザがネットワークを介して接続されたシステム(コンピュータ、端末)か

らアクセスを求めている場合も、同様の確認が必要である。

【解説】 システムアクセス制御の目的は、システムの不正利用を未然に防止することにある。システム利用に関するユーザの権限は、ユーザ識別子によって判断されるため、そのユーザ識別子を利用しているユーザが正当であることを確認することは、アクセス制御の根幹に関わる。したがって、いかなるユーザであっても、認証を受けずにシステムを利用することは認められない。ユーザ(ユーザ識別子)に対する認証を実行しないと、他のユーザになりすましてシステムにアクセスすることが可能となり、システムが管理する資源(例えば、メモリや磁気ディスク)に存在する情報の機密を保ち、またシステムが安定して動作することが困難となる。またネットワークで接続されたシステムは、不特定多数の人間がアクセスできる可能性がより高いことを留意すべきである。特に分散システム環境では、ユーザが最初にアクセスしたシステムからさらに別のシステムにアクセスする際には、新たにアクセスされたシステムは認証その他の方法によってユーザの正当性を再度確認する必要がある。

(�)上記にかかわらず、ユーザのアクセスが他のシステムへの取り次ぎだけを求めており、かつシステムアクセス制御の対象外となる場合には、この限りではない。

【解説】 一方で、他のシステムへアクセスするために、ユーザがあるシステムを中継機器としで利用して取り次きを依頼する場合は、以下の考え方を適用することもできる。そのシステム内で当該ユーザがいかなる処理も実行できないことを保証できれば、システムアクセス制御の対象外であるとしてそのシステムでの認証を実行せずに、ユーザアクセスを他のシステムに取り次ぐことができる。

&' システムにアクセスするユーザは、システム管理者によって事前に登録されていなければならない。

Page 23: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

(�)ネットワークを介して接続された機器からシステムにアクセスする場合、その機器はセキュリティ情報として事前に登録されていなければならない。

(*)このセキュリティ情報にユーザ、及びネットワークを介して接続された機器を登録する、または登録されているユーザまたは機器を無効にするという変更は、システム管理者だけが実行できる機能でなければならない。

(�)システムへのアクセスに関して登録されたすべてのユーザ及び機器のリストを出力できなければならない。またこの機能はシステム管理者だけが実行できる機能でなければならない。

【解説】 システムへの接続を要求してきたユーザに、接続を許可するかどうかを判断するためには、アクセス可能なユーザ(ユーザ識別子)を事前に登録しておく必要がある。事前にシステムを利用できるユーザを規定(登録)しておかないと、権限をもたないユーザがシステムにアクセスする可能性がある。システムのセキュリティ方針でシステムの利用条件を規定しておき、それに基づいてユーザ登録するべきである。システムの利用を要求するユーザがこの利用条件に合致するかどうかを確認するためにも、この機能の利用はシステムのセキュリティを管理するシステム管理者に限定する必要がある。

ネットワークを介した機器からのシステム利用を許可する場合、誰かがネットワーク上から他のユーザになりすましてシステムにアクセスすることを防止するために、必要に応じてネットワークを介して接続した相手システム(機器)を確認できるよう、事前にシステム管理者によって登録しておく必要がある。

&�' ユーザがシステムを利用している際に、システムのセキュリティ方針で規定した一定時間、ユーザがシステムを利用しなかった場合には、処理をロック(中断)できなければならない。この一定時間の設定は、システム管理者以外が実行できてはならない。また、処理を中断するのではなく、処理を終了させる機能も提供しなければならない。この処理終了機能はシステム管理者以外が実行できてはならない。さらに、ユーザは利用している処理をユーザ自身がロックできなければならない。またロックに関して、システムは次の機能を提供できなければならない。

(�)処理のロックを解除する前に、ユーザ認証を実施することを要求すること。(*)処理のロック中は、当該プロセス及び関連するプロセス・デバイスを他のユー

Page 24: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

ザが利用できないようにするか、処理のロックを解除すること以外のデータ入力やディスプレイ表示等を実行できないようにすること。

(�)ディスプレイに表示されていた内容が読めないように、画面をクリアするか、上書きして別の表示を行うこと。

【解説】 キーボード等の入出力機器を利用してシステムにアクセスしているユーザが、一定時間システムを利用しなかった場合、そのユーザが中座したか、もしくは何らかの要因によりアクセスできなくなったことが考えられる。このような間に他人が勝手にシステムを利用することを防止するために、システムはそのような状態に陥ったユーザのシステム利用を一時ロックできなければならない。またこのような状態に陥るのを未然に防ぐために、ユーザ自身が処理をロックできることも必要である。処理のロック解除には、ユーザの身元を確認するために再度ユーザの認証を実施すべきである。また処理のロック中においては、ユーザが利用していた処理を他人が実行することのないよう、ロック中のセッションに関するプロセスやデバイスを分離したり、作業の内容を見られることのないよう、ディスプレイ上の情報を隠蔽する必要がある。また、よりセキュリティを確実にするために、処理を中断するだけでなく、そのユーザのシステム利用を終了させることができる必要もある。

&' ユーザがシステムにアクセスする際に、システムのセキュリティ方針で規定した一定回数以上認証に失敗した場合には、ユーザとの接続を切断しなければならない。

【解説】 一定回数以上連続して認証に失敗するユーザは、パスワード等の認証情報を知らない、つまりシステムを利用可能であると登録されていないユーザである可能性がある。このようなユーザが、システムを不正に利用するために、推定したさまざまな認証情報を用いてシステムへの接続を繰り返し試行することは十分に考えられる。このような行為を防止するため、一定回数以上認証に失敗したユーザからの接続を切断し、不正な試みを断つ必要がある。

(�)この機能が実行されたとき、本事象が発生した旨の警告をシステム管理者に通知できなければならない。

Page 25: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【解説】 システムに不正にアクセスしようとしているユーザが存在する可能性があることをシステム管理者に速やかに通知し、必要であればシステム管理者が処置をとれるようにすべきである。不正にシステムを利用しようとしている可能性があることをシステム管理者が知らないでいることは、システムセキュリティの運用上問題がある。

(*)この機能が実行された後、システムのセキュリティ方針で規定した一定時間が経過した後でなければ、同一ユーザ識別子によるシステムへの接続処理を開始することはできない。

【解説】 認証に失敗したユーザが、すぐにまたシステムへのアクセスを試みる可能性がある。このようなユーザによるシステムへのアクセスは、一定時間経過した後にのみ許可するということで、このような行為を防止する必要がある。また連続して認証に失敗するようなユーザは、不正ユーザである可能性がより一層高まったといえるので、接続処理(例:ログイン手続き)再開までの時間を長くするようにする機能を提供することも考えられる。

(�)この機能が実行されたとき、そのユーザ識別子を無効にできなければならない。この機能を、全ユーザに対してデフォルトにしてはならない。

【解説】 より機密性の高いシステムでは、不正アクセスを厳しく防止するため、認証に失敗したユーザの識別子使用を停止させる機能も必要である。全ユーザに対してデフォルトにすると、悪意のユーザによって全識別子が無効にされてしまう。

&�' 特定のユーザに対して、システムを利用できる日時・時間帯等を制限できなければならない。この設定はシステム管理者のみが実行できること。

【解説】 ユーザのアクセスレベルや業務内容によってシステムを利用可能な時間帯(期間)を設けた方がよい場合がある。例えば、社内システムであれば、勤務時間帯に限ってサービスを提供するということが考えられる。本来そのユーザが利用しないはずの時間帯(期間)には、最初からサービスを提供しないことで、不正な利用者がシステムに接続しようと試み

Page 26: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

るのを防止することができる。つまり、システムの利用が可能な時間を制限することで、不正侵入の確率を減らすことができる。システムが提供する機能としては、・⦆一日(時間)のうちの利用可能または不可能な時間帯の指定・⦆一週間のうちの利用可能または不可能な曜日の指定・⦆利用可能または不可能な特定の日付(期間)の指定が考えられる。

&�' 特定のユーザに対して、システムを利用する際のアクセス経路を制限できなければならない。この設定はシステム管理者のみが実行できること。

(�)公衆電話回線からシステムにアクセスできるユーザを制限できなければならない。

(*)ネットワークからシステムにアクセスできるユーザを制限できなければならない。

【解説】 ネットワークをすべて物理的な管理下におくのは困難であり、ネットワーク上を伝送される識別・認証データ等を不正に奪取して、それをもとに、システムを不正利用される可能性がある。これを防止するためには、�つの対策が考えられる。①⦆利用できるシステム(端末)を制限し、ユーザがシステムを利用しようとした時、アクセスしてきたシステム(端末)を確認することである。実現手段としては、コールバック、ネットワークアドレスの確認等が考えられる。②⦆利用できるネットワークそのものを制限し、特に危険度の高い公衆電話網や無線の利用を制限することが考えられる。③⦆ネットワークを介してシステムを利用できるユーザを制限することも有効である。

&�' 特定のユーザに対して、システムを利用する際のアクセス手段を制限できなければならない。この設定はシステム管理者のみが実行できること。

【解説】 ユーザがシステムを利用する時、どのような手段でアクセスするかを制限する。例えば、端末からのアクセスか、������:-��プロトコルによるアクセスか等が考えられる。

     &�'� アクセス経路によって、ユーザの特権を制限できなければならない。

Page 27: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【解説】 (�)と同様の考え方に基づき、ネットワークを介した場合のシステムの利用は、利用できる機能、権限についても制限できることが必要となる。特に特権利用については、一般的にシステム管理者が特定の端末から利用することを前提にし、一般のユーザが不正にその権限を利用することがないようにする必要がある。

&�' システムの利用を許可されたユーザに対して、以下の情報を表示できなければならない。また、ユーザ自身以外がそれを消去してはならない。

(�)前回システムを利用した日時、アクセス経路、アクセス手段。(*)前回システムを利用した後、そのユーザ識別子でシステムへの接続に失敗した

日時または回数、アクセス経路とアクセス手段。

【解説】 前回システムを利用した後に、誰かがそのユーザの識別子を勝手に利用してシステムに不正にアクセスする可能性がある。自分のユーザ識別子を不正に利用されていないかどうかを、ユーザ自身が確認するためにはこの機能が必要である。この機能でそれを防止することはできないが、不正をユーザ自身で発見することができ、対策を取ることが可能になる。

&��' ユーザへの権限の付与、または剥奪、及び属性の変更に関する機能は、システム管理者以外が利用できてはならない。

【解説】 ユーザがシステムを利用する際の権限の付与/変更等は、システムのセキュリティ方針に基づき、定められたシステム管理者だけが行うべきである。これはセキュリティの運用を一元化するために必要であり、システム管理者以外がこの機能を利用できると、ユーザの権限を勝手に変更できることになり、システム全体のセキュリティを維持することが困難となる。

&��' セキュリティ制御に関する機能をグループ分けし、それぞれごとに利用できるユーザ(システム管理者)の設定を可能にしなければならない。

(�)この機能を使用する際は、ユーザがその権限を有していることを確認しなければならない。

【解説】 セキュリティ制御に関する機能は、一人にすべての権限を持たせるとそ

Page 28: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

の人間が不正を働いた場合にチェックできず、かつ何でも実行できるので、被害が広がる可能性がある。このため役割を複数人で分担する方法がよくとられる。この時、他の管理者がもつ権限の機能を利用できないよう、セキュリティ制御に関する機能を分割して設定できる必要がある。例えば、日常の運用でシステム管理者が不正を働くという可能性があるが、この場合の被害を最小限にし、かつ監査等によってチェック可能とするために、ユーザの権限の管理等を行っている管理者と監査を実施する管理者とを分離する等がある。

2.2.2 資源アクセス制御

資源の所有者または、システム管理者は、その資源への他のユーザからのアクセスを許可または禁止するために、システムで提供する機構を利用する。システムの資源アクセス制御は、個々の資源への正当なアクセス権限を有するユーザに対してのみアクセスを許可し、ユーザと資源との間を仲介しなければならない。以下に資源アクセス制御に関する機能要件を列記する。

&�' システムは、資源へのアクセスを制御しなければならない。

【解説】 許可されていないユーザが、システムが保護対象とする全ての資源(例えば、メモリや磁気ディスク)に存在する情報を利用(参照)したり、資源を変更・破壊(削除)するのを防御するためには資源へのアクセスを制御する必要がある。

&' システムは、識別と認証を終了していないユーザに対しては、資源へのアクセスを許可してはならない。また、この資源へのアクセス制御は、システムが認証済みのユーザ識別情報に基づいて実行されなければならない。

【解説】 許可されていないユーザが、資源にアクセスするのを防御するためには識別と認証を受けずに資源を利用することを認めてはならない。識別と認証を受けないユーザに資源のアクセスを許すと、他のユーザになりすまして資源にアクセスすることが可能となり機密性が失われてしまう。

&�' システムは、各資源毎に個々のユーザあるいはユーザの集合として構成される個々のグループからのアクセス権限を設定できなければならない。

Page 29: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【解説】 アクセス制御を行う資源単位は、システム全体という大きな範囲では識別と認証を終えたユーザはすべて同じ扱いで全ての資源にアクセス可能となり、個々のユーザ間では何の機密性も無くなってしまう。また、個々の資源毎に機密性・重要性が異なり、個々のユーザ単位にその権限も異なる。よって、各資源別に機密性を維持するためにはシステム内の資源を一意に識別できる必要があり、その各々についてユーザからのアクセス権限を設定できるようにする必要がある。またグループを構成できる場合には、個々のグループからのアクセス権限も設定できるようにする必要がある。

&' システムは、資源の利用性をできるだけ高め、かつ不当な利用方法から資源を保護するために、アクセス権限をユーザの資源の利用方法によって分割して設定できなければならない。すくなくとも、資源毎に「参照」「更新(書き込み)」「実行(利用)」という権限を個別に設定できなければならない。

【解説】 本来は「参照」等、限られたアクセス権限だけを与えるべきユーザに当該資源へのアクセス権限全てを付与することによって、そのユーザが本来許可されていないはずの資源に対する更新、実行等を行うことができるようになり機密性を維持できなくなる恐れがある。「参照」権には、磁気ディスクや磁気テープ等からのデータの読み出し等が該当する。「更新(書き込み)」権は、磁気ディスクや磁気テープ等への書き込み、および資源の構成変更等が該当する。「実行(利用)」権は、プログラム実行、処理機構の利用等が該当する。この他にディレクトリ作成または、カタログ中のエントリ変更のためのアクセス権限として、「作成」と「削除」権を持つ事も考えられる。アクセス権限の細分化は実現レベルの問題であると考える。

&�' システムは、資源にアクセスしようとしたユーザに対するアクセス権限と、そのユーザが属するグループに対するアクセス権限の両方がその資源に設定されている場合、ユーザに対するアクセス権限とグループに対するアクセス権限のいずれを優先するかを統一しなければならない。

【解説】 ユーザのアクセス権限よりもグループのアクセス権限の方が大きい場合、そのグループに属するユーザのアクセス権限が不当に拡大し、資源に対して不当にアクセスするのを防御する必要がある。

Page 30: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

&�' システムは、資源にアクセスしようとしたユーザに対するアクセス権限も、そのユーザが属するグループに対するアクセス権限もその資源に設定されていない場合、初期値としてのアクセス権限を使用すること。また、システムはこの初期値としてのアクセス権限を設定する機構を提供しなければならない。

【解説】 新規のユーザのように明示的なアクセス権限が設定されていないユーザが、許可されていない資源にアクセスするのを防御するために必要。例えば、明示的にアクセス権限が設定されているかどうかを判定可能な場合には、上記のようにシステム管理者が指定したデフォルトに従う方式でもよい。また、代替として明示的アクセス権限が指定されていないユーザを無くす方式として、システムへの新規ユーザ登録時にアクセス権限指定を省略した場合には、必ず暗黙のアクセス権限が設定されるようにしておくなどの方式も考えられる。

&�' システムは、ユーザの資源へのアクセス権限の確認とアクセスの許可を、少なくとも資源のアクセス開始時(または、アクセスを開始するために資源を確保する時)に、実施しなければならない。

【解説】 アクセス権限が確認され、許可を取得する以前に、ユーザが資源にアクセスするのを防御するために必要。例えばファイルの使用に際しては、ファイルのオープン処理要求時にチェックするのが一般的である。

&�' システムは資源の所有者(資源のアクセス権限を変更することができるユーザ)を設定・変更するための機構を提供しなければならない。この機構の利用は現在の所有者および、システム管理者だけに限定されなければならない。

【解説】 資源作成者の許可無しに、他のユーザが資源にアクセスするのを防御するために必要。また、該当資源内に記憶されている情報の機密性に変化があった場合など、必要に応じて他のユーザからのアクセス権限を制御できる必要が生じる。このような制御をできるのはその資源の所有者のみであり、情報を作成した所有者という概念が必須である。

&�' システムは、新しく作成された資源のアクセス権限情報の初期値を指定するための機構を提供しなければならない。

Page 31: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 作成した資源へのアクセス権限が明示的に設定される前に、資源作成者以外のユーザが、当該資源にアクセスするのを防御するのに必要。

&��' システムは、資源に対するアクセス権限の追加・削除等の内容を変更する機構を提供しなければならない。また、これらの行為は、その資源の所有者とシステム管理者または権利を付与されたユーザに限定して許可しなければならない。

【解説】 アクセス権限の変更を許可されていないユーザが、資源へのアクセス権限を不当に変更し、本来許可されていないユーザが資源にアクセスするのを防御するのに必要。また、該当資源内に記憶されている情報の機密性に変化があった場合など、必要に応じて他のユーザからのアクセス権限を制御できる必要が生じる。

&��' システムは、コマンドやユーティリティで資源の複製を作成する場合、複製元の資源に対するアクセス権限属性を複製された資源にも引き継がなければならない。

【解説】 システム管理者がバックアップを取るような場合に有効な機能である。単純に複製された資源へのアクセス権限が緩和され、本来、当該資源の利用を許可されていないユーザが当該資源にアクセスするのを防御するために必要。

&�' システムは、指定されたユーザあるいはグループが所有しているすべての資源と、指定されたユーザあるいはグループがアクセス可能なすべての資源のリストを出力するための機能を持たなければならない。また、その資源毎にアクセス権限の内容も出力できる必要がある。この機能は、システム管理者以外に使用させてはならない。

【解説】 資源に対するアクセス権限が不当に設定され、許可されていないユーザが資源にアクセスすることを察知するために必要。

&��' システムは、特定のユーザあるいはグループについて、すべての資源への特定のアクセス権限を剥奪することのできる機能を提供しなければならない。また、

Page 32: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

この機能をシステム管理者以外に使用させてはならない。

【解説】 許可されていないユーザが不当に資源をアクセスしていることを察知した場合などにおいてこの機能を用いて、その行為を停止させるために必要。このためには、指定されたユーザあるいはグループについては、すべての資源について特定のアクセス権限を拒否するように制御できる必要があり、また、この機構は標準のアクセス管理機構を無視しなければならない。

&�' システムが出荷時に提供される各資源は、その資源の意図された利用を可能にするための、必要最小限のアクセス権限が付けられなければならない。システムは、資源アクセス制御を実行するための制御情報テーブルおよびファイルを、無許可のアクセスから保護しなければならない。

【解説】 システム出荷時に提供されるOSで使用するシステムプログラム、システムファイルなどには、一般ユーザからのアクセスに対して必要最小限のアクセス権限を付けるようにしてそのアクセスを制限すべきである。許可されていないユーザが、アクセス権限を不正に変更したり、利用することで機密管理が崩れ、資源に不正にアクセスするのを防御するためである。資源アクセス制御を実行するための管理情報とは、アクセス制御リスト、グループリスト、システム日および時間などである。アクセスできるのはシステム管理者に限定される。

Page 33: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2.3 資源の再利用

資源の中には、あるユーザが使用を終えて一旦非割り当て状態になった後、他のユーザに再割り当てが可能なものがあるが、その資源には元のユーザのデータが残っているかもしれない。システムはこのような再利用可能な記憶型資源に関し、非割り当て状態の時、あるいは、他のユーザに再割り当て後、両方について、元のユーザ・データの開示を制限する機能を持たなくてはならない。次に記憶型資源の再利用に関する機能要件を列記する。

&�' システムは、権限を持たないユーザが、非割り当て状態の資源に含まれる、元のユーザのデータを入手できてはならない。

【解説】 想定する脅威の一例を示す。あるユーザがディスク上のファイルを消去すると、そのファイルが存在したディスク領域は非割り当て状態となるが、領域上には元のデータが残っているかもしれない。この領域を別のユーザが直接アクセスして、元のデータを入手してしまう可能性がある。

&' システムは、資源を割り当てたユーザに、その資源が以前割り当てられていたときに格納された情報へ、アクセスさせてはならない。

【解説】 想定する脅威の一例を示す。あるユーザにディスクファイルを割り付け、それを使用する前に、そのファイルの内容を読めば、以前そのディスク領域を使用していたユーザのデータが入手できる可能性がある。

Page 34: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

2.4 監査

監査の目的は、システム上でのセキュリティに関係する行動(セキュリティ関連事象)を記録し、分析することによって、ユーザ一人一人の責任追跡性を確保することにある。従ってシステムは、あらゆるセキュリティ関連事象を最終的には個々のユーザに結びつけ、監査証跡として記録できなければならない。監査証跡自体のセキュリティ保護が必要であるとともに、記録された証跡を適時適切にわかりやすいかたちで利用できる機能も欠くことができない。監査機能要件は、証跡の記録機能と分析・報告機能に大別される。

2.4.1 記録機能

監査証跡は、それを分析し総合することによって個々のユーザのセキュリティ関連行動の全体像を把握する目的で収集する。従って分散システム環境下であっても、個々のユーザに関して収集するデータは、当該ユーザの直接的な行動はもとより、間接的に当該ユーザに起因するあらゆる行動・事象を、システム全体にわたって当該ユーザに関連づけて追跡できる情報を含むものでなければならない。また、監査機能自体も、個々のシステム・ニーズや環境に使いやすく適応できるように、柔軟性を備えていることが要求される。従って、監査証跡記録の機能要件は、①⦆どのような観点からどのような内容の証跡を記録するか②⦆証跡記録の機能自体はどのような特性を備えていることが必要かを規定する必要がある。

&�' システムは、監査証跡を生成し記録することができなければならない。証跡内容としては、それを事後に分析利用することによって、情報・資源の減失やシステムの不正使用に対して、適切な管理対策をとれるだけの十分な情報を包含していることが必要である。

【解説】 監査機能の最終目的は、システムの不正使用や、情報・資源の破損・減失を防ぐことにある。そのためには、適切な管理対応策をとるのに十分なデータと情報が必要になる。そして基本的には監査証跡がこのデータの基礎となるので、システムには確実かつ有効に監査証跡を記録できる機能が要求される。監査証跡が、適切な管理対応策がとれるだけの十分なデータと情報を包含していてはじめて意味をなす。

Page 35: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

&' システムの基本機能として行う証跡記録のほかに、アプリケーションプログラムから証跡記録をとることができる、ないしはアプリケーションが指定する代替証跡ファイルに記録することができるように、%,�(%����������� ,�����$�����-���)が用意されている必要がある。これらのアプリケーションプログラムの利用にあたっては、特権を必要とすること。

【解説】 監査機能は、個々のアプリケーション機能から独立していることが望ましいので、基本的にはシステム共通の基本機能として装備される必要がある。しかし、個別のニーズ・環境に対応した、きめ細かい監査機能を実現できるように、アプリケーションプログラムて使える安全な %,� が求められる。

&�' セキュリティ関連事象に関するユーザの責任はシステム全体にわたり、行動の発生から終了までの全過程で追跡可能でなければならない。分散システム環境においても、ユーザ行動の直接的・間接的影響が及ぶすべてのセキュリティ関連事象が、当該ユーザと関連づけて監査できることが求められる。 従って、当初の処理要求元ユーザに関する情報が以降の全過程で保持・伝達されて、監査証跡と当該処理要求元ユーザの関連づけができなければならない。

【解説】 システムを使用する企業・組織のセキュリティ方針の下で、個々のユーザのセキュリティ関連行動の全体像を総合的に把握してその責任を追跡することが監査機能の目標である。従って個々ユーザに関わるセキュリティ関連事象は、それが当該ユーザの直接的行動によるものはもとより、クライアント・サーバの関係で間接的に起因する事象も含めて、また当該ユーザが直接に関わるシステムにおいてだけではなく、ネットワークを介して間接的に使用されるシステムにおいても、責任追跡が可能でなければならない。この要件は、一つの情報システムが複数のコンピュータシステムの結合でできている、いわゆる分散環境においても、構成するシステムの 2(

や通信プロトコルなどの環境・基盤に左右されることなく、処理要求元ユーザとその行動責任を関連づけることを求める意味で、(介在する環境条件にかかわりない)エンド・エンド要件と呼ばれる。分散環境でこのエンド・エンド要件の追跡性が確保されていないと、監査証跡がシステム間で一貫性を欠く可能性があり、この欠陥を利用する

Page 36: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

セキュリティ侵害に対応できなくなる。

&' システムの通常稼働中でも、証跡記録対象となる事象のタイプを即座に変更できるような機能を備えていなければならない。 この動的変更管理機能としては、初期設定した監査対象事象の一部分を対象からはずす、あるいはその他の事象を監査対象に入れたりはずしたりできることが要求される。 この機能の実行は、特権を必要とすること。

【解説】 セキュリティ侵害は時に予想外の事態で発生しうる。その事実把握のためには当初想定した記録対象以外の事象をトレースすることも必要になる。ことにハッカーを典型とするオンライン侵害などに対しては、即時の証跡記録採取が要求される。ただしこの機能により、記録対象事象の変更が恣意的に行われることがあってはかえって不正利用の原因となりうるので、実行は特権ユーザ(システム管理者)に限定すること。その場合、下記の①、②の付記が必要となる。①⦆上記項目に関わらず、特権を要する行動は、すべて監査対象としておかなければならない。②⦆上記項目に関わらず、監査対象事象の範囲を変更する行動自体は、必ず証跡記録の対象とすること。

&�' 最小限次に掲げる事象は監査証跡に記録する。この要件機能は、初期設定とすること。

【解説】 ①から⑮に掲げる事項は、一般的にどのシステムにも共通する基本監査対象項目。

①⦆監査の起動および終了②⦆失敗したユーザ認証③⦆不許可になった資源アクセス要求④⦆許可・不許可にかかわらず、すべての特権獲得の要求⑤⦆特権を必要とするすべての行動� 特権を伴う行動は権限範囲が広く、一般業務に関連した資源や機能だけではなく、セキュリティ上重要な機能や資源にもアクセスできる。例えば監査機能や監査証跡の変更も可能になる。従って、特権行為は無条件で監査対象にしてお

Page 37: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

かないと、特権を利用したセキュリティ侵害を惹き起こす可能性がある。特権行動に対するセキュリティ上でのより厳しい管理は、内部関与者、ことに管理者によるセキュリティ侵犯への対策の基本原則である。⑥⦆セキュリティ上重要な資源についてのすべてのアクセス要求� 例えば監査証跡ファイル⑦⦆ユーザのセキュリティ情報の変更要求� 例えばユーザ登録データやそのパスワードファイルなど⑧⦆ユーザ毎に設定されている特権の変更要求⑨⦆資源に設定されているアクセス権限の変更要求� アクセス制御リストが代表的な例⑩⦆セキュリティ構成の変更要求� 例えば 2( が使う制御リスト/テーブル類。あるいは ?4�@ において 3 >

(3� !���� �$� �����>�!�)を規定している:���:!�� ����:!�!�<��-�など� ⑦~⑩の各項目の情報はいずれもユーザのセキュリティ方針を直接表現しているので、その内容を変更する行動はセキュリティ上のきわめて重要な事象であり、原則として監査記録対象とされる。⑪⦆システムが提供する基本ソフトウェアの変更要求� 基本ソフトウェアは、ハードウェアとともにシステムの基盤を形成する。すべてのセキュリティ機能やアプリケーション機能が乗っている基盤自体の整合性・一貫性を確保することはシステムセキュリティの前提条件である。⑫⦆ログイン数の制限による新しいログインの失敗⑬⦆セションロックの開始/ロック解除要求/ロック解除⑭⦆ログインの終了⑮⦆他のシステムとのセキュリティに関する管理データの交換及び解釈 他システムを含む分散・混成システム全体の監査のためには、他システムとセキュリティに関する管理データ(アクセス制御リスト等)を交換する場合には記録を残しておく必要がある。また、システム間で交換する管理データの解釈が個々のシステムで異なると全体としてのセキュリティレベルを保持できないため、関連する全システムに一貫した解釈が必要である。

&�' 最小限次に掲げる事象については監査証跡への記録対象に含めたり、はずしたりできる機能を備えていること。なお、この機能の実行は特権を必要とする。

【解説】 一般にどのシステムにも共通する監査対象のほかに、個別(企業・事業所)システムのセキュリティ方針やユーザ(システム管理者)の判断で、以下①~⑧のようなセキュリティ関連事象やその他の事象を管理対象に

Page 38: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

指定できることは、監査機能の柔軟性を確保する観点から必要である。

①⦆成功したユーザ認証� 特定ユーザに注目して選択的に監査する必要が生ずることがある。その場合、当該ユーザの行動の全体像と個別行動を把握分析することになるが、そのためにはユーザ認証から始まる一連の行動を、許可・不許可、成功・不成功にかかわりなく、すべて証跡に記録して分析できる機能が必要になる。②⦆資源の作成・削除③⦆ディスクファイルへのアクセス④⦆テープファイルへのアクセス⑤⦆プログラムの実行⑥⦆オンラインコマンドの実行⑦⦆ユーザ(システム管理者)が定義した事象� 監査機能自体が、個々のシステム・ニーズや環境に柔軟に対応できることが求められる。また、企業・組織全体の監査ニーズに加えて、部門管理者の個別判断によって監査対象を管理できる弾力性も必要である。⑧⦆特定のユーザ識別子に関わる行動 特定のユーザ識別子についてセキュリティ侵害の恐れが検知された際には、当該ユーザ識別子にかかわる行動を選択的に証跡記録できるようにする機能が求められる。ハッカーによるオンライン侵害や、内部のユーザを装った(ユーザ識別子を使った)外部者によるシステム侵害等の場合に、このような機能が必要になる。

&�' すべての証跡記録は、最小限次の情報を含んでいること。①⦆事象の日付・時刻②⦆ユーザ識別子とアクセス経路とアクセス手段

� アクセス経路: ネットワーク� アクセス手段: 使用したプロトコル③⦆事象のタイプ④⦆アクセスした資源名⑤⦆可否結果(許可/不許可) 注)アクセス経路とはダイアルアップやLAN(A�����%����4��B��<)経由を指

す。アクセス手段とは使用したプロトコル� &������等'�を指す。

&�' ユーザ認証の過程で、ユーザ認証情報は、監査証跡に含めてはならない。

Page 39: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 ユーザ認証はあらゆるセキュリティ機能の前提であり、なかでもパスワードは(他の本人確認方式が実用化されるまでは)本人認証の最終的な根拠情報である。そのために、何よりもパスワードの安全保護が必要である。①⦆暗号化されていない平文パスワードをいっさい記録・保管しない。②⦆平文パスワードがシステム内で存在する機会を最小にすることは、パスワード保護の基本原則である。

この意味でパスワードを保護するために、監査証跡といえどもユーザが入力した平文データそのものを記録・保管してはならない。

&�' 特定の端末やネットワーク接続の状況をリアルタイムで監視できるツールを備えていること。このツールの使用には特権が必要とされていること。また、どこを監視しているかをリアルタイムで表示できること。

&��' 監査証跡に権限のないアクセスがなされないように、保護できなければならない。

【解説】 監査証跡それ自体に対して、不正なアクセスをされないようなセキュリティ保護を行わなければならない。アクセスできるのはシステム管理者に限定される。

&��' 監査証跡ファイルを生成、消去、空にする等の維持・管理機能は、特権を必要とする。

【解説】 無許可の監査証跡の変更によって監査を逃れるようなことがあってはならない。

&�' 監査機能自体に権限のないアクセスがなされないように、保護できなければならない。

【解説】 監査機能自体の整合性、一貫性の確保。アクセスできるのはシステム管理者に限定される。

&��' システムが再起動されても、監査制御に関するデータ(例えば監査事象の設定値)の一貫性を保持できなければならない。

Page 40: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

【解説】 システムの再起動によって監査制御データが変更ないしはリセットされることがあると、意図的にシステムを停止再起動させて、監査を逃れる不正が考えられる。

&�' システムは、監査証跡ファイルのサイズを監視し、あるしきい値を超えたときにシステム管理者に通知できなければならない。またそのしきい値をシステム管理者が設定できるための機能を提供しなければならない。

【解説】 システムの記憶領域不足により監査証跡の記録が停止することを未然に防ぐための機能である。

&��' 監査証跡の記録ができない事態が生じたときには①⦆アラーム(警告)をあげる(初期設定機能)②⦆システムを停止する③⦆監査記録の発生を無視または抑制するなどの対応措置ができなければならない。

【解説】 監査機能自体の障害への対応策を備えることが必要である。最小対応策要件として、アラームやシステム停止機能が求められる。

&��' システムは、生成した監査記録を永久的な監査証跡に格納しなければならない。

【解説】 停電で消えてしまうような監査証跡の格納場所では本来の機能が発揮できない。

&��' システムは、システムの監査証跡格納場所の枯渇、または故障・攻撃等による監査証跡の消失の数量を制限できねばならない。

【解説】 監査証跡は絶対に消失しない事が望ましいが、やむを得ない場合でも消失する数量を最小限度にすべきである。

2.4.2 分析・報告機能

記録された監査証跡は、セキュリティ侵害対策のために利用することではじめて

Page 41: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

意味がある。そのために監査機能の要件として、監査証跡にもとづいてセキュリティ侵犯(ならびにその可能性)を即座に知らせるアラーム(警告)機能と、監査証跡を目的別に分析し、わかりやすく報告にまとめる分析、報告機能とが求められる。

&�' 記録される監査証跡にもとづいて、必要な場合にアラーム(警告)をあげる機能を備えていること。そのためにシステムは、アラームのあげ方(例えば、どこにアラームを出すか、誰にアラームするか)を指定できる機能を持っていること。

【解説】 監査報告・利用形態の一つとして、事象発生とともにただちにアラームをあげる機能が必要とされる。ネットワーク経由のハッカー侵害を受けたような場合は、即時対応こそがもっとも適切な管理措置となる。また、セキュリティ侵害の恐れが検知された場合、事後監査を待つ間に侵害を許してしまうのではなく、アラームによって即時対応を行い侵害を未然に防ぐことも監査の目的である。

&' 監査証跡を、監査目的に応じて事後的に分析し、報告にまとめるためのツールを備えていること。このツールを例外報告やサマリー報告のほかに、特定のデータやユーザ、通信機器に関しても詳細な報告が作れること。このツールはシステム管理者のみが使用できること。

【解説】 監査証跡は、これを分析し、わかりやすい報告にまとめることで役に立つ。従って分析・報告ツールは大切な機能要件である。このツールはシステム管理者のみが使用できる。

&�' 個別ユーザ識別子にもとづき、任意・特定のユーザ(特権ユーザを含む)の行動を分析できるツールを備えていること。

&' システム上のいかなる資源の変更に関する事象についても、報告可能であること。

【解説】 &�'&'両項目に関して監査証跡の分析・報告の基本切り口はユーザと資源である。この切り口をニーズによって任意に設定して監査実態を把握できることが求められる。なかでも、資源の変更に関わる行動・事象はセキュリティ確保に重要な影響を持つ可能性が大きいので、その報告出力ができることは必須

Page 42: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

条件である。

&�' 上記のツール類は、システムの通常稼働時に同時平行的に使用可能であること。

【解説】 監査機能の弾力的運用の観点から、分析・報告ツールはシステム稼働中でもいつでも使用できる必要がある。

Page 43: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2.5 完全性

完全性とは、システム内で行われる各種の変更操作が、定められた手段、定められた手順通りに実行されている状態をいう。例えば、ユーザがディスク上にデータを書き込む場合、ディスクの任意の位置に書きこむことは許されず、OSが定めたファイル・システムの規則にしたがって、空き領域の割り当てをあらかじめ行う必要がある。これらは、システム内のデータの完全性を維持するための機能であり、通常は、ユーザによるデータの変更は、システム提供の(セキュリティ機能を有した)ソフトウェアを介してのみ許されるというメカニズムで実現されている。ただし、このソフトウェアが持つべき機能は 2(ごとに多種多様なものが考えられるので、本書では機能要件としては取り扱わず、データの完全性の検査に関するもののみとしている。一方、このセキュリティ機能はデータだけではなく、システム提供のソフトウェア自身にも適用されるべきであり、これをシステムの完全性と呼ぶ。例えば、システム提供のソフトウェアの変更は、定められた改版手続きでのみ実施されなければならない。

2.5.1 システムの完全性

&�' システムは、システムまたはユーザのプログラムとデータを、その他のユーザのプログラムとデータから分離して保護する機能を提供しなければならない。

【解説】 マルチ・ユーザ 2(の多くは、ユーザ(プロセス)ごとに異なるアドレス空間を使用して、プログラムやデータを分離し、故意あるいは偶発的なエラーにより、システムのセキュリティ機能が変更されることを防いでいる。

&' システムは、システムコンソールがある場合、その使用に関する管理と監査を行う機能を提供しなければならない。

【解説】 システムコンソールの操作は、システムのセキュリティ機能を含めた各種機能に重大な影響を与える。従来は、システムコンソールは入室管理などの物理的な対策で十分であったが、最近のマルチ・コンソール、リモート・コンソール機能の出現により、一般の端末装置と同様のセキュリティ機能(例えば、ユーザの識別、認証)が求められるようになって

Page 44: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

きた。

&�' システムは、システムが提供するソフトウェアの実行、変更、削除を禁止、制限、または検出する機能を提供しなければならない。

【解説】 システムが提供するソフトウェアの中には、例えばシステムのメインテナンスや回復のためのユーティリティなどがあるため、ソフトウェアごとに、実行できるユーザを制限できることが望ましい。また、システムの提供するすべてのソフトウェアの変更(改版を含む)や削除は、権限を持つユーザ(例えばシステム管理者)に限るべきである。

&' システムが正常に動作することを管理者が確認できなければならない。

【解説】 この確認機能は、電源投入時、オフラインで動作すればよい。

&�' システムは、現在設定されているすべてのセキュリティ関連パラメータ値を出力する機能を提供しなければならない。また、当該データへのアクセスは制限できなければならない。

【解説】 システム自身は十分なセキュリティ機能を有しているにも関わらず、故意または過失による不適切なパラメータ設定のため、それら機能が適切に動作していない状態を検出するのが目的である。

&�' 管理者の操作ミスによりセキュリティ機能が誤動作しないように有効なパラメタ値をチェックできなければならない。

&�' システムのセキュリティ機能を妨害や誤操作から守るために、セキュリティ機能は他のアプリケーションと分離した領域に置かなければならない。

&�' システムはシステムの設置や構成や管理等のセキュリティ関連の管理機能を使用する特権を持ったユーザ達を他の一般ユーザから区別できること。

2.5.2 データの完全性

&�' システムは、データの完全性を確認(データの改ざん・破壊を検出)するための手段をユーザが利用できるようにしなければならない。

Page 45: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【解説】 このような手段として、例えば暗号技術の利用、チェックサムなどが考えられる。また、対象となるのは資源上に保存されたデータだけでなく、通信回線を介して送受するデータも含まれる。

&' システムは、指定された資源に関して、最後に行われた変更の日時及び変更したユーザの識別情報を出力する機能を提供しなければならない。

【解説】 これらの情報は、データの完全性に支障があった場合の原因追及手段として、最低限必要なものである。

Page 46: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2.6 サービスの信頼性

&�' システムの動作に関する障害の発生を検出しなければならない。検出した障害発生の事実は記録する必要がある。また回復可能な場合には障害を回復しなければならない。

&' 障害その他の原因によりシステムの運用継続ができなくなった場合でも、運転中と同程度のセキュリティを保ちながら回復を行うことが出来なければならない。

【解説】 システムまたはそこに蓄積された情報が、システムの回復中に通常の運転中以上の危険にさらされてはならない。

&�' ファイルのバックアップと復旧との手段が備えられていなければならない。このバックアップをとる作業の実行と作成されたバックアップ・ファイルへのアクセスは、特権を有するシステム管理者のみであること。

【解説】 ファイルの復旧に際しては、アプリケーションプログラムとの同期を取るためのチェックポイント機能(関連するファイルの整合をとって復旧する機能)の利用が必要になることがある。

&' 一般ユーザの行為によって他のユーザがシステムを利用できなくなることがあってはならない。

【解説】 一般ユーザが自分以外のユーザのファイルに対するアクセス権限を変更してアクセス不能にすることなどが出来てはならないのは言うまでもないが、それ以外にシステムの共用資源(メモリ領域、ファイル領域、 ,?( �������,����!!����?���)能力、回線容量など)を一般ユーザが大量に占有し、他のユーザに使えなくすることなどは、たとえそれが故意によるものでなくとも、防止できなければならない。

&�' システムの重要な共用資源について、ユーザが占用できる限度量をユーザ毎およびグループ毎に設定できる必要がある。

【解説】 ()の解説に述べたようなシステム共用資源の独占現象を防ぐために有効な機能要件である。

Page 47: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

2.7 ネットワーク上のデータ保護

&�' 保護が完全でないネットワークを利用する場合、暗号機能を使用して、盗聴防止のためデータを秘匿すること。

【解説】 暗号機能については、最低限、その時点での技術動向等を考慮し、安全と思われるアルゴリズム・鍵長等を、データの重要度・暗号化速度・コスト等に応じて選択すること。暗号鍵の生成方法、配布と確認、運用時の保管、有効期限、バックアップに関して、安全性を考慮すること。

&' 保護が完全でないネットワークを介してデータを送受信する場合、データの不正な再送、挿入、削除、改竄を検知して、不正なデータの使用を防止する手段を講じなければならない。

&�' ネットワークを介してデータを送受信するときは、互いに相手が認識されていること。

【解説】 ネットワークを介してサーバ間やサーバ・クライアント間でデータを送受信するときは、ネットワークの構成が決まっているので直接通信する相手も既知のはずである。特にダイヤルアップによるアクセスの場合等は、通信相手を確認することが重要である。未知の相手とデータを送受信することは危険である。

Page 48: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【付録A】 国際的なハーモナイズ状況

基本要件・機能編⦆1.0(1994)

米国 カナダイギリス ドイツ フランス

EU

TCSEC(1985) CTCPEC

(1991)

MSR(1993)

ITSEC(1991)

Green⦆Book Blue/WhiteBook

Blue/White/Red⦆book

ISO/IEC⦆JTC1⦆SC27⦆WG3

日本

CC⦆0.9(1994)

FC(1992)

CC⦆1.0(1996)

CC⦆2.0(1997)

WD/CD(1996)

CD(1997)

基本要件・機能編2.0(1997)

DIS(1998?)

IS(1998?)

CC⦆3.0?(1998?)

CC⦆4.O?(1998?)

安全対策基準他

矢印の意味

複数の基準の統合

同等の内容

対応する要件の配慮

標準化

CCEB(CCIB)

Page 49: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【付録B】CCの構成1.CCの構成CCは、1章でも述べているように、米国、カナダ、EU(� ������� ?����,ECから名称変更)によって開発中のコンピュータセキュリティ評価基準である。1996年1月に発行されたCC第1版は、次に示す構成から成り立っている。PART1:導入及び一般モデル&������ ������������������$����'PART2:セキュリティ機能要件&(�� �����- �����������6 ���$���!'PART3:セキュリティ保証要件&(�� ������!! ��������6 ���$���!'PART4:プロテクションプロファイル(,����-�����,����������,��-���!'

2.CCにおけるセキュリティ評価基準のモデルPART1で示されたモデルを図示すると下記の図のようになる。網カケを行った部分がCCで作成している箇所である。

分類(family)

レベル1

レベル2

機能要件(PART2)

分類(family)

レベル1

レベル2

分類(family)

レベル1

レベル2

分類(family)

レベル1

レベル2

保証要件(PART3)

分類(family)

レベル1

レベル2

分類(family)

レベル1

レベル2

一般的なセキュリティ目標(Security⦆Target)

プロテクションプロファイル(PART4)

個々のユーザ/システムごとのセキュリティ目標

参照 参照

一般的要件を体系的に整理

各国標準プロファイル

特定用途向けプロファイル

ユーザ定義プロファイル

要件3要件2要件1

機能要件プロファイル

要件3要件2要件1

保証要件プロファイル

プロテクションプロファイル2

要件3要件2要件1

機能要件プロファイル

要件3要件2要件1

保証要件プロファイル

プロテクションプロファイル1

参照

Page 50: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

【付録C】用語集本書の2章(機能要件及びその解説等)で使用している用語等について解説する。

アクセス[����!!](1)⦆ユーザによるシステムや資源の利用(の総称)。(2)⦆ユーザによるシステムの利用。システムアクセス。(3)⦆ユーザによる資源の利用。ディスク上のファイルの読み出し、更新等。資

源アクセス。

アクセス経路[����!!�����]システムにアクセスする時に使用する通信経路を意味する。LANや電話回線によるダイヤルアップ等を指す。

アクセス手段[����!!�$�����]システムにアクセスする時に使用するプロトコルを意味する。������等を指す。

アクセス制御[����!!��������]正当なユーザにのみシステムの利用を許可し、また、システムの利用を許可されたユーザに許可された権限の範囲内でのみ資源を利用させるように制御し、不正を防ぐこと。「システムアクセス制御」及び「資源アクセス制御」参照。

アクセス制御リスト[����!!�����������!�]資源に対するアクセスを許可されたユーザとそのアクセス権のリスト。

暗号[������������]データの機密性を保つために、データを意味がわからないように変換するための原理・方式。データの完全性の確認(データの改ざん・破壊の検出)等にも応用される。

暗号アルゴリズム[����������������������$,������]暗号化の手順を暗号化アルゴリズム(�������������������$)、復号の手順を復号(化)アルゴリズム(�������������������$)といい、暗号化アルゴリズムと復号アルゴリズムをまとめて暗号アルゴリズムという。

暗号化[����������]

Page 51: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

データ(平文)を意味がわからないように変換すること。その逆変換を復号(化)という。

暗号鍵[��������������<��]暗号化または復号(化)のアルゴリズムに入力される変換のためのパラメータの総称。例外的な場合を除いて、秘密に保持されるべきもの。単に鍵(<��)ともいう。

一貫性[���!�!�����]分散システム環境等において、セキュリティに関する管理データ(アクセス制御リスト等)が矛盾のない一貫した解釈であること。システム内またはシステム間において、セキュリティ方針に従ったセキュリティレベルが保持されるためには、このような一貫性が必要である。

一般ユーザ[�������� !��]システム管理者以外のユーザ。システム運用やセキュリティ管理に関して特別な権限を持たない。

可用性[�#����*�����]ユーザに許可された範囲内で、システム及び資源の利用が常時可能な特性。許可されたユーザがサービスの拒否に会わないこと。

監査[� ���]不正なシステム利用や資源アクセス等のセキュリティ上の異常を検出し、システムのセキュリティ管理を確立されたセキュリティ方針通りの妥当なものにするための、システムやアプリケーションプログラムによる自らのセキュリティ関連事象に関する記録とシステム管理者等によるその記録の分析。

監査者[� �����]監査を実施する権限を持つ人。

監査証跡[� ���������]監査を的確に行うためのシステムやアプリケーションプログラムが自らのセキュリティ関連事象に関して記録するデータ。

完全性[���������]

Page 52: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

「データの完全性」、「システムの完全性」を参照。

機能要件[- �����������6 ���$���]情報システム、または、情報システムを構成する個々の製品が具備すべきセキュリティ機能を定めた要件。

機密性[���-�����������]未認可のユーザまたはプロセスにデータの開示や利用を許可せず、データの秘匿が保たれる特性。不正なデータの流失が防止されること。

脅威[������](1)⦆システムにセキュリティ上の被害を与える可能性のある行為・事象。(2)⦆システムにセキュリティ上の被害を与える可能性のある、主として人為的

な故意・過失による行為・事象。

許可[� �����9�����]権利の許諾がなされること。資源へのアクセス権限を持つユーザであっても、資源にアクセスをする際に事前にアクセス許可を得る必要がある。

グループ[��� �]システムにより識別される、アクセス権限等を共通化するための指定されたユーザの集合。

グループ識別子[��� ���":��� ��������-���]システム内で、各々のグループを一意に識別するための識別情報。

コンピュータシステム[��$� ����!�!��$]一つのオペレーティングシステムが動作するハードウェア、ソフトウェア等からなる構築物。

サービスの拒否[��������-�!��#���]システムや資源の利用が障害・妨害等により停止されること。または、効率的な利用ができないこと。

識別[������-�������]

Page 53: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

システム内部でユーザ、資源を一意かつ監査可能な形で区別すること。

識別子[�":������-���]システム内でユーザ、グループ、資源を一意に特定するための符号。

識別情報[������-����������-��$�����]システム内でユーザ、グループ、資源を一意に特定するための情報。識別子等。

資源[��!� ���]コンピュータシステムを構成するハードウェア、ソフトウェア、データ(システムデータ、ユーザデータ)のうち、評価対象が提供するセキュリティ機能が保護対象とするもの(例.メモリ内のデータ、磁気ディスク上のファイル)。

資源アクセス制御[��!� ��������!!��������]ユーザによる資源の利用を、ユーザ毎に設定された資源へのアクセス権限により制御し、権限のないユーザには当該資源へのアクセスを許可しないこと。

資源の再利用[�*C������ !�]一度使用され、システムに返却された記憶型資源を、ユーザまたはプロセスに割り当て、再び利用可能な状態にすること。

資源の所有者[�B�����-���!� ���]資源(情報)の作成者であり、当該資源のアクセス権限を変更できるユーザ。または、当該資源のアクセス権限を変更できる権限を付与されたユーザ。

システム[!�!��$]評価対象。システム内で、個々のユーザ及び資源は一意に識別できなければならない。

システムアクセス制御[!�!��$�����!!��������]ユーザによるシステムの利用を、ユーザ毎に設定したシステムへのアクセス権限により制御し、権限のないユーザには当該システムへのアクセスを許可しないこと。

システム管理者[!�!��$���$���!������,���#������� !��,� �����9��� !��]システム運用やセキュリティ管理に関して責任と特別な権限を有するユー ザ。

Page 54: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

システム全体の責任者、システムオペレータ、セキュリティ管理者、システム監査者等。

システムの完全性[!�!��$����������]人為的な故意・過失による操作、偶発的なシステムエラー等が発生しても、システムのセキュリティ管理機能が正常に保たれる特性。

情報システム[�3�!�!��$:��-��$�����������������!�!��$]個々のコンピュータシステム、または、接続された複数のコンピュータシステムからなる特定の情報技術設備(の総称)。

情報セキュリティ[�3�!�� ����:��-��$�����������������!�� ����]「セキュリティ」参照。

省略値[��-� ��]システムの機能を利用する際、ユーザが特別な指定をしないときに設定される値。

セキュリティ[!�� ����](1)⦆情報システム内のデータ(システムデータ、ユーザデータ)、ソフトウェ

ア、ハードウェアを、それらに被害を与える可能性のある物理的・人為的等の行為・事象から保護すること。

(2)⦆主として人為的な故意・過失による行為、事象から情報システム内のデータ(システムデータ、ユーザデータ)、ソフトウェア、ハードウェアを保護すること。機密性、完全性、可用性がセキュリティ上考慮すべき主要な3要素である。

セキュリティ関連事象[!�� ���������#�����#���]システムのセキュリティに関連するシステム内におけるユーザやシステムのすべての行為・事象。具体的には、ユーザ認証の成功・失敗、システムアクセスの許可・不許可、資源アクセスの許可・不許可及び許可の内容、ユーザに付与するアクセス権限の変更、特権獲得の要求等。

セキュリティ機構[!�� �����$������!$]セキュリティ機能を実装したシステム内の仕組み。

セキュリティ方針[!�� �����������]

Page 55: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

システムにおいて、どのようなセキュリティ上の脅威に対処し、どのようなセキュリティレベルを維持するかを明確にした方針。具体的には、システム内のデータを保護するための一連の規則等。

追跡性[���� ���*�����]あるユーザの行為が、最初のシステムログインからシステムログアウトまで、一意に追跡できる特性。

データの完全性[��������������]人為的な故意・過失による行為、偶発的なシステムエラー等によって、データが改ざん・破壊されない特性。

認証[� ������������]個々のユーザ、マシン及びプロセス等の身元の正当性を証明すること。代表的な認証機構としては、パスワード及び本人に固有な身体的特徴を利用した認証方法がある。

認証情報[� ���������������-��$�����]個々のユーザ、マシン及びプロセス等の身元の正当性を保証するために使用される情報。

ネットワーク[���B��<]コンピュータシステムを接続する物理的な通信路・通信網。

パスワード[��!!B���]秘密の本人認証情報であり、通常は文字列から構成される。

評価[�#�� �����]情報システム、または、情報システムを構成する個々の製品を評価基準の定義に照らして、合致しているかを判定すること。セキュリティ評価。

評価基準[�#�� ��������������]情報システム、または、情報システムを構成する個々の製品のセキュリティ充足度を判定するための基準。機能要件及び保証要件からなる。

評価対象[32��D���������-��#�� �����]

Page 56: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

セキュリティ評価の対象とする情報システム、または、情報システムを構成する個々の製品。正確には、セキュリティ評価の対象とする、一つのコンピュータシステム、または、接続(ネットワーク接続、分散システム環境)された複数のコンピュータシステムにおけるソフトウェア(システムソフトウェア、ミドルソフトウェア、アプリケーションソフトウェア)、ハードウェアの範囲。

復号(化)[����������]意味がわからないように変換(暗号化)されたデータ(暗号文)を意味のわかる元のデータに戻すこと。

プロセス[�����!!]コンピュータ内部でプログラムを実行する単位。タスクとも呼ばれる。個々のユーザの代理として動作することがあり、このときにはシステムは識別・認証やアクセス権限に関し、ユーザと同様に扱う。

分散システム環境[��!���* ������$� �����!�!��$���#����$���]複数の物理的なコンピュータシステムから構成されているシステム形態。分散環境。分散システム。

平文[�������1�,�������1�]暗号化が施されていない通常の形態のデータ(テキスト、画像、音声等)。平文を暗号化したものを暗号文(��������1�)という。

保証要件[�!! ��������6 ���$���]機能要件の実現の確かさを保証するための要件。

ユーザ[ !��]システムを利用する人間。または、システム内で特定のユーザの代理として処理を実行する当該ユーザの識別情報を有するプロセス。

ユーザ識別子[ !����": !���������-���]システム内で個々のユーザを一意に識別するための符号。ユーザを識別するための識別情報。

ログアウト[���� �]サーバに接続したパソコンや端末からの、サービスの利用を終了すること。

Page 57: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

ログイン[�����]サーバに接続したパソコンや端末からの、サービスの利用をシステムから許可を受け開始すること。通信回線やLANを介した接続の場合と、サーバへ直接接続する場合とがある。

Page 58: コンピュータセキュリティ基本要件 機能編 - JEITA...コンピュータセキュリティ基本要件 機能編 【第2版】 平成9年8月 社団法人 日本電子工業振興協会

��

コンピュータセキュリティ基本要件・機能編【第 版】平成 �年8月

発行 社団法人 日本電子工業振興協会印刷 有限会社 矢部印刷