ビュー:
注意
注意
マルチテナントは、 AWS MarketplaceのDeep Securityでのみ使用できます。ライセンス持ち込み (BYOL)支払いオプション。
Deep Securityのマルチテナント機能では、1つのDeep Security Manager内に複数の独立した管理環境を作成できます。各テナントでは、独自の設定とポリシーを適用でき、そのテナントのイベントを監視できます。この機能は、準備環境と実稼働環境を別々に作成する場合や、組織の事業単位ごとに環境を作成する必要がある場合に役立ちます。また、サービスモデルの顧客にDeep Securityをプロビジョニングする場合にも、マルチテナント機能を利用できます。
マルチテナントを有効にすると、「プライマリテナント」ではDeep Security Managerの通常のインストール環境の機能がすべて維持されます。ただし、プライマリテナントがその後作成するテナントについては、システムの構成に基づいて、利用できるDeep Securityの機能を制限できます。
注意
注意
マルチテナント環境では、FIPSモードはサポートされていません。FIPS 140のサポートを参照してください。
このトピックの内容:

マルチテナントの要件

次の製品ではマルチテナントを設定できません。
  • '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で、Create and Manage Tenantsを参照してください。
マルチテナントモードが有効になったら、[管理]→[テナント] からテナントを管理できます。
テナントの追加に必要なデータベースのユーザアカウントの権限の詳細については、データベースのユーザアカウントを設定するを参照してください。
  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からのリモート有効化とは異なり、他のテナントユーザが有効化を実行するには、パスワードとテナントIDが 必要です。
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つのテナントでセキュリティイベントアクティビティが急増している場合は、攻撃を受けている可能性があります。

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

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

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

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

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

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

テナントレポート

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

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

各テナントのデータの大部分は別個のデータベースに保存されます。このデータベースは、他のテナントと同じデータベースサーバに共存させることも、専用のデータベースサーバに分離することもできます。いずれの場合も、一部のデータはプライマリデータベース (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データベース名からテナントのデータベース名を導き出します。例えば、メインデータベースが「dsm」と名付けられている場合、最初のテナントのデータベースは「dsm_1」、2番目のテナントのデータベース名は「dsm_2」となります。
マルチテナントでは、新しいテナントを作成するときにDeep Securityがデータベースを作成できることが必要であるため、そのSQL Serverデータベースユーザには「dbcreator」ロールが必要です。
dsmuser SQLアカウント
プライマリテナントのユーザのロールについては、メインデータベースのDB所有者を割り当てます。
dbcreator SQLサーバーロール
権限を制限して、スキーマの変更とデータのアクセスのみを許可することもできます。
db_ownerデータベースロールメンバーシップ
「dbcreator」ロールを持つアカウントが作成したデータベースは、自動的にそのユーザの所有になります。たとえば、最初のテナント作成後のユーザプロパティは次のとおりです。
Deep Security テナントデータベース
セカンダリデータベースサーバの最初のアカウントを作成するには、「dbcreator」サーバロールのみが必要です。ユーザマッピングは必要ありません。

Oracle

Oracleにおけるマルチテナントは、Microsoft SQL Serverの場合と似ていますが、重要な違いがいくつかあります。SQL Serverでは、データベースサーバごとにユーザアカウントが1つですが、Oracleではテナントごとにユーザアカウントが1つです。Deep Securityをインストールしたユーザがプライマリテナントに対応付けられます。このユーザには、追加のユーザやテーブルスペースを割り当てる権限を付与できます。
注意
注意
Oracleでは、引用符で囲めば特殊文字をデータベースオブジェクト名に使用できますが、Deep Securityでは、データベースオブジェクト名内の特殊文字がサポートされていません。引用符を使わずに名前で使用できる文字については、次のOracleのサイトを参照してください。https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/Database-Object-Names-and-Qualifiers.html
ヒント
ヒント
テナントのデータベース名を読みやすくするために、メインデータベース名には短い名前を使用してください。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の詳細については、Use the Deep Security API to automate tasksを参照してください。

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

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