@johtaniの日記 2nd

@johtani ‘s blog 2nd edition

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

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

原文: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設定ファイルで定義されます。 設定のサンプルは次のようになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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の両方に読み書きができるロール

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

1
2
3
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.authtrueを設定することで可能です。 設定した場合、ノード間で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になります)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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日の試用ライセンスが始まります。 もし、さらに時間が必要な場合は、[email protected]まで連絡してください。

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

Comments