RBAC VS マルチテナント
はじめに
アプリケーションやサービスを顧客に提供することを考えるとき、プラットフォーム内で顧客をどのように構成するか、どこかの時点で考える必要があります。Things Cloud は 2 つの異なる方法でそのお手伝いをします。
ロールベースのアクセス制御(RBAC: Role-based access control) は、Things Cloud プラットフォームのすべてのテナントの一部であり、各ユーザーの権限を細かく定義できます。特定のユーザー(顧客など)に、テナントの部分的な表示のみ(そのユーザーに属するデバイスのみ)を提供するために使用できます。
それに加えて、Things Cloud プラットフォームは一般に マルチテナント プラットフォーム であり、プラットフォーム内の他のテナントと同じように機能する独自のサブテナントを作成することもできます。
これにより、顧客を組織化するための 2 つの選択肢があります。顧客ごとにテナントを作成するか、1 つのテナントで RBAC を使用して顧客同士を相互に保護し複数の顧客を管理するかの、いずれかです。
以下では、両方のアプローチをより詳しく検討し、それぞれの方法で解決する手段を説明したいくつかのユースケースをざっと見ていきます。どちらのアプローチが自社のビジネスケースに適しているかを判断できるようになります。Things Cloud は、テナント階層を使用してテナントを管理するように設計されています。その結果、ロールベースのアクセス制御をする場合、顧客環境で対応する必要があるいくつかの場面で、より困難になります。両方のアプローチを組み合わせて使用することで、あなたとあなたの顧客に最も柔軟なアプローチを提供できます。
備考
1 つのアプローチから始めて、もう一方のアプローチに切り替えるには、ある程度の移行が必要になります。RBAC からマルチテナントに移行する方が、その逆よりも簡単です。
一般的なセットアップ
特定のユースケースについて詳しく説明する前に、各アプローチの一般的なセットアップと、その基礎となるコンセプトを明確にする必要があります。
ロールベースのアクセス制御 (RBAC: Role-based access control)
通常、1 つのテナントですべてを処理するには、顧客用の個別のフォルダをアセット階層に作成することから始まります。アセット階層の詳細はカスタマイズできますが、おそらく最終的には顧客ごとに 1 つのフォルダを作成することになります。顧客は自分のフォルダにのみアクセスでき、そのフォルダ以外のものを見ることができないようになります。
マルチテナント
顧客ごとにテナントを作成すると、顧客がテナントレベルで分離されます。顧客は自分のテナントにのみアクセスできるようになり、あなたのテナントで行うのと同じように、そのテナントで作業できるようになります(顧客に付与したい特定のアクセス権限を使用します)。このユースケースでは、顧客が自分のテナントの管理者であり、フルアクセス権を持っていると想定しています。
備考
顧客の特定の機能を明示的に制限しない限り、顧客のテナントはあなたのテナントと変わりません。
さまざまなユースケースの比較
次のタスクは、プラットフォーム ソリューションでカバーされる必要があります。
次のセクションでは、これらのタスクが両方のアプローチでどのように処理されるかについて説明します。
顧客のオンボーディング
ロールベースのアクセス制御(RBAC)
マルチテナント
新しい顧客を追加するには、アセット階層を拡張し、階層の一部に作成された新しいアセットにアクセスできる顧客用のそれぞれのユーザーアカウントを作成します。
新しい顧客を追加するには、自身のテナントから新しいサブテナントを作成します。テナントの作成時に、管理者権限を持つ顧客用の最初のユーザーを自動的に作成することができます。
比較:
新しい顧客の作成も同様に簡単です。ただし、マルチテナントのアプローチでは、標準のアプリケーション以外は何も含まない新しい空のテナントを作成することを考慮する必要があります。追加のアプリケーションのサブスクライブ、デフォルトのダッシュボードの作成、保持ルールの構成などが必要になる場合があります。これらの設定は全員に対して一度だけセットアップされるため、RBAC アプローチにはすでに設定されていますが、一方で、この特定の設定(保持ルールなど)はテナントレベルで構成されるため、顧客ごとに異なる設定を行うことができません。
デバイスの登録
ロールベースのアクセス制御(RBAC)
マルチテナント
RBAC セットアップの一般的なシナリオは、顧客がデバイスの登録に責任を負わず、すべてのデバイスがプラットフォーム提供者によってプラットフォームに登録されるというものです。ただし、顧客がデバイスを登録することは技術的には可能です。この場合の重要な点は、顧客は登録エントリーを作成する際に、デバイスが属する正しいグループを指定する必要があることです。そうしなければ、顧客は自分のグループのみ表示可能なため、自分のグループ以外で作成されたデバイスを見ることができなくなります。
顧客はテナントにフルアクセスできるため、追加の制限なく自由にデバイスを登録できます。
比較:
プラットフォームに誰がデバイスを登録するかについて、技術的な制限はありません。ただし、RBAC アプローチでは、顧客がデバイスを閲覧できない状態でデバイスを登録してしまうという誤った設定も簡単にできてしまうため、注意が必要です。
アクセス権
ロールベースのアクセス制御(RBAC)
マルチテナント
Things Cloud には、グローバルロールとインベントリロールの 2 種類のロールがあります。グローバルロールはテナントレベルで適用されます。RBAC アプローチでは、適切なレベルの分離を行うためにインベントリロールを使用する必要があります。一部のグローバルロールの権限(「自身のユーザー管理」など)を除いて、顧客ユーザーにはロールが割り当てられません。インベントリロールを作成するか、デフォルトのインベントリロールを使用して、そのロールが適用されるアセットと組み合わせてユーザーに割り当てる必要があります。これは顧客ごとに少なくとも一度行う必要があります。
テナントは他のすべての顧客から完全に分離されているため、必ずしも顧客のアクセス権の設定に関与する必要はありません。顧客にテナントの管理権限が付与されている場合は、自分でアクセス許可を設定できます。顧客が他の顧客を見たり、知ったりすることはできません。
比較:
RBAC アプローチでは、構成ミスにより顧客が他の顧客のデータなど、見てはいけないデータにアクセスできる可能性があるため、アクセスの管理が最も複雑な部分になります。インベントリロールを使用すると、データの特定部分のみに対するアクセスを細かく定義できますが、偶発的な構成ミスからをも保護することはできません。ここでのもう 1 つの制限は、顧客が独自のロールを作成できないことです。
アクセス制御のセキュリティ側面については、アクセス制御 を参照してください。
ユーザー管理
ロールベースのアクセス制御(RBAC)
マルチテナント
ユーザー階層機能を使用すると、ユーザー管理を顧客に委譲して、顧客が自分で新しいユーザーを作成できるようにすることができます。この機能を使用すると、顧客は自分が持っているのと同じロール (またはそれ以下)を持つユーザーのみを作成できます。したがって、顧客が必要とするすべてのロールを最初のユーザーに割り当てて、そのロールを委譲できるようにする必要があります。
顧客はユーザー管理への管理者のフルアクセス権を持ち、自身のロールを定義することもできます。
比較:
顧客ごとに独立したテナントを持つことで、顧客はユーザー管理に関して制限されず、すべての管理機能をフル活用できます。RBAC アプローチでは、特定の管理機能を委譲でき、プラットフォームによってユーザーが境界を越えることがないようにできます。ただし、ロールの作成などの特定の機能は、完全なユーザー管理の管理者のみが利用できます。
アプリケーション管理
ロールベースのアクセス制御(RBAC)
マルチテナント
アプリケーションの管理は管理者のみが行うことができます。顧客は引き続き、利用可能なアプリケーションへのアクセスをユーザーに許可することができます(自身がアクセスできるアプリケーションのみ)が、ユーザーは自身のアプリケーションを作成することはできません。
顧客は、テナントに必要に応じてアプリケーションを自由に追加できます。マイクロサービス ホスティング機能はオプションであるため、マネジメントテナント によりテナントに付与される必要があります。これは UI アプリケーションには適用されません。
比較:
アプリケーションの管理はテナントレベルでのみ利用できます。顧客が自身でプラットフォームを拡張できるようにしたい場合、顧客用のテナントを別途用意する必要があります。RBA Cアプローチでは、アプリケーション管理を行う必要がありますが、顧客ごとに異なるアプリケーションを持つことは可能です。これは UI アプリケーションでは簡単に実行できますが、通常、マイクロサービスを追加する場合、マイクロサービスはテナント全体で利用できるため、アクセス権で管理する必要があります。
請求書と使用状況データ
ロールベースのアクセス制御(RBAC)
マルチテナント
プラットフォームは、API リクエスト、ストレージ容量、ユーザーとデバイスの数などの使用状況データを自動的に収集します。ただし、これは常にテナントレベルで行われます。どのくらいのデバイスを所有しているかは API 経由で確認することは可能ですが、どの顧客がストレージ容量と API リクエストをどの程度利用しているかを分離することはできません。
顧客が自身のテナントのサブテナントである場合、顧客のデータにアクセスすることなく、自身のテナントから各テナントの使用状況データを参照し、エクスポートすることができます。また、顧客に対して制限を設定できるため、顧客の一定の使用量を下回るようにすることができます。
比較:
RBAC アプローチを選択すると、顧客の正確な使用状況データを取得することができなくなるため、ビジネスモデルの選択肢が制限されます。ライセンスベースのビジネスモデル(例:デバイスごと)は、RBAC のセットアップの方がはるかに実現性が高いです。マルチテナントのセットアップを扱うと、API コールやストレージごとに課金する典型的なクラウドベースのビジネスモデルを選択するオプションが提供されます。
分析
ロールベースのアクセス制御(RBAC)
マルチテナント
すべてのデータは単一のデータベースで利用できるため、Apama ストリーミング分析エンジンや、外部ツールを使用してデータの分析を簡単に適用できます。対象の顧客が属するグループに基づいてデバイスを分割する必要があるため、1 つの顧客のみに分析機能を適用することは、少し難しくなります。
すべてのデータは複数のデータベース(テナント/顧客ごとに 1 つ)に分割されており、それらすべてに直接アクセスすることはできません。データを抽出するには各テナントにアクセスするか、データエクスプローラのような機能を使用して分析に関連するデータを 1 つのテナントに同期させ、そこで分析を行う必要があります。
比較:
1 つのテナントを扱っている場合、すべての顧客のすべてのデバイスにわたって分析を行うのは簡単ですが、1 つの顧客に対して個別に分析を行うのはより複雑になる可能性があります。複数のテナントにデータを分散させると、データを 1 カ所に収集する手間が増えます。ただし、顧客ごとのカスタム分析ソリューションの導入は容易になります。
Things Cloud DataHub
Things Cloud DataHub は現在 RBAC をサポートしていません。テナントで DataHub にアクセスできるユーザーは、使用中の権限に関係なく、メジャーメント、イベント、アラーム、およびインベントリの詳細を同じデータレイクにオフロードできます。オフロードジョブをユーザーのデータのみに制限することは可能ですが、これには慎重な手動構成が必要です。DataHub は現在、テナントごとに 1 つのデータレイク フォルダ接続のみをサポートしています。また、分析ツールからデータレイクにアクセスするために作成されるユーザーは 1 人だけであるため、データレイク内のデータにセキュリティを適用することも現在は不可能です。