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

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

Deep Security Managerで使用するデータベースの準備

YouTubeの Deep Security 12 - データベースに関する考慮事項を参照して、データベースの要件、設定、および認証のセットアップを確認できます。

Deep Security Managerをインストールする前に、Deep Security Managerで使用するデータベースを準備する必要があります。データベースのインストールおよび使用手順については、データベースプロバイダのドキュメントを参照してください。ただし、Deep Securityとの統合に関して、次の点にも注意してください。

ハードウェア要件を確認します。
データベースの種類を選択します。サポートされるデータベースのリストについては、「データベース」を参照してください。

選択したデータベースに応じて、Microsoft SQL Server、Oracle Database、またはPostgreSQLの推奨設定を参照してください。

Microsoft SQL Server Expressは、限られた構成でのみサポートされます。詳細については、Microsoft SQL Server Expressに関する注意事項を参照してください。
時刻とタイムゾーンの両方を同期させます。データベースとDeep Security Managerサーバの両方で、同じタイムソースを使用します。
Deep Security Managerとデータベース間のネットワーク接続を許可します。ポート番号、URL、およびIPアドレスを参照してください。

インストール中に、準備したデータベースのデータベース接続と認証資格情報を入力します。

インストール後に、データベースメンテナンスを参照してください。

ハードウェア要件

専用のサーバ

データベースは、Managerノードから独立した専用のサーバにインストールします。また、データベースとDeep Security Managerを1GbpsのLAN接続を使用する同じネットワーク上に配置して、両者間の通信が妨げられずに確実に行われるようにすることも重要です。(WAN接続は推奨されません)。これは、Deep Security Managerノードを追加する場合にも該当します。Deep Security Managerからデータベースへの接続の待ち時間は、2ミリ秒以内が推奨されます。

そのためには、Managerとデータベースを仮想マシンにインストールする場合に、それらが必ず同じESXiホストで実行されるようにしてください。

vCenter Web Clientで、[Host and Clusters] に移動してクラスタを選択します。
[Manage] タブに移動して、[VM/Host Rules]→[Add] をクリックします。
ルールの名前を入力します。
[Enable rule] を選択します。
[Type] で [Keep Virtual Machines Together] を選択します。
[Add] をクリックし、Managerとデータベースの仮想マシンを選択します。

スケーラビリティとサービスの稼働時間のために、データベースロードバランシング、ミラーリング、および高可用性 (HA) が推奨されています。Amazon Aurora、PostgreSQL、Microsoft SQL Serverなどのベンダのドキュメントを参照してください。

データベース複製ではなく、データベースミラーとHAを使用してください。フェイルオーバでは、データベーススキーマを変更しないでください。一部の種類の複製では、複製中にデータベーステーブルに列が追加されるため、スキーマが変更され、重大なデータベース障害が発生します。

クラウドでホストされているデータベースの場合、複数の可用性ゾーン (「multi-AZ」) はネットワーク待ち時間を増加させることがあるため、推奨しません。

ハードウェアに関する推奨事項

アップデートや推奨設定の検索など、Deep Security Managerの処理の多くは、多くのCPUリソースとメモリリソースを必要とします。大規模な環境の場合、トレンドマイクロでは、各Managerノードに4コアおよび十分なメモリを持たせることを推奨します。

データベースは、最適なDeep Security Managerノードの仕様と同等か、それ以上のハードウェアにインストールしてください。十分なパフォーマンスのためには、データベースに8～16GBのメモリと、ローカルまたはネットワーク接続されたストレージへの高速アクセスが必要です。可能であれば、最適なデータベースサーバの設定と実施されるメンテナンス計画について、データベース管理者に確認してください。

Microsoft SQL Server

一般的な要件

Deep Securityで使用される空のデータベースを作成する必要があります。
リモートTCP接続を有効にする"( https://docs.microsoft.com/en-us/previous-versions/bb909712(v=vs.120)?redirectedfrom=MSDN ).を参照してください。
Deep Security Managerのデータベースユーザにdb_owner権限を付与します。

Microsoft SQL Serverを使用する場合は、Deep Security ManagerがMicrosoft Active DirectoryドメインまたはSQLユーザとして接続する必要があります。Windowsのワークグループ認証はサポート対象外になりました。

トランスポートプロトコル

