View on GitHub

bok

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

抄録

その名の通り、IAM（Identity and Access Management）は、ID情報の管理とアクセス制御の実行という2つの機能に分かれている。有利にも、アクセス制御の要件がなければ、アイデンティティ管理の必要性はありません。そのため、IAMの専門家にとっては、これが焦点となっている。アクセス制御の核心は、ユーザーが保護されたリソースにアクセスするために認証されることを保証することである。これは、ユーザーがアクセスする権利を与えられたシステムと情報にのみアクセスできるように、ユーザーの権限を管理し、依存アプリケーションの要件を満たすことで達成されます。この記事では、アクセス管理の歴史、期待される現在の機能、そして今後のトレンドについて見ていきます。

キーワード: Access Control, Authorization, Governance, Risk, Authentication, Future

引用の仕方:

Koot A., (2020) “Introduction to Access Control”, IDPro Body of Knowledge 1(2).

2020年6月18日発行

査読付き

ライセンス CREATIVE COMMONS ATTRIBUTION-NONCOMMERCIAL-NODERIVS 4.0

アクセスコントロールの紹介

By André Koot

© 2020 IDPro, André Koot

序章

概念としてのアクセスコントロールには長い歴史があります。しかし、現在の課題と解決策を調査するために、まず、非常に古い伝統的な政府機密文書のモデルを評価することから始めましょう。

ファイルに保存されている文書の情報は、通常、誰もがアクセスできるものではありません。情報は機密情報である可能性があり、必要なクリアランスレベルを持つ人だけが機密ファイルにアクセスできるようにすべきである。物理的な形態では、この管理は比較的簡単です。高度に機密化された情報の入ったフォルダは、赤い糸くずで固定され、「トップシークレット」または「フォーユアアイズオンリー」のスタンプが押されています。1

しかし、この単純な例では、すでにセキュリティの異なる基本的な概念を扱っています。

まず、情報そのものがあります。情報をトップシークレットに分類することはできますが、それは、情報の所有者、文書、フォルダなど、適切なレベルの権限を持つ人が定義しなければなりません。そして、分類レベルがどのような影響を与えるかを明確にしなければなりません。分類レベルは、情報へのアクセスや情報の使用の異なるレベルを区別するために必要です。 フォルダの所有者は、どのようなレベルの分類が適用可能か、どのようなタイプのユーザーがアクセスできるかについて、おそらく何らかのガイダンスを持っているでしょう。

第二に、情報の利用者であるアクターのクリアランスレベルがある。この場合、シークレットサービスのエージェントは、異なるセキュリティレベルの情報へのアクセスが許可されるような方法で、信頼されるように識別され、審査されているでしょう。

第三に、正しいセキュリティクリアランスレベルを持つ者だけが機密情報にアクセスできることを保証するために、分類レベルとクリアランスレベルをマッピングしなければならない。所有者は文書を分類し、特定のセキュリティレベルはエージェントの事前に定義された信頼レベルによってのみアクセスできることを受け入れることになる。

そして第四に：シークレットサービスのエージェントにフォルダを与える前に、アーカイブにファイルを保存し、取り出す責任を負う人(ファイルマネージャまたはアクセスコントローラ)は、ファイルを要求するエージェントが実際には正当なユーザーであるかどうかを確認しなければならない。したがって、アクセスコントローラは、エージェントを特定しようとします。この検証は、エージェントがそのフォルダにアクセスする権限を持っていることを証明するために、シークレットサービスのバッジと署名入りの手紙を見せることで行うことができます。ファイル管理者は、もちろん、手紙の署名が正しいことを検証しなければならない。

これらの責任が果たされた後にのみ、フォルダはシークレットサービスのエージェントに引き渡されます。引き渡しは、その後、ジャーナルに登録されます。

アクセスコントローラは常にアクセスを監視しており、フォルダを閉じるために使用される赤い糸くずをチェックすることで、これを簡単にしています。この例では、情報の盗難（データ漏洩など）もかなり物理的なもので、フォルダが削除されます。赤い糸くずの有無にかかわらず、その辺に転がっているのが見つかるかもしれません。

