属性ベース アクセス制御（ABAC）とは、特性（部門、場所、責任者、時刻など）に基づいてポリシーを設定、施行する認可方法です。ポリシー ベース アクセス制御（PBAC）またはクレーム ベース アクセス制御（CBAC）とも呼ばれています。ABACでは、ブール論理を使用して、if-thenステートメントを含むアクセス ルールを作成します。if-thenステートメントでは、ユーザー、リクエスト、リソース、アクションを定義します。たとえば、申請者が営業担当者の場合、顧客管理システム（CRM）への読み取り/書き込みアクセス権限が付与されます。一方、申請者が管理者の場合、レポートを作成するための表示権限のみが付与されます。
ABACにより、コンテキスト認識型の動的なセキュリティを提供し、複雑化するIT要件に対応することができます。ABACのユース ケースには、次のようなものがあります。
- データ、ネットワーク端末、クラウド サービス、ITリソースを、未認証のユーザーや不正行為から保護
- マイクロサービス/アプリケーション プログラミング インターフェース（API）を保護し、機密トランザクションの露出を防止
- ユーザーごとにポリシーを決定できるようにすることで、動的なネットワーク ファイアウォール制御を実現
ABACの構成要素
属性とは、アクセス イベントで使用されるコンポーネントの特性または値です。これらの属性は、複数のデータソース（ID管理システム)、企業資源計画（ERP）システム、社内人事システムからの社員情報、顧客管理システム（CRM）からの顧客情報、LDAPサーバーなど）から取得できます。
ABACでは、複数の属性を使用して認可を実行し、より詳細な職務分掌などのアクセス制御アプローチを提供できます。
管理者が不正行為のリスクを軽減し、コンプライアンスを維持するためのポリシーをどのようにすばやく策定できるのかをご覧ください。アクセス権限を付与するかどうかを判断する際に使用できる特性には、次のようなものがあります。
サブジェクト/ユーザー属性
サブジェクト/ユーザー属性は、アクションを実行するために誰がリソースへのアクセス権限を取得しようとしているのかを記述します。これには、ユーザー名、年齢、役職、国籍、ユーザー アイデンティティ（ID）、部門、会社、セキュリティ クリアランス、管理レベル、その他の識別基準が含まれます。ABACシステムでは、ログイン時に使用される認証トークン、またはデータ ベースやシステム（LDAP、人事システムなど）からこれらの属性情報を収集できます。
オブジェクト/リソース属性
オブジェクト/リソース属性には、アクセス権限の申請を受信したオブジェクトまたはリソース（ファイル、アプリケーション、サーバー、APIなど）の特性が含まれます。オブジェクト/リソース属性の一例には、作成日、最終更新日、作成者、所有者、ファイル名、ファイル タイプ、データの機密性などがあります。
環境/コンテキスト属性
環境属性は、アクセス権限の申請、付与に関する広範なコンテキストを提示します。環境属性には、さまざまなコンテキスト項目を指定できます。一例には、アクセス試行の時間と場所、サブジェクトの端末タイプ、通信プロトコル、認証の強度、サブジェクトの通常の行動パターン、過去24時間以内に実行されたトランザクション数、サード パーティとの関係などがあります。
アクション属性
アクション属性は、ユーザーがリソースに対して実行したい操作を示します。アクセス権限の申請、付与における一般的なアクション属性の例には、表示、読み取り、書き込み、コピー、編集、転送、削除、承認などがあります。これらの属性は、単独で使用するだけでなく、複数の属性を組み合わせてより複雑なシナリオに対応することもできます。
サブジェクト/ユーザー属性 | オブジェクト/リソース属性 | 環境/コンテキスト属性 | アクション属性 |
|---|---|---|---|
クリアランス | 作成者/所有者 | 現在の日付 | 削除 |
ABACの仕組み
ABACでは、ユーザーの行動ではなくユーザーの身元に基づいてアクセス権許諾を行うため、詳細な制御が可能になります。属性を分析して、環境内での属性間の関係を評価し、その関係に基づいてルールを施行します。
一般的なプロセスは次のとおりです。
- アクセス権限の申請を行います。
- ABACツールを使用して属性をスキャンし、既存のポリシーと一致するかどうかを判断します。
- ABACツールの分析結果に基づいて、アクセス権限を付与するかどうかを決定します。
ABACの利点
ABAC認可モデルは、その独自の機能により、組織に次のような強力なメリットをもたらします。
幅広いポリシー
ABACでは、計算言語で表現できる属性と条件に制約があるものの、実質的にあらゆる種類のポリシーを作成できます。
ABACにより、状況変数を制御して、ポリシー策定者が詳細なアクセス権限を実装できるようにします。
また、管理者は、スマート アクセス制限を使用してコンテキストを取得し、セキュリティ、プライバシー、コンプライアンスに関するインテリジェントな意思決定を下すことができます。たとえば、ある社員グループが、特定の時間帯や場所でのみ、特定の種類の情報にアクセスできるようにします。
使いやすさ
ABACは、テクニカル権限セットを基盤とする、直観的で使いやすいインターフェースを備えています。適切な権限を有していれば、誰でもユーザー プロファイルを更新できます。また、属性が最新の状態であれば、ユーザーは必要なアクセス権限を確実に取得できます。さらに、管理者は、各ユーザーやオブジェクト間の関係を指定することなく、最大数のユーザーに利用可能なリソースへのアクセス権限を付与できます。
新規ユーザーの迅速なオンボーディング
ABACモデルを使用すると、管理者やオブジェクト所有者がポリシーを作成し、新規ユーザーにリソースへのアクセス権限を付与する属性を割り当てることができるため、新入社員や外部パートナーのオンボーディングを迅速化できます。ABACでは、このアクセス権限を付与するために既存のルールやオブジェクト特性を変更する必要はありません。
柔軟性
ABACを使用すると、ほぼあらゆる属性を表現できます。さらに、コンテキスト要因（ユーザーがアクセスできるアプリケーションやデータの種類、送信できるトランザクション、実行できるオペレーションなど）に基づいて、属性を自動的に変更できます。
法規制遵守
ABACの詳細なアクセス権許諾、制御により、セキュリティを強化できます。これにより、組織は、法令で規定されている、個人を特定できる情報（PII）やその他の機密データを保護するためのコンプライアンス要件を遵守できます。これらの法令には、HIPAA法（米国における医療保険の相互運用性と説明責任に関する法令）、GDPR（EU一般データ保護規則）、PCI DSS（ペイメント カード インダストリー データ セキュリティ基準）などがあります。
拡張性
ABACを導入すると、管理者は同様のコンポーネントやユーザーの役職に対して属性を複製、再利用できるため、ポリシーのメンテナンスと新規ユーザーのオンボーディングを簡素化できます。
ABACの課題
ABACを導入すれば、その後の拡張やセキュリティ プログラムへの統合を容易に行うことができます。ただし、導入して利用を開始するまでには、ある程度労力を要します。ABACのメリットが課題をはるかに上回ることは、多くの人が同意するでしょう。しかし、考慮すべき点が1つあります。それは、実装の複雑さです。管理者はABACを実装するために、次のことを行う必要があります。
- すべてのコンポーネントに属性を割り当てる。
- メインのポリシー エンジンを作成し、さまざまな条件（XならばY）に基づいて、属性にどのような操作を許可するのかを決定する。
- すべての属性を定義する。
- すべての属性とルールを設定する前に、特定のユーザーが取得できる権限を評価する。
- 認可ポリシーをマッピングし、アクセス権限を統制するための包括的なポリシー セットを作成する。
ABACとRBACの比較
ABACとRBAC（ロール ベース アクセス制御）はどちらも、アクセス権限管理手法です。ABACとは異なり、RBACでは、フラット ロールまたは階層ロールに基づいてアクセス権限を付与します。ロールは、一連のエンタイトルメントまたは権限として扱われます。
| ABAC | RBAC |
|---|---|
| 属性とポリシーを使用して、既存のロールを拡張（例：関連するアクション、リソースの特性、場所、時間、アクセス権限の申請、付与方法） | 各ユーザーにロールを割り当てる |
| インテリジェントな意思決定に基づく認可 | 認可では、ロールと関連する特権のみを考慮 |
| ポリシーは、各属性に基づいて自然言語で構成される（コンテキストも含まれる） | アクセス権限はロールのみに基づいて付与される |
| 管理者は、ポリシーを作成し直すことなく属性を追加、削除、再編成できる | 新規ロールを手動で定義する必要がある |
| アクセス権限を詳細に定義 | 企業全体で広範なアクセス権限を付与 |
ABACとRBACの選定
ABACとRBACのどちらを採用すべきかどうかは、企業の規模、予算、セキュリティのニーズによって異なります。ABACの初期実装は煩雑で、膨大なリソースを要するため、企業の規模が選定を大きく左右します。
| ABAC | RBAC |
|---|---|
| 複雑な実装プロセスをサポートするリソースがある | アクセス制御が必要だが、複雑な実装プロセスのためのリソースが不足している |
| 動的なロールを持つユーザーが数多くいる | 組織内でグループを明確に定義している |
| 堅調な成長を遂げている大規模組織 | 組織の大幅な成長は期待できない |
| 社員が複数の地域に分散している | 社員が単一の拠点に集まっている |
| 高度かつ特殊なアクセス制御機能が必要 | 広範なアクセス制御ポリシーに対応 |
ABACとRBACを組み合わせたハイブリッド アプローチ
ABACとRBACを組み合わせて使用すると、ABACの柔軟なポリシー仕様、動的な意思決定機能と、RBACのポリシー管理のしやすさの両方を享受できます。ABACとRBACの両方を活用することで、強力なセキュリティを提供し、ITリソースを最適化できます。
このハイブリッド アプローチ（ARBAC）により、IT管理者は基本的なアクセス権限を自動的に付与できます。また、オペレーション部門は、ビジネス構造に応じて調整されたロールを通じて、特定のユーザーに追加のアクセス権限を付与できます。ロールを属性に依存させることで、検索や設定を行うことなく、特定のユーザーに制限を自動的に適用できます。
これにより、アクセス権限の割り当てを簡素化し、管理する必要があるユーザー プロファイルを最小限に抑えることができます。IT部門は、ARBACを導入することで、ユーザーのオンボーディング、オフボーディングのワークロードを、社内の意思決定者に委託できます。
たとえば、ARBACを使用すると、ユーザーのロールに基づいたプロファイル ベースの職務を通じて任意のアクセス制御を適用しながら、特定の属性に基づいたアクセス制御を施行できます。また、職務分掌を可能にする相互排他的な特権を付与し、リスクに適応できるアクセス制御モデルをサポートすることもできます。
ABACで組織のセキュリティをサポート
ABACは、主要な認可モデルとして、多くの組織で広く採用されています。ABACは、強力なアクセス制御を実現するだけでなく、セキュリティ管理の負担を軽減します。
