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

Deep Securityのマルチテナント機能を使用すると、1つのDeep Security Manager内に個別の管理環境を作成できます。これにより、各テナントが独自の設定とポリシーを持ち、自分のイベントをモニタすることができます。これは、別々のステージング環境と本番環境を作成したい場合や、組織内の異なるビジネスユニットのために個別の環境を作成する必要がある場合に便利です。また、サービスモデルで顧客にDeep Securityを提供するためにマルチテナントを使用することもできます。

マルチテナントを有効にすると、あなた (プライマリテナント) は通常のDeep Security Managerのインストールのすべての機能を保持します。ただし、その後に作成するテナントは、システムの設定方法に基づいて、Deep Securityの機能へのアクセスがさまざまな程度に制限される可能性があります。

FIPSモードはマルチテナント環境ではサポートされていません。詳細については、FIPS 140のサポートを参照してください。

このトピックの内容:

マルチテナントの要件

次のいずれかでマルチテナントを設定することはできません:

  • Deep Security Manager VM for Azure Marketplace
  • Azure SQLデータベース

マルチテナントにはアクティベーションコードが必要です。マルチテナントには追加のデータベース要件もあります。詳細については、 データベースの要件 および データベースのユーザアカウントを設定するを参照してください。

スケーラビリティを最大化するために、複数ノードのDeep Security Managerを使用することをお勧めします (複数のノードにDeep Security Managerをインストールするを参照)。すべてのManagerノードが、任意のテナントのGUI、ハートビート、またはジョブの要求を処理します。バックグラウンド処理については、各テナントに、ジョブの処理待ち、メンテナンス、およびその他のバックグラウンドタスクを処理するManagerノードが割り当てられます。タスクは、Managerノードが追加またはオフラインにされたときに、残りのノードに再調整されます。

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

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

  1. Deep Security Managerで、管理 > システム設定 > 詳細設定に移動します。マルチテナントオプションエリアで、マルチテナントを有効にするをクリックして、マルチテナント構成ダイアログを開きます。
  2. マルチテナント構成ダイアログで、マルチテナントアクティベーションコードを入力し、次へをクリックしてください。

  3. 使用したいライセンスモードを選択してください。

    • プライマリテナントからライセンスを継承: すべてのテナントにプライマリテナントと同じライセンスを使用します。準備環境でマルチテナントを使用する場合や、同じ組織内の部門ごとにテナントを設定する場合は、このオプションが推奨されます。
    • テナントごとのライセンス: この構成では、テナントを作成する際にDeep Security APIを使用してライセンスを提供することができます。または、テナントが初めてDeep Security Managerにサインインする際にライセンスを入力することができます。

  4. [次へ] をクリックします。

    ダイアログが閉じると、管理 > システム設定 > テナントが表示され、マルチテナントオプションを設定できます。

マルチテナントを有効にすると、無効にしたり、プライマリテナントを削除したりすることはできませんのでご注意ください。

テナントを作成する

マルチテナントモードが有効になったら、[管理]→[テナント] からテナントを管理できます。

テナントの追加に必要なデータベースのユーザアカウントの権限の詳細については、データベースのユーザアカウントを設定するを参照してください。

  1. Deep Security Managerで、管理 > テナントに移動し、新規をクリックして新規テナントダイアログを開きます。
  2. 新しいテナントダイアログで、テナントアカウント名を入力します。プライマリテナント用に予約されているPrimary以外の任意の名前を使用できます。
  3. テナントへの連絡に使用されるメールアドレスを入力してください。
  4. ロケールを選択して、テナントのDeep Security Managerユーザインターフェースの言語を決定します。
  5. タイムゾーンを選択します。イベントの時間は、イベントが発生したシステムのタイムゾーンではなく、このタイムゾーンを基準にして表示されます。
  6. Deep Securityインストールで複数のデータベースを使用している場合、新しいテナントアカウントを保存するデータベースサーバをDeep Securityに自動的に選択させる (自動 -- 優先なし) か、特定のサーバを使用するかを選択します。新しいテナントを受け入れていないデータベースサーバはリストに表示されません。
  7. 新しいテナントアカウントの最初のユーザのユーザ名を入力します。

  8. 次の3つのパスワードオプションのうち1つを選択します。

    • メールなし: テナントの最初のユーザのユーザ名とパスワードを設定します。メールは送信されません。
    • 確認リンクをメール: テナントの最初のユーザのパスワードを設定します。ただし、ユーザが確認メールのリンクをクリックするまでアカウントは有効になりません。メール確認によって、ユーザがアカウントにアクセスする前に、指定されたメールアドレスがユーザのものであることを確認できます。
    • 生成したパスワードをメール: パスワードを指定せずにテナントを生成できます。

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

  9. 次へをクリックしてテナントの作成に進みます。スキーマの作成と初期データの投入により、最大で4分かかることがあります。これにより、各新しいテナントが最新の構成を持ち、特に複数のデータベースサーバー間でデータベーステンプレートを管理する負担が軽減されます。

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

Deep Security APIを使用してテナントの作成と構成を自動化できます。例については、Deep Security Automation Centerのテナントの作成と管理ガイドを参照してください。

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

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

Welcome to Deep Security! To begin using your account, click the following confirmation URL. You can then access the console using your chosen password.

Account Name: ExampleCorp

User name: admin

Click the following URL to activate your account:

https://managerIP:portnumber/SignIn.screen?confirmation=1A16EC7A-D84F-D451-05F6-706095B6F646&tenantAccount=ExampleCorp&username=admin

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

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

Welcome to Deep Security! A new account has been created for you. Your password will be generated and provided in a separate email.

Account Name: ExampleCorp

Username: admin

You can access Deep Security using the following URL:

https://managerIP:portnumber/SignIn.screen?tenantAccount=ExampleCorp&username=admin

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

This is the automatically generated password for your Deep Security account. Your Account Name, Username, and a link to access Deep Security will follow in a separate email.

Password: z3IgRUQ0jaFi

SQL Server可用性グループにテナントデータベースを追加する

Deep Security ManagerがSQL Server Always On可用性グループに接続されている場合、新しいテナントデータベースを既存の可用性グループに自動的に追加することはできません。SQL Server Always On可用性グループデータベースに接続されたDSMのテナントを追加または削除するに記載されている手順に従って手動で行うことができます。

スケーラビリティのガイドライン

テナント数が50～100、またはこれを超える環境では、スケーラビリティの問題を避けるために次のガイドラインに従う必要があります。

  • Deep Security Managerノードセット1つにつき作成するテナント数は最大2000です。
  • 1つのデータベースサーバで作成するテナント数は最大300です。
  • プライマリテナントには別のデータベースサーバを使用し、他のテナントは含めません。
  • 1テナントあたりのエージェント数は3000に制限します。
  • エージェントの総数は20000に制限します。
  • 使用するDeep Security Managerノードは最大2つです。
  • Relayを同じ場所に配置して使用しません。

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

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

攻撃の予兆IPリスト

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

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

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

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

テナントは削除できますが、処理はすぐに実行されません。Deep Securityでは、レコードを削除する前に、テナント関連のすべてのジョブが完了している必要があります。最も頻度の低いジョブは毎週実行されるため、テナントは最大で約7日間、「削除の保留中」状態のままになる可能性があります。

Deep Security ManagerがSQL Server Always On可用性グループに接続されている場合、テナントが削除されても、対応するデータベースは自動的に可用性グループから削除されません。データベース管理者は、SQL Server Always On可用性グループデータベースに接続されたDSMのテナントを追加または削除するに記載された手順に従って手動でこれを行うことができます。

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

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

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

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

テナントを管理する

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

  • 作成: 作成済みですが、アクティベーションのメールがテナントのユーザに送信されていません。
  • 確認が必要です: 作成されましたが、テナントユーザに送信された確認メール内のアクティベーションリンクがクリックされていません。この状態を手動で上書きすることができます。
  • 有効: 完全にオンラインで管理されている状態です。
  • 一時停止: ログオンが許可されていません。
  • 削除の保留中: テナントは削除できますが、すぐにではありません。保留中のジョブが終了するまで、テナントは最大で7日間、「削除の保留中」状態になることがあります。
  • データベースアップグレード失敗: アップグレードに失敗したテナントです。[データベースアップグレード] ボタンで、この問題を解決できます。

テナントのプロパティ

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

一般

ロケール、タイムゾーン、およびステータスを変更できます。変更は既存のテナントユーザには影響しません (新しいユーザ、およびユーザ固有ではないUIの一部にのみ変更が反映されます)。

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

モジュール

モジュールタブでは、保護モジュールの表示オプションを提供します。選択された表示設定は、どのテナントにどのモジュールを表示するかを調整するために使用できます。デフォルトでは、すべての未ライセンスのモジュールは非表示になっています。これを変更するには、未ライセンスのモジュールを常に非表示にするの選択を解除します。また、選択されたモジュールはテナントごとに表示することもできます。

デフォルトでは、テナントごとのライセンスを使用する場合、各テナントは自分のライセンスされたモジュールのみを表示します。

プライマリテナントからライセンスを継承を選択すると、すべてのテナントがプライマリテナントであるあなたがライセンスを持っているすべての機能を確認できます。プライマリテナントのライセンスされていないモジュールは、ライセンスされていないモジュールを常に非表示にするのオプションを選択解除しても、他のテナントには非表示になります。

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

本番環境でデモモードを使用しないでください。使用すると、デモデータが実際のデータと混ざり、実際の攻撃や不正プログラムがあるかどうかを判断するのが難しくなる可能性があります。

機能

管理者は、特定のテナントの特定の機能を有効または無効にすることができます。これらの使用可能な機能は、時間とともに変化する場合があります。

イベント転送の拡張説明を有効にすると、Deep SecurityはAmazon SNSまたはSIEMに転送されるイベントの完全な説明を含みます。そうでない場合、説明は省略されます。SAMLアイデンティティプロバイダ統合、Amazon WorkSpaces統合、アプリケーション(アプリケーションコントロール)、およびAPIレート制限(オートメーションセンター内) はデフォルトで有効になっています。

統計

統計タブには、現在のテナントに関する情報が表示されます。これには、データベースのサイズ、処理されたジョブ、ログイン、セキュリティイベント、システムイベントが含まれます。スパークラインは、過去24時間の概要を示します。

Deep Security Agentの有効化

エージェントのアクティベーションタブには、コンピュータ上でエージェントをアクティベートするために実行できるコマンドが表示されます。このコマンドは、このテナントのコンピュータのエージェントインストールディレクトリに関連しています。アクティベーションは、Deep Security Managerが安全に接続し、テナントがポリシーを割り当てたり、Deep Security Managerから他の設定手順を実行したりするために必要です。

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

マルチテナントが有効になっている場合、サインインページには追加のアカウント名フィールドがあります。

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

あなた (主テナント) としてログインする際は、アカウント名を空白のままにするか、Primaryを使用してください。

Deep Security Manager UIの一部の機能はテナントユーザには利用できません。以下の領域はテナントには非表示です:

  • マネージャノードコンポーネント
  • マルチテナントコンポーネント
  • [管理]→[システム情報]
  • 管理>ライセンス (継承が選択されている場合)
  • [管理]→[Managerノード]
  • [管理]→[テナント]

  • [管理]→[システム設定]

    • テナントタブ
    • セキュリティタブ > サインインメッセージ
    • 更新タブ > プライマリテナントからリレーを使用するテナントの許可設定
    • 詳細タブ > ロードバランサー
    • 詳細タブ > プラグ可能セクション
  • テナントに関係がないヘルプの内容
  • テナントに関係がない一部のレポート
  • マルチテナントオプションに基づくその他の機能

  • 一部のアラートも非表示になります。

    • ハートビートサーバの失敗
    • Managerのディスク容量不足
    • Managerがオフライン
    • Managerの時刻が非同期
    • 新しいバージョンの Deep Security Managerが利用可能
    • コンピュータ数がデータベースの上限を超過
    • ライセンスの継承が有効になっている場合、ライセンス関連の アラート

テナントからは、プライマリテナントのマルチテナント機能や、他のテナントのデータは確認できません。また、プライマリテナントの権限が必要な一部のAPIも制限されます (他のテナントの作成など)。

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

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

エージェントによるアクティベーションの開始

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

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

テナントは、管理 > アップデート > ソフトウェア > ローカルに移動し、エージェントソフトウェアを選択してからデプロイメントスクリプトを生成をクリックすることで、エージェントによるアクティベーションに必要な引数を確認できます。例えば、Windowsコンピュータでのエージェントによるアクティベーションのスクリプトは次のようになります。

dsa_control -a dsm://<host or IP>:4120/ "tenantID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" "token:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

テナントの診断

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

使用状況の監視

Deep Security Managerはテナントの使用状況に関するデータを記録します。これを表示するには、ダッシュボードのテナント保護アクティビティ、テナントプロパティウィンドウの統計タブ、およびレポートに移動します。この情報は、レガシーREST APIのステータスモニタリングを通じてもアクセス可能で、管理 > システム設定 > 詳細 > ステータスモニタリングAPIに移動して有効または無効にできます。

環境に応じて、表示するテナント情報の種類をカスタマイズするには、従来のREST APIのステータス監視を使用します。企業では、事業単位ごとの使用状況を確認する場合に便利です。また、この情報を使用してDeep Securityシステム全体の使用状況を監視し、異常の兆候を検出することができます。たとえば、1つのテナントでセキュリティイベントアクティビティが急増している場合は、攻撃を受けている可能性があります。

マルチテナントのダッシュボード

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

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

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

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

マルチテナントのレポート

必要な情報が含まれているレポートを生成するには、[イベントとレポート]→[レポートの生成] の順に移動して、ドロップダウンメニューから生成するレポートを選択します。マルチテナント環境のレポートと含まれる情報は次のとおりです。

セキュリティモジュールの累積使用状況レポート

  • テナント
  • ホスト名
  • ID
  • 不正プログラム対策
  • ネットワーク時間
  • システムセキュリティ
  • SAPシステム
  • 企業時間

セキュリティモジュールの使用状況レポート

  • テナント
  • ID
  • ホスト名
  • 表示名
  • コンピュータグループ
  • インスタンスの種類
  • 開始日
  • 開始時刻
  • 停止時刻
  • 期間 (秒)
  • 不正プログラム対策
  • Webレピュテーション
  • ファイアウォール
  • 侵入防御
  • 変更監視
  • セキュリティログ監視
  • アプリケーションコントロール
  • SAP

テナントレポート

  • テナント名
  • データベースサイズ
  • ピーク時のホスト数
  • 保護時間
  • 保護されている時間の割合

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

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

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

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

Microsoft SQL Server、Oracle、PostgreSQLはデータベースの概念に対して異なる用語を使用していることに注意してください。以下の表をご参照ください。

概念SQL Serverの用語Oracleの用語PostgreSQLの用語
複数のテナントが実行されるプロセスデータベースサーバデータベースデータベースサーバ
単一のテナントのデータデータベース表領域/ユーザデータベース

以下の説明では、SQL ServerとOracleの両方に対してMicrosoft SQL Serverの用語が使用されています。

SQL Server

マルチテナントでは、新しいテナントを作成する際にDeep Securityがデータベースを作成できる必要があるため、SQL Serverデータベースユーザにはdbcreatorロールが必要です。

メインデータベース名には短い名前を使用することをお勧めします。これにより、テナントのデータベース名が読みやすくなります。Deep Securityは、メイン (プライマリテナントの) SQLデータベース名からテナントのデータベース名を派生させます。例えば、メインデータベースがdsmと名付けられている場合、最初のテナントのデータベースはdsm_1、2番目のテナントのデータベース名はdsm_2となります。

dsmuser SQLアカウント

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

dbcreator SQLサーバロール

権限を制限して、スキーマの変更とデータのアクセスのみを許可することもできます。

db_ownerデータベースロールのメンバーシップ

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

Deep Securityのテナントデータベース

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

SQL Server Always On可用性における一般的な接続問題のトラブルシューティング方法については、SQL Server Always On可用性グループデータベースに接続した際のDSMの一般的な問題のトラブルシューティングを参照してください。

Oracle

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

Oracleではデータベースオブジェクト名に引用符で囲まれた特殊文字を許可していますが、Deep Securityではデータベースオブジェクト名に特殊文字をサポートしていません。詳細については、データベースオブジェクト名と修飾子を参照してください。

メインデータベース名には短い名前を使用することをお勧めします。これにより、テナントのデータベース名が読みやすくなります。Deep Securityは、メイン (プライマリテナント) のOracleデータベース名からテナントのデータベース名を派生させます。例えば、メインデータベースがMAINDBという名前の場合、最初のテナントのデータベースはMAINDB_1、2番目のテナントのデータベース名はMAINDB_2というようになります。

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

Oracleのマルチテナント権限

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

Oracleのテナントのユーザ権限

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

PostgreSQL

ユーザは、新しいデータベースとロールを作成する権限を持つ必要があります。

ALTER ROLE [username] CREATEDB CREATEROLE;

セカンダリデータベースサーバでは、ホスト名、ユーザ名、およびパスワードが必要です。ユーザ名には、追加のユーザ (役割) とデータベースを作成する権限が必要です。

メインデータベース名には短い名前を使用することをお勧めします。これにより、テナントのデータベース名が読みやすくなります。Deep Securityは、メイン (プライマリテナント) のPostgreSQLデータベース名からテナントのデータベース名を派生させます。例えば、メインデータベースがdsmと名付けられている場合、最初のテナントのデータベースはdsm_1、2番目のテナントのデータベース名はdsm_2となります。

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

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

さらにデータベースを設定するには、管理 > システム設定 > テナントに移動します。データベースサーバーセクションでデータベースサーバーを表示をクリックし、次に新規をクリックします。

Microsoft SQL Serverの場合、セカンダリデータベースサーバにはホスト名、ユーザ名、およびパスワードが必要です (名前付きインスタンスとドメイン)。Deep Security Managerのデータベースユーザは、以下の権限を持つ必要があります。

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

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

Oracleでは、マルチテナント展開は異なるモデルを使用します。新しいデータベース定義は、テーブルスペースにバインドされたユーザを定義し、それが追加のOracleユーザの作成をブートストラップします。

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

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

セカンダリサーバのホスト名、ユーザ名、パスワード、または詳細が変更された場合は、 Deep Security Managerコンソールでこれらの値を変更できます。プライマリ・データベースの値を変更するには、 Deep Security Managerのすべてのノードを停止し、dsm.propertiesファイルを新しい詳細で編集する必要があります。

API

Deep Security Managerには次のためのAPIが含まれています。

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

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

APIの詳細については、「Deep Security APIを使用したタスクの自動化」を参照してください。

マルチテナント環境のアップグレード

  1. すべてのデータベースをバックアップします。
    • Microsoft SQLおよびPostgreSQLでは、メインのデータベースが1つとテナントごとのデータベースがあります。
    • Oracleでは、すべてのテナント情報が1つのマネージャデータベースに含まれますが、テナントごとに追加のユーザが作成されます。各ユーザに専用のテーブルがあります。
  2. マネージャをアップグレードします。インストーラーは次のことを行います:
    • 他のマネージャノードが存在する場合、それらをシャットダウンしてからアップグレードを開始します
    • データベーススキーマを更新します。
    • データをプライマリテナント (t0) の新しい構造に移行します。
    • 他のテナントのデータを移行します (各バッチに5つ)。
  3. すべてのテナントを含めてマネージャが完全にアップグレードされた後、次のマネージャノードがあればアップグレードします。詳細については、 マルチテナント環境のアップグレード のマネージャのバージョンアップを参照してください。

次の点に注意してください:

  • t0の移行が失敗した場合、インストーラーは復旧できません。続行しません。データベースをバックアップから復元し、再試行してください。
  • プライマリ以外のテナントの移行に失敗した場合、インストーラは続行しますが、 の[管理]→[テナント ]の各テナントのステータスは、 [データベースのアップグレードが必要]（オフライン）に設定されます。バックアップから復元してインストーラを再度実行するか、該当するテナントの移行を再試行できます。
  • テナントの移行を再試行するには、テナントのインタフェースを使用します。再試行を強制できない場合は、サポート担当者にお問い合わせください。

テナントをサポートする

特に、テナントに対する最上位サポート担当者であるMSSPの場合、プライマリテナントは他のテナントのユーザインタフェースにログインする必要があるかもしれません。

これを行うには、管理 > テナントに移動します。テナント名を右クリックし、として認証を選択します (テナントがアクセスを無効にしている場合、このオプションは利用できない可能性があります)。これにより、そのテナント内でフルアクセス権を持つ一時的なユーザアカウントが作成され、すぐにそのアカウントにログインします。一時アカウント名は、プライマリテナント内のユーザ名に続くsupport_です。

たとえば、メインテナントのユーザー名がjdoeで、テナントT1内に一時的なアカウントを作成した場合、すぐにsupport_jdoeとしてT1にログインされます。

一時的なサポートアカウントは、ログアウトするかセッションがタイムアウトすると削除されます。テナントは、一時的なサポートアカウントの作成、ログイン、ログアウト、および削除に関するシステムイベントを確認できます。

プライマリテナントのユーザは、より多くの診断ツールや情報にアクセスできます。

  1. [管理]→[システム情報] には、テナントのメモリ使用量とスレッドの状態に関するより多くの情報が表示されます。
  2. 各Managerノードのディスク上のserver#.logログファイル (server0.logなど) には、各イベントに関連するテナントの名前と、該当する場合にはユーザの名前が表示されます。

場合によっては、UIで利用できないアクションを実行したり、テナントの設定を変更したりする必要があるかもしれません。これは通常、トレンドマイクロのサポートからの依頼によるものです。Command Lineで-tenantname<tenant-name>引数を追加して、そのテナントに設定変更やアクションを適用します。引数が省略された場合、コマンドはプライマリテナントに適用されます。

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

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

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

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