3 ->B

A English

$ ABA （ABA ガイドライン）
(N) 「ABA デジタル署名ガイドライン（American Bar Association (ABA) Digital Signature Guidelines）」 [ABA]。電子商取引におけるデジタル署名とデジタル証明書を使うことについての法的原則のフレームワーク。

$ Abstract Syntax Notation One (ASN.1)
(N) データオブジェクトを記述するための標準。[X680]

(C) ASN.1 を使用してプロトコル用のデータフォーマットを指定する OSI 標準。OSI は、層の機能性を定義する。最上位の層の情報オブジェクトは、下位の層のオブジェクトとの実装のために抽象的に定義できる。上位の層は、コンピュータ間での抽象オブジェクトの転送を定義でき、下位の層は、転送をビット列として具体的に定義できる。抽象オブジェクトの定義には文法が必要で、抽象オブジェクトとビット列の変換にはエンコーディング規則が必要である。
（Basic Encoding Rules 参照。）

(C) ASN.1 では、正式名は空白を用いずに記述し、名前の中の各単語は最初の文字を大文字にすることによって区別する。ただし、先頭の単語の最初の文字は大文字にはしない。例えば、CRLの名前は、"certificateRevocationList" である。

$ ACC
access control center 参照。

$ access （アクセス）
(I) システム資源を使用して情報を処理する、あるいは、システムが保有する情報を認識するために、システムと通信する、あるいはシステムとやり取りする能力と手段。

(O) 「結果として一方から他方への情報の流れとなる主体と客体間の特定の種類のやり取り。」 [NCS04]

(C) この小事典においては、システム間とのいずれか一方向の通信も含め、システムと通信する任意の能力を「アクセス」としている。しかし、実際には、セキュリティ領域の外部にあり、システムからの出力は受け取るが、入力できない、またはシステムと直接やり取りできない主体は、「アクセス」を持たないものして扱われ、それゆえ、セキュリティクリアランスの要求などのセキュリティポリシーの要件を免除される。

