Skip to content

NIST 特別刊行物 800-162

属性ベースアクセス制御（ABAC）— 定義と考慮事項ガイド

Vincent C. Hu、David Ferraiolo、Rick Kuhn、Adam Schnitzer、Kenneth Sandlin、Robert Miller、Karen Scarfone

本刊行物は以下から無償で入手できます: https://doi.org/10.6028/NIST.SP.800-162

C O M P U T E R S E C U R I T Y

NIST 特別刊行物 800-162

属性ベースアクセス制御（ABAC）— 定義と考慮事項ガイド

Vincent C. Hu、David Ferraiolo、Rick Kuhn コンピュータセキュリティ部門 情報技術研究所

Adam Schnitzer Booz Allen Hamilton

Kenneth Sandlin、Robert Miller The MITRE Corporation

Karen Scarfone Scarfone Cybersecurity（米バージニア州クリフトン）

本刊行物は以下から無償で入手できます:

https://doi.org/10.6028/NIST.SP.800-162

2014 年 1 月

2019-08-02 時点の更新を含む。詳細は ix ページ参照。

米国商務省 長官 Penny Pritzker

国立標準技術研究所（NIST） Patrick D. Gallagher（商務次官〈標準技術担当〉兼 NIST 長）

権限（Authority）

本刊行物は、連邦情報セキュリティ管理法（FISMA、Public Law（P.L.）107-347）に基づく NIST の法定責務を推進するために作成されたものである。NIST は、連邦情報システムの最小要件を含む情報セキュリティの標準およびガイドラインを策定する責任を負うが、これらの標準・ガイドラインは、当該システムに対する政策権限を行使する適切な連邦当局の明示的承認がない限り、国家安全保障システムには適用されない。本ガイドラインは、行政管理予算局（OMB）回章 A-130 の第 8b(3)節「庁内情報システムの保護」の要件と整合しており、回章 A-130 付録 IV「主要セクションの分析」で分析されている。補足情報は、回章 A-130 付録 III「連邦自動化情報資源のセキュリティ」に提供されている。

本刊行物のいかなる内容も、商務長官が法定権限に基づき連邦機関に対し義務化・拘束力を持って定めた標準・ガイドラインと矛盾するものとして解釈してはならない。また、本ガイドラインが商務長官、OMB 長官、その他の連邦当局の既存の権限を変更または優越するものとして解釈されてはならない。本刊行物は、任意に民間団体が使用することができ、米国内において著作権の対象とはならない。ただし、出典表示（アトリビューション）を行うことができれば、NIST としては望ましい。

National Institute of Standards and Technology Special Publication 800-162 Natl. Inst. Stand. Technol. Spec. Publ. 800-162, 47 pages（2014 年 1 月） CODEN: NSPUE2

本刊行物は以下から無償で入手できます: https://doi.org/10.6028/NIST.SP.800-162

本書では、実験手順や概念を適切に記述するために、特定の商用団体、機器、または資材が記載されている場合がある。かかる記載は、NIST による推奨や支持を意味するものではなく、また、それらの団体・資材・機器が当該目的に入手可能な中で必ずしも最良であることを意味するものでもない。

本刊行物には、NIST が付与された法的責務に従い現在作成中の他の刊行物への参照が含まれている場合がある。本刊行物に含まれる情報（概念や方法論を含む）は、関連する補助刊行物の完成前であっても連邦機関が使用できる。したがって、各刊行物が完成するまでは、現行の要件、ガイドライン、手順が存在する場合にはそれらが有効である。計画や移行の目的のため、連邦機関は NIST によるこれら新刊行物の開発を注意深く追跡することが望ましい。

組織は、公開コメント期間中にすべての草案をレビューし、NIST にフィードバックを提供することが推奨される。上記で特記したものを除き、NIST コンピュータセキュリティ部門の刊行物は https://csrc.nist.gov/publications で入手可能である。

本刊行物に関するコメント送付先：

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive（Mail Stop 8930） Gaithersburg, MD 20899-8930 Email: sp800-162-comments@nist.gov

コンピュータシステム技術に関する報告書

国立標準技術研究所（NIST）の情報技術研究所（ITL）は、米国の測定・標準インフラストラクチャに対する技術的リーダーシップを提供することにより、米国経済と公共の福祉の向上に寄与している。ITL は、情報技術の発展と生産的な利用を促進するため、試験、試験手法、参照データ、概念実証実装、ならびに技術分析を開発する。ITL の責務には、連邦情報システムにおける、国家安全保障に関係しない情報の費用対効果の高いセキュリティとプライバシーのための、管理、運用、技術、物理的標準およびガイドラインの策定が含まれる。特別刊行物 800 シリーズは、情報システムセキュリティにおける ITL の研究、ガイドライン、アウトリーチの取り組み、ならびに産業界、政府、学術機関との協働活動について報告する。

要旨（Abstract）

本書は、属性ベースアクセス制御（ABAC）の定義を連邦機関に提供する。ABAC は論理的アクセス制御の方法論であり、主体、客体、要求された操作、および場合によっては環境条件に関連付けられた属性を、当該属性集合に対して許容される操作を記述するポリシー、規則、関係に照らして評価することにより、一定の操作集合を実行する権限を決定する。本書はまた、情報の管理を維持しつつ、組織内および組織間での情報共有を改善するために ABAC を用いる際の考慮事項も提供する。

キーワード

アクセス制御；アクセス制御機構；アクセス制御モデル；アクセス制御ポリシー；属性ベースアクセス制御（ABAC）；認可；特権。

謝辞（Acknowledgements）

著者である NIST の Vincent C. Hu、David Ferraiolo、Rick Kuhn、Booz Allen Hamilton の Adam Schnitzer、The MITRE Corporation の Kenneth Sandlin と Robert Miller、Scarfone Cybersecurity の Karen Scarfone は、本書の草案をレビューした同僚各位に謝意を表する。以下を含む：National Security Agency（NSA）の Arthur R. Friedman、Alan J. Lang、Margaret M. Cogdell、Kevin Miller、Jeffery L. Coleman（SOTERA Defense Solutions）、Anne P. Townsend（The MITRE Corporation）、Jennifer Newcomb（Booz Allen Hamilton）、Tim Weil（Coalfire）、Ed Coyne（DRC）、John W. Tolbert（Boeing）、Jeremy Wyant（General Dynamics）、Ian Glazer（Gartner）、Scott C. Fitch（Lockheed Martin）、Tim Schmoyer（Jericho Systems）、Luigi Logrippo（Université du Québec en Outaouais）、Dave Coxe（Criterion Systems）、Don Graham（Radiant Logic）、ならびに NIST の Ronald Ross と Ramaswamy Chandramouli。さらに、NIST コンピュータセキュリティ部門は、本取り組みを開始し、政府および産業界における属性ベースアクセス制御の重要性の高まりを先見的に見抜いた Friedman 氏に謝意を表する。

また、政府機関、民間組織、個人が、本書の作成にあたり方向性や支援を提供する形で寄せたコメントと貢献にも、著者らは深く感謝する。

商標情報

すべての登録商標または商標は、それぞれの組織に帰属する。

目次

- エグゼクティブサマリー …… vii

  1. はじめに …… 1

  2. 1.1 目的と適用範囲 …… 1

  3. 1.2 想定読者 …… 1
  4. 1.3 文書構成 …… 1
  5. 1.4 用語に関する注記 …… 2

- 2. ABAC の理解 …… 4

  • 2.1 ABAC の利点 …… 5
  • 2.2 ABAC の作業定義 …… 6
  • 2.3 ABAC の基本概念 …… 8

  • 2.4 企業レベルの ABAC 概念 …… 11

    • 2.4.1 企業 ABAC ポリシー …… 12
    • 2.4.2 企業 ABAC における属性管理 …… 13
    • 2.4.3 企業 ABAC におけるアクセス制御機構の分散 …… 14

- 3. ABAC の企業導入に関する考慮事項 …… 17

  • 3.1 構想段階の考慮事項 …… 18

    • 3.1.1 ABAC 機能導入のビジネスケースの構築 …… 18
    • 3.1.2 スケーラビリティ、実現可能性、性能要件 …… 19
    • 3.1.3 運用要件とアーキテクチャの策定 …… 22

  • 3.2 調達／開発段階の考慮事項 …… 25

    • 3.2.1 業務プロセスの生成と展開準備 …… 25
    • 3.2.2 システム開発とソリューション調達の考慮事項 …… 27
    • 3.2.3 その他の企業 ABAC 機能に関する考慮事項 …… 30

  • 3.3 実装／評価段階の考慮事項 …… 31

    • 3.3.1 属性キャッシング …… 31
    • 3.3.2 属性ソースの最小化 …… 31
    • 3.3.3 インタフェース仕様 …… 32

  • 3.4 運用／保守段階の考慮事項 …… 32

    • 3.4.1 質の高いデータの可用性 …… 32

- 4. 結論 …… 33 - 付録 A — 頭字語と略語 …… 34 - 付録 B — 参考文献 …… 36

図一覧

  • 図 1：従来型（非 ABAC）の複数組織間アクセス方法 …… 6
  • 図 2：ABAC の基本シナリオ …… 8
  • 図 3：ABAC の中核機構 …… 9
  • 図 4：企業 ABAC のシナリオ例 …… 12
  • 図 5：ACM の機能ポイント例 …… 15
  • 図 6：ACM の NIST システム開発ライフサイクル（SDLC） …… 17
  • 図 7：ACL のトラストチェーン …… 21
  • 図 8：ABAC のトラストチェーン …… 22

エグゼクティブサマリー

属性ベースアクセス制御（ABAC）の概念は長年存在してきた。これは、アクセス制御リスト（ACL）、ロールベースアクセス制御（RBAC）、および属性の評価に基づいてアクセスを提供する ABAC 方式を含む、論理的アクセス制御の空間における一点を表す。従来、アクセス制御は、オブジェクト（例：ファイル）に対して操作（例：読み取り）を実行する能力の実行を要求するユーザの同一性に基づいて、直接またはロールやグループといった事前定義の属性型を通じて行われてきた。実務者は、このアプローチでは、能力をユーザ自身やそのロール／グループに直接関連付ける必要があるため、管理がしばしば煩雑になることを指摘してきた。さらに、要求者の限定子である同一性、グループ、ロールは、現実世界のアクセス制御ポリシーの表現においてしばしば不十分であることも指摘されている。代替案として、ユーザの任意の属性、オブジェクトの任意の属性、そして当該ポリシーにより関連性が高くグローバルに認識されうる環境条件に基づいて、ユーザ要求を許可または拒否する方法がある。これがしばしば ABAC と呼ばれるアプローチである。

2009 年 11 月、連邦最高情報責任者協議会（Federal CIO Council）は、「Federal Identity, Credential, and Access Management（FICAM） Roadmap and Implementation Plan v1.0」[FEDCIO1] を公表し、連邦組織が論理的アクセス制御アーキテクチャを発展させ、組織内および連邦エンタープライズ全体での組織間アクセスを可能にする方法として、属性の評価を含めるための指針を提供した。2011 年 12 月には、FICAM Roadmap and Implementation Plan v2.0 [FEDCIO2] が、異種・多様な組織間での情報共有を促進するための推奨アクセス制御モデルとして ABAC を明示的に挙げる段階へと進んだ。2012 年 12 月には、「国家情報共有・保護戦略（National Strategy for Information Sharing and Safeguarding）」において、連邦政府があらゆるセキュリティドメインの連邦ネットワーク全体で FICAM ロードマップを拡張・実装すべきという優先課題が含まれた。米国総務庁（GSA）と Federal CIO Council はこの課題の主担当とされ、実装計画を準備している。

FICAM ロードマップおよび文脈（リスク適応）型のロール／属性ベースアクセス制御を実装するという明確な指針があるにもかかわらず、これまで連邦政府内で ABAC を正式に定義したり実装を指導したりする包括的な取り組みは行われてこなかった。本書は二つの目的を持つ。第一に、連邦機関に ABAC の定義と ABAC の機能要素の説明を提供すること。第二に、情報共有を改善しつつその情報の管理を維持することを目的に、企業内で ABAC を採用するための計画、設計、実装、運用に関する考慮事項を提供することである。本書は、ABAC と他のアクセス制御機能との比較評価（代替案分析）として解釈されるべきではない。というのも、本書は ABAC の導入に伴う課題に焦点を当てており、他の機能と ABAC の費用対効果を比較して均衡を図ることを目的としていないためである。

ABAC は、要求に関連する主体・客体の属性、操作、および環境に対する規則を評価することで客体へのアクセスを制御する点で特徴づけられる論理的アクセス制御モデルである。ABAC システムは、任意アクセス制御（DAC）および強制アクセス制御（MAC）の概念の双方を実施することが可能である。ABAC は精緻なアクセス制御を可能にし、アクセス制御判断に取り込まれる離散的入力の数を増やすことにより、これらの変数の組合せの可能性を拡大し、ポリシーを表現するためのより大きく明確な規則集合を提供する。

ABAC で実装可能なアクセス制御ポリシーは、計算言語の能力と利用可能な属性の豊富さによってのみ制限される。この柔軟性により、各主体と各客体の個別の関係を特定することなく、最も幅広い主体が最も幅広い客体にアクセスできるようになる。例えば、主体は雇用時に主体属性の集合が付与される（例：「Nancy Smith は循環器科の看護師（Nurse Practitioner）である」）。客体は作成時に客体属性が付与される（例：「心臓疾患患者の医療記録を収めたフォルダ」）。客体は作成者から直接、または自動スキャンツールの結果として属性を付与されうる。管理者または客体の所有者は、主体と客体の属性を用いてアクセス制御規則を作成し、許容される能力の集合を規定する（例：「循環器科のすべての看護師は心臓疾患患者の医療記録を閲覧（View）できる」）。ABAC では、属性値を変更するだけでアクセス判断が要求ごとに変化しうるため、根底にある規則集合を定義する主体／客体の関係を変更する必要がない。これにより、より動的なアクセス制御管理が可能となり、客体保護の長期的な保守要件が抑制される。