このシナリオでは、アクセス制御は非常にシンプルです。アクセスは、パーソナル バッジで示されたクリアランス レベルに対応する人物にフォルダを物理的に渡すことで許可され、特定の場所へのアクセスを制限することでさらに強化されます。

以下のようなトピックを見ることができます。:

  1. 情報の分類：これはリスク管理の側面です。
  2. ユーザーの分類：これはアイデンティティ管理の側面である。
  3. 認可マッピング: これは認可管理に属する
  4. 認証：この検証は、アイデンティティ管理とアクセス管理の両方に含まれています。
  5. アクセスが許可されました：これはアクセス制御です。

コンピュータの出現以来、システムや文書、その他の保護されたリソースへのアクセスを制御する必要性がありました。コンピュータの初期の時代には、アクセス制御メカニズムをモデル化するために、古いスパイ映画の時代に類似したプロセスが使用されました。リソースの所有者」や「リソースの読者」といった概念が使われていました。プログラマは、裁量アクセス制御(DAC)（「アクセスコントローラを迂回してはならない」という機能で、Windows NTFSファイルシステムに今でも見られる）や強制アクセス制御(MAC)（「特定の部屋の専用ワークステーションなど、特定の場所でしかデータにアクセスできない」）のようなアクセス制御メカニズムを開発しました。2 , 3 情報技術の急速な発展に伴い、アクセス制御の開発と改善の必要性が高まってきました。ユーザー数の増加、システム数の増加、処理される情報の指数関数的な増加は、紙の世界の比喩がデジタルの世界では持続可能ではないことを明らかにしています。

信頼レベルの概念（例えば、個々の文書読取者のクリアランスレベルを管理すること）は、実装が難しいことがすぐにわかりました。なぜなら、非常に多くのアクターがそれに合わせて行動しており、もはや物理的なセキュリティ管理が行われていないからです（赤い糸くずが見えない）。その代わり、フォルダやファイルの複数のコピーが複数の場所に存在することさえあり、盗難はもはやデータがなくなることを意味しませんが、データはおそらく所有者の同意なしにコピーされることになるでしょう。物理的に簡単だったことが、デジタルの世界では簡単には実現できない。しかし、「識別」「認証」「認可」「アクセス制御」「ログ」「監査」で学んだことは、そのままにしています。

情報、データ、サービス、システムへのアクセス、および物理的な場所へのアクセスは、セキュリティポリシーによって管理されます。これらのセキュリティポリシーは形式化されていなければならず、リソースの所有者が実施する必要があります。そうすることで、所有者は、情報の乱用、データ漏洩、盗難、詐欺、その他のセキュリティ上の脅威など、アクセスに関連するリスクを管理しようとします。管理を行うためには、所有者は、配置されたセキュリティ管理によって達成可能なセキュリティレベルの保証を持つ必要があります。

アクセス制御の概念とは別に、所有権はそれ自体が複雑なテーマである。データの所有権の概念を見ると、所有権を確立するための多くの基準を特定することができます。誰かが情報の所有者になることができるのは、以下の理由からです。:

所有者を特定するための基準は他にもたくさんあるが、これはデータガバナンスの一部であり、この記事の対象外である。医療ファイルの場合、オブジェクトである患者は、データに対するいくつかの固有の権利を持っており、この人がアクセスの決定に対して部分的に責任を負うことになります。アクセス制御の共有責任の概念については、IDPro BoKのアクセスガバナンスについての別記事で説明します。

専門用語

略語

AAA: 認証、認可、説明責任

上の分類された文書の例で示したように、アクセスを得るためには、認証されたIDが鍵となります。このパラダイムの背後にある考え方は、AAAの概念で要約することができます。

認証

認証とは、アクセスを要求するデジタル ID を持つユーザーがその ID の正当な所有者であることを証明するプロセスである。これは、パスワードを使用するのと同じくらい簡単なものから、デジタル証明書を提供するのと同じくらい複雑なものまであります。アクセス供給者とアクセス要求者の両方が、認証プロセスの結果を管理し、利用することができなければなりません。

