マルチテナント (詳細)

データベースのユーザアカウントの設定

SQL Server

マルチテナントを使用するには、ソフトウェアでデータベースを作成できる必要があるので、SQL Serverのdbcreatorの役割が必要です。次に例を示します。

プライマリテナントのユーザの役割については、メインデータベースのDB所有者を割り当てることが重要です。

必要な場合は、権限を詳細に設定し、スキーマの変更とデータのアクセスのみを許可することもできます。

dbcreatorの役割を持つアカウントが作成したデータベースは、自動的にそのユーザの所有になります。たとえば、最初のテナント作成後のユーザプロパティは次のとおりです。

セカンダリデータベースサーバの最初のアカウントを作成するには、dbcreatorサーバ役割のみが必要です。ユーザマッピングを定義する必要はありません。

Oracle

Oracleにおけるマルチテナントは、SQL Serverの場合と似ていますが、重要な違いがいくつかあります。SQL Serverでは、データベースサーバごとにユーザアカウントが1つですが、Oracleではテナントごとにユーザアカウントが1つです。Deep Securityをインストールしたユーザがプライマリテナントに対応付けられます。このユーザには、追加のユーザやテーブルスペースを割り当てる権限を付与できます。

マルチテナントを有効にする場合、Oracleの次の権限を割り当てる必要があります。

テナントは、長いランダムパスワードを持つユーザとして作成され、次の権限が付与されます。

Oracleのセカンダリサーバ用に、最初のユーザアカウント (ブートストラップユーザアカウント) を作成する必要があります。このユーザは、テーブルスペースが基本的に空になります。設定は、プライマリユーザアカウントと同じです。

API

Deep Security Managerには、次の処理を実行するためのREST APIが含まれています。

1. マルチテナントの有効化
2. テナントの管理
3. 監視データのアクセス
4. チャージバックデータ (保護の利用状況) のアクセス
5. セカンダリデータベースサーバの管理

また、従来のSOAP APIに、3つ目のパラメータとしてテナントアカウント名を受け取る新しい認証メソッドがあります。

REST APIの詳細については、REST APIのドキュメントを参照してください。

アップグレード

アップグレードは、これまでのバージョンと変わりません。インストーラが実行され、既存のインストールが検出されます。次に、アップグレードオプションが表示されます。アップグレードが選択された場合、他のノードにシャットダウンするように通知してから、アップグレードの処理が開始されます。

プライマリテナントが最初にアップグレードされ、その後、テナントが並行して処理されます (5テナントずつ)。インストーラが終了したら、残りのManagerノードで同じインストーラパッケージを実行します。

テナントのアップグレード中に問題が発生した場合は、テナントの状態 ([管理]→[テナント] 画面) が「データベースアップグレード失敗 (オフライン)」になります。テナントのインタフェースを使用して、強制的にアップグレードを実行できます。

テナントのサポート

プライマリテナントがテナントのユーザインタフェースにアクセスする必要が生じる場合があります。テナントリストとテナントプロパティの画面に、特定のテナントとして認証するオプションがあり、このオプションを使用すると、すぐに管理者アクセスが可能です。

ユーザは、接頭辞「support_」を使用する特殊なアカウントとしてログオンします。たとえば、プライマリテナントのユーザ「jdoe」が、テナントとしてログオンした場合、「Full Access」役割を持つ「support_jdoe」というアカウントが作成されます。サポートユーザがタイムアウトになるか、アカウントからログアウトすると、ユーザは削除されます。

テナントは、このユーザアカウントの作成、ログオン、ログアウト、および削除と、その他の操作をシステムイベントで確認できます。

プライマリテナントのユーザは、他にも次の診断ツールを使用できます。

1. [管理]→[システム情報] 画面には、テナントのメモリ使用量とスレッドの状態に関する追加情報が表示されます。この情報は、直接使用する以外に、トレンドマイクロのサポートに提供することもできます。
2. Managerノードのディスクにあるserver0.logには、ログの原因となったテナント (該当する場合はユーザ) の名前に関する追加情報が含まれます。この情報は、問題の原因特定に役立つ場合があります。

テナントが、GUIにないカスタム調整を行う必要がある場合があります。これは通常、トレンドマイクロのサポートからの要望に応じて行います。このような設定を変更するコマンドラインユーティリティは、次の引数を受けます。

-Tenantname "account name"

この引数を使用して、設定の変更や、その他のコマンドライン処理の対象として特定のテナントを指定できます。引数を省略した場合は、プライマリテナントに対して処理が実行されます。

ロードバランサ

初期設定では、複数ノードのManagerから、すべてのManagerノードのアドレスが、すべてのAgentとVirtual Applianceに提供されます。AgentとVirtual Applianceは、このアドレスのリストを使用して、アクセスするノードをランダムに選択し、接続できるノードがなくなるまで (またはノードがすべてビジー状態になるまで) リスト内の残りのノードへのアクセスを続行します。接続できるノードがなかった場合は、次のハートビートまで待ってから再度実行します。これは、Managerノードの数が固定されている環境に適しており、可用性とスケーラビリティのためにManagerノードの前にロードバランサを設定する必要をなくします。

マルチテナント環境では、クラウド環境のオートスケーリング機能などを使用して、必要に応じてManagerノードを追加または削除する場合があります。このような場合、Managerを追加または削除すると、環境内のすべてのAgentとVirtual Applianceのアップデートが発生します。このアップデートを回避するため、ロードバランサの設定を使用できます。

ロードバランサは、トラフィックの種類ごとに異なるポートを使用するように設定できます。また、ロードバランサでポートのリダイレクトがサポートされている場合は、3つのロードバランサを使用して、必要なすべてのプロトコルをポート443を経由して公開できます。

いずれの場合も、ロードバランサは、セッションを維持するTCPのロードバランサとして設定します (SSL終端ではない)。この方法で、Agent/Virtual ApplianceとManagerの間で通信が最初から最後まで直接実行されます。次の接続は、別のノードに分散される可能性があります。

Deep Security Virtual Appliance環境のマルチテナント

VMware環境にDeep Securityを導入する場合、vCenterとvShieldコネクタをプライマリテナントに構成し、vCloud Connectorをテナントに構成することができます。正しく設定された場合、プライマリテナントでは、ESXiサーバ、Deep Security Virtual Appliance、およびその他のインフラストラクチャコンポーネントを確認でき、テナントでは、vCloud環境でテナントが所有する仮想マシンのみを確認できます。テナントでは、Agentを導入しなくてもこれらの仮想マシンを有効化できます。

このような環境を設定にするには、[管理]→[システム設定]→[Agent] に進み、[ApplianceによるvCloud仮想マシンの保護を許可] チェックボックスをオンにします。

vCloudの統合の詳細については、インストールガイドを参照してください。

詳細な技術情報

各テナントデータベースには約100MBのディスク容量のオーバーヘッドがあります (初期設定でシステムに入力されるルール、ポリシー、およびイベントに起因)。

テナントの作成には、スキーマの作成と、初期データの登録が必要なので、30秒～4分程度かかります。この方法で、新しいテナントは最新の設定になり、またデータベーステンプレートを管理する負担、特に複数のデータベースサーバを管理する負担が軽減されます。