さらに、ABAC は、特定の主体について事前知識がなく、アクセスを必要とする主体数が無制限であっても、客体の所有者や管理者がアクセス制御ポリシーを適用できるようにする。新しい主体が組織に加わっても、規則や客体を変更する必要はない。必要な客体へのアクセスに必要な属性が主体に付与されている限り（例：循環器科のすべての看護師にその属性が付与されている）、既存の規則や客体属性を変更する必要はない。この利点はしばしば「外部（想定外）のユーザを取り込める」能力と呼ばれ、ABAC を採用する主要な利点の一つである。

情報共有を多様な組織間で高める目的でエンタープライズ全体に展開する場合、ABAC の実装は、属性管理インフラ、機械可読なポリシー、アクセス決定とポリシー執行を支える一連の機能によって支えられる複雑なものになりうる。

基本的なポリシー、属性、アクセス制御機構の要件に加え、企業は、企業ポリシーの策定と配布、企業のアイデンティティと主体属性、主体属性の共有、企業の客体属性、認証、アクセス制御機構の展開と配布のための管理機能を支援しなければならない。これらの機能の開発と展開には、企業 ABAC ソリューションの設計、セキュリティ、相互運用性に影響を与える多くの要因を慎重に検討する必要がある。これらの要因は、次の活動の集合として要約できる：

  • ABAC 実装のビジネスケースを確立する
  • 運用要件と全体的なエンタープライズアーキテクチャを理解する
  • ABAC を支援するための業務プロセスを確立または洗練する
  • 相互運用可能な機能セットを開発・調達する
  • 効率的に運用する

本書の残りの部分では、ABAC の概念と、エンタープライズ ABAC 機能を導入する際の考慮事項について、より詳細な説明を提供する。本書は、ABAC を活用して米国連邦政府の情報共有と保護の要件を満たそうとする計画立案者、アーキテクト、管理者、実装担当者を支援する第一歩となる。

正誤表（Errata）

この表は、特別刊行物（SP）800-162 に取り込まれた変更を示す。正誤表の更新には、編集上または実質的な性質のいずれかで、出版物に対する修正、明確化、その他の軽微な変更が含まれうる。

日付 種別 変更点 該当ページ
2019-02-25 編集 すべてのページで DOI と入手可否の記述を更新。 全ページ
2019-02-25 編集 NIST SP 800-63-1 および 800-63-2 の参照を、SP 800-63-3 および SP 800-63B への参照に置換。 1, 27, 37
2019-02-25 編集 付録 B のいくつかの参考文献を、当該文書の現行版に合わせて更新。 36–37
2019-08-02 実質的変更 図 8「ABAC のトラストチェーン」を更新し、アクセス制御判断への入力として「環境条件」を含めるようにした。 22

1. はじめに

1.1 目的と適用範囲

本書の目的は、連邦機関に属性ベースアクセス制御（ABAC）の定義を提供し、情報の管理を維持しつつ情報共有を改善するために ABAC を用いる際の考慮事項を提供することである。本書は、ABAC の機能要素を記述するとともに、認証メカニズムやアイデンティティ管理のあらゆる側面を直接扱うことなく（注 1）、主体が信頼できるアイデンティティまたはアイデンティティプロバイダに結び付けられていることを前提として、大規模エンタープライズ内で ABAC を採用する際の論点集合を示す。焦点は ABAC の中核概念にあり、属性エンジニアリング／管理、アイデンティティ管理との統合、フェデレーション、状況認識（リアルタイムまたはコンテキスト）メカニズム、ポリシー管理、自然言語ポリシーからデジタルポリシーへの翻訳といったトピックを詳細には扱わない。ここで論じる考慮事項は包括的なものと見なすべきではない。ABAC 製品や技術を選定・展開する前に、ホスティング組織はこれらの考慮事項を、試験や第三者による製品レビューで補完すべきである。

本書は、これまで別々であった ABAC に関する多くの知見を統合し、利用可能な技術とベストプラクティスに基づく ABAC 実装の間のギャップを埋め、組織全体で一貫して適用できるガイドラインを提供することを目指す。ABAC システムの導入を検討中、導入計画中、または現在導入中の組織にとって、情報提供ガイドとして活用できる。

このガイダンスは、NISTIR 7316『アクセス制御システムの評価（Assessment of Access Control Systems）』[NIST7316]、NISTIR 7665『特権管理ワークショップ議事録（Proceedings of the Privilege Management Workshop）』[NIST7665]、NISTIR 7657『特権（アクセス）管理ワークショップ報告（A Report on the Privilege (Access) Management Workshop）』[NIST7657]、NISTIR 7874『アクセス制御システム評価指標のガイドライン（Guidelines for Access Control System Evaluation Metrics）』[NIST7874] に含まれる、アクセス制御（AC）システムのポリシー、モデル、性質の基本概念を拡張する。

1.2 想定読者

本書は、次の二つの特定の読者層のニーズに応えることを意図している。

  • アクセス制御の基礎的な概念を理解し、ABAC の一般的理解を求める人
  • アクセス制御の概念に精通し、ABAC の詳細な導入または運用情報を求めるアクセス制御の専門家や管理者

1.3 文書構成

本書の残りは以下のセクションと付録から成る：

  • セクション 2 は ABAC の基礎理解を提供する。論理的アクセス制御の現状、ABAC の作業定義、ABAC の中核および企業レベルの概念の説明を与える。読者は、セクション 2 を読むだけで ABAC 概念の一般的理解を得られる。
  • セクション 3 は、構想、調達／開発、実装／評価、運用／保守の各段階における、ABAC の企業導入に関する考慮事項を論じる。アクセス制御やプロジェクト管理に関心のある読者は、本セクションから最大の利益を得られるだろう。

注 1： [NIST800-63-3] および [NIST800-63B] を参照。

  • セクション 4 は本書を結語する。
  • 付録 A は ABAC に関連する各種の頭字語と略語を定義する。
  • 付録 B は本書の参考文献を列挙する。

IT 産業の性質が絶えず変化することから、読者には本書で参照したものを含む他のリソースも積極的に活用することを強く推奨する。

1.4 用語に関する注記

本書での用語は強制ではないが、文書内での一貫性を意図している。可能な限り、NIST 刊行物や連邦政府全体で使用されている用語を採用し、整合性を維持した。連邦政府やアイデンティティ／アクセス制御コミュニティにおいて、共通の概念に対して用語が一貫せず、または複数の用語が使用されている場合には、最も簡潔な用語と定義を適用した。

論理的客体（resource と呼ばれることもある）とは、不正使用から保護されるべきエンティティである。主体（subject）は、その客体に対して操作を実行しようとする要求主体を表す。主体は requestor と呼ばれることもある。

主体は多くの場合人間である。自律型サービスやアプリケーションのような非人間エンティティ（NPE: Non-Person Entity）も主体の役割を果たしうる。一般に、コンピュータによって実行されるあらゆる操作は、当該操作を実行する権限を持つ何らかの個人または組織（NPE の場合）に代わって実行されねばならない。本書では、客体へのアクセスを要求する人間または NPE を表す用語として「主体」を用いる。

主体には、氏名、生年月日、住所、訓練履歴、職務などの特性、すなわち属性があり、それらは個別または組み合わせにより、他のすべての人からその人物を区別する一意のアイデンティティを構成しうる。これらの特性はしばしば「主体属性」と呼ばれる。本書では一貫して「主体属性」という用語を用いる。

人は人生の中で、異なる組織で働き、異なるロールで活動し、それらのロールに紐づく異なる特権を継承することがある。人は、各組織またはロールごとに異なるペルソナを確立し、それぞれのペルソナに関する異なる属性を蓄積する場合がある。例えば、ある個人が平日は A 社でゲート警備員として勤務し、週末は B 社でシフトマネージャとして勤務しているかもしれない。各ペルソナにおける主体属性は異なる。A 社のゲート警備員として訓練・資格を有していても、週末に B 社のペルソナでシフトマネージャとして活動している間は、B 社のゲート警備員として職務を遂行する権限は有さない。

認証はアクセス制御や認可と同じではない。認証とは、主体が提示した識別子を使用することについて、信頼できるアイデンティティプロバイダ組織により主体が権限付与されていることを検証する行為である。一方、アクセス制御または認可は、主体にシステムの客体（ネットワーク、データ、アプリケーション、サービス等）へのアクセスを許可または拒否する判断である。ABAC は識別情報なしでも使用可能であり、認証方式は本書では扱わない点に留意されたい。本書では「アクセス制御」と「認可」という用語を同義に用いる。

特権（Privilege）は主体の認可された振る舞いを表し、権限主体により定義され、ポリシーや規則に具体化される。本書では、特権と認可という用語は同義であり、いずれも、ある者が一つ以上の客体にアクセスする権威と暗黙の承認を表すものとして用いる。

環境条件（Environment Conditions）は、主体や客体から独立した動的要因であり、判断時における属性としてアクセス判断に影響を与えるために使用されうる。環境条件の例には、時間、場所、脅威レベル、温度などがある。

ポリシー、規則、関係は、主体の特権と、どのような環境条件の下で資源または客体を保護するかに基づき、組織内の許容される振る舞いを統制する。本書では、これらの規則と関係を表現する用語として「ポリシー」を用いる。ポリシーは、保護を要する客体の観点から書かれることが一般的であり、主体に利用可能な特権を前提とする。

主体と同様に、各客体にもそれを記述・識別する一連の属性がある。これらの特性は「客体属性」と呼ばれ、resource attributes と呼ばれることもある。本書では一貫して「客体属性」という用語を用いる。客体属性は、参照によって、客体に埋め込むことによって、または暗号学的バインディングのような、その他の何らかの確実な結合手段によって、当該客体に結び付けられることが一般的である。注 2

ポリシーに関する情報（著者、ポリシーの発効日、競合解消方法等）は、メタポリシー（metapolicy）と呼ばれることがある。属性に関する情報（属性の権威、属性の作成日等）はメタ属性（metaattributes）と呼ばれることがある。メタポリシーとメタ属性は、ポリシー集合の作成や、認可に必要な適切な属性集合の識別に利用されうる。メタ属性の使用例として、属性にアシュアランスレベル（信頼度）を付与することが挙げられる。これは、属性の背景にある権威に対する信頼度、属性情報の鮮度、情報が検証される頻度に関する正確性レベルといった主観的評価を組み合わせた複合スコアであることがあり、場合によってはこれらの信頼度がアクセス判断の入力として用いられることもある。

これらのポリシーは、何らかのアクセス制御機構を通じて強制されなければならない。アクセス制御機構は、保護対象の客体に関する情報、アクセスを要求する主体に関する情報、資源へのアクセスを統制するポリシー、判断に必要なあらゆるコンテキスト情報など、認可に関する情報を収集する必要がある。各ポリシー要素を入手可能な情報と照合して評価することにより、アクセス制御機構はしばしば、判断を下すポリシー決定点（PDP）、判断を強制するポリシー執行点（PEP）、判断に必要な属性の収集を管理するコンテキストハンドラまたはワークフローコーディネータといった機能を備える。本書では、これらすべての機能を包含する概念として「アクセス制御機構」という用語を想定し、一貫して用いる。

注 2：暗号学的バインディングは、よく知られた暗号手法を用いて、データおよびデータ間関係の完全性と真正性を提供するための方法論である。暗号学的バインディングは、特定の客体に関連付けられた各客体属性のハッシュ値を求め、それらハッシュ値の集合に電子署名を施すことによって機能する。客体にアクセスする際に客体の署名が検証に失敗した場合、どの要素が最後のバインディング以降に改変されたかを特定するため、属性のハッシュ値が比較される。

2. ABAC の理解

ABAC を十分に理解するためには、論理的アクセス制御の基本原理を理解する必要がある。論理的アクセス制御の目的は、データ、サービス、実行可能アプリケーション、ネットワーク機器、その他の情報技術のいずれであっても、客体を不正な操作から保護することにある。これらの操作には、発見、読み取り、作成、編集、削除、実行が含まれる。客体は個人または組織が所有しており、その所有者が保護する動機を持つ何らかの固有の価値を有する。所有者は客体の所有者として、どの主体が、どの操作を、どのような状況で実行できるかを述べるポリシーを定める権限を有する。主体が客体の所有者により定められたアクセス制御ポリシーを満たす場合、その主体は当該客体に対して望む操作を実行する権限が与えられる—すなわち客体へのアクセスが許可される。主体がポリシーを満たさない場合は、客体へのアクセスは拒否される。

コンピュータセキュリティのアーキテクトや管理者は、主体からの要求を仲介することで客体を保護するように論理を組んだアクセス制御機構（ACM）を展開する。これらの ACM は、当該客体に適用されるアクセス制御ポリシーを執行するために、さまざまな方法を利用できる。ACM は次のように定義できる：

アクセス制御機構（ACM）：主体からアクセス要求を受け取り、判断し、その判断を強制するための論理コンポーネント。

これらの ACM の動作は、さまざまな論理的アクセス制御モデルの観点から記述できる。アクセス制御モデルは、客体、主体、操作、規則を組み合わせてアクセス制御判断を生成・執行するための枠組みと境界条件を提供する。各モデルには固有の長所と制約があるが、ABAC モデルの柔軟性と適用性を十分に理解するためには、これらモデルの発展の経緯を理解することが重要である。

MAC/DAC

論理的アクセス制御の初期の応用は、1960 ～ 1970 年代の国防総省（DoD）アプリケーションにおいて、任意アクセス制御（DAC）と強制アクセス制御（MAC）の概念の登場とともに見られた。これらの用語は、DoD Trusted Computer System Evaluation Criteria（TCSEC）または「オレンジブック」[TCSEC] においてさらに定義されている。DAC と MAC の定義は [NIST800-53] にも記載がある。

IBAC/ACL

ネットワークが拡大するにつれ、特定の保護された客体へのアクセスを制限する必要性が、アイデンティティベースアクセス制御（IBAC）機能の発展を促した。IBAC は、アクセス制御リスト（ACL）のような機構を用いて、当該客体へのアクセスが許可される者の同一性を記録する。主体が ACL に記録されたものと一致する資格情報を提示した場合、主体は客体へのアクセスを許可される。主体が実行できる個別の操作（読み取り、書き込み、編集、削除など）の特権は、客体の所有者が個別に管理する。各客体は、独自の ACL と、各主体に割り当てられた特権の集合を必要とする。IBAC モデルでは、認可判断は特定のアクセス要求の前に行われ、その結果として主体が ACL に追加される。各主体を ACL に追加するため、客体の所有者は、客体を統制するポリシーに照らして、同一性・客体・コンテキストの属性を評価し、主体を ACL に追加するかどうかを決定しなければならない。この決定は静的であり、所有者が、主体・客体・コンテキストの変更を反映するため主体を ACL から再評価し、場合によっては削除するための通知プロセスが必要となる。時間の経過とともに削除または権限剥奪が行われないと、ユーザが特権を蓄積してしまう。

