Elastic SecurityのCloud Workload Protectionによるクラウド保護
![blog-security-lock-720x420.png](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blte21ddedce08464b6/61e1de94c5ff2e754efb027e/blog-security-lock-720x420.png)
Elastic SecurityでCloud Workload Protectionを使い始める
このたび新たにリリースするElastic 8.2では、Cloud Workload Protectionのユースケースで、Elastic Securityに新たにクラウドセキュリティ機能を導入します。ElasticがElastic Serucityのいっそうの強化を目指してCmdを買収したのは、昨年8月のことです。Elasticはそれ以来、お客様がワークロードをクラウドとデータセンターのどちらで運用しているかに関係なく、ワークロードに対する攻撃を予防、検知し、対応できる「クラウドワークロードのランタイムセキュリティ機能」の開発に取り組んできました。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt9a13f0306d471a99/6271a9e2deee7329767e6386/diagram-cloud-workload-protection-in-elastic-security.png)
Elastic 8.2では、ワークロード保護に関する以下の新機能をすぐにご利用いただけます。
- eBPFを使ったクラウドワークロードのデータ収集:高い可用性と信頼性を求めるワークロードでは、Linuxがデファクトスタンダードになっています。そして、そのようなワークロードを保護するためには、ワークロードからランタイムデータを効率的にキャプチャできなければなりません。そこでこのたび、Endpoint Securityのデータ収集メカニズムにeBPFを追加しました。eBPFはカーネルテクノロジーの一種で、カーネルのソースコードを変更したり、モジュールを追加したりすることなくプログラムを実行できるようにするものです。このため、Linuxカーネルでプログラムを実行する際のパフォーマンスと安全性が高まります。もちろん、あらゆるユーザーを確実に保護できるよう、現状の幅広いサポート対象OSもそのまま維持しているので、既存のデータ収集メカニズムを使用している場合でも問題ありません。
- スキーマを拡張し、Linuxの論理イベントモデルを追加:Linuxの論理イベントモデルは、fork、exec、プロセスのexit、setsidなどのイベントに関して、Session View向けのデータを生成するために使用する基本的なフレームワークです。Elasticではこれまで、Elasticsearchでの検索とインデックスがしやすくなるよう、このデータモデルを定義し、Elastic Common Schema(ECS)に変換するべく、さまざまな取り組みを実施してきました(詳細はこちらのブログ記事参照してください)。その結果、セキュリティ担当の皆様が自社のワークロードに何が起こっているかについてコンテクスト情報が得られるようになりました。たとえば、ワークロードでセキュリティに関するアラートが発生した場合には、特定の時点のセッションでユーザーやサービスが何をしていたかを正確に把握できます。
- Session Viewによりワークロードを詳しく調査:最後が、このたびベータ版で提供を開始したSession View機能です(Session Viewは、Cmdの商標です)。Session Viewは、Linuxワークロードのプロセスの実行状況をターミナルシェルのような見た目で時系列表示する機能であり、ワークロードでのユーザーやサービスの挙動を調査する際に便利です。
アラート、調査、ホスト調査など、Elastic Securityの重要なワークフローには、Session Viewが統合されています。そのため、セキュリティアナリストが環境についての豊富なコンテクスト情報を見ながら、ホストで発生したアラートのトリアージを進めていくことができます。また、実行されたコマンドのそれぞれについて、入力されたユーザー名、引数などの情報や、親プロセス、エントリーリーダー、グループリーダーに関する情報を確認できます。さらに、生成されたアラートの確認からケースの開始、Osqueryの実行などの対応に至るまでを、Session Viewから直接行うことができます。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltb0197dc886ea2fef/6271a7d35f7b601eaaebbc1c/screenshot-session-view-elastic-security.gif)
Cloud Workload Protectionを使い始める
ここまで、さまざまな新機能をご紹介してきました。そろそろ、自社のクラウドワークロードを保護するうえで具体的にまず何をすれば良いかが気になってきたのではないでしょうか。ここからは、その手順を順番にご説明します。今回の説明では、監視と保護の対象とするワークロードとしてAWS EC2インスタンスを使用しています。
- Cloudトライアルを開始するか、インストール済みのElastic Securityを8.2にアップグレードします。
- Elastic Security 8.2へのアップグレードが終わったら、[Integrations](統合機能)、[Endpoint Security]の順に移動します。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blta58aae3718636cfb/6271cf460cffdf1eb1368d4f/cloud-workload-protection-integrations.png)
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltda978bfcfe6299c1/6271cf07a1a1dd2aa9f6b920/cloud-workload-protection-browse-integrations.png)
- [Add Endpoint Security](Endpoint Securityの追加)ボタンをクリックします。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt2d72c8d2cb2cf369/6271cf2e4886af2aa2be01e3/cloud-workload-protection-elastic-security.png)
- 次のページに表示される手順に従って操作を進めます。必要であれば、エージェントポリシーを作成します。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt941fb49d89a0ca88/6271a9d74d9f89297128f097/cloud-workload-protection-agent-policy.png)
- ポリシーに統合機能を追加したら、[Integration policies](統合ポリシー)に移動して[new policy](新しいポリシー)をクリックします。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltafdfe9cc236032a7/6271cf38deee7329767e63e5/cloud-workload-protection-integration-policies.png)
- [Integration Policy](統合ポリシー)ページで、Linuxシステムの[Event Collection](イベント収集)のセクションに移動します。移動したら、[Include Session Data](セッションデータを含める)を有効にして[Save](保存)をクリックします。なお、新しいホストや既存のホストでセッションデータを有効にするこの手順は、サーバーやVMにエージェントをインストールする前に完了しておく必要があります。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt7ac824f9287ba496/6271cf720cffdf1eb1368d51/cloud-workload-protection-event-collection.png)
- AWSターミナルのシェルにログインまたはSSH接続し、エージェントとエンドポイントをインストールします。[Add agent](エージェントの追加)に表示されている手順に従って操作を進め、EC2インスタンスにElastic Agentをインストールします。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt80f961baaeb9e291/6271cf7e4d9f89297128f272/cloud-workload-protection-add-agent.png)
ps -aux | grep elastic
を実行し、Elastic Agentのプロセスが実行中であることを確認します。- [Elastic Security]→[Hosts](ホスト)→[Sessions](セッション)タブの順に移動します。セッションテーブルに、さまざまなホストのセッションリーダーすべての監査証跡が表示されます。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt7925865b3616e5e3/6271cf507198441d81b3972f/cloud-workload-protection-sessions-tab.png)
- 各ユーザーの各セッションで何が起こっているかを確認する場合には、Session Viewでアイコン[>_]をクリックします。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltc5e828ff86983e82/6271cf664886af2aa2be01e5/cloud-workload-protection-session-tab-user.png)
- ワークロード保護のルールについて:[Elastic Security]→[Detect](検出)→[Rules](ルール)の順に移動します。[Linux]タグを有効にし、ワークロードに適したルールが見つかったら、そのルールを有効にします。Linux向けにあらかじめ用意されているルールは68種類、機械学習関連のルールは18種類あります。いずれもMITREフレームワークをベースに作られているので、お好きなものを有効にしてください。なお、インデックス「logs-endpoint-events*」が設定されているルールでは、Session Viewerが有効になります。
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltb2b2a3ba122e6dbc/6271cf5c8e09542a15b7d087/cloud-workload-protection-tags.png)
![](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltfccaff1013acb904/6271cf1b5f7b601eaaebbe68/cloud-workload-protection-definition.png)