アプリケーションの権限を最適に保つ、エンタイトルメント管理

Okta が Identity Governance & Administration(IGA)ソリューションの Okta Identity Governance(OIG)を提供し始めてからしばらく経ちました。Oktaが目指しているのは、「効果が出るのに時間がかかりすぎる」、「成果に結びつかない」、「導入の負担とコストが高い」といった難点を抱える従来型の IGA ソリューションとは異なった、モダンなアプローチによって IGA の領域の課題を解決することです。

本日はその中でもエンタイトルメント管理について、ご紹介したいと思います。多くの方があまり馴染みのない言葉かと思いますので、まずはエンタイトルメント管理の目的など一般的なことをお話し、その後具体的なOktaの機能についてご紹介します。

エンタイトルメント管理機能の目的

シングルサインオン環境ではユーザーがアプリを利用開始する準備として、Oktaのようなシングルサインオンを提供するシステムでユーザーにアプリを割り当て、アプリにもユーザーを登録する必要があります。プロビジョニングが利用可能な場合、アプリへのユーザー登録は自動的に行われます。

実務上はこれに加えて、アプリのライセンスやロールといった権限の割り当て管理が必要となるケースがあります。ユーザー属性や所属するグループなどの静的な情報に基づいた権限の割り当てはプロビジョニングでも可能なケースがありますが、権限はビジネス上の要求により追加割り当てや剥奪など、より動的、機動的な扱いを求められることがあります。

エンタイトルメント管理は、このような管理を効率的に実現するための機能です。

エンタイトルメントとは?

エンタイトルメント(Entitlement)は、一般的に「権利」や「資格」と翻訳される言葉ですが、この言葉は人によってイメージする範囲や捉え方が大きく異なると思います。このブログで扱う”エンタイトルメント”が意味するものは、ユーザーがサードパーティアプリケーション内で特定のアクションを実行できるようにする「権限」、「特権」、または「アクセスレベル」のことです。Okta のエンタイトルメント管理機能のアイテム名でもあるので、単に権限を意味したい場合は「権限」、Okta のシステム上のアイテムを表現したい時は「エンタイトルメント」と表現を使い分けて書きたいと思います。

どのようなアプリをエンタイトルメント管理すべきか

エンタイトルメント管理は、全てのアプリケーションに対して必要であるとは限りません。単純な権限しか存在しないアプリケーションや、自社の利用方法次第で敢えてプロビジョニングによるアイデンティティ管理ができれば十分なものもあるでしょう。

アプリケーションに権限やライセンスが複数種あり、その割り当てが複雑だったりユーザーの要求に合わせて動的に付与する運用が必要な場合にはエンタイトルメント管理によって、運用を最適化しIT部門のオペレーション最適化や、ユーザーの利便性向上といった効果が期待でき、ひいてはビジネスの効率化に繋がります。

また、管理すべき権限が単純、または不要であるアプリはグループでまとめるなどのシンプルな管理を行いつつ、次のセクションにあるような複雑な権限管理が必要なアプリはエンタイトルメント管理の対象とすることで、システム全体として効率的かつ負担の少ない管理ができる点もOktaの提供するアイデンティティ管理の特徴です。

どのような管理が必要とされるか

では、エンタイトルメント管理の対象となるアプリに対して、エンタイトルメントはどのような管理が要求されるでしょうか?

  • 基本的なアサインまず、ユーザーの役職や部署などに応じて割り当てられるべき共通的なエンタイトルメントのアサインが挙げられます。例えば、管理職ではないユーザーには基本的な機能が利用できる権限を付与し、管理職のユーザーには一律で承認が可能な権限を付与するなどがこれにあたります。
  • 複雑なアサインより複雑な条件をもとに権限を細かく分ける必要があるケースもあります。部門や職責、業務上の役割などが複合的な条件としてアプリの権限とマッチングしているような状況です。
  • 動的なアサインしかるべき責任者が承認をした上で、利用者に随時権限の割り当てを行いたいケースがあります。一定期間後や定期的な棚卸しを経て、割り当てた権限を解除することが必要な場合もあります。具体例として、職責とは別に選ばれた部門の代表者に割り当てる権限や、プロジェクトの発足に伴い追加で必要となる権限などがあります。

このような管理を効率的に行う必要があります。

Okta のエンタイトルメント管理

条件に基づいた静的な割り当ては、ポリシーとして設定します。設定されている条件はすべて評価され、条件に合致したルールに設定されたエンタイトルメントを合わせたものが、実際にユーザーに付与されるエンタイトルメントです。

例としてSalesforce.comに対するポリシーによるエンタイトルメント管理を見てみましょう。

entitlement policy

上図のポリシーに対して、例えば

  • 営業部の人は2番のポリシーのみがマッチするのでProfile は Standard User、Role はWestern Sales Team が割り当てられる。
  • 営業部の人でも、マネージャーの場合は1番と2番のポリシーにマッチする。2番目のポリシーにしか存在しない Profile はそのまま Standard User になり、Role は両方のポリシーに存在するため、優先度が高い1番目のルールの Role である Manager, Japan Sales が割り当てられる。

access details

