ユーザー操作SaaSプラットフォーム（SaaSプラットフォーム権限アーキテクチャ）

SaaS プラットフォームの権限アーキテクチャ

編集者注: 事業の数が多い企業の場合、組織構造は比較的複雑になります。現時点では、プラットフォームの権限アーキテクチャが特に重要です。この記事の著者は、SaaS プラットフォームの権限アーキテクチャに関するコンテンツを共有し、さまざまな運用シナリオにおけるデータ権限の問題を詳細に紹介します。ご興味がありましたら、ぜひ一緒に学びに来てください。お役に立てれば幸いです。

SaaS システムの権限は、ログイン アカウントの機能権限とデータ権限の組み合わせです。

機能権限とは、アカウントがプラットフォーム上でどのページを表示できるか、およびページ上でどの機能またはボタンを操作できるかを指します。

データ権限とは、このアカウントがシステム内で表示できるデータと、機能レベルの操作を実行できるデータを指します。

機能権限は通常、ロールと機能セット、つまり RBAC モデルに関連付けられます。データ権限は通常、データの分離を実現するためにテナントの組織構造に依存します。

次に、アカウントは機能権限を取得するためにロールに関連付けられ、管理可能なデータを取得するために組織構造に関連付けられます。該当コンテンツについては下記で詳しく紹介しております。

実際の運用シナリオでは、やや規模の大きい企業では、多くの階層を持つ比較的複雑な組織構造になっています。各レベルのノードのデータ要件は異なるため、異なるレベルのノードのデータは分離する必要があります。

たとえば、ケータリング会社の組織構造は次のようになります。本社の CEO は支店のすべてのデータを確認したいと考えており、支店長はすべて地域のデータを確認したいと考えており、朝陽区の地域マネージャーはすべての店舗のデータを確認したいと考えており、店長は店舗内のすべてのデータを確認したいと考えています。

したがって、プラットフォーム アカウントの権限に組織構造を導入する必要があります。アカウントは組織構造に直接関連付けられており、各レベルではそのレベルのデータを見ることができます。組織構造を通じて、複数レベルのデータを分離できます。

一般的に、アカウントを組織構造に関連付ける場合、データが正確にどのノードに配置されているのか、現在のノードと下位ノードのデータなのか、現在のノードのデータだけなのか、指定した下位ノードのデータなのか、自分で作成したデータだけを管理できるのかを判断する必要があります。

レベルをまたいでデータを表示する必要のある特殊なケースもあります。シナリオは 5 つあります。

1) シナリオ 1: アカウントは現在のレベルとそれより低いレベルのデータを表示できます。

アカウントを作成するときは、アカウントがどのレベルに属するかを選択する必要があります。そうすると、現在のレベルとそれ以下のレベルのすべてのデータが表示されます。

たとえば、アカウント 1 は北京支店とその下位ノードのすべてのデータを表示できます。

これはよく使用されるデータ権限です。同時に、アカウントは親組織構造ノードのデータを表示できません。たとえば、アカウント 2 が朝陽地区ノードに属している場合、北京支店に属するデータは表示されません。

2) シナリオ 2: アカウントはこのレベルのデータのみを表示できます。

このアカウントが表示できるデータの具体的なレベルを決定するには、データ権限をさらに細かく設定する必要があります。たとえば、アカウント 3 は朝陽区に属していますが、朝陽区に属するデータしか表示できず、下位ノードのストアデータは表示されません。

3) シナリオ 3: アカウントは下位レベルの特定のノードのデータのみを表示できます。

たとえば、アフターセールススタッフのアカウント 2 は北京支店に属していますが、朝陽区の店舗 1 と店舗 2 のデータのみを担当します。

このような状況に基づいて、アカウントを作成するときに、組織構造を関連付け、現在のアカウントがこのノード下のどのデータを表示できるかを指定する必要があります。

4) シナリオ 4: アカウントは指定されたレベルの指定されたデータのみを表示できます。

組織構造の各レベルには、現在のレベルの特定のアカウントに固有のデータがいくつかあります。

例えば、業務協力のための顧客データは、現在の組織構造のノードに属し、特定の業務担当者に固有のものであり、他の投資促進担当者と共有されることはありません。

例えば、投資促進部門の従業員Aのアカウント3は朝陽区に属する顧客情報を管理しており、アカウント3が属する従業員Aのみが管理しています。

同じレベルのアカウント 4 を持つ他の従業員には、この顧客情報を表示する権限がありません。しかし、投資促進部門の部門長は自分の部門のすべてのデータを見たいと考えています。

したがって、アカウントを作成するときに、このアカウントが部門のデータを見ることができるのか、それともアカウントによって作成されたデータだけを見ることができるのかを指定する必要があります。

5) シナリオ 5: 異なるレベルで他のノード データが管理されます。

たとえば、アカウント 5 は元々、組織構造内のストア 1 に属しています。理論上は、ストア 1 のデータのみを管理できます。ただし、同じ親ノードにないストア 4 などのストアがアフターセールスの問題の分析を支援したい場合、アカウント 5 はどのようにしてノード間でストア 4 のアフターセールスの問題を管理できるでしょうか。

答えは、ストア 4 の管理者が、ノードの特定のデータまたはすべてのデータを管理のためにストア 1 のアカウント 5 と共有するように指定できることです。

データ共有は、組織構造内の階層関係や同僚関係を制限しません。

