View on GitHub

bok

IDPro Body of Knowledgeの日本語訳を載せていきます

ポリシーベースのアクセス制御

著者 メアリー・K・マッキー（デューク大学）

概要

アクセス制御の自然な進化により、多くの組織が、構造化された再現性の高いルールに基づいてアクセスを割り当てたり取り消したりするアクセス管理パラダイムを採用するようになりました。

そのようなパラダイムの1つとして、ポリシーベース・アクセス・コントロール（PBAC）が知られており、次の2つの主要な特徴によって差別化されている。

  1. 他のアクセスコントロールのパラダイムが、すべての関連リソースへのユーザーのアクセスを許可することの容易さを重視しているのに対し、PBACはすべての該当ユーザーにリソースへのアクセスを拡大することの容易さを重視している。

  2. PBAC は、保護されたリソースへのアクセスを許可する際に、コンテキスト（時間帯、 場所など）の評価を容易にします。 コンテキストは、誰がリソースにアクセスできるか、そのアクセスが許可される条件を表すために使用される。

アクセス制御の焦点をユーザーからリソースに移すことで、PBAC システムは、組織構造や規制上の義務の変化に 対して、特に強い耐性を持つことができる。 また、許可されたユーザーの場所やデバイスなどのコンテキストを含めることで、リソースのパーミッション自体に追加のセキュリティコントロールを表現・拡張することができ、アクセスコントロールのすべての側面が単一の構造の中に含まれ、監査可能であることが保証される。

PBACは、誰がどのような状況でリソースにアクセスできるかを非常に正確に表現することができるため、アクセスのプロビジョニングとデプロビジョニングを自動化し、管理を容易にするだけでなく、セキュリティと適応性を高めることができる。

キーワード アイデンティティ、アーキテクチャ、アクセス制御、デジタルアイデンティティ、リスク、ポリシー、自動化、PBAC

引用の仕方

McKee M. K., (2021) “Policy-Based Access Controls”, IDPro Body of Knowledge 1(4).

ポリシーベースのアクセスコントロール

メアリー・マッキー

© 2021 IDPro, Mary McKee

アクセスコントロールの入門書としては、André KootのIntroduction to Access Controlをご覧ください。

この記事へのコメントは、GitHubリポジトリにアクセスして、イシューを提出してください。

はじめに

入退室管理システムは、組織の資産にセキュリティとプライバシーを提供しますが、効果的に機能させるためには、技術、規制、組織構造の急速な変化に対応できるように設計する必要がある。 限られた、主にオンプレミスの情報技術インフラではうまくいっていた戦略も、クラウドサービス、統合されたアイデンティティ、高度なサイバー脅威の時代には通用しなくなる。

初期のアクセス管理システムの多くは、現在、DAC（Discretionary Access Control）と呼ばれるものを利用している。 DACシステム（アクセス制御リストなど）では、管理者は、必要性、適切な使用、および組織のルールに関する理解に従って、ユーザーに手動で特権を割り当てる。 DAC システムは、ユーザ、リソース、管理者、および/または年齢が増加するにつれて、アドホックな管理に依存することで、アクセスの適用と理解に不一致が生じる。 不適切なアクセスは気づかれないことが多く、不十分なアクセスは目に見えるビジネス上の課題を引き起こすため、DAC管理者は、権限を自由に与え、アクセスのクリーンアップの保守作業を行う必要がある。その結果、DAC は、現代のニーズに対して、コストがかかりすぎ、一貫性がなく、柔軟性に欠けることが多くなっている。