RBAC

ロールベースアクセス制御（RBAC）モデル [FK92, ANSI359, SCFY96] は、特定の特権セットを有する事前定義のロールを用い、主体はこれらのロールに割り当てられる。例えば、マネージャのロールに割り当てられた主体は、アナリストに割り当てられた者とは異なる客体集合にアクセスできる。このモデルでは、アクセスは、個々人にロールを割り当てる者により暗黙に、また、各ロールに関連付けられる特権を決定する際の客体の所有者により明示的に、あらかじめ決定される。アクセス要求時点では、アクセス制御機構が、アクセスを要求する主体に割り当てられたロールと、そのロールが当該客体に対して実行することを認可された操作集合を評価して、アクセス判断を下し、執行する。ロールは、アクセス制御機構によって評価され、その周辺で客体アクセスのポリシーが生成される主体属性と見なすことができる。RBAC 仕様が普及するにつれ、企業のアクセス制御機能の集中管理が可能となり、ACL の必要性が低減された。

ABAC

ACL と RBAC は、用いられる属性の観点では、ある意味で ABAC の特殊例である。ACL は「同一性」という属性で機能し、RBAC は「ロール」という属性で機能する。ABAC の主要な相違点は、複雑な真偽値規則集合を表現し、さまざまな属性を評価できるポリシーの概念にある。ACL や RBAC を用いて ABAC の目的を達成することは可能だが、アクセス制御要件への適合性を実証することは、ACL や RBAC モデルと要件との間に必要な抽象化レベルのため、困難かつ高コストになりがちである。ACL または RBAC モデルのもう一つの問題は、アクセス制御要件が変更された場合に、ACL または RBAC の実装のどの部分を更新する必要があるのか特定することが難しくなりうる点である。

ABAC と整合的なアクセス制御フレームワークの一例が、Extensible Access Control Markup Language（XACML）[XACML] である。XACML モデルは、規則、ポリシー、規則／ポリシー結合アルゴリズム、属性（主体、（リソース）客体、アクション、環境条件）、義務（obligations）、助言（advice）といった要素を用いる。その参照アーキテクチャには、ポリシー決定点（PDP）、ポリシー執行点（PEP）、ポリシー管理点（PAP）、ポリシー情報点（PIP）といった機能が含まれ、アクセスを統制する。もう一つの例として、Next Generation Access Control 規格 [ANSI499] がある。

一般に、ABAC では、（操作／客体の）能力を、要求前に要求者である主体やそのロール／グループに直接割り当てる必要がない。代わりに、主体がアクセスを要求すると、ABAC エンジンは、要求者に割り当てられた属性、客体に割り当てられた属性、環境条件、およびそれらの属性と条件で記述されたポリシーの集合に基づいて、アクセス制御判断を行うことができる。この枠組みでは、ポリシーは数多くのユーザや客体を直接参照することなく作成・管理でき、ユーザや客体はポリシーを参照することなくプロビジョニングできる。

2.1 ABAC の利点（The Benefit of ABAC）

多くの AC システムでは、論理的アクセス制御の解決策は、ある主体がある客体に対して（例：ファイルに対して）ある操作（例：読み取り）を実行することを要求する際の主体の同一性に主として基づいてきた。例としては、IBAC や RBAC があり、そこでは客体へのアクセスが、ローカルに特定された主体に対して個別に付与される場合や、主体が所属するローカルに定義されたロールに対して付与される場合がある。この AC アプローチは、管理がしばしば煩雑である。以下の図 1 に示す非 ABAC の複数組織間アクセス手法の例では、主体の出自組織の外にある客体に対する認証済みアクセスを行うには、対象組織において主体の同一性を事前プロビジョニングし、アクセスリストに事前登録しておく必要がある。

image

図 1：従来型（非 ABAC）の複数組織間アクセス方法

さらに、同一性やロールといった主体の限定子は、現実世界の AC ニーズを表現する上で不十分であることが多い。RBAC は主体のロールとの関連に基づいて判断を行う。RBAC は、多要素の判断（たとえば物理的位置に依存する判断や、医療保険の相互運用性と説明責任に関する法律（HIPAA）の記録アクセスのような専門的訓練に依存する判断—医療記録を閲覧する前提条件として最近の HIPAA データ保護訓練が求められる場合がある）を容易にはサポートしない。RBAC のロール割り当ては、より静的な組織上のポジションに基づく傾向があり、動的なアクセス制御判断が必要となる特定の RBAC アーキテクチャでは課題となる。こうした種類のアクセス制御判断を実装しようとすると、アドホックで構成員が限定的な多数のロールを作成する必要が生じ、しばしば「ロール爆発」と呼ばれる事態につながる。

主体による客体の事前知識や、客体所有者による主体の知識なしに AC 判断を行う方法が必要である。組織間で一貫して定義された主体属性と客体属性という概念に依拠することで、ABAC は、客体に対する操作要求の前に個々の主体に明示的な認可を直接割り当てる必要を回避する。さらに、このモデルは、アクセス制御リストやロール／グループの管理が時間を要し複雑になる大規模エンタープライズにおいて柔軟性を実現する。一貫して定義された属性を主体と客体の双方にまたがって活用することにより、認証および認可の活動は、適切なセキュリティ水準を維持しつつ、同一または別個のインフラストラクチャで実行・管理することができる。

2.2 ABAC の作業定義（A Working Definition of ABAC）

ABAC は様々な形で記述されてきた。例えば、ウェブサービスに関する初期の論文では、ABAC は「要求者が保有する属性に基づいてサービスへのアクセスを許可する」ものとされている [WWJ04]。また、地理情報システムのセキュリティに関する論考では、ABAC は「ユーザに関連付けられた属性値が、ユーザと特権との関連を決定する」アプローチとして記述されている [CGLO09]。

別の論文では、ABAC を「主体、客体、環境の属性に基づき、強制アクセス制御と任意アクセス制御の両方のニーズを支援する」モデルと要約している [YT05]。これらおよび他の定義においては、ABAC がアクセス（すなわちシステム客体に対する操作）を、主体属性、客体属性、環境条件の現在値を、アクセス制御規則に指定された要件と照合することで決定する、という点に合理的な合意がある。以下に ABAC の高水準の定義を示す。

属性ベースアクセス制御（ABAC）：主体が客体に対して操作を実行する要求に対し、主体に割り当てられた属性、客体に割り当てられた属性、環境条件、そしてそれらの属性と条件で表現されたポリシーの集合に基づいて許可または拒否を行うアクセス制御方式。

属性（Attributes）とは、主体、客体、または環境条件の特性である。属性は名前—値の組で与えられる情報を含む。

主体（Subject）とは、人間のユーザまたは NPE（デバイスなど）であり、客体に対して操作を実行するアクセス要求を発行する。主体には 1 つ以上の属性が割り当てられる。本書では、便宜上、subject と user は同義とみなす。

客体（Object）とは、ABAC システムによりアクセスが管理されるシステム資源であり、デバイス、ファイル、レコード、テーブル、プロセス、プログラム、ネットワーク、情報を含むまたは受け取るドメイン等が含まれる。主体が操作を実行しうる対象（データ、アプリケーション、サービス、デバイス、ネットワークを含む）や、要求されたエンティティ自体を指しうる。

操作（Operation）とは、主体の要求により客体に対して関数を実行することをいう。操作には、読み取り、書き込み、編集、削除、コピー、実行、変更が含まれる。

ポリシー（Policy）とは、主体・客体・場合によっては環境条件の属性値が与えられたとき、要求されたアクセスを許可すべきかどうかを判断可能にする規則または関係の表現である。

環境条件（Environment conditions）：アクセス要求が発生する運用上または状況上のコンテキスト。環境条件は検出可能な環境の特性であり、主体や客体から独立している。現在時刻、曜日、ユーザの所在、現在の脅威レベルなどが含まれうる。

この高水準の ABAC 定義は図 2 に示されている。ここでは ABAC の ACM が主体のアクセス要求を受け取り、主体と客体の属性を特定のポリシーに照らして評価する。ACM はその後、主体が客体に対してどの操作を実行できるかを決定する。

  1. 主体が客体へのアクセスを要求する
  2. アクセス制御機構が a) 規則、b) 主体属性、c) 客体属性、d) 環境条件 を評価して判断を算出する
  3. 許可される場合、主体に客体へのアクセスが付与される

image

図 2：ABAC の基本シナリオ

2.3 ABAC の基本概念（Basic ABAC Concepts）

最も基本的な形の ABAC は、主体の属性、客体の属性、環境条件、および主体—客体の属性の組み合わせに対して許容される操作を定義する形式的な関係またはアクセス制御規則／ポリシーの評価に依拠する。あらゆる ABAC ソリューションは、これらの基本的中核能力—属性を評価し、それらの属性間の規則または関係を執行する能力—を備えている（下図 3 参照）。

image

図 3：ABAC の中核機構

小規模で孤立したシステム内であっても、ABAC は、主体と客体への属性の割り当て、およびアクセス規則を含むポリシーの策定に依拠する。システム内の各客体には、その客体を特徴付ける特定の客体属性を割り当てなければならない。所有者のように客体インスタンス全体に関わる属性もあれば、客体の一部にのみ適用される属性もある。例えば、ある文書オブジェクトが A 組織に所有され、B 組織の知的財産を含むセクションを持ち、C 組織が運営するプログラムの一部である、といったことがあり得る。別の例として、ファイル管理システム内のディレクトリに格納された文書を考える。この文書には、タイトル、著者、作成日、最終編集日といった、作成者・著者・編集者によって決まる客体属性がある。さらに、所有組織、知的財産の特性、輸出管理区分、セキュリティ区分といった客体属性を付与できる。新しい文書が作成または変更されるたびに、これらの客体属性は捕捉されなければならない。これらの客体属性は文書自体に埋め込まれることが多いが、別表に記録したり、参照により組み込んだり、別のアプリケーションで管理したりする場合もある。

システムを利用する各主体にも特定の属性を割り当てる必要がある。ファイル管理システムにアクセスするユーザの例を考える。管理者によって当該ユーザはシステム内の主体として確立され、そのユーザに関する特性が主体属性として捕捉される。この主体には、氏名、ロール、所属組織があるかもしれない。他にも、米国人（US Person）かどうか、国籍、セキュリティクリアランスといった主体属性がありうる。これらの主体属性は、ファイル管理システム向けの主体アイデンティティ情報を維持する組織内の権威によって付与・管理される。新規ユーザの追加、既存ユーザの離脱、主体の特性の変化に伴い、これらの主体属性は更新が必要になることがある。

システム内のすべての客体には、その客体に対して許容される主体・操作・環境条件を定義する少なくとも 1 つのポリシーが必要である。このポリシーは通常、組織内の業務プロセスや許容される行為を記述する文書化された規則または手順に由来する。例えば病院では、「許可された医療従事者のみが患者の医療記録にアクセスできる」といった規則があるかもしれない。あるシステムでは、客体が「患者医療記録」という記録タイプ属性を持つ文書である場合、「医療記録規則」が選択・処理され、読み取り操作を試みる「非医療サポート職」という人員区分属性の主体はアクセスを拒否され、操作は不許可となる。このように、属性と規則の結び付けを実装する方法は一つではない点に注意されたい。

主体属性と客体属性を結び付ける規則は、（どの主体が、どの客体に対して、どの操作を行えるかという）特権を間接的に特定する。許容操作の規則は、次のような多様な計算言語の形式で表現できる。

  • 特定の操作の認可条件を満たす、属性と条件のブール結合
  • 主体属性と客体属性および許容操作を関連付ける関係の集合

客体属性、主体属性、ポリシーが整備されれば、ABAC を用いて客体を保護できる。アクセス制御機構は、許容主体による許容操作にアクセスを限定することで客体へのアクセスを仲介する。ACM はポリシー、主体属性、客体属性を収集し、ポリシーの論理に基づいて判断を下し、執行する。ACM は、どのポリシーを取得すべきか、どの属性をどの順序でどこから取得すべきかといった、判断の作成と執行に必要なプロセスを管理できなければならない。その上で、判断を下すために必要な計算を実行する必要がある。

ABAC モデルで実装可能なポリシーは、計算言語の制約と利用可能な属性の豊富さによってのみ制限される。この柔軟性により、各主体と各客体の個別の関係を明示せずとも、最大限広範な主体が最大限広範な客体にアクセスできる。例えば、主体は雇用時に主体属性の集合が付与される（例：「Nancy Smith は循環器科の看護師（Nurse Practitioner）である」）。客体は作成時に客体属性が付与される（例：「心臓疾患患者の医療記録のフォルダ」）。指定された権限主体が、許容操作の集合を統制する規則を作成する（例：「循環器科のすべての看護師は心臓疾患患者の医療記録を閲覧（View）できる」）。さらに柔軟性を高めるため、属性およびその値は、主体・客体・属性のライフサイクル全体にわたって変更できる。

どの操作が実施できるかを指定する一連の規則に従って、主体と客体に属性をプロビジョニングすることにより、客体所有者や規則作成者が特定の主体を事前に把握していなくても、無制限の数の主体が客体に対する操作を実行できる。新しい主体が組織に加わっても、規則や客体を変更する必要はない。必要な客体へのアクセスに必要な属性が主体に付与されている限り（例：循環器科のすべての看護師にその属性が付与されている）、既存の規則や客体属性の変更は不要である。この利点はしばしば「外部（想定外）ユーザの取り込み」能力と呼ばれ、ABAC を採用する主要な利点の一つである。

他の方式と異なり、ここで示す ABAC の定義では、操作自体には「属性」がない。定義上、「属性は名前—値の組で与えられる情報を含む」。例えば「read = all」（または「all = read」）のような表現は適切ではない。操作には多様なタイプや分類があり得るが、それらは「属性」ではなく固定的な値の集合である。操作そのものを「属性名」にして「operation