チャレンジ - レスポンス

ユーザーは、秘密のコードやパスワードのように、アクセス要求者とアクセス供給者だけが知っている秘密を提供することで、この正当な利用を証明することができるかもしれません。基本的なメカニズムは、チャレンジレスポンスと呼ばれています。アクセス供給者はアクセス要求者に自分の身元を証明するようにチャレンジし、対象者はアクセス供給者が期待する方法で応答しなければなりません。チャレンジレスポンスを行う最も簡単な方法は、パスワードやピンコードを要求することです。しかし、多くのウェブサイトに搭載されているCAPTCHA機能もまた、チャレンジレスポンスの一形態である：あなたが人間であることを証明してください。4

知識-所有-存在

しかし、CAPTCHAチャレンジ以外では、既知の秘密を共有することができます。パスワードを共有したり、(例えばポストイットノートの上で)パスワードが転がっているのを見つけたりすることで、他の人が正当な所有者のふりをする可能性があるため、正当なアクセスを保証するには十分ではないかもしれません。このような既知の秘密モデルの弱点は、パスワードだけを使用するアクセス要求者の信頼レベルがアプリケーションによっては十分ではないことを意味します。

本人確認や認証の後、正当な所有者の特定にはある程度の不確実性があり、その結果、アクセスのレベルがさらに評価されるべきである。信頼度が低ければ公開情報へのアクセスには十分かもしれないが、機密情報へのアクセスにはおそらく不十分であろう。

身元の証明をより多く追加するには、より具体的でユニークな識別子、すなわち身元の証明を要求することによっ て行うことができる。これらのより信頼された認証手段は、容易にコピーできない、または容易に共有または盗用できない（不可能ではないが、 安全な物理的トークンをコピーするコストが高すぎて、それを没収するのは経済的に不健全になる可能性がある）。実際には、トークン、証明書、バイオメトリクス証明などの追加要素を導入することでこれが行われる。これらの追加的な身元証明の要求は、最初の認証時にセッションの開始時に要求するか、以前の低信頼認証では安全なリソースへのアクセスが不十分であることが判明した後のセッション中に要求することができます。この場合、「ステップアップ」認証を実行することで低信頼アクセスを強化することができ、追加の要素を要求することができます。ログイン中の最初のステップではパスワードを使用することができ、その後、2 番目の高レベルのステップではトークンまたは生体認証を使用することができます。

認可

アクセス制御と同義語であることが多い認可は、認証の段階の後にアクセスを得るための次の段階です。これは、コンピュータアプリケーションやアプリケーション内の特定の機能など、特定のリソースへのアクセスを許可する行為です。

権限は、権限の概念と密接に関連している。所有者のような誰かが説明責任を持ち、所有権があるため、保護されたリソースにアクセスするために他の人に権限を与えることが義務付けられています。この説明責任は、他の人が所有者になることを意味するものではありませんが、「読み取り」や「削除」などのいくつかの権限が実行できることを意味します。所有者はデータのライフサイクルを通して説明責任を負う。所有者のタスクのいくつかは、例えばラインマネージャーが、所有者によって設定された境界内で、従業員にリソースへの読み取りアクセスを許可することができるような方法で、他の人に委任することができます。

主流のアクセス制御方法

現在、多くの組織では、さまざまなアプリケーション、オペレーティング・システム、およびネットワーク・コンポーネントにセキュリティ・ポリシーが埋め込まれています。これらの制御は、アクセス制御リスト（ACL）、ロール、DACビジネスルールの形で実装されています。しかし、これらの制御は、関連するすべてのコンポーネントに設計され、実装されていなければなりません。そして、これらのコントロールは、一貫した方法で設計されなければなりません。例えば、特定のプロセスに対して職務分掌(SoD)制限が定義されている場合、すべてのシステム、アプリケーション、プラットフォーム、アプリ、およびネットワークコンポーネントはSoDルールをサポートしなければなりません。多くのコンポーネントのうちの1つがSoD統制を欠いている場合、組織は統制が取れていないことになります。

