属性ベースのアクセス制御

属性ベースのアクセス制御（ABAC ）は、 IAMのポリシーベースのアクセス制御とも呼ばれ、サブジェクト、オブジェクト、要求された操作、場合によっては環境属性に関連付けられた属性を評価することによって、サブジェクトが一連の操作を実行するための承認を決定するアクセス制御パラダイムを定義します。^[1]

ABAC は、アクセス制御ポリシーを実装する方法であり、適応性が高く、さまざまな属性を使用してカスタマイズできるため、分散環境や急速に変化する環境での使用に適しています。ABAC で実装できるポリシーの唯一の制限は、計算言語の機能と関連する属性の可用性です。^[2] ABAC ポリシー ルールは、サブジェクトの属性、オブジェクトの属性、および環境属性のブール関数として生成されます。^[3]

ロールベースのアクセス制御(RBAC) は、特定の権限セットが関連付けられてサブジェクトが割り当てられるロールを定義しますが、ABAC は、さまざまな属性を評価できる複雑なルール セットを表現できます。セキュリティポリシーに一貫したサブジェクトとオブジェクト属性を定義することで、ABAC では、非 ABAC アクセス方法で必要な個人のサブジェクトに対する明示的な承認が不要になり、アクセス リストとグループの管理の複雑さが軽減されます。

属性値は、セット値またはアトミック値にすることができます。セット値の属性には、複数のアトミック値が含まれます。例としては、roleやprojectがあります。アトミック値の属性には、1 つのアトミック値のみが含まれます。例としては、clearanceやsensitive があります。属性は、静的な値と比較することも、属性同士を比較することもできるため、関係ベースのアクセス制御が可能になります。^{[引用が必要]}

概念自体は長年存在していましたが、ABAC はリソースに対する動的でコンテキスト認識型のリスクインテリジェントなアクセス制御を提供し、さまざまな情報システムの特定の属性を含むアクセス制御ポリシーを定義して認証を解決し、効率的な規制コンプライアンスを実現できるため、「次世代」の認証モデルと見なされています。これにより、企業は既存のインフラストラクチャに基づいて柔軟に実装できます。

属性ベースのアクセス制御は、ポリシーベースのアクセス制御( PBAC ) またはクレームベースのアクセス制御( CBAC )と呼ばれることもありますが、これはマイクロソフト固有の用語です。ABAC を実装する主要な標準は、XACMLとALFA (XACML)です。^[4]

ABAC は次のように考えられます。

• 外部化された認可管理^[5]
• 動的権限管理^[6]
• ポリシーベースのアクセス制御
• きめ細かな認証

ABAC には、次のような推奨アーキテクチャが付属しています。

1. PEP またはポリシー適用ポイント: ABAC を適用するアプリとデータを保護する役割を担います。PEP はリクエストを検査し、承認リクエストを生成して PDP に送信します。
2. PDP またはポリシー決定ポイントは、アーキテクチャの頭脳です。これは、設定されたポリシーに対して着信要求を評価する部分です。PDP は許可/拒否の決定を返します。PDP は、不足しているメタデータを取得するために PIP を使用することもあります。
3. PIP またはポリシー情報ポイントは、PDP を LDAP やデータベースなどの外部属性ソースにブリッジします。

属性は、あらゆるものや人に関するものです。属性は、通常、4 つのカテゴリに分類されます。

1. サブジェクト属性: アクセスを試みるユーザーを説明する属性 (例: 年齢、許可、部門、役割、役職)
2. アクション属性: 試行されているアクションを説明する属性 (例: 読み取り、削除、表示、承認)
3. オブジェクト属性: アクセスされるオブジェクト (またはリソース) を説明する属性。例: オブジェクトの種類 (医療記録、銀行口座)、部門、分類または機密性、場所
4. コンテキスト（環境）属性：アクセス制御シナリオの時間、場所、または動的側面を扱う属性^[7]

ポリシーは、属性をまとめて、何が起こり、何が許されないかを表すステートメントです。ABAC のポリシーは、許可ポリシーまたは拒否ポリシーになります。ポリシーはローカルまたはグローバルにすることもでき、他のポリシーを上書きするように記述することもできます。例:

1. ドキュメントがユーザーと同じ部門にある場合、ユーザーはドキュメントを閲覧できます。
2. ユーザーは、所有者であり、ドキュメントが下書きモードである場合にドキュメントを編集できます。
3. 午前9時前はアクセスを拒否

ABACを使用すると、さまざまなシナリオやテクノロジーに対応する無制限の数のポリシーを作成できます。^[7]

歴史的に、アクセス制御モデルには、強制アクセス制御(MAC)、任意アクセス制御(DAC)、そして最近ではロールベース アクセス制御(RBAC) が含まれています。これらのアクセス制御モデルはユーザー中心であり、リソース情報、ユーザー (要求元エンティティ) とリソースの関係、時刻やユーザー IP などの動的情報などの追加パラメータは考慮されません。

ABACは、要求元のエンティティ（ユーザー）、対象となるオブジェクトまたはリソース、必要なアクション（表示、編集、削除）、環境またはコンテキスト情報を記述する属性に基づいてアクセス制御を定義することで、この問題に対処しようとします。これが、アクセス制御が属性ベースであると言われる理由です。^[8]

ABAC には主に 3 つの実装があります。

• オアシスXACML
• 承認のための省略言語 (ALFA)。
• NISTの次世代アクセス制御 (NGAC)

