Shield on @johtaniの日記 3rd

Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）

Fri, 30 Oct 2015 16:21:31 +0900

※この記事は次のブログを翻訳したものになります。

原文：Shield, Watcher, and Marvel 2.0.0 GA Released

本日（10/28）Shield、WatcherおよびMarvel 2.0をリリースしました。これが、Elasticsearch 2.0に対応したこれらのプラグインの最初のリリースです。

Elasticsearch 2.0対応のほかに、ShieldとWatcher 2.0は、セキュリティとアラートを拡張するいくつかの新しい素敵な機能も備えています。

Shield

拡張可能なレルム - Sheild 1.xはユーザ認証のコア的なものを定義するのにフォーカスし 3つの認証メカニズム（esusers、LDAP/AD、PKI）を提供しました。これらを提供することで、多くのユーザおよびユースケースをカバー出来ましたが、追加の認証メカニズムを統合する必要があることもわかっていました。ということで、Shieldのレルムベースの認証システムをユーザが利用、拡張できるようにオープンにし、ユーザ認証を扱うためのレルム実装をプラグインとして拡張できるようにしました。特定もしくはプロプライエタリな認証メカニズムが必要なユーザもShieldの強力なセキュリティ機能（ロールベースの認証、セキュアな通信など）をフルに活用できるようになりました。カスタムレルムの詳細については、こちらをご覧ください。
フィールドとドキュメントのACL - Shield 2.0はフィールドとドキュメントレベルのアクセス制御機能を提供します。これは、ロールごとにアクセス可能なフィールドやドキュメントを定義できます。この新しい機能は、設定の変更するよりも便利です。このアクセス制御はElasticsearchのLuceneインデックスという最も低レベルで実装されています。その結果として、このメンテナンスがより簡単であるだけでなく、より良くなっています。詳細についてはこちらをご覧ください。
ユーザなりすまし - Shield 2.0で、ユーザなりすましの機能が実装されました。これは、ユーザ（適切なパーミッションを持った）が、他のユーザになることができ、それらのユーザのためにリクエストを実行できます。これは、Elasticsearch上に構築されたアプリケーションがすでにユーザ認証を行いますが、認可はElasticsearchサイドで行う必要があるような場合に有用です。このシナリオで、アプリケーションの"main"ユーザを設定でき、正しくなりすましを割り当て、 ElasticsearchにアプリケーションユーザとしてリクエストをElasticsearchに実行させることができます。詳細については、こちらをご覧ください。

Watcher

SlackとHipChatインテグレーション - SlackとHipChatはチーム/グループコラボレーションツールです。これらは、急速に主流になり、組織の主な内部コミュニケーションハブとなっています。 Watcher 2.0はチャンネル/ルームやユーザにこれらのコミュニケーションチャネル経由で、Watchの通知を行うことができるアクションを実装しました。 slackやhipchatアクションについてはドキュメントをご覧ください。
Array Compare Condition - 新しいconditionはタイムシリーズのデータのスパイクを検知するのを簡単にします。 compare conditionは1.xで導入されましたが、このコンディションはElasticsearchのダイナミックスクリプト機能を有効にする必要がアンク使えます。詳細についてはarray_compare conditionをご覧ください。
Watchの有効・無効化 - ユーザからの多かったリクエストとして、Watchの無効化がありました。 1.xには、登録済みのWatchを無効にする機能がありませんでした。これは、Watchを消すか、Watchのトリガーを変更することで回避していました。これは、全体としてはWatchを管理するのを難しくする回避方法でしかありません。 2.0では、APIを呼び出すだけで、Watchの変更をすることなく、簡単にWatchの有効化・無効化が可能になりました。これは1.0からあるべき基本的な機能でしたが、ついにこの問題を解決しました。詳細はこちらをご覧ください。

Marvel

Marvel 2.0を紹介するのに興奮しています。 Kibana 4をベースとした、再設計されたUIを持っています。 Marvel 1.xで学んだ多くのことを導入し、より使いやすく監視しやすいUIになっています。 ShieldとWatcherと同様に、最初のMarvelのリリースは将来的な成長の基盤となり Elasticsearch2.0を効率的に管理するための主要なメトリックにフォーカスしています。

画像あり。 ※画像に関しては原文をご覧ください。

再設計により、インタフェースを6ページに減らしています。

Cluster list

画像あり。 ※画像に関しては原文をご覧ください。