このようにセキュリティポリシーが分散的に実装されているため、集中管理された組織全体の統制を実装することが困難になっています。すべてのコントロールが類似しているわけではなく、システムやプラットフォームのアクセス要求ごとにセキュリティポリシーと適合性を検証しなければならない可能性があります。

近代的なアクセスコントロール

最近のアクセス制御の実装では、アクセスポリシーを集中的に評価するためにポリシーエンジンが使用され、ポリシーの実施は「リスクレベル」の評価を包含する必要があります。アクセスリスクの管理を担当するビジネスプロセスの所有者、またはデータ所有者は、自分たちが責任を負うポリシーを定義します。場合によっては、複数の「ビジネスオーナー」が存在し、それぞれが企業のセキュリティポリシーの一部に責任を負う。このようなビジネスオーナーの割り当てにより、アクセス制御ポリシーが継続的に変更される可能性があります。

この分野では多くの開発が行われており、アプリケーションはもはやユーザーの ACL を維持することはできません。代わりに、1 つ以上のアクセス・ポリシーに基づいて、ユーザーのアクセス要求に関する決定を行う ID 管理認証システムに依存しています。企業内のさまざまな利害関係者は、さまざまなポリシーに責任を負っています。アクセスが許可される前に、適用されるすべてのポリシーを評価する必要があります。このようなきめ細かなアクセス制御の方法は、強制アクセス制御の一種である。

説明責任

説明責任は、アクセスガバナンスにおける重要な責任である。すべてのアクセスの決定が権限のある人物によって説明されるようにするということは、所有者に対処しなければならないということを意味しています。所有者は、スチュワードシップの下にあるデータに対して適切な説明責任を果たすために、自分の管理下にあるすべての活動について知らされていなければなりません。

アクセス制御におけるすべての活動を登録することは、必須の品質要件です。この記録は、すべての権限要求（人と人との間の権限や役割の付与や取り消しなど）を記録するものから、役割内の権限の変更を記録するものまで、複雑さは様々です。このレジスタの存在は、アクセスを真に制御するために不可欠です。識別と認証のプロセスについても同じことが言えます。すべてのアクセス要求が検証されていることを確認するために、ログインメカニズム、オペレーティングシステム、および適用されたIAMソリューションの一部から保証がなければなりません。

特定のアクセス制御の考慮事項

アクセス制御はビジネス上の意思決定だけではありません。ユーザーがどのように制御メカニズムに関与するか、何が必要か（必要でないか）に関する法的な意味合いなど、他の考慮事項も含めて、この活動がどのように行われなければならないかを知ることができます。

ヒューマンファクター

セキュリティ管理に対処する必要があるユーザ自身が、効果的な管理への道の障害となり得る。ユーザ体験（UX）は、すべての情報セキュリティプロジェクトの重要な成功要因である。セキュリティ対策が厳しすぎると、ユーザは抑止されたり、対策を回避しようとしたりする可能性がある。 ユーザー側のこの回避は、多くの場合、消費者のアクセスを見ることができます：顧客ポータルがユーザーに焦点を当てて構築されていない場合、消費者は他の場所に行く傾向があります。これは機会を逃すことになり、結果的にコンバージョン率が低くなります。Consumer Identity and Access Management (CIAM) ソリューションは、このような行動を防ぐために開発されています。

CIAMで学んだことは、ワークフォースIAM：UXが影響を与え始めているという点でも実践されています。例えば、ユーザーが自宅から定期的にVPNを利用して社内のイントラネットポータルにアクセスしている場合、アクセス制御システムはこの行動を認証プロセスの要因として検証することができる。アクセス制御システムは、既知の信頼された接続を利用している信頼されたユーザーであるため、多要素認証の繰り返し使用を必要としないことを決定することができます。

法的な意味合い

