らら子です。
都内のスタートアップでWEBサービスの開発をやってます。
今回は、「Qiitaエンジニアフェスタ Trend Micro Cloud One を使ってAWS環境をよりセキュアにする方法について投稿しよう！」の企画に参加するために、CloudOneについて触ってみることにしました。
私の開発しているサービスは、AWSのEC2インスタンスにデプロイされていて、ALBとAutoScaringを使っています。
（ EC2インスタンスはAmazonLinuxで、現在のところトレンドマイクロのセキュリティソフトは入れてません(´;ω;｀) ）
サービスで採用しているわけではないのですが、セキュリティについて興味があるので実際にインストールしてみて使ってみた感想などを記事にしてみようと思います。
CloudOneのアカウントを登録する
さっそくCloudOneのアカウントを登録しようと思ったのですが、地味に難所でした。
「cloudone 登録」でGoogle検索をかけたところ、一番上にはなぜかソフトバンクのページが表示されたのでスキップしました。
次の「Trend Micro Cloud Oneへのお申し込み - Billing」というページも、どうやらMarketplaceから購入するちょっと特殊なタイプのサービスのページだったのでスキップしました。
最終的に3つ目のリンク先からこのページに行きつき、登録することができました。
ちょっとややこしかったので注意ですね。
登録時に、アカウントのデータをホストするリージョンを選べと言われたのですが、選択肢がUS-1しかなく、若干困惑しました。
現在は全部のデータがアメリカに保存されていて、変更ができないようです。
今後は選択肢が増えていくんでしょうか。
登録が完了したのでアカウントにログインしてみたところ、いろんなサービスがでてきました。
こんなにたくさんのセキュリティサービスを出してるんですね。
今回の目的はEC2にインストールするタイプのセキュリティサービスを使うことなので、「Workload Security」というサービスを選択します。
初回ログイン時に、細かい文字のポップアップがでてきました。
「Smart Feedback」という診断データがデフォルトで送信されるようになっているので確認してね、という内容みたいです。
よくあるプライバシーポリシーの同意みたいなポップアップのようです。
なんで全部英語なのかと思ったのですが、ログイン後のダッシュボードも全部英語でした。
トレンドマイクロってウイルスバスターのイメージがありましたが、日本語対応してないんでしょうか？
（あとで調べたらちゃんと日本語対応してました。私が登録したときに最初から英語だったのは、たぶん私のブラウザの言語設定が英語だったから…。）
ともかくこれで、CloudOneのアカウント登録に成功しました！
次はAWSのEC2インスタンスにセキュリティエージェントをインストールしていきます。
EC2にセキュリティエージェントをインストールする
Trend Micro Cloud One ドキュメントを読んでみると、今ログインしているWEBコンソールは管理のためのもので、各EC2にはそれぞれセキュリティエージェントをインストールする必要があるということがわかりました。
公式のドキュメントは、コンソールの右上のHelpボタンをクリックしたら開けました。
セキュリティエージェントをEC2にインストールする方法は、最初はよくわからなかったのですが、めちゃ簡単でした。
さっきのHelpボタンの隣にSupportタブがあり、この中のDeploymentScriptというボタンをクリックすると次のような画面が開き、インストール用のスクリプトが自動生成されます。
設定項目としては、
- インストール先のプラットフォーム（今回はLinuxを選択）
- セキュリティエージェントを自動的に有効化するか、有効化する場合は初期設定のポリシー
- CloudOne WorkloadSecurity のTLS証明書を検証するか
- セキュリティエージェントにインストーラの証明書を検証するか
といったものでした。
自動生成されたスクリプトをEC2インスタンスにコピペして実行することで、セキュリティエージェントがインストールされ、CloudOneのコンソールに登録されました。
インストール自体は10秒くらいで終わったので、あっという間に完了した感じでした。
$ chmod +x ./install.sh
$ sudo ./install.sh
Downloading agent package...
Installing agent package...
warning: /tmp/agent.rpm: Header V4 RSA/SHA256 Signature, key ID e1051cbd: NOKEY
Preparing... ################################# [100%]
Host platform - NAME="Amazon Linux"
Updating / installing...
1:ds_agent-20.0.0-2740.amzn2 ################################# [100%]
add ds_agent service with chkconfig
Starting ds_agent (via systemctl): [ OK ]
Install the agent package successfully
HTTP Status: 200 - OK
Activation will be re-attempted 30 time(s) in case of failure
dsa_control
HTTP Status: 200 - OK
Response:
Attempting to connect to https://agents.deepsecurity.trendmicro.com:443/
SSL handshake completed successfully - initiating command session.
Connected with (NONE) to peer at agents.deepsecurity.trendmicro.com
Received a 'GetHostInfo' command from the manager.
Received a 'SetDSMCert' command from the manager.
Received a 'SetAgentCredentials' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'SetAgentStatus' command from the manager.
Received a 'GetInterfaces' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'GetHostMetaData' command from the manager.
Received a 'GetHostMetaData' command from the manager.
Received a 'GetAgentStatus' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'GetDockerVersion' command from the manager.
Received a 'SetXDRInformation' command from the manager.
Received a 'SetSecurityConfiguration' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'GetAgentStatus' command from the manager.
Received a 'GetIoT' command from the manager.
Received a 'SetDSMCACert' command from the manager.
Received a 'Metrics' command from the manager.
Command session completed.
スクリプトで自動的にインストールできるので、EC2の起動時スクリプトに登録しておけば、わざわざSSHログインして手動でインストールしなくてもセキュリティエージェントの追加ができそうです。
各種イベントのログは、WEBコンソールのEvents&Reportsタブから確認できるようです。
セキュリティエージェント登録後、しばらく「Check Status Failed」という不穏なエラーが表示され、セキュリティエージェントがオフラインステータスになっていましたが、数分後にはいつの間にか解消され、オンラインステータスに戻っていました。
これで、EC2インスタンスへのセキュリティエージェントのインストールが完了しました！
せっかくなのでEC2インスタンスがちゃんとウイルスから守られていることを確認したかったのですが、実際のウイルスはダウンロードして保持するだけでも犯罪になるとのことだったので断念しました。
セキュリティソフトの動作確認って難しいですよね。
導入されている会社の方はどうやって確認しているんでしょうか？
EICARという疑似ウイルスでテストを行うのが一般的なようですが、あくまで検出用のダミーなので、セキュリティソフトの動作確認ができるのみで、セキュリティ性能の検証とは言えなさそうです。
セキュリティ性能については色々調べてみたところ、MITRE Engenuity ATT&CK Evaluationsという資料を見つけました。
一応性能的にはトップクラスだよ、といった内容のアピールがされてますね。
AWS連携をする
先ほど登録したセキュリティエージェントを眺めていたところ、「AWSアカウントとの連携」という項目を見つけました。
連携用のクロスアカウントロールを作成して、AWSのアカウントとCloudOneのアカウントを連携させることができるようです。
上記の作成画面に進むと、CloudFormationのテンプレートリンクが表示されました。
このテンプレートの設定は変えずに、クロスアカウントロールを作成していきます。
作成が完了すると、自動的にCloudOneのコンソールに登録されていたセキュリティエージェントが、どのリージョンのどのVPCに所属しているかが表示されるようになりました！
すごいすごい！
とはいえ、先ほどまでのようにAWSアカウントを連携しなくてもセキュリティエージェントは正常に使えるようですが、AWSアカウントを連携する利点は何なのでしょうか。
公式ドキュメントを読んでみると、次のメリットが挙げられていました。（日本語が機械翻訳っぽい感じで読みづらいので、英語で読んだ方がいいかもしれません。）
- EC2などの変更が、Workload Securityに自動的に反映されます。
AWSでいくつかのEC2インスタンスまたはWorkSpaceインスタンスを削除すると、これらのインスタンスはコンソールから自動的に表示されなくなります。 - EC2インスタンスとWorkSpaceインスタンスは、 Workload Security コンソールの[AWS region]→[VPC]サブネットに編成されており、どのインスタンスが保護されているか、どのインスタンスが保護されていないかを簡単に確認できます。
- イベントベースタスク（EBT） でAWSメタデータを使用してポリシーの割り当てを簡素化できます。
- スマートフォルダ でメタデータを使用して、AWSインスタンスを整理することもできます。
主に、管理運用の面でのメリットが大きいようですね。
まとめ
とりあえずEC2インスタンスにCloudOne Workload Securityのセキュリティエージェントをインストールして、AWSアカウントを連携するところまでやってみました。
今回は自動化のところまでは試せなかったのですが、APIを使った自動化などができるようなので、次回はそちらについても試してみたいと考えています。