$ access control （アクセスコントロール）
(I) 権限のないアクセスに対するシステムリソースの保護； システム資源を使用するプロセスは、セキュリティポリシーによってコントロールされ、権限を持った主体 (ユーザー、プログラム、プロセス、または他のシステム）によってのみセキュリティポリシーに基づいて許可される。
（access, access control service 参照。）

(O) 「資源に対する権限のない使用を防止すること。権限のない方法による資源の使用を防止することも含む。」 [I7498 Part 2]

$ access control center (ACC) （アクセスコントロールセンター）
(I) アクセス制御サービスのセキュリティポリシーを定義するエントリのあるデータベースを持つコンピュータ。

(C) ACC は、共通鍵暗号方式における鍵配布システムにアクセス制御を実装するため、鍵センターと共にしばしば用いられる。

$ access control list (ACL)
(I) 特定のシステム資源へのアクセスが許容されている主体の身元であることをチェックすることによってシステム資源についてのアクセスコントロールを実装するメカニズム。
（capability 参照。）

$ access control service （アクセスコントロールサービス）
(I) システム主体がシステムのセキュリティポリシーで認定されていない方法でシステムリソースを使用するのを防護するセキュリティサービス。； 簡単に言うと、権限のないアクセスからシステム資源を防護すること。
（access control, discretionary access control, identity-based security policy, mandatory access control, rule-based security policy 参照。）

(C) このサービスは、別の方法でリソースの使用を認定されたユーザーが、権限のない方法でリソースを使用することに対する防護も含む。このサービスを実装するための 2 つの基本的な機構は、ACL とチケットである。

$ access mode （アクセスモード）
(I) 主体が、コンピュータ システム内のオブジェクトに潜在的に実行できるデータ処理操作（例： 読み込み、書き出し、追加、実行）の明確な種類。

$ accountability （アカウンタビリティ、説明可能性）
(I) 「システム主体の行為を、その行為に責任をもつ主体について、一意に追跡できること」を確保するシステムの（システム資源すべてを含む）属性。
（audit service 参照。）

(C) 説明可能性（accountability）は、セキュリティ侵害の検知と以降の調査を許容する。

$ accredit （運用を承認する）
$ accreditation （運用承認）
(I) 指示されたセーフガードをもつ特定のセキュリティ設定のもとに、情報システムが運用することを承認される、という指定された機関による行政的宣言。[FP102]
（certification 参照。）

(C) accreditation は、通常、システムのセキュリティメカニズムの技術的な certification に基づく。"certification" と "accreditation" という用語は、商業組織体においてよりも、米国国防総省や他の省庁において、より頻繁に使われ ている。しかし、この概念は、マネージャーがセキュリティリスクを扱うことが要求される局面、および、責任を受容する局面であれば、適用可能である。ABA（American Bar Association）は、CA のための運用承認（accreditation）を開発している。

$ ACL
access control list 参照。

$ acquirer
(N) SET における用法：
「業者とアカウントを確立し、支払いカード 認可と支払いを処理する財務的な団体。」 [SET1]

(O) 「カード受取者からトランザクションに関する財務データを取得し、そのデータを交換システムに生成する団体（または、その代理人）。」 [SET2]

$ active attack （積極的攻撃）
attack（にある 2番目の定義）参照。

$ active wiretapping （積極的な回線盗聴）
wiretapping（にある 2番目の定義）参照。

$ add-on security
(I) 「[自動データ処理] システムが稼動した後、ハードウェアもしくはソフトウェアによって実装された保護メカニズムを改造すること。」 [FP039]

$ administrative security
(I) システムへの権限のないアクセスを防止する管理的な手順および制約。
（security architecture 参照。）

(O) 「機密データの保護に対する受け入れ可能なレベルを提供するために確立された管理制約、運用手順、説明責任に関する手順、および補助的コントロール。」 [FP039]

(C) 義務の明確な定義と分割および設定コントロールを含む例。

$ Advanced Encryption Standard (AES)
(N) DES の後継として NIST によって開発されている次世代の FIPS 発行物。全世界でロイヤリティフリーで利用できる、機密でなく、公開された、共通鍵暗号化アルゴリズムの選定を目的としている。
$ adversary （敵）
(I) システムを攻撃する主体、あるいはシステムに対して脅威となる主体。

$ aggregation
(I) 情報アイテムの集まりが、それを構成する個々のどのアイテムよりも、より高いセキュリティレベルに分類される状況。

$ AH
Authentication Header 参照。

$ algorithm
(I) 問題を解決するためのステップごとの命令または計算手順の有限個のセットで、特にコンピュータに実装されるもの。
（cryptographic algorithm 参照。）

$ alias
(I) 実際の名前の代わりに使用する名前。通常は、匿名性または欺瞞の目的で用いる。

$ American National Standards Institute (ANSI)
(N) ユーザー、業者、および他の組織による、非営利の協会で、米国民間部門の自発的な標準を管理する。

(C) ANSI は、2 つのメジャーな国際標準化組織である ISO と、USNC（米国国内委員会）経由の IEC（国際電気標準会議）の米国唯一のメンバー体である。

$ anonymous
(I) 未知もしくは秘密にされている名前を持っている状態。
（anonymous login 参照。）

(C) アプリケーションは、ユーザーまたは他のシステム主体のプライバシーを保持したり、攻撃から隠したりするために、それらの匿名性を維持するセキュリティサービスを必要とする。主体の実名を隠すときは、エイリアス（別名）を使用することがある。例えば、財務的な協会はアカウント番号を割り当てるであろう。これによって、トランザクションに関わる団体は相対的な匿名性を維持しながら、正式なトランザクションを受け取ることができる。団体の実名は、トランザクションの監視者からは簡単には識別されないが、権限のある第三者は、裁判所の命令を協会に提示することなどにより、エイリアスと実名を一致させることができる。他のアプリケーションでは、エイリアスを完全にトレースできない場合もある。
$ anonymous login
(I) 多くのインターネットホストで使用されているアクセス制御機能で、事前に設定されたユーザー固有のアカウント（すなわち、ユーザー名と秘密パスワード）なしに、汎用または公開サービスおよびホスト上のリソースへのアクセス（たとえば、FTP (File Transfer Protocol) によるデータ転送など)を可能にする。

