このページのトピック
インストールスクリプトを使用したコンピュータの追加と保護
Workload Security で保護リソースのリストにコンピュータを追加し、保護を実装するには、複数のステップが必要です。これらのステップのほとんどはコマンドラインから実行できるため、スクリプトを使用できます。Workload Security コンソールには、サポート メニューからアクセスできるデプロイメントスクリプト作成アシスタントが含まれています。
Workload Security を介して生成された配信スクリプトは、次の処理を行います。
-
選択したプラットフォームにエージェントをインストールする
-
Agentの有効化
- エージェントへのポリシーの割り当て
インストールスクリプトを生成する
生成されるインストールスクリプトはリージョンによって異なるため、リージョン間で同じインストールスクリプトを使用することはできません。
- 開始前に、次の点を確認してください
a. エージェントのバージョン管理設定を構成しました。詳細については、エージェントのバージョン管理を構成するを参照してください。
b. エージェント開始のアクティベーション (AIA) を有効にしました。インストール後にデプロイスクリプトでエージェントをアクティベートする場合に必要です。詳細については、エージェント開始のアクティベーションと通信を使用してエージェントをアクティベートおよび保護する を参照してください。 - Workload Security コンソールの右上隅にある[Support]→[Deployment Scripts]の順にクリックします。
- ソフトウェアをインストールするプラットフォームを選択します。
- [インストール後にAgentを自動的に有効化] を選択します。
Agentはコンピュータを保護するポリシーの適用前に有効にする必要があります。有効化により、最初の通信時にManagerにAgentが登録されます。 - 必要に応じて、 セキュリティポリシー, コンピュータグループ, Relay グループ, プロキシを選択して、 Workload Securityに連絡し、 プロキシから Relay()に接続します。
- 必要に応じて (ただし推奨)、[ Validate Workload Security TLS certificate] を選択します。
このオプションを選択すると、Workload Security がエージェントソフトウェアをダウンロードする際に、信頼できる認証局 (CA) からの有効なトランスポート層セキュリティ (TLS) 証明書を使用することが保証されます。これにより、中間者攻撃を防ぐことができます。Workload Security が有効な CA 証明書を使用しているかどうかは、Workload Security コンソールのブラウザバーで確認できます。 - 任意ですが(推奨)、エージェントインストーラーの署名を検証を選択して、デプロイスクリプトがエージェントインストーラーファイルのデジタル署名チェックを開始するようにします。チェックが成功すると、エージェントのインストールが続行されます。チェックが失敗すると、エージェントのインストールは中止されます。このオプションを有効にする前に、次の点を考慮してください:
- このオプションは、LinuxおよびWindowsのインストーラ(RPM、DEB、またはMSIファイル)、およびmacOS(PKGファイル)でのみサポートされます。
- Linux では、このオプションを使用するには、デプロイスクリプトが実行される各エージェントコンピュータに公開署名キーをインポートする必要があります。詳細については、RPM ファイルの署名を確認する および DEB ファイルの署名を確認する を参照してください。
- デプロイメントスクリプトジェネレーターはスクリプトを表示します。クリップボードにコピーをクリックして、デプロイメントスクリプトをお好みのデプロイメントツールに貼り付けるか、ファイルに保存をクリックします。
Workload Security for Windowsエージェントの配信で生成される配信スクリプトには、Windows PowerShell 4.0以上が必要です。PowerShellを管理者として実行する必要があります。スクリプトを実行するには、次のコマンドを実行する必要があります。 Set-ExecutionPolicy RemoteSigned
- Linux: --tls1.2 タグを削除します。
- Windows: #requires -version 4.0 行を削除します。また、 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; Managerとの通信に初期のTLS(バージョン1.0)が使用されるように、行を追加します。
Amazon Web Servicesを使用していて、新しいAmazon EC2、Amazon WorkSpace、またはVPCインスタンスをデプロイしている場合は、生成されたスクリプトをコピーして、[ User Data ] フィールドに貼り付けます。これにより、既存のAmazon Machine Image (AMI) を起動し、起動時にエージェントを自動的にインストールしてアクティベートできます。新しいインスタンスは、生成された配置スクリプトで指定されたURLにアクセスできる必要があります。
Linux 配置の User Data フィールドに配置スクリプトをコピーする場合、配置スクリプトをそのまま User Data フィールドにコピーすると、CloudInitはsudoを使用してスクリプトを実行します。失敗した場合は、/var/log/cloud-init.log
に記録されます。
ユーザデータフィールドは、CloudFormationなどの他のサービスでも使用されます。詳細については、AWS CloudFormation: WaitConditionを参照してください。
トラブルシューティングおよびヒント
- PowerShell (x86) からエージェントを配信しようとすると、次のエラーが表示されることがあります:
C:\Program Files (x86)\Trend Micro\Deep Security Agent\dsa_control' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
PowerShellスクリプトでは、ProgramFiles
の環境変数がProgram Files (x86)
ではなくProgram Files
フォルダに設定されていることを想定しています。この問題を解決するには、PowerShell (x86) を終了し、管理者としてPowerShellでスクリプトを実行します。 - 展開スクリプトは
rpm -U
にrpm -ihv
を変更することで、エージェントの更新の代わりに、新規インストールを実行するように変更することができます。 - 配信スクリプトで使用される特定のバージョンのエージェントを制御する必要がある場合は、次の2つの方法があります。
- エージェントバージョン管理を使用します。詳細については、 エージェントバージョン管理 の設定を参照してください。このアプローチには、各スクリプトにエージェントのバージョン自体をハードコードする必要がないという利点があります。これは、一部の展開ではより柔軟なアプローチになる可能性があります。
- 展開スクリプトを変更するか、独自のスクリプトを作成して、展開に固有の要件を満たしてください。エージェントをダウンロードするためのURL形式の詳細は、こちらを参照してください。 エージェントのダウンロードURL形式。
- 代わりに、管理者によって生成されたデプロイメントスクリプトを使用して、あなたは、エージェントのダウンロードとインストールを自動化するために、エージェントのダウンロードURLと相まって、独自の自動化方法を使用することができます。詳細については、を参照してください。エージェントのダウンロードURL形式。