ユーザやカスタマーの多くは複数のクラスタを利用しています。新しいMarvelはそれらを集中的にモニタリングする一つのクラスタからそれらを簡単に監視できます。各クラスタのデータ送信先をこのモニタリングクラスタにするだけです。

Cluster Overview

画像あり。 ※画像に関しては原文をご覧ください。

クラスタオーバービューはある一つのクラスタの主要な性能メトリックを見ることができ、素早くスパイクを発見できます。このページはまた、アクティブなシャードのリカバリやリロケーションも見ることができます。

Indices List

画像あり。 ※画像に関しては原文をご覧ください。

インデックスのリストにはクラスタにあるすべてのインデックスとその属性が表示されます。テーブルはライブでアップデートされ、フィルタリングやソートも可能です。一番大きなインデックスは？といったことも調べられます。

Index Detail

画像あり。 ※画像に関しては原文をご覧ください。

インデックス詳細ページはインデックスの主な性能メトリックを見ることができ、シャードの配置についても表示します。

Nodes List

画像あり。 ※画像に関しては原文をご覧ください。

ノードリストはクラスタにあるノードとその主な性能メトリックを見ることができます。テーブルはライブでアップデートされ、フィルタリングも可能です。高いCPU利用率やディスクの残り容量なども簡単にわかるようになっています。

Node Detail

画像あり。 ※画像に関しては原文をご覧ください。

ノード詳細ページは個別のノードに関する主な性能メトリックを見ることができ、ノードにあるシャードのリストも見ることができます。

新しいMarvelはKibana 4の上に構築されたので、管理方法が変わっています。 Marvelのインストールは2つのステップがあります。 marvel-agentとmarvel user interfaceです。

Marvel Agent

marvel-agentはElasticsearchクラスタにプラグインとしてインストールします。主なパフォーマンス情報を取得し、ローカルもしくは分離されたモニタリングクラスタにデータを保存・送信します。

Marvel User Interface

Marvel UIはKibanaのプラグインとしてインストールします。これは、Kibana 4.2の新しいプラグインインフラを利用し、 Marvel Appとして、Kibanaのインタフェースとは個別に提供されます。 Kibanaのアプリの切り替えは次の画像の通りです。

画像あり。 ※画像に関しては原文をご覧ください。

2.0リリースは私たちのプロダクトの大きな一歩です。またユーザの意見を常にお待ちしています。ぜひ、Webフォーラム（https://discuss.elastic.co）やメール（info@elastic.co）でご意見を。

Shield および Watcher 2.0.0-beta2リリース（日本語訳）

Fri, 18 Sep 2015 17:32:10 +0900

※この記事は次のブログを翻訳したものになります。

原文：Elasticsearch 2.0.0-beta1 released

セキュリティ向けプラグインShieldのリリース（日本語訳）

Fri, 27 Feb 2015 18:49:56 +0900

※この記事は次のブログを翻訳したものになります。

原文：you know, for security: shield goes ga

1/27にShield 1.0 をリリースしました。 Elasticsearch向けの私たちのセキュリティプラグインの最初のリリースです。 11月にShieldについてアナウンスしてから、Elsaticsearchのためのセキュリティの機能は、一般的に望まれているものから始まり、具体的な考えと実行できる計画へと変遷し、それが、いま現実となりました。

十分にセキュアな環境に、Elasticsearchクラスタをセキュアな状態でデプロイできるようにするため、私たちは継続的にカスタマーやユーザーからのリクエストを受け取り、統合されたソリューションになるようにしてきました。

私たちは、そのようなプロダクトがどうあるべきか調査することから始め、カスタマーとユーザが必要とするセキュリティとはどんなものかを理解するために多くの時間を費やしました。その結果がShieldです。 Shieldは、ElasticsearchクラスタをセキュアにするElasticsearchの有償プラグインです。私たちは、ShieldをDev、Gold、Platinumサブスクリプションの一部として、追加料金なしで提供します。

最初のリリースでは、基本的な機能と基盤にフォーカスしています。 Elasticsearch自身に対しても、セキュリティに対して準備してきました。拡張性の側面だけでなく、Elasticsearchにあるデータフローについても再考してきました。 Elasticsearchクラスタをセキュアにする場合に、具体的な価値を即座に届けるだけでなく、素早く拡張できるようにも開発しました。

機能

Shield 1.0は次の5つにフォーカスしています。

