属性ベースのアクセス制御（Attribute Based Access Control）とは、ロールではなく属性（特性）を評価してアクセスを決定する認可モデルです。ABAC は、成長している環境で役立ち、アクセス制御ポリシー管理が手間になっている状況に役立ちます。ABACの目的は、データ、ネットワークデバイス、ITリソースなどのオブジェクトを、権限を持たないユーザーやアクション（組織のセキュリティポリシーの定義に沿って「承認」された特性を持たないユーザーやアクション）から保護することです。
論理アクセス制御の一形態としてのABACは、単純なアクセス制御リストやロールベースのアクセス制御（RBAC）から進化し、過去10年間で普及しました。ABACは、米国の連邦政府機関がアクセス制御アーキテクチャーを改善するためのイニシアチブの一環として、2011年に連邦最高情報責任者評議会（Federal Chief Information Officers Council）により承認されました。情報を安全に共有するためのモデルとしてABACが推奨されたのです。
この記事では、属性ベースのアクセス制御（ABAC）の仕組みについて説明し、組織がABACの採用によりメリットを得るための方法と自社に適したアクセス制御モデルの選び方を紹介します。
属性ベースのアクセス制御（ABAC）の主要コンポーネント
組織のアクセスポリシーでABACが使用される場合、アクセスイベントに関与するサブジェクト、リソース、アクション、環境の属性に基づいてアクセスが決定されます。
Subject
サブジェクトとは、アクションを実行するためにリソースへのアクセスを要求するユーザーを指します。ユーザープロファイルのサブジェクトの属性には、ID、ジョブロール、グループのメンバーシップ、部門および組織のメンバーシップ、管理レベル、セキュリティクリアランスなどの識別基準が含まれます。ABACシステムは、しばしば人事システムやディレクトリから、このデータを取得します。また、ログイン時に使用される認証トークンから情報を収集することもあります。
リソース
リソースとは、サブジェクトがアクセスする資産またはオブジェクト（ファイル、アプリケーション、サーバー、APIなど）を指します。リソースの属性はすべて、ファイルの作成日、所有者、ファイル名とタイプ、データの機密性などの識別特性です。たとえば、オンライン銀行口座にアクセスしようとする場合に関与するリソースは、「銀行口座 = <正しい口座番号>」になります。
アクション
アクションとは、ユーザーがリソースに対して実行しようとしている操作を指します。一般的なアクション属性には、「読み取り」「書き込み」「編集」「コピー」「削除」があります。場合によっては、複数の属性が1つのアクションを記述することがあります。先のオンラインバンキングの例では、送金の要求は「アクションタイプ = 送金」と「金額 = $200」という特性を持ちます。
環境
環境とは、各アクセス要求のより広範なコンテキストを指します。すべての環境属性は、アクセス試行の時間と場所、サブジェクトのデバイス、通信プロトコル、暗号化強度などのコンテキスト要因に影響します。コンテキスト情報には、認証強度やサブジェクトの通常の行動パターンなど、組織が設定したリスク信号が含まれることもあります。
ABACが属性によりアクセス制御ポリシーを表現する方法とは？
属性は、アクセスイベントに関与するコンポーネントの特性または値です。属性ベースのアクセス制御（ABAC）は、これらのコンポーネントの属性をルールに照らして分析します。これらのルールは、サブジェクトがオブジェクトに対してアクションを正常に実行するために許可される属性の組み合わせを定義します。
環境における属性の相互作用に応じて、各ABACソリューションは環境内で属性を評価し、ルールと関係を適用できます。ポリシーは、属性を考慮して、許可するアクセス条件を定義します。
たとえば、以下のようなポリシーが使用される場合を考えてみましょう。
「サブジェクトがコミュニケーションの役職にある場合は、担当するビジネス部門のメディア戦略に対して読み取りと編集のアクセス権を持つ」
アクセス要求が発生すると、ABACシステムは属性の値を分析し、確立されたポリシーに一致させます。上記のポリシーが適用されている限り、以下の属性を持つアクセス要求はアクセスを付与します。
- サブジェクトの「役職」=「コミュニケーション」
- サブジェクトの「ビジネス部門」=「マーケティング」
- アクション =「編集」
- リソースの「タイプ」=「メディア戦略文書」
- リソースの「ビジネス部門」=「マーケティング」
これにより、ABACを使用する管理者は、ポリシーベースのきめ細かなアクセス制御を実装し、さまざまな属性の組み合わせを使用して、状況に応じて限定的または広範なアクセス条件を作成できます。
ABACのメリット
ABACがどのようなもので、どのように機能するかを理解しましたでしょうか。次にABACがビジネスの俊敏性と安全性を維持する方法について見ていきましょう。属性ベースのアクセス制御には、主に以下の3つのメリットがあります。
きめ細かく、しかも柔軟なポリシーの作成
ABACの主なメリットは、その柔軟性です。基本的に、ポリシーの作成は、考慮する必要がある属性と、計算言語が表現できる条件によって制約されます。ABACでは、管理者がサブジェクト/オブジェクトの関係を1つ1つ指定しなくても、最も広い範囲のサブジェクトが最も多くのリソースにアクセスできます。以下の手順を例として考えます。
- サブジェクトが組織に参加すると、サブジェクトの属性セットが割り当てられます（たとえば、John Doeは放射線科のコンサルタント）。
- 作成されたオブジェクトには、その属性（たとえば、心臓病患者の心臓画像検査ファイルを含むフォルダー）が割り当てられます。
- 管理者またはオブジェクト所有者は、アクセス制御ルールを作成します（たとえば、「放射線科のすべてのコンサルタントは、心臓病患者の心臓画像検査ファイルを表示および共有できる」）。
管理者は、組織のニーズに合わせて、これらの属性とアクセス制御ルールをさらに変更できます。たとえば、請負業者やプロバイダーなどの外部のサブジェクトに新しいアクセスポリシーを定義する場合に、サブジェクト/オブジェクトのそれぞれの関係を手動で変更する必要がありません。ABACにより、多様なアクセスの状況に対応でき、管理者による監督がほとんど必要ありません。
新規ユーザーを効率的に有効化
ABACを使用すると、管理者とオブジェクト所有者は、新しいサブジェクトがリソースにアクセスできるようにするポリシーを作成できます。新しいサブジェクトにオブジェクトへのアクセスに必要な属性が割り当てられている限り（たとえば、放射線科のすべてのコンサルタントにそれらの属性が割り当てられている場合）、既存のルールやオブジェクトの属性を変更する必要はありません。
ABACモデルにより、新しいスタッフのオンボーディングや外部パートナーの有効化に迅速に対応できます。
厳格なセキュリティとプライバシー
ABACでは、属性を使用することで、ポリシー作成者は状況によって多くの変動する要素を制御し、アクセスをきめ細かく保護できます。たとえば、RBACモデルでは、人事チームは、給与データや個人情報などの機密性の高い従業員情報に常にアクセスできます。ABACを使用すると、管理者はコンテキストを考慮したスマートなアクセス制限を実装できます。たとえば、人事担当者は、特定の時期に限って情報にアクセスできる、または関連する支社のスタッフに関係する場合にのみアクセスできるといった指定が可能です。
結果として、ABACにより、組織はセキュリティギャップを効果的に解消し、従業員のプライバシーを守るとともに、規制コンプライアンスの要件に効率的に対応できます。
ABACのデメリット
ABACは、コストをはるかに上回るメリットを提供します。しかし、属性ベースのアクセス制御（ABAC）を実装する前に、企業が留意すべきデメリットが1つあります。それは実装が複雑であることです。
ABACは設計と実装が複雑
ABACは、使用開始までの道のりが険しくなる可能性があります。管理者は、属性を手動で定義し、すべてのコンポーネントに割り当て、さまざまな条件（「XであればY」）に基づいて許可される属性を決定する中央ポリシーエンジンを作成する必要があります。また、モデルが属性に重点を置いているため、すべての属性とルールが設定される前に、特定のユーザーが使用できる権限の測定が難しくなります。
ABACの実装にはかなりの時間とリソースが必要ですが、労力をかけるだけの価値があります。管理者は、同様のコンポーネントやユーザー職位の属性をコピーして再利用できます。ABACは適応性に優れているため、新しいユーザーやアクセス状況に対するポリシーを維持することが比較的に「手間いらず」になります。
自社に適したアクセス制御モデルは？
この疑問に対する答えでは、組織の規模が重要な要素となります。ABACは初期の設計と実装が難しいため、小規模のビジネスが使用を検討するには複雑すぎることがあります。
中小・中堅企業の場合、ABACに比べてRBACの方がシンプルな選択肢となります。各ユーザーに固有のロールが割り当てられ、対応する権限と制限が適用されます。ユーザーが新しいロールに移ると、権限は新しい職位の権限に変更されます。つまり、ロールが明確に定義された階層では、少数の内部および外部ユーザーを管理することが容易になります。
ただし、新しいロールを手動で構築する必要がある場合、大規模な組織にとっては効率的な方法ではありません。属性とルールを一度定義してしまえば、ユーザーやステークホルダーが多数でもABACのポリシーを簡単に適用でき、セキュリティリスクも軽減できます。
まとめると、以下の場合にABACを選択することをお勧めします。
- 組織が大規模で、ユーザーが多い
- 特定の詳細なアクセス制御機能が必要である
- 効果の大きなモデルに時間をかけて取り組む余力がある
- プライバシーとセキュリティへのコンプライアンスを確保する必要がある
一方で、以下の場合にはRBACを検討することをお勧めします。
- 中小・中堅企業
- アクセス制御ポリシーが幅広い
- 外部ユーザーが少なく、組織のロールが明確に定義されている
まだ決めかねていますか？ 自社に最適な選択肢を見極めるため、ABACとRBACの詳細な比較をご確認ください。
