テナントは、物理的に分離されたデータのスペースであり、個別の URL、特定のユーザーのセットを持ち、個別のアプリケーション管理であり、デフォルトでデータは共有されません。1 つのテナント内のユーザーは、同じ URL で同一スペースのデータを共有します。
多くのシナリオでは、1 つのテナント内で複数の関係者（顧客など）を管理できれば十分です。この場合は、適切な権限を割り当てることでユーザーのアクセスを制御 し、ユーザーがどのデバイスを見ることができるかを指定します。これにより、複数の関係者を互いに分離して保護します。このアプローチは、Things Cloud の 標準テナント（サブテナント） に相当します。
他のシナリオでは、さまざまな理由からこのアプローチでは十分ではない可能性があり、テナントのポートフォリオの管理に関連する可能性があります。このマルチテナントのアプローチは、Things Cloud の エンタープライズテナント（親テナント） のコンセプトに反映されています。
Things Cloud は完全なマルチテナントをサポートしています。テナントに関連するすべてのデータは、専用のデータスペースに保存されます。これには、ユーザーデータ、インベントリ、イベント、メジャーメント、オペレーション、アラームが含まれます。
エンタープライズテナント（親テナント）は、サブテナントを作成することができ、サブテナントは、プラットフォーム内で 標準テナント（サブテナント）と同じように機能し、独自のテナント管理を行います。
このマルチテナントのアプローチには、次のようなさまざまなメリットがあります。
ユーザーと権限の管理
各テナントは、ユーザーと権限の管理に対する管理者のフルアクセス権を持ち、独自のロールを作成できます。
アプリケーション管理
各テナントはアプリケーションを個別に管理し、アプリケーションを追加することでプラットフォームを拡張できます。
使用状況の統計と請求
通常、API コールとストレージごとに課金されるクラウドベースのビジネスモデルは、テナントを分けることで可能になります。
ただし、各テナントには専用のデータベースがあるため、各テナント内ではそのテナント自体の IoT データのみアクセスできます。これはデータを明確に分離するという点で多くのメリットがある一方で、テナント間でデータを共有するにはデータをコピーする必要があり、データが二重に保存されることになります。
シングルテナントとマルチテナント アプローチにおけるロールベースのアクセス制御（RBAC: Role-based access control）のメリットとデメリットの詳細については、RBACとマルチテナント アプローチの比較 を参照してください。
Things Cloud テナントのコンセプトとして、下から上へ、次のような 3 レベルの階層を構築します。
これらの 3 つのレベルは、特に管理に関する範囲が異なります（以下をご覧ください）。
階層の一番下には、Things Cloud の 標準テナント（サブテナント） のコンセプトで表されるシングルテナントがあります。
標準テナント（サブテナント） は、Things Cloud プラットフォームのほとんどのデバイス管理および監視機能を提供しますが、管理面に関しては一定の制限があります。
標準テナント（サブテナント） では、複数の関係者は個別のユーザーとして反映されます。テナント内のすべてのユーザーは、同じ URL とデータスペースを共有するため、ロールの概念 に基づいてアクセス権を割り当てることによってのみ、相互に分離することができます。つまり、ロールを使用すると、特定のユーザーにテナントの制限された可視性（例えば、そのユーザーに所属するデバイスのみ）を与えることができます。
標準テナント（サブテナント）は、マネジメントテナントの直接のサブテナントとして、完全に標準化された機能を提供します。
標準テナント（サブテナント） の管理の詳細については、標準テナント（サブテナント）管理 を参照してください。
エンタープライズテナント（親テナント）は、標準テナント（サブテナント）と比較して管理機能が追加されます。主な違いは マルチテナント であることです。
エンタープライズテナント（親テナント） を使用すると、次のことが可能となります。
マルチテナント も参照してください。
さらに、エンタープライズテナント（親テナント）には次の追加機能が含まれます。
エンタープライズテナント（親テナント）は、標準機能と一部の個別カスタマイズが組み合わされています。
この追加機能の使用方法と、エンタープライズテナント（親テナント）の追加管理オプションの詳細については、エンタープライズテナント（親テナント） を参照してください。
マネジメントテナントは、Things Cloud テナントの最上位階層です。
すべての Things Cloud の配置は、マネジメントテナント とともに提供されます。マネジメントテナント は、プラットフォームレベルで同じ配置内のすべてのテナントを管理するために使用され、プラットフォームを完全に制御できます。
Things Cloud クラウドのインスタンスでは、Things Cloud のクラウド運用チームのみが マネジメントテナント にアクセスできます。ただし、基本的にお客様の了承を得ないでアクセスしません。
マネジメントテナント にアクセスできるのは、専用／ホスティングされたクラウド デプロイメント、オンプレミス デプロイメント、または Things Cloud エッジオファリングとして、独自の Things Cloud インスタンスをセットアップした場合のみです。
アプリケーションやサービスを顧客に提供することを考えるとき、プラットフォーム内で顧客をどのように構成するか、どこかの時点で考える必要があります。Things Cloud は 2 つの異なる方法でそのお手伝いをします。
ロールベースのアクセス制御（RBAC: Role-based access control） は、Things Cloud プラットフォームのすべてのテナントの一部であり、各ユーザーの権限を細かく定義できます。特定のユーザー（顧客など）に、テナントの部分的な表示のみ（そのユーザーに属するデバイスのみ）を提供するために使用できます。
それに加えて、Things Cloud プラットフォームは一般に マルチテナント プラットフォーム であり、プラットフォーム内の他のテナントと同じように機能する独自のサブテナントを作成することもできます。
これにより、顧客を組織化するための 2 つの選択肢があります。顧客ごとにテナントを作成するか、1 つのテナントで RBAC を使用して顧客同士を相互に保護し複数の顧客を管理するかの、いずれかです。
以下では、両方のアプローチをより詳しく検討し、それぞれの方法で解決する手段を説明したいくつかのユースケースをざっと見ていきます。どちらのアプローチが自社のビジネスケースに適しているかを判断できるようになります。Things Cloud は、テナント階層を使用してテナントを管理するように設計されています。その結果、ロールベースのアクセス制御をする場合、顧客環境で対応する必要があるいくつかの場面で、より困難になります。両方のアプローチを組み合わせて使用することで、あなたとあなたの顧客に最も柔軟なアプローチを提供できます。
特定のユースケースについて詳しく説明する前に、各アプローチの一般的なセットアップと、その基礎となるコンセプトを明確にする必要があります。
通常、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 は現在 RBAC をサポートしていません。テナントで DataHub にアクセスできるユーザーは、使用中の権限に関係なく、メジャーメント、イベント、アラーム、およびインベントリの詳細を同じデータレイクにオフロードできます。オフロードジョブをユーザーのデータのみに制限することは可能ですが、これには慎重な手動構成が必要です。DataHub は現在、テナントごとに 1 つのデータレイク フォルダ接続のみをサポートしています。また、分析ツールからデータレイクにアクセスするために作成されるユーザーは 1 人だけであるため、データレイク内のデータにセキュリティを適用することも現在は不可能です。