(C) すべてのユーザーが、自己の行動を説明できる既知の登録済みの主体である場合に比べ、この機能は、システムをより多くの脅威に晒す。ユーザーは、広く知られている特殊な名前 (例："anonymous"、"guest"、または "ftp") を使用してログインする。公開名を使用するには、ユーザは秘密パスワードを知る必要はなく、名前以外の入力は求められない。別のケースでは、ログインプロトコルの通常手順を完了させるために、システムが、対応する公開パスワード（"anonymous"） の入力をユーザーに求めたり、電子メールアドレスやその他の任意の文字列をユーザーに求めたりすることがある。

$ APOP
POP3 APOP 参照。

$ archive （アーカイブ）
(I)
(1.) 名詞：
記録的な目的や、監査サービス、可用性サービス、システムの完全性サービスのサポートなどの目的で、比較的長期間保存されているデータの集まり。
（backup 参照。）
(2.) 動詞：
このような方法でデータを保存すること。
（back up 参照。）

(C) 署名後に長い年月が経過したときは、デジタル署名の検証が必要なことがある。この年月の間に、CA（署名の検証に必要な公開鍵を含む証明書を発行した CA）が機能しなくなっている可能性がある。このため、CA は、証明書の発行先の署名を検証するために必要な情報を長期間保存する必要がある。

$ ARPANET
(N) Advanced Research Projects Agency Network。1970 年代初めに米国政府の管轄下で構築された最初のパケット交換ネットワーク。これが、現在のインターネットの開発へと発展した。1990年 6月に運用終了。

$ ASN.1
Abstract Syntax Notation One 参照。

$ association （協定）
(I) システム主体間における協力関係であり、通常、それらの間で情報を転送する目的のためのもの。
（security association 参照。）

$ assurance （保証）
(I)
(1.) 情報システムの属性の 1 つで、システムセキュリティポリシーに沿ってシステムが動作することの信頼性を与える土台を提供する。
(2.) システムのセキュリティポリシーに従ってシステムが開発および運用されていることを確認する手続き。

$ assurance level （保証レベル）
(I) 評価における用法：
階層的な尺度における特定のレベル。評価対象が十分に要件を達成できる、連続的に増加した信頼性を表す。
（例： TCSEC 参照。）

$ asymmetric cryptography （公開鍵暗号技術）
(I) 暗号化の近代的な手法の 1つで、一般に、公開鍵暗号技術と呼ばれている。このアルゴリズムは、鍵のペア (公開鍵とプライベート鍵) を用い、アルゴリズムの異なるステップでは、鍵ペアの異なるコンポーネントを使用する。
（key pair 参照。）

(C) 公開鍵暗号技術は、同等の強さをもつ共通鍵暗号技術よりも、鍵管理において優位性がある。その理由として、まず、ペアの一方の鍵が、その鍵の所有者を除く誰にも知られる必要がない点が挙げられる。このため、より簡単に鍵を安全に保管できる。次に、もう一方の鍵はそのアルゴリズムを使用するすべての主体によって共有されるが、鍵を使用しない他の主体から鍵を秘密に保つ必要はない。このため、鍵管理における鍵配布の部分が容易に実行される。

(C) 暗号化用：
公開鍵暗号アルゴリズム（例： RSA 参照）では、アリスがボブに送信するデータの守秘性を保持するには、アリスはボブ から提供された公開鍵を使用してデータを暗号化する。ボブだけが、データの復号に必要な、一致するプライベート鍵を持つ。

(C) 署名用：
公開鍵暗号デジタル署名アルゴリズム（例： DSA 参照）では、アリスがボブに送信するデータの完全性を保持する、またはデータに正当性を与えるには、アリスは自身のプライベート鍵を使用してデータに署名する（すなわち、データに基づくデジタル署名を作成する）。署名を検証するには、ボブはアリスから提供された、一致する公開鍵を使用する。