アカウントを機能に直接関連付けるのではなく、ロールに依存して機能権限を解決する必要があるのはなぜですか?これは、プラットフォーム上に多くのページがあり、ページ内に多くの機能があるためです。アカウントがページや機能に直接関連している場合、すべてのアカウントを操作するのは面倒です。

ロールを導入し、ロールを権限に関連付けることで、同じ権限を持つユーザーをロールに直接関連付け、ロールに対応する機能権限を取得できるようになります。操作の利便性が向上しました。ロール自体は機能の集合です。

同じアカウントに複数のロールを持たせ、複数のロールの複合的な権限を取得できます。アカウント 4 が従業員とアシスタントの 2 つのロールに関連付けられている場合、アカウント 4 は、従業員ロールに対応するページ 3 とページ 4、およびアシスタント ロールに対応するページ 5 の機能権限を取得できます。

それほど複雑でない組織構造の場合、組織構造を実装するためにロールが使用され、ロールは上位と下位のツリー構造として設計されます。

この実装方法は柔軟性が低いです。組織構造が複雑な場合は、役割も多くなります。組織構造の各ノードで、同じストア マネージャー ロールを個別に作成する必要があります。この実装は通常は使用されません。

実際のビジネス シナリオでは、同じアカウントが同時に 2 つのロールを取得することはできません。 2 つの役割は相互に排他的です。 1 つのロールを持っている場合、他のロールを取得することはできません。

財務においては、会計担当者と出納係の両方の役割を 1 人で担うことはできないため、財務権限を分離する必要があります。

これには、ロール定義を作成するときに相互に排他的な状況を具体的に定義する必要があります。

RBAC1 + RBAC2 の複合形式であり、組織構造と相互に排他的な役割の実装の両方を備えています。

1) アカウントは、機能権限とデータ権限の両方を取得するためにロールにのみバインドされます。

上の図に示すように、役割は役職とみなされ、組織構造に直接関連付けられます。アカウントは、組織構造に個別に関連付ける必要はなく、ロールにのみ関連付ける必要があります。このようにして、アカウントは現在の役割に基づく機能権限と、役割に対応する組織構造に基づくデータ権限を直接取得できます。

このように、アカウントの位置を調整する必要がある場合は、アカウントに対応する役割を直接調整できるため、操作が便利です。

ただし、そのためには各ノードにポジションと対応するノード ロールを作成する必要があります。ロール データの量は比較的多く、各ロールは対応する機能権限で構成する必要があります。

2) アカウントは、機能権限とデータ権限の両方を取得するために、組織構造内のポジションにのみバインドされます。

組織構造内にポジションを作成し、ポジションを対応するロールに関連付け、アカウントを組織構造内のロールに直接関連付けます。同時に、ロールを再度関連付ける必要なく、ロール権限を取得します。

ポジションを転送する場合、アカウントは組織構造内のポジションを変更するだけです。

これは上記のシナリオと同じで、どちらも同じコンテンツを頻繁に再作成する必要があります。

上記のアカウント、ロール、組織構造は、機能権限とデータ権限の問題を解決するために関連付けられています。ただし、承認プロセスに関しては、たとえば店舗 1 内でウェイターが休暇を申請し、店長の承認が必要になります。ただし、両者は Store 1 の同じ組織構造に属しており、両者の間には階層関係はありません。指定された人だけがプロセスを承認できます。

ただし、各部門が独自の承認プロセスを作成する必要があり、これは面倒です。

ロール自体が職務責任であるため、承認プロセスにロールを導入することができ、承認ノードはすべてロールです。

• たとえば、休暇を申請する場合、承認プロセスで店舗従業員ロールを設定し、店舗マネージャーまたは管理者ロールが休暇を承認するようにすることで、すべての店舗がこのプロセスに従うようにすることができます。
• たとえば、払い戻しプロセスには、店舗マネージャーと地区レベルの財務マネージャーの両方の承認が必要です。一定額の払い戻しと支店の財務担当副社長による承認が必要な場合、プロセスは承認者を指定する機能をサポートする必要があります。ただし、承認のために人を指定することは一般的に推奨されません。その後人員が調整された場合は、承認プロセスもそれに応じて調整する必要があります。

また、現在の承認ロールに複数のアカウントがある場合、プロセスで特定のアカウントが承認対象として指定されていない限り、複数のアカウントが承認できます。

財政補填が朝陽区財政役所に届き、その配下に口座3と口座4がある場合、承認者が責任を負うという原則に基づいて、口座3と口座4の両方を承認することができます。

アカウント 3 が特定の払い戻しフォームを承認した場合、その後の支払いも承認のためにアカウント 3 に転送される必要があります。

1. ロール グループは、複数のロールの集合であり、複数のロールにおける機能権限の集合です。複数のロールを 1 つのアカウントにバインドする場合の操作を容易にするには、新しいロール バインディング アカウントを直接作成することをお勧めします。
2. ユーザー グループは複数のアカウントの集合です。これは、複数のアカウントが同じロールにバインドされている場合の操作を容易にするように設計されていますが、特定の権限の問題は解決しません。

現在、SaaS プラットフォームに基づく既存のビジネスと将来の管理のビジネス特性では、一般的に Title 1、Title 2、Title 6 の組み合わせを採用して、それぞれ機能権限、データ権限、承認プロセス権限を解決します。

この記事はもともと @阿白 によって Everyone is a Product Manager に掲載されました。許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。