というわけです。この仕組みにより、単純な条件はもちろん複雑な条件でのエンタイトルメントの割り当てもシンプルに設定することができます。

複雑な複数条件の組み合わせも、Okta の Expression Language を利用して設定することができます。例えば3番目のポリシーである ”一部のマーケティング部門ユーザー権限” では、Oktaグループ ”マーケティング部” に所属しており、Division 情報がフィールドマーケティング、さらにサスペンドされていないユーザーを指定しています。
Expression Language は、ポリシーやアプリケーションに渡す情報を属性を参照、変換、結合することにより柔軟な情報の加工を提供するものです。

前項で挙げた動的なアサインは、エンタイトルメントがこのように割り当てられた状態に対し、必要に応じて都度実施されます。
もちろん、管理者はOktaの管理画面から手作業で、エンタイトルメントの追加や一部剥奪などの調整を行うことができます。それに加え、さらにビジネスオペレーションに適した方法として、ユーザーからの申請による追加と棚卸しによる剥奪をサポートしています。

これは既存のプロビジョニング機能によって実施可能な範囲で権限管理していた場合には、でき得なかったことです。

ユーザーの申請に基づくエンタイトルメントの追加

それではユーザーの申請からの流れを見てみましょう。ユーザーは普段からアプリへのアクセス時に利用するOktaのユーザーダッシュボード画面から、そのままアプリや権限の追加を要求することができます。ユーザーのアプリ活用における導線がシンプルなので、ユーザーの利便性を高めIT部門へのサポート依頼の削減などに繋がります。申請は、ダッシュボードの「アクセスを要求する」のボタンから開始できます。
 

request access

管理者が申請できるように設定しておいたアプリの一覧が表示されます。ユーザーはここから自分が権限を申請するアプリを選択します。
 

request access2

Salesforce.com を選択した画面です。管理者が予め設定した、申請可能なエンタイトルメントが表示されます。(実際には、1つまたは複数のエンタイトルを定義した ”エンタイトルメントバンドル” を作り、それが申請する単位となります。)

ユーザーはこの中から必要な権限を選択します。名称や説明はわかりやすいように管理者が自由に設定できます。

request access3

管理者は申請されるエンタイトルメントごとに、確認事項の入力を求めたり、誰が承認すべきかや何段階の承認が必要かなどを予め決めておくことができます。以下の場合、申請理由の入力を求めています。

request access4

あとは「リクエストを送信」を押して申請は完了です。

承認が設定されている場合、必要な承認が完了すればユーザーは自動的にアプリやその権限を割り当てられます。承認が不要な設定の場合、すぐに割り当てが行われます。

実はこのユーザー体験部分は、エンタイトルメント管理対象ではないアプリでも利用できます。アプリ自体またはアプリにアサインされたグループへの割り当て依頼ができるように、管理者が設定できます。グループ=権限のような管理をしているアプリがある場合は、実質的にこれで権限管理が可能です。

イベントドリブンのエンタイトルメント剥奪

エンタイトルメントの剥奪には管理者による変更以外に、2つの方法があります。イベントドリブンという言葉を使いましたが、そのイベントとは時間と、人による判断です。

1つ目は申請によって獲得されるエンタイトルメントに対して、管理者が予め設定することができる有効期限です。有効期限が経過すると自動的にエンタイトルメントが剥奪されます。一定の有効期限内の権限付与で十分なアプリにはシンプルに剥奪ができるので向いています。

2つ目は棚卸しによる剥奪です。管理者は棚卸しキャンペーンを作成し、アプリ利用者の上司やアプリ管理者などに棚卸し作業を割り当てることができます。棚卸しの結果、その権限がもはや不要であると判断されたユーザーからはエンタイトルメントが剥奪されます。以下は先ほどユーザーが申請したエンタイトルメントを棚卸している画面です。
 

entitlement review

棚卸し担当者は判断のためにユーザーの詳細を確認することができます。前述の通り申請される単位は1つまたは複数のエンタイトルメントを定義した ”エンタイトルメントバンドル” のため、その中で定義されているエンタイトルメント(この場合4種)が確認できます。

entitlement details

日々申請によって新たな権限が割り当てられていくと、次第に現状が妥当なものなのか不明確になり、セキュリティなどの面で悩みの種となります。このような剥奪の仕組みをつかって、常に必要最小限の権限が付与された状態を保つことが重要です。

エンタイトルメント管理を始めましょう

エンタイトルメント管理はアプリケーションの権限をコントロールするためのコネクタがOktaとアプリケーションの連携をします。Okta は現在、Box、GitHub Team、Google Workspace、Microsoft Office 365、NetSuite、PagerDuty、Salesforce、Zendesk に対するOut-of-box コネクタ(すぐに利用できるコネクタ)をサポートしており、今後数ヶ月でさらに多くのコネクタの提供を予定しています。Out-of-box コネクタがないアプリでも、サードパーティー提供のコネクタや Okta Workflows を利用して構成することも可能です。

エンタイトルメント管理は現在、Okta Identity Governance(OIG)をご利用のお客様すべてに一般提供されています。OIG ご購入前で Okta をすでに利用頂いているお客様は、担当のカスタマーサポートマネージャー(CSM)または担当営業までご相談ください。