マルチテナント環境の設定

Deep Securityのオンプレミスソフトウェアインストール版およびAWS Marketplace BYOLライセンスオプション版のみに該当します。

Deep Securityのマルチテナント機能では、1つのDeep Security Manager内に複数の独立した管理環境を作成できます。各テナントでは、独自の設定とポリシーを適用でき、そのテナントのイベントを監視できます。この機能は、準備環境と実稼働環境を別々に作成する場合や、組織の事業単位ごとに環境を作成する必要がある場合に役立ちます。また、サービスモデルの顧客にDeep Securityをプロビジョニングする場合にも、マルチテナント機能を利用できます。

マルチテナントを有効にすると、「プライマリテナント」ではDeep Security Managerの通常のインストール環境の機能がすべて維持されます。ただし、プライマリテナントがその後作成するテナントについては、システムの構成に基づいて、利用できるDeep Securityの機能を制限できます。

このトピックの内容:

マルチテナントの要件

次の製品ではマルチテナントを設定できません。

マルチテナントにはアクティベーションコードが別途必要です。また、通常のDeep Security Managerの 要件に加えてデータベース要件がいくつか追加されます。詳細については、Deep Security Managerで使用するデータベースの準備データベースのユーザアカウントを設定する

マルチノードのDeep Security Manager(複数のDeep Security Managerをインストールし、すべて同じデータベースを使用します)を設定して、スケーラビリティを確保することもお勧めします。すべてのManagerノードが、任意のテナントのGUI、ハートビート、またはジョブの要求を処理します。バックグラウンド処理では、ジョブのキューイング、保守などのバックグラウンドタスクを管理するマネージャノードがテナントごとに割り当てられます。タスクは、Managerノードが追加またはオフラインにされたときに、残りのノードに再調整されます。

マルチテナントを有効にすると、Deep Security Managerの現在のインストール環境がプライマリテナント (t0) になり、テナントの作成などの特別な権限を付与されます。テナントを作成すると、そのテナントは特定の機能の使用を制限され、該当する機能を操作するUIはDeep Security Managerに表示されません。たとえば、テナントが他のテナントを作成することはできません。詳細については、マルチテナント環境の設定

マルチテナントを有効にする

重要: マルチテナントは、いったん有効にすると無効にすることができず、プライマリテナントを削除することもできません。

  1. Deep Security Managerで、[管理]→[システム設定]→[詳細] の順に選択します。[マルチテナントのオプション] エリアで [マルチテナントモードの有効化] をクリックします。
  2. マルチテナント設定ウィザードが表示されます。マルチテナントのアクティベーションコードを入力し、[次へ] をクリックします。
  3. 使用するライセンスモードを選択します。

    プライマリテナントからライセンスを継承: すべてのテナントにプライマリテナントと同じライセンスを使用します。このオプションは、 準備環境でマルチテナントを使用する場合や、同じ組織内の部門ごとにテナントを設定する場合に推奨されます。

    テナント単位の ライセンス: Deep Securityをサービスとして提供している場合は、このオプションが推奨されます。この設定では、テナント作成時にDeep Security APIを使用して ライセンスを提供するか、またはテナントがDeep Security Managerに初めてログオンするときにライセンスを入力できます。

  4. [次へ] をクリックします。ウィザードが終了したら、[管理]→[システム設定]→[テナント] の順に選択して新しい [テナント] 画面を表示し、そこで マルチテナントのオプションを設定できます。この画面のオプションについては、Deep Security Managerの右上にある [ヘルプ] をクリックしてください。

テナントを作成する