現代のアクセス制御システムは、構造化されたルールによってリソースへのアクセスを許可することで、一貫性と効率性を促進することを目的としている。 アクセス制御を抽象化してパーミッションをルールに基づいて付与するモデルとしては、おそらくロールベース・アクセス・コントロール（RBAC）が最もよく知られている。 RBACでは、権限はユーザーに割り当てられた「ロール」と関連付けられる。 このモデルは、同じ責任を持つユーザーに一貫して同じ許可を与えるのに有効であり、ロールとそれに関連する許可を使用する前に定義することを要求することで、ガバナンスを促進する。 さらに、RBACは、リソースのパーミッションが外部のユーザオーソリティから提供される情報に依存するような、フェデレートされた認可シナリオでの使用に適している。これらはDACに比べて改善されているが、RBACのパーミッションは組織内の責任構造の変化には強くなく、パーミッションの定義方法にも制限がある。後述するこれらの欠点により、RBACシステムでは、ユーザーが意図されたビジネス機能を実行するために必要な以上のアクセス権を持たないようにすることが困難となる（最小特権の原則とも呼ばれる 1）。

ポリシーベースアクセスコントロール（PBAC）は、連携または非連携のコンテキストで構造化されたルールによってパーミッションを管理するための、より強固なパラダイムである。RBACモデルが意図的にパーミッションを束ねるのに対し、PBACは属性ベースのアクセスコントロール（ABAC）という概念に基づいて、パーミッションの相互依存を避け、ユーザーの雇用状況やジョブコードなどの情報に基づいて、よりきめ細かなアクセスコントロールを実現する。PBACは、ABACモデルをベースに、ユーザー認証以外のアクセスの許容範囲を表現できるようにしたもので、アクセス制御の定義、適応、自動化の幅を広げるものである。

PBACのパーミッションは個別に設定されているため、ビジネスや規制上のニーズに応じて、コントロールを正確かつ直感的に、段階的に変更することが可能であり、時間をかけてメンテナンスを行う必要がないため、「最小特権」アーキテクチャの可能性を最大限に引き出すことができる。

用語解説

PBAC と RBAC の比較。比較

PBAC構造の理解を深めるためには、RBACとの違いを確認するとよい。

RBAC パーミッションの主にユーザーに焦点をあてるが、PBAC パーミッションは主にリソースに焦点をあてる。

RBACは「どのようなタイプのユーザーがいて、彼らは私の環境で何をすることができるか」を問いかける。 コントロールは、サブジェクト（誰がアクセスするのか）、パーミッション（何にアクセスするのか、何を使うのか）、ロール（サブジェクトにどのようなパーミッションを割り当てることができるのか）で構成される2。 これは次のようなものである。

サブジェクト   ロール パーミッション
エイダ 〜としての エディター ドキュメントを修正可能

PBACでは、「どのような種類のリソースを持っていて、誰がどのように使用・管理することができるか」を問いかける。統制は、主体（誰がアクセスするのか）、行為（どのような行動が議論されているのか）、対象（どのような資源にアクセスしたり使用したりするのか）、文脈（許容されるアクセスを定義する環境やその他のパラメータ）によって構築される3。 これは次のようなものである。

オブジェクト   アクション   サブジェクト コンテキスト
ドキュメント かもしれない 修正される によって エディターの職位を持つ誰か 管理されたデバイスで

これらの例では、すべての編集者に必要な許可を与えるために、主題を抽象化している。RBACの例では、エイダは手動または自動のプロセスで「エディター」ロールに割り当てられているため、許可を取得する。PBACの例では、エイダは、サブジェクトの定義が彼女のアイデンティティ情報と一致するため、パーミッションを取得するが、サブジェクトの定義は、グループ・メンバーシップの割り当てのような手動プロセスである可能性もある。

最もわかりやすい比較をするために、RBACシステムがエイダを「エディター」ロールに追加し、PBACシステムがアクセスポリシーで参照される「エディター」グループメンバーシップに追加したとする。これらのアクションはほぼ同等に見えるかもしれないが、PBACアーキテクチャには、異なる状況をサポートする柔軟性（コンテキスト）、他のパーミッションに影響を与えずに変更を個別に処理する能力（モジュール性）、リアルタイムのパーミッション評価を処理する能力（対称性）といった利点がある。

コンテキスト

エイダの雇用主は、リソースへのアクセス方法に影響を与える法的またはコンプライアンス上の問題に直面している可能性がある。例えば、国家安全保障に関する規制（輸出規制など）により、特定の種類のデバイスからのアクセスが制限されている場合、PBACの関連ポリシーを修正して、この規定を含めることができる。