アクセス制御は、歴史的には、ビジネスプロセスをサポートする方法として見られており、より大きな情報セキュリ ティとリスク軽減の方針の一部となっている。アクセス・コントロールの実践に直接関連する法的な意味合いの問題は、ビジネスごと、セクターごと、法域ごとに異なる。これらのポリシーは、多くの法律、規制、または基準によって部分的に推進される大規模なプログラムの中に織り込まれていることが多いため、ほとんどのアクセ ス・コントロールの実施に直接的な法的要件については、明確な答えはありません。アクセス管理プログラムやシステムの役割の一部は、ビジネスや組織のより大きなリスク管理プログラムをサポートするのに十分な柔軟性を確保することです。このようにして、法的要件やコンプライアンスの意味合いに関する疑問に有機的に対処することで、組織が運営し、前進するために必要な自信を持つことができるようになります。

IDPro BoKの別記事では、法令の異なる側面を詳しく解説しています。

アクセスコントロールの現状

主流のアクセス制御機構

いくつかのメカニズムがアクセス制御の実装をサポートしています。このセクションでは、より一般的なものについて説明します。アクセス制御リスト(ACL)、役割ベースのアクセス制御(RBAC)、属性ベースの制御(ABAC)です。

アクセス制御リスト - ACL

保護されたリソースへのアクセス制御は、リソースの分類レベルに基づいて行われる。すべてのリソースは、リソースのセキュリティレベルを定義するために、所有者（または委任された人）によって分類されます。セキュリティレベルに基づいて、適切なレベルのアクセスを確保するために、セキュリティ制御を実施しなければならない。利用可能なアクセス、すなわち付与可能なパーミッションは、エンタイトルメント（リソースにアクセスするための細かいパーミッション）としても知られています。エンタイトルメントの最も初期の、そして最もよく知られた実装の1つは、アクセス制御リスト(ACL)を使用することです。ACLでは、ファイルの所有者は、どのユーザーがどのようなタイプのアクセスができるかを定義します。この概念は理解しやすく、個々のオブジェクトの管理も簡単です。また、オブジェクトの数が限られている場合は、ACLでアクセスを制御すれば十分です。しかし、ユーザの数やオブジェクトの数が増えてくると、ACL’sが制限要因になることがあります。

ファイルの各所有者は、オブジェクトの ACL を定義する必要があります。この分散型の制御方法は、アクセスの中央制御が存在しないことを意味します。しかし、監査の観点からは、保護されたリソースへのアクセス権がリソースの ACL に登録されているので、誰がアクセス権を持っているのかを見つけるのは比較的簡単です。

ACLの考え方については、今後のBoKの記事で解説していきます。

役割ベースのアクセス制御 (RBAC)

ACL を管理するのは面倒な作業です。ユーザーごと、またはエンタイトルメントごとにリソースへのアクセスを管理することは、人口が増えるにつれて問題に直面します。ある時点で、規模の問題から新しいアクセス管理アプローチが必要になりました。RBAC（Role-based Access Control）は、リソースへのアクセスを個人レベルではなくグループレベルで付与するアプローチです。これを実現するためには、アクセスコントローラの後に中間コンポーネントを設置する必要があります。ロールマネージャまたはロールオーナーは、ユーザーのロールを保護されたリソースへの権限にマッピングすることができなければなりません。このマッピングは簡単そうに見えますが、実際には、権限が組織のビジネスプロセスや組織構造と矛盾していないことを確認するために、この人が組織内の他の責任者と協力しなければならないことを意味します。アクセスガバナンスの記事では、この概念とガバナンスモデルに関連する複雑さについてさらに説明しています。

社内Webサイトの例では、社員は全員「社員」というグループのメンバーになっています。リソースは、この場合、内部Webサイトのメインページは、このような方法で、ユーザーがこのグループのメンバーである場合にのみアクセスが許可されるように保護されています。もう一つの例は、ライン・マネージャーが新入社員をアカウント・マネージャーの役割のメンバーにすることができ、見よ、アカウント・マネージャーの役割に接続されたアクセス権限が新入社員にも利用できるようになります。アクセスを許可するこの非個人指向の方法は、アクセスを管理することをはるかに簡単にします。