サポートされているトランスポートプロトコルは、新しくインストールされたDeep Security 10.2以降のバージョンの場合はTCPです。
Deep Security 10.1以前のバージョンからアップグレードし、トランスポートプロトコルとして名前付きパイプを使用する場合、DSMはアップグレード時に引き続き名前付きパイプを使用します。トレンドマイクロでは、TCPを使用して通信を暗号化することをお勧めします(Deep Security Managerとデータベース間の通信の暗号化を参照してください)。

マルチテナントを使用する場合

メインデータベース名を短くします。これにより、テナントのデータベース名が読み取りやすくなります(たとえば、メインデータベースが「MAINDB」の場合、最初のテナントのデータベース名は「MAINDB_1」、2番目のテナントのデータベース名は「MAINDB_2」になります (以下同様))。
Deep Security Managerのデータベースユーザアカウントにdbcreator権限を付与します。マルチテナントについては、マルチテナント環境の設定を参照してください。

Oracle Database

「Oracle Listener」サービスを開始します。TCP接続が許可されていることを確認します。
Deep Security Managerのデータベースユーザ名に特殊文字は使用しないでください。Oracleでは、引用符で囲めばデータベースユーザオブジェクトの設定時に特殊文字を使用できますが、Deep Securityでは、データベースユーザの特殊文字がサポートされていません。
Deep Security ManagerのデータベースユーザにCONNECTロールとRESOURCEロール、およびUNLIMITED TABLESPACE、CREATE SEQUENCE、CREATE TABLE、CREATE TRIGGERの各権限を付与します。
マルチテナントを使用する場合は、Deep Security ManagerのデータベースユーザにCREATE USER、DROP USER、ALTER USER、GRANT ANY PRIVILEGE、GRANT ANY ROLEの権限も付与します。
Oracleコンテナデータベース (CDB) の設定は、Deep SecurityManagerのマルチテナントではサポートされません。

Oracle RAC (Real Application Clusters) のサポート

Deep Securityでは次の構成がサポートされます。

SUSE Linux Enterprise Server 11 SP3とOracle RAC 12c Release 1 (v12.1.0.2.0)
Red Hat Linux Enterprise Server 6.6とOracle RAC 12c Release 1 (v12.1.0.2.0)

初期設定のLinux Server Deep SecurityポリシーはOracle RAC環境に対応していますが、ファイアウォールの設定だけは例外です。ファイアウォール自体を無効にするか、Oracle RACでのファイアウォール設定の手順に従ってファイアウォールの設定をカスタマイズしてください。

データベースメンテナンス

Deep Security環境の状態を正常に維持するには、データベースメンテナンスが不可欠です。

インデックスのメンテナンス

Deep Security Managerのパフォーマンスを向上させるには、Deep Securityデータベースでインデックスのメンテナンスを定期的に実行して、過度のフラグメント化を防止することをお勧めします。組織のベストプラクティスに従ってデータベースのインデックスを再作成するか、データベースベンダが提供する以下のドキュメントを参照してください。

PostgreSQL:PostgreSQLのインデックス再作成コマンドの詳細については、https://www.postgresql.org/docs/10/sql-reindex.htmlを参照してください。このコマンドを実行すると一部の処理がブロックされるため、アップグレード時にオフラインで実行することをお勧めします。このコマンドを既存のスナップショットに対してオフラインで実行する場合、完了までに約45分かかります。
Microsoft SQL： インデックス管理のベストプラクティスについては、Microsoftのドキュメントを参照してください： https://docs.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver15。
Oracle Database: インデックスの管理に関するOracleのベストプラクティスに従ってください。たとえば、https://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes002.htm#ADMIN11713を参照してください。

このタスクに役立つスクリプトは、オープンソースのWebサイトでも提供されています。

バックアップと障害復旧

高可用性やロードバランシングとは別に、ベストプラクティスとして、定期的なデータベースのバックアップや障害復旧プランがあります。バックアップは、重大な障害が発生した場合にデータベースを復元するために使用できます。ベンダのドキュメントのほか、データベースのバックアップと復元を参照してください。

PostgreSQLデータベースの場合、pg_dumpやpg_basebackupのような基本的なツールは、エンタープライズ環境でのバックアップと復元には適していません。Barmanなど、別のツールの使用を検討してください。