(C) 鍵共有用：
公開鍵暗号鍵交換アルゴリズム（例： Diffie-Hellman 参照）では、アリスとボブは各自の公開鍵を相互に送信する。次に、自身のプライベート鍵と相手の公開鍵を使用して新しい鍵値を計算する。

$ attack （攻撃）
(I) インテリジェントな脅威、すなわちセキュリティサービスを回避し、システムのセキュリティポリシーを侵害する故意の試み（特に、方式あるいは技法という意味において）としてのインテリジェントな動作によってもたらされるセキュリティシステムへの攻撃。
（penetration, violation, vulnerability 参照。）

(C) 攻撃（attack）という用語は、次のダイアグラムに示した、いくつかの他の基礎的なセキュリティ用語と関連する。：

+ - - - - - - - - - - - - +  + - - - - +  + - - - - - - - - - - -+

| An Attack:              |  |Counter- |  | A System Resource:   |

| i.e., A Threat Action   |  | measure |  | Target of the Attack |

| +----------+            |  |         |  | +-----------------+  |

| | Attacker |<==================||<=========                 |  |

| |   i.e.,  |   Passive  |  |         |  | |  Vulnerability  |  |

| | A Threat |<=================>||<========>                 |  |

| |  Agent   |  or Active |  |         |  | +-------|||-------+  |

| +----------+   Attack   |  |         |  |         VVV          |

|                         |  |         |  | Threat Consequences  |

+ - - - - - - - - - - - - +  + - - - - +  + - - - - - - - - - - -+
$ attribute authority （属性機関）
(I) 属性証明書を発行する CA。

(O) 「検証者によって権限の委任が信頼された、属性証明書を発行する機関。」 [FPDAM]

$ attribute certificate （属性証明書）
(I) 公開鍵以外の記述的なデータアイテムのセットを、主体名に直接バインドするか、公開鍵証明書である他の証明書にバインドするデジタル証明書。 [X509]

(O) 「いくつかの他の情報を伴う一式のユーザの属性であり、それを発行した CA（認証機関）のプライベート鍵を使って作り出されたデジタル署名によって、偽装不能に提供される。」 [X509]
　
(O) 「いくつかの属性値および属性証明書の所有者の識別情報を含むデータ構造体で、すべてが属性認証局によってデジタル署名されている。この機関の署名は、属性と所有者間のバインディングの保証として機能する。」 [FPDAM]

(C) 公開鍵証明書は、特定の暗号機能を実行するのに必要な情報と共に、主体の名前を公開鍵の値にバインドする。セキュリティクリアランスなどの主体のその他の属性は、属性証明書と呼ばれる別の種類のデジタル証明書によって証明されることがある。主体は、自分自身の名前やそれぞれの公開鍵証明書対応する複数の属性証明書を持つことがある。

(C) 属性証明書は、次の状態のときに主体に発行される。：
$ audit service （監査サービス）
(I) システムイベント、およびその原因となったシステム主体の活動に対する説明能力を確立するのに必要な情報を記録するセキュリティサービス。
（security audit 参照。）

$ audit trail （監査証跡）
security audit trail 参照。

$ AUTH
POP3 AUTH 参照。

$ authentic signature
(I) 検証可能であるために信頼できる署名 (特にデジタル署名)。
（validate vs. verify 参照。）

$ authenticate （認証する）
(I) システム主体によって／システム主体について、主張された身元を検証すること（すなわち、同一性が真実であると確立すること）。
（authentication 参照。）

(D) 一般的な英語の用法において、この用語は、通常、「真正性を提供すること（to prove genuine）」を意味する。（例： 芸術の達人がミケランジェロの絵画を「真正であるとする（authenticate）」。） しかし、推奨される定義は、もっと狭い意味をもつ。例えば、インターネット標準文書は、正確であるように、"the host authenticates each received datagram (ホストは、受け取った各データグラムを認証する)"といってはいけない（SHOULD NOT）。代わりに、そのインターネット標準文書は、"the host authenticates the origin of each received datagram (ホストは、受け取った各データグラムの出自を認証する) "という必要がある（SHOULD）。大部分の場合、我々は、"and verifies the datagram's integrity (そして、データグラムの完全性を検証する)" ともいうが、通常、これは暗示される。
（data integrity service （における「data integrity service と authentication services の関係」）参照。）

