Deep Security 11のサポートは終了しています。バージョンセレクタ（上記）を使用して、より新しいバージョンのヘルプセンターを表示します。
本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。
本ヘルプセンターの一部の記事には外部リンクが含まれています。リンク切れなどお気づきの点がございましたら、トレンドマイクロサポート窓口までご連絡ください。
マルチテナント環境の設定
Deep Securityのマルチテナント機能では、1つのDeep Security Manager内に複数の独立した管理環境を作成できます。各テナントでは、独自の設定とポリシーを適用でき、そのテナントのイベントを監視できます。この機能は、準備環境と実稼働環境を別々に作成する場合や、組織の事業単位ごとに環境を作成する必要がある場合に役立ちます。また、サービスモデルの顧客にDeep Securityをプロビジョニングする場合にも、マルチテナント機能を利用できます。
マルチテナントを有効にすると、「プライマリテナント」ではDeep Security Managerの通常のインストール環境の機能がすべて維持されます。ただし、プライマリテナントがその後作成するテナントについては、システムの構成に基づいて、利用できるDeep Securityの機能を制限できます。
このトピックの内容:
- マルチテナントの要件
- マルチテナントを有効にする
- テナントを作成する
- スケーラビリティのガイダンス
- マルチテナントに関するヒント
- テナントを管理する
- マルチテナント環境の設定
- 使用状況の監視
- データベースのユーザアカウントを設定する
- アップグレード
- テナントをサポートする
- ロードバランサ
- Deep Security Virtual Appliance環境のマルチテナント
マルチテナントの要件
次の製品ではマルチテナントを設定できません。
- Deep Security Manager VM for Azure Marketplace
- Deep Security as a Service
- Azure SQLデータベース
- Azure SQLまたはオンプレミス常時可用性グループ
マルチテナントにはアクティベーションコードが別途必要です。また、通常のDeep Security Managerの要件に加えてデータベース
要件がいくつか追加されます。詳細については、
スケーラビリティを最大化するために、複数ノードのDeep Security Managerを使用することをお勧めします (複数のノードでのDeep Security Managerの実行を参照)。すべてのManagerノードが、任意のテナントのGUI、ハートビート、またはジョブの要求を処理します。バックグラウンド処理については、各テナントに、 ジョブの処理待ち、メンテナンス、およびその他のバックグラウンドタスクを処理するManagerノードが割り当てられます。タスクは、Managerノードが追加またはオフラインにされたときに、残りのノードに再調整されます。
マルチテナントを有効にすると、Deep Security Managerの現在のインストール環境がプライマリテナント (t0) になり、 テナントの作成などの特別な権限を付与されます。テナントを作成すると、そのテナントは特定の機能の使用を制限され、該当する機能を操作するUIはDeep Security Managerに表示されません。 たとえば、テナントが他のテナントを作成することはできません。詳細については、マルチテナント環境の設定を参照してください。
マルチテナントを有効にする
- Deep Security Managerで、[管理]→[システム設定]→[詳細] の順に選択します。[マルチテナントのオプション] エリアで
[マルチテナントモードの有効化] をクリックします。
- マルチテナント設定ウィザードが表示されます。マルチテナントのアクティベーションコードを入力し、[次へ] をクリックします。
- 使用するライセンスモードを選択します。
- プライマリテナントからライセンスを継承: すべてのテナントにプライマリテナントと同じライセンスを使用します。準備環境でマルチテナントを使用する場合や、 同じ組織内の部門ごとにテナントを設定する場合は、このオプションが推奨されます。
- テナント単位の ライセンス:Deep Securityをサービスとして提供している場合は、このオプションが推奨されます。この設定では、テナント作成時にDeep Security APIを使用してライセンスを提供するか、 またはテナントがDeep Security Managerにはじめてログオンするときにライセンスを入力できます。
- [Next] をクリックします。ウィザードが終了したら、[管理]→[システム設定]→[テナント] の順に選択して新しい [テナント] 画面を表示し、そこで マルチテナントのオプションを設定できます。この画面のオプションについては、Deep Security Managerの右上にある [ヘルプ] をクリックしてください。
テナントを作成する
マルチテナントモードを有効にしたら、[管理] セクションの [テナント] 画面からテナント を管理できます。
テナントの追加に必要なデータベースのユーザアカウントの権限の詳細については、データベースのユーザアカウントを設定するを参照してください。
- Deep Security Managerで、[管理]→[テナント] の順に選択し、[新規] をクリックします。
- 新規テナントウィザードが表示されます。テナントのアカウント名を入力します。アカウント名には、プライマリテナント用に予約されている「Primary」以外の任意の名前 を使用できます。
- テナントの連絡先として使用するメールアドレスを入力します。
- ロケールを選択します。ロケールによって、テナントでのDeep Security Managerのユーザインタフェースの言語が決まります。
- タイムゾーンを選択します。テナント関連のイベントは、ここで指定するタイムゾーンでテナントのユーザに表示されます。
- 複数のデータベースを使用しているDeep Securityインストール環境では、
新しいテナントアカウントを格納するデータベースサーバをDeep Securityで自動的に選択するオプションを選択するか ([自動 - 設定なし])、または特定のサーバを指定できます。
データベースが1つしかない場合は、このオプションが表示されません。新しいテナントの受け入れを停止しているデータベースサーバは、 リストに表示されません。
- 新しいテナントアカウントの最初のユーザのユーザ名を入力します。
- 次の3つのパスワードオプションのうち1つを選択します。
- メールなし: テナントの最初のユーザのユーザ名とパスワードを設定します。メールは送信されません。
- 確認リンクをメール: テナントの最初のユーザのパスワードを設定します。ただし、ユーザが受信した確認メールのリンクをクリックするまでアカウントは有効になりません。
- メール 生成したパスワードをメール: パスワードを指定せずにテナントを生成できます。
3つのオプションはすべてREST APIを介して使用できます。確認オプションは、 一般ユーザが登録する場合に適した方法を提供します。テナントの作成者がプログラムではなく人であることを確認する方法として、CAPTCHAが推奨されて います。
メール確認によって、ユーザがアカウントにアクセスする前に、指定されたメールアドレスがユーザのものであることを確認できます。
- [次へ] をクリックしてウィザードを終了し、テナントを作成します。
テナントの作成には、スキーマの作成と、初期データの登録が必要なので、最大4分程度かかることがあります。この方法で、新しいテナントは最新の設定になり、 またデータベーステンプレートを管理する負担、特に複数のデータベースサーバを管理する負担が軽減されます。
各テナントデータベースには約100 MBのディスク容量のオーバーヘッドがあります (初期設定でシステムに入力されるルール、ポリシー、およびイベントに起因)。
テナントに送信されるメッセージの例
確認リンクをメール: アカウント確認要求
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
スケーラビリティのガイダンス
テナント数が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の [ダッシュボード]、[レポート]、および [イベント] の各画面にデータを入力するために新しいデータが継続的に生成されます。
機能
管理者は、特定のテナントに対して特定の機能のオン/オフを切り替えることができます。これらの使用可能な機能は、時間とともに変化する場合があります。現在、 イベント転送の詳細な説明 を有効にして、Amazon SNSまたはSIEMに転送されるイベントの完全な説明を含めることができます。そうでない場合、説明は省略する。SAMLアイデンティティプロバイダの統合, Amazon WorkSpacesの統合、および アプリケーション （アプリケーションコントロール ), は初期設定で有効になっています。
統計
[統計] タブには、データベースのサイズ、処理済みジョブ、ログオン、セキュリティイベント、システムイベントなど、現在のテナントに関する情報が表示されます。グラフは、 過去24時間のデータを示します。
Deep Security Agentの有効化
[Agentの有効化] タブには、このテナントのコンピュータでDeep Security Agentを有効にするためのコマンドが表示されます。このコマンドは、Deep Security Agentのインストールディレクトリから実行できます。 Deep Security Agentが有効になると、テナントはDeep Security Managerを使用して、ポリシーの割り当てやその他の設定を実行できます。
テナントに表示される内容
マルチテナントが有効になっている場合は、ログオンページに追加の [アカウント名] テキストフィールドが表示されます。
テナントは、ユーザ名とパスワードに加えてアカウント名を入力する必要があります。アカウント名があるので、ユーザ名が重複していてもかまいません。たとえば、 複数のテナントが同じActive Directoryサーバと同期する場合などです。
テナントユーザは、Deep Security Manager UIの一部の機能を使用できません。次の画面は、テナントには表示されません。
- Managerノードのウィジェット
- マルチテナントのウィジェット
- [管理]→[システム情報]
- [管理]→[ライセンス] (継承オプションが選択されている場合)
- [管理]→[Managerノード]
- [管理]→[テナント]
- [管理]→[システム設定]
- [テナント] タブ
- [セキュリティ] タブ→[ログオンページのメッセージ]
- [アップデート] タブ→ プライマリテナントのRelayの使用をテナントに許可する設定
- [詳細] タブ→[ロードバランサ]
- [詳細] タブ→[プラグイン] セクション
- テナントに関係がないヘルプの内容
- テナントに関係がない一部のレポート
- マルチテナントオプションに基づくその他の機能 (後述)
- 一部のアラートタイプも非表示:
- ハートビートサーバの失敗
- Managerのディスク容量不足
- Managerがオフライン
- Managerの時刻が非同期
- 新しいバージョンの Deep Security Managerが利用可能
- コンピュータ数がデータベースの上限を超過
- ライセンスの継承が有効になっている場合、ライセンス関連の アラート
テナントからは、プライマリテナントのマルチテナント機能や、他のテナントのデータは確認できません。また、 プライマリテナントの権限が必要な一部のAPIも制限されます (テナントの作成など)。
テナントユーザが使用できる機能と使用できない機能の詳細については、マルチテナント設定を参照してください。
テナントは、複数のユーザアカウントに役割に基づいたアクセス制御を使用して、アクセスをさらに分割することもできます。また、 ユーザのActive Directory統合を使用して、認証をドメインに委任することもできます。この場合も、テナントの認証にテナントのアカウント名が必要です。
Agentからのリモート有効化
Agentからのリモート有効化は、すべてのテナントで初期設定で有効になっています。
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]の順に選択して有効化/無効化できます。
ステータス監視REST APIを使用して、環境に応じて、確認するテナント情報の種類をカスタマイズします。企業では、事業単位ごとの使用状況を確認する場合に便利です。また、この情報を使用して Deep Securityシステム全体の使用状況を監視し、異常の兆候を検出することができます。たとえば、1つのテナントでセキュリティイベントアクティビティが急増している場合は、 攻撃を受けている可能性があります。
マルチテナントのダッシュボード
マルチテナントが有効になっているとき、プライマリテナントのユーザには、テナントの使用状況を監視できる次のダッシュボードウィジェットが追加されます。
- テナントのデータベース使用状況
- テナントのジョブアクティビティ
- テナントの保護アクティビティ
- テナントのセキュリティイベントアクティビティ
- テナントのログオンアクティビティ
- テナントのシステムイベントアクティビティ
- テナント
同じ情報を、[管理]→[テナント] 画面 (一部はオプションの列) と テナントの [プロパティ] 画面の [統計] タブで確認できます。
この情報によって、システム全体の使用状況を監視し、異常の兆候を検出することができます。たとえば、 1つのテナントでセキュリティイベントアクティビティが急増している場合、攻撃を受けている可能性があります。
マルチテナントのレポート
必要な情報が含まれているレポートを生成するには、[イベント]→[レポート]→[レポートの生成] の順に移動して、ドロップダウンメニューから生成するレポートを選択します。マルチテナント環境のレポートと含まれる情報は次のとおりです。
セキュリティモジュールの累積使用状況レポート
- テナント
- ホスト名
- ID
- 不正プログラム対策時間
- ネットワーク時間
- システム時間
- SAP時間
- 企業時間
セキュリティモジュールの使用状況レポート
- テナント
- ID
- ホスト名
- 表示名
- コンピュータグループ
- インスタンスの種類
- 開始日
- 開始時刻
- 停止時刻
- 期間 (秒)
- 不正プログラム対策
- Webレピュテーション
- ファイアウォール
- 侵入防御
- 変更監視
- セキュリティログ監視
- アプリケーションコントロール
- SAP
テナントレポート
- Tenant name
- データベースサイズ
- ピーク時のホスト数
- 保護時間
- 保護されている時間の割合
データベースのユーザアカウントを設定する
各テナントのデータの大部分は別個のデータベースに保存されます。このデータベースは、他のテナントと同じデータベースサーバに共存させることも、 専用のデータベースサーバに分離することもできます。いずれの場合も、一部のデータはプライマリデータベース (Deep Security Managerとともにインストールされたデータベース) だけに保存されます。複数の データベースサーバが利用可能な場合、テナントは、負荷が最も低いデータベースに作成されます。
データベースへの各テナントのデータの分割には、次のメリットがあります。
- データ削除: テナントを削除すると、製品でサポートされているテナントのデータがすべて削除されます。
- バックアップ: 各テナントのデータに、それぞれ異なるバックアップポリシーを適用できます。これは、 準備環境と実稼働環境でテナントを使用し、準備環境のバックアップ要件が厳しくない場合に便利です (バックアップは、Deep Security Managerを設定した管理者が実行します)。
- 調整: 将来、すべてのデータベースサーバで負荷を均等に分散するための再調整が可能です。
データベースのユーザアカウントを設定する
SQL Server、Oracle、およびPostgreSQLでは、データベースの概念を表す用語が、次のように異なります。
| 概念 | SQL Serverの用語 | Oracleの用語 | PostgreSQLの用語 |
|---|---|---|---|
| 複数のテナントが実行されるプロセス | データベースサーバ | データベース | データベースサーバ |
| 単一のテナントのデータ | データベース | テーブルスペース/ユーザ | データベース |
次のセクションでは、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の次の権限を割り当てる必要があります。
テナントは、長いランダムパスワードを持つユーザとして作成され、次の権限が付与されます。
Oracleのセカンダリサーバ用に、最初のユーザアカウント (ブートストラップユーザアカウント) を作成する必要があります。このユーザは、テーブルスペースが基本的に空になります。確認オプションは、 設定は、プライマリユーザアカウントと同じです。
PostgreSQL
ユーザには、新しいデータベースを作成する権限と 次の役割が必要です。
ALTER ROLE [username] CREATEDB CREATEROLE;
セカンダリデータベースサーバでは、ホスト名、ユーザ名、およびパスワードが必要です。ユーザ名には、追加のユーザ (役割) とデータベースを作成する権限が必要です。
複数のデータベースサーバを設定する
初期設定では、すべてのテナントが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が含まれています。
- マルチテナントの有効化
- テナントの管理
- 監視データのアクセス
- チャージバックデータ (保護の利用状況) のアクセス
- セカンダリデータベースサーバの管理
また、従来のSOAP APIに、3つ目のパラメータとしてテナントアカウント名を受け取る新しい認証メソッドがあります。
REST APIの詳細については、Deep Security REST APIの使用を参照してください。
アップグレード
アップグレードは、これまでのバージョンと変わりません。インストーラが実行され、既存のインストールが検出されます。次に、アップグレードオプションが表示されます。アップグレードが 選択された場合、他のノードにシャットダウンするように通知してから、アップグレードの処理が開始されます。
プライマリテナントが最初にアップグレードされ、その後、テナントが並行して処理されます (5テナントずつ)。インストーラが終了したら、 残りのManagerノードで同じインストーラパッケージを実行します。
テナントのアップグレード中に問題が発生した場合は、テナントの状態 ([管理]→[テナント] 画面) が 「データベースアップグレード失敗 (オフライン)」になります。テナントのインタフェースを使用して、強制的にアップグレードを実行できます。
テナントをサポートする
プライマリテナントがテナントのユーザインタフェースにアクセスする必要が生じる場合があります。テナントリストとテナントプロパティの画面に、 特定のテナントとして認証するオプションがあり、このオプションを使用すると、すぐに管理者アクセスが可能です。
ユーザは、接頭辞「support_」を使用する特殊なアカウントとしてログオンします。たとえば、プライマリテナントのユーザ「jdoe」がテナントとしてログオンした場合は、 「Full Access」役割を持つ「support_jdoe」というアカウントが作成されます。サポートユーザがタイムアウトになるか、アカウントからログアウトすると、ユーザは削除されます。
テナントは、このユーザアカウントの作成、ログオン、ログアウト、および削除と、その他の操作をシステムイベントで確認できます。
プライマリテナントのユーザは、他にも次の診断ツールを使用できます。
- [管理]→[システム情報] 画面には、テナントのメモリ使用量とスレッドの状態に関する追加情報が表示されます。この情報は、 直接使用する以外に、トレンドマイクロのサポートに提供することもできます。
- Managerノードのディスクにある
server*.logには、ログの原因となったテナント (該当する場合はユーザ) の名前に関する追加情報が 含まれます。この情報は、問題の原因特定に役立つ場合があります。
テナントが、GUIにないカスタム調整を行う必要がある場合があります。これは、通常、トレンドマイクロサポートからの要求に基づいています。このような 設定を変更するコマンドラインユーティリティは、次の引数を持ちます。
-Tenantname "account name"
この引数を使用して、設定の変更や、その他のコマンドライン処理の対象として特定のテナントを指定できます。引数を省略した場合は、プライマリテナントに対して処理が実行されます。
ロードバランサ
初期設定では、複数ノードのManagerから、すべてのManagerノードのアドレスが、すべてのAgentとVirtual Applianceに提供されます。Deep Security AgentとDeep Security Virtual Applianceは、このアドレスのリストを使用して、アクセスするノードをランダムに選択し、接続できるノードがなくなるまで (またはノードがすべてビジー状態になるまで) リスト内の残りのノードへのアクセスを続行します。接続できるノードがなかった場合は、次のハートビートまで待ってから再度実行します。
マルチテナント環境では、マネージャノードを頻繁に追加および削除することをお勧めします。この場合、マネージャを追加および削除すると、環境内のすべてのエージェントおよび仮想アプライアンスがアップデートされます。このアップデートを回避するため、ロードバランサの設定を使用できます。
ロードバランサは、トラフィックの種類ごとに異なるポートを使用するように設定できます。また、ロードバランサでポートのリダイレクトがサポートされている場合は、3つのロードバランサを使用して、 必要なすべてのプロトコルをポート443を経由して公開できます。
いずれの場合も、ロードバランサは、TCPのロードバランサとして設定します (SSL終端ではない)。この方法で、 AgentまたはVirtual ApplianceとManagerの間で通信が最初から最後まで直接実行されます。次の接続は、別のノードに分散される可能性があります。
詳細なDeep Security Managerの配信推奨事項については、 Deep Securityのベストプラクティスガイド（英語）を参照してください。
Deep Security Virtual Appliance環境のマルチテナント
VMware環境にDeep Securityを導入する場合、vCenterとそのコネクタをプライマリテナント内に設定し、vCloud Connectorをその他のテナント内に設定することが できます。この設定を正しく行えば、プライマリテナントにはESXiサーバ、Deep Security Virtual Appliance、およびその他のインフラストラクチャコンポーネントが表示され、 各テナントにはvCloud環境でテナントが所有する仮想マシンのみが表示されます。テナントでは、Agentを導入しなくてもこれらの仮想マシンを有効化できます。
このような環境を設定するには、[管理]→[システム設定]→[Agent] の順に選択し、 [ApplianceによるvCloud仮想マシンの保護を許可] チェックボックスをオンにします。
vCloudとの統合の詳細については、VMware vCloudへのAgentのインストールを参照してください。