また、会社がリソースにアクセスする前に何らかのトレーニングを必要としている場合、これもコンテキストとして明確にすることができる。「認証ステータス」属性は、権限を持つ組織の内外から参照される記録に基づいて、エイダに対して維持することができる。エイダのパーミッションは、アクセス時にこのステータスが最新であることを要求できる。エイダがトレーニングに準拠していない場合、アクセスは自動的にブロックされ、トレーニングを再認証すると自動的に復元される。同様に、エイダが許可されたアクセスの条件に同意しなければならない場合、PBACコンテキストは、リソースとのやりとりの前に、この条件が発生していることを確認することができる。

セキュリティ上の理由から、エイダは会社のリソースに安全なネットワークスペースからのみアクセスすることが期待されているかもしれないし、権限の低いユーザーよりも厳しい多要素認証の要件が求められているかもしれない。説明責任のある利害関係者がこのような要件を定義すると、これらもコンテキスト定義で成文化され、強制される。

これらのタイプの制御をアクセスポリシーの外に実装することは可能かもしれないが、そうすると課題が生じる。アクセス時ではなく許可の割り当て時にコンプライアンスを検証すると、コンプライアンスに違反した者がリソースにアクセスできるというギャップが生じる可能性がある。 さらに、組織のアクセス制御システムの外で表現されたアクセス制限を課すと、管理者は、ユーザがリソースにアクセスできるかどうかを権威的に語ることができなくなる。 このため、電子メールの受信者全員が、メッセージ内で参照されているリソースに送信前にアクセスできるかどうかなど、権限付与に関する日常的なビジネス上の疑問に答えることが非常に困難になる。

モジュール化

PBACポリシーで付与されたパーミッションは、RBACのように本質的に相互に関連していないため、高度にモジュール化されており、安心して管理することができる。 組織があるリソースに対する制御を追加、削除、または変更する必要がある場合、そのリソースに対するポリシーは、他のリソースに影響を与えることなく、必要に応じて正確に適用することができる。

RBACのようにパーミッションが束ねられている場合、新しいビジネスシナリオに対応するには、既存のパーミッションのグループを幅広く分析する必要がある。多くの場合、管理者は、必要のないパーミッションを伴う「十分に近い」アクセス権限を定義するか、理解と維持がますます困難になるアクセス権限を多数定義するか、の選択を迫られる。

例えば、エイダの会社の上層部が、投資家向けの機密性の高いブリーフィングを編集するために彼女を選んだとしたら、彼女にはエディターとしては異例のアクセスが必要になるだろう。このようなアクセス権の付与を任されたRBACシステムの管理者は、次のような解決策を検討するだろう。

このようなユースケースを持つ組織では、例外的なアクセスが必要になるたびにRBACロールを再構築することは現実的ではなく、アクセス管理に対するますます無頓着なアプローチを促進することになる。

対称性

アクセスを許可する基準とアクセスを取り消す基準がシステム内で乖離している場合、一時的には適切であっても現在のポリシーでは許可されない権限がシステムに蓄積されることがよくある。PBACシステムは、リアルタイムで参照できる方法でアクセスの許容状況を定義することで、この問題を回避する。

PBACはABACを拡張したものであるため、属性に基づいて完全または部分的に自動化されたアクセスに容易に対応することができる。例えば、ある企業の現在の従業員、オフィスXに勤務する従業員、オフィスXに勤務していて私用休暇中ではない従業員に、自動的にアクセスを許可したい場合がありる。

アクセスの割り当て方を自動化することで、権限の継続的な監視を自動化し、現在のルールで許可されなくなったものを取り消すことが簡単にできるようになる。これにより、アクセスのプロビジョニングとデプロビジョニングの間に対称性が生まれ、時間を節約し、望ましくない残存パーミッションのない環境を確保することができる。

PBACの実用性

PBACに関する最も一般的な懸念の1つは、シンプルなアクセス管理のシナリオにしては複雑すぎるのではないかということだ。