XACML (eXtensible Access Control Markup Language) は、アーキテクチャ (ALFA および NGAC と共有)、ポリシー言語、および要求/応答スキームを定義します。従来のIAMツール、データベース、およびディレクトリに任されている属性管理 (ユーザー属性の割り当て、オブジェクト属性の割り当て、環境属性の割り当て) は処理しません。

アメリカ軍の各部門を含む企業は、ABACの使用を開始しています。基本的なレベルでは、ABACはユーザーにデータを割り当てるのではなく、「IF/THEN/AND」ルールでデータを保護します。米国商務省はこれを義務化しており、いくつかの政府機関や軍事機関に導入が広がっています。^[9]

ABAC の概念は、テクノロジー スタックとエンタープライズ インフラストラクチャのあらゆるレベルに適用できます。たとえば、ABAC はファイアウォール、サーバー、アプリケーション、データベース、およびデータ レイヤーで使用できます。属性を使用すると、アクセス要求の正当性を評価するための追加のコンテキストが得られ、アクセスを許可するか拒否するかの決定に役立てることができます。

ABAC ソリューションを評価する際の重要な考慮事項は、パフォーマンスに対する潜在的なオーバーヘッドとユーザー エクスペリエンスへの影響を理解することです。制御が細かくなるほど、オーバーヘッドが高くなることが予想されます。

ABAC を使用すると、属性ベースのきめ細かな承認を API メソッドまたは関数に適用できます。たとえば、銀行 API は、approveTransaction(transId) メソッドを公開する場合があります。ABAC を使用すると、呼び出しを保護できます。ABAC を使用すると、ポリシー作成者は次のように記述できます。

• ポリシー: マネージャーは承認制限までトランザクションを承認できます
• 使用される属性: ロール、アクション ID、オブジェクト タイプ、金額、承認制限。

流れは次のようになります。

1. ユーザのアリスはAPIメソッドapproveTransaction(123)を呼び出します。
2. API は呼び出しを受信し、ユーザーを認証します。
3. API のインターセプターは、承認エンジン (通常はポリシー決定ポイントまたは PDP と呼ばれます) を呼び出し、次のように質問します: Alice はトランザクション 123 を承認できますか?
4. PDP は ABAC ポリシーと必要な属性を取得します。
5. PDPは許可または拒否などの決定を下し、それをAPIインターセプターに返します。
6. 決定が「許可」の場合、基礎となる API ビジネス ロジックが呼び出されます。それ以外の場合、API はエラーを返すか、アクセスを拒否します。

ABAC の主な利点の 1 つは、認可ポリシーと属性をテクノロジーに依存しない方法で定義できることです。つまり、API またはデータベース用に定義されたポリシーをアプリケーション スペースで再利用できます。ABAC のメリットを享受できる一般的なアプリケーションは次のとおりです。

1. コンテンツ管理システム
2. ERP
3. 自社開発アプリケーション
4. ウェブアプリケーション

API セクションで説明したものと同じプロセスとフローがここでも適用されます。

データベースのセキュリティは長い間、データベース ベンダー固有のものでした。Oracle VPD、IBM FGAC、Microsoft RLS はすべて、きめ細かい ABAC のようなセキュリティを実現するための手段です。

例は次のようになります。

• ポリシー: マネージャーは自分の地域の取引を閲覧できる
• データ中心の方法でポリシーを改訂しました。ユーザーはrole = manager、SELECTtable = TRANSACTIONSuser.region = transaction.region

データ セキュリティは通常、データベース セキュリティよりも一歩進んでおり、データ要素に直接制御を適用します。これは、データ中心のセキュリティと呼ばれることがよくあります。従来のリレーショナル データベースでは、ABAC ポリシーは、属性に基づいてフィルタリング条件とマスキングを備えた論理制御を使用して、テーブル、列、フィールド、セル、サブセルでデータへのアクセスを制御できます。属性は、データ、ユーザー、セッション、またはツール ベースにすることができ、特定のデータ要素へのアクセスを動的に許可/拒否する際の柔軟性を最大限に高めることができます。ビッグ データや Hadoop などの分散ファイル システムでは、データ レイヤーで適用される ABAC が、フォルダー、サブフォルダー、ファイル、サブファイル、その他の粒度へのアクセスを制御します。

属性ベースのアクセス制御は、Hadoopのようなビッグデータシステムにも適用できます。データレイクからデータを取得するときに、以前に使用されたものと同様のポリシーを適用できます。^{[10] [11]}

Windows Server 2012 以降、Microsoft はファイルとフォルダへのアクセスを制御するための ABAC アプローチを実装しています。これは、動的アクセス制御 (DAC) ^[12]とセキュリティ記述子定義言語 (SDDL) によって実現されます。SDDL は、ユーザー (クレーム) とファイル/フォルダのメタデータを使用してアクセスを制御するため、ABAC 言語と見なすことができます。

• 属性ベースのアクセス制御とは何ですか?
• 属性ベースアクセス制御 (ABAC) - 概要
• DAC、MAC、RBAC をカバーする統合属性ベース アクセス制御モデル (ABAC)
• 属性ベースのアクセス制御モデル (ABAC) とクラウド インフラストラクチャ サービスでの実装
• ABAC ではなく RBAC: (IoT) コンテキスト セキュリティの世界へようこそ、2015 年、Lori MacVittie
• マーケットコンパス：動的承認管理、2020年、グラハム・ウィリアムソン