(D) インターネット標準文書は、デジタル署名（digital signature）もしくはデジタル証明書（digital certificate）について、認証する（authenticate）と語ってはいけない（SHOULD NOT）。代わりに、デジタル署名を「署名（sign）」し「正確性検証（verify）」する、およびデジタル証明書を「発行（issue）」し「十分性検証（validate）」するという。
（validate vs. verify 参照。）

$ authentication （認証）
(I) システム主体によって／システム主体について、主張された身元を検証するプロセス。
（authenticate, authentication exchange, authentication information, credential, data origin authentication, peer entity authentication 参照。）

(C) 認証過程は、2つのステップから成る。：
1. 識別ステップ：
識別子をセキュリティシステムに渡す。
(認証された同一性はアクセス制御サービスなどの他のセキュリティサービスのベースとなるので、識別子は慎重に割り当てなければならない。)
2. 検証ステップ：
主体と識別子間のバインディングを確証する認証情報を提供または生成する。
（verification 参照。）

(C) data integrity service （における「data integrity service と authentication services の関係」）参照。

$ authentication code
(D) インターネット標準文書は、暗号技術的であるか否かを問わず、いかなる形態のチェックサム（checksum）の同義語としても、この用語を使ってはいけない（SHOULD NOT）。通常、関連するメカニズムは、認証関数としてではなく、データ完全性関数として機能するので、"authentication"という単語は誤解を招く。また、"code" という単語は誤解を招く。これは、エンコードまたは暗号化の関与や、コンピュータソフトウェアを示す単語を暗示するからである。
（message authentication code 参照。）

$ authentication exchange （認証交換）
(I) 情報交換の手段で、主体の身元を検証するメカニズム。

(O) 「情報交換の手段で、主体の身元を確認することを目的とするメカニズム。」 [I7498  Part 2]

$ Authentication Header (AH) （認証ヘッダー）
(I) コネクション指向でないデータ完全性サービス、IP データグラムに対する出所認証サービス、およびリプレイ攻撃に対する防御 (オプション) の提供を目的として設計されたインターネット IPSec プロトコル。 [R2402]

(C) リプレイ攻撃に対する防護は、セキュリティ協定が確立されるとき、受信者によって選択される可能性がある。AH は、上位層プロトコルのデータユニット、および、可能な限り多くの IP ヘッダーを認証する。しかし、IP ヘッダーのフィールドには、転送中に変化するものがあり、受信者にパケットが到着するとき、これらのフィールドの値は、送信者によって防護されていない可能性がある。それゆえ、このようなフィールドの値は、AH によって「エンド to エンド」に防護できない。； AH による IP ヘッダーの防護は、このようなフィールドが存在するとき、部分的なものにすぎない。

(C) AH は、単独で、あるいは、IPsec ESP プロトコルと組み合わせて、あるいは、トンネル化によって包まれた形態で使われる可能性がある。セキュリティサービスを、通信ホストのペア間、通信セキュリティゲートウェイのペア間、もしくは、ホストとゲートウェイの間に提供できる。ESP は、AH と同様なセキュリティサービスを提供でき、ESP も、データ守秘性サービスを提供できる。ESP によって提供される認証サービスと、AH によって提供されるものの主要な差異は、対応範囲である。； ESP は、AH によってカプセル化されていない限り IP ヘッダーフィールドを防護しない。

$ authentication information （本人認証情報）
(I) 主体によって／主体について、主張された身元を検証するために使われる情報。
（authentication, credential 参照。）

(C) 本人認証情報は、次のどれかとして、もしくは、次のどれかから得られる。：
$ authentication service （認証サービス）
(I) ある主体によって主張された身元、もしくは、ある主体についての身元を正確性を検証するセキュリティサービス。
（authentication 参照。）

(C) ネットワークにおいて、2 つの一般的な形態の認証サービスがある。： データ発信元認証サービスと、ピア主体認証サービスである。