PBACのポリシーは他の戦略に比べて重いと思われるかもしれないが、従来のアプローチに比べて柔軟性が高いため、大企業と同様に小規模な運用にもメリットがある。効率化されたRBACロールで節約された時間は、ロール（またはそれに関連する多くのパーミッション）を変更することによるビジネス上の影響が不明確な場合、すぐに失われてしまう。これは、アクセス制御の積極的かつ責任ある管理を阻害し、あらゆる規模の組織の成長を妨げる可能性がある。

小規模な組織であってもPBACがいかに望ましいかを説明するために、次のようなシナリオを考えてみよう。

JE Plumbingは、5人の配管工と、すべての管理を行うオーナーからなる小さな企業としてスタートした。

優れた評判と顧客数の増加により、オーナーは配管工を20人に増やし、ビジネスマネージャー、3人の営業担当者、2人の財務担当者がサポートしている。

時が経つにつれ、JE Plumbing社は会社のカバーエリアとサービスを拡大する機会を得た。そのため、新たに2つの拠点を設立し、2人の新しいビジネスマネジャー（1人は財務スペシャリストからの昇格者）が監督することにした。住宅用配管工のスタッフを75人に増やし、商業用配管工を25人採用した。 財務と営業のポジションは新しい2つのオフィスに分散し、チームは2人から6人に増えた。また、3つの拠点すべてをカバーするために、専任のマーケティング担当者を採用した。

この問題に対するRBACのアプローチは、オーナーのための管理者ロールと彼女のスタッフのための技術者ロールの2つのロールで始まるかもしれない。会社が成長するにつれ、ビジネスマネージャーが管理者の役割を任せられるようになるかもしれないが、販売と財務のスペシャリストのために新しい役割を作る必要があるだろう。役割が2つから4つに倍増した後、技術者の役割を商業用技術者と住宅用技術者に分け、営業とマーケティングの役割をそれぞれ別の役割に分割し、ビジネスマネージャーとカスタマーサービスの役割を正式に定め、管理者と財務の役割は元のままにして、役割の数を再び倍増させた。

この例では、JE Plumbing社の発展を3つの時点で見ているが、同社が一夜にしてこのような大規模なシフトを実施することはあり得ないだろう。責任の段階的なシフトによってセキュリティを維持するために、限られた運転資金で戦略的な組織調整を行っている中小企業は、今回の演習には含まれていない役割、つまり、RBACロールを永続的に再構築し、それを利用する各システムを適応させることができるフルタイムのIT専門家の不在を考慮すべきである。

PBACのアプローチでは、JE Plumbingが確保する必要のあるリソースは何かを考えることから始める。それは、作業指示書、顧客情報、請求書、在庫、従業員の個人情報とライセンス情報、給与データ、経費報告書です。 これらの機能に対する責任は、会社がスタッフを増やすことによって変わるが、機能自体は変わらない。もし、会社の規模だけでなく、ビジネスの内容が拡大した場合、既存の機能を妨げることなく、新しい機能をサポートするためのパーミッションを簡単に追加することができる。

このように、アクセスコントロールの表現をユーザー重視からリソース重視に変えるだけで、アクセスコントロールの複雑さは指数関数的ではなく、直線的に増加していく。その結果、JE Plumbingは、膨れ上がったロールを管理することなく、組織の変化に合わせて権限を変更することができる。

PBACは、より持続可能であることに加え、アクセスのためのコンテキストを設定することで、企業がリスクを軽減する機会を生み出す。例えば、

アクセス管理のニーズがそれほど高くない組織では、最初はアクセスポリシーのコンテキスト制限などのPBAC機能を見送ることもできるかもしれないが、早期にアクセス管理のためのPBACアーキテクチャにコミットすることで、時間の経過とともにアクセス管理ルールを有機的かつ自然に成熟させることができる。それが、より多くのユーザ、より多くのリソース、そしてより洗練されたセキュリティやリスク管理態勢に対応するためであっても、だ。

RBACが好ましい場合