システム所有者は、個々の権限を管理する必要性を防ぐために、情報システム内に「ロール」を作成することもできます。顧客関係管理（CRM）システムのシステム所有者は、「顧客管理者」のロールを定義し、そのロールにシステム権限（データベースからの顧客レコードの読み取りやフォームへの入力など）をグループ化することができます。

RBACでは、我々はマルチレベルのロールモデルを識別することができます。一方では、組織的または階層的にアイデンティティのグループ化を識別し、組織的または業務的な役割を定義することができる。一方で、システムまたはアプリケーションの役割と呼ばれるアプリケーション機能またはプラットフォームレベルでの権限または許可のグループ化がある。組織的な役割とアプリケーションの役割を結びつけることで、非常に効率的に権限を付与したり、取り消したりすることができます。しかし、グループを入れ子にすることで権限管理を複雑にすることも容易です。例えば、サービスデスクで働く従業員を「ServiceDesk」グループのメンバーにすることができます。例えば、サービスデスクで働く従業員を「ServiceDesk」グループのメンバーにし、このグループを「Windows Administrators」グループのメンバーにすることができます。このようにすることで、誰がWindows管理者の権限を持っているのかを見つけることがすぐに難しくなります。これは、Windows管理者の役割のメンバーだけでなく、ServiceDeskの従業員の役割のメンバーである従業員のグループも含まれることになります。多くのIAMプロジェクトは、ネスティングの可能性がないために失敗しています。ネスティングはまた、RBAC環境の監査可能性を制限します。グループは、権限と競合する可能性のある権限を評価するために、ネスティングを解除しなければなりません。

実装、長所、短所については、後ほどBoKのRBACについての記事で説明します。

属性ベースアクセス制御 (ABAC)

属性ベースのアクセス制御（ABAC）は、ビジネスロジックに基づく追加の制御を導入することで、RBACモデルをベースに構築されています。RBACモデルの主な欠点は、その静的な性質です。一度エンタイトルメントが付与されると、それは一般的に、手動で取り消されるまで、常にエンドユーザーが利用可能な状態になります。この長期性は、適切なクリーンアップアクションが取られていない場合、ユーザがRoleからRoleへとアクセスを持ち歩くことになることを意味します。これに対処するために、ABACはこのモデルを拡張し、アクセスを許可すべきかどうかを判断する時点で、ユーザーのさまざまな特性とユーザーの属性を考慮に入れています。その結果、アクセス管理システムは、与えられたユーザーの権限、時間帯、ユーザーの場所（ネットワーク上またはリモート、IPアドレスに基づくジオロケーションなど）、デバイスの種類（個人所有、組織所有、デスクトップまたはテーブルなど）、およびその他のワーカーのメタデータに基づいて決定を下すことができます。ABACは、トランザクション時のアクセスをリアルタイムで制御する場合と、ユーザーのメタデータに基づいて割り当てられた役割と権限を受動的に制御する場合の両方で使用することができます。どちらのアプローチも、ユーザーのニーズを理解するためには、リソース所有者、役割マネージャ、人や組織のマネージャからの強力な入力とサポートが必要であり、ビジネスロジックの定義を支援するアナリストからの追加サポートも必要です。

例えば、以下のようになります。顧客関係管理プロセスの所有者は、属性’Business Role = Account manager’を持つすべての人が、属性’Allowed Time = defined office hours’の場合にのみリソースにアクセスできるように定義することができます。この動的アクセス制御哲学の複数のバリエーションについては、将来のIDPro BoKの記事で後述します。

アクセス制御の今後の方向性

ACLやRBACによるアクセス制御は比較的静的なもので、ユーザーとその権限の組み合わせは設定されており、簡単には変化しませんし、他の権限は変更が必要です。しかし、人々は仕事の間で移動したり、デバイスを変更したり、場所を変えたり、新しいコンテキストで新しいタスクを取得したりします。また、文脈の変化や適用される法律や規制の変更により、保護されているリソースに割り当てられているリスクレベルが変わることもあります。関連する変更には、以下のようなものがあります。:

これらの制限や変化は、よりダイナミックなアクセス管理の方法が必要であることを示しています。アクセス制御の今後の方向性は、この点を考慮した上で、様々な展開が考えられます。