$ authenticity （真正性）
(I) 真正であり、かつ、検証可能で信頼可能であることの属性。
（authenticate, authentication, validate vs. verify 参照。）

$ authority （機関）
(D) 「証明書の発行について責任を負う主体。」 [FPDAM]

(C) インターネット標準文書は、この用語を AA, CA, RA, ORA もしくは同様の用語の同義語として使ってはいけない（SHOULD NOT）。なぜなら、混乱をもたらす可能性があるからである。代わりに、用法の最初の箇所で用語全体を使い、次に、その文章を短くすることが必要不可欠である場合、この小辞典において定義されたスタイルの短縮語を使う。

(C) インターネット標準文書は、この定義をいかなる PKI 主体についても使ってはいけない（SHOULD NOT）。なぜなら、この定義は、「この主体が実際に証明書を発行するのか（例： AA（Attribute Authority）もしくは CA（Certification Authority）、あるいは、単に、先行処理もしくは以降の署名について説明責任をもつのみであるのか（例： RA（Registration Authority））」に関して曖昧であるからである。
（issue 参照。）

$ authority certificate
(D) 「機関／局宛に発行された証明書（例： either to a 認証機関／認証局（CA： Certification Authority）宛、もしくは、属性機関／属性局（AA： Attribute Authority）宛。」 [FPDAM]
（authority 参照。）

(C) インターネット標準文書は、この用語もしくは定義を使ってはいけない（SHOULD NOT）。なぜなら、どの種類の PKI エンティティに対応するかについて、曖昧であるからである。

$ authority revocation list (ARL)
(I) CA 宛に発行されたが、予定されていた失効日以前に発行者によって無効化されたデジタル証明書を列挙するデータ構造。
（certificate expiration, X.509 authority revocation list 参照。）

(O) 「証明書発行者によって、もはや有効ではないとみなされる機関に対して発行された公開鍵証明書のリストを含む失効リスト。」 [FPDAM]

$ authorization （認可）
$ authorize （認可する）
(I)
(1.) 「認可（authorization）」は、システム主体が、システム資源にアクセスすることをかなえられた、権限もしくは許可である。
(2.) 「認可過程（authorization process）」は、そのような権限をかなえるための手順。
(3.) 「認可する（authorize）」とは、そのような権限もしくは許可をかなえることを意味する。
（privilege 参照。）

(O) SET における用法：
「正規に指名された人間が、ある組織体を代表する何らかの行為を行う権限を決裁する過程。この過程は、取引リスクを評価し、「ある取引が、口座名義人与信限度額を越えて負債を増やさないこと」を確認し、一定の与信金額を確保する。（商人が認可を得たとき、認可された金額についての決済は、当然ながら、「その承認が、認可過程に関するルールに従ったこと」 が保証・提供されている。）」 [SET2]

$ automated information system （自動化された情報システム）
(I) 一定の仕様とされた機能を実現するために、情報を収集、記録、処理、蓄積、転送、取得もしくは表示するシステム資源と手順の組織的な組み合わせ（すなわち、サポート施設と要員を伴う情報処理と通信の機器とサービス）。

$ availability （アベイラビリティ／可用性）
(I) ある認可されたシステム主体によって要求されたとき、システムについての性能仕様に従って、アクセス可能であり、かつ、利用可能であるというシステムもしくはシステム資源の属性。； すなわち、ユーザがシステムに要求すれば、いつでも、システムがそのシステム設計に従ったサービスを提供する場合、システムは利用可能である。
（critical, denial of service, reliability, survivability 参照。）

(O) 「認可された主体による要望に応じて、アクセス可能であり、利用可能である属性。」 [I7498 Part 2]

$ availability service （アベイラビリティサービス／可用性サービス）
(I) システムのアベイラビリティ（可用性）を確保するように保護するセキュリティサービス。

(C) このサービスは、サービス妨害攻撃によって起こされるセキュリティ関心事に対応する。これは、正しいマネジメントとシステム資源のコントロールに依存するので、アクセスコントロールサービスや他のセキュリティサービスに依存する。

3 ->B