read」とすることも理論上は可能だが、そうすると操作に関する属性はそれのみとなり、冗長である。

アカウンタビリティ要件を満たすため、特定のユーザに紐付く特定の主体による客体へのアクセスを追跡する必要がある。もしアクセス判断が属性に基づいて行われ、主体またはユーザ ID が個々のアクセス要求や判断に紐付けて追跡されない場合、アカウンタビリティが損なわれ得る。

2.4 エンタープライズ ABAC の概念（Enterprise ABAC Concepts）

ABAC は情報共有の促進要因だが、エンタープライズ全体に展開されると、ABAC を実装するために必要な構成要素の集合はより複雑になる。エンタープライズレベルでは、規模の拡大に伴い、ポリシーと属性の一貫した共有・利用、ならびにアクセス制御機構の統制された配布と運用を確保するために、複雑で場合によっては独立に確立された管理能力が必要となる。本書における「エンタープライズ」の定義は次のとおりである。

エンタープライズ（Enterprise）：情報共有が必要であり管理される、エンティティ間の協働またはフェデレーション。

下図 4 は、エンタープライズ ABAC を可能にするために必要な主要コンポーネントの例を示す。エンタープライズによっては、ABAC 実装に活用できる既存の機能がある。例えば、多くのエンタープライズは、氏名、一意識別子、ロール、クリアランスなどの主体属性の母集団を管理するための、何らかのアイデンティティおよびクレデンシャル管理を持っている。同様に、多くのエンタープライズは、主体のエンタープライズ客体へのアクセスを認可する規則を定める組織ポリシーやガイドラインを持っている場合がある。しかし、これらの規則は通常、すべてのアプリケーションに一貫して統合できる機械執行可能な形式で書かれてはいない。ABAC のポリシーは機械執行可能な形式で利用可能にし、リポジトリに保存し、ACM が利用できるよう公開しなければならない。これらのデジタルポリシーには、アクセス制御判断を下すために必要な主体属性と客体属性が含まれる。エンタープライズの主体属性は、主体属性管理機能を通じて、エンタープライズ内の組織間で作成・保存・共有されなければならない。同様に、エンタープライズの客体属性は確立され、客体属性管理機能を通じて客体に結び付けられなければならない。この時点で、ABAC 対応のアクセス制御機構を展開する必要がある。本節の残りでは、エンタープライズ ABAC のこれら主要コンポーネントそれぞれの詳細を述べる。

image

図 4：エンタープライズ ABAC のシナリオ例

2.4.1 エンタープライズ ABAC ポリシー（Enterprise ABAC Policy）

自然言語ポリシー（NLP）は、情報アクセスがどのように管理され、誰がどのような状況でどの情報にアクセスできるかを定める高位の要件である。NLP は人間が理解可能な用語で表され、ACM で直接実装できない場合がある。NLP は曖昧な場合があり、形式的に実行可能な要素に落とし込むのが難しいため、エンタープライズポリシーを機械執行可能な形に符号化するのが難しいことがある。NLP はアプリケーション固有でありうるためアプリケーションシステムによって考慮され得る一方で、複数アプリケーションにまたがる主体の行為に関わることも同様にあり得る。例えば、NLP は組織単位内外での客体の利用に関するもの、または知る必要性（need-to-know）、能力、権限、義務、利益相反といった要因に基づくものかもしれない。この種のポリシーは、複数のコンピューティングプラットフォームとアプリケーションにまたがり得る。本書における NLP の定義は次のとおりである。

自然言語ポリシー（NLP）：エンタープライズ客体の管理とアクセスを統治する記述。NLP は、機械執行可能なアクセス制御ポリシーへ翻訳し得る、人間による表現である。

エンタープライズ内の各組織において関連する NLP が存在すると仮定すると、次のステップは、それらをエンタープライズ中の ACM 内で等しく一貫して執行できる共通の規則集合に翻訳することである。そのためには、必要となる主体／客体の属性の組み合わせと許容操作をすべて特定する必要がある。これらの値は組織ごとに異なることが多く、エンタープライズ相互運用性を確保するために、各組織の既存属性に対する合意形成やマッピングが必要になる場合がある。合意された主体属性および客体属性の一覧、許容操作、そして既存の組織固有属性からのすべてのマッピングは、機械執行可能な形式に翻訳される。

NLP はデジタルポリシー（DP）のアルゴリズムや機構に符号化されなければならない。性能の効率と記述の簡潔さのため、NLP は、エンタープライズ内の運用単位のインフラに適合するよう、異なる DP へ分解・翻訳を要する場合がある。本書における DP の定義は次のとおりである。

デジタルポリシー（DP）：機械実行可能なコードまたはシグナルへ直接コンパイルされるアクセス制御規則。主体／客体属性、操作、環境条件は DP の基本要素であり、DP 規則の構成要素であって、アクセス制御機構により執行される。

複数の DP には、DP の階層的権限、DP の競合解消、DP の保管・更新を扱うため、DP の使用と管理を規定するメタポリシー（MP）が必要となることがある。MP は DP の管理に用いられる。複雑性の水準に応じて、NLP が規定する優先順位や結合戦略の構造に基づき、階層的 MP が必要になることがある。本書における MP の定義は次のとおりである。

メタポリシー（MP）：ポリシーに関するポリシー、すなわち、DP や他の MP 間の優先順位付けや競合解消など、ポリシーの管理のためのポリシー。

DP と MP が作成されると、それらは管理・保存・検証・更新・優先順位付け・競合解消・共有・廃止・執行される必要がある。これらの各操作には、しばしばエンタープライズ全体に分散される一連の機能が必要であり、総称してデジタルポリシー管理（DPM）と呼ぶ。組織内には、エンタープライズポリシーに変種を持つ複数のポリシー権限および階層が存在し得る。DP と MP の管理方法の規則は中央の権限により定められることがある。

適切な DP の定義と作成は、アクセス制御判断を下すために必要な主体属性と客体属性の特定にとって極めて重要である。DP の記述は、許容操作の集合を満たすために必要な主体属性と客体属性の組み合わせ、ならびに環境条件から構成されることを想起されたい。特定のエンタープライズ客体集合について、許容操作の全集合を満たすために必要な主体属性と客体属性の完全な集合が特定されると、この属性集合こそが、エンタープライズ ABAC のアクセス判断において定義・割り当て・共有・評価されるべき全属性集合となる。このため、エンタープライズ ABAC を実装する際には、属性の支援を受けつつ NLP と DP を特定することが不可欠である。DP 管理に関する追加の考慮事項は本書セクション 3 を参照されたい。

2.4.2 エンタープライズ ABAC における属性管理（Attribute Management in Enterprise ABAC）

次に、NLP と DP を検討する中で作成された属性の一覧を考える。十分な客体属性と主体属性の集合がなければ、ABAC は機能しない。属性には名前を付し、定義し、許容値の集合を与え、スキーマを割り当て、主体と客体に関連付ける必要がある。主体属性は、権威の下で確立・発行・保存・管理されなければならない。客体属性は、客体に割り当てられなければならない。組織間で共有される属性は、所在特定、取得、公開、検証、更新、変更、失効が可能でなければならない。

主体属性は属性当局によってプロビジョニングされる—通常、提供される属性の種類について権威を持ち、属性管理点を通じて管理される。しばしば複数の当局が存在し、それぞれが異なる属性についての権威を有する。例えば、クリアランス属性についてはセキュリティ部門が権威であり、氏名属性については人事部門が権威である場合がある。一つの組織の主体が他組織の客体にアクセスできるように主体属性を共有する必要がある場合、同等のポリシーを執行できるよう、主体属性は一貫しており、比較可能であるか、またはマッピングされていなければならない。例えば、A 組織のメンバーが Job Lead というロールを持ち B 組織の情報にアクセスしたいが、B 組織では同等のロールを Task Lead という用語で表しているような場合である。この問題は、エンタープライズ属性スキーマとアプリケーション固有スキーマの間のマッピングにも当てはまる。特に、エンタープライズスキーマの定義前に構築されたスキーマや、独自スキーマを備えた市販既製品（COTS）において顕著である。組織は主体属性名と値を正規化するか、全組織について同等語のマッピングを維持すべきである。これは中央の権威によって管理されるべきである。

客体属性は、客体が作成・変更される際に確立・維持・割り当てられる必要がある。エンタープライズ全体で共通の客体属性集合を用いることが必須でない場合でも、客体属性はエンタープライズのポリシー要件を満たすために一貫して用いられるべきであり、利用可能な客体属性の集合は、客体に属性をマーク／タグ付けすることを望む者に公開されるべきである。時には、アクセス要求を満たすために客体属性が改ざん・変更されないことを確保する必要がある。客体は、自身の客体属性と暗号学的にバインドされ、客体または対応する属性が不適切に変更されていないかを識別できるようにすることができる。すべての客体が作成される際に、ACM が用いるポリシーを満たすために適切な客体属性集合が割り当てられるよう、メカニズムを展開しなければならない。こうした要件を調整するために、エンタープライズ客体属性管理者が必要になる場合がある。

属性を管理する過程では、「メタ属性（metaattributes）」—すなわち属性の特性—という概念が生じる。メタ属性は、属性に関する拡張情報として主体・客体・環境条件に適用され、属性に関する情報を取り込むより詳細なポリシーの執行や、エンタープライズ属性管理に必要なデータ量の管理に有用である。本書におけるメタ属性の定義は次のとおりである。

メタ属性（Metaattributes）：ACM 内で MP および DP の処理を実装するために必要となる、属性に関する情報。

属性管理に関する追加の考慮事項は本書セクション 3 を参照されたい。

2.4.3 エンタープライズ ABAC におけるアクセス制御機構の分散（Access Control Mechanism Distribution in Enterprise ABAC）

最後に、エンタープライズ全体における ACM の分散と管理を考える。ユーザのニーズ、エンタープライズの規模、資源の分散状況、アクセス・共有が必要な客体の機微性に応じて、ACM の分散は ABAC 実装の成否にとって極めて重要になり得る。ACM の機能コンポーネントは、システムレベルでの ABAC の集中型の見取り図とは異なり、エンタープライズ内で物理的・論理的に分離・分散される場合がある。

ACM 内には、ポリシーの取得と管理のためのサービスノードとなるいくつかの機能「ポイント」と、ポリシーや属性の取得・評価のコンテキストやワークフローを扱う論理コンポーネントがある。図 5 は主要な機能ポイント、すなわちポリシー執行点（PEP）、ポリシー決定点（PDP）、ポリシー情報点（PIP）、ポリシー管理点（PAP）を示す。これらのコンポーネントがある環境では、アクセス制御判断とポリシー執行を提供するために連携して機能しなければならない。

image

図 5：ACM の機能ポイントの例

PDP は DP と MP に対して評価を行い、アクセス制御判断を生成する。PDP と PEP は本書で次のように定義される。

ポリシー決定点（PDP）：適用可能な DP と MP を評価してアクセス判断を算出する。PDP の主要機能の一つは、MP に従って DP を仲裁または競合解消することである。

PEP は PDP によって下された判断を執行する。

ポリシー執行点（PEP）：保護対象の客体へのアクセスを要求する主体からの要求に応じて、PDP が下したポリシー判断を執行する。

PDP と PEP の機能は分散または集中させることができ、物理的・論理的に相互を分離できる。例えば、エンタープライズは、属性とポリシーを評価して判断を下し、その判断を PEP に渡す、集中管理されたエンタープライズ決定サービスを設けることができる。これにより、主体属性とポリシーの中央管理・統制が可能になる。あるいは、エンタープライズ内のローカル組織が、集中型の DP ストアを参照する個別の PDP を実装することもできる。ACM コンポーネントの設計と分散には、ABAC 機能の調整を確実にするための管理機能が必要である。

アクセス判断を算出するには、PDP は属性に関する情報を持っていなければならない。この情報を提供するのが PIP である。PIP は次のように定義される。

ポリシー情報点（PIP）：PDP が判断を行うために必要な情報を提供するべく、属性またはポリシー評価に必要なデータの取得元として機能する。

これらのポリシーを執行する前に、意図したニーズを満たしていることを徹底的に試験・評価しなければならない。この役割を担うのが PAP である。PAP は次のように定義される。

ポリシー管理点（PAP）：DP および MP を作成・管理・試験・デバッグし、適切なリポジトリに保存するためのユーザインタフェースを提供する。

最後に、ACM 内の任意の追加コンポーネントとして、コンテキストハンドラが、ポリシーと属性の取得順序を管理する。これは、時間制約が厳しい、または接続性が限定された状況でアクセス制御判断を行う必要がある場合に重要になり得る。例えば、アクセス要求の前に属性を取得したり、アクセス要求時の取得に伴う遅延を避けるために属性をキャッシュしたりできる。コンテキストハンドラはまた、PIP と連携してリクエストコンテキストに属性値を追加し、（例：XACML のような）標準形式の認可判断を、ネイティブの応答形式へ変換する。コンテキストハンドラは次のように定義される。

コンテキストハンドラ（Context Handler）：ポリシーと属性をどの順序で取得・執行するかというワークフロー論理を実行する。

3. ABAC のエンタープライズ導入に関する考慮事項（ABAC Enterprise Considerations）

エンタープライズ全体に ABAC システムを展開する前に考慮すべき要因は多数ある。本セクションでは、今日までの技術動向に基づく利用可能なガイドラインを統合し、連邦政府における大規模エンタープライズ全体で ABAC 機能を展開しようとした複数の試みから得られた教訓を扱う。ガイドラインは、図 6 に示す NIST のシステム開発ライフサイクル（SDLC）の各段階に沿って提示する。各段階の定義と想定アウトプットに関する一般的情報は [NIST800-100] を参照のこと。エンタープライズ ABAC の導入に関する考慮事項の大半は、最初の 4 段階—構想（Initiation）、調達／開発（Acquisition/Development）、実装／評価（Implementation/Assessment）、運用／保守（Operations/Maintenance）—に含まれる。本セクションでは、それらの段階に限定して焦点を当てる。

image

図 6：ACM における NIST システム開発ライフサイクル（SDLC）