認証(Authentication)
認可(Authorization)
暗号化通信とノードの認可(Encrypted Communication & Node Authentication)
IPフィルタリング
監査証跡(Audit Trail)

認証(Authentication)

セキュリティの大部分はアイデンティティについてです（例えば、だれがこのAPIを呼び出したのか？システムに何のサービスが接続するか？など）サービスのライフタイムのある時点で、サブジェクト（例えばユーザー）を現在実行中のサブプロセスなどに結びつけることです。この関係性を持つためには、サブプロセスを実行する前にユーザの身元を確認するように命じます。ユーザの身元の確認のプロセスをAuthenticationと呼び、ElasticsearchのすべてのAPIコールでそれが実行されます。

認証の手法は多くの異なるものがあります。それぞれの手法は、ユーザが認証されたという資格（Authentication Token）を、それぞれのタイプで提供するようにユーザに要求します。 Shield 1.0ではシンプルに、必要なauthentication tokenをユーザ/パスワードペアとしています。（これは、Shieldの認証基盤が簡単に拡張でき、将来は異なるauthentication tokenもサポートできることを意味します。）

ユーザの資格を受け取ることだけでは不十分で、次に、それらをチェックする必要があります。 Shieldでは、これはレルムの責務です。レルムは認証プロバイダ/サービスとしてみることができます。妥当なユーザであると判断/解決されたか、 authentication tokenが適切な資格を持っていない/単に知らないユーザであるということで、拒否されたかです。 Shieldの認証メカニズムでは、複数のレルムを設定でき、さらに、あるレルムの戻り値を扱う他のレルム、というようなchainとすることもできます。 Shield 1.0は3つのレルムをサポートします。

esusers - Elasticsearchによって管理されるファイルベースのレルムです。これは、ファイルにユーザを定義することができます。（Apacheサーバのhtpasswdファイルのようなもの）このレルムは外部への依存はなく、Shieldをインストールすれば、デフォルトで使用できます。このレルムは配置が簡単で、マルチテナントなElasticsearchクラスタに対して使用できます。マルチテナントなElasticsearchクラスタとは、クラスタを複数のアプリでシェアすることをテナントと言います。また、すべてのユーザがパスワードを忘れてしまうような"emergency"な代替レルムも対応可能です。 (誰もシステムに入れないような状況のことです)
LDAP - 外部のLDAPサーバでユーザを認証するレルムです。このレルムは組織のLDAPサーバで管理/保存されているユーザをすでに持っている組織を対象としています。
Active Directory - LDAPのタイプの1つで、Active Directoryに対する設定になります。

レルムはelasticsearch.yml設定ファイルで、次のように設定可能です。

shield.authc realms:

    esuser:
        type: esusers
        order: 0

    ldap:
        type: ldap
        order: 1
        url: ldaps://url/to/ldap1/server

    ldap_fallback:
        type: ldap
        order: 2
        url: ldaps://url/to/ldap2/server

上記のようにrealmsが一つのチェインとして参照されます。レルムごとに、設定された順序で、それらは参照されます。

NOTE : Shieldには、esusersファイルに保存されたユーザを管理するためのコマンドラインツールもあります。

認可(authorization)

認可(Authorization)は保護されたリソースにアクセスするユーザを許可するか拒否するかということです。モダンなシステムは、ユーザのパーミッションのために、ロールベースのアクセスコントロール（RBAC）モデルを利用します。このモデルでは、各ユーザはロールの集合に関連していて、それぞれのロールには、パーミッションの集合が定義されています。これは、洗練された設定で、パーミッションを機能的なグループで共有させることができます。例えば、次のようなロールを定義したとします。

employee - すべての従業員は部門をまたいだ会社のデータへアクセスできます（例えば、コンタクトやディレクトリ情報など）
sales - すべての営業職は営業データにアクセスできる（例えば、流通ルート、ルート、顧客）
finace - すべての財務の従業員は財務データにアクセスできる（例えば、予算、経費、伝票）

財務部門のAnnは従業員と財務のロールを持っており、会社のディレクトリと財務データにアクセスでできます。

認可プロセスはユーザがリクエストに関連したユーザが必要で、このプロセスのために、認証フェーズの後に直接実行されます。

Shieldは2つのタイプのリソースを定義します。クラスタとインデックスです。これらは、すべてのAPIコールで保護されます。さらに、それらに関連したパーミッションとロールも定義できます。一度定義をすると、ロールはユーザもしくはLDAP/ADのグループに関係します。ロールはroles.yml設定ファイルで定義されます。設定のサンプルは次のようになります。