この記事では、アクセス制御戦略としてRBACが注目されていることから、主にポリシーベースのアクセス制御とロールベースのアクセス制御を比較してきた。

IAM担当者の中には、PBACコントロールの導入に興味があっても、RBACしかサポートしていないシステムで作業しなければならない人もいるだろう。このようなケースでは、組織の役割をリソースや特定の作業機能の観点から再考することは、時間の経過とともに適応することが困難な許可の束ではなく、有利な場合がある。RBACシステムがユーザーの複数の役割に対応している限り、そのシステム内でPBACのいくつかの利点（モジュール性など）を実現することができるはずである。

RBACとPBACのどちらかを選択する際には、PBACがRBACのように動作するように構築することが、その逆よりも信頼性が高いことを考慮するとよいだろう。例えば、「役割」という観点から考えることを好む組織は、グループのメンバーシップをそのように表現することを選択し、それらのグループに多くのリソースパーミッションを割り当てても、最終的な効果は同じである（1つのアクションで定義されたパーミッションのセットが適用される）。逆に、RBACパーミッションにコンテキストの概念を適用するオプションは、しばしば制限される。

PBACの柔軟性と拡張性の向上により、PBACは機密性の高いリソースを保護するための強力な選択肢となっているが、システムレベルでの思考が必要となるため、アクセス管理システムのカジュアルユーザには近づきにくいかもしれない。かなり静的なアクセス制御を行うシステムや、アクセス管理を管理者ではなくエンドユーザに委ねているシステム（コンテンツ作成者が共同作業者に権限を与えるようなシステムなど）では、PBACの堅牢性よりもRBACの親しみやすさの方が価値があると感じるかもしれない。

PBACの実装

成功するアクセスコントロール環境を構築する鍵は、抽象度を慎重に管理することである。抽象化が多すぎると、アクセスコントロールの環境は管理しづらくなり、エラーが発生しやすくなる。また、抽象度が低すぎると、環境が脆弱になり、ビジネス要件に合わせて進化することができなくなる。

ポリシーベースのアクセスコントロールへの投資から最大限の利益を得るためには、以下の指針を考慮するとよい。

再利用可能なコンポーネントの構築

PBACで抽象化を管理することは、他のポリシーに適用可能なポリシーの一部を分離することを意味する。一番わかりやすいのは、ユーザーのセグメンテーションである。

例えば、次のようなポリシーを構築する場合だ。

オブジェクト   アクション   サブジェクト コンテキスト
ユーザープロファイル かもしれない 更新される 〜によって ビジネスマネージャ フルタイム従業員

“ビジネスマネージャ” と “フルタイム従業員” は、他のポリシーで再び使用される可能性が非常に高い。したがって、これらのセグメントの定義を作成して、1つまたは複数のポリシーで使用できるようにすることが賢明である。

これらの定義が細かすぎて硬直化するのを避けるための理想的な方法は、セットロジック、特に交点（セット A AND セット B のメンバーシップ）、組合（セット A OR セット B のメンバーシップ）、および補完（セット A のメンバーシップ、ただしセット B ではない）を可能にするアクセス管理システムの実装だ。

前述の例を発展させて、上記のポリシーが次のような更新を必要とする場合、

オブジェクト   アクション   サブジェクト b
ユーザープロファイル かもしれない 更新される 〜によって デトロイトオフィスビジネスマネージャ デトロイトオフィスのフルタイム従業員

この問題を解決する最善の方法は、通常4、”ビジネスマネージャ”と “フルタイム従業員” の定義を維持したまま、”デトロイトオフィスの従業員” という3番目の定義を追加することである。そうすれば、ポリシーの対象は、ビジネス・マネージャーとデトロイトオフィスの従業員の両方に該当するユーザーにのみ適用されるように更新することができる。

このような操作ができない場合は、”ビジネスマネージャ”と “デトロイトオフィスのビジネスマネージャ” を別々に定義する必要があるかもしれない。グループが具体的で微妙になればなるほど、システムの維持は難しくなるが、優れた命名規則は、将来のポリシー作成者が、”従業員 - 全て”、”従業員 - デトロイト”、”従業員 - ダーハム” などのセグメント間のニュアンスを理解するのに役立つ。

