本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。

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

マルチテナントは、Bring Your Own License (BYOL) 支払オプションを使用するDeep Security from AWS Marketplaceでのみ使用できます。

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

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

このトピックの内容:

• マルチテナントの要件
• マルチテナントを有効にする
• テナントを作成する
• スケーラビリティのガイドライン
• マルチテナントに関するヒント
• テナントを管理する
• マルチテナント環境の設定
• 使用状況の監視
• データベースのユーザアカウントを設定する
• API
• マルチテナント環境のアップグレード
• テナントをサポートする

マルチテナントの要件

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

• 'Protected Instance Hour'課金オプション を使用したAWS MarketplaceからのDeep Security（BYOLオプションのみがサポートされます）
• Deep Security Manager VM for Azure Marketplace
• Azure SQLデータベース
• 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. [次へ] をクリックします。

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

テナントを作成する

Deep Security APIを使用してテナントの作成と設定を自動化できます。例については、Deep Security Automation Centerで、Configure database user accountsを参照してください。

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

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

1. Deep Security Managerで、[管理]→[テナント] の順に選択し、[新規] をクリックします。
2. 新規テナントウィザードが表示されます。テナントのアカウント名を入力します。アカウント名には、プライマリテナント用に予約されている「プライマリ」以外の任意の名前を使用できます。
3. テナントへの連絡に使用されるメールアドレスを入力してください。
4. ロケールを選択します。ロケールによって、テナントでのDeep Security Managerのユーザインタフェースの言語が決まります。
5. タイムゾーンを選択します。イベントの時間は、イベントが発生したシステムのタイムゾーンではなく、このタイムゾーンを基準にして表示されます。

6. 複数のデータベースを使用するDeep Securityインストール環境では、新しいテナントアカウントを格納するデータベースサーバを Deep Securityで自動的に選択するオプションを選択するか ([自動 - 設定なし])、または特定のサーバを指定できます。

   新しいテナントを受け入れていないデータベースサーバは、リストに表示されません。

7. 新しいテナントアカウントの最初のユーザのユーザ名を入力します。

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

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

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

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

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

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

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

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

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

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

テナント数が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日間、「削除の保留中」状態のままになる可能性があります。

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

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

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

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

テナントを管理する

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

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

テナントのプロパティ

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

一般

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

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

モジュール

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

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

[プライマリテナントからライセンスを継承] を選択すると、すべてのテナントに、自分 (プライマリテナント) がライセンスを許可されているすべての機能が表示されます。

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

機能

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

[イベント転送の詳細な説明] を有効にした場合、Deep Securityによって、Amazon SNSまたはSIEMに転送されるイベントの完全な説明が含められます。そうしなかった場合、説明は省略されます。SAMLアイデンティティプロバイダの統合, Amazon WorkSpacesの統合, アプリケーション （アプリケーションコントロール ), および APIレート制限 （自動化センター内）は、初期設定で有効になっています。

統計

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

Deep Security Agentの有効化

[Agentの有効化] タブには、コンピュータ上のAgentを有効にするために実行できるコマンドが表示されます。コマンドは、このテナントのコンピュータのAgentインストールディレクトリを基準にしています。Deep Security Managerが安全に接続できるようにし、テナントがDeep Security Managerからポリシーを割り当てたり、他の設定手順を実行したりできるようにするには、有効化が必要です。

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

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

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

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

• Managerノードのウィジェット
• マルチテナントのウィジェット
• [管理]→[システム情報]
• [管理]→[ライセンス] (継承オプションが選択されている場合)
• [管理]→[Managerノード]
• [管理]→[テナント]

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

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

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

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

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

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

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

Agentからのリモート有効化

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

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

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は、[管理]→[システム設定]→[詳細]→[ステータス監視API] の順に移動して、有効または無効にすることができます。

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

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

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

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

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

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

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

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

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

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

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

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

テナントレポート

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

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

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

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

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

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

SQL Server

テナントのデータベース名を読みやすくするために、メインデータベース名には短い名前を使用してください。Deep Securityは、テナントのデータベース名をメインデータベース（プライマリテナント)'のSQLデータベース名）から取得します。たとえば、メインデータベースの名前が「dsm", 」の場合、最初のテナントのデータベースは「dsm_1", 」、2番目のテナントのデータベース名は「dsm_2", 」などとなります。

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

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

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

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

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

Oracle

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

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

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

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

PostgreSQL

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

ALTER ROLE [username] CREATEDB CREATEROLE;

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

テナントのデータベース名を読みやすくするために、メインデータベース名には短い名前を使用してください。テナントのデータベース名がメインデータベース（プライマリテナント)'の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. マネージャーをアップグレードします。
3. インストーラによって次の処理が実行されます。
   • 他の マネージャノードが存在する場合はシャットダウンしてからバージョンアップを開始します。
   • データベーススキーマを更新します。
   • プライマリテナント（t0）の新しい構造にデータを移行します。
   • 他のテナントのデータを移行します（各バッチで5つ）。
4. すべてのテナントを含めてマネージャが完全にアップグレードされた後、次のマネージャノードがあればアップグレードします。詳細については、 マルチテナント環境のアップグレード のマネージャのバージョンアップを参照してください。

注意:

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

テナントをサポートする

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

そうするには、[管理]→[テナント] に移動します。テナントの名前を右クリックし、[テナントとしてログオン] を選択します。テナントのアクセスが無効になっている場合、このオプションを使用できないことがあります。この機能により、そのテナント内に「フルアクセス」ロールを持つ一時的なユーザアカウントが作成され、すぐにそのアカウントへのログインが行われます。一時的なアカウント名は、「support_」で始まり、その後にプライマリテナント内のユーザ名が続きます。

たとえば、プライマリテナントのユーザ名が「user」で、一時アカウントをテナント「T1」の内部に作成した場合、すぐに「support_user」として「T1」へのログインが行われます。

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

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

1. [管理]→[システム情報] には、テナントのメモリ使用量とスレッドの状態に関するより多くの情報が表示されます。

2. 各Managerノードのディスク上のserver#.logログファイル (server0.logなど) には、各イベントに関連するテナントの名前と、該当する場合にはユーザの名前が表示されます。

場合によっては、処理を行ったり、GUIで使用できないテナントの設定を変更したりする必要があります。これは通常、トレンドマイクロのサポートからの要望に応じて行います。コマンドラインで、次の引数を追加します。

-tenantname <tenant-name>

このようにして、設定の変更や処理をそのテナントに適用します。引数を省略すると、コマンドはプライマリテナントに適用されます。