エンタープライズ ABAC 機能の開発と展開には、その設計、セキュリティ、相互運用性に影響する多くの要因を慎重に検討する必要がある。これらの要因は、次のような検討すべき設問群につながる。

  • ABAC 実装のビジネスケースを確立する。 新機能の開発／調達や既存機能からの移行に要するコストは何か。ABAC により得られる重要な便益は何か。ABAC によって新たに導入されるリスクがある場合、それは何か。また、共有機能や、これまでは人手を介して行っていた判断に基づくポリシー文書を管理するために、どのような新たなガバナンス構造が必要か。どのデータセット、システム、アプリケーション、ネットワークに ABAC 機能が必要か。データ損失やデータの不正利用に対する責任はどのように管理するか。
  • 運用要件とエンタープライズ全体のアーキテクチャを理解する。 特権はどのように管理・監視・コンプライアンス検証されるか。情報共有のためにエンタープライズが公開するインタフェースと客体は何か。どの ACM を使用するか。主体属性と客体属性はどのように共有・管理されるか。アクセス制御規則は何であり、どのように収集・評価・執行されるか。エンタープライズ内の信頼はどのように管理されるか。
  • ABAC を支える業務プロセスを確立または洗練する。 アクセス規則とポリシーは十分に理解され文書化されているか。必要な属性はどのように特定・割り当てられるか。複数のポリシーはどのように階層で適用・競合解消されるか。アクセス失敗はどのように扱うか。新しいポリシーは誰が作成するか。共通ポリシーはどのように共有・管理されるか。
  • 相互運用可能な機能セットを開発・調達する。 相互運用性はどのように達成するか。アイデンティティ管理からの主体属性はどのように ABAC に統合するか。多様または特殊なアイデンティティ要件にはどのように対応するか。主体属性はエンタープライズの各組織間でどのように共有・維持されるか。認証・認可・属性管理・判断・執行機能を集中させるか分散させるか、そのトレードオフは何か。環境条件はアクセス判断でどのように使用されるか。セキュリティ・品質・正確性に関する確信度はどのように測定・伝達・アクセス判断で利用されるか。主体属性は組織間でどのようにマッピングされるか。主体・客体・環境条件の利用可能な属性の最新集合を取り込むために、ポリシーはどのように策定されるか。
  • 性能を評価する。 切断環境や帯域・資源が限られたユーザ向けに主体属性はどのように管理するか。エンタープライズの新規参加者に対してインタフェース仕様はどの程度利用可能か。属性とポリシーの変更の品質とタイムリーさはどのように測定・徹底するか。システム全体およびエンドツーエンドの性能は十分か。

以下の各節では、これらの原則と設問をより詳しく扱う。

3.1 構想段階の考慮事項（Initiation Phase Considerations）

構想段階では、組織は ABAC システムの必要性とその潜在的用途を評価する。ABAC システムが独立した情報システムになるのか、既に定義済みのシステムのコンポーネントになるのかを決定すべきである。これらの作業を完了し、ABAC 機能の必要性が認められたら、ABAC システムが承認される前に、目標を明確化し高位要件を定義することを含む、いくつかのプロセスを実施しなければならない。この段階では、ABAC システムの高位のビジネス要件と運用要件、およびエンタープライズアーキテクチャを定義する。

image

3.1.1 ABAC 機能導入のビジネスケースの構築（Building the Business Case for Deploying ABAC Capabilities）

他の主要システム導入と同様に、エンタープライズ ABAC 機能の導入に先立っては、要件評価、トレードスタディ、計画活動を十分に行い、アプリケーション群を前提として ABAC が必要かつ実現可能な種類のアクセス制御機能かどうかを判断すべきである。ABAC は、主体に関する事前知識や情報がなくてもアクセスを提供でき、ミッション／ビジネス上重要な限られた客体集合に関する大規模なエンタープライズ情報共有を可能にするという利点を持つ。

技術要件を作成したり導入判断を下したりする前に、ABAC 機能導入のビジネスケースを評価・確立し、これらの機能が対象とするエンタープライズの範囲を定義することが重要である。エンタープライズ ABAC には、開発・実装・運用の相当なコストに加え、エンタープライズの客体の共有と保護の方法に変化をもたらす。ABAC 導入の計画には、他組織の事例研究や経験報告が役立つ場合がある。現実的には、段階的アプローチを採り、限定された客体集合に対して ABAC による保護を実装する方がよいこともある。この実装では、可能な限り最大限、エンタープライズ全体に適したポリシーと属性を確立・活用する。段階的に ABAC 機能を拡張することで得られるフィードバックは、ポリシーと属性の定義を洗練し、エンタープライズ全体で ABAC の広範な利用を支えるガバナンスおよび構成管理機能を鍛えるだろう。以下の小節で述べる論点に対処しない場合、ABAC 導入に大幅な遅延と追加コストが生じ得る点に留意されたい。

3.1.2 スケーラビリティ、実現可能性、性能要件（Scalability, Feasibility, and Performance Requirements）

ABAC 製品や技術の導入を検討する際には、スケーラビリティ、実現可能性、性能が重要な論点である。エンタープライズ ABAC—同一エンタープライズ内で、ある組織が別組織の管理する許可客体へアクセスできるようにすること—には、ABAC コンポーネント間の複雑な相互作用が必要である。これらのコンポーネントは、しばしば組織境界を越え、時には異なるネットワーク上に分散配置される。エンタープライズが大規模で多様であるほど、これらの相互作用は複雑になる。リポジトリ中の文書への単純なアクセス要求が、エンタープライズサービスへのポリシー要求、論理的・物理的に分散した多数の属性ソースからの複数属性取得、文書にバインドされた客体属性の完全性に関する第三者検証、そしてエンタープライズ内の一箇所でなされた判断を別の箇所で執行するといった処理を必要とするかもしれない。実現可能性の評価では、アプリケーションが ABAC をネイティブに、またはサードパーティ製アプリケーションを通じてサポートできるかを確認すべきである。これらの相互作用はすべて、エンタープライズ ABAC 実装を通じて共有可能な客体の範囲を決める際に評価すべき性能コストを伴う。潜在的な性能・スケーラビリティ上の懸念を軽減するために、さまざまなアーキテクチャを検討すべきである。ABAC コンポーネントの分散は、基盤となるエンタープライズアーキテクチャ、および共有すべき必要データと客体の所在を考慮すべきである。例えば、PDP と PEP を同一の管理下に配備することもあり得る。

3.1.2.1 開発・保守コスト（Development and Maintenance Cost）

ABAC はエンタープライズ全体に展開された場合に多くの新機能を提供するが、長期的には ABAC の開発・導入・保守コストがその便益を上回る可能性がある。加えて、アプリケーションを ABAC 対応に改修するコストは、認可インフラを調達・構築・維持するコストとは全く別物である。既存ソリューションを保守しなくてよくなることでコスト削減が得られるとしても、その大部分が、ABAC に必要な主体属性とポリシーの管理・維持コストや、追加のシステムサポートにより相殺される可能性がある。より精緻 3 で、一貫性があり、柔軟なセキュリティを持つことの便益を定量化し、リスクコストとセキュリティコストの適切なバランスを判断すべきである。これらを踏まえると、ABAC はすべてのアクセス制御問題にとって最適解ではないが、主体と客体が豊富な属性集合を持ち、アクセス判断がそれら属性間の複雑な関係に関わる環境においては有力な選択肢となり得る。

3.1.2.2 ABAC への移行コスト（Cost of Transition to ABAC）

ABAC への移行に伴うガバナンスと業務プロセスの変更は、客体がエンタープライズが統治するポリシーとエンタープライズが管理する属性（場合によってはローカル制御も併用）によって管理されるアプローチへの大きな転換を意味する。これらの客体は、これまでアクセス制御に用いられてこなかった追加的な特性集合に関連付ける必要が生じるかもしれない。ネットワークにログオンすれば広範な資源にアクセスできていたユーザは、もはやその利便性を享受できない可能性がある。ポリシー策定者は現行のミッション／ビジネスニーズをポリシーに反映するよう最善を尽くすだろうが、重要なミッション／ビジネス機能を担う者に対しても、予期しないが不可避なアクセス拒否が発生し得る。

ABAC 製品が実装され、組織のアクセス制御が変わるにつれ、新しいプロセスと機能をユーザの日々の業務プロセスやエンタープライズポリシーに統合する必要がある。移行期間中は、なぜこれらのアクセス制御変更を実施するのか、業務の進め方にどのような影響があるのかをユーザに理解してもらうことが重要である。ユーザは新しい ABAC システムとプロセスについて教育を受ける必要がある。これらの変更は、ユーザ体験の向上、重要情報の強化されたセキュリティと保護、新しい ABAC システムの要件、そして（置き換えられる場合は）段階的に廃止される従来のアクセス制御システムの点を適切に伝える形で周知されるべきである。ユーザは既存プロセスに慣れており、ABAC 機能への切り替えに直ちに価値を見出さないかもしれない。ABAC が既存のアクセス制御機構を補完する領域と対比しつつ、エンタープライズのセキュリティ態勢をどのように強化するかを強調することが重要となり得る。

3.1.2.3 特権のレビューと認可の監視の必要性（Need to Review Privilege and Monitor Authorizations）

一部のエンタープライズでは、主体とその属性に関連付けられた能力、および客体とその客体属性に関連付けられたアクセス制御エントリをレビューできる能力を望むことがある。より端的には、要求が発行される前に、各個人がどのアクセス権を持つかを把握する要件がある。これは「事前監査（before the fact audit）」と呼ばれることがある。事前監査は、特定の規制や指示への適合を示すために必要となる場合が多い。もう一つ一般的に望まれるレビュー機能は、特定の客体、または特定の客体属性に割り当てられた資源集合に誰がアクセスできるかを特定することである。ABAC システムは、これらの監査を効率的に実施するのに必ずしも適していない場合がある。むしろ、ABAC の主要な特徴は、客体所有者が個々の主体に関する事前知識なしに客体を保護・共有できる点にある。特定の客体にアクセスできる主体集合を評価するには、大量のデータ取得と計算が必要になり得る—エンタープライズ内の既知のすべての主体について、すべての客体所有者がアクセス要求のシミュレーションを実行することを要する可能性がある。ABAC 実装の適用範囲を限定することで事前の認可把握を助けられるが、当該企業がそのような検証を必要とする場合には、アクセス認可の妥当性を保証する他の方法も検討すべきである。

3.1.2.4 客体保護要件の理解（Understanding Object Protection Requirements）

エンタープライズの各所には、ポリシーの執行対象となる様々な操作・客体タイプが存在する。これにはオペレーティングシステム、アプリケーション、データサービス、データベース管理システムが含まれ得る。認可アクセスの判断に役立つ NLP が存在する場合もあるが、ほとんどの客体へのアクセスは、ローカルのビジネスルール、文書化されていない評価要因、非標準の慣行により統治されるローカルグループポリシーによって制御されている。ABAC を実装するには、何よりもまず、客体とその保護要件を十分に理解する必要がある。その理解が欠けていると、エンタープライズ ABAC に必要な技術の開発・実装コストは著しく増大する。エンタープライズ ABAC の導入は、定義が明確で、管理され、文書化されている客体から開始することが推奨される。

3.1.2.5 エンタープライズのガバナンスと統制（Enterprise Governance and Control）

エンタープライズ ABAC を成功させるには、複数の業務プロセスおよび技術的要因の調整・決定に加え、エンタープライズの責務と権限の確立が必要である。適切なガバナンスモデルがなければ、各組織は縦割りの解決策を生み、エンタープライズの相互運用性は大幅に遅延するだろう。アイデンティティ、クレデンシャル、アクセス管理の機能導入と運用を統括するエンタープライズのガバナンス組織を設置し、各下位組織でも同様の組織を維持して、エンタープライズ ABAC の導入と移行の管理における一貫性を確保することが推奨される。加えて、トラストチェーンを可視化し、情報やサービスの所有と責任、追加のポリシーやガバナンスの必要性、信頼関係を検証・強制する技術要件を明らかにするための「信頼モデル」をガバナンス組織が策定することが推奨される。信頼モデルは、他組織から来る情報を信頼でき、また自組織の情報がどのように使用・保護されるか明確な期待を持って情報を共有するよう、組織に働きかけるのに有用である。

さらに、エンタープライズの認可サービスは、セキュリティ監査、データ損失防止、セキュリティ構成管理、継続的モニタリング、サイバー防御機能と緊密に統合されるべきである。認可サービス単体では、ネットワーク上のミッションクリティカルな客体を保護するために必要なセキュリティを十分に保証できない。エンタープライズのセキュリティ要件と、ABAC 実装がもたらす影響を十分に理解するための取り組みを行うべきである。例えば、分散型の ACM アーキテクチャを用いると、アクセス制御判断やイベントの監査能力に影響が生じる可能性がある。

ABAC システムは、トラストフレームワークで統治される環境での展開によって恩恵を受け得る。従来の ACL と ABAC の代表的なトラストチェーン（図 7 と図 8）を比較すると、ABAC が適切に機能するためには、より複雑な信頼関係が多数必要であることがわかる。ACL は客体の所有者または管理者により設定され、最終的には、ユーザを ACL に追加することで客体アクセス規則を執行する。一方 ABAC では、信頼の根は、主体属性当局やポリシー策定者など、多くのソースに由来する。

image

図 7：ACL のトラストチェーン

image

図 8：ABAC のトラストチェーン

情報共有に内在するリスクを管理する際、エンタープライズ ABAC を展開する場合には、2 つのリスクの観点に対処する必要がある。第一に、ABAC ソリューションは、エンタープライズをリスクから保護する多数のセキュリティ制御オプションの一つと見なされ得る。保護対象リソースへの不正アクセスのリスクは、精緻なポリシーを一貫して実装し、変化する脅威に対応してより容易に更新できるため、ABAC の導入によって低減し得る。第二に、ABAC の利用は、未知のエンティティによるアクセスに客体をさらすことにより、エンタープライズの運用リスクを増減させ得る。属性が適切に発行されることを前提とすると、ABAC システムは属性発行当局に部分的に依存している。このようにリスクの根が多元的であることは、多くの課題を生み、ガバナンスと正式な信頼モデルによって管理しなければならない。

ABAC に内在するリスクを管理するためのガバナンスモデルを確立する際は、各責任組織と、これらの信頼の根および不当なアクセスに起因して生じる責任を監視・管理するためのメカニズムと合意が存在することを確保することが重要である。