このアプローチにより、RBACと同じように個人のグループにパーミッションを簡単に割り当てることが可能になる。パーミッション間の相互依存を避けることができ、対象者だけでなくオブジェクトもきれいにセグメント化することができ、人以外のもの（デバイスの識別子、IPアドレスの範囲、ドキュメントの分類など）も簡単にセグメント化できるというメリットがある。

ポリシーは、外部で管理されているユーザー／リソースのセグメント／グループ／セットを参照させ、複数のポリシーが同じセットを（場合によっては異なる方法で）使用できるようにするのが最善であることが多いが、ポリシーはサポートするリソースによって直接参照されるべきである。ここで抽象化してしまうと、アクセス管理に対する期待と現実の間に乖離の余地が生じるだけである。

静的アクセスコントロールの調整

PBAC は、リソースに対するリアルタイムの認証に使用されてきたが、アクセスポリシーをリアルタイムで参照できず、内部の静的なパーミッションに依存しているリソースに対しては、アクセスポリシーとプロビジョニングメカニズムを統合する必要がある場合がある。

PBACポリシーを直接参照できないリソースには、現在の組織のアクセスルールでは許可されなくなった既得権が蓄積される傾向がある。例えば、部門間で異動した従業員は、リソースに対していくつかの新しいパーミッションを必要とし、以前のパーミッションのサブセットのみを必要とする場合がある。 ユーザが組織を離れたとき、または管理者の裁量でのみアクセス権を解除することは、管理者にとって適切な移行計画を交渉する負担となり、そのような議論は組織のポリシーではなくユーザの信頼性の問題として行われることが多い。

PBAC環境では、このような設定でアクセスのプロビジョニングを自動化することが可能であるかどうかに関わらず、その取り消しを少なくとも部分的に自動化することが常に可能であるべきである。アクセス管理のオーバーヘッドは、不要になったアクセスを手動で削除することに時間を費やすよりも、認可されなくなったアクセスを即座に失効させるポリシーの定義や、猶予期間やスポンサー付きの期限付きポリシーの例外など、より円滑なアクセスの移行を通じて組織をサポートすることに割り当てる方がはるかに良い。

より静的なアクセスコントロール設定におけるレガシーパーミッションは、管理者の不作為ではなく、自動化プロセスの不備の結果であることがある。これらのレガシーパーミッションは、通常、デプロビジョニングプロセスが、状態（例：ユーザがアクティブなスタッフメンバーではない）ではなく、イベント（例：従業員が解雇された）によってトリガされるために発生する。ユーザーがAのポジションに採用されたか、Aのポジションに昇進したか、Aのポジションに異動したかを監視するのではなく、ユーザーが現在Aのポジションにいるかどうかを決定するPBACポリシーに準拠しているかどうかを監視する方がよい。このアプローチは、ポリシーの表現を合理化すると同時に、アクセス管理者に必ずしも伝えられていないプロセスの変更によって引き起こされる問題を回避することができる。このようにして、人事部は、アクセスプロビジョニングに不用意に影響を与えることなく、ユーザがどのようにしてAのポジションになるのかについての内部プロセスを導入または変更することができる。

ビジネスプロセスは多くの場合、イベントドリブンであるフローチャートを用いて開発される。そのため、アクセス管理システムもイベントドリブンな方法で実装されることが多い。堅牢なPBACポリシーに変えることができるアクセスルールをワークショップで作成するには、フローチャートの矢印をやめて、条件を表す円だけで作業することを検討する。これらの円をベン図またはオイラー図5として配置することで、アクセスの許容条件を議論することができ、よりすっきりとした強固なポリシーを実現することができる。

