第4回 Commvaultが提供するマルチテナント機能 (前編)
第4回となる今回は、Commvaultの特徴的な機能としてしばしばとりあげられるマルチテナント機能をご紹介していきます。
通常、マルチテナントとは、1つのシステムやサービスを複数の企業もしくはユーザーで共有して使うことを意味します。しかしながら、「バックアップ ソフトウェアでのマルチテナントって何だろう?」と思う方もいらっしゃるかもしれません。
今回のブログでは、Commvaultが提供するマルチテナント機能の説明の前編ということで、そもそもなぜバックアップ ソフトにマルチテナント機能が必要なのか、Commvaultはどのようにしてマルチテナントを実現するのかについてご紹介していきます。そして、来月配信予定の次回のブログ（後編）で、どのようにしてマルチテナント機能を使うのかについて、簡単な例で設定方法をご紹介していく予定です。
(1) バックアップソフトウェアでのマルチテナント機能の必要性
最初に、バックアップ ソフトウェアでのマルチテナント機能の必要性について考えてみます。ここでは、ホスティング サービスを行うサービス プロバイダーを例に考えてみます（※この例はフィクションです）。
サービス プロバイダーのX社は、A社、B社、C社の3社の顧客のシステムをホスティングしています。X社は顧客からの要望で、顧客のシステムをバックアップするためのバックアップ システムを構築しサービス提供することに決めました。そこで、実際にバックアップ システムを本番環境にサービスインする前にまずはテスト環境で検証してみることにしました。
テスト環境には、A社、B社、C社のシステムを想定した3台のサーバー (それぞれ、サーバーA、サーバーB、サーバーCとします) を準備しました。X社では、あるバックアップ ソフトウェアを使用して、1台のバックアップ サーバーを構築し、そのバックアップ ソフトウェアのエージェントをサーバーA、サーバーB、サーバーCにインストールし、エージェントを使用してバックアップ / リストアすることにしました。このテスト環境の構成を簡単に図にしてみると以下のような状態です。
このテスト環境ではバックアップもリストアも特に問題なく成功しましたので、X社では具体的にどのようにバックアップ システムを運用するかを考えることにしました。運用方法の案として、案1、案2の2つの案を考えました。案1はX社がA社、B社、C社すべてのバックアップ / リストアの運用を行う案、案2はA社、B社、C社それぞれにバックアップ ソフトウェアの管理者権限を与えて各社に運用を任せる案です。ところが、案1、案2ともに検討していくうちに簡単な話ではないことが分かってきました。
- 【案1】 「X社がA社、B社、C社すべてのバックアップ / リストアの運用を行う」 の課題： 運用者であるX社の負担が大きくなる
この場合、X社がA社、B社、C社すべてのサーバーのバックアップ / リストアの運用を行うことになります。バックアップに関しては最初に要件を明確にし、バックアップ実行をスケジューリングしておけば人の手を必要とする作業は最小限に留めることも可能と考えられますが、特に大きな懸念点となったのはリストアです。データに問題が発生しリストアが必要となる場合、顧客の3社はX社にリストア処理を依頼することになります。顧客側としては待ち時間が発生することになりますが、サービス プロバイダーのX社の立場からすると、データのリストアは急ぎの対応や夜間の対応なども求められることが考えられます (以下がイメージ図です)。そのため、X社の負担が大きくこの運用では難しくなることが懸念点として挙げられました。
- 【案2】 「A社、B社、C社それぞれにバックアップ ソフトウェアの管理者権限を与えて各社に運用を任せる」 の課題： 管理者権限では他社にデータが参照されてしまう
この場合、A社、B社、C社それぞれにバックアップ ソフトウェアの管理者権限を与えて各社に運用を任せることになります。この方法ではX社は各顧客に運用を任せることが可能でX社の負担は大きく軽減されますが、あっさりと管理者権限を渡してしまうと大変なことになることが予想できました。管理者権限を渡すと、バックアップ ソフトウェア上で何でもできてしまい、他社のデータをリストアすることも可能なため、他社のデータを参照できてしまいます。例えば、A社の場合、B社とC社のデータを参照することができ、B社とC社に自社データを見られることになります (以下がイメージ図です)。
他の顧客のデータを参照できる状態は受け入れがたいため、この状況ではバックアップ システムを運用できません。この状況を回避する方法として、各社専用のバックアップ サーバーを準備することでバックアップ インフラを分離し、それぞれの管理者権限を与えるという方法もあります （以下がイメージ図です）。しかし、これではハードウェアとソフトウェアの費用が大きくなってしまい、サービス プロバイダーのX社としては、このバックアップ システムのインフラを導入し、顧客に提供するメリットがなくなってしまうかもしれません。
このような課題を解決するのに役立つのが、Commvaultのマルチテナント機能です。Commvaultでは、CommCell環境のリソース（例えば、MediaAgentやクライアント、バックアップ デバイスであるライブラリ、バックアップの保持期限を定めるポリシー等）を論理的に区分し、Commvaultの管理コンソールにログインするユーザーに対して、必要なリソースだけを利用できるように設定することが可能です。また、ログインするユーザー毎に実行可能な操作を制限することが可能です。
今回の例で説明すると、X社は顧客A社、B社、C社それぞれに自社のサーバーのデータだけをバックアップ / リストア可能な状態とし、運用を任せることも可能になります。X社は各社別にバックアップ インフラを分離して準備する必要はありませんし、顧客であるA社、B社、C社は他社に自社のデータを参照されることもありません。
Commvaultではロールベース セキュリティの仕組みを活用することにより、バックアップのマルチテナントを実現します。ここからは、Commvaultのロールベースセキュリティの仕組みを簡単にご紹介していきます。
(2) Commvaultによるマルチテナント：ロールベースセキュリティの活用
Commvaultのロールベース セキュリティでは、3つのコンポーネントが登場します。その3つとは、ユーザー (ユーザー グループ)、ロール、エンティティのことを意味します。それぞれを簡単に説明します。ロールベース セキュリティに関しては、こちらも適宜ご参照ください。
- ユーザー （ユーザー グループ)
ユーザーは、CommCell環境で定義するユーザー、または、Active Directory等のCommvaultが連携可能な外部のドメインのユーザーを意味します。ユーザー グループはこれらのユーザーをグループ化したものです。
※Commvaultでは、Active Directory等の外部のドメインと連携可能でCommCell Consoleから外部のドメインを登録し、そのドメイン内のグループやユーザーでCommCell Consoleにログインすることが可能です。Active Directoryドメインの追加に関しては、こちらをご参照ください。
- ロール
ロールは、ユーザーまたはユーザー グループに対して割り当てる権限をセットにしたものです。適切な権限をユーザーに付与することにより、様々な設定操作やバックアップ / リストア等が可能になります。
- エンティティ
エンティティは、ロールに基づいてユーザーがアクセス可能となるCommvaultのコンポーネントです。例えばクライアントやストレージ ポリシー (バックアップの保持期限等を定義するポリシー) 等が該当します。
このユーザー、ロール、エンティティの3つを関連付けることにより、誰に(ユーザーで定義)、どのような権限を(ロールで定義)、何に対して(エンティティで定義) 与えるか をきめ細かく指定することが可能になります。
Commvaultではユーザー、ロール、エンティティの3つを完全に分離して管理しており、この3つを関連付けることできめ細かなロールベース セキュリティの設定が行えます。そのため、1人のユーザーに対して、あるエンティティに対してはロールAを割り当て、別のエンティティに対してはロールBを割り当てるといった設定が可能です。例えば、Aさんがファイル サーバーに対してはバックアップ操作もリストア操作も可能だが、メール サーバーに対してはリストア操作のみ可能、というような設定も可能です (以下がイメージ図です)。
ここまででCommvaultのロールベースセキュリティの概要をご理解いただけたのではないかと思います。次回の後編では、簡単な例を使ってロールベース セキュリティの設定方法をご説明する予定です。ご期待ください。
【参考資料】
Posted on 2018.07