はじめに
従来のRBAC(役割ベースアクセス制御)の手法が進化し、ABAC(属性ベースアクセス制御)が登場しました。ABACは、異なる属性を活用することでより正確な制御を実現します。利用者、環境、リソースの各属性が選択可能となった今、SaaS事業者はより複雑なユースケースにも対応できます。他のトピック、例えばABACの具体例に進む前に、まずABACの意味について説明します。
属性に基づくアクセス制御(ABAC)とは、リソース、オブジェクト、環境、利用者属性などの様々な属性に基づいてアクセス制御ポリシーを決定する認可手法です。ABACは「もし〜なら」という形式のルールを用いて、利用者、リクエスト、リソース、操作をブール論理で示します。
リクエスト者が会計士である場合、金融情報への読み書きアクセスを許可します。
特定の業務要求や管理上の制約に合わせた属性を用いることで、ABACは組織が柔軟なアクセス制御戦略を構築できるようにします。米国連邦政府が実装の優先目標とした後、米国国立標準技術研究所(NIST)は、事業環境におけるABACの実施方法について一連の基準を示しました。
特定の目的でリソースを利用しようとリクエストする人を利用者(サブジェクト)と言います。例えば、ユーザープロフィールの利用者属性には、ID、業務上の役割、グループ所属、部署や組織、管理レベル、セキュリティクリアランスなどが含まれます。ABACシステムは通常、これらの情報をカタログや人事システム、あるいはサインイン時に利用する認証トークンから取得します。
利用者がアクセスする必要のある資産や項目をリソースと呼びます。例としては、ファイル、アプリ、サーバー、あるいはプログラミングインタフェースなどが挙げられます。個々のファイルの作成日、所有者、ファイル名、種類、情報の機密性などがリソース属性の証拠となります。例えば、オンラインバンキングにアクセスするための資産は「銀行口座=正しい口座番号」といった情報になります。
利用者がリソースで行おうとする行動が操作です。一般に「読む」、「書く」、「編集」、「コピー」、「削除」といった表現が使われます。場合によっては、一つの操作が複数の属性で示されることもあります。オンラインバンキングの例では、取引リクエストが「操作タイプ=移動」「金額=200ドル」といった形で表されることがあります。
各アクセスリクエストは、その時々の環境内で行われます。環境属性は、アクセス試行の日時や場所、利用者が利用するデバイス、通信プロトコル、暗号化の強度など、重要な要素に関連しています。さらに、情報源の信頼性や利用者の通常の行動パターンなど、リスクを示す情報も含まれる場合があります。
アクセス時に取り込まれた各属性の特性は、その属性値と呼ばれます。ABACでは、これらの属性値がポリシーと照合され、利用者が適切な操作を実施できるよう、どの属性の組み合わせが許可されるかが示されます。
各ABAC設定は、環境内の属性や属性同士の組み合わせを踏まえたルール・ポリシーを評価します。これにより、どのアクセス条件が許可されるか判断されます。
例として、以下のようなケースを考えてみましょう:
"利用者がコミュニケーション関連の業務に従事している場合、担当する事業部のメディア戦略に対し、読み書きアクセスが許可されるべきである。"
アクセスリクエストが行われる際、ABACシステムは各属性値が規定ポリシーに適合しているか検証します。以下の属性が揃っていれば、どれほどその規則が有効であってもアクセスが許可されるべきです:
利用者の「職種」=「コミュニケーション」
利用者の「事業部」=「マーケティング」
操作=「編集」
リソースの「タイプ」=「メディア戦略文書」
リソースの「事業部」=「マーケティング」
ABACは、細かいポリシーベースのアクセス制御を実現することで、多様な属性の組み合わせにより、必要なアクセス条件を柔軟に設定できるようにします。
ABACシステムには、組織のセキュリティ向上に寄与する様々な利点があります。以下に一例を示します:
ABACは、役割に基づくアクセスを許可するRBACとは異なり、属性に基づきアクセスを制御します。これにより、情報セキュリティに対してより適切な対応が可能となります。また、ABACはアクセス時に複数の要素を考慮するため、RBACでは実現しにくい追加の安全性を提供します。
例えば、RBACでは営業担当者はその役割に基づいて常に取引先情報にアクセスできますが、ABACの場合、場所や時刻、行動(情報の閲覧、変更、削除)などの特定属性に基づきアクセスが制限されることがあります。これにより、利用者管理者は様々な属性をアクセスの基準として重視し、各アクセス時の安全性を高めることが可能です。
ABACは属性に基づいてアクセスを設定するため、RBACと比べ、1つの方法を複数の役割に効果的に適用できます。これにより、単に役割に依存するのではなく、様々な要素に基づいたアクセス制御が可能となります。
RBACシステムでは、各営業担当者に個別の役割を設定しなければならない場合がありますが、ABACでは、全営業担当者に共通の役割を設定しつつ、業種や取引件数などの属性による制限を加えることで、従来のRBACよりも安全性を高めることが可能です。
ABACセキュリティの短所について見てみましょう。
ABACを情報セキュリティプログラムに導入するのは、設定が完了すれば容易ですが、組み込む段階では、多数の属性定義やルール策定、実装に多くの時間とリソースが必要となるため、挑戦的な面があります。しかし、一度導入すれば非常に高いセキュリティと柔軟性を発揮します。
ABACは属性に依存し、RBACは役割に基づいて利用者のアクセスを認証します。どちらも十分に機能しますが、ABACのほうがより柔軟です。
RBAC
RBACシステムの主な利点は、個々の利用者ではなく役割に基づいてアクセスの付与や解除を行う点にあります。少規模な企業では、細かい役割設定が有用ですが、企業が成長すると柔軟性に欠けることがあります。
ABAC
ABACの主な利点は、属性に基づいてアクセスを設定できる点です。役割だけでなく、複数の属性を活用することで、より高いセキュリティを実現します。その反面、複雑さが主な短所となる場合がありますが、実装後はメリットがデメリットを上回ります。
主要なクラウドサービス供給者が提供するアクセスモデルのひとつにABACがあります。2大クラウド供給者であるAmazon Web Services(AWS)とMicrosoft Azureは、以下のようにABACを実装しています。
Amazon Web Services(AWS)のIAM(アイデンティティとアクセス管理)サービスの一部としてABACが提供されています。AWSのABACは、以下の手順で機能します:
ABACは、複雑なポリシー管理が求められる環境や急速に変化する状況下で効果を発揮します。組織はAWS ABACを活用してAWS資産のアクセス管理を行い、グループや資産がAWSポリシーの変更を最小限に留めながら拡張できるようにします。また、役割や利用者を指定する際、セッションタグを付与し、そのタグ条件を利用してプリンシパルにアクセスを許可するポリシーを構築することが可能です。
SAMLに基づくアイデンティティプロバイダー(IdP)を使用する組織は、SAML属性を利用してAWSクラウド内できめ細かなアクセス制御を実現できます。例えば、コストセンターの識別子、プロジェクトや部門の割り当て、利用者のメールアドレスなどが挙げられます。これらの属性は、セッションタグとして送信することでAWSアクセスを制限するために用いられます。
Microsoft Azureは、クラウドサービス供給者としてRBACとABACの両方のアクセス管理オプションを提供しています。AzureのRBAC認可システムは、役割定義と役割割り当てによってAzure資産へのアクセスを管理します。特定の操作に属性ベースの役割割り当て条件を追加することで、Azure ABACはAzure RBACを拡張します。
より精密なアクセス制御を実現するため、役割割り当てに追加の条件を設けることが可能です。役割の定義や割り当ては条件で絞り込みができ、例えば特定のタグが付与されたオブジェクトのみが閲覧可能とする要件を設定できます。ただし、特定の資産へのアクセスを直接条件で制限することはできません。
Azure ABACを利用することで、役割割り当ての数を削減することが可能です。Azureサブスクリプションには現時点で役割割り当ての上限があるため、多数の割り当てを管理する場合は、制限を設けることが求められます。
最新情報を購読