動的認証

アクセス制御は静的なイベントではありません。ユーザーが低リスクレベルを必要とするサービスにアクセスするセッションを開始した場合、ユーザー名とパスワードの組み合わせによる識別で十分な場合があります。セッションの後半になると、別の信頼レベルが必要になります。例えば、トランザクションを実行する際には、トークンのような追加の識別が必要になるかもしれません。

これらのセッション・ダイナミクスに適応するためには、認証自体もまた、例えば行動バイオメトリクスの新しい概念を 通じて、継続的なプロセスでなければならない。ID に対する信頼に対するニーズの変化の例 :

アダプティブ認証は、安全で動的かつ柔軟性のある認証形態です。これにより、リソースへのアクセスを許可する前に、ログイン試行の真正性を判断するために複数の要素を検証することができます。ユーザー検証に使用される要素は、特定のユーザーへのアクセス許可に関連するリスクに依存し、実際の状況に基づいて認証強度を調整する必要があります。

ポリシーベースアクセス制御(PBAC)

柔軟性のある従業員を擁するコラボレーション環境の拡大した組織において、効果的かつ効率的なアクセス制御を実現するためには、動的で柔軟性のある手法が必要となります。ポリシーベースのアクセス制御（PBAC）は、この柔軟性を提供するためのパラダイムです。クレームベースのアクセス制御やコンテンツベースのアクセス制御としても知られるPBACは、ABACモデルで導入されたビジネスロジックの一部を利用し、コンテキスト評価とダイナミックなステップアップ機能を追加して強化しています。

アクセス要求者のコンテキストは動的に変化する可能性があります。ポリシー管理と実施の動的な性質により、定義されたリスク管理が必要な場合には、より高い信頼レベルに対応するために、セッション内でのステップアップ認証が必要になる可能性があります。ポリシーエンジンは、アクセスが要求された時点でのユーザ属性とコンテキスト情報が、セキュリティポリシーの所有者によって定義されたアクセスポリシーに準拠しているかどうかをチェックする責任があります。コンテキスト情報には、時間帯、地理的な場所、デバイスの種類などが含まれます。また、異なる信頼された、事前に定義された属性提供者から属性を収集できるようにすることで、アクセスのスケーラビリティが可能になります。例として、この人はリスク管理レポートにアクセスできますが、この人がCRISC証明書を持っている場合に限ります。ISACAはこの証明書を提供しているので、ISACAレジストリを検索すれば、CRISC証明書に関する質問に答えることができます（アクセス要求者とISACAメンバーのマッピングはこの議論の範囲外です）。8

このアーキテクチャの中心的なコンポーネントは、ポリシー決定ポイントで、アクセスポリシーを評価し、アクセス要求に対する応答を返します。Policy Enforcement Pointは、アプリケーションに組み込まれたコードによって、またはAPIゲートウェイを介して、応答を強制します。Policy Enforcement Engine は、アクセス要求フローの中の任意のコンポーネントです。

さらなる自然な展開として、AIACとReBACを挙げなければならない。

関係ベースのアクセス制御(ReBAC)

アクセス制御の新しい概念として、ReBAC（Relation Based Access Control）があります。ReBACは、アクセス要求者と、アクセス制御の決定によって影響を受ける可能性のある他のアイデンティティとの関係性を利用してアクセス制御の決定を行う可能性に対応しています。これらのアクセス決定は、（他のサービスの中でも）アクセス要求者のソーシャルメディアネットワークの関係から推論することができる。評判」のような属性が評価され、考慮され得る。ReBACは、アクセス決定のための評価と勧告を行うために、大規模で明確なデータセット（HR/ソーシング＆アクセス/エンタメ/行動からのデータを組み込んだもの）とAIの利用可能性に依存しています。

ReBACの方向性はまだ完全には明確ではなく、主流の実装には十分に成熟していない。我々は、動的なABAC実装のための予測ロールマイニング技術の一部としての実装の可能性を予見している。9

人工知能がサポートするアクセス制御 (AIAC)