3.1.3 運用要件とアーキテクチャの策定（Developing Operational Requirements and Architecture）

ABAC ソリューションを実装する前に、いくつかの高位の運用およびアーキテクチャ計画要件を満たす必要がある。

  • 第一に、ABAC によって共有・保護される客体を特定する。
  • 第二に、それらの保護を統治する規則またはポリシーを定義する。
  • 第三に、アクセス制御規則の作成者と調整しつつ、主体属性と客体属性、およびそれらの権威を識別・定義する。
  • 第四に、アクセス制御ポリシーがどのように作成・検証・管理されるかに関するプロセスを策定する。
  • 最後に、ACM をエンタープライズ全体でどのように分割または分散し、属性・ポリシー・判断の要求と応答をどのように生成・処理するかを決定する。

3.1.3.1 客体識別とポリシー付与（Object Identification and Policy Assignment）

ABAC ソリューションによって共有・保護される客体の選定は、組織の要件に応じて異なる。各客体または客体のクラスは識別され、それぞれを保護するポリシーまたは規則が文書化されなければならない。ABAC 実装の範囲内で新たに作成される各客体を識別し、分類し、ポリシーを割り当てるための業務プロセスを整備する必要がある。

3.1.3.2 属性アーキテクチャ（Attribute Architecture）

アクセス制御ポリシーは属性の観点で表現される。したがって、必要なすべての属性は、該当するポリシーに求められる許容値によって確立・定義され・制約されなければならない。属性のスキーマと許容属性値は、規則や関係の策定を行う客体所有者を支援するために、すべての参加者に公開されなければならない。属性と許容値が確立されたら、主体と客体に属性と適切な属性値をプロビジョニングする方法、ならびに、属性リポジトリ、取得サービス、完全性検証サービスのアーキテクチャを確立する必要がある。これらの属性の共有を可能にするインタフェースとメカニズムを開発または採用しなければならない。

3.1.3.3 主体属性（Subject Attributes）

多くの人間の主体属性は、通常、組織への雇用時にプロビジョニングされ、（人事、セキュリティ、組織のリーダーシップなど）複数の当局によってプロビジョニングされ得る。これらについて権威データを取得する手法はよく知られている。例えば、クリアランス属性と属性値は、権威ある人事クリアランス情報に基づき、セキュリティ当局のみがプロビジョニング・主張すべきであり、個人が自分のクリアランス属性値を変更できてはならない。他の主体属性には、主体の現在のタスク、物理的位置、要求が送信されたデバイスなどが含まれ得る。これらの主体属性データの品質を評価・保証するためのプロセスを整備する必要がある。

権威ある主体属性のプロビジョニング機能は、品質・保証・プライバシー・サービスに関する期待に照らして適切に信頼できるものであるべきである。これらの期待は「属性実務記述（APS: Attribute Practice Statement）」で定義され得る。APS は、エンタープライズ全体で使用される属性の一覧を示し、エンタープライズの権威ある属性ソースを特定することがある。さらに、（属性の機密性・完全性・可用性を維持できることを含む）ネットワークインフラ機能が、権威ある主体属性データを組織内および組織間で共有・複製するために必要である。

3.1.3.4 客体属性（Object Attributes）

客体属性は通常、客体の作成時にプロビジョニングされ、客体にバインドされるか、外部に保存され参照される。アクセス制御当局がすべての事象を綿密に監視できるとは期待すべきでない。多くの場合、この情報はセキュリティ以外のプロセスや要件により左右される。良好なアクセス判断を支える良質な属性データは不可欠であり、客体属性が、アプリケーションにとって適切かつ権威あると客体所有者または管理者が見なすプロセスによって割り当て・検証されるよう、措置を講じなければならない。例えば、アクセス制御判断の結果を操作する目的で主体が客体属性を変更できてはならない。アクセス制御判断のために、客体属性はアクセス制御機構が取得可能でなければならない。客体属性の作成に関する追加の考慮事項として：

  • 一般に、ユーザは客体属性の値（例：あるユーザがどの機微区分に認可されているか）を知らない。ACM では、ユーザには自分に適用可能な値のみが見えるよう配慮すべきである。
  • 主体属性と同様、客体属性にも属性名と許容値を定義するスキーマが必要である。
  • 属性は DP、MP、NLP において一貫性を保たなければならない。

連邦政府および商用分野では、データへのタグ付けのみならず、属性の客体への暗号学的バインドや、アクセス制御判断要件を満たすための客体属性フィールドの検証を行う客体属性タグ付けツールの開発が多数行われてきた。

3.1.3.5 環境条件（Environment Condition）

環境条件とは、一般に特定の主体や客体には関連付けられないが、判断プロセスで必要となるコンテキスト情報を指す。環境条件は、管理的に作成・管理される主体・客体属性とは異なり、本質的なものであり、ABAC システムによって検出可能でなければならない。現在の日時・時刻、所在、脅威、システム状態などの環境条件は、アクセス要求の認可時に、現在の対応する環境変数と照合して評価されるのが通常である。環境条件により、ABAC ポリシーは、主体／客体属性だけでは記述できない例外的または動的な AC 規則を指定できる。環境条件を用いて ABAC 規則を構成する際には、環境条件の変数とその値がグローバルにアクセス可能で、改ざん不能であり、使用される環境に対して関連性があることを確保することが重要である。

3.1.3.6 アクセス制御規則（Access Control Rules）

ABAC では、すべての AC 規則に、何らかの属性と許容操作の組み合わせが含まれていなければならない。条件、階層的継承、複雑なロジックを含むこともある。これらを組み合わせることで、ABAC 実装時に豊富な選択肢が得られる。規則集合と、その客体への適用は、適切に統治・管理されなければならない。規則は NLP を正確かつ完全に反映し、権威を持って（組織が作るものもあれば、リソース所有者が作るものもある）作成・適用・維持・共有・主張されるべきである。ABAC は、複数の関係者からの複数の規則を許容する。共有と保護の適切なバランスを調整し確保するための新しい手法が必要である。状況によっては、権限を得るために属性を操作する不正主体の可能性を低減するため、どの客体にどの規則が適用されるかの可視性を制限することもあるだろう。一方で、アクセスを拒否された主体には、拒否の原因となった状況を検証・是正する手段が必要な場合もある。規則が適切であったかを確認するため、拒否事象の追跡を望む組織もある。同様に、規則の定義と適用のメカニズム・プロセスには、規則の競合（規則の判断が食い違う場合の解決）を特定し、解決プロセスを定める、強固な規則競合解消機能を含めるべきである。

3.1.3.7 アクセス制御機構とコンテキスト処理（Access Control Mechanism and Context Handling）

ACM の分散とオーケストレーションは、客体保護における衝突や弱点を避けるために、事前に定めておかなければならない。例えば、同一の客体が 2 つの異なる組織により保持されている場合、より緩い制限を持つ組織が保持する版に不正主体がアクセスできてはならない。ACM は、相互運用性と包括的なセキュリティを確保するため、一貫した方法で管理・維持・運用されるべきである。

ACM が情報を取得し、判断のために評価し、判断を執行する順序は、実装の具体的要件に応じて大きく異なり得るし、アクセス制御判断の作成時に環境条件を考慮に入れることもある。これは「コンテキスト処理（Context Handling）」と呼ばれ、ACM が判断に必要なデータを収集する際に実行するワークフローを意味する。

さらに、エンタープライズ全体で、ポリシー・属性・判断に関する情報をどこでどのように保存・交換するかは、性能とスケーラビリティの観点から重要な検討事項である。

注 3：属性と規則により、アクセス制御判断に取り込まれる離散的入力の数が増え、変数の組合せの可能性が拡大することで、より大きく明確な規則・ポリシー・アクセス制限の集合を表現できる。ABAC では多数の属性を組み合わせて、あらゆるアクセス制御規則を満たすことが可能である。アクセス判断時に評価するための属性が利用可能である限り、規則は客体の保護要件を満たすために必要なだけ複雑かつ明確になり得る。このように、細粒度の AC は、粗粒度の AC と比べて、より詳細または柔軟にアクセスを区分できる（例：粗粒度—「従業員はファイル X を読める」／細粒度—「プロジェクト A に従事する従業員はファイル X を読める」／さらに細粒度—「プロジェクト A に従事する従業員は就業時間中にファイル X を読める」）。

3.2 調達／開発段階における考慮事項（Considerations during the Acquisition/Development Phase）

調達／開発段階では、システムが設計・購入・プログラム作成・開発、またはその他の方法で構築される。通常この段階では、組織はエンタープライズ全体で実行するために必要な業務プロセスを準備し、配備・統合されるシステムを定義する。この段階の前半では、組織はシステムのセキュリティ要件と機能要件を同時に定義すべきである。この段階の後半では、実装／評価段階を開始する前に、意図どおりに動作することを確実にするため、技術的機能およびセキュリティ機能の開発試験を実施すべきである。

image

3.2.1 業務プロセスの生成と展開準備（Business Process Generation and Deployment Preparation）

3.2.1.1 規則の文書化（Documentation of Rules）

組織が管理する各種類の客体について、対応するアクセス制御規則の集合を NLP で文書化しておくべきである（ユースケースは、エンタープライズの参加者が客体集合に対する NLP を定義する最も簡便な手段となり得る）。これらの規則は、組織が管理するデータやサービスについて、誰が作成・閲覧・変更・削除・転送・相互作用でき、またどのようなコンテキストや環境条件の下でそれらの特権を持つのかを規定すべきである。これらの規則を文書化することにより、適用されるポリシーやガイダンスに対する組織の解釈、該当客体の特有の機微性、当該客体を必要とする適切なユーザコミュニティに関する知見が取り込まれる。

NLP を文書化することで DP の策定が容易になり、成文化されたポリシーへ遡及可能性（トレーサビリティ）が確保される。例えば、多くの組織が、対応する NLP が存在しないために、ACL からより堅牢な ABAC インフラへの認可機能の移行に苦労している。例として、アクセス要求を受けたとき、データ所有者が「この人物はワーキンググループの一員か」「私はこの人物またはその所属組織を知っているか」といった（通常は文書化されていない）一連の基準を評価し、要求者の名前を適切な ACL に追加する前に判断を下す状況を考える。十分に文書化された NLP は、人手による判断から、一貫した自動ポリシー駆動のアクセス制御判断への移行を可能にする。

3.2.1.2 ポリシーのカスタマイズ（Customizing Policy）

上位の権限や義務で求められていない限り、下位組織はローカルポリシーを緩和すべきではない。エンタープライズ内の下位組織が、エンタープライズポリシーで定められた制限を独自に緩めることが可能であるなら、システムに内在するセキュリティは損なわれ、エンタープライズ客体に本来は許されないローカルアクセスを可能にしてしまうおそれがある。

フェデレーション化されたエンタープライズで実装されるローカルアクセスポリシーは、要求者の組織からマッピングされた属性に基づき、要求された客体に関連するエンタープライズポリシーを反映すべきである。組織間の共有合意に応じて、共有所有または共有管理の客体は、最も厳格なポリシーに従って保護されるべきである。

3.2.1.3 属性に関する合意と理解（Agreement and Understanding of Attributes）

エンタープライズの主体属性と客体属性には、一貫した妥当な値の集合が定義・適用されなければならない。これにより、エンタープライズ全体で一貫した既知の値に基づいて認可判断を行うことができる。属性のライフサイクル管理は、その属性が組織内のみで使われるか組織横断で使われるかにかかわらず、プロビジョニングを担う組織の責任である。

3.2.1.4 属性の意味の理解（Understanding Meaning of Attributes）

属性サービス提供者は、消費者が属性を適切かつ有効に利用できるよう、属性と他の属性との関係を記述する必要がある。属性サービス提供者は、エンタープライズの認可属性値の定義と意味を文書化し、属性の利用に関するガイダンスを提供しなければならない。場合によっては、有効なコンテキストを確立するために、属性を他の属性と組み合わせて使用する必要がある（例：ロールと組織の組み合わせ—ロールは組織のコンテキスト内で定義されて初めて意味を持つ）。例えば、組織全体のオペレーション部門長（財務・人事・法務なども所掌する可能性がある）は、IT 部門の Web サービス課におけるオペレーション課長とは、文脈上まったく異なる意味を持つ。属性に関するガイダンス、そのコンテキスト、そしてこれらの属性値が判断を下すために一体として必要であるという認識が欠けると、DP（ひいては判断）は不十分な情報や誤ったロジックに基づいて生成されるおそれがある。

3.2.1.5 アクセス失敗に対するプロセスと手順（Processes and Procedures for Access Failures）

例外処理、アクセス拒否、エラーの伝達に関する手順と要件の集合を確立し、ミッション・ロール・知る必要性（need-to-know）の要請に照らして、ユーザがアクセス判断を是正できる手段を提供すべきである。認可サービスが、アカウントのプロビジョニングと ACL への登録という従来手法から、自動化された判断プロセスへと成熟するにつれ、システムユーザはアクセス拒否を理解・是正することがより困難になる。アクセス承認に必要な属性を適切に見つけ出し取得するための、確立されたプロセスは移行を容易にする。これは、接続断や認可サービスコンポーネントへのアクセス困難といった事象にも拡張できる。

ミッションクリティカルな役割においては、主体が制限事項を理解し、例外を申請したり、権威ある支援窓口を案内されたり、同等の情報やサービスへアクセスする代替経路を試行したりできるべきである。

3.2.1.6 属性のプライバシーに関する考慮（Attribute Privacy Considerations）

ABAC 機能は、適用されるすべてのプライバシー法令・指令・ポリシーに適合するよう開発されるべきである。主体属性は個人的かつ記述的な性質を持つため、属性共有機能の実装により、信頼できない第三者への属性データの不注意な露出や、発信元より防護が弱い環境での機微情報の集約を通じて、個人特定情報（PII）に対するプライバシー侵害リスクが高まる可能性がある。属性共有に関与する組織は、PII の適切な取り扱いと PII 規制の遵守を確保するため、信頼契約を用いるべきである。これらの信頼契約には、トラストチェーンのすべてのコンポーネントにおける、PII の許可された利用・取り扱いの詳細、ならびに規制違反に関する検証・是正・責任裁定の方法を含めるべきである。第二の考慮点として、付与／拒否の判断パターンから主体属性が露見し得ることが挙げられる。主体が特定のリソースにアクセスできるなら、その主体は当該リソースのアクセス規則に指定された属性を備えていなければならない。組織は、付与／拒否判断を見抜かれる手段になり得るアクセスログその他を保護すべきである。