マルチテナントモードを有効にしたら、[管理] セクションの [テナント] 画面から テナントを管理できます。

  1. Deep Security Managerで、[管理][テナント] の順に選択し、[新規] をクリックします。
  2. 新規テナントウィザードが表示されます。テナントのアカウント名を入力します。アカウント名には、プライマリテナント用に予約されている「Primary」以外の任意の名前を 使用できます。
  3. テナントの連絡先として使用するメールアドレスを入力します。
  4. ロケールを選択します。ロケールによって、テナントでのDeep Security Managerのユーザインタフェースの言語が決まります。
  5. タイムゾーンを選択します。テナント関連のイベントは、ここで指定するタイムゾーンでテナントのユーザに表示されます。
  6. 複数のデータベースを使用しているDeep Securityインストール環境では、新しいテナントアカウントを格納するデータベースサーバを Deep Securityで自動的に選択するオプションを選択するか ([自動 - 設定なし])、または特定のサーバを指定できます。

    注意: データベースが1つしかない場合は、このオプションが表示されません。新しいテナントの受け入れを停止しているデータベースサーバは、 リストに表示されません。

  7. 新しいテナントアカウントの最初のユーザのユーザ名を入力します。
  8. 次の3つのパスワードオプションのうち1つを選択します。

    メールなし: テナントの最初のユーザのユーザ名とパスワードを設定します。メールは送信されません。

    確認リンクをメール: テナントの最初のユーザのパスワードを設定します。ただし、ユーザが受信した確認メールのリンクをクリックするまでアカウントは有効になりません。

    生成した パスワードをメール: パスワードを指定せずにテナントを生成できます。

    ヒント:

    3つのオプションはすべて、REST APIにより利用可能となります。確認オプションは、一般ユーザが登録する場合に適した方法を提供します。テナントの作成者がプログラムではなく人であることを確認する方法として、CAPTCHAが 推奨されています。

    メール確認によって、ユーザがアカウントにアクセスする前に、指定されたメールアドレスがユーザのものであることを確認できます。

  9. [次へ] をクリックしてウィザードを終了し、テナントを作成します。

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

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

テナントに送信されるメッセージの例

確認リンクをメール: アカウント確認要求

Deep Securityへようこそ。アカウントの使用を開始するには、次の確認用URLをクリックしてください。パスワードを入力するとコンソールに アクセスできます。
アカウント名: AnyCo
ユーザ名: admin
アカウントを有効にするには次のURLをクリック:
https://managerIP:portnumber/SignIn.screen?confirmation=1A16EC7A-D84F-D451-05F6-706095B6F646&tenantAccount=AnyCo&username=admin

生成したパスワードをメール

1通目のメール: アカウントとユーザ名の通知

Deep Securityへようこそ。新しいアカウントが作成されました。パスワードは別のメールでお知らせします。

アカウント名:AnyCo
ユーザ名: admin
Deep Securityには次のURLからアクセスできます:
https://managerIP:portnumber/SignIn.screen? tenantAccount=AnyCo&username=admin

2通目のメール: パスワード通知

Deep Securityアカウント用に自動生成されたパスワードをお知らせします。アカウント名とユーザ名、Deep Securityにアクセスするためのリンクを 別のメールでお知らせします。

パスワード: z3IgRUQ0jaFi

マルチテナントに関するヒント

攻撃の予兆IPリスト

マルチテナント環境では、テナントがDeep Security ManagerのIPアドレスを「攻撃の予兆を無視」IPリスト ([ポリシー]→[共通オブジェクト]→[リスト]→[IPリスト] の順に選択) に追加することが必要になる場合があります。これは、「攻撃の予兆の検出: ネットワークまたはポートの検索」警告が表示されないようにするためです。

複数のデータベースサーバを使用する

マルチテナントでは、複数のデータベース (Microsoft SQLを使用する場合) または複数のユーザ (Oracleを使用する場合) が使用されます。規模を拡大する場合は、 Deep Security Managerを複数のデータベースサーバに接続し、使用可能な一連のデータベースサーバに新しいテナントを自動的に分散させることができます。データベースのユーザアカウントを設定するを参照してください。

テナントの「削除の保留中」状態

テナントは削除できますが、処理はすぐに実行されません。Deep Securityは、テナント関連ジョブがすべて終了したことを確認してからレコードを削除します。また、データベースが削除されるまでの間、テナントは「削除の保留中」状態になります。

[システム設定] のマルチテナントオプション

[管理]→[システム設定]→[テナント] 画面では次のオプションを設定できます。

「初期設定のRelayグループ」内のRelayの使用をテナントに許可 (割り当てられていないRelay): プライマリテナントで設定されているRelay有効化済みAgentにテナントが自動的に アクセスできるようにします。これにより、セキュリティアップデート用に専用のRelay有効化済みAgentをテナント側で設定する必要がなくなります。

予約タスク「バックアップ」の使用をテナントに許可: ほとんどの場合、バックアップはデータベース管理者によって管理されるため、このオプションは 選択しないままにしておきます。

予約タスク「スクリプトの実行」の使用をテナントに許可: スクリプトは、システムへのアクセスを潜在的な危険にさらす可能性があります。ただし、 スクリプトはファイルシステムのアクセス権を使用してDeep Security Managerにインストールされるため、リスクを軽減できます。

テナントを管理する