admin:
    cluster: all
    indices:
        '*' : all

monitor:
    cluster: monitor
    indices:
        '*': monitor

employee:
    indices:
        'company_directory' : read

sales:
    indices:
        'opportunities' : read, write
        'accounts' : read, write

finance:
    indices:
        'expenses' : read, write
        'purchases' : read, write

上記のサンプルで、次の5つのロールを定義しています。

admin - 管理者のロールで、すべてのクラスターレベルの操作とすべてのインデックスに対してすべてのインデックスレベルの操作を実行可能です。 (¥*インデックスはすべてのインデックスにマッチするワイルドカード)
monitor - システム/クラスタのモニタリングのためのロール。このロールのユーザはすべてのクラスタとインデックスレベルの情報の読み取りの APIにアクセス可能だが、インデックスのデータへの読み書きや設定の更新は不能
employee - compnay_directoryにあるすべてのデータへの読み取りアクセスを与えられたロール。このロールはクラスタレベルへのアクセスやデータの書き込みアクセスは持っていない (特にcompany。洗濯されたグループの人々はcompanyディレクトリの更新は可能だが、employeeは読み取りのみが可能)
sales - opportunitiesとaccountsインデックスの読み書きができるロール
finance - expensesとpurchasesの両方に読み書きができるロール

上記のサンプルで定義されているallとreadとwriteとして名前がつけられた権限です。これらは、予約語で、Elasticsearchのローレベルのアクションを複数含んだ権限です。（writeはindex, delete, delete_by_query, bulk, updateの操作を含んでいます。）多くのケースで、これらのハイレベルの名前が付けられた権限で十分ですが、特定のロールに特定のアクションを明示的に指定することもできます。次のようになります。

hr:
    indices:
        'company_directory' : indices:data/write/index, indices:data/write/update

ここまで説明した認可のレルムは、各ユーザに関連するロールを識別するためのものです。内部のesuserレルムでは、提供されるesuserコマンドラインツールを使ってロールはユーザに割り当てたり変更したりもできます。 LDAPやActive Directoryでは、LDAP/ADグループにShieldのロールを割り当てることができます。

認証と認可の両方を用いることで、ユーザリクエストに対して、ユーザごとに許可/不許可をすることができます。

暗号化通信

認可はElasticsearchのデータを機能的な観点（許可されたユーザだけが操作を可能にする）で保護しますが、クライアントからElasticsearchクラスタへ、もしくはクラスタのノード間では暗号化されていないデータを送るためまだ危険があります。第三者が登頂したり、オンザフライでデータを書き換えたりといった可能性やクラスタを壊すことができます。

Shield 1.0はElasticsearchのすべての通信チャネルをセキュアにすることができます。クラスタ内のノード間のチャネルやクライアントに公開されているチャネルです。これは、SSL/TLS通信を導入して実現します。

Shieldで使えるSSLはElasticsearchのtransportサービスをSSL/TLSで通信できるものに置き換えます。これは、ノード間通信チャネルと、HTTP transport（REST APIを提供するもの）のそれぞれに設定可能です。

ShieldのSSL/TLSは、スタンダードなJavaのものとkeystoreとtruststoreを基本にしたものが利用可能です。 SSL/TLSを設定すると、各ノードのキーストアに証明書をインポートする必要があります。 CAがサインした証明書を使うことも、CAが信頼したものとして許可許諾されたものを使うことが可能です。これは、信頼されたすべてのCAとして知られているtrust storeが必要です。新しいノードをクラスタに追加するときに、すべての必要な少なくとも一つの信頼されたCAから発行されてサインされたものが必要になります。クラスタで個別のノードがすべてのkeystore/truststoreを更新する必要性なしに。？？

通信チャネルを安全にする方法やSSL/TLS設定をどのように行うかはShieldのドキュメントをご覧ください。

ノード間認証

強く推奨しますが、許可されたノードだけがクラスタに接続できるようにするために、ノードの認証をSSL transportに設定することができます。これは、shield.transport.client.authにtrueを設定することで可能です。設定した場合、ノード間でSSLハンドシェイクが行われ、接続されたノードが接続に来たノードのクライアント認証を要求しチェックします。もし、チェックに失敗した場合は、SSLシェイクハンドが失敗し接続が拒否されます。

SSLクライアント認証