3.2.1.7 デジタルポリシーの作成と維持（Digital Policy Creation and Maintenance）

各 DP は、NLP の要件を満たすよう定義されるべきである。DP は機微であり、適切なポリシーに従って客体と同様に保護される必要がある。これらのポリシーは、DP の特定部分の作成・変更に関わる場合がある。DP は、NLP を解釈でき、DP を作成する権限を持つ個人のみが作成・変更すべきである。特定の NLP を実装するには、複数の DP の定義が必要になることがある。下位ポリシーが上位ポリシーと矛盾しないよう、特別の配慮を払うべきである。各組織は、自組織またはその下位組織のみに適用されるローカルポリシーおよび固有ポリシーを策定・維持すべきである。

3.2.2 システム開発とソリューション調達に関する考慮（System Development and Solution Acquisition Considerations）

3.2.2.1 エンタープライズ内の標準化と相互運用性（Standardization and Interoperability within the Enterprise）

ABAC の実装者は、今日の相互運用性と将来の展開柔軟性を実現できる、包括的な標準準拠アプローチの採用を強く検討すべきであり、その目的を満たす製品や機能を活用すべきである。相互運用性と費用効率の高い ABAC 導入を達成する既存の実践として、標準・仕様・標準化された設定（標準の選択肢をサブセット化した、いわゆるプロファイル）の組を用いる方法がある。任意要素を含む標準は、開発者間で不整合に実装され得るため、標準に完全準拠していてもサービスやアプリケーション同士が相互運用できない場合がある。このため、特に組織横断の環境では、明確に定義された標準プロファイルの採用を推奨する。ABAC ソリューションを調達する際は、広く合意されたテイラードプロファイルを使用し、既存の標準レジストリに含まれる標準やプロファイルを活用すべきである。

個々の認可サービスコンポーネント（例：ポリシー決定点、ポリシー執行点、ポリシー取得点、属性取得点、メタ属性取得点）は、複数製品のシステムを相互運用させられるよう、標準的かつオープンなインタフェースで開発されるべきである。エンタープライズは、機能・インタフェース・インフラ・製品サポートを対象とする要件集合を検討し、分類や系列に関わらずすべての調達でのフィルタとして用いることを検討すべきである。

3.2.2.2 アイデンティティ管理との統合（Identity Management Integration）

客体へのアクセス要求は、一意の主体から発せられたことが認証されなければならない。認証はアイデンティティクレデンシャルの使用によって達成され、アクセス判断が下される前に行われなければならない。ABAC システムは、組織が使用する主流かつ戦略的な認証メカニズムとクレデンシャルをサポートする必要がある。これは、現在の状態が ABAC 採用の妨げとなる場合、組織が認証基盤を強化する必要を意味し得る。これらのクレデンシャルに含まれる主体属性は、主体を一意に決定できるべきであり、クレデンシャル発行に用いられる本人確認プロセスは、特定されたエンティティにアカウンタビリティを課すのに十分であるべきである。発行・本人確認プロセスは、エンタープライズ全体で、信頼できるものとして認知され、アカウンタビリティ要件を満たすに足るものであるべきである。強力な認証方式（[NIST800-63-3, NIST800-63B]）を用い、要求に対して十分な保証水準を提供すべきである。主体が認証されると、その主体に紐づく属性を用いてアクセス判断を行い、判断は要求の帰属情報を提供するため、必要な監査記録／システムに捕捉できる。例えば、信頼された認証局が識別名に紐付けて発行した X.509 証明書に依拠したクライアント認証付きの TLS 1.2 セッション [RFC5246] により転送された要求は、当該認証局によって紐付けられたエンティティに関連付けられる。

3.2.2.3 NPE のサポート（Support for NPEs）

アクセス制御サービスにおける NPE のサポートには特別な要件がある。認可サービスは、いかなる形態のエンティティに結び付いた属性も利用する。NPE に結び付けられた属性は、NPE を一意に特定する助けとなるだけでなく、組織内におけるそのエンティティのコンテキストを反映する。

場合によっては、NPE の主体が 1 人以上の人間の主体を代理して行動することがある。これらの NPE は、人間の主体とは独立した独自のアイデンティティクレデンシャルを保持しうる。NPE のクレデンシャルに基づいてアクセス判断を行うアクセス制御システムは、その時点で当該ロールで行動している、またはグループアカウントにログインしている個々人に要求を帰属させることができない点に留意が必要である。NPE は、独立して、または認証済み個人の代理として行動し得る。NPE には、ネットワーク機器（スイッチ、ルータ等）、サーバ上で動作するプロセス（ポータル等）、ワークステーション、その他のエンドポイントデバイスが含まれる。ミッション機能およびセキュリティ機能の自動化が進むにつれ、NPE は認可サービス相互作用における主体として、より大きな役割を担うようになる。

3.2.2.4 ABAC コンポーネント間の認証とデータ完全性（Authentication and Data Integrity between ABAC Components）

認可サービスは、認可サービスコンポーネント間で機微な情報を交換する際（例：PEP と PDP）、強力な相互認証を必要とする。各交換について、発信者の証明、データ完全性、タイムリネスを考慮すべきである。例えば、認可サービスが権威ある属性サービスから属性を取得する必要がある場合、相互認証を行い、その後、メッセージ完全性とメッセージの発信元を検証するメカニズムを用いるべきである。強力な方式（例：X.509 認証）に基づく認証プロトコルを使用し、属性交換に関与する双方が必要とする保証水準を提供すべきである。

3.2.2.5 ABAC と他の統制の統合（Integrating Other Controls with ABAC）

認可サービス単体では、エンタープライズ全体に分散するミッションクリティカルな客体を保護するために必要なセキュリティを十分に確保できない。所望の保証水準を確立するために、包括的かつ整合的なセキュリティ機能が必要であり、これらは緊密に統合され、アクセス判断およびその執行に必要なセキュリティ情報をシームレスに供給できなければならない。これらの他の統制には、主体の認証、セキュリティ監査、セキュリティ構成管理、侵入検知、監視機能が含まれ得る。

3.2.2.6 属性ソースの選定と可用性（Selection and Accessibility of Attribute Sources）

属性ソースが権威あるソースからポリシー決定点へ属性を提供できるよう、権限は明確に識別されるべきである。複数の属性サービスが利用可能で、（保証水準などの）異なるメタ属性を伴う場合、属性ストア／ポリシー情報点は、最も制限的なポリシーを満たす属性の取得と、性能・可用性要件とのバランスを取るべきである。

3.2.2.7 主体属性の共有リポジトリ（A Shared Repository for Subject Attributes）

十分なネットワーク接続性がある場合には、規模の経済、品質管理の向上、標準インタフェースの活用を見込めるため、主体属性の共有リポジトリを直接利用することを検討すべきである。共有属性リポジトリを利用するもう一つの利点は、複数ソースのデータに対する単一のアクセス点を提供できる点にある。単一のアクセス点への接続を構築・管理する方が、複数の接続を管理するよりも複雑性が低い場合がある。一方で、接続性の制約、帯域不足、断続的な接続といった理由から、認可サービス提供者が共有リポジトリを安定的に利用できない場合がある。その場合、共有属性リポジトリと継続的に同期できないローカルコピーのデータを維持する必要が生じ、最新データへアクセスできないことがある。

3.2.2.8 最小属性割り当て（Minimum Attribute Assignments）

一部のエンタープライズでは、最小属性集合が定義されることがある。標準化されたエンタープライズの主体属性・客体属性の集合があれば、ポリシー変更を反映するための DP の策定や修正が容易になる。このアプローチが適用される例として、機密ネットワークにおける分類・コンパートメント化のマーキングが挙げられる。多くの場合、適切なマーキングなしに客体をネットワークに配置することはできず、アクセス制御ポリシーは、有限でよく知られた分類・コンパートメント化のマーキング集合を対象に記述される。

3.2.2.9 環境条件（Environment Conditions）

ポリシーで求められる場合、環境（またはコンテキスト）情報をアクセス制御プロセスに供給できる。例として、脅威レベル、主体／客体の所在、認証方式、時刻などが挙げられる。環境条件は、主体属性や客体属性よりも時間的に迅速に変化する場合がある。

3.2.2.10 属性管理（Attribute Management）

属性を割り当てる権限は、適切な属性ポリシーと整合する形で明確に定義されるべきである。属性の完全性・許容値・完全性（integrity）・変更履歴を検証するための、何らかの検証・完全性・来歴（provenance）メカニズムを、属性管理に用いられるメカニズムまたはフレームワークに統合すべきである。

3.2.2.11 NLP／DP のトレーサビリティ（NLP/DP Traceability）

エンタープライズの高位の成文化ポリシー／NLP と、エンタープライズ内の下位またはローカルの DP の間の、包括的かつ一貫したトレーサビリティを、適切な権限主体が維持すべきである。これにより、成文化ポリシーの変更を評価し、後続の DP をそれに応じて変更できる。このポリシートレーサビリティにより、ローカル組織に存在する多数の DP は、要件の変更に応じて監査・検証・変更可能となる。

3.2.2.12 合意済み属性に基づく規則またはポリシー（Rules or Policies Based on the Agreed Attributes）

組織が、1 つ以上の他組織と定義済みの属性リストを使用する合意を結んでいる場合（今日では業界別・ユースケース別の属性グルーピングが利用可能な場合がある）、客体を所有する組織は、当該属性のみに基づいてアクセス制御ポリシーを策定することを確実にしなければならない。限定的であっても安全な情報共有を実現するため、受け入れられた共通の共有エンタープライズ属性集合が存在するなら、その利用に最大限努めるべきである。新たな要件が生じれば、エンタープライズは新しいエンタープライズ属性と、その共有に関する規則を導入することを選択し得る。

例えば、OASIS XACML の Export Control-US（EC-US）および Intellectual Property Control（IPC）プロファイルは、一般に制約された属性値を伴う、ドメイン特化の標準化属性の例である。EC-US プロファイルは、米国商務省輸出管理規則（EAR）および米国国務省国際武器取引規則（ITAR）に関するアクセス制御判断に共通する属性を文書化している。

3.2.2.13 ポリシー決定サービスの外部化（Externalization of Policy Decision Services）

PDP をサービスとして実装し、個々のエンタープライズサービスやアプリケーションから分離することは一般的である。そうすることで、各エンタープライズサービスやアプリケーションごとに同種の決定サービスを提供する負担や費用がなくなる。単一の PDP が複数のエンタープライズ認可サービスを支援できるからである。認可サービス提供者が、より大きなエンタープライズや組織が提供する PDP サービスを利用できるようにすることは、サービス／アプリケーション開発を大幅に簡素化し、これらのサービスの個別インスタンスに費やされるライセンス・訓練・設定・配備のコストを節約し、運用・保守を個別プログラムから切り離す効果がある。

3.2.3 その他のエンタープライズ ABAC 機能に関する考慮（Considerations for Other Enterprise ABAC Capabilities）

ABAC のエンタープライズ認可機能を開発・実装する際、アーキテクトやプロジェクトマネージャは、現在使用中のアクセス制御方式から目標とする最終状態への移行が長期に及ぶことを念頭に置かなければならない。標準や技術が成熟するにつれ、組織は相互運用性を高め、より高い保証を促進する概念を取り入れ、プロプライエタリで縦割りの解決策を廃していく必要がある。

3.2.3.1 アクセス制御判断に対する確信度（Confidence in Access Control Decisions）

アクセス制御判断は、リスク水準に見合った権威あるソースから収集された、正確・迅速・関連性の高いデータを用いて行われる。アクセス制御判断に対する確信度は、判断の算出に用いる情報のタイムリネス、関連性、権威性、品質・信頼性・完全性に依存する。確信度の確立における他の要素には、識別・認証プロセス（例：認証方式の強度、本人確認、クレデンシャル発行と証明、アテステーション、送信元 IP アドレス）が含まれる。ABAC にリスクベースのアプローチを採用する際には、上述の要素を考慮すべきである。

3.2.3.2 組織間での属性マッピング（Mapping Attributes between Organizations）

組織ごとに、属性および属性値の名称が異なる場合がある。「エンタープライズ属性」と呼ばれる特別な属性群の必要性を最小化するため、エンタープライズ組織間で属性マッピングを提供する解決策を実装することが重要となり得る。属性マッピングは、名称の異なる属性あるいは属性値間の変換として機能する。例えば、ある組織は Citizenship を、別の組織は Nationality を、同一の属性値集合を指す名称として用いるかもしれない。

実務では、組織横断の ABAC は、3.1.3.1 および 3.1.3.2 節で概説した協調的アプローチに従うことがある。これにより、組織間で適切な統制の確証を与えるフレームワークの中で、各組織がローカルな判断を下せるようになる。新しいポリシーが作成されるとき、ポリシー作成者が独自の属性を作る、または指定する場合、ポリシーは相互運用性を欠く可能性がある。事前に合意された属性を用いることで、ポリシーはより一様で理解しやすくなる。

3.3 実装／評価段階における考慮事項（Considerations during the Implementation/Assessment Phase）

実装／評価段階では、組織はシステムをインストールまたは実装し、システムのセキュリティ機能を構成して有効化し、これらの機能の動作をテストし、最終的にシステムの運用認可（ATO）を正式に取得する。この段階での考慮事項の大半は、パフォーマンスの最適化と、セキュリティ機能が期待どおりに動作することの確保に焦点が置かれる。

image

3.3.1 属性キャッシュ（Attribute Caching）

ABAC ソリューションが試作／パイロットから本番展開へ移行する際、性能向上のため属性キャッシュを検討してもよい。各アクセス判断のたびにネットワーク越しの属性要求が必要になると、ABAC ソリューションの性能は悪化しうる。これは、とくに低帯域・高遅延の環境で顕著である。

属性キャッシュに関する性能面の課題に加えて、属性の鮮度とセキュリティへの影響に関するトレードオフを評価することも考えられる。更新頻度の低い属性は、リアルタイムで更新される属性に比べ、最終的にセキュリティが低下する。例えば、前回の更新以降に主体のアクセス特権が変更されていても、次回の更新までその変更は利用可能なアクセス特権に反映されない。