[テナント] 画面 ([管理]→[テナント]) には、全テナントのリストが表示されます。テナントの ステータスは次のいずれかです。

  • 作成: 作成済みですが、アクティベーションのメールがまだテナントのユーザに送信されていません。
  • 設定が必要: 作成済みですが、テナントのユーザに送信された確認メールのアクティベーションリンクがまだクリックされていません (このステータスは 手動で変更できます)。
  • 有効: 完全にオンラインで管理されている状態です。
  • 一時停止: ログオンが許可されていません。
  • 削除の保留中: テナントは削除されましたが、処理はまだ実行されていません。
  • データベースアップグレード失敗: アップグレードに失敗したテナントです。[データベースアップグレード] ボタンで、この問題を解決できます。

テナントのプロパティ

テナントをダブルクリックすると、テナントの [プロパティ] 画面が表示されます。

一般

テナントのロケール、タイムゾーン、および状態を変更できます。タイムゾーンとロケールを変更しても、既存のテナントユーザには反映されません。テナント内の 新規ユーザ、イベント、およびユーザ固有ではないUIのその他の部分にのみ反映されます。

データベース名は、このテナントに使用されているデータベースの名前です。ハイパーリンクから、テナントデータベースのプロパティにアクセスできます。

モジュール

[モジュール] タブには、保護モジュールの表示に関するオプションがあります。表示オプションを選択することで、 各テナントに表示されるモジュールを調整できます。初期設定では、ライセンス許可されていないモジュールはすべて非表示になります。この設定は、[ライセンス許可されていないモジュールを常に非表示] をオフにすることで変更できます。選択したモジュールを テナント単位で表示することもできます。

[プライマリテナントからライセンスを継承] を選択した場合、プライマリテナントにライセンス許可されているすべての機能が すべてのテナントに表示されます。つまり、[ライセンス許可されていないモジュールを常に非表示] の選択を解除した場合でも、この継承オプションを選択すると、ライセンス許可されていないすべてのモジュールが 非表示になります。

「テナント単位」のライセンスを使用している場合、初期設定では各テナントにライセンス許可されているモジュールだけが表示されます。

テスト環境でDeep Securityを評価している場合、完全なマルチテナント環境を確認するには、マルチテナントのデモ モードを有効にします。デモモードの場合、Managerは、シミュレートされたテナント、コンピュータ、イベント、アラート、およびその他のデータをデータベースに入力します。最初に7日分のデータが 生成されますが、その後も、Managerの [ダッシュボード]、[レポート]、および [イベント] の各画面にデータを入力するために新しいデータが継続的に生成されます。

デモモードは、実稼働環境では使用しないでください。

機能

管理者は、特定のテナントに対して特定の機能のオン/オフを切り替えることができます。これらの使用可能な機能は、時間とともに変化する場合があります。現在、 イベント転送の詳細な説明 を有効にして、Amazon SNSまたはSIEMに転送されるイベントの完全な説明を含めることができます。そうでない場合、説明は省略する。

統計

[統計] タブには、データベースのサイズ、処理済みジョブ、ログオン、セキュリティイベント、システムイベントなど、現在のテナントに関する情報が表示されます。グラフは、 過去24時間のデータを示します。

Deep Security Agentの有効化

[Agentの有効化] タブには、このテナントのコンピュータでAgentを有効にするためのコマンドが表示されます。このコマンドは、Agentのインストールディレクトリから実行できます。Agentが有効になると、 テナントはDeep Security Managerを使用して、ポリシーの割り当てやその他の設定を実行できます。

テナントに表示される内容

マルチテナントが有効になっている場合は、ログオンページに追加の [アカウント名] テキストフィールドが表示されます。

テナントは、ユーザ名とパスワードに加えてアカウント名を入力する必要があります。アカウント名があるので、ユーザ名が重複していてもかまいません(たとえば、 複数のテナントが同じActive Directoryサーバと同期する場合)。

プライマリテナントとしてログインするときは、アカウント名を空白のままにするか、「Primary」と入力します。

テナントユーザは、Deep Security Manager UIの一部の機能を使用できません。次の画面は、テナントには表示されません。

  • Managerノードのウィジェット
  • マルチテナントのウィジェット
  • [管理]→[システム情報]
  • [管理]→[ライセンス] (継承オプションが選択されている場合)
  • [管理]→[Managerノード]
  • [管理]→[テナント]
  • [管理]→[システム設定]
    • [テナント] タブ
    • [セキュリティ] タブ→[ログオンページのメッセージ]
    • [アップデート] タブ→プライマリテナントのRelayの使用を テナントに許可する設定
    • [詳細] タブ→[ロードバランサ]
    • [詳細] タブ→[プラグイン] セクション
  • テナントに関係がないヘルプの内容
  • テナントに関係がない一部のレポート
  • マルチテナントオプションに基づくその他の機能 (後述)
  • 一部のアラートタイプも非表示:
    • ハートビートサーバの失敗
    • Managerのディスク容量不足
    • Managerがオフライン
    • Managerの時刻が非同期
    • 新しいバージョンの Deep Security Managerが利用可能
    • コンピュータ数がデータベースの上限を超過
    • ライセンスの継承が有効になっている場合、ライセンス関連の アラート

テナントからは、プライマリテナントのマルチテナント機能や、他のテナントのデータは確認できません。さらに、一部のAPIはプライマリテナント権限(他のテナントの作成など)でのみ使用できるため、制限されています。

テナントユーザが使用できる機能と使用できない機能の詳細については、マルチテナント設定を参照してください。

テナントは、複数のユーザアカウントに役割に基づいたアクセス制御を使用して、アクセスをさらに分割することもできます。また、ユーザのActive Directory統合を使用して、認証をドメインに委任することもできます。この場合も、テナントの認証にテナントのアカウント名が必要です。

Agentからのリモート有効化

Agentからのリモート有効化は、すべてのテナントで初期設定で有効になっています。

プライマリテナントにおけるAgentからのリモート有効化とは異なり、他のテナントユーザが有効化を実行するには、パスワードとテナントIDが 必要です。

Agentからのリモート有効化に必要なこれらの情報を確認するには、[管理]→[アップデート]→[ソフトウェア]→> [ローカル] をクリックし、Agentソフトウェアを選択して、[インストールスクリプトの生成] ボタンをクリックします。WindowsコンピュータにおけるAgentからの リモート有効化のスクリプトの例を次に示します。

dsa_control -a dsm://<ホストまたはIP>:4120/ "tenantID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" "token:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

テナントの診断

Managerの診断パッケージに含まれるデータは機密性が高いので、テナントからこのパッケージにアクセスすることはできません。ただし、テナントは、 コンピュータエディタを開き、[概要] 画面の [処理] タブで [診断パッケージの作成] を選択することで、Agentの診断情報を生成できます。

使用状況の監視

Deep Security Managerでは、テナントの使用状況に関するデータが記録されます。この情報は、ダッシュボードの [テナントの保護アクティビティ] ウィジェット、 テナントの [プロパティ] 画面の [統計] タブ、およびチャージバックレポートに表示されます。この情報は、ステータス監視REST APIからもアクセスできます。このAPIは、[管理]→[システム設定]→[詳細設定]→[ステータス監視API]の順に選択して有効化/無効化できます。

レポートに表示するチャージバック情報の種類はカスタマイズできます。この設定は、サービスプロバイダ環境で必要な、さまざまな課金モデルに 対応するように設計されています。企業では、事業単位ごとの使用状況を確認する場合に便利です。また、この情報を使用して Deep Securityシステム全体の使用状況を監視し、異常の兆候を検出することができます。たとえば、1つのテナントでセキュリティイベントアクティビティが急増している場合は、 攻撃を受けている可能性があります。

マルチテナントのダッシュボードおよびレポート

マルチテナントが有効になっているとき、プライマリテナントのユーザには、テナントの使用状況を監視できる次のダッシュボードウィジェットが追加されます。

  • テナントのデータベース使用状況
  • テナントのジョブアクティビティ
  • テナントの保護アクティビティ
  • テナントのセキュリティイベントアクティビティ
  • テナントのログオンアクティビティ
  • テナントのシステムイベントアクティビティ
  • テナント

同じ情報を、[管理]→[テナント] 画面 (一部はオプションの列) とテナントの [プロパティ] 画面の [統計] タブで確認できます。

この情報によって、システム全体の使用状況を監視し、異常の兆候を検出することができます。たとえば、1つのテナントでセキュリティイベントアクティビティが急増している場合、攻撃を受けている可能性があります。

チャージバックレポートには、さらに詳細な情報が含まれます ([イベントとレポート] セクション)。このレポートは、保護時間、現在のデータベースサイズ、コンピュータの台数 (有効および無効) をテナントごとに示します。

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

各テナントのデータの大部分は別個のデータベースに保存されます。このデータベースは、他のテナントと同じデータベースサーバに共存させることも、専用のデータベースサーバに分離することもできます。いずれの場合も、一部のデータはプライマリデータベース (Deep Security Managerと同時にインストールされたデータベース) だけに保存されます。複数のデータベースサーバが利用可能な場合、テナントは、負荷が最も低いデータベースに作成されます。

単一テナント マルチテナント
管理対象コンピュータ 100,000 1,000,000以上
Deep Security Managerのノード 1-5 1-50
データベース 1 1-10,000
データベースサーバ 1 (複製あり、またはなし) 1-100

データベースへの各テナントのデータの分割には、次のメリットがあります。

  • データ削除: テナントを削除すると、製品でサポートされているテナントのデータがすべて削除されます。
  • バックアップ: 各テナントのデータに、それぞれ異なるバックアップポリシーを適用できます。これは、準備環境と実稼働環境でテナントを使用し、 準備環境のバックアップ要件が厳しくない場合に便利です(バックアップは、Deep Security Managerを設定した 管理者が実行します)。
  • 調整: 将来、すべてのデータベースサーバで負荷を均等に分散するための再調整が可能です。

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

SQL ServerとOracleとでは、データベースの概念を表す用語が、次のように異なります。

SQL Server Oracle
複数のテナントが実行されるプロセス データベースサーバ データベース
単一のテナントのデータ データベース テーブルスペース/ユーザ

次のセクションでは、SQL ServerとOracleの両方にSQL Serverの用語を使用します。

SQL Server

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

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

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

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

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

Oracle

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

Oracleでは、引用符で囲めば特殊文字をデータベースオブジェクト名に使用できますが、Deep Securityでは、 データベースオブジェクト名内の特殊文字がサポートされていません。引用符を使わずに名前で使用できる文字については、次のOracleのサイトを参照してください。http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements008.htm#SQLRF0 0223
Deep Securityのテナントのデータベース名は、Oracleのメイン (プライマリテナント) データベースから派生します。たとえば、メインデータベースが「MAINDB」の場合、 最初のテナントのデータベース名は「MAINDB_1」、2番目のテナントのデータベース名は「MAINDB_2」(以下同様) になります (メインデータベース名を短くすると、 テナントのデータベース名が読み取りやすくなります)。

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

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

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

複数のデータベースサーバを設定する

初期設定では、すべてのテナントがDeep Security Managerと同じデータベースサーバ上に作成されます。スケーラビリティ向上のために、 Deep Security Managerではデータベースサーバを追加することもできます (追加のデータベースサーバはセカンダリデータベースと呼ばれることもあります)。テナントを追加するときに、 新しいテナントアカウントを格納するデータベースサーバをDeep Securityで自動的に選択するオプションを選択するか、または特定のサーバを指定できます。

データベースを追加するには、[管理][システム設定][テナント] に移動し、[データベースサーバ] の [データベースサーバの表示] をクリックします。[新規] をクリックしてデータベースサーバを追加します。

SQL Serverの場合、セカンダリデータベースサーバにはホスト名、ユーザ名、およびパスワードが必要です (名前付きインスタンスとドメインはオプションです)。ユーザ (Deep Security Manager) には、次の権限が必要です。

  • データベースの作成
  • データベースの削除
  • スキーマの定義

このアカウントは、データベースの作成だけでなく、作成されたデータベースに対する認証にも使用されます。

Oracleのマルチテナントでは異なるモデルが使用されます。新しいデータベース定義で、表領域にバインドされるユーザが定義されます。このユーザを 使用して、Oracleにおける追加ユーザの作成が自動化されます。

セカンダリデータベースを削除または変更する

サーバ上にテナントが存在しない場合は、プライマリデータベース以外のデータベースサーバを削除できます。

セカンダリサーバのホスト名、ユーザ名、パスワード、またはその他の情報が変わった場合は、Deep Security Managerコンソールでこれらの値を変更できます。プライマリサーバの値を変更するには、Deep Security Managerのすべてのノードをシャットダウンし、 dsm.propertiesファイルを編集して新しい情報を追加する必要があります。

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ノードのディスクにあるserver*.logには、ログの原因となったテナント (該当する場合はユーザ) の名前に関する 追加情報が含まれます。この情報は、問題の原因特定に役立つ場合があります。

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

-Tenantname "account name"

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

ロードバランサ

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

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

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

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

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

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

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

vCloudとの統合の詳細については、vCloud環境でのAgentベースの保護の実施を参照してください。