transportレベルでノード認証が必要なようなら、次のような疑問がわくでしょう。 Elasticsearchはクラスタに接続するTransportクライアントを使うときはどのように振る舞うのか？ Transportクライアントはクラスタの他のノードと同じチャネルを使うため、コネクションを確立するときに、ノードが他のノードと異なるかどうかを見極めることはできません。

この時、もっとも単純な解決は、Transportクライアントも同様に許可を与えることです。それは、認証を解決するときに、他の問題（潜在的な悪意）を引き起こします。 Transportクライアントが他のクラスタのノードを偽装しようとすることです。これは望んでいません。

幸いなことに、良い解決方法があります。トランスポートプロファイルです。 Elasticsearch 1.4で導入されたトランスポートプロファイルは、トランスポートレイヤー（異なるホスト/ポートにバインドされる）のために複数のネットワークチャネルを設定することができます。 Shieldはこのサポートを、プロファイルごとに異なるSSL設定をできるように拡張します。また、ノードのタイプとクライアントプロファイルタイプの間に明確な違いを設定することも可能です。これを用いると、2つのプロファイルを設定できるようになります。ひとつは、クライアントのためのもので、もうひとつはクラスタのノードのためのものです。これにより、クライアントのための認証の問題が必要なくなり、Shieldはクライアントプロファイルをもった限定されたクライアントからのリクエストを保証します。

IPフィルタリング

これは、厳密には、認証カテゴリではありませんが関係しています。 Shieldはそれ自身がIPフィルタリングのメカニズムを持っています。これは、許可/不許可のIPのリストを設定することができます。これらのフィルタリングのルールは複数のレベルで設定可能です。 transportチャネル、transportプロファイルレベル、そして、HTTPチャネルです。次の設定は、それらの設定のサンプルです。（設定ファイルはelasticsearch.ymlになります）

shield:

    transport.filter:
        allow:
            - '127.0.0.1'
            - '2001:0db8:1234:0000:0000:8a2e:0370:73
        deny:
            - '10.0.0.0/8'
            - '2001:0db8:1234::/48'
            - '*.google.com'

    http.filter:
        allow: [ '10.0.0.0/8' ]
        deny: [ '127.0.0.1' ]

transport.profiles:
    client:
        shield.filter.deny: [ '_all' ]

このように、IPv4とIPv6、CIDR、ホスト名、ワイルドカードが利用できます。また、この機能はホストOSのIPテーブルに設定することで追加できるが、Shieldにそれを保持し、それらの設定を単純化し、デプロイの全体から除去できることにも注意してください（詳細はドキュメントのIPフィルタリングをご覧ください）。

監査証跡（Audit Trail）

セキュアなシステムの必須機能の一つで、監査硝石により、Elasticsearchに発生した重要なイベントをトラッキングすることが可能です。これらのイベントを保存することは、Elasticsearchクラスタの重要なアクティビティの証拠を提供でき、不審な/悪意のある可能性のあるイベントを追跡するときの診断ツールにもなります。

Shield 1.0.0で、監査証跡は監査/アクセスlogを一般的なElasticsearchのログとは個別に保存します。それらは、構造化されているため、読んだりパースするのが容易で、イベントのタイプも分類されています。また、情報のレベルを設定することができ、各イベントをlogレベルの設定で書き出すことができます。以下が、イベントのリストです。

anonymous_access_denied - 認証トークンがないユーザからのリクエストがあった時のログ
authentication_failed - リクエストされたユーザの認証に失敗した時のログ
access_denied - 認証されたユーザが許可されていない操作を実行した時のログ
access_granted - 認証されたユーザが許可された操作を実行した時のログ
tampered_request - 不正に書き換えられたリクエストが到着したのを検知した時のログ
connection_granted - ノードもしくはtransportクライアントがIPフィルタのルールにパスした時のログ
connection_denied - ノードもしくはtransportクライアントがIPフィルタリングルールの制限により却下された時のログ

Shieldの監査証跡についてより詳しく知りたい方は、ドキュメントをごらんください。

次のバージョンでは？

ここまで紹介したように、これはまだ始まりにすぎません。 Shieldに追加される多くの機能があり、しっかりとした基盤を構築したところです。 Shieldの次のバージョンでは、以下の機能の追加にフォーカスするでしょう。（これらだけに限ったわけではありません。）

APIによる設定、管理
より拡張され、柔軟なLDAP/Active Directoryサポート
レルムタイプの追加（kerberos、anonymous、certificatesなどなど）
セッションベースの認証