この分野では、人工知能（AI）の概念が加わることで、より多くのことが期待できます。機密性の高いリソースを分類する堅牢な環境があれば、ダイナミック・アクセス・コントロールに高度なリスク管理アプローチを取ることが可能になり、ID マネージャ・ソリューションが通常のリスク・レベルを超えるアクセス要求を警告します。また、AI はアクセス制御要求を監視して、通常の活動から外れた活動を警告する。そのため、現在の RBAC および ABAC 実装に追加することができる。このコンセプトはまだ主流ではなく、方向性はほとんど予測できませんが、AIと機械学習が何らかの価値を付加する可能性があります。

ユーザーコントロールと同意

プライバシーに関する法律や規制は、個人情報へのアクセスに対する新たな意識を生み出しています。これらの法律と規制は、顧客、従業員、または患者によるデータの所有権と同意の概念を推進しています。データ所有者は個人情報の管理を期待しており、多くの場合、法律や規制がこれを義務付けています。このデータ所有権のギャップを埋めるために、いくつかの技術的なプラットフォームが登場し始めています。カンタラ・イニシアティブの「ユーザー・マネージド・アクセス」のようなソリューションが、新しいアクセス・パラダイムに対応しています。OAuthのようなプロトコルがさらに発展しているため、この概念の実装が容易になっています。10

結論

RBAC や ACL のような主流のアクセス制御メカニズムには長い歴史があり、今後も多くの組織で有効なユースケースがあります。しかし、企業、政府機関、組織が従来の4つの壁の外でのコミュニケーションやコラボレーションを必要とするようになると、他の方法でアクセスを制御することが必要になってきます。

主流のアクセスコントロール手法では、変化する世界で高まる柔軟性のあるアクセスコントロールのニーズに対応できません。近代的なアクセスガバナンスには、近代的なアクセスコントロール手法が必要です。ダイナミックアクセスコントロールの必要性は明らかです。興味深いことに、ツールが利用可能になりつつあり、実装は現在のベストプラクティスに干渉する必要がなく、適応認証、PBACは既存のアイデンティティとアクセスアーキテクチャに追加することができます。そのためには、ロードマップに基づいた計画が必要です。そしてもちろん、アクセスガバナンスの要素を実装する必要があります（IDPro BoKの別の記事で説明しています）。

著者情報

André Koot（アンドレ・クート）は、Nixu BeneluxのIAMおよびセキュリティコンサルタントであり、NixuのIAM内部プラクティスリーダーです。彼のIAMの経験は、財務会計と監査のバックグラウンドに由来しています。このような不正検知防止ビジネスプロセスの背景から、認証原則の分野での研究を行っています。

  1. Wikipedia contributors, “Classified information,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Classified_information&oldid=958717370 (accessed June 8, 2020). ↩
  2. Davis, Shannon, “A Look at Discretionary Access Control,” blog, TED Systems, 27 February 2019, https://www.tedsystems.com/look-at-discretionary-access-control/. ↩ 3.Rouse, Margaret, “mandatory access control (MAC),” TechTarget, December 2013, https://searchsecurity.techtarget.com/definition/mandatory-access-control-MAC (accessed June 8, 2020). ↩ 4.Wikipedia contributors, “CAPTCHA,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=CAPTCHA&oldid=947308972 (accessed June 8, 2020). ↩
  3. “SCIM: System for Cross-domain Identity Management,” http://www.simplecloud.info/ (accessed June 8, 2020). ↩
  4. “EU General Data Protection Regulation (GDPR): Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation),” OJ 2016 L 119/1. ↩
  5. https://kantarainitiative.org/confluence/display/uma/Specifications+and+Auxiliary+Documents ↩
  6. ISACA home page, https://www.isaca.org/ (accessed June 8, 2020). ↩
  7. “Data Mining and Predictive Analytics: Things We should Care About,” Inside Big Data, 24 November 2018, https://insidebigdata.com/2018/11/24/data-mining-predictive-analytics-things-care/ . ↩
  8. Wikipedia contributors, “OAuth,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=OAuth&oldid=951287251 (accessed June 8, 2020). ↩