疎結合な接続環境では、ローカルで属性をキャッシュする必要がある。キャッシュした属性をローカルで用いることのセキュリティ上の影響は、実装組織内でポリシーレベルで判断し、適切な技術的統制で対処する必要がある。こうした切断環境では、ローカル（切断状態）の属性がシステムの更新前に変更・削除されることがありうるため、管理者はアクセス判断の根拠としてリスクベース分析を用いる場合がある。最新ではないキャッシュ属性（スタ ale 属性）をローカル（かつ切断状態）で用いることは、最新の属性を用いないがゆえに、一定のリスクをシステムにもたらしうる。したがって、この種の解決策を導入するか否かについて、リスクベース分析を行うことが妥当である。

一例として、エンタープライズのネットワーク基盤との接続が断続的かつ理想的ではない、展開中の艦船を考える。移動期間中の配乗ユーザの変動は小さいため、「予期しない」システムユーザへの対応はあまり問題にならない。この場合、主体属性を一括ダウンロードしローカルに保存することで、大半のローカルなアクセス制御判断に十分対応できる。したがって、主体属性データは配備期間中、艦内にローカル保存され、ローカルのアプリケーションやサービスは権威あるエンタープライズ属性ソースへ問い合わせることなく、ローカルストアのデータを利用できる。これは厳しい環境に対する解の一例ではあるが、唯一の解と解釈すべきではない。

3.3.2 属性ソースの最小化（Attribute Source Minimization）

認可判断に用いる属性ソースの数を最小化することは、性能の向上と ABAC ソリューション全体のセキュリティ管理の単純化に寄与しうる。ABAC ソリューションの展開を計画する組織は、展開に関与するすべての関係者間で緊密な連携関係を確立することで利益を得られる可能性がある。

3.3.3 インタフェース仕様（Interface Specifications）

エンタープライズ ABAC 機能を通じて情報共有に参加するすべての組織は、属性要求や DP 要求を含むあらゆる種類のリクエストについて、そのインタフェース、相互作用、事前条件の要件を十分に理解し、ABAC サービスへのアクセスを常に信頼できるものにすることが望ましい。また、インフラやインタフェース要件に変更が生じた際には、全ての依存当事者に更新通知を確実に行い、各自のコンポーネントを適切に改修できるようにすることも重要である。

3.4 運用／保守段階における考慮事項（Considerations during the Operations/Maintenance Phase）

運用／保守段階では、システムや製品が導入・運用され、システムの拡張や修正が開発・試験され、ハードウェアやソフトウェアが追加・交換される。この段階において組織は、事前に定めたユーザ要件およびセキュリティ要件に整合していることを確保するため、システムの性能を監視し、必要なシステム修正を取り込むべきである。

image

3.4.1 良質なデータの可用性（Availability of Quality Data）

アクセス制御判断に必要な情報（場合によっては判断そのもの）が客体や利用者から外部化されるにつれ、情報やサービスへのアクセスは、外部サービスがタイムリーかつ正確なデータを提供できる能力に、より依存するようになる。基盤は堅牢で十分に試験され、レジリエントで、ミッション要件に対してスケールできることが重要である。これは、属性サービス、属性ストア、ポリシーストア、ポリシー／属性の生成・検証コンポーネント、決定エンジン、メタ属性のリポジトリおよびこれらの情報が通過する経路を支援するために重要である。外部委託する場合、サービス合意には、可用性、応答時間、データ品質および完全性の要件を詳細に定めるべきである。例えば、ミッションクリティカルと見なされるデータやサービスについては、フェイルオーバー、冗長性、事業継続（COOP）を考慮しなければならない。高可用かつ高品質なデータを維持するには、属性値の追加・更新・削除を訓練を受けた認可された個人が実施し、定期的に監査する必要がある。

属性やサービスの提供者と利用者の間の正式な合意は、適切なサービス水準、品質、可用性、保護、利用に関する基準を満たすべきである。さまざまな法令は、情報の適切な保護に関わる責務、責任、罰則を定めている。合意には、これらの要件およびデータに関する責任に関わる要件を盛り込むべきである。

組織間で適切なレベルの信頼を確立する合意は重要である。これらの合意は、要求事項群と、場合によっては不遵守に対する罰則によって、信頼関係を形式化する役割を果たす。属性サービスや、権威と説明責任を持つ属性ソースに関する APS や MOU/MOA は、組織のポリシーを運用手順に落とし込む役割も担い得る。これらの正式な合意には、当該サービスの目的、利用法、関係者、責務、管理が記述される。

4. 結論（Conclusion）

本書は、これまで別個に存在していた ABAC に関する知見を集約し、利用可能な技術と最良実装との間にある既存のギャップを橋渡しするとともに、連邦政府における ABAC への関心の高まりに対応することを目的としている。

ABAC は、要求に関連するエンティティ（主体・客体）の属性、操作、および環境に対する規則の評価によって客体へのアクセスを制御する。ABAC は、主体属性・客体属性の評価と、主体・客体属性の組合せに対する許容操作を定義する正式な関係またはアクセス制御規則の評価に依拠する。ABAC は、アクセス制御判断への多数の離散的入力を可能にし、それらの変数の組合せの大きな集合を提供することで、多様な規則・ポリシー・アクセス制限を表現する精緻なアクセス制御を実現する。したがって、ABAC は、豊かなポリシー集合を満たすために、制限のない数の属性を組み合わせることを可能にする。

本書は、ABAC を理解するために必要な一般概念を定義する。具体的には、主体属性と客体属性、ABAC モデルとそのコンポーネントの一般的機能を扱う。また、エンタープライズ内で ABAC 機能を計画・設計・開発・実装・運用する際に考慮すべき、システム開発ライフサイクルに沿った多数の事項を明らかにする。とくに大規模エンタープライズにおける ABAC メカニズムの利点と一般的な落とし穴を論じる。

ABAC 機能は、異種組織間の情報共有を促進しつつ、前例のない柔軟性とセキュリティを提供する。最大限の相互運用性を確保するためには、共通の概念基盤と機能要件に基づいて、これらの機能を開発・展開することが不可欠である。ABAC は大規模エンタープライズに適している。ABAC システムは既存のロールベースアクセス制御ポリシーを実装でき、要求者の多様な特性に基づく、よりきめ細かなアクセス制御ポリシーへ移行することも支援できる。ABAC は、外部（予期しない）ユーザへの対応を支え、管理の効率化をもたらす。他方で、ABAC システムはより複雑であり、より単純なアクセス制御システムに比べて実装・維持にコストがかかる。

付録 A - 頭字語と略語（Appendix A - Acronyms and Abbreviations）

本ガイドで用いる主な頭字語・略語を以下に示す。

AASC — Attribute and Authorization Services Committee ABAC — Attribute Based Access Control AC — Access Control ACL — Access Control List ACM — Access Control Mechanism APS — Attribute Practice Statement CIO — Chief Information Officer CONOPS — Concept of Operations COTS — Commercial Off-the-Shelf DAC — Discretionary Access Control DLP — Data Loss Prevention DoD — Department of Defense DP — Digital Policy DPM — Digital Policy Management FICAM — Federal Identity, Credential, and Access Management FISMA — Federal Information Security Management Act GUI — Graphical User Interface HIPAA — Health Insurance Portability and Accountability Act IBAC — Identity Based Access Control IETF — Internet Engineering Task Force IP — Internet Protocol IR — Interagency Report IT — Information Technology ITL — Information Technology Laboratory MAC — Mandatory Access Control MP — Metapolicy NIST — National Institute of Standards and Technology NLP — Natural Language Policy NPE — Non-Person Entity OASIS — Organization for the Advancement of Structured Information Standards OMB — Office of Management and Budget OPSEC — Operations Security PAP — Policy Administration Point PDP — Policy Decision Point PEP — Policy Enforcement Point PII — Personally Identifiable Information PIP — Policy Information Point PKI — Public Key Infrastructure RAdAC — Risk-Adaptable Access Control RBAC — Role-Based Access Control RFC — Request for Comment RLS — Row Level Security SAN — Storage Area Network SDLC — System Development Life Cycle SOA — Service Oriented Architecture SP — Special Publication SQL — Structured Query Language TCSEC — Trusted Computer System Evaluation Criteria TD — Technology Development TLS — Transport Layer Security XACML — Extensible Access Control Markup Language XML — Extensible Markup Language

付録 B - 参考文献（Appendix B - References）

[ANSI359] InterNational Committee for Information Technology Standards, American National Standard for Information Technology - Role Based Access Control, ANSI/INCITS 359-2012, American National Standards Institute, New York, 2012 年 5 月 29 日, 56pp. https://webstore.ansi.org/Standards/INCITS/INCITS3592012

[ANSI499] InterNational Committee for Information Technology Standards, Information technology Next Generation Access Control - Functional Architecture (NGAC-FA), ANSI/INCITS 499-2018, American National Standards Institute, New York, 2018 年 1 月 30 日, 57pp.

[CGLO09] I. F. Cruz, R. Gjomemo, B. Lin, and M. Orsini, “A Constraint and Attribute Based Security Framework for Dynamic Role Assignment in Collaborative Environments,” Collaborative Computing: Networking, Applications and Worksharing, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol. 10, 322–339 (2009). https://doi.org/10.1007/9783-642-03354-4_24

[FEDCIO1] Federal Chief Information Officers Council, Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance (Version 1.0), Office of Management and Budget, Washington, D.C., 2009 年 11 月 10 日, 220pp.

[FEDCIO2] Federal Chief Information Officers Council, Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance (Version 2.0), Office of Management and Budget, Washington, D.C., 2011 年 12 月 2 日, 478pp. https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf

[FK92] D. F. Ferraiolo and D. R. Kuhn, “Role-Based Access Controls,” Proceedings of 15th NIST-NCSC National Computer Security Conference, National Institute of Standards and Technology, Gaithersburg, Maryland, 554–563 (1992). https://csrc.nist.gov/publications/detail/conference-paper/1992/10/13/role-based-access-controls

[NIST7316] V. C. Hu, D. F. Ferraiolo, and D. R. Kuhn, Assessment of Access Control Systems, NISTIR 7316, National Institute of Standards and Technology, Gaithersburg, Maryland, 2006 年 9 月, 60pp. https://doi.org/10.6028/NIST.IR.7316

[NIST7657] NIST/NSA Privilege (Access) Management Workshop Collaboration Team, A Report on the Privilege (Access) Management Workshop, NISTIR 7657, National Institute of Standards and Technology, Gaithersburg, Maryland, 2010 年 3 月, 48pp. https://doi.org/10.6028/NIST.IR.7657

[NIST7665] Proceedings of the Privilege Management Workshop, September 1–3, 2009, NISTIR 7665, S. A. Durrant, T. Brewer, and A. Sokol, eds., National Institute of Standards and Technology, Gaithersburg, Maryland, 2010 年 1 月, 10pp. https://doi.org/10.6028/NIST.IR.7665

[NIST7874] V. C. Hu, and K. Scarfone, Guidelines for Access Control System Evaluation Metrics, NISTIR 7874, National Institute of Standards and Technology, Gaithersburg, Maryland, 2012 年 9 月, 48pp. https://doi.org/10.6028/NIST.IR.7874

[NIST800-100] P. Bowen, J. Hash, and M. Wilson, Information Security Handbook: A Guide for Managers, NIST Special Publication 800-100, National Institute of Standards and Technology, Gaithersburg, Maryland, 2006 年 10 月（2007 年 3 月 7 日更新を含む）, 178pp. https://doi.org/10.6028/NIST.SP.800-100

[NIST800-53] Joint Task Force Transformation Initiative, Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication 800-53 Revision 4, National Institute of Standards and Technology, Gaithersburg, Maryland, 2013 年 4 月（2015 年 1 月 22 日更新を含む）, 462pp. https://doi.org/10.6028/NIST.SP.800-53r4

[NIST800-63-3] P. Grassi, M. Garcia, and J. Fenton, Digital Identity Guidelines, NIST Special Publication 800-63-3, National Institute of Standards and Technology, Gaithersburg, Maryland, 2017 年 6 月（2017 年 12 月 1 日更新を含む）, 74pp. https://doi.org/10.6028/NIST.SP.800-63-3

[NIST800-63B] P. Grassi, E. Newton, R. Perlner, A. Regenscheid, J. Fenton, W. Burr, J. Richer, N. Lefkovitz, J. Danker, Y.-Y. Choong, K. Greene, and M. Theofanos, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST Special Publication 800-63B, National Institute of Standards and Technology, Gaithersburg, Maryland, 2017 年 6 月（2017 年 12 月 1 日更新を含む）, 79pp. https://doi.org/10.6028/NIST.SP.800-63b

[RFC5246] T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol, Version 1.2, RFC 5246, Internet Engineering Task Force, Network Working Group, 2008 年 8 月, 104pp. https://doi.org/10.17487/RFC5246

[SCFY96] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-Based Access Control Models,” IEEE Computer 29(2), 38–47 (1996 年 2 月). https://doi.org/10.1109/2.485845

[TCSEC] U.S. Department of Defense, Information Assurance (IA), DoD Directive 8500.1, U.S. Department of Defense, Washington, D.C., 2002 年 10 月 24 日, 25pp. https://dodcio.defense.gov/Portals/0/Documents/DIEA/850001p.pdf

[WWJ04] L. Wang, D. Wijesekera, and S. Jajodia, “A Logic-based Framework for Attribute Based Access Control,” Proceedings of the 2004 ACM workshop on Formal Methods in Security Engineering, FMSE '04, ACM, New York (2004 年 10 月) 45–55. https://doi.org/10.1145/1029133.1029140

[XACML] “OASIS eXtensible Access Control Markup Language (XACML) TC,” Organization for the Advancement of Structured Information Standards［Web ページ］, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

[YT05] E. Yuan and J. Tong, “Attributed Based Access Control (ABAC) for Web Services,” Proceedings of the 2005 IEEE International Conference on Web Services, ICWS 2005, IEEE Computer Society, Los Alamitos, California (2005 年) 561–569. https://doi.org/10.1109/ICWS.2005.25