ShieldはElasticsearch社の2番目の（Marvelに続く）商用プロダクトです。ダウンロードして開発環境で評価してください。インストールは他のプラグインと同様の方法です（インストール方法についての詳細はこちら）。一度インストールすると、30日の試用ライセンスが始まります。もし、さらに時間が必要な場合は、sales@elasticsearch.comまで連絡してください。

私たちのすべてのプロダクトについてフィードバックをお待ちしています。 Shieldの商用利用、機能、ロードマップ、その他のセキュリティに関するトピックなど、質問がありましたら、サイトからご連絡ください。

Shield: ご存知の通り、セキュリティのためのもの(coming soon)、日本語訳

Wed, 05 Nov 2014 12:30:06 +0900

※この記事は次のブログを翻訳したものになります。

原文：Shield: You Know, For Security (Coming Soon)

Elasticsearchの初期のころから、外部システムとして使うElasticsearchをセキュアにすることが望まれていました。例えば、Elasticsearch APIはREST over HTTPとして危険にさらされており、ユーザはプロキシやファイアウォールでそれをセキュアにします。

ElasticsearchとELKスタックの爆発的な選択で、私たちのカスタマーやユーザは外部システムを使って実現することなく、先進的な機能でセキュリティ・ソリューションをより統合できるものを求めました。

カスタマー（彼らの非常に大切なセキュリティ要件を持つ一部の）と多くの時を過ごした後、私たちはElasticsearchでセキュリティプロダクト（Shieldと命名）に取り組み始めました。（Marvelファンなら、とあるテーマを感じると思います。:)）

ここ数ヶ月、ミートアップでカスタマーやユーザと話をするために世界中を旅して周り、Shieldについて説明し、人々はそれを聞いて興奮しました。この理由のために、私たちはセキュリティプロダクトに取り組んでいることを公開することが意味があると思いましした。それが何であるか説明し、年末までにリリースしようと思っています。

Shieldは、Marvelと同じ精神のもと、Elasticsearchの公開されている拡張ポイントの上に作られており、プラグインとして既存のElasticsearchに簡単にインストールできます。 Elasticsearchの異なるディストリビューションは必要ありませんし、Elasticsearchがすでに公開しているオープンなAPIに依存しています。

Shield自体は次の主な４つの機能を提供します。

Role-Based Access Control

Elasticsearchクラスタの各ユーザのためのクラスタ、インデックス、エイリアスレベルのパーミッションをセットできます。例えば、マーケティング部門には、センシティブな財務データへのアクセスを防ぎつつ、read-onlyパーミッションでソーシャルメディアを自由に検索、解析することができるようにします。

Authentication System Support

LDAPベースの認証システムならびにActive DirectoryとShieldは統合できるので、あなたのユーザがさらに別のパスワードを覚える必要がありません。また、Elasticsearchですべてのアクセスを管理したいユーザのために、ネイティブな認証システムも提供します。

Encrypted Communications

Node間の暗号化でデータを侵入者から守ります。証明書ベースのSSL/TLS暗号化とHTTPSを用いたセキュアクライアント通信で、Shieldは保護されたデータ通信を保持します。

Shield keeps data traveling over the wire protected.

Audit Logging

コンプライアンスを確実にし、Elasticsearchの配置で起きるセキュリティに関するアクティビティの動きを監視します。ログイン失敗や未認可の情報へのアクセスを記録します。

最近では、テストであることを説明した一部のカスタマーに対して、ベータ版の提供を開始しました。利用するユーザのために最終的なプロダクトへの価値あるフィードバックを学んでおり、興奮しております。

最後に、Shieldが既存と将来のサブスクリプションカスタマーに対しては無償で提供されることを発表できることを喜んでいます。

私たちのカスタマーは、彼らの開発とプロダクションへの配備を通して彼らを支えることで、プロダクト自身を開発することによる大きな投資と同じくらい、私たちのデベロッパーと良い関係を築き、楽しんでいます。さらに、Shieldを使うためのオプションを（追加費用無しで）提供することにわくわくしています。

私たちはShieldを、最も大変なセキュリティ要件でさえ満足させることができる、ELKスタックがセキュアになるためのone-stop店舗のように開発します。私たちは、カスタマーに対してこれを利用可能とすることに興奮し、同様にみなさんもそうであると望んでいます。

リリース日が近づくので、今後も楽しみにしてください。