インストールスクリプトを使用したコンピュータの追加と保護

Workload Security で保護されたリソースのリストにコンピュータを追加し、保護を実装することは、複数のステップからなるプロセスです。ほとんどの手順は、コンピュータのコマンドラインから実行できるので、スクリプト化が可能です。 Workload Security コンソールには、配置スクリプト作成アシスタントが含まれており、[サポート] メニューからアクセスできます。

Workload Security を介して生成された配信スクリプトは、次の処理を行います。

• 選択したプラットフォームにエージェントをインストールする
• エージェントをアクティベートする
• エージェントにポリシーを割り当てる

インストールスクリプトを生成する

生成されるインストールスクリプトはリージョンによって異なるため、リージョン間で同じインストールスクリプトを使用することはできません。

1. 開始前の準備:
   a. エージェントのバージョン管理設定が必要に応じて設定されていることを確認してください。詳細については、 エージェントバージョン管理 の設定を参照してください。
   b. エージェント起動アクティベーション (AIA) が有効になっていることを確認してください。AIAは、インストールスクリプトをインストール後にエージェントを有効にする場合に必要です。[詳細については、エージェント起動アクティベーションおよび通信] (../agent-initiated-activation) を使用したエージェントのアクティベートおよび保護を参照してください。
2. Workload Security コンソールの右上隅にある[Support]→[Deployment Scripts]の順にクリックします。
3. ソフトウェアをインストールするプラットフォームを選択します。
4. [インストール後にAgentを自動的に有効化] を選択します。
   Agentはコンピュータを保護するポリシーの適用前に有効にする必要があります。有効化により、最初の通信時にManagerにAgentが登録されます。
5. 必要に応じて、 セキュリティポリシー, コンピュータグループ, Relay グループ, プロキシを選択して、 Workload Securityに連絡し、 プロキシから Relay（）に接続します。
6. 必要に応じて（ただし強く推奨）、 Workload SecurityTLS証明書の検証を選択します。
   このオプションを選択すると、エージェントソフトウェアのダウンロード時に Workload Security が信頼された認証機関（CA）からの有効なTLS証明書を使用していることが確認されます。これにより、「man in the middle」攻撃を防ぐことができます。有効なCA証明書を Workload Security が使用しているかどうかは、 Workload Security コンソールのブラウザバーで確認できます。
7. 必要に応じて（ただし強く推奨）、エージェントインストーラで署名を検証を選択して、インストールスクリプトでエージェントインストーラファイルのデジタル署名チェックを開始します。チェックに成功すると、エージェントのインストールが続行されます。チェックに失敗した場合、エージェントのインストールは中止されます。このオプションを有効にする前に、次の点を理解してください。
   • このオプションは、LinuxおよびWindowsのインストーラ（RPM、DEB、またはMSIファイル）、およびmacOS（PKGファイル）でのみサポートされます。
   • （Linuxのみ）このオプションは、配置スクリプトが実行する各エージェントに、公開署名鍵をインポートすることが必要です。詳細は、 を参照してください。RPMファイルの署名をチェックする および DEBBAファイルの署名を確認します。
8. インストールスクリプトジェネレータにスクリプトが表示されます。[クリップボードにコピー]をクリックし、展開スクリプトを目的の配置ツールに貼り付けるか、[ ファイルに保存]をクリックします。。

Workload Security for Windowsエージェントの配信で生成される配信スクリプトには、Windows PowerShell 4.0以上が必要です。PowerShellを管理者として実行する必要があります。スクリプトを実行するには、次のコマンドを実行する必要があります。 Set-ExecutionPolicy RemoteSigned

Amazon Web Servicesを使用していて、新しいAmazon EC2、Amazon WorkSpacesまたはVPCのインスタンスを作成する場合は、生成したスクリプトをコピーして [User Data] フィールドに貼り付けます。このスクリプトによって既存のAmazon Machine Image (AMI) が起動され、Agentが自動的にインストールされて有効化されます。新しいインスタンスは、生成したインストールスクリプトで指定されているURLにアクセスできる必要があります。

展開スクリプトを Linux 展開の User Data フィールドにコピーする場合、展開スクリプトをそのまま「ユーザデータ」フィールドにコピーすると、CloudInitはsudoを使用してスクリプトを実行します。（失敗がある場合、/var/log/cloud-init.logに記録されます。）

[User Data] フィールドは、CloudFormationなどの他のサービスでも使用します。詳細については次を参照してください。
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitcondition.html

トラブルシューティングおよびヒント

• 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形式。