イベントベースのパーミッションデザイン ステートベースのパーミッションデザイン
見た目の特徴: フローチャート 見た目の特徴: 重ね合わせた円
結果として厳密なワークフロー、ポイントインタイムの検証、複雑なデプロビジョニングロジック 結果として柔軟で並列的なワークフロー、継続的な検証、調和の取れたプロビジョニングとデプロビジョニング

イベントベースのプロビジョニングの決定が、アクセスコントロールシステムの最善の意図を損なう理由はいくつかある。

一般的に、状態につながるイベントの数は、状態そのものよりも多く、不必要な複雑さを生み出す。

アクセス管理チームは、イベントの変更（スタッフを雇用するために使用できる プロセスの数、企業ネットワークの変更、インフラストラクチャのアップグレードなど）よりも、 関連する状態（雇用、企業ポリシー、業務機能など）の変更について通知を受ける可能性がはるかに高い。アクセスを促すイベントの検出に影響を与えるように部門のプロセスが変化すると、アクセス管理チームは結果として生じる不整合を調査する責任を負うことになり、システムが意図されたとおりに機能していると確信することができない。

イベントはある時点で発生するため、その適切性を監査することがより困難になる。例えば、改訂されたレガシープロセスによってアクセス権を持っている人（アクセス権を維持すべき）や、デプロビジョニングを行おうとした時にネットワークの不具合によってアクセス権を失った人（アクセス権を失うべき）がいるかもしれない。現在のポリシーと比較することができなければ、既存のパーミッションが適切であるかどうかを判断することは非常に困難であり、システムに対する信頼性はさらに低下する。

アクセスをイベントではなく観測可能な状態で定義することにより、アクセスルールを PBAC ポリシーとして表現することができる。これにより、コントロールの継続的な調整が可能になり、リアルタイムでポリシーを参照できないシステムでもレガシーなアクセスを排除することができる。また、このアプローチは、既存のポリシーと提案されたポリシーの下で許容されるアクセスを比較することで、アクセスコントロールの進化をサポートする。

プライバシーの保護

PBACに関するより学術的なガイドラインでは、「ポリシー決定点（PDP）」と「ポリシー実施点（PEP）」と呼ばれることがある。 誰かがアクセスする資格があるかどうかを決定する中央機関（PDP）は、特定の個人がポリシーに含まれたり除外されたりした理由を明らかにすることなく、その決定の基準を公開することができる。 これにより、下流のリソース（PEP）は、センシティブな情報をシステム間で伝播させることなく、組織的なアクセス・ポリシーを実施することができる。

より実用的な例として、連邦法の対象となる科学機器のアクセス管理を考えてみよう。この機器は、すべてのユーザが自国の市民または合法的な永住者であり、さらに過去3年以内に実施された身元調査に問題がないことを条件としている。アクセス管理システム（PDP）が下した決定に基づいて、機器（PEP）がポリシーを実施するように設定することで、管理組織は市民権、移民ステータス、バックグラウンドチェックの結果を機器に送信しなくて済む。このようにして、組織は、センシティブなユーザデータを管理するリソース全体（または、連携したコンテキストでは、組織の境界を越えて）に伝播させることなく法的義務を果たすことができ、この情報の露出を大幅に減らすことができる。

ガバナンスと監査のサポート

優れたアクセスコントロールシステムは、アクセスガバナンスに携わる監査人やビジネスオーナーが、組織のアクセスコントロールにおける既存の前例を理解し、それらをどのように拡張または修正する必要があるかを分析し、提案された変更がビジネスに与える影響を確認することを可能にする。

PBAC システムを設計する際には、サブジェクト、アクション、オブジェクト、およびコンテクストが、これらのどの視点からのアクセスについても簡単に報告できるような方法で保存されていることを確認することが重要です。 ビジネスオーナーや監査人は、ユーザーのアクセス権、対象となるリソースにアクセスできるユーザー、リソースに定義されたアクションに対する許容されるコンテキストなどの質問に答えるレポートに簡単にアクセスできる必要がある。

PBACパーミッションの表現力は、ポリシー内ですべてのアクセスに関する考慮事項を定義することを現実的にする。このような柔軟性は、組織のアクセス制御システムの外部で追加のセキュリティ対策（IP制限など）を実施する場合に有利に働く。また、アクセスが許可されている状況について、単一の情報源として把握することができる。

このような方法でパーミッションをレポートできることで、リソースへのアクセスに関する現在のルールの調査が容易になる。優れたレポートには、現在これらの基準を満たしているユーザーも含まれます。PBAC は、すべての潜在的な利用者のアイデンティティ（およびその他のコンテクスト）情報がリソー ス管理者に提供されないような、統合された状況で使用されることが多いが、このような利用者の報告は、特に提案された変更の状況において、抜き打ち検査に役立つことがある。提案されたポリシーの下で誰がアクセス権を得たり失ったりするかについてのレポートは、ビジネスオーナーや監査人が組織のニーズとセキュリティを最も円滑にするためにコントロールを改良する際に役立つ。

結論

アクセス管理システムは、ユーザー、担当者、責任、組織構造、法的義務などの変化に対応して、組織のミッションを促進し、保護するものです。 アクセス管理の失敗の多くは、システムアーキテクチャが手動で拡張できなかったり、コストと時間のかかる再アーキテクチャ作業なしではビジネスのペースに合わせて変更できないほど脆弱であることが原因である。

アクセス制御システムを最適化してアクセス許可の効率を高めようとするのはよくあることだが、堅牢なアクセス制御システムの本当の評価は、アクセスをいかに確実に取り消すことができるかということだ。ポリシーベースのアクセス制御は、アクセスの割り当てと取り消しを論理的に対称化することにより、最小特権のセキュリティ原則をサポートする。アクセスに関する要件を定義することにより、手動で割り当てられたアクセスであっても、その有効性を動的に検証し、現在のポリシーに基づいてアクセスが無効になった時点で、自動的に取り消したり報告したりすることができる。

リソースファーストの観点からアクセス制御を設計し、これらの制御にコンテキストの概念を加えることで、PBACシステムはアクセス割り当ての利便性よりもリソースの安全性を最大限に高めることができる。これらのシステムは、当初は他のアプローチよりも複雑になる可能性があるが、ポリシーのアトミックな性質と、レガシーパーミッションの蓄積に対する相対的な回復力により、RBACのようなより限定的なルールベースのアクセス管理システムと比較して、長期的なメンテナンスが可能なシステムとなる。

著者プロフィール

デューク大学でアイデンティティ管理およびセキュリティサービスのディレクターを務めるメアリー・マッキーは、学部でコンピュータサイエンスを学んだ後、ウェブアプリケーション開発者として採用された。その後、抽象化と相互運用性に興味を持ち、アイデンティティ・アクセス・マネジメント、そして情報セキュリティの分野に進んだ。

謝辞

本記事の初期バージョンに丁寧な回答をいただいたAndré Koot氏とAndrew Hindle氏、本記事の開発にフィードバックとサポートをいただいたHeather Flanagan氏、Christienna Fryar氏、Dave Wible氏、Mary Ellen Wible氏に感謝いたします。

  1. “Least Privilege,” https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege (accessed February 10, 2020)︎。 ↩

  2. “Role-based access control”, https://en.wikipedia.org/wiki/Role-based_access_control (accessed February 10, 2020)︎ ↩

  3. “Attribute-based access control”, https://en.wikipedia.org/wiki/Attribute-based_access_control (accessed February 10, 2020)︎ ↩

  4. 本節の例は、ID プロバイダ（またはユーザー属性ストア）とサービス・プロバイダ（または保 護対象のリソース）の両方が共通の環境内に存在するコンテキスト内でのセット数学能力の最適化を 説明するためのものであり、サービス・プロバイダが 1 つ以上の外部制御された ID プロバイダと相互に作用する可能性がある連携コンテキストには適用されない。ただし、PBAC（/ABAC/CBAC）がこれらの外部性に容易に対応できることは注目に値する。 ↩

  5. “Euler diagram,” https://en.wikipedia.org/wiki/Euler_diagram, (accessed February